Risk in Financial Services: Operational Risk

Study operational risk for CISI Risk in Financial Services, with a UK-specific reading frame built around the official chapter structure and exam weighting.

Operational risk is one of the most practical chapters on the paper because it turns process failure into financial-services judgement. The exam expects candidates to recognise that loss can arise from people, process, systems, external events, or third-party weakness, and that operational risk management is about control design, resilience, incident response, and learning, not just post-loss classification. The strongest answers connect incidents to framework weakness and then to a credible control response.

Chapter snapshot

CheckWhat matters
Official topic weighting15%
Core distinction under pressureseparate the operational event from its downstream consequences, then choose the strongest framework, measurement, and control response.
Strongest use of this pageread it before timed sets so failed processes, cyber events, outsourcing weakness, and conduct spillovers do not blur together
UK noteKeep the UK frame active: operational resilience, outsourcing, incident reporting, conduct risk, three lines of defence, KRIs, scenario analysis, stress testing, and GBP when a monetary example is needed.

What this chapter is really testing

The exam usually tests whether the candidate can move from event to framework. A payment failure, cyber incident, mis-booked trade, or weak outsourcing control may create reputational, conduct, or financial consequences, but the first task is to identify the operational root and decide how it should be governed.

It also tests whether you understand that measurement supports judgement. Loss data, scenarios, control assessments, KRIs, and self-assessment tools are useful only if they improve prevention, escalation, and resilience.

Section map

SectionMain exam angle
Definitions of operational riskIf a loss follows people, process, systems, or external-event weakness, operational-risk framing is usually the starting point
Operational risk policyIf the question is about ownership, scope, or standards, policy and governance are central
Operational risk frameworkIf the issue is how the firm organises identification, monitoring, reporting, and challenge, think framework rather than one-off control
Operational risk identificationIf the firm is trying to discover where failures may emerge, mapping, assessment, and event capture matter
Operational risk assessment and measurementIf metrics or loss data appear, ask what they actually tell management about exposure and control quality
Managing operational riskIf the stem asks what to do next, the answer usually lives in mitigation, resilience, escalation, or control redesign

Section-by-section lesson

Definitions of operational risk

Operational risk is usually framed around loss arising from inadequate or failed internal processes, people, systems, or external events. At this paper level, the exam uses that definition to build boundary discipline. The candidate should not mistake every loss for credit or market risk when the primary cause is process failure.

Conduct consequences can sit beside operational loss. That is why stronger answers often classify the root cause as operational while acknowledging that the wider impact may reach customers, regulators, or reputation.

Operational risk policy

Policy matters because it sets scope, accountabilities, escalation expectations, and baseline control standards. A strong operational-risk policy is not a glossary document. It tells the business what must be identified, recorded, reported, challenged, and remediated.

Questions here often test ownership. If responsibility is unclear between business lines, risk, compliance, and internal audit, the framework will weaken even before an event occurs.

Operational risk framework

The framework turns policy into working control architecture. It may include risk and control self-assessment, incident capture, KRIs, scenario analysis, governance committees, reporting, and challenge by second-line functions.

The exam usually rewards answers that treat operational risk as recurring management discipline rather than as an annual review exercise. The framework exists to support identification, escalation, and remediation before losses become systemic or customer-harming.

Operational risk identification

Identification tools matter because firms need to know where errors or disruptions are most likely. Process mapping, issue logs, incident histories, control reviews, vendor assessments, and change programmes all help expose weak points.

Third-party and technology dependencies are common themes. A firm can believe a control has been outsourced when in reality only the task has moved and the accountability remains.

Operational risk assessment and measurement

Measurement helps management decide where attention is needed most. Loss-event data, near-miss analysis, KRIs, scenarios, and control scoring all provide different forms of evidence. None of them is perfect in isolation.

The stronger answer normally knows what the metric is for. A KRI is not the same as a loss record. A scenario is not the same as historical evidence. A near-miss can be valuable because it reveals latent weakness before a full loss crystallises.

Managing operational risk

Management includes mitigation, control redesign, incident response, business continuity, lessons learned, and governance escalation. The exam often tests whether the candidate knows that fixing the visible event is not enough if the root cause remains.

Operational resilience overlaps strongly here. A firm may not be able to stop every disruption, but it should be able to identify important services, understand dependencies, and respond in a way that limits intolerable harm.

Best study order inside this chapter

  1. Definitions of operational risk: Start with boundary discipline.
  2. Operational risk policy: Then secure ownership and baseline standards.
  3. Operational risk framework: Build the recurring management structure.
  4. Operational risk identification: Then focus on discovery tools and mapping.
  5. Operational risk assessment and measurement: Add evidence and prioritisation.
  6. Managing operational risk: Finish with mitigation, response, and resilience.

Quick map

    flowchart TD
	A["Operational event or near miss"] --> B["Root-cause identification"]
	B --> C["Control and policy assessment"]
	C --> D["Measurement through losses, KRIs, and scenarios"]
	D --> E["Escalation and remediation"]
	E --> F["Resilience improvement and monitoring"]

What stronger answers usually do

  • identify the operational root before discussing reputational or conduct consequences
  • distinguish policy from framework and framework from individual controls
  • use measurement as evidence for prioritisation rather than as a substitute for management
  • connect incident response to root-cause remediation and resilience learning

Sample Exam Question

A UK wealth manager suffers a failed third-party software update that misroutes client cash transfers and creates £2.4 million of remediation cost. Which is the strongest next-step judgement?

  • A. Treat the issue purely as market risk because client balances moved incorrectly
  • B. Record the event only as a one-off loss and avoid wider framework review
  • C. Analyse the operational root cause, reassess third-party controls, and strengthen escalation and resilience procedures
  • D. Assume outsourcing transfers the control responsibility entirely to the vendor

Answer: C.

The event is operational in origin and requires root-cause analysis, vendor-control review, escalation, and resilience improvement. Outsourcing the task does not remove the firm’s accountability.

Common traps

  • calling every operational event a conduct issue and stopping there
  • assuming policy wording alone proves the framework is strong
  • treating historical loss data as the only useful measurement evidence
  • forgetting that third-party arrangements retain internal accountability

Key takeaways

  • Operational risk management is about framework quality as much as incident capture.
  • Measurement tools should improve control decisions, not replace them.
  • Root-cause remediation and resilience matter more than cosmetic post-event reporting.
Revised on Thursday, April 23, 2026