NIS2 Business Continuity & Backups (Article 21(2)(c)): Tested, Not Assumed
NIS2 Article 21(2)(c) requires backup management, disaster recovery and crisis management. The word that matters is 'tested', a backup you've never restored is a hope, not a control.
Article 21(2)(c) covers backup management, disaster recovery, and crisis management. In practice it answers one blunt question: if your most important system went down, or got encrypted, right now, how fast and how cleanly would you come back?
General guidance, not legal advice. NIS2 is transposed nationally (Italy: D.Lgs. 138/2024 / ACN). Verify specifics with your authority.
The three parts
- Backups, regular, and crucially restorable. The most common failure isn’t the absence of backups; it’s discovering during an incident that they were incomplete, corrupted, or also encrypted by the ransomware.
- Disaster recovery, a documented way to bring critical services back: where they run, in what order, with what dependencies, and within what target time (RTO) and acceptable data loss (RPO).
- Crisis management, who’s in charge during a major disruption, how decisions and communications flow, and how you keep the business running while IT recovers.
The one thing auditors look for: evidence you’ve tested it
A backup you have never restored is a hope. A DR plan you have never exercised is a document. NIS2’s intent, and any serious assessor’s question, is “show me the last time you tested this.” A defensible baseline:
- 3-2-1 backups (three copies, two media, one off-site/offline) for critical data, with at least one copy isolated from your network so ransomware can’t reach it.
- A restore test on a schedule (quarterly is a sensible default), where you actually recover a system from backup and confirm it works, and you write down that you did.
- A one-page DR runbook per critical service with RTO/RPO targets and recovery steps.
- A crisis playbook: roles, contact tree, decision authority, and a comms template for customers and your authority.
The link to incidents and vulnerabilities
Most continuity events that aren’t natural disasters are security incidents, and most security incidents start with a known, exploited vulnerability. Strong backups and DR are your safety net; reducing the number of incidents you’ll ever need that net for is the complementary half. Knowing fast which systems are exposed to actively-exploited vulnerabilities, what SentriKat does, shrinks the set of “bad days” you have to recover from.
Start here
Pick your single most important system. Confirm it’s backed up with one offline copy, restore it into a test environment this week, and write a one-page recovery runbook with an RTO. That alone takes you from “we have backups somewhere” to “we have a tested continuity capability.”
Want to see where continuity sits among all ten NIS2 measures for you? Try the free NIS2/DORA readiness check, indicative result in ~5 minutes.
Ready to automate your vulnerability management?
Deploy SentriKat on-premises in minutes. Track CISA KEV vulnerabilities, generate NIS2 compliance reports, and protect your infrastructure.
Request a Demo