Incident Response Plan
Defines the response organisation, phases, decision authorities and hand-offs used for every incident regardless of type.
Available soon
- Format
- Word
- Size
- 85 KB
- Length
- 34 pages
- Version
- 1.5
- Updated
What's inside
- Purpose and objectives
- Scope
- The response phases
- Roles and the crisis team
- Severity at a glance
- Decision rights
- Reporting duties
- Communications
- Suppliers in an incident
- Resources
- Playbook index
- Contact directory
- Yearly calendar
- Measures of success
- How the plan ran on 12 August 2026
- Related documents
- Approval and review
- Adapting this template
- Framework references
- Definitions
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
Purpose and objectives
This plan is how [[Organisation Name]] responds to every information security incident, whatever its type: who does what, in which order, who decides, who must be told and by when, and what has to be ready before anything happens. It carries out the Security Incident Management Policy, and applies the rules IM-01 to IM-12 by number. The playbooks add the steps for the incidents that need their own; this plan is the response for all the others, and the frame the playbooks sit in.
The plan has four objectives, each with a measure the quarterly report shows (IM-12):
- Stop the harm quickly. Contain every incident before it spreads, and every significant one within [[24]] hours of detection (IMM-01).
- Tell the right people on time. Escalate within the times the severity sets, and make every report to an authority, a controller or the people affected by its deadline (IMM-02).
- Recover safely. Return nothing to service until the recovery criteria are met, so the attacker does not come back through the same door (IM-10).
- Learn. Review every serious incident, finish the actions it produces, and exercise the plan every year (IMM-03, IMM-04).
Guidance — delete before approval
Read this plan with the Incident Classification, Severity & Escalation Matrix open beside it: the plan says who does what; the matrix says how serious an incident is and how fast each clock runs. Keep both, with the contact directory, where you can read them when every system is down (see Resources).
Scope
The plan applies to every event reported under the Security Incident Management Policy and every incident declared from it, at every severity: [[all sites, systems, services and data of Organisation Name, including those run for it by suppliers]]. Severity 3 and 4 incidents follow the same phases with fewer people: the IT service desk or the incident manager runs them in working hours, and nobody else is called unless the severity rises. Severity 1 and 2 incidents bring in the executive incident lead and, for Severity 1, the crisis team and the board.
Not covered here: [[business continuity events with no security cause, e.g. a power cut or a flood, which follow the business continuity plan — the two plans hand over to each other when an incident disrupts a service]].
The response phases
Every incident moves through the same seven phases. Several can run at once — containment starts while triage is still being completed, and the reporting screen runs alongside containment — but none is skipped. Each phase has one owner and a recorded output; the output is what the next phase and the post-incident review rely on.
Phase | Owner | Output | Rules |
|---|---|---|---|
Prepare | Head of Information Security | An approved plan; a contact directory checked in the last quarter; an exercise report from the last 12 months; the readiness checklist completed. | IM-12 |
Detect and report | Reporter | A report in the case log with the time and the reporter. | IM-01, IM-13 |
Triage and declare | Incident manager | A declared incident with a case number, incident manager, category and severity; escalations made; the reporting screen complete within 4 hours. | IM-02, IM-03, IM-04, IM-05, IM-06 |
Contain | Incident manager | Containment recorded with its time; the evidence log started; every decision with business impact in the decision log. | IM-07, IM-08, IM-09 |
Eradicate | Technical responders | The cause and the route in recorded; the route closed; credentials changed. | IM-07 |
Recover | Technical responders | A recovery sign-off for each system; the monitoring period passed; the incident closed. | IM-10 |
Review | Head of Information Security | The review report within 10 working days of closure for Severity 1 and 2; actions in the case log; the plan's revision history. | IM-11, IM-12 |
Prepare
Keep the plan, the contact directory, the playbooks and the resources ready; train the people in the roles and their deputies; exercise the plan.
Owner: Head of Information Security. Output: an approved plan; a contact directory checked in the last quarter; an exercise report from the last 12 months; the readiness checklist completed. Governed by: IM-12; Incident Response Readiness Checklist.
Detect and report
Anyone who sees something suspicious reports it at once through the reporting route; monitoring alerts reach the IT service desk or the incident manager directly.
Owner: Reporter. Output: a report in the case log with the time and the reporter. Governed by: IM-01, IM-13; Incident Case & Action Log.
- The reporting route: [[phone number, email address and portal]], answered by the IT service desk in working hours ([[08:00–18:00, Monday to Friday]]) and by [[the on-call incident manager, or the security monitoring provider]] outside them.
- Alerts: the security monitoring service's alerts go to [[the service desk queue and the on-call incident manager's phone]]; an alert is a report and starts the triage clock.
Triage and declare
The service desk triages the report within the IM-02 times; the incident manager declares an incident or closes the event with a reason, sets category and severity, escalates, and starts the reporting screen.
Owner: Incident manager. Output: a declared incident with a case number, incident manager, category and severity; escalations made; the reporting screen complete within 4 hours. Governed by: IM-02, IM-03, IM-04, IM-05, IM-06; Incident Classification, Severity & Escalation Matrix; Incident Triage & First-Hour Assessment Procedure.
Triage starts within 30 minutes of the report in working hours and 60 minutes outside them, and ends within [[30]] minutes of starting with the event closed with a reason or declared an incident (IM-02). Once the incident manager declares an incident, the first hour runs in this order (the Incident Triage & First-Hour Assessment Procedure gives the detail):
- Open the case. Give it a case number, record the time of declaration (the start of every reporting clock) and the reporter.
- Set severity and category. Use the matrix. When in doubt, choose the higher severity.
- Escalate. Tell the people the severity requires, within its time.
- Contain what is spreading. Isolate before investigating when harm is spreading, with the least disruptive containment that stops it; otherwise preserve evidence first.
- Start the reporting screen. Ask the three legal questions (NIS2, GDPR, DORA where it applies) and the contract and insurance questions. The screen is complete within 4 hours (IM-06).
- Set the next update. Agree when the team reconvenes, and send the first internal update.
Contain
Stop the harm spreading with the least disruptive containment that does it: isolate systems, sites or accounts, block the attacker's routes, and preserve evidence unless waiting would let the harm spread.
Owner: Incident manager. Output: containment recorded with its time; the evidence log started; every decision with business impact in the decision log. Governed by: IM-07, IM-08, IM-09; Ransomware Response Playbook; Business Email Compromise Response Playbook; Personal Data Breach Response Playbook; Incident Communications Template Set.
- Isolate or preserve first? Preserve evidence first unless the harm is spreading; if it is spreading, isolate first and record what was lost (IM-07).
- Least disruptive first: the incident manager contains at once, with the least disruptive action that stops the harm (an account, a device, a segment or the attacker's route in, before a whole service). Waiting for an executive is never a reason to let harm spread (IM-08).
- Business impact: containment that stops a customer-facing service is the executive incident lead's decision, except where waiting would let the harm spread. Before any action that would stop a service people depend on for safety or essential operations, the incident manager brings in its service owner and specialists (IM-08). See Decision rights.
- Updates: send updates at the interval the severity sets (Severity 1 every 2 hours; Severity 2 every 4 hours; Severity 3 every 24 hours), using the approved templates (IM-09).
Eradicate
Find the cause and the way in; remove the attacker's access, tools and persistence; change credentials that could have been taken; close the route in.
Owner: Technical responders. Output: the cause and the route in recorded; the route closed; credentials changed. Governed by: IM-07; Ransomware Response Playbook; Business Email Compromise Response Playbook.
- Assume the attacker had more than you have found: change the credentials of every account used on an affected system, including service accounts and administrators, and check for new accounts, mail rules, scheduled tasks and remote access tools.
- Do not rebuild before the evidence is safe (IM-07). A rebuilt machine cannot tell you how the attacker got in.
Recover
Restore from backups or rebuild images checked for integrity; bring services back in order of business priority; watch them closely for the monitoring period.
Owner: Technical responders. Output: a recovery sign-off for each system; the monitoring period passed; the incident closed. Governed by: IM-10; Ransomware Response Playbook.
A system returns to normal service only when all of these are true (IM-10):
- The cause is understood well enough that the same route in is closed.
- Backups or rebuild images were checked for integrity before they were used.
- Restored systems are patched, scanned and monitored, with credentials changed where they could have been taken.
- The system owner has tested the service and confirms it works.
- The monitoring period has started: [[7]] calendar days of closer watching for Severity 1 and 2 before closure.
The incident manager closes the incident when the recovery criteria are met, the monitoring period of 7 calendar days (Severity 1 and 2) has passed without recurrence, and the case log is complete.
Review
Review what happened and how the response went; agree actions with owners and dates; reassess the risks the incident touched; update this plan. Severity 3 and 4 incidents are reviewed together once a quarter.
Owner: Head of Information Security. Output: the review report within 10 working days of closure for Severity 1 and 2; actions in the case log; the plan's revision history. Governed by: IM-11, IM-12; Post-Incident Review Template; Incident Case & Action Log.
The post-incident review uses the Post-Incident Review Template. It asks what happened, what went well, what did not, and why; it is not a search for someone to blame. Its actions go into the Incident Case & Action Log with an owner and a due date (default [[within 90 calendar days]]), and the risks the incident touched are reassessed in the Information Security Risk Register (Information Security Risk Management pack).
Roles and the crisis team
Every role has a named deputy with the same authority while acting in it. Names and numbers are in the contact directory; the roles are defined here so that they survive a change of people.
Role | In an incident | Deputy |
|---|---|---|
Incident manager [[e.g. Information Security Manager, with a named deputy]] | Runs the response from declaration to closure; declares, sets category and severity; escalates; directs the responders; completes the reporting screen; keeps the case log and the decision log. May isolate systems, sites and accounts at once, with the least disruptive containment that stops the harm; brings in the service owner and specialists before stopping a service people depend on for safety or essential operations. | [[Role]] |
Executive incident lead [[e.g. Chief Operating Officer, with a named deputy]] | Takes the decisions with business impact; approves reports to authorities and what is said outside; chairs the crisis team; briefs the board. | [[Role]] |
Head of Information Security [[e.g. Head of Information Security or CISO]] | Owns this plan; advises the incident manager; runs the post-incident review and the yearly exercise. | [[Role]] |
IT service desk [[internal service desk, or the managed IT provider's]] | Receives reports and alerts; triages within the IM-02 times; handles Severity 4 incidents; calls the incident manager for anything larger. | [[Role]] |
Technical responders [[IT operations, the managed IT provider and the security monitoring provider]] | Contain, investigate, eradicate and recover under the incident manager's direction; preserve evidence; check backups before restoring. | [[Named lead at each]] |
Data Protection Officer [[or the privacy lead where no DPO is appointed]] | Assesses every incident involving personal data for risk to individuals; advises on GDPR reports; keeps the breach record. | [[Role]] |
Legal [[in-house or external counsel]] | Advises on reporting duties, contracts, evidence, law enforcement and any extortion demand; engages outside counsel. | [[Role]] |
Communications lead [[e.g. Head of Marketing and Communications]] | The only voice outside the organisation (IM-09); prepares every message from the approved templates. | [[Role]] |
Board [[the board chair, or the equivalent where there is no board]] | Is told of every Severity 1 incident; alone decides on any ransom or extortion demand. | [[Vice-chair, or equivalent]] |
The crisis team
Members: [[executive incident lead, incident manager, Head of IT, Legal, DPO, communications lead, and the owners of affected services]]. Chair: the executive incident lead. Convened: for every Severity 1 incident, within 1 hour of declaration, and for a Severity 2 incident when the executive incident lead decides. Meets: in the war room, or on the out-of-band service, at the update interval the severity sets, until containment; then as the chair decides.
Every crisis team meeting follows the same agenda:
- What we know, what we do not know, and what has changed since the last meeting.
- Severity and category: still right? Anyone may raise severity; only the incident manager lowers it.
- Is harm still spreading? What containment is under way, and what is it costing the business?
- Decisions needed now, and who has the right to take each one.
- The reporting screen: which reports are due, to whom, and by when.
- Communications: staff, customers, suppliers, media — what is said, by whom, from which template.
- People and resources: who is tired, who takes over, and whether outside help is needed.
- The time of the next update and the next meeting.
Guidance — delete before approval
Name a deputy for every role, and make sure the deputy has taken part in an exercise. Most serious incidents start at night, at a weekend or in the holidays, and the first hours are run by whoever answers the phone.
The incident manager and the executive incident lead must be different people. One runs the response; the other decides what the business can bear and answers for it.
Severity at a glance
Severity is the highest level any impact area reaches, judged on what the incident has done or is capable of doing. When in doubt, choose the higher level. Severity is reviewed at every update and can be raised by anyone on the response team; it is lowered only by the incident manager, with the reason recorded in the case log. The full criteria for each impact area are in the Incident Classification, Severity & Escalation Matrix; this summary is what the response team works from.
Severity | Impact level | Who leads | Who is told, and how fast | Updates | Working pattern |
|---|---|---|---|---|---|
Severity 1 Critical | Severe | Incident manager, with the executive incident lead deciding | Incident manager at once; executive incident lead within 30 minutes; crisis team convened within 1 hour; board chair, or equivalent, within 4 hours | Every 2 hours | Round the clock until contained |
Severity 2 High | Major | Incident manager | Incident manager at once; executive incident lead within 2 hours | Every 4 hours | Extended hours as needed |
Severity 3 Medium | Moderate | Incident manager, or the IT service desk under their direction | Incident manager at once; Head of Information Security the same working day | Every 24 hours | Working hours |
Severity 4 Low | Minor | IT service desk | IT service desk logs and handles it; Head of Information Security in the weekly summary | None scheduled | Working hours; closed within [[5]] working days |
Times run from declaration. Severity is reviewed at every update (IM-04); a rise in severity brings in the people the new level requires at once.
Decision rights
These decisions have business impact, so the plan says in advance who may take them. Waiting for the executive is never a reason to let harm spread (IM-08). The one limit: before any action that would stop a service people depend on for safety or essential operations, its service owner and specialists are brought in, and containment goes on meanwhile.
Decision | Who decides | Conditions |
|---|---|---|
Isolate a system, site or account | Incident manager | Use the least disruptive containment that stops the harm, and bring in the service owner and specialists before any action that would stop a service people depend on for safety or essential operations. Tell the executive incident lead at the next update. |
Stop a customer-facing service | Executive incident lead | The incident manager may do it first where waiting would let the harm spread, and reports it at once. Where people depend on the service for safety or essential operations, its service owner and specialists are brought in first. |
Report to an authority | Executive incident lead, on the incident manager's reporting screen | The Data Protection Officer advises on GDPR reports. A report is never held back to avoid a deadline. |
Say anything outside the organisation | Communications lead, with the executive incident lead's approval | Only from the approved templates (IM-09). |
Engage outside responders or the insurer's panel | Incident manager, within the [[retainer]]; above it the executive incident lead | — |
Pay a ransom or extortion demand | Only the board or its equivalent | Never before legal advice (including sanctions checks), the insurer's view and a report to law enforcement. The plan assumes we do not pay. |
Ransom and extortion. Only the board or its equivalent may decide on a ransom or extortion demand (IM-08), and only once the conditions in the table are met. The sanctions check names each regime that could apply: the US Treasury's OFAC rules, under which liability can be strict, and any EU or UK sanctions regime that binds you. A non-US organisation can be exposed where a US person or a US dollar payment is involved. OFAC reviews licence requests for ransomware payments case by case, with a presumption of denial, and the US government strongly discourages payment. Paying does not guarantee decryption or deletion of stolen data. The report to law enforcement is made in the first hours, so that it is not waiting on the decision: OFAC treats an early, complete, self-initiated report as a significant mitigating factor. The Ransomware Response Playbook sets out what the board is told, and when.
Where the US duties apply, two more decisions have named owners:
Decision | Who decides | Conditions |
|---|---|---|
Determine that an incident is material (registrants) | [[Disclosure committee, or the chief financial officer with the General Counsel]]; the audit committee is informed | Made without unreasonable delay after discovery, on the facts known at the time, and never held back to avoid or postpone the four business days of RD-21. The time of the determination and the reasons are recorded in the case log; if it is not yet made, the reason it is not made yet is recorded at each update. |
Pay an extortion demand (entities covered by New York's financial services rules) | Only the board or its equivalent, as for any ransom (IM-08) | A payment opens RD-23 (notice within 24 hours) and RD-24 (a written description within 30 days of why it was necessary, the alternatives considered and the diligence done, including sanctions checks). Never before legal advice. |
Every decision in this table is recorded in the decision log with its time, who took it and why, whether or not it turned out to be right.
Reporting duties
Every incident is screened against every reporting duty within 4 hours of declaration, and the decision and its reasons recorded whether or not a report is made (IM-06). The screen asks three legal questions, then the contract, insurance and law-enforcement questions:
Law | Question | If yes |
|---|---|---|
NIS2 | Are we an essential or important entity, and has this incident caused, or could it cause, severe operational disruption or financial loss to us, or considerable damage to others? | RD-01 to RD-05 |
GDPR | Is personal data affected (confidentiality, integrity or availability)? If so, is the breach unlikely to result in a risk to individuals, a risk, or a high risk? | RD-06 to RD-09 |
DORA | Are we a financial entity, and does the incident affect critical services and meet the thresholds of Delegated Regulation (EU) 2024/1772 Articles 8 and 9? | RD-10 to RD-13 |
The duties the screen can trigger are below, grouped by where they come from. The clocks run from awareness — the moment the reporting clocks start: the time the incident is declared, as recorded in the case log, unless the record shows we had reasonable certainty earlier, in which case the earlier time. The pack chooses this deliberately. The legal tests turn on what we knew: the EDPB's Guidelines 9/2022 treat a controller as aware once it has a reasonable degree of certainty that a breach occurred, and NIS2 counts from becoming aware of a significant incident, judged on an initial assessment. A late declaration therefore does not postpone a clock the law starts earlier. The Incident Classification, Severity & Escalation Matrix gives each clock in full and the Incident Communications Template Set the approved content for each report.
ID | Report | Deadline | To | Applies to |
|---|---|---|---|---|
RD-01 | NIS2: Early warning | Within 24 hours of awareness | [[CSIRT or competent authority]] | Essential and important entities, for a significant incident |
RD-02 | NIS2: Incident notification | Within 72 hours of awareness | [[CSIRT or competent authority]] | Essential and important entities, for a significant incident |
RD-03 | NIS2: Intermediate report | When the authority asks | [[CSIRT or competent authority]] | Essential and important entities, for a significant incident |
RD-04 | NIS2: Final report | Within one month of the incident notification (a progress report then, and the final report within one month of handling, if still ongoing) | [[CSIRT or competent authority]] | Essential and important entities, for a significant incident |
RD-05 | NIS2: Notice to recipients of our services | Without undue delay, where appropriate | Customers whose service is likely to be adversely affected | Essential and important entities, for a significant incident |
RD-06 | GDPR: Notification to the supervisory authority | Without undue delay and, where feasible, within 72 hours of awareness; later only with reasons for the delay | [[lead supervisory authority]] | Controllers, unless the breach is unlikely to result in a risk to individuals |
RD-07 | GDPR: Communication to the individuals affected | Without undue delay | The data subjects | Controllers, where the breach is likely to result in a high risk to individuals, unless an Article 34(3) condition is met |
RD-08 | GDPR: Breach record | For every personal data breach, notified or not | Kept by us; shown to the authority on request | Controllers |
RD-09 | GDPR: Notice to the controller | Without undue delay | The controller whose data we process | Where we act as a processor |
RD-10 | DORA: Initial notification | Within 4 hours of classifying the incident as major, and no later than 24 hours after awareness; where it is classified as major only after those 24 hours, within 4 hours of that classification | [[financial competent authority]] | Financial entities, for a major ICT-related incident |
RD-11 | DORA: Intermediate report | Within 72 hours of the initial notification, and again when regular activities are recovered | [[financial competent authority]] | Financial entities, for a major ICT-related incident |
RD-12 | DORA: Final report | No later than one month after the latest intermediate report | [[financial competent authority]] | Financial entities, for a major ICT-related incident |
RD-13 | DORA: Notice to clients | Without undue delay | Clients whose financial interests are affected | Financial entities, for a major ICT-related incident |
RD-14 | Contract: Notice to customers under contract | [[as each contract requires]] | [[customers with a notification clause]] | Where a contract requires it |
RD-15 | Insurance: Notice to the cyber insurer | [[as the policy requires, often within 48 hours]] | [[insurer or broker incident line]] | Where a cyber policy is held |
RD-16 | Law enforcement: Crime report | [[as soon as practical for suspected crime]] | [[national cybercrime reporting service]] | Suspected criminal acts, including ransomware and fraud |
The US duties
The US duties are for organisations that are subject to them: HIPAA covered entities and business associates, companies that file reports with the SEC, entities licensed by the New York Department of Financial Services, and organisations that hold personal information of State residents. State laws are shown as placeholders with California and New York as examples; every State has its own. This is not legal advice; ask counsel which duties apply. Where they apply, the screen asks five more questions, in this order:
Law | Question | If yes |
|---|---|---|
HIPAA | Are we a covered entity or a business associate, and was protected health information acquired, accessed, used or disclosed in a way the Privacy Rule does not permit? That is presumed to be a breach unless a risk assessment of the four factors shows a low probability of compromise. If it is a breach: how many individuals, and how many residents of any one State? | Duties RD-17 to RD-19 (covered entity); RD-20 (business associate) |
SEC | Are we a registrant, and has the incident been determined to be material, or could it be? Who is making that determination, and by when? | Duties RD-21 |
NYDFS | Do we operate under a licence or similar authorisation under the Banking Law, the Insurance Law or the Financial Services Law, and have we determined that a cybersecurity incident has occurred? Has an extortion payment been made? | Duties RD-22 (and RD-23 and RD-24 if a payment was made) |
State law | Are residents of any State affected, and is the data personal information as that State defines it? | Duties RD-25 to RD-27, once for each State |
FTC | Are we a financial institution under the FTC's jurisdiction and were 500 or more consumers' unencrypted records acquired, or are we a vendor of personal health records or a related entity that HIPAA does not cover? (A third-party service provider tells its customer instead.) | Duties RD-28; RD-29 |
The US clocks for HIPAA, the FTC's rules and State breach laws run from discovery, not from the declaration time that starts awareness. Record both times (IM-13). The SEC's clock runs from the materiality determination, New York's from the determination that a cybersecurity incident has occurred, and the extortion notices from the payment. The duties are below; the Incident Classification, Severity & Escalation Matrix gives each clock in full.
ID | Report | Deadline | To | Applies to |
|---|---|---|---|---|
RD-17 | HIPAA: Notification to each individual affected | Without unreasonable delay and in no case later than 60 calendar days after discovery | Each individual whose unsecured protected health information was, or is reasonably believed to have been, accessed, acquired, used or disclosed | Covered entities, for a breach of unsecured protected health information |
RD-18 | HIPAA: Notice to prominent media outlets | Without unreasonable delay and in no case later than 60 calendar days after discovery, where more than 500 residents of one State or jurisdiction are involved | Prominent media outlets serving the State or jurisdiction | Covered entities, for a breach involving more than 500 residents of a State or jurisdiction |
RD-19 | HIPAA: Notice to the Secretary of Health and Human Services | 500 or more individuals: contemporaneously with the notice to individuals (no later than 60 calendar days after discovery); fewer than 500: log the breach and report it within 60 days after the end of the calendar year of discovery | The Secretary of Health and Human Services, through the Office for Civil Rights breach portal | Covered entities, for any breach of unsecured protected health information |
RD-20 | HIPAA: Notice by a business associate to the covered entity | Without unreasonable delay and in no case later than 60 calendar days after discovery (the contract usually sets a shorter time) | [[the covered entity we serve]] | Business associates, for a breach of unsecured protected health information |
RD-21 | SEC: Current report on Form 8-K, Item 1.05 | Within four business days after the company determines the incident is material; missing information is filed by amendment within four business days after it is determined or becomes available; a filing whose transmission begins after 5:30 p.m. Eastern time is deemed filed on the next business day, so the last safe time is 5:30 p.m. Eastern on the fourth business day | The Securities and Exchange Commission, filed on EDGAR | Registrants, for a cybersecurity incident the registrant determines to be material |
RD-22 | NYDFS: Notice of a cybersecurity incident | As promptly as possible and no later than 72 hours after determining that a cybersecurity incident has occurred | The Superintendent of Financial Services, electronically | Covered entities: persons operating under a licence, registration, charter, certificate, permit, accreditation or similar authorisation under the Banking Law, the Insurance Law or the Financial Services Law |
RD-23 | NYDFS: Notice of an extortion payment | Within 24 hours of the extortion payment | The Superintendent of Financial Services, electronically | Covered entities that make an extortion payment in connection with a cybersecurity event |
RD-24 | NYDFS: Written description of why the payment was necessary | Within 30 days of the extortion payment | The Superintendent of Financial Services, electronically | Covered entities that make an extortion payment in connection with a cybersecurity event |
RD-25 | State law: Notice to residents of the State | [[the deadline of each State where affected residents live, for example 30 days]] | Residents of each State whose personal information was involved | Any organisation holding personal information of a State's residents; each State sets its own definition of personal information and its own test for a breach |
RD-26 | State law: Notice to the State attorney general or regulator | [[whether, when and above what number of residents each State requires it]] | [[the attorney general, or the regulator the State names, for each State]] | Organisations notifying residents of a State that requires it |
RD-27 | State law: Notice to consumer reporting agencies | [[where a State requires it, with its threshold]] | [[the consumer reporting agencies a State names]] | Organisations notifying more residents than a State's threshold |
RD-28 | FTC Safeguards: Notice to the Federal Trade Commission | As soon as possible and no later than 30 days after discovery of a notification event involving the information of at least 500 consumers | The Federal Trade Commission, electronically on its form | Financial institutions under the FTC's jurisdiction, for the acquisition without authorisation of unencrypted customer information of at least 500 consumers |
RD-29 | FTC Health Breach: Notices under the Health Breach Notification Rule | Without unreasonable delay and in no case later than 60 calendar days after discovery: individuals, and for 500 or more residents of a State the media; the FTC at the same time for 500 or more individuals, or in an annual log for fewer | Individuals; prominent media outlets; the Federal Trade Commission | Vendors of personal health records and PHR related entities, for a breach of security of unsecured PHR identifiable health information; not HIPAA covered entities, nor business associates acting as such. A third-party service provider owes the vendor or related entity a notice within the same 60 calendar days instead (16 CFR 318.3(b)) |
Some facts move a US deadline. They are modifiers, not duties, and each is recorded in writing with who stated it and when:
ID | Law | What changes | Duties |
|---|---|---|---|
DL-01 | HIPAA | If a law enforcement official states that notice would impede a criminal investigation or damage national security: a written statement that names a period delays the notice for that period; an oral statement is documented, with the identity of the official, and delays the notice for no longer than 30 days from the date of the oral statement, unless a written statement arrives in that time. | RD-17, RD-18, RD-19, RD-20 |
DL-02 | SEC | If the United States Attorney General determines that disclosure poses a substantial risk to national security or public safety and tells the Commission in writing: the company may delay for the period the Attorney General specifies, up to 30 days; for up to 30 more days if the Attorney General repeats the determination; and in extraordinary circumstances for up to 60 more, where the risk is to national security; any later delay only by Commission exemptive order. A registrant that is subject to the FCC's breach notification rule (47 CFR 64.2011) and is required to delay under it may delay for the period that rule applies, and no more than seven business days after its notice, if it tells the Commission by correspondence on EDGAR by the original due date (Item 1.05(d)). | RD-21 |
DL-03 | FTC Health Breach | The Rule has its own law-enforcement exception to the 60 calendar days. | RD-29 |
DL-04 | State law | [[Each State's law-enforcement delay and its other extensions, which each State sets for itself]] | RD-25, RD-26, RD-27 |
Guidance — delete before approval
EXAMPLE (US), from Example Health Group, Inc. (EXAMPLE), a US health services company that runs a health plan and a network of outpatient clinics, with about 2,800 staff and members in several States: A security analyst saw unusual queries against the patient portal database on the afternoon of 14 September and logged an event. The incident manager declared an incident the next morning, when the queries were tied to a stolen administrator credential. 3,200 members' names, dates of birth, member numbers and claims details were read, 640 of them California residents. The first person to know saw it on 14 Sep 2026, 16:40; the incident was declared on 15 Sep 2026, 09:10. The HIPAA and State clocks ran from the discovery, the New York clock from the determination at declaration, and the SEC clock from the materiality determination on 24 Sep 2026, 14:00.
Assumption: It is a HIPAA covered entity, and for one service also a business associate of other covered entities.
Assumption: Its shares are listed on a US exchange, so the SEC's rules for current reports apply to it. A private company reads the SEC rows as not applying.
Assumption: It holds a licence under the New York Insurance Law, so the Department of Financial Services' cybersecurity regulation applies. An organisation with no such licence reads those rows as not applying.
Assumption: It has members who live in California and New York, so those two States' laws are the examples; every other State has its own law.
Assumption: It is not a financial institution under the FTC's jurisdiction, so the FTC Safeguards Rule is not part of the example.
Duty | Report | Due | Made | Result |
|---|---|---|---|---|
RD-22 | NYDFS: Notice of a cybersecurity incident | 18 Sep 2026, 09:10 | 17 Sep 2026, 15:30 | On time |
RD-17 | HIPAA: Notification to each individual affected | end of 13 Nov 2026 | 28 Sep 2026, 10:00 | On time |
RD-18 | HIPAA: Notice to prominent media outlets | end of 13 Nov 2026 | 28 Sep 2026, 10:00 | On time |
RD-19 | HIPAA: Notice to the Secretary of Health and Human Services | end of 13 Nov 2026 | 28 Sep 2026, 10:30 | On time |
RD-21 | SEC: Current report on Form 8-K, Item 1.05 | 5:30 p.m. Eastern on 30 Sep 2026 | 29 Sep 2026, 16:20 | On time |
Named, not worked through: CIRCIA (The Cyber Incident Reporting for Critical Infrastructure Act of 2022 sets a 72-hour report for covered cyber incidents and a 24-hour report for ransom payments, but, as at 18 October 2026, the Cybersecurity and Infrastructure Security Agency had not published the final rule that makes them binding (CISA says it is still working on the final rule, and reporting is not required until the final rule takes effect). Check its current status.) DFARS (Contractors that handle covered defense information report cyber incidents to the Department of Defense within 72 hours of discovery under DFARS 252.204-7012.) Also not covered: foreign private issuers, which report on Form 6-K and not Form 8-K; sector rules outside the screen above; and each State's detail beyond the two examples.
Guidance — delete before approval
Replace each authority placeholder with the authority your national law names, and put its reporting route in the contact directory. If you are not an essential or important entity under NIS2 and not a financial entity under DORA, keep the questions anyway: the screen takes minutes, and a wrong assumption about status is how deadlines are missed.
A report is never held back to avoid a deadline. Make the report with what is known and add detail later: every regime allows it.
Communications
Only the communications lead speaks for the organisation outside it, and only from the approved templates (IM-09). The Incident Communications Template Set holds them:
Template | Audience | When | Approved by |
|---|---|---|---|
CT-01 Incident alert to the response team | Incident manager, responders, executive incident lead | At declaration | Incident manager |
CT-02 Executive and board briefing | Executive incident lead, crisis team, board chair | Severity 1 and 2, at each update | Incident manager |
CT-03 Staff holding message | All staff, or the affected site or team | When staff notice the effects | Executive incident lead |
CT-04 Customer notice | Customers whose service or data is affected | When a customer's service is affected or a contract requires it | Executive incident lead |
CT-05 Supplier notice and request for help | Suppliers involved in the incident or the recovery | When a supplier must act or be warned | Incident manager |
CT-06 NIS2 early warning and notification content | [[CSIRT or competent authority]] | RD-01 to RD-04 | Executive incident lead |
CT-07 GDPR notification to the supervisory authority | [[lead supervisory authority]] | RD-06 | Executive incident lead, with the Data Protection Officer |
CT-08 Communication to individuals affected | Data subjects | RD-07 | Executive incident lead, with the Data Protection Officer |
CT-09 Media holding statement | Press and public | When the incident is, or is about to be, public | Executive incident lead |
CT-10 All-clear and thank-you | Everyone told earlier | At closure | Executive incident lead |
Assume that anything written on a system the attacker may control can be read by the attacker. During a Severity 1 or 2 incident, the response team talks on the out-of-band service.
Suppliers in an incident
The Third-Party Security Policy (Third-Party Security Risk Management pack) requires (P06 TP-10): “Critical suppliers must be part of incident response and continuity plans, with named contacts and notification duties.” This section is where that happens. The contracts of these suppliers carry the clauses “Security incident notification” (P06 CL-07: notice of an incident at the supplier within [[24]] hours) and “Cooperation in our incident response” (P06 CL-11: a named contact, evidence and help in our response), from the Supplier Contract Security Clause Library.
EXAMPLE — the example organisation's critical suppliers and what each does in an incident:
Supplier | Its part in our response | 24/7 contact | Clauses |
|---|---|---|---|
EXAMPLE SUP-001 Managed IT service provider | Isolates networks and systems, rebuilds devices, restores from backup | [[name, number]] | P06 CL-07, CL-11 |
EXAMPLE SUP-006 Security monitoring provider | Detects and alerts around the clock; supplies logs and analysis | [[name, number]] | P06 CL-07, CL-11 |
EXAMPLE SUP-011 Backup service provider | Confirms backup integrity and supports restoration | [[name, number]] | P06 CL-07, CL-11 |
EXAMPLE SUP-002 Cloud hosting provider | Protects and restores the hosted ordering platform | [[name, number]] | P06 CL-07, CL-11 |
EXAMPLE SUP-005 Email and office software provider | Suspends accounts, removes mail rules and supplies mailbox audit logs | [[name, number]] | P06 CL-07, CL-11 |
[[Supplier]] | [[What it does for us in an incident]] | [[name, number]] | [[clauses]] |
- Tell the supplier early when it must act or be warned, using the supplier notice (CT-05); do not wait to be sure it is involved.
- Direct, do not delegate: a supplier's responders work under the incident manager's direction. A supplier may advise on severity or reporting, but the decisions and the reports stay with us.
- When the incident is at the supplier (category IC-10), the supplier's notice starts our triage like any other report. Ask for what the clause promises: what happened, what of ours is affected, the measures taken and a contact.
Resources
These must exist before an incident. Check each one in the quarterly contact check and before the yearly exercise.
Resource | What it is for | Ours | Kept ready by |
|---|---|---|---|
Out-of-band communication | A way to talk, meet and share files that does not depend on systems the attacker may control, such as company email and chat. | [[e.g. a separate messaging workspace on personal devices; a conference bridge number; a shared folder outside the corporate tenant]] | Head of Information Security |
War room | A place for the crisis team to meet and work, in person and online. | [[Room and site; the backup room at another site; the online meeting link on the out-of-band service]] | Incident manager |
Incident response retainer | Outside responders who start within agreed hours, without a new contract, when the incident is beyond our own team. | [[Firm; contract reference; hours included; response time; 24/7 activation number; who may activate it]] | Head of Information Security |
Cyber insurer's panel | The responders, lawyers and negotiators the insurer will pay for, and the conditions for using them. | [[Insurer and policy number; incident line; notice period; panel firms; whether our own retainer firm is accepted]] | Executive incident lead |
Forensic tooling | Tools to collect and preserve evidence and to see what an attacker did. | [[Endpoint detection and response console; central log platform keeping at least 90 days; memory and disk capture tools; who is trained to use them]] | Technical responders |
Offline copies | The plan, the playbooks, the contact directory, network diagrams and restore instructions, readable when every system is down. | [[Printed copies held by the incident manager and deputy; an encrypted copy on removable media; where each is kept]] | Incident manager |
Clean devices | Devices known to be uncompromised, for responders and the crisis team to use when the network cannot be trusted. | [[e.g. two laptops and two phones, kept off the corporate network and updated monthly]] | Technical responders |
Guidance — delete before approval
Check the insurance policy before you need it: many policies require the insurer to be told within a set time, and some pay only for the panel's firms. If your own retainer firm is not on the panel, agree now whether the insurer will accept it.
The retainer, the insurer and the war room are useless if nobody can reach them when email is down. Put their numbers in the offline copies.
Playbook index
The category chooses the playbook; severity is set separately. Where no playbook exists, the phases of this plan are the response.
ID | Category | For example | Response |
|---|---|---|---|
IC-01 | Ransomware or destructive malware | Files encrypted; ransom note; systems wiped | Ransomware Response Playbook |
IC-02 | Other malware | Malware found and blocked or removed, no encryption | This plan's phases |
IC-03 | Business email compromise and payment fraud | A mailbox taken over; a request to change bank details; a fake invoice | Business Email Compromise Response Playbook |
IC-04 | Account compromise | A user or administrator account used by someone else | This plan's phases |
IC-05 | Personal data breach | Personal data sent to the wrong person, lost, stolen, altered or made unavailable | Personal Data Breach Response Playbook |
IC-06 | Exploited vulnerability | A weakness in an internet-facing system used to get in | This plan's phases |
IC-07 | Denial of service | A service made unavailable by traffic or requests | This plan's phases |
IC-08 | Insider misuse | An employee or contractor misusing access | This plan's phases |
IC-09 | Lost or stolen device | A laptop, phone or removable drive | Personal Data Breach Response Playbook |
IC-10 | Supplier incident | An incident at a supplier that affects our data or services | This plan's phases |
Guidance — delete before approval
Add a playbook when the same kind of incident keeps happening, or when one incident type needs decisions this plan does not cover. Write it in the same seven phases, so responders never have to learn a second structure.
Contact directory
Keep this directory current, check it every quarter, and hold it offline as well as online. Every entry has a number that is answered outside working hours.
Response roles
Role | Name | 24/7 number | Deputy | Deputy's number |
|---|---|---|---|---|
Incident manager | [[Name]] | [[number]] | [[Name]] | [[number]] |
Executive incident lead | [[Name]] | [[number]] | [[Name]] | [[number]] |
Head of Information Security | [[Name]] | [[number]] | [[Name]] | [[number]] |
IT service desk | [[Name]] | [[number]] | [[Name]] | [[number]] |
Technical responders | [[Name]] | [[number]] | [[Name]] | [[number]] |
Data Protection Officer | [[Name]] | [[number]] | [[Name]] | [[number]] |
Legal | [[Name]] | [[number]] | [[Name]] | [[number]] |
Communications lead | [[Name]] | [[number]] | [[Name]] | [[number]] |
Board | [[Name]] | [[number]] | [[Name]] | [[number]] |
Suppliers and outside help
Who | For | 24/7 number | Account or contract reference |
|---|---|---|---|
Managed IT service provider | Isolates networks and systems, rebuilds devices, restores from backup | [[number]] | [[reference]] |
Security monitoring provider | Detects and alerts around the clock; supplies logs and analysis | [[number]] | [[reference]] |
Backup service provider | Confirms backup integrity and supports restoration | [[number]] | [[reference]] |
Cloud hosting provider | Protects and restores the hosted ordering platform | [[number]] | [[reference]] |
Email and office software provider | Suspends accounts, removes mail rules and supplies mailbox audit logs | [[number]] | [[reference]] |
[[Incident response retainer firm]] | Outside responders (see Resources) | [[number]] | [[reference]] |
[[Outside counsel]] | Legal advice, including on extortion and sanctions | [[number]] | [[reference]] |
Authorities, insurer and others we must tell
Who | Reports | Route | 24/7 number | Our reference |
|---|---|---|---|---|
[[CSIRT or competent authority]] | RD-01 early warning (NIS2) RD-02 incident notification (NIS2) RD-03 intermediate report (NIS2) RD-04 final report (NIS2) | [[portal or address]] | [[24/7 number]] | [[our registration or policy number]] |
[[lead supervisory authority]] | RD-06 notification to the supervisory authority (GDPR) | [[portal or address]] | [[24/7 number]] | [[our registration or policy number]] |
[[financial competent authority]] | RD-10 initial notification (DORA) RD-11 intermediate report (DORA) RD-12 final report (DORA) | [[portal or address]] | [[24/7 number]] | [[our registration or policy number]] |
[[customers with a notification clause]] | RD-14 notice to customers under contract (Contract) | [[portal or address]] | [[24/7 number]] | [[our registration or policy number]] |
[[insurer or broker incident line]] | RD-15 notice to the cyber insurer (Insurance) | [[portal or address]] | [[24/7 number]] | [[our registration or policy number]] |
[[national cybercrime reporting service]] | RD-16 crime report (Law enforcement) | [[portal or address]] | [[24/7 number]] | [[our registration or policy number]] |
The Secretary of Health and Human Services, through the Office for Civil Rights breach portal | RD-19 notice to the secretary of health and human services (HIPAA) | [[portal or address]] | [[24/7 number]] | [[our registration or policy number]] |
[[the covered entity we serve]] | RD-20 notice by a business associate to the covered entity (HIPAA) | [[portal or address]] | [[24/7 number]] | [[our registration or policy number]] |
The Securities and Exchange Commission, filed on EDGAR | RD-21 current report on form 8-k, item 1.05 (SEC) | [[portal or address]] | [[24/7 number]] | [[our registration or policy number]] |
The Superintendent of Financial Services, electronically | RD-22 notice of a cybersecurity incident (NYDFS) RD-23 notice of an extortion payment (NYDFS) RD-24 written description of why the payment was necessary (NYDFS) | [[portal or address]] | [[24/7 number]] | [[our registration or policy number]] |
The Federal Trade Commission, electronically on its form | RD-28 notice to the federal trade commission (FTC Safeguards) | [[portal or address]] | [[24/7 number]] | [[our registration or policy number]] |
Yearly calendar
The plan stays ready only if these happen on time. Put each one in the owner's calendar.
When | Activity | Owner | Rule |
|---|---|---|---|
At least once a year, in [[month]] | Exercise the plan: a tabletop exercise on a realistic scenario, with the crisis team and deputies; alternate the scenario year to year. | Head of Information Security | IM-12 |
Every quarter | Check every number in the contact directory, including deputies, suppliers, the retainer, the insurer and the authorities; call the 24/7 numbers. | Incident manager | IM-12 |
Every quarter | Report incidents by severity, reports made on time and overdue review actions to executive management. | Head of Information Security | IM-12 |
Every quarter | Review the quarter's Severity 3 and 4 incidents together, looking for repeated causes and for incidents that should have been rated higher. | Head of Information Security | IM-11 |
After every Severity 1 incident | Review this plan against what happened, and record the review in the revision history even if nothing changes. | Head of Information Security | IM-12 |
Every year, and at renewal | Check the retainer and the cyber insurance: cover, response times, notice periods and panel firms. | Executive incident lead | IM-12 |
When something changes | Update the plan and the directory when a role holder, a critical supplier, a regulated status or a core service changes. | Head of Information Security | IM-12 |
IM-12: “The plan must be exercised at least once a year and reviewed after every Severity 1 incident; incidents by severity, reports made on time and overdue review actions must be reported to executive management every quarter.”
Measures of success
The quarterly report to executive management shows four measures (IM-12). IMM-01 is also the board's measure of incidents.
Measure | What it counts | Target | EXAMPLE, Q3 2026 |
|---|---|---|---|
IMM-01 Significant incidents and time to contain | Incidents reported to an authority as significant (NIS2) or major (DORA) in the quarter, and for each the hours from detection to containment. | Each contained within [[24]] hours | 1 significant incident; contained in 6 hours |
IMM-02 Reports made on time | Reports to authorities and individuals made by their deadline, out of all that fell due in the quarter. | All | 4 of 4 |
IMM-03 Review actions overdue | Open post-incident review actions past their due date. | None more than 30 days overdue | 1 (PIA-04, 5 days) |
IMM-04 Months since the plan was last exercised | Whole months from the last exercise of the plan (not a live incident) to the end of the quarter. | 12 or fewer | 6 months (last exercise 18 Mar 2026) |
How the plan ran on 12 August 2026
EXAMPLE. The example organisation (a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders) is an important entity under NIS2 in its Member State, and not a financial entity, so DORA's reporting duties do not apply. This is its ransomware incident, INC-2026-014, run against this plan. The security monitoring provider alerted on encryption activity on one office PC at Warehouse 2. It had spread to 14 office PCs on that site's office network before the site was cut off. Ordering and dispatch were not affected.
What happened, phase by phase
Time | From declaration | What happened | Who | Phase |
|---|---|---|---|---|
12 Aug 2026, 07:50 | 35 minutes before | Monitoring alert: encryption activity on one office PC at Warehouse 2 | Security monitoring provider (SUP-006) | Detect and report |
12 Aug 2026, 08:05 | 20 minutes before | Triage starts (out of hours: within 60 minutes) | IT service desk | Triage and declare |
12 Aug 2026, 08:25 | Declaration | Declared Severity 1, category IC-01; reporting clocks start | Incident manager | Triage and declare |
12 Aug 2026, 08:40 | +15 minutes | Executive incident lead told | Incident manager | Triage and declare |
12 Aug 2026, 08:55 | +30 minutes | Decision: cut Warehouse 2's office network off from all other networks (the incident manager's decision; the executive incident lead agreed, as it stopped office work at the site) | Incident manager | Contain |
12 Aug 2026, 09:10 | +45 minutes | Warehouse 2 office network isolated | Managed IT provider (SUP-001) | Contain |
12 Aug 2026, 09:20 | +55 minutes | Crisis team convened | Executive incident lead | Contain |
12 Aug 2026, 11:30 | +3 hours 5 minutes | Reporting screen complete: NIS2 significant; GDPR breach to assess; DORA not applicable | Incident manager, Data Protection Officer | Triage and declare |
12 Aug 2026, 11:45 | +3 hours 20 minutes | Cyber insurer told | Executive incident lead | Contain |
12 Aug 2026, 12:20 | +3 hours 55 minutes | Board chair told | Executive incident lead | Contain |
12 Aug 2026, 13:50 | +5 hours 25 minutes | Contained: 14 PCs isolated, no activity on any other site | Incident manager | Contain |
12 Aug 2026, 15:40 | +7 hours 15 minutes | NIS2 early warning submitted | Incident manager | Contain |
12 Aug 2026, 17:10 | +8 hours 45 minutes | Crime reported | Legal | Contain |
12 Aug 2026, 19:30 | +11 hours 5 minutes | Eradicated: the phishing email removed from every mailbox, its sender and attachment blocked, and the affected user's and Warehouse 2 administrator passwords reset | Managed IT provider (SUP-001), email provider (SUP-005) | Eradicate |
13 Aug 2026, 14:00 | +1 day 5 hours | Office work resumes on rebuilt PCs; backups checked before restoring | Managed IT provider (SUP-001), backup provider (SUP-011) | Recover |
14 Aug 2026, 10:00 | +2 days 1 hour | GDPR assessment: unlikely to result in a risk; recorded, not notified | Data Protection Officer | Recover |
14 Aug 2026, 14:00 | +2 days 5 hours | NIS2 incident notification submitted | Incident manager | Recover |
21 Aug 2026, 09:00 | +9 days | Closed after 7 days' monitoring without recurrence | Incident manager | Recover |
27 Aug 2026, 10:00 | +15 days 1 hour | Post-incident review held | Head of Information Security | Review |
11 Sep 2026, 12:00 | +30 days 3 hours | NIS2 final report submitted | Incident manager | Review |
Escalation against the plan's deadlines
The incident was declared Severity 1 at 12 Aug 2026, 08:25, category IC-01 (ransomware or destructive malware), so the Ransomware Response Playbook applied and every Severity 1 clock started.
Step | Deadline | Took | Result |
|---|---|---|---|
Triage starts (IM-02) | 60 minutes (out of hours) from report | 15 minutes | Met, 45 minutes to spare |
Declared (IM-02) | [[30]] minutes from start of triage | 20 minutes | Met, 10 minutes to spare |
Executive incident lead told (IM-05) | 30 minutes from declaration | 15 minutes | Met, 15 minutes to spare |
Crisis team convened (IM-05) | 1 hour from declaration | 55 minutes | Met, 5 minutes to spare |
Reporting screen complete (IM-06) | 4 hours from declaration | 3 hours 5 minutes | Met, 55 minutes to spare |
Board chair told (IM-05) | 4 hours from declaration | 3 hours 55 minutes | Met, 5 minutes to spare |
Contained (IMM-01) | [[24]] hours (target) from detection | 6 hours | Met, 18 hours to spare |
The incident manager decided to cut Warehouse 2's office network off 30 minutes after declaration, within the decision rights: isolating a site is the incident manager's decision. The executive incident lead was told and agreed, because it stopped office work at the site.
Reports against their deadlines
The reporting screen found: NIS2 — significant: capable of severe operational disruption; early warning, notification and final report made; GDPR — personal data breach (availability of shipping records on the PCs); restored from backup, no sign of data taken; unlikely to result in a risk, so recorded and not notified; DORA — not applicable: not a financial entity.
Report | Deadline | Made | Result |
|---|---|---|---|
RD-01 NIS2 early warning | 13 Aug 2026, 08:25 | 12 Aug 2026, 15:40 | On time, 16 hours 45 minutes to spare |
RD-02 NIS2 incident notification | 15 Aug 2026, 08:25 | 14 Aug 2026, 14:00 | On time, 18 hours 25 minutes to spare |
RD-04 NIS2 final report | 14 Sep 2026, 23:59 | 11 Sep 2026, 12:00 | On time, 3 days 11 hours to spare |
RD-06 GDPR notification to the supervisory authority | 15 Aug 2026, 08:25 | Not needed: decided 14 Aug 2026, 10:00 | Decided 22 hours 25 minutes before the clock ran out; recorded in the breach record (RD-08) |
RD-15 notice to the cyber insurer | [[as the policy requires, often within 48 hours]] | 12 Aug 2026, 11:45 | Insurer's incident line; its panel firm was not needed |
RD-16 crime report | [[as soon as practical for suspected crime]] | 12 Aug 2026, 17:10 | Reported to [[the national cybercrime reporting service]] |
Recovery, closure and review
- Recovered: office work resumed on rebuilt PCs at 13 Aug 2026, 14:00, 1 day 5 hours after declaration, with backups checked before they were restored (IM-10). Ordering and dispatch never stopped.
- Closed: 21 Aug 2026, 09:00, after 7 days 19 hours of monitoring without recurrence (the plan requires 7 days).
- Reviewed: 27 Aug 2026, 4 working days after closure (IM-11 requires 10). Cause: a phishing attachment opened by a warehouse office user whose account had local administrator rights. That site's office network was not yet separated, so it spread to 14 PCs.
The review's actions, as at the end of the quarter:
Action | Owner | Due | Status |
|---|---|---|---|
PIA-01 Remove local administrator rights from all office PCs | Head of IT | 31 Oct 2026 | In progress |
PIA-02 Finish separating the warehouse networks from the office network at all three sites (P05 TA-04; two were still joined on 12 Aug) | Head of IT | 11 Sep 2026 | Done, 11 Sep 2026 |
PIA-03 Reassess the risk of ransomware spreading to warehouse systems (P05 R-04) | Head of Logistics | 26 Aug 2026 | Done, 20 Aug 2026 |
PIA-04 Add site isolation steps for each warehouse to the Ransomware Response Playbook | Information Security Manager | 25 Sep 2026 | Open |
PIA-05 Give the monitoring provider's out-of-hours analysts a direct line to the incident manager | Head of Information Security | 15 Sep 2026 | Done, 10 Sep 2026 |
What changed in the plan: out-of-hours alerts now reach the incident manager directly (PIA-05), and the Ransomware Response Playbook is being given site isolation steps for each warehouse (PIA-04). IMM-03 counts the second as overdue.
Guidance — delete before approval
Keep this worked example until you have run the plan in an exercise of your own; then replace it with your own exercise or incident, with the same tables. The comparison with each deadline is what the board and the auditor look for.
Related documents
Document | Relationship |
|---|---|
Security Incident Management Policy | The rules IM-01 to IM-13 this plan carries out |
Incident Classification, Severity & Escalation Matrix | Severity criteria, categories, escalation times and reporting clocks |
Incident Triage & First-Hour Assessment Procedure | Triage and the first hour after declaration |
Ransomware Response Playbook; Business Email Compromise Response Playbook; Personal Data Breach Response Playbook | The response to the categories that need their own steps |
Incident Case & Action Log | The case log, decision log, evidence log and review actions |
Incident Communications Template Set | The approved messages, CT-01 to CT-10 |
Post-Incident Review Template | The post-incident review |
Incident Response Readiness Checklist | Whether the plan, the people and the tools are ready |
Third-Party Security Policy; Supplier Contract Security Clause Library | Suppliers' part in the response (P06 TP-10, CL-07, CL-11); Third-Party Security Risk Management pack |
Information Security Risk Register | Where the risks an incident touches are reassessed (IM-11); Information Security Risk Management pack |
[[Business continuity plan]] | [[Keeps services running and restores them; hands over to and from this plan]] |
Approval and review
Approval record
Version | Approved by | Date | Evidence of approval | Next review by |
|---|---|---|---|---|
[[1.0]] | [[Executive management]] | [[YYYY-MM-DD]] | [[e.g. minutes of meeting, reference and item]] | [[YYYY-MM-DD]] |
Review. This plan is reviewed at least every 12 months, after every Severity 1 incident and after every exercise (IM-12), and when a role holder, a critical supplier, a regulated status or a core service changes. A review that changes nothing is still recorded in the revision history.
Distribution. Everyone with a role in the plan, and their deputies, has the current version online and offline. [[List who holds printed copies.]]
Adapting this template
Guidance — delete before approval
Small organisation: keep the seven phases and the reporting screen; shrink everything else. One person may be incident manager and Head of Information Security, and the crisis team may be three people, but the executive incident lead is someone else, usually the managing director. The resources can be modest: a messaging group on personal phones, a meeting room, the insurer's panel instead of a retainer. The yearly exercise can be a two-hour discussion around one scenario.
Regulated entity: an essential or important entity under NIS2 needs incident handling and crisis management among its measures (Article 21(2)(b) and (c)) and reports significant incidents on the RD-01 to RD-05 clocks (Article 23(4)). A financial entity under DORA reports major ICT-related incidents under DORA instead of NIS2 (NIS2 Article 4(1), DORA Article 1(2)): replace RD-01 to RD-05 with RD-10 initial notification (within 4 hours of classifying the incident as major, and no later than 24 hours after awareness; where it is classified as major only after those 24 hours, within 4 hours of that classification); RD-11 intermediate report (within 72 hours of the initial notification, and again when regular activities are recovered); RD-12 final report (no later than one month after the latest intermediate report); RD-13 notice to clients (without undue delay). DORA also expects the plan to assign roles for each incident type, set communication plans, and report major incidents to senior management and the management body (Article 17(3)); the roles, the crisis team and the communications sections do this. Use the reporting template of Implementing Regulation (EU) 2025/302 for all three reports.
IT run by a service provider: your managed IT provider and security monitoring provider are likely to be the service desk and most of the technical responders. Name their leads in the roles table and the directory, make sure their contracts carry the incident notification and cooperation clauses (P06 CL-07, CL-11), and invite them to the yearly exercise. Declaration, severity, the reporting screen and every decision in the decision rights stay with your own people: an outsourced provider can advise and act, but it cannot decide or report for you.
US organisation: answer the US questions of the reporting screen as well, record the time of discovery as well as the time of declaration (IM-13), and name who determines that an incident is material, if you are a listed company. The US duties are for organisations that are subject to them: HIPAA covered entities and business associates, companies that file reports with the SEC, entities licensed by the New York Department of Financial Services, and organisations that hold personal information of State residents. State laws are shown as placeholders with California and New York as examples; every State has its own. This is not legal advice; ask counsel which duties apply.
Delete this section before approval.
Framework references
These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2) and Implementing Regulation (EU) 2024/2690; Regulation (EU) 2016/679 (GDPR); Regulation (EU) 2022/2554 (DORA), Delegated Regulations (EU) 2024/1772 and 2025/301, Implementing Regulation (EU) 2025/302.
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 5.24 — Information security incident management planning and preparation | Whole plan: phases, roles, deputies, resources, contact directory and calendar |
ISO/IEC 27001:2022 | Annex A 5.25 — Assessment and decision on information security events | Triage and declare; severity at a glance |
ISO/IEC 27001:2022 | Annex A 5.26 — Response to information security incidents | Contain, eradicate and recover; decision rights |
ISO/IEC 27001:2022 | Annex A 5.27 — Learning from information security incidents | Review; the worked example's actions |
ISO/IEC 27001:2022 | Annex A 5.29 — Information security during disruption | The crisis team; recovery; the hand-over to the business continuity plan |
ISO/IEC 27001:2022 | Annex A 5.5 — Contact with authorities | Reporting duties; the authorities in the contact directory |
NIST CSF 2.0 | ID.IM-04 — “Incident response plans and other cybersecurity plans that affect operations are established, communicated, maintained, and improved” | Whole plan: established, communicated, reviewed after incidents and exercises |
NIST CSF 2.0 | RS.MA-01 — “The incident response plan is executed in coordination with relevant third parties once an incident is declared” | The phases, run with suppliers and outside responders |
NIST CSF 2.0 | RS.MA-04 — “Incidents are escalated or elevated as needed” | Severity at a glance: who is told, and how fast |
NIST CSF 2.0 | GV.SC-08 — “Relevant suppliers and other third parties are included in incident planning, response, and recovery activities” | Suppliers in an incident |
NIST CSF 2.0 | RC.RP-01 — “The recovery portion of the incident response plan is executed once initiated from the incident response process” | Recover phase |
NIST CSF 2.0 | RC.RP-03 — “The integrity of backups and other restoration assets is verified before using them for restoration” | Recovery criteria: backups checked before use |
NIST CSF 2.0 | RC.RP-06 — “The end of incident recovery is declared based on criteria, and incident-related documentation is completed” | Closure after the monitoring period |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(b) — the cybersecurity risk-management measures include “incident handling” | Whole plan |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(c) — “business continuity, such as backup management and disaster recovery, and crisis management” | The crisis team; recovery; regulated-entity tailoring |
NIS2 — Directive (EU) 2022/2555 | Article 23(4) — an early warning within 24 hours of becoming aware of a significant incident; an incident notification within 72 hours; an intermediate report on request; a final report not later than one month after the incident notification (or a progress report, then a final report within one month of handling, if still ongoing) | Reporting duties RD-01 to RD-04; the worked example's reports |
GDPR — Regulation (EU) 2016/679 | Article 33(1) — notify the supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it”, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons; a later notification gives reasons for the delay | Reporting duty RD-06; the worked example's GDPR decision |
HIPAA — 45 CFR Part 164, Subpart D (breach notification) | § 164.404 — a covered entity notifies each affected individual without unreasonable delay and no later than 60 calendar days after discovery; a breach is treated as discovered on the first day it is known, or by reasonable diligence would have been known, to any workforce member or agent other than the person who committed it; the notice says what happened, what information was involved, what individuals should do, what the entity is doing, and how to ask questions, in plain language | RD-17: the 60-day clock runs from discovery; the US worked example shows discovery before declaration |
HIPAA — 45 CFR Part 164, Subpart D (breach notification) | § 164.408 — a covered entity notifies the Secretary of Health and Human Services: for 500 or more individuals contemporaneously with the notice to individuals; for fewer than 500, it keeps a log and notifies not later than 60 days after the end of each calendar year, for breaches discovered in the year before | RD-19: the Secretary is told with the individuals for 500 or more, or in an annual log for fewer |
HIPAA — 45 CFR Part 164, Subpart D (breach notification) | § 164.412 — if a law enforcement official states that notice would impede a criminal investigation or damage national security, the notice is delayed for the time a written statement specifies, or, for an oral statement that is documented, for no longer than 30 days unless a written statement follows | DL-01: the law-enforcement delay |
SEC — Regulation S-K and Form 8-K | Form 8-K Item 1.05 — a registrant that experiences a cybersecurity incident it determines to be material describes the material aspects of its nature, scope and timing and its material impact or reasonably likely material impact, within four business days after the determination; the determination is made without unreasonable delay after discovery; information not yet determined is filed by amendment within four business days after it is determined or becomes available | RD-21 and the materiality decision right: four business days from the determination |
SEC — Regulation S-K and Form 8-K | Form 8-K Item 1.05(c) — the United States Attorney General may determine, in writing to the Commission, that disclosure poses a substantial risk to national security or public safety; the registrant may then delay for the period specified, up to 30 days, a further 30 days, and in extraordinary circumstances a final 60 days; further delay only by Commission exemptive order | DL-02: the Attorney General's delay |
NYDFS — 23 NYCRR Part 500 | § 500.17(a) — notify the Superintendent electronically as promptly as possible and no later than 72 hours after determining that a cybersecurity incident has occurred at the covered entity, its affiliates or a third-party service provider, and provide requested information and updates promptly | RD-22: 72 hours from determining that a cybersecurity incident has occurred |
NYDFS — 23 NYCRR Part 500 | § 500.17(c) — notify the Superintendent within 24 hours of an extortion payment made in connection with a cybersecurity event, and within 30 days give a written description of the reasons the payment was necessary, the alternatives considered, the diligence performed to find alternatives, and the diligence performed to ensure compliance with applicable rules, including those of the Office of Foreign Assets Control | RD-23 and RD-24: the extortion-payment notices, and the board-only decision on a payment |
FTC — Safeguards Rule, 16 CFR Part 314 | § 314.4(j) — notify the Federal Trade Commission as soon as possible and no later than 30 days after discovery of a notification event involving the information of at least 500 consumers; the notice gives the institution's contact details, the types of information, the date or date range, the number of consumers, a general description, and whether a law enforcement official has determined that public notice would impede an investigation or harm national security | RD-28: 30 days from discovery, 500 or more consumers |
FTC — Health Breach Notification Rule, 16 CFR Part 318 | § 318.4 — notices are sent without unreasonable delay and in no case later than 60 calendar days after discovery; notice to the Federal Trade Commission is contemporaneous for 500 or more individuals and may be sent annually, no later than 60 calendar days after the end of the calendar year, for fewer than 500; the Rule has a law-enforcement exception | RD-29: the Health Breach Notification Rule's 60 calendar days |
State breach notification law (examples) | New York General Business Law § 899-aa — notice to affected New York residents within 30 days after the breach was discovered; the person or business also notifies the State attorney general, the department of state and the division of state police, and the department of financial services if it is a covered entity under 23 NYCRR 500.1; a HIPAA covered entity that notifies the Secretary of Health and Human Services also notifies the attorney general within five business days of doing so; where more than 5,000 New York residents are notified at one time, the consumer reporting agencies are notified too. This is one State's rule, given as an example; every other State has its own | RD-25 to RD-27: one State's rule, as an example |
State breach notification law (examples) | California Civil Code § 1798.82 — notice to affected California residents within 30 calendar days of discovery or notification of the breach, with extensions for law enforcement needs and to determine the scope of the breach; for a breach affecting more than 500 California residents, a sample copy of the notice to the Attorney General within 15 calendar days of notifying residents. Read on 20 October 2026 in the Legislature's chaptered text of SB 446 (Chapter 319, Statutes of 2025, approved 3 October 2025); this section as amended takes effect on 1 January 2026, as California statutes do unless they say otherwise. Confirm the current text. This is one State's rule, given as an example; every other State has its own | RD-25 and RD-26: a second State's rule, as an example |
NIS2 — Directive (EU) 2022/2555 | Article 4(1) — where a sector-specific Union legal act requires entities to notify significant incidents with requirements at least equivalent in effect, the relevant provisions of NIS2 do not apply to those entities | Regulated-entity tailoring: DORA's reporting replaces NIS2's for financial entities |
DORA — Regulation (EU) 2022/2554 | Article 1(2) — for financial entities identified as essential or important entities under NIS2, DORA “shall be considered a sector-specific Union legal act for the purposes of Article 4” of NIS2 | Regulated-entity tailoring: DORA is the sector-specific act for NIS2 Article 4 |
DORA — Regulation (EU) 2022/2554 | Article 17(3) — early warning indicators; procedures to log, categorise and classify incidents; roles for each incident type; communication plans; reporting major incidents to senior management and the management body; response procedures | Roles, communications and escalation to the management body; regulated-entity tailoring |
DORA — Regulation (EU) 2022/2554 | Article 19(4) — an initial notification, an intermediate report, and a final report when the root cause analysis is complete and actual impact figures are available | Reporting duties RD-10 to RD-12; regulated-entity tailoring |
DORA — Delegated Regulation (EU) 2025/301 | Article 5 — initial notification within 4 hours of classifying the incident as major and no later than 24 hours after becoming aware of it; intermediate report within 72 hours of the initial notification; final report no later than one month after the latest intermediate report | The DORA clocks in the regulated-entity tailoring |
DORA — Implementing Regulation (EU) 2025/302 | Article 1 — the Annex I template is used for the initial notification, the intermediate report and the final report | Regulated-entity tailoring: the DORA reporting template |
Definitions
Term | Meaning in this plan |
|---|---|
Event | Something observed or reported that might affect the security of our information or services. Most events are not incidents. |
Incident | An event, declared by the incident manager, that has compromised, or threatens to compromise, the availability, authenticity, integrity or confidentiality of our data or services, and needs a managed response. |
Significant incident | NIS2's term: an incident that has caused or could cause severe operational disruption or financial loss to us, or considerable damage to others. Reported to the authority on NIS2's clock. |
Major ICT-related incident | DORA's term, for financial entities only: an ICT-related incident with a high adverse impact on systems that support critical or important functions, as tested by Delegated Regulation (EU) 2024/1772. |
Personal data breach | GDPR's term: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data. |
Awareness | The moment the reporting clocks start: the time the incident is declared, as recorded in the case log, unless the record shows we had reasonable certainty earlier, in which case the earlier time. The pack chooses this deliberately. The legal tests turn on what we knew: the EDPB's Guidelines 9/2022 treat a controller as aware once it has a reasonable degree of certainty that a breach occurred, and NIS2 counts from becoming aware of a significant incident, judged on an initial assessment. A late declaration therefore does not postpone a clock the law starts earlier. |
Containment | The incident can no longer spread or cause new harm, even though systems may not yet be restored. |
Closure | Recovery criteria met, the monitoring period passed without recurrence, and the case log complete. |
Crisis team | The group that takes the business decisions in a Severity 1 incident, chaired by the executive incident lead. |
Deputy | The named person who holds a role, with its authority, when the role holder cannot be reached. |
Monitoring period | The 7 calendar days of closer watching after restoration, before a Severity 1 or 2 incident is closed. |
Out-of-band | Communication that does not depend on the systems affected by the incident. |
Playbook | The steps for one category of incident, written in this plan's phases: the Ransomware Response Playbook, Business Email Compromise Response Playbook and Personal Data Breach Response Playbook. |
Reporting screen | The check of every reporting duty made within 4 hours of declaration (IM-06). |
Retainer | A contract with an outside incident response firm that lets it start work within agreed hours, without a new contract. |
War room | The place, physical or online, where the crisis team meets and works. |