First week after a breach

What the first week is for

Audience: the incident commander and the leadership, counsel, insurer, and DFIR already on the out-of-band bridge. The first 72 hours walked the notification clocks that may have come due. The first week is recovery you can defend, individual-notice timing (which is not a single 7-day rule), the start of the CRA final-report band if that duty applies, packaging the evidence so it survives the rebuild, and a handoff into root-cause and post-incident review. Dedicated RCA, containment-and-recovery-docs, and post-incident-review guides are not on this site yet; NIST SP 800-61r2's last phase is still post-incident activity, and the SANS PICERL model still ends at lessons learned.

Do not skip the write-up because the systems are back. A recovered estate with no timeline, no image, and no decision log is how week two becomes an argument.

• Validate recovery against a checklist, not a feeling that the site is up.
• Keep the evidence hold on the original artifacts. Rebuild is not delete.
• Plan individual notice with counsel. GDPR Article 34 and US state statutes are not a uniform week-one filing. Verify per jurisdiction.
• If CRA Article 14 applies and a corrective or mitigating measure is available, the 14-day final-report clock for the vulnerability track runs from that availability — not from day one of the week, and not from awareness.
• Package the timeline, images, hold list, and filings so the next person can use them.
• Schedule the post-incident review. Do not wait for a quiet month.

Recovery-validation checklist

NIST SP 800-61r2 sequences containment, then eradication, then recovery. The SANS PICERL model does the same. Recovery before a forensic image, or restore from a dirty primary, is how you re-infect the estate and destroy the investigation. CISA's ransomware guidance treats rebuild as a last-resort containment move, not a default, because it costs volatile evidence. The FTC Data Breach Response guide: do not destroy forensic evidence during investigation and remediation.

• Confirm memory and disk images exist (or DFIR has said they are not needed) before you rebuild a host.
• Eradicate: remove the malware or persistence you actually found, disable breached accounts, rotate credentials from a clean identity plane — not from the possibly compromised one.
• Restore from known-good backups or a clean image, not by 'refreshing' the copy that was live at detection.
• Validate: the service functions, logging and monitoring are on, and the persistence you found is gone. Watch for reinfection. Record who signed that off, in UTC.
• Keep the original compromised artifacts under the evidence hold. Recovery of the production path is not permission to wipe the exhibit.
• Every recovery action is a new timeline line: time, owner, system, what was done, who authorised it. NIST SP 800-61r2: acquire, preserve, secure, and document.

CRA 14-day final report — if it applies

Regulation (EU) 2024/2847 Article 14 is a legal requirement only when CRA applies to you. For an actively exploited vulnerability, Article 14(2)(c) requires a final report no later than 14 days after a corrective or mitigating measure is available. That clock runs from measure availability, not from awareness, and not from the Monday of the incident week. The 24-hour early warning and 72-hour notification should already be in flight or filed; a final report does not replace them. Article 14 reporting applies from 11 September 2026. Last verified 7 September 2026. Not legal advice.

For a severe incident having an impact on the security of the product, the final-report timing differs from the vulnerability track. The European Commission's CRA summary (Commission services, not the regulation) describes a final report within one month from the 72-hour submission for severe incidents. Confirm against Article 14 and counsel; this page does not apply the incident-track deadline. Scope, 'product with digital elements', 'actively exploited', 'severe', and 'measure available' are legal and factual tests.

• If you are not in CRA scope, do not invent a 14-day ENISA filing because the incident was serious.
• If you are in scope on the vulnerability track, record when the corrective or mitigating measure became available. That timestamp starts the 14-day clock. Missing it is how the deadline becomes an argument.
• The final report is a different artifact from the 72-hour notification. Do not assume the earlier filing discharged it.
• Filing CRA never discharges GDPR, and the reverse.

Individual notification — timing is not one number

There is no single 'notify customers in week one' rule. GDPR Article 34 is a legal requirement only when it applies: when the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller communicates the breach to the data subject without undue delay. That is not a 72-hour clock and not a 7-day clock. Article 34(3) sets exceptions (including encryption that renders the data unintelligible, subsequent measures that make the high risk no longer likely, and disproportionate effort with a public communication instead). Confirm against the regulation and counsel.

US individual-notice timing lives in state and sector statutes. The FTC Data Breach Response guide (regulator guidance, not a statute) tells businesses to notify affected parties when the facts require it, and notes that every US state plus DC, Puerto Rico, and the Virgin Islands has a security-breach notification law; HIPAA and the FTC Health Breach Notification Rule may also apply. Deadlines and triggers differ. Verify per jurisdiction. Last verified 7 September 2026. Not legal advice.

Operationally, CISA still warns that public or in-band messages tip the actor. Individual notice is a counselled decision coordinated with containment, not a status-page reflex because the calendar says week one.

Evidence packaging and the handoff into review

Week one is when the investigation's working papers either become a package or start to rot. NIST SP 800-61r2's post-incident activity includes lessons learned and using the experience to improve; its evidence-handling guidance is still acquire, preserve, secure, and document. The SANS PICERL model ends at lessons learned. Do not wait for a dedicated RCA or post-incident-review page on this site — those guides are not published here yet — to keep the artifacts.

• Package: UTC timeline, evidence-hold list, images and their chain-of-custody notes, contain-versus-observe decision, eradication and recovery sign-offs, regulator or insurer filings actually sent, and the list of unknowns.
• One owner for the package (usually the commander or counsel). Split folders are how a disk image goes missing.
• Do not tidy the contemporaneous log into a 'clean' narrative and throw the original away. The reconstructed write-up is a different document.
• Schedule the post-incident review while the facts are still in living memory. NIST treats that meeting as part of handling, not optional culture.
• Root-cause work starts from the timeline and the images, not from a blame session. A longer RCA guide is not on this site yet; the operational rule is: write what failed, what you changed, and what you still do not know.

Where this shows up in ShipReady Metrics

The signed-in app does not run this week-one plan, validate your recovery, or file a notice. If you already have a session: signed-in app → Compliance → CRA reporting tracks the 24-hour / 72-hour / 14-day ladder from your recorded awareness and, for the final-report stage, from recorded measure-available time — for findings the org has classified as CRA-in-scope actively exploited vulnerabilities. It does not start a clock for you, it does not track a separate CRA incident-track final-report deadline, it does not assess GDPR Article 34, and it is not a determination that CRA applies. A named human still submits. The cyber risk register lives under Security; the obligation map (frameworks you have marked in-scope) is under Compliance. None of those surfaces restore a host or notify a data subject.

Primary sources (last verified 7 September 2026)

Every operational and regulatory 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.

Regulation (EU) 2024/2847 Article 14 is a legal requirement only when CRA applies. The European Commission's CRA summary is Commission-services text to aid reading; it is not the Official Journal. Regulation (EU) 2016/679 Article 34 is a legal requirement only when GDPR applies. NIST SP 800-61 Revision 2 remains the current final Computer Security Incident Handling Guide (August 2012) — guidance, not a statute. CISA's playbooks are operational procedures written for US federal civilian executive branch information systems. The SANS handbook is a practitioner checklist. 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