Operational Risk and Resilience
Operational risk management identifies and controls loss events. Operational resilience asks whether critical services can continue through disruption. Map dependencies, set tolerances, test recovery and act on failures discovered in the test.
The topic at a glance
| Concept | How it works | Watch for |
|---|---|---|
| Identify | Map critical operations to people, technology, facilities and third parties. | Assuming two vendors are independent when they share infrastructure. |
| Tolerate | Define the disruption the service can withstand. | Confusing a recovery target with demonstrated recovery capability. |
| Test | Exercise severe but plausible failures and verify actual restoration. | Checking only whether a backup exists. |
01Identify
How it works: Map critical operations to people, technology, facilities and third parties.
Watch for: Assuming two vendors are independent when they share infrastructure.
02Tolerate
How it works: Define the disruption the service can withstand.
Watch for: Confusing a recovery target with demonstrated recovery capability.
03Test
How it works: Exercise severe but plausible failures and verify actual restoration.
Watch for: Checking only whether a backup exists.
Original worked example
Two servers, one shared failure
A payment service has two servers in the same building. Its disruption tolerance is two hours. A site-wide power failure disables both, and the recovery exercise takes five hours.
- STEP 1
The servers share a site dependency, so they are not independent protection against this event.
- STEP 2
Observed recovery exceeds tolerance by three hours.
- STEP 3
Remediate the dependency and repeat an end-to-end service recovery test.
The control gap is demonstrated service recovery under a common-cause failure, not simply the number of servers.
Illustrative assumptions and calculations for learning. Not observed market data or an official exam item.
How the ideas fit together
Before you start: Process controls, critical services and third-party dependencies.
Map the service, including common dependencies
Start with a critical operation such as processing customer payments. Map people, systems, premises, data and suppliers needed to deliver it. Two applications can still fail together through a shared identity provider or network. A dependency map makes that common failure visible before the recovery exercise.
Define the test’s success in service terms
Specify tolerable disruption, the severe but plausible event and the end-to-end service outcome. Record observed restoration, transaction backlogs and data reconciliation. Restarting a server is an intermediate event, not proof that customers can transact correctly. Assign remediation owners and retest weaknesses rather than treating completion of the exercise as success.
Follow the service all the way to the customer
Restoring a database is not the same as restoring payments. Authentication, reconciliation, network access, staff permissions and third-party connections may all be required. Test the full service and include the backlog of work created during the outage. Controls reduce event likelihood; resilience also addresses what happens when controls fail.
Work through the topic
Connect operational-risk controls with continued delivery of critical operations. Assess service outcomes and recovery evidence, as well as losses and capital.
Map the critical operation and its dependencies
Operational resilience concerns the ability to deliver critical operations through disruption. Begin with the service outcome that matters, such as completing payments, maintaining customer access or producing a required risk report. A list of servers is not a service map. Identify the people, processes, technology, information, facilities and third parties required to deliver the outcome.
For an original payment-service case, the operation depends on customer authentication, transaction screening, a ledger, a network connection and settlement access. Each system may have an individual recovery plan, yet the service remains unavailable if they return in the wrong sequence or cannot exchange consistent data. The map should therefore show dependencies and handoffs, including dependencies shared by the main and backup arrangements.
Prioritization should reflect the consequences of disruption for customers, the institution and the wider system. A critical operation may require more stringent continuity arrangements than a low-impact internal convenience. Document the rationale, the accountable owner and the assumptions about acceptable disruption. The Basel principles provide a framework; precise implementation requirements depend on the relevant authority and institution.
Distinguish preventive controls from recovery capability
Preventive controls seek to reduce the likelihood of a failure. Detection controls identify that it has happened. Response and recovery arrangements limit consequences and restore service. These functions are related but not interchangeable. Strong access controls do not prove that a corrupted ledger can be restored, and a successful restore does not prove that unauthorized access has been prevented.
Assume a backup system starts within 30 minutes, but reconciliation and queued-payment processing take another 90 minutes. Reporting a 30-minute recovery time would describe a technical milestone while omitting the service outcome. The relevant end point should specify what users can do, the capacity available and the integrity of the processed transactions. A degraded service can be useful, but its limitations need to be measured.
Evidence should include the scenario, starting conditions, observed timestamps, unresolved exceptions and actual service capacity. A tabletop exercise can reveal decision and communication gaps; an execution test can reveal technical or operational constraints. Neither should be described as proving more than it tested. Record remediation actions and retest material weaknesses after changes.
| Stage | Evidence to record | What it does not prove alone |
|---|---|---|
| Detect | First alert and confirmation time | The root cause has been removed |
| Restore technology | Applications and connections available | Transactions are reconciled |
| Restore service | Successful end-to-end payment and throughput | All backlog has been cleared |
| Recover backlog | Queue size, error rate and customer impact | The same outcome under a larger disruption |
Original payment-service test: evidence at each stage
- Detect
- Evidence to record: First alert and confirmation time
- What it does not prove alone: The root cause has been removed
- Restore technology
- Evidence to record: Applications and connections available
- What it does not prove alone: Transactions are reconciled
- Restore service
- Evidence to record: Successful end-to-end payment and throughput
- What it does not prove alone: All backlog has been cleared
- Recover backlog
- Evidence to record: Queue size, error rate and customer impact
- What it does not prove alone: The same outcome under a larger disruption
Test shared dependencies and severe but plausible disruption
Two suppliers can rely on the same underlying cloud region, telecommunications route or specialist staff. Counting contracts therefore does not measure independence. Examine the dependencies beneath the immediate provider, subject to the information available. Where visibility is incomplete, document the uncertainty and test the consequences of a broader failure rather than assuming the dependency does not exist.
In an original scenario, a primary processor and backup processor both use one identity service. A failure of that service prevents staff from accessing either processor. A useful response might include a securely controlled alternative access procedure, but it requires testing, permissions and adequate capacity. Merely renaming the backup provider would leave the shared dependency unchanged.
Connect the result to governance: compare observed disruption with the institution’s tolerance, assign corrective actions and decide whether residual exposure is acceptable. Capital can absorb some financial losses but does not authenticate customers or settle payments. The companion capital-and-resiliency lesson separates the capital calculation from recovery performance; this overview focuses on managing the complete operation.
Is a business continuity plan enough to demonstrate resilience?
A plan is an input. Demonstration requires evidence that the required operation can continue or recover within the stated conditions, including dependencies, data integrity and realistic capacity. Plans should be exercised and revised when tests expose weaknesses.
Does a shorter outage always mean a successful recovery?
No. A quickly restored service can still process incorrect transactions or exclude an important user group. Assess service availability, integrity, capacity and the consequences of the backlog together.
Try a changed assumption
The backup database is available in one hour, but payments cannot resume for five hours. Which time matters against a two-hour payment-service tolerance?
Show answer and reasoning
The five-hour service disruption. Component recovery does not demonstrate recovery of the critical operation.
Original learning check. No email or account needed.
Does business continuity remove operational risk?
No. Continuity planning and tested recovery reduce disruption consequences, but incidents, control failures and residual exposures remain possible.
Sources and scope
Links checked 2026-10-10. GARP establishes exam scope; the technical references support the methods identified below. These are selected study notes and original examples, not complete curriculum coverage or official exam questions.
- GARP FRM study materials and 2026 learning objectives
Exam-domain scope and the official route to the annual learning objectives. This page does not certify coverage of every reading.
- Basel Committee: principles for operational resilience (2021)
Critical operations, dependencies, disruption tolerances and recovery testing.
Prepared by MiloPrep editorial team. MiloPrep is independent of GARP. References do not imply endorsement or independent review of these notes.