NIS2 business continuity and backup: what Article 21(2)(c) requires

Article 21(2)(c) reads, in the operative part, as business continuity, such as backup management and disaster recovery, and crisis management. That single item bundles together three things that most organisations run in different places: a technical backup practice owned by infrastructure, a recovery plan owned by IT, and a crisis process owned by the executive. NIS2 treats them as one measure because from a regulator's point of view they answer one question. If this service stops, what happens next, and how long until it is back?

This article works through the measure in the order you should build it: recovery objectives derived from service criticality, a backup architecture that assumes the attacker is already inside, the continuity layer above the technology, crisis management and its collision with the Article 23 reporting clock, and the evidence that proves the whole thing works.

Start with services, not systems

The measure applies to the continuity of your essential or important services. That is the unit of analysis, and it is not the same as the unit most IT teams work in. A backup policy that says "all production servers, daily, 30 day retention" is a systems answer to a services question. It cannot tell you which restore to run first when forty servers are encrypted at once.

The starting artefact is a short table. One row per essential or important service. Columns for the maximum tolerable outage agreed with the business, the maximum tolerable data loss, the systems that support the service, the supplier dependencies, and a named business owner. Ten rows done properly is worth more than a hundred rows copied from the CMDB. This table is also the thing that makes the difference between an argument and a decision when recovery is under way, because priority has been agreed in advance by people who were not under pressure.

From that table, recovery objectives fall out naturally. The recovery time objective is the maximum tolerable outage translated into a technical target. The recovery point objective is the maximum tolerable data loss translated into a backup frequency. Neither term appears in the directive, but Article 21(2)(f) requires you to assess the effectiveness of your measures, and effectiveness cannot be assessed without a target to measure against.

Backup architecture that assumes compromise

Backup design used to be about hardware failure and human error. Both still happen, and both are handled by conventional backups. The threat that reshaped the discipline is ransomware, because a ransomware operator with domain administrator rights spends time locating and destroying backups before triggering encryption. Against that adversary, a backup server joined to the same domain, with a management console reachable by the same credentials, is part of the blast radius rather than the recovery path.

The design principles that follow are not new, but they are worth stating plainly because they are what a supervisor or an underwriter is checking for.

• At least one copy an attacker cannot reach. Offline, air gapped, or immutable with a retention lock the production administrators cannot lift. The test is simple: if someone with the highest privilege in your environment turns malicious this afternoon, which copy survives?
• Separate the identity plane. Backup infrastructure should not authenticate against the same directory as production. A compromised directory should not hand over the recovery capability along with everything else.
• Protect the configuration, not only the data. Restoring files onto a domain you cannot rebuild is a slow way to discover that the directory, the certificate authority and the network configuration were never in scope for backup.
• Monitor backup failures as security events. A quiet run of failed backup jobs is either an operational problem or the first stage of an attack. Either way it should page someone, not sit in a report nobody reads.
• Keep a clean recovery environment plan. Restoring into a network that is still compromised reinfects the restored systems. Write down where clean recovery happens before you need it.

Restore testing is the evidence, not the backup job

A completed backup job proves that data was written. It does not prove that data can be read, that the restore procedure works, that the person on call can execute it, or that the result comes back inside the recovery time objective. Only a restore test proves those things, and it is the single artefact most likely to be requested during supervision.

A restore test worth documenting has five properties. It restores to a separate environment rather than over production. It is executed by someone following the written procedure, ideally not the person who wrote it. It measures elapsed time from decision to service availability. It verifies the restored data at application level, not just at file level. And it records what went wrong, because every real test produces surprises and a report with no surprises reads as a report of a test that was not really run.

Frequency should follow criticality. Annually is the floor for anything in scope, quarterly is normal for the systems behind the most critical service, and after any material change to the backup platform. What matters for evidence is the trend: three dated reports over eighteen months, with recovery times improving and issues closed, tell a much better story than one flawless test last month.

The continuity layer above the technology

Disaster recovery gets the systems back. Business continuity keeps the service running while they are down. These are different plans with different owners, and NIS2 names both. The continuity plan answers questions that no technical runbook covers.

• Manual workarounds. What does the operation do on paper, by phone, or on a standalone laptop, and for how long can that hold? Hospitals and utilities generally have this. Software and services companies often do not.
• Prioritisation. If only part of the service can run, who gets it. This is a business decision made in advance, not an operational decision made at 03:00.
• Communication. What customers, staff and supervisory authorities are told, by whom, through which channel, and where the templates live if email is down.
• Dependencies you do not control. If the outage is at a supplier, your recovery time is theirs. That belongs in the supplier contract and in the continuity plan, not in a hopeful assumption.
• Return to normal. Coming off a workaround and reconciling the data created during it is often harder than the outage. It needs a plan of its own.

Crisis management and the reporting clock

Crisis management is the third element in the measure and the one most often left as an implicit assumption that the executive team will work it out. Under NIS2 that assumption is expensive, because the Article 23 reporting timeline runs at the same time as the recovery. An early warning is due to the CSIRT or competent authority within 24 hours of becoming aware of a significant incident. An incident notification with an initial assessment follows within 72 hours. A final report is due within one month.

Those deadlines are not paused by the fact that your team is busy restoring systems. The practical fix is structural: separate the technical incident commander from the regulatory reporting owner, and give each a deputy. One person cannot both direct a recovery and draft a regulatory notification, and when they try, the notification is what slips.

Crisis management also needs a written trigger. Who declares a crisis, on what criteria, and what changes when they do. Without that, organisations spend the first six hours of a major incident debating whether it is a major incident, which is exactly the six hours the 24-hour clock cannot spare.

Where the cloud assumption breaks

A recurring gap in otherwise mature programmes is the assumption that software as a service means someone else handles continuity. Platform providers deliver infrastructure resilience and, usually, short recovery windows for data they consider theirs to protect. What they generally do not protect you against is deletion by your own administrators, corruption propagated through your own integrations, a compromised account in your tenant, or a contractual termination that takes your data with it.

Document the split per service. What the provider backs up, for how long, how you request a restore, how long that takes, and what you back up independently. Then check the answer against the recovery objectives in your criticality table. Where a provider's standard restore window is longer than your stated objective, you have either a control gap or an objective that needs revising. Both are fine outcomes. Discovering the mismatch during an incident is not.

Frequently asked questions

Related articles