Incident Response Plan: Structure, Roles, and the 72-Hour Clock

What this policy is

The IR plan exists because incidents are won or lost in the first hour. Without a written plan, the response becomes a set of individually reasonable decisions made under pressure by people who have never rehearsed the scenario together. The result is predictable: systems are contained unevenly, evidence is destroyed by well-meaning remediation, regulators are notified late or not at all, and customers learn about the problem from Twitter.

The plan is also a compliance artefact. UK GDPR Article 33 requires controllers to notify the ICO within 72 hours of becoming aware of a personal-data breach. ISO/IEC 27001:2022 Annex A.5.24 through A.5.27 requires documented incident management, planning, response and learning. NIS2 Article 23 requires notification to the competent authority with an initial early warning within 24 hours. DORA Article 17 requires ICT incident classification and reporting for financial-services firms. The SEC's 2023 rules require public filers to disclose material cyber incidents on Form 8-K within four business days. Every one of these regulators expects to see a written plan, and will ask about it.

The plan is not a runbook. Runbooks cover specific incidents (e.g., compromised credentials, ransomware on the file server, supplier breach) with technical steps. The IR plan sits above them and provides the framework: who declares an incident, what severity levels mean, who makes the notification decision, how communications flow, when the plan is closed. A good plan is short and legible by the general counsel and the CFO, not only the security team.

Who needs one

Every organisation processing personal data or running information systems needs an IR plan. That threshold is broader than “mature security programme”; it is effectively universal under UK GDPR. More specifically:

• Any UK or EU data controller or processor — UK GDPR Article 33 and Article 32(1)(b) require the ability to detect, respond to and report personal-data breaches.
• Any organisation pursuing ISO/IEC 27001 certification — Annex A.5.24–A.5.27 is auditor bait without a documented plan.
• Essential and important entities under NIS2 — financial services, energy, water, transport, health, digital infrastructure and managed-security providers in the EU and, by analogy, in UK implementations.
• Financial-services firms subject to DORA — EU firms and their UK/Swiss/US counterparts mapping to DORA through contractual inheritance.
• Listed US filers — SEC disclosure rules require materiality determination and 8-K filing; the IR plan encodes the materiality committee and its decision thresholds.
• Public-sector bodies — UK HMG Security Policy Framework, NCSC guidance and sector-specific rules (NHS DSP Toolkit, PSN) all presume a plan.
• Any organisation carrying cyber insurance — insurers increasingly require a documented plan as a condition of coverage and will subrogate if it is absent at the time of claim.

What must be in it

A defensible IR plan covers the clauses below. Length should be short enough to read end-to-end in thirty minutes and long enough to answer the questions that will be asked at 2am.

• Scope and definitions — precise definitions of event, incident and breach, with the cross-reference to UK GDPR Article 4(12). A worked example for each category prevents the reflex to escalate everything to “breach”.
• Roles — the incident commander (usually the CISO or head of security), the executive sponsor (CEO or COO for material incidents), the legal lead (general counsel or retained external counsel), the data protection officer where one is appointed, the communications lead (head of PR or CMO), the technical lead (engineering or ops), and the customer-success lead for customer-facing incidents. Named deputies for every role because the incident will not wait for the primary.
• The six phases — Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned (NIST IR 800-61r2). Each phase defined by entry and exit criteria, not just activities. Exit criteria matter most: how do you know you are done with Containment and can move to Eradication?
• Severity classification — a four- or five-level scheme (commonly P1 Critical / P2 High / P3 Moderate / P4 Low / P5 Informational) with clear triggers: number of users affected, systems offline, data classes involved, regulatory implications, media interest. The plan must state who can declare each level; the CISO for P1/P2, duty engineer for P3 and below.
• Escalation and communications — the escalation tree with names and out-of-hours contact numbers, the cadence of internal updates during an active incident (hourly for P1, every four hours for P2), the template for customer notification, and the approved channels (never reveal active IR details on social media, always synchronise customer-facing and regulator-facing statements).
• Regulator notification timelines — a decision matrix matching the incident facts to the regulator and the deadline. ICO 72 hours for personal-data breaches. NIS2 24 hours for early warning and 72 hours for incident notification, one-month final report. DORA classification within four hours and major-incident report within 24 hours. SEC 8-K within four business days of materiality determination. State-level US breach-notification laws (California, New York SHIELD, Massachusetts 93H) with their own thresholds.
• Forensic evidence preservation — the requirement to preserve system images, logs and volatile memory before remediation; chain of custody; the engagement of external forensics where the incident is serious enough; the prohibition on over-writing evidence during triage.
• Customer notification criteria and templates — pre-approved wording for customer-facing notifications, differentiated by severity and data class, cleared by legal and PR in advance so that during an active incident the only work is adapting facts, not drafting from scratch.
• Post-incident review — the written lessons-learned report within two weeks of closure, distributed internally, feeding back into the plan, controls and training. Auditors will ask to see evidence that prior incidents drove change.
• Plan ownership and review cadence — named owner (the CISO), annual full review, more frequent partial reviews after material changes to the environment, versioning of the document.

Common pitfalls

1. The plan exists but has never been rehearsed

A plan that has never been tabletopped is worth roughly what it cost to write. The first time a plan is exercised, structural problems appear: the escalation list has out-of-date numbers, the legal lead has never worked with the CISO under pressure, nobody knows who holds the cyber-insurance policy number. Run a full tabletop annually and a short scenario quarterly.

2. Treating it as an IT document

IR plans that live in the security team's SharePoint and have never been read by legal, PR or the CEO fail the first time a material incident happens. The plan is an organisational document and its rehearsal must include the non-technical roles, because the failure mode is never a shortage of technical skill; it is the legal-PR-exec coordination.

3. Missing the 72-hour clock

The ICO clock starts at awareness, not at occurrence, and the ICO is clear that speculative awareness does not start it but confirmed compromise does. The most common failure is organisations that spend the first 72 hours investigating whether they have a breach, concluding at hour 71 that they do, and missing notification. The fix is a triage rule: any plausible personal-data compromise enters the notification workflow immediately, even if the assessment continues in parallel; late withdrawal is cheaper than late notification.

4. No severity definition

Without written severity levels, every incident becomes P1 because that is the only one anyone has the language for. The consequence is that the executive is in the room for a misplaced laptop and asleep for a full-scale ransomware event because both looked the same on the incident ticket.

5. Confusing event, incident and breach

Teams that use the three words interchangeably over-notify (turning events into regulator filings) or under-notify (treating breaches as mere incidents). A short worked-examples annex resolves most of this: “failed login from unknown IP is an event; the same login succeeding is an incident; the successful login followed by personal-data exfiltration is a breach.”

6. No pre-agreed external counsel

Engaging a law firm for the first time at 2am of a live ransomware event costs a full business day and produces the worst advice you will ever receive. Pre-contract an external counsel under a retainer or letter of engagement that can be activated immediately. The same applies to external forensics providers.

7. Out-of-date contact information

The single most common failure of any IR plan. The CFO has changed mobile number; the external counsel you used two years ago has retired; the cyber-insurance broker's out-of-hours line is stale. Quarterly review of the contact list, done by the CISO's assistant, is a simple control that auditors specifically look for.

8. Plan has no defined end

Incidents drag on because there are no defined exit criteria for the final “recovery” phase. A clear criterion (“production service metrics at pre-incident baseline for 72 hours, root cause remediated and verified, customer communications closed out, lessons-learned scheduled”) gives the IR team permission to formally stand down.

Framework mapping

Incident response plan mapped to frameworks and legal instruments

Framework	Reference	What it requires
NIST IR 800-61r2	Sections 2–3	The six-phase model (Preparation, Identification, Containment, Eradication, Recovery, Lessons Learned) and the policy-team-procedure stack.
ISO/IEC 27001:2022	Annex A.5.24 — A.5.27	Incident management planning, assessment, response and learning — each as a separate auditable control.
UK GDPR	Articles 33 & 34	72-hour breach notification to the ICO; notification to affected data subjects where the breach is likely to result in high risk.
EU GDPR	Articles 33 & 34	Identical structure; notification goes to the lead supervisory authority under the one-stop-shop mechanism.
NIS2 Directive (EU 2022/2555)	Article 23	Early warning within 24 hours, incident notification within 72 hours, final report within one month for significant incidents.
DORA (EU 2022/2554)	Article 17 & ITS/RTS	ICT incident classification (major, significant, recurring), reporting to competent authority within 4 hours of classification, intermediate and final reports.
SEC (US 17 CFR 229.106)	Form 8-K Item 1.05	Disclosure of material cyber incidents within four business days of materiality determination.
SOC 2 (AICPA TSC 2017)	CC7.4	The entity identifies, develops and implements activities to recover from identified security incidents.

How it fits with other policies

• Data Breach Response Policy — the specific sub-plan for personal-data breaches, operating the UK GDPR Article 33–34 workflow; it sits inside the IR plan as one of its runbooks.
• Business Continuity Plan (BCP) — picks up where the IR plan ends: if the incident has caused a business-impacting outage, BCP governs how the business continues to operate while IR restores systems.
• Disaster Recovery Policy — the technical sub-plan for restoring systems and data; IR coordinates the overall response but hands the DR runbook to the engineering team during the Recovery phase.
• Privacy Policy (UK GDPR) — the public-facing disclosure of rights; its “right to complain to the ICO” clause is exercised when affected subjects are notified.
• Data Retention Policy — interacts with the IR plan through the legal-hold mechanism; incidents often trigger a legal hold that suspends scheduled deletion of affected records.
• Third-Party Risk & Contracting Policy — defines how processor-side incidents feed into the controller's IR plan; the DPA should require 24-hour notification from the processor.

Frequently asked questions

When does the UK GDPR 72-hour breach notification clock start?

The clock starts when the controller becomes aware of the personal-data breach, not when it occurred. The ICO's guidance is explicit: awareness means having a reasonable degree of certainty that a security incident has led to personal data being compromised. Speculative indications do not start the clock; confirmed compromise does. Document the moment of awareness with a timestamped entry because the ICO will ask if notification was delayed. Even if the 72 hours are missed, still notify: a late notification with a good reason attached is far better than a hidden breach later discovered by the regulator.

What is the difference between an event, an incident, and a breach?

An event is any observable occurrence in a system or network. An incident is an event that compromises, or threatens to compromise, confidentiality, integrity or availability. A personal-data breach (UK GDPR Article 4(12)) is a specific subtype of incident involving accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. These distinctions matter because they drive different notification obligations: events are logged, incidents are managed, breaches may trigger regulator and subject notifications. An IR plan that conflates them will over- or under-notify.

Do we need to notify the ICO if no personal data was affected?

Not under UK GDPR Article 33, which only covers personal-data breaches. However, other regulators have different triggers. NIS2 Article 23 requires notification to the competent authority for significant incidents in essential and important entities regardless of personal-data involvement. DORA requires ICT incident classification for financial-services firms. SEC 10-K and 8-K disclosure rules apply to material cyber incidents in listed US filers whether or not personal data is involved. Your IR plan should have a decision matrix for each regulator you are subject to.

How often should we run tabletop exercises?

At least annually for the full plan; quarterly for specific scenarios (ransomware, credential compromise, supplier breach) if you operate critical systems or hold special category data. ISO/IEC 27001:2022 Annex A.5.26 expects tested incident procedures; auditors will ask for exercise reports. The exercise should include the legal, PR and executive functions, not only technical staff, because those are the roles that most commonly fail under real-incident pressure. A plan that has never been rehearsed has roughly the same value as no plan at all.

Should the incident response plan be public?

No, and a common mistake is to publish it on an intranet or help desk where it is indexable externally. The plan reveals your detection capabilities, your escalation tree and your external counsel, all of which are attacker intelligence. Publish a short public-facing statement about your approach (for vendor security questionnaires), but keep the plan itself in a controlled location with access limited to the response team and their backups. Print copies should be held in at least one physical location in case of a total systems outage.

Related guides