Something is wrong. A user can't log in. Files are encrypted. Your IT admin is getting strange alerts. Or it's simpler than that: your accounting system is gone and there's a ransom note on the screen.
Whatever the trigger, you're in the worst possible position: facing a possible security incident with no rehearsed response, uncertain who to call first, and acutely aware that the decisions you make in the next few hours will determine whether this is a manageable disruption or an organizational catastrophe.
This guide is written for exactly that situation. It's not written for experienced incident responders — it's written for the IT manager, the operations director, or the small business owner who needs to know what to do right now, before professional help arrives.
Before you read further: If you are actively experiencing a ransomware attack or believe attackers are currently in your systems: do not turn off systems — preserve forensic evidence. Do not pay ransom without professional guidance. Do isolate affected systems from the network immediately by disconnecting ethernet and disabling Wi-Fi. Then continue reading.
the first decision: is this actually an incident?
The most important judgment call in the first few minutes is distinguishing a confirmed incident from a suspicious indicator that requires investigation.
Treat the following as confirmed incidents requiring immediate response: visible ransomware notes or encrypted files, confirmed unauthorized access to systems or accounts, active credential theft or account takeover, evidence of data exfiltration, or a credible external notification from law enforcement, CISA, or MS-ISAC.
Treat the following as requiring urgent investigation but not yet full incident response: unusual login times or locations for a single user account, unexpected software installed on endpoints, anomalous outbound network traffic, suspicious but not confirmed malicious email. These need immediate attention — but isolation and shutdown decisions can wait until you have more information.
hours 0–2: stabilize and preserve
contain without destroying evidence
The most counterintuitive guidance in incident response is this: do not immediately shut everything down. Modern forensic investigation relies heavily on volatile data — running processes, active network connections, memory contents — that is lost permanently when a system is powered off. Shutting down too quickly destroys exactly the evidence you'll need to understand what happened.
The correct containment action is network isolation: disconnect affected systems from the network without shutting them down. Pull ethernet cables. Disable Wi-Fi adapters at the OS level. This prevents attacker communication and further lateral movement while preserving the forensic state of running systems.
Checklist for hours 0–2:
- Isolate affected systems from the network (disconnect ethernet, disable Wi-Fi)
- Disable compromised accounts — do NOT just change passwords (attacker may have established persistence elsewhere)
- Preserve all logs: firewall, authentication, email, endpoint — do not delete or overwrite anything
- Document everything with timestamps: what you found, when, and what actions you took
- Photograph or screenshot ransom notes and unusual screens before touching anything
- Identify your backups and verify they are not connected to the affected network
notify leadership and engage help
This is not a decision you should make alone. If you have credible indicators of a significant incident, notify leadership immediately. The business implications — legal, regulatory, reputational — extend far beyond IT.
Simultaneously: engage outside help. If you have a relationship with an incident response firm or a managed security service provider, call them now. If you have cyber insurance, call your insurer — most policies include access to an IR response team. If you're a government entity, contact MS-ISAC (available 24/7 at 866-787-4722 for SLTT members).
hours 2–6: assess and understand
understand what you're dealing with
Once initial containment is in place and you have outside help engaged, the focus shifts to understanding scope.
Checklist for hours 2–6:
- Identify patient zero: which system or account was the likely initial access point?
- Map which systems have had contact with the suspected compromised system since the estimated compromise time
- Review authentication logs for unusual activity: off-hours logins, unfamiliar locations, accounts accessing systems they don't normally access
- Check for new user accounts, especially administrative ones, created in recent days or weeks
- Review outbound network traffic logs for large transfers or connections to unusual external destinations
- Determine what data was accessible from compromised systems: customer data, financial data, PII, PHI
assess backup status and recovery options
In parallel with investigation, assess your recovery options. The sooner you understand what's available to you, the less pressure you'll feel to make hasty decisions like paying ransom.
- Identify your most recent clean backup and the systems it covers
- Verify the backup itself has not been compromised or encrypted
- Estimate restoration time: how long will it take to restore critical systems from backup?
- Identify which operations can continue manually while systems are down, and for how long
hours 6–12: communicate and comply
manage communications carefully
Communication during an incident is a legal and reputational minefield. The general guidance: say less publicly until you know more, say it accurately, and say it through the right channels.
Internal communications should be factual and calm. If your communication systems themselves are compromised (email, Slack, Teams), establish an out-of-band channel for coordination.
External communication — to customers, the public, regulators — should wait until you have legal counsel involved. What you say, to whom, and when you say it has significant legal implications.
Regulatory notification requirements: Healthcare organizations with PHI: HIPAA requires breach notification within 60 days of discovery. Financial services: depends heavily on state law and applicable federal regulations. Government entities: check your state's cybersecurity incident reporting requirements — many states now require notification to a state CISO or cybersecurity office within 72 hours.
hours 12–24: recover with purpose
structured recovery — not just restoration
The goal of this phase is to restore critical operations while preserving investigative integrity. Work with your incident response support to sequence this appropriately.
Checklist for hours 12–24:
- Do NOT restore systems into the same network segment or with the same credentials — the compromise path must be closed before restoration begins
- Prioritize restoration of your most critical operations: payroll, patient records, essential services
- Restore from clean backup onto clean systems — do not attempt to "clean" a compromised system in-place
- Rotate all credentials (passwords, API keys, service account secrets) before restoring access
- Enable enhanced logging on restored systems from day one of their return to operation
- Document all actions taken throughout the incident for legal and insurance purposes
what comes after 24 hours
The first 24 hours are about stabilization, containment, and initial recovery. The work that follows — root cause analysis, full scope determination, regulatory compliance, remediation planning, and lessons learned — typically takes weeks to months.
The quality of that work depends heavily on how well the first 24 hours were handled: whether evidence was preserved, whether communications were managed carefully, and whether the right outside resources were engaged early.
The best preparation for an incident is having an incident response plan that's been reviewed, communicated to key stakeholders, and tested before you need it. If you don't have one, building even a basic version — identifying who does what, who gets called, and what the decision framework is — is time better spent today than it will be at 2am when something is wrong.