We've been breached — what do we do now?

What to do now

Audience: the founder, CTO, CISO, or whoever is on-call and just learned something is wrong. You do not need certainty that this is a 'breach' before you act. NIST SP 800-61r2 treats incident handling as starting at detection and analysis — declare, document, then decide. The first 15 minutes are a separate checklist; this page is the hub that tells you the first moves and how the next hours are supposed to unfold.

• Declare an incident and name a single commander. Split command is how evidence and containment drift.
• Open a comms channel the actor cannot see. CISA's ransomware guidance tells responders to isolate in a coordinated way and use out-of-band methods (phone, a clean bridge) so the actor does not watch you respond.
• Start a contemporaneous log in UTC: who noticed what, when, which systems, which actions. SANS's Incident Handler's Handbook treats contemporaneous notes as part of identification, not a write-up you do later.
• Isolate likely-affected systems from the network if spread is plausible. The FTC's Data Breach Response guide says take affected equipment offline — and leave the machines on until forensic experts arrive.
• Preserve volatile evidence first: memory, current network connections, running processes, logs that rotate. Do not power down, reimage, or wipe. NIST SP 800-61r2's evidence-handling guidance is acquire, preserve, secure, and document — eradication comes later.
• Page the people your plan names (leadership, counsel, whoever owns cyber insurance notice). You can still be wrong; you cannot un-lose the first hour.

Do not do this

The failures that make a bad hour irreversible are almost always well-intentioned. They sit above the fold because they happen before anyone opens a playbook.

• Do not reimage, restore from backup, or 'just rebuild' an affected host yet. That is eradication. It destroys the disk and memory evidence DFIR and insurers will ask for. NIST SP 800-61r2 and the SANS handbook both put evidence preservation before cleanup.
• Do not power down as the first containment move. Volatile memory holds encryption keys, fileless malware, and live connections. CISA's ransomware guidance allows powering down only when you cannot isolate the host from the network, and it states that this step loses volatile evidence.
• Do not delete logs, purge mailboxes, or tidy the environment so it 'looks contained'. The FTC guide is explicit: do not destroy forensic evidence during investigation and remediation.
• Do not tip the actor. No in-band 'we see you' messages, no public status page, no reset of every password from the possibly compromised identity plane until you have an out-of-band path. CISA warns that actors monitor response activity and will move laterally or deploy ransomware if they know they have been found.
• Do not wait for a complete picture before you isolate and log. Completeness is a later timebox. The first minutes are stop-the-bleeding and keep-the-evidence.

How the next hours are supposed to go

After the first 15 minutes, the work is timeboxed so notification clocks and containment decisions are not improvised. The first-15-minutes, first-hour, first-24-hours, first-72-hours, and first-week checklists are on this site. Use the first-15-minutes checklist now, then continue in this order.

First hour: scope affected systems and accounts, decide contain-versus-observe (some intrusions are watched briefly so you can find the persistence; most ransomware is contained immediately), and escalate to leadership, counsel, and the insurer if your policy requires prompt notice.

First 24 hours: finish short-term containment, onboard DFIR if you need it, and map which reporting clocks may have started. Clocks are jurisdiction- and fact-specific. One example that is a legal requirement only when it applies: Regulation (EU) 2024/2847 (the Cyber Resilience Act) Article 14 sets a 24-hour early-warning / 72-hour notification / 14-day final-report ladder to ENISA for actively exploited vulnerabilities on in-scope products with digital elements. Whether you are in scope is a legal determination. Verify against the regulation and counsel — this page does not decide it.

First 72 hours: notification determinations (regulators, customers, partners) belong here, not in minute five. US state breach-notification statutes exist in every state plus DC, Puerto Rico, and the US Virgin Islands, per the FTC guide; the FTC guide itself is regulator guidance, not a statute. Sector rules (HIPAA, the FTC Health Breach Notification Rule, and others) may also apply. Confirm applicability and current deadlines with counsel.

First week: recovery, root-cause work, and a post-incident review. NIST SP 800-61r2's last phase is post-incident activity; the SANS PICERL model ends at lessons learned. Do not skip the write-up because the systems are back.

Legal requirement, regulator guidance, industry practice

These are not the same thing, and mixing them is how a hub page turns into fake legal advice.

Where this shows up in ShipReady Metrics

Only if you already use the signed-in app — these are not public incident-response tools, and an unauthenticated visitor will not reach them.

CRA Article 14 reporting for actively exploited vulnerabilities lives under Compliance readiness. It tracks the 24-hour / 72-hour / 14-day ladder from your recorded awareness; it does not start a clock for you, and it is not a determination that CRA applies. The cyber risk register lives under Security. Open findings, remediation status, and KEV/EPSS ranking live on Security findings. None of those surfaces preserve volatile evidence, isolate a host, or notify a regulator.

Primary sources (last verified 7 September 2026)

Every operational claim on this page is taken from one of these. If a later revision of a source changes the advice, the date above is how you can see we have not re-checked yet.

NIST SP 800-61 Revision 2 remains the current final Computer Security Incident Handling Guide (August 2012). Treat it as guidance, not a statute. CISA's playbooks are operational procedures written for federal civilian executive branch information systems. The SANS handbook is a practitioner checklist, not a regulator document. The FTC guide is business guidance from a US regulator; the legal notification duties are in the statutes it points at, not in the guide itself.

Frequently asked questions