Incident notification procedure: stages and deadlines
An incident notification procedure moves through four fixed stages: detection and internal confirmation, scoping, notification to the competent authority, and a follow-up report. The clock for the first notification starts when the incident is confirmed internally, not when it happened. Missing the confirmation stage does not close the file — it changes the risk profile of every stage that follows, and that change is difficult to reverse once a regulator has opened a file.
How the stages fit together
The procedure does not begin with the notification itself. It begins with a confirmed detection inside the organisation, and the internal record of that moment carries more weight than most teams expect. The applicable framework measures the deadline from confirmation, not from the underlying event, so the internal log of when confirmation happened becomes the first piece of evidence a regulator asks for.
Once detection is confirmed, the organisation moves into scoping. Scoping decides which systems or categories of data are affected, how many people or counterparties are exposed, and whether the incident crosses into a second regulatory track. A single incident can trigger more than one notification track at once, and each track keeps its own clock running from its own confirmation point.
What changes once the clock starts running
Before confirmation, the organisation manages an operational problem. After confirmation, it manages a regulatory deadline, and the two are not the same discipline. Internal communication has to slow down and formalise, because every message about the incident becomes part of a file a regulator can request later.
The second change is contractual. If the incident touches data processed on behalf of a customer or a partner, the duty toward the regulator does not replace the duty toward that counterparty. When a processing arrangement survives the end of the underlying service, the notification duty tied to it does not expire automatically either; that overlap is examined in When the contract term outlives the product: the deadline.
What to do, in order
- Confirm the incident internally and record the exact time of confirmation. The internal security or data protection lead signs off on this record.
- Scope the incident: which systems, which categories of data, how many affected parties, whether more than one regulatory track applies.
- Draft the internal incident file: timeline, systems touched, containment steps taken so far, and open questions still unanswered.
- Notify the competent authority through the channel that authority accepts, once scoping has closed and the file is complete enough to submit.
- Notify directly affected counterparties where scoping shows material risk to them, in parallel with the regulatory notification, not after it.
- File the follow-up report once containment is complete, closing the gaps left open in the first notification.
Who decides and how each stage closes
Ownership shifts as the file moves through the procedure. The table below lists who typically holds each stage and what closing that stage requires, without attaching a fixed duration to any of them.
| Stage | Who owns it | What closes the stage |
|---|---|---|
| Detection and confirmation | Internal security or data protection lead | Signed internal record of confirmation |
| Scoping | Internal lead, with external counsel where more than one track applies | Written scope memo |
| First notification | Competent authority for the affected regime | Acknowledgement of receipt from that authority |
| Counterparty notification | Contract owner on the business side | Confirmation sent to each affected counterparty |
| Follow-up report | Same authority, same file reference | Authority closes the file or requests further detail |
The table lists ownership rather than duration on purpose. The deadline for the first notification is set by the applicable framework, and it depends on the regime in play rather than on the incident itself. Treating a single figure as universal across every regime is the most common mistake at this stage.
Common scenarios
If the incident affects one system with a clear boundary, scoping closes quickly and the first notification follows soon after. If the incident affects a shared platform used by several business lines, scoping takes longer, because each line has to confirm its own exposure before the file can close.
If the same incident touches intellectual property alongside personal data — for example, a breach exposing both customer records and a licensed dataset — the notification track and the licensing question run on separate clocks. That overlap between a security deadline and a licensing deadline is easy to miss, and it is examined in When exclusive and sole are used interchangeably: the deadline.
If a competing claim to the underlying dataset or invention surfaces during scoping, the notification file and the ownership dispute proceed on separate timelines. The mechanics of that second timeline are set out in The deadline that matters in this situation in detail.
The same layered approach to sequencing — fixed stages, a named owner for each stage, a defined closing condition — appears in structurally different procedures as well, including Redemption process design step by step in practice.
What this page does not cover
This page describes the mechanics of the procedure: stages, ownership, and the order in which they run. It does not state which specific deadline applies to which regime, because that figure depends on the framework in force for the affected sector and the affected data, and a single number here would misstate the others. It also does not resolve contractual exposure created before the incident happened; that is a separate question with its own procedure.
Verified
Last reviewed in June 2025. This page sets out procedural mechanics that hold across the applicable regulatory frameworks for security and data incidents. It does not cite specific statutory provisions, in line with the scope of a procedural note; readers who need the exact deadline for a named regime should confirm it with the competent authority for that regime before acting.
Related reading
The scoping stage described here overlaps with a related internal review: Records of processing review. The two procedures often run at the same time inside the same organisation.
Frequently asked questions
How long does incident notification procedure take in practice?
Total duration depends on how quickly scoping closes. A single system with a clear boundary closes scoping fast; a shared platform used by several business lines takes longer, because each line has to confirm its own exposure first. The first notification follows as soon as scoping is closed and the file is complete.
Which documents are needed to start?
The file needs an internal confirmation record with a timestamp, a written scope memo listing systems and data categories affected, a containment log showing steps taken so far, and a list of counterparties who may need direct notification. Without these four, the notification stage cannot open.
What happens if the other side does not respond?
If the competent authority does not respond after acknowledgement of receipt, the file stays open and the organisation proceeds to the follow-up report on schedule regardless. If an affected counterparty does not respond to direct notification, that silence does not suspend the organisation's own obligations, and it should be logged in the file as a separate item.
Where the exposure runs the other way — a counterparty pressing for terms an incident has made costly — the mechanics of that pressure are covered separately: When a customer demands unlimited liability in practice.