Incident notification procedure: what the decision maker looks at

When a security incident is confirmed, the person who decides what happens next does not start with the technical report. They check who was affected, how fast the organisation reacted, and whether internal escalation matched the severity of what occurred. Everything else in the file exists to support that first reading.

What the decision maker checks first

A decision maker reviewing an incident file — whether inside a regulator, a board, or a client's own compliance function — reads for three things before anything else: scope, timeline, and containment. Scope means how many records or systems were touched, and whether the exposure was contained to one processing activity or spread across several. Timeline means the gap between detection and internal escalation, not the gap between the incident and the notification itself. Containment means whether the organisation can show, with dated evidence, that the exposure was closed rather than merely noticed.

These three points decide how the rest of the file gets read. A short internal gap with clear containment evidence is treated differently from a long, undocumented gap, even where the underlying incident is identical in size. The narrative written by the organisation matters less than the timestamps that support or contradict it.

Why the timeline changes the risk

Once an incident is confirmed, a short and fixed window opens for the first notification step, measured in hours rather than days. That window starts running from confirmation, not from suspicion, and it does not pause while internal teams debate severity. Every hour spent on internal disagreement is an hour that a later reviewer will ask about directly.

The same clock affects vendor relationships. If the incident originated with a data processor or a platform supplier, the client's own contract with that vendor often becomes relevant at exactly this point, particularly where the agreement allows exit on short notice rather than for cause. Termination for convenience: stages and deadlines sets out how that separate clock runs, and it rarely aligns neatly with the notification clock described here.

What to do before you file

The steps below assume the incident has already been confirmed internally. They are written for the person coordinating the response, not for the technical team handling containment.

1. Confirm the trigger date and record it in writing — the compliance lead logs the exact hour of confirmation, separate from the hour of first suspicion.
2. Establish scope in writing — the data protection or security lead lists affected categories of data and approximate numbers of individuals or systems, flagged as provisional if final figures are not yet available.
3. Draft the internal escalation note — the compliance lead prepares a short memo for the board or senior management, stating what is known and what remains open.
4. Check whether a parallel regulatory track applies — where the incident also touches a security enforcement matter rather than a purely data protection one, the two tracks can run at the same time and need separate handling; Security enforcement: stages and deadlines covers that separate track.
5. Prepare the notification text — the compliance lead drafts the notification using only confirmed facts, marking any estimate clearly as an estimate.
6. Route for sign-off — a named senior officer signs off before submission, and that sign-off is itself logged with a timestamp.

Who decides, and how long it usually takes

Two decision points sit inside this procedure: the internal sign-off before submission, and the regulator's own review after the notification is received. Each has its own actor and its own rhythm.

The regulator's own timetable is the least predictable part of this chain. A straightforward, well-documented file with clear containment evidence tends to move faster through review than one with gaps or inconsistent dates.

If your situation differs

The steps above assume a single incident with a single clear scope. Three common variations change how the file should be built.

If the incident affects only part of a wider data set or system range — a subset of records rather than the whole database — the deadline calculation and the scope description both need to be handled with particular care, since a partial-scope claim invites closer questioning than a full-scope one. The deadline that matters in this situation in detail works through a comparable partial-scope timing problem in a different context, and the same caution applies here.

If the incident touches tokenised records or a digital asset platform — for example, where affected data underpins a redemption or settlement mechanism — the notification file needs to describe how that mechanism was affected, not only how personal data was exposed. Redemption process design token issuance what the decision maker looks at the design questions that arise once a redemption process is involved, and those questions often surface again once an incident touches the same infrastructure.

If a vendor or processor involved in the incident does not respond within the internal deadline set for them — the organisation still has to file on the basis of what it knows, flagged as provisional, rather than waiting for the vendor's confirmation. Waiting is not a defence against the running clock.

What this page does not cover

This page describes the internal and regulatory procedure once an incident is confirmed. It does not cover the technical forensics work that establishes what happened, and it does not cover simultaneous notification duties that arise where more than one authority in more than one country has jurisdiction over the same incident. Both of those require a file built for the specific facts, not a general procedure.

Verified

This page describes procedural sequence and decision points only. It does not cite specific statutory provisions, since the applicable national implementing rules vary by sector and by country and are checked separately for each matter. Reviewed for accuracy against current regulatory practice; last checked in 2025.

Frequently asked questions

How long does the incident notification procedure take in practice?
The first notification step runs to a short fixed window measured in hours from confirmation. The regulator's own review afterwards typically takes from a few weeks to several months, depending on the scope of the incident and the quality of the initial file.

Which documents are needed to start?
A dated confirmation record, a written scope description, an internal escalation memo, and a signed-off draft notification. Provisional figures are acceptable if marked clearly as provisional.

What happens if the other side does not respond?
Where a vendor or processor involved in the incident fails to respond within the internal deadline, the organisation still files on the basis of confirmed facts, flagged as provisional where needed, rather than delaying submission.

Related reading

How records of processing review data protection what the decision maker checks covers the adjacent review that often follows an incident once containment is complete.

— Rasa Tumenaite, AURELIS