Reportability Decision Model
Structured decision tree for whether an incident is significant, major or notifiable, with the reasoning recorded.
Available soon
- Format
- Word
- Size
- 78 KB
- Length
- 28 pages
- Version
- 1.0
- Updated
What's inside
- Purpose
- Legal note
- Scope
- The applicability profile
- The decision tree
- Outcomes and the doubt rule
- The NIS2 test
- The DORA test
- The GDPR test
- Other notices
- Recording the decision
- Worked example: the decisions of Q3 2026
- Common mistakes
- How to defend a decision not to report
- Limitations
- Calibration and review
- Related documents
- Adapting this template
- Framework references
- Definitions
What changed
- 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
This model decides, for one declared incident, whether a report to an authority is due under NIS2, DORA or the GDPR, and records the reasoning so that anyone can check it later. It is a decision tree: ten steps, the same every time, that end in one recorded outcome per legal regime.
It exists because the clocks are short and the tests are not obvious. A NIS2 early warning is due within 24 hours of awareness; a GDPR notification within 72; a DORA initial notification within 4 hours of classifying an incident as major. The tests behind them use words such as "significant", "major" and "risk to the rights and freedoms of natural persons" that need turning into questions an incident manager can answer at three in the morning. This model does that, and it says what to do when the answer is not yet known.
The decision it records is also the evidence: the decision line, the facts it rested on and every revisit. Four things hold throughout. Decide every regime for every incident. Test what the incident could do, not only what it has done. Decide on the facts known, and mark the rest Not settled. When in doubt, report (RN-04).
Legal note
This document helps you apply the tests in NIS2, DORA and the GDPR to your own facts. It is not legal advice. National law may add to the Directive, and authorities publish their own guidance, forms and portals, so confirm your approach with counsel before you rely on it.
The Member State details in this document are placeholders: [[national law transposing NIS2: title, number and date]]; [[national CSIRT, or the competent authority where notifications go to it]]. Nothing here states national law as fact.
Scope
The model applies to every incident declared under the Incident Response Plan (P09), whatever its severity, and to a supplier's notice that we treat as our own incident (RN-15). It covers the three legal regimes and checks the three other notices P09 lists.
What P09 owns and what this model adds
P18 builds on P09 and never restates a P09 clock with a different value. P09's duties are cited here by their IDs (RD-01 to RD-16) and stay P09's.
P09 owns | This model adds |
|---|---|
The reporting duties RD-01 to RD-16, with each deadline and recipient | How to decide whether each legal regime's duties are triggered for one incident |
The 4-hour reporting screen (P09 IM-06) and its three legal questions | The steps DS-01 to DS-10 that answer those questions and record the answers |
When the clocks start: awareness, fixed at declaration | How to fix awareness where the record shows certainty earlier (DS-01), and when a later fact restarts a regime's clocks (CN-02) |
Severity 1 to 4, and the decision right to report (the executive incident lead) | The NIS2 indicators, set at Severity 1's values, and who may record a decision not to report (RN-06) |
The message templates and their approvers (P09 CT-04, CT-06 to CT-08) | Nothing: drafting, approval and submission are the Regulatory Notification Operating Procedure's |
Drafting, reviewing, approving and submitting the reports belong to the Regulatory Notification Operating Procedure. What each report must contain is in the NIS2 Early Warning, Notification & Final Report Templates and the Personal Data Breach Notification Templates. The decisions are recorded in the Regulatory Notification Log.
The applicability profile
The organisation must keep an applicability profile, approved by executive management: for NIS2, DORA and the GDPR, whether each can apply, in which role, which authority receives each report and through which channel, and any shorter clock or extra report national law sets. It is reviewed at least once a year and whenever the entity's status, services or authorities change (RN-01).
The profile is made once, before any incident, so the 4-hour screen does not start by asking whether NIS2 applies to us at all. DS-02 reads it. A regime the profile marks as not applying is recorded as Not applicable for every incident, in one line, with the profile as the reason.
The profile records, for each regime: whether it applies, our role, the authority and its channel ([[national CSIRT, or the competent authority where notifications go to it]]; [[lead supervisory authority, or the supervisory authority of the Member State concerned]]; [[financial competent authority designated under DORA Article 46]]), and any shorter clock or extra report national law adds.
The EXAMPLE profile
EXAMPLE. The organisation used throughout the pack is a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. It is an important entity under NIS2 in its Member State; not a financial entity, so DORA's reporting duties do not apply; and a controller for its customers', staff and suppliers' personal data; it processes no personal data for other controllers. Its profile was approved by executive management on 15 Sep 2026:
Regime | Applies? | Role | Authority | National additions |
|---|---|---|---|---|
NIS2 | Yes | Important entity, confirmed by the board on 21 May 2026 (P12) | [[national CSIRT, or the competent authority where notifications go to it]] | [[no shorter clock in national law, confirmed by counsel]] |
DORA | No | Not a financial entity | — | — |
GDPR | Yes | Controller; never a processor for another controller | [[lead supervisory authority, or the supervisory authority of the Member State concerned]] | [[none]] |
The decision tree
Run these steps in order for every declared incident. DS-01 to DS-08 are complete within P09's 4 hours of declaration. DS-09 follows at once; DS-10 runs until the incident closes.
The steps in sequence
- DS-01 Fix the awareness time. Take the declaration time from the P09 case log, or an earlier time where the record shows reasonable certainty earlier. Every clock that runs from awareness starts here (CN-01).
- DS-02 Read the applicability profile. See which regimes can apply to us, in which role, and to which authority. A regime marked Not applicable there is recorded as Not applicable for the incident, with the profile as the reason.
- DS-03 Open the fact base. Record what is known for the fields the tests need (FACT_BASE). Mark each unknown, and who is finding it out.
- DS-04 Apply the NIS2 test. Where NIS2 applies: is any significance indicator met, on what the incident has done or is capable of doing? Any one met makes it significant.
- DS-05 Apply the DORA test. Where DORA applies: does it affect critical services, and has there been a malicious unauthorised access, or are two other materiality thresholds met? Recurring incidents are tested together.
- DS-06 Apply the GDPR test. Is it a personal data breach? Are we the controller or a processor? Is it unlikely to result in a risk, a risk, or a high risk to individuals?
- DS-07 Check the other notices. Contracts, the cyber insurance policy and crime reporting (P09 RD-14 to RD-16).
- DS-08 Record the decisions. One line per regime in the log: outcome, the indicators or thresholds met or not, the facts relied on, who decided and when. All within P09's 4 hours of declaration.
- DS-09 Set the clocks. For each Reportable regime, enter every due time in the log and in the calendar of the drafter and the signatory.
- DS-10 Revisit. At every P09 update, and at once when a fact changes: re-run the test for any Not settled or Not reportable regime, and record the result even when it is unchanged.
Each step's question and where the answer leads
Read each row as a branch of the tree. A blank cell means the step has one path.
Step | Question | Yes, or the answer leads to | No |
|---|---|---|---|
DS-01 Fix the awareness time | When did we first have reasonable certainty that an incident had occurred? | Record that time as awareness. Go to DS-02. | |
DS-02 Read the applicability profile | Can this regime apply to us at all, according to the applicability profile? | Test it at DS-04, DS-05 or DS-06. | Record Not applicable, with the profile as the reason. Next regime. |
DS-03 Open the fact base | Is every fact the tests need known? | Apply the tests. | Mark it unknown, name who is finding it out, and apply the tests anyway. A test that turns on the unknown fact is Not settled. |
DS-04 Apply the NIS2 test | Is any indicator NS-01 to NS-06 met, on what the incident has done or could do? | Reportable: RD-01 to RD-05 open. | Not reportable. Revisit at each update (DS-10). |
DS-05 Apply the DORA test | Are critical services affected (DC-01), and is DC-02 or any two of DC-03 to DC-08 met? | Reportable: RD-10 to RD-13 open. | Not reportable. Check for recurring incidents each month. |
DS-06 Apply the GDPR test | Is it a personal data breach, are we the controller, and what is the risk to people? | Controller: by risk level, RD-08 only, RD-06 and RD-08, or RD-06 to RD-08. Processor: RD-09. | No personal data at stake: Not applicable. Personal data at stake but no breach: Not reportable, recorded as assessed. |
DS-07 Check the other notices | Does a contract, the insurance policy or a suspected crime need a notice? | Record the notice due under RD-14, RD-15 or RD-16. | Record that none is due. |
DS-08 Record the decisions | Is there one recorded decision for every regime in the profile? | Go to DS-09. | Record the missing one now: the screen is not complete without it. |
DS-09 Set the clocks | Is any decision Reportable? | Enter every due time in the log and in the drafter's and signatory's calendars. | No clock to set. Go to DS-10. |
DS-10 Revisit | Has a fact changed, or has a P09 update fallen due? | Re-run the test for every regime not yet Reportable and record the result, even if unchanged. | Wait for the next update or the revisit time, whichever is first. |
Guidance — delete before approval
Word cannot hold a live diagram, so the tree is drawn here as a sequence and a table. If you want a picture, draw it from the table above and keep the table as the version of record: the step IDs are what the log cites.
Outcomes and the doubt rule
The four outcomes
Every declared incident must have a reportability decision for each regime in the profile, recorded in the log with its outcome, the indicators or thresholds met or not, the facts relied on, who decided and when, within P09's 4 hours of declaration (P09 IM-06), whether or not a report is made (RN-02).
Outcome | What it means |
|---|---|
Reportable | The test is met. The regime's clocks run, the reports are drafted and the log shows each due time. |
Not reportable | The regime applies to us, and the test is not met. The reasons are recorded; for the GDPR the breach is still recorded (RD-08). |
Not applicable | The regime cannot apply to us, or not to this incident (for example, no personal data involved). Said once, with the reason. |
Not settled | A fact the test needs is unknown. The decision carries the time it will be revisited, never later than the doubt point (RN-04). |
When a decision cannot be settled
A decision that cannot be settled must be recorded as Not settled with the time it will be revisited. If it is still not settled [[6]] hours before the regime's first deadline, it is treated as Reportable: the report is made by the deadline on the facts known, saying that the assessment is continuing. A report can be updated or withdrawn; a missed deadline cannot be undone (RN-04).
The rule exists because the cost of the two errors is not equal. A report made on incomplete facts can be corrected, updated or, where the test turns out not to be met, withdrawn with an explanation. A missed deadline is a breach of the law that no later report repairs. So the default, once time runs short, is to report. NIS2 also says that the mere act of notification does not subject the notifying entity to increased liability (Article 23(1)).
Where the doubt point falls
For an incident declared at 09:00 on day 1, with each regime's first deadline computed from P09's clocks. The doubt point is [[6]] hours before it.
Regime | First deadline | Due | Doubt point | Time to settle |
|---|---|---|---|---|
NIS2 | RD-01 NIS2 early warning | Day 2, 09:00 | Day 2, 03:00 | 18 h after awareness |
DORA | RD-10 DORA initial notification | Day 2, 09:00 | Day 2, 03:00 | 18 h after awareness |
GDPR | RD-06 GDPR notification to the supervisory authority | Day 4, 09:00 | Day 4, 03:00 | 66 h after awareness |
DORA's first deadline has two limits, and the earlier wins (CN-04). The 24-hour limit from awareness runs regardless of classification. Where the incident is classified as major more than 24 hours after awareness, the initial notification is due 4 hours after classification (CN-10). The same incident, classified at three different times:
Classification | Classified | 4 hours from classification | 24 hours from awareness | Initial notification due |
|---|---|---|---|---|
Classified quickly | Day 1, 10:00 | Day 1, 14:00 | Day 2, 09:00 | Day 1, 14:00 |
Classified late on the first day | Day 2, 07:00 | Day 2, 11:00 | Day 2, 09:00 | Day 2, 09:00 |
Classified after 24 hours | Day 3, 10:00 | Day 3, 14:00 | Day 2, 09:00 | Day 3, 14:00 |
The NIS2 test
What the Directive says
NIS2 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”.
Only essential and important entities report under Article 23. The profile says whether we are one. The Directive gives no numbers, so this model turns its words into six indicators. Any one met makes the incident significant (DS-04).
The indicators
Indicator | Limb | Question | Where the value comes from |
|---|---|---|---|
NS-01 | Operational disruption | Has a service we provide in the NIS2 sector stopped, or is it capable of stopping, for more than [[4 hours]], or degraded for a large share of its users? | P09 Severity 1, Service |
NS-02 | Financial loss | Is our loss likely to exceed [[€1,000,000]], the P05 Severe threshold? | P09 Severity 1, Financial |
NS-03 | Damage to others | Has it caused, or could it cause, considerable material or non-material damage to customers, individuals or other organisations: their operations stopped, money lost, personal data exposed at scale, or harm to health or safety? | Article 23(3)(b) |
NS-04 | Capability | Does an attacker hold administrator-level access to core systems, or is malware spreading, so that NS-01, NS-02 or NS-03 could follow if it is not stopped? | P09 Severity 1, Spread |
NS-05 | Recurrence | Have incidents with the same apparent cause occurred at least twice in six months, and do they together meet NS-01, NS-02 or NS-03? | Modelled on Implementing Regulation (EU) 2024/2690, Article 4, which binds the digital providers it names and tests their financial loss only; this model applies it to every indicator as good practice |
NS-06 | Digital providers | Are we one of the digital providers the Implementing Regulation (EU) 2024/2690 names in Article 1? If so, its Article 3 decides: among other criteria, a direct financial loss above 500,000 euro or 5% of annual turnover, whichever is lower, and the provider-specific Articles 5 to 14. These indicators only add to it. | Implementing Regulation (EU) 2024/2690, Articles 1, 3 and 4 |
Not significant on its own. A scheduled interruption of service, or the planned effect of scheduled maintenance, is not a significant incident. The Implementing Regulation says so for the providers it binds (Article 3(2)); this model applies it to every entity.
Why the indicators carry P09's Severity 1 values
NS-01 uses P09's Severity 1 service threshold, [[4 hours]], and NS-02 its money threshold, [[€1,000,000]], which is the P05 Severe level. P09's Severity 1 already reads, under "Legal and regulatory": "Likely a significant incident (NIS2), a major ICT-related incident (DORA), or a breach that individuals must be told of". Using the same values means that an incident judged Severity 1 on service or money is presumed significant, and the two packs cannot disagree about the same incident.
NS-04 carries the Severity 1 "Spread" level: an attacker with administrator-level access to core systems, or malware spreading. It is the capability limb. It lets the incident manager decide in the first hours, before the disruption the Directive describes has happened.
If you change one of these values in P09, change it here the same day, and record the change in the calibration record. The build of this pack checks that the two agree.
Recurring incidents and digital providers
NS-05 treats incidents with the same apparent cause together. The Implementing Regulation (EU) 2024/2690 does this in Article 4 for the digital providers it binds, and only for financial loss; this model applies it to every indicator as good practice.
NS-06 applies to the digital providers named in Article 1 of the Implementing Regulation (cloud computing, data centre, managed service and managed security service providers, among others). For them Article 3 decides, among other criteria on a direct financial loss above a set amount, and the other indicators only add to it.
Calibrating the indicators with counsel
Each decision must apply the tests of the Reportability Decision Model. Its NIS2 indicators are calibrated by the organisation with counsel and the national authority's guidance; where the law or an authority sets a threshold, the law or the authority wins. Legal advice is sought where a test is unclear, but never waited for past the doubt point (RN-03).
- Before first use, give counsel this section, the P09 severity matrix and the national law's text or guidance on significant incidents.
- Ask three questions: do the national law or the authority set a threshold for our sector? Are the values [[4 hours]] and [[€1,000,000]] right for our size? Does any service we provide need its own threshold?
- Where the law or the authority sets a threshold, enter it in the indicator's question and in the applicability profile. It wins over this model's value.
- Run the calibration cases below and two or three of your own past incidents through the changed indicators. Each should give the result counsel expects.
- Record the date, counsel's name, the values and the cases in the calibration record. Repeat every year and whenever the national guidance changes.
The DORA test
DORA's reporting duties apply only to financial entities. A major ICT-related incident is 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. The criteria and thresholds are set by Delegated Regulation (EU) 2024/1772, read here on 2 October 2026. This section summarises them; a financial entity applies the Regulation's own text.
The criteria
Criterion | Threshold met when | Article | |
|---|---|---|---|
DC-01 | Critical services affected Always required | The incident affects ICT services or network and information systems that support critical or important functions, or financial services that need authorisation, registration or supervision, or it is a successful, malicious and unauthorised access to the entity's network and information systems. | Art 6 |
DC-02 | Malicious unauthorised access Enough with DC-01 | A successful, malicious and unauthorised access to network and information systems that may result in data losses. With critical services affected, this alone makes the incident major. | Art 9 |
DC-03 | Clients, financial counterparts and transactions | More than 10% of the clients using the affected service, or more than 100,000 of them; more than 30% of the financial counterparts for the service; more than 10% of the daily average number, or of the daily average value, of the service's transactions; or any client or counterpart identified as relevant affected. | Art 1 |
DC-04 | Reputational impact | The incident has been in the media, has caused repeated complaints from different clients or counterparts, means the entity will not or is likely not to meet regulatory requirements, or will or is likely to lose clients or counterparts with a material impact on its business. | Art 2 |
DC-05 | Duration and service downtime | The incident lasts longer than 24 hours, or an ICT service supporting critical or important functions is down for longer than 2 hours. | Art 3 |
DC-06 | Geographical spread | An impact in two or more Member States. | Art 4 |
DC-07 | Data losses | An impact on the availability, authenticity, integrity or confidentiality of data that has, or will have, an adverse impact on the entity's business objectives or its ability to meet regulatory requirements. | Art 5 |
DC-08 | Economic impact | Direct and indirect costs and losses that have exceeded, or are likely to exceed, 100,000 euro, before any recoveries. | Art 7 |
Articles are those of Delegated Regulation (EU) 2024/1772.
Numbers that cannot yet be counted are estimated from comparable periods. Duration runs from when the incident occurred, or was detected, until it is resolved; downtime from when the service became unavailable until regular activities are restored.
The rule in words
An incident is major when both of these hold:
- It has affected critical services (DC-01: critical services affected).
- And either a successful, malicious and unauthorised access that may result in data losses has occurred (DC-02), or at least two of the other thresholds DC-03 to DC-08 are met.
Without DC-01 nothing is major, however many thresholds are met. With DC-01, the access threshold is enough on its own; any other threshold needs a second.
Test cases
Each case is run through the model's rule when this document is built. A spreadsheet or tool that applies the rule should give the same answers.
Criteria met | Major? | Why |
|---|---|---|
DC-01, DC-02 | Major | critical services and a malicious unauthorised access |
DC-01, DC-05, DC-06 | Major | critical services and two other thresholds |
DC-01, DC-07 | Not major | critical services and only one other threshold (data losses alone is not enough) |
DC-02, DC-03, DC-05 | Not major | no critical service affected |
Recurring incidents
Incidents that are not major one by one are one major incident where they have occurred at least twice within 6 months, have the same apparent root cause, and together meet the test above. Check for them every month. This does not apply to microenterprises or to the financial entities that DORA Article 16(1) lists. The Regulation sets this out in Article 8(2); the aggregated report uses Implementing Regulation (EU) 2025/302, Article 3.
Significant cyber threats and voluntary notification
A threat that could cause a significant or major incident but has not yet done so. NIS2 asks us to tell affected recipients what they can do about it; DORA lets financial entities notify one voluntarily. DORA defines it in Article 3(13): “significant cyber threat” means “a cyber threat the technical characteristics of which indicate that it could have the potential to result in a major ICT-related incident or a major operational or security payment-related incident”.
Delegated Regulation (EU) 2024/1772, Article 10 makes a threat significant when all three hold: if it materialised it could affect critical or important functions of the entity, other financial entities, third-party providers, clients or counterparts; it has a high probability of materialising; and it could meet the criticality-of-services criterion or the client or geographical thresholds. A financial entity may notify such a threat voluntarily (DORA Article 19(2)); record that decision in the same fields as an incident.
Reclassification
Under DORA, changing a reported incident from major to non-major, or the other way, when new facts show the first classification was wrong. It is reported, never made silently. Where further assessment shows that an incident reported as major at no time met the criteria, the entity notifies the authority that it has reclassified it as non-major, on the template (Implementing Regulation (EU) 2025/302, Article 5). In this model that is a revisited decision: a new line, outcome Not reportable, replacing the Reportable one, with the facts that changed. Never stop reporting silently.
Guidance — delete before approval
Not a financial entity, so DORA's reporting duties do not apply. The EXAMPLE therefore records DORA as Not applicable for every incident. Financial entities should add a worked case of their own from a past incident during calibration.
The GDPR test
The GDPR test has three questions, asked in order. The Data Protection Officer leads the assessment and advises; the decision to notify is the executive incident lead's (RN-06).
Question 1: is it a personal data breach?
GDPR Article 4(12): “personal data breach” means “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed”.
A breach can affect confidentiality (data seen or taken), integrity (data altered) or availability (data lost or unreachable, even for a time). Ransomware that encrypts files holding personal data is an availability breach even when nothing is taken.
If no personal data was at stake, record Not applicable. If personal data was at stake and the assessment shows no breach (the logs prove nothing was read, altered or lost), record Not reportable, with the evidence. The difference matters: the second is a decision about personal data, and the reasons must show it.
Question 2: are we the controller or a processor?
As controller we decide and notify. As a processor we tell the controller without undue delay, without first assessing the risk, and the controller decides (GDPR Article 33(2); RN-15 sets our limit at [[24]] hours). The profile says which role we hold for which data.
Question 3: what is the risk to people?
The Data Protection Officer assesses each factor and records the facts behind it. The factors follow the European Data Protection Board's breach guidelines.
Factor | What to ask | |
|---|---|---|
GF-01 | Type of breach | Confidentiality (seen or taken), integrity (altered) or availability (lost or unreachable)? Each can harm people differently. |
GF-02 | Nature, sensitivity and volume of the data | Special category data, criminal offence data, financial or identity documents, passwords, location, or data about children raise the risk. So does a combination of data about the same person. |
GF-03 | Ease of identification | How easily can the people be identified from the data, directly or with other data? |
GF-04 | Severity of consequences | Could it lead to identity theft, fraud, financial loss, discrimination, distress, damage to reputation or physical harm? Is it permanent? |
GF-05 | Who the people are | Children, vulnerable adults, patients or people at risk of harm if their whereabouts are known? |
GF-06 | Number of people | More people usually means more harm, but one person can suffer a high risk. |
GF-07 | Where the data went and whether it is recovered | To a trusted party who confirmed deletion, to an unknown party, or published? Encrypted with the key safe? Restored from backup with nothing lost? |
The level decides the duties:
Risk level | Duties | What happens |
|---|---|---|
Unlikely to result in a risk | RD-08 | Recorded, with the reasons, and not notified. |
Risk | RD-06, RD-08 | Notified to the supervisory authority and recorded. |
High risk | RD-06, RD-07, RD-08 | Also communicated to the people affected, without undue delay, unless an Article 34(3) condition is met. |
A high-risk breach need not be communicated to the people affected where any of these holds (GDPR Article 34(3)):
- The data was protected so that it is unintelligible to anyone not authorised to see it, for example by encryption with the key safe.
- Measures taken since mean the high risk is no longer likely to materialise.
- Telling each person would involve disproportionate effort; a public communication or similar measure that informs them as effectively is made instead.
The supervisory authority may still require the communication. Record which condition was relied on and the evidence for it.
When we became aware
The GDPR clock runs from when the controller became aware of the breach. The European Data Protection Board says a controller is aware when it “has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised” (Guidelines 9/2022, paragraph 31). P09's awareness is the declaration time unless the record shows reasonable certainty earlier (DS-01). For most incidents the two are the same moment. Where personal data comes into question only later, as when an investigation finds that a file was copied, the GDPR clock starts when the record shows that fact was known (CN-02).
The GDPR's 72 hours is the outer limit of "without undue delay", not a target. A notification after 72 hours is still made, with the reasons for the delay. Information not yet known may follow in phases.
Other notices
DS-07 checks the three notices P09 screens for beside the legal regimes. They are not tested by this model: their trigger and deadline are in the contract, the policy or the law on crime reporting. Record in the log whether each is due.
Duty | Notice | Deadline | To | When it applies |
|---|---|---|---|---|
RD-14 | Notice to customers under contract | [[as each contract requires]] | [[customers with a notification clause]] | Where a contract requires it |
RD-15 | 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 | Crime report | [[as soon as practical for suspected crime]] | [[national cybercrime reporting service]] | Suspected criminal acts, including ransomware and fraud |
Recording the decision
The decision record
Each decision is one line in the Regulatory Notification Log. The fields, and what to write in each:
Field | What to write |
|---|---|
Decision ID | A number that never changes, such as DEC-2026-001. A revisited decision gets a new number. |
Incident | The P09 case number. |
Regime | NIS2, DORA or GDPR. One line per regime in the applicability profile. |
Recorded | Date and time the decision was made, not when it was typed up. |
Outcome | Reportable, Not reportable, Not applicable or Not settled. |
Indicators, thresholds or risk level | The NIS2 indicators met (NS-xx), the DORA criteria met (DC-xx), or the GDPR risk level and the factors that set it (GF-xx). Say "none met" where none is. |
Reasons and facts relied on | The facts from the fact base the outcome rests on, in a sentence or two, and what was still unknown. |
Decided by | The role and name of the person who decided, under RN-06. |
Revisit by | For Not settled, the time it will be revisited, before the doubt point. Otherwise the next P09 update. |
Replaces | For a revisited decision, the ID of the one it replaces. The old line stays in the log. |
Who decides
Every decision to report is the executive incident lead's (P09). A decision not to report an incident that is at Severity 1 or 2 when the decision is recorded is the executive incident lead's too; for Severity 3 and 4 the incident manager may record it. The Data Protection Officer advises on every GDPR decision (RN-06).
Severity at the decision | Decision to report | Decision not to report |
|---|---|---|
Severity 1 | Executive incident lead | Executive incident lead |
Severity 2 | Executive incident lead | Executive incident lead |
Severity 3 | Executive incident lead | Incident manager |
Severity 4 | Executive incident lead | Incident manager |
Use the severity when the decision is recorded. An incident lowered from Severity 2 to 3, with the reason recorded (P09 IM-04), before its decisions are recorded is decided as Severity 3, as INC-2026-017 was; a decision recorded before the lowering is the executive incident lead's. P09 gives the decision right to report to the executive incident lead, on the incident manager's screen; Legal advises where a test is unclear, within the doubt rule.
Revisiting a decision
Every decision other than Reportable must be revisited at each P09 update and at once when a fact changes, and the result recorded even when unchanged. Where an incident becomes reportable later, that regime's clocks start when the record shows the fact that met the test was known (RN-05).
Where an incident becomes reportable later, because a new fact meets a test, that regime's clocks start when the record shows the fact was known (RN-05). The decision is made at once.
A revisit is recorded as a new line with a new decision ID and the ID it replaces. The first line stays. Together they show what was known when, which is what an authority will ask.
Worked example: the decisions of Q3 2026
EXAMPLE. The distributor adopted this pack on 15 Sep 2026 and entered its Q3 2026 incidents from P09's case log. 5 incidents, 17 decisions: one per incident and regime, plus two revisits. Final outcomes: 2 Reportable, 6 Not reportable, 7 Not applicable. Every first decision was recorded within P09's 4 hours.
DORA is Not applicable for every incident because the profile says so; each incident still has its DORA line, so the log shows the regime was considered.
INC-2026-014: Ransomware on 14 office PCs at Warehouse 2
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. Declared 12 Aug 2026, 08:25 at Severity 1; screen due 12 Aug 2026, 12:25. EXAMPLE
Decision and regime | Recorded | Outcome; indicators or factors | Reasons and facts relied on | Decided by |
|---|---|---|---|---|
DEC-2026-001 NIS2 | 12 Aug 2026, 11:30 3 h 5 min after awareness | Reportable NS-04, NS-01, NS-02 | NS-04 met: ransomware spreading across the Warehouse 2 office network, capable of stopping dispatch (NS-01) if it reached the warehouse systems. NS-01 and NS-02 not met on the facts at 11:30. | Executive incident lead |
DEC-2026-002 GDPR | 12 Aug 2026, 11:30 3 h 5 min after awareness | Not settled None met Revisit by 14 Aug 2026, 10:00 | Shipping records with customer names and delivery addresses on the encrypted PCs: an availability breach. Whether any data was taken is not yet known. | Executive incident lead |
DEC-2026-003 GDPR Replaces DEC-2026-002 | 14 Aug 2026, 10:00 49 h 35 min after awareness | Not reportable GF-01, GF-07 | Unlikely to result in a risk: restored from backup with nothing lost, and the provider's analysis found no sign of data taken (GF-01, GF-07). Recorded under RD-08. | Executive incident lead |
DEC-2026-004 DORA | 12 Aug 2026, 11:30 3 h 5 min after awareness | Not applicable None met | Not a financial entity (applicability profile). | Executive incident lead |
NIS2 was decided on capability. At 11:30 no service had stopped and no loss was known, so NS-01 and NS-02 were not met. Ransomware was spreading on the office network, which meets NS-04: if it reached the warehouse systems, dispatch would stop. One indicator is enough.
GDPR could not be settled at the screen. The encrypted PCs held customer names and addresses, so there was an availability breach; whether anything had been taken was unknown. DEC-2026-002 was recorded as Not settled, with a revisit before the GDPR doubt point of 15 Aug 2026, 02:25.
What followed: NIS2 early warning made 12 Aug 2026, 15:40, due 13 Aug 2026, 08:25 (RD-01); NIS2 incident notification made 14 Aug 2026, 14:00, due 15 Aug 2026, 08:25 (RD-02); NIS2 final report made 11 Sep 2026, 12:00, due 14 Sep 2026, 23:59 (RD-04); notice to the cyber insurer made 12 Aug 2026, 11:45 (RD-15); crime report made 12 Aug 2026, 17:10 (RD-16).
INC-2026-016: Customer order spreadsheet sent to the wrong business customer
A customer service agent emailed a spreadsheet of 212 customers' names, delivery addresses and order histories to the wrong business customer. The recipient confirmed in writing the same day that it had deleted the file. No payment data was included. Declared 9 Sep 2026, 11:20 at Severity 2; screen due 9 Sep 2026, 15:20. EXAMPLE
Decision and regime | Recorded | Outcome; indicators or factors | Reasons and facts relied on | Decided by |
|---|---|---|---|---|
DEC-2026-008 NIS2 | 9 Sep 2026, 13:00 1 h 40 min after awareness | Not reportable NS-03 | No indicator met: no service disrupted; one recipient, a business customer, not damage at scale (NS-03). | Executive incident lead |
DEC-2026-009 GDPR | 9 Sep 2026, 13:00 1 h 40 min after awareness | Reportable GF-01, GF-03, GF-06 | Confidentiality breach: names, delivery addresses and order histories of 212 customers sent to the wrong business customer. A risk (GF-01, GF-03, GF-06); whether a high risk to be settled once the recipient confirms deletion. | Executive incident lead |
DEC-2026-010 GDPR Replaces DEC-2026-009 | 9 Sep 2026, 17:15 5 h 55 min after awareness | Reportable GF-02, GF-07 | A risk, not a high risk: the recipient confirmed deletion in writing at 16:30, no payment data was included, and the data went to a known business (GF-02, GF-07). Notify the authority (RD-06); individuals not told (RD-07 not due). | Executive incident lead |
DEC-2026-011 DORA | 9 Sep 2026, 13:00 1 h 40 min after awareness | Not applicable None met | Not a financial entity (applicability profile). | Executive incident lead |
A Severity 2 incident, so the executive incident lead recorded the decision not to report under NIS2 (RN-06): one file to one customer is not damage at scale (NS-03). GDPR was Reportable from the screen. The open question was whether the breach was a high risk, which would also require telling the customers (RD-07).
What followed: GDPR notification to the supervisory authority made 11 Sep 2026, 10:00, due 12 Sep 2026, 11:20 (RD-06).
The three incidents not reported
INC-2026-015, request to change a supplier's bank details from its compromised mailbox (Severity 3); INC-2026-017, staff mailbox taken over after a phishing email (Severity 2, lowered to Severity 3); INC-2026-018, blocked attempts to exploit a published weakness on the ordering platform (Severity 4). EXAMPLE
Decision and regime | Recorded | Outcome; indicators or factors | Reasons and facts relied on | Decided by |
|---|---|---|---|---|
DEC-2026-005 NIS2 | 2 Sep 2026, 12:10 1 h 30 min after awareness | Not reportable None met | No indicator met: no service disrupted, no money lost, the call-back check stopped the payment. | Incident manager |
DEC-2026-006 GDPR | 2 Sep 2026, 12:10 1 h 30 min after awareness | Not applicable None met | No personal data of ours affected: the compromised mailbox was the supplier's. | Incident manager |
DEC-2026-007 DORA | 2 Sep 2026, 12:10 1 h 30 min after awareness | Not applicable None met | Not a financial entity (applicability profile). | Incident manager |
DEC-2026-012 NIS2 | 22 Sep 2026, 15:20 55 min after awareness | Not reportable None met | No indicator met: one mailbox, contained 40 minutes after detection, no service affected. Recorded after the incident was lowered to Severity 3. | Incident manager |
DEC-2026-013 GDPR | 22 Sep 2026, 15:20 55 min after awareness | Not reportable None met | Not a personal data breach: the mailbox audit log shows no mail was read or forwarded by the attacker. Recorded as assessed. | Incident manager |
DEC-2026-014 DORA | 22 Sep 2026, 15:20 55 min after awareness | Not applicable None met | Not a financial entity (applicability profile). | Incident manager |
DEC-2026-015 NIS2 | 29 Sep 2026, 10:30 40 min after awareness | Not reportable None met | No indicator met: every attempt blocked, the system already patched. | Incident manager |
DEC-2026-016 GDPR | 29 Sep 2026, 10:30 40 min after awareness | Not applicable None met | No personal data affected. | Incident manager |
DEC-2026-017 DORA | 29 Sep 2026, 10:30 40 min after awareness | Not applicable None met | Not a financial entity (applicability profile). | Incident manager |
- INC-2026-015: the compromised mailbox was the supplier's, so no personal data of ours was at stake. GDPR is Not applicable. What followed: crime report made 2 Sep 2026, 14:30 (RD-16).
- INC-2026-017: declared at Severity 2 and lowered at 15:20, when the decisions were recorded. The decisions were recorded once it was Severity 3, so the incident manager recorded them, and P09 never needed the executive incident lead. GDPR is Not reportable: personal data was at stake, and the audit log is the evidence that no breach occurred.
- INC-2026-018: every attempt blocked; the incident manager recorded the three decisions in 40 min.
The two revisited decisions
Both revisits followed a new fact. Each is a new line naming the decision it replaces, and each first decision was right on the facts known when it was made.
Incident and regime | First decision | Revisited decision | Interval |
|---|---|---|---|
INC-2026-014 GDPR | DEC-2026-002 12 Aug 2026, 11:30 Not settled | DEC-2026-003 14 Aug 2026, 10:00 Not reportable | 46 h 30 min |
INC-2026-016 GDPR | DEC-2026-009 9 Sep 2026, 13:00 Reportable | DEC-2026-010 9 Sep 2026, 17:15 Reportable | 4 h 15 min |
The first revisit changed the outcome. DEC-2026-002 was settled at its revisit time, 16 h 25 min before the doubt point; had the provider's analysis not been ready, the notification would have gone by 15 Aug 2026, 08:25 on the facts known, saying the assessment was continuing. The second revisit kept the outcome and settled the level: the notification under RD-06 went on 11 Sep 2026, 10:00, before its deadline of 12 Sep 2026, 11:20, and no communication to individuals was needed. EXAMPLE
INC-2026-014: the clocks
Every due time below is computed from P09's clocks and the awareness time. The NIS2 incident notification and the GDPR notification share the same 72-hour deadline. EXAMPLE
Time | What happened or fell due | Rule |
|---|---|---|
12 Aug 2026, 08:25 | Declared Severity 1; awareness fixed (DS-01). Every awareness clock starts. | |
12 Aug 2026, 11:30 | Screen complete: DEC-2026-001 NIS2 Reportable; DEC-2026-002 GDPR Not settled, revisit by 14 Aug 2026, 10:00; DEC-2026-004 DORA Not applicable | DS-08 |
12 Aug 2026, 12:25 | P09's 4-hour screen due | IM-06, RN-02 |
12 Aug 2026, 15:40 | NIS2 early warning submitted | RD-01 |
13 Aug 2026, 02:25 | NIS2 doubt point: 6 hours before the early warning's deadline. Not reached: the decision was already Reportable. | RN-04 |
13 Aug 2026, 08:25 | NIS2 early warning deadline | RD-01 |
14 Aug 2026, 10:00 | DEC-2026-003: GDPR revisited, Not reportable; recorded as a breach (RD-08) | DS-10, RN-05 |
14 Aug 2026, 14:00 | NIS2 incident notification submitted | RD-02 |
15 Aug 2026, 02:25 | GDPR doubt point. Had DEC-2026-002 still been Not settled now, it would have become Reportable and the notification gone by the deadline on the facts known. | RN-04 |
15 Aug 2026, 08:25 | NIS2 incident notification deadline, and the GDPR deadline had the breach been a risk | RD-02, RD-06 |
11 Sep 2026, 12:00 | NIS2 final report submitted | RD-04 |
14 Sep 2026, 23:59 | NIS2 final report deadline: one month from the incident notification, end of day | RD-04, CN-03 |
Guidance — delete before approval
What this example teaches: the screen took 3 h 5 min, and the early warning went 7 h 15 min after awareness on what was then known. The GDPR question was left open on purpose, with a revisit time, and settled in time. Nothing waited for the cause.
Common mistakes
Mistake | What the model does instead |
|---|---|
Waiting for the investigation before deciding | The screen is due within P09's 4 hours. Decide on what is known; mark the rest Not settled with a revisit time (DS-03, RN-04). |
Testing only what the incident has done | Every test runs on what the incident has done or could do. Spreading ransomware meets NS-04 before any service stops. |
Treating P09 severity as the legal test | Severity says how fast we respond. A Severity 2 incident can be a personal data breach that must be notified; a Severity 1 incident can be not reportable under the GDPR. Each regime is tested separately. |
Starting the clock at the decision | Every clock that runs from awareness starts at DS-01, before the decision. A decision taken at hour 3 leaves 21 hours for the early warning, not 24. |
Leaving Not settled open | Every Not settled decision carries a revisit time before the doubt point. At the doubt point it becomes Reportable (RN-04). |
Deciding Not reportable once and never again | A new fact can meet a test days later. Re-run the test at each update and record the result (RN-05). |
Writing reasons nobody can test | "Low impact" is not a reason. Name the indicator, threshold or factor, and the fact that met it or did not. |
Confusing Not applicable with Not reportable | Not applicable means the regime cannot apply (the profile says so, or no personal data was at stake). Not reportable means it applies and the test was not met. |
How to defend a decision not to report
An auditor will usually test that legal and regulatory reporting requirements are identified, that events are assessed and decided on consistently, and that the decisions are recorded (ISO/IEC 27001 controls 5.25 and 5.31). An authority that learns of an incident some other way will ask a narrower question: why did you not tell us? Both are answered from the same records.
Evidence to have ready
- The applicability profile in force on the day, approved under RN-01, with the role and authority for each regime.
- The decision line for the incident and regime: outcome, indicators or thresholds, reasons, who decided and when.
- The fact base as it stood at the decision, and the evidence each fact rests on (logs, the supplier's analysis, the recipient's confirmation of deletion).
- Every revisit of the decision, with the time and the result, including those that changed nothing.
- The calibration record for the NIS2 indicators, showing counsel's view and any national guidance used (RN-03).
- For the GDPR, the breach record (RD-08) and the Data Protection Officer's risk assessment.
- The P09 case log, showing the screen completed within 4 hours.
The re-derivation test
Invite the auditor to pick [[5]] decisions from the log, including at least one Not reportable and one revisit. For each, read the fact base as it stood at the decision and apply the test in this model. The outcome should match the log, the indicators or factors named should be the ones the facts meet, and the decider should be the one RN-06 names. Run this test yourself each quarter, so the first time is not in front of the auditor.
Questions you will be asked
Question | Answer the model gives |
|---|---|
Why was this incident not significant? | Name each NIS2 indicator, the fact that shows it was not met, and that the indicators are calibrated to the national guidance (RN-03). |
When did you become aware, and why then? | Awareness is P09's declaration time unless the record shows certainty earlier (DS-01). Show the case log entry and what was known before it. |
What did you know at the time of the decision? | The fact base as it stood, and what was marked unknown. A decision is judged on the facts known then. |
Did you look again when the facts changed? | Show every revisit (RN-05). A decision never revisited is the weakest point of any defence. |
Why is a personal data breach unlikely to result in a risk? | The factors GF-01 to GF-07 that were assessed, the facts behind each, and the breach record (RD-08). |
If the authority disagrees
Make the report at once, with the reasons for the delay (RN-13). Correct any earlier statement in the next report (RN-12). Record the authority's view and recalibrate the indicator it concerns (RN-03), so the next decision follows it.
Guidance — delete before approval
The strongest defence is a decision recorded within 4 hours, with named indicators, the facts behind them and every revisit. The weakest is a reason written after the authority asked.
Limitations
No decision model is complete. These are this one's known weaknesses, and how they are managed.
Limitation | Effect | How it is managed |
|---|---|---|
The NIS2 indicators are this model's, not the law's. | An authority may read Article 23(3) differently. | Calibrate them with counsel and the national guidance before use and every year (RN-03). Where the law or the authority sets a threshold, it wins. |
National law may add to the Directive. | A shorter clock, an extra report or a sector threshold the model does not show. | Enter it in the applicability profile (RN-01, CN-08) and use it instead. |
Capability is a judgement. | Two people can disagree on whether an incident could cause severe disruption. | Record the facts behind the judgement. When in doubt, the doubt rule decides (RN-04). |
The GDPR risk level is a judgement. | The same breach can be assessed as a risk by one person and a high risk by another. | The Data Protection Officer leads the assessment on the EDPB factors and records each one; the executive incident lead decides. |
Calibration and review
Calibration test cases
Run these cases on any spreadsheet, form or tool that applies the model, including the log. Each must give the expected result. They are run through the model's own functions when this document is built.
NIS2
Indicators met | Significant? | Case |
|---|---|---|
None | No | Nothing met: a contained phishing click with no service, money or data effect |
NS-04 | Yes | Capability alone: ransomware spreading, before any service has stopped |
NS-02 | Yes | A fraudulent payment above the Severe threshold, with no service disruption |
NS-03 | Yes | Customers' operations stopped by a fault in a service we provide them |
GDPR
Role | Risk level | Duties | Case |
|---|---|---|---|
Controller | Unlikely to result in a risk | RD-08 | Encrypted laptop lost, key safe |
Controller | Risk | RD-06, RD-08 | Customer list sent to one wrong business, deletion confirmed |
Controller | High risk | RD-06, RD-07, RD-08 | Identity documents published on the internet |
Processor | High risk | RD-09 | The same, in data we process for a client |
The DORA cases are in the section on the DORA test.
Review
This model is reviewed at least every 12 months with the applicability profile (RN-01), and also when the national law or an authority's guidance changes, when P09's severity values change, after any decision an authority questioned, and when the quarterly re-derivation test (see "How to defend a decision not to report") finds a decision it cannot reproduce. The Head of Information Security runs that test with P09's quarterly report (RN-18).
Calibration record
Date | Counsel or reviewer | What was calibrated | Values agreed | Cases run | Approved by |
|---|---|---|---|---|---|
[[YYYY-MM-DD]] | [[Name, firm]] | [[NIS2 indicators / GDPR factors / DORA criteria]] | [[values]] | [[n, all as expected]] | [[Name]] |
Related documents
Document | Relationship |
|---|---|
EU Incident Notification Timeline Matrix (NIS2, DORA, GDPR) | Every duty's trigger, clock, recipient and content, for the regimes this model opens |
Regulatory Notification Operating Procedure | The rules RN-01 to RN-18; drafting, review, approval and submission once a decision is Reportable; the fact base |
Regulatory Notification Log | Where each decision is recorded, with the submissions that follow |
Notification Readiness Checklist | Checks that the applicability profile and the calibration are current |
Incident Classification, Severity & Escalation Matrix | Severity 1 to 4, whose values NS-01, NS-02 and NS-04 carry, and the reporting duties RD-01 to RD-16 |
Incident Triage & First-Hour Assessment Procedure | The 4-hour reporting screen this model answers (IM-06) |
Personal Data Breach Response Playbook | The Data Protection Officer's breach assessment behind DS-06 |
Adapting this template
Guidance — delete before approval
Small organisation: keep the profile, the ten steps, the four outcomes, the doubt rule and the decision record; they are what an authority asks for. One person may run the screen and the privacy lead may be external, but the decider stays the executive named under RN-06.
Not in scope of NIS2: mark NIS2 Not applicable in the profile and keep the line. NIS2 Article 30 lets other entities notify significant incidents voluntarily; record that decision too if you consider it.
Regulated financial entity (DORA): classify against Delegated Regulation (EU) 2024/1772 in the authority's own terms, keep a record of the client, transaction and economic figures behind each threshold, and run the recurring-incident check monthly. If reporting is outsourced to a service provider, it uses this model's records (RN-16).
Processor for other controllers: list each controller, its breach contact and its contract's notice period in the profile. Your GDPR decision is then RD-09 only; the controller decides the rest.
National law: enter any shorter clock, extra report or sector threshold in the profile and in the indicator it affects. Where it conflicts with this model, the law wins.
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.25 — Assessment and decision on information security events | The decision tree: every declared incident assessed and decided against each reporting duty |
ISO/IEC 27001:2022 | Annex A 5.31 — Legal, statutory, regulatory and contractual requirements | The applicability profile and the three legal tests |
ISO/IEC 27001:2022 | Annex A 5.5 — Contact with authorities | The authorities in the profile and the decision to contact them |
NIST CSF 2.0 | RS.MA-03 — “Incidents are categorized and prioritized” | The whole model: each incident categorised as significant, major or notifiable |
NIST CSF 2.0 | RS.AN-06 — “Actions performed during an investigation are recorded, and the records' integrity and provenance are preserved” | The decision record, kept with every revisit |
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 test (DS-04) and the indicators NS-01 to NS-04 |
NIS2 — Directive (EU) 2022/2555 | Article 6(11) — “significant cyber threat” means “a cyber threat which, based on its technical characteristics, can be assumed to have the potential to have a severe impact on the network and information systems of an entity or the users of the entity’s services by causing considerable material or non-material damage” | Significant cyber threats, beside the incident test |
NIS2 — Implementing Regulation (EU) 2024/2690 | Article 1 — lays down the technical and methodological requirements of the Article 21(2) measures, and further specifies when an incident is significant, for DNS service providers, TLD name registries, cloud computing, data centre and content delivery network providers, managed service and managed security service providers, providers of online marketplaces, online search engines and social networking services platforms, and trust service providers | Who the Implementing Regulation binds (NS-06); for other entities it is a guide only |
NIS2 — Implementing Regulation (EU) 2024/2690 | Article 3 — the cases in which an incident is significant for the digital providers named in Article 1 (among them cloud computing, data centre, managed service and managed security service providers) | NS-06: the digital providers' own significance test |
NIS2 — Implementing Regulation (EU) 2024/2690 | Article 3(1) — for the providers named in Article 1, an incident is significant where one or more criteria are met, among them direct financial loss above €500,000 or 5% of total annual turnover, whichever is lower; exfiltration of trade secrets; death of, or considerable damage to the health of, a natural person; a successful, suspectedly malicious and unauthorised access capable of causing severe operational disruption; or the criteria of Article 4 or of the provider-specific Articles 5 to 14 | NS-06: the criteria for digital providers |
NIS2 — Implementing Regulation (EU) 2024/2690 | Article 3(2) — “Scheduled interruptions of service and planned consequences of scheduled maintenance operations carried out by or on behalf of the relevant entities shall not be considered to be significant incidents.” | Scheduled maintenance is not significant |
NIS2 — Implementing Regulation (EU) 2024/2690 | Article 4 — incidents that individually are not significant are considered collectively as one significant incident where “(a) they have occurred at least twice within 6 months; (b) they have the same apparent root cause; (c) they collectively meet the criteria set out in Article 3(1)(a)” (the financial-loss criterion) | NS-05: recurring incidents |
DORA — Regulation (EU) 2022/2554 | Article 3(10) — “major ICT-related incident”: an ICT-related incident “that has a high adverse impact on the network and information systems that support critical or important functions” | The DORA test (DS-05): what a major ICT-related incident is |
DORA — Regulation (EU) 2022/2554 | Article 3(13) — “significant cyber threat” means “a cyber threat the technical characteristics of which indicate that it could have the potential to result in a major ICT-related incident or a major operational or security payment-related incident” | Significant cyber threats |
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 | The criteria DC-01 to DC-08 |
DORA — Regulation (EU) 2022/2554 | Article 18(2) — classify cyber threats as significant based on the criticality of the services at risk, the number or relevance of clients or financial counterparts targeted, and the geographical spread of the areas at risk | Significant cyber threats: how they are classified |
DORA — Delegated Regulation (EU) 2024/1772 | Article 1 — clients, financial counterparts and transactions: count all clients unable to use the service or adversely impacted, all affected financial counterparts with a contractual arrangement, and affected transactions with at least one part in the Union; weigh the relevance of those affected; estimate from comparable periods where actual numbers are unknown | DC-03: clients, financial counterparts and transactions |
DORA — Delegated Regulation (EU) 2024/1772 | Article 2 — reputational impact has occurred where the incident has been reflected in the media, has caused repetitive complaints from different clients or counterparts, means the entity will not or is likely not to meet regulatory requirements, or will or is likely to lose clients or counterparts with a material business impact | DC-04: reputational impact |
DORA — Delegated Regulation (EU) 2024/1772 | Article 3 — duration runs from when the incident occurs (or is detected, or first recorded in logs) until it is resolved; service downtime runs from when the service is fully or partially unavailable until regular activities are restored; estimates apply where the end is unknown | DC-05: duration and service downtime |
DORA — Delegated Regulation (EU) 2024/1772 | Article 4 — geographical spread: whether the incident has had an impact in other Member States, in particular on clients and counterparts, branches or group entities, or financial market infrastructures or third-party providers there | DC-06: geographical spread |
DORA — Delegated Regulation (EU) 2024/1772 | Article 5 — data losses: whether the incident has made data inaccessible or unusable (availability), compromised the trustworthiness of its source (authenticity), caused unauthorised modification (integrity), or led to access or disclosure to an unauthorised party (confidentiality) | DC-07: data losses |
DORA — Delegated Regulation (EU) 2024/1772 | Article 6 — criticality of services affected: whether the incident affects ICT services or systems supporting critical or important functions, affects authorised, registered or supervised financial services, or is a successful, malicious and unauthorised access to the entity’s network and information systems | DC-01: critical services affected |
DORA — Delegated Regulation (EU) 2024/1772 | Article 7 — economic impact: the direct and indirect costs and losses incurred, without accounting for financial recoveries (among them expropriated funds, replacement costs, staff costs, contractual fees, redress, forgone revenue, communication and advisory costs), excluding day-to-day running costs and insurance premiums | DC-08: economic impact |
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 rule in words and the test cases |
DORA — Delegated Regulation (EU) 2024/1772 | Article 8(2) — recurring incidents that individually are not major are one major incident where “(a) they have occurred at least twice within 6 months; (b) they have the same apparent root cause …; (c) they collectively fulfil the criteria for being considered a major incident set out in paragraph 1”; assessed monthly; not applicable to microenterprises and the entities listed in DORA Article 16(1) | Recurring incidents under DORA |
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 | DC-02 and the thresholds of DC-03 to DC-08 |
DORA — Delegated Regulation (EU) 2024/1772 | Article 10 — a cyber threat is significant where all of these hold: if materialised it could affect critical or important functions of the entity or other financial entities, third-party providers, clients or counterparts; it has a high probability of materialisation; and it could meet the criticality-of-services criterion or the thresholds in Article 9(1) or 9(4) | When a cyber threat is significant |
DORA — Implementing Regulation (EU) 2025/302 | Article 5 — where further assessment shows that an incident reported as major at no time met the Article 8 criteria of Delegated Regulation (EU) 2024/1772, the entity notifies the authority that it has reclassified it as non-major, using the template fields ‘type of report’ and ‘other information’ | Reclassification as a revisited decision |
GDPR — Regulation (EU) 2016/679 | Article 4(12) — “personal data breach” means “a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed” | GDPR question 1: is it a personal data breach? |
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 | The risk level that requires notification (RD-06); the 72-hour clock |
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 | The high-risk level that requires communication to individuals (RD-07) |
GDPR — Regulation (EU) 2016/679 | Article 34(3) — no communication is required where the data was protected (for example encrypted), where later measures mean the high risk is no longer likely, or where it would involve disproportionate effort (then a public communication instead) | The conditions under which a high-risk breach need not be communicated |
EDPB — Guidelines 9/2022 | Paragraph 31 — a controller should be regarded as having become “aware” when it “has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised” | When we became aware, for the GDPR |
NIS2 — Directive (EU) 2022/2555 | Article 23(1) — entities report, among other things, any information that lets the CSIRT or competent authority determine any cross-border impact; “The mere act of notification shall not subject the notifying entity to increased liability.” | The doubt rule: notifying does not of itself increase liability |
DORA — Regulation (EU) 2022/2554 | Article 19(2) — financial entities may voluntarily notify significant cyber threats to the relevant competent authority when they deem the threat relevant to the financial system, service users or clients | Voluntary notification of significant cyber threats |
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.” | GDPR question 2: a processor tells the controller |
GDPR — Regulation (EU) 2016/679 | Article 33(5) — the controller documents every personal data breach: the facts, its effects and the remedial action taken | Every breach recorded, notified or not (RD-08) |
ISO/IEC 27001 references name the clause or control this document relates to. They do not say that meeting it meets any other framework's requirement.
Definitions
Term | Meaning in this model |
|---|---|
Applicability profile | The standing record, made before any incident, of which regimes can apply to us at all, in which role, and which authority each report goes to (RN-01). |
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. |
Fact base | The one record of the incident's facts that every report is drafted from, so reports to different authorities agree (RN-11). |
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. |
Not settled | A decision that cannot yet be made because a fact the test needs is still unknown. It always carries the time it will be revisited and is never left open past the doubt point (RN-04). |
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. |
Regime | A body of law that sets its own reporting duty: NIS2, DORA or the GDPR. Contracts, insurance policies and crime reporting add duties of their own, which P09 lists beside them. |
Reportability decision | The recorded answer, for one incident and one regime, to whether a report is due: Reportable, Not reportable, Not applicable or Not settled, with the reasons and the facts it rests on (RN-02). |
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. |