--- title: "IT Resilience Maturity: Self-Assessment for IT Leaders" date: 2026-05-15T11:30:00+02:00 author: FAST LTA canonical_url: "https://www.fast-lta.de//en/blog/resilienz-reifegrad-messen-selbstbewertung-für-it-leiter" section: "Entries: Articles" --- ### The 5‑Level Model [\#](#the-5-level-model "The 5-Level Model") #### Level 1: Reactive (Ad-hoc, unstructured) [\#](#level-1-reactive-ad-hoc-unstructured "Level 1: Reactive (Ad-hoc, unstructured)") **Characteristics:** - No documented resilience strategy - Backups exist, but frequency and scope are arbitrary - Recovery tests are not performed - RTO/RPO are not defined - Incident response is improvised **Self-assessment questions:** - Do you have a written backup plan? - Do you test backups regularly (at least twice per year)? - Is recovery time from backups documented and under 8 hours? - Do you have an incident response plan? **If fewer than 2 answers are YES: you are at Level 1 (Reactive).** **Typical organizations:** SMBs without IT governance, startups, legacy organizations with outdated IT. **Problem:** In a real emergency, everything is improvised: very long downtime. #### Level 2: Basic (Documented, but untested) [\#](#level-2-basic-documented-but-untested "Level 2: Basic (Documented, but untested)") **Characteristics:** - Backup policy exists and is followed (e.g., daily) - RTO/RPO are estimated but not measured - Recovery tests are performed sporadically (at most once per year) - Incident response plan exists but is rarely practiced - No air gap or isolated backups **Self-assessment questions:** - Do you have a written, documented backup plan with defined frequency? - Do you perform recovery tests at least twice per year? - Do you have RTO/RPO targets (even if estimated)? - Do you have a written incident response plan? - Have you implemented an isolated (air gap) backup tier? **If 3 to 4 answers are YES: you are at Level 2 (Basic).** **Typical organizations:** Mid-sized businesses with IT leadership but few specialists. **Problem:** No practical knowledge of whether recovery actually works. Tests frequently expose problems that go unresolved. #### Level 3: Defined (Documented, tested, partially automated) [\#](#level-3-defined-documented-tested-partially-automated "Level 3: Defined (Documented, tested, partially automated)") **Characteristics:** - Comprehensive DR plan with system-by-system runbooks - RTO/RPO are tested, not just estimated - Quarterly or semi-annual recovery tests are standard - Air gap backups exist and are tested regularly - Incident response plan is trained annually (tabletop exercise) - Recovery tools are identified and tested **Self-assessment questions:** - Do you have system-specific recovery runbooks for all critical systems? - Is RTO/RPO measured from actual tests (not estimated)? - Do you perform recovery tests at least 4 times per year? - Do you have isolated (air gap) backups with regular tests? - Do you have a documented incident response plan with annual training? - Is your backup architecture resilient against ransomware (multiple tiers)? **If 4 to 5 answers are YES: you are at Level 3 (Defined).** **Typical organizations:** Larger mid-sized companies, some larger enterprises with a dedicated resilience team. **Problem:** Gaps remain (e.g., no isolated recovery environment, or an immutable WORM archive tier is missing). #### Level 4: Managed (Automated, continuously monitored) [\#](#level-4-managed-automated-continuously-monitored "Level 4: Managed (Automated, continuously monitored)") **Characteristics:** - Backups are automated (not manual) - Isolated recovery environment exists for critical systems - 4‑tier backup architecture (online, air gap, WORM, geo) - Recovery tests are quarterly and documented - Incident response is practiced regularly - Metrics are continuously monitored (RTO compliance, backup success rate) **Self-assessment questions:** - Is your backup process fully automated (no manual copying)? - Do you have an isolated recovery environment for critical systems? - Do you use a 4‑tier backup architecture (online, air gap, WORM, geo)? - Do you perform quarterly full recovery tests? - Are incident response scenarios practiced on a fixed schedule? - Do you monitor resilience metrics (RTO compliance, backup success rate)? **If 4 to 5 answers are YES: you are at Level 4 (Managed).** **Typical organizations:** Large enterprises, critical infrastructure operators, financial services. **Problem:** Individual systems may still lack resilience, or processes are not fully documented. #### Level 5: Optimized (Continuous improvement, lessons learned) [\#](#level-5-optimized-continuous-improvement-lessons-learned "Level 5: Optimized (Continuous improvement, lessons learned)") **Characteristics:** - All aspects of Level 4, PLUS: - Lessons-learned process after every incident - Tabletop exercises with threat modeling - Regular penetration tests (annual or more) - Red teaming to identify weaknesses - Continuous architecture improvements based on findings - Industry best practices are monitored and adopted **Self-assessment questions:** - Do you conduct post-incident reviews and implement improvements? - Do you perform at least one annual full test with external evaluation? - Do you run tabletop exercises with threat modeling? - Do you conduct penetration tests at least annually? - Do you have a continuous improvement process for resilience? - Are recovery architecture decisions made based on data? **If 4 or more answers are YES: you are at Level 5 (Optimized).** **Typical organizations:** Large listed corporations, financial services with the highest compliance requirements, cyber resilience leaders. **Problem:** This level is expensive and complex. It only makes sense for the largest organizations or the most regulated sectors. ### Where most organizations stand [\#](#where-most-organizations-stand "Where most organizations stand") There is no precise public census of resilience maturity, but assessments and industry surveys point in the same direction: the majority of mid-sized organizations sit at Level 2. They have documented backups and estimated RTOs, but no tested recovery capability and no isolated backup tier. Levels 4 and 5 remain the exception, concentrated in large enterprises, critical infrastructure, and regulated financial services. That majority position is exactly the risk zone: documented enough to feel safe, untested enough to fail in a real ransomware incident, in which attackers target the backup infrastructure first. ### The most impactful next step per level [\#](#the-most-impactful-next-step-per-level "The most impactful next step per level") **If you are at Level 1 (Reactive):** The most impactful step: implement an isolated (air gap) backup tier and start recovery tests twice per year. This is affordable relative to the risk and has maximum impact, because the isolated copy is what survives a ransomware attack. **If you are at Level 2 (Basic):** The most impactful step: increase recovery test frequency to 4 times per year and refine recovery runbooks. This costs mostly time and converts your estimated RTO into a demonstrated capability. **If you are at Level 3 (Defined):** The most impactful step: build an isolated recovery environment and introduce an immutable WORM archive tier (hardware WORM such as Silent Cubes). This is a real investment, but it is what separates general DR from genuine cyber resilience against attackers who sabotage recovery. **If you are at Level 4 (Managed):** The most impactful step: a full test with external evaluation plus red teaming. This surfaces the gaps internal routines no longer see. ### A practical note [\#](#a-practical-note "A practical note") Most IT leaders are frustrated that they are stuck at Levels 2 to 3. They know what is needed (an isolated tier, runbooks, tests), but resources are limited. That is normal. The key: **start with what has the most impact, not what is perfect.** For most organizations: an air-gapped backup tier plus quarterly tests beats everything else. It costs relatively little and protects against what will most likely hit you: ransomware that goes after your backups. ### Frequently asked questions [\#](#frequently-asked-questions "Frequently asked questions") **Can you skip a level?** Not really. You cannot move to Level 4 without having the foundations of Levels 2 to 3 in place. **How quickly can you advance a level?** Level 1 to 2: 3 to 6 months. Level 2 to 3: 6 to 12 months. Level 3 to 4: 12 to 24 months. **Do SMBs need Level 4?** No. Level 3 is optimal for most SMBs. Level 4 makes sense for enterprises with higher compliance requirements, including many entities in scope of NIS2 or DORA. --- ### Further Resources [\#](#further-resources "Further Resources") → IT Resilience Guide (/en/blog/it-resilienz-leitfaden/) → From Level 2 to Level 4 Resilience (/en/blog/from-level-2-to-level-4-resilience/) → Multi-Tier Backup Architecture (/en/blog/mehrstufige-backup-architektur/) → Disaster Recovery Test (/en/blog/disaster-recovery-test/) ### WORM WORM (Write Once, Read Many) refers to a storage principle in which data is written once and can technically no longer be altered or deleted — in hardware WORM, this immutability is a physical property of the storage controller, independent of software, operating system or user privileges. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/worm) ### KRITIS (Critical Infrastructure) KRITIS refers to organizations and facilities whose failure or impairment would cause significant supply shortages or threats to public safety — KRITIS operators are subject to heightened IT security requirements under §8a of the German BSI Act and must demonstrate compliance to the BSI every two years. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/kritis-critical-infrastructure) ### WORM WORM (Write Once, Read Many) refers to a storage principle in which data is written once and can technically no longer be altered or deleted — in hardware WORM, this immutability is a physical property of the storage controller, independent of software, operating system or user privileges. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/worm) ### WORM WORM (Write Once, Read Many) refers to a storage principle in which data is written once and can technically no longer be altered or deleted — in hardware WORM, this immutability is a physical property of the storage controller, independent of software, operating system or user privileges. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/worm) ### Disaster Recovery Disaster recovery refers to the structured processes and technical measures that ensure IT systems can be restored within defined timeframes (RTO) with maximum data loss (RPO) after a severe failure — ransomware attack, hardware failure or data center outage. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/disaster-recovery) ### DORA DORA (Digital Operational Resilience Act, EU 2022/2554) is an EU regulation that has applied to all regulated financial market participants since January 2025, setting concrete requirements for ICT risk management, backup systems (Art. 11 and 12), third-party provider management (Art. 28–30) and incident reporting. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/dora) ### Disaster Recovery Disaster recovery refers to the structured processes and technical measures that ensure IT systems can be restored within defined timeframes (RTO) with maximum data loss (RPO) after a severe failure — ransomware attack, hardware failure or data center outage. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/disaster-recovery) ### Disaster Recovery Disaster recovery refers to the structured processes and technical measures that ensure IT systems can be restored within defined timeframes (RTO) with maximum data loss (RPO) after a severe failure — ransomware attack, hardware failure or data center outage. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/disaster-recovery) ### WORM WORM (Write Once, Read Many) refers to a storage principle in which data is written once and can technically no longer be altered or deleted — in hardware WORM, this immutability is a physical property of the storage controller, independent of software, operating system or user privileges. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/worm) ### WORM WORM (Write Once, Read Many) refers to a storage principle in which data is written once and can technically no longer be altered or deleted — in hardware WORM, this immutability is a physical property of the storage controller, independent of software, operating system or user privileges. [Mehr erfahren →](https://www.fast-lta.de//en/glossary/worm)