Cyber Incident Response: What to Do in the First 72 Hours

Table of Contents

Cyber Incident Response: What to Do in the First 72 Hours

The decisions made in the first few hours after a security incident determine most of what follows — how far the damage spreads, whether data is recoverable, what your legal exposure looks like, and whether your insurer pays out. Most businesses discover this the hard way, because their "plan" amounts to calling whoever answers the phone and figuring it out from there.

This playbook covers what actually needs to happen in the first 72 hours after a confirmed or suspected cyber incident. It's written for small and mid-sized businesses that don't have a dedicated security team — organizations where the incident commander is often the IT manager, the CFO, or whoever happens to be in the building.

One important framing note before the framework: the 72-hour window isn't arbitrary. Attackers move faster than they used to. The median time between initial compromise and data exfiltration dropped from nine days in 2022 to roughly two days by 2024. That compression means the first hours of your response matter more than they ever did.

Before the Incident: What You Need in Place

A playbook you find during an incident is worth less than one you have ready before it. Three things need to exist before you need them:

A named incident commander. One person with authority to make decisions — isolate systems, engage outside help, approve spending, communicate externally. If that role isn't assigned in advance, three people will assume the other two are handling it, and an hour of containment time will disappear before anyone calls for help.

A contact list stored offline. Your cyber insurer's claims line, your legal counsel, your MSP's emergency number, the FBI's CyWatch line (1-855-292-3937), and CISA's 24/7 hotline (888-282-0870). If the incident takes down the system that holds this information, you need it somewhere else — printed, in a separate email account, on a personal device.

An offline copy of this playbook. The same logic applies. The plan cannot live only in the environment that may be compromised.

Hour 0–4: Confirm, Contain, Don't Contaminate

Step 1 — Confirm Something Actually Happened

Not every alert is an incident. Before escalating, someone with technical judgment needs to confirm that what you're seeing is real — ransomware note on a screen, confirmed unauthorized access, actual data exfiltration — and not a misconfigured alert or a user mistake. False positives happen. Starting a full incident response for a misconfigured monitoring rule costs real time and money.

That said, err on the side of treating ambiguous situations as real until you can prove otherwise. The cost of investigating a false positive is much lower than the cost of failing to contain an actual breach.

Step 2 — Isolate Affected Systems Immediately

The goal of containment is stopping lateral movement — preventing the attacker from spreading further through your environment. Standard containment steps:

Disconnect affected systems from the network — physically unplug the ethernet cable or disable the network interface. Don't just turn off Wi-Fi from the operating system; that may not be sufficient. For ransomware, disconnect from the internet entirely at the perimeter while you assess scope.

Do not shut systems down unless instructed by your forensic responder. Powering down a compromised system can destroy volatile memory that contains evidence — running processes, active network connections, encryption keys — that forensic analysts need to understand what happened and potentially recover data.

Do not wipe or reimage systems yet. The instinct to "clean" an infected machine immediately is understandable but wrong. You'll destroy the forensic evidence your insurer, your legal team, and law enforcement may need.

Step 3 — Notify Your Incident Response Team

Who gets called in the first hour depends on your organization's size and structure, but these roles need to be activated:

Incident commander — takes ownership of decisions and communication. IT lead or MSP — manages technical containment. Legal counsel — advises on notification obligations and evidence preservation. Cyber insurer — most policies require prompt notification; waiting can complicate or void coverage. For organizations without in-house legal, outside counsel with breach response experience is the call to make in the first hour.

For a 25-person company, these four roles may map to two or three people. That's fine. What's not fine is leaving any role uncovered.

Step 4 — Document Everything From This Moment Forward

Start a written incident log immediately — timestamps, decisions made, actions taken, who was notified and when. This documentation serves four purposes: it helps your forensic team reconstruct the timeline; it supports your insurance claim; it demonstrates reasonable diligence to regulators; and it protects you if litigation follows.

Use a separate device or paper to keep this log. Do not document the incident in systems that may be compromised.

Hour 4–24: Assess Scope and Engage Outside Help

Step 5 — Determine What Was Accessed or Exfiltrated

The scope question — what data was affected and how many individuals are involved — drives your legal notification obligations, your insurance claim, and your communication strategy. You probably won't have complete answers in the first 24 hours, but you need to start the assessment.

Work with your IT team or MSP to identify: which systems were accessed, what data those systems contain, whether logs show data leaving the environment, and what the likely entry point was. EDR and SIEM logs are your primary sources here — which is one of the reasons those tools matter before an incident, not just during one.

Step 6 — Engage a Forensic Responder if Needed

For incidents involving confirmed data access, ransomware, or any situation with regulatory implications, a professional forensic responder should be engaged. Your cyber insurer typically has a panel of pre-approved forensic firms — use them, both because they're vetted and because using an insurer-approved firm protects your claim.

A forensic responder preserves evidence correctly, identifies the attack vector and persistence mechanisms, determines the full scope of compromise, and produces documentation that holds up in regulatory investigations. Trying to investigate a significant breach with internal resources alone almost always results in incomplete findings and evidence contamination.

Step 7 — Assess Ransomware-Specific Decisions

If the incident is ransomware, the payment question will come up early. The FBI's position is clear: do not pay. Paying doesn't guarantee you'll get data back, funds threat actor groups directly, and may put you in legal jeopardy if the group is OFAC-sanctioned. Before any payment decision is made — and this decision should involve legal counsel — report to the FBI via IC3 (ic3.gov) and check the No More Ransom project (nomoreransom.org) for available decryptors. Some ransomware variants have known decryption tools that make payment unnecessary.

Regardless of whether you pay, report the incident. IC3 data feeds directly into FBI field offices. In cases involving wire transfers or ransomware payments, the FBI's Recovery Asset Team has frozen funds — sometimes within days of a report. Every unreported incident makes tracking and disrupting threat groups harder.

Hour 24–72: Notify, Report, Communicate

Step 8 — Understand Your Notification Obligations

Notification requirements vary by industry, data type, and geography. Get these wrong and you compound a security incident with a compliance violation.

If you handle protected health information (HIPAA): Affected individuals must be notified within 60 days of discovery. For breaches affecting 500 or more individuals, HHS Office for Civil Rights must also be notified within 60 days, and prominent media outlets in affected states must be notified if 500 or more residents of a single state are affected. For breaches under 500 individuals, HHS reporting can be deferred to within 60 days after year-end — but individual notification still runs from the 60-day clock from discovery. Business associates must notify covered entities within 60 days of discovery. Note that many state breach laws impose shorter deadlines — New York's SHIELD Act, for example, requires notification "in the most expedient time possible." HIPAA's 60-day limit doesn't override a state law requiring faster notice.

If you hold federal defense contracts (DFARS/CMMC): DFARS clause 252.204-7012 requires reporting cyber incidents to the Department of Defense within 72 hours. This is not optional — non-compliance can cost you your contract. Report via the DoD's DIBNet portal.

All organizations: Every U.S. state has data breach notification laws covering personal information — names combined with Social Security numbers, financial account numbers, driver's license numbers, or health information. Timelines and covered data types vary by state. Your legal counsel needs to map the applicable state laws based on where your affected individuals reside, not where your business is located.

Step 9 — Report to Law Enforcement

Two federal contacts matter for most SMB incidents:

FBI IC3 (ic3.gov) — file a detailed complaint including the incident type, what data was involved, any attacker contact information, and — for ransomware — the variant name if known, the ransom demand amount, and cryptocurrency addresses used. IC3 can't respond to every complaint, but the data feeds FBI field offices and has led to fund recovery in wire fraud and ransomware cases.

CISA (cisa.gov/report or 888-282-0870) — CISA doesn't investigate crimes, but provides technical assistance and uses incident reports to warn other organizations about active threats. For incidents involving critical infrastructure or significant operational disruption, CISA contact is particularly valuable.

For incidents involving wire fraud or business email compromise where funds were transferred, contact your bank's fraud department immediately — not after you've done everything else. The FBI's Financial Fraud Kill Chain has successfully recalled fraudulent wire transfers, but only if initiated quickly. Within 24 hours significantly improves odds of recovery.

Step 10 — Draft External Communications

The communications question — what to tell customers, partners, and employees — needs legal review before anything goes out. A few principles:

Be accurate about what you know and honest about what you don't. Overclaiming ("no data was accessed") before the forensic investigation is complete creates significant liability if the finding later contradicts the statement. Saying "we are investigating the scope of the incident and will provide updates as our review progresses" is both accurate and defensible.

Don't communicate externally before your legal team has reviewed the message. Breach notification letters in particular have specific content requirements under state laws — description of the incident, types of information involved, steps affected individuals can take, what you're doing to investigate and prevent recurrence.

Notify affected employees first, before news of the incident reaches them from outside the organization.

After 72 Hours: Recovery and Post-Incident Review

The 72-hour window covers containment, initial forensics, and notification triggers. What follows is recovery — restoring systems from clean backups, rebuilding compromised infrastructure, patching the entry point, and implementing controls that would have prevented the incident.

Recovery sequencing matters. Restore the most critical systems first. Before restoring from backup, confirm the backup predates the compromise — restoring from an infected backup reintroduces the attacker. Verify the integrity of restored systems before reconnecting them to the network.

The post-incident review, conducted after the dust has settled, is where organizations either learn from what happened or repeat it. A structured review should answer: How did the attacker get in? What controls failed or were absent? How long were they in the environment before detection? What slowed the response? What would have been different with the controls now being considered?

This review also feeds the documentation that regulators, insurers, and potential plaintiffs may eventually ask for — evidence that the organization responded reasonably, investigated thoroughly, and took remedial action.

What Most SMBs Get Wrong

A few failure patterns appear in almost every incident where the response goes poorly:

Wiping systems immediately. The instinct to clean infected machines destroys forensic evidence and can make it impossible to determine scope — which directly affects notification obligations and insurance claims.

Delaying the insurer call. Cyber policies often require prompt notification as a condition of coverage. Waiting until you have "all the facts" before calling your insurer can result in a denied claim.

Paying ransom without legal review. Ransomware groups on OFAC's sanctions list make ransom payments legally problematic — paying a sanctioned group can itself generate regulatory exposure. This is a legal question, not just a business one.

Restoring from backup without verifying it's clean. Backups taken after the attacker established persistence may contain malware. Restoring from an infected backup resets the clock, not the problem.

Not testing the plan before the incident. A tabletop exercise — running a scenario, walking through who calls whom and what decisions get made — takes a few hours and surfaces gaps that only appear under pressure. Organizations that have done tabletop exercises respond measurably faster and make fewer consequential mistakes than those encountering the process for the first time during an actual incident.

How Stratify IT Can Help

Incident response preparation — documented plans, tested backups, forensic-ready logging, and defined escalation paths — is built into how Stratify IT structures managed IT engagements. For organizations that experience a security incident, we provide technical response support, evidence preservation guidance, and coordination with forensic responders and legal counsel.

The controls that make incident response faster and less damaging — EDR on all endpoints, SIEM log monitoring, tested backup and recovery, MFA enforcement — are the same controls that reduce the probability of reaching this playbook in the first place. Our strategic security services cover both the preventive layer and the response framework.

For organizations that handle PHI or hold defense contracts, HIPAA compliance and CMMC compliance programs include incident response plan development as part of the required documentation. A plan that exists only to satisfy an auditor is better than no plan — but one that has actually been tested is what protects you when something goes wrong.

Contact Stratify IT to discuss where your current incident response preparedness stands and what a structured assessment of your environment would cover.