NIS2 and BSIG: backup management that holds up when it counts

Since 6 December 2025, backup and disaster recovery have been a legal obligation for many companies in Germany. The NIS2 Implementation Act (NIS2UmsuCG) rewrote the German BSI Act (BSIG) for this and transposed the European NIS2 Directive. Around 30,000 companies now have to run risk management they can prove, many of them for the first time. For an overview of all technical requirements, see our page NIS2 for development and operations.

This article focuses on one part that is often underestimated in practice: Section 30(2) no. 3 BSIG requires measures for “business continuity, such as backup management and disaster recovery, and crisis management”. In the directive, this is Article 21(2)(c). We show what is behind it, which concrete requirements exist and what a backup concept looks like that survives a ransomware attack.

Note: This article is a technical assessment and not legal advice. Whether and how your company is affected is best clarified with your legal department or law firm.

Are you affected?

Section 28 BSIG distinguishes two categories. What matters is the sector (Annexes 1 and 2 of the Act) and the size:

Some entities are covered regardless of size, such as operators of critical facilities, DNS service providers, TLD registries and qualified trust service providers. Lower thresholds apply to telecommunications providers. Affected companies must register with the BSI under Section 33. For entities that were affected when the law took effect, the deadline ended on 6 March 2026. Anyone who becomes affected later, for example through growth, has three months from then. You can check whether you are affected with the BSI's self-assessment (in German).

For banks and insurers, the Digital Operational Resilience Act (DORA) takes precedence. Its backup and recovery requirements are in Article 12 and point in a similar direction.

Backups are now a board-level topic

What is new is who is responsible. Under Section 38 BSIG, management must implement the risk management measures and oversee their implementation. Its members must take part in training regularly and are liable to their entity for culpably caused damage.

The question “Does our backup work?” is therefore no longer just for IT, but for management. And management needs an answer it can prove.

What belongs in your backup concept

The text of the law itself stays general. The Implementing Regulation (EU) 2024/2690 is more specific. It applies directly to digital providers such as cloud, data centre and DNS services and managed service providers. For everyone else, it is the best available guide to what auditors will consider the “state of the art”.

Section 4.2 of its annex (“Backup and redundancy management”) essentially requires:

• Backups and redundancy with sufficient resources: sites, systems and staff.
• A backup plan derived from the risk assessment and the continuity plan, with recovery times, access controls and retention periods. The copies must be complete, explicitly including configuration data and data stored in cloud services, and kept in a location that is not on the same network as the system and far enough away to survive damage at the main site.
• Regular integrity checks of the backup copies.
• Redundancy of systems, facilities, staff and communication channels where needed.
• Regular, documented tests of recovery, with corrective action if something does not work.

ENISA has published detailed implementation guidance on this, with examples of which evidence is considered sufficient.

First question: how much downtime can you take?

Every backup strategy starts with two numbers per system:

• RPO (Recovery Point Objective): How much data can you afford to lose? An RPO of 24 hours means a nightly backup is enough. At 5 minutes, you need continuous replication or point-in-time recovery.
• RTO (Recovery Time Objective): How long can the system be down before it is running again?

These numbers are not set by IT but by the business, ideally in a business impact analysis following BSI Standard 200-4. Three classes are a pragmatic start:

Only from these follow backup frequency, storage location and the effort you put into tests.

Ransomware-proof backups

Ransomware groups specifically look for backups and delete or encrypt them before they attack production systems. A backup that a compromised admin account can access does not protect you. The 3-2-1-1-0 rule has proven itself:

• 3 copies of your data,
• on 2 different media or systems,
• 1 of them at another site,
• 1 of them immutable (immutable backup, for example with S3 Object Lock, MinIO Object Lock or WORM media) or offline,
• 0 errors when verifying recovery.

With Object Lock, pay attention to the mode. Only in compliance mode can nobody lift the lock early, not even a root account. In governance mode, anyone with the s3:BypassGovernanceRetention permission can delete, and those are exactly the rights an attacker looks for first.

On top of that come points that are regularly missing in projects:

• Separate identities for the backup system. Backups do not belong in the same Active Directory domain as production. Separate access, multi-factor authentication and as few people as possible with delete rights.
• Key management. Encrypted backups are worthless if the key is lost along with the compromised system. Store the keys separately and test whether you can get to them without the production environment.
• Retention longer than dwell time. Attackers are often in the network for days to weeks before they encrypt. If you only keep backups for seven days, every copy may already be compromised. Retention must therefore be longer than a realistic dwell time.
• The backup system itself. The catalogue and configuration of your backup software, for example Veeam or Bareos, must be backed up too. Without them, the data is there, but you can no longer get to it.
• Retention and data protection. Immutable backups and GDPR erasure obligations seem to contradict each other at first. Short, documented retention periods and a recovery process that removes deleted records again resolve the conflict.

What often isn't backed up

Most gaps don't appear with the classic database in the data centre, but here:

• SaaS services: Microsoft 365, GitHub, Jira or your CRM. Providers back up their infrastructure, but not necessarily your data against accidental deletion or a compromised account. Read your provider's shared responsibility model carefully.
• Kubernetes: Besides the persistent volumes, you need the cluster state. For self-managed clusters, you back up etcd with snapshots. With managed Kubernetes (EKS, AKS, GKE), you have no access to it. There, you back up API objects and volumes with Velero, or you rebuild the cluster state with GitOps and only back up the data. Remember the keys: if you encrypt secrets with Sealed Secrets or a KMS, you need exactly those keys after a restore. More on this in our article Should you run your software on Kubernetes?
• Databases: A database file copied while running is not a reliable backup. Use the database's own tools: for PostgreSQL, base backups plus WAL archiving with pgBackRest or WAL-G, which also enable point-in-time recovery.
• Infrastructure and configuration: If your platform lives as code in Git, the repository is part of your disaster recovery plan. With GitOps and Argo CD, you rebuild an environment from Git instead of piecing it together from backups.
• Manual changes to IaC infrastructure: If a cloud resource, a switch or an appliance was originally provisioned with Terraform or Ansible and later changed by hand, your code only restores the old state. This drift usually only shows up during recovery. Detect drift regularly, for example with terraform plan in the pipeline, and bring manual changes back into the code.
• Configuration after installation: Many applications are installed automatically but then configured through their UI: users, groups, runners, integrations, webhooks. In GitLab, for example, such settings live in the database and in configuration files the installation script doesn't know about. Back them up as well, or manage them as code too.

What we see in projects again and again

When we look at backup management at our clients, we almost always find one or more of these weaknesses:

• Backups in the same environment as the application. If backup and application share a cloud account, a cluster or the same storage, an attack or an operating error takes out both at once.
• Backup jobs are barely monitored, or not at all. A job that has been failing for weeks or only writes empty files goes unnoticed until someone needs a backup.
• Restore tests only once after the rollout. After that, data volumes, versions and dependencies change, but nobody checks whether recovery still works and how long it takes.
• No WORM. Without immutable storage, anyone with write access to the backup target can delete or encrypt backups, including a compromised account.
• Incomplete backups. A typical example is GitLab: repositories and database are backed up, but the file containing the keys GitLab uses to encrypt sensitive data in the database (gitlab-secrets.json) is not part of the standard backup. Without it, CI/CD variables, two-factor settings and runner tokens can no longer be decrypted after a restore. You only notice if you actually test the recovery.

Plan the recovery, not just the backup

Disaster recovery rarely fails because of the backup itself, but because of the order. Before your business application runs again, you need network, DNS, identity provider, secrets and databases. A disaster recovery plan therefore defines:

1. Who decides and who restores, including deputies.
2. In which order systems come back, derived from their dependencies.
3. Where the instructions are. A runbook in the wiki that goes down with the wiki does not help. Keep an offline copy.
4. How you communicate when email and chat are down.

Only recovery tests show whether the plan holds, and on several levels: individual files, whole systems and, once a year, a full disaster recovery exercise. Automated restore tests give the most confidence, for example a pipeline that restores the production database into a staging environment every night and checks it. That way you measure your actual RTO instead of estimating it, and the log is your evidence at the same time.

Include the reporting obligations in your plan. Under Section 32 BSIG, you must report a significant security incident to the BSI no later than 24 hours after becoming aware of it with an early warning, after 72 hours with an incident notification and after one month with a final report. These deadlines run in parallel with the recovery. Decide in advance who reports.

A scenario: Friday, 10 pm

A monitoring alert reports an unusually high number of file changes on the file server. Shortly afterwards, the first systems are encrypted. What matters now:

• Hours 0–2: Assemble the crisis team, isolate affected systems, disconnect backups from the network if they aren't already. Inform management.
• By hour 24: Early warning to the BSI. Check which backups are clean, meaning they date from before the attackers first got in.
• From hour 24: Restore in the planned order, first into a clean, isolated environment (clean room). There you check the data for malware before it goes back into production, so the attacker doesn't come back with the backup. Critical systems first, according to their RTO.
• By hour 72: Notification with an initial assessment to the BSI.
• Afterwards: Root cause analysis, final report, feed lessons learned back into the plan.

If you have walked through this once as a tabletop exercise, you will be much faster when it happens for real.

What to show in an audit

NIS2 requires not only measures but evidence. Keep at least these documents up to date:

• Backup policy with RPO and RTO per system class
• Overview of which systems and data are backed up, and where
• Logs of recovery tests with measured duration
• Monitoring history of the backups and responses to alerts
• Disaster recovery plan with the date of the last exercise
• Evidence that management knows and oversees the measures

This is easiest when the evidence is produced automatically: pipelines that log tests, monitoring with history and documented architecture decisions.

Mapping to established standards

If you already work to a standard, you can reuse a lot:

Practical checklist

These questions quickly show you where you stand:

• Do you know the RPO and RTO of your most important systems? And has the business confirmed them?
• Do you know which data is backed up and which isn't? SaaS services and new systems in particular often slip through.
• Is there an immutable or offline copy? And can a compromised admin account delete it?
• Is access to the backup system separate from production? With its own multi-factor authentication?
• Can you get to the keys when production is gone?
• Do you notice when a backup is missing or suspiciously small? A job reporting “success” doesn't mean the file is actually complete.
• When did you last test a recovery? How long did it take, and does that match the RTO?
• Does everyone on the team know the emergency plan? And can they reach it when systems are down?
• Do you know who reports to the BSI within 24 hours?
• Can you prove all of this in an audit?

Monitor backups actively

For monitoring, we built backmon. backmon checks the presence, size and age of your backup files in the file system or in S3-compatible object storage and delivers the metrics to Prometheus and Grafana. There you build dashboards and alerts for when a backup is missing, too old or out of line. The history also serves as evidence in an audit. backmon is open source and free.

This answers the question “Is the backup there?”. Whether it can also be restored is only shown by recovery tests. Together, both make for backup management you can defend in front of auditors and your management.

Want to know what NIS2 means for your architecture and infrastructure? Our page NIS2 for development and operations gives you an overview of all technical areas. Or talk to us directly: in our Advisory, we answer exactly these questions.

Sources

• Directive (EU) 2022/2555 (NIS2 Directive), Art. 21: EUR-Lex
• German BSI Act (BSIG) as amended by the NIS2UmsuCG (in German): Section 28, Section 30, Section 32, Section 33, Section 38
• Implementing Regulation (EU) 2024/2690, annex section 4: EUR-Lex
• ENISA: NIS2 Technical Implementation Guidance (June 2025): enisa.europa.eu
• BSI: NIS2-regulated companies and self-assessment (in German): bsi.bund.de
• BSI: IT-Grundschutz Compendium, module CON.3 (in German): bsi.bund.de
• BSI Standard 200-4 Business Continuity Management (in German): bsi.bund.de
• Regulation (EU) 2022/2554 (DORA), Art. 12: EUR-Lex
• ISO/IEC 27001:2022: iso.org
• GitLab documentation: backing up configuration and secrets files: docs.gitlab.com

Originally published on July 9, 2024.