Having a backup is not enough under NIS2. It’s about verifiable recovery. In an earlier article, we explained why registering with the BSI is only the beginning. This article looks at the follow-up question of how to build that evidence. Using our webinar with Dr. Carsten Csambal from Pink Elephant, we show what it takes.

Carsten opened the webinar on October 8 with a question for participants: Can you demonstrate to management, customers, or auditors that your critical systems can be cleanly restored within the agreed time? If your answer is “yes and no,” he said, you’re in the right place.

According to Carsten, the real question is no longer whether or when a company will be hit. The question is how often. And when it happens, it should happen only once. If you look at cyber resilience that way, you can’t treat recovery as a plan on paper. You need to be able to show that it works.

What the NIS2 Implementation Act requires for recovery

Since December 6, 2025, Germany’s NIS2 Implementation Act has been in force. It transposes the European NIS2 Directive into German law and revises the BSI Act (BSIG). Affected entities must implement appropriate, proportionate, and effective measures. Section 30 BSIG lists ten minimum requirements. One of them explicitly covers maintaining operations, such as backup management and recovery after an emergency, and crisis management. In other words: not only preventing things from going wrong, but also ensuring you can keep working and recover when they do.

The law does not prescribe in detail how you must implement this. The measures must fit your organization and risk profile. That freedom sounds convenient, but it also puts the burden of proof on you. Another minimum requirement calls for concepts and procedures to assess the effectiveness of your measures. So you decide what is appropriate—as long as you can prove it works. Carsten put it like this: A successful backup is a technical event. A documented recovery test is evidence.

That’s exactly where, in practice, the difference between trust and evidence often lies. For the Data Trust and Resilience Report 2026, Veeam surveyed more than 900 IT and security decision-makers. Ninety percent expect to be operational again within the agreed recovery time after a cyber incident. The same study shows that, among organizations hit by ransomware, 28% got all their data back. The two figures don’t measure the same thing. The first is about expected recovery time; the second is about data actually restored. Together, they show that trusting recovery is not the same as proven recovery.

This is exactly where NIS2 comes in. As long as nothing happens, recovery is largely an internal assessment. After an incident, it becomes evidence. Then you must be able to show which systems are critical, what recovery times were agreed, when testing took place, and with what result.

Requirements first, then technology

If you want to prove under NIS2 that recovery works, you first need to know exactly what must be restored. The technology comes afterwards. Verifiable recovery therefore starts with a business impact analysis. In it, you define which processes are critical and which systems are needed to keep those processes running.

You then set two limits per service. The Recovery Time Objective (RTO) defines how long a service may be down at most. The Recovery Point Objective (RPO) defines how much data loss is acceptable. These limits are not the same for every service. An archive system can usually be down longer than the system your core process runs on.

Carsten uses the term Minimum Viable Company for this: the smallest functional operating state after a major disruption. Instead of restoring the entire environment immediately, you first prioritize the processes, applications, data, and access needed for your core services. The practical question is which services must work in the first few hours—and which can follow later.

That leads to the restart sequence. First come foundational services and core processes, then dependent and less critical functions. Carsten pointed out a detail that is often overlooked: if forensic teams take the old environment offline for analysis after an attack, you need spare capacity to build your Minimum Viable Company in the first place. It’s better to plan that capacity in advance than in the middle of an incident.

Make sure the backup survives the attack

In the past, a backup was mainly for bad luck—think of a failed hard drive, an accidentally deleted file, or water damage in the data center. With ransomware, it’s different. There is intent behind it. Traditional backup concepts were designed for outages, not for an intelligent adversary, Carsten said. An attacker knows that a working backup can be the reason not to pay. That’s why they often try to render backups unusable first.

That’s why you need not only to have a backup, but also to ensure it survives the attack. A practical starting point is the 3-2-1-1-0 rule. You keep three copies of your data, including production data. These are stored on two different types of media. One copy is off-site, and one copy is immutable. The zero stands for zero errors after verification. You don’t just check whether the backup ran—you also check whether you can actually restore from it. That’s where evidence begins.

For the immutable copy, there are two broad approaches. The first is air-gapping. There is no permanent, open connection between production and backup, and data moves only via controlled paths such as a separate gateway. Carsten emphasized that an effective air gap separates the data path, management path, and identity path. If any of these remains open, an attacker can bypass the isolation. The second approach is storage that cannot be changed after writing, such as object storage with Object Lock, or an offline medium like a tape in a safe.

Access must be separated as well. In the event of a successful attack, assume the authentication domain of your production environment is compromised. Ten years ago, it was still common to add the backup server to the production domain for convenience. Today, that is an ideal attack scenario. The backup environment therefore belongs in its own authentication domain, with no trust relationship to production and with multi-factor authentication for administrator accounts.

Restore without reintroducing the infection

Assume things go wrong. For days, backups run without error messages—then it turns out the environment is infected. The first question is from which point you can restore safely. Malware is often present in a system before it is discovered—and therefore in your backups as well.

Carsten walked through the process step by step. First, you scan the existing backups using current threat intelligence so you know which restore points are clean. In his example, fully restoring the oldest clean backup would have cost many changes, even though individual data segments were never attacked and could have come from the latest backup. With synthetic recovery, you therefore assemble the restored environment per object from the most recent clean version.

This recovery first takes place in a cleanroom—an environment isolated from the production network. There you verify that the data is clean and consistent and that the systems do what they are supposed to do. The cleanroom should be realistic enough to test dependencies, but must remain strictly separated from production. This validation remains manual work. Only after documented approval does the environment go into production.

What an auditor wants to see

Up to this point, the focus was on being able to restore. It only becomes verifiable when you document it. Carsten spoke of a dual mandate for recovery teams: act quickly, and at the same time record times, decisions, and recovery steps in a way that can be reconstructed later. Every step needs an owner and a documented outcome.

What belongs in a recovery test report? At a minimum, the test date and the systems involved. Also the measured recovery time alongside the agreed RTO, the point up to which you recovered data alongside the RPO, and any deviations with an action plan. A document stating that you can restore is an intention. A measured recovery time is evidence.

A single test is not enough, because plans age. New versions, interfaces, and locations change the environment. According to Carsten, every change should therefore trigger a review of the recovery documentation. You don’t have to start with a full failover. A tabletop exercise for decision-making or a partial failover for individual components already provides an initial measurement.

Cyber Resilience Assessment

Would you like to first understand where your own organization stands? The free Cyber Resilience Assessment gives you an initial view of your recovery capability in just a few questions.

Cyber resilience begins at the storage level

The next Data Resilience Session takes place on 19 November and covers protecting your backups at the storage level. Sign up now

Frequently asked questions about verifiable recovery and NIS2