Microsoft handed Dutch civil servants’ names to the U.S. House of Representatives. No court order. No judicial review on European soil. Just a statute that overrides every contractual assurance you’ve ever been sold.

Last month, Vrij Nederland broke a story that should be circulating in every CISO briefing room in Europe. Microsoft, compelled by a U.S. House of Representatives investigation, handed over emails, minutes, and meeting invitations belonging to Dutch civil servants working at the ACM (Authority for Consumers and Markets) and the AP (Dutch Data Protection Authority). Their names were not redacted. They were working on Digital Services Act enforcement. The U.S. government considers that work censorship. And so it demanded — and received — the data.

No Dutch court was involved. No European regulator gave sign-off. No data processing agreement clause protected anyone. The CLOUD Act simply applied, and Microsoft complied.

The Clarifying Lawful Overseas Use of Data (CLOUD) Act — signed into U.S. law in 2018 — requires any U.S.-incorporated technology provider to hand over data stored anywhere in the world when the U.S. government demands it. Jurisdiction follows the provider, not the server.

The Safe Harbor problem

When European organisations procure U.S. cloud services, they are routinely assured of compliance with EU data protection law. Data Processing Agreements. Standard Contractual Clauses. EU data residency options. “Your data stays in Europe.” All of it is technically accurate — and all of it is beside the point.

The CLOUD Act does not care where the data sits. It does not recognise SCCs. It is not constrained by GDPR. It reaches through every contractual wrapper and attaches directly to the provider’s U.S. corporate identity. If the provider is American, the data is reachable — regardless of geography, regardless of encryption commitments, regardless of the sovereign cloud marketing language on the product page.

The Dutch case is blunt proof. The civil servants affected weren’t storing sensitive personal data in a consumer app. They were EU regulatory professionals, working on EU law enforcement, whose names appeared in work emails and calendar invitations. That metadata — banal, routine — became a surveillance instrument the moment it touched a U.S.-incorporated platform.

This is not a hypothetical for Ireland

Ireland hosts the European headquarters of most major U.S. cloud and technology providers. The Central Bank, as DORA’s domestic supervisor for financial entities, expects ICT risk management — including supply chain and third-party concentration risk — to be demonstrably addressed. NIS2, now transposed into Irish law via the 2024 Network and Information Security Regulations, places binding obligations on operators of essential services. The CyFun framework referenced by the NCSC gives you a maturity model. None of it resolves the CLOUD Act problem.

If your backup, your email, your collaboration tooling, or your document management system runs on a U.S.-incorporated platform, the jurisdictional exposure is real. The HSE ransomware attack in 2021 laid bare what happens when resilience is assumed rather than engineered. The December 2025 Office of the Ombudsman incident showed that the attack surface remains live. The Dutch story adds a different dimension: the threat is not only ransomware. It is quiet, lawful, unilateral access by a foreign government with its own interests.

What true data sovereignty requires

True data sovereignty is not a data centre postcode. It is jurisdictional independence. It means the entity operating your infrastructure is not subject to extraterritorial legal compulsion from a foreign power — and that you have the contractual, technical, and operational controls to verify that claim.

In practice, that means asking harder questions about your cloud and backup providers than most procurement processes currently require:

Is your provider incorporated in the EU — and only in the EU? Do your contracts contain notification clauses obliging disclosure if a foreign government demands your data? Is your backup environment — including metadata — stored on infrastructure that is genuinely outside U.S. jurisdiction? Can you demonstrate this to your regulator, your insurer, and your board?

Backup deserves specific attention here. Backup data is, by definition, a comprehensive copy of your operational environment. It contains everything — files, emails, calendar data, user metadata, configuration. If your primary environment is scoped to EU-sovereign infrastructure but your backup replicates into a U.S.-incorporated cloud, the sovereign posture of your primary environment is academic.

The regulatory clock is running

DORA’s ICT third-party risk requirements include supply chain mapping, concentration risk assessment, and exit planning. NIS2 requires a proportionate, demonstrable approach to supply chain security. GDPR’s Chapter V restrictions on international transfers have not gone away — and “we use an American provider with EU data residency” has always been a weaker argument than its proponents acknowledged.

The Dutch incident gives every European DPO, CISO, and board member a concrete, newsworthy example of what the abstract regulatory language actually describes. Use it. The conversation about jurisdictional risk is no longer theoretical — it happened, in May 2026, to the regulator responsible for enforcing data protection law.

State Secretary Aerdts told the U.S. Ambassador directly: “If you have a problem, fight it out with us — not against the backs of civil servants.” That is the right instinct. But instincts don’t protect data. Architecture does.

The Netherlands is now actively pursuing digital sovereignty — deals with European cloud providers, university-government partnerships to reduce Big Tech dependency. Ireland should be watching closely. The question is not whether this can happen to Irish public sector or regulated private sector data. The question is whether it already has, and whether anyone would know.

What to do now

Audit your third-party and backup providers for U.S. incorporation status. Review your DPAs for foreign government access notification clauses. Map your backup data flows with the same rigour you apply to your primary environment. Brief your board on CLOUD Act exposure as a named risk — not as a vendor footnote, but as a boardroom item. And if your current architecture cannot support a credible answer to “could a foreign government access this data without our knowledge?”, treat that as a gap that needs closing before your next regulatory engagement.

Safe Harbor was struck down once before — in Schrems I, in 2015 — precisely because European courts found it could not protect against U.S. surveillance law. The CLOUD Act is a newer instrument, but the structural problem is identical. Contractual frameworks cannot override statute. Geography is not jurisdiction. And vendor assurances are not the same as verified, auditable sovereign control.

Build accordingly.

Ireland has had a rough few years as a target.

The HSE attack in 2021 cost an estimated €600 million to recover from, took four months to fully remediate, and became one of the most referenced ransomware case studies in the world. In December 2025, the Office of the Ombudsman was hit by a financially motivated ransomware attack that forced all systems offline, disrupted six connected public bodies, and triggered simultaneous notifications to the NCSC, An Garda Síochána, and the Data Protection Commissioner. A survey published in February 2026 found that 80% of Irish workers had personally experienced a cyberattack or security incident at work in the past twelve months.

Ireland is not an incidental target. It is a consistent one.

Against that backdrop, cyber insurance has moved from a nice-to-have to a board-level priority for Irish organisations across sectors. But the market has changed significantly. Insurers lost heavily on ransomware claims between 2020 and 2024 — and a lot of that money went to organisations that, it turned out, had overstated their security controls on the application.

The response has been a shift from self-attestation to evidence-based underwriting.

Carriers are no longer asking whether you have controls. They are asking you to prove it. And if a claim is made and the forensic review finds something different from what was on the application, the claim gets denied.

That shift has very specific implications for backup architecture. If you’re heading into a renewal without understanding what underwriters are actually looking for, you may be walking into a gap you didn’t know you had.

The Irish Regulatory Context Makes This More Complicated

Most cyber insurance conversations in Ireland are happening against a backdrop of overlapping regulatory obligations that directly shape what underwriters expect to see.

DORA came into force in January 2025 and applies directly to Irish financial entities and their ICT providers — without the need for national transposition. The Central Bank of Ireland is the supervisory authority. DORA’s requirements around ICT risk management, operational resilience testing, third-party dependency mapping, and incident reporting are prescriptive, and backup architecture sits squarely within scope. For any Irish financial services organisation, or any technology provider serving one, DORA compliance and cyber insurance requirements are now effectively the same conversation.

NIS2 is a more complicated picture. Ireland missed the EU transposition deadline of October 2024. The European Commission issued a reasoned opinion for failure to transpose in May 2025. The NCSC has published draft Risk Management Measures (RMM) and a Cyber Fundamentals (CyFun) framework in the interim, but full legislative implementation is still in progress. That creates an awkward position: the directive’s obligations exist at EU level, Irish organisations in scope are aware of them, but domestic enforcement machinery is not yet fully in place. Insurers operating in the Irish market are well aware of this gap — and are not waiting for it to close before incorporating NIS2-aligned control expectations into their underwriting assessments.

GDPR enforced by the Data Protection Commission adds a further layer. Ireland is home to the European headquarters of many of the world’s largest technology companies, which means the DPC is one of the most active data protection authorities in Europe. For Irish organisations, the obligation to report a breach to the DPC within 72 hours is not theoretical. The Ombudsman attack involved simultaneous notification to the DPC, NCSC, and An Garda on the day of confirmation. Insurers factor this reporting risk into their underwriting.

The practical result for Irish IT and security teams is that a cyber insurance renewal is no longer just a procurement question. It sits at the intersection of insurance, regulatory compliance, and security architecture.

What Underwriters Are Now Looking For in Backup Specifically

Backup has always appeared on cyber applications. But the questions have become far more specific — and the evidence requirements have hardened.

1. Immutability — and Proof It’s Actually Enforced

Immutable backups are now a near-universal requirement across major carriers. But “we have immutability enabled” is no longer sufficient.

Underwriters want to understand whether immutability is genuinely enforced or simply configured in name. The distinction matters because immutability flags can be set while admin accounts retain the ability to bypass them. Object lock can be enabled without proper retention governance. Hardened Linux repositories can still be compromised if SSH is open and credentials are shared.

What they want to see:

• Configuration screenshots or documentation of Object Lock or immutability settings
• Evidence of hardened repository architecture — separate credentials, no domain join
• Confirmation that retention periods are enforced at the storage layer, not just at the backup application level

For Irish organisations under DORA or in-scope for NIS2, immutability is also a regulatory expectation, not just an insurance one. The two are converging.

2. Tested Backups — Not Just Running Backups

Green backup jobs are not the same as working recovery.

Underwriters are now explicitly treating untested backups as non-existent for underwriting purposes. The requirement that has emerged across multiple carrier frameworks is evidence of a restore test within the past twelve months — and ideally more frequently.

What they want to see:

• Documented restore test results with dates, scope, and outcomes
• Evidence that the test covered more than a single VM or handful of files
• Confirmation that the restore was validated for application functionality, not just file presence

The HSE incident is instructive here. The post-incident review found that backup systems existed but the scale and complexity of recovery was far beyond what had been planned or tested for. Untested recovery is, in practice, untested trust.

Your backup test records are now a policy document. If you don’t have them, you don’t have evidence.

3. Backup Isolation and Credential Separation

This is the area where many otherwise well-designed backup environments quietly fail the underwriting test.

The question underwriters are increasingly asking isn’t just “are your backups immutable?” It’s “can your backups survive a full production identity compromise?”

Modern ransomware operators actively target backup infrastructure as part of the attack. If backup admin access shares the same identity plane as production, compromising production effectively means compromising the backups. This pattern appeared in the HSE attack, where attackers had been operating undetected for eight weeks before deploying ransomware — more than enough time to identify and compromise backup systems.

What they want to see:

• MFA enforced on backup management consoles — not just on email and VPN
• Privileged access management evidence for backup admin accounts
• Network segmentation documentation showing backup infrastructure is isolated
• Confirmation that backup service accounts follow least-privilege principles and are not domain-joined

4. Offline or Air-Gapped Copies

Most underwriting checklists now specifically ask about offline or air-gapped backup copies — separate from immutable cloud or disk-based backups.

The logic is straightforward: immutable cloud backups are strong, but they depend on the API plane remaining accessible and the cloud account remaining uncompromised. An air-gapped or offline copy provides a recovery path that is genuinely independent of any connected infrastructure.

For Irish organisations with data sovereignty obligations under GDPR or DORA, there is an additional consideration: where is that offline copy physically located, and what jurisdiction applies? An air-gapped copy held in EU infrastructure with Irish-controlled access is a different proposition from one sitting in a hyperscaler region with foreign-held encryption keys.

What they want to see:

• Evidence of a backup copy that is offline, tape-based, or fully isolated from the network
• Retention policy documentation showing the offline copy is maintained at regular intervals
• Confirmation that access to the offline copy is governed separately from production credentials

5. Recovery Time Objectives — and Evidence They’re Achievable

Underwriters are beginning to probe not just whether data is backed up, but whether recovery objectives are realistic and have been validated.

The gap between stated RTO confidence and actual recovery performance in ransomware incidents has become well documented. Global research consistently shows that a large majority of organisations believe they will hit their RTOs, while actual full recovery rates during ransomware incidents are far lower. When organisations claim a four-hour RTO but the forensic review of a claim shows a three-week recovery, that gap becomes a coverage dispute.

For Irish organisations, this has a specific dimension. The HSE’s independent post-incident review documented a recovery process that took four months to fully complete, with hospital systems reverting to pen and paper in the interim. That is the real-world benchmark that Irish insurers have in mind when they ask about recovery objectives. Documenting an RTO without a credible, tested plan to back it up is a risk.

What they want to see:

• Documented RTOs and RPOs
• Evidence those objectives have been tested under realistic conditions
• Confirmation that recovery includes identity and application dependencies, not just raw data restoration

The Controls That Appear Alongside Backup on Every Application

Backup doesn’t exist in isolation on a cyber insurance application. Underwriters evaluate it as part of a broader control picture. The controls that consistently appear alongside backup requirements — and that carriers treat as a package — are:

MFA across all privileged access. Not just email. VPN, RDP, backup consoles, cloud management planes, and admin accounts. Partial MFA implementation is treated as no MFA for underwriting purposes. One Irish insurer contact recently described this as the single most common cause of policy denial in the current market.

Endpoint Detection and Response. Legacy antivirus is no longer accepted. Carriers want EDR deployed on endpoints and servers, with active monitoring and documented agent coverage reporting.

Privileged Access Management. Standing admin privileges are a red flag. Underwriters want evidence of time-limited elevation, least-privilege enforcement, and separated admin and daily-use accounts.

Documented Incident Response Plan. Not a theoretical plan — a documented, tested IR playbook with vendor contacts, escalation paths, and tabletop exercise records. Under DORA, financial entities are required to test operational resilience on a continuous basis. Insurers are aligning to the same expectation.

The Regulatory Convergence Is Doing Some of the Work for You

One piece of genuinely good news for Irish organisations: if you are building toward NIS2 or DORA compliance, you are largely building toward cyber insurance compliance at the same time.

NIS2 requires organisations to implement backup management as part of ICT risk management obligations. It requires business continuity testing. It requires supply chain security evaluation. It requires incident response capability. DORA goes further still for financial entities, with mandatory resilience testing including full operational recovery simulations.

The controls that satisfy these regulatory frameworks are, with very few exceptions, the same controls that underwriters are asking you to evidence on a renewal application.

The organisations that struggle with renewal are typically the ones treating insurance and compliance as separate workstreams. They are not separate. In Ireland in 2026, they are the same conversation.

The Part Nobody Tells You About Claims

The shift in underwriting posture has a direct implication for claims.

Carriers are now conducting forensic reviews post-incident that specifically compare the controls attested to on the application against what actually existed at the time of the breach. Where material misrepresentations are found, claims are being denied.

The practical risks for backup specifically:

• Attesting to immutability that isn’t properly enforced at the infrastructure level
• Claiming tested backups when restore tests haven’t been documented
• Stating that backup credentials are isolated when they share the production identity domain
• Confirming offline copies exist when they haven’t been maintained or tested

These aren’t edge cases. They are the areas where backup architecture most commonly diverges between what looks good on paper and what actually holds up under adversarial conditions.

For Irish organisations that have experienced a breach and notified the DPC, NCSC, and An Garda — as the Ombudsman’s office was required to do — the insurer’s forensic team will be working through those same notification records. Everything you have documented, and everything you have not, will be visible.

What to Do Before Your Next Renewal

The same steps that make your backup architecture genuinely resilient also make your insurance application easier to defend.

Document everything. Restore tests, immutability configurations, credential isolation, retention policies, recovery exercise outcomes. If it exists but isn’t documented, it doesn’t exist for underwriting purposes. This applies equally to your DORA and NIS2 compliance evidence.

Test recovery, not just backup. A restore test that validates application functionality, includes identity recovery, and is conducted under realistic load is worth more on a renewal application than a year of green backup job status reports.

Harden backup credentials independently. MFA on backup consoles, isolated admin accounts, no shared identity with production. This is increasingly a direct question on underwriting questionnaires — and the answer needs to be backed by evidence.

Maintain an offline copy and keep it current. One genuinely air-gapped or offline copy, maintained regularly, documented, and tested. Consider where it is physically located and what jurisdictional controls apply — relevant for both insurance and GDPR purposes.

Be accurate on the application. This sounds obvious. But the gap between what organisations believe is in place and what forensic review finds has been the source of most significant claim disputes in recent years. If a control isn’t fully implemented, say so — and document the remediation plan. Misrepresentation on the application is the fastest way to a denied claim after a breach.

Final Thought

Cyber insurance used to be something the procurement team handled. Backup teams rarely saw the application.

That has changed.

Ireland’s threat profile, the combined weight of GDPR, DORA, and incoming NIS2 obligations, and a hardened global insurance market have made cyber insurance renewal a genuinely technical exercise — one that requires IT and security teams to be directly involved.

The questions underwriters are now asking about immutability, credential isolation, restore testing, and recovery objectives are backup architecture questions. The evidence they want is the same evidence that good backup hygiene should already be producing.

If your backup environment has never been reviewed against a current underwriting checklist, there’s a reasonable chance the renewal conversation is going to surface gaps that neither you nor your broker expected.

Better to find them now than at 2am when the incident is already in progress.

I had a client reach out last week asking for an RTO on their M365 backups. For years the concern around M365 data protection was all about coverage, storage efficiency and immutability. but this was the first time I was challenged with the question of “if disaster strikes and my tenant gets wiped out, how long am I down for?” My initial reaction was “how long is a piece of string”? But it sent me down the rabbit hole of recovery speed….

Many organisations assume that if their Microsoft 365 data is backed up, they can restore it quickly after a ransomware attack, accidental deletion, or tenant-wide compromise. In reality, recovery times are often constrained by Microsoft’s own API throttling limits.

And during a disaster, that can turn a planned four-hour recovery objective into a multi-day recovery operation.

The Problem: Backup Is Fast. Restore Is Slow.

Most third-party Microsoft 365 backup platforms rely heavily on the Microsoft Graph API, Exchange Web Services (EWS), and SharePoint Online APIs to extract and restore data.

Microsoft deliberately throttles these APIs to protect the stability of its shared SaaS infrastructure. The platform applies both global and service-specific limits across Exchange Online, SharePoint Online, OneDrive, and Teams.

When backup vendors hit these limits, Microsoft returns HTTP 429 (“Too Many Requests”) responses and forces the application to pause and retry later. Microsoft explicitly states this behaviour is built into the platform and cannot generally be disabled.

In day-to-day operations, throttling is manageable. Incremental backups and occasional mailbox restores usually complete without major issues.

During a large-scale recovery, however, the limitations become painfully visible.

Why Disaster Recovery Changes Everything

A disaster recovery scenario creates exactly the type of workload Microsoft throttling is designed to suppress:

• Massive parallel restore operations
• Millions of SharePoint and OneDrive file writes
• Large Exchange mailbox restores
• Permission and metadata recreation
• Version history reconstruction
• Teams and collaboration object recovery

The bottleneck is no longer bandwidth or storage performance.

It becomes API transaction allowance.

One Microsoft Q&A response regarding large SharePoint restores using Veeam stated plainly that throttling during large-scale restores is “normal and unavoidable.”

This creates an uncomfortable reality:

Your backup platform may technically work perfectly while still failing your recovery time objectives.

The SharePoint and OneDrive Problem

SharePoint Online and OneDrive are especially challenging because restores involve huge numbers of individual object operations rather than large sequential data streams.

A 5 TB SharePoint restore containing millions of small files can take dramatically longer than expected because the restore speed is governed by:

• API call limits
• Object count
• Metadata operations
• Version reconstruction
• Permission reapplication

Not raw throughput.

Community discussions across Reddit and Microsoft forums consistently describe SharePoint restores “crawling” under throttling pressure during large recoveries.

Why Vendors Rarely Lead With This

Backup vendors understandably market:

• retention features
• ransomware detection
• unlimited storage
• Teams backup
• immutable repositories

But few prominently publish:

• full-tenant restore benchmarks
• worst-case RTOs
• API dependency limitations
• tenant-scale recovery modelling

That omission matters.

In a real incident, the question is not:

“Do you have backups?”

It becomes:

“How long until 40 TB of collaboration data is actually usable again?”

Those are very different conversations.

Microsoft’s Own Backup Strategy Changes the Equation

Microsoft itself appears to recognise this limitation.

Its newer Microsoft 365 Backup architecture introduces native backup and restore APIs with significantly faster recovery capabilities than traditional Graph-based approaches.

Industry discussions frequently distinguish between:

• traditional API-based backup methods
• Microsoft-native “Express” style restores

The latter can avoid many of the throttling constraints affecting conventional backup vendors.

This is an important shift because it effectively acknowledges that conventional SaaS API restore mechanisms are not always suitable for mass recovery scenarios.

Alternative Approaches Organisations Should Consider

1. Native Microsoft 365 Backup Integrations

Some vendors now integrate directly with Microsoft’s newer backup framework instead of relying entirely on Graph APIs.

These solutions may offer:

• dramatically faster restores
• reduced throttling exposure
• improved tenant-scale recovery
• higher throughput during ransomware events

However, they can also involve:

• higher licensing costs
• feature trade-offs
• reduced portability

2. Hybrid Recovery Architectures

Some organisations are moving toward layered protection models:

• traditional SaaS backup for granular restores
• native Microsoft backup for large-scale disaster recovery
• offline or isolated exports for worst-case scenarios

This avoids relying on a single recovery mechanism.

3. Recovery Isolation

Another emerging concern is identity dependency.

Many Microsoft 365 backup platforms authenticate directly against the same Entra ID tenant they are protecting. In a major compromise, attackers targeting identity infrastructure may simultaneously impact:

• production access
• administrative control
• backup platform access

Security architects are increasingly prioritising:

• isolated credentials
• cross-tenant recovery
• independent management planes
• out-of-band administrative control

Community discussions increasingly highlight this as a major design consideration.

4. Real Recovery Testing

The only meaningful validation is:

• large-scale restore testing
• realistic ransomware simulation
• tenant-wide recovery exercises
• SharePoint-heavy restore validation

Not theoretical vendor datasheets.

Ask vendors:

• What is the largest tenant restore they have documented?
• What are real-world SharePoint restore rates?
• How does throttling impact recovery?
• What dependencies exist on the customer tenant?
• Can restores occur into alternate tenants?
• What happens if Entra ID is compromised?

These answers matter far more than backup storage pricing.

Final Thought

Microsoft 365 backup discussions often focus on whether data is recoverable.

The more important question is whether it is recoverable fast enough to matter.

API throttling has quietly become one of the biggest constraints in Microsoft 365 disaster recovery — particularly for SharePoint Online, OneDrive, and tenant-scale ransomware recovery scenarios.

As SaaS estates continue growing, organisations need to evaluate backup platforms not just as storage systems, but as recovery execution platforms.

Because in a real disaster, recovery speed is the product.

Data Sovereignty After NIS2 and DORA: What Backup Teams Need to Know

For years, backup strategy was primarily driven by cost, recovery speed, and storage efficiency.

Today, that’s no longer enough.

Across Europe, regulations like the EU’s NIS2 Directive and the Digital Operational Resilience Act (DORA) are reshaping how organisations think about resilience, operational risk, and — critically — data sovereignty.

For backup and recovery teams, this marks a significant shift.

The conversation is no longer simply:
“Can we recover the data?”

It is increasingly:

• Where is the data stored?
• Who can access it?
• Which legal jurisdiction applies?
• How resilient is the service provider?
• And can we prove operational recoverability under regulatory scrutiny?

Backup infrastructure has become part of the compliance perimeter.

Why Data Sovereignty Suddenly Matters More

Data sovereignty is not a new concept. But NIS2 and DORA have elevated it from a legal or procurement concern into an operational resilience issue.

That distinction matters.

Organisations are now expected not only to protect data, but also to understand:

• where critical systems and backups reside,
• how third-party providers operate,
• and what happens if those providers fail, suffer outages, or fall under foreign jurisdictional pressures.

For many organisations, especially those heavily invested in global cloud platforms, that creates uncomfortable questions.

A backup copy stored “in Europe” does not automatically mean sovereign control exists.

NIS2 Raises the Baseline for Operational Resilience

The NIS2 Directive significantly expands cybersecurity obligations across the EU, affecting sectors including:

• healthcare,
• energy,
• transport,
• digital infrastructure,
• manufacturing,
• public administration,
• and managed service providers.

One of the most important changes is accountability.

Organisations are now expected to demonstrate:

• risk management measures,
• incident response capabilities,
• business continuity planning,
• supply chain security,
• and disaster recovery preparedness.

Backups are no longer viewed as passive infrastructure. They are part of an organisation’s resilience capability.

This means backup teams must increasingly answer questions like:

• Can recovery operations continue during a supplier outage?
• Are backup credentials isolated?
• Can ransomware compromise recovery platforms?
• Are recovery procedures regularly tested?
• Is sensitive data replicated outside approved jurisdictions?

These are operational resilience questions — not just storage questions.

DORA Changes the Conversation for Financial Services

While NIS2 applies broadly, DORA specifically targets financial institutions and their ICT providers.

Its focus is clear:
financial organisations must be able to withstand, respond to, and recover from severe operational disruptions.

That includes cyberattacks, cloud outages, third-party failures, and systemic technology risks.

Under DORA, firms are expected to:

• continuously test resilience,
• assess third-party ICT risk,
• maintain robust recovery capabilities,
• and document operational dependencies.

This has major implications for backup architecture.

Financial institutions must increasingly evaluate:

• cloud concentration risk,
• dependency on single vendors,
• cross-border data replication,
• recovery testing maturity,
• and the operational resilience of backup providers themselves.

The days of treating backup storage as a simple commodity are ending.

The Cloud Sovereignty Grey Area

One of the biggest misconceptions in modern backup strategy is the assumption that regional hosting automatically guarantees sovereignty.

It often does not.

A platform may store data within the EU while still being operated by:

• a non-EU parent company,
• foreign support personnel,
• or infrastructure subject to external legal frameworks.

For regulated industries, this creates a governance challenge.

Questions increasingly being asked by security and compliance teams include:

• Who ultimately controls encryption keys?
• Can foreign entities compel access?
• Where are support operations based?
• How is metadata handled?
• What jurisdictions govern incident response operations?

Backup teams now need visibility beyond the storage location itself.

Recovery Is Becoming a Compliance Function

Historically, recovery testing was often informal or infrequent.

That is changing rapidly.

Both NIS2 and DORA push organisations toward demonstrable operational resilience:
not theoretical recovery, but proven recovery capability.

This means organisations must increasingly validate:

• recovery times under pressure,
• dependency mapping,
• ransomware recovery workflows,
• backup integrity,
• and cross-functional crisis coordination.

In practice, many organisations are discovering that recovery complexity — not backup failure — is their biggest operational weakness.

A technically successful restore does not necessarily mean the business can operate safely.

What Backup Teams Should Be Doing Now

1. Review Data Residency and Jurisdiction

Understand:

• where backups physically reside,
• who operates the platform,
• what legal jurisdictions apply,
• and how encryption keys are controlled.

2. Assess Third-Party Dependency Risk

Backup providers are now part of the operational resilience chain.

Evaluate:

• concentration risk,
• provider resilience,
• support models,
• and recovery guarantees.

3. Treat Backup Infrastructure as Critical Security Infrastructure

Protect backup systems with:

• MFA,
• privileged access isolation,
• network segmentation,
• immutable storage,
• and continuous monitoring.

4. Test Recovery Realistically

Move beyond simple restore tests.

Validate:

• identity recovery,
• application dependencies,
• operational workflows,
• and ransomware response scenarios.

5. Align Backup Strategy With Governance Teams

Backup architecture decisions now intersect with:

• compliance,
• legal,
• procurement,
• risk management,
• and executive governance.

Backup teams should be involved earlier in resilience and sovereignty discussions.

The New Reality: Backup Is Now Strategic Infrastructure

NIS2 and DORA are accelerating a broader shift already underway across Europe.

Backup is no longer just an IT operations function.

It is now directly connected to:

• cyber resilience,
• regulatory compliance,
• operational continuity,
• and organisational trust.

The organisations that adapt fastest will not simply store backups more securely.

They will build recovery strategies that are:

• operationally tested,
• jurisdictionally understood,
• resilient under pressure,
• and aligned with modern regulatory expectations.

Because in the era of operational resilience, sovereignty is not just about where data lives.

It’s about whether the organisation can still function when everything around that data goes wrong.

Immutable storage has become one of the defining technologies in modern backup strategy. And for good reason: if backup data cannot be altered or deleted, ransomware attackers lose one of their most effective tactics.

But there’s a growing problem in the way organisations talk about immutability.

Too many businesses now treat immutable backups as synonymous with cyber resilience.

They are not the same thing.

Immutability protects backup data. Cyber resilience ensures the business can recover and operate under pressure. Those are very different outcomes.

A backup platform can remain technically intact while recovery still fails.

The Dangerous Assumption

In many ransomware incidents, the issue is not that backups are missing. The issue is that recovery becomes operationally complex, delayed, or impossible within the required timeframe.

Attackers have evolved.

Modern ransomware groups increasingly target:

• privileged identities,
• orchestration systems,
• recovery infrastructure,
• authentication services,
• and operational processes.

The backup files may survive untouched. The environment around them often does not.

That distinction matters.

1. Compromised Credentials Can Defeat Recovery

Immutable storage does not protect against stolen administrative access.

If attackers compromise:

• backup admin accounts,
• API keys,
• privileged IAM roles,
• or orchestration platforms,

they may not need to delete backup data at all.

Instead, they can:

• disable jobs,
• alter retention policies,
• revoke access,
• destroy catalogues,
• or sabotage recovery workflows before encryption even begins.

In many incidents, organisations only discover this during recovery.

Resilience takeaway

Protect backup infrastructure like a Tier 0 security system:

• enforce MFA everywhere,
• isolate privileged access,
• use separate identity domains where possible,
• continuously monitor for abnormal admin behaviour.

2. Poisoned Backups Are Becoming More Common

A backup can be immutable and still be unusable.

Attackers increasingly dwell inside environments for weeks before triggering ransomware. During that time, corrupted data, dormant malware, or malicious configuration changes can silently replicate into protected backups.

When recovery starts, organisations face a second crisis:
Which restore point is actually safe?

Without validation and testing, immutability may simply preserve compromised data permanently.

Resilience takeaway

Recovery assurance matters as much as backup retention:

• automate restore testing,
• scan backups for malware,
• validate application integrity,
• maintain known-good recovery points.

3. Orchestration Failures Break Real Recovery

Restoring data is not the same as restoring services.

Modern environments depend on:

• identity systems,
• DNS,
• cloud networking,
• SaaS integrations,
• certificates,
• automation tooling,
• and application dependencies.

A technically successful restore can still leave critical systems unusable.

This is where many recovery plans fail in practice: the backup worked, but the business could not operate.

Resilience takeaway

Recovery orchestration must be tested end-to-end:

• document dependency chains,
• test full service recovery,
• validate application functionality,
• rehearse real operational scenarios.

4. Insider Threats Still Exist

Immutability is designed primarily to defend against modification and deletion. It is not a complete defence against malicious insiders or compromised operators.

An attacker with sufficient access may:

• exfiltrate sensitive backup data,
• manipulate recovery priorities,
• disrupt infrastructure,
• or intentionally delay recovery efforts.

Cyber resilience must include governance, monitoring, separation of duties, and operational controls — not just storage policies.

Resilience takeaway

Build resilience around people and process as well as technology:

• implement least privilege,
• separate operational responsibilities,
• audit recovery actions,
• continuously review access rights.

5. Recovery Complexity Is the Real Risk

The biggest challenge during a ransomware incident is rarely “Do backups exist?”

The real question is:
“How quickly can the organisation return to business operations safely?”

That involves:

• prioritisation,
• communication,
• DFIR coordination,
• legal review,
• infrastructure rebuilds,
• identity recovery,
• application sequencing,
• and executive decision-making under pressure.

Immutable storage is one component of that process — not the entire strategy.

Cyber Resilience Is an Outcome, Not a Feature

The industry often markets resilience as a product capability.

In reality, resilience is the result of:

• preparation,
• architecture,
• testing,
• operational maturity,
• and recovery discipline.

Immutable storage is essential. Every modern backup strategy should include it.

But immutability alone does not guarantee recoverability.

Organisations that succeed during major incidents are the ones that continuously test recovery, secure backup operations, validate dependencies, and treat cyber recovery as a business function — not simply a storage feature.

Because when recovery becomes real, operational resilience matters far more than marketing terminology.

For years, SaaS backup strategies were built on a simple assumption: if your data is stored in the EU, you’re compliant.

That assumption no longer holds.

In 2026, EU regulators and enterprises are converging on a more demanding reality—data sovereignty is no longer about geography alone, but about jurisdiction, control, and operational independence across the full data lifecycle, including backup.

From GDPR to a multi-layered sovereignty regime

The EU compliance landscape has evolved far beyond GDPR as a standalone framework. Today, SaaS backup and data protection strategies must align with a stack of overlapping regulations:

• GDPR – foundational rules for personal data processing and cross-border transfer restrictions
• Schrems II (C-311/18) – invalidated Privacy Shield and tightened requirements for international data transfers
• EU Data Act & Data Governance Act – expand control, portability, and access rights across cloud and SaaS ecosystems
• NIS2 Directive – raises cybersecurity and incident reporting obligations for essential services
• DORA (Digital Operational Resilience Act) – enforces operational resilience for financial services, including backup and recovery controls
• Emerging AI Act considerations – adding governance pressure where backup data intersects with model training datasets

Collectively, these frameworks mean SaaS backup is now part of the regulated control plane—not just an IT function.

As one recent analysis notes, sovereignty in 2026 is increasingly defined by “who can compel access to data, and what technical controls prevent that access even under legal obligation” rather than where data physically resides.

Why SaaS backup is now the sovereignty weak point

A recurring pattern is emerging across audits and regulatory reviews:

Production environments are compliant. Backups are not.

This is where many SaaS architectures quietly fail EU sovereignty expectations:

• Backup copies stored in non-EU jurisdictions for resilience
• Metadata or logs flowing through non-EU SaaS observability tools
• Encryption key management handled outside EU control boundaries
• Cross-region replication that is operationally convenient but legally opaque

As highlighted in recent industry guidance, organisations often assume compliance holds at the storage layer—but “compliance did not fail in production, it failed in backups.”

The sovereignty shift: from cloud location to cloud control

EU institutions themselves are now formalising this shift.

In April 2026, the European Commission awarded a €180M sovereign cloud contract designed to ensure EU entities can procure cloud services with measurable sovereignty guarantees across legal, operational, and supply-chain dimensions.

This reflects a broader trend: sovereignty is being treated as a measurable capability, not a marketing label.

In parallel, vendors are responding. For example, backup providers are now integrating EU sovereign cloud options explicitly to align backup storage with regulatory expectations around residency and control.

What “sovereign SaaS backup” actually means in practice

A compliant EU-aligned SaaS backup architecture now typically requires:

1. Data residency with enforceable jurisdiction

• EU-only storage and processing
• No uncontrolled replication outside EU legal boundaries

2. Operational sovereignty

• EU-based administration access
• Controlled support access (no extraterritorial exposure)

3. Cryptographic sovereignty

• Customer-held or EU-controlled encryption keys
• Separation of data and key custody domains

4. Backup independence from SaaS provider control plane

• Ability to restore outside the primary SaaS ecosystem
• Protection against vendor lock-in and account-level disruption

5. Auditability aligned to EU regulatory frameworks

• Evidence mapping to GDPR, DORA, and NIS2 controls
• Clear lineage of backup data flows and retention

The uncomfortable reality for SaaS vendors and MSPs

The biggest challenge isn’t technical—it’s jurisdictional ambiguity.

Even when data is stored in EU regions, legal exposure can persist depending on corporate control structures and applicable foreign laws. This has led analysts to warn that physical location alone is insufficient for sovereignty guarantees when non-EU providers remain in the control chain.

This is why procurement teams are increasingly asking a new set of questions:

• Who ultimately controls the infrastructure?
• Who can be compelled to access data?
• Can backups be restored independently of the SaaS provider?
• What happens if legal jurisdiction changes?

Conclusion: Backup is now a sovereignty control plane

SaaS backup has moved from a resilience feature to a regulatory control surface.

In the EU context, it is now directly shaped by:

• Data protection law (GDPR + Schrems II)
• Operational resilience regulation (DORA)
• Cybersecurity directives (NIS2)
• Strategic procurement policy (sovereign cloud frameworks)

The organisations that will stay ahead are those that treat backup not as a secondary copy of production data, but as a jurisdictionally governed, independently recoverable system of record.

Most organisations think ransomware is just another disaster scenario. It isn’t.

Disaster recovery vs ransomware

Disaster recovery (DR) is designed for availability failures:

• Hardware or infrastructure issues
• Power or site outages

The assumption is: your data is intact but unavailable.
So the response is speed:

• Failover
• Restore
• Resume operations

Ransomware is a security incident:

• Data may be encrypted, altered, or stolen
• Backups may be compromised
• Attackers may still have access

The assumption here is the opposite: your environment is not trustworthy.

Why MSPs don’t include DFIR in standard DR services

There’s a common expectation that backup or DR providers will “handle ransomware.” In most cases, they won’t—and that’s by design.

DFIR isn’t bundled into BC/DR services because:

• It requires specialist skills (forensics, threat intel, malware analysis)
• It involves unpredictable effort and duration, unlike structured DR workflows
• It may require legal oversight and evidence handling
• It carries significantly higher risk and liability

DR services are engineered to be repeatable, automatable, and commercially predictable.
DFIR is none of those things—it’s investigative, variable, and often business-critical in ways that extend beyond IT recovery.

As a result, DFIR is typically delivered as a separate retained or on-demand service, not something included in standard recovery contracts.

What DFIR actually is

Digital Forensics and Incident Response (DFIR) is the discipline that handles cyber incidents properly. It combines investigation, containment, and controlled recovery.

In practice, DFIR covers:

1. Containment

• Isolate affected systems
• Disable compromised accounts
• Stop lateral movement

2. Forensics

• Identify the initial access vector (phishing, RDP, exploit, etc.)
• Map attacker activity across systems
• Determine what data was accessed or exfiltrated
• Preserve evidence for legal/regulatory use

3. Eradication

• Remove malware, persistence mechanisms, and backdoors
• Reset credentials and rebuild trust in identity systems

4. Clean recovery

• Restore from known-good backups
• Rebuild into a sanitised environment, not the original compromised one

5. Post-incident hardening

• Close gaps that allowed entry
• Increase monitoring and detection

This is specialist work—different tools, different skills, often legal oversight.

The gap in most service contracts

Backup and DR services typically include:

• Restore and failover
• Recovery orchestration
• DR testing

They do not include:

• Forensic investigation
• Threat hunting
• Evidence handling
• Breach assessment or reporting

That’s because DFIR is a separate service, often delivered via retainer or on-demand engagement.

Bottom line

DR gets you back from failure.
DFIR gets you out of an attack.

If you don’t explicitly plan for both, you’re only prepared for half the problem.

Veeam released their latest Data Trust and Resilience Report this week and there’s some very interesting stats that will make for some uncomfortable reading. You can get your copy here.

There’s a lot in the report, with some very vaulable data around cyber insurance, AI and more. But the first uncomfortable statistic is that most CIOs think their DR plan is solid, but the data says otherwise.

In their latest research, 90% of leaders are confident they’ll hit their RTOs—but when ransomware actually hits, only 28% fully recover their data .

That’s not a gap. That’s a disconnect.

The Technical Problem

This usually comes down to one thing: untested recovery paths.

On paper, everything looks fine:

• Backups are running
• Jobs are green
• Replication is in place

But in a real ransomware scenario, the failure modes stack up fast:

• Backup chains are partially encrypted
• Credentials used by backup software are compromised
• Immutability isn’t actually enforced end-to-end
• Restore points exist, but aren’t clean
• Recovery throughput can’t meet RTOs at scale

And the big one:
nobody has tested a full environment rebuild under pressure.

Testing (Properly) Is Where Most Shops Fall Down

A “DR test” in many environments means:

• Restoring a VM or two
• Checking a box for audit/compliance

That’s not recovery—that’s a demo.

Real testing should look more like:

• Simulated ransomware (including credential compromise)
• Bulk restore of tier-1 systems
• Isolated recovery environments (clean room)
• Verification of data integrity, not just restore success

If you’re not testing those, you don’t know if:

• Your backups are usable
• Your sequencing works (AD, DNS, apps)
• Your RTOs are even remotely achievable

Modern Environments Make It Worse

Throw in:

• Hybrid cloud
• SaaS dependencies
• Identity as the control plane
• AI/data pipelines

Now your recovery scope isn’t just VMs—it’s:

• Identities
• APIs
• Data flows you don’t fully track

Which explains why so many recoveries fail halfway through.

The Fix Is Boring (But Rare)

The orgs that actually recover well do a few things consistently:

• Test often, and break things on purpose. Build the muscle memory!
• Validate clean restore points (not just latest)
• Use immutability + separate security domains
• Measure recovery speed, not backup success

Bottom Line

If you haven’t:

• Simulated a ransomware attack
• Rebuilt critical services from scratch
• Proven you can hit RTOs under load

…then your DR plan isn’t validated.

It’s just assumed.

And ransomware is very good at testing assumptions.

For years, organisations have trusted platforms like Veeam Software to deliver reliable backup and fast recovery. And from an operational standpoint, that trust is well placed. But modern ransomware isn’t targeting your ability to restore infrastructure—it’s targeting your ability to trust your data.
That’s the line between operational recovery and cyber recovery. And it’s where many otherwise well-designed Veeam environments start to break down.

The Industry Warning Signs
Recent industry coverage is starting to reflect what many engineers already suspect: The core issue isn’t backup failure. It’s recovery integrity under adversarial conditions.

1. The Architecture Problem: Flat Backup Domains

Typical Veeam Deployment (Operationally Optimised)

• Single Veeam Backup Server
• Domain-joined infrastructure
• Backup repositories accessible over the network
• Shared identity plane (AD integration)

This works perfectly for:

• VM restores
• File-level recovery
• DR failover

Why It Fails Under Attack

In a ransomware scenario:

• Active Directory is often compromised early
• Attackers escalate privileges → gain backup admin rights
• Backup jobs, repositories, and restore points become accessible

At that point:

• Backups can be deleted
• Immutability can be circumvented (if misconfigured)
• Restore points can be corrupted silently

👉 The issue isn’t Veeam—it’s shared trust boundaries

2. Immutability: Implementation vs Reality

Veeam supports immutability via:

• Hardened Linux repositories
• Object storage with Object Lock (S3-compatible)

But there’s a critical distinction:

“Configured Immutability”

• Flag enabled
• Retention set
• Appears compliant

“Enforced Immutability”

• No root-level tampering
• No credential reuse
• No backdoor deletion paths

Hardened Repository (What Actually Matters)

A properly secured Veeam hardened repo should include:

• Dedicated Linux host (not domain joined)
• SSH disabled or restricted
• Single-use credentials during deployment
• Immutable flag enforced via chattr +i (under the hood)
• No direct internet access
• Firewall restricted to Veeam components only

👉 If an attacker can gain root, immutability is gone.

Object Storage (S3 Object Lock)

Using S3-compatible storage with Object Lock:

• Write-once-read-many (WORM) enforcement
• Retention policies enforced at storage layer
• Protection even if Veeam is compromised

But common pitfalls:

• Object lock not enabled at bucket creation
• Short retention windows
• Same credentials used across environments

Key takeaway:
Immutability is only as strong as your identity and access model.

3. Identity: The Real Attack Surface

Modern attacks don’t “hack backups”—they log into them.

Common Exposure Points

• Veeam service accounts with domain privileges
• Backup admins tied to corporate identity
• Lack of MFA on backup console
• Reused credentials across infrastructure

What a Secure Model Looks Like

• Separate identity domain (or no domain) for Veeam
• MFA enforced on all admin access
• Privileged Access Workstations (PAWs) for backup admins
• No trust relationship with production AD

👉 If your backup platform trusts production identity, it inherits its compromise.

4. Clean Recovery: The Missing Layer

Veeam excels at restoring data.

But cyber recovery requires controlled reintroduction of that data.

Clean Room Architecture (Using Veeam)

A proper cyber recovery flow:

1. Isolated Recovery Environment
   • No outbound trust
   • No domain connectivity
   • Segmented network
2. Staged Restore via Veeam
   • Restore VM or data into clean room
   • No direct production restore
3. Validation Layer
   • Malware scanning
   • Behavioural analysis
   • Integrity checks
4. Controlled Promotion
   • Rebuild identity services first
   • Gradually reintroduce workloads

👉 Veeam provides the restore capability—but not the decision-making layer around trust.

5. Backup Testing vs Recovery Validation

Most Veeam environments test:

• SureBackup jobs
• Instant VM Recovery
• Restore performance

These are valuable—but incomplete.

What Cyber Recovery Testing Should Include

• Restore from known compromised timelines
• Identify last clean restore point
• Validate:
  • No persistence mechanisms
  • No lateral movement artefacts
• Simulate full rebuild:
  • AD restore
  • Application stack recovery
  • Network reintegration

👉 The question shifts from:

“Did it restore?”

To:

“Is it safe to restore?”

6. Replication vs Backup: A Critical Distinction

Many environments rely on Veeam replication for fast recovery.

Operationally:

• Excellent RTO
• Near-instant failover

Under Cyber Attack:

• Replicates corruption and encryption instantly
• Eliminates clean recovery points

Recommended Approach

• Use replication for availability
• Use immutable backups for recovery
• Never assume replicated workloads are clean

7. Minimum Viable Recovery (MVR) with Veeam

In a cyber event, restoring everything is:

• Slow
• Risky
• Often unnecessary

A Better Model

Define:

• Tier 0: Identity (AD, DNS, IAM)
• Tier 1: Core business systems
• Tier 2: Everything else

Recovery Flow

1. Restore identity in isolation
2. Validate and secure
3. Restore critical apps
4. Gradually expand

👉 Veeam orchestration can support this—but only if the recovery plan is designed this way

The Bottom Line

Veeam is one of the most capable platforms in the market.

But capability ≠ outcome.

Veeam deployed for backup delivers operational recovery
Veeam deployed with security architecture delivers cyber resilience

Final Thought

Most environments don’t fail because backups didn’t run.

They fail because:

• Identity was compromised
• Immutability was bypassed
• Recovery wasn’t validated

There’s a growing trend in the enterprise backup market where vendors are introducing “backup acceleration appliances.” When you strip away the marketing, most of these are essentially very fast NVMe landing zones that sit in front of slower backup storage. They act like a write cache for backups — ingest data quickly, then move it to slower storage later.

These devices absolutely have a place, but it’s important to understand what problem they actually solve, and what they don’t.

Backup Acceleration: Solving the Backup Window Problem

In many environments, the biggest backup challenge is still the backup window. Large data volumes, high change rates, and slower deduplicated or object storage repositories mean backups can run into business hours or impact production systems.

A fast NVMe landing zone solves this by allowing backup jobs to write at very high speed. The data is then de-staged to slower storage in the background after the backup job has completed. From the backup server’s perspective, the job finishes much sooner.

This can shrink backup windows, reduce load on production systems, and prevent backups running into business hours. For backup ingestion performance, this is a very effective solution.

The Important Reality: It Doesn’t Help Restore Speeds

Where buyers need to be careful is assuming that faster backups automatically mean faster restores. In most architectures, once the backup data has been moved from the NVMe landing zone to the main backup repository, restores still have to come from that slower storage and often involve rehydrating compressed or deduplicated data.

So while backup jobs finish faster, restore times are often unchanged.

This highlights a critical point that is often misunderstood in backup design: backup performance and restore performance are completely different engineering problems. Backup acceleration appliances solve backup ingest bottlenecks, not recovery time objectives.

Backup vs Business Continuity

This leads to a bigger architectural issue: backups are often treated as the entire disaster recovery strategy. They are not. Backups are for retention, rollback, and protection. They are not designed for rapid recovery of entire platforms.

If the business requirement is fast recovery and low downtime, replication needs to be part of the solution. Replication keeps a near-live copy of systems in another location so recovery becomes a failover operation rather than a full restore.

The simplest way to think about it is:

Backup = Data Protection
Replication = Business Continuity

You still need backups for retention, compliance, and ransomware recovery, but backups alone are not a business continuity strategy.

The Real Takeaway

Backup acceleration appliances are useful for shrinking backup windows and solving ingest performance problems, but they will not significantly improve restore speeds. If the real requirement is faster recovery, the discussion should move beyond backup storage and toward replication and recovery architecture.

Because ultimately, the business does not care how fast backups run — they care how fast systems come back.