The ability of information and communication technology to keep critical services operating during disruption and to recover quickly when controls fail. In supervisory contexts, it increasingly means demonstrating that controls still reduce risk under real-world attack conditions, not just on paper.
What ICT Resilience Means in Practice
ICT resilience is not just backup and recovery. It is the ability of critical technology services to continue operating through disruption, absorb control failures, and restore acceptable service quickly enough that business impact stays bounded.
That makes resilience a service-level property, not a single control. Availability, failover, recovery time, manual workarounds, and dependency management all shape whether the organisation can keep operating when parts of the technology stack fail.
How ICT Resilience Differs from Basic Availability
Basic availability asks whether a system is up. ICT resilience asks what happens when something important breaks, such as an application, a data centre, an identity service, a network segment, or a third-party provider. A resilient environment assumes disruption will happen and is designed to keep essential services usable anyway.
This distinction matters because many environments are stable under normal conditions but fragile under stress. Resilience is therefore judged by how gracefully services degrade, how quickly they recover, and whether the organisation can operate during the recovery window.
Control Expectations and Supervisory Meaning
In supervisory and assurance contexts, ICT resilience has become more demanding than traditional continuity planning. Regulators and auditors increasingly expect evidence that controls remain effective under realistic failure and attack conditions, rather than only in documentation or tabletop scenarios. That is why the EU Digital Operational Resilience Act (DORA) matters to this topic: it treats operational resilience as something firms must demonstrate, test, and govern.
Resilience programmes usually combine technical hardening, redundancy, recovery design, incident response, and dependency oversight. They also need clear ownership, because resilience fails when no one is accountable for restoring services or validating that recovery assumptions still hold.
Why ICT Resilience Depends on Trust Boundaries
Modern ICT resilience is shaped by how tightly services depend on each other. Shared identity platforms, cloud control planes, external SaaS providers, and outsourced infrastructure can all become single points of failure if they are not isolated or recoverable. The same is true of recovery tooling, because a backup that cannot be restored quickly is not resilient in practice.
For that reason, resilience is as much about dependency mapping and recovery order as it is about redundancy. A system may have multiple copies and still fail the resilience test if those copies all rely on the same weak control, the same authentication path, or the same unavailable provider.
Risk and Threat Considerations
ICT resilience fails when disruption outpaces recovery, when dependencies cascade, or when an attacker deliberately targets the control layer that keeps services running. The most damaging failures are often not total outages, but partial ones where critical functions become slow, inconsistent, or impossible to trust.
Failure mechanism: Single points of failure, weak failover design, brittle dependencies, and untested recovery procedures can turn a local incident into a wider service interruption. Adversaries also exploit these weak points by degrading availability, corrupting recovery assumptions, or disabling the controls needed to restore service.
Impact: Organisations can lose critical service continuity, miss recovery objectives, and amplify the business effect of otherwise contained incidents. In regulated environments, poor resilience can also become a governance failure because the organisation cannot evidence that essential services remain dependable under stress.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 and DORA define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | RC.RP-01 — Recovery Plan Execution | ICT resilience centers on executing recovery plans after disruption. |
| RC.IM-01 — Improvements | ICT resilience requires restoring services and improving recovery from real incidents. | |
| RC.CO-03 — Communications | Resilience depends on timely coordination during service disruption and recovery. | |
| Recommendation — Test and execute recovery plans until critical services can be restored within target timelines. Capture lessons from outages and update recovery design after each disruption. Define recovery communications so owners, operators, and stakeholders stay aligned during incidents. | ||
| ISO/IEC 27001:2022 | A.5.30 — ICT readiness for business continuity | ICT resilience directly concerns maintaining ICT services during disruptive events. |
| A.8.14 — Redundancy of information processing facilities | Resilience relies on redundant facilities and recovery paths that sustain service continuity. | |
| Recommendation — Align continuity planning to the ICT services that must remain available during disruption. Provide redundant processing capacity for critical services and validate it through recovery testing. | ||
| NIST SP 800-53 Rev 5 | CP-2 — Contingency Plan | ICT resilience requires documented continuity and recovery planning for essential services. |
| CP-4 — Contingency Plan Testing | Resilience depends on proving recovery works under realistic conditions. | |
| Recommendation — Maintain contingency plans for critical services and keep them current through testing. Test contingency capabilities against realistic disruption scenarios and fix failures quickly. | ||
| DORA | Article 11 — Digital operational resilience testing | DORA directly requires resilience testing of ICT systems and services. |
| Article 12 — ICT third-party risk management | ICT resilience is often constrained by providers and outsourced dependencies. | |
| Recommendation — Run resilience tests that validate service continuity under severe but plausible disruption scenarios. Map third-party dependencies and ensure contractual and technical recovery expectations are enforceable. | ||
Practitioner Guidance
Why practitioners should care: ICT resilience should be treated as an operational assurance question, not a paper exercise. The key judgement is whether critical services still meet acceptable service levels when important controls, providers, or dependencies fail.
Practitioner note: The most useful resilience evidence comes from real recovery behaviour, not from policy statements. If a service can only survive disruption when everything works exactly as planned, it is not resilient enough for a supervisory lens.
Related resources from NHI Mgmt Group
- What do teams get wrong about ICT third-party risk in resilience programmes?
- Why do third-party ICT dependencies create the biggest operational resilience risk under DORA?
- How should financial institutions prepare for DORA compliance across ICT risk, incident reporting, and resilience testing?
- What breaks when ICT incident management and reporting are not tightly integrated with resilience controls?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org