Banks often underestimate operational risk by treating it as a back office issue instead of a control failure that can affect the whole institution. The article points to inadequate processes, human error, and IT system failures, along with the Barings example, where weak supervision and missing approvals allowed losses to escalate for years before anyone intervened.
Why banks misread operational risk
Banks often frame operational risk as a support function problem, when the real issue is institutional control failure. That mistake matters because weak processes, human error, and technology failures can interact across front, middle, and back office activities, turning a local breakdown into a firm-wide loss event.
Operational risk is not limited to obvious fraud or one-off process mistakes. It also includes absent approvals, incomplete supervision, poor segregation of duties, and fragile systems that let errors persist long enough to become material.
The Barings case remains useful because it shows the pattern clearly: if oversight is weak and exceptions are not challenged, losses can accumulate unnoticed even when the trading or operations process appears to be functioning normally. This is why operational risk has to be treated as a control design and control execution issue, not just an audit or operations issue.
What makes operational risk so easy to underestimate
The main error is to treat operational risk as something that sits behind the revenue line, rather than something that can reshape it. When management only looks at operational events after they surface, it misses the fact that process gaps, system fragility, and human workarounds are often the conditions that make larger losses possible.
In practice, operational risk grows where controls depend on informal knowledge, manual review, or the assumption that someone else will catch the problem. That includes weak exception handling, unclear ownership, and environments where approvals are expected but not enforced.
Banks also underestimate how quickly technology failures become operational failures. A system outage, data integrity issue, or broken workflow can freeze payments, distort reporting, interrupt customer service, or prevent timely intervention. The risk is not the technology alone, but the business process dependency built around it.
Why supervision, approvals, and system resilience matter together
Operational risk becomes material when control layers are not independent. If the same team can initiate, approve, and conceal an activity, or if the same system both records and validates the activity without challenge, the institution is relying on trust instead of control.
That is why weak supervision and missing approvals are not minor governance defects. They reduce the chance of early detection, increase the blast radius of a mistake, and create a path for losses to continue even after warning signs appear. The same applies to brittle systems: if continuity and reconciliation are weak, the bank may not know whether the process is failing, whether the data is wrong, or whether an exception has already become an incident.
For financial institutions, current guidance suggests looking at operational risk as a chain of control dependencies, not a single control. EU Digital Operational Resilience Act (DORA) is a useful reference point because it treats resilience, incident reporting, and third-party dependency as core operational concerns, not add-ons.
Risk and Threat Considerations
Operational risk becomes more dangerous when institutions assume that losses will be obvious, limited, or quickly reversible. In reality, control failures can compound quietly through poor segregation, delayed escalation, inadequate reconciliation, and system weaknesses that hide the true state of activity until the loss is already large.
Failure mechanism: A process or system breaks down, but no effective second line control, approval gate, or supervisory challenge interrupts the error path early enough. That allows the same weakness to repeat across transactions, desks, or channels.
Impact: The bank can face sustained losses, misstated records, regulatory scrutiny, customer harm, and a credibility problem that is much harder to repair than the original incident.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while DORA defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| DORA | Operational Resilience, Incident Reporting, and ICT Risk Management | Banks' operational risk includes resilience, incident handling, and dependency control. |
| Recommendation — Map operational risk scenarios to resilience, reporting, and third-party controls. | ||
| NIST CSF 2.0 | GV.RM-01 — Risk Management Strategy | Operational risk is a governance and risk-management problem, not only an operations issue. |
| Recommendation — Set a risk strategy that treats process failures as enterprise control failures. | ||
| NIST SP 800-53 Rev 5 | AU-6 — Audit Review, Analysis, and Reporting | Operational risk depends on timely review of logs, exceptions, and anomalies. |
| AC-6 — Least Privilege | Weak supervision and missing approvals often reflect excessive authority and poor segregation. | |
| Recommendation — Review audit and exception data quickly enough to detect repeating control failures. Limit privilege so no single actor can bypass or conceal critical controls. | ||
| CIS Controls v8 | CIS-5 — Account Management | Operational control failure often starts with poor ownership and approval discipline. |
| Recommendation — Enforce account and approval ownership so risky actions remain attributable. | ||
Practitioner Guidance
What to prioritise: Focus first on the control points where an error can become persistent, not just where it is most visible. If a process allows activity to proceed without timely challenge, treat that as a higher-risk condition than a process that is merely inconvenient or manual.
What to verify: Check whether approvals are actually enforced, whether exceptions are independently reviewed, and whether reconciliations are timely enough to stop repeat losses. In operational risk reviews, evidence of “someone should have noticed” is usually a sign that the control design is too weak.
Practitioner takeaway: The best operational risk programmes do not just count incidents, they prove that errors cannot quietly persist across the institution.
Related resources from NHI Mgmt Group
- What do institutions get wrong about tokenization and operational risk?
- What do teams get wrong about operational risk management in CI/CD pipelines?
- What do banks get wrong about digital risk management in AML programmes?
- What do banks get wrong about BCBS 239 when risk reporting still depends on manual reconciliation?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 24, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
