Breach notification report pack

On becoming aware of a personal data breach, notify it to the competent supervisory authority without undue delay and, where feasible, not later than 72 hours after becoming aware, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons; a notification made later than 72 hours must be accompanied by the reasons for the delay. A processor must notify its controller without undue delay after becoming aware of a breach. The notification must at least describe the nature of the breach including, where possible, the categories and approximate number of data subjects and of personal data records concerned, give the name and contact details of the data protection officer or other contact point, describe the likely consequences, and describe the measures taken or proposed including any measures to mitigate adverse effects. Information may be provided in phases where it cannot all be given at once. Document every personal data breach, including the facts, its effects and the remedial action taken, so the supervisory authority can verify compliance with this Article.

What an assessor asks to see: The internal breach register covering all breaches including those assessed as not notifiable, with the risk assessment recorded for each; The awareness timestamp per incident and the basis for it, since the 72 hours runs from awareness and not from confirmation or containment; Notifications as submitted, checked against the four content elements Article 33(3) requires; The methodology used to decide notifiability, and evidence it was applied rather than the decision reached first and documented after. Where it usually falls short: The awareness clock started at the end of the investigation rather than at the point of reasonable certainty that a breach had occurred

Where a personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, communicate the breach to the affected data subjects without undue delay, describing in clear and plain language the nature of the breach and giving at least the contact point, the likely consequences and the measures taken or proposed including mitigation. Communication is not required where the controller had implemented appropriate technical and organisational protection measures and applied them to the affected data, in particular measures such as encryption rendering the data unintelligible to anyone unauthorised, where the controller has since taken measures making the high risk no longer likely to materialise, or where individual communication would involve disproportionate effort, in which case a public communication or similar equally effective measure must be made instead. The supervisory authority may require communication or decide that one of the exemptions applies.

What an assessor asks to see: The high risk assessment per breach, kept distinct from the Article 33 assessment, which uses a lower threshold; The communication as sent, assessed for clear and plain language and for the three content elements required; Where the encryption exemption is relied on, evidence the measure covered the specific affected data and that the keys were not also compromised; Where disproportionate effort is claimed, the public communication actually made and evidence of the reach it achieved. Where it usually falls short: Communication deferred until the investigation completes, when the Article requires it without undue delay once high risk is identified

APRA must be notified as soon as possible and no later than 72 hours after the entity becomes aware of an incident that materially affected or could have materially affected the entity or its customers, or that has been notified to another regulator in any jurisdiction.

What an assessor asks to see: Notification records with awareness and submission timestamps; Materiality assessment criteria and decision records; Register of notifications made to other regulators. Where it usually falls short: Clock started at incident confirmation rather than awareness

The first stage of the layered reporting regime falls due without undue delay and in any event within 24 hours of becoming aware of the significant incident. The early warning is deliberately light: where applicable it indicates whether the incident is suspected of being caused by unlawful or malicious acts, and whether it could have cross-border impact. It is not a full assessment and waiting for one is the classic way to miss the deadline. Two operational points decide whether an entity can meet this. First, becoming aware has to be defined and evidenced, because the clock starts there and an entity that cannot say when it knew cannot show it reported in time. Second, submission has to be possible at any hour, since a Friday night detection has the same 24 hours as a Tuesday morning one. The CSIRT or authority is expected to respond within 24 hours where possible, so the channel is two-way.

What an assessor asks to see: The definition of becoming aware and the evidence trail that fixes that moment per incident; Submitted early warnings with timestamps, measured against the 24-hour limit; Out-of-hours submission capability, including named authorised submitters and their credentials; The judgement recorded on suspected unlawful or malicious cause and on cross-border impact. Where it usually falls short: Awareness treated as the moment of executive briefing rather than of qualified detection

Within 72 hours of becoming aware, the entity updates the early warning and provides an initial assessment of the significant incident covering its severity and impact, together with indicators of compromise where those are available. The 72 hours runs from awareness, not from the early warning, so the two clocks start together. Trust service providers are held to a shorter deadline: for significant incidents affecting the provision of their trust services they must notify within 24 hours. The practical demand here is investigative rather than administrative, since the entity needs enough forensic capability within three days to characterise severity and impact honestly and to extract indicators worth sharing. Producing indicators requires that the telemetry existed before the incident.

What an assessor asks to see: Submitted notifications with timestamps measured from the awareness moment; The initial severity and impact assessment as submitted, and the basis for it; Indicators of compromise shared, and the telemetry and tooling they were derived from; Where the entity is a trust service provider, evidence the shorter 24-hour deadline is built into the procedure. Where it usually falls short: 72 hours counted from the early warning rather than from awareness

One month after the 72-hour notification the entity owes a final report containing a detailed description of the incident including its severity and impact, the type of threat or root cause likely to have triggered it, the mitigation measures applied and ongoing, and where applicable the cross-border impact. If the incident is still ongoing when that month expires, the entity provides a progress report at that point and then a final report within one month of finishing its handling of the incident. Root cause is the demanding element: a report that names the immediate technical trigger without reaching the reason the condition existed does not meet the standard, and it is also the element that determines whether the entity learns anything. The mitigation section must distinguish what is already done from what is still in progress.

What an assessor asks to see: Final reports as submitted, with the date measured one month from the notification; Root cause analysis output, reaching the underlying condition rather than the immediate trigger; The mitigation record separating completed measures from ongoing ones, with owners and dates; Cross-border impact assessment where applicable. Where it usually falls short: Root cause given as the exploited vulnerability with no account of why it was exposed

The core reporting duty attaches to any incident with a significant impact on the provision of the entity's services. Article 23(3) fixes the threshold: an incident is significant if it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity, or if it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage. Capable of causing matters, because it brings in near-miss and contained events that could have gone further. Notification goes to the CSIRT or, where the Member State so provides, the competent authority, without undue delay, and must carry whatever lets the recipient determine cross-border impact. Where appropriate the entity must also tell the recipients of its services about significant incidents likely to affect service delivery. The Directive states that notifying does not of itself increase the notifying entity's liability, which removes one common reason for delay.

What an assessor asks to see: The documented significance test, expressed against the Article 23(3) limbs including capable of causing; The determination record for each candidate incident, including reasoned decisions not to report; Notifications as submitted, with timestamps, and the identity of the receiving CSIRT or authority; Cross-border impact information captured and included in the notification. Where it usually falls short: Threshold applied only to realised impact, so contained incidents capable of severe disruption go unreported

Identify and respond to suspected or known incidents, mitigate harmful effects, and document incidents and their outcomes. NIST recommends linkage to HIPAA Breach Notification Rule timelines.

What an assessor asks to see: Incident ticket log; Post-incident reports; Breach risk assessments per 164.402; Notification records (individuals, HHS, media). Where it usually falls short: Incident closure without root cause

Financial entities shall report major ICT-related incidents to the relevant competent authority within the prescribed timelines using initial, intermediate and final notifications, and may notify significant cyber threats on a voluntary basis.

What an assessor asks to see: Major-incident reports (initial/intermediate/final) submitted to the competent authority within the deadlines. Where it usually falls short: Late or missing major-incident reporting

An incident response plan exists and is ready to be activated in the event of a suspected or confirmed security incident, covering roles, responsibilities, communication, containment, and recovery.

What an assessor asks to see: Incident response plan with named roles; Communication trees including legal, comms, law enforcement; Containment and recovery procedures; Approval and version control. Where it usually falls short: IRP stale