Appearance
Incident Register
Where to find it: Incidents & Loss Events, then Incidents (/incidents).
The register is the record of every material incident, from report to governed closure.
Its business reference is INC-YYYY-NNNN.
What an incident record carries
| Field | Purpose |
|---|---|
| Business reference | INC-YYYY-NNNN, sequential, tenant-scoped |
| Title | A short, recognisable description |
| Description | The event narrative and scope |
| Category | The classification |
| Severity | Low, Medium, High, Critical |
| Status | Its lifecycle state |
| Owner | Who is accountable |
| Business service | The affected service |
| Financial ledger | Estimated loss, actual loss, recovery, net loss, currency |
| Reportability status | The regulatory reporting position |
| Regulatory bodies | Which authorities are involved |
| Regulatory reporting deadline | The statutory disclosure date |
| Investigation | Narrative, root cause category, contributing factors |
| Historical snapshots | Immutable frozen states at closure |
References and deep links
Incidents carry two identities, and only one is ever shown to users:
| Identity | Example shape | Where it appears |
|---|---|---|
| Business reference | INC-2026-0001 | Everywhere a person reads |
| Technical primary key | An opaque internal identifier | Nowhere user-facing |
Deep links resolve business references directly: /incidents?id=INC-2026-0001 opens the incident on first load, on refresh, and from Workbench tasks, notifications and calendar events — with no technical key exposed.
Connected canonical objects
The module maintains no duplicate registers. Incidents link to:
| Category | Objects |
|---|---|
| Scope | Business services, assets, legal entities, organisational units, third parties, engagements |
| GRC | Risks, controls, requirements, evidence |
| Remediation | Findings, action plans |
Human-gated remediation
Findings and actions are never created automatically
Creating a finding or an action plan from an incident is an explicit human action.
An incident is an event. Whether it reveals a control deficiency is a judgement, and it is frequently the wrong judgement — plenty of incidents occur despite controls operating exactly as designed.
When a person does create them, they become canonical records in the shared registers with the incident linked, tracked identically to findings and actions from any other source.
Control linkage is not blame
Linking a control to an incident records that the control was relevant. It does not assert the control failed.
| Situation | What the linkage means |
|---|---|
| A detective control fired and alerted correctly | The control worked; the incident happened anyway |
| A preventive control was bypassed | The control was relevant and did not prevent |
| A control was not in scope for the affected system | A scope gap, not a control failure |
Control assurance records remain independent. An incident does not change a control's effectiveness rating.
Governed isolation
Incident data is completely isolated from the generic entity CRUD surface. The dedicated incident API is the only mutation and query authority.
This prevents ungoverned column writes — an incident cannot be moved to closed, or have its loss ledger altered, by a generic entity update that bypasses the state machine and the review requirement.
Permissions
| Action | Permission |
|---|---|
| View the register, loss assessments, investigations and status | incident.read |
| Report, triage and update details, classifications and impact | incident.manage |
| Record investigation narratives and root causes | incident.investigate |
| Governed review, sign-off and closure | incident.review |
| Generate advisory AI drafts | incident.ai_assist |
Requires the incident_management entitlement.
Example
Incident INC-2026-0014 — Payment file duplication.
| Field | Value |
|---|---|
| Category | operational |
| Severity | High |
| Business service | Retail Payments |
| Owner | Head of Payments Operations |
| Description | A payment instruction file was submitted twice following a failed batch run, resulting in 1,412 duplicate transactions |
Connected objects:
| Type | Records |
|---|---|
| Assets | 3 |
| Controls | CTL-2026-0071 Batch reconciliation, CTL-2026-0074 Duplicate detection |
| Risk | RSK-2026-0029 Payment processing error |
| Findings | FND-2026-0155 |
| Actions | ACT-2026-0301, ACT-2026-0302 |
On control linkage: CTL-2026-0074 duplicate detection worked — it identified 1,398 of the 1,412 duplicates within 20 minutes. Fourteen were released because they fell below the detection threshold.
The finding was raised against the threshold configuration, not against the control's existence. The control's effectiveness rating in continuous assurance was unaffected, because the control operated as designed; the design was wrong.
That distinction survives into the board report, where "our duplicate detection control failed" and "our duplicate detection threshold was set too high" are very different statements.
Troubleshooting
"I cannot set an incident to closed." Closure requires governed review approval. See Closure Governance.
"A deep link with a business reference does not resolve." Check the reference is correct and the incident is in your tenant. Business references are tenant-scoped.
"Findings were not created from an incident." Correct. Creation is human-gated and explicit.
"Incidents is not visible." Requires the incident_management entitlement and incident.read.