How should MSPs offer immutable backup to their clients?

What makes a backup truly immutable?

A backup is immutable when no one can change or delete it before its retention period ends: not an attacker, not a client admin and not your own technicians. If anyone with the right permissions can switch it off, it's a setting, not immutability.

AWS's documentation on S3 Object Lock shows the difference. Object Lock uses a write-once-read-many (WORM) model. In governance mode, users with a special permission can still alter retention or delete objects. In compliance mode, a locked object "can't be overwritten or deleted by any user, including the root user", and the retention period can't be shortened.

For an MSP, that distinction matters. An attacker who takes over a technician account inherits that technician's permissions. On our backup as a service page we explain how we combine immutable storage with an air-gapped copy so that one stolen account isn't enough to destroy client backups.

Why are MSPs a target, and what does that mean for backup?

Because one compromised MSP opens the door to many clients. Attackers who reach your RMM or admin accounts can push ransomware to every managed network, and they'll look for the backups first.

The 2021 Kaseya VSA attack is the reference case. According to BleepingComputer's reporting, REvil exploited a zero-day in Kaseya's on-premises VSA product, affecting about 60 direct customers and up to 1,500 downstream businesses managed through MSPs. Third parties are a growing route in: Verizon's 2025 Data Breach Investigations Report found third-party involvement in 30% of breaches, double the year before.

Remote management tools themselves are abused. The NSA, CISA and MS-ISAC warned in January 2023 that criminals used legitimate RMM software to bypass anti-malware defences and take control of systems. And backups are a deliberate target: in Sophos' 2024 survey, 94% of ransomware victims said attackers tried to compromise their backups.

The joint advisory on cyber threats to MSPs from cyber agencies in the UK, Australia, Canada and the US gives the practical answer: maintain offline backups encrypted with separate keys, enforce MFA on every account that accesses customer environments, and separate customer data sets from each other and from your internal network.

What should an MSP backup service include?

Four components: immutable and air-gapped storage, a control plane isolated from your other tools, automated verification, and evidence clients can hand to auditors. Leave any one out and you're selling storage with a recovery promise attached.

The NCSC UK's principles for ransomware-resistant cloud backups make a useful checklist for evaluating any provider: resistance to destructive actions, restores from uncorrupted versions and alerts when privileged actions are attempted.

How Mindtime supports MSPs

Partners get a multi-tenant console, pay-as-you-grow billing and REST APIs and hooks for your RMM and PSA tools. Client backups are kept immutable with Object Lock plus an air-gapped copy, in our own Tier III data centres in the Netherlands and Germany. Every backup job is checked automatically, backups are scanned for malware, admin actions require MFA and the platform is monitored 24/7. We cover Microsoft 365, Google Workspace, VMware, Hyper-V, Proxmox, Linux servers, SQL Server, NAS, AWS, Azure, Google Cloud and endpoints, with unlimited backup jobs and storage.

How do you package backup tiers for clients?

Tier by outcome: how fast a client gets back up, how often restores are tested and what evidence they receive. Clients understand "back in four hours" far better than "500 GB".

The tier names and contents are yours to define. What Mindtime adds underneath: critical workloads restored on a 4-hour SLA, instant VM boot in an isolated recovery environment on a separate, clean network, and, for disaster recovery, standby infrastructure with automated DR tests every quarter and evidence for auditors. A certified engineer validates the first test failover, typically within 10 days.

Use downtime costs to set the tiers with each client. Our guide to the cost of downtime gives a calculation you can walk through together.

How does NIS2 change backup for MSPs?

It makes backup a legal duty for many MSPs and their clients. The NIS2 Directive (EU) 2022/2555 lists managed service providers and managed security service providers in Annex I, and its Article 21 requires risk-management measures from in-scope entities.

• Article 21(2)(c): "business continuity, such as backup management and disaster recovery, and crisis management".
• Article 21(2)(d): supply chain security, so your clients will assess you as a supplier.
• Article 23: an early warning within 24 hours, an incident notification within 72 hours and a final report within one month.
• Article 34: fines of at least €10 million or 2% of worldwide turnover for essential entities and €7 million or 1.4% for important entities.

National laws now apply. In the Netherlands, the Cyberbeveiligingswet took effect on 15 August 2026, and in Germany the NIS-2-Umsetzungsgesetz took effect on 6 December 2025. Check whether you're in scope on our NIS2 scope overview, and read our guide to NIS2 supply chain security for what clients will ask you.

How do you roll out immutable backup across your client base?

Start with your own stack, then move clients in waves, beginning with those that would suffer most from an outage.

1. Audit your own access. Map which accounts can change backup retention or delete backups, and remove any link to RMM or domain credentials.
2. Define tiers by outcome. Agree restore targets and test frequency per tier, and put them in your service agreements.
3. Migrate in waves. Move regulated and high-impact clients first, and run a test restore for each one after onboarding.
4. Automate evidence. Connect job and test results to your PSA through APIs, so monthly client reports build themselves.
5. Review every quarter. Check failed jobs, restore times and any changes to client systems that aren't yet in scope.

Our guide on how to verify your backup works lists what each test restore should prove.

What to do next

Offer immutable backup as provable recovery. Keep copies that no admin can delete, separate the backup console from your RMM, check every job, test restores on a schedule and give clients the evidence. That protects them and protects you, because a breach that starts in your tools shouldn't end in every client's data being lost.

See how the service is built on our backup as a service page, and read about the partner programme on our partners page.

Want to see the multi-tenant console with a real restore? Book a free 15-minute demo with our team, in Dutch, German or English.

This article is information, not legal advice.