Incident response plan
incident-response-planDomain: cybersecurityType: processDescription
An incident-response plan is both a document and a practiced workflow. The document captures the playbook that runs when a cybersecurity incident is detected; the workflow is what the response team actually does when the playbook is invoked under real-world conditions. The point of having both is to compress the time between detection and containment, and to produce the artifact a regulator or insurer asks for after the fact. The canonical NIST framing in SP 800-61 organizes the work into six phases: preparation, detection and analysis, containment, eradication, recovery, and post-incident review. Most modern cybersecurity regulations either reference NIST directly or carry a structurally similar skeleton, which means an operator with one well-designed plan can usually map it to the obligations under several different regimes rather than maintaining parallel playbooks. The regulatory bar has lifted materially in the last several years. CIRCIA, the US Cyber Incident Reporting for Critical Infrastructure Act with rules published in 2024, compresses reporting timelines to 72 hours for covered cyber incidents and 24 hours for ransomware payments by covered entities; the scope sweep is broader than most operators initially assume and reaches well beyond traditional critical-infrastructure operators. NIS2 (Directive (EU) 2022/2555) Article 21 lays out specific cybersecurity-risk-management measures including incident handling, with member-state competent authorities supervising the implementation; the Article 23 reporting cascade is 24 hours for an early warning, 72 hours for an incident notification, and a month for the final report. GDPR Article 32 sits underneath both as the privacy-side anchor; PDPL, KVKK, APPI, CSL, PIPEDA, and the Australian Privacy Act each carry their own variants. Brazil's LGPD points the same direction through Article 46. The shape of an actually-functional plan covers eight pieces. The detection layer (logging, alerting, SIEM thresholds) that surfaces incidents at a time when containment is still cheap. The triage rubric that distinguishes a true incident from a noisy alert. The containment playbook with named actors and named tools; the named-actors part is the one that breaks most often when the named actor has changed roles since the plan was last updated. The eradication and recovery sequence with rollback points. The communication tree (internal, customer, regulator, law-enforcement) with templates for each. The evidence-preservation procedure that satisfies both forensic and regulatory expectations. The post-incident review with a documented set of process changes. And the calendar that schedules the tabletop exercises against the plan. The plan itself is necessary but not sufficient. The regulatory and contractual question that follows almost every incident is whether the plan was tested, whether the testing exercised the parts that mattered, and whether the people on the response team had run the playbook before they had to run it for real. Tabletop exercises (executives walking through a scripted incident, decision points and all) are the cheap pre-incident investment that most consistently produces a faster real-world response. The absence of recent tabletop documentation is one of the things that tends to surface in post-incident regulator conversations, alongside the documentation of the response itself; an operator with a thorough plan but no record of testing it in the prior 12 months tends to face the same regulatory follow-up as an operator with no plan at all.
Required by (12 regulations)
- APPI
Act on the Protection of Personal Information (Act No. 57 of 2003, as amended by Act No. 44 of 2020, effective April 1, 2022)
- CIRCIA
- CSL
Cybersecurity Law of the People's Republic of China (adopted November 7, 2016, effective June 1, 2017)
- GDPR
Article 32 — security of processing.
Regulation (EU) 2016/679 of the European Parliament and of the Council
- LGPD
Lei nº 13.709, de 14 de agosto de 2018 (as amended by Lei nº 13.853/2019 and Emenda Constitucional nº 115/2022)
- NIS2
Article 21 — incident-handling cybersecurity risk management measures.
- Privacy Act
Privacy Act 1988 (Cth), No. 119 of 1988
- Anti-Cyber Crime Law
Royal Decree M/17, Anti-Cyber Crime Law, issued 8/3/1428 AH (March 26, 2007)
- PDPL
Royal Decree M/19, dated 9/2/1443 AH (September 16, 2021), Personal Data Protection Law, effective September 14, 2023
- KVKK
- EU CRA
Supports the CRA's severe-incident and actively-exploited-vulnerability reporting duty (Article 14) — the response and notification process behind the 24-hour early warning and 72-hour full notification.
Regulation (EU) 2024/2847 (Cyber Resilience Act)
- China CIIPA
China CIIPA requires critical-information-infrastructure operators to maintain incident-response capabilities.
Regulations on the Security Protection of Critical Information Infrastructure (State Council Order No. 745); implementing Cybersecurity Law Articles 31-39
Fulfilled by (4)
- sentry · partial · low effort · $Detection layer only.
- datadog · partial · medium effort · $$
- In-house build · medium effort
- crowdstrike · partial · medium effort · $$$Falcon endpoint detection + IR services as part of an incident playbook.
Magist does not accept payment from vendors. Methodology.
Evidence formats
- incident response playbook
- tabletop-exercise records
- incident retrospective archive