Appearance
Journey: Incident to Risk
How an operational event becomes learning, remediation and an updated risk position — without any of those being assumed from the others.
Fictional example.
Day 0, 02:14 — The event
A payment instruction file fails downstream in the retail payments batch. At 02:31 the operator resubmits per the runbook. The file processes as new, producing 1,412 duplicate transactions.
Duplicate detection alerts at 02:53. Processing is halted at 04:05. All identified duplicates are reversed by 06:12.
Day 0 — Report and triage
The on-call operator reports incident INC-2026-0014 in draft.
The Head of Payments Operations triages it to triage, then investigating:
| Classification | Value |
|---|---|
| Category | operational |
| Severity | High |
| Business service | Retail Payments |
| Owner | Head of Payments Operations |
Reportability is set to potentially_reportable pending assessment. It is not derived from severity.
Four independent classifications
Category, severity, impact and reportability are set separately from different criteria. A High severity incident may be non-reportable; a Medium one may be reportable within 72 hours.
Day 1 — Investigation
The investigation establishes the timeline first:
| Time | Event | Interval |
|---|---|---|
| 02:14 | Batch fails downstream | — |
| 02:31 | Operator resubmits | 17 min to resubmission |
| 02:33 | Duplicates begin processing | — |
| 02:53 | Detection alerts | 20 min to detection |
| 03:10 | Investigation begins | 17 min to response |
| 04:05 | Processing halted | 55 min to containment |
| 06:12 | Reversals complete | — |
The 55-minute containment interval is the largest improvable gap, and only the timeline makes it visible.
Root cause: no idempotency control on batch payment file submission.
Contributing factors:
- The downstream error message did not distinguish "not submitted" from "submitted and failed downstream"
- The duplicate detection threshold was set above the value of 14 of the duplicates
- The failure runbook instructed resubmission with no verification step
What worked: duplicate detection identified 1,398 of 1,412 within 20 minutes; reversals completed same-day; no customer detriment.
The investigation-questions prompt earned its place
The analyst requested AI investigation questions. Nine of eleven prompts were obvious. Two were not — one asked whether the detection threshold covered the full value range of the duplicated transactions.
Nobody had checked. It became contributing factor 2 and a finding.
Day 2 — Reportability
Compliance assesses reportability against the operational incident reporting threshold. Below both the value and customer-count thresholds; all 14 released transactions reversed within four hours with no detriment.
Reportability: not_reportable, with the rationale recorded and reviewed by Legal.
Control linkage: CTL-2026-0074 Duplicate Detection is linked to the incident. It worked — it identified 1,398 of 1,412 within 20 minutes.
Control linkage is not blame
The control operated as designed. The design was wrong: the threshold excluded low-value transactions.
The finding is against the threshold configuration, not against the control's existence. The control's effectiveness rating in continuous assurance is unaffected — the control did what it was configured to do.
In the board report, "our duplicate detection control failed" and "our duplicate detection threshold was set too high" are very different statements, and only one of them is true.
Day 4 — Findings and actions
Three findings are raised — one per contributing factor worth fixing:
| Finding | Subject |
|---|---|
FND-2026-0155 | No idempotency control on batch submission |
FND-2026-0156 | Duplicate detection threshold excludes low-value transactions |
FND-2026-0157 | Batch failure runbook lacks a verification step |
The ambiguous error message was recorded as a contributing factor but not raised as a finding — the vendor platform's error semantics are outside the bank's control, and the runbook change addresses the operational consequence. That decision and its reasoning are on the record.
Three action plans follow, each with an owner, an approver and a verifier.
One finding per fixable contributing factor
A single finding titled "improve batch processing" produces a single vague action plan nobody can verify. Three specific findings produce three verifiable fixes.
Day 4 — Risk impact
RSK-2026-0029 — Payment processing error shows signals:
| Signal | Detail |
|---|---|
| Open findings — High | Three findings raised from INC-2026-0014 |
The Risk Manager reviews. He leaves the residual rating unchanged at Medium, recording:
"Incident materialised a known risk within expected impact bounds. Detective control operated. No financial loss. Residual remains Medium; reassess if the threshold finding is not remediated within the period."
An incident is not a risk realisation requiring a rerating
An incident may involve realised risks. Whether the residual rating should move depends on whether the incident revealed something the rating did not already assume.
Here it did not: the risk anticipated processing errors, the detective control worked, and the impact was within bounds. Rerating on every incident produces a register that tracks recency rather than exposure.
Day 12 — Review
The incident moves to in_review. A task appears in the Head of Operational Risk's Workbench with a deep link.
Day 15 — returned. The reviewer requires the reportability assessment rationale to be documented rather than asserted.
Day 18. Resubmitted with the Legal-reviewed rationale.
Day 21. Approved. Incident closed.
The return is the point of the review
The reportability decision was correct. Its reasoning existed only in a conversation. A supervisor asking about it in two years would have found an assertion and no basis.
The review turned it into a record.
Day 21 — The frozen snapshot
Closure writes an immutable snapshot:
| Element | Value |
|---|---|
| Financial ledger | Estimated 0.00, actual 0.00, recovery 0.00, net 0.00 USD |
| Impact | 14 customers affected; retail payments degraded 3 hours; no data impact |
| Reportability | not_reportable, with rationale and Legal review |
| Investigation | Narrative, root cause, three contributing factors |
| Sign-off | Head of Operational Risk, day 21, with closure rationale |
Net loss 0.00 on a High severity incident. Loss is never inferred from severity.
What closure did not close
| Still open at day 21 | Why |
|---|---|
FND-2026-0155 | Idempotency control not yet built |
FND-2026-0157 | Runbook revision in progress |
| Two action plans | In progress |
Incident closure is independent of finding and action closure
The incident was operationally resolved, investigated, reviewed and closed in three weeks. The idempotency control took five months to build.
Holding the incident open for five months would misrepresent the operational position. Closing the findings alongside the incident would abandon the remediation.
Month 6 — Completion
All three findings closed, all three action plans completed and verified.
The incident has been closed since day 21 and is unchanged.
Risk reassessment: the Risk Manager reviews RSK-2026-0029 and records that the idempotency control materially reduces likelihood. Residual moves from Medium to Low.
That rating change happened because a control was built, not because an incident occurred.
What the journey demonstrates
| Principle | Where |
|---|---|
| Occurrence is not loss | Day 21 — High severity, 0.00 net loss |
| Occurrence is not reportability | Day 2 — assessed independently, by Compliance and Legal |
| Occurrence is not control failure | Day 2 — the detective control worked |
| Occurrence is not a finding | Day 4 — findings created by explicit human action |
| Occurrence is not risk realisation requiring rerating | Day 4 — rating unchanged, with recorded reasoning |
| Closure is not finding or action closure | Day 21 to month 6 |
| Governed closure requires review | Day 15 — the review returned it |