The 5 dimensions of IT resilience #

IT resilience can be divided into five complementary dimensions:

1. Prevention (Prevent): Measures to make attacks harder, such as patch management, endpoint detection and response (E), network segmentation, and multi-factor authentication. Prevention is necessary but not sufficient.

2. Detection (Detect): The ability to identify intrusions, anomalies, and security breaches quickly. SIEM systems, network detection and response (N), threat intelligence, and logging are detection tools. The key: the faster you detect an attack, the more limited the damage.

3. Response (Respond): The structured handling of a detected attack: incident response plan, IR team, escalation processes, forensics. Response minimizes the damage during an active attack.

4. Recovery (Recover): The technical ability to restore systems from a known-clean state: backup management, recovery runbooks, isolated recovery environments, regular recovery tests. This is the core of cyber resilience, because most other measures fail in the event of a complete compromise.

5. Adaptation (Adapt): The continuous process of post-incident reviews, lessons learned, tabletop exercises, and architecture improvements. Organizations learn from attacks (their own or others’) and adapt their systems accordingly.

IT resilience vs. high availability #

This is the most common confusion. High availability means a system is always accessible, achieved through redundancy, failover, and load balancing. A highly available system can be reachable 24⁄7 and yet be completely compromised. Example: a web server with perfect failover can still transmit all data to an attacker without going offline.

IT resilience is not primarily concerned with availability. It is concerned with restorability from a clean state. A resilient infrastructure can deliberately go offline to clean itself, and then be restored from secured, verified backups.

One key characteristic: highly available systems can unknowingly amplify attacks because they continuously replicate. Resilient systems disconnect from the network to prioritize integrity over uptime.

IT resilience vs. IT security #

This is an important conceptual boundary. IT security is preventive: it tries to prevent threats. IT resilience is reactive: it accepts that prevention will fail at some point and prepares for recovery.

The data illustrates the problem. According to the Veeam Trends Report 2025, about 7 in 10 organizations suffered at least one ransomware attack in the preceding year, despite improved defenses. They were not attacked because they lacked security. They were attacked because security alone is insufficient against modern, well-funded adversaries.

IT security answers the question: How do we prevent an attack? IT resilience answers the question: How do we recover when prevention fails?

Both disciplines are complementary and necessary. Resilience alone is negligent (you accept too many attacks). Security alone is unrealistic (you cannot prevent all attacks). Best practice is the combination: strong prevention plus a strong, tested recovery capability.

IT resilience is no longer just good practice. EU legislation has turned it into a binding obligation:

NIS2 (Directive (EU) 2022⁄2555): Requires essential and important entities to implement risk management measures that explicitly include backup management, disaster recovery, and crisis management. Management bodies must approve and oversee these measures and can be held personally accountable. In Germany, the directive is implemented through the NIS2UmsuCG, in force since 6 December 2025.

(Regulation (EU) 2022⁄2554): Applies to the financial sector since 17 January 2025 and mandates ICT business continuity policies and regular digital testing.

Art. 32: Requires the ability to restore the availability of and access to personal data in a timely manner after a physical or technical incident.

ISO 22301 and ISO 27001:2022: The international standards for business continuity management and information security management provide the certifiable frameworks most organizations use to structure their resilience programs.

The last layer: an immutable, tested restore path #

Whatever framework you follow, the recovery dimension stands or falls with one architectural element: at least one backup copy that an attacker with full network control cannot reach or alter, plus a restore path you have actually tested. That means an air-gapped or immutable secondary storage tier, separated from production credentials, combined with regular recovery tests. Without this layer, every other resilience investment rests on an unverified assumption.

Frequently asked questions #

Is IT resilience the same as disaster recovery? No. Disaster recovery () is a component of resilience, specifically the recovery aspect. Resilience also encompasses prevention, detection, response, and adaptation.

Can we achieve resilience with cloud? Cloud services can contribute, but cloud alone does not create resilience, and it should not be the primary strategy. Continuously synchronized cloud copies replicate ransomware encryption within minutes. Resilience requires an isolated, tier under your own control, which is why on-premises secondary storage remains the foundation.

Do we need resilience if we have good IT security? Yes. IT security alone does not provide sufficient protection. Resilience is the safety net that activates when prevention fails.

Further Resources #

→ IT Resilience Guide (/en/blog/it-resilienz-leitfaden/) → 5 Pillars of IT Resilience (/en/blog/5‑saeulen-it-resilienz/) → Assume Breach Architecture Principle (/en/blog/assume-breach-architekturprinzip/) → NIS2 and IT Resilience Requirements (/en/blog/nis2-it-resilienz-anforderungen/)

Disclaimer

This article was written by our editorial team and edited using AI. It provides a general overview and does not constitute legal advice – we recommend seeking professional advice for your specific situation.