Incident notification procedure: documents to prepare
An incident notification procedure runs on a fixed clock, not on convenience. Documents must exist before the clock starts: an incident log, a risk assessment, a list of affected systems and individuals, and a record of what containment steps were taken and when. Assembling these after the deadline has passed does not satisfy the requirement.
Why the sequence matters
The notification window is calculated from the moment the organisation becomes aware of an incident, not from the moment the incident is confirmed or fully understood. Teams that wait for certainty before starting the file lose the time they needed to draft it. A late notification is treated differently from a timely one, even when the underlying incident is identical.
Two clocks run at once. The internal clock covers detection, escalation and the decision on whether the incident meets the notification threshold. The external clock covers the submission itself, once that decision is made. Preparing documents in parallel with the internal clock, rather than after it stops, is what keeps the external clock manageable.
The practical effect of missing the internal deadline is not only a late filing. It removes the option to correct the record before an external body forms its own view of what happened and how fast the organisation responded.
What to prepare, step by step
Assign each document to a named person before the incident happens, not during it. The table below sets out the minimum file.
| Document | Purpose | Typical owner |
|---|---|---|
| Incident log | Timestamped record of detection, escalation and decisions taken | Security lead |
| Risk assessment | Severity, scope and likely consequences for affected individuals or systems | Data protection lead |
| Affected-scope list | Systems, categories of data and individuals within scope | IT operations |
| Containment record | Steps taken to stop or limit the incident, with times | Security lead |
| Notification draft | Text intended for the supervisory authority or affected individuals | Data protection lead with counsel |
| Management briefing note | Short summary for the decision-maker who approves the filing | Data protection lead |
| Post-incident report | What happened, what changed, what prevents recurrence | Security lead |
Draft the notification text before the assessment is complete, not after. A near-final draft that is corrected once new facts arrive is faster to finalise than a blank page written under deadline pressure.
- Log the incident the moment it is detected, with a timestamp, not a summary written the next day.
- Assign the risk assessment to the data protection lead within the same working day.
- Build the affected-scope list from system records, not from memory or assumption.
- Record every containment step as it happens, including steps that did not work.
- Draft the notification text in parallel with the assessment, not after it is signed off.
- Route the management briefing note to the decision-maker before the external deadline, with time left to act on their questions.
Who decides and how long it takes
Internally, the data protection lead or security lead decides whether the incident meets the notification threshold, usually with input from counsel on borderline cases. That decision, not the technical fix, is what starts the external clock.
Externally, the supervisory authority that receives the notification decides whether the response was adequate and timely. It works from the documents submitted, not from an account given afterwards. Affected individuals, where notification to them is required, are informed on a decision made by the same internal decision-maker, once the scope is confirmed.
In practice, the internal timeline is measured in hours rather than days: detection to escalation on the same day, escalation to a notification decision within one working day, the notification itself dispatched once the file is complete. The external deadline is short and starts running from awareness. Treat the first working day as the only day available for internal preparation, and build the file accordingly.
Common forks
If a supplier or processor caused the incident and refuses to cooperate on the record or on indemnity, the notification file still has to be prepared on your own timeline; the dispute with the supplier follows a separate track — see When the other side moved first in this situation.
If the incident exposes technology or data held under a licence rather than owned outright, the question of enforcement against the licence sits with a different decision-maker than the notification itself — see How security enforcement IP licence what the decision maker.
If the incident originates with a technology vendor and the organisation is weighing whether to end the contract rather than pursue a claim, that decision follows its own procedure, separate from the notification file — see How termination for convenience technology contract what the decision.
If the incident touches a tokenised asset system, the documents needed to support a redemption freeze are not the same as the documents needed for a standard notification file, and the two files should not be merged — see Redemption process design: documents to prepare.
What this page does not cover
This page describes the sequence and the documents. It does not set out which incidents trigger a notification duty, which authority receives it, or what the statutory deadline is in a given jurisdiction — those questions depend on the applicable framework and are answered on the pages that address that framework directly, not on a procedure page. It also does not cover the wording of the notification itself beyond noting that a draft should exist early.
We recommend treating this page as the checklist for the file, and the framework-specific pages as the source for thresholds and deadlines.
Verified
Last reviewed: October 2025. This page is procedural by design: it does not cite specific statutory provisions, article numbers or regulatory deadlines. Where a threshold or deadline is relevant to a specific case, it is addressed on the framework-specific pages linked above, not here.
Related publications
The document logic on this page mirrors the file used for a different internal review — see Records of processing review.
FAQ
How long does incident notification procedure take in practice?
Internally, hours rather than days: detection to escalation the same day, escalation to a notification decision within one working day. The external deadline is short and starts from the moment of awareness, not from confirmation, so the first working day carries most of the preparation work.
Which documents are needed to start?
An incident log and a preliminary risk assessment are enough to start. The affected-scope list, containment record and notification draft follow within the same working day, built in parallel rather than in sequence.
What happens if the other side does not respond?
Where a vendor, processor or supplier is implicated and does not respond, the notification file is still prepared and submitted on the organisation's own timeline. Non-response by a third party does not pause the notification clock; it becomes a separate matter to pursue afterwards.
If a live incident is running and the notification file is not yet built, a fast first conversation with a partner is available in working hours — see When the contract is silent on AI output in.