Identity Incident Communication Template

Notification checklists and fill-in message templates for a credential or session compromise: the GDPR, NIS2 and SEC clocks from official sources, what each notice must contain, and customer, regulator and internal messages with identity-specific actions.

When an identity incident (stolen credentials, hijacked sessions, a compromised admin or integration token) may have exposed data or disrupted a service, several clocks can start at once: data protection regulators, sector cybersecurity authorities, securities regulators, contracts with customers, and the people whose accounts were affected. This template lists the main clocks with their official sources, a checklist for each notice, and fill-in messages that tell customers what happened and exactly what to do about their sessions and credentials. It is not legal advice: confirm with counsel which regimes apply to you before the incident, and record the answer here.

How to use this template

Before an incident: fill section 1 (which regimes apply, who decides, who sends) and get legal sign-off. Pre-approve the message skeletons in section 5.
At detection: open this document alongside the identity incident response runbook. Record the "aware" time in UTC; most clocks run from it.
During the incident: update the fact sheet (section 3) as facts change. Send notices in phases rather than waiting for a complete picture; GDPR allows information in phases, and NIS2 is built on staged reports.
After: file the record (section 7) whether or not you notified anyone.

1. Pre-incident decisions

Question	Answer
Are we a controller or processor of personal data of people in the EU/EEA or UK?	`[ ]`
Are we an essential or important entity under NIS2 in any member state? Which national CSIRT or authority?	`[ ]`
Are we a US public company subject to SEC Form 8-K? Who determines materiality?	`[ ]`
Other regimes (DORA, NYDFS Part 500, HIPAA, state breach laws, sector rules)	`[ ]`
Contractual notice commitments to customers (time, content)	`[ ]`
Decision makers: notify / not notify	`[Legal, DPO, CISO]`
Spokesperson and approvers for external messages	`[ ]`
Out-of-band communication channel if email or chat is compromised	`[ ]`

Look up regime details on the SWI regulations index and the compliance calendar.

2. Notification clocks (official sources)

Regime	Who you tell	Deadline	Clock starts	Source
GDPR Art. 33(1)	Supervisory authority	Without undue delay and, where feasible, not later than 72 hours; if later, give reasons for the delay	When the controller becomes aware of the personal data breach	Regulation (EU) 2016/679; EDPB Guidelines 9/2022
GDPR Art. 33(2)	Controller (if you are a processor)	Without undue delay	When the processor becomes aware	Same
GDPR Art. 34	Affected individuals	Without undue delay, when the breach is likely to result in a high risk to their rights and freedoms	Same as above	Same
NIS2 Art. 23	National CSIRT or competent authority	Early warning within 24 hours; incident notification within 72 hours; final report no later than one month after that	When the entity becomes aware of a significant incident	Directive (EU) 2022/2555; European Commission NIS2 FAQ
SEC Form 8-K Item 1.05	Investors (public filing)	Generally within four business days of determining the incident is material; materiality must be determined without unreasonable delay after discovery	Materiality determination	SEC final rule fact sheet
Contracts	Customers	`[per contract]`	`[ ]`	`[contract ref]`
`[Other]`	`[ ]`	`[ ]`	`[ ]`	`[ ]`

Notes from the sources:

GDPR exemptions. Notification to the authority is not required if the breach is unlikely to result in a risk to individuals. Communication to individuals is not required if, under Art. 34(3), the data was protected (for example by state-of-the-art encryption), later measures mean the high risk is no longer likely, or it would involve disproportionate effort (then a public communication is used instead). Every breach must still be documented under Art. 33(5).
SEC delay. Disclosure may be delayed if the US Attorney General determines that immediate disclosure would pose a substantial risk to national security or public safety and notifies the SEC in writing.
NIS2 national rules. NIS2 is a directive, so the reporting channel and forms are set by each member state's law. Check the national transposition for your authority.

Guidance: for an identity incident, "aware" usually arrives before you know whether personal data was touched. A session hijack on an admin account with access to customer records is a likely personal data breach until the logs show otherwise. Start the clock and stop it with evidence, not the other way round.

3. Incident fact sheet (keep current)

Field	Value
Incident ID	`[ ]`
Aware time (UTC) and how	`[ ]`
Type	`[credential theft / session or token theft / MFA bypass / admin takeover / integration token compromise / insider]`
Identities affected	`[number and type: workforce, customer, admin, service account, OAuth app]`
Systems and data reached	`[ ]`
Categories and approximate number of people affected	`[ ]`
Categories and approximate number of records affected	`[ ]`
Entry vector	`[phishing / infostealer / help desk / leaked secret / third party]`
Containment done	`[sessions revoked, tokens rotated, accounts disabled, apps removed]` with times
Likely consequences for individuals	`[account takeover, fraud, exposure of ...]`
Cross-border impact	`[ ]`
Suspected unlawful or malicious	`[ ]`
Third party involved	`[provider name, their incident reference]`

4. Regulator notification checklist

GDPR Art. 33(3), minimum content:

Nature of the breach, including where possible the categories and approximate number of data subjects and of personal data records concerned.
Name and contact details of the DPO or other contact point.
Likely consequences of the breach.
Measures taken or proposed to address the breach, including measures to mitigate its possible adverse effects.
If notifying after 72 hours: the reasons for the delay.
If information is incomplete: say so, and say when the next update will follow.

NIS2 (per national form):

Early warning within 24 hours of becoming aware. The Commission notes it can also be used to ask for guidance or operational advice on mitigation.
Incident notification within 72 hours of becoming aware, updating the early warning.
Final report no later than one month later.
Content for each stage taken from Article 23 of the Directive and your national authority's form: [link to national form].

SEC Form 8-K Item 1.05:

Material aspects of the nature, scope and timing of the incident.
Material impact or reasonably likely material impact, including on financial condition and results of operations.
Record of when and how materiality was determined.

5. Message templates

5.1 Customer or user notice (credential or session compromise)

Subject: Security notice about your [Product] account

On [date], we found that [an unauthorized party / an attacker using stolen login sessions] accessed [some accounts / your account] on [Product]. We have [ended all active sessions / reset credentials / revoked access tokens] for affected accounts.

What happened: [one or two plain sentences: entry route, time window]

What information was involved: [categories of data, or "we have no evidence that ... was accessed"]

What we have done: [revoked sessions and tokens on date/time; blocked the method used; required re-enrollment of MFA; notified authorities where required]

What you should do now:

Sign in again. You will be asked to [re-verify / re-enroll MFA].

Review recent activity at [link] and tell us about anything you do not recognize.

If you reused your [Product] password elsewhere, change it there.

[For admins:] Review users, admin roles, API keys and connected apps added since [date], and rotate any API keys or integration tokens issued from [Product].

Be careful with messages that claim to be from us. We will never ask for your password or MFA code.

For more information: [status page / FAQ link], [contact]. [DPO contact if applicable].

Guidance: GDPR Art. 34 notices must describe the breach in clear and plain language. The EDPB recommends dedicated messages, not notices buried in newsletters, and says a press release or blog post alone is not an effective way to inform individuals.

5.2 Business customer (B2B) admin notice

To: Security and admin contacts at [Customer]

Incident reference: [ID] | Status: [investigating / contained / resolved] | Next update: [date/time UTC]

Summary: [What happened, when, which of your tenant's identities or data were reached]

Indicators: [IP addresses, user agents, app or token IDs, time window] for your own log searches.

Actions we took on your tenant: [revoked tokens for integration X; rotated keys; disabled support access]

Actions we recommend: revoke and reissue [API keys / OAuth tokens]; review audit logs for [events] between [times]; restrict [integration] to our published IP ranges; confirm no new admins, SSO connections or MFA methods were added.

Your regulatory clocks: if you are a controller for affected personal data, your own notification assessment may be required. Our DPA reference: [ ].

Guidance: in a fan-out breach your customers have their own clocks. Give them indicators and token IDs early so they can scope their own exposure; see the Salesloft Drift incident.

5.3 Internal staff notice

We are responding to a security incident involving [accounts / sessions]. You may be asked to sign in again or re-register MFA. Do not discuss the incident outside [channel]. The security team will never ask for your password or MFA code by phone or chat. Report suspicious messages to [ ].

5.4 Holding statement (media and public)

On [date], [Company] identified unauthorized access to [systems]. We took immediate steps to contain it, including [ ], and are investigating with [outside experts]. We are notifying affected [customers / individuals] and relevant authorities as required. We will share updates at [link].

6. Identity-specific actions to include in every notice

Sessions and refresh tokens revoked (not only passwords reset), with the time.
MFA methods registered during the incident window removed.
OAuth grants, API keys and integration tokens rotated, with the IDs customers should look for.
New admins, SSO or federation connections and mailbox rules checked.
Help desk and recovery path closed if it was the entry route.

7. Record keeping

Item	Kept where	Retention
Fact sheet versions with timestamps	`[ ]`	`[ ]`
Notify / not notify decision with reasons, per regime	`[ ]`	`[ ]`
Copies of every notice sent, recipients, time sent	`[ ]`	`[ ]`
Regulator acknowledgments and reference numbers	`[ ]`	`[ ]`
GDPR Art. 33(5) breach register entry: facts, effects, remedial action	`[ ]`	`[ ]`

Maps to: ISO/IEC 27001:2022 Annex A 5.24 Information security incident management planning and preparation, 5.26 Response to information security incidents, 5.5 Contact with authorities; NIST SP 800-53 Rev. 5 IR-4 Incident Handling, IR-6 Incident Reporting.