Introduction

---

Ask most security teams how the last quarter went, and you’ll likely hear a list of metrics: threats blocked, vulnerabilities patched, or phishing click rates reduced. These are all useful measurements, but they don’t answer the question that matters most to the business:

If a critical service goes down, how quickly can we restore it and serve customers again?

That is where operational resilience comes in. It is often mistaken for a new name for cybersecurity or disaster recovery, but it is neither. Instead, operational resilience shifts the focus away from the attacker and toward the continuity of critical business services.

Prevention Has Limits. Resilience Reduces Impact.

Traditional cybersecurity focuses on prevention. The assumption is that with enough firewall rules, endpoint protection, network segmentation, and monitoring, organizations can stop most attacks before they cause damage.

In reality, prevention has its limits.

Threat actors purchase stolen credentials from brokers, trusted software vendors can unknowingly distribute compromised updates, and critical infrastructure can fail without warning. Not every disruption is the result of a cyberattack—a fiber cut, a cloud outage, or a nation-state attack can all produce the same business outcome: unavailable services.

Operational resilience starts with a different assumption: disruptions will happen. While organizations cannot eliminate every incident, they can improve how quickly they detect, contain, recover from, and adapt to those events. Prevention reduces the likelihood of an incident, while resilience minimizes its business impact. Both are necessary, but resilience determines how well an organization performs when prevention is no longer enough.

Start with the Service, Not the Asset

Many cybersecurity programs begin by cataloging technical assets such as servers, endpoints, network devices, cloud resources, and applications.

Operational resilience starts somewhere else.

It begins by identifying the business services that matter most—payment processing, customer onboarding, patient records, order fulfillment, or claims processing—and then mapping every dependency required to keep those services operational.

For every critical service, organizations should clearly define three key elements:

1. Dependency Mapping

Understand every component that supports the service, including applications, databases, network paths, identity providers, third-party APIs, cloud platforms, and infrastructure. Dependency mapping often reveals undocumented relationships or hidden single points of failure that become major risks during an outage.

2. Impact Tolerance

Impact tolerance is one of the most valuable concepts in operational resilience. It is a clearly defined limit, approved by senior leadership, that specifies the maximum acceptable disruption to a critical business service.

For example:

“Payment processing must not be unavailable for more than four hours under any scenario, including a destructive cyberattack.”

This is not an aspiration or performance target. It is an operational boundary that defines when customer harm becomes unacceptable and provides a measurable objective for resilience testing.

3. Severe but Plausible Scenarios

Testing should focus on realistic high-impact events rather than convenient simulations. Examples include:

• A domain-wide ransomware attack with encrypted backups
• Loss of a primary cloud region
• A compromised managed service provider used as an attack vector

If a scenario feels too comfortable, it probably isn’t challenging enough to expose resilience gaps.

Turning Strategy into Operational Resilience

A resilience policy alone does not create a resilient organization. Success depends on implementing practical controls that support business continuity.

Design Segmentation to Limit Impact

Network segmentation should be designed to reduce the blast radius of an incident, not simply satisfy compliance requirements. The key question is not whether segmentation exists, but whether critical business services remain operational if one network segment is compromised.

Build Independent Recovery Track

Recovery capabilities should not rely on the same infrastructure that has failed. Emergency administrative accounts, offline credential storage, out-of-band management, and alternative communication channels become essential when core identity systems are unavailable.

Test Backup Recovery

Backups should be immutable, offline where appropriate, and regularly tested under realistic conditions. Organizations should verify their ability to restore not only application data but also identity services, certificates, network configurations, and supporting infrastructure.

Plan for Graceful Degradation

Not every service needs to stop completely during an incident. Reduced operating modes, temporary manual processes, or read-only access can allow essential business functions to continue until full recovery is achieved.

Evaluate Third-Party Dependencies

Critical business services often rely on cloud providers, managed service providers, payment gateways, and other external partners. Operational resilience requires understanding these dependencies and ensuring they align with defined impact tolerances.

Test Like It Matters

A tabletop exercise where everyone agrees the recovery plan would have worked is useful—but it is not proof.

Meaningful resilience testing should:

• Measure results against defined impact tolerances.
• Assume key communication systems may be unavailable.
• Include operational staff who would respond during an actual incident.
• Produce measurable recovery outcomes.

The most valuable result is a statement such as:

“We exceeded our four-hour recovery tolerance by nine hours, and these are the reasons why.”

That single measurement provides meaningful information for executive leadership, regulators, auditors, and investment decisions.

Regulatory Expectations

Operational resilience has moved beyond best practice and is now a regulatory expectation in many regions. Frameworks such as the European Union’s Digital Operational Resilience Act (DORA), the UK PRA/FCA Operational Resilience Framework, and the NIS2 Directive all emphasize similar principles:

• Identify critical business services.
• Define measurable impact tolerances.
• Understand internal and third-party dependencies.
• Test against severe but credible disruption scenarios.
• Address resilience gaps identified during testing.

Organizations that build resilience around these principles strengthen both their operational capabilities and their regulatory compliance, avoiding the need for separate resilience and compliance initiatives.

The Question Every Organization Should Answer

Imagine your most critical business service tomorrow.

Every Windows server supporting that service has been encrypted. Your identity provider is unavailable. Your backups cannot immediately be trusted.

How long would it take to restore service?

More importantly, would recovery remain within your organization’s defined impact tolerance?

These are the questions operational resilience is designed to answer.

If your organization cannot confidently provide a measurable answer, the challenge extends beyond cybersecurity.

It is a resilience issue—and often a far more costly one.

Prevention helps avoid disruption.

Operational resilience determines how successfully your organization recovers when disruption inevitably occurs.