What is operational resilience?

Disruptions may involve technology, people, processes, suppliers, data, or external events. Resilience does not mean preventing every incident or maintaining perfect service at all times.

The focus is on whether important operations can continue or recover when something goes wrong. NIST’s glossary defines operational resilience at the system level as the ability to resist, absorb, and recover from or adapt to an adverse occurrence during operation. Organizations often apply the broader idea across the dependencies needed to deliver an end-to-end service.

Operational resilience depends on connected capabilities, which can include:

• People and processes: clear responsibilities, decision paths, operational knowledge, and procedures for responding to disruption.
• Technology and data: systems that can be monitored, maintained, protected, and recovered, along with access to the information needed to operate.
• Dependencies: suppliers, infrastructure, facilities, communications, and other services that support delivery.
• Response and recovery: the ability to detect problems, coordinate a response, restore important functions, and learn from events.

No single component proves that an organization is resilient. A backup may help restore data but not restore the wider service if a key supplier, integration, or team capability is unavailable. Third-party risk management can help organizations consider supplier dependencies, but resilience also includes internal processes and capabilities. Likewise, a written recovery plan does not show whether people can use it under pressure.

Business continuity focuses on maintaining or restoring business activities during and after disruption. Operational resilience is a broader view of whether important services can continue within acceptable limits, considering the people, processes, technology, data, and third parties on which they depend. Business continuity planning can support operational resilience, but the terms are not synonyms.

The terminology also varies by context. The UK Financial Conduct Authority’s operational resilience rules set expectations for important business services and impact tolerances for firms within scope. Those requirements should not be treated as the universal definition of operational resilience.

Disaster recovery is concerned with restoring technology systems, data, or infrastructure after a major disruption. It can be one capability within a resilience program. Operational resilience asks a broader question: can the organization continue or recover the important operation, including the non-technical dependencies and decisions needed to serve customers or internal users?

A system recovery plan may specify how to restore a database, for example. The associated service may also depend on an identity provider, integrations, trained staff, or a third-party platform. If those dependencies are not available, restoring the database alone may not restore the service. Recovery objectives are useful, but they do not capture every operational dependency or response need. Coordinated incident management helps teams detect, respond to, and learn from incidents as part of that broader picture.

Organizations rely on connected operations to deliver products and services. A disruption in one component can affect users beyond the team that owns it. Thinking in terms of resilience helps organizations identify which operations matter, understand dependencies, and consider how disruption could affect delivery.

This does not mean eliminating all risk or funding every system equally. Resilience decisions involve trade-offs: which services need stronger protections, what level of interruption is tolerable, and which recovery capabilities are proportionate to the impact of failure. Those decisions depend on the organization’s context and obligations.

Technology can support resilience through reliable architecture, monitoring and observability, redundancy where appropriate, tested backups, incident response tools, and deployment practices that help teams make changes safely. Site reliability engineering provides practices for operating and improving reliable production systems, while resilience also depends on business processes and third-party relationships.

Technology alone does not define operational resilience. A highly available application may still depend on a fragile manual process or an unavailable supplier. Observability can help teams see system behavior, but it is useful only when they can interpret signals and act on them. Redundancy can also add complexity if failover paths are not tested. Technical measures need to fit the service and its operating model.

Organizations may not have a complete view of the dependencies behind an important service. Ownership can be split across business units, engineering teams, suppliers, and operations, while procedures may exist in documents but remain untested. Resilience can also be difficult to assess because the same disruption can affect services in different ways.

A glossary definition should not be mistaken for a full implementation method. A useful starting point is to identify the operation or service whose continuity matters and recognize the broad categories of dependency around it. Detailed dependency mapping, scenario testing, impact tolerance design, and maturity assessment belong to more focused planning work.

The term is used in several sectors, including regulated financial services, but regulatory language is not a universal template for every organization. The shared idea is the capacity to sustain important operations despite disruption, with the exact obligations shaped by context.

For technology teams, this distinction matters when they assess a system in isolation. An application may meet its availability target while the service that depends on it is still interrupted by a failed integration, missing operational access, or an unavailable third party. Resilience therefore connects technical reliability to service outcomes without reducing the whole concept to uptime or recovery speed.