Register of incidents: documents to prepare
A register of incidents needs five things in place before the first entry is written: a fixed template, a source log, an assigned owner, an escalation trigger and a retention rule. Skip any one of them and the file cannot show where an entry came from later, and that gap is the first thing a supervisory authority or a counterparty checks.
Why the register matters in practice
Most disputes about an incident are not about what happened. They are about when the organisation knew, who told whom, and whether the response matched the timeline the organisation itself set. A register answers those three questions only if each entry carries its own provenance: origin, timestamp and author.
Without that, a register becomes a list of conclusions with no way to check them. Rebuilding provenance after the fact takes days of interviews and email searches. Building it into the template from the start takes minutes per entry.
What the register is for
Under the applicable data protection and cybersecurity framework, an organisation keeps a running record of security incidents, whether or not any single incident is ever reported outward. The record exists so the organisation can show, months later, exactly what it knew and when it knew it.
A register that only lists closed, externally reported incidents fails that purpose. A register that captures every detected event, including the ones closed internally without notification, is the one that holds up under review.
Documents to prepare
Prepare these files before an incident happens, not while one is under way.
- A register template with fixed fields: source, timestamp, detection method, affected system, initial severity, status.
- A source log naming who reported the incident, through which channel, and at what time.
- An internal notification form for the person who detects an incident to complete within hours, not days.
- An escalation matrix naming who decides severity and who signs off on any external notification.
- A retention schedule stating how long each entry stays active and where closed entries are archived.
- A closure checklist confirming remedial steps were taken before an entry is marked closed.
- A short glossary of severity levels, so two people filling in the template use the same words for the same event.
The security lead assembles the template, the escalation matrix and the glossary. The person who detects an incident completes the notification form. The register owner consolidates both into the running log and keeps the retention schedule current.
Stages and timing
| Stage | Typical duration | Who acts |
|---|---|---|
| Detection and internal notification | Within hours of discovery | Employee or system that detects the incident |
| First register entry | Same working day | Register owner |
| Severity assessment | 1–2 working days | Security lead |
| Decision on external notification | Set by the escalation matrix | Management or a delegated officer |
| Remedial steps confirmed | Varies by incident | Security lead and system owner |
| Closure and archiving | After remedial steps are confirmed | Register owner |
Who decides
The register owner decides what goes into the log and when an entry is closed. The security lead decides severity. Whether an incident is reported outward, to a supervisory authority or to a counterparty, is a management decision, taken against the timeline the escalation matrix sets, not against a deadline attached to the register itself.
None of these roles has to sit with outside counsel by default. A lawyer reviews the file when notification is contested, when a counterparty disputes what the record shows, or when the same incident touches a separate contractual file.
Where the register connects to other files
An incident rarely stays inside one document. It usually touches whatever governs the affected system, and the register should say so rather than stand alone.
- If the affected system runs on licensed technology with a defined scope of use, cross-reference the licence file in the register rather than leaving the link implicit — see How field-of-use drafting IP licence documents to prepare runs.
- If the incident overlaps with a pending patent matter, check whether an opt-out from a unified court applies before the register entry is closed — see How opt-out and withdrawal of opt-out patent runs in.
- If closing the incident requires a change to an existing technology contract, route that change through the standing procedure instead of amending the contract informally — see How change control procedure technology contract documents to prepare.
- If the affected system sits on a token issuance platform, confirm who holds the issuer role before the register assigns responsibility for remediation — see Issuer in token issuance: definition and use.
What this page does not cover
This page does not assess whether a specific incident crosses the threshold for external notification. It does not draft the notification text itself. It does not set how many jurisdictions are affected once a group structure with several entities is involved.
Those three questions depend on the facts of the incident, not on a general procedure, and answering them without the facts would make the register less reliable, not more.
Verified
Reviewed 03 February 2025 against current supervisory guidance and internal file-keeping practice. Where an incident later triggers a formal notification, the register still stands as the underlying record. The notification itself is a separate document, built from the register rather than replacing it.
Related reading
Once a register entry escalates far enough to draw outside attention, the next file most organisations need is already familiar territory — see Supervisory inspection: documents to prepare.
FAQ
How long does keeping a register of incidents take in practice?
The first entry takes minutes once the template exists. The full file, from detection through to closure, usually runs from a few days to several weeks, set by the escalation matrix rather than by a fixed calendar deadline.
Which documents are needed to start?
A fixed-field template, a source log and an escalation matrix. Without these three, an entry cannot show where it came from, and that is the first thing checked when the register is reviewed.
What happens if the other side does not respond?
If a processor or counterparty was asked to confirm details and stays silent, the entry is closed on the information available, flagged as unconfirmed, and reopened if new facts arrive later.
If your organisation is building this file for the first time, or trying to bring an inconsistent one back into shape, the technology and data team can work through it with you directly. For a related question on how disputes over contract terms play out once a customer pushes back — see When the customer refuses a limitation of liability in.