NIS2 and SaaS backup: what the directive actually expects
NIS2 pushes backup and recovery from best practice to legal obligation for many EU organisations. Here's what that means for your SaaS data — and how to show you can recover.
· Updated:
For many EU organisations, NIS2 backup obligations turn what used to be a best practice into a legal one: you must be able to demonstrate that you can recover critical data and keep operating through an incident. The directive doesn't hand you a product checklist, but its emphasis on business continuity, backup management and testable recovery makes one thing clear — a rolling 30-day SaaS trash bin is not evidence, and native retention alone won't satisfy an assessor.
Here's how NIS2 lands on your SaaS data specifically, and what "demonstrable recovery" looks like in practice.
Who NIS2 applies to
NIS2 (Directive (EU) 2022/2555) covers medium and large organisations that EU member states classify as "essential" or "important" entities — spanning energy, transport, banking, financial market infrastructure, health, drinking water, digital infrastructure, public administration, space, and more, plus their key suppliers. If your organisation sits in one of those sectors above the applicable size threshold, or received a scoping notice from a national authority, NIS2 already applies to you — and the pressure is not theoretical: member states transposed the directive into national law through 2024–2025, and enforcement is now active.
What NIS2 actually asks for
NIS2 requires in-scope entities to adopt appropriate risk-management measures. Among them, the areas that touch backup directly:
- Business continuity — backup management and disaster recovery as an explicit control area.
- Incident handling — the ability to detect, respond to and recover from incidents, including ransomware.
- Effectiveness testing — measures have to be assessed, not just declared. Recovery you've never tested is not a control you can evidence.
The theme throughout is demonstrability. It is not enough to believe you could recover; you have to show it.
Why native SaaS retention doesn't satisfy it
Microsoft 365, Google Workspace, Slack and Atlassian Cloud all offer short native retention — designed for accidental deletion, not for audit evidence. It falls short of NIS2 in three ways:
- No point-in-time recovery. You can restore recent deletions, not "our state on the morning of the 14th".
- No independent copy. Data inside the tenant is exposed to the same compromise that hit the tenant. This is the SaaS shared responsibility model: the vendor guarantees the platform, not your recovery.
- No testable evidence. There's no restore report, no retention proof, no recovery-time record to hand an assessor.
Your SaaS vendors are in scope too
NIS2 doesn't stop at your own infrastructure — it explicitly extends risk-management obligations to your supply chain, including the cloud and SaaS providers holding your data. Microsoft 365, Google Workspace, Slack and Atlassian Cloud all sit in that supply chain. That means the recovery gap in each of them — short retention windows, no independent copy, no restore evidence — isn't just an operational risk anymore; it's a compliance finding waiting to happen across your stack.
What "demonstrable recovery" looks like
To evidence NIS2-aligned recovery for SaaS data, you want:
- Independent, point-in-time backups stored outside the SaaS tenant.
- Defined and tested recovery objectives — a recovery point and recovery time you've actually measured, not guessed.
- Restore reports and retention logs you can put in front of an assessor.
- Ransomware anomaly detection so an incident is caught and time-stamped, not discovered after retention lapses.
That is what we help you put in place across Microsoft 365, Google Workspace, Slack and Atlassian — we help you choose and deploy an independent solution that delivers the capture, the point-in-time restore, and the audit-grade evidence that makes the compliance conversation boring in the best way, and we guide the onboarding. You own and run it.
A practical NIS2 backup checklist for SaaS teams
Before your next audit or supplier review, work through this:
- Inventory which SaaS platforms hold data that matters to continuity — most teams find more than they expect once Teams, Slack channels and Confluence spaces are counted alongside email and Drive.
- Confirm independence — is there a copy of that data stored outside the vendor's own infrastructure, immune to a compromise of the tenant itself?
- Measure your recovery point and recovery time — not the vendor's SLA language, your own tested numbers.
- Keep restore evidence — a report you can hand an assessor, not a verbal assurance.
- Re-run the test — a NIS2 backup control verified once, a year ago, isn't a control an auditor will accept as current.
If you've already mapped this discipline for on-premises systems, the same rigor needs to extend to SaaS — see our Microsoft 365 ransomware recovery playbook for what that looks like once an incident actually happens.
The 30-second self-test
Ask yourself: "If an assessor asked us to restore last quarter's SharePoint state and produce a report proving it, could we — today?" If not, native retention has already left a gap NIS2 will find.
Want a plain map of where you stand? Book a free risk assessment — we'll review your SaaS tenants against recovery and evidence needs, and give you a straight list of the gaps. No legal hand-waving, no pricing pitch.
Related reading
GDPR backup requirements: what the regulation asks of SaaS data
GDPR never says the word "backup" — yet Article 32 requires you to restore personal data in a timely manner, and to test that you can. Here's what that means.
SaaS disaster recovery plan: the failures backup alone will not fix
Most SaaS disasters destroy access, not data — a vendor outage, a failed sign-on, a lapsed subscription. A SaaS disaster recovery plan has to cover all five hazards, not just the one a backup fixes.
Ransomware disaster recovery plan for SaaS data
A ransomware disaster recovery plan for SaaS starts with RTO and RPO — but the platform, not you, sets your recovery point. Here is how to take it back.