Batch Register

Regulator incident notification

The shortest fixed clock in the held texts is 24 hours (daily), set by NIS2 Art.23.4.a. Paste one job that feeds this consumer, for example apra_incident_notification, weekly, and the register reads its period against the clocks below, names the gap in hours, and carries the question for its owner.

Matched on the job name or the consumer column by these words: regulator notif, apra notif, authority notif, incident notification, incident notice, csirt, supervisor notif, regulator report, notify regulator, regulator notification. The clocks on this class run from the event, not from a schedule, so the register asks for the drill or exercise job that proves the pack can be produced in time.

The clock each rule sets

RegimeClockClause
CPS 23472hCPS 234 para 35 APRA Notification of Material Incidents within 72 Hoursno later than 72 hours
NIS224hNIS2 Art.23.4.a Submit an early warning within 24 hours of becoming aware of a significant incidentan early warning within 24 hours of becoming aware
72hNIS2 Art.23.4.b Submit an incident notification within 72 hours, with an initial assessment and indicators of compromisean incident notification within 72 hours of becoming aware
730hNIS2 Art.23.4.d Submit a final report within one month, and a progress report where the incident is still runninga final report within one month of the notification
no clockNIS2 Art.23.1 Notify significant incidents to the CSIRT or competent authority, and warn affected service recipientswithout undue delay
DORAno clockDORA Art. 19 Reporting of major ICT-related incidentsthe prescribed timelines
GDPR72hGDPR Art. 33 Notification of a personal data breach to the supervisory authoritynot later than 72 hours
SP 800-53no clockSP 800-53 IR-6 Incident reportingan organization-defined period

Questions this page answers

How often does APRA CPS 234 require regulator incident notification?

Within 72 hours of the event (no later than 72 hours): CPS 234 para 35, APRA Notification of Material Incidents within 72 Hours. 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.

How often does NIS2 Directive require regulator incident notification?

Within 24 hours of the event (an early warning within 24 hours of becoming aware): NIS2 Art.23.4.a, Submit an early warning within 24 hours of becoming aware of a significant incident. Within 72 hours of the event (an incident notification within 72 hours of becoming aware): NIS2 Art.23.4.b, Submit an incident notification within 72 hours, with an initial assessment and indicators of compromise. Within 730 hours of the event (a final report within one month of the notification): NIS2 Art.23.4.d, Submit a final report within one month, and a progress report where the incident is still running. The held text of NIS2 Art.23.1 (Notify significant incidents to the CSIRT or competent authority, and warn affected service recipients) sets no fixed period: without undue delay. 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. 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. 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. 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.

How often does DORA (Regulation (EU) 2022/2554) require regulator incident notification?

The held text of DORA Art. 19 (Reporting of major ICT-related incidents) sets no fixed period: the prescribed timelines. 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.

How often does GDPR require regulator incident notification?

Within 72 hours of the event (not later than 72 hours): GDPR Art. 33, Notification of a personal data breach to the supervisory authority. 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.

How often does NIST SP 800-53 Rev 5 require regulator incident notification?

The held text of SP 800-53 IR-6 (Incident reporting) sets no fixed period: an organization-defined period. Requires personnel to report suspected incidents to the incident response capability within an organization-defined period, and requires incident information to be reported to the authorities the organization has identified.

What does the register ask the owner of a regulator incident notification job?

Who decides an incident is material, and how is that decision timed against the 72 hours?

The clauses in full

CPS 234 para 35 APRA Notification of Material Incidents within 72 Hoursthe standard's page

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

NIS2 Art.23.4.a Submit an early warning within 24 hours of becoming aware of a significant incidentthe standard's page

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

NIS2 Art.23.4.b Submit an incident notification within 72 hours, with an initial assessment and indicators of compromisethe standard's page

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

NIS2 Art.23.4.d Submit a final report within one month, and a progress report where the incident is still runningthe standard's page

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

NIS2 Art.23.1 Notify significant incidents to the CSIRT or competent authority, and warn affected service recipientsthe standard's page

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

DORA Art. 19 Reporting of major ICT-related incidentsthe standard's page

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

GDPR Art. 33 Notification of a personal data breach to the supervisory authoritythe standard's page

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

SP 800-53 IR-6 Incident reportingthe standard's page

Requires personnel to report suspected incidents to the incident response capability within an organization-defined period, and requires incident information to be reported to the authorities the organization has identified.

What an assessor asks to see: Defined internal reporting timeframe and the channels available to staff; Evidence staff know how and when to report, such as awareness material; List of authorities to be notified and the applicable timeframes; Records of actual notifications made and their timing. Where it usually falls short: Reporting timeframe undefined, so escalation depends on individual judgement

Requirement text quoted from the standards themselves, published at compliance.theartofservice.com, the same publisher as this register, read against the held text of each standard: our statement of each clause, not the instrument verbatim. Run this job through the register