Incident Classification, Severity & Escalation Matrix
Classifies events by impact criteria and maps each severity to escalation paths, notification triggers and response-time targets.
Available soon
- Format
- Excel
- Size
- 77 KB
- Length
- 12 sheets
- Version
- 1.1
- Updated
Follow this documentFree account. We can email you when it changes.
What's inside
What changed
- 1.1
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)); the clock calculator applies it.
- 1.0
Published.
Preview
The workbook's sheets as you will receive them, with its example rows and the values its formulas calculate. Highlighted [[text]] is for you to replace; rows marked EXAMPLE are for you to delete. Wide sheets scroll sideways. The cover, document control and changelog sheets are in the file.
Instructions
How to use this workbook
| Step | What to do |
|---|---|
| 1 | Tailor the Severity Matrix before you adopt it. Replace every [[placeholder]] with your own figures (the money thresholds should be the ones in your risk scale), and set who leads and who is told to fit your organisation. Keep four levels: the other documents in the pack refer to Severity 1 to 4. |
| 2 | At declaration, the incident manager sets the category (Categories) and the severity (Severity Matrix), and records both in the case log (IM-03). Use the Classifier sheet if it helps: give a level for every impact area; the severity is the most severe of them. 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. |
| 3 | Escalate as the Severity Matrix says for that severity (IM-05). The category chooses the playbook: IC-01 ransomware or destructive malware uses the Ransomware Response Playbook; IC-03 business email compromise and payment fraud uses the Business Email Compromise Response Playbook; IC-05 personal data breach uses the Personal Data Breach Response Playbook; IC-09 lost or stolen device uses the Personal Data Breach Response Playbook; every other category uses the Incident Response Plan (general response). |
| 4 | Within 4 hours of declaration, screen the incident against every reporting duty (IM-06): 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? 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? 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? The Categories sheet says which duties are most likely for each category; the Reporting Clocks sheet lists every duty, its clock and its legal reference. |
| 5 | On the Clock Calculator sheet, enter the case ID, the time of awareness and the three screen answers. The deadlines calculate. Add the NIS2 incident notification time when it is made (the final report runs one month from it), and for DORA the time the incident was classified as major and the later report times. |
| 6 | Review the matrix after every Severity 1 incident and at least once a year (IM-12). Change the reporting clocks only when the law or your competent authority changes them; the clocks on the Reporting Clocks sheet feed the calculator. |
| 7 | Delete the EXAMPLE rows on the Clock Calculator and Classifier sheets before the matrix is approved. The Severity Matrix, Categories and Reporting Clocks sheets are the content itself: tailor them, do not delete them. |
Legend
Yellow cells are inputs. Everything else is calculated or fixed — do not overwrite formulas.
| EXAMPLE | Rows marked EXAMPLE in the first column show how a completed row looks. Delete them before approval. |
EXAMPLE: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders, an important entity under NIS2 in its Member State; not a financial entity, so DORA's reporting duties do not apply. Its five incidents of Q3 2026 are on the Classifier sheet with the level it judged for each impact area; the mailbox takeover (INC-2026-017) has a second row showing the levels at declaration, before the audit log let the incident manager lower it (IM-04). The ransomware incident (INC-2026-014) was a NIS2 significant incident, and the order spreadsheet sent to the wrong customer (INC-2026-016) was notified under GDPR; the Clock Calculator sheet shows their deadlines, all met.
Tailoring — small organisation: the incident manager may also run IT, the executive incident lead may be the managing director, and the crisis team may be the leadership team. Keep the four levels and the clocks; shorten the lead and escalation columns to the people you have, each with a deputy.
Tailoring — regulated financial entity: DORA replaces NIS2's reporting for financial entities. Use RD-10, RD-11, RD-12, RD-13 instead of RD-01 to RD-05, answer the DORA question with the classification criteria of Delegated Regulation (EU) 2024/1772 Articles 8 and 9, and record the time the incident was classified as major: the initial notification is due within 4 hours of it and no later than 24 hours after awareness. Add the regulation's classification criteria (clients, duration, geographical spread, data losses, critical services, economic impact) to the Legal and regulatory row of the Severity Matrix.
Tailoring — IT run by a managed service provider: the provider usually detects, triages and contains, but the severity, the reporting screen and every report stay yours. Give the provider this matrix, agree that it escalates to your incident manager within the times shown, and name its on-call contact in the lead column for Severity 3 and 4.
The NIS2 clocks run from awareness of a significant incident; the GDPR clock from awareness of a personal data breach. In this pack awareness is the declaration time recorded in the case log, unless the record shows reasonable certainty earlier. National transposition may add detail: check your authority's guidance and put its name in the [[placeholders]].
Severity Matrix
Set severity on the worst impact area (IM-04). Minutes and hours run from declaration. Yellow cells are yours to tailor.
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.
| Level | Severity | Label | Judged against (risk scale impact) | Service | Data | Spread | Financial | Legal and regulatory | Reputation | Who leads | Who is told, and how fast (IM-05) | Updates | Working pattern |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Severity 1 | Critical | Severe | A core customer service stopped, or likely to stop, for more than [[4 hours]] | Personal or customer data at scale taken or exposed, or likely to be | Malware or an attacker spreading, or administrator-level access to core systems | Loss likely above [[€1,000,000]] | Likely a significant incident (NIS2), a major ICT-related incident (DORA), or a breach that individuals must be told of | National press, or loss of a major customer, likely | 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 |
| 2 | Severity 2 | High | Major | A core customer service degraded, or an internal critical service stopped | Personal data of individuals exposed, lost or altered, in limited numbers | One system or account compromised with elevated rights, and contained | Loss likely between [[€250,000]] and [[€1,000,000]] | Possibly notifiable to a supervisory authority or under a contract | Customers or local press aware | Incident manager | Incident manager at once; executive incident lead within 2 hours | Every 4 hours | Extended hours as needed |
| 3 | Severity 3 | Medium | Moderate | One system or group of users affected; no customer effect | Internal non-personal data, or personal data that was protected (for example encrypted) or recovered before it could be misused | One user account or device compromised; attacker stopped before harm | Loss likely between [[€50,000]] and [[€250,000]] | Not notifiable | Not noticed outside the organisation | 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 |
| 4 | Severity 4 | Low | Minor | No service affected | No data affected | Attack stopped by an existing control, with response work still needed | Loss likely below [[€50,000]] | Not notifiable | None | IT service desk | IT service desk logs and handles it; Head of Information Security in the weekly summary | No scheduled updates | Working hours; closed within [[5]] working days |
Categories
The category chooses the playbook; severity is set separately. Add your own categories on the blank rows, with a new ID.
| Category ID | Category | Examples | Playbook | Reporting questions most likely to apply (the full screen is always asked, IM-06) |
|---|---|---|---|---|
| IC-01 | Ransomware or destructive malware | Files encrypted; ransom note; systems wiped | Ransomware Response Playbook | NIS2 significant incident (RD-01 to RD-04) is likely; GDPR breach of availability, and of confidentiality if data was taken (RD-06, RD-08); DORA major incident for a financial entity (RD-10 to RD-12); insurer (RD-15) and crime report (RD-16). |
| IC-02 | Other malware | Malware found and blocked or removed, no encryption | Incident Response Plan (general response) | Usually none beyond the case log. Ask the GDPR question if the malware could read personal data (RD-08), and NIS2 if services were disrupted. |
| 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 | Crime report (RD-16) whenever money was lost or asked for; insurer (RD-15) when money was lost, or when the policy asks to be told of attempts too; GDPR if a mailbox holding personal data was read (RD-06, RD-08); contract notices where a customer was deceived (RD-14). |
| IC-04 | Account compromise | A user or administrator account used by someone else | Incident Response Plan (general response) | GDPR: check the audit log for personal data read or sent (RD-06, RD-08); NIS2 if the account had administrator rights over a core service. |
| IC-05 | Personal data breach | Personal data sent to the wrong person, lost, stolen, altered or made unavailable | Personal Data Breach Response Playbook | GDPR always: breach record (RD-08), authority within 72 hours unless unlikely to result in a risk (RD-06), individuals if a high risk (RD-07); controller notice where we are a processor (RD-09). |
| IC-06 | Exploited vulnerability | A weakness in an internet-facing system used to get in | Incident Response Plan (general response) | NIS2 if a service was disrupted or could have been (RD-01, RD-02); GDPR if the system holds personal data (RD-06, RD-08). |
| IC-07 | Denial of service | A service made unavailable by traffic or requests | Incident Response Plan (general response) | NIS2 significant incident when a core service is stopped for long (RD-01 to RD-05); DORA for a financial entity's critical services (RD-10); customer contract notices (RD-14). |
| IC-08 | Insider misuse | An employee or contractor misusing access | Incident Response Plan (general response) | GDPR if personal data was misused (RD-06 to RD-08); crime report where the misuse is criminal (RD-16); take legal and HR advice before speaking to the person. |
| IC-09 | Lost or stolen device | A laptop, phone or removable drive | Personal Data Breach Response Playbook | GDPR always needs a breach record (RD-08), and a notification to the authority (RD-06) unless the device was encrypted and the key is safe, so the breach is unlikely to result in a risk; individuals only for a high risk (RD-07, with Article 34(3)). Crime report for a theft (RD-16). |
| IC-10 | Supplier incident | An incident at a supplier that affects our data or services | Incident Response Plan (general response) | The supplier's notice to us starts our own screen: NIS2 (RD-01) if our service is disrupted; GDPR where the supplier processes our personal data (RD-06, RD-08); for a financial entity, DORA (RD-10), which the financial entity files itself. Where we are an ICT provider to financial entities, we do not file under DORA: we give our customers what their own reports need, as our contracts require (RD-14). |
Reporting Clocks
Every external reporting duty the screen asks about (IM-06). The Clock Calculator reads the hours and months columns. Recipients are [[placeholders]] until you name your authorities.
| Duty ID | Regime | Report | Deadline | Clock (hours) | Clock (months, due by the end of the day) | DORA: hours after classifying as major | Clock starts at | Starts from report | Recipient | Applies to | Legal reference |
|---|---|---|---|---|---|---|---|---|---|---|---|
| RD-01 | NIS2 | Early warning | Within 24 hours of awareness | 24 | — | — | Awareness | — | [[CSIRT or competent authority]] | Essential and important entities, for a significant incident | 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) |
| RD-02 | NIS2 | Incident notification | Within 72 hours of awareness | 72 | — | — | Awareness | — | [[CSIRT or competent authority]] | Essential and important entities, for a significant incident | 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) |
| RD-03 | NIS2 | Intermediate report | When the authority asks | — | — | — | — | — | [[CSIRT or competent authority]] | Essential and important entities, for a significant incident | 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) |
| 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) | — | 1 | — | Notification | RD-02 | [[CSIRT or competent authority]] | Essential and important entities, for a significant incident | 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) |
| RD-05 | NIS2 | Notice to recipients of our services | Without undue delay, where appropriate | — | — | — | Awareness | — | Customers whose service is likely to be adversely affected | Essential and important entities, for a significant incident | NIS2 — Directive (EU) 2022/2555 — Article 23(1) — notify the CSIRT or competent authority, without undue delay, of any significant incident; where appropriate, notify the recipients of the services of significant incidents likely to adversely affect those services |
| 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 | 72 | — | — | Awareness | — | [[lead supervisory authority]] | Controllers, unless the breach is unlikely to result in a risk to individuals | 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 |
| RD-07 | GDPR | Communication to the individuals affected | Without undue delay | — | — | — | Awareness | — | 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 | GDPR — Regulation (EU) 2016/679 — Article 34(1) — where a breach is likely to result in a high risk to the rights and freedoms of natural persons, communicate it to the data subjects without undue delay |
| RD-08 | GDPR | Breach record | For every personal data breach, notified or not | — | — | — | — | — | Kept by us; shown to the authority on request | Controllers | GDPR — Regulation (EU) 2016/679 — Article 33(5) — the controller documents every personal data breach: the facts, its effects and the remedial action taken |
| RD-09 | GDPR | Notice to the controller | Without undue delay | — | — | — | Awareness | — | The controller whose data we process | Where we act as a processor | GDPR — Regulation (EU) 2016/679 — Article 33(2) — “The processor shall notify the controller without undue delay after becoming aware of a personal data breach.” |
| 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 | 24 | — | 4 | Awareness | — | [[financial competent authority]] | Financial entities, for a major ICT-related incident | 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 |
| RD-11 | DORA | Intermediate report | Within 72 hours of the initial notification, and again when regular activities are recovered | 72 | — | — | Initial notification | RD-10 | [[financial competent authority]] | Financial entities, for a major ICT-related incident | 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 |
| RD-12 | DORA | Final report | No later than one month after the latest intermediate report | — | 1 | — | Latest intermediate report | RD-11 | [[financial competent authority]] | Financial entities, for a major ICT-related incident | 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 |
| RD-13 | DORA | Notice to clients | Without undue delay | — | — | — | Awareness | — | Clients whose financial interests are affected | Financial entities, for a major ICT-related incident | DORA — Regulation (EU) 2022/2554 — Article 19(3) — where a major ICT-related incident has an impact on the financial interests of clients, inform them without undue delay of the incident and of the measures taken |
| RD-14 | Contract | Notice to customers under contract | [[as each contract requires]] | — | — | — | Awareness | — | [[customers with a notification clause]] | Where a contract requires it | No legal clock: set by the contract, the policy or the police |
| RD-15 | Insurance | Notice to the cyber insurer | [[as the policy requires, often within 48 hours]] | — | — | — | Awareness | — | [[insurer or broker incident line]] | Where a cyber policy is held | No legal clock: set by the contract, the policy or the police |
| RD-16 | Law enforcement | Crime report | [[as soon as practical for suspected crime]] | — | — | — | Awareness | — | [[national cybercrime reporting service]] | Suspected criminal acts, including ransomware and fraud | No legal clock: set by the contract, the policy or the police |
Clock Calculator
One row per incident. Enter the yellow cells; every deadline calculates from the Reporting Clocks sheet. A blank deadline means that duty does not apply on the answers given.
| Example | Case ID | Aware at (declared) | NIS2 significant incident? | GDPR: notify the supervisory authority? | DORA major incident? | DORA: classified as major at | NIS2 incident notification made at | DORA initial notification made at | DORA latest intermediate report made at | RD-01 NIS2 early warning due | RD-02 NIS2 incident notification due | RD-04 NIS2 final report due | RD-06 GDPR notification to the supervisory authority due | RD-10 DORA initial notification due | RD-11 DORA intermediate report due | RD-12 DORA final report due | Check |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | INC-2026-014 | 12 Aug 2026 | Yes | No | No | 14 Aug 2026 | 13 Aug 2026 | 15 Aug 2026 | 14 Sep 2026 | OK | |||||||
| EXAMPLE | INC-2026-016 | 9 Sep 2026 | No | Yes | No | 12 Sep 2026 | OK |
Classifier
For each impact area, the level (1 to 4) the incident has reached or is capable of reaching, from the Severity Matrix. Severity is the most severe of them (IM-04). When in doubt, choose the higher level.
| Example | Case ID | Title | Category ID | Category | Service (1–4) | Data (1–4) | Spread (1–4) | Financial (1–4) | Legal and regulatory (1–4) | Reputation (1–4) | Severity level | Severity | Label | Set by | Who leads | Who is told, and how fast | Updates | Playbook | Check |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE | INC-2026-014 | Ransomware on 14 office PCs at Warehouse 2 | IC-01 | Ransomware or destructive malware | 2 | 2 | 1 | 3 | 1 | 3 | 1 | Severity 1 | Critical | Spread; Legal and regulatory | 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 | Ransomware Response Playbook | OK |
| EXAMPLE | INC-2026-015 | Request to change a supplier's bank details from its compromised mailbox | IC-03 | Business email compromise and payment fraud | 4 | 4 | 4 | 3 | 4 | 4 | 3 | Severity 3 | Medium | Financial | 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 | Business Email Compromise Response Playbook | OK |
| EXAMPLE | INC-2026-016 | Customer order spreadsheet sent to the wrong business customer | IC-05 | Personal data breach | 4 | 2 | 4 | 4 | 2 | 3 | 2 | Severity 2 | High | Data; Legal and regulatory | Incident manager | Incident manager at once; executive incident lead within 2 hours | Every 4 hours | Personal Data Breach Response Playbook | OK |
| EXAMPLE | INC-2026-017 | Staff mailbox taken over after a phishing email — at declaration, 14:25 (lowered to Severity 3 at 15:20) | IC-04 | Account compromise | 4 | 2 | 3 | 4 | 2 | 4 | 2 | Severity 2 | High | Data; Legal and regulatory | Incident manager | Incident manager at once; executive incident lead within 2 hours | Every 4 hours | Incident Response Plan (general response) | OK |
| EXAMPLE | INC-2026-017 | Staff mailbox taken over after a phishing email — lowered to Severity 3 at 15:20: The mailbox audit log showed no mail had been forwarded or read by the attacker, so no personal data had gone | IC-04 | Account compromise | 4 | 4 | 3 | 4 | 4 | 4 | 3 | Severity 3 | Medium | Spread | 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 | Incident Response Plan (general response) | OK |
| EXAMPLE | INC-2026-018 | Blocked attempts to exploit a published weakness on the ordering platform | IC-06 | Exploited vulnerability | 4 | 4 | 4 | 4 | 4 | 4 | 4 | Severity 4 | Low | Service; Data; Spread; Financial; Legal and regulatory; Reputation | IT service desk | IT service desk logs and handles it; Head of Information Security in the weekly summary | No scheduled updates | Incident Response Plan (general response) | OK |
Lists
| SeverityLevel | ImpactLevel | YesNo | Regime |
|---|---|---|---|
| 1 | Minor | Yes | NIS2 |
| 2 | Moderate | No | GDPR |
| 3 | Major | DORA | |
| 4 | Severe | Contract |
Insurance
Law enforcement
Definitions
Definitions
| Term | Meaning in this workbook |
|---|---|
| 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. |
| Near miss | An event that could have compromised our data or services but was prevented or did not happen, and needs nothing beyond logging. Logged, never declared. An attack that was stopped but still needs response work, such as warning a supplier, confirming a patch or watching for a repeat, is declared, usually at Severity 4. |
| Significant incident (NIS2) | 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) | 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) | 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. |
| Severity | How fast we respond, from Severity 1 (Critical) to Severity 4 (Low). 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. Severity is ours; it is not any of the legal tests, which are screened separately (IM-06). |
| Impact area | One of the 6 things severity is judged on: service, data, spread, financial, legal and regulatory, reputation. The money thresholds are those of the risk scale, so an incident and a risk are judged on the same consequences. |
| Category | What kind of incident it is (IC-01 to IC-10). It chooses the playbook; it does not set severity. |
| Reporting duty | An external report the law, a contract or a policy may require (RD-01 to RD-16), each with its recipient and clock. |
| Reporting screen | Every incident must be screened against every reporting duty (NIS2, GDPR, DORA where it applies, contracts and insurance) within 4 hours of declaration, and the decision and its reasons recorded whether or not a report is made. |
| Executive incident lead | [[e.g. Chief Operating Officer, with a named deputy]]. Decides on stopping a customer-facing service and on reports to authorities. |
| Incident manager | [[e.g. Information Security Manager, with a named deputy]]. Runs the response from declaration to closure. |
| NIS2 | Directive (EU) 2022/2555 on measures for a high common level of cybersecurity across the Union, as transposed in your Member State. Applies to essential and important entities. |
| GDPR | The General Data Protection Regulation, Regulation (EU) 2016/679. Applies whenever personal data is affected. |
| DORA | The Digital Operational Resilience Act, Regulation (EU) 2022/2554, with its Delegated Regulations (EU) 2024/1772 and 2025/301. Applies to financial entities only; for them its reporting replaces NIS2's. |
| CSIRT | Computer security incident response team: the national team (or the competent authority) that receives NIS2 reports. |
| IM-nn, IC-nn, RD-nn | Rule, category and reporting duty numbers used across the pack; the rules are in the Security Incident Management Policy. |
| EXAMPLE | A worked example: a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders, Q3 2026. Delete the EXAMPLE rows before approval. |
Framework References
Framework references
These references indicate relevance only and do not reproduce the text of any standard.
| Framework | Reference | Supported by |
|---|---|---|
| ISO/IEC 27001:2022 | Annex A 5.25 — Assessment and decision on information security events | Severity Matrix and Classifier: each event assessed and a decision made whether it is an incident, and how severe |
| ISO/IEC 27001:2022 | Annex A 5.26 — Response to information security incidents | Who leads, who is told and how fast, and the playbook each category uses |
| ISO/IEC 27001:2022 | Annex A 5.5 — Contact with authorities | Reporting Clocks: the authorities to be told, when, and by whom |
| NIST CSF 2.0 | RS.MA-03 — “Incidents are categorized and prioritized” | Categories and Severity Matrix: incidents categorised and prioritised |
| NIST CSF 2.0 | RS.MA-04 — “Incidents are escalated or elevated as needed” | Who is told, and how fast: escalation by severity |
| NIST CSF 2.0 | DE.AE-08 — “Incidents are declared when adverse events meet the defined incident criteria” | Declaration: an event becomes an incident when the incident manager declares it against these criteria |
| NIST CSF 2.0 | RS.AN-08 — “An incident's magnitude is estimated and validated” | Classifier: the magnitude judged on every impact area, reviewed at each update |
| NIS2 — Directive (EU) 2022/2555 | Article 23(3) — an incident is significant if it “has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned”, or has affected or is capable of affecting others “by causing considerable material or non-material damage” | The NIS2 screen question and the Legal and regulatory row: when an incident is significant |
| 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) | RD-01 to RD-04 and their deadlines in the Clock Calculator |
| 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 | RD-06 and its 72-hour deadline in the Clock Calculator |
| GDPR — Regulation (EU) 2016/679 | Article 34(1) — where a breach is likely to result in a high risk to the rights and freedoms of natural persons, communicate it to the data subjects without undue delay | RD-07: communication to the individuals affected |
| DORA — Regulation (EU) 2022/2554 | Article 18(1) — classify ICT-related incidents by clients and transactions affected, reputational impact, duration and downtime, geographical spread, data losses, criticality of services affected and economic impact | Tailoring for financial entities: classification criteria added to the Legal and regulatory row |
| DORA — Delegated Regulation (EU) 2024/1772 | Article 8 — an incident is major where it affects critical services and either meets the data-loss threshold in Article 9(5)(b) or meets two or more of the other materiality thresholds | The DORA screen question: when an incident is major |
| DORA — Delegated Regulation (EU) 2024/1772 | Article 9 — materiality thresholds, among them more than 10% of clients of the service, duration over 24 hours or downtime over 2 hours for services supporting critical or important functions, two or more Member States, and costs above €100,000 | The DORA screen question: the materiality thresholds |
| 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 | RD-10 to RD-12 and their deadlines in the Clock Calculator |
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