‘Not in the Same Network’: What CIR 4.2.2(c) Means for Same-Tenant Snapshots, Replicas and Microsoft 365 Backup

Short answer: NIS2’s implementing rules require backup copies to sit “not in the same network as the system”. Native Microsoft 365 Backup keeps every copy inside what Microsoft itself calls the Microsoft 365 data trust boundary, and the same tenant’s admins manage it. That makes it a strong recovery tool, but a weak answer on its own to that clause. A second copy outside your tenant’s identity plane removes the doubt. The same annex also names cloud-hosted data and configuration data, so “it’s SaaS, Microsoft handles it” isn’t a defence either.

The clause is point 4.2.2(c) of the Annex to Commission Implementing Regulation (EU) 2024/2690. Most of what ranks for this query comes from backup vendors, and none of the pages we checked quote the clause or test Microsoft’s own architecture notes against it. That’s what this guide does, mechanism by mechanism.

One disclosure: we sell NIS2 templates, including a business continuity pack that contains a backup policy. Weigh the product mention with that in mind. The legal text below is quoted from the Official Journal, and the product facts come from Microsoft’s own documentation.

This article provides general information only and does not constitute legal or regulatory advice. Requirements may vary by jurisdiction and organisation type. Consult a qualified legal professional or compliance specialist for advice specific to your situation.

Does this apply to you? Scope first

In plain terms: the backup clauses quoted here are binding word for word only on certain digital-infrastructure and digital-service entities. Every other NIS2 entity still has to manage backups under the Directive and its national law, and the CIR wording is the most detailed EU benchmark for what that looks like.

Article 1 of Implementing Regulation 2024/2690 (the CIR) limits its technical requirements to a closed list of “relevant entities”. For everyone else, the duty comes from Article 21(2)(c) of the NIS2 Directive, which requires measures covering “business continuity, such as backup management and disaster recovery, and crisis management”, as transposed by your Member State.

Your organisation	Status of CIR point 4.2.2	What that means for Microsoft 365 data
DNS service provider, TLD registry, cloud computing, data centre or CDN provider, managed service provider (MSP), managed security service provider (MSSP), online marketplace, search engine, social network platform, trust service provider	Binding text (CIR Article 1 and Article 2(1))	Your backup plan must address each point (a) to (f). Proportionality under Article 2(2) shapes how you meet it, not whether.
Any other essential or important entity (energy, health, transport, manufacturing, public administration and so on)	Benchmark. The binding duty is Article 21(2)(c) as transposed nationally.	In practice, auditors often reach for the CIR wording as the reference standard. Check your national law for its own backup provisions.
Supplier to a NIS2 entity, not in scope yourself	Contractual, through your customer’s supply chain clauses	Expect questionnaires that quote 4.2.2(c). Have an answer ready.

MSPs deserve a flag. If you run Microsoft 365 tenants for clients, you’re a relevant entity, and you’re often also the party whose admin accounts sit closest to every client’s backups.

What CIR 4.2.2 actually says: the clauses that decide the Microsoft 365 question

In plain terms: three of the six required elements in a CIR backup plan bite hard on Microsoft 365: cloud data must be covered, copies must sit outside “the same network”, and backup access must be controlled separately.

Point 4.2.2 opens: “Based on the results of the risk assessment carried out pursuant to point 2.1 and the business continuity plan, the relevant entities shall lay down backup plans which include the following”. The three points that matter here read, verbatim:

• (b) “assurance that backup copies are complete and accurate, including configuration data and data stored in cloud computing service environment;”
• (c) “storing backup copies (online or offline) in a safe location or locations, which are not in the same network as the system, and are at sufficient distance to escape any damage from a disaster at the main site;”
• (d) “appropriate physical and logical access controls to backup copies, in accordance with the asset classification level;”

Two details are easy to miss. First, point (c) carries no “where appropriate” qualifier, so Article 2(2)’s documented-reasoning route for opting out doesn’t apply to it. The risk-assessment opening of 4.2.2 still shapes how you implement it. Second, “(online or offline)” means the CIR doesn’t require an offline copy. Some backup guides present an offline copy as mandatory. The text doesn’t.

Two neighbouring points complete the picture. Point 4.2.3 requires “regular integrity checks on the backup copies”, and point 4.2.6 requires regular recovery testing, with documented results and corrective action “where needed”. Point 4.3 is crisis management, not recovery testing. The two often get confused.

“Not in the same network”: what the clause means when you don’t own a network

In plain terms: the CIR never defines “network” here. For a SaaS tenant, the most defensible reading is that the backup must not share the failure and compromise domain of the system it protects. That covers both the infrastructure and the admin accounts that can reach it.

The Directive’s definition of “network and information system” in Article 6(1) covers three things: an electronic communications network, “any device or group of interconnected or related devices” that process digital data, and the data itself. Point (c) says “the same network as the system”, and that gives two plausible readings:

1. Topology reading. “Network” means a communications network. The copy must not sit on the same LAN or segment as production. For Microsoft 365 customers this reading is almost empty, because you don’t operate Microsoft’s network. It would make the clause pointless for SaaS, which is hard to square with point (b) naming cloud data in the same list.
2. Compromise-domain reading. The clause targets what kills backups in practice: an attacker or failure that reaches production and the copies through the same path. For a tenant, that path is the identity plane (Entra ID, the Global Administrator role, the backup admin role) as much as any cable.

Point (c) already handles physical disasters separately, through its “sufficient distance” wording. That makes the “same network” words most useful as a guard against shared compromise, which supports the second reading. ENISA’s technical implementation guidance lists “Backups are physically separated from the systems that generated them” as evidence under 4.2.1. It also lists logs “confirming that one copy of the backup is stored off-site, such as in a cloud storage service or a remote data centre”.

Be clear about the status of this: it’s our interpretation. No authority or court has ruled on how “same network” applies to SaaS tenants, and ENISA’s guidance is non-binding. If your auditor takes the narrower topology reading, native backup may pass. Under the broader reading, the next section shows where it stands.

Testing each Microsoft 365 recovery feature against 4.2.2(c)

In plain terms: recycle bins, versioning, retention policies and geo-replication are resilience features, not backup copies in a separate location. Native Microsoft 365 Backup is a real backup, but it stays inside Microsoft’s trust boundary and your tenant’s admin plane.

When we read Microsoft’s architecture note against the CIR text, one sentence decided the analysis. The Microsoft 365 Backup overview states: “Data never leaves the Microsoft 365 data trust boundary and honors the geographic locations of your current data residency.” It also says the product creates “backups within the protected services’ data boundaries”. Microsoft presents that as a speed advantage, and it is. It’s also the point where the “same network” question starts.

Mechanism	What it is (Microsoft’s figures)	Shares tenant and admin plane?	Our read against 4.2.2(c)
SharePoint/OneDrive recycle bins	Deleted items kept 93 days	Yes. It’s the same data in the same service.	Not a backup copy. Weak.
Versioning and Files Restore	Roll a library back to any second in the last 30 days	Yes	Point-in-time recovery inside the system. Weak.
Purview retention policies	Hold or delete content for compliance	Yes	A records tool, not a recovery copy. Weak.
Microsoft’s geo-replication	Each SharePoint file written to a primary and a secondary region at the same time	Yes, and it’s Microsoft-operated	Covers “distance” for site disasters. A replica mirrors deletions and encryption, so it doesn’t meet the “separate copy” intent. Weak.
Native Microsoft 365 Backup	Append-only. Recovery window of 3 months to 2 years (existing policies default to 1 year). $0.15 per GB per month.	Yes. It stays within the trust boundary and is run from the same tenant.	A real backup with strong tamper resistance. Arguable on “same network”. Pair it with another copy.
Partner app built on Microsoft 365 Backup Storage	Third-party interface on the same Microsoft storage platform	Mostly yes	Same boundary as native. Ask the vendor where the copies physically live.
Third-party backup to independent storage	Copy lands in a separate cloud account or provider, with separate credentials	No, if the credentials are truly separate	Strongest online option.
Export to offline or customer-held media	Periodic export to storage you control	No	Meets the text. The cost is restore speed and testing effort.

The recycle bin, Files Restore and replication figures come from Microsoft’s SharePoint and OneDrive data resiliency documentation. The same page notes that SharePoint APIs can skip the recycle bin and force an immediate delete. A compromised admin account doesn’t have to wait 93 days.

Native backup deserves a fair hearing, because its controls are better than most people assume. Microsoft documents append-only storage. Purview retention and deletion policies can’t shorten the backup recovery window. Restore points come every 10 minutes for the prior two weeks on OneDrive and SharePoint, then weekly out to 52 weeks. There’s an optional multi-admin email alert for potentially harmful actions. The gap is a single sentence: “The backups are immutable unless expressly deleted by the Backup tool admin via product offboarding.” A 90-day grace period follows offboarding. Even so, the account that can trigger it lives in the same Entra ID tenant an attacker is trying to take over. That’s the shared compromise domain the second reading targets.

Snapshots and replicas beyond Microsoft 365

In plain terms: the same test applies to Azure, AWS or on-premises virtualisation. Ask whether the copy shares the system’s admin credentials and whether it mirrors changes automatically.

• Same-subscription snapshots. A VM or disk snapshot stored in the same subscription, under the same admin roles, fails the compromise-domain test for the same reason native Microsoft 365 Backup is arguable. Anyone who can delete the VM can usually delete its snapshots.
• Replicas. Synchronous or near-real-time replication is built to copy every write, including a ransomware encryption pass. It answers “distance” and recovery-time needs under 4.2.2(a), not “separate copy”.
• Cross-account vaults. Copies pushed to a separate account, with their own credentials and deletion protection, fit both readings of point (c).

ENISA’s guidance points the same way for cloud-hosted backups. Its tips suggest replication “across multiple availability zones or … an alternate region”, the 3-2-1 rule, immutable backups and offline storage, and storing encryption keys separately from the backup data. These tips are good practice, not CIR obligations. The 3-2-1 rule in particular appears nowhere in the CIR text.

What 4.2.2(b) adds: cloud data and configuration data are in scope

In plain terms: the CIR rules out the “Microsoft looks after our data” assumption, and Microsoft’s own responsibility model agrees.

Point (b) names “data stored in cloud computing service environment” and “configuration data” in the same breath. Microsoft’s shared responsibility model lists customer data, configurations and settings, and identities and users as the customer’s responsibility for SaaS. Microsoft runs the infrastructure. Whether your copies are complete is your problem.

Native Microsoft 365 Backup covers SharePoint sites, OneDrive accounts and Exchange mailboxes. Tenant configuration isn’t in that documented scope: Entra ID objects, Conditional Access policies, Intune profiles, Exchange transport rules. Rebuilding Conditional Access from memory after an incident is exactly the “complete and accurate” failure point (b) describes. Cover configuration with a separate export or tool, and list it in the backup plan. For how these Microsoft 365 controls line up with the other Article 21(2) measures, see our Microsoft 365 feature mapping to Article 21(2).

Who does what: a role-by-role plan

Role	Action	CIR anchor	Effort
IT / security manager	Keep native backup for fast restores. Add one copy outside the tenant, in a separate account with credentials no production admin holds.	4.2.2(c), (d)	Medium
IT / security manager	Turn on alerts for backup deletion, policy changes and offboarding. Log access to backup configuration.	3.2.3(f), 4.2.2(d)	Low
IT / security manager	Export tenant configuration (Entra ID, Conditional Access, Intune) on a schedule.	4.2.2(b)	Medium
Compliance officer	Write down which reading of “same network” you’ve adopted and why, and get it signed off.	4.2.2, Article 2(2)	Low
Compliance officer	Schedule restore tests from each copy and record results and corrective actions.	4.2.6	Medium
SME owner / management body	Approve the budget for the second copy, and accept or reject the residual risk of relying on native backup alone, in writing.	Article 21(2)(c); 4.2.2	Low

The UK National Cyber Security Centre’s principles for ransomware-resistant cloud backups are a useful design check for the “separate credentials” row. They’re not EU law, but they’re specific. Principle 2 asks that “it isn’t possible for an attacker to deny all customer access”. Principle 5 wants alerts raised on privileged actions “whether the attempts are successful or not”. A backup admin role held by the same people who hold Global Administrator fails principle 2’s intent.

On test frequency, the CIR says only “regular”. ENISA gives an example: weekly checks for data of high criticality and monthly for moderate and low, tied to your risk assessment. Treat that as a starting point, not a rule. For setting the recovery targets those tests prove, see our guide to backup recovery requirements and RPO/RTO targets.

Evidence an auditor can ask for

• A backup plan that addresses 4.2.2 (a) to (f) and names Microsoft 365 workloads and tenant configuration explicitly
• A written note on where each copy lives, who can delete it, and which reading of “same network” it relies on
• Role assignments showing backup admins are separate from production Global Administrators
• Alert configuration and a sample alert for a backup policy change
• Restore test records from each copy, with timings measured against your recovery objectives (4.2.6)
• Integrity-check records (4.2.3), such as reports from the backup tool
• Retention periods with their business or regulatory basis (4.2.2(f))

The backup plan sits inside your wider continuity programme. Our NIS2 business continuity requirements guide shows how 4.2 connects to the business impact analysis and continuity plan that point 4.2.2 builds on. If you also need to know when a Microsoft outage becomes your reportable incident, read cloud provider outage reporting.

Frequently asked questions

Is Microsoft 365 Backup NIS2 compliant?

No product is “NIS2 compliant” by itself. Compliance is a property of your measures and your documentation. Native Microsoft 365 Backup can support points 4.2.2(a) and (e), recovery times and restoring, very well. On 4.2.2(c), its copies stay inside Microsoft’s trust boundary and your tenant’s admin plane, so relying on it alone is arguable rather than settled.

Doesn’t Microsoft already back up our data?

Microsoft replicates data for its own service resilience and keeps short internal windows, such as 14 days of SharePoint metadata backups. Its responsibility model still assigns customer data and configuration to you, and CIR 4.2.2(b) names cloud-stored data explicitly.

Is an offline or air-gapped copy mandatory?

Not under the CIR text, which says “(online or offline)”. An offline copy is one way to meet the separation and access-control points, and ENISA lists offline storage as a good-practice tip.

Does geo-redundancy satisfy the “sufficient distance” requirement?

It can help with distance. A replica that mirrors every change isn’t a separate backup copy, though, so it doesn’t settle the “same network” point on its own.

We’re an MSP. Do we need a different answer for each client?

The binding duty applies to your own systems as a relevant entity. Clients in scope will also ask how their copies are separated from your admin accounts, so document that per tenant.

Sources

1. Commission Implementing Regulation (EU) 2024/2690 of 17 October 2024. EUR-Lex, Official Journal text. Articles 1, 2(1) and 2(2); Annex points 3.2.3(f), 4.2.1, 4.2.2(a)–(f), 4.2.3, 4.2.6 and 4.3.
2. Directive (EU) 2022/2555 (NIS2 Directive). EUR-Lex. Articles 6(1) and 21(2)(c).
3. Technical Implementation Guidance on cybersecurity risk-management measures, version 1.0. ENISA, June 2025. Guidance, evidence examples and tips under Annex points 4.2.1–4.2.6 (pp. 56–60).
4. Overview of Microsoft 365 Backup. Microsoft Learn, updated September 2026.
5. SharePoint and OneDrive data resiliency in Microsoft 365. Microsoft Learn, Microsoft Service Assurance.
6. Shared responsibility in the cloud. Microsoft Learn, updated August 2026.
7. Principles for ransomware-resistant cloud backups. UK National Cyber Security Centre, 22 November 2024.