Data Breach Notification Letter Template thirteen sections that turn blank-page drafting into a counsel-ready artefact across every regulator clock
A free, copy-ready data breach notification letter template for CISOs, GRC and compliance teams, privacy officers, incident response leads, SOC managers, internal security teams, AppSec teams, vulnerability management teams, security operations leaders, and disclosure committees. Thirteen structured sections covering letter header and regime in scope and version control, notified-party identification and delivery channel, discovery and confirmation and the regulator-clock chronology, scope and data categories and affected-party counts, cause and root cause and the confirmed-versus-suspected distinction, affected-party impact and realised harm and the risk-of-harm assessment, protective measures recommended and company-funded protective offer, points of contact and the named hotline and inbound inquiry handling, regime-specific carve-outs and statutory exceptions invoked, legal hold and privilege treatment and counsel-reviewed evidence, signature block and named title and named effective date, framework expectations evidenced by the artefact, and lifecycle and supplemental notifications and post-closure obligations. Variant blocks cover GDPR Articles 33 and 34, NIS2 Article 23 early warning and incident notification and final report, SEC Item 1.05 Form 8-K cybersecurity disclosure narrative, the HIPAA Breach Notification Rule across the individual, Secretary, media, and business associate variants, DORA Articles 19 and 20 progression schedule, state breach-notification laws in the United States, the PCI DSS account data compromise pathway, the cyber insurance notice-of-claim pattern, the law-enforcement coordination letter, and the contractual customer notification clause variant. Aligned with ISO/IEC 27001:2022 Annex A 5.24 through 5.28, SOC 2 CC7.3 and CC7.4, NIST SP 800-61 Rev. 2 incident handling, NIST SP 800-53 IR-4 through IR-8, ISO/IEC 27035 incident management, UK PRA SS1/21 and SS2/21 operational resilience and outsourcing, APRA CPS 234, MAS Technology Risk Management Guidelines, FFIEC Information Security Booklet, OCC Heightened Standards, NYDFS Part 500, FINRA cybersecurity obligations, FTC Health Breach Notification Rule, and Gramm-Leach-Bliley Act Safeguards Rule where in scope.
Run breach notification on the live engagement record, not on a hurried Word document
SecPortal opens a breach engagement at the moment a triggering event is suspected so the named incident commander, the named legal counsel, the named disclosure committee chair, the named privacy officer, the named clock chronology, the named materiality determination chain, the named letter drafts, the named counsel review timestamps, and the named delivery confirmations all live on one workspace record with a named-actor activity log. Free plan available.
No credit card required. Free plan available forever.
Thirteen sections that turn breach notification from a blank-page draft into a counsel-ready artefact
A data breach notification letter is the formal written notice a regulated organisation sends to a supervisory authority, an affected individual, a customer, a cyber insurance carrier, or another notified party when a personal-data or regulated-data breach occurs. The letter is not legal advice and does not replace counsel: counsel, the privacy officer, the disclosure committee, and the communications lead read the template into the active incident and use it as the operational skeleton that lets the named GDPR 72-hour clock, the NIS2 24-hour early warning, the SEC four-business-day Item 1.05 clock, the HIPAA 60-day individual notice clock, the DORA progression schedule, the state breach-law clocks, the PCI account data compromise pathway, and the contractual customer notification window all close on time and with defensible language.
The letter template is the formal-correspondence companion to the incident response runbook template (the procedural document the responders read during the active incident), to the security incident severity classification template (the multi-dimensional rubric that decides which severity band the response runs against), to the breach notification and regulator readiness workflow (the engagement-record discipline that holds every clock, materiality determination, and disclosure decision on one trail), to the incident response tabletop exercise template (the simulation that validates the notification capability under pressure), to the audit evidence retention policy template (the named retention overlay that governs how long the engagement record and its attachments stay available to regulator inquiry, customer litigation, and audit-committee read-back), and to the legal hold notice template (the counsel-issued preservation instruction that suspends ordinary-course deletion over the named in-scope evidence for the duration of the matter). Copy the regime-specific variant that matches the matter and replace the variable placeholders from the live engagement record.
Copy the full letter template (all thirteen sections) as one block.
1. Letter header, regime in scope, and version control
Open the letter artefact with the letter identifier (cross-referenced from the incident engagement record), the regime in scope, the named article reference, the named clock anchor, the named clock deadline, the named drafter, the named counsel reviewer, the named approver, and the named sender. A reviewer should be able to read in the first lines which letter this is, which regulator regime it lands against, which clock it is filed against, and where it sits in the progression schedule for that regime. ISO 27001 Clause 7.5 expects documented information with controlled identification and review; the letter is what makes notification evidence traceable across audit cycles and across regulator inquiry reads after the active incident.
Letter identifier (cross-referenced from the incident engagement record): {{LETTER_IDENTIFIER}}
Letter variant (one of: GDPR Article 33 supervisory authority notification, GDPR Article 34 individual notification, NIS2 Article 23 early warning, NIS2 Article 23 incident notification, NIS2 Article 23 final report, NIS2 Article 23 supplemental update, SEC Item 1.05 Form 8-K cybersecurity incident disclosure narrative, SEC Item 1.05 Form 8-K amendment narrative, HIPAA Breach Notification Rule individual notification, HIPAA Breach Notification Rule Secretary notification, HIPAA Breach Notification Rule media notification, HIPAA business-associate-to-covered-entity notification, DORA Article 19 initial notification, DORA Article 19 intermediate report, DORA Article 19 final report, state breach notification individual notification, state breach notification attorney general notification, PCI DSS account data compromise notification, contractual customer notification, cyber insurance carrier notification, law-enforcement coordination letter): {{LETTER_VARIANT}}
Regime article or section reference: {{REGIME_ARTICLE_REFERENCE}}
Named clock anchor (one of: detection timestamp, suspicion-confirmation timestamp, breach-declaration timestamp, materiality-determination timestamp, scope-confirmation timestamp): {{CLOCK_ANCHOR_LABEL}} = {{CLOCK_ANCHOR_TIMESTAMP}}
Named clock deadline: {{CLOCK_DEADLINE_TIMESTAMP}}
Letter position in regime progression schedule (one of: initial notification, early warning, intermediate report, supplemental update, final report, amendment, post-closure supplemental): {{PROGRESSION_POSITION}}
Letter version: v{{LETTER_VERSION}}
Letter drafting date: {{DRAFTING_DATE}}
Letter send-target date: {{SEND_TARGET_DATE}}
Letter actual send date: {{ACTUAL_SEND_DATE}}
Named buyer-side roles:
- Drafter:
- Role: {{DRAFTER_ROLE}}
- Named person at time of publication: {{DRAFTER_NAME}}
- Legal counsel reviewer (external counsel where applicable):
- Firm: {{COUNSEL_FIRM}}
- Named lawyer: {{COUNSEL_NAME}}
- Counsel review timestamp: {{COUNSEL_REVIEW_TIMESTAMP}}
- Privacy officer (for GDPR / HIPAA / state law variants):
- Role: {{PRIVACY_OFFICER_ROLE}}
- Named person: {{PRIVACY_OFFICER_NAME}}
- Disclosure committee chair (for SEC / DORA / NIS2 variants):
- Role: {{DISCLOSURE_CHAIR_ROLE}}
- Named person: {{DISCLOSURE_CHAIR_NAME}}
- Approver (the named officer authorising send):
- Role: {{APPROVER_ROLE}}
- Named person: {{APPROVER_NAME}}
- Approval timestamp: {{APPROVAL_TIMESTAMP}}
- Sender (the named officer or counsel delivering the letter):
- Role: {{SENDER_ROLE}}
- Named person: {{SENDER_NAME}}
Cross-references:
- Incident engagement record reference: {{ENGAGEMENT_RECORD_REFERENCE}}
- Severity classification rubric version applied: {{SEVERITY_RUBRIC_VERSION}}
- Most recent severity band on engagement: {{SEVERITY_BAND}}
- Incident response runbook reference applied: {{RUNBOOK_REFERENCE}}
- Regulator-engagement protocol reference: {{REGULATOR_ENGAGEMENT_PROTOCOL_REFERENCE}}
- Compliance tracking record identifier: {{COMPLIANCE_RECORD_IDENTIFIER}}
Revision history (each entry: letter version, effective date, trigger, author, counsel reviewer, signed-off-by):
- v{{PRIOR_VERSION_1}} effective {{PRIOR_DATE_1}}, trigger {{PRIOR_TRIGGER_1}}, author {{PRIOR_AUTHOR_1}}, counsel {{PRIOR_COUNSEL_1}}, signed {{PRIOR_SIGNATORY_1}}
- v{{PRIOR_VERSION_2}} effective {{PRIOR_DATE_2}}, trigger {{PRIOR_TRIGGER_2}}, author {{PRIOR_AUTHOR_2}}, counsel {{PRIOR_COUNSEL_2}}, signed {{PRIOR_SIGNATORY_2}}
2. Notified party identification and delivery channel
Name the recipient party explicitly: the supervisory authority and the file reference, the affected individual identifier reference, the customer entity, the cyber insurance carrier and policy reference, or the law-enforcement coordination contact. The block also names the delivery channel: the regulator portal, the secure email channel, the postal address, the in-person delivery path, or the contracted customer notification address. Notification that lands on the wrong channel or the wrong addressee fails the regulator clock even when the content is correct.
Notified party (use only the variant that applies to this letter):
[Supervisory authority / regulator variant]
- Authority name: {{AUTHORITY_NAME}}
- Authority jurisdiction: {{AUTHORITY_JURISDICTION}}
- Authority file or case reference (if assigned): {{AUTHORITY_FILE_REFERENCE}}
- Named contact at the authority (if previously established): {{AUTHORITY_NAMED_CONTACT}}
- Delivery channel (named portal, named email, named postal address): {{AUTHORITY_DELIVERY_CHANNEL}}
- Delivery confirmation reference: {{AUTHORITY_DELIVERY_CONFIRMATION}}
[Affected individual variant]
- Recipient class (named natural-person category): {{RECIPIENT_CLASS}}
- Recipient set size (count of letters being sent under this variant): {{RECIPIENT_SET_SIZE}}
- Mailing or contact method (named email broadcast, named postal mailing, named portal in-app message): {{RECIPIENT_DELIVERY_CHANNEL}}
- Bounce-tracking and undelivered-letter handling protocol: {{RECIPIENT_BOUNCE_PROTOCOL}}
- Named call-centre hotline for inbound recipient inquiry: {{RECIPIENT_HOTLINE}}
- Named hotline hours of operation and named multilingual support: {{RECIPIENT_HOTLINE_HOURS}}
[Enterprise customer variant]
- Customer entity legal name: {{CUSTOMER_LEGAL_NAME}}
- Customer relationship reference: {{CUSTOMER_RELATIONSHIP_REFERENCE}}
- Contract reference: {{CUSTOMER_CONTRACT_REFERENCE}}
- Contractual notification clause reference: {{CUSTOMER_CONTRACT_CLAUSE_REFERENCE}}
- Contractual deadline anchored from clock anchor: {{CUSTOMER_CONTRACT_DEADLINE}}
- Customer-side named single point of contact: {{CUSTOMER_NAMED_SPOC}}
- Delivery channel (named secure email, named portal, named encrypted file share): {{CUSTOMER_DELIVERY_CHANNEL}}
[Cyber insurance variant]
- Carrier legal name: {{INSURER_LEGAL_NAME}}
- Policy reference: {{INSURER_POLICY_REFERENCE}}
- Effective date: {{INSURER_POLICY_EFFECTIVE_DATE}}
- Notice-of-claim window from policy: {{INSURER_NOTICE_WINDOW}}
- Named carrier claims contact: {{INSURER_NAMED_CLAIMS_CONTACT}}
- Broker reference: {{INSURER_BROKER_REFERENCE}}
- Delivery channel (named broker portal, named carrier portal, named email): {{INSURER_DELIVERY_CHANNEL}}
[Law-enforcement coordination variant]
- Agency name: {{LE_AGENCY_NAME}}
- Named coordination contact: {{LE_NAMED_CONTACT}}
- Investigation reference (if assigned): {{LE_INVESTIGATION_REFERENCE}}
- Named statutory authority for the coordination: {{LE_STATUTORY_AUTHORITY}}
- Delivery channel: {{LE_DELIVERY_CHANNEL}}
Cross-border coordination block (where the same matter triggers multiple supervisory authorities or multiple regulators concurrently):
- Lead supervisory authority for GDPR Article 56 one-stop-shop matters: {{GDPR_LEAD_SA_NAME}}
- Additional concerned supervisory authorities: {{GDPR_CONCERNED_SA_LIST}}
- DORA home competent authority: {{DORA_HOME_COMPETENT_AUTHORITY}}
- DORA host competent authorities: {{DORA_HOST_COMPETENT_AUTHORITY_LIST}}
- United States state attorney general distribution list (one entry per state in scope): {{US_STATE_AG_LIST}}
- Sector regulator distribution (FFIEC, APRA, FCA, BaFin, FINMA, MAS, OSFI, HKMA, where in scope): {{SECTOR_REGULATOR_LIST}}
3. Discovery, confirmation, and the regulator-clock chronology
Reconstruct the chronology that the regulator and the litigant will read after the fact: the detection timestamp, the suspicion confirmation timestamp, the confirmed breach declaration timestamp, the scope confirmation timestamps, and the clock anchor for the regime in scope. Without an explicit chronology the recipient cannot determine when the clock started, and the company cannot defend the named send-by-deadline posture. The chronology is the spine of the letter.
Detection event:
- Detection method (one of: SOC alert, scanner detection, internal report, customer report, third-party notification, regulator inquiry, dark-web monitoring hit, threat-intelligence feed, named-other): {{DETECTION_METHOD}}
- Detection timestamp (UTC): {{DETECTION_TIMESTAMP_UTC}}
- Detection source identifier (alert ID, ticket ID, report ID, scanner finding ID): {{DETECTION_SOURCE_ID}}
- Detection-to-triage latency: {{DETECTION_TO_TRIAGE_LATENCY}}
Suspicion confirmation event:
- Suspicion confirmation timestamp (UTC): {{SUSPICION_CONFIRMATION_TIMESTAMP_UTC}}
- Named role authorising the suspicion confirmation: {{SUSPICION_CONFIRMATION_AUTHOR_ROLE}}
- Named person authorising at time of publication: {{SUSPICION_CONFIRMATION_AUTHOR_NAME}}
- Named evidence supporting suspicion confirmation (forensic log analysis, scanner evidence chain, anomaly indicator set, third-party advisory): {{SUSPICION_EVIDENCE_LIST}}
Breach declaration event:
- Breach declaration timestamp (UTC): {{BREACH_DECLARATION_TIMESTAMP_UTC}}
- Named role authorising the breach declaration: {{BREACH_DECLARATION_AUTHOR_ROLE}}
- Named person authorising at time of publication: {{BREACH_DECLARATION_AUTHOR_NAME}}
- Severity band on breach declaration: {{BREACH_DECLARATION_SEVERITY}}
- Reclassification chronology (each entry: timestamp, prior band, new band, trigger): {{RECLASSIFICATION_CHRONOLOGY}}
Materiality determination (SEC Item 1.05 and equivalent variants):
- Materiality determination timestamp (UTC): {{MATERIALITY_DETERMINATION_TIMESTAMP_UTC}}
- Disclosure committee chair authorising: {{MATERIALITY_AUTHOR_NAME}}
- Named materiality criteria applied (financial impact, operational disruption, reputational impact, legal liability, customer harm, sector-specific factors): {{MATERIALITY_CRITERIA_APPLIED}}
- Reasoned conclusion: {{MATERIALITY_REASONED_CONCLUSION}}
Scope-confirmation chronology (each entry: timestamp, scope element confirmed, source of confirmation):
- {{SCOPE_CONFIRMATION_EVENT_1}}
- {{SCOPE_CONFIRMATION_EVENT_2}}
- {{SCOPE_CONFIRMATION_EVENT_3}}
Regime clock anchor and deadline (restated for clarity at this position in the letter so the recipient can verify the timing posture):
- Named clock anchor for this regime: {{CLOCK_ANCHOR_LABEL}} = {{CLOCK_ANCHOR_TIMESTAMP}}
- Named clock deadline: {{CLOCK_DEADLINE_TIMESTAMP}}
- Letter actual send date relative to deadline: {{SEND_TIMING_POSTURE}}
- Where letter is filed after deadline, named reasoned justification (GDPR Article 33(1) reasoned delay, equivalent regime carve-out): {{REASONED_DELAY_JUSTIFICATION}}
Investigation ongoing statement:
[ ] Investigation continues at the letter date
[ ] Supplemental notification will follow under regime progression schedule when material new information becomes available
[ ] Named progression schedule cited: {{NAMED_PROGRESSION_SCHEDULE}}
4. Scope, data categories, and affected-party counts
State the scope as known at the letter date with explicit timestamp anchors, named data categories, named record counts, named jurisdictions, named retention class, named processing purposes, and named sensitive-data sub-categories. Where counts are estimated rather than confirmed, name the estimation method. The block also states what is under continuing investigation. The recipient and the regulator need to understand both the certain and the provisional parts of the scope.
Data categories in scope (named at the letter date with timestamp anchor):
- Identifier categories confirmed in scope: {{IDENTIFIER_CATEGORIES_LIST}}
- Contact data confirmed in scope: {{CONTACT_DATA_CATEGORIES_LIST}}
- Financial account or payment-instrument data confirmed in scope: {{FINANCIAL_DATA_CATEGORIES_LIST}}
- Health information confirmed in scope (HIPAA PHI scope, equivalent): {{HEALTH_DATA_CATEGORIES_LIST}}
- Biometric data confirmed in scope: {{BIOMETRIC_DATA_CATEGORIES_LIST}}
- Special-category personal data under GDPR Article 9 confirmed in scope: {{SPECIAL_CATEGORY_LIST}}
- Children data under GDPR Article 8 confirmed in scope: {{CHILDREN_DATA_LIST}}
- Criminal-record data under GDPR Article 10 confirmed in scope: {{CRIMINAL_RECORD_DATA_LIST}}
- Employee or workforce data confirmed in scope: {{EMPLOYEE_DATA_LIST}}
- Authentication credentials confirmed in scope (password hashes, recovery factors, OAuth tokens, session tokens, API keys): {{AUTH_CREDENTIAL_LIST}}
- Other categories named in scope: {{OTHER_DATA_CATEGORIES}}
Affected-party counts (each count anchored to data class and timestamp):
- Confirmed count of affected individuals at letter date: {{CONFIRMED_INDIVIDUAL_COUNT}} as of {{INDIVIDUAL_COUNT_TIMESTAMP}}
- Estimated count of affected individuals at letter date (if counts are provisional): {{ESTIMATED_INDIVIDUAL_COUNT}} as of {{ESTIMATE_TIMESTAMP}}
- Named estimation method (sampling extrapolation, system inventory baseline, log-derived bound, named-other): {{ESTIMATION_METHOD}}
- Count breakdown by jurisdiction (one row per jurisdiction in scope): {{JURISDICTION_BREAKDOWN}}
- Count breakdown by data class (one row per data class in scope): {{DATA_CLASS_BREAKDOWN}}
- Count breakdown by customer (for enterprise customer variant, one row per customer entity in scope): {{CUSTOMER_BREAKDOWN}}
Processing purposes named in scope:
- Named processing purpose 1 (with retention class and legal basis): {{PROCESSING_PURPOSE_1}}
- Named processing purpose 2: {{PROCESSING_PURPOSE_2}}
- Named processing purpose 3: {{PROCESSING_PURPOSE_3}}
Cross-border processing in scope (named source and destination jurisdictions with named transfer mechanism):
- Source jurisdiction: {{SOURCE_JURISDICTION}}
- Destination jurisdictions confirmed in scope: {{DESTINATION_JURISDICTION_LIST}}
- Named transfer mechanism (GDPR Standard Contractual Clauses 2021 module, Binding Corporate Rules, named adequacy decision, named-other): {{TRANSFER_MECHANISM}}
- Transfer Impact Assessment on file (reference): {{TIA_REFERENCE}}
Investigation continuing statement on scope:
[ ] Data categories named above are confirmed at letter date and may expand
[ ] Affected-party counts named above are confirmed at letter date and may revise upward
[ ] Estimation method named above will be replaced by confirmed counts when the inventory completes
[ ] Supplemental notification will provide updated scope under the named progression schedule
5. Cause, root cause, and the confirmed-vs-suspected distinction
State the cause as known at the letter date with explicit distinction between confirmed and suspected vectors. Counsel sign-off on this block is non-negotiable because the named exploitation chain, the named third-party causation language, and the named human-factor trigger become part of the evidentiary record for downstream regulator inquiry, customer litigation, and shareholder action.
Confirmed at letter date (named technical or human-factor vector independently verified by forensic evidence):
- Named exploitation chain confirmed: {{CONFIRMED_EXPLOITATION_CHAIN}}
- Named technical vector confirmed (credential compromise via phishing, exploitable vulnerability under active exploitation, misconfigured access control, insider misuse, third-party dependency compromise, supply-chain compromise, named-other): {{CONFIRMED_TECHNICAL_VECTOR}}
- Named affected system, application, or data store confirmed: {{CONFIRMED_AFFECTED_SYSTEM}}
- Forensic evidence cross-reference (case file, log range, indicator set): {{FORENSIC_EVIDENCE_REFERENCE}}
Suspected at letter date (additional candidate vectors under investigation, explicitly unconfirmed):
- Named candidate vector 1: {{SUSPECTED_VECTOR_1}}
- Named candidate vector 2: {{SUSPECTED_VECTOR_2}}
- Investigation status on suspected vectors: {{SUSPECTED_VECTORS_STATUS}}
- Explicit statement that suspected vectors are unconfirmed and the letter does not attribute the breach to them at this stage: {{UNCONFIRMED_DISCLAIMER}}
Root cause class (the broader systemic factor under investigation, named at letter date):
- Control gap class: {{ROOT_CAUSE_CONTROL_GAP}}
- Monitoring gap class: {{ROOT_CAUSE_MONITORING_GAP}}
- Identity governance gap: {{ROOT_CAUSE_IDENTITY_GAP}}
- Supply-chain weakness: {{ROOT_CAUSE_SUPPLY_CHAIN}}
- Configuration drift: {{ROOT_CAUSE_CONFIGURATION_DRIFT}}
- Architectural pattern: {{ROOT_CAUSE_ARCHITECTURE}}
- Other named class: {{ROOT_CAUSE_OTHER}}
Containment status (named actions executed against the active incident):
[ ] Named containment action 1 executed at {{CONTAINMENT_TIMESTAMP_1}}: {{CONTAINMENT_ACTION_1}}
[ ] Named containment action 2 executed at {{CONTAINMENT_TIMESTAMP_2}}: {{CONTAINMENT_ACTION_2}}
[ ] Named containment action 3 executed at {{CONTAINMENT_TIMESTAMP_3}}: {{CONTAINMENT_ACTION_3}}
Remediation in flight (named actions scheduled with named target close dates):
[ ] Named remediation action 1 target close {{REMEDIATION_TARGET_1}}: {{REMEDIATION_ACTION_1}}
[ ] Named remediation action 2 target close {{REMEDIATION_TARGET_2}}: {{REMEDIATION_ACTION_2}}
[ ] Named remediation action 3 target close {{REMEDIATION_TARGET_3}}: {{REMEDIATION_ACTION_3}}
Compensating controls operating during remediation (named monitoring posture introduced):
[ ] Named compensating control 1: {{COMPENSATING_CONTROL_1}}
[ ] Named compensating control 2: {{COMPENSATING_CONTROL_2}}
[ ] Named compensating control 3: {{COMPENSATING_CONTROL_3}}
Counsel-reviewed statement on root cause attribution:
[ ] The cause and root cause block has been reviewed by named counsel ({{COUNSEL_NAME}}) before send
[ ] Named privilege treatment applied to detailed forensic findings: attorney-client privilege and work-product doctrine where applicable
[ ] Named contact for further regulator inquiry on detailed forensic findings: {{COUNSEL_FURTHER_INQUIRY_CONTACT}}
[ ] Investigation under attorney-client privilege: explicit statement that detailed forensic findings beyond the named confirmed cause are protected from disclosure outside the privileged channel
6. Affected-party impact, realised harm, and risk-of-harm assessment
Describe the realised harm and the assessed risk-of-harm categories with explicit anchored examples of what individuals or customers could experience. The block also addresses regime-specific harm thresholds (HIPAA low-probability exception four-factor analysis, GDPR Article 34 high-risk threshold, state breach-law risk-of-harm thresholds). Without an explicit harm analysis the regulator cannot evaluate whether individual notification was required.
Realised harm categories (what affected parties are confirmed to have experienced at the letter date):
- Financial harm: {{REALISED_FINANCIAL_HARM}}
- Identity-misuse harm: {{REALISED_IDENTITY_HARM}}
- Service-disruption harm: {{REALISED_SERVICE_HARM}}
- Reputational harm to affected parties: {{REALISED_REPUTATIONAL_HARM}}
- Physical or safety harm: {{REALISED_PHYSICAL_HARM}}
- Discrimination or denial-of-service harm: {{REALISED_DISCRIMINATION_HARM}}
- Other named harm: {{REALISED_OTHER_HARM}}
Risk-of-harm assessment (categories the affected parties may experience based on the named data classes in scope):
- Identity theft risk: {{RISK_IDENTITY_THEFT}}
- Account takeover risk: {{RISK_ACCOUNT_TAKEOVER}}
- Payment-instrument fraud risk: {{RISK_PAYMENT_FRAUD}}
- Tax-fraud or government-benefit-fraud risk: {{RISK_TAX_FRAUD}}
- Health-insurance-fraud risk: {{RISK_HEALTH_FRAUD}}
- Targeted phishing risk: {{RISK_TARGETED_PHISHING}}
- Reputational or social-engineering risk: {{RISK_REPUTATIONAL}}
- Children-specific risk under GDPR Article 8: {{RISK_CHILDREN}}
- Special-category data risk under GDPR Article 9: {{RISK_SPECIAL_CATEGORY}}
[HIPAA variant only: four-factor risk assessment under the Breach Notification Rule]
- Factor 1: the nature and extent of the PHI involved (named identifiers, sensitive categories): {{HIPAA_FACTOR_1}}
- Factor 2: the unauthorised person who used the PHI or to whom the disclosure was made: {{HIPAA_FACTOR_2}}
- Factor 3: whether the PHI was actually acquired or viewed: {{HIPAA_FACTOR_3}}
- Factor 4: the extent to which the risk to the PHI has been mitigated: {{HIPAA_FACTOR_4}}
- Risk assessment conclusion (one of: high probability of compromise / low probability of compromise): {{HIPAA_RISK_CONCLUSION}}
- If low probability, named compensating mitigation supporting the conclusion: {{HIPAA_LOW_PROBABILITY_BASIS}}
[GDPR variant only: high-risk threshold determination under Article 34]
- Named risk factors evaluated: {{GDPR_RISK_FACTORS}}
- Named risk-magnitude assessment: {{GDPR_RISK_MAGNITUDE}}
- Conclusion on Article 34 obligation (one of: individual notification required / individual notification not required / public communication issued under Article 34(3)(c) in lieu of direct individual notification): {{GDPR_ARTICLE_34_CONCLUSION}}
- Named reasoned basis for the conclusion: {{GDPR_ARTICLE_34_BASIS}}
[State breach-law variant only: state risk-of-harm threshold determinations]
- State 1 (named statute, named threshold framework): {{STATE_1_RISK_DETERMINATION}}
- State 2 (named statute, named threshold framework): {{STATE_2_RISK_DETERMINATION}}
- State 3 (named statute, named threshold framework): {{STATE_3_RISK_DETERMINATION}}
- Named encryption safe harbour considered (Massachusetts, California, Texas, named-other): {{ENCRYPTION_SAFE_HARBOUR_DETERMINATION}}
Counsel-reviewed statement on harm assessment:
[ ] The risk-of-harm block has been reviewed by named counsel ({{COUNSEL_NAME}}) before send
[ ] Named risk-assessment record retained on the engagement: {{RISK_ASSESSMENT_RECORD_REFERENCE}}
7. Protective measures recommended and company-funded protective offer
Name the protective measures the recipient should consider taking: credential rotation, monitoring enrolment, payment-instrument cancellation, identity-monitoring enrolment, tax-fraud monitoring, vigilance against phishing referencing the breach. Where the company is funding a protective offer (identity-monitoring service, credit-monitoring enrolment, dedicated hotline), the block also names the offer, the duration, the enrolment pathway, and the named customer-service contact. Counsel reviews this block because the named protective offer becomes a contractual obligation once committed in writing.
Protective measures the recipient should consider (one row per measure with explicit applicability based on data classes in scope):
[ ] Credential rotation on the affected service if account password or recovery factors were in scope: {{CREDENTIAL_ROTATION_INSTRUCTION}}
[ ] Credential reuse audit across other services where the recipient used the same password: {{CREDENTIAL_REUSE_AUDIT_INSTRUCTION}}
[ ] Multi-factor authentication enrolment or strengthening where not already in place: {{MFA_INSTRUCTION}}
[ ] Identity-monitoring enrolment if identifiers or sensitive categories were in scope: {{IDENTITY_MONITORING_INSTRUCTION}}
[ ] Credit-monitoring enrolment if financial account or identifier data was in scope: {{CREDIT_MONITORING_INSTRUCTION}}
[ ] Payment-instrument cancellation or replacement if payment data was in scope: {{PAYMENT_CANCELLATION_INSTRUCTION}}
[ ] Tax-fraud monitoring if Social Security or government-identifier data was in scope: {{TAX_FRAUD_MONITORING_INSTRUCTION}}
[ ] Health-insurance-fraud monitoring if PHI was in scope: {{HEALTH_FRAUD_MONITORING_INSTRUCTION}}
[ ] Vigilance against phishing attempts referencing the breach: {{PHISHING_VIGILANCE_INSTRUCTION}}
[ ] Named credit-bureau fraud alert pathways (United States variant): Experian, Equifax, TransUnion fraud alert and security freeze pathways with named contact instructions
[ ] Named FTC identity theft reporting pathway (United States variant): IdentityTheft.gov with named workflow instructions
[ ] Named state attorney general complaint pathways (United States variant): {{STATE_AG_COMPLAINT_PATHWAYS}}
[ ] GDPR data subject access rights pathway (EU and UK variant): named controller contact for data subject access requests, named supervisory authority complaint pathway
Company-funded protective offer (if the company is providing protective services to affected parties):
- Named protective service: {{PROTECTIVE_SERVICE_NAME}}
- Named service provider: {{PROTECTIVE_SERVICE_PROVIDER}}
- Named duration of offer: {{PROTECTIVE_OFFER_DURATION}}
- Named enrolment pathway (web URL, named code, named hotline): {{PROTECTIVE_ENROLMENT_PATHWAY}}
- Named enrolment deadline: {{PROTECTIVE_ENROLMENT_DEADLINE}}
- Named cost coverage (full company-funded / co-pay / no-cost-to-recipient): {{PROTECTIVE_COST_COVERAGE}}
- Named coverage for dependents or family members in scope: {{PROTECTIVE_DEPENDENT_COVERAGE}}
- Named restoration support included (named identity restoration service): {{PROTECTIVE_RESTORATION_SUPPORT}}
- Named opt-out mechanism if the recipient declines: {{PROTECTIVE_OPT_OUT_MECHANISM}}
Counsel-reviewed statement on protective offer:
[ ] The protective measures and company-funded offer block has been reviewed by named counsel ({{COUNSEL_NAME}}) before send
[ ] The protective offer commitments are reviewed against the existing customer contract, the existing privacy policy, and the existing communication that may have been issued before the letter date
[ ] The protective offer is reviewed against state-specific obligations where the state requires a named minimum offer (named state, named statute, named minimum offer): {{STATE_SPECIFIC_PROTECTIVE_OFFER_OBLIGATIONS}}
8. Points of contact, named hotline, and inbound inquiry handling
Provide a single named contact path the recipient can use: a named hotline with named hours of operation and multilingual support, a named email address, and a named web reference. Provide also a single named buyer-side contact for follow-up regulator inquiry. Without a clearly named single point of contact the regulator inquiry stalls in the company switchboard and the affected-individual call volume saturates an unprepared customer service team.
Named recipient-facing hotline (for affected-individual variant and customer variant):
- Hotline phone number (named local-rate or toll-free where applicable per jurisdiction): {{HOTLINE_PHONE}}
- Hotline hours of operation (named timezone and named hours): {{HOTLINE_HOURS}}
- Named multilingual support (named languages and named hours per language): {{HOTLINE_LANGUAGES}}
- Hotline expected wait-time posture during peak hours: {{HOTLINE_WAIT_POSTURE}}
- Named named-hotline knowledge base reference for recipient self-service: {{HOTLINE_KB_REFERENCE}}
Named recipient-facing email address:
- Inbound email address (named domain-aligned email address dedicated to the matter): {{INBOUND_EMAIL}}
- Email response SLA: {{INBOUND_EMAIL_SLA}}
- Email signature posture: {{INBOUND_EMAIL_SIGNATURE_POSTURE}}
Named recipient-facing web page:
- Web page URL: {{INBOUND_WEB_PAGE_URL}}
- Web page content covers: named context, named protective measures, named enrolment pathway for the company-funded protective offer, named FAQ, named contact options
- Web page accessibility posture: {{WEB_PAGE_ACCESSIBILITY_POSTURE}}
Named buyer-side single point of contact for regulator follow-up inquiry:
- Role: {{REGULATOR_SPOC_ROLE}}
- Named person at time of publication: {{REGULATOR_SPOC_NAME}}
- Contact email: {{REGULATOR_SPOC_EMAIL}}
- Contact phone: {{REGULATOR_SPOC_PHONE}}
- Named delegation authority for regulator-correspondence release: {{REGULATOR_SPOC_DELEGATION}}
Named buyer-side single point of contact for enterprise customer follow-up inquiry:
- Role: {{CUSTOMER_SPOC_ROLE}}
- Named person at time of publication: {{CUSTOMER_SPOC_NAME}}
- Contact email: {{CUSTOMER_SPOC_EMAIL}}
- Contact phone: {{CUSTOMER_SPOC_PHONE}}
Named buyer-side single point of contact for legal counsel correspondence:
- Firm: {{COUNSEL_FIRM}}
- Named lawyer: {{COUNSEL_NAME}}
- Contact email: {{COUNSEL_EMAIL}}
- Contact phone: {{COUNSEL_PHONE}}
- Named privilege treatment for inbound regulator correspondence routed through counsel: {{COUNSEL_PRIVILEGE_TREATMENT}}
Inbound inquiry capacity planning (operational block, not for publication on outbound letter):
- Expected inbound call volume during the active phase: {{INBOUND_VOLUME_FORECAST}}
- Named call-centre capacity ramp plan: {{CALL_CENTRE_RAMP_PLAN}}
- Named call-centre script reference: {{CALL_CENTRE_SCRIPT_REFERENCE}}
- Named call-centre escalation runbook for high-sensitivity inbound: {{CALL_CENTRE_ESCALATION_RUNBOOK}}
- Named training cadence for call-centre staff on the matter: {{CALL_CENTRE_TRAINING_CADENCE}}
9. Regime-specific carve-outs and statutory exceptions invoked
Name the regime-specific obligations and exceptions: GDPR Article 34 high-risk threshold for individual notification, HIPAA low-probability exception scope under the four-factor risk assessment, SEC delayed-disclosure carve-out under Attorney General national security determination, NIS2 cross-border notification mechanism, DORA progression schedule, state encryption safe harbours, contractual notification carve-outs. Without an explicit statement of which carve-out is invoked, the regulator and the litigant cannot evaluate whether the company correctly identified the obligation it was operating against.
[GDPR variant carve-outs]
[ ] GDPR Article 33(1) supervisory authority notification obligation invoked
[ ] GDPR Article 33(1) reasoned delay claim: {{GDPR_REASONED_DELAY_BASIS}}
[ ] GDPR Article 33(5) controller documentation obligation evidenced: {{GDPR_CONTROLLER_DOCUMENTATION_REFERENCE}}
[ ] GDPR Article 34(1) individual notification obligation invoked
[ ] GDPR Article 34(3)(a) individual notification exemption claimed (appropriate technical and organisational measures rendering data unintelligible): {{GDPR_34_3_A_BASIS}}
[ ] GDPR Article 34(3)(b) individual notification exemption claimed (subsequent measures rendering high risk no longer likely): {{GDPR_34_3_B_BASIS}}
[ ] GDPR Article 34(3)(c) public communication issued in lieu of direct individual notification (disproportionate effort): {{GDPR_34_3_C_BASIS}}
[ ] GDPR Article 56 one-stop-shop lead supervisory authority identified: {{GDPR_LEAD_SA_IDENTIFIED}}
[HIPAA variant carve-outs]
[ ] HIPAA Breach Notification Rule individual notification obligation invoked
[ ] HIPAA four-factor risk assessment conducted and documented at engagement reference: {{HIPAA_RISK_ASSESSMENT_REFERENCE}}
[ ] HIPAA low-probability-of-compromise exception invoked: {{HIPAA_LOW_PROBABILITY_INVOCATION}}
[ ] HIPAA 500-or-more breach Secretary notification within 60 days obligation invoked
[ ] HIPAA 500-or-more breach prominent media outlet notification obligation invoked
[ ] HIPAA business-associate-to-covered-entity notification within 60 days obligation invoked
[SEC variant carve-outs]
[ ] SEC Item 1.05 Form 8-K disclosure obligation invoked
[ ] Materiality determination documented at engagement reference: {{SEC_MATERIALITY_REFERENCE}}
[ ] Item 1.05(c) amendment posture established for material information becoming available: {{SEC_AMENDMENT_POSTURE}}
[ ] Item 1.05(d) Attorney General national security or public safety delayed-disclosure carve-out invoked: {{SEC_DELAYED_DISCLOSURE_INVOCATION}}
[ ] If carve-out invoked, named Attorney General determination reference: {{SEC_AG_DETERMINATION_REFERENCE}}
[NIS2 variant carve-outs]
[ ] NIS2 Article 23 early warning within 24 hours filed: {{NIS2_EARLY_WARNING_TIMESTAMP}}
[ ] NIS2 Article 23 incident notification within 72 hours filed: {{NIS2_INCIDENT_NOTIFICATION_TIMESTAMP}}
[ ] NIS2 Article 23 final report within one month filed or scheduled: {{NIS2_FINAL_REPORT_POSTURE}}
[ ] NIS2 cross-border notification mechanism applied to named additional Member State authorities: {{NIS2_CROSS_BORDER_MECHANISM}}
[DORA variant carve-outs]
[ ] DORA Article 19 major-incident classification documented: {{DORA_CLASSIFICATION_REFERENCE}}
[ ] DORA Article 19 initial notification within four hours filed: {{DORA_INITIAL_TIMESTAMP}}
[ ] DORA Article 19 intermediate report within 72 hours filed: {{DORA_INTERMEDIATE_TIMESTAMP}}
[ ] DORA Article 19 final report within one month filed or scheduled: {{DORA_FINAL_POSTURE}}
[ ] DORA Article 20 home and host competent authority coordination applied: {{DORA_COORDINATION_REFERENCE}}
[State breach-law variant carve-outs]
[ ] State law in scope and named statute reference: {{STATE_STATUTE_LIST}}
[ ] State encryption safe harbour claimed (named state, named statute, named basis): {{ENCRYPTION_SAFE_HARBOUR_DECLARATION}}
[ ] State risk-of-harm threshold determination (named state, named conclusion): {{STATE_RISK_THRESHOLD_DECLARATION}}
[ ] State attorney general notification filed (one row per state): {{STATE_AG_FILING_LIST}}
[ ] State law enforcement coordination hold invoked (named state, named period): {{STATE_LE_HOLD_DECLARATION}}
[PCI DSS variant carve-outs]
[ ] PCI DSS account data compromise notification filed with named acquirer and named payment brand: {{PCI_ACQUIRER_BRAND_NOTIFICATION}}
[ ] Named forensic investigator engaged per payment brand requirements: {{PCI_FORENSIC_INVESTIGATOR}}
[Contractual customer carve-outs]
[ ] Contractual customer notification clause obligation invoked: {{CUSTOMER_CONTRACT_OBLIGATION}}
[ ] Contractual indemnification posture established: {{CUSTOMER_INDEMNIFICATION_POSTURE}}
[ ] Customer cooperation commitments documented: {{CUSTOMER_COOPERATION_COMMITMENTS}}
Counsel-reviewed statement on carve-out invocations:
[ ] Each invoked carve-out has been reviewed by named counsel ({{COUNSEL_NAME}}) before send
[ ] Counsel reviewed risk has been documented in the privileged engagement record cross-reference: {{COUNSEL_PRIVILEGE_RECORD_REFERENCE}}
10. Legal hold, privilege treatment, and counsel-reviewed evidence
Name the legal-hold scope, the named retention overlay applied to incident artefacts, the privileged-evidence treatment for detailed forensic findings, and the named cross-references to the incident engagement record. The block makes the evidence custody chain defensible against later litigation discovery, regulator inquiry, and audit reads, by stating explicitly what is retained, where it is retained, who can access it, and how privilege is preserved.
Legal-hold scope:
- Legal hold issued at timestamp: {{LEGAL_HOLD_ISSUE_TIMESTAMP}}
- Named counsel issuing the legal hold: {{LEGAL_HOLD_ISSUING_COUNSEL}}
- Named scope of the legal hold (named custodians, named systems, named data classes, named date ranges): {{LEGAL_HOLD_SCOPE_DETAIL}}
- Named retention overlay applied (overrides standard retention policy where the hold scope applies): {{LEGAL_HOLD_RETENTION_OVERLAY}}
- Named legal-hold acknowledgement protocol per custodian: {{LEGAL_HOLD_ACKNOWLEDGEMENT_PROTOCOL}}
- Named legal-hold release protocol when hold is lifted: {{LEGAL_HOLD_RELEASE_PROTOCOL}}
Privileged-evidence treatment:
[ ] Detailed forensic findings beyond the named confirmed cause are protected under attorney-client privilege and work-product doctrine where applicable
[ ] Named forensic investigator engaged under counsel direction: {{FORENSIC_INVESTIGATOR_NAME}}
[ ] Named engagement letter establishing privilege: {{FORENSIC_ENGAGEMENT_LETTER_REFERENCE}}
[ ] Named privilege log maintained on the engagement record: {{PRIVILEGE_LOG_REFERENCE}}
[ ] Named privileged-document storage with restricted access: {{PRIVILEGED_STORAGE_REFERENCE}}
[ ] Named RBAC restriction on workspace access to privileged folder: {{PRIVILEGED_RBAC_REFERENCE}}
Counsel-reviewed evidence (the categories of evidence that have been reviewed by counsel for release with the letter):
- Forensic logs and indicator analysis: {{FORENSIC_LOGS_REVIEW_STATUS}}
- Scope-determination memos and timeline reconstruction: {{SCOPE_MEMO_REVIEW_STATUS}}
- Materiality-determination minutes (SEC variant): {{MATERIALITY_MINUTES_REVIEW_STATUS}}
- Disclosure-committee minutes (SEC, DORA, NIS2 variants): {{DISCLOSURE_COMMITTEE_MINUTES_REVIEW_STATUS}}
- Privacy officer risk-assessment record (GDPR, HIPAA, state law variants): {{PRIVACY_OFFICER_RECORD_REVIEW_STATUS}}
- Insurance carrier notice-of-claim correspondence: {{INSURER_CORRESPONDENCE_REVIEW_STATUS}}
- Law-enforcement coordination correspondence: {{LE_COORDINATION_REVIEW_STATUS}}
Cross-references to the incident engagement record (for internal audit-chain reconstruction; not for publication on outbound letter):
- Incident engagement record reference: {{ENGAGEMENT_RECORD_REFERENCE}}
- Severity classification rubric application: {{SEVERITY_RUBRIC_REFERENCE}}
- Incident response runbook application: {{RUNBOOK_REFERENCE}}
- Regulator-engagement protocol application: {{REGULATOR_ENGAGEMENT_PROTOCOL_REFERENCE}}
- Activity log retention class applied to the engagement: {{ACTIVITY_LOG_RETENTION_CLASS}}
- Document management retention class applied to the engagement: {{DOCUMENT_MANAGEMENT_RETENTION_CLASS}}
- Findings management cross-reference to the underlying breach finding records: {{FINDINGS_CROSS_REFERENCE}}
- Compliance tracking cross-reference to the named framework controls evidenced: {{COMPLIANCE_CROSS_REFERENCE}}
11. Signature block, named title, named effective date
Close the letter with a defensible signature block: the named signatory, the named title, the named effective date, the named approval timestamp, the named delivery confirmation, and the named version reference. The signature line is what regulators, auditors, and litigants read first when reconstructing what the company committed to in writing.
Sincerely,
____________________________________________
{{SIGNATORY_NAME}}
{{SIGNATORY_TITLE}}
{{SIGNATORY_ORGANISATION}}
Effective date: {{SIGNATURE_EFFECTIVE_DATE}}
[For HIPAA covered-entity individual notification variant]
This notification is provided in accordance with the Health Insurance Portability and Accountability Act of 1996 Breach Notification Rule at 45 CFR Part 164 Subpart D. The named privacy officer is {{PRIVACY_OFFICER_NAME}}, contactable at {{PRIVACY_OFFICER_EMAIL}}.
[For HIPAA Secretary notification variant]
This notification is submitted to the Secretary of the United States Department of Health and Human Services in accordance with 45 CFR 164.408. Submitting entity: {{COVERED_ENTITY_NAME}}; OCR submitting agent: {{OCR_AGENT_NAME}}.
[For GDPR supervisory authority variant]
This notification is provided pursuant to Article 33 of Regulation (EU) 2016/679 (the General Data Protection Regulation). Controller named contact: {{CONTROLLER_NAMED_CONTACT}}. Data Protection Officer named contact: {{DPO_NAMED_CONTACT}}.
[For GDPR individual notification variant]
This communication is provided pursuant to Article 34 of Regulation (EU) 2016/679 (the General Data Protection Regulation). For data subject access requests, contact {{CONTROLLER_DSR_CONTACT}}. To lodge a complaint with the supervisory authority, contact {{SUPERVISORY_AUTHORITY_CONTACT}}.
[For NIS2 variant]
This notification is provided pursuant to Article 23 of Directive (EU) 2022/2555 (NIS2 Directive). Filing entity: {{NIS2_ENTITY_NAME}}; named single point of contact for follow-up: {{NIS2_NAMED_SPOC}}.
[For DORA variant]
This notification is provided pursuant to Articles 19 and 20 of Regulation (EU) 2022/2554 (DORA Regulation). Filing financial entity: {{DORA_ENTITY_NAME}}; named single point of contact for follow-up: {{DORA_NAMED_SPOC}}.
[For SEC Item 1.05 variant: this is the narrative prepared for the Form 8-K filing rather than a private letter]
Item 1.05 of Form 8-K. Cybersecurity Incident.
On {{DETERMINATION_DATE}}, {{REGISTRANT_NAME}} determined that the cybersecurity incident first detected on {{DETECTION_DATE}} is reasonably likely to have a material impact on the registrant's financial condition and results of operations. The material aspects of the nature, scope, and timing of the incident, and the material impact or reasonably likely material impact on the registrant, are as set out in the narrative above. The registrant intends to amend this Form 8-K to disclose material new information when it becomes available pursuant to Item 1.05(c).
[For state breach-law variant]
This notification is provided in accordance with {{STATE_STATUTE_REFERENCE}}. Recipient state: {{RECIPIENT_STATE}}. Named buyer-side privacy officer: {{PRIVACY_OFFICER_NAME}}. To request additional information or lodge a complaint with the state attorney general, contact {{STATE_AG_CONTACT}}.
[For enterprise customer variant]
This notification is provided in accordance with Section {{CONTRACT_CLAUSE_REFERENCE}} of the master service agreement effective {{CONTRACT_EFFECTIVE_DATE}}. Named buyer-side single point of contact: {{CUSTOMER_NAMED_SPOC}}. Indemnification claim notification pathway: {{INDEMNIFICATION_PATHWAY}}.
Delivery confirmation:
- Letter version on send: v{{SENT_LETTER_VERSION}}
- Send timestamp (UTC): {{ACTUAL_SEND_TIMESTAMP_UTC}}
- Delivery channel confirmed: {{DELIVERY_CHANNEL_CONFIRMED}}
- Delivery confirmation reference: {{DELIVERY_CONFIRMATION_REFERENCE}}
- Receipt acknowledgement received timestamp (where applicable): {{RECEIPT_ACK_TIMESTAMP}}
12. Framework expectations evidenced by the letter artefact
Capture the regulatory and assurance-framework expectations the letter evidences so the artefact slots into the audit pack alongside the engagement record, the runbook, the severity rubric, and the regulator-engagement protocol. The map shows the auditor, the cyber insurer, the audit committee, and the next external assurance cycle that the notification discipline is operating on a named, defensible standard rather than ad hoc.
GDPR (Regulation (EU) 2016/679):
- Article 33 controller notification to supervisory authority (72-hour clock from awareness)
- Article 34 individual notification (high-risk threshold)
- Article 33(5) controller documentation obligation
- Article 56 one-stop-shop lead supervisory authority coordination
- Article 28 processor obligations (where the breach implicates a processor relationship)
- Article 32 security of processing (the technical and organisational measures the controller maintained)
UK GDPR and Data Protection Act 2018:
- Equivalent obligations to GDPR Articles 33 and 34 with the Information Commissioner's Office named as the supervisory authority
- DPA 2018 Part 3 law-enforcement-purposes provisions where applicable
EU NIS2 Directive (Directive (EU) 2022/2555):
- Article 23 early warning (24 hours), incident notification (72 hours), final report (one month), interim updates on request
- Member-State transposition references to be named per affected jurisdiction
EU DORA Regulation (Regulation (EU) 2022/2554):
- Article 19 major-incident notification (initial within four hours, intermediate within 72 hours, final within one month)
- Article 20 cross-border coordination between home and host competent authorities
US HIPAA Breach Notification Rule (45 CFR Part 164 Subpart D):
- 164.404 notification to affected individuals
- 164.406 notification to the media (for breaches affecting 500+ in a state or jurisdiction)
- 164.408 notification to the Secretary of HHS
- 164.410 notification by business associate to covered entity
- 164.402(2) low-probability-of-compromise exception with four-factor risk assessment
US SEC Item 1.05 of Form 8-K and Regulation S-K Item 106:
- Item 1.05 disclosure of material cybersecurity incidents within four business days of materiality determination
- Item 1.05(c) amendment when material information becomes available
- Item 1.05(d) Attorney General national security or public safety delayed disclosure carve-out
- Regulation S-K Item 106 annual cybersecurity governance and risk management disclosure
US state breach-notification laws (named per state in scope; statutes vary):
- California Civil Code 1798.82 and 1798.84
- New York General Business Law 899-aa and 899-bb
- Texas Business and Commerce Code 521.053
- Massachusetts General Laws Chapter 93H
- Washington RCW 19.255
- Illinois 815 ILCS 530 (Personal Information Protection Act)
- Florida Statutes 501.171
- Other applicable state laws per jurisdiction in scope
US Federal Trade Commission Health Breach Notification Rule (16 CFR Part 318) where applicable.
US Gramm-Leach-Bliley Act Safeguards Rule (16 CFR Part 314) where applicable.
PCI DSS Requirement 12.10 incident response and account data compromise reporting expectations.
ISO/IEC 27001:2022 Annex A:
- A.5.24 information security incident management planning and preparation
- A.5.25 assessment and decision on information security events
- A.5.26 response to information security incidents
- A.5.27 learning from information security incidents
- A.5.28 collection of evidence
- A.5.34 privacy and protection of PII
ISO/IEC 27035 information security incident management standard.
NIST SP 800-61 Rev. 2 Computer Security Incident Handling Guide:
- Section 3.2 incident response phases
- Section 4 handling an incident
NIST SP 800-53 Rev. 5:
- IR-4 incident handling
- IR-6 incident reporting
- IR-8 incident response plan
SOC 2 (AICPA Trust Services Criteria):
- CC7.3 incident assessment and response
- CC7.4 communication of identified incidents
- CC2.3 communication with external parties
UK PRA SS1/21 and PRA SS2/21 operational resilience and outsourcing.
APRA CPS 234 information security (Australia).
MAS Technology Risk Management Guidelines (Singapore).
OCC Heightened Standards and FFIEC Information Security Booklet (United States banking).
Sector overlays as in scope: HKMA SA-2, OSFI B-13, EBA Guidelines on ICT and security risk management, EIOPA Guidelines on ICT security and governance.
Cross-reference to compliance tracking record for evidence pack assembly: {{COMPLIANCE_RECORD_IDENTIFIER}}
13. Lifecycle, supplemental notifications, and post-closure obligations
Notification is rarely a one-shot event. Capture the named progression schedule the letter sits inside, the trigger conditions that force supplemental notification, the regulator inquiry follow-up obligations, the named amendments expected, and the post-closure obligations the engagement carries through to next-cycle assurance. The block makes the notification arc reconstructable as a single chain of decisions rather than a string of forwarded emails.
Letter position in the notification arc:
- Letter is the {{LETTER_POSITION}} notification under the regime in scope
- Named expected supplemental notifications under the regime progression schedule (one row per expected supplemental):
- {{EXPECTED_SUPPLEMENTAL_1}}
- {{EXPECTED_SUPPLEMENTAL_2}}
- {{EXPECTED_SUPPLEMENTAL_3}}
Trigger conditions for supplemental notification (named in advance so the named trigger is identifiable when it fires):
[ ] Confirmed material expansion of scope (named class of new evidence triggers supplemental): {{TRIGGER_SCOPE_EXPANSION}}
[ ] Confirmed material change in cause attribution (named class of forensic update triggers supplemental): {{TRIGGER_CAUSE_REATTRIBUTION}}
[ ] Confirmed material change in affected-party count (named threshold triggers supplemental): {{TRIGGER_COUNT_REVISION}}
[ ] Confirmed material change in protective-measure posture: {{TRIGGER_PROTECTIVE_CHANGE}}
[ ] Confirmed regulator inquiry requiring written response: {{TRIGGER_REGULATOR_INQUIRY}}
[ ] Confirmed customer-side request for follow-up information (enterprise customer variant): {{TRIGGER_CUSTOMER_INQUIRY}}
Regulator inquiry follow-up obligations:
[ ] Named single point of contact for regulator inquiry: {{REGULATOR_INQUIRY_SPOC_NAME}}
[ ] Named response SLA per regulator regime: {{REGULATOR_RESPONSE_SLA}}
[ ] Named cadence for proactive status updates (where the regime expects them): {{PROACTIVE_UPDATE_CADENCE}}
[ ] Named protocol for on-site supervisory visits where applicable: {{ON_SITE_VISIT_PROTOCOL}}
Post-closure obligations:
[ ] Lessons-learned review scheduled at engagement closure: {{LESSONS_LEARNED_SCHEDULE}}
[ ] Programme-retrospective findings landing on the engagement record: {{PROGRAMME_RETROSPECTIVE_REFERENCE}}
[ ] Named audit-pack assembly for next external assurance cycle: {{AUDIT_PACK_ASSEMBLY_REFERENCE}}
[ ] Named cyber-insurance post-claim narrative for the named insurer: {{CYBER_INSURANCE_NARRATIVE_REFERENCE}}
[ ] Named board read-out and audit-committee briefing on the cadence the audit committee operates against: {{BOARD_READOUT_CADENCE}}
[ ] Named refresh cycle for the breach notification letter template itself based on what the engagement taught: {{TEMPLATE_REFRESH_CYCLE}}
Lifecycle event log (one row per notification event in the matter, maintained on the engagement record):
- {{EVENT_LOG_ENTRY_1}}
- {{EVENT_LOG_ENTRY_2}}
- {{EVENT_LOG_ENTRY_3}}
- {{EVENT_LOG_ENTRY_4}}
- {{EVENT_LOG_ENTRY_5}}
Closure sign-off (only filled when the active notification phase closes):
- Closure timestamp: {{CLOSURE_TIMESTAMP}}
- Named approver of closure: {{CLOSURE_APPROVER_NAME}}
- Named open items at closure for ongoing supervision: {{OPEN_ITEMS_LIST}}
Ten failure modes the letter template has to design against
Notification programmes fail under regulator-clock pressure in recognisable patterns. Each failure has a structural fix that the template above is designed to enforce. Read this list before customising the template so the customisation does not weaken the discipline that makes the letter defensible across regulator inquiry, customer litigation, audit-committee read, and cyber-insurance claim review.
Drafting from a blank page after the regulator clock has started
The notification clock has started, the disclosure committee is meeting in three hours, and the team is composing the letter from a blank page while counsel reviews fast-moving drafts in real time. The result is a letter that either misses the regulator-clock deadline or commits to language that has not been counsel-reviewed. Make the template the named pre-incident artefact stored on the workspace with the regime-specific variant blocks pre-drafted, so the active-phase drafting is filling variables from the live engagement record rather than composing the structure from scratch.
Naming the wrong regulator clock anchor on the letter header
The letter declares it is filed against the GDPR Article 33 72-hour clock with the clock anchor named as the breach declaration timestamp, but the regulator reads the clock as starting at the moment of awareness, which was the suspicion confirmation timestamp earlier. The clock posture on the header is wrong, the filing appears late, and the regulator opens an inquiry on timing. Make the clock anchor block explicit on the header with the named timestamp, the named role authorising the determination, and counsel-reviewed sign-off before send.
Overcommitting to record counts while the investigation continues
The letter states a confirmed count of affected individuals that the forensic team revises upward two weeks later as additional log sources come into scope. The supplemental notification has to issue the corrected count, and the gap between the initial overcommitment and the corrected number becomes part of the regulator inquiry record. Use the confirmed-vs-estimated distinction explicitly, name the estimation method when counts are provisional, and commit the regime to supplemental notification under the named progression schedule.
Naming root cause attribution without counsel review
The letter names a third-party vendor as the cause of the breach, the vendor reads the letter, and the vendor litigates against the contractual indemnification posture. Make root cause attribution a counsel-reviewed block with explicit confirmed-vs-suspected distinction. The letter says what is independently confirmed by forensic evidence and what remains under investigation, with privileged-evidence treatment for the detailed forensic narrative.
Treating multiple regulator notifications as one undifferentiated obligation
The same incident triggers GDPR, NIS2, HIPAA, DORA, SEC, multiple state laws, the PCI account data compromise pathway, and a contractual customer notification, and the team writes one letter and tries to send it to all of them. Each regime has its own named clock, its own named article reference, its own named carve-outs, and its own audience calibration. Maintain the parallel-notification matrix on the engagement record and draft the regime-specific variant per regulator.
Committing to protective-measure offers that the company cannot operationally deliver
The letter promises five years of identity-monitoring for every affected individual, the call-centre cannot scale to the inbound enrolment volume, and the named monitoring vendor declines the enrolment capacity. Make the protective-measure offer block counsel-reviewed and operationally pre-validated: the named vendor commitment, the named enrolment pathway capacity, the named call-centre ramp plan, and the named cost-coverage posture all reviewed before the letter commits in writing.
Not naming a single point of contact for regulator follow-up
The letter goes out with the general counsel switchboard as the named contact. The regulator follow-up call lands on a receptionist who cannot find a named privacy officer or a named incident commander to answer the inquiry. The regulator opens a separate proceeding on responsiveness. Name a single point of contact per regime with named delegation authority, named SLA, named privilege treatment for inbound regulator correspondence, and named escalation runbook.
Sending letters out of sequence with the regulator-engagement protocol
The customer-facing individual notification lands in mailboxes before the supervisory authority notification is filed, the press picks up the customer letters, and the regulator first reads about the breach in news coverage. Maintain the regulator-engagement protocol on the engagement record, sequence the letters under the named protocol, and pre-clear the customer-facing send with counsel against the regulator-side coordination protocol.
Forgetting the supplemental notification obligation after the initial filing
The initial notification is filed inside the regulator clock, the team relaxes, and the SEC Item 1.05(c) amendment obligation, the NIS2 intermediate report, the GDPR Article 33 follow-up communication, the HIPAA additional notification on confirmed scope expansion, and the DORA progression updates are missed. Maintain the lifecycle block on the letter template with the named expected supplemental schedule per regime, named trigger conditions, named owners, and named target dates on the engagement record.
Treating the letter as the only artefact rather than as part of the engagement record
The letter lands in the regulator portal and the team treats the matter as closed without preserving the chain of custody for the materiality-determination minutes, the disclosure-committee minutes, the privacy officer risk-assessment record, the counsel-reviewed evidence pack, and the activity log trail. Six months later the regulator inquiry asks how the materiality determination was reached and the team cannot reconstruct it. The letter is one artefact in a chain that includes the engagement record, the runbook application, the severity rubric application, and the regulator-engagement protocol record. Preserve the chain.
Ten questions a quarterly notification-programme review has to answer
Per-matter post-incident review keeps each notification artefact current. Programme-wide review answers the cumulative question: is the notification capability durably audit-ready, and is the programme on top of the regime carve-outs, the supplemental schedule, the protective-offer obligations, and the inbound capacity baseline. Run these ten questions at every quarterly programme review and capture the answers in the programme-level summary record.
1.How many notification letters were drafted during the period, broken out by regime variant, and how many were drafted inside the named regulator clock without overtime escalation versus how many drifted past the deadline.
2.How many letters went through documented counsel review before send, and how many bypassed the named counsel review gate because of clock pressure or escalation noise.
3.How many letters issued under each regime invoked a carve-out (GDPR Article 34(3) exemption, HIPAA low-probability exception, SEC delayed-disclosure carve-out, state encryption safe harbour), what was the named basis on the carve-out, and how many of those carve-out invocations have been audit-reviewed since.
4.How many letters carried a confirmed record count that was later revised upward in a supplemental notification, and what was the magnitude of revision relative to the initial count.
5.How many letters named a third-party vendor or sub-processor as a confirmed or suspected cause, and how many of those letters resulted in contractual indemnification claims or contractual disputes downstream.
6.How many supplemental notifications fired under each regime progression schedule (NIS2 intermediate report, NIS2 final report, GDPR Article 33 follow-up communication, SEC Item 1.05(c) amendment, HIPAA additional notification), and how many were filed inside the named follow-on clock.
7.How many regulator inquiries opened after notification, what was the mean-time-to-respond on each inquiry, and how many resulted in a supervisory letter, an on-site visit, or a formal proceeding.
8.How many customer-facing notifications resulted in a documented enrolment uptake on the named protective-measure offer, and how many resulted in escalated inquiry beyond the named call-centre capacity baseline.
9.How many cyber-insurance notice-of-claim letters were filed during the period, what was the mean-time-to-notify under the named policy notice-of-claim window, and how many of those notices preserved coverage versus how many produced a coverage-position reservation.
10.How many programme-retrospective findings from notification matters landed on the engagement record and produced a documented update to the letter template, the runbook, the severity rubric, the regulator-engagement protocol, or the inbound capacity plan.
How the letter template pairs with SecPortal
The template above is copy-ready as a standalone artefact. If the security team already runs incident engagement records, evidence handling, exception management, and framework-evidence packaging on a workspace, the letter becomes one of several artefacts attached to one engagement record rather than a separate document lifecycle. SecPortal opens a breach engagement at the moment a triggering event is suspected through engagement management so the named incident commander, the named legal counsel, the named disclosure committee chair, the named privacy officer, the named in-scope assets, the named in-scope jurisdictions, and the named in-scope data categories all live on one workspace record from the first hour, before any regulator clock has started.
The findings management feature captures the underlying breach record as findings under the unified schema with CVSS 3.1 calibration, severity, target close date, named owner, named retest pointer, and named evidence-of-closure expectation, so the letter draws scope, cause, and remediation status from a structured backlog rather than from a chat transcript. The named exploitation chain finding, the named affected-data-category findings, and the named third-party-causation findings where in scope all land on the engagement so the section on cause and root cause is filled from confirmed evidence rather than from memory.
The document management feature stores the executed letter drafts as versioned artefacts with named retention class stamped at capture, the regulator file references for inbound and outbound correspondence, the materiality-determination minutes, the disclosure-committee minutes, the privacy officer risk-assessment record, the counsel-reviewed forensic evidence pack, and the insurer notice-of-claim correspondence. The finding overrides feature carries the eight-field exception decision chain for residual conditions captured during remediation so any compensating controls operating in lieu of full closure stay on the live record rather than on a side spreadsheet that nobody renews.
The activity log captures named-actor status transitions on every entity (letter draft creation, counsel review request, counsel approval, send timestamp, regulator inbound correspondence receipt) by named user and timestamp with CSV export, so the audit chain of who reviewed what, when, and against which version is reconstructable from the workspace rather than from forwarded emails. The compliance tracking feature maps the named regulator clocks the engagement is operating under (GDPR Articles 33 and 34, NIS2 Article 23, SEC Item 1.05, HIPAA Breach Notification Rule, DORA Articles 19 and 20, PCI DSS account data compromise pathway, state breach-notification laws, and the framework expectations the letter evidences at ISO 27001 Annex A 5.24 through 5.28, SOC 2 CC7.3 and CC7.4, NIST 800-61 Rev. 2, NIST 800-53 IR family) so the parallel notification posture is visible on one record and the framework evidence map at Section 12 can be sliced by regime when an auditor asks for the evidence pack.
The team management feature carries the role-based access control that decides which roles can author each section, which roles can request counsel review, which roles can sign off on send, and which roles can access the privileged-evidence folder under restricted RBAC. The multi-factor authentication control gates workspace access so the audit reads the access record on counsel-reviewed evidence as a documented control rather than as a hope. The notifications and alerts feature routes named-clock-deadline approaching events to the named drafter, the named counsel reviewer, and the named approver so the regulator-clock posture stays visible throughout the active phase. The AI report generation workflow can draft the executive summary the disclosure committee reads at the next governance cadence, the audit-committee read-out at quarterly board cadence, the cyber-insurance post-claim narrative for the insurer claims desk, and the next external assurance cycle narrative (ISO 27001 surveillance audit, SOC 2 examination period coverage, sector-specific audit such as HIPAA OCR examination, NYDFS Part 500 certification, FINRA cybersecurity review) from the same engagement data, so the publication path produces multiple consumer-shaped reads of the same underlying notification without re-keying.
Honest scope: SecPortal does not provide legal counsel, does not draft the letter on the customer platform side, does not send notifications to regulators or individuals on behalf of the customer, does not file SEC Form 8-K on EDGAR, does not file with supervisory authority portals (ICO, CNIL, IMY, AEPD, Garante, BfDI, DPC, BSI, ENISA, OCR), does not deliver postal mailings or run identity-monitoring enrolment hotlines, does not ingest regulator inbound correspondence over webhook in real time, does not operate cyber-insurance claim portals, and does not ship native push connectors into Jira, ServiceNow, OneTrust, Vanta, Drata, SecureFrame, Whistic, LogicGate, Archer, MetricStream, RSA Archer, AuditBoard, Resolver, ServiceNow IRM, or any GRC platform. Customer-side legal counsel, the named privacy officer, the named regulator-engagement specialists, the named call-centre vendor, the named identity-monitoring vendor, the named insurer counsel, and the disclosure committee continue to own the substantive notification work; the platform carries the consolidated operating record the named experts read into.
Who reads the breach notification artefact
CISOs, security directors, and security programme owners
CISOs, security directors, security programme owners, and audit-committee chairs read the letter template as the named operational artefact that makes the notification capability defensible at board and audit-committee cadence rather than as an ad-hoc-drafted communication. Pair the template with the CISOs persona page and the security leadership reporting use case.
GRC, privacy, and compliance teams
GRC and compliance teams, privacy officers, and data protection officers read the template as the regime-specific variant block they will reach for under regulator-clock pressure, with the framework-expectations map at Section 12 making the artefact slot into the audit pack alongside the engagement record, the runbook, and the severity rubric. Pair the template with the GRC and compliance teams persona page and the audit fieldwork evidence request fulfilment use case.
Incident response leads and SOC managers
Incident response leads, SOC managers, and detection engineering teams read the template as the formal-correspondence companion to the runbook and the severity rubric, so the active-phase response and the formal notification both run against the same engagement record. Pair the template with the incident response leads persona page and the incident response workflow.
Internal security and AppSec teams
Internal security teams, AppSec teams, security engineering teams, and vulnerability management teams read the template as the artefact the response will reach for if a vulnerability under their stewardship contributes to a notifiable breach. Pair the template with the internal security teams persona page and the cyber insurance security evidence use case.