Incident Communications Template Set
Pre-drafted internal, executive, customer and supplier messages for each severity level with approval routing.
Available soon
- Format
- Word
- Size
- 73 KB
- Length
- 26 pages
- Version
- 1.1
- Updated
What's inside
What changed
- 1.1
RD-10 now states DORA's rule for an incident classified as major only after 24 hours: the initial notification is due within 4 hours of that classification (Delegated Regulation (EU) 2025/301, Article 5(2)).
- 1.0
Published.
Preview
The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.
Purpose and audience
What an organisation says during an incident is judged as closely as what it does. This template set gives [[Organisation Name]] ten messages, CT-01 to CT-10, drafted and approved before they are needed, so that in an incident the communications lead fills in facts instead of writing from a blank page, every message goes through the right approver, and nothing is said outside that has not been checked.
It serves the Incident Response Plan, which sets the roles and the phases of a response, and the Incident Classification, Severity & Escalation Matrix, which sets severity, escalation times and the reporting clocks. The three playbooks — the Ransomware Response Playbook, the Business Email Compromise Response Playbook and the Personal Data Breach Response Playbook — name the messages each scenario needs by their CT numbers. Every message sent is recorded in the message approval log below and in the Incident Case & Action Log.
Reader | What they use |
|---|---|
Communications lead | All ten messages, the principles, and the approval log |
Incident manager | CT-01 and CT-02, which they send; the facts sheet, which they keep current; CT-05 |
Executive incident lead | Approves CT-03, CT-04 and CT-06 to CT-10 |
Data Protection Officer | Approves CT-07 and CT-08 with the executive incident lead |
Legal | Reviews CT-04, CT-08 and CT-09 before first use, and any message that could admit liability |
The messages at a glance
Audience, timing and approver are fixed in the pack's shared facts, so that the plan, the playbooks and this set agree.
Message | Audience | When | Approver |
|---|---|---|---|
CT-01 Incident alert to the response team | Incident manager, responders, executive incident lead | At declaration | Incident manager |
CT-02 Executive and board briefing | Executive incident lead, crisis team, board chair | Severity 1 and 2, at each update | Incident manager |
CT-03 Staff holding message | All staff, or the affected site or team | When staff notice the effects | Executive incident lead |
CT-04 Customer notice | Customers whose service or data is affected | When a customer's service is affected or a contract requires it | Executive incident lead |
CT-05 Supplier notice and request for help | Suppliers involved in the incident or the recovery | When a supplier must act or be warned | Incident manager |
CT-06 NIS2 early warning and notification content | [[CSIRT or competent authority]] | RD-01 to RD-04 | Executive incident lead |
CT-07 GDPR notification to the supervisory authority | [[lead supervisory authority]] | RD-06 | Executive incident lead, with the Data Protection Officer |
CT-08 Communication to individuals affected | Data subjects | RD-07 | Executive incident lead, with the Data Protection Officer |
CT-09 Media holding statement | Press and public | When the incident is, or is about to be, public | Executive incident lead |
CT-10 All-clear and thank-you | Everyone told earlier | At closure | Executive incident lead |
Which messages each severity normally needs
Severity is set with the Incident Classification, Severity & Escalation Matrix. Messages to authorities and individuals (CT-06, CT-07, CT-08) follow the reporting screen, not the severity: the screen is complete within 4 hours of declaration (IM-06).
Severity | Messages normally used | Internal updates |
|---|---|---|
Severity 1 (Critical) | CT-01, CT-02, CT-03, CT-04, CT-05, CT-09, CT-10 | Every 2 hours until contained |
Severity 2 (High) | CT-01, CT-02, CT-03, CT-04, CT-05, CT-10 | Every 4 hours until contained |
Severity 3 (Medium) | CT-01, CT-05, CT-10 | Every 24 hours |
Severity 4 (Low) | CT-01, CT-10 | In the weekly summary |
Guidance — delete before approval
Approve this whole set once a year, and after any change of approver, so that in an incident only the facts need approval. The approver of each message still approves each version sent.
Keep a printed copy, and a copy outside your own email and file systems. A ransomware incident can take both away at the moment you need the templates most.
The EXAMPLE messages are for a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders. The organisation, people and figures are fictional.
Who may speak for us
IM-09 Only the communications lead may speak for the organisation about an incident outside it, using the approved templates; nobody else may talk to the media or post about an incident.
The decision right is recorded in the Incident Response Plan: Say anything outside the organisation — Communications lead, with the executive incident lead's approval. Only from the approved templates (IM-09).
In practice this means:
- Only the communications lead, or a spokesperson they name for the incident, speaks to the press, posts on social media or answers questions from outside.
- Messages to authorities (CT-06, CT-07) are submitted by the incident manager or the Data Protection Officer, but the text is approved as the table above sets out, and logged.
- Everyone else who is asked about the incident — by a customer, a supplier, a journalist or a friend — says they cannot comment and passes the question to the communications lead. CT-03 tells staff this in writing.
- Suppliers and outside responders do not speak about our incident. The contract clauses in the P06 clause library, and CT-05, say so.
Guidance — delete before approval
Name the communications lead and a deputy: [[e.g. Head of Marketing and Communications]]. In a small organisation this is often the managing director; the rule is the same.
Tell staff once a year, and in induction, that they must not talk or post about an incident. The first time they hear it should not be in the middle of one.
Principles for every message
Each message answers five questions, in this order:
Say | Why |
|---|---|
What we know | Facts only: what happened, where and since when. A short true message is better than a long guess. |
What we do not know yet | Saying so is honest, and stops people filling the gap with speculation. It also stops you having to take a statement back. |
What we are doing | The actions in progress, in plain words. |
What people should do | The one or two things the reader must do or not do. For staff and individuals this is the most important part. |
When we will update next | A time, and keep it. Silence after a promised update does more harm than an update that says little. |
And six things every message avoids
- Speculation on cause or attacker. Do not name or guess at who is responsible, or how they got in, until the investigation shows it. Early theories are often wrong.
- Admission of liability. Say sorry for what happened; do not accept legal responsibility, promise compensation or describe a failure as negligence without legal review.
- Jargon. Write for a reader who does not work in IT. "Malicious software that locked files", not "a ransomware payload executed".
- Detail that helps an attacker. Do not describe which defences failed or which systems are still weak.
- Minimising. "A minor technical issue" about a security incident will be quoted back when the truth comes out.
- Contradiction. Every message draws on one source of truth: the facts sheet the incident manager keeps current. A figure changes in the facts sheet first, then in every message after it.
Guidance — delete before approval
If your organisation has a style guide or a tone of voice, apply it to the templates now, before approval. In an incident there is no time for it.
The message set
Each message below has when to use it, its audience, approver and channel, the template text with [[placeholders]], and its dos and don'ts. Placeholders that repeat — the case number, the time of declaration, the next update — come from the facts sheet.
CT-01 Incident alert to the response team
Send it at declaration, before anything else: it is how the team learns there is an incident, and the time of declaration it carries starts every reporting clock (see awareness, in the definitions).
Template. Replace every placeholder; delete any line that does not apply.
Template | CT-01 Incident alert to the response team |
|---|---|
When to use | At declaration |
Audience | Incident manager, responders, executive incident lead |
Approver | Incident manager |
Channel | [[Incident chat channel and a call to each person; phone for Severity 1 and 2 out of hours]] |
Subject | [[Severity n]] incident declared: [[case number]] — [[short title, e.g. Malware on office PCs at one site]] |
Message | Declared at [[date and time of declaration]] by [[Name]], Incident manager. The reporting clocks started at that time. What we know: [[What has happened, in two or three sentences of fact: what, where, since when]] What we do not know yet: [[What we do not know yet, e.g. how it started, whether any data was taken]] Severity and category: [[Severity n]]; [[category, e.g. IC-01 Ransomware or destructive malware]]. What I need from you now: [[What each person must do now, by name or role]] Where we work: [[call link or room, and the incident chat channel]]. Everything done and decided goes in the case log. Keep this within the response team. Nobody speaks or posts about this incident outside the organisation unless the communications lead has approved it (IM-09). Next update: [[time and date of the next update]]. [[Name]], Incident manager |
Dos and don'ts
Do | Don't |
|---|---|
Send it within minutes of declaration, even if it says little. The time of declaration in it is the start of every clock. | Wait for the full picture before alerting the team. |
Name each person's first task. | Forward it outside the response team, or copy in suppliers — they get CT-05. |
CT-02 Executive and board briefing
For Severity 1 and 2, at every update: every 2 hours for Severity 1 and every 4 hours for Severity 2 until contained. The first briefing to the executive incident lead is due within 30 minutes of declaration for Severity 1 and 2 hours for Severity 2; for Severity 1, the board chair or equivalent is briefed within 4 hours (IM-05).
Template. Replace every placeholder; delete any line that does not apply.
Template | CT-02 Executive and board briefing |
|---|---|
When to use | Severity 1 and 2, at each update |
Audience | Executive incident lead, crisis team, board chair |
Approver | Incident manager |
Channel | [[Email to the named list, and read out at the start of each crisis team call]] |
Subject | [[case number]] briefing [[n]]: [[Severity n]] — [[short title, e.g. Malware on office PCs at one site]] — [[Contained / Not yet contained / Recovering]] |
Message | Situation: [[What has happened, in two or three sentences of fact: what, where, since when]] Impact: [[Service, data, money, legal and reputation, each in one line: what has happened and what could]] What we are doing: [[What we are doing now, e.g. the affected systems are cut off and being checked]] What we do not know yet: [[What we do not know yet, e.g. how it started, whether any data was taken]] Reporting: [[Each duty from the reporting screen: decided or not, deadline, done or when due]] Decisions needed from you: [[Decisions needed from the executive or the board, each with the option recommended and by when — or "none"]] Next briefing: [[time and date of the next update]]. [[Name]], Incident manager |
Dos and don'ts
Do | Don't |
|---|---|
Lead with the decisions needed and their deadlines. | Bury a reporting deadline in the detail. |
Say what changed since the last briefing, and whether severity went up or down, with the reason. | Present guesses about the cause or the attacker as facts. |
CT-03 Staff holding message
When staff will notice the effects — systems they cannot use, colleagues pulled away, a site cut off — or will hear about the incident from outside. Staff who are not told fill the gap with rumour, and some of it reaches customers and social media.
Template. Replace every placeholder; delete any line that does not apply.
Template | CT-03 Staff holding message |
|---|---|
When to use | When staff notice the effects |
Audience | All staff, or the affected site or team |
Approver | Executive incident lead |
Channel | [[Email to the affected staff, the site noticeboard, and team leaders' briefings for staff without email]] |
Subject | Please read: a security incident affecting [[the systems, site or team affected]] — what to do |
Message | Dear colleagues, We are dealing with a security incident affecting [[the systems, site or team affected]]. [[What has happened, in two or three sentences of fact: what, where, since when]] What this means for you: [[What this means for staff: what they can and cannot use]] What to do: [[What to do, e.g. use the paper process; switch nothing off; report anything unusual]] What not to do: do not [[what not to do, e.g. log on to an office PC at the site, or plug in a USB drive]]. Do not talk about the incident outside the organisation or post about it. If a customer, supplier, journalist or anyone else asks, say you cannot comment and pass them to [[Name]], Communications lead. If you notice anything unusual, report it at once to [[the IT service desk, phone and email]]. Nobody is blamed for a report made in good faith. We will update you by [[time and date of the next update]]. [[Name]], Executive incident lead |
Dos and don'ts
Do | Don't |
|---|---|
Tell staff what to do and what not to do, in that order. | Call it "a technical glitch" when it is a security incident: staff find out, and trust goes. |
Reach staff without email — the site noticeboard and team leaders. | Include technical detail that would help an attacker, or blame a colleague. |
CT-04 Customer notice
When a customer's service is affected, a contract requires notice (RD-14), or NIS2 requires recipients of our services to be told (RD-05). Where we process personal data for a customer as its processor, this message is also our notice to the controller (RD-09: without undue delay); give the content of GDPR Article 33(3) so that the customer can make its own notification.
Template. Replace every placeholder; delete any line that does not apply.
Template | CT-04 Customer notice |
|---|---|
When to use | When a customer's service is affected or a contract requires it |
Audience | Customers whose service or data is affected |
Approver | Executive incident lead |
Channel | [[Email from a named account manager or the customer service mailbox; letter where the contract requires]] |
Subject | [[Organisation Name]]: a security incident that [[affects your service / may affect information we hold about you or your organisation]] |
Message | Dear [[Customer name]], We are writing to tell you about a security incident at [[Organisation Name]] that [[affects your service / may affect information we hold about you or your organisation]]. What happened: [[What has happened, in two or three sentences of fact: what, where, since when]] What it means for you: [[What it means for the customer: service effect and any data involved, in plain terms]] What we are doing: [[What we are doing now, e.g. the affected systems are cut off and being checked]] What we ask you to do: [[What the customer should do, e.g. watch for unexpected emails appearing to come from us — or "nothing at present"]] Questions: [[named contact, email and phone]]. We will update you by [[time and date of the next update]]. [[Name]], Executive incident lead |
Dos and don'ts
Do | Don't |
|---|---|
Say plainly what it means for this customer and what they should do. | Admit liability or promise compensation without legal review. |
Check each customer's contract for notice terms and deadlines (RD-14). | Send the same text to every customer when their exposure differs. |
CT-05 Supplier notice and request for help
When a supplier must act — isolate, preserve logs, restore, suspend accounts — or must be warned because the incident may reach it. The contract clauses on incident notice and cooperation are in the P06 Supplier Contract Security Clause Library (CL-07 and CL-11).
Template. Replace every placeholder; delete any line that does not apply.
Template | CT-05 Supplier notice and request for help |
|---|---|
When to use | When a supplier must act or be warned |
Audience | Suppliers involved in the incident or the recovery |
Approver | Incident manager |
Channel | [[Email to the supplier's security contact in the contract schedule, followed by a call]] |
Subject | Security incident [[case number]]: action needed by [[time and date]] |
Message | Dear [[Supplier contact name]], We are responding to a security incident that involves [[the service or systems the supplier provides or supports]]. What we know: [[What has happened, in two or three sentences of fact: what, where, since when]] What we need you to do: [[What the supplier must do, e.g. preserve and send the logs for these accounts from this date]], by [[time and date]]. We ask for this under the incident cooperation terms of our contract [[clause reference, e.g. the clause based on P06 CL-11]]. If you cannot do it by then, tell us at once what you can do and when. If you find anything that suggests the incident has reached your own systems, tell us within the time our contract sets [[e.g. the clause based on P06 CL-07]]. Please treat this message and the incident as confidential, and do not contact our customers, the press or any authority about it without talking to us first. Our contact: [[Name]], Incident manager, [[email and phone]]. |
Dos and don'ts
Do | Don't |
|---|---|
Ask for something specific, by a time, under a named clause. | Share more about the incident than the supplier needs to act. |
Follow the email with a call to the named security contact. | Assume the supplier's service desk will pass it on. |
CT-06 NIS2 early warning and notification content
For an essential or important entity, when the reporting screen finds a significant incident: the early warning (RD-01, within 24 hours of awareness), the incident notification (RD-02, within 72 hours of awareness), an intermediate report on request (RD-03) and the final report (RD-04): within one month of the incident notification (a progress report then, and the final report within one month of handling, if still ongoing). The same template is used for each stage; each adds to the last.
What each stage must contain (NIS2 Article 23(4)). The authority's own form decides the layout; this is the minimum content.
Stage | Point | Content |
|---|---|---|
Early warning (RD-01) | 23(4)(a) | Whether the significant incident is suspected of being caused by unlawful or malicious acts |
Early warning (RD-01) | 23(4)(a) | Whether it could have a cross-border impact |
Incident notification (RD-02) | 23(4)(b) | An update of the information in the early warning, where appropriate |
Incident notification (RD-02) | 23(4)(b) | An initial assessment of the incident, including its severity and impact |
Incident notification (RD-02) | 23(4)(b) | Indicators of compromise, where available |
Intermediate report (RD-03) | 23(4)(c) | Relevant status updates, on the request of the CSIRT or competent authority |
Final report (RD-04) | 23(4)(d)(i) | A detailed description of the incident, including its severity and impact |
Final report (RD-04) | 23(4)(d)(ii) | The type of threat or root cause that is likely to have triggered the incident |
Final report (RD-04) | 23(4)(d)(iii) | Applied and ongoing mitigation measures |
Final report (RD-04) | 23(4)(d)(iv) | Where applicable, the cross-border impact of the incident |
Guidance — delete before approval
DORA financial entities: do not use CT-06. A financial entity reports a major ICT-related incident to its financial competent authority on the template of Implementing Regulation (EU) 2025/302 — the Annex I template is used for the initial notification, the intermediate report and the final report — on the DORA clocks: RD-10 (within 4 hours of classifying the incident as major, and no later than 24 hours after awareness; where it is classified as major only after those 24 hours, within 4 hours of that classification), RD-11 (within 72 hours of the initial notification, and again when regular activities are recovered) and RD-12 (no later than one month after the latest intermediate report). Clients whose financial interests are affected are told under RD-13, using CT-04.
Your Member State's law and your CSIRT's or competent authority's form may ask for more than Article 23(4). Confirm the form, the portal and any national additions with counsel and the authority before you need them, and record them here.
Template. The content to prepare, field by field.
Template | CT-06 NIS2 early warning and notification content |
|---|---|
When to use | RD-01 to RD-04 |
Audience | [[CSIRT or competent authority]] |
Approver | Executive incident lead |
Channel | [[The CSIRT's or competent authority's reporting platform or form]] |
Stage | [[Early warning (RD-01) / Incident notification (RD-02) / Intermediate report (RD-03) / Final report (RD-04)]] |
Entity | [[Organisation Name]]; [[essential or important entity; sector and sub-sector under NIS2 Annex I or II]] |
Contact | [[Name]], Incident manager, [[email and phone]] |
Our reference | [[case number]] |
Became aware | [[date and time of declaration]] |
What happened | [[What has happened, in two or three sentences of fact: what, where, since when]] |
Suspected unlawful or malicious act? (23(4)(a)) | [[Yes / No / Not yet known — and why, in one line]] |
Possible cross-border impact? (23(4)(a)) | [[Yes / No / Not yet known — which Member States, and why]] |
Initial assessment: severity and impact (23(4)(b)) | [[Early warning: not required. Notification: severity, the services affected, how many users, for how long, and the financial effect estimated]] |
Indicators of compromise, where available (23(4)(b)) | [[Early warning: not required. Notification: file hashes, domains and addresses seen, where available]] |
Measures taken | [[What we are doing now, e.g. the affected systems are cut off and being checked]] |
Help asked of the CSIRT | [[Any support we ask of the CSIRT, or "none at present"]] |
Next report | [[the next report and its deadline]] |
Dos and don'ts
Do | Don't |
|---|---|
Send the early warning on time with what is known: it can be short. | Hold the early warning back to wait for facts; later stages add them. |
Keep each stage's submission, and the platform's receipt, in the case log. | Use CT-06 if you are a DORA financial entity: use the template of Implementing Regulation (EU) 2025/302. |
CT-07 GDPR notification to the supervisory authority
When the reporting screen finds a personal data breach that is not unlikely to result in a risk to individuals (RD-06: without undue delay and, where feasible, within 72 hours of awareness; later only with reasons for the delay). A breach that is unlikely to result in a risk is recorded (RD-08) and not notified. The Personal Data Breach Response Playbook sets out the risk assessment.
What the notification must contain at least (GDPR Article 33(3)). Where not everything is known, send what is and say what will follow: information may be provided in phases without undue further delay (33(4)). A notification made after 72 hours gives the reasons for the delay (33(1)).
Point | Content |
|---|---|
33(3)(a) | The nature of the breach, including where possible the categories and approximate number of people concerned, and the categories and approximate number of personal data records concerned |
33(3)(b) | The name and contact details of the Data Protection Officer, or another contact point where more information can be obtained |
33(3)(c) | The likely consequences of the breach |
33(3)(d) | The measures taken or proposed to deal with the breach, including, where appropriate, measures to reduce its possible adverse effects |
Guidance — delete before approval
Most supervisory authorities have their own online form. Use it, and use this template to prepare the answers and to keep a copy. Confirm the authority's form, and any national rules, with counsel and the authority before you need them.
Never paste the personal data itself into the notification: describe its categories and numbers.
Template. The content to prepare, field by field.
Template | CT-07 GDPR notification to the supervisory authority |
|---|---|
When to use | RD-06 |
Audience | [[lead supervisory authority]] |
Approver | Executive incident lead, with the Data Protection Officer |
Channel | [[The supervisory authority's online breach notification form]] |
Controller | [[Organisation Name]], [[registered address]] |
Contact point (33(3)(b)) | [[Name]], Data Protection Officer, [[email and phone]] |
Our reference | [[case number]] |
When the breach happened | [[date and time, or the period]] |
When we became aware | [[date and time of declaration]] |
Reasons for any delay beyond 72 hours (33(1)) | [[Not applicable: notified within 72 hours / the reasons]] |
Nature of the breach (33(3)(a)) | [[Confidentiality / integrity / availability breach: what happened, in two or three sentences]] |
People concerned: categories and approximate number (33(3)(a)) | [[e.g. customers who are individuals; approximately n]] |
Records concerned: categories and approximate number (33(3)(a)) | [[e.g. names, addresses, order histories; approximately n records]] |
Likely consequences (33(3)(c)) | [[What could happen to the people concerned, and how likely]] |
Measures taken or proposed (33(3)(d)) | [[What we have done to contain it and reduce the harm, and what we will do to stop it recurring]] |
Individuals told? (Article 34) | [[Yes, on date, by what means / No, and why: not a high risk, or the Article 34(3) condition that applies]] |
Other authorities or Member States involved | [[None / the authorities and why]] |
Further information to follow? (33(4)) | [[No / Yes: what is still to come, and when]] |
Dos and don'ts
Do | Don't |
|---|---|
Notify within 72 hours of awareness with what is known, and say what will follow (33(4)). | Wait to know everything before notifying. |
Have the Data Protection Officer check the risk assessment and the text. | Put names or personal data of the people concerned in the notification. |
CT-08 Communication to individuals affected
When the breach is likely to result in a high risk to individuals (RD-07: without undue delay), unless an Article 34(3) condition is met. The Personal Data Breach Response Playbook sets out the assessment and the conditions.
What the communication must contain (GDPR Article 34(2)). It describes the nature of the breach in clear and plain language and gives at least the content of Article 33(3)(b), 33(3)(c) and 33(3)(d):
- 33(3)(b) The name and contact details of the Data Protection Officer, or another contact point where more information can be obtained
- 33(3)(c) The likely consequences of the breach
- 33(3)(d) The measures taken or proposed to deal with the breach, including, where appropriate, measures to reduce its possible adverse effects
Guidance — delete before approval
Read the letter aloud before it is approved. If a sentence would confuse a relative who does not work in IT, rewrite it.
Where writing to each person would involve disproportionate effort, Article 34(3)(c) allows a public communication instead, as effective as a letter. Take legal advice first, and record the decision in the breach record.
Template. Replace every placeholder; delete any line that does not apply.
Template | CT-08 Communication to individuals affected |
|---|---|
When to use | RD-07 |
Audience | Data subjects |
Approver | Executive incident lead, with the Data Protection Officer |
Channel | [[Email or letter to each person; a public notice only under Article 34(3)(c)]] |
Subject | Important: information about you held by [[Organisation Name]] |
Message | Dear [[Name]], We are writing to tell you that [[in plain words, e.g. on 9 September we sent a file with some of your details to another business by mistake]]. We are sorry that this happened. What information was involved: [[the kinds of information, e.g. your name, delivery address and what you ordered; say also what was not involved, e.g. no payment details]] What this could mean for you: [[what could happen, honestly and without alarm, e.g. you could receive unexpected contact from someone pretending to be us]] What we have done: [[what we did, e.g. the business confirmed in writing it deleted the file; we have changed how we send files]] What you can do: [[specific steps, e.g. be wary of emails or calls about your orders that you did not expect; we will never ask for your password]] Questions: our Data Protection Officer, [[Name]], Data Protection Officer, [[email and phone]]. You also have the right to complain to [[the supervisory authority, with its contact details]]. [[Name]], Executive incident lead |
Dos and don'ts
Do | Don't |
|---|---|
Write in clear and plain language, as for a letter to a relative (34(2)). | Use legal or technical terms, or play down what happened. |
Give specific steps people can take, and a named contact who can answer. | Hold it back to wait for the authority's view: "without undue delay" runs from awareness, and people may need to protect themselves now. |
CT-09 Media holding statement
When the incident is public, or about to be: a journalist has called, customers are posting about it, or a notice to many customers will make it public. Prepare it at the start of every Severity 1 incident, so it is ready.
Template. Replace every placeholder; delete any line that does not apply.
Template | CT-09 Media holding statement |
|---|---|
When to use | When the incident is, or is about to be, public |
Audience | Press and public |
Approver | Executive incident lead |
Channel | [[Read or sent to a journalist on request; posted on the website only on the executive incident lead's decision]] |
Subject | Statement from [[Organisation Name]], [[date and time]] |
Message | [[Organisation Name]] is dealing with a security incident affecting [[the systems, site or team affected]], which we identified on [[date and time of declaration]]. [[What we are doing now, e.g. the affected systems are cut off and being checked]] [[What customers need to know, e.g. ordering and deliveries are working normally]] We have informed [[the relevant authorities / the authorities we are required to inform]] and are working with them. We will give a further update [[time and date of the next update]]. Media enquiries: [[Name]], Communications lead. |
Dos and don'ts
Do | Don't |
|---|---|
Keep it short and factual, and say when the next update will come. | Speculate on the cause, the attacker or the cost. |
Have the one approved spokesperson say it. | Say "no comment" — say what you can, and that you will update. |
CT-10 All-clear and thank-you
At closure, when the recovery criteria are met and the monitoring period has passed (IM-10). It goes to everyone told earlier, in the same channels. The lessons note that follows it feeds the post-incident review, held within 10 working days of closure for Severity 1 and 2 (IM-11).
Template. Replace every placeholder; delete any line that does not apply.
Template | CT-10 All-clear and thank-you |
|---|---|
When to use | At closure |
Audience | Everyone told earlier |
Approver | Executive incident lead |
Channel | [[The same channels as the messages it closes]] |
Subject | Closed: [[case number]] — [[short title, e.g. Malware on office PCs at one site]] |
Message | Dear colleagues, What happened: [[What happened, in two sentences]] Where we are now: [[What is back to normal, and since when]] What changes: [[What we are changing so it does not happen again, each with its date]] Thank you: [[Who to thank, and for what]] If you notice anything unusual, report it at once, as before. The post-incident review will look at what went well and what did not; if you have something to add, tell the incident manager. [[Name]], Executive incident lead |
Dos and don'ts
Do | Don't |
|---|---|
Say what changes as a result, with dates. | Declare the all-clear before the recovery criteria are met and closure is agreed. |
Thank people and teams by name where they agree. | Blame a person. |
Required inputs with owners
Every message is filled in from the facts sheet. The incident manager keeps it current, dated at each update; a message may only state what the facts sheet states.
Input | Used in | Owner | When updated |
|---|---|---|---|
Case number, title, category, severity and time of declaration | All | Incident manager | At declaration; severity at every update (IM-04) |
What we know, what we do not know yet, what we are doing | All | Incident manager | At every update |
Services affected, and the effect on customers | CT-02, CT-03, CT-04, CT-06, CT-09 | Owners of affected services | At every update |
What staff, customers and individuals should do | CT-03, CT-04, CT-08, CT-09 | Incident manager, with the service owners | When it changes |
Personal data affected: categories, numbers of people and records, the risk to them | CT-04, CT-07, CT-08 | Data Protection Officer, with the owner of the data | As the assessment develops |
Reporting screen: each duty, decision, reasons and deadline | CT-02, CT-04, CT-06, CT-07, CT-08 | Incident manager (IM-06) | Within 4 hours of declaration, then when it changes |
Suspected malicious act, cross-border effect, indicators of compromise | CT-06 | Technical responders | Before each NIS2 stage |
Customers with a notification clause, and their terms | CT-04 | Legal | Prepared in advance; checked per incident |
Supplier security contacts and contract clauses | CT-05 | Incident manager | Prepared in advance (P06) |
Authority forms, portals and contact details | CT-06, CT-07 | Legal and Data Protection Officer | Prepared in advance; checked yearly |
Named spokesperson and deputy; media enquiries received | CT-09 | Communications lead | Prepared in advance; logged per incident |
Facts sheet
One page, kept with the case log. Copy it for each update and date it: the dated copies show what was known when each message went out.
Field | Current value | As at |
|---|---|---|
Case number and title | [[INC-YYYY-nnn — short title]] | [[time]] |
Declared (reporting clocks start) | [[date and time]] | — |
Severity and category | [[Severity n; IC-nn]] | [[time]] |
Status | [[Not yet contained / Contained / Recovering / Closed]] | [[time]] |
What we know | [[facts]] | [[time]] |
What we do not know yet | [[open questions]] | [[time]] |
What we are doing | [[actions in progress]] | [[time]] |
Services affected | [[service: effect]] | [[time]] |
Personal data affected | [[categories; approximate numbers of people and records; risk level]] | [[time]] |
What people should do | [[staff / customers / individuals]] | [[time]] |
Reporting duties | [[RD-nn: decided yes or no; due; made]] | [[time]] |
Messages sent | [[MSG-nn: CT-nn to whom]] | [[time]] |
Next update | [[time]] | — |
Message approval log
Every message that leaves the response team is logged: which template, which version, who approved it, when it was sent and how. Keep the sent text with the entry. The log is the evidence that IM-09 was followed and that each report was made on time (measure IMM-02, reported under IM-12).
Ref | Case | Message | Version | Audience | Approved by | Sent | Channel |
|---|---|---|---|---|---|---|---|
[[MSG-nn]] | [[INC-…]] | [[CT-nn]] | [[n]] | [[to whom]] | [[name and role]] | [[date, time]] | [[channel]] |
MSG-01 EXAMPLE | INC-2026-014 | CT-01 | 1 | Response team | Information Security Manager | 12 Aug 2026, 08:25 | Incident chat channel and calls |
MSG-02 EXAMPLE | INC-2026-014 | CT-03 | 1 | Warehouse 2 staff | Chief Operating Officer | 12 Aug 2026, 09:40 | Email, site noticeboard, team leaders' briefing |
MSG-03 EXAMPLE | INC-2026-014 | CT-06 | 1 (early warning) | [[CSIRT]] | Chief Operating Officer | 12 Aug 2026, 15:40 | [[CSIRT reporting platform]] |
MSG-04 EXAMPLE | INC-2026-014 | CT-06 | 2 (notification) | [[CSIRT]] | Chief Operating Officer | 14 Aug 2026, 14:00 | [[CSIRT reporting platform]] |
MSG-05 EXAMPLE | INC-2026-014 | CT-06 | 3 (final report) | [[CSIRT]] | Chief Operating Officer | 11 Sep 2026, 12:00 | [[CSIRT reporting platform]] |
MSG-06 EXAMPLE | INC-2026-016 | CT-07 | 1 | [[Supervisory authority]] | Chief Operating Officer, with the Data Protection Officer | 11 Sep 2026, 10:00 | [[Authority's online form]] |
Guidance — delete before approval
Record the version of a message that was actually sent, not the draft. Where a message is changed after approval, it is a new version and needs approval again.
The EXAMPLE rows are the messages of INC-2026-014 and INC-2026-016 that the worked examples show, with the other messages of INC-2026-014 that had a legal deadline. The report times are the case log's (Incident Case & Action Log).
Follow-up template
The follow-up to an incident is CT-10, the all-clear and thank-you, sent at closure to everyone told earlier (see the message set). It says what happened, what is back to normal, what changes, and thanks the people who helped.
After CT-10, the communications lead completes a lessons note on the communications and gives it to the post-incident review (Post-Incident Review Template). For Severity 1 and 2 it is due before the review, which is held within 10 working days of closure (IM-11); severity 3 and 4 incidents are reviewed together once a quarter.
Lessons note on communications
Question | Answer |
|---|---|
Case number and title | [[INC-…]] |
Messages sent (from the approval log) | [[CT-nn × n; MSG-nn to MSG-nn]] |
Were any messages late against their deadline or promised update time? Why? | [[answer]] |
Did anyone speak or post outside the organisation other than through these templates (IM-09)? | [[answer, and what was done]] |
What questions came in that the templates or facts sheet could not answer? | [[answer]] |
Did any message have to be corrected or withdrawn? Why? | [[answer]] |
Were the channels available? Did anyone not receive a message they needed? | [[answer]] |
What should change in this template set? | [[change, owner, date]] |
Worked examples
Three messages from the EXAMPLE organisation's quarter: two from INC-2026-014, ransomware on 14 office PCs at Warehouse 2, and one from INC-2026-016, customer order spreadsheet sent to the wrong business customer. Each is the template above with the facts sheet's values in it.
INC-2026-014: CT-03 staff holding message
Declared Severity 1 at 08:25 on 12 Aug 2026. Warehouse 2's office network was cut off at 09:10; staff at the site could see that their PCs had stopped working. The chief Operating Officer, as executive incident lead, approved this message and it went out at 09:40. The next update is 2 hours later, the Severity 1 update interval.
EXAMPLE — INC-2026-014 | CT-03 Staff holding message |
|---|---|
Sent | 12 Aug 2026, 09:40 |
To | All staff at Warehouse 2 |
Approved by | Chief Operating Officer |
Channel | Email to Warehouse 2 staff, the site noticeboard, and team leaders' briefings at the start of each shift |
EXAMPLE — INC-2026-014 | CT-03 message |
|---|---|
Subject | Please read: a security incident affecting the office PCs at Warehouse 2 — what to do |
Message | Dear colleagues, We are dealing with a security incident affecting the office PCs at Warehouse 2. This morning our security monitoring provider alerted us to malicious software on an office PC at Warehouse 2. To stop it spreading, Warehouse 2's office network was cut off from all our other networks at 09:10. Ordering and dispatch are not affected. What this means for you: office PCs at Warehouse 2 cannot be used until the IT team has checked or rebuilt them. Warehouse picking and dispatch carry on as normal. What to do: leave every office PC at Warehouse 2 as it is, and tell your team leader what work is held up. The IT team will contact anyone whose PC they need. What not to do: do not switch on, log on to or unplug any office PC at Warehouse 2, or connect a laptop, phone or USB drive to the office network there. Do not talk about the incident outside the organisation or post about it. If a customer, supplier, journalist or anyone else asks, say you cannot comment and pass them to [[Name]], Communications lead. If you notice anything unusual, report it at once to [[the IT service desk, phone and email]]. Nobody is blamed for a report made in good faith. We will update you by 11:40 today. [[Name]], Chief Operating Officer |
What it does not say: who is behind it, how it got in, or that it is ransomware. At 09:40 none of that was confirmed, and staff did not need it to know what to do.
INC-2026-014: CT-06 NIS2 early warning
The reporting screen, complete at 11:30, found a significant incident: capable of severe operational disruption. The early warning was submitted at 15:40, 7 hours 15 minutes after declaration and well inside the 24 hours of RD-01 (due 13 Aug 2026, 08:25). It says only what the early warning needs; the initial assessment and the indicators of compromise followed in the incident notification on 14 Aug 2026, 14:00.
EXAMPLE — INC-2026-014 | CT-06 early warning content |
|---|---|
Stage | Early warning (RD-01), submitted 12 Aug 2026, 15:40 |
Entity | [[Organisation Name]]; an important entity under NIS2 in its Member State; [[sector and sub-sector]] |
Contact | [[Name]], Information Security Manager, [[email and phone]] |
Our reference | INC-2026-014 |
Became aware | 12 Aug 2026, 08:25 (declared Severity 1) |
What happened | 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: the 14 PCs isolated, no activity on any other site. |
Suspected unlawful or malicious act? (23(4)(a)) | Yes. Encryption activity by ransomware; a crime report will be made to [[the national cybercrime reporting service]]. |
Possible cross-border impact? (23(4)(a)) | Not known to be. The affected PCs are at one site in [[Member State]], and no customer or partner system is known to be affected. |
Initial assessment: severity and impact (23(4)(b)) | Not required in the early warning; it will follow in the incident notification (RD-02), due by 15 Aug 2026, 08:25. |
Indicators of compromise, where available (23(4)(b)) | Not required in the early warning; those available will follow in the incident notification. |
Measures taken | Warehouse 2's office network cut off from all other networks at 09:10. The managed IT service provider (SUP-001) is rebuilding the 14 PCs; backups are checked before anything is restored. |
Help asked of the CSIRT | None at present. |
Next report | Incident notification (RD-02) by 15 Aug 2026, 08:25. |
INC-2026-016: CT-07 GDPR notification to the supervisory authority
Declared Severity 2, category IC-05 (personal data breach), at 11:20 on 9 Sep 2026. The Data Protection Officer assessed the breach as a risk to individuals but, once the recipient had confirmed deletion in writing, not a high risk: the authority was notified and the individuals were not told. The notification went at 10:00 on 11 Sep 2026, 46 hours 40 minutes after awareness (due 12 Sep 2026, 11:20). The reasoning is set out in the Personal Data Breach Response Playbook.
EXAMPLE — INC-2026-016 | CT-07 notification content |
|---|---|
Controller | [[Organisation Name]], [[registered address]] |
Contact point (33(3)(b)) | [[Name]], Data Protection Officer, [[email and phone]] |
Our reference | INC-2026-016 |
When the breach happened | 9 Sep 2026. The customer service agent who sent the email reported it at 11:05. |
When we became aware | 9 Sep 2026, 11:20 |
Reasons for any delay beyond 72 hours (33(1)) | Not applicable: notified 46 hours 40 minutes after we became aware, within 72 hours. |
Nature of the breach (33(3)(a)) | Confidentiality breach. 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. The email client suggested a similar address and there was no warning for external recipients. |
People concerned: categories and approximate number (33(3)(a)) | Customers: 212 people. |
Records concerned: categories and approximate number (33(3)(a)) | 212 customer records: name, delivery address and order history. No payment data, and no special categories of data. |
Likely consequences (33(3)(c)) | The file was outside our control until the recipient confirmed its deletion at 16:30. The recipient is a known business customer and says it did not use the data. Had the file been copied or passed on, the people concerned could receive unwanted contact, or phishing that uses their order history to look genuine. No payment data or special categories of data were involved, so the risk of financial loss or of harm from sensitive data is low. |
Measures taken or proposed (33(3)(d)) | The recipient was asked to delete the file and any copies and to confirm in writing; it confirmed at 16:30 on 9 Sep 2026. The customer service team has been reminded to check external addresses. A warning for external recipients will be turned on, and address autocomplete stopped for customer service, by 15 Oct 2026. |
Individuals told? (Article 34) | No. Once the recipient had confirmed deletion in writing, the breach is not likely to result in a high risk to the people concerned (Article 34(1)). The decision and its reasons are in our breach record. |
Other authorities or Member States involved | None. |
Further information to follow? (33(4)) | No. This notification is complete; we will answer any questions the authority has. |
Guidance — delete before approval
Replace the EXAMPLE messages with your own once you have used the templates in an exercise. An exercise is the right time to find out that a message takes two hours to approve.
Adapting this template
Guidance — delete before approval
Small organisation: you may have no communications team. Name one person — often the managing director — as communications lead and one deputy, and keep the ten messages: they matter more when nobody has time to draft. CT-02 may be a phone call recorded in the case log; CT-03 may be a team meeting followed by the same words in writing. Keep the approval log even if it has three rows.
Regulated entity: an essential or important entity under NIS2 uses CT-06 on the Article 23(4) clocks, and CT-04 to tell recipients of its services where appropriate (RD-05). A DORA financial entity replaces CT-06 with the template of Implementing Regulation (EU) 2025/302, and uses CT-04 to tell clients whose financial interests are affected (RD-13); Article 17(3) of DORA expects communication plans for staff, external stakeholders and the media, which this set is. Every controller uses CT-07 and CT-08 under GDPR. Check your national transposition and your authorities' forms with counsel, and record any additions in the message set.
IT run by a service provider: your managed IT or security monitoring provider is often first to know. Its contract should say it tells you at once and does not speak about your incident; CT-05 is how you ask it to act. If you are yourself a service provider processing personal data for customers, CT-04 is also your notice to each controller (RD-09), and as a managed or managed security service provider under NIS2 the significant-incident tests of Implementing Regulation (EU) 2024/2690 apply to you.
Set every [[placeholder]] in the templates that does not depend on an incident — channels, contacts, forms — before approval, so that in an incident only the facts remain.
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.26 — Response to information security incidents | The message set, approvals and approval log: communication as part of the response |
ISO/IEC 27001:2022 | Annex A 5.5 — Contact with authorities | CT-06 and CT-07: prepared content, forms and contacts for the authorities |
NIST CSF 2.0 | RS.CO-02 — “Internal and external stakeholders are notified of incidents” | CT-01 to CT-09: internal and external stakeholders notified, with an approver for each |
NIST CSF 2.0 | RS.CO-03 — “Information is shared with designated internal and external stakeholders” | Facts sheet and message set: information shared with designated stakeholders |
NIST CSF 2.0 | RC.CO-03 — “Recovery activities and progress in restoring operational capabilities are communicated to designated internal and external stakeholders” | CT-02, CT-04 and CT-10: recovery progress communicated |
NIST CSF 2.0 | RC.CO-04 — “Public updates on incident recovery are shared using approved methods and messaging” | CT-09 and IM-09: public updates only through the approved method and messages |
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 | CT-06 and CT-04: the authority, and recipients of our services where appropriate |
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) | CT-06: the content of the early warning, notification and final report |
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 | CT-07: notification within 72 hours, with reasons if later |
GDPR — Regulation (EU) 2016/679 | Article 33(3) — the notification describes the nature of the breach (categories and approximate numbers of people and records), a contact point, the likely consequences, and the measures taken or proposed | CT-07: the minimum content of a notification |
GDPR — Regulation (EU) 2016/679 | Article 34(2) — the communication describes the breach “in clear and plain language” and gives at least the information in Article 33(3)(b), (c) and (d) | CT-08: clear and plain language, with the content of 33(3)(b) to (d) |
DORA — Regulation (EU) 2022/2554 | Article 17(3) — early warning indicators; procedures to log, categorise and classify incidents; roles for each incident type; communication plans; reporting major incidents to senior management and the management body; response procedures | The message set as the communication plan for staff, stakeholders and media |
DORA — Regulation (EU) 2022/2554 | Article 19(3) — where a major ICT-related incident has an impact on the financial interests of clients, inform them without undue delay of the incident and of the measures taken | CT-04 for clients whose financial interests are affected |
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 | CT-06 guidance: financial entities use the Implementing Regulation's template instead |
Definitions
Term | Meaning in this template set |
|---|---|
Approval log | The record of every message sent outside the response team: template, version, approver, time sent and channel. |
Approver | The role that must approve a message before it is sent. It approves each version sent. |
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. |
Communications lead | The only person who speaks for the organisation outside it during an incident (IM-09): [[e.g. Head of Marketing and Communications]]. |
Competent authority | The national authority that supervises an entity under NIS2 or, for financial entities, DORA. |
CSIRT | Computer security incident response team: the national team that receives NIS2 incident reports in many Member States. |
CT-nn | A message in this template set. |
Early warning | The first NIS2 report of a significant incident, due within 24 hours of awareness (RD-01). |
Facts sheet | The single, dated page of current facts about an incident, kept by the incident manager, from which every message is filled in. |
Holding statement | A short message that says what is known and when the next update will come, before the full picture is available. |
IM-nn | A rule of the Security Incident Management Policy. |
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. |
RD-nn | A reporting duty in the Incident Classification, Severity & Escalation Matrix. |
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. |
Supervisory authority | The data protection authority a controller notifies of a personal data breach under GDPR. |