---
title: "Operational risk management: what regulated customers expect from their tech suppliers"
canonical: https://www.grcmana.io/vault/risk-management/operational-risk-management
published: 2026-10-21
updated: 2026-10-23
author: "Harry West"
framework: "Risk Management"
control: "Guide Operational risk management: what regulated customers expect from their tech suppliers"
journeyStage: intermediate
---

# Operational risk management: what regulated customers expect from their tech suppliers

## Key takeaways

Operational risk management is the ongoing process of identifying, assessing, controlling and monitoring the risk of loss from failed processes, people, systems or external events. Tech suppliers to banks, insurers and payments firms are part of their customers' operational risk, so regulated customers ask for a documented process, tested continuity, incident notification and exit plans before the deal closes.

- **Operational risk** — UK CRR Article 4(1)(52) defines operational risk as the risk of loss resulting from inadequate or failed internal processes, people and systems or from external events, and includes legal risk.
- **Third parties in operational resilience mapping** — An in-scope firm must map the people, processes, technology, facilities and information behind each important business service (SYSC 15A.4.1R), and the FCA expects it to understand its third parties' part (15A.4.2G).
- **DORA Article 30** — DORA Article 30 lists clauses EU financial entities must put in ICT contracts, including data locations, incident assistance and, for critical or important functions, audit rights, tested contingency plans and exit strategies.
- **Critical third parties** — The UK critical third parties rules took effect on 1 January 2025 and apply only to suppliers HM Treasury designates; the regulators may recommend designation, but HM Treasury decides.

The bank's supplier onboarding pack has a section headed "operational risk management framework", and it wants your business continuity plan, your exit arrangements and a named owner. Your platform is ready. Your answers are not, and the enterprise deal is waiting on them.

Operational risk management is the ongoing process of identifying, assessing, controlling and monitoring the risk of loss from failed processes, people and systems, or from external events. When you sell to banks, insurers or payments firms, you become part of their operational risk. They will ask you to show your own process, and the answer decides whether the deal closes.

This guide is for founders, CTOs and security or compliance leads at UK B2B technology firms of 25 to 150 staff selling into regulated customers. It explains why those customers ask and what they ask for. It then sets out the evidence that answers each question, and how to run a process that answers once instead of once per customer.

## What is operational risk management?

Operational risk management (ORM) is the continuous cycle of identifying, assessing, controlling, monitoring and reporting the risks that come from how your business runs. UK prudential law defines operational risk as the risk of loss from inadequate or failed internal processes, people and systems, or from external events. For a tech supplier, those four sources map onto everyday failures.

Banks and investment firms take that definition from [Article 4(1)(52) of the UK Capital Requirements Regulation](https://www.legislation.gov.uk/eur/2013/575/article/4). It also counts legal risk as part of operational risk. You do not need to adopt banking vocabulary, but it helps to recognise it when it lands in a questionnaire.

| Source | What it means | Supplier-side example |
| --- | --- | --- |
| People | Errors, absence or misconduct by staff and contractors | One engineer is the only person who can restore the production database |
| Processes | Inadequate or failed internal procedures | A release goes out without a rollback plan and breaks a customer integration |
| Systems | Failure of technology, infrastructure or data | A cloud region outage takes your service down for six hours |
| External events | Events outside your control, including supplier failure | A sub-processor that handles your email or payments goes offline |

For the wider discipline of risk management, such as the risk vocabulary in ISO 31000, this page assumes you already have the basics. It focuses on the operational risk questions regulated customers send to their suppliers.

## Why do regulated customers ask about your operational risk management?

Regulated firms stay accountable for anything they outsource, so your failures become their regulatory problem. FCA and PRA outsourcing rules, the UK operational resilience rules and, for EU customers, the Digital Operational Resilience Act (DORA) all require them to understand and control the risk their suppliers bring. Those duties reach you as due diligence questions and contract clauses.

None of these rules applies to you directly. They apply to your customer, and your customer passes them on by contract.

**Outsourcing rules keep the customer accountable.** In the FCA Handbook, [SYSC 8.1](https://www.handbook.fca.org.uk/handbook/SYSC/8/1.html) applies to banks, building societies and MiFID investment firms (the FCA's "common platform firms") that outsource critical or important functions. They must ensure, among other conditions, that the provider can perform reliably, discloses material developments and gives access to data and premises (SYSC 8.1.8R). The firm and the provider must also keep a disaster recovery plan where the service calls for one, with periodic testing of backup facilities. Other FCA firms that outsource critical or important functions remain fully responsible for their regulatory obligations (SYSC 8.1.6R).

The PRA sets its expectations in [supervisory statement SS2/21 on outsourcing and third party risk management](https://www.bankofengland.co.uk/prudential-regulation/publication/2021/march/outsourcing-and-third-party-risk-management-ss). It covers PRA-regulated banks, building societies, PRA-designated investment firms and Solvency II insurers, and has a chapter on business continuity and exit plans. The FCA adds its [FG16/5 guidance on outsourcing to the cloud and other third party IT services](https://www.fca.org.uk/publications/finalised-guidance/fg16-5-guidance-firms-outsourcing-cloud-and-other-third-party-it). From 18 March 2027, new FCA rules will require firms to notify the FCA of their material third-party arrangements. That is likely to bring more questions about your service.

**Operational resilience rules reach into your service.** [SYSC 15A](https://www.handbook.fca.org.uk/handbook/SYSC/15A/1.html) applies to enhanced scope SMCR firms, banks, building societies, designated investment firms, Solvency II firms, payment and e-money institutions, and a few others. The PRA's [SS1/21](https://www.bankofengland.co.uk/prudential-regulation/publication/2021/march/operational-resilience-impact-tolerances-for-important-business-services-ss) sets parallel expectations for PRA firms. The FCA's rules came into force on 31 March 2022. According to its [operational resilience page](https://www.fca.org.uk/firms/operational-resilience), in-scope firms had until 31 March 2025 to be able to stay within their impact tolerances.

An in-scope firm must map the people, processes, technology, facilities and information behind each important business service (SYSC 15A.4.1R). Where a third party delivers part of that service, the FCA expects the firm to understand the third party's side well enough to map it (SYSC 15A.4.2G). It also expects the firm to work with the third party on scenario testing (SYSC 15A.5.5G). If your platform sits behind a customer's payments or claims service, you are in their map.

**DORA applies to EU financial customers.** [DORA, Regulation (EU) 2022/2554](https://eur-lex.europa.eu/eli/reg/2022/2554/oj/eng), has applied since 17 January 2025 to EU financial entities. It is EU law, not UK law. Article 28 keeps the financial entity fully responsible when it uses ICT services. Article 30 lists the clauses its contracts with ICT providers must contain. Expect a DORA addendum from any EU bank or insurer that buys your platform.

## What will a bank or insurer ask its tech supplier to show?

Expect six recurring asks: a documented risk process and register, tested business continuity and disaster recovery, incident notification within agreed times, sub-outsourcing and data location, audit and access rights, and exit and transition support. Each maps to a source in the outsourcing, resilience or DORA rules. Each is answered with evidence you can produce on request, not a policy promise.

The table pairs each ask with its source and the evidence that answers it. The evidence column is our recommendation for a firm of your size, not a regulatory list.

| What the customer asks | Where it comes from | Evidence that answers it |
| --- | --- | --- |
| A documented risk process and a current risk register | SYSC 8.1.8R(1) and (3); SS2/21 due diligence | Risk management policy, the register with owners and review dates, the last leadership risk report |
| Business continuity and disaster recovery, tested | SYSC 8.1.8R(11); DORA Article 30(3)(c); SYSC 15A.5.5G | Business continuity plan, recovery time and recovery point targets per service, the last restore and failover test results |
| Incident notification within agreed times | SYSC 8.1.8R(6); DORA Article 30(2)(f) and 30(3)(b) | Incident response procedure with a customer notification step and timings, a recent post-incident review |
| Sub-outsourcing and data location | DORA Article 30(2)(a) and (b) | Sub-processor list with locations, the notice you give before changing one, your supplier due diligence records |
| Audit, access and information rights | SYSC 8.1.8R(9); DORA Article 30(3)(e) | An agreed assurance pack (ISO 27001 certificate, SOC 2 report, penetration test summary) and a process for customer audits |
| Exit and transition support | SYSC 8.1.8R(12); DORA Article 30(2)(d) and 30(3)(f) | A written exit plan: data export format, transition period, and what you will keep running during it |

The DORA rows show the fuller clause set. Under Article 30(3), several of them, including tested contingency plans, audit rights and exit strategies, apply where your service supports a customer's critical or important function.

A business continuity plan nobody has tested is a document, not a capability.

## How do you build an operational risk management process for a 25 to 150 person firm?

Build operational risk management as five steps on one register: identify, assess, control, monitor and report. Give it a named owner at leadership level and a fixed reporting rhythm. At 25 to 150 staff, one register, one owner and a quarterly leadership review usually cover what regulated customers expect, provided every step leaves evidence behind.

1. **Identify.** Start from the services your customers buy, not from a generic risk list. For each one, list what it depends on: people, release processes, cloud infrastructure, sub-processors. The four sources in the table above give you a checklist.
2. **Assess.** Rate each risk for likelihood and impact on the customer's service, not only on your business. A four-hour outage may cost you little but break a bank's payment service.
3. **Control.** Decide how each risk is treated and name the control that does it: a second on-call engineer, a rollback step, a multi-region deployment, a backup sub-processor. Record the decision and the owner.
4. **Monitor.** Check the controls still work and the risks have not moved. Restore tests, failover drills and supplier reviews belong here, with results kept.
5. **Report.** Take the register to leadership on a fixed rhythm. We suggest quarterly, plus after any significant incident. The minutes are evidence that someone with authority owns the risk.

Write the method down once, in a short risk management policy, so the process survives staff changes and answers the "describe your framework" question directly. The detailed mechanics of the register, scoring scales and risk appetite belong to their own pages; this process only needs them to be consistent.

## How much of this does your ISO 27001 and SOC 2 work already cover?

Most of it. ISO 27001 clause 6.1 risk assessment gives you a documented risk process, Annex A gives you continuity and incident controls, and the SOC 2 Availability criteria cover capacity and tested recovery. What is usually missing is the customer's view: impact tolerance thinking, a written exit plan and a customer incident notification commitment.

| What you already have | What it gives you | What is usually missing |
| --- | --- | --- |
| [ISO 27001 clause 6.1](https://www.grcmana.io/vault/iso-27001/clause-6-1-actions-to-address-risks-and-opportunities) risk assessment and treatment | A documented, repeatable risk process with owners | Operational risks beyond information security, such as key-person and release risk |
| [ISO 27001 Annex A 5.30, ICT readiness for business continuity](https://www.grcmana.io/vault/iso-27001/annex-a-5-30-ict-readiness-for-business-continuity) | ICT continuity planned and tested against your own objectives | Recovery targets set against the customer's service, not only yours |
| [ISO 27001 Annex A 5.24, incident management planning](https://www.grcmana.io/vault/iso-27001/annex-a-5-24-information-security-incident-management-planning-and-preparation) | Incident roles, procedures and escalation | A contractual customer notification step with timings |
| [SOC 2 Availability criteria](https://www.grcmana.io/vault/soc-2/trust-services-criteria) | Capacity, resilience and tested recovery, independently examined | Exit and transition arrangements |
| An [ISO 22301](https://www.grcmana.io/vault/iso-22301) or other business continuity plan | Business impact analysis and recovery strategies | Scenario testing shared with customers who rely on you |

Impact tolerance is the idea that matters most. The FCA describes it as the maximum tolerable disruption to an important business service. Your customer sets that tolerance, not you. Ask your largest regulated customers which of their important business services your platform supports, and check your recovery targets against what they need.

Your recovery time objective is a promise to yourself. Your customer's impact tolerance is the one that counts.

## How does GRC Engineering keep your operational risk answers current?

GRC Engineering runs operational risk management as a system rather than an annual document. Continuous control monitoring checks controls automatically, key risk indicators are fed from live systems, and evidence is collected as work happens. The register and your due diligence answers then stay current between audits, so each new customer gets the same verified answer.

In practice, that means three things:

- **Continuous control monitoring.** Automated checks confirm that backups ran, restores succeeded, access reviews happened and production changes were approved, and they flag failures the day they occur.
- **Key risk indicators from live systems.** Uptime, recovery test results, open critical vulnerabilities and sub-processor status feed the register directly, so a risk's rating moves when the evidence moves.
- **Automated evidence.** The records a customer asks for, such as the last restore test or the current sub-processor list, are collected and dated as a by-product of the work, ready to share.

The commercial payoff is speed. A supplier that can send a current, evidenced answer pack in days, instead of rebuilding it for each questionnaire, removes itself from the critical path of the deal.

## Does the UK critical third parties regime apply to your firm?

Almost certainly not. The UK critical third parties regime applies only to suppliers that HM Treasury designates because their failure could threaten financial stability or confidence in the UK financial system. The final rules took effect on 1 January 2025. A 25 to 150 person supplier is very unlikely to be designated.

The FCA's [PS24/16 on critical third parties](https://www.fca.org.uk/publications/policy-statements/ps24-16-operational-resilience-critical-third-parties-uk-financial-sector) confirms that the regulators may recommend third parties for designation, but HM Treasury takes the decision. Your obligations come through your customers' contracts, which is why the asks in this guide matter more to you than the critical third parties rules do.

## What are the common operational risk management mistakes for tech suppliers?

Four operational risk management mistakes recur for tech suppliers. The register is written for the audit and never updated. Each questionnaire is answered from scratch. Resilience is claimed but not tested. DORA is misread as UK law or as someone else's problem. Each one stalls a deal or creates a contract commitment you cannot keep.

1. **A register written for the audit.** A risk register that changes once a year tells a customer when your auditor visits, not how you manage risk.
2. **Answering from scratch every time.** Each fresh answer drifts from the last, and inconsistency is what a customer's due diligence team notices first.
3. **Claiming untested resilience.** Writing "four-hour recovery" into a contract without a restore test to back it turns a sales answer into a breach waiting to happen.
4. **Misreading DORA.** DORA is EU law and does not bind a UK supplier directly, but an EU customer will put its Article 30 clauses in your contract. Signing them makes them your obligations.

A risk you only describe when a customer asks is a risk nobody is managing.

## Frequently asked questions

### What is operational risk management in simple terms?

Operational risk management is how a business finds, rates, controls and keeps watch on the things that could go wrong in how it runs: its people, processes, systems and suppliers. For a tech supplier, it means knowing what could interrupt the service customers rely on, and showing what you do about it. It sits alongside operational resilience, which the FCA describes as the ability to prevent, adapt and respond to, recover from and learn from operational disruption.

### What are examples of operational risk for a technology company?

Common examples are a cloud region outage, a failed release that breaks integrations, a single engineer holding critical knowledge, a sub-processor going offline, a ransomware attack and a mistake in a manual data change. Each one maps to people, processes, systems or external events.

### What is the difference between operational risk management and enterprise risk management?

Enterprise risk management covers every type of risk a business faces, including strategic, financial and market risk. Operational risk management is the part of it that deals with how the business runs day to day. A smaller firm can manage both on one register, with operational risks tagged so they can be reported to customers.

### What does an operational risk management framework include?

An operational risk management framework includes a written policy setting out the method, roles and reporting, and a register that applies it. Two parts are often missed: a short list of risk categories, so every team describes risks the same way, and a log of incidents and near misses that feeds the register, so ratings reflect what has actually gone wrong. Regulated customers will also look for business continuity, incident notification and exit arrangements alongside it.