TL;DR
Operational risk is the risk of loss from inadequate or failed internal processes, people, and systems, or from external events. It is the risk that sits inside the day-to-day running of a business: a payment sent twice, an approval skipped, a reconciliation that never tied out. It is usually a process problem before it is a technology problem, which is why it is managed through controls, indicators, and evidence rather than through a single tool.
Key Takeaways: The formal definition comes from the Basel framework, which groups operational loss into seven event types. Most everyday losses fall under execution, delivery, and process management. Good management follows five steps: identify, assess, control, monitor, and report. Key risk indicators such as exception rate and override rate move before a loss does. Automation removes manual-error risk but adds process risk if its behavior cannot be reproduced or inspected.
What operational risk is
The most widely used definition comes from the Basel framework for banks: operational risk is the risk of loss resulting from inadequate or failed internal processes, people, and systems, or from external events. The definition includes legal risk and excludes strategic and reputational risk, which are treated separately.
The definition is written for banks, but the idea applies to any organization. Every business runs on processes performed by people using systems, and each of those three can fail. Operational risk is the term for the losses that follow.
Two features set it apart from other risk types. It is internal in origin: unlike market risk or credit risk, it does not come from the world outside the organization behaving unexpectedly. And it is the risk most closely tied to how work is actually done, which makes it the one most affected by changes in process design and automation.
The seven event types
Basel classifies operational loss into seven event types. The categories are a useful checklist because they force the question of where a loss could come from, not just where one already has.
| Event type | What it covers | A finance or operations example |
|---|---|---|
| Internal fraud | Intentional misconduct by an employee or insider | A payment approved by someone who also controls the vendor record |
| External fraud | Theft or fraud by an outside party | A forged request to change a vendor bank account |
| Employment practices and workplace safety | Losses from employment law, safety, or discrimination issues | A claim arising from a mishandled payroll or leave process |
| Clients, products, and business practices | Losses from failing to meet an obligation to a client or from product flaws | A customer billed under the wrong contract terms |
| Damage to physical assets | Loss of or damage to physical assets from disasters or other events | A flooded data center or warehouse |
| Business disruption and system failures | Interruption of operations from system or infrastructure failure | A payment run that cannot complete because a bank file fails |
| Execution, delivery, and process management | Failures in processing transactions or managing process relationships | A duplicate payment, a missed approval, or a reconciliation that does not tie out |
Most of the headline cases involve fraud or disasters. Most of the cumulative loss in a finance or operations team comes from the last row, execution, delivery, and process management. These are rarely dramatic. They are small, frequent, and recoverable in isolation, which is why they are tolerated until the total becomes visible.
Examples that look ordinary
Operational risk is easier to recognize in concrete form. These examples come from finance and operations processes and rarely appear in a risk register under their own names.
The duplicate payment. The same invoice arrives twice, once as a PDF and once through a portal, and both are paid. The loss is the amount, plus the effort of recovering it, plus the question of how many others went unnoticed.
The stale bank detail. A vendor’s account number is changed on the strength of an email. The payment is correct against the record and wrong against reality. Our guide to vendor payment fraud controls covers the control for this case.
The reconciliation that does not tie out. A month-end break is carried forward because closing the period matters more than resolving it. The difference stays in the ledger until it is large enough to explain.
The approval that was bypassed. A control exists on paper, and under time pressure someone approves on behalf of someone else. The control is designed correctly and operates incorrectly.
The process only one person understands. The work is done correctly every month until that person is absent, and then it is not done at all.
The spreadsheet that became a system. A workbook built for one purpose now feeds decisions across the team, with no version control and no review of its formulas.
The management process
Frameworks differ in labeling, but the work follows five steps.
Identify. List the processes, the people and systems they rely on, and the ways each could fail. Use the seven event types as a prompt, and include losses that have already happened.
Assess. Estimate how likely each failure is and how large the loss would be. For frequent, small losses, use real data. For rare, severe ones, use scenarios.
Control. Decide what prevents the failure, what detects it, and what limits the damage. Match the control to the risk: approval limits and segregation of duties prevent, reconciliations detect, and recovery procedures limit.
Monitor. Track indicators and test that controls operate. A control that exists but is not tested is an assumption.
Report. Show owners and leadership what has changed and what has been lost, in terms they can act on. Our guide to internal controls covers how controls fit into this cycle.
Key risk indicators
A loss record tells you what has already gone wrong. Key risk indicators, usually shortened to KRIs, are measures that move before the loss does, which makes them the practical monitoring tool for operational risk.
| Indicator | What it signals | Why it leads |
|---|---|---|
| Exception rate | How often work falls outside the standard path | Rising exceptions mean the process no longer fits the work arriving |
| Manual-touch rate | How much of the volume needs a person | Manual steps are where keying errors and skipped checks occur |
| Override rate | How often a control or system result is bypassed | Frequent overrides show a control people are working around |
| Aged reconciling items | Unresolved differences and how long they have been open | Old breaks are losses that have not been recognized yet |
| Time to detect | How long an error lives before someone finds it | Longer detection means larger and harder-to-trace losses |
| Key-person dependency | Steps only one person can perform | A single absence turns into a process failure |
Pick a small number tied to the specific failures you identified, set a threshold for each, and decide in advance who acts when it is crossed. An indicator with no owner and no threshold is a chart.
Operational, compliance, and enterprise risk
These terms overlap in practice, which is why they are confused.
Operational risk is loss from failed processes, people, and systems. Compliance risk is loss from failing to follow laws, regulations, or internal policy. A failed process often causes a compliance breach, and a compliance breach is often caused by a failed process, so the two are managed together even though they are defined separately.
Enterprise risk is the umbrella. It covers every category, including strategic, financial, and market risk, and aggregates them into one view for leadership. Operational risk is one input to it.
The practical difference between risk and compliance is the question each asks. Risk management asks what could go wrong and how much it would cost. Compliance asks whether we are doing what we are required to do.
Where automation helps and where it adds risk
Automation changes the operational risk profile in both directions.
It reduces the risks that come from manual work: keying errors, skipped steps, inconsistent decisions, and dependence on one person. A rule applied by a system is applied the same way every time and at every hour.
It also introduces new ones. A system whose behavior cannot be reproduced cannot be tested. A system whose decisions cannot be inspected cannot be reviewed. A system that fails silently moves the loss from a visible manual error to an invisible automated one. Automation applied to a poorly designed process runs the poor design faster.
The question to ask of any automated process is the one a control owner would ask of a person: what does it do, how would I know if it stopped doing it, and can I see what it did last Tuesday. The NIST framework treats these questions as part of managing AI risk, and our guide to the NIST AI Risk Management Framework sets them out for operations teams.
Where Kognitos fits
Kognitos is not an operational risk management or GRC platform. It does not replace a risk register, a loss-event database, or the judgment of a risk function. Those are decisions and records your organization owns.
What Kognitos addresses is the operational layer where many of the everyday losses above originate. Processes are written in plain English, so the rule being applied can be read by the person who owns the risk, not only by a developer. Execution is deterministic, so the same input under the same rules produces the same outcome and can be tested. Each decision leaves a record of what was determined and on what basis, which supports detection and the evidence a control test needs. Exceptions are routed to a person, who explains the handling in plain English and sees it applied from then on, which reduces key-person dependency.
For related material, see our guides on internal controls, risk management in banking, automated risk management, the NIST AI Risk Management Framework, and third-party risk management. To see how this works on your own processes, book a demo or try the platform.
