Issue & Incident Log¶

Ready

Purpose. The record of what went wrong, what you did, and what changed as a result. It is both a management tool and the evidence base for serious-incident reporting duties.

When to use it. From day one. You need the route defined before the first incident, not during it.

How to use it. Define severity and the reporting clock in advance, and make reporting easy and blameless. The failure mode is not a bad log — it is people not reporting at all because they fear the consequences.

Closes assessment gaps

This template addresses Q14, Q18, Q30 in the readiness assessment.

Fill it in here¶

Work directly in the browser — nothing is uploaded, and your rows are saved on this device. Download to Excel whenever you want, or save a file you can reopen later.

Loading the editable register…

The template¶

Severity¶

Severity	Definition	Response	Notify
S1 Critical	Harm to people, regulatory breach, or major data loss	Immediate; incident lead appointed	Committee immediately; Board; regulator assessment within Within 24 hours of detection, in parallel with fixing itUnless: Immediately if the incident involves harm to a person or special category data.
S2 Major	Material impact; significant risk	Within 4 hours	Committee within 24 hours
S3 Moderate	Contained impact	Within [1 working day]	Governance Lead
S4 Minor	Negligible	Next cycle	Logged only

The serious-incident clock

Under Art. 73 the reporting window for serious incidents is short and starts when you establish the link between the system and the incident — not when you finish investigating. Assess reportability early and in parallel with fixing it.

The log¶

ID	Date	Title	System	Severity	Type	Reported by	Owner	Personal data?	Reportable?	Status	Closed
INC-001	[date]	Model returned biased ranking	AI-004	S2	Fairness	[name]	[name]	Yes	Under assessment	Open
INC-002	[date]	Confidential doc pasted into public LLM	—	S2	Data leak	[name]	[name]	Yes	Yes — DPA	Closed	[date]

Incident types¶

Fairness / bias · Accuracy or drift · Data leak · Unauthorised use · Security (injection, poisoning, extraction) · Availability · Transparency failure · Oversight failure · Third-party / vendor · Regulatory

Record for each incident¶

What happened — factual, no blame.
When — occurred, detected, reported. The gap between occurred and detected is itself a finding.
Impact — who and what was affected, how many people.
Immediate action — including whether the system was suspended.
Root cause — the real one, not the proximate one.
Reportability assessment — with the reasoning and the date decided.
Remediation — actions, owners, dates.
Lessons — what changed so it does not recur.

Post-incident review¶

For S1 and S2, hold a blameless review within Within 10 working days for S1 and S2Unless: Within 5 working days if the incident is still open or a regulator has been notified — the facts fade fast and you may need them. Ask:

Could we have prevented it? Which control failed or was missing?
Could we have detected it sooner?
Did the escalation path work as written?
What changes in policy, control, or design follow?
Does anything here change the Risk Register?

Trends¶

Review quarterly for pattern: repeat causes, systems appearing often, and detection times getting longer. Report to committee via KPI / KRI Dashboard.

Adaptation notes¶

Small organisations: Use your existing incident process and add the AI-specific fields — system, reportability, personal data. A separate AI process will not be remembered under pressure.
Regulated sectors: Map severity to your existing operational incident taxonomy and regulatory reporting triggers, so one incident does not get two incompatible severities.
Consumer-facing services: Add a customer communication field: what was said, by whom, and when. It is usually the part that gets scrutinised afterwards.

Not legal advice

These templates are a head start, not a substitute for professional judgement. Adapt them to your jurisdiction, sector, and risk appetite, and have qualified counsel review anything material before you rely on it.