Operational Risk and Business Resilience

Introduction and Context

Banks, insurers and other financial institutions depend on people, processes, technology, information and external service providers. A failure in any of these elements can interrupt payments, misstate financial records, expose confidential information, breach a legal obligation or damage public confidence. Operational risk management addresses these exposures systematically.

Operational risk is commonly defined as the risk of loss resulting from inadequate or failed internal processes, people and systems, or from external events. This definition includes legal risk, but generally excludes strategic and reputational risk as separate categories, although operational events may produce both strategic and reputational consequences. Examples include employee fraud, processing errors, cyberattacks, poor change management, technology outages, litigation, natural disasters and the failure of a critical cloud provider.

Business resilience is the organisation’s ability to prepare for, respond to and recover from disruption while continuing to deliver important products and services. Contemporary resilience thinking goes beyond restoring systems after an incident. It asks whether the institution can remain within predefined impact tolerances during disruption, even when individual assets, locations or suppliers are unavailable.

This chapter develops a practical framework for identifying, assessing, controlling and monitoring operational risk and for designing business continuity and operational resilience arrangements.

Learning Objectives

By the end of this chapter, students should be able to:

1. Explain operational risk and distinguish it from related risk categories.
2. Analyse how people, processes, systems and external events create operational exposures.
3. Evaluate controls for fraud, legal risk, outsourcing and third-party failure.
4. Use risk-and-control self-assessments, loss-event data and scenario analysis.
5. Explain business continuity, disaster recovery and operational resilience.
6. Interpret measures such as recovery time objective, recovery point objective and expected loss.
7. Recommend governance arrangements and improvements to resilience capability.

1. The Nature and Scope of Operational Risk

Operational risk is pervasive because every financial service requires a sequence of activities. A loan application must be captured, assessed, approved, documented, disbursed and monitored. An insurance claim must be registered, investigated, authorised and paid. Each activity presents opportunities for error, manipulation, delay or failure.

A useful causal model has four primary sources:

Legal risk is usually included within operational risk. It arises from unenforceable contracts, regulatory breaches, inadequate disclosures, employment disputes, consumer-protection failures or litigation. Strategic, credit, market and liquidity risks are distinct, but operational weaknesses can trigger them. For example, a faulty trading system may create market losses, while a payment-processing failure may generate liquidity pressure.

Operational risk has several distinctive characteristics. It is often difficult to estimate from historical data because severe events are rare and the business changes over time. It is also highly interconnected: a cyberattack may exploit a people weakness, disrupt a technology platform, activate a third-party dependency and create legal consequences simultaneously. Finally, operational risk is not normally managed by eliminating all risk. Controls cost money and can themselves introduce complexity. The objective is proportionate risk taking within approved limits.

2. Governance and the Three Lines Model

The board is responsible for ensuring that operational risk is governed consistently with the institution’s strategy and risk appetite. It approves significant policies, oversees resilience of important services and receives information about material incidents and emerging threats.

Senior management translates board expectations into processes, resources and accountability. Business managers own the risks arising from their activities. They are responsible for designing controls, correcting deficiencies and ensuring that staff follow procedures.

A practical three-lines model is:

• First line—business and operations: owns risks and operates controls.
• Second line—risk and compliance: establishes methods, challenges assessments, aggregates information and monitors adherence.
• Third line—internal audit: independently evaluates governance, risk management and controls.

The model is not a substitute for management responsibility. A risk department should not become the owner of risks created by business units. Nor should internal audit design or operate the controls it later evaluates.

A sound governance system includes a policy hierarchy, defined risk appetite, escalation thresholds, incident reporting, issue tracking, independent assurance and documented accountability. Risk appetite should be expressed in business terms—for example, maximum tolerable downtime for a critical payment service, zero tolerance for deliberate regulatory misconduct, or a low tolerance for unauthorised access to customer data.

3. Identifying and Assessing Operational Risk

Risk and control self-assessment

A risk and control self-assessment (RCSA) asks each business unit to identify important activities, threats, existing controls, control weaknesses and residual risk. The process should be evidence-based rather than a negotiation designed to obtain a preferred rating.

A basic sequence is:

1. Map the process and identify its important outputs.
2. Identify failure events and causes.
3. Record preventive and detective controls.
4. Assess inherent risk before controls.
5. Assess residual risk after considering control effectiveness.
6. Compare residual risk with appetite.
7. Assign actions, owners and due dates.
8. Validate material assessments independently.

Many organisations use ordinal scales such as 1 to 5 for impact and likelihood. A simple score may be calculated as:

The ratings are dimensionless ordinal judgements, not precise probabilities. Multiplying them creates a prioritisation aid, not a mathematically exact measure of expected loss. The method is useful for consistency but can conceal important differences: a rare catastrophic event may receive the same score as a frequent moderate event.

Key risk indicators

Key risk indicators (KRIs) provide forward-looking signals. Examples include failed authentication attempts, system availability, overdue reconciliations, staff turnover in a control function, unresolved audit issues, claims-processing backlogs and supplier incidents. A KRI should have a clear owner, data definition, frequency, threshold and escalation action. Excessive indicators create reporting noise and encourage attention to what is easy to count rather than what is important.

Loss-event data

A loss database records actual events and near misses. Useful fields include date, business line, event type, cause, gross loss, recoveries, direct costs, dates of discovery and resolution, affected customers, control failures and lessons learned.

For events with measurable monetary losses, a simple average loss is:

where L_i is the loss from event i and n is the number of recorded events. This statistic is meaningful only when event definitions, reporting thresholds and observation periods are consistent. It can be seriously biased by under-reporting, changing business volume and the small number of severe events.

A basic expected annual loss estimate is:

where λ is the expected frequency of loss events per year and E[L] is the expected monetary loss per event. The formula assumes that frequency and severity are adequately represented and that their product is an appropriate expectation. It does not predict the loss in any particular year and does not describe extreme-tail risk.

Worked example. A payment process experiences an estimated 12 operational incidents per year. The average loss per incident is £4,000. The estimated expected annual loss is:

12 × £4,000 = £48,000

This estimate supports decisions about controls, but management must also consider customer harm, regulatory consequences and the possibility of a rare event much larger than £4,000.

Scenario analysis

Scenario analysis explores plausible severe events for which historical data are insufficient. A scenario should specify the initiating event, affected services, duration, dependencies, customer impact, management actions and recovery assumptions. Examples include a ransomware attack during a peak payment period, a cloud provider outage, simultaneous staff unavailability and a major data-integrity problem.

Effective scenarios are challenging but credible. They should involve subject-matter experts, technology and business representatives, compliance, communications and senior decision-makers. Results should be converted into improvements, not merely recorded as a severe rating.

4. Control Design and Operational Risk Treatment

Controls may be preventive, detective or corrective. Preventive controls stop an event or reduce its probability; detective controls identify an event; corrective controls limit consequences and restore operations.

Examples include segregation of duties, approval limits, reconciliations, access controls, transaction monitoring, exception reports, backups, staff training, insurance and incident-response procedures. A control is effective only if it is appropriately designed and operates consistently. A documented procedure that staff routinely bypass is not an effective control.

Important design principles include:

• Segregation of duties: no single person should initiate, approve and settle a high-risk transaction.
• Least privilege: users receive only the access required for their role.
• Maker-checker review: significant actions require independent verification.
• Reconciliation: records from separate sources are compared and exceptions resolved.
• Change control: system and process changes are tested, approved and traceable.
• Fail-safe design: systems should default to a controlled state when an essential check fails.
• Evidence and auditability: decisions and approvals should be reconstructable.

Controls should be risk-sensitive. Excessive manual approvals can slow service, encourage workarounds and create new error opportunities. Automation can improve consistency but may scale errors rapidly if rules, data or model assumptions are wrong.

5. Fraud, Conduct and People Risk

Fraud involves intentional deception for personal or organisational gain. The fraud triangle identifies three common conditions: pressure or incentive, opportunity and rationalisation. Governance can reduce opportunity through access controls, independent review, monitoring, job rotation and protected whistleblowing channels. It cannot assume that only poorly performing or junior employees commit fraud.

External fraud includes account takeover, identity theft, payment manipulation and social engineering. Internal fraud includes unauthorised trading, procurement collusion, false expense claims and manipulation of customer records. Controls should address the complete transaction lifecycle, including onboarding, authentication, approval, settlement and post-transaction review.

A strong anti-fraud programme combines preventive, detective and responsive measures. It includes a code of conduct, conflicts-of-interest declarations, background screening where lawful and proportionate, staff training, data analytics, investigation protocols and disciplinary consistency. Ethical culture matters because employees may technically comply with procedures while deliberately exploiting gaps in their purpose.

Whistleblowing systems should provide confidentiality, protection against retaliation and escalation outside the accused employee’s reporting line. Investigations must preserve evidence, respect due process and comply with privacy and employment law.

6. Legal, Compliance and Regulatory Risk

Legal and compliance risk is managed through clear obligations, accountable owners and timely interpretation of regulatory change. Institutions should maintain an obligations register linking laws, regulations, licences and contractual duties to policies, controls and evidence.

Common weaknesses include unclear customer disclosures, inappropriate product design, poor record retention, inadequate consent, weak complaint handling and contracts that do not define service levels or liability. Legal review should occur before material products, outsourcing arrangements and technology changes are launched—not only after a dispute arises.

Regulatory compliance is not identical to good risk management. A firm may satisfy a minimum rule yet remain vulnerable to customer harm or operational disruption. Conversely, a proportionate control framework may exceed formal requirements where the risk warrants it. Board reporting should therefore combine compliance status with actual outcomes, incidents and control effectiveness.

7. Outsourcing and Third-Party Risk

Outsourcing transfers an activity, not ultimate accountability. A bank remains responsible for complying with law and serving customers even when processing, cloud infrastructure, call-centre operations or information security are provided by another organisation.

Third-party risk management should cover the whole lifecycle:

1. Due diligence: evaluate financial strength, ownership, competence, security, resilience, subcontractors and legal standing.
2. Contracting: specify services, performance measures, audit rights, data use, confidentiality, incident notification, business continuity, liability and termination assistance.
3. Onboarding: test interfaces, access, reconciliations, escalation and contingency procedures.
4. Monitoring: review service-level results, incidents, assurance reports, concentration and changes in the provider.
5. Exit: maintain a credible plan for transfer, substitution, internalisation or orderly closure.

Concentration risk is important. Several institutions may depend on the same cloud region, telecommunications network, software component or specialist provider. A provider can be financially healthy and still fail to meet an institution’s needs during a systemic event. Contracts and certifications are useful evidence, but they do not replace testing and independent oversight.

8. Business Continuity, Disaster Recovery and Operational Resilience

Business continuity management (BCM) prepares the organisation to continue or recover critical activities after disruption. A business impact analysis identifies important products and services, dependencies, disruption consequences and recovery priorities.

Disaster recovery (DR) is the technology-focused part of recovery, including restoration of infrastructure, applications and data. BCM is broader: it includes people, premises, communications, manual workarounds, suppliers and decision-making. Operational resilience is broader still. It focuses on the ability to deliver important services through disruption, using preventative and adaptive capabilities as well as recovery.

Key terms include:

• Recovery time objective (RTO): the target maximum time within which a system, process or service should be restored after disruption.
• Recovery point objective (RPO): the maximum acceptable period of data loss measured in time, such as 15 minutes of transactions.
• Maximum tolerable period of disruption (MTPD): the longest period an activity can be unavailable before unacceptable harm occurs.
• Impact tolerance: the maximum level of disruption to an important service that an organisation is prepared to accept, often expressed through time, volume, customers affected or financial and non-financial harm.

RTO and RPO are design targets, not guarantees. If an activity has an RTO of two hours, recovery arrangements must be capable of meeting that target under defined assumptions. If its RPO is 15 minutes, backup and replication arrangements must limit unrecoverable data to that period, subject to the stated technical conditions.

Figure: An operational resilience cycle linking service identification, impact assessment, response, testing and continual improvement.

Resilience strategies may include resilient architecture, geographically separate facilities, tested backups, alternate suppliers, cross-trained staff, manual processing, emergency communications and predefined decision rights. The appropriate solution depends on the service’s impact tolerance and dependencies; a costly active-active architecture is not justified for every process.

Testing should progress from document reviews to walkthroughs, technical recovery tests, failover exercises and realistic scenario simulations. Tests should include senior decision-makers and external providers where relevant. A successful technical failover does not prove that customers can access services, staff can operate them or legal and communication obligations can be met.

9. Incident Management and Lessons Learned

Incident management aims to contain harm, protect people and customers, restore service and learn from the event. A structured process normally includes detection, triage, classification, escalation, containment, eradication, recovery, communication and post-incident review.

Severity criteria should consider customer harm, duration, affected volume, data sensitivity, financial loss, legal duties and systemic implications. Communications should be accurate, timely and coordinated. Concealing an incident can increase legal and reputational damage and may breach notification duties.

Root-cause analysis should distinguish the immediate trigger from underlying weaknesses. For example, a payment error may be triggered by a software change, but underlying causes may include weak testing, unclear ownership, excessive deadline pressure and inadequate monitoring. Corrective actions should have owners, deadlines and effectiveness tests.

10. Technology, Cybersecurity and Artificial Intelligence

Technology creates both resilience and concentration challenges. Cloud services, application programming interfaces, automation and real-time analytics can improve speed and control, but they introduce dependency, configuration, access and data risks. Cybersecurity should be integrated into operational risk management through identity management, secure development, vulnerability management, network protection, logging, detection, response and recovery.

Artificial intelligence can assist with fraud detection, incident classification, control testing and scenario generation. However, AI systems may produce false positives, discriminatory outcomes, opaque decisions, data leakage or model drift. Human oversight, documented purpose, data governance, validation, access controls and an appeal process are necessary where AI affects customers or material decisions. An AI tool should not be treated as an independent control merely because it is sophisticated.

11. Applied Case: Illustrative Regional Bank Payment Outage

Background

The fictional Meridian Regional Bank processes retail payments through an internal interface connected to a cloud-based service provider. Its stated target is to restore the payment service within four hours, with no more than 30 minutes of transaction data unrecoverable.

Problem

During a peak salary-processing day, a supplier software update caused duplicate payment messages and then halted the interface. The bank’s automated reconciliation stopped. Telephone lines became congested, and branch staff lacked a current manual-processing procedure. The cloud provider’s status page reported a regional incident. The bank had tested restoration of its own application but had not tested the complete supplier interface or customer communications.

Analysis

The event involved several risk sources: change-management weakness, third-party dependency, inadequate reconciliation, insufficient capacity planning and incomplete continuity procedures. The bank’s RTO was not met because restoration of its application did not restore the end-to-end service. Its nominal RPO was also misleading because transaction queues held by the provider were not covered by the bank’s backup design.

The incident showed the difference between component recovery and service resilience. It also exposed concentration risk: the bank had no alternative processing route and several critical functions depended on the same telecommunications provider.

Approach and solution

The bank established an incident command team, froze risky message reprocessing, reconciled internal and provider records, and prioritised salary and vulnerable-customer payments. It issued staged customer communications and notified relevant authorities according to its obligations. After stabilisation, it required the provider to strengthen release testing and notification procedures.

Longer-term actions included an end-to-end service map, an independent reconciliation control, dual approval for material supplier changes, tested manual processing, alternate communications, clearer contract rights, provider exit analysis and quarterly scenario exercises involving the supplier. The board revised the impact tolerance to include maximum delayed-payment volume and customer communication deadlines, not only system restoration time.

Outcome and learning points

The bank restored service later than planned but reduced duplicate payments and completed the highest-priority transactions. The principal learning was that resilience must be measured at the level of the important service experienced by the customer. Recovery objectives should cover dependencies, data flows, people, suppliers and communications. Testing must challenge assumptions rather than confirm that a preferred plan works.

12. Challenges, Limitations and Professional Judgement

Operational risk measurement is limited by sparse data, inconsistent classifications, changing business models and dependence on expert judgement. A low number of recorded losses may indicate strong control, low exposure or poor reporting. Quantitative models can create false precision, especially when extreme events are rare and correlated.

Scenario analysis is also subjective. Participants may anchor on familiar events, underestimate duration or assume that suppliers and public infrastructure will function normally. Independent challenge, diverse participants and explicit assumptions improve quality.

Resilience investments involve trade-offs. Redundancy, manual workarounds and multiple suppliers increase cost and complexity. Standardisation and outsourcing may improve efficiency while increasing concentration. Senior managers must weigh financial cost against customer harm, legal duties, systemic consequences and institutional trust.

Ethically, institutions should protect customers who are least able to absorb disruption, including vulnerable customers and those dependent on timely payments. Privacy should be respected in monitoring and fraud analytics. Employees should not be pressured to bypass controls or conceal incidents. Governance should ensure that responsibility remains clear when automated tools and external providers are involved.

13. Best-Practice Implementation Road Map

A practical institution can strengthen capability through the following sequence:

1. Define board-approved operational risk appetite and important services.
2. Map processes, technology, data, people and third-party dependencies.
3. Establish consistent event taxonomy, loss reporting and issue management.
4. Perform RCSAs supported by KRIs, incidents and independent challenge.
5. Prioritise controls for fraud, access, reconciliation, change and outsourcing.
6. Set impact tolerances, RTOs and RPOs based on customer and business harm.
7. Test continuity, technology recovery, communications and supplier arrangements.
8. Measure deficiencies, corrective action and recovery performance.
9. Use incidents and near misses to update scenarios and controls.
10. Report meaningful information to the board and promote a speak-up culture.

The objective is not a risk-free institution. It is an institution able to understand its operational vulnerabilities, prevent avoidable failures, respond decisively and continue important services within acceptable limits.

Chapter Summary

Operational risk arises from inadequate or failed people, processes, systems and external events and includes legal risk. Its effects may include financial loss, customer harm, regulatory action and disruption of critical services. Effective governance assigns ownership to business management, challenge to the second line and assurance to internal audit.

RCSAs, KRIs, loss-event data and scenario analysis provide complementary evidence. Simple expected-loss calculations can support decisions, but they do not capture uncertainty, extreme events or non-financial harm fully. Controls should be preventive, detective and corrective, with particular attention to segregation of duties, access, reconciliation, change management and evidence.

Fraud, legal risk, outsourcing and third-party concentration require lifecycle management. Business continuity is broader than technology recovery, while operational resilience focuses on maintaining important services within impact tolerances. RTO, RPO and MTPD are useful planning concepts but must be tested across the full service chain. Strong resilience depends on governance, realistic testing, incident learning, ethical conduct and continual improvement.

Key Terms

Operational risk: Risk of loss from failed or inadequate people, processes, systems or external events, including legal risk.

Business resilience: Ability to prepare for, respond to and recover from disruption while continuing important services.

Operational resilience: Capability to deliver important services within predefined impact tolerances during disruption.

Risk appetite: The amount and type of risk an institution is willing to accept.

Risk and control self-assessment: Structured assessment of risks, controls, weaknesses and residual exposure by a business unit.

Key risk indicator: A measure that signals changing exposure or control conditions.

Loss-event data: Recorded information about actual operational losses, near misses and related causes.

Scenario analysis: Assessment of plausible events, including severe events for which historical data are limited.

Preventive control: A control designed to reduce the probability of an unwanted event.

Detective control: A control designed to identify an event or exception.

Corrective control: A control designed to limit consequences and restore operations.

Fraud: Intentional deception for unlawful or improper gain.

Legal risk: Risk arising from unenforceable rights, legal disputes, regulatory breaches or inadequate legal obligations management.

Third-party risk: Risk arising from dependence on suppliers, outsourcers or other external parties.

Recovery time objective: Target time for restoring a system, process or service after disruption.

Recovery point objective: Maximum acceptable period of data loss measured in time.

Impact tolerance: Maximum acceptable level of disruption to an important service.

Business impact analysis: Assessment of the consequences, priorities and dependencies associated with disruption.

Maximum tolerable period of disruption: Longest period an activity can be unavailable before unacceptable harm occurs.

Root-cause analysis: Investigation of underlying conditions that allowed an incident to occur or persist.

Review Questions

5 Short Answer Questions

1. Define operational risk and identify its four primary sources.
2. What is the difference between RTO and RPO?
3. Explain the purpose of a key risk indicator.
4. Why does outsourcing not transfer ultimate accountability?
5. Distinguish business continuity from disaster recovery.

5 Long Answer Questions

1. Explain how the three lines model supports operational risk governance.
2. Compare RCSA, loss-event data and scenario analysis as risk assessment methods.
3. Discuss the design principles of effective fraud and conduct controls.
4. Explain how an institution should manage the lifecycle of a critical third-party provider.
5. Evaluate why operational resilience requires more than restoring technology systems.

3 Analytical / Application Questions

1. A bank records 20 incidents annually with an average loss of £2,500. Calculate the estimated expected annual loss and explain two reasons why management should not treat it as a complete risk measure.
2. A critical insurance claims service has an MTPD of eight hours, an RTO of six hours and an RPO of one hour. Assess whether a recovery plan that restores service in seven hours but may lose three hours of data is acceptable. Explain your reasoning.
3. Design a response and improvement plan for a ransomware incident that disables a bank’s customer portal and affects an outsourced identity-verification provider. Address governance, customer communication, continuity, third-party management and lessons learned.

Multiple Choice Questions with Answers

Question 1

Which statement best describes operational risk?

A. The risk that interest rates will reduce bond values

B. The risk of loss from inadequate or failed people, processes, systems or external events

C. The risk that borrowers will default

D. The risk that an insurer will misprice a policy

Correct Answer: B. The risk of loss from inadequate or failed people, processes, systems or external events

Question 2

A process has an estimated frequency of 10 incidents per year and an average loss of £3,000 per incident. What is its estimated expected annual loss?

A. £300

B. £3,000

C. £13,000

D. £30,000

Correct Answer: D. £30,000

Question 3

Which activity is primarily a detective control?

A. Segregation of duties before approval

B. A reconciliation that identifies unmatched transactions

C. A password policy preventing weak passwords

D. A backup used after data corruption

Correct Answer: B. A reconciliation that identifies unmatched transactions

Question 4

What does an RPO specify?

A. The maximum acceptable period of data loss measured in time

B. The target time to hire replacement staff

C. The maximum legal liability of a supplier

D. The time required to approve a new product

Correct Answer: A. The maximum acceptable period of data loss measured in time

Question 5

Which statement about outsourcing is correct?

A. Outsourcing transfers regulatory accountability to the supplier

B. A supplier contract eliminates concentration risk

C. The institution retains ultimate accountability for outsourced activities

D. Outsourced activities do not need business continuity plans

Correct Answer: C. The institution retains ultimate accountability for outsourced activities

Question 6

Why is scenario analysis particularly useful in operational risk management?

A. It eliminates the need for incident data

B. It examines plausible severe events that may be poorly represented in historical data

C. It guarantees the probability of every event

D. It measures only routine processing errors

Correct Answer: B. It examines plausible severe events that may be poorly represented in historical data

Question 7

Which feature most clearly distinguishes operational resilience from basic disaster recovery?

A. A focus only on rebuilding data centres

B. A focus on delivering important services within defined impact tolerances

C. A decision to avoid all technology suppliers

D. A requirement that no disruption ever occurs

Correct Answer: B. A focus on delivering important services within defined impact tolerances

Question 8

In the three lines model, who normally owns and operates business controls?

A. The first line business and operations

B. The external auditor

C. The board alone

D. The third line internal audit function

Correct Answer: A. The first line business and operations

Question 9

A bank restores its own application within its RTO, but its cloud interface remains unavailable and customers cannot make payments. What key weakness does this reveal?

A. The bank used too many preventive controls

B. The recovery test focused on a component rather than the end-to-end important service

C. The bank had no market risk

D. The RPO was necessarily zero

Correct Answer: B. The recovery test focused on a component rather than the end-to-end important service

Question 10

Which is an important ethical consideration in operational risk management?

A. Concealing incidents to protect reputation

B. Maximising automation regardless of customer impact

C. Protecting vulnerable customers and preventing retaliation against whistleblowers

D. Allowing suppliers to define the institution’s risk appetite

Correct Answer: C. Protecting vulnerable customers and preventing retaliation against whistleblowers