7 Operational Resilience Risks Boards Now Expect Mid-Market Financial Services to Address

The regulator requires firms to define Important Business Services from a customer-outcome perspective — services whose disruption would cause intolerable harm to consumers, to market integrity, to the firm’s safety and soundness, or to the financial system.

The mid-market default is to define IBSs from a revenue impact perspective. The services that produce the highest revenue, that are most visible commercially, get listed first. The IBSs that matter most to the regulator — those whose disruption causes customer harm at scale — may or may not be in the list.

This produces a structural misalignment between the firm’s operational resilience focus and what the regulator is actually asking about. The firm invests in protecting the services most important to it commercially. The regulator scrutinises the services most important to customers. When the two lists diverge, the firm finds that its resilience investment doesn’t address the questions being asked. The architectural fix is to define IBSs through customer outcome, then layer commercial impact separately. The regulator’s framework is designed around the first lens.

The impact tolerances are documented. Maximum tolerable duration of disruption for each Important Business Service. Approved by the board. Submitted to the regulator. The framework is in place.

What is rarely in place is operational testing of whether the documented tolerances can actually be met under realistic stress. The recovery time objectives assume infrastructure performs to specification. The communications protocols assume staff are available. The customer-facing fallback positions assume manual operations can scale to incident volumes.

In actual incidents, these assumptions are routinely wrong. The board sees the documented tolerance. The CIO knows the operational reality. The two are different numbers, and the difference is what regulator scrutiny will increasingly surface. The architectural fix is end-to-end operational testing — under conditions designed to stress the assumptions, not validate the documentation. Run the scenario. Measure actual recovery. Document the gap. Architect the remediation. Most mid-market firms have not yet built this discipline.

The third-party register exists. Critical suppliers are documented. Contracts are in place. Vendor risk assessments are run periodically.

What rarely exists in mid-market is fourth-party visibility. The cloud provider’s sub-processors. The payment processor’s downstream providers. The KYC vendor’s data sources. The communications platform’s infrastructure dependencies. The firm’s resilience depends on this full chain — but the architectural map of it usually stops at second-party.

The cost is concentration risk that is structurally invisible. Multiple third parties may all depend on the same fourth-party infrastructure. A single outage at the fourth-party level cascades through several third-party services simultaneously, hitting the firm in multiple places at once. The firm’s resilience framework treats them as independent risks. They are not. The architectural fix is to extend dependency mapping past second-party, with concentration risk monitored at each level. This is governance work, not procurement work.

The scenario testing exercise happens. The team gathers. The scenario is described. The response is rehearsed. The lessons are logged. The exercise report goes to the board. The compliance team confirms scenarios have been tested.

What rarely happens after these exercises is architectural change. The gaps identified in testing are documented. The architectural remediation that would close the gaps is rarely commissioned. The same scenario, tested again twelve months later, often reveals the same gaps.

This is the difference between resilience as exercise and resilience as architecture. The exercise produces a plan. The architecture changes the underlying capability. Plans without architecture leave the firm theoretically prepared but operationally exposed. The architectural fix is to treat scenario testing as a discovery process for architectural investment, not as a compliance milestone. Every test produces an architectural action list. Every action list has named owners, timelines, and CFO-approved funding. The board reviews architectural progress, not just exercise completion.

The operational resilience function is staffed and competent. It produces frameworks, registers, scenario plans, board papers. It is well-organised and credible.

The structural question is where it reports. In most mid-market firms, operational resilience sits within risk or compliance. The function is treated as a discipline of regulatory risk management. The outputs reflect this — documentation-led, framework-led, externally-facing.

What this organisational placement does not produce is operational architecture change. The function describes the architecture; it does not redesign it. The COO, who could change operational architecture, is the consumer of resilience reports, not the owner of resilience design. In well-architected firms, operational resilience reports to the COO or equivalent operational executive. The function is positioned as operational architecture, with regulatory compliance as one of its outputs. The change is structural and the outcomes are different. Most mid-market firms have not yet made the shift. The CRO sees resilience as risk. The COO sees it as operations. Neither sees it as architecture.

The Recovery Time Objective for each Important Business Service is documented. The number is signed off by the board. It appears in the resilience framework. It is submitted to the regulator.

The number is rarely tested under conditions that would validate it. In real-world incidents — and in tabletop exercises that simulate realistic conditions — the actual recovery time is materially longer than the documented RTO. The infrastructure recovery dependencies that the documented number assumed are not the dependencies that actually exist. The communications and coordination overhead that the number assumed away is the dominant factor in real incidents.

The board sees the documented number. The CIO knows the operational reality. The gap is rarely escalated unless an actual incident forces it. The architectural fix is to test RTOs against realistic recovery scenarios, document the actual recovery curve, and either remediate the gap architecturally or restate the RTO to reflect operational reality. The first option requires investment. The second requires board honesty. Most mid-market firms have done neither, and the regulator is increasingly going to find the gap when they ask for evidence.

FCA and PRA expectations are real. So is the cost of meeting them. Most mid-market firms frame operational resilience investment defensively — what we need to do to satisfy the regulator, manage the risk, avoid the censure. The investment is treated as a cost line.

This framing misses an architectural opportunity. Operational resilience excellence is increasingly a commercial differentiator. Enterprise customers — particularly in B2B financial services — are demanding resilience evidence as part of vendor due diligence. Institutional investors are starting to ask about resilience architecture as part of investment decisions. Consumers are increasingly sensitive to firms that have experienced visible incidents and those that have not.

The same investment, framed and architected differently, produces commercial returns. The firm that can demonstrate audit-defensible operational resilience to a B2B procurement committee wins deals the firm that cannot will lose. The firm with consumer trust narrative built on transparent resilience practices commands different brand economics. The architectural fix is the framing. Operational resilience is commercial architecture, not regulatory architecture. The investment is the same. The return is different.