Operational Resilience Executive Briefing: What Boards Must Set, Test and Evidence

Most boards approve a business continuity plan every year, yet few can say how long their most important services can be down before customers or markets are harmed, or whether the firm could stay inside that limit if its main cloud or software supplier failed. Operational resilience regulation asks exactly those questions. The Basel Committee's principles, the UK's important business services regime, the EU's Digital Operational Resilience Act (DORA), Australia's CPS 230 and the US interagency sound practices all start from the same idea: assume disruption will happen and prove you can keep critical services running through it. This briefing is for directors, chief executives, chief risk officers and CISOs in financial services and other regulated sectors. It explains the shared concepts across jurisdictions, what the board itself must set and approve, and how to test management's answers. The EU specifics are in the DORA Executive Briefing and the UK rules in the UK Financial Operational Resilience Guide.

Source note: regulatory dates and definitions below come from the Basel Committee (BIS), the Bank of England PRA, the FCA, APRA, the Federal Reserve and the FSB, as read in November 2026. The board questions, red flags, investment priorities and 90-day plan are NHI Mgmt Group recommendations, not regulatory requirements. Confirm against the official text before relying on it.

The risk in one paragraph

Customers judge a firm on whether its services work, not on whether its servers are up. A payment that cannot be made, a claim that cannot be filed or a trade that cannot settle causes harm within hours, and the cause is now as likely to be a supplier's faulty update, a cloud region failure or ransomware at a software provider as anything inside the firm. Traditional business continuity planning protects assets and sites. Operational resilience protects outcomes: it asks the firm to name the services that matter most, set a hard limit on how much disruption each can bear, map everything those services depend on (people, technology, data, facilities and third parties), and test against severe but plausible scenarios until it can show it stays within the limit. Where several firms share the same supplier, the failure becomes a sector problem, which is why supervisors in the UK and EU now oversee critical technology providers directly. The board owns the limits, approves the self-assessment and answers for the result.

Why this is a board-level issue now

• The deadlines have passed. The UK FCA and PRA rules came into force on 31 March 2022, and by 31 March 2025 firms in scope had to have completed mapping and testing and be able to remain within impact tolerances. DORA has applied in the EU since 17 January 2025. Supervisors have moved from asking about plans to asking for evidence.
• Regulators name the board. The Basel Committee's Principle 1 (governance) places responsibility for the operational resilience approach with the board, and the UK, EU and Australian regimes all require board approval of key artefacts such as impact tolerances, the self-assessment or the ICT risk framework.
• Concentration is now supervised. The UK critical third parties regime (PRA PS16/24, FCA PS24/16, published 12 November 2024) took effect on 1 January 2025, with HM Treasury designating the providers. In the EU the supervisory authorities designate critical ICT third-party providers under DORA. Your suppliers are becoming regulated entities, but that does not move your accountability.
• Disruption increasingly comes from outside. The July 2024 faulty endpoint update and the 2025 UK retail cyberattacks, which Marks and Spencer has said involved social engineering through a third party, show that the most damaging events often start in the supply chain. The Marks and Spencer cyberattack is a reminder of how long recovery can take when it does. See the Major IT Outage Lessons Guide for what the post-incident reviews found.

One idea, several rulebooks

The vocabulary differs between jurisdictions but the structure is the same. Directors of groups that operate in more than one market should insist on one internal model that maps to each regime, rather than parallel programmes.

The Basel Committee defines operational resilience as "the ability of a bank to deliver critical operations through disruption", and tolerance for disruption as the level of disruption a bank is willing to accept given a range of severe but plausible scenarios. Its seven principles cover governance, operational risk management, business continuity planning and testing, mapping, third-party dependency management, incident management, and ICT including cyber security. In the US, the Federal Reserve, FDIC and OCC published "Sound Practices to Strengthen Operational Resilience" on 30 October 2020 for the largest banks (over $250 billion in assets, or over $100 billion with specified risk characteristics). It draws on existing rules and does not create new ones. APRA's CPS 230 replaced Australia's older outsourcing and business continuity standards from 1 July 2025, and APRA finalised targeted amendments in 2026 with limited exemptions from some contract requirements for specified provider categories.

Decisions only the board can make

• Which services count: The list of important business services or critical operations is a judgement about harm to customers, markets and the firm, not an IT inventory. A list that is too long dilutes effort; a list that leaves out a service customers would notice within a day is a finding waiting to happen.
• Where the line sits: An impact tolerance is a statement such as "customers must be able to make payments again within 12 hours, and no more than a set number of customers may be affected". The board sets it from harm, not from what IT can currently achieve. If the gap between the two is large, that gap is the investment case.
• How severe the scenarios are: The board should agree the scenario library, including loss of a major cloud provider or region, destructive ransomware with backups also affected, loss of the identity provider, a faulty supplier update across all endpoints, and insider misuse of privileged access. See the Cyber Risk Scenario Library Guide.
• How much concentration to accept: Some single points of failure cannot be removed at reasonable cost. The board should accept those explicitly, with a documented rationale and a tested workaround, rather than discover them during an incident. See the Third-Party Concentration Risk Guide.
• Whether the self-assessment is true: The UK regime requires a written self-assessment approved by the board. Directors should read it as a document they may have to defend to a supervisor after an outage.

Five questions for the board to ask

1. For each important service, how long can it be down before customers are seriously harmed, and how do we know? Expect a tolerance expressed in time and volume, tied to evidence about customer harm, not a copy of the IT recovery time objective.
2. In the last scenario test, did we stay within tolerance, and if not, what is being fixed and by when? A firm that passes every test is probably testing mild scenarios. Breaches of tolerance in testing are useful; unremediated ones are not.
3. Which single suppliers, if they failed tomorrow, would take more than one important service outside tolerance? Ask for the list by name, and for the date each exit or substitution plan was last exercised.
4. If our identity provider, privileged access system or key management service were unavailable or compromised, how would we operate and recover? These shared control planes sit under almost every service and are often missing from service maps. See the emergency identity operations guide.
5. Who decides, in the first hour of a severe disruption, to invoke workarounds, communicate with customers and notify regulators, and have they practised it? Decision rights that are not rehearsed tend to fail under pressure.

Red flags in management answers

• Tolerances equal recovery objectives: If every impact tolerance matches an existing IT target, the firm has relabelled its continuity plan rather than assessed harm.
• Maps stop at the firewall: Service maps that list internal applications but not cloud regions, SaaS platforms, payment schemes, managed service providers and their subcontractors understate dependency.
• Testing means tabletop only: Discussion exercises are a start. Technical recovery tests, failovers and restore tests at production scale are what show the tolerance is achievable.
• Exit plans that have never been opened: A plan to leave a critical supplier that has not been walked through, costed and timed is not evidence.
• Cyber and resilience run separately: If the CISO and the resilience lead use different service lists and scenario sets, the board is getting two partial pictures.

What good looks like

Where to invest first

• Recoverable identity and access: Most recovery plans assume administrators can log in. Protect break-glass accounts, back up identity provider configuration and make sure the service and machine accounts that run recovery tooling are inventoried and their secrets recoverable. See the IdP configuration backup and restore guide.
• Isolated, tested backups: Immutable or logically isolated copies of the data behind each important service, with restore times measured at realistic volume. See the Business Continuity and Disaster Recovery Guide.
• Supplier exit and substitution: For the few suppliers that would breach several tolerances, fund a real alternative or a manual workaround and exercise it. See the Cloud Concentration Risk and Exit Strategy Guide.
• Change control on suppliers' pushes: Ask critical vendors how they stage updates and whether you can control the rollout ring for your estate. See the Security Tool Faulty Update Outage Playbook.
• Crisis decision-making: Pre-agreed authority to switch to degraded modes, and pre-drafted customer and regulator messages. See the Crisis Management Guide.

Metrics to track

A 90-day plan

1. Days 1 to 30, confirm the foundations: Reconfirm the list of important services and their accountable executives. Check that every tolerance is expressed as time and volume and justified by harm. Obtain the latest self-assessment and the open vulnerabilities list.
2. Days 31 to 60, close the blind spots: Extend service maps to third parties and shared control planes (identity, privileged access, key management, DNS, network). Run a concentration analysis across the supplier register and name the suppliers that would breach more than one tolerance.
3. Days 61 to 90, prove it: Run one severe technical scenario end to end, ideally loss of a major supplier or of the identity provider, with a timed restore. Report the result to the board against tolerance, with a funded remediation plan for every breach.

Common failure patterns

• Treating resilience as a compliance project: Programmes built to meet a 2025 deadline lose funding once the deadline passes, and maps go stale within a year.
• Ignoring machine dependencies: Service accounts, API keys and certificates that link services together are rarely on the map, and an expired certificate or revoked token can take a service outside tolerance as surely as a data centre fire.
• Assuming the supplier's resilience is yours: A provider's multi-region architecture does not help if your own configuration runs in one region, or if your access to it depends on a single identity path.
• Testing recovery without the attacker: Destructive cyber scenarios differ from outages because the environment may not be trustworthy. Plans that restore into a compromised identity system can reinfect.

Practitioner checklist

• Keep one internal service and tolerance model mapped to each regime the group is subject to.
• Express every impact tolerance as maximum time and volume of disruption, justified by customer or market harm.
• Map each important service to people, technology, data, facilities, third parties and their key subcontractors.
• Include identity, privileged access, key management, certificates and DNS in every service map.
• Maintain a scenario library agreed by the board, with at least one severe supplier failure and one destructive cyber scenario.
• Record every tolerance breach found in testing as a vulnerability with an owner, a date and funding.
• Run concentration analysis across the supplier register at least annually and after major sourcing decisions.
• Exercise exit or substitution plans for suppliers that would breach more than one tolerance.
• Align supplier incident notification terms with your own regulatory reporting clocks.
• Report tolerance test results and decisions needed to the board, not programme status alone.

Standards and references

• Basel Committee on Banking Supervision: Principles for operational resilience
• Bank of England PRA: SS1/21 Operational resilience, impact tolerances for important business services
• Financial Conduct Authority: Operational resilience
• Bank of England PRA: Critical third parties to the UK financial sector policy statement
• Australian Prudential Regulation Authority: Operational risk management (CPS 230)
• Federal Reserve Board: Agencies release paper on sound practices to strengthen operational resilience
• Financial Stability Board: Enhancing third-party risk management and oversight, a toolkit

How NHI Mgmt Group can help

We provide independent identity and non-human identity risk assessments and board briefings, focused on the identity providers, privileged accounts, service accounts, API keys and certificates that sit underneath important business services and are often missing from resilience maps. Our NHI Foundation Level Training Course helps security and IAM teams govern machine identities that recovery depends on. Contact us to arrange a briefing.

Related NHI Mgmt Group resources: Cyber Resilience Guide · Third-Party and Supply Chain Risk Executive Briefing · Risk Appetite and Tolerance for Cyber Guide · Board Cyber Risk Reporting Guide. This guide summarises operational resilience regulation for board members and is not legal advice. Confirm against the official text before relying on it.