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
- 75 KB
- Length
- 26 pages
- Version
- 1.2
- 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
What changed
- 1.2
RD-10 now states DORA's rule for an incident classified as major only after 24 hours: the initial notification is due within 4 hours of that classification (Delegated Regulation (EU) 2025/301, Article 5(2)).
- 1.1
Containment is least disruptive first, and the service owner and specialists come in before a service people depend on for safety or essential operations is stopped.
- 1.0
Published.
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 |
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; 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 Ransomware Response Playbook sets out what the board is told, and when.
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 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 |
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 (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” (CL-07: notice of an incident at the supplier within [[24]] hours) and “Cooperation in our incident response” (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]] | CL-07, CL-11 |
EXAMPLE SUP-006 Security monitoring provider | Detects and alerts around the clock; supplies logs and analysis | [[name, number]] | CL-07, CL-11 |
EXAMPLE SUP-011 Backup service provider | Confirms backup integrity and supports restoration | [[name, number]] | CL-07, CL-11 |
EXAMPLE SUP-002 Cloud hosting provider | Protects and restores the hosted ordering platform | [[name, number]] | CL-07, CL-11 |
EXAMPLE SUP-005 Email and office software provider | Suspends accounts, removes mail rules and supplies mailbox audit logs | [[name, number]] | 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]] |
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-12 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 (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 (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.
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 |
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. |
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. |