Shadow AI in the workplace

A Business Continuity Plan (BCP) is not just an IT document. It is the written strategy for how an organization maintains (or quickly restores) its critical business processes when a disruption occurs. A cyberattack, a natural disaster, a building failure: the BCP covers all of it.Many IT leaders confuse the BCP with a DR Plan (Disaster Recovery Plan). That is a mistake. The DR Plan is technical (how do we bring systems back up?). The BCP is business-oriented (which processes are critical, and how long can they be down?).---

A DR plan that has never been tested is fiction. This is not an overreaction. It is IT reality. Backups that have not been tested often cannot be restored. Recovery runbooks that have never been rehearsed contain countless errors. RTOs that have never been measured are guesswork.The good news: regular DR tests are not impossible. There are three practical methods, varying in effort and depth.---

The NIS2 Directive (EU 2022/2555) had to be transposed into national law by 17 October 2024. Deadlines and details vary by EU member state, so always check the national law applicable to your organisation. Germany completed transposition with the NIS2 Implementation Act (NIS2UmsuCG), in force since 6 December 2025. The examples below refer to the German implementation.The key point: there is no general transition period. The obligations apply since the law took effect.---

RTO (Recovery Time Objective) and RPO (Recovery Point Objective) are the most critical metrics in any resilience strategy. They answer two questions:- **RTO:** How long can my system be down? - **RPO:** How much data loss can I tolerate?The problem: many organizations "estimate" RTO/RPO based on gut feeling or IT tradition. That is the wrong approach. RTO/RPO must be derived from a **Business Impact Analysis (BIA)**, not the other way around. The BIA-first approach is also what the relevant standards expect: ISO 22301 builds the entire BCM system on it, and NIS2 (Directive (EU) 2022/2555) requires risk-based backup management and disaster recovery.---

RTO is one of the most important concepts in backup and disaster recovery management. But most organisations get it wrong. They say "our RTO is 4 hours," then when an attack hits, recovery takes 2 days. This article explains how to calculate RTO realistically and, more importantly, how to test it.---

A recovery runbook is not an IT philosophy. It is an operational handbook. It is the document your IT team reaches for during an actual disaster and uses to work through, step by step, how to bring systems back up.A good runbook is specific enough that someone who does not normally maintain the system could still restore it. That is the quality benchmark.---

An Isolated Recovery Environment (IRE), sometimes called a cleanroom, is not a single device. It is an infrastructure zone that is completely isolated from the production network. It is the place where you restore, verify, and clean compromised systems before returning them to production.Without an IRE, recovery in a compromised network is a gamble: the restored server gets reinfected before you can use it.---

"Assume Breach" is not just a security slogan. It is a fundamental design principle that reshapes the entire architecture of an organization. Think it through consistently, and you have to rebuild parts of your IT.The concept is simple: **not if, but when will your organization be attacked and compromised?**This is not pessimism. The data is unambiguous: in the Veeam Ransomware Trends Report 2025, roughly 7 in 10 organizations reported at least one ransomware attack in the preceding year, despite improved defenses. For exposed industries (financial services, healthcare, manufacturing), the question is realistically only: when?---

Most organizations have backups, but no demonstrated recovery capability. They have a DR plan, but it is outdated and has never been tested. When a ransomware attack hits the backup infrastructure as well, that is not a recovery plan. It is an assumption.Level 4 is the point where resilience stops being an assumption and becomes a demonstrated, verifiable capability. This article describes what makes the difference, and which measures get you there most efficiently.---

Most organizations do not know where they stand on the resilience maturity scale. They say "We have backups," but that could mean anything: from "someone sporadically copies data to a USB stick" to "a professional 4-tier backup architecture with quarterly tests."A maturity model in the style of the Capability Maturity Model (CMM) helps. It defines 5 maturity levels for IT resilience. Use these questions to assess where you stand, and where the most impactful next step is. Maturity evidence also matters for compliance: NIS2 (Directive (EU) 2022/2555) expects demonstrable backup management and disaster recovery, and DORA requires financial entities to test their resilience.---

IT resilience is no longer a technical question. It is a board-level question. At the latest since NIS2 (Directive (EU) 2022/2555) and DORA (Regulation (EU) 2022/2554), executives face personal accountability for inadequate resilience. But compliance is not the only driver. Five hard business arguments demonstrate why resilience investment pays off and why inaction is costly.---

A robust IT resilience strategy does not rest on a single pillar. It rests on five. Each pillar has specific technologies, processes, and responsibilities. Many organizations invest heavily in Pillar 1 (Prevention) and neglect the other four. That is a classic mistake that leads to vulnerability, and it is also a compliance gap: NIS2 (Directive (EU) 2022/2555) explicitly requires backup management, disaster recovery, and crisis management alongside preventive measures.Here is a practical framework showing what belongs to each pillar and how to implement it.---