Operational Resilience Defined in Plain Terms
Operational resilience is the ability of an organisation to keep its critical business services running during a disruption and to recover them quickly when they fail. It assumes that outages, cyberattacks and supplier failures will happen and focuses on limiting the harm to customers and the business rather than trying to prevent every incident.
That shift matters because modern services run on a short list of shared providers. One faulty software update or one breached supplier can stop services for millions of people in hours. Regulators have responded by turning resilience from good practice into a legal duty.
The Basel Committee set out global principles for banks in 2021. The EU made digital operational resilience binding for the financial sector through DORA in 2025. In Sweden, NIS2 took effect as Cybersäkerhetslagen on 15 January 2026 and extends continuity duties well beyond finance.
Operational Resilience vs Business Continuity
Business continuity and disaster recovery ask how fast you can restore a system after it breaks. Operational resilience starts one step earlier from the service the customer depends on, and asks whether that service survives a disruption within a limit you have agreed in advance.
The difference is the starting point. Continuity and recovery plans are mechanisms that sit inside resilience. Resilience is the outcome they serve, measured by whether a payment, a booking or a patient record stays available when something fails.
Resilience is also broader than cyber. An IMF review of euro-area cyber resilience in 2025 noted that red-teaming tests defences against attackers but does not reveal weaknesses in business continuity or disaster recovery which matter just as much when a non-malicious failure takes a service down.
The Core Components of Operational Resilience
Operational resilience management turns that outcome into a repeatable process. The UK regulators and the Basel Committee describe the same building blocks and DORA and NIS2 require versions of them.
- Important business services: The services that, if disrupted, would cause intolerable harm to your customers or the market. You name them first because everything else follows from the list.
- Impact tolerances: The maximum level of disruption each service can take before that harm becomes real, set as a clear limit such as hours of downtime or volume of failed transactions.
- Mapping: The people, processes, technology, data, facilities and third parties each service depends on, mapped to the detail needed to find the weak points.
- Scenario testing: Testing each service against severe but plausible scenarios including a cyberattack and a key supplier going down, to prove it stays within tolerance.
- Third-party and concentration risk: Knowing which services rely on a single provider and managing that dependence, a core pillar of both DORA and the Basel principles.
- Governance: A board that approves the approach, reviews it at least once a year and owns the result.
The Business Impact of Operational Disruption
Downtime is expensive and the bill is rising. In the Uptime Institute’s 2025 outage analysis, 54 percent of organisations said their most recent serious outage cost more than 100,000 dollars and about one in five put it above 1 million dollars.
A single incident can dwarf those averages. Delta Air Lines told regulators that the July 2024 software-update outage cost it around 500 million dollars. TSB’s 2018 migration failure cost the bank hundreds of millions once redress and remediation were counted.
The cost is not only money. A failed service erodes customer trust and in the public sector it can interrupt care, benefits and schooling. Where one provider sits behind many organisations, a single failure becomes a systemic event.
Regulators now add a penalty on top. NIS2 allows fines up to 10 million euros or 2 percent of global turnover for essential entities and it makes board members personally accountable for security measures under Article 20.
Real-World Cases
The July 2024 Software-Update Outage
On 19 July 2024 a faulty update from a third-party security vendor crashed about 8.5 million Windows devices worldwide, according to Microsoft. Airlines, hospitals, banks and broadcasters went down at the same time because they ran the same software.
Delta Air Lines was hit hardest among the airlines. It cancelled about 7,000 flights over five days and said publicly that the July 2024 software-update outage cost it around 500 million dollars. Its slower recovery was traced to how many critical systems ran on the affected platform.
The lesson is concentration. When one supplier sits deep inside your systems, its problems become yours. Resilience here means reducing single points of failure and rehearsing recovery so a critical service can be brought back inside its impact tolerance.
The TSB Migration Failure, 2018
In April 2018 TSB moved its 5.2 million customers to a new banking platform before it had been properly tested. The system failed on go-live and up to 1.9 million customers were locked out of online and mobile banking, with problems lasting months.
In December 2022 the Financial Conduct Authority and the Prudential Regulation Authority jointly fined TSB 48.65 million pounds for failing to manage the migration and its IT outsourcing. The total cost to the bank ran to hundreds of millions.
Testing was the gap. A severe but plausible test of the new platform under real load with a workable plan to roll back, would have caught the failure before customers ever saw it.https://ebuildersecurity.se/en/?s=ransomware&post_type=cyber-101
The Miljödata Supplier Attack, August 2025
In late August 2025 ransomware hit Miljödata, a Swedish supplier whose HR and work-environment systems are used by roughly 80 percent of the country’s municipalities. Around 200 of Sweden’s 290 municipalities were disrupted and about 2.2 million people’s data was later exposed.
The Swedish data protection authority, IMY, fined Miljödata for weak security around the software it ran. For the municipalities the service failure was real even though the breach happened at a supplier.
Concentration struck again. One supplier used by most of the sector is a single point of failure so due diligence on critical suppliers and a tested plan for a supplier outage are part of resilience. You stay accountable for the service even when someone else runs it.
Operational Resilience and Compliance
Four regimes now shape operational resilience for organisations in Sweden and the EU. Each is a requirement in its own right and most firms are touched by more than one.
DORA is the EU’s Digital Operational Resilience Act, Regulation (EU) 2022/2554, which has applied across the financial sector since 17 January 2025. It sets five pillars including digital operational resilience testing and threat-led penetration testing and lets the European Supervisory Authorities oversee critical ICT third-party providers directly. See our DORA compliance guide.
The ECB made operational resilience a supervisory priority and ran its first cyber resilience stress test in 2024. It tested 109 banks on how they would respond to and recover from a severe cyberattack and found that frameworks were in place but recovery needed improvement.
The UK regime from the Financial Conduct Authority and the Prudential Regulation Authority has applied since 31 March 2022, with a transition that ended on 31 March 2025. It requires firms to identify important business services, set impact tolerances and prove they can stay within them during severe but plausible disruption.
NIS2 took effect in Sweden as Cybersäkerhetslagen on 15 January 2026. It requires business continuity and supply-chain security from essential and important entities, makes the board accountable under Article 20 and sets an incident reporting cascade of 24 hours, 72 hours and one month to NCSC through CERT-SE (the national functions moved from MCF, formerly MSB, to NCSC at FRA on 1 July 2026). See our NIS2 compliance guide.
The Basel Committee set the global baseline with its Principles for Operational Resilience in March 2021. Its seven principles cover governance, third-party dependency, mapping, incident management and ICT, and they underpin the regimes above.
Signs of Weak Operational Resilience
You do not need an incident to find the gaps. These are the common signs that a service would not survive a serious disruption.
- You cannot quickly name your most important business services or who relies on them.
- No impact tolerances are set so there is no agreed limit on how much disruption is too much.
- Recovery plans exist on paper but have never been tested from end to end.
- You do not know which critical services depend on a single supplier or system.
- Incident response and business continuity sit with different teams that never rehearse together.
- The board only hears about resilience after something has already gone wrong.
Passing an audit is not the same as being resilient. An audit checks that documents exist. Only a tested recovery, under a realistic scenario, shows that a service will actually hold.
How to Build Operational Resilience
Building operational resilience is an ongoing programme rather than a one-off project. The steps below follow the order the regulators expect and give the board something it can review.
- Identify your important business services and the customers who depend on each one.
- Set an impact tolerance for every service, the maximum disruption you can absorb before real harm.
- Map the people, systems, data, facilities and suppliers behind each service.
- Test each service against severe but plausible scenarios including ransomware and a key supplier failing.
- Reduce single points of failure and avoid depending on one provider for a critical service.
- Rehearse recovery end to end, not just the technical restore, so people know their role.
- Give the board ownership of the approach and review it at least once a year.
Start with one important business service and work it through all seven steps. A single service tested to failure teaches you more than a binder of plans that no one has ever used.
