Introduction
When an auditor asks what your AI systems did and how you know, the incident record is the answer. This page covers what that record proves, what it cannot prove, how long it lasts, and — candidly — how you get it out of the product today.
Why an incident is evidence at all
Most operational logs make poor evidence because they can be edited and because they record an event without recording the rule that made it an event. An incident avoids both.
Evidentiary property | How the incident record provides it |
Tamper resistance | Only status, assignee and notes can be changed. Detection, severity, action, control, policy, asset, trace and timestamp are all immutable |
Provenance | Names the control that fired and the policy it belonged to — the rule, not just the event |
Attribution | Names the asset, its owner ( |
Corroboration | Links to the trace, so the surrounding run can be inspected |
Human judgement | Notes and the resolution status record what a person concluded |
Note: The immutability is the feature. An incident you could edit would prove nothing. If a control stamped the wrong severity, the correct action is to fix the control — future incidents get the new severity, and the historical ones keep the old one, which is exactly what an auditable trail requires.
What it proves — and what it does not
Claim | Supported? |
"A control was in force on this date" | Yes — an incident could only be raised by a control that was running |
"This specific content was caught, and this was done" | Yes |
"A person reviewed it and reached this conclusion" | Yes, if triage notes were written |
"Nothing was missed" | No. Incidents evidence what was detected. Absence of incidents is not absence of breaches |
"The action was actually enforced" | Only on an enforced connection. |
"Our whole estate is covered" | No. That is a coverage claim, answered by the registry and policy assignment, not by incidents |
"An empty incident list is equally consistent with excellent behaviour and with no controls pointed at anything. Bring the coverage evidence too."
Two different clocks
The incident and the trace it points at do not last the same length of time. Telemetry ages out of retention after thirty days; the incident record is not telemetry and persists as a record.
So the corroborating detail expires before the finding does. For any incident you expect to matter — a genuine breach, a regulator-facing one, anything feeding a report — capture what you need from the trace during triage, into the notes, while the trace still exists. A note written at the time is contemporaneous evidence; a reconstruction later is not.
Getting evidence out today
There is no export action on the Incidents list. No CSV download, no scheduled report, no evidence pack. This is the honest state of the product, and it shapes how you should prepare for an audit.
What you can do:
Filter to the exact set, then capture the view — The list filters by status, action and policy, and bounds by the
Detecteddate range. A filtered list with the filter criteria visible is a legitimate exhibit — the criteria are what makes it reproducible.Capture individual incidents in full — For the small number that matter, the drawer holds everything on one surface: detection, provenance, triage and notes.
Write the narrative in the notes, at the time — The one part of the record you control is the part an auditor most wants: what you concluded and why. It is also the part that expires if you wait for the trace to be gone.
Pair it with coverage evidence — Incidents show detection. Auditors ask about scope. Bring the registry and the policy's
Applies toalongside — see Evidence for ISO/IEC 42001.
If you need programmatic export
Recurring reporting, or feeding a GRC system, is not something manual capture supports at any reasonable volume. Raise it with your UnifyApps account team with the specifics — the fields you need, the cadence, and the destination — rather than building a manual process you will have to run every month.
Related
Evidence for ISO/IEC 42001