Regulatory Notification Operating Procedure

Assigns decision authority, drafting, legal review, submission and follow-up reporting for each regime.

Available soon

Format: Word
Size: 77 KB
Length: 29 pages
Version: 1.1
Updated: 2 Oct 2026

Follow this documentFree account. We can email you when it changes.

What changed

1.12 Oct 2026
Quotes P09's corrected RD-10 deadline.
1.02 Oct 2026
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 procedure gets an incident's reports to the authorities made correctly and on time: to the national Computer Security Incident Response Team (CSIRT) or competent authority, the data protection supervisory authority and, for financial entities, the financial competent authority. It says who decides, who drafts, who reviews, who approves, who submits and who logs each report under NIS2, DORA and the GDPR, and how the next report is tracked once the first is in.

It is the working routine behind rules RN-01 to RN-18. The Security Incident Management Policy and its documents handle the incident and own the reporting duties themselves: the sixteen duties RD-01 to RD-16, their deadlines and recipients, the 4-hour reporting screen (P09 IM-06), and the decision to report, which is the executive incident lead's. This procedure takes over once the screen has a decision, and gets the reports made. It never changes a P09 clock.

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. National details in this procedure are placeholders: [[national law transposing NIS2: title, number and date]]; [[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]].

Scope

This procedure applies to:

every report to an authority under NIS2, DORA or the GDPR, from the first to the last, for any declared incident;
follow-up reports, answers to an authority's questions, and corrections;
notices to customers, clients and individuals that the law requires (P09 RD-05, RD-07, RD-13), as far as they must agree with the reports;
our notice to a controller where we process personal data for it (P09 RD-09), and a supplier's notice to us (P06 CL-07);
everyone in the roles below, at any hour, and any third party that reports for us.

It does not cover how an incident is handled, how severity is set or when an incident is declared (the Incident Triage & First-Hour Assessment Procedure), how each legal test is applied (the Reportability Decision Model), or what each report says line by line (the NIS2 Early Warning, Notification & Final Report Templates and the Personal Data Breach Notification Templates). Contract, insurance and crime notices (P09 RD-14 to RD-16) stay with P09; they are listed in the fact base so the reports agree with them.

How this procedure sits under P09

P09 declares the incident and fixes awareness, which starts the clocks. This procedure uses that time for every due time.
P09 runs the reporting screen within 4 hours (IM-06). This procedure records one decision per regime (RN-02) and revisits it (RN-05).
P09 owns the duties RD-01 to RD-16, their deadlines and recipients. This procedure drafts, reviews, approves, submits and logs each report against them.
P09 names the approver of each message template (CT-04, CT-06, CT-07, CT-08). This procedure uses those approvers and adds the four-eyes check (RN-08).

Roles

Role	What they do in this procedure
Executive incident lead [[e.g. Chief Operating Officer, with a named deputy]]	Decides whether each report is made, on the incident manager's screen (P09), and approves the NIS2 and DORA reports before they go.
Incident manager [[e.g. Information Security Manager, with a named deputy]]	Runs the reportability screen within P09's 4 hours, keeps the fact base and the log, and drafts the NIS2 and DORA reports.
Data Protection Officer [[or the privacy lead where no DPO is appointed]]	Assesses the risk of a personal data breach, drafts the notification to the supervisory authority and the communication to individuals, and advises on every GDPR decision.
Legal [[in-house or external counsel]]	Reviews each report before it goes, within the time RN-07 allows, and advises where a test is unclear. Never holds a report past its deadline.
Communications lead [[e.g. Head of Marketing and Communications]]	Sends notices to customers, clients and individuals from the approved templates (P09 IM-09).
Notification signatory [[the named people who may submit reports, each with a deputy]]	Submits reports through each authority's channel and records the submission (RN-08, RN-09).
Head of Information Security [[e.g. Head of Information Security or CISO]]	Owns this procedure, the applicability profile and the readiness checklist, and reports the measures.
Executive management [[e.g. Executive Committee]]	Approves this procedure and the applicability profile.

Who decides

RN-06 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.

Who does what, by regime

The approvers are the ones P09 names for each template. Nobody else may approve a report.

Step	NIS2	GDPR	DORA
Screen and decide	Incident manager screens; executive incident lead decides	Data Protection Officer assesses risk; executive incident lead decides	Incident manager classifies; executive incident lead decides
Draft	Incident manager	Data Protection Officer	Incident manager
Review	Legal	Legal	Legal
Approve	Executive incident lead	Executive incident lead, with the Data Protection Officer	Executive incident lead
Submit and log	Notification signatory	Notification signatory	Notification signatory, or the third party under RN-16
Notice to people	Communications lead; approved as P09 CT-04	Communications lead; approved as P09 CT-08	Communications lead; approved as P09 CT-04

Signatories and deputies

A signatory is a person named in advance with the authority to submit reports in the organisation's name, and with working access to the channel each regime uses (RN-08). Name them in writing before any incident.

RN-17 The Notification Readiness Checklist must be completed at least every [[6]] months and whenever an authority, channel, signatory or the profile changes. Each signatory's access to each channel is tested at least every [[12]] months, and every signatory has a deputy with access.

Channel	Authority	Signatory	Deputy	Access last tested
NIS2	[[national CSIRT, or the competent authority where notifications go to it]]	[[Name, role]]	[[Name, role]]	[[YYYY-MM-DD]]
GDPR	[[lead supervisory authority, or the supervisory authority of the Member State concerned]]	[[Name, role]]	[[Name, role]]	[[YYYY-MM-DD]]
DORA	[[financial competent authority designated under DORA Article 46]]	[[Name, role, or the third party under RN-16]]	[[Name, role]]	[[YYYY-MM-DD]]

Guidance — delete before approval

The signatory can be the person who drafts. The four-eyes check (RN-08) then needs someone else. In a small team, the incident manager often drafts and submits the NIS2 reports and the Data Protection Officer the GDPR one; give each a deputy who has signed in to the portal at least once.

Delete the DORA row if the applicability profile says DORA cannot apply to you.

Triggers and inputs

What starts this procedure

Trigger	Where it comes from	First step
P09's reporting screen records a decision of Reportable or Not settled for any regime	The Regulatory Notification Log, within P09's 4 hours (P09 IM-06)	NP-02
A decision short of Reportable is revisited and becomes Reportable (RN-05)	Any P09 update, or a new fact	NP-02; the clocks start when the record shows the fact was known
A supplier tells us of an incident at its end (P06 CL-07, within [[24]] hours)	The supplier's notice to our security contact	Screened as our own incident, with its own awareness time (RN-15)
A breach affects personal data we process for another controller	P09's screen	NP-03: notice to the controller within [[24]] hours (RN-15)
An authority asks for an intermediate report or more information	The authority's message, through the channel or the contact point	NP-08: logged as a new due time at once (RN-10)
A report already sent is found to contain a material error	Anyone on the response; the fact base	Corrections (RN-12)

Inputs

Everything starts from the applicability profile, made before any incident.

RN-01 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.

Input	Where it is kept
The applicability profile: regimes, roles, authorities, channels, national clocks (RN-01)	[[where the approved profile is kept]]
The reportability decisions for the incident	Regulatory Notification Log
The clocks, triggers and recipients of every report	EU Incident Notification Timeline Matrix (NIS2, DORA, GDPR)
The report templates	NIS2 Early Warning, Notification & Final Report Templates; Personal Data Breach Notification Templates; or the authority's own form
The approved notices to customers and individuals (CT-04, CT-08)	Incident Communications Template Set
The signatory list, with deputies and their access to each channel (RN-08, RN-17)	Notification Readiness Checklist; [[the signatory list]]

The reports and their clocks

P09 sets every duty and deadline below. This procedure adds who drafts and who approves. Hours run on the calendar, not working hours.

Duty	Report	Deadline (P09)	Who drafts and approves
RD-01 NIS2	Early warning	Within 24 hours of awareness	Drafts: Incident manager Approves: Executive incident lead (CT-06)
RD-02 NIS2	Incident notification	Within 72 hours of awareness	Drafts: Incident manager Approves: Executive incident lead (CT-06)
RD-03 NIS2	Intermediate report	When the authority asks	Drafts: Incident manager Approves: Executive incident lead (CT-06)
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)	Drafts: Incident manager Approves: Executive incident lead (CT-06)
RD-05 NIS2	Notice to recipients of our services	Without undue delay, where appropriate	Drafts: Communications lead (RN-14) Approves: Executive incident lead (CT-04)
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	Drafts: Data Protection Officer Approves: Executive incident lead, with the Data Protection Officer (CT-07)
RD-07 GDPR	Communication to the individuals affected	Without undue delay	Drafts: Data Protection Officer; sent by the communications lead (RN-14) Approves: Executive incident lead, with the Data Protection Officer (CT-08)
RD-08 GDPR	Breach record	For every personal data breach, notified or not	Keeps: Data Protection Officer No approval: kept as a record
RD-09 GDPR	Notice to the controller	Without undue delay	Drafts: Data Protection Officer Approves: Executive incident lead [[or as the processing contract names]]
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	Drafts: Incident manager Approves: Executive incident lead (Authority's template)
RD-11 DORA	Intermediate report	Within 72 hours of the initial notification, and again when regular activities are recovered	Drafts: Incident manager Approves: Executive incident lead (Authority's template)
RD-12 DORA	Final report	No later than one month after the latest intermediate report	Drafts: Incident manager Approves: Executive incident lead (Authority's template)
RD-13 DORA	Notice to clients	Without undue delay	Drafts: Communications lead (RN-14) Approves: Executive incident lead (CT-04)

Every clock that runs from awareness starts at the time P09 records it: the declaration, unless the record shows reasonable certainty earlier. It does not wait for the reportability decision. (CN-01)
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. (CN-02)
National law may shorten a clock or add a report. Where it does, the shorter clock is entered in the applicability profile and used instead (RN-01). (CN-08)

Guidance — delete before approval

One incident can start several clocks at once. List every due time in the log at NP-02, earliest first, and work to the earliest. The EU Incident Notification Timeline Matrix (NIS2, DORA, GDPR) sets them side by side.

Procedure steps

Take the steps in order for each report. Several reports can be in progress at once; each follows its own steps.

Step	What to do	By when	Who
NP-01 Screen	Run the decision model; record a decision per regime (RN-02).	Within 4 hours	Incident manager; Data Protection Officer for the GDPR; Executive incident lead decides
NP-02 Brief the signatory	Tell the signatory on duty which reports are coming and when they are due.	At once on any Reportable or Not settled decision	Incident manager
NP-03 Draft	Draft from the fact base on the template (RN-07, RN-11).	As soon as the decision is made	Incident manager (NIS2, DORA); Data Protection Officer (GDPR)
NP-04 Review	Legal checks the draft (RN-07).	Within 60 minutes of the draft	Legal
NP-05 Approve	The template's approver approves (RN-08).	Before the deadline	The approver P09 names for the template
NP-06 Check and submit	A second person checks it where time allows; the signatory submits (RN-08).	Before the deadline	A second person; the notification signatory
NP-07 Log	Record time, channel, reference and copy; set the next due time (RN-09, RN-10).	At once on submission	Notification signatory
NP-08 Follow up	Draft and submit the next report the same way; answer the authority's questions through the incident manager.	Each next due time, or on the authority's request	Drafter and signatory, as at NP-03 to NP-07
NP-09 Close	Mark the incident's reports complete in the log; give the post-incident review (P09) the report history.	When the last report is made	Incident manager

NP-01 Screen and decide

P09's screen asks the three legal questions within 4 hours of declaration. The Reportability Decision Model applies each test.

RN-02 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-03 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.

Every decision has one of four outcomes:

Outcome	Meaning
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).

RN-04 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-05 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.

Guidance — delete before approval

A report made in doubt can be updated, or withdrawn with an explanation. A deadline missed while waiting for certainty cannot be recovered. That is why a Not settled decision becomes Reportable [[6]] hours before the first deadline.

NP-02 Brief the signatory

Call the notification signatory on duty for each regime that is Reportable or Not settled. A message alone is not enough out of hours.
Say which reports are coming, to which authority, and when each is due. Give the due times from the log, not from memory.
The signatory checks at once that they can sign in to the channel. If they cannot, the deputy takes over now, not at the deadline (RN-17).
Put every due time in the calendars of the drafter and the signatory, with the reminder RN-10 sets.

NP-03 Draft from the fact base

RN-07 Each report must be drafted from the fact base on the pack's templates or the authority's own form: the NIS2 and DORA reports by the incident manager, the GDPR notification and communication by the Data Protection Officer. Legal reviews it within [[60]] minutes; a report with no review by then goes on its approver's decision.

Open the fact base. Take every item from it; do not write facts into the report that are not in the fact base. If a fact is new, add it to the fact base first (RN-11).
Use the template for the report, or the authority's own form where it requires one. The templates list what each report must contain.
Say what is not yet known, and when it will follow. A report that waits for completeness is a late report.
Where a figure differs from one given to another authority because the regimes count differently, say so in the report (RN-11).
Send the draft to Legal and to the approver at the same time, with the deadline at the top.

The fact base

The fact base is the one record of the incident's facts that every report is drafted from, so reports to different authorities agree (RN-11). Open it at NP-01 and keep it current until NP-09. The EU Incident Notification Timeline Matrix (NIS2, DORA, GDPR) shows which report uses each field.

	Field	What to record
FB-01	Entity identification	Legal name, registration or identifier numbers each authority uses, sector and the services in scope. Kept ready in the applicability profile.
FB-02	Contact point	The person the authority or individuals can reach at any hour: name, role, telephone and email. For the GDPR, the Data Protection Officer.
FB-03	What happened	A plain description: what was seen, what was affected, what the attacker or fault did, as far as known.
FB-04	Key times	Occurrence (if known), detection, declaration (awareness), DORA classification where it applies, containment, recovery.
FB-05	Services affected	Which services, for whom, how badly and for how long: stopped, degraded, at risk.
FB-06	Severity and impact	P09 severity and the impact on each P05 area; for DORA, the duration and service downtime.
FB-07	Geography	Member States where services, customers or data are affected; whether there is or could be a cross-border impact.
FB-08	Systems and data affected	Systems, sites and data sets involved, and the security property affected (availability, integrity, confidentiality, authenticity).
FB-09	Suspected cause	Whether unlawful or malicious acts are suspected, and the type of threat (ransomware, account takeover, fault, supplier failure).
FB-10	Root cause	The cause established by the investigation, and the route in. Left as "under investigation" until known.
FB-11	Indicators of compromise	File hashes, addresses, domains, accounts and techniques seen, where they can be shared.
FB-12	Measures taken	Containment, eradication, recovery and mitigation done and planned, with times; whether continuity plans were activated.
FB-13	Notices to others	Customers, clients, individuals and suppliers told, when and how, and what we advised them to do.
FB-14	Report history	Each report made: regime, stage, time, channel and the authority's reference.
FB-15	People affected	Categories and approximate numbers of people (customers, staff, clients) affected.
FB-16	Personal data affected	Categories and approximate numbers of personal data records, with any special category or criminal offence data marked.
FB-17	Likely consequences	What could happen to the people affected (fraud, distress, loss of control of their data, discrimination) and how likely it is.
FB-18	Classification result	The DORA criteria and thresholds met, and the NIS2 indicators met, from the decision record.
FB-19	Economic impact	Direct and indirect costs and losses, gross and after recoveries, as far as known.

Why one fact base

RN-11 Every report for an incident must be drafted from the one fact base, so that reports to different authorities agree. Where figures differ between reports because the regimes count differently, the report says so.

One incident can be reported to the national CSIRT, the data protection supervisory authority and a financial regulator within the same day. Authorities share what they receive. Two reports that give different start times, different numbers of customers or different causes invite questions at the worst moment. One record, kept by one person, prevents it.

The incident manager owns the fact base. Others add to it through the incident manager, never straight into a draft.
Each entry carries its time and its source. Unknowns are written as unknown; estimates are marked.
When a fact changes, the change is dated, not overwritten. The report history (FB-14) shows what each authority was told and when.

Guidance — delete before approval

Regimes count differently. DORA counts affected clients and transactions; the GDPR counts people and records; NIS2 looks at the service and its users. The same incident can be counted in people in one report and in business customers in another. Both can be right: say what each figure counts (RN-11).

Legal review: the time-box

Legal reviews every report before it goes, within [[60]] minutes of receiving the draft (RN-07, NP-04). The time-box starts when the draft is sent, not when Legal opens it.

Legal checks that every fact is in the fact base, that estimates and unknowns are marked, that nothing contradicts another report or a notice to customers, that the draft says no more than it needs about cause or fault, and that shared detail such as indicators of compromise can be shared.

Legal does not rewrite facts, and does not hold a report. A draft with no review when the [[60]] minutes run out goes on its approver's decision, and the log records that the review lapsed (PF-03). Where a test itself is unclear, Legal advises at NP-01, never past the doubt point (RN-03).

Guidance — delete before approval

Agree the time limit with Legal before any incident, in and out of hours (RC-10). External counsel on a retainer can cover nights and weekends.

Approval and the four-eyes check

RN-08 Each report must be approved by the approver P09 names for its template, and submitted only by a notification signatory through the authority's channel. Where at least [[60]] minutes remain before the deadline, a second person checks it against the fact base first.

The approvers are P09's: CT-06, NIS2 early warning and notification content: executive incident lead; CT-07, GDPR notification to the supervisory authority: executive incident lead, with the Data Protection Officer; CT-08, communication to individuals affected: executive incident lead, with the Data Protection Officer; CT-04, customer notice: executive incident lead. Approval is in writing, with its time: an email or a message in the case channel. Out of hours, approval by phone is written into the log by the incident manager with the time, and the approver confirms it in writing afterwards. An approver who cannot be reached is replaced by their named deputy (RC-09).

NP-06 The four-eyes check and submission

Where at least [[60]] minutes remain before the deadline, a second person compares the approved report with the fact base, line by line: times, numbers, names, systems and the authority's earlier reference. The drafter cannot be the second person.
With less time left, the signatory submits without the check and logs that it was skipped and why.
The signatory submits through the channel in the applicability profile, under their own account.
If the channel is down, use the authority's fallback route in the profile and log it. Resubmit through the channel later if the authority asks.

Submission and the log

RN-09 On submission, the signatory must record in the log the time, the channel, who submitted it, a copy of what was sent and any reference or acknowledgement the authority returns. Every later report for the incident quotes that reference.

RN-10 On each submission, the next report's due time must be entered in the log and in the calendars of its drafter and signatory, with a reminder at [[half]] the time remaining. A request from the authority for an intermediate report is logged as a new due time at once.

Record in the log: the time of submission, the channel, who submitted, and a copy of exactly what was sent (RN-09).
Record the authority's reference and the time of any acknowledgement as soon as they arrive. If none arrives, ask the authority for one and log that you asked.
Add the submission to the fact base's report history, so the next report quotes the reference.
Enter the next report's due time in the log and in the calendars of its drafter and signatory, with the reminder (RN-10).

The submission record in the Regulatory Notification Log holds: submission ID, incident, duty, report, due, submitted, on time, channel, submitted by, authority reference, acknowledged, next report, next due.

Follow-up reports and requests from the authority

Log any reply from the authority at once: feedback, an offer of help, a question or a request for an intermediate report. A request is a new due time (RN-10).
Answer questions through the incident manager, from the fact base. Anything that changes a reported fact is a correction (RN-12).
Draft, review, approve, check, submit and log each follow-up report exactly as the first (NP-03 to NP-07).
Revisit every decision short of Reportable at each P09 update (RN-05). A regime that becomes Reportable starts its own clocks.

The follow-up reports and their clocks are in the table of reports above: NIS2 RD-02 to RD-04, DORA RD-11 and RD-12. Under the GDPR, information not yet known follows in phases, without undue further delay. NIS2's final report runs from the incident notification, not from awareness. If the incident is still being handled at that deadline, a progress report goes instead and the final report follows within one month of handling ending.

The CSIRT may reply to an early warning with initial feedback and an offer of help. Under DORA the competent authority acknowledges each report and may give feedback. Log every reply and act on it through the incident manager. An authority's question is answered from the fact base, by the drafter, approved as the report was.

NP-09 Close

Check the log: every Reportable regime has its last report made, every request answered, every correction made.
Mark the incident's reports complete in the log, with the date.
Give the report history and any late or skipped step to the post-incident review (Post-Incident Review Template).

Corrections

RN-12 A material error found in a submitted report must be corrected in the next report, or by a correction to the same authority without undue delay where no report is due, and the correction logged.

A material error is one that would change how the authority sees the incident: a wrong time, a wrong number of people or customers, a wrong cause, a system or service missed.
Where a report is due soon, correct it there: say what was wrong, what is right, and why it changed.
Where no report is due, send a correction to the same authority through the same channel, drafted, approved and logged as a report.
If the same error went to another authority, correct it there too (RN-11).
Under DORA, if later facts show the incident never met the major test, notify the reclassification as non-major on the template. Never stop reporting silently.

Late reports

RN-13 A report that will miss its deadline must still be made as soon as possible, with the reasons for the delay. A report is never held back to avoid a deadline, and a missed deadline is reported to the executive incident lead at once.

A report that will be late is still made. It says why it is late, in one or two plain sentences, and gives what is known. Then:

NIS2: make the report as soon as possible and give the reasons. Tell the CSIRT by telephone or email if the portal is the cause.
GDPR: 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. (P09 RD-06)
DORA: if a time limit cannot be met, tell the authority before it passes and say why (Delegated Regulation (EU) 2025/301, Article 5(3)). Telling the authority before the limit passes is a duty in itself; it does not replace the report.

Every late report goes to the post-incident review with its reasons (NP-09), and counts against the headline measure for reports made on time.

Escalation

When	What to do	Who is told
The approver cannot be reached	Their named deputy approves (RC-09)	The approver, at once when reached
The signatory cannot reach the channel	The deputy signatory submits (RN-17); if no signatory can, the authority's fallback route in the profile	Head of Information Security
The channel itself is down	The authority's fallback route in the profile, logged; resubmit through the channel when the authority asks	The authority, in the fallback message
A deadline will be missed	Make the report as soon as possible with the reasons (RN-13). Under DORA, tell the authority before the limit passes (RN-13; Delegated Regulation (EU) 2025/301, Article 5(3))	Executive incident lead, at once
A supplier's notice arrives late, or not at all, and we learn of its incident another way	Screen at once as our own incident; raise the late notice under the contract (P06 CL-07)	Head of Information Security

Notices to customers and individuals

RN-14 Notices to customers, clients and individuals (P09 RD-05, RD-07, RD-13) go only through the communications lead from the approved templates (P09 IM-09), approved as P09 names, and say nothing that contradicts a report to an authority.

Duty	Notice	Template and approver (P09)
RD-05	NIS2: notice to recipients of our services. Without undue delay, where appropriate.	CT-04; Executive incident lead
RD-07	GDPR: communication to the individuals affected. Without undue delay.	CT-08; Executive incident lead, with the Data Protection Officer
RD-13	DORA: notice to clients. Without undue delay.	CT-04; Executive incident lead

The Data Protection Officer drafts the communication to individuals (RD-07) from the fact base; the communications lead sends it.
A notice says nothing an authority has not been told, and nothing that contradicts a report. Where the notice goes first, the next report mentions it (FB-13).
The supervisory authority may require us to tell individuals, and a CSIRT may inform the public or require us to. Log the request as a new due time (RN-10).

Processors and suppliers

RN-15 Where we process personal data for another controller, we must notify that controller without undue delay and within [[24]] hours of awareness, or sooner where the contract says so (P09 RD-09). A supplier's notice to us (P06 CL-07) is screened as our own incident, with its own awareness time.

When we are the processor

The Data Protection Officer notifies the controller, using the contact the controller's contract names, within [[24]] hours of awareness or sooner where the contract says so.
We do not first assess whether the breach is likely to result in a risk. That assessment is the controller's. Give the controller everything it needs for its own notification, as far as known, and follow up as facts arrive.
The controller decides whether to notify its supervisory authority and the people affected. We do not notify them for the controller unless the contract says so.

When a supplier tells us of an incident

Clause CL-07 of the Supplier Contract Security Clause Library, security incident notification, tells us of an incident at the supplier within [[24]] hours, early enough to meet our own notification duties to regulators and customers. It applies to suppliers in Tier 1 to Tier 3, and any supplier holding our data or with access to our systems.

Screen the supplier's incident as our own, at once. Its awareness time is ours: when the record shows we had reasonable certainty, usually on receiving the notice.
Where the supplier processes personal data for us, we are in principle aware of a personal data breach once the supplier has told us. Our 72 hours run from then.
Put the supplier's notice and every update in the fact base, with its time. A late notice is raised under the contract by the Head of Information Security.

Outsourced DORA reporting

RN-16 Where a third party submits DORA reports for us, the contract must say so, the third party must use this procedure's fact base and log, and we stay responsible for every report and its timing.

DORA lets a financial entity outsource its reporting to a third-party service provider. The entity stays fully responsible for every report. Where you do it:

the contract names the third party as reporter, sets the times it must meet, and gives it the fact base and the log as its only sources;
the authority is told of the arrangement before the first notification, with the third party's name, contact details and identification code, and told again when it ends (Implementing Regulation (EU) 2025/302, Article 6);
the decision to report stays with the executive incident lead, and the approval with the approver P09 names; the third party submits and logs;
a third party serving several financial entities may send one aggregated report only in the narrow cases Implementing Regulation (EU) 2025/302, Article 7 allows, and with the authority's permission;
the readiness check confirms the contract and the third party's access to the channel (RC-16).

What each regime adds

NIS2

The early warning is short on purpose: send what is known. Do not wait for the cause.
The CSIRT may reply with initial feedback and an offer of help within 24 hours of the early warning (Article 23(5)). Log it and act on it.
If the incident is still being handled at the final report's deadline, send a progress report then and the final report within one month of handling ending.
Recipients of our services whose service is likely to be affected are told where appropriate (RD-05); for a significant cyber threat, tell them what they can do (Article 23(2)).
A trust service provider sends its incident notification for an incident affecting its trust services within 24 hours, not 72.

DORA

Classify as soon as the facts allow: the 4-hour clock runs from classification, and the 24-hour limit from awareness runs regardless.
Use the template of Implementing Regulation (EU) 2025/302 through the competent authority's channel.
An intermediate report also goes when regular activities are recovered (RD-11). The final report's clock restarts with each intermediate report.
If later facts show the incident never met the major test, notify the reclassification as non-major on the template. Never stop reporting silently.
Significant cyber threats may be notified voluntarily (Article 19(2)).
Clients whose financial interests are affected are told without undue delay (RD-13).
DORA's initial notification has two limits, and the earlier wins: 4 hours from classifying the incident as major, and 24 hours from awareness.
Where an incident is classified as major more than 24 hours after awareness, the initial notification is due within 4 hours of that classification.
Where a deadline falls on a weekend or a bank holiday in the entity's Member State, the report may go by noon of the next working day. This never applies to the initial notification or intermediate report of credit institutions, central counterparties, trading venue operators, or financial entities that are also essential or important entities under NIS2, and the authority may withdraw it from other significant or systemic entities.

The Data Protection Officer leads the risk assessment and drafts; the decision to notify is the executive incident lead's.
Notify within 72 hours of awareness where feasible. Information not yet known follows in phases (Article 33(4)).
Where processing crosses borders inside the EU, notify the lead supervisory authority.
Record every personal data breach, notified or not, with the risk decision and its reasons (RD-08).
As a processor, tell the controller; the controller decides and notifies (RN-15).

Working out of hours

Clocks run on calendar hours, through nights, weekends and public holidays. The one exception is DORA's weekend rule (CN-09), under What each regime adds. Working hours in P09 are [[08:00–18:00, Monday to Friday]]; a report is due at 03:00 on a Sunday if that is when its clock ends. The procedure works out of hours only if these are in place before the incident:

What must be in place	Rule; readiness check
A signatory and a deputy for each channel, both reachable, with sign-in that does not depend on one person's device	RN-08, RN-17; RC-07, RC-08
A deputy for the executive incident lead and for each template approver, reachable out of hours	RN-06; RC-09
Legal's out-of-hours contact, who has agreed the review time limit	RN-07; RC-10
Each authority's out-of-hours contact, where it has one	RN-01; RC-05
The templates with the entity's details already filled in	RN-07; RC-11
The fact base and the log reachable during an outage of the main systems	RN-11; RC-12

Legal's time-box applies at night as by day. If Legal cannot be reached, the time-box runs from when the draft was sent.
A deadline that falls at a weekend is met before the weekend where the facts allow. Under DORA only, the weekend rule (CN-09) may give until noon of the next working day; check that it applies to you.

Guidance — delete before approval

Test it. At least every [[12]] months, at an awkward hour, ask the signatory on duty and the deputy to sign in to each portal and record that they could (RN-17). The Notification Readiness Checklist records the result.

Pitfalls

The hours in which reports most often go wrong, and the fix this procedure uses:

	Pitfall	Fix
PF-01	Waiting for the cause before the early warning	The early warning needs only what is known now (RD-01). The cause belongs in the final report.
PF-02	Only one person can reach the portal	Every signatory has a deputy with tested access (RN-17).
PF-03	Legal review runs past the deadline	Review is time-boxed at 60 minutes; the approver decides without it after that (RN-07).
PF-04	Reports to different authorities disagree	One fact base feeds every report (RN-11).
PF-05	The next deadline is forgotten once the first report is in	Each submission sets the next due time in the log and two calendars (RN-10).
PF-06	"Not reportable" is decided once and never revisited	Every decision short of Reportable is revisited at each update (RN-05).
PF-07	The authority's reference is lost	It is logged on submission and quoted in every later report (RN-09).

Outputs and records

Output	Step	Held in
A reportability decision per regime, with reasons, and each revisit	NP-01; NP-08	Regulatory Notification Log
Signatory briefed; due times in the log and two calendars	NP-02	Regulatory Notification Log; calendars
The fact base, kept current	NP-03 onwards	[[with the case in the Incident Case & Action Log]]
Each draft, Legal's review or its lapse, and the approval with its time	NP-03 to NP-05	[[the case folder]]
A copy of every report exactly as sent, with its time, channel, signatory, reference and acknowledgement; the second check or why it was skipped; requests, replies, corrections and late-report reasons	NP-06 to NP-08	Regulatory Notification Log; [[the case folder]]
The GDPR breach record, notified or not (P09 RD-08)	NP-01; NP-09	Regulatory Notification Log; Incident Case & Action Log
Reports marked complete; the report history given to the review	NP-09	Regulatory Notification Log; Post-Incident Review Template

RN-18 The log and a copy of every report and decision must be kept for at least [[6]] years after the incident is closed. The headline measures are reported to executive management every quarter with P09's (P09 IM-12).

Keep the copies exactly as sent, with the approvals and acknowledgements, for at least [[6]] years after the incident is closed, or longer where national law or a contract says so.
Keep decisions not to report, and the GDPR breach record for every personal data breach, notified or not, with their reasons. They show the test was applied.

Measures

The headline measures are reported to executive management every quarter with P09's (P09 IM-12). RNM-02 is P09's IMM-02, unchanged.

	Measure	Definition	Target	Q3 2026 (EXAMPLE)
RNM-01	Decisions on time	Declared incidents with a decision for every regime in the profile recorded within 4 hours of declaration, out of all declared in the quarter.	All	5 of 5
RNM-02	Reports made on time	Reports to authorities and individuals made by their deadline, out of all that fell due in the quarter.	All	4 of 4
RNM-03	Follow-up reports overdue	Reports past their due time and not yet made, at the quarter end.	None	0
RNM-04	Readiness	Readiness checks Ready, out of those that apply, at the last check; and blocking checks not Ready.	Every blocking check Ready	13 of 16; blocking not Ready: 0

Worked example: the distributor's reports in the third quarter

EXAMPLE, not part of the procedure. The organisation is the one used throughout the pack: 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 and a controller for its customers', staff and suppliers' personal data; it processes no personal data for other controllers. It is not a financial entity, so DORA's reporting duties do not apply. Executive management approved this procedure and the applicability profile on 15 Sep 2026, and the Head of Information Security entered the quarter's incidents from P09's case log. The walk-through reads those records against the steps above. Replace every time and name with your own.

The applicability profile and signatories

Regime	Applies	Role	Authority
NIS2	Yes	Important entity, confirmed by the board on 21 May 2026 (P12)	[[national CSIRT, or the competent authority where notifications go to it]]
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]]

Signatories: NIS2, Information Security Manager; deputy Head of Information Security, with access from 24 Sep 2026. GDPR, Data Protection Officer; deputy Legal. EXAMPLE

INC-2026-014: three NIS2 reports

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 at Wed 12 Aug 2026, 08:25. EXAMPLE

When	What happened	Who	Step
Wed 12 Aug 2026, 08:25	Declared Severity 1, category IC-01; reporting clocks start. Every clock that runs from awareness starts here (CN-01).	Incident manager	CN-01
Wed 12 Aug 2026, 11:30	Reporting screen complete: NIS2 significant; GDPR breach to assess; DORA not applicable. Decisions recorded: NIS2 Reportable (DEC-2026-001); GDPR Not settled, to revisit by 14 Aug 2026, 10:00 (DEC-2026-002); DORA Not applicable. The early warning is due 13 Aug 2026, 08:25; the notification 15 Aug 2026, 08:25.	Incident manager, Data Protection Officer; Executive incident lead decides	NP-01, NP-02
Wed 12 Aug 2026, 15:40	NIS2 early warning submitted through [[the national notification portal or address, from the national law or the CSIRT's website]]. Next due time set: the notification, 15 Aug 2026, 08:25, reminder at 14 Aug 2026, 00:02. Acknowledged with the authority's reference at 16:05.	Information Security Manager (signatory)	NP-06, NP-07
Wed 12 Aug 2026, 19:45	CSIRT initial feedback received at 19:45 with an offer of malware analysis, which was declined (Article 23(5)). Logged.	Incident manager	NP-08
Fri 14 Aug 2026, 10:00	GDPR decision revisited: Not reportable. DEC-2026-003 replaces DEC-2026-002: 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.	Data Protection Officer; Executive incident lead decides	RN-05
Fri 14 Aug 2026, 14:00	NIS2 incident notification submitted. Quoted the early warning's reference. Acknowledged at 14:20. Next due time set: the final report, 14 Sep 2026, 23:59.	Information Security Manager (signatory)	NP-06, NP-07
Fri 21 Aug 2026, 09:00	Closed after 7 days' monitoring without recurrence. Handling has ended, so the report due next is a final report, not a progress report (CN-03).	Incident manager	CN-03
Thu 27 Aug 2026, 10:00	Post-incident review held: the root cause the final report needs.	Head of Information Security	Fact base FB-10
Fri 11 Sep 2026, 12:00	NIS2 final report submitted. Root cause from the post-incident review of 27 Aug 2026. Acknowledged at 12:30; no further report due, so the reports are marked complete (NP-09).	Information Security Manager (signatory)	NP-06 to NP-09

Check	Limit	Actual	Met	Basis
Decisions for every regime recorded, from declaration	4 hours	3 hours 5 minutes	Yes	RN-02; P09 IM-06
GDPR Not settled revisited, by the doubt point	By 15 Aug 2026, 02:25	14 Aug 2026, 10:00; 16 hours 25 minutes to spare	Yes	RN-04
NIS2 early warning made	By 13 Aug 2026, 08:25	12 Aug 2026, 15:40; 16 hours 45 minutes to spare	Yes	P09 RD-01
NIS2 incident notification made	By 15 Aug 2026, 08:25	14 Aug 2026, 14:00; 18 hours 25 minutes to spare	Yes	P09 RD-02
NIS2 final report made	By 14 Sep 2026, 23:59	11 Sep 2026, 12:00; 3 days 11 hours 59 minutes to spare	Yes	P09 RD-04

P09's other notices went alongside, outside this procedure: the cyber insurer at 11:45 (RD-15) and the crime report at 17:10 (RD-16). Both are in the fact base (FB-13). EXAMPLE

Three points from this incident. First, the early warning went 7 hours 15 minutes after awareness, on what was known then; the root cause reached the authority in the final report, from the post-incident review (PF-01). Second, the GDPR decision was Not settled at the screen, with a revisit time, and was settled at 14 Aug 2026, 10:00, before the doubt point of 15 Aug 2026, 02:25; had it still been open then, a notification would have gone on the facts known (RN-04). The breach is still recorded under P09 RD-08. Third, the incident notification's deadline fell on Sat 15 Aug 2026, 08:25; it went on Fri 14 Aug 2026, 14:00, the day before. EXAMPLE

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 at Wed 9 Sep 2026, 11:20. EXAMPLE

When	What happened	Who	Step
Wed 9 Sep 2026, 11:20	Declared Severity 2: customer order spreadsheet sent to the wrong business customer. The GDPR clock starts (CN-01).	Incident manager	CN-01
Wed 9 Sep 2026, 13:00	Decisions recorded. NIS2 Not reportable (DEC-2026-008): no indicator met: no service disrupted; one recipient, a business customer, not damage at scale (NS-03). GDPR Reportable (DEC-2026-009): 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. DORA Not applicable. The notification is due 12 Sep 2026, 11:20.	Incident manager; Data Protection Officer; Executive incident lead decides	NP-01, NP-02
Wed 9 Sep 2026, 16:30	Contained: the recipient's deletion confirmed in writing.	Incident manager	Fact base FB-12
Wed 9 Sep 2026, 17:15	DEC-2026-010 replaces DEC-2026-009: 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).	Data Protection Officer; Executive incident lead decides	RN-05; the high-risk question settled
Fri 11 Sep 2026, 10:00	GDPR notification submitted through [[the authority's breach notification form or portal]]. No information left to follow; no reasons for delay needed. Acknowledged at 10:02; no report follows.	Data Protection Officer (signatory)	NP-06 to NP-09

The NIS2 decision not to report a Severity 2 incident was the executive incident lead's, as RN-06 requires. The Data Protection Officer drafted the notification and submitted it as GDPR signatory, 1 day 22 hours 40 minutes after awareness and 1 day 1 hour 20 minutes before the deadline. The decisions were recorded 1 hour 40 minutes after declaration, inside P09's 4 hours, and the risk level was settled 1 day 16 hours 45 minutes before the notification went. Individuals were not told: the final risk decision was a risk, not a high risk, so the communication to individuals (RD-07) was not due. The review that followed raised PIA-06: turn on the warning for external recipients in email, and stop address autocomplete for customer service. EXAMPLE

Guidance — delete before approval

The 72 hours are the outer limit (CN-06). Record why each step took the time it did, so you can show the notification was made without undue delay.

The other incidents

INC-2026-015 (request to change a supplier's bank details from its compromised mailbox); INC-2026-017 (staff mailbox taken over after a phishing email); INC-2026-018 (blocked attempts to exploit a published weakness on the ordering platform): each had a decision for every regime within 4 hours of declaration, none Reportable, so no report was made (DEC-2026-005, DEC-2026-006, DEC-2026-007; DEC-2026-012, DEC-2026-013, DEC-2026-014; DEC-2026-015, DEC-2026-016, DEC-2026-017). P09's other notices were made for INC-2026-014 and INC-2026-015. EXAMPLE

What the records showed

While INC-2026-014's reports were made, only the Information Security Manager could reach the NIS2 portal. The first readiness check on 18 Sep 2026 found it (RC-08): "The GDPR channel's deputy (Legal) has access; the NIS2 portal's deputy (Head of Information Security) had none. Account issued and tested on 24 Sep." (PF-02). EXAMPLE
P09's case log holds the submission times, but not when Legal reviewed each draft or who made the second check. From adoption, the log records both (NP-04, NP-06). EXAMPLE
Legal agreed the 60-minute review for working hours only; RA-03, agree out-of-hours review cover with external counsel, is due 31 Oct 2026. EXAMPLE

Document	Relationship
EU Incident Notification Timeline Matrix (NIS2, DORA, GDPR)	Every report's trigger, clock, recipient and content, side by side
Reportability Decision Model	The tests applied at NP-01, and how each decision is recorded
NIS2 Early Warning, Notification & Final Report Templates	The NIS2 report content drafted at NP-03
Personal Data Breach Notification Templates	The GDPR notification and communication drafted at NP-03
Regulatory Notification Log	Decisions, submissions, references and next due times (NP-01, NP-07)
Notification Readiness Checklist	What must be ready before an incident (RN-17)
Incident Classification, Severity & Escalation Matrix	The reporting duties RD-01 to RD-16 and their clocks
Incident Triage & First-Hour Assessment Procedure	Declaration, awareness and the reporting screen
Incident Communications Template Set	The approved templates CT-04, CT-06, CT-07 and CT-08
Supplier Contract Security Clause Library	Clause CL-07: suppliers' incident notices
NIS2 Competent Authority Registration Data Sheet	The contact details the NIS2 authority holds for us

Adapting this template

Guidance — delete before approval

Small organisation: the incident manager may draft and submit, and the executive incident lead may be the managing director. Keep the decision record, the fact base, the time-box and the log; they are what an authority asks for. Name a second person for the four-eyes check, even if it is someone outside security.

Regulated financial entity (DORA): keep the DORA rows and notes. Add the classification time to the fact base (FB-04) and the classification result (FB-18), set the initial notification's due time from both limits, and check every month for recurring incidents. If a third party reports for you, complete the outsourcing section before the first incident.

Processor for other organisations: record each controller's breach contact and notice period (RC-15). Your notice to the controller is the report that matters most; give it the same steps.

Several countries: under the GDPR, a breach in cross-border processing goes to the lead supervisory authority. Under NIS2, check where each entity in the group is registered. Put the answer in the applicability profile, not in this procedure.

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.5 — Contact with authorities	Signatories, channels and the authorities' contacts; submission and the log
ISO/IEC 27001:2022	Annex A 5.26 — Response to information security incidents	The procedure steps NP-01 to NP-09: the response's reporting part
ISO/IEC 27001:2022	Annex A 5.37 — Documented operating procedures	The whole procedure: a documented operating procedure for reporting
NIST CSF 2.0	RS.CO-02 — “Internal and external stakeholders are notified of incidents”	The whole procedure: authorities, customers and individuals notified
NIST CSF 2.0	RS.MA-04 — “Incidents are escalated or elevated as needed”	Escalation and late reports
NIST CSF 2.0	GV.SC-08 — “Relevant suppliers and other third parties are included in incident planning, response, and recovery activities”	Processors and suppliers; outsourced DORA reporting
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	The reports and their clocks; notices to recipients of our services
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)	The reports and their clocks; follow-up reports
NIS2 — Directive (EU) 2022/2555	Article 23(5) — the CSIRT or competent authority responds without undue delay and where possible within 24 hours of receiving the early warning, with initial feedback and, on request, guidance or operational advice on mitigation; where the incident is suspected to be criminal, it also gives guidance on reporting it to law enforcement	Follow-up reports: the CSIRT's feedback logged at NP-08
NIS2 — Directive (EU) 2022/2555	Article 23(7) — where public awareness is necessary to prevent or deal with a significant incident, or disclosure is otherwise in the public interest, the CSIRT or competent authority may, after consulting the entity, inform the public or require the entity to do so	Notices to customers and individuals: the authority may inform the public or require us to
NIS2 — Directive (EU) 2022/2555	Article 30 — essential and important entities may notify incidents, cyber threats and near misses voluntarily, and other entities significant incidents, cyber threats and near misses; voluntary notifications follow the Article 23 procedure, and voluntary reporting imposes no additional obligations the entity would not otherwise have had	Scope: voluntary notifications follow the same steps
DORA — Regulation (EU) 2022/2554	Article 19(1) — report major ICT-related incidents to the relevant competent authority	The reports and their clocks, DORA rows
DORA — Regulation (EU) 2022/2554	Article 19(4) — an initial notification, an intermediate report, and a final report when the root cause analysis is complete and actual impact figures are available	Follow-up reports: initial notification, intermediate and final reports
DORA — Regulation (EU) 2022/2554	Article 19(5) — financial entities may outsource the reporting obligations to a third-party service provider; “the financial entity remains fully responsible for the fulfilment of the incident reporting requirements”	Outsourced DORA reporting (RN-16)
DORA — Regulation (EU) 2022/2554	Article 22(1) — the competent authority acknowledges receipt of the initial notification and each report and may give feedback or high-level guidance; the financial entity remains fully responsible for handling the incident and its consequences	Follow-up reports: the authority's acknowledgement and feedback
DORA — Delegated Regulation (EU) 2025/301	Article 5(3) — an entity unable to meet a time limit informs the competent authority without undue delay, and no later than that time limit, and explains the reasons for the delay	Late reports: tell the authority before the limit passes
DORA — Implementing Regulation (EU) 2025/302	Article 1 — the Annex I template is used for the initial notification, the intermediate report and the final report	NP-03: the authority's template for DORA reports
DORA — Implementing Regulation (EU) 2025/302	Article 4 — reports go through the secure electronic channels the competent authority provides; an entity unable to use them informs the authority through other secure means agreed with it, and resubmits through the channel if required	NP-06 and escalation: the authority's channel and fallback
DORA — Implementing Regulation (EU) 2025/302	Article 6 — an entity that has outsourced its reporting under DORA Article 19(5) informs its competent authority of the arrangement at the latest before the first notification, gives the third party’s name, contact details and identification code, and informs the authority when the outsourcing ends	Outsourced DORA reporting: the authority told before the first notification
DORA — Implementing Regulation (EU) 2025/302	Article 7 — a third-party service provider to which reporting is outsourced may submit one aggregated report for several financial entities only where the incident originates from a third-party ICT provider serving them, each entity classifies it as major, all are in one Member State under the same authority, and the authority permits it; not for significant credit institutions, trading venues or central counterparties	Outsourced DORA reporting: aggregated reports
GDPR — Regulation (EU) 2016/679	Article 33(1) — notify the supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it”, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons; a later notification gives reasons for the delay	The reports and their clocks; late reports with reasons
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.”	Processors and suppliers: notice to the controller (RN-15)
GDPR — Regulation (EU) 2016/679	Article 28(3)(f) — the processing contract stipulates that the processor “assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 taking into account the nature of processing and the information available to the processor”	Processors and suppliers: what the controller needs from us
GDPR — Regulation (EU) 2016/679	Article 34(4) — if the controller has not already communicated the breach to the data subjects, the supervisory authority, having considered the likelihood of high risk, may require it to do so or may decide that any of the conditions in Article 34(3) are met	Notices to customers and individuals: the authority may require it
GDPR — Regulation (EU) 2016/679	Article 56(1) — the supervisory authority of the main or single establishment of the controller or processor is competent to act as lead supervisory authority for its cross-border processing, without prejudice to Article 55	What each regime adds, GDPR: the lead supervisory authority
EDPB — Guidelines 9/2022	Paragraph 44 — a processor notifies the controller without first assessing the likelihood of risk, which is for the controller; in principle the controller is “aware” once the processor has informed it	Processors and suppliers: no risk assessment by the processor; the controller aware once told

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 procedure
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.
Doubt point	The time, a fixed number of hours before a regime's first deadline, after which an unsettled decision is treated as Reportable and the report made on the facts known (RN-04).
Fact base	The one record of the incident's facts that every report is drafted from, so reports to different authorities agree (RN-11).
Four-eyes check	A second person's comparison of an approved report with the fact base before it is submitted, where at least [[60]] minutes remain (RN-08).
Late report	A report made after its deadline. It is still made, as soon as possible, and says why it is late. A report is never held back because its deadline has passed.
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.
Progress report	Under NIS2, the report made at the final report's deadline when the incident is still being handled. The final report then follows within one month of handling ending.
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.
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).
Signatory	A person named in advance with the authority to submit reports in the organisation's name, and with working access to the channel each regime uses (RN-08).
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.

Regulatory Notification Operating Procedure

What's inside

What changed

Preview

Purpose

Scope

How this procedure sits under P09

Roles

Who decides

Who does what, by regime

Signatories and deputies

Triggers and inputs

What starts this procedure

Inputs

The reports and their clocks

Procedure steps

NP-01 Screen and decide

NP-02 Brief the signatory

NP-03 Draft from the fact base

The fact base

Why one fact base

Legal review: the time-box

Approval and the four-eyes check

NP-06 The four-eyes check and submission

Submission and the log

Follow-up reports and requests from the authority

NP-09 Close

Corrections

Late reports

Escalation

Notices to customers and individuals

Processors and suppliers

When we are the processor

When a supplier tells us of an incident

Outsourced DORA reporting

What each regime adds

NIS2

DORA

GDPR

Working out of hours

Pitfalls

Outputs and records

Measures

Worked example: the distributor's reports in the third quarter

The applicability profile and signatories

INC-2026-014: three NIS2 reports

INC-2026-016: a GDPR notification

The other incidents

What the records showed

Related documents

Adapting this template

Framework references

Definitions