5 Backup Security Checks MSPs Should Run Before Attackers Do

Attackers have figured out that a business with working backups has no reason to pay. So, the backups get hit first.

I've spent more than 30 years in backup and data protection, and I talk with MSPs every week who handle recovery for small and midsize businesses. What I see most often is attackers sitting undetected in the network for days or weeks before executing the payload. They use that time to map where the backups are located, and then delete, corrupt, or lock them out. That dwell time also undermines recovery efforts. If the recovered version was already infected, the systems will come back online for a few days until the attackers re-encrypt everything.

Table of Contents

1. How Attackers Reach Your Backups
2. Five Backup Security Checks
3. What Is a Realistic Recovery Time?
4. Backup Security Checklist
5. Frequently Asked Questions

How Attackers Reach Your Backups

Most backup compromises start with a person and a set of credentials.

Phishing got harder to spot.

AI-written emails show none of the grammar mistakes or odd phrasing that filters and employees used to catch.

My own team constantly receives payment requests convincing enough that even I have wondered why we haven't paid the invoice yet. And just one well-crafted message is enough to hand over the credentials an attacker needs to access backup storage.

Shared and over-scoped credentials do the rest.

Many roads lead to Rome and unfortunately, there are also many ways on how an attacker can get access to your backups:

• The backup agent runs as a domain admin or as a domain user with write access to production shares.
• One local admin password is reused across servers, with no rotation.
• Credentials for the NAS or cloud bucket sit in a shared password manager, a script, or a mapped drive.
• The same RMM or admin account reaches production, the domain controller, and the backup console.

Mistakes hit backups too.

A well-meaning employee accidentally deletes or overwrites the wrong folder, or a password rotation breaks the backup job's access without anyone noticing. While businesses invest heavily in security tools, they allocate a comparatively smaller budget to training and access control. Yet, that is precisely where most of these failures originate.

The reality is that no security stack stops every attack. This is why businesses need to keep their backups secure. That way, if something gets through, the backups are still there and restorable.

Five Backup Security Checks

Backup has to evolve from being a checkbox item to something you can verify and recover from if your business is compromised.

I won't spend time on the 3-2-1 backup rule; everyone should be following it by now. Instead, let's review the following five questions we also go through with our MSP partners when we look at their customers' backup setups.

1. Is restore testing easy enough that your team runs it?

Testing has to be simple enough to run on a schedule, for example file and application restores monthly or quarterly and a full system restore at least once a year. Every test confirms the backup works and gives your techs hands-on practice, so nobody learns the steps for the first time during an incident.

2. Is the backup storage isolated?

Local and cloud backup storage both need to be separate from production. That means:

• A dedicated NAS or cloud storage destination used only for backups and visible only to the backup software; never a general file share or a mapped drive.
• One set of credentials for that storage, stored encrypted inside the backup software, not in a script or a vault entry the whole team can read.

3. Is the cloud storage immutable, and can you still reach it?

Immutable storage prevents changes and deletion for a set retention period, stopping an attacker with valid credentials from wiping your offsite copy. But the credentials and encryption keys needed to access the storage can still be compromised. If these are stored somewhere that gets encrypted or stolen during an attack, the immutable copy may remain intact, yet it will be completely inaccessible and unusable. To avoid this, keep access credentials and encryption keys documented outside the production environment.

4. Can you go back far enough?

If the ransomware remained in the network for three weeks before running, then yesterday's and last week's backups likely already contain it, meaning that restoring those backups would reintroduce the problem. To restore an uninfected version, retention settings must allow enough versions to be held back in time to a point before the attacker got in.

One strategy is to create retention policies for each backup job and storage location. Maintain a short retention period for local storage to enable quick operational restores and a longer retention period for offsite storage that extends beyond a reasonable dwell time.

5. Does the backup check its own work?

A good backup job verifies at the start of each run that everything selected is present in the backup set. If something is missing or damaged, it backs it up again. NovaBACKUP, for example, accomplishes this by comparing the backup index to the contents of the storage before every scheduled job.

This confirms the completeness of the backup file. It doesn't confirm the recoverability of the backup though. Even a complete backup can still fail an application-consistent restore if a Volume Shadow Copy Service writer times out, for example, or a bare-metal restore to different hardware if drivers are missing. Only a restore test can catch those issues, which brings you back to check number one.

What Is a Realistic Recovery Time?

Most business owners can answer the question, "Do we have backups?" But what about, "If everything went down right now, how many hours would it take to start running again, and how much data would we lose?"

Only the second question gives you insight into what you can expect your RTO and RPO to be.

Bandwidth is the first constraint.

As businesses use more SaaS applications, databases, and file storage, their internet connections can't keep up with the growth. The table shows the best-case scenario for a cloud-only restore at full line rate, before accounting for protocol overhead, throttling, and other factors that use the connection.

In reality, restores are slower than that. This is why we focus on hybrid backup, which allows you to restore from the local backup at LAN speed and only pull from cloud storage what the local copy cannot provide.

Team readiness is the second constraint.

The time you save by skipping a restore test will cost you more when your team has to figure out how to start the restore process, locate encryption keys, and determine the restore order. Meanwhile, your customer will continue to lose money. The only solution is to perform regular, measured restore tests for each system. Only then will you know your customers' RTO.

Backup Security Checklist

Backup Security Checklist

8 checks to run on every customer environment. Click to check off as you go.

The backup agent runs under a dedicated service account with no domain admin rights and no write access to production shares. Backup storage credentials exist only inside the backup software, stored encrypted, and aren't shared with any other system or user. Backup storage (local and cloud) is used for backups only and isn't mapped or browsable from production. MFA on backup consoles and admin accounts is phishing-resistant (FIDO2 or hardware key), not push-based. Offsite storage is immutable, and its access credentials and encryption keys are documented outside production. Retention reaches further back than a realistic dwell time, set per job and per storage location. Restore tests run on a schedule and after every significant change, with results logged. Each customer and system has a measured RTO from a real restore test and a documented restore order.

Download Checklist (PDF)

Frequently Asked Questions

Make Your Backups Something You Can Prove

Backups are the last line of defense, and attackers treat them as such. Keep the storage isolated, store credentials inside the backup software, maintain enough history to surpass the dwell time, and test restores until your team can perform them without needing a manual. Then, measure how long the recovery takes so that your customers hear the real number from you before an incident reveals it to them.

Sources

1. Sophos, The Impact of Compromised Backups on Ransomware Outcomes (2024): attackers attempted to compromise backups in 94% of ransomware attacks; 57% of attempts succeeded.
2. Verizon 2026 Data Breach Investigations Report: human element present in 62% of breaches.
3. Czybik et al., A Large-Scale Study of Personalized Phishing using Large Language Models (USENIX Security 2026): 10.0% click rate for AI-personalized phishing versus 3.7% for generic AI-generated phishing, across 7,741 employees.
4. Restore time table: calculated at full line rate (data size × 8 ÷ connection speed), excluding overhead.

Worth Reading

5 Backup Security Checks MSPs Should Run Before Attackers Do

Best Practices

5 Backup Security Checks MSPs Should Run Before Attackers Do

Oct 8, 2026, 8:00:01 AM 7 min read

Multi-Location Clients Need a Different Backup Plan Than Single-Site Ones | Data Protection Digest | September 2026

Data Protection Digest

Multi-Location Clients Need a Different Backup Plan Than Single-Site Ones | Data Protection Digest | September 2026

Oct 1, 2026, 8:00:00 AM 4 min read