# Identity Incident Communication Template

Source: https://startwithidentity.com/templates/identity-incident-communication-template/
Last updated: 2026-11-05
License: content by Start with Identity. Cite the source URL.

---

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

1. **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.
2. **At detection:** open this document alongside the [identity incident response runbook](https://startwithidentity.com/templates/identity-incident-response-runbook/). Record the "aware" time in UTC; most clocks run from it.
3. **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.
4. **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](https://startwithidentity.com/regulations/) and the [compliance calendar](https://startwithidentity.com/regulations/calendar/).

## 2. Notification clocks (official sources)

| Regime | Who you tell | Deadline | Clock starts | Source |
|--------|-------------|----------|--------------|--------|
| [GDPR](https://startwithidentity.com/regulations/european-union/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](https://eur-lex.europa.eu/eli/reg/2016/679/oj/eng); [EDPB Guidelines 9/2022](https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-92022-personal-data-breach-notification-under_en) |
| 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](https://startwithidentity.com/regulations/european-union/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](https://eur-lex.europa.eu/eli/dir/2022/2555/oj); [European Commission NIS2 FAQ](https://digital-strategy.ec.europa.eu/en/faqs/directive-measures-high-common-level-cybersecurity-across-union-nis2-directive-faqs) |
| 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](https://www.sec.gov/files/33-11216-fact-sheet.pdf) |
| 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:**
>
> 1. Sign in again. You will be asked to `[re-verify / re-enroll MFA]`.
> 2. Review recent activity at `[link]` and tell us about anything you do not recognize.
> 3. If you reused your `[Product]` password elsewhere, change it there.
> 4. `[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]`.
> 5. 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](https://startwithidentity.com/glossary/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](https://startwithidentity.com/breaches/incidents/2025-salesloft-drift-oauth-token-theft/).

### 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.

## Related

- [Identity incident response runbook](https://startwithidentity.com/templates/identity-incident-response-runbook/)
- [Identity Breach Database](https://startwithidentity.com/breaches/incidents/) and [Identity Breach Report 2026](https://startwithidentity.com/reports/identity-breach-report-2026/)
- [GDPR for identity systems](https://startwithidentity.com/guides/compliance/gdpr-for-identity-systems/), [identity controls for NIS2](https://startwithidentity.com/guides/compliance/identity-controls-for-nis2/), [identity controls for DORA](https://startwithidentity.com/guides/compliance/identity-controls-for-dora/)
- [Identity threat detection and response guide](https://startwithidentity.com/guides/security/identity-threat-detection-response-guide/)
- [Session cookie theft](https://startwithidentity.com/techniques/session-cookie-theft/), [infostealer credential harvesting](https://startwithidentity.com/techniques/infostealer-credential-harvesting/)