Independent thinking. Informed defence.

CISO Times

Intelligence for the people behind the defence.

The CISO Decision Brief

Personal Data Breach Notification Templates

Templates for notification to the supervisory authority and communication to affected data subjects.

Available soon

Format
Word
Size
77 KB
Length
28 pages
Version
1.0
Updated

What's inside

What changed

  1. 1.0

    Published.

Changes across this pack

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

These templates hold the words of every notice a personal data breach can need under the GDPR: the notification to the supervisory authority, the follow-up when information arrives in phases, the communication to the people affected, the notice to a controller when we process its data, and the entry in the breach record when nothing is notified. Each is drafted by the Data Protection Officer from the one fact base (RN-07, RN-11), so every notice says the same thing.

Not legal advice. 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.

Template

Duty (P09)

Goes to

Approved by

When

1 Notification to the supervisory authority

RD-06

[[lead supervisory authority]]

Executive incident lead, with the Data Protection Officer (CT-07)

Without undue delay and, where feasible, within 72 hours of awareness; later only with reasons for the delay

2 Follow-up and phased information

RD-06

[[lead supervisory authority]]

Executive incident lead, with the Data Protection Officer (CT-07)

Without undue further delay, as each fact is known, and by the date Template 1 gave

3 Communication to individuals

RD-07

The data subjects

Executive incident lead, with the Data Protection Officer (CT-08)

Without undue delay

4 Notice to the controller, and its acknowledgement

RD-09

The controller whose data we process

Executive incident lead (CT-04)

Without undue delay, and within [[24]] hours of awareness unless the contract sets less (RN-15)

5 Breach record entry

RD-08

Kept by us; shown to the authority on request

Decided as RN-06 sets

For every personal data breach, notified or not

What is actually submitted

The supervisory authority's own form or portal is what is submitted: [[the authority's breach notification form or portal]]. Authorities ask for the content of Article 33(3) in their own order and words, and some ask for more. Template 1 prepares the answers in the order the law gives them, so that the signatory can copy each into the authority's form, and so that a dated copy of exactly what was sent is kept (RN-09).

Guidance — delete before approval

Before any breach, open your supervisory authority's form. Map each of its fields to a row of Template 1, and add a row for any field it asks that Template 1 does not. Record the channel, the language it accepts and its out-of-hours contact in the applicability profile (RN-01).

Which supervisory authority

Lead supervisory authority. Under the GDPR, the supervisory authority of the controller's main establishment, which receives the notification where processing crosses borders inside the EU. Otherwise the authority of the Member State concerned. GDPR Article 56(1): the supervisory authority of the main or single establishment of the controller or processor is competent to act as lead supervisory authority for its cross-border processing, without prejudice to Article 55. The European Data Protection Board's guidelines add: for a breach in cross-border processing, notification goes to the lead supervisory authority, not necessarily where the data subjects are or where the breach happened; in doubt, notify at least the local authority where the breach took place (Guidelines 9/2022, paragraph 69).

Decide this once, in the applicability profile (RN-01), not during a breach: [[lead supervisory authority, or the supervisory authority of the Member State concerned]]. Template 1 names it in T1-A.

Where these templates sit

P09's Personal Data Breach Response Playbook contains the breach, assesses the risk and runs the decision tree; these templates do not repeat its steps. Templates 1 and 3 are the full wording of P09's CT-07 and CT-08 in the Incident Communications Template Set, and Template 4 the wording its CT-04 takes when we act as a processor. The Reportability Decision Model makes the decision (DS-06), the Regulatory Notification Operating Procedure says who drafts, reviews, approves and submits (RN-07 to RN-10), and the Regulatory Notification Log logs each decision and submission. Come here when the GDPR decision is Reportable (Template 1), Not reportable (Template 5) or Not settled (draft Template 1 now, ready for the doubt point).

The duties

P09 owns the four GDPR duties and their deadlines: RD-06 notification to the supervisory authority (Templates 1 and 2), RD-07 communication to the individuals affected (Template 3), RD-08 breach record (Template 5), RD-09 notice to the controller (Template 4). The table under "How to use these templates" gives each deadline. This section explains how to read them.

The 72 hours are an outer limit

The GDPR's 72 hours is the outer limit of "without undue delay", not a target. A notification after 72 hours is still made, with the reasons for the delay. The hours run from awareness, as P09 records it: 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.

The European Data Protection Board puts it the same way: a controller should be regarded as aware when it “has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised” (Guidelines 9/2022, paragraph 31). Template 1 records both times in T1-C, so the authority can see which clock was used.

Information in phases

Article 33(4): information not available at once may be provided in phases without undue further delay. Template 1 says what is not yet known, who is finding it out and when it will follow (T1-F). Template 2 sends it, quoting the authority's reference (RN-09), and its due time goes in the log (RN-10).

Reasons for delay

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 (RN-13). Article 33(1) asks a late notification to give the reasons for the delay; T1-C holds them. Reasons that hold up, and those that do not:

Reason given

Does it hold up?

What to say or do instead

We became aware later than the breach happened

The clock runs from awareness, so this is not a delay at all.

Give both times in T1-C, and the evidence for the awareness time.

Facts needed for the risk decision were not available in time, and the decision was recorded as Not settled

Partly. The doubt point exists so this never runs past the deadline (RN-04).

Notify at the doubt point on the facts known, and say the assessment continues. A delay past 72 hours on this ground needs a very good reason.

We were waiting for complete information

No. Information may be given in phases (Article 33(4)).

Notify what is known; follow with Template 2.

The signatory or the channel was not available

No. That is a readiness failure (RN-17).

Use the deputy; if the channel is down, use the authority's other contact and record it.

Legal review had not finished

No. Review is time-boxed (RN-07).

The approver decides without it once the time has passed.

When the decision is not yet settled

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). For the GDPR, the doubt point is [[6]] hours before the 72-hour deadline: 66 hours after awareness. From then, the breach is treated as Reportable and Template 1 goes on the facts known, saying that the assessment continues (RN-04). A notification can be updated, or withdrawn with Template 2; a missed deadline cannot be undone.

When we are the processor

Where we process personal data for another controller, we must notify that controller without undue delay and within [[24]] hours of awareness, or sooner where the contract says so (P09 RD-09). A supplier's notice to us (P06 CL-07) is screened as our own incident, with its own awareness time (RN-15). The contract asks us to help the controller with its own duties (Article 28(3)(f)). We do not judge the risk for it: a processor notifies the controller without first assessing the likelihood of risk, which is for the controller; in principle the controller is “aware” once the processor has informed it (Guidelines 9/2022, paragraph 44). Template 4 gives the controller what it needs for its own notification.

The risk decision, in summary

Which templates are used turns on one decision: how likely and how severe the harm to the people concerned is. It is made under the Reportability Decision Model (DS-06), on the Data Protection Officer's assessment. Every decision to report is the executive incident lead's (P09). A decision not to report an incident that is at Severity 1 or 2 when the decision is recorded is the executive incident lead's too; for Severity 3 and 4 the incident manager may record it. The Data Protection Officer advises on every GDPR decision. This section summarises the test so the drafter knows what follows. The full test, and how each factor is weighed, is in the Reportability Decision Model; the assessment as it is run during the response is in P09's Personal Data Breach Response Playbook.

Risk level

What follows

Duties

Templates

Unlikely to result in a risk

Recorded, with the reasons, and not notified.

RD-08

Template 5

Risk

Notified to the supervisory authority and recorded.

RD-06, RD-08

Templates 1 and 2; Template 5

High risk

Also communicated to the people affected, without undue delay, unless an Article 34(3) condition is met.

RD-06, RD-07, RD-08

Templates 1 and 2; Template 3; Template 5

The factors the decision weighs:

Factor

The question

GF-01

Type of breach

Confidentiality (seen or taken), integrity (altered) or availability (lost or unreachable)? Each can harm people differently.

GF-02

Nature, sensitivity and volume of the data

Special category data, criminal offence data, financial or identity documents, passwords, location, or data about children raise the risk. So does a combination of data about the same person.

GF-03

Ease of identification

How easily can the people be identified from the data, directly or with other data?

GF-04

Severity of consequences

Could it lead to identity theft, fraud, financial loss, discrimination, distress, damage to reputation or physical harm? Is it permanent?

GF-05

Who the people are

Children, vulnerable adults, patients or people at risk of harm if their whereabouts are known?

GF-06

Number of people

More people usually means more harm, but one person can suffer a high risk.

GF-07

Where the data went and whether it is recovered

To a trusted party who confirmed deletion, to an unknown party, or published? Encrypted with the key safe? Restored from backup with nothing lost?

When individuals need not be told

Article 34(3): a high-risk breach need not be communicated to the people concerned where one of three conditions is met. Each still leaves something to write:

Condition

What is written instead

The data was protected so that it is unintelligible to anyone not authorised to see it, for example by encryption with the key safe.

No communication. Name the condition and its evidence (the encryption used, and where the key was) in T1-F and T5-D.

Measures taken since mean the high risk is no longer likely to materialise.

No communication. Name the measures, when they were taken and why they remove the high risk, in T1-F and T5-D.

Telling each person would involve disproportionate effort; a public communication or similar measure that informs them as effectively is made instead.

Template 3c, the public communication, after legal advice. Record why individual messages were disproportionate in T3-D.

The authority can disagree. Article 34(4): if the controller has not already communicated the breach to the data subjects, the supervisory authority, having considered the likelihood of high risk, may require it to do so or may decide that any of the conditions in Article 34(3) are met. That is why T1-F always gives the reason individuals were not told, in words the authority can test.

Template 1: Notification to the supervisory authority

Use it when the GDPR decision is Reportable: the breach is a risk or a high risk to the people concerned (RD-06: without undue delay and, where feasible, within 72 hours of awareness; later only with reasons for the delay). It is the full wording of P09's CT-07, approved by the executive incident lead, with the Data Protection Officer. One notification covers one breach; anything learned later goes in Template 2.

What it must contain, and where each item comes from:

What the notification must contain

Law

Drafted from the fact base

On the form

The nature of the breach: categories and approximate number of people concerned, and categories and approximate number of records

Article 33(3)

FB-03 What happened

FB-15 People affected

FB-16 Personal data affected

T1-D

The name and contact details of the Data Protection Officer or other contact point

Article 33(3)

FB-02 Contact point

T1-B

The likely consequences of the breach

Article 33(3)

FB-17 Likely consequences

T1-E

The measures taken or proposed to address the breach, including those to reduce its possible adverse effects

Article 33(3)

FB-12 Measures taken

T1-E

If made after 72 hours, the reasons for the delay

Article 33(1)

Decided when drafting

T1-C

What is not yet known, and when it will follow (phased notification)

Article 33(4)

Decided when drafting

T1-F

Field guidance

Field

Fact base

What a good answer looks like, and the weak answer to avoid

T1-A Type of notification

FB-14

Initial and complete; or initial with more to follow, saying what and when; or late, with the reasons in T1-C. Avoid: Left blank. The authority cannot tell whether to wait for more, and a later update looks like a new breach.

T1-A Supervisory authority

FB-01

FB-07

The lead supervisory authority named in the applicability profile (RN-01), or the authority of the one Member State concerned. Avoid: Whichever authority the drafter finds first. A notification to the wrong authority is not a notification to the right one: settle it in the profile, before any breach.

T1-B Contact point

FB-02

A named person who can answer the authority's questions at any hour during the incident, with a direct telephone number and an email address that someone reads. Avoid: A shared mailbox nobody watches out of hours, or a person who was not involved in the assessment.

T1-C Times

FB-04

Three times, each with its source: when the breach happened (or the period), when it was detected, and when we became aware. Awareness is the time the 72 hours ran from. Avoid: One date for everything. The authority will ask which clock was used, and the answer must match the log.

T1-D What happened

FB-03

FB-08

Two to four sentences of fact: what was disclosed, lost, altered or made unavailable, how, and the security property affected. Avoid: Technical narrative or speculation about the cause. Give facts; the cause can follow in Template 2.

T1-D People concerned

FB-15

Categories (customers, staff, children) and an approximate number for each, with how the number was counted. Avoid: "Some customers." Give a number or a range, and say it is an estimate where it is one.

T1-D Records concerned

FB-16

The data items, by kind, and an approximate number of records; special category or criminal offence data marked; what was not involved. Avoid: A copy of the file, or the people's names. Never paste the personal data itself into a notification: describe it.

T1-E Likely consequences

FB-17

What could realistically happen to the people concerned, and how likely, with the factors that raise or lower it (GF-01 to GF-07). Avoid: "No consequences expected" with no reason. If there were none, the breach was probably not notifiable; say why it is.

T1-E Measures

FB-12

What was done to contain the breach and when, what reduces the harm to the people concerned, and what will stop it recurring, each with a date. Avoid: "Staff reminded." Name the change and its date, or say it is still being decided.

T1-F Individuals told?

FB-13

Yes, with when and how (Template 3); or no, with the reason: not a high risk, or the Article 34(3) condition met. Avoid: "Not yet" with no plan. If the breach is a high risk, the communication goes without undue delay.

The form

Guidance — delete before approval

Keep the field codes (T1-A to T1-G) when you adopt the form: Template 2 and the log refer to them.

Never paste the personal data itself into a notification. Describe its categories and numbers.

T1-A About this notification

Type

initial or late; a follow-up uses Template 2

[[Initial, complete / Initial, more to follow (Article 33(4)) / Late: reasons in T1-C]]

Our reference

case number and decision ID

[[INC-YYYY-NNN; DEC-YYYY-NNN]]

Supervisory authority

the lead authority for cross-border processing (Article 56(1))

[[lead supervisory authority, or the supervisory authority of the Member State concerned]]

Channel

[[the authority's breach notification form or portal]]

Member States of the people concerned

other than the authority's own

[[None / list]]

Other authorities told

NIS2, police, others, with references

[[None / which, and when]]

T1-B Controller and contact point

Controller

legal name, address, registration

[[Organisation Name]], [[registered address, registration number]]

Contact point

Article 33(3)(b): the Data Protection Officer or another contact, reachable at any hour

[[Name]], Data Protection Officer, [[email and telephone]]

T1-C Times

Breach happened

date and time, or the period

[[YYYY-MM-DD HH:MM, or from and to]]

Detected

and by whom

[[YYYY-MM-DD HH:MM; who]]

Became aware

the time the 72 hours run from

[[YYYY-MM-DD HH:MM]]

Notified

this submission, hours after awareness

[[YYYY-MM-DD HH:MM; n hours]]

Due by

awareness plus 72 hours (RD-06)

[[YYYY-MM-DD HH:MM]]

Reasons for delay

only after 72 hours (Article 33(1))

[[Not applicable / the reasons]]

T1-D The breach | Article 33(3)(a)

Kind

confidentiality, integrity, availability

[[Confidentiality / integrity / availability]]

How it was discovered

[[Who found it, and how]]

What happened

facts, not the data itself

[[Two to four sentences: what, how, since when]]

People concerned

categories and approximate number

[[e.g. customers, staff, children: about n]]

Records concerned

categories and approximate number; special categories marked

[[Data items; about n records; what was not involved]]

T1-E Consequences and measures | Article 33(3)(c) and (d)

Likely consequences

for the people concerned, and how likely

[[What could happen to them, and why it is more or less likely]]

Measures taken

containment and to reduce the harm, with times

[[What was done, when, by whom]]

Measures proposed

to stop it recurring, with dates

[[Change, owner, date]]

T1-F Individuals, and what follows

Individuals told?

Article 34: Template 3, or why not

[[Yes: when and how / No: not a high risk / No: the Article 34(3) condition met, and why]]

Still to come

Article 33(4): what, and when

[[Nothing / what is not yet known, who is finding it out, and when Template 2 will follow]]

T1-G Review, approval and submission

Drafted by

the Data Protection Officer (RN-07)

[[Name, role]]

Drafted at

[[YYYY-MM-DD HH:MM]]

Checked against the fact base by

a second person, where 60 minutes or more remain (RN-08)

[[Name, role / not possible: minutes left]]

Legal review

within [[60]] minutes (RN-07)

[[Name, time / not received in time]]

Approved by

Executive incident lead, with the Data Protection Officer (P09 CT-07)

[[Name, role, time]]

Submitted by

a notification signatory (RN-08)

[[Name, role]]

Submitted at

the time the authority's form was sent

[[YYYY-MM-DD HH:MM]]

Authority's reference

quoted in every later report (RN-09)

[[Reference]]

Acknowledged

[[YYYY-MM-DD HH:MM / none received]]

Logged as

submission ID in the Regulatory Notification Log

[[SB-YYYY-NNN]]

Next report due

entered in the log and two calendars (RN-10)

[[Template 2 by YYYY-MM-DD HH:MM / none]]

Template 2: Follow-up and phased information

Use it for every later message to the authority about the same breach:

  • Phased information (Article 33(4)): what Template 1 said would follow, by the date it gave.
  • Correction (RN-12): a material error found in a submitted report must be corrected in the next report, or by a correction to the same authority without undue delay where no report is due, and the correction logged.
  • An answer to a question the authority asks. Log the question and its due time at once (RN-10).
  • A change in the risk level. A breach found to be a high risk after Template 1 went: Template 3 goes, and Template 2 tells the authority when. A breach found not to be a breach at all: say so, with the evidence, rather than letting the notification lapse.

T2-A The notification this follows

Authority's reference

from Template 1 (RN-09)

[[Reference]]

Our reference

[[INC-YYYY-NNN]]

First notified at

[[YYYY-MM-DD HH:MM]]

This follow-up is

[[Phased information (Article 33(4)) / Correction (RN-12) / Answer to the authority's question of YYYY-MM-DD / Change in the risk level]]

T2-B What is new or changed | one line per Template 1 field, by its code

Field

[[e.g. T1-D People concerned]]

Said before

[[e.g. about 200]]

Says now, and source

[[e.g. 212, counted from the order system export]]

Field

[[T1-n field]]

Said before

[[Previous answer]]

Says now, and source

[[New answer; fact base field]]

Correction

what was wrong and why (RN-12)

[[The error, how it was found, and the correct value / none]]

Individuals told since?

Template 3

[[No change / Yes: when, how, how many / Now a high risk: Template 3 goes on YYYY-MM-DD]]

Still to come

[[Nothing: this completes the notification / what, and when]]

Review, approval and submission

[[Complete T1-G's rows for this follow-up, on a copy of T1-G]]

Template 3: Communication to individuals

Use it when the breach is likely to result in a high risk to the people concerned and no Article 34(3) condition is met (RD-07: without undue delay). 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). It is the full wording of P09's CT-08, approved by the executive incident lead, with the Data Protection Officer, and only the communications lead sends it (RN-14).

What it must contain, and where each item sits in the text:

What the communication must contain

Law

Drafted from the fact base

In the text

What happened, in clear and plain language

Article 34(2)

FB-03 What happened

What happened

The name and contact details of the Data Protection Officer or other contact point

Article 34(2)

FB-02 Contact point

Questions

The likely consequences for them

Article 34(2)

FB-17 Likely consequences

What this could mean for you

What we have done and will do, and what they can do to protect themselves

Article 34(2)

FB-12 Measures taken

FB-13 Notices to others

What we have done; What you can do

Guidance — delete before approval

Write the texts in the language each person uses with you. Run every draft through the plain-language checklist before approval.

Brief the enquiry line with the same facts, and a script, before anything is sent. People who receive a breach notice call.

3a Email to each person

Template 3a

Email

Subject

[[Organisation Name]]: important information about your personal details

Message

Dear [[Name]],

What happened. [[in plain words, what happened and when, e.g. on 9 September we sent a file with some of your details to another business by mistake]]. This involved some of your information. We are sorry that it happened.

What information was involved. [[the kinds of information about you, e.g. your name, delivery address and what you ordered]]. [[what was not involved, e.g. no payment card or bank details, and no passwords]].

What this could mean for you. [[what could happen, honestly and without alarm, and how likely, e.g. you could receive unexpected emails or calls from someone pretending to be us]].

What we have done. [[what we did and will do, with dates, e.g. the business confirmed in writing that 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; check any request with us on the number below]]. [[what we will never ask for, e.g. we will never ask you for your password or card details by email or phone]].

Questions. Contact [[Name]], Data Protection Officer, [[email]], [[telephone and hours]], or call [[enquiry line number and hours]]. This email has no links or attachments. To check it is genuine, call us on the number on our website.

You also have the right to complain to [[the supervisory authority, with its website and telephone]].

[[Name]], [[role, e.g. Chief Operating Officer]]

3b Letter to each person

Use a letter where there is no email address, where the email address may itself be compromised, or where a letter is the usual way you write to these people. The body is 3a's, from What happened to the complaint line, without the email's line on links.

Template 3b

Letter

Heading

Important: information about your personal details held by [[Organisation Name]]

Opening

[[date]]

Dear [[Name]],

We are writing to tell you about a mistake that involved some of your information, and what we are doing about it. We are sorry that it happened.

Body

As 3a

Close

Yours sincerely,

[[Name]], [[role, e.g. Chief Operating Officer]]

3c Public communication

Use it only under Article 34(3)(c): telling each person would involve disproportionate effort; a public communication or similar measure that informs them as effectively is made instead. Publish it where the people concerned will see it: [[website notice, customer portal banner, a notice in the press]]. Take legal advice first, and record the reason in T3-D.

Template 3c

Public communication

Subject

[[Organisation Name]]: notice about some customers' personal details

Message

What happened. [[in plain words, what happened and when, e.g. on 9 September we sent a file with some of your details to another business by mistake]].

Who is affected. [[who is affected, described so that people can tell, e.g. customers who placed an order for delivery between 1 and 8 September 2026]]. [[how people can find out whether they are affected, without giving details online, e.g. call the enquiry line; we will confirm by letter]].

What information was involved. [[the kinds of information about you, e.g. your name, delivery address and what you ordered]]. [[what was not involved, e.g. no payment card or bank details, and no passwords]].

What this could mean for you. [[what could happen, honestly and without alarm, and how likely, e.g. you could receive unexpected emails or calls from someone pretending to be us]].

What we have done. [[what we did and will do, with dates, e.g. the business confirmed in writing that 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; check any request with us on the number below]]. [[what we will never ask for, e.g. we will never ask you for your password or card details by email or phone]].

Questions. Contact [[Name]], Data Protection Officer, [[email]], [[telephone and hours]], or call [[enquiry line number and hours]]. You also have the right to complain to [[the supervisory authority, with its website and telephone]].

Published [[date]]. [[Name]], [[role, e.g. Chief Operating Officer]]

Approval and sending record

T3-D Approval and sending | one record per sending

Template used

[[3a email / 3b letter / 3c public communication]]

Why this form

3c: the Article 34(3) condition and legal advice

[[Reason]]

Drafted by

the Data Protection Officer, with the communications lead

[[Names]]

Approved by

Executive incident lead, with the Data Protection Officer (P09 CT-08)

[[Name, role, time]]

Checked against Template 1 by

RN-14: nothing contradicts it

[[Name, time]]

Plain-language checklist

every check done

[[Yes / which not, and why]]

Sent by

the communications lead only (RN-14)

[[Name]]

Sent at

[[YYYY-MM-DD HH:MM]]

People sent to

number, and the list used

[[n; list reference]]

Not delivered

and what was done

[[n; second channel used]]

Enquiry line ready

staffed and briefed before sending

[[Yes: number, hours, briefed on YYYY-MM-DD]]

Authority told

with Template 2

[[YYYY-MM-DD HH:MM]]

Template 4: Notice to the controller when we are its processor

Use it when we process personal data for another organisation and a breach affects that data (RD-09: without undue delay; RN-15: within [[24]] hours of awareness unless the contract sets less). The controller decides the risk and makes its own notification; we give it the facts, as far as known, and keep them coming. We do not notify the authority or the people concerned on the controller's behalf unless the contract says so.

It must give everything the controller needs for its own notification, as far as known: what happened, the data and people concerned, likely consequences, measures taken, and a contact (Article 28(3)(f); fact base FB-03, FB-15, FB-16, FB-17, FB-12, FB-02; on the form at T4-C, T4-D).

T4-A To the controller

Controller

legal name

[[Controller name]]

Breach contact

from the contract

[[Name, email, telephone]]

Contract

and its notice period

[[Contract reference; notice within n hours, or within [[24]] hours where it sets none (RN-15)]]

Processing affected

the service we provide

[[Service, systems, data sets]]

We became aware

[[YYYY-MM-DD HH:MM]]

Notice due by

awareness plus the contract's hours

[[YYYY-MM-DD HH:MM]]

This notice sent at

[[YYYY-MM-DD HH:MM]]

Breach happened

date and time, or the period

[[YYYY-MM-DD HH:MM]]

T4-B What we know | as far as known; the controller decides the risk

What happened

kind, how, since when

[[Facts in two to four sentences]]

People concerned

categories and approximate number

[[Categories; about n]]

Records concerned

categories and approximate number

[[Data items; about n records]]

Likely consequences

as far as we can see them

[[What could happen to the people concerned]]

Measures taken

and proposed, with times

[[What we have done and will do]]

T4-C Contact and what follows

Our contact

at any hour during the incident

[[Name]], Data Protection Officer, [[email and telephone]]

Not yet known

and when the next update comes

[[What, who is finding it out, next update YYYY-MM-DD HH:MM]]

What we need from you

[[e.g. confirm receipt; tell us if you will notify individuals, so our customer service can answer]]

Approved by

as P09 approves a customer notice

[[Name]], Executive incident lead (P09 CT-04)

Sent by, and how

[[Name; email to the breach contact, followed by a call]]

The controller's acknowledgement

The acknowledgement fixes when the controller became aware, which starts its own 72 hours. Send T4-D with every Template 4 and ask for it back. Use it the other way round too: when one of our processors tells us of a breach (P06 CL-07 asks for notice within [[24]] hours, in P06's Supplier Contract Security Clause Library), we return T4-D to it, and screen the notice as our own incident, with our own awareness time (RN-15).

T4-D Acknowledgement | returned by the controller to the processor

Notice received at

the controller's awareness time

[[YYYY-MM-DD HH:MM]]

Received by

[[Name, role]]

Controller's case number

[[INC-YYYY-NNN]]

Processor's reference

[[Reference on the notice]]

Questions for the processor

each with the time an answer is needed

[[Question; needed by YYYY-MM-DD HH:MM]]

Next update agreed

time and channel

[[YYYY-MM-DD HH:MM; channel]]

Evidence to keep

logs, copies, confirmations

[[What the processor must keep, and for how long]]

Template 5: Breach record entry

Every personal data breach is recorded, whether or not it was notified (RD-08). Article 33(5): the controller documents every personal data breach: the facts, its effects and the remedial action taken. For a notified breach, the entry points to the copy of Template 1. For a breach not notified, the entry is the only evidence that the decision was made on time and for good reasons, so it carries them in full. The authority may ask to see it. Keep it for at least [[6]] years after the incident is closed (RN-18).

It must hold the facts of the breach, its effects and the remedial action taken, whether or not it was notified (T5-B, T5-C, T5-E), and the risk decision and its reasons (T5-C, T5-D). It also holds every field of P09's breach record, so the two never differ:

P09 breach record field

What to record

On the form

Case number

The incident case number

T5-A

Kind of breach

Confidentiality, integrity or availability, or more than one

T5-A

What happened

The facts, in a few sentences

T5-B

When it happened; when we became aware

Dates and times

T5-B

Data and people

Categories and approximate numbers of people and records

T5-B

Effects

The likely consequences for the people concerned

T5-C

Risk assessment

The level (unlikely, risk, high risk), the factors and the reasons

T5-C

Notified to the authority?

Yes, when and with what reference; or no, and why

T5-D

People told?

Yes, when and how; or no, and why (not a high risk, or the Article 34(3) condition)

T5-D

Remedial action

What was done to contain the breach and reduce the harm, and what changes to stop it recurring

T5-E

Decided by; date

The Data Protection Officer's assessment and the executive incident lead's decision

T5-D

T5-A The breach

Case number

and title

[[INC-YYYY-NNN: title]]

Decisions

final, and those it replaced

[[DEC-YYYY-NNN]]

Kind

confidentiality, integrity, availability

[[Kind]]

How it was discovered

[[Who found it, and how]]

T5-B Facts | Article 33(5)

What happened

[[The facts, in a few sentences]]

Breach happened

[[YYYY-MM-DD HH:MM]]

Became aware

[[YYYY-MM-DD HH:MM]]

People concerned

categories and approximate number

[[Categories; about n]]

Records concerned

categories and approximate number

[[Data items; about n records]]

T5-C Effects and risk

Effects

likely consequences for the people concerned

[[What could happen to them]]

Risk level

[[Unlikely to result in a risk / Risk / High risk]]

Revisits

earlier decisions on this breach

[[DEC-YYYY-NNN, time: outcome / none]]

Factors

GF-01 to GF-07, as found

[[Each factor that mattered: what was found]]

Reasons

the decision's own words

[[Why this level, citing the factors]]

T5-D Decision

Notified to the authority?

yes: reference; no: why, and when it would have been due

[[Yes: Template 1, reference / No: why; due by; decided before the doubt point]]

People told?

Template 3, or why not

[[Yes: when, how / No: why]]

Other regimes and notices

[[NIS2, contract, insurer, police: each decision and reference]]

Decided by

RN-06

[[Name, role; on whose assessment]]

Decided on

[[YYYY-MM-DD HH:MM]]

T5-E Remedial action

Contained

what, when

[[What stopped the breach, and when]]

Restored or recovered

what, when

[[What was restored, from what, when / not applicable]]

Stopping it recurring

action, owner, date, status

[[Action; owner; due; status]]

T5-F Keeping the record

Kept until

RN-18

[[6]] years after closure on [[YYYY-MM-DD]]

Entered by, and where

[[Name, role; Regulatory Notification Log]]

Approvals

Each template is drafted, reviewed, approved and sent by the people P09 and the Regulatory Notification Operating Procedure name. Each report must be approved by the approver P09 names for its template, and submitted only by a notification signatory through the authority's channel. Where at least [[60]] minutes remain before the deadline, a second person checks it against the fact base first (RN-08).

Template

Drafts

Reviews

Approves

Sends or submits

Records

1 and 2

Data Protection Officer

Legal, within [[60]] minutes (RN-07)

Executive incident lead, with the Data Protection Officer (CT-07)

Notification signatory (RN-08)

Signatory, in the log at once (RN-09)

3

Data Protection Officer, with the communications lead

Legal

Executive incident lead, with the Data Protection Officer (CT-08)

Communications lead only (RN-14)

Communications lead; the authority told with Template 2

4

Data Protection Officer

Legal

Executive incident lead (CT-04)

Data Protection Officer, to the controller's breach contact

Data Protection Officer, in the log

5

Data Protection Officer

—

The decision: executive incident lead, or for Severity 3 and 4 not reported, the incident manager (RN-06)

Not sent

Data Protection Officer, kept as RN-18 sets

Guidance — delete before approval

Name the GDPR signatories, each with a deputy who has tested access to the authority's form. EXAMPLE: the Data Protection Officer, with Legal as deputy.

Plain-language checklist for Template 3

Work through it before Template 3 goes for approval, and record the result in T3-D.

Check

Why it matters

Done

1

The first two sentences say what happened and that it involves the reader's information.

People decide in the first lines whether to read on.

[[ ]]

2

It names the kinds of information involved, and what was not involved.

People worry most about what they are not told. "No bank details" is the line they look for.

[[ ]]

3

Sentences are short, in everyday words. No "personal data breach", "data subject", "controller", "exfiltration", "threat actor" or article numbers.

Article 34(2) asks for clear and plain language. Legal terms make a letter feel like it is protecting us, not them.

[[ ]]

4

The consequences are stated honestly, with how likely they are, neither played down nor alarming.

A letter that says "nothing to worry about" and is then followed by fraud does more harm than the breach.

[[ ]]

5

Every step under "What you can do" is specific, and something an ordinary person can do today.

"Be vigilant" is not a step. "Do not reply to emails about your order that you did not expect" is.

[[ ]]

6

It gives a named contact who can answer, with a telephone number and hours, and the enquiry line is staffed and briefed before anything is sent.

People who receive a breach letter call. An unanswered line turns a notice into a complaint.

[[ ]]

7

It contains no link asking people to sign in, and no attachment, and says what we will never ask for.

Breach notices are copied by fraudsters. Ours must not look like theirs.

[[ ]]

8

It says sorry, and admits nothing about legal liability that Legal has not reviewed.

An apology is right. A statement of fault or a promise of compensation is a legal decision.

[[ ]]

9

Every fact and number agrees with Template 1 and the fact base.

RN-11 and RN-14: the authority may compare the two.

[[ ]]

10

Someone outside the response team has read it aloud and understood it without help.

The test for plain language is a reader, not the writer.

[[ ]]

Worked example: a notification to the supervisory authority

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; a controller for its customers', staff and suppliers' personal data; it processes no personal data for other controllers. INC-2026-016: 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 screen recorded DEC-2026-009 at 13:00 on 9 Sep 2026: Reportable, a risk (GF-01, GF-03, GF-06); whether a high risk to be settled once the recipient confirms deletion. DEC-2026-010 replaced it at 17:15 on 9 Sep 2026, once deletion was confirmed.

Why the individuals were not told. The final decision, DEC-2026-010, found a risk but not a high risk: the recipient confirmed deletion in writing at 16:30, no payment data was included, and the data went to a known business (GF-02, GF-07). A risk opens RD-06 and not RD-07, so Template 3 was not used, and T1-F says why in words the authority can test (Article 34(4)).

Guidance — delete before approval

Note the timing. The notification went 46 hours 40 minutes after awareness, after DEC-2026-010 settled whether the breach was a high risk and well inside the 72 hours, so T1-C needs no reasons for delay. Nothing was left to follow, so no Template 2 was due.

Delete this worked example from your adopted templates.

T1-A About this notification — EXAMPLE

Type

Initial notification, complete. No information left to follow.

Our reference

INC-2026-016; decision DEC-2026-010

Supervisory authority

[[lead supervisory authority, or the supervisory authority of the Member State concerned]]

Channel

[[the authority's breach notification form or portal]]

Member States of the people concerned

None

Other authorities told

None. NIS2: not reportable (DEC-2026-008). DORA: not applicable (not a financial entity).

T1-B Controller and contact point — EXAMPLE

Controller

[[Organisation Name]], a wholesale distributor with about 900 staff, three warehouses and an online ordering service that takes 60% of its orders; [[registered address, registration number]]

Contact point

[[Name]], Data Protection Officer, [[email and telephone]]

T1-C Times — EXAMPLE

Breach happened

9 Sep 2026, before it was reported at 11:05

Detected

9 Sep 2026, 11:05: customer service agent (self-reported)

Became aware

9 Sep 2026, 11:20: declared Severity 2, IC-05 personal data breach

Notified

11 Sep 2026, 10:00: 46 hours 40 minutes after awareness

Due by

12 Sep 2026, 11:20

Reasons for delay

Not applicable: notified within 72 hours

T1-D The breach | Article 33(3)(a) — EXAMPLE

Kind

Confidentiality (GF-01)

How it was discovered

Reported by the agent who sent the email

What happened

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. Cause: the email client suggested a similar address and there was no warning for external recipients.

People concerned

212 customers, one record each.

Records concerned

Names, delivery addresses and order histories. No payment data, no special categories. 212 records.

T1-E Consequences and measures | Article 33(3)(c) and (d) — EXAMPLE

Likely consequences

Unwanted contact, or phishing made convincing by real order details. No route to financial loss without further deception. No vulnerable people: none known among the customers concerned. The file was unprotected, but the recipient is a known business customer that deleted it the same day, so the risk is limited.

Measures taken

Contained at 16:30 on 9 Sep 2026: the recipient, a known business customer with a contract, confirmed in writing the same day that it had deleted the file.

Measures proposed

Turn on the warning for external recipients in email, and stop address autocomplete for customer service: Head of IT, by 15 Oct 2026.

T1-F Individuals, and what follows — EXAMPLE

Individuals told?

No. A risk, not a high risk: the recipient confirmed deletion in writing at 16:30, no payment data was included, and the data went to a known business (GF-02, GF-07). Decision DEC-2026-010.

Still to come

No information left to follow. We will answer any question the authority asks.

T1-G Review, approval and submission — EXAMPLE

Drafted by

[[Name]], Data Protection Officer

Drafted at

After decision DEC-2026-010, 9 Sep 2026, 17:15

Checked against the fact base by

[[Name, role]]: required, as more than [[60]] minutes remained

Legal review

[[Name]], Legal

Approved by

Chief Operating Officer (executive incident lead), with the Data Protection Officer

Submitted by

Data Protection Officer, the GDPR signatory

Submitted at

11 Sep 2026, 10:00

Authority's reference

[[authority's reference]]

Acknowledged

11 Sep 2026, 10:02

Logged as

SB-2026-004, Regulatory Notification Log

Next report due

None: the notification is complete

The breach also has its breach record entry (Template 5), which points to this copy. EXAMPLE

Worked example: a breach recorded and not notified

EXAMPLE. INC-2026-014: 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. The reporting screen found a personal data breach to assess and recorded it as Not settled (DEC-2026-002); the revisit settled it before the doubt point (DEC-2026-003). The entry below is the breach record for it.

Guidance — delete before approval

Note what made the record good enough: the decision was recorded inside the 72 hours, with the factors and the evidence (the restore from checked backups, the provider's analysis), and the record says when the notification would have been due. Had the analysis still been running at the doubt point, Template 1 would have gone on the facts known.

The people count is a placeholder: the case log does not hold it. Your entry must give an approximate number.

T5-A The breach — EXAMPLE

Case number

INC-2026-014: ransomware on 14 office PCs at Warehouse 2

Decisions

DEC-2026-003 (final), replacing DEC-2026-002

Kind

Availability (GF-01)

How it was discovered

Security monitoring provider (SUP-006)

T5-B Facts | Article 33(5) — EXAMPLE

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. The breach: shipping records with customer names and delivery addresses on the encrypted PCs became unavailable.

Breach happened

Not known: before the first alert at 12 Aug 2026, 07:50

Became aware

12 Aug 2026, 08:25

People concerned

Customers named in the shipping records: [[approximate number]]

Records concerned

Shipping records on the office PCs: customer names and delivery addresses.

T5-C Effects and risk — EXAMPLE

Effects

Ordering and dispatch were not affected. The copies on the office PCs were out of reach for about a day and a half, with no effect on the people concerned.

Risk level

Unlikely to result in a risk

Revisits

DEC-2026-002, 12 Aug 2026, 11:30: Not settled, revisit by 14 Aug 2026, 10:00

Factors

Type and sensitivity of the data: shipping records on the office PCs: customer names and delivery addresses.

Protection of the data: encrypted by the ransomware, so unavailable; the same records were held in the ordering platform and in backups.

Whether containment worked: restored from checked backups when office work resumed; the security monitoring provider's analysis found no sign of data being taken.

Severity and permanence of the consequences: ordering and dispatch were not affected. The copies on the office PCs were out of reach for about a day and a half, with no effect on the people concerned.

Reasons

Unlikely to result in a risk: restored from backup with nothing lost, and the provider's analysis found no sign of data taken (GF-01, GF-07). Recorded under RD-08.

T5-D Decision — EXAMPLE

Notified to the authority?

No. Had it been a risk, the notification was due by 15 Aug 2026, 08:25; the decision came 49 hours 35 minutes after awareness, before the doubt point at 15 Aug 2026, 02:25 (RN-04).

People told?

No: not a high risk.

Other regimes and notices

NIS2: significant incident, reported separately: SB-2026-001 NIS2 early warning, 12 Aug 2026, 15:40; SB-2026-002 NIS2 incident notification, 14 Aug 2026, 14:00; SB-2026-003 NIS2 final report, 11 Sep 2026, 12:00.

Decided by

Chief Operating Officer (executive incident lead), on the Data Protection Officer's assessment

Decided on

14 Aug 2026, 10:00

T5-E Remedial action — EXAMPLE

Contained

12 Aug 2026, 13:50: 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.

Restored or recovered

13 Aug 2026, 14:00: office work resumes on rebuilt PCs; backups checked before restoring.

Stopping it recurring

PIA-01 Remove local administrator rights from all office PCs: Head of IT, due 31 Oct 2026, in progress.

PIA-02 Finish separating the warehouse networks from the office network at all three sites (P05 TA-04; two were still joined on 12 Aug): Head of IT, due 11 Sep 2026, done on 11 Sep 2026.

T5-F Keeping the record — EXAMPLE

Kept until

[[6]] years after closure on 21 Aug 2026 (RN-18)

Entered by, and where

Data Protection Officer; entered in the Regulatory Notification Log on adoption, 15 Sep 2026

Document

Relationship

P09 Personal Data Breach Response Playbook

The response, the risk assessment and the decision tree these templates put into words

P09 Incident Communications Template Set

CT-07, CT-08 and CT-04, their approvers and the message approval log

Reportability Decision Model

The GDPR test (DS-06) and the outcomes these templates follow

Regulatory Notification Operating Procedure

Who drafts, reviews, approves and submits (RN-07 to RN-10, RN-14, RN-15)

NIS2 Early Warning, Notification & Final Report Templates

The NIS2 reports for an incident that is also significant

Regulatory Notification Log

Where each decision and submission is logged

Notification Readiness Checklist

The checks that the templates, signatories and channels are ready

P06 Supplier Contract Security Clause Library

CL-07: a supplier's notice within [[24]] hours

Adapting this template

Guidance — delete before approval

Small organisation: you may have no Data Protection Officer. Name the privacy lead in every place this set says Data Protection Officer, and make sure someone else approves and checks (RN-08). Keep Templates 1, 3 and 5; Template 4 only if you process data for others.

Regulated entity: a breach can also be a NIS2 significant incident or, for a financial entity, a major ICT-related incident. Those reports have their own templates and clocks; draft them from the same fact base so the figures agree (RN-11). Sector law may add a breach duty of its own: record it in the applicability profile.

IT run by a service provider: your provider is probably your processor and the first to see a breach. Send it T4-D's questions in advance, and make sure its contract asks for notice within the hours your own clock needs. If you are the provider, Template 4 is yours.

National law: your supervisory authority's form decides the layout, and national law may add content. Map the form to Template 1 before approval, and confirm with counsel. Set every placeholder, including [[lead supervisory authority, or the supervisory authority of the Member State concerned]].

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.34 — Privacy and protection of PII

The whole set: meeting the breach duties that come with protecting personal data

ISO/IEC 27001:2022

Annex A 5.5 — Contact with authorities

Templates 1 and 2: notifying the supervisory authority through its own channel

ISO/IEC 27001:2022

Annex A 5.24 — Information security incident management planning and preparation

The set prepared and approved before any breach, with the authority's form mapped

NIST CSF 2.0

RS.CO-02 — “Internal and external stakeholders are notified of incidents”

Templates 1, 3 and 4: the authority, the people concerned and the controller notified

GDPR — Regulation (EU) 2016/679

Article 33(1) — notify the supervisory authority “without undue delay and, where feasible, not later than 72 hours after having become aware of it”, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons; a later notification gives reasons for the delay

The duties; Template 1, T1-C: the 72 hours and the reasons for delay

GDPR — Regulation (EU) 2016/679

Article 33(2) — “The processor shall notify the controller without undue delay after becoming aware of a personal data breach.”

Template 4: the processor's notice to the controller

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

Template 1: what the notification must contain

GDPR — Regulation (EU) 2016/679

Article 33(4) — information not available at once may be provided in phases without undue further delay

Information in phases; Template 2

GDPR — Regulation (EU) 2016/679

Article 33(5) — the controller documents every personal data breach: the facts, its effects and the remedial action taken

Template 5: the breach record entry

GDPR — Regulation (EU) 2016/679

Article 34(1) — where a breach is likely to result in a high risk to the rights and freedoms of natural persons, communicate it to the data subjects without undue delay

The risk decision: when individuals are told

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)

Template 3 and the plain-language checklist

GDPR — Regulation (EU) 2016/679

Article 34(3) — no communication is required where the data was protected (for example encrypted), where later measures mean the high risk is no longer likely, or where it would involve disproportionate effort (then a public communication instead)

When individuals need not be told; Template 3c

GDPR — Regulation (EU) 2016/679

Article 34(4) — if the controller has not already communicated the breach to the data subjects, the supervisory authority, having considered the likelihood of high risk, may require it to do so or may decide that any of the conditions in Article 34(3) are met

T1-F: the reason individuals were not told

EDPB — Guidelines 9/2022

Paragraph 31 — a controller should be regarded as having become “aware” when it “has a reasonable degree of certainty that a security incident has occurred that has led to personal data being compromised”

The 72 hours: when the controller is aware

GDPR — Regulation (EU) 2016/679

Article 28(3)(f) — the processing contract stipulates that the processor “assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36 taking into account the nature of processing and the information available to the processor”

Template 4: helping the controller with its own duties

GDPR — Regulation (EU) 2016/679

Article 56(1) — the supervisory authority of the main or single establishment of the controller or processor is competent to act as lead supervisory authority for its cross-border processing, without prejudice to Article 55

Which supervisory authority; T1-A

EDPB — Guidelines 9/2022

Paragraph 44 — a processor notifies the controller without first assessing the likelihood of risk, which is for the controller; in principle the controller is “aware” once the processor has informed it

Template 4: the controller judges the risk; its awareness starts on our notice

EDPB — Guidelines 9/2022

Paragraph 69 — for a breach in cross-border processing, notification goes to the lead supervisory authority, not necessarily where the data subjects are or where the breach happened; in doubt, notify at least the local authority where the breach took place

Which supervisory authority, for cross-border processing

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

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.

Breach record

The record of every personal data breach, notified or not: the facts, effects, risk decision and remedial action (RD-08, Article 33(5)).

Doubt point

The time, a fixed number of hours before a regime's first deadline, after which an unsettled decision is treated as Reportable and the report made on the facts known (RN-04).

Fact base

The one record of the incident's facts that every report is drafted from, so reports to different authorities agree (RN-11).

High risk

The risk level at which the people concerned are told (RD-07), unless an Article 34(3) condition is met.

Lead supervisory authority

Under the GDPR, the supervisory authority of the controller's main establishment, which receives the notification where processing crosses borders inside the EU. Otherwise the authority of the Member State concerned.

Not settled

A decision that cannot yet be made because a fact the test needs is still unknown. It always carries the time it will be revisited and is never left open past the doubt point (RN-04).

Personal data breach

GDPR's term: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data.

Phased notification

Giving the information a report needs in stages, as it becomes known, without undue further delay. The GDPR allows it in terms; NIS2 and DORA build it into their staged reports.

Processor

An organisation that processes personal data on the controller's behalf.

RD-nn, CT-nn, RN-nn

A reporting duty and a message of P09's Incident Classification, Severity & Escalation Matrix and Incident Communications Template Set; a rule of the Regulatory Notification Operating Procedure.

Prepared by Zero One Cybersecurity · Published by CISO Times

CISO Times Resource Licence — Internal Use