NIS2 Early Warning, Notification & Final Report Templates
Drafting templates for the three NIS2 reporting stages, aligned to the information each stage requires.
Available soon
- Format
- Word
- Size
- 72 KB
- Length
- 27 pages
- Version
- 1.0
- Updated
What's inside
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.
How to use these templates
When a significant incident hits an essential or important entity, NIS2 asks for up to four reports to the national CSIRT (computer security incident response team) or competent authority: an early warning, an incident notification, an intermediate report if the authority asks for one, and a final report. These templates prepare the content of each report, field by field, from the incident's fact base, so the reports agree with each other and nothing the law asks for is missed. They also hold the notice to recipients of our services that NIS2 asks for where appropriate.
The duties themselves are P09's: RD-01 early warning, RD-02 incident notification, RD-03 intermediate report, RD-04 final report, RD-05 notice to recipients of our services, in the Incident Classification, Severity & Escalation Matrix. These templates expand P09's CT-06 NIS2 early warning and notification content and do not change a clock, a recipient or an approver.
What is submitted. The authority's own portal or form is what is submitted. Use these templates to prepare and approve the content, then copy it into the portal field by field. Keep a copy of what was sent.
For [[Organisation Name]] | |
|---|---|
Receives NIS2 reports | CSIRT or competent authority: [[national CSIRT, or the competent authority where notifications go to it]] |
Channel | [[the national notification portal or address, from the national law or the CSIRT's website]] |
National law | [[national law transposing NIS2: title, number and date]] |
What national law adds | [[any duty or field the national law adds to the Directive]] |
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.
Steps for each report
The roles are P09's; the rules are the Regulatory Notification Operating Procedure's (RN-07 to RN-10).
- Read the due time from the log. The reportability decision set it (Reportability Decision Model).
- The incident manager drafts from the fact base: the header block, then the stage's fields. Write "not yet known" for anything unknown, and never leave a field empty.
- Legal reviews within [[60]] minutes. If the review has not come back by then, the approver decides without it (RN-07).
- The executive incident lead approves. Where at least [[60]] minutes remain before the deadline, a second person checks the report against the fact base (RN-08).
- A notification signatory copies the content into the authority's portal and submits it, then records the time, channel, the authority's reference and a copy in the log (RN-09).
- The signatory enters the next report's due time in the log and in the drafter's and signatory's calendars (RN-10).
Guidance — delete before approval
Fill in the header's standing fields now: entity, sector, contacts and channel. Readiness check RC-11 in the Notification Readiness Checklist asks for it.
Find out what the authority's portal asks for, in what order and in what language, and reorder the fields below to match. Note any length limit on a field: a portal that cuts text off loses the end of it.
Keep a copy of these templates outside your own systems. A ransomware incident can take the file shares and email away when you need them most.
The clocks
Each report has P09's deadline. Clocks run on calendar hours, through nights and weekends, from the time P09 records awareness.
Duty | Report | Deadline (P09) | Goes to |
|---|---|---|---|
RD-01 | Early warning | Within 24 hours of awareness | [[CSIRT or competent authority]] |
RD-02 | Incident notification | Within 72 hours of awareness | [[CSIRT or competent authority]] |
RD-03 | Intermediate report | When the authority asks | [[CSIRT or competent authority]] |
RD-04 | Final report | Within one month of the incident notification (a progress report then, and the final report within one month of handling, if still ongoing) | [[CSIRT or competent authority]] |
RD-05 | Notice to recipients of our services | Without undue delay, where appropriate | Customers whose service is likely to be adversely affected |
How to read the clocks:
Note | What it means |
|---|---|
CN-01 | 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-02 | 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-03 | 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. |
CN-08 | 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). |
Trust service providers
A trust service provider sends its incident notification for an incident that affects its trust services within 24 hours of awareness, not 72 (CN-12). The early warning and the notification then fall due together: send the early warning as soon as it is ready, and the notification by the same deadline. The incident notification template is the same.
When the decision is late, or the deadline will be missed
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-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.
Guidance — delete before approval
If national law sets a shorter clock or an extra report, enter it in the applicability profile and in the table above (CN-08).
The fact base and the header block
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.
The fact base fields NIS2 reports draw on:
Field | What it holds | Used in |
|---|---|---|
FB-01 Entity identification | Legal name, registration or identifier numbers each authority uses, sector and the services in scope. | RD-01 |
FB-02 Contact point | The person the authority or individuals can reach at any hour: name, role, telephone and email. | RD-01 |
FB-03 What happened | A plain description: what was seen, what was affected, what the attacker or fault did, as far as known. | RD-01, RD-04 |
FB-04 Key times | Occurrence (if known), detection, declaration (awareness), containment, recovery. | RD-01 |
FB-05 Services affected | Which services, for whom, how badly and for how long: stopped, degraded, at risk. | RD-02, RD-04, RD-05 |
FB-06 Severity and impact | P09 severity and the impact on each P05 area. | RD-02, RD-04 |
FB-07 Geography | Member States where services, customers or data are affected; whether there is or could be a cross-border impact. | RD-01, RD-04 |
FB-08 Systems and data affected | Systems, sites and data sets involved, and the security property affected (availability, integrity, confidentiality, authenticity). | RD-02, RD-04 |
FB-09 Suspected cause | Whether unlawful or malicious acts are suspected, and the type of threat (ransomware, account takeover, fault, supplier failure). | RD-01 |
FB-10 Root cause | The cause established by the investigation, and the route in. | RD-04 |
FB-11 Indicators of compromise | File hashes, addresses, domains, accounts and techniques seen, where they can be shared. | RD-02 |
FB-12 Measures taken | Containment, eradication, recovery and mitigation done and planned, with times; whether continuity plans were activated. | RD-02, RD-04 |
FB-13 Notices to others | Customers, clients, individuals and suppliers told, when and how, and what we advised them to do. | RD-02, RD-05 |
FB-14 Report history | Each report made: regime, stage, time, channel and the authority's reference. | RD-02, RD-03 |
Header block
Every report starts with the same header. It tells the authority who we are, who to call now, and which earlier report this one follows. 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.
Header: every report | |||
Report stage, and P09's duty | [[Early warning (RD-01) / Incident notification (RD-02) / Intermediate report (RD-03) / Final report or progress report (RD-04)]] | ||
Entity FB-01 | [[Legal name; the identifier the authority uses; essential or important entity]] | ||
Sector and services FB-01 | [[Sector and sub-sector under NIS2 Annex I or II; the services we provide in it]] | ||
Contact at any hour FB-02 | [[Name, role, mobile, email]] | Deputy contact FB-02 | [[Name, role, mobile, email]] |
Our reference P09 case number | [[INC-YYYY-nnn]] | Authority's reference RN-09 | [[None yet (early warning) / the reference the authority returned for the first report]] |
Due by P09's clock | [[Date, time]] | Drafted by | [[Name, role; date, time]] |
Reviewed by Legal (RN-07) | [[Name; time / not reviewed in time: the approver decided]] | Approved by RN-08 | [[Name, role; time]] |
Checked by second person (RN-08) | [[Name; time / not enough time before the deadline]] | Submitted by a signatory | [[Date, time; name of the signatory]] |
Channel | [[the national notification portal or address, from the national law or the CSIRT's website]] | Next report and when due (RN-10) | [[Report; date, time / none: last report]] |
Header guidance
Field | What to write; and if it is not yet known |
|---|---|
Report | The stage as the portal names it, and P09's duty number, so the log and the report match. |
Entity FB-01 | Exactly as the authority holds it from registration (P12 NR-02), so it can match the report to its records. Filled in before any incident. |
Sector and services FB-01 | The sector line from the registration, and the services in scope in one line. |
Contact at any hour FB-02 | A person who can answer the authority's questions about this incident tonight and at the weekend, usually the incident manager. Add a deputy. Not yet known: Never leave it blank. If the incident manager is unreachable, name the deputy. |
Our reference | The case number from the P09 case log. |
Authority's reference FB-14 | From the second report on, the reference the authority returned for the first. Every later report quotes it (RN-09). Not yet known: If no reference came back, quote the time and channel of the first report and ask the authority for one. |
Due by | The deadline from the log, worked out from P09's clock. |
Reviewed by | Legal's name and the time, or that the review time ran out and the approver decided without it (RN-07). |
Checked by | Who checked the report against the fact base before it went, or that there was not enough time. |
Channel | The portal, form or address in the applicability profile (RN-01). |
Next report | The next stage and its due time, as entered in the log and the calendars (RN-10). Not yet known: For the intermediate report, "only if the authority asks". |
Checks before any report goes
The incident manager completes these checks with the signatory before every report is submitted, with the stage's own checks below (RN-08). Tick each one; where one cannot be met in the time left, say so in the log.
Before it goes | Rule | Done |
|---|---|---|
Every fact and figure matches the fact base, and agrees with any report to another authority (or says why it differs) | RN-11 | ☐ |
The header is complete: entity, a contact reachable now, our reference and, after the first report, the authority's reference | RN-09 | ☐ |
Every field has an answer; anything unknown says "not yet known" and when it will follow | PF-01 | ☐ |
Legal has reviewed it, or the review time has run out and the approver decided without it | RN-07 | ☐ |
The approver has approved this version | RN-08 | ☐ |
A second person has checked it against the fact base, if the time left allows | RN-08 | ☐ |
Nothing in it contradicts a notice already sent to customers | RN-14 | ☐ |
It goes before its deadline; if it cannot, it goes now and gives the reasons for the delay | RN-13 | ☐ |
The signatory has access to the channel, and a copy of what is sent is kept | RN-09 | ☐ |
Early warning
NIS2's first report, within 24 hours of awareness. It says whether the incident is suspected to be unlawful or malicious, and whether it could have a cross-border impact. (P09 RD-01.) The early warning needs only what is known now (RD-01). The cause belongs in the final report. Send what is known: a short early warning on time is worth more than a full one late.
Template. The header block, then these fields. Under each label: the point of NIS2 Article 23 it answers and the fact base fields it draws on.
Early warning (RD-01) | |||
What has happened 23(4)(a) · FB-03 | [[Two to five sentences of fact: what was seen, which systems or sites, what the attacker or fault has done, and what has been done to stop it]] | ||
Key times 23(4)(a) · FB-04 | [[Detected: date, time. Became aware (declared): date, time. Contained: date, time / not yet]] | ||
Suspected unlawful or malicious act? 23(4)(a) · FB-09 | [[Yes / No / Not yet known: and why, in one line]] | ||
Could it have a cross-border impact? 23(4)(a) · FB-07 | [[Yes / No / Not yet known: which Member States, and why]] | ||
Not yet known | [[What is still being found out, and which report it will follow in]] | ||
Help asked of the CSIRT 23(5) | [[None at present / the help wanted: malware analysis, advice on mitigation, guidance on reporting a crime]] | ||
Field guidance
Field | What to write, and how much; and if it is not yet known |
|---|---|
What has happened NIS2 23(4)(a) · FB-03 | Facts, not theories: what was seen, where, since when, and what has been done so far. Two to five sentences. Write for an analyst who has never heard of us. Not yet known: Say what is known and that the assessment continues. The early warning is short on purpose: do not wait for the cause (PF-01). |
Key times NIS2 23(4)(a) · FB-04 | The awareness time is P09's declaration time, unless the record shows reasonable certainty earlier (CN-01). Add detection and, once reached, containment. Not yet known: When it started is often unknown: write "not yet known". Awareness is always known: it is in the case log. |
Suspected unlawful or malicious act? NIS2 23(4)(a) · FB-09 | Yes, No or Not yet known, with the one fact behind it: a ransom note, an attacker's sign-in, a fault in a change. Say whether a crime report has been or will be made (P09 RD-16). Not yet known: "Not yet known" is an answer. Never guess at who the attacker is. |
Could it have a cross-border impact? NIS2 23(4)(a) · FB-07 | Whether services, customers, suppliers or data in another Member State are or could be affected. One or two lines. Not yet known: "Not yet known", and what you are checking. A Yes can become a No later: say so in the notification. |
Not yet known Not asked by the law | The open questions, so the authority knows what is coming and need not ask. |
Help asked of the CSIRT NIS2 23(5) | The CSIRT replies to an early warning with initial feedback, and gives guidance or advice on request (Article 23(5)). Ask for what would help; say "none at present" otherwise. Not yet known: "None at present". You can ask later. |
Before it goes. The checks every report needs, and these:
Before it goes | Rule | Done |
|---|---|---|
Both questions are answered: suspected malicious act, and possible cross-border impact | 23(4)(a) | ☐ |
It has not been held back to wait for the cause | PF-01 | ☐ |
Incident notification
NIS2's second report, within 72 hours of awareness. It updates the early warning with an initial assessment of severity and impact and any indicators of compromise. (P09 RD-02.) For a trust service provider it is due within 24 hours (CN-12). It quotes the authority's reference for the early warning, and gives the initial assessment the early warning did not need.
Template. The header block, then these fields. Under each label: the point of NIS2 Article 23 it answers and the fact base fields it draws on.
Incident notification (RD-02) | |||
Changes since the early warning 23(4)(b) · FB-14 | [[What is new or different since the early warning, and any correction to it]] | ||
Malicious act and cross-border impact: now 23(4)(b) · FB-09, FB-07 | [[The early warning's two answers, confirmed or changed, with the reason]] | ||
Services affected 23(4)(b) · FB-05 | [[Which services, for whom, how badly and for how long: stopped, degraded or at risk]] | ||
Severity and impact 23(4)(b) · FB-06 | [[Initial assessment: our severity (P09) and the impact on service, data, money, legal and reputation; which significance indicators are met]] | ||
Systems and data affected 23(4)(b) · FB-08 | [[Systems, sites and data sets; the security property affected: availability, integrity, confidentiality, authenticity]] | ||
Indicators of compromise 23(4)(b) · FB-11 | [[File hashes, addresses, domains, accounts and techniques seen, where they can be shared / none available yet, and why]] | ||
Measures taken 23(4)(b) · FB-12 | [[Containment, eradication and recovery done, with times; what is still to do]] | ||
Recipients of our services told? 23(4)(b) · FB-13 | [[Yes: who, when, how and what we advised them / No, and why]] | ||
Not yet known | [[What is still being found out, and which report it will follow in]] | ||
Field guidance
Field | What to write, and how much; and if it is not yet known |
|---|---|
Changes since the early warning NIS2 23(4)(b) · FB-14 | Start with what has changed. Correct anything the early warning got wrong, and say it is a correction (RN-12). The authority's reference goes in the header. Not yet known: "No change" where nothing has. |
Malicious act and cross-border impact: now NIS2 23(4)(b) · FB-09, FB-07 | Both early warning answers again, as they now stand: confirmed, changed, or still not known. Not yet known: "Still not known", and when you expect to know. |
Services affected NIS2 23(4)(b) · FB-05 | Each service in the NIS2 sector: stopped, degraded or at risk, for whom, since when and until when. One line per service. Not yet known: Estimate, say it is an estimate, and how it was made. |
Severity and impact NIS2 23(4)(b) · FB-06 | Our severity and the impact on each P09 area, in one line each, and the significance indicators met (NS-01 to NS-06). This is the initial assessment the law asks for: it may change. Not yet known: Give a range for money ("between ... and ..."). Never leave the field empty. |
Systems and data affected NIS2 23(4)(b) · FB-08 | The systems, sites and data sets involved, and what happened to each: unavailable, altered, seen or taken, or no longer trustworthy. Not yet known: "Under investigation", and which systems are still being checked. |
Indicators of compromise NIS2 23(4)(b) · FB-11 | What others could search for: file hashes, network addresses, domains, sender addresses, attacker techniques. Attach a file if the list is long, and mark how it may be shared. Not yet known: "None available yet", and who is producing them. The law asks for them where available. |
Measures taken NIS2 23(4)(b) · FB-12 | What has been done, with times, and what is planned. Short lines, in time order. |
Recipients of our services told? NIS2 23(4)(b) · FB-13 | Whether customers whose service is likely to be adversely affected have been told (P09 RD-05), and what they were told to do. The notice itself is the communications lead's (RN-14). Not yet known: "Decision pending", and when it will be made. |
Not yet known Not asked by the law | The questions still open, usually the root cause and the cost. They belong in the final report. |
Before it goes. The checks every report needs, and these:
Before it goes | Rule | Done |
|---|---|---|
It quotes the early warning's reference and says what has changed | 23(4)(b) | ☐ |
It gives an initial assessment of severity and impact, and indicators of compromise or why there are none yet | 23(4)(b) | ☐ |
It says whether recipients of our services have been told | RD-05 | ☐ |
A trust service provider: it goes within the shorter clock for trust services | CN-12 | ☐ |
Intermediate report
A report of progress between the notification and the final report. Under NIS2 it is due only when the CSIRT or competent authority asks for one, and by the time it sets (RD-03). Log the request as a new due time at once (RN-10).
Template. The header block, then these fields. Under each label: the point of NIS2 Article 23 it answers and the fact base fields it draws on.
Intermediate report (RD-03) | |||
The authority's request 23(4)(c) · FB-14 | [[Date and time received; who asked; their reference; what was asked, question by question]] | ||
Status update 23(4)(c) · FB-14 | [[One answer per question, numbered as the request numbers them]] | ||
Other changes since the last report 23(4)(c) · FB-05, FB-06, FB-12 | [[Anything else the authority should know, and any correction / none]] | ||
Field guidance
Field | What to write, and how much; and if it is not yet known |
|---|---|
The authority's request NIS2 23(4)(c) · FB-14 | Quote the request: when it came, who sent it, its reference, and each question in its own words. |
Status update NIS2 23(4)(c) · FB-14 | Answer every question, in the request's order and numbering. Keep to what was asked; add other news in the next field. Not yet known: "Not yet known", why, and when the answer will follow. |
Other changes since the last report NIS2 23(4)(c) · FB-05, FB-06, FB-12 | News the authority did not ask for but needs: a change in impact, a new measure, a correction (RN-12). Not yet known: "None". |
Before it goes. The checks every report needs, and these:
Before it goes | Rule | Done |
|---|---|---|
It answers every question the authority asked, by the time it set | 23(4)(c) | ☐ |
Final report
The last report, once the cause and actual impact are known: under NIS2, within one month of the incident notification. (P09 RD-04.)
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. Use the same template: mark it as a progress report, give what is known, and complete the last field. Then send the final report on this template once handling ends (CN-03).
Template. The header block, then these fields. Under each label: the point of NIS2 Article 23 it answers and the fact base fields it draws on.
Final report (RD-04) | |||
Report type FB-04 | [[Final report: incident handling ended on date / Progress report: still being handled]] | ||
Detailed description 23(4)(d) · FB-03 | [[What happened from start to end, with the key times: start, detection, awareness, containment, recovery, closure]] | ||
Severity and impact: final 23(4)(d) · FB-05, FB-06 | [[Final figures: services affected and for how long; the impact on each area; cost so far]] | ||
Systems and data affected 23(4)(d) · FB-08 | [[Systems, sites and data sets, and what happened to each]] | ||
Type of threat or root cause 23(4)(d) · FB-10 | [[The type of threat, and the root cause found: how it got in, and why it could]] | ||
Mitigation applied 23(4)(d) · FB-12 | [[Each measure done, with its date]] | ||
Mitigation still under way 23(4)(d) · FB-12 | [[Each measure under way, with its owner and due date / none]] | ||
Cross-border impact 23(4)(d) · FB-07 | [[Final answer: none, or which Member States and how]] | ||
Progress report only | [[What is still being handled; when handling is expected to end; the final report within one month after that]] | ||
Field guidance
Field | What to write, and how much; and if it is not yet known |
|---|---|
Report type Not asked by the law · FB-04 | A final report if handling has ended; a progress report if it has not, at the same deadline (Article 23(4)(e)). Not yet known: If you cannot say whether handling has ended, it has not: send a progress report. |
Detailed description NIS2 23(4)(d) · FB-03 | The whole incident in time order, one or two short paragraphs. Use the case log's times. Not yet known: "Not established" for any time the investigation could not fix, such as when it started. |
Severity and impact: final NIS2 23(4)(d) · FB-05, FB-06 | The final figures for each area the notification gave, and the cost so far. Where a figure differs from an earlier report, say why (RN-11). Not yet known: Cost often is not final: give the figure so far and say it is. |
Systems and data affected NIS2 23(4)(d) · FB-08 | As in the notification, with the final answer for each. |
Type of threat or root cause NIS2 23(4)(d) · FB-10 | The threat type in words (ransomware, account takeover, a fault, a supplier failure) and the root cause from the post-incident review: the route in and why it was open. Not yet known: "Under investigation" means the incident is still being handled: send a progress report. |
Mitigation applied NIS2 23(4)(d) · FB-12 | Each measure taken, with its date, from containment to the review's completed actions. |
Mitigation still under way NIS2 23(4)(d) · FB-12 | Each measure not yet finished, with its owner's role and due date. |
Cross-border impact NIS2 23(4)(d) · FB-07 | The final answer, with the reason. |
Progress report only Not asked by the law | Only in a progress report: what remains, when handling should end, and that the final report follows within one month of it. Not yet known: Give the expected end as an estimate. |
Before it goes. The checks every report needs, and these:
Before it goes | Rule | Done |
|---|---|---|
Handling has ended; if not, this is a progress report and says when the final report will follow | 23(4)(e) | ☐ |
It gives the threat type or root cause, applied and ongoing mitigation, and cross-border impact | 23(4)(d) | ☐ |
Figures that differ from the notification say why | RN-11 | ☐ |
Notice to recipients of our services
Where appropriate, NIS2 asks us to tell the recipients of our services, without undue delay, of a significant incident likely to affect the service they receive (RD-05, Article 23(1)). Where the incident is also a significant cyber threat to them, we tell them the measures or remedies they can take (Article 23(2)). A significant cyber threat is a threat that could cause a significant incident but has not yet done so. NIS2 asks us to tell affected recipients what they can do about it.
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. For RD-05 the communications lead sends the notice, approved as P09's CT-04 customer notice by the executive incident lead. The incident notification then says who was told, when and what they were advised (FB-13).
What the notice must give: that a significant incident is likely to affect the service they receive from us, in plain words (23(1)); where the incident is also a significant cyber threat to them: the measures or remedies they can take (23(2)).
Template: a significant incident
Template | Notice of a significant incident (Article 23(1)) |
|---|---|
Sent by | Communications lead (RN-14) |
Approved by | Executive incident lead, as P09's CT-04 customer notice |
To | [[Customers whose service is likely to be adversely affected / customers potentially affected by the threat]] |
Channel | [[Email from a named account manager, or as the contract requires]] |
Subject | [[Organisation Name]]: an incident that may affect the [[service]] we provide to you |
Message | Dear [[Customer name]], We are writing to tell you about a security incident at [[Organisation Name]] that is likely to affect the [[service]] we provide to you. What it means for you: [[the effect on your service: stopped, slower or at risk; since when; how long we expect it to last]] What we are doing: [[the measures under way, in plain words]] What you can do: [[specific steps, or "nothing at present"]] Questions: [[named contact, phone and email]]. We will update you by [[time and date]]. [[Name]], [[role]] |
Template: a significant cyber threat
Use this where a threat could cause a significant incident at a recipient of our services but has not yet done so, and there is something they can do about it.
Template | Notice of a significant cyber threat (Article 23(2)) |
|---|---|
Sent by | Communications lead (RN-14) |
Approved by | Executive incident lead, as P09's CT-04 customer notice |
To | [[Customers whose service is likely to be adversely affected / customers potentially affected by the threat]] |
Channel | [[Email from a named account manager, or as the contract requires]] |
Subject | [[Organisation Name]]: a security threat to the [[service]] we provide, and what you can do |
Message | Dear [[Customer name]], We have learned of a security threat that could seriously affect the [[service]] we provide to you. It has not affected your service so far. The threat: [[what it is and how it could affect you, in plain words; leave out detail that would help an attacker]] What you can do: [[the measures or remedies you can take, step by step]] What we are doing: [[the measures we have taken or are taking]] Questions: [[named contact, phone and email]]. [[Name]], [[role]] |
Before it goes.
Before it goes | Rule | Done |
|---|---|---|
The communications lead sends it, from this template, approved as P09's customer notice | RN-14 | ☐ |
It says nothing that contradicts a report to the authority, and nothing that would help an attacker | RN-14 | ☐ |
It tells the customer what to do, in plain words | 23(2) | ☐ |
Guidance — delete before approval
Read the notice aloud before it is approved. If a customer who does not work in IT would not know what to do after reading it, rewrite it.
Check each customer's contract for its own notice terms (P09 RD-14). One notice can meet both duties if it meets the stricter of the two.
Worked example: the ransomware incident of 12 August
EXAMPLE. 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, an important entity under NIS2 in its Member State. At 07:50 on 12 Aug 2026 the security monitoring provider alerted on encryption activity at Warehouse 2. The incident manager declared Severity 1 at 08:25, and the reporting screen at 11:30 found a significant incident (DEC-2026-001). Three reports followed, each on time.
Report | Clock runs from | Due | Made | Margin |
|---|---|---|---|---|
Early warning (RD-01) | Awareness, 12 Aug 2026, 08:25 | 13 Aug 2026, 08:25 | 12 Aug 2026, 15:40 | 16 hours 45 minutes |
Incident notification (RD-02) | Awareness, 12 Aug 2026, 08:25 | 15 Aug 2026, 08:25 | 14 Aug 2026, 14:00 | 18 hours 25 minutes |
Final report (RD-04) | The incident notification, 14 Aug 2026, 14:00 | 14 Sep 2026, 23:59 | 11 Sep 2026, 12:00 | 3 days 11 hours 59 minutes |
Guidance — delete before approval
The distributor made these reports with P09's CT-06 before it adopted this pack on 15 Sep 2026. On adoption it entered them in the log and redrew them on these templates from P09's case log. That is why the header shows no Legal review or second-person check: neither was recorded at the time.
Technical values the facts do not hold, such as file hashes and the authority's reference, are left as [[placeholders]]. Delete this worked example from your adopted templates.
Early warning, 12 Aug 2026
Made 7 hours 15 minutes after awareness, with the incident contained but the cause unknown. It says only what the early warning needs.
Header: early warning — EXAMPLE | |||
Report stage, and P09's duty | Early warning (RD-01) | ||
Entity FB-01 | [[Organisation Name]], [[identifier the authority uses]]: an important entity under NIS2 in its Member State | ||
Contact at any hour FB-02 | [[Name]], Information Security Manager (incident manager), [[mobile, email]] | Deputy contact FB-02 | [[Name]], Head of Information Security, [[mobile, email]] |
Our reference P09 case number | INC-2026-014 | Authority's reference RN-09 | None yet: first report |
Due by P09's clock | 13 Aug 2026, 08:25 | ||
Reviewed by Legal (RN-07) | Not recorded: before this pack was adopted | Approved by RN-08 | [[Name]], Chief Operating Officer (executive incident lead) |
Checked by second person (RN-08) | Not recorded: before this pack was adopted | Submitted by a signatory | 12 Aug 2026, 15:40; [[Name]], Information Security Manager |
Channel | [[the national notification portal or address, from the national law or the CSIRT's website]] | Next report and when due (RN-10) | Incident notification (RD-02), due by 15 Aug 2026, 08:25 |
Early warning (RD-01) — EXAMPLE | |||
What has happened 23(4)(a) · FB-03 | 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. Contained at 13:50: 14 PCs isolated, no activity on any other site. | ||
Key times 23(4)(a) · FB-04 | Detected: 12 Aug 2026, 07:50, an alert from the security monitoring provider. Became aware: 12 Aug 2026, 08:25, when it was declared Severity 1. Contained: 12 Aug 2026, 13:50. | ||
Suspected unlawful or malicious act? 23(4)(a) · FB-09 | Yes. Ransomware encrypted files on the PCs. A crime report will be made to [[the national cybercrime reporting service]]. | ||
Could it have a cross-border impact? 23(4)(a) · FB-07 | Not known to be. The affected PCs are at one site, in [[Member State]], and ordering and dispatch, the services our customers use, are not affected. | ||
Not yet known | How the ransomware got in; whether any data was taken from the PCs; the indicators of compromise. They will follow in the incident notification. | ||
Help asked of the CSIRT 23(5) | None at present. | ||
After submission: CSIRT initial feedback received at 19:45 with an offer of malware analysis, which was declined (Article 23(5)). The authority acknowledged the report at 16:05.
Incident notification, 14 Aug 2026
Made after the personal data assessment of 10:00 on 14 Aug, so the notification could say what had happened to the data on the PCs. The header fields not shown are as in the early warning.
Header: incident notification — EXAMPLE | |||
Report stage, and P09's duty | Incident notification (RD-02) | ||
Authority's reference RN-09 | [[authority's reference]], returned for the early warning | ||
Due by P09's clock | 15 Aug 2026, 08:25 | ||
Approved by RN-08 | [[Name]], Chief Operating Officer (executive incident lead) | ||
Submitted by a signatory | 14 Aug 2026, 14:00; [[Name]], Information Security Manager | ||
Channel | [[the national notification portal or address, from the national law or the CSIRT's website]] | Next report and when due (RN-10) | Final report (RD-04), due by 14 Sep 2026, 23:59, or a progress report then if still being handled |
Incident notification (RD-02) — EXAMPLE | |||
Changes since the early warning 23(4)(b) · FB-14 | Crime reported at 17:10 on 12 Aug to [[the national cybercrime reporting service]]. CSIRT initial feedback received at 19:45 with an offer of malware analysis, which was declined: our security monitoring provider was already analysing the sample. Eradicated at 19:30 on 12 Aug; office work resumed on rebuilt PCs at 14:00 on 13 Aug. The personal data on the PCs was assessed at 10:00 on 14 Aug: restored from backup with nothing lost, and no sign of any data taken. | ||
Malicious act and cross-border impact: now 23(4)(b) · FB-09, FB-07 | Malicious act: confirmed. Ransomware, from an attachment to a phishing email; the email has been removed from every mailbox. Cross-border impact: none. Every affected PC is at one site in [[Member State]], and no customer, supplier or service in another Member State is affected. | ||
Services affected 23(4)(b) · FB-05 | Ordering and dispatch, the services our customers use, were not affected. Office work at Warehouse 2 stopped when its office network was cut off at 09:10 on 12 Aug and resumed on rebuilt PCs at 14:00 on 13 Aug: 28 hours 50 minutes. | ||
Severity and impact 23(4)(b) · FB-06 | Severity 1 (Critical) on our scale, set at declaration and unchanged. Impact by area: Service: Major; Data: Major; Spread: Severe; Financial: Moderate, loss likely between [[€50,000]] and [[€250,000]]; Legal and regulatory: Severe; Reputation: Moderate. Significant on indicator NS-04 (capability): 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. | ||
Systems and data affected 23(4)(b) · FB-08 | 14 office PCs on Warehouse 2's office network: files encrypted. The PCs held shipping records with customer names and delivery addresses, made unavailable; restored from backup with nothing lost, and the provider's analysis found no sign of any data taken. Assessed separately as a personal data breach unlikely to result in a risk to individuals. | ||
Indicators of compromise 23(4)(b) · FB-11 | [[Hashes of the ransomware file and of the phishing attachment; the phishing email's sender address and domain; the addresses the ransomware contacted]], from the security monitoring provider's analysis (SUP-006). | ||
Measures taken 23(4)(b) · FB-12 | 09:10 on 12 Aug: Warehouse 2's office network cut off from all other networks. 13:50 on 12 Aug: contained; 14 PCs isolated, no activity on any other site. 19:30 on 12 Aug: the phishing email removed from every mailbox, its sender and attachment blocked, and the affected user's and Warehouse 2 administrator passwords reset. 14:00 on 13 Aug: office work resumed on rebuilt PCs; backups checked before anything was restored. Now: 7 days' closer monitoring before the incident is closed. | ||
Recipients of our services told? 23(4)(b) · FB-13 | No. Ordering and dispatch were not affected, so no customer's service was likely to be adversely affected (P09 RD-05 not due). | ||
Not yet known | The cost, and the post-incident review of how the ransomware got in and why it could spread. Both will follow in the final report. | ||
Final report, 11 Sep 2026
The incident was closed on 21 Aug 2026, before the final report's deadline, so a final report went rather than a progress report. The root cause is the post-incident review's of 27 Aug 2026. The header fields not shown are as in the early warning.
Header: final report — EXAMPLE | |||
Report stage, and P09's duty | Final report (RD-04) | ||
Authority's reference RN-09 | [[authority's reference]], returned for the early warning | ||
Due by P09's clock | 14 Sep 2026, 23:59 | ||
Approved by RN-08 | [[Name]], Chief Operating Officer (executive incident lead) | ||
Submitted by a signatory | 11 Sep 2026, 12:00; [[Name]], Information Security Manager | ||
Channel | [[the national notification portal or address, from the national law or the CSIRT's website]] | Next report and when due (RN-10) | None: the last report |
Final report (RD-04) — EXAMPLE | |||
Report type FB-04 | Final report. Incident handling ended on 21 Aug 2026: the incident was closed after 7 days' monitoring without recurrence. | ||
Detailed description 23(4)(d) · FB-03 | 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. 12 Aug 2026, 07:50: Monitoring alert: encryption activity on one office PC at Warehouse 2. 12 Aug 2026, 08:25: Declared Severity 1, category IC-01 (awareness). 12 Aug 2026, 09:10: Warehouse 2 office network isolated. 12 Aug 2026, 13:50: Contained: 14 PCs isolated, no activity on any other site. 12 Aug 2026, 19:30: Eradicated: the phishing email removed from every mailbox, its sender and attachment blocked, and the affected user's and Warehouse 2 administrator passwords reset. 13 Aug 2026, 14:00: Office work resumes on rebuilt PCs; backups checked before restoring. 21 Aug 2026, 09:00: Closed after 7 days' monitoring without recurrence. | ||
Severity and impact: final 23(4)(d) · FB-05, FB-06 | Severity 1 (Critical), unchanged throughout. Impact by area: Service: Major; Data: Major; Spread: Severe; Financial: Moderate, loss likely between [[€50,000]] and [[€250,000]]; Legal and regulatory: Severe; Reputation: Moderate. Contained 6 hours after detection. About 1.5 days of lost office work; no data taken, as far as we know. Ordering and dispatch were not affected at any time. Cost so far: [[Cost from Finance: the managed IT provider's rebuild time, overtime and lost office work]]. | ||
Systems and data affected 23(4)(d) · FB-08 | 14 office PCs on Warehouse 2's office network, rebuilt. Shipping records on them were restored from backup with nothing lost; no data was found to have been taken. | ||
Type of threat or root cause 23(4)(d) · FB-10 | Threat type: ransomware (IC-01, ransomware or destructive malware), delivered by a phishing email. Root cause, from the post-incident review of 27 Aug 2026: a phishing attachment opened by a warehouse office user whose account had local administrator rights. That site's office network was not yet separated, so it spread to 14 PCs. | ||
Mitigation applied 23(4)(d) · FB-12 | 09:10 on 12 Aug: Warehouse 2's office network cut off; 13:50 on 12 Aug: contained. 19:30 on 12 Aug: the phishing email removed from every mailbox, its sender and attachment blocked, and the affected user's and Warehouse 2 administrator passwords reset. 14:00 on 13 Aug: office PCs rebuilt; backups checked before restoring. 20 Aug 2026: Reassess the risk of ransomware spreading to warehouse systems. 10 Sep 2026: Give the monitoring provider's out-of-hours analysts a direct line to the incident manager. 11 Sep 2026: Finish separating the warehouse networks from the office network at all three sites. | ||
Mitigation still under way 23(4)(d) · FB-12 | Remove local administrator rights from all office PCs: Head of IT, due 31 Oct 2026. Add site isolation steps for each warehouse to the Ransomware Response Playbook: Information Security Manager, due 25 Sep 2026. | ||
Cross-border impact 23(4)(d) · FB-07 | None. Every affected system was at one site in [[Member State]], and no customer, supplier or service in another Member State was affected. | ||
Progress report only | Not applicable: this is a final report. | ||
Submission record
What the signatory entered in the Regulatory Notification Log for each report (RN-09, RN-10).
Record | Report | Due | Submitted | By | Acknowledged | Next due |
|---|---|---|---|---|---|---|
SB-2026-001 | Early warning (RD-01) | 13 Aug 2026, 08:25 | 12 Aug 2026, 15:40 | Information Security Manager | 12 Aug 2026, 16:05 | RD-02: 15 Aug 2026, 08:25 |
SB-2026-002 | Incident notification (RD-02) | 15 Aug 2026, 08:25 | 14 Aug 2026, 14:00 | Information Security Manager | 14 Aug 2026, 14:20 | RD-04: 14 Sep 2026, 23:59 |
SB-2026-003 | Final report (RD-04) | 14 Sep 2026, 23:59 | 11 Sep 2026, 12:00 | Information Security Manager | 11 Sep 2026, 12:30 | — |
What the distributor did not need to send
- Intermediate report (RD-03): the CSIRT did not ask for one.
- Progress report: handling ended on 21 Aug 2026, before the final report fell due on 14 Sep 2026, 23:59.
- Notice to recipients of our services (RD-05): ordering and dispatch were not affected, so no customer's service was likely to be adversely affected. The notification says so.
The distributor also told its cyber insurer and reported the crime (P09 RD-15 and RD-16). Those notices have no NIS2 template.
Related documents
Document | Relationship |
|---|---|
EU Incident Notification Timeline Matrix (NIS2, DORA, GDPR) | Every reporting duty side by side, with its trigger, clock and recipient |
Reportability Decision Model | Whether an incident is significant (NS-01 to NS-06), and the decision that starts these reports |
Regulatory Notification Operating Procedure | The rules these templates apply: RN-07 to RN-14 |
Regulatory Notification Log | Where each decision, report, reference and next due time is recorded |
Notification Readiness Checklist | The checks that the authority, channel, signatories and these templates are ready |
Incident Classification, Severity & Escalation Matrix | The duties RD-01 to RD-05 and their deadlines |
Incident Communications Template Set | CT-06, which these templates expand, and CT-04, the customer notice |
NIS2 Competent Authority Registration Data Sheet | The details the authority holds about us, which the header must match |
Adapting this template
Guidance — delete before approval
Small organisation: one person may draft, approve and submit. Keep the header, the fields and the check, and name a deputy who can reach the portal (PF-02). A report made by one person on time is better than one held for a second signature.
The authority's own form: where the CSIRT's portal asks its own questions, reorder and rename these fields to match it, and keep the fact base references. Add any field national law adds ([[any duty or field the national law adds to the Directive]]).
Trust service provider: change the incident notification's due time to 24 hours from awareness (CN-12) in the clocks table and the log.
Regulated financial entities: these templates are for NIS2 reports only. A financial entity reports major ICT-related incidents on its own regime's template and clocks, set out in the EU Incident Notification Timeline Matrix (NIS2, DORA, GDPR) and the Regulatory Notification Operating Procedure.
IT run by a service provider: the provider often holds the indicators of compromise and the technical timeline. Its contract should require it to give them in time for the notification (P06 CL-07).
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).
Framework | Reference | Supported by |
|---|---|---|
ISO/IEC 27001:2022 | Annex A 5.5 — Contact with authorities | The whole document: prepared content, contacts and channel for reporting to the authority |
ISO/IEC 27001:2022 | Clause 7.4 — Communication | The header, stages and notices: what is communicated, when, to whom, by whom and how |
NIST CSF 2.0 | RS.CO-02 — “Internal and external stakeholders are notified of incidents” | The reports and the notice: the authority and recipients of our services notified |
NIST CSF 2.0 | RS.CO-03 — “Information is shared with designated internal and external stakeholders” | The incident notification and final report: indicators of compromise and status shared with the authority |
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 | Notice to recipients of our services; the reports to the CSIRT or competent authority |
NIS2 — Directive (EU) 2022/2555 | Article 23(2) — where applicable, communicate without undue delay to the recipients of the services potentially affected by a significant cyber threat any measures or remedies they can take in response; where appropriate, also inform them of the threat itself | The significant cyber threat notice: measures or remedies recipients can take |
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 four stages and their clocks |
NIS2 — Directive (EU) 2022/2555 | Article 23(4)(a) — “without undue delay and in any event within 24 hours of becoming aware of the significant incident, an early warning”, which where applicable indicates whether the incident is suspected of being caused by unlawful or malicious acts or could have a cross-border impact | The early warning template |
NIS2 — Directive (EU) 2022/2555 | Article 23(4)(b) — “without undue delay and in any event within 72 hours of becoming aware of the significant incident, an incident notification”, which where applicable updates the early warning and gives an initial assessment of the incident, including its severity and impact, and, where available, the indicators of compromise | The incident notification template |
NIS2 — Directive (EU) 2022/2555 | Article 23(4)(c) — “upon the request of a CSIRT or, where applicable, the competent authority, an intermediate report on relevant status updates” | The intermediate report template |
NIS2 — Directive (EU) 2022/2555 | Article 23(4)(d) — a final report not later than one month after the incident notification, including: (i) a detailed description of the incident, including its severity and impact; (ii) the type of threat or root cause likely to have triggered it; (iii) applied and ongoing mitigation measures; (iv) where applicable, its cross-border impact | The final report template |
NIS2 — Directive (EU) 2022/2555 | Article 23(4)(e) — if the incident is still ongoing when the final report is due, a progress report at that time and a final report within one month of the entity’s handling of the incident | The progress report variant of the final report |
NIS2 — Directive (EU) 2022/2555 | Article 23(4), second subparagraph — by derogation from point (b), a trust service provider notifies significant incidents that have an impact on the provision of its trust services “without undue delay and in any event within 24 hours of becoming aware of the significant incident” | The trust service provider's shorter notification clock |
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” | What a significant cyber threat is, for the threat notice |
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 | The early warning's field for help asked of the CSIRT, and its feedback |
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 these templates |
|---|---|
Authority's reference | The case or reference number the authority returns for a report. Every later report for the same incident quotes it. |
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. |
CSIRT | Computer security incident response team: the national team that receives NIS2 reports in many Member States. In others the competent authority receives them. |
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). |
Early warning | NIS2's first report, within 24 hours of awareness. It says whether the incident is suspected to be unlawful or malicious, and whether it could have a cross-border impact. |
Fact base | The one record of the incident's facts that every report is drafted from, so reports to different authorities agree (RN-11). |
Final report | The last report, once the cause and actual impact are known: under NIS2, within one month of the incident notification. |
Incident notification | NIS2's second report, within 72 hours of awareness. It updates the early warning with an initial assessment of severity and impact and any indicators of compromise. |
Intermediate report | Under NIS2, a report on relevant status updates, made when the CSIRT or competent authority asks for one. |
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). |
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. |
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 cyber threat | A threat that could cause a significant incident but has not yet done so. NIS2 asks us to tell affected recipients what they can do about it. |
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. |
Trust service provider | A provider of trust services such as electronic signatures, seals and time stamps. NIS2 gives it a shorter clock for the incident notification. |