Business Continuity for NIS-2: From Manual Runbooks to Automated Mechanics

With the enactment of NIS-2 and the tightening of national security laws (such as BSIG 2.0), the playing field for KRITIS operators has changed. It is no longer sufficient to file theoretical emergency plans in folders. Regulations now demand proof of business continuity—and under real conditions.

The problem for many organizations: their “Disaster Recovery” is based on manual runbooks. In an emergency, people would have to execute complex command chains under extreme stress. In today’s interconnected world, this approach is too slow and error-prone. True resilience is achieved when business continuity shifts from a human task to an architectural mechanism.

The Problem: “Paper Security”

Manual emergency plans (runbooks) have three systemic weaknesses:

1. Expiration Date: Infrastructures change weekly, runbooks often only annually. In an emergency, the commands no longer match reality.
2. Human Factor: Stress leads to errors. Manually switching databases or DNS entries in a crisis is one of the most common causes of prolonged downtimes.
3. Lack of Testability: Testing a manual recovery scenario is so labor-intensive that it rarely happens. Without regular tests, the actual recovery time (RTO) remains a mere estimate.

The Solution: “Resilience by Design” through Automation

A modern KRITIS system, as described in this series, replaces hope with mechanics. Business continuity here is not an event to be “declared” but a feature of the platform.

1. Automated Response Instead of Manual Intervention

By combining BGP Anycast and active/active clusters, the infrastructure autonomously responds to the failure of a region. Traffic reroutes because network paths physically change, not because a technician makes a decision. This reduces the RTO from hours to seconds.

2. Verifiability through System Logs (Audit Capability)

Instead of laboriously writing logs for auditors, an automated platform provides evidence systemically. GitOps histories demonstrate consistency, and monitoring dashboards document every automatic load shift. This makes compliance with NIS-2 requirements a byproduct of normal operations.

3. Continuous Validation (Chaos Engineering)

Instead of conducting an “emergency drill” once a year, an automated multi-region architecture allows for regular failover tests during operation. A region is deliberately shut down, and the system’s response is measured. These measurable data are the strongest argument against any regulator.

Conclusion: The Evolution of Security

The transition from isolated machines to interconnected, geo-redundant platforms is the answer to the threat landscape and regulatory requirements of our time. Security for KRITIS today means mastering complexity through intelligent architecture. Automating business continuity not only protects data but also operational capability and market trust.

FAQ

What is the first step to becoming NIS-2 compliant? The first step is a realistic risk analysis: What happens if my current location is completely offline for 24 hours? The answer to this question usually immediately reveals the gaps in the current business continuity strategy.

Aren’t automated systems more prone to “chain reactions”? Only if they are poorly decoupled. That’s why the approach of autonomous clusters and a clear separation of control planes (as described in Part 3) is so important. Automation must always be accompanied by limiting the blast radius.

How do auditors react to automated failover concepts? Generally very positively. A technical proof that a system autonomously switches over within 30 seconds is far more credible to an auditor than a 50-page document describing who should call whom in an emergency.

Can smaller companies handle this effort? Yes, because the necessary technologies (Kubernetes, Cilium, ArgoCD) are open source and industry standards. The challenge lies less in the budget and more in building the necessary know-how for a clean architecture.