INC-005 Incident Reporting and Regulatory Notification
Description
Internal incident reporting requirements and timelines are defined for every severity level. A personal data breach is notified to the relevant supervisory authority within 72 hours of the organisation becoming aware of it, and to affected data subjects without undue delay where the breach is likely to result in a high risk to them. Where the organisation processes personal data on behalf of a controller, the controller is notified without undue delay after the organisation becomes aware of the breach. Each notification states the nature of the breach, the categories and approximate number of data subjects affected, the likely consequences and the remedial measures taken. Where an incident involves a supplied product, component or service, the provider of that product or service and the other parties in the supply chain the incident reaches are informed, with the information they need to act. Every personal data breach is recorded in an internal breach register, including those below the notification threshold, with the facts, effects and remedial action. A register records each statutory incident reporting obligation that binds the service, naming for each one the trigger, the recipient, the clock and the content the submission carries, including obligations whose trigger is a request from an authority rather than an elapsed period and obligations whose deadline is conditional on the incident still running. Each incident that meets a trigger carries the submissions the register requires, with the time at which the organisation became aware recorded and each submission recorded against its deadline. A deadline missed carries a recorded reason and a corrective action, and the register carries a review date within the defined interval and the date each obligation was added.
Rationale
Regulatory breach notification is a legal obligation with defined timelines and content, and late or incomplete notification creates material exposure. Covering internal and external reporting in one control reflects the operational reality that a single event triggers both. Supply chain notification is the direction most often missed: an organisation notifies upwards to regulators and outwards to customers while the supplier whose component was involved, and the other users of that component, hear nothing. The register is the durable form of a duty that changes with every instrument: writing each new clock into the description would turn the control into a schedule and leave the next regime unserved. What the control requires is that the obligations are known, named and met, and the register is where the trigger, the recipient, the clock and the content live; the profile row for each overlay carries that regime's figures. The time of awareness is the field everything else hangs on, because every statutory clock in scope runs from it and no clock can be tested without it. GOV-010 records that an obligation exists, who is accountable for it and which instrument or contract it arises from. This register is the incident-keyed extract: only the obligations an incident can fire, with the submission each one wants. INC-003 decides whether a trigger has been met, INC-008 produces the content a final report carries and INC-010 holds the contact it is sent to.
Applicability (9 profiles)
Includes informing the provider of a risk or incident found in use (Art.26.4).
The register this control keeps gains an EU AI Act entry that runs alongside the GDPR 72-hour clock and is measured from a different moment. The Art.73 deadlines are stated once, on the AIG-021 row; what this row adds is the trigger. Art.26(5) is why the deployer sits inside the provider's clock: awareness at the deployer starts the period the provider reports on, so the register entry names the deployer notification route as part of the trigger. AIG-021 defines what counts as serious and holds the incident record.
Includes informing the provider of a risk or incident found in use (Art.26.4).
The financial entity has its own Art. 19 major-incident reporting clock, which starts from facts only the provider holds. The statutory reporting register now written into this control is where that dependency becomes visible: an obligation whose trigger is a customer's clock is an entry with its own recipient, timing and content, alongside the GDPR and NIS2 entries. The assistance that serves the customer's clock is INC-006.
The control now holds a register of every statutory reporting obligation an incident can trigger, with the trigger, the recipient, the clock and the content of each, and records every submission against its deadline. This instrument supplies five entries running in parallel with the GDPR clock: an early warning within 24 hours of awareness, an incident notification within 72 hours, an intermediate report on request, a final report within one month of the notification with four fixed contents, and a progress report where the incident is still running at that point with the final report a month after handling ends. For an organisation that also holds the managed-service-provider role, an incident crossing an Art. 10 threshold on a managed service runs the same sequence, so the classification decision in INC-003 says which service tripped it.
Framework Mappings (24)
| SEF-08 | Security Breach Notification | full |
| SEF-08 | Security Breach Notification | full |
| DORA-Art.30.2.f | Incident assistance at no additional or ex-ante determined cost | informative |
| EU-AI-Art.26.4 | Deployer Obligations — Operational Monitoring and Incident Notification | partial |
| EU-AI-Art.73 | Serious Incidents — Reporting to Market Surveillance Authorities | partial |
| GDPR-Art.33.1 | Breach Notification to Supervisory Authority — 72-Hour Requirement | full |
| GDPR-Art.33.2 | Processor Notification of a Breach to the Controller | full |
| GDPR-Art.33.3 | Breach Notification Content Requirements | full |
| GDPR-Art.33.5 | Internal Breach Documentation | full |
| GDPR-Art.34.1 | Breach Communication to Data Subjects | full |
| GDPR-Art.34.3 | Exemptions from Data Subject Breach Notification | informative |
| HIPAA-164.314.a.2.i.C | Business Associate Contract Security Incident Reporting Term | informative |
| NIS2-Art.23.1 | Notification of Significant Incidents | partial |
| NIS2-Art.23.4.a | Early Warning Within 24 Hours | full |
| NIS2-Art.23.4.b | Incident Notification Within 72 Hours | full |
| NIS2-Art.23.4.c | Intermediate Report on Request | full |
| NIS2-Art.23.4.d | Final Report Within One Month | full |
| NIS2-Art.23.4.e | Progress Report and Final Report for an Ongoing Incident | full |
| IR-6 | Incident Reporting | full |
| IR-6(3) | Incident Reporting | Supply Chain Coordination | full |
| MG-2.3-001 | Unknown Risk Response and Recovery | MG-2.3-001 | informative |
| MG-4.3-003 | Incident and Error Communication | MG-4.3-003 | informative |
| P6.5 | Notification of Privacy Breaches | full |
| P6.6 | Remediation of Privacy Breaches | informative |
Evidence (4)
Incident reporting and breach notification procedure defining internal reporting timelines, GDPR 72-hour notification requirements, data subject notification triggers, and required notification content.
Example: Breach Notification Procedure or IRP section on regulatory notification (version-controlled, approved by legal/DPO, dated within the last 12 months) with notification timelines, required content checklist, and DPA contact details
Test: Request the breach notification procedure. Verify: (1) internal reporting timelines are defined for all severity levels; (2) the 72-hour GDPR Art.33 notification obligation is explicitly stated; (3) Art.33(3) content requirements are listed as a checklist; (4) data subject notification trigger criteria (high risk to individuals) are defined; (5) current DPA and supervisory authority contact details are included.
Breach notification records demonstrating GDPR-compliant notifications were made within 72 hours for applicable incidents, with required content and documentation of the notification.
Example: DPA notification submission confirmation (e.g., ICO online submission receipt), data subject notification record, or internal breach register entry (GDPR Art.33(5)) showing notification date, submitted content, and responsible DPO, or a documented justification if no notifications were required in the review period
Test: Request the breach register and notification records for the last 12 months. Verify: (1) all incidents assessed as personal data breaches appear in the Art.33(5) breach register; (2) supervisory authority notifications were submitted within 72 hours of becoming aware; (3) notification content addresses Art.33(3) requirements; (4) where notification was not made, the documented rationale is proportionate and records the decision-maker.
Supply chain notification records for incidents that reached a supplied product, component or service.
Example: Supplier incident notifications, INC-2026-0117 and INC-2026-0142
Test: Request the supply chain notification records. Verify: (1) every incident in the period whose root cause or blast radius touched a supplied component carries a notification to that supplier, (2) the notification states what the recipient needs in order to act rather than only that an incident occurred, (3) downstream parties the incident reached were informed where the contract or the risk required it, (4) the notification date falls within the period the plan sets, (5) an incident where the supplier was deliberately not notified carries a recorded decision and its reason.
Statutory incident reporting register with the per-incident submission record for the period.
Example: Statutory Incident Reporting Register v2.1 with the INC-2026-0114 submission log, reviewed 30 June 2026.
Test: Verify: (1) the register carries an entry for every obligation in the compliance inventory that an incident can trigger, and nothing in that inventory of the kind is missing from it, (2) each entry names the trigger, the recipient, the clock and the content the submission carries, (3) at least one entry has a trigger that is a request from an authority rather than an elapsed period, and states how such a request reaches the incident case, (4) an entry whose deadline is conditional on the incident still running states both dates and how each is tracked, (5) for each incident in the period that met a trigger, the time of awareness is recorded and each required submission is recorded with its sent date against its deadline, (6) a deadline missed carries a recorded reason and a corrective action, (7) the register carries a review date within the defined interval and the date each obligation was added, so an obligation that arose mid-cycle is visible.
Questions (3)
Are internal incident reporting requirements and timelines defined for every severity level?
The breach notification procedure must explicitly state the 72-hour GDPR Art.33 obligation and include GDPR Art.33(3) content requirements as a checklist. The procedure should be approved by the DPO or legal team.
Which elements are included in your breach notification procedure?
Options run from the most commonly present to the least. A missing content checklist and an undefined trigger for notifying individuals are the usual gaps. Supply chain notification is the direction most often missed: organisations notify upwards to regulators and outwards to customers while the supplier whose component was involved hears nothing. The last two items are what make the procedure survive a second regime: one named clock inside an incident response plan is not a register, and a deadline cannot be tested against an awareness time nobody wrote down.
What does your internal breach register capture for each personal data incident?
A complete breach register is required for GDPR accountability. All incidents should be logged regardless of notification threshold. The register must capture the notification decision with documented justification.