Beyond the Perimeter: Why Operational Resilience Must Be a Design Principle Not an Afterthought

In March 2022, the Financial Conduct Authority and Prudential Regulation Authority made operational resilience a regulatory requirement for UK financial services firms. Organisations were given until March 2025 to not only identify their important business services and set impact tolerances, the maximum time they could be disrupted before causing intolerable harm but to prove they could remain within those tolerances when things went wrong.

The regulation did not ask firms to prevent disruption. It asked them to survive it.

That distinction matters enormously. And it sits at the heart of a gap that exists in most security programmes today including many that are well-funded, well-staffed, and fully certified to ISO 27001.

The prevention trap

Most security programmes are architecturally optimised for prevention. Firewalls, endpoint detection, vulnerability scanning, access controls, security awareness training, every control in the standard toolkit is oriented toward stopping something bad from happening. This is necessary. It is not sufficient.

The prevention model has a fundamental flaw: it assumes that failure is avoidable. It is not. A security programme that is designed only to prevent incidents will inevitably fail because incidents are inevitable. The question is never whether your organisation will experience a significant security event. The question is whether your organisation can continue to function when it does.

Consider the NHS Synnovis ransomware attack of June 2024. Synnovis, a pathology services provider to NHS trusts in London, was hit by a Qilin ransomware attack that disrupted blood transfusion services, cancelled thousands of appointments, and caused the NHS to declare a critical incident. The attack did not succeed because Synnovis lacked security controls. It succeeded because the security programme like most was not designed with the question "what happens when we are breached?" at its centre.

The answer to that question, and the organisation's ability to keep serving patients while recovering, was not embedded in the design of the programme. It was an afterthought.

What operational resilience means

Operational resilience is not a synonym for business continuity. It is broader and more demanding.

Business continuity asks: how do we recover after a disruption? Operational resilience asks: how do we keep delivering our most important services during a disruption and how quickly can we return to full capability after it?

The FCA's operational resilience framework defines important business services as the services that, if disrupted, would cause intolerable harm to customers, market integrity, or financial stability. For a bank that might be payments processing or mortgage servicing. For a fintech it might be the lending decisioning engine or the customer onboarding flow. For a logistics firm it might be the order management system.

Once important business services are identified the question becomes: what is the maximum tolerable disruption to each service? How long can it be unavailable before real harm occurs? And critically, can the organisation prove it can remain within that tolerance under realistic stress scenarios?

This reframes security programme design entirely. Instead of asking "what controls do we need to pass our ISO 27001 audit?" the question becomes "what does our security architecture need to look like to ensure payment processing is restored within four hours of a ransomware attack?"

Designing for resilience: what it looks like in practice

A security programme designed with operational resilience as a principle looks different from a conventional programme in several important ways.

The first difference is in how assets are prioritised. A conventional programme treats all systems as broadly equivalent and everything gets the same controls applied according to a standard risk matrix. A resilience-oriented programme maps every system to the important business services it supports and applies controls proportionate to the resilience requirements of those services. The core payment processing infrastructure gets a different level of protection, monitoring, and recovery capability than the marketing website not because the marketing website does not matter, but because a four-hour outage of the marketing website does not cause intolerable harm to customers.

The second difference is in how organisations design incident response. In a conventional programme, incident response is a plan, a document that describes what to do when something goes wrong. In a resilience-oriented programme, incident response is a tested capability. Your team conducts tabletop exercises, red team engagements, and live failover tests against realistic scenarios. The organisation knows, not believes, but knows that it can isolate a compromised environment, fail over to a clean backup, and restore critical services within defined timeframes. Because it has done it.

The third difference is in how the supply chain is treated. The Synnovis attack was a supply chain attack, a third party's failure cascaded into NHS disruption. A resilience-oriented security programme maps third-party dependencies against important business services and maintains playbooks for operating without each critical supplier. This is not paranoia. It is design.

The Nigerian context: CBN and DORA

For Nigerian enterprises, operational resilience is increasingly a regulatory expectation rather than a best practice aspiration. The Central Bank of Nigeria's Risk-Based Supervision framework and its Cybersecurity Framework for financial institutions both emphasise the need for financial institutions to maintain operational continuity in the face of cyber incidents. The CBN's 2021 Operational Risk Management Guidelines explicitly require banks to identify critical operations, assess concentration risks in their technology supply chains, and maintain tested recovery capabilities.

For Nigerian fintechs and financial institutions with European operations or customers, the Digital Operational Resilience Act, DORA adds a further layer of obligation. DORA, which entered into force across the EU in January 2025, requires financial entities to implement ICT risk management frameworks, conduct digital operational resilience testing, and manage ICT third-party risk. It defines specific requirements for recovery time objectives and recovery point objectives for critical systems and it requires those objectives to be tested, not documented.

Where to start - practical steps

For organisations that want to move from a prevention-oriented to a resilience-oriented security programme, the starting point is not a technology investment. It is a mapping exercise.

Identify your important business services. Ask: which services, if unavailable for four hours, would cause real harm to your customers? Which, if unavailable for twenty-four hours, would cause regulatory intervention? Which, if unavailable for a week, would threaten the viability of the business?

For each important business service, map the technology systems, people, processes, and third parties it depends on. Identify single points of failure, the dependencies where a single failure cascades into service disruption.

Then ask the honest question: if the most critical dependency failed today, how long would it take to restore the service? Not how long the recovery plan says it would take. How long it would take, given the current state of your backups, your team's familiarity with the recovery procedure, and your ability to operate the service manually while the technology is restored.

The gap between the planned recovery time and the actual recovery time is where resilience programmes find their work.

The security programme that earns its budget

Operational resilience changes the conversation between security teams and boards. A prevention-oriented security programme asks the board to fund controls against threats that may or may not materialise. A resilience-oriented security programme asks the board to fund the organisation's ability to keep serving its customers when, not if a significant incident occurs.

That is a conversation boards understand. It is a conversation that connects security investment directly to customer outcomes, regulatory obligations, and business continuity. And it is a conversation that positions the security function not as a cost centre managing compliance obligations, but as a strategic capability protecting the organisation's ability to operate.

FortressPoint works with organisations across UK and Nigerian markets to design security programmes that are built for resilience from the ground up. If your programme was designed around a checklist, it may be time to redesign it around a question: what happens when something goes wrong, and how quickly can we recover?