FRM operational risk explained: causes, controls and resilience
Operational risk concerns failures in people, processes, systems or external events. Operational resilience asks whether critical services can continue through disruption. A good answer identifies the failure mechanism, matches a control, and tests the remaining dependency.
| Scenario | Control question | Resilience question |
|---|---|---|
| Incorrect payment instruction | Are validation and authorization effective? | Can the error be detected and corrected promptly? |
| Cloud-provider outage | Are concentration and access risks understood? | Can the critical service operate through the outage? |
| Unavailable staff | Are roles and access documented? | Can an alternate team execute the process? |
| Corrupted data | Are integrity checks and backups reliable? | Can clean data and service be restored together? |
- Identify
- Failure mechanismName what fails and how the loss or disruption occurs.
- Control
- Prevention + responseA control must address the actual cause.
- Resilience
- Critical serviceRecovery must work under the tested disruption.
Trace the service all the way to its dependencies
A service can appear redundant while both routes rely on the same hidden component. Map the people, data, systems, facilities and third parties needed to deliver it. Test a disruption that affects the common dependency.
- 1
Critical operation
Define the service and what an unacceptable interruption would mean.
- 2
Dependencies
Map providers, authentication, networks, staff and data.
- 3
Disruption
Choose a severe but plausible failure affecting those dependencies.
- 4
Recovery evidence
Measure restored service, unresolved transactions and remaining failures.
Worked case: an authorized payment can still be wrong
This original classification example separates access authorization from transaction accuracy.
Original worked example
An authorized employee submits the same supplier payment twice. Both instructions pass the access check. Has the authorization control prevented the operational error?
No. The user is authorized, but the transaction is duplicated.
An access control answers who may act. A duplicate check and reconciliation address different failure mechanisms. Name the event before choosing a control, and do not assume that passing one control proves that the entire transaction is correct.
Separate preventive, detective and recovery controls
A control may reduce the likelihood, detect an event or reduce its impact. Do not call a detective control preventive unless it actually blocks the event. Combine controls around the same failure mechanism.
| Failure | Prevent or reduce | Detect | Recover |
|---|---|---|---|
| Duplicate payment | Unique transaction identifier and authorization. | Duplicate and reconciliation alerts. | Investigate and correct the settlement record. |
| Data corruption | Validated changes and access controls. | Integrity checks and reconciliation. | Restore verified data and reconcile intervening transactions. |
| Third-party outage | Dependency and concentration management. | Service and dependency monitoring. | Tested alternate process or exit arrangement. |
A recovery test needs an observable result
Define what is being tested before the exercise: the service, assumed disruption, permitted workarounds and acceptable outcome. Record whether the team restored usable operations rather than merely starting a backup server. Capture failures as corrective actions with owners.
| Evidence | Useful observation |
|---|---|
| Service | Transactions can be completed and reconciled. |
| Data | Recovered records are complete and consistent. |
| People | The alternate team has access and can execute the procedure. |
| Dependency | The recovery path does not rely on the failed component. |
Separate the event, its cause and its impact
A useful operational-risk description names what happened, why it happened and what it affected. “Payment risk” is too broad. “A duplicate instruction passed through processing because the transaction identifier was not checked” identifies an event and a control gap. The impact might include an incorrect settlement, reconciliation work and a customer problem.
Keep the event classification separate from its financial consequences. A system outage can prevent trading during a market move, but the initiating operational failure differs from the price movement. A credit loss can occur alongside a processing error without the two being the same mechanism. This distinction helps match a control to the cause.
A near miss also deserves a precise description. If a duplicate instruction was caught before settlement, record what detected it and which earlier control allowed it through. The absence of a realized loss does not prove that the process is sound. Equally, one near miss does not quantify the future loss distribution without additional analysis.
| Element | Duplicate-payment illustration |
|---|---|
| Event | The same supplier obligation is submitted twice. |
| Cause to investigate | Missing or ineffective duplicate identification. |
| Control evidence | Whether the duplicate is blocked or detected before settlement. |
| Impact | Incorrect payment, reconciliation and any resulting disruption. |
Why control quality and resilience are different questions
A preventive control reduces the chance of a specified event. A detective control identifies an event or error. Recovery restores usable operations after disruption. A control can have more than one function, but describe what it actually does rather than assuming that a monitoring alert prevents the underlying failure.
Operational resilience extends the discussion to continued delivery of critical operations through disruption. A control may fail, a dependency may become unavailable or several protections may share a common weakness. The relevant question then concerns the service and the ability to operate within the institution’s defined tolerance, not just whether a backup component exists.
Use the detailed Part II lesson for dependency mapping, tolerances and recovery assessment. This concept guide supplies the vocabulary and classification needed to read those cases. The distinction also helps with Current Issues: a technology can improve an analytical process while increasing dependence on a shared provider.
Common questions
- Is resilience just disaster recovery?
- Disaster recovery is part of it. Resilience also considers critical operations, people, data, third parties and the ability to deliver service through disruption.
- Does outsourcing remove operational risk?
- No. It changes the dependency and oversight task; the service can still fail through a third party.
- Is the lowest-cost control always the best answer?
- Choose the control that addresses the stated risk and operating context. The question’s facts determine the tradeoff.
Sources and editorial notes
By MiloPrep editorial team. Source check: . Official requirements and product information can change. Examples and planning allocations are independent teaching material, not official questions or passing standards.
- Basel Committee: operational resilience ↗
Critical operations, dependencies, disruption testing and third-party resilience.
MiloPrep is an independent study resource and is not affiliated with or endorsed by GARP or the named providers. FRM and provider names are trademarks of their respective owners. Editorial methodology.