What is an incident response plan?

Article 33 of the GDPR gives a controller 72 hours from becoming aware of a personal data breach to notify the supervisory authority. Not 72 hours from containment. Not 72 hours from the forensic report.

In the case of a personal data breach, the controller shall without undue delay and, where feasible, not later than 72 hours after having become aware of it, notify the personal data breach to the supervisory authority. (Regulation (EU) 2016/679, Article 33(1))

That is one clock. There are usually several, and they start at different moments in the same incident. None of them pause while someone works out who is allowed to answer the phone.

An incident response plan is the document that answers the questions nobody can answer calmly at 03:00. Most of those questions are about authority, not technique. The analyst watching files get renamed to .locked across a file server generally knows what to do. What they do not know is whether they are allowed to do it, who to wake, and what their action does to the company's disclosure position.

NIST SP 800-61 Rev. 3, published April 2025, supersedes the 2012 Rev. 2 and restates incident response as a CSF 2.0 Community Profile rather than a standalone four-phase lifecycle. The centre of gravity is still preparation. The plan is the artifact preparation produces.

Who declares, and who un-declares

The first line of a usable plan names the role that can declare an incident. A role, not a person. "Duty incident manager" survives holidays and resignations. "Sarah in security ops" does not.

Declaration authority has to be reachable at 03:00 on a Sunday, which means the plan carries a rota with a phone number and a documented escalation after two failed attempts. It also has to be delegated downward. If only the CISO can declare, then every incident that starts at 02:00 starts with a voicemail.

The half that plans routinely omit is who can stand an incident down. Nobody wants to end a war room and turn out to be wrong, so incidents drift for days at full staffing. Name the role that closes, and state the criteria: containment verified, eradication confirmed on the affected hosts, no new detections tied to the campaign for a defined window.

Severity definitions that actually separate

Vague severity definitions collapse into a single level. If your bands read "significant business impact" versus "moderate business impact", every ticket becomes a P2, because P2 is the choice nobody gets criticised for. Severity has to be decidable by a tired analyst from evidence on screen.

Write the criteria as observable conditions. "Domain controller compromised" is decidable. "High impact" is a debate. If a criterion cannot be checked against a log, a console or a phone call in five minutes, it is not a criterion.

Pre-authorised containment

The two-hour approval hunt is the most expensive failure mode in this document, and it is entirely preventable. An analyst who can see lateral movement should not be paging a VP to ask whether isolating a host is permitted.

Pre-authorisation is a table of standing permissions, agreed in daylight, signed by whoever owns the systems:

Action                                    Pre-authorised at   Notify after
Isolate endpoint (EDR containment)        Sev 3+, analyst     Asset owner, 30 min
Disable user account, revoke sessions     Sev 2+, analyst     Line manager, 30 min
Block egress IP / domain at perimeter     Sev 2+, analyst     Network on-call, 1 h
Force password reset, whole domain        Sev 1, IM           CISO, immediately
Disconnect production system from network Sev 1, IM + service owner (or IM alone after 15 min no contact)
Power off a system (destroys memory)      Never without IR lead sign-off

Two details make that table work. The escalation path has a timeout, so an unreachable service owner cannot block containment indefinitely. And powering off is treated as a destructive act, because it discards memory that the investigation may need.

Out-of-band communications

A plan stored only on the file share is not a plan, it is a hostage. The same intrusion that requires the plan is the one that encrypts it. Corporate email and chat fail the same way when identity is compromised, and worse, an attacker with mailbox access reads your response as you coordinate it.

The plan needs a communication path that does not depend on the estate:

• A signed PDF copy on the phone of everyone on the call tree, refreshed each quarter.

• A printed copy in the office and at the DR site.

• A conference bridge on a separate provider with a dial-in number that does not require SSO.

• A pre-created out-of-band chat space (a separate tenant or a consumer secure messenger) with the responder group already added. Creating it during the incident means adding people from a directory you no longer trust.

Test the call tree, not just the plan. The common finding in a first tabletop is that two numbers belong to people who left, and one belongs to an outsourced service desk that was replaced eighteen months ago.

Notification triggers and their clocks

Regulatory clocks belong in the plan with the trigger that starts them, named in the same line. Two that apply widely:

• GDPR Article 33(1). Notification to the supervisory authority without undue delay and, where feasible, not later than 72 hours after the controller becomes aware of a personal data breach, unless the breach is unlikely to result in a risk to individuals. Late notification must be accompanied by reasons for the delay.

• SEC Form 8-K Item 1.05. The final rules took effect on 5 September 2023, but Item 1.05 itself became binding on 18 December 2023 for US registrants other than smaller reporting companies, and on 15 June 2024 for smaller reporting companies. Disclosure of a material cybersecurity incident within four business days of determining that the incident is material. The materiality determination itself must be made without unreasonable delay. Item 1.05(c) permits a delay only where the US Attorney General determines that disclosure poses a substantial risk to national security or public safety and notifies the Commission in writing, initially for up to 30 days.

Note what the SEC clock hangs on. It does not start at detection, it starts at a determination, and the determination is a decision made by named people using a documented process. That process is part of the plan or it does not exist. Sector rules add their own clocks, so the plan should carry the ones that apply to your jurisdictions and contracts, each with its trigger, its owner and its recipient.

External parties, with real numbers

Every external party in the plan needs a name, a 24/7 number, a contract reference and a note on what they are pre-approved to do.

IR retainer     <firm>   24/7 hotline, retainer #, prepaid hours, SLA to first responder
Cyber insurer   <carrier> claims notice line, policy #, notice deadline per policy,
                          panel vendor list (using an off-panel firm can void cover)
Outside counsel <firm>   partner + mobile, engagement letter on file, privilege routing
Law enforcement          local cyber unit / national CERT, reporting portal
Key suppliers            cloud, MSP, payroll: security contact and escalation

Cyber policies commonly require notice to the carrier and use of panel vendors before you engage anyone. Read yours before the incident. Discovering that constraint at hour six, after your own forensics firm has imaged three hosts, is a coverage argument nobody wants.

The detection that skips triage

Some events are severity definitions in themselves. Mass shadow copy deletion is one. It is a precursor to encryption (T1490, Inhibit System Recovery, usually followed by T1486, Data Encrypted for Impact), and when it fires on a server there is nothing left to triage. It declares.

title: Shadow copy and backup catalog deletion
id: 5b4b0f0c-7d2e-4f6f-9a4b-2f3d6f1c8a91
status: experimental
description: Detects deletion of volume shadow copies or the backup catalog, a
    common precursor to ransomware encryption
references:
    - https://attack.mitre.org/techniques/T1490/
logsource:
    category: process_creation
    product: windows
detection:
    selection_vssadmin:
        Image|endswith: '\vssadmin.exe'
        CommandLine|contains|all:
            - 'delete'
            - 'shadows'
    selection_wmic:
        Image|endswith: '\wmic.exe'
        CommandLine|contains|all:
            - 'shadowcopy'
            - 'delete'
    selection_wbadmin:
        Image|endswith: '\wbadmin.exe'
        CommandLine|contains|all:
            - 'delete'
            - 'catalog'
    condition: 1 of selection_*
falsepositives:
    - Backup and imaging software pruning old restore points
    - Administrative disk cleanup scripts on low-storage file servers
level: high
tags:
    - attack.impact
    - attack.t1490

What it catches: the default command lines used by most commodity ransomware families before encryption. What it misses: a renamed binary, since the selections match on Image. Add OriginalFileName to close that. It also misses shadow copy deletion through the VSS COM API, through Get-WmiObject Win32_Shadowcopy | Remove-WmiObject in PowerShell, and recovery tampering via bcdedit /set recoveryenabled No, which is a different rule.

It needs process creation telemetry with command lines. That is Sysmon Event ID 1, or Security Event ID 4688 with Audit Process Creation enabled and the "Include command line in process creation events" policy switched on. Without the second setting, 4688 records the image path and no arguments, and every contains in the rule above matches nothing. More Windows process-execution coverage is in the catalog.

The plan is not the capability

An untested plan is a compliance artifact. It has a version number, an approver and no evidence that anyone can execute it.

The tabletop converts it. Two hours, the actual responders, a scenario with injects, and one rule: if the answer is "we would check the plan", someone opens the plan and reads out the answer. That single rule finds most of the defects in a first exercise. The severity band everyone interprets differently. The pre-authorisation matrix naming a team that was reorganised. The bridge number that goes to a disconnected line.

Run one after material changes and after real incidents, then track the defects as findings with owners and dates. A plan that has closed twenty findings is a different document from one approved twice and opened never. For the mechanics of running the response itself, see what incident response actually involves.

Summary

An incident response plan exists to remove decisions from the worst possible moment to make them. Its most valuable content is not technical procedure but authority: who declares, who stands down, who can disconnect production without asking, and which clocks start when. Severity levels must be decidable from observable evidence, or everything becomes the middle band. Store it off the estate, with a call tree you have dialled, and treat the tabletop as the thing that turns the document into a capability.

Minimum contents to check your plan against:

[ ] Declaration authority by role, with 24/7 rota and escalation timeout
[ ] Un-declaration authority and closure criteria
[ ] Severity bands with observable, decidable criteria per level
[ ] Pre-authorised containment actions per severity, with unreachable-owner timeouts
[ ] Power-off treated as destructive, requires named sign-off
[ ] Offline copy: phones, printed, DR site. Quarterly refresh
[ ] Out-of-band bridge and chat, pre-created, no SSO dependency
[ ] Notification triggers with clock, owner and recipient per obligation
[ ] External contacts: IR retainer, insurer, counsel, CERT, key suppliers
[ ] Telemetry prerequisites: process creation with command line, EDR isolation tested
[ ] Tabletop cadence, findings log with owners and dates