Incident response

Incident response is the workflow that turns a signal — a drift alert, an inbound complaint, an SLA breach, an external regulator query — into a tracked, accountable piece of work with a beginning, a middle, and an end. Every state change is recorded on the ledger, so the timeline of who did what and when is provable.

Severity and category

Every incident is graded with both a severity (LOW, MEDIUM, HIGH, CRITICAL) and a category from a fixed taxonomy:

• MODEL_FAILURE — drift, hallucination, regression in a registered AI model
• BAD_ADVICE — a piece of advice that should not have been given (caught at review or post-issuance)
• DATA_ISSUE — bad inputs reaching the workflow (corrupted fact-find, mis-categorised client)
• SLA_BREACH — a review job missed its 48-hour deadline
• SECURITY — credential leak, unauthorised access, suspicious activity
• OTHER — anything else that needs the incident audit trail

Lifecycle

1. OPEN — newly logged, awaiting triage
2. INVESTIGATING — owner is gathering evidence
3. REMEDIATING — taking action: pulling a model, escalating to a senior reviewer, contacting customers
4. RESOLVED — the action is complete and the root cause is captured
5. CLOSED — terminal state once the post-mortem and any follow-up have been signed off

Each remediation action is tracked separately on the incident with its own status (PENDING, IN_PROGRESS, COMPLETED, CANCELLED), owner and due date.

Evidence produced

• INCIDENT_LOGGED ledger event when the incident is created — anchors the title, severity, category and any affected job/record links to the immutable chain.
• INCIDENT_RESOLVED ledger event when the status transitions to RESOLVED or CLOSED — anchors the root cause and the resolved-by actor.
• Full incident history (creation, status changes, remediation actions) addressable via GET /v1/incidents/{id}.

FCA mapping

• PRIN 11 — Relations with regulators
• SYSC 6.1 — Compliance arrangements
• DISP 1 — Complaints handling

See also

• Drift detection
• Respond to an incident