First in a six-part series on restore testing. The client described here is a composite, drawn from a few engagements that shared the same shape. The details are real. The organisation isn’t.

Every backup article ever written ends the same way. Build it properly, secure it properly, and test your restores. I’ve written that line on this site five times in the last four months. Not once have I said what it means. So this series is me making good on it, and week one is the awkward bit: working out what a restore test is actually supposed to prove, and to whom.

Because most organisations are running a test that answers a question nobody asked.

The two hour RTO that took eight

The client is a business administration firm. Around 500 staff across several offices and countries. Roughly 100 VMs, a line-of-business case management platform sitting on SQL, a pile of file shares that nobody has ever successfully rationalised, and M365 on top of the lot.

A good shop. A competent, but very busy team. Backups had been ticking over for years and restores were tested monthly; a VM here, a mailbox there, a folder off a file share. Twelve months of green.

Their head of IT inherited a DR process but had no confidence in it, so I was brought in to test it, find it’s faults and fix it. Nothing was broken. The backups were fine. The restore worked exactly as designed. They just had no idea what their recovery time actually was, because they’d never measured the thing that mattered.

Three audiences, three different tests

Here’s the bit that clarified it for me when I stopped and thought about it properly. A restore test is being asked to do three separate jobs, and most organisations only ever do the first.

For yourself, it’s operational: Does the data come back, and does the thing work afterwards. This is the test everyone runs, and it’s the easiest to pass because you get to choose the scope.

For your insurer, it’s evidentiary: Underwriters have moved to evidence-based assessment and the forensic review at claims time compares what you attested to against what actually existed. I went through this in detail a couple of months back. A test you ran but didn’t document is, for these purposes, a test you didn’t run.

For your regulator, it’s a capability: This is the one that catches people. DORA expects resilience testing on a continuous basis. NIS2’s Article 21 measures cover business continuity as an ongoing obligation, not an event. “We restored a VM last March” is a thing that happened. It is not a demonstration that you can do it again next March with different people on shift.

A test can satisfy the first two and still fail the third. That’s not a compliance technicality – it’s the difference between having done a restore once and being able to recover.

The scoping ladder

Four rungs. Worth being honest with yourself about which one you’re actually on.

1. File or item. Someone deleted a folder. You get it back.
2. Single VM or single mailbox. One workload, restored, powers on.
3. A service. The application and everything it needs to be genuinely usable by a person with a job to do.
4. The estate, or a defensible subset of it, under conditions that resemble a bad day.

The firm above was testing at rung two, monthly, diligently. The C-suite cares about rungs three & four. Those are not the same exercise and the gap between them is where their six extra hours went.

This is rarely dishonesty. It’s that nobody ever defined what was being asked, so everyone answered the version of the question they were already able to answer.

Related mess worth sorting out now: “restore test”, “DR test” and “failover test” get used interchangeably and mean different things. A restore test brings data back from a backup. A failover test moves a running service to a secondary location, usually from replication, and often never touches a backup at all. A DR test is whatever the person saying it wants it to mean. I’ll be specific throughout this series, and if you take one thing from this post, be specific in your own documentation too. Auditors and underwriters read the word, not the intent.

What “success” means

File presence isn’t success. Service functionality is.

The questions that decide whether a restore is actually usable:

• Does the application start, and does it start without somebody remembering an undocumented step?
• Can a user authenticate into it?
• Does it talk to the things it needs to talk to?
• Is the data consistent to a point in time that somebody can name?

That second one is where two hours went, and it’s where a great many recoveries go. Identity is the dependency that breaks the most restores and gets tested the least, so it’s getting its own post next week rather than a bullet here. The wider dependency chain is week three.

The things nobody tests

Short list, deliberately uncomfortable.

Certificates. DNS. Licensing servers that phone home and won’t activate on restored hardware. Service accounts whose passwords live in the head of a contractor who finished up in 2023. The runbook written by someone who’s since left, describing a version of the environment that no longer exists.

And the one that gets least attention: whether the person who ran the test is the person who’d actually be available at three in the morning on a Sunday. A recovery capability that depends on one individual isn’t a capability. It’s a bloke.

Write it down while you’re doing it

Reconstructing a test eighteen months later for a claim does not work. A forensic team knows what a retrofitted document looks like – the dates are too tidy and the failures are all missing.

Minimum record, captured as you go:

• Date, and who ran it
• Scope, stated in the terms above so it can’t be misread later
• What was restored, from what, to where
• Elapsed time per phase, not just a total
• What failed
• What was changed as a result
• When it’s being repeated

Those last two are what turn an event into a capability. A test with no remediation trail reads as theatre, and reads that way to exactly the people you don’t want thinking it. If you haven’t found fault, you haven’t tested hard enough.

I’m not going to build the full evidence pack here. That’s week six, and it’s a proper piece of work in itself. For now: record it as it happens or you don’t have it.

The point isn’t the test

If a restore test never fails anything, it’s scoped too small. That’s the whole argument. The value isn’t the green tick at the end, it’s the failures and the list of tasks you’ve got to work through to fix them before the next test.

The firm in this piece came out of that exercise with a recovery time roughly 300% longer than the one they committed to the board, and a fairly urgent conversation to have about it. Uncomfortable. Considerably less uncomfortable than the alternative version, where they find out during an incident with a regulator already asking questions.

Next week: identity. Why the restore that comes back fastest is usually the one nobody can log into, and what forest recovery looks like when you’ve never had to do it.

For the best part of two decades, picking a hypervisor was the easy bit. VMware was the default, and every backup and replication vendor built their integration around it first. VADP, journal-based CDP, tag-driven job scoping… The whole ecosystem grew up assuming vSphere underneath.

That assumption is gone. Broadcom’s licensing changes knocked the certainty out of the market, and the result isn’t a tidy migration from one platform to another. It’s fragmentation. Hyper-V, Proxmox, Nutanix AHV, XCP-ng, OpenShift Virtualization, Sangfor aSV estates are splitting across multiple hypervisors, sometimes within the same organisation, sometimes within the same rack. I covered the sharp end of this a few weeks back with the Tesco filing: 40,000 servers moving off VMware, and a backup and replication stack that doesn’t follow them.

the mistake is thinking of this as a one-off decision

Most organisations are treating the hypervisor question as a single migration project with an end date. Pick the target, move the workloads, done. That’s the wrong frame for backup and DR specifically, because of one detail that gets lost in the platform debate: your data protection software has to survive longer than any one piece of compute infrastructure underneath it.

Long-term retention requirements don’t care what hypervisor you were running when the backup was taken. A seven-year retention policy for regulatory or legal reasons will span at least one hypervisor refresh, quite possibly two. Compliance obligations under DORA and NIS2 don’t reset because you swapped from ESXi to Hyper-V. The backup platform is the constant. The compute layer underneath it is the thing that changes.

Put simply: you’ll replace your hypervisor more than once during the life of a single retention policy. Choose backup and DR tooling as if that’s a certainty, not a risk.

what this means in practice

Native, broad hypervisor support beats deep integration with one. A platform that only does VMware brilliantly is a liability the moment your estate stops being VMware-only. This is where it’s worth giving credit where it’s due – Veeam has clearly clocked this shift and has been putting real engineering effort into closing the gap rather than hoping the market stays still. Version 13.1, announced at VeeamON in May, introduced a Universal Hypervisor API and added native support for Red Hat OpenShift Virtualization, Sangfor aSV, Vates XCP-ng, and Citrix XenServer on top of existing VMware and Hyper-V coverage. That takes them to something like 95% of hypervisors in active use, with cross-platform portable recovery built in from the off, meaning a VM protected on one platform can genuinely be restored onto another, not just backed up on both in isolation. That’s the direction every vendor in this space needs to be moving, and it’s a meaningfully different starting position for anyone planning a hypervisor move today versus twelve months ago.

Vendor lock-in at the hypervisor layer becomes lock-in at the backup layer if you’re not careful. This is the expensive lesson Tesco are learning. Choosing a backup platform because it’s the best VMware tool available, without checking what happens if VMware isn’t the answer in three years, is how organisations end up rebuilding their entire data protection stack mid-migration, under time pressure, with leadership only finding out about the gap once it’s already a problem.

the retention timeline is the argument

This is the part that doesn’t get enough airtime in the hypervisor debate. Nobody selects a backup platform with a seven-year retention in mind. But the retention data doesn’t move when the compute does. It has to be restorable regardless of what’s running underneath it by the time someone actually needs it back. Again, this is where Veeam are leading the pack.

If there’s one lesson from watching the VMware exodus play out this year, it’s this: don’t pick backup and DR tooling to match your current hypervisor. Pick it because it’ll still be doing its job long after that hypervisor has been and gone.

On 9 July 2026, the European Commission referred Ireland to the Court of Justice of the EU for failing to transpose NIS2. Spain, France, and the Netherlands were referred alongside it. This isn’t a warning letter. It’s the Commission asking the Court to impose a lump sum penalty plus ongoing daily fines until Ireland formally notifies full transposition.

For anyone who’s been half-tracking NIS2 and assuming it’ll land “eventually,” this is the moment to stop assuming and start planning against an actual timeline, even an uncertain one.

Where things actually stand

Ireland missed the original transposition deadline of 17 October 2024. It wasn’t alone, most member states did, but Ireland is now one of a shrinking group still without transposing legislation in force. The vehicle is the National Cyber Security Bill, whose general scheme was published back in August 2024. It’s still working through pre-legislative scrutiny. The 2024 general election disrupted the legislative calendar early on, and the bill has been moving slowly since.

The Commission opened infringement proceedings against Ireland (and 22 other states) in November 2024, escalated to a reasoned opinion in May 2025, and has now escalated again to a CJEU referral. The pattern in similar cases is that member states tend to adopt the legislation while proceedings are underway, at which point the Commission withdraws before judgment. Don’t read the CJEU referral as “nothing will happen for years”, read it as external pressure that’s now genuinely accelerating the timeline.

The relevant minister has indicated Ireland is targeting notification of transposition by the end of 2026. Take that as a direction of travel, not a commitment; this bill has already slipped past one publicly stated timeline.

What’s still in effect while we wait

The old NIS1 framework continues to apply to already-designated Operators of Essential Services. If you were in scope under NIS1, you still have obligations today. NIS2’s expanded scope, the sectors, the essential/important entity split, the tighter incident reporting windows, doesn’t bind you yet, because the national implementing law that would create those obligations doesn’t exist.

The NCSC has published interim guidance in the gap, including the CyFun framework (Cyber Fundamentals, originally developed in Belgium, which Ireland has joined as a co-owner scheme) as a maturity model organisations can use to self-assess now, ahead of formal registration requirements.

The scope, for anyone who hasn’t checked

When it lands, NIS2 in Ireland is expected to bring an estimated 4,500–6,000 organisations into scope, using the directive’s standard thresholds:

• Essential entities: ≥250 employees and €50m+ turnover, in specified critical sectors
• Important entities: ≥50 employees and €10m+ turnover, in a broader set of sectors

That’s a significant expansion from NIS1’s much narrower OES list. If you’re an MSP, note that MSPs themselves are explicitly in scope as a sector under NIS2, not just your clients.

What backup and DR teams should actually do about this now

The temptation with a delayed transposition is to deprioritise the work until the law is actually in force. That’s the wrong read for two reasons.

First, the requirements aren’t a surprise. The directive text has been stable since 2022. The Irish-specific detail that’s still moving is enforcement mechanics, competent authority structure, and exact registration timing, not the substance of what “good” looks like for risk management, incident response, business continuity, and supply chain security.

Second, cyber insurers, as covered on this blog previously, are already underwriting to NIS2-aligned control expectations regardless of Irish transposition status. The market isn’t waiting for the legislature.

Practical steps that hold up regardless of when the bill passes:

1. Run a scope self-assessment now using the CyFun framework or the directive’s own thresholds. Don’t wait for the NCSC’s “Am I in scope?” tool. It’s listed above and won’t change between now and then.
2. Map backup and recovery architecture against Article 21 risk management measures: MFA, supply chain risk, incident handling capability, business continuity and crisis management, and encryption.
3. Treat your existing NIS1 obligations, if any apply, as the floor, not the target. The gap between NIS1 and NIS2 scope is where most organisations will discover they’re newly in-scope and unprepared.
4. Watch the registration mechanism. When it launches, expect a short self-registration window (three months has been floated as the model in earlier drafts). Have your CRO number, NACE code, and a designated cybersecurity contact ready so you’re not scrambling when the portal opens.

Final thought

Ireland being taken to the CJEU over this isn’t really the story. The story is that the substance of NIS2, what regulators, insurers, and increasingly your own customers expect of your resilience posture, has already arrived, even though the statute hasn’t. Legislative delay is not the same as obligation delay. Treat this the way you’d treat any known deadline of uncertain date: build to the requirement now, and let the formal enforcement date be a compliance formality rather than the trigger to start.

I’m a technologist by trade, but the business side of the MSP space has always interested me. I’ve been listening to Dave Sobel’s Business of Tech podcast for a while now, and yesterday’s episode, a repost from a sister publication, the SMB Community Podcast, was very interesting.

The argument is straightforward, and the implications are uncomfortable: AI could reduce white-collar jobs by 30–50%, and that directly threatens the per-seat AYCE managed services pricing model that has anchored MSP revenue for the better part of two decades.

That’s not a distant forecast. That’s a structural problem arriving faster than most MSPs in the SMB space are prepared for.

We charge per seat because each seat represents a person generating tickets, consuming bandwidth, needing endpoints managed, requiring access controls. Remove the person — or replace them with an AI agent — and the commercial logic collapses. Microsoft’s introduction of Agent365 licenses AI agents rather than human users, and that’s not a coincidence. The vendors are already repricing for a world with fewer people in it. MSPs need to be doing the same.

The challenge is especially acute for MSPs operating in the SMB space. Enterprise customers have enough complexity — infrastructure, compliance, multi-site, hybrid cloud — that there’s always something to bill for regardless of headcount shifts. SMBs are leaner. Fewer seats means lower billables. If a ten-person accountancy firm automates four roles, we’ve just lost 40% of our billing base on that client, with no equivalent replacement.

So what’s the alternative? Outcome-based pricing is the direction of travel, but it’s harder to operationalise than it sounds. Charging for uptime, availability, security posture, recovery time objectives — these require us to define, measure, and contractually commit to outcomes rather than simply covering a seat count. It demands better tooling, tighter SLAs, and a more sophisticated commercial conversation with clients who have historically bought IT like a utility.

Vendor-attached outcomes and resilience warranties are already pushing in this direction — some vendors are now offering performance guarantees that require MSPs to standardise on their architecture in exchange for coverage-based commitments. That’s a version of outcome delivery, even if it’s vendor-led and comes with its own lock-in risks.

The MSPs that navigate this well won’t be the ones who figure out how to replace lost seat revenue with clever billing gymnastics. They’ll be the ones who can articulate — and prove — what business continuity, security resilience, and operational uptime are actually worth to a client whose headcount is shrinking. That’s a different kind of value conversation, and frankly, most of us aren’t having it yet.

Worth thinking about now, while there’s still room to move deliberately.

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.