Backup Recovery

10 Backup & Ransomware Questions Every IT Leader Must Ask

Ransomware attacks are no longer a matter of if, but when. Ten questions that expose the hidden gaps in your backup strategy — before an attacker does.

By InventiveHQ Team

For many organizations, backups are the ultimate safety net — right up until the moment they discover the net has a hole. The most important backup question an IT leader can ask is not "do we have backups?" but "when did we last successfully perform a full restore test?" — because backup jobs that report "success" routinely fail to actually recover, thanks to silent job failures, corrupted snapshots, expired credentials, and gaps in what's covered. The ten questions below expose those hidden failures: recovery you've never timed, backups sitting one hop from the ransomware, retention too short to outlast a dormant infection, and SaaS data nobody realized wasn't being protected.

That paragraph is the summary an AI overview would hand you. The rest of this article is the part it can't: a self-assessment scorecard that tells you what a good answer to each question looks like versus the red flag, a diagram of exactly how ransomware reaches unprotected backups, and the modern 3-2-1-1-0 rule that hardens the classic version against encryption. Whether you run backups in-house or lean on a provider, work through these before you're forced to find out the hard way.

How ransomware reaches unprotected backups versus isolated backups Ransomware spreads from production across the network to an always-online backup and encrypts it, but cannot reach an air-gapped, immutable copy. Why isolation is the difference between recovery and ruin Production Servers · endpoints SaaS · cloud Connected backup Same network + creds ✕ encrypted too air gap Isolated copy Immutable · offline Separate creds ✓ survives The whole game is reachability. If ransomware can reach a backup with stolen credentials, it will encrypt it. Isolation removes the path.

The 10-question readiness scorecard

Read each question below and score yourself honestly. If your answer lands in the "red flag" column, that's a gap to close now — not after an incident forces the issue.

#QuestionA good answer looks likeRed flag
1Last successful restore test?Full restore verified within the last quarter"Backups report success" (never restored)
2Full-recovery time (RTO)?Timed, documented, meets a business-approved targetNever measured — it's a guess
3Backups isolated?Immutable and/or air-gapped, separate credentialsSame domain, same creds, always online
4Can you detect ransomware in backups?Anomaly detection + long retention to roll backOnly a few recent versions kept
5Who has access?RBAC, separation of duties, audit logsOne admin controls prod and backup
6Covering SaaS, endpoints, cloud?Microsoft 365, laptops, cloud all backed upOn-prem servers only
7Policy review cadence?Reviewed at least quarterly"Set it and forget it"
8Backing up config + security data?System/security settings captured, not just dataData only — rebuild by hand
9Ransomware-specific plan?Isolation, forensics, comms, clean-restore workflowOnly a generic DR plan
10Backup audit in last 12 months?Formal audit with documented findingsOut of sight, out of mind

❶ When was the last time we successfully tested our backup recovery?

This might be the most critical question on the list. Backup failures are surprisingly common, often resulting in silent job failures, corrupted data, incomplete snapshots, or expired credentials that disrupt automated processes. The only way to know your backups work is to test them regularly.

🚨 Many organizations discover their backups don't work only during an actual emergency when it's too late to fix the problem.

Test These Elements:

  • Full system restore (not just individual files)

  • Database integrity after restoration

  • Application functionality post-recovery

  • Time required for complete restoration

❷ How long would it take to recover from a full ransomware incident?

It's one thing to have backups—it's another to actually restore them fast enough to keep the business running. Many organizations have never timed a full recovery, and during a ransomware incident, every hour of downtime adds pressure and cost.

Two key metrics help frame this:

RTO (Recovery Time Objective): How long does it take to restore systems and resume operations?

RPO (Recovery Point Objective): How much data loss is acceptable, usually measured in time between backups.

⚠️ Without a real-world test, you're guessing. And in a ransomware scenario, guessing is expensive.

❸ Are our backups isolated from the rest of the network?

One of the biggest mistakes organizations make is keeping their backups too close to the systems they're meant to protect. When ransomware hits, it often spreads across the network, and if your backups are accessible, they can be encrypted or deleted right along with everything else.

To prevent this, backups must be isolated. That can mean:

  • Immutability: Backups that can't be altered or deleted for a fixed period of time.

  • Air-gapped storage: Offline or physically separated backups, such as external drives or tape.

  • Access restrictions: Ensuring backup systems aren't on the same domain or accessible via the same credentials used elsewhere in the environment.

Advertisement

The 3-2-1 rule, upgraded for ransomware: 3-2-1-1-0

The classic 3-2-1 rule predates ransomware. The modern, attack-hardened version is 3-2-1-1-0: it adds one offline or immutable copy and a requirement to verify zero restore errors. That extra "1" — a copy the attacker cannot reach — is the part that turns a backup into a recovery guarantee.

The 3-2-1-1-0 backup rule Three copies of data, on two media types, one offsite, one offline or immutable, verified with zero restore errors. 3-2-1-1-0: the ransomware-hardened backup rule 3 copies of your data 2 media different types 1 offsite stored remotely 1 offline or immutable 0 errors verified by restore test The green "1" defeats ransomware; the amber "0" proves the whole chain actually works.

❹ Can we detect if ransomware has made it into our backups?

Ransomware doesn't always announce itself right away. Some strains remain dormant for weeks or months, gradually encrypting or corrupting files in the background. If your backup system is configured to retain only a few recent versions, there's a real risk that all your backups contain encrypted data, without you even realizing it.

That's why early detection is critical. Some modern backup solutions offer:

  • Anomaly detection: Alerts when backup sizes or file change rates deviate from normal patterns.

  • Ransomware scanning: Identifies known ransomware signatures or suspicious file behavior.

  • Extended retention: Lets you roll back to clean versions from weeks or months ago.

Silent ransomware can lurk for months—make sure your backup retention spans longer than typical attack timelines.

❺ Do we know who has access to backup systems—and why?

Your backup system is a high-value target. If an attacker—or even a disgruntled insider—can access your backups, they can delete recovery points, encrypt backup data, or quietly disable jobs without being noticed.

Protect your backups like you protect your production systems—with strict access controls and monitoring.

That's why access control and audit logging are just as important for backup infrastructure as they are for your production systems. You should have:

  • Role-based access control (RBAC): Only the people who need to manage backups should have access.

  • Separation of duties: No single admin should have end-to-end control over both production and backup systems.

  • Audit logs: Track who accessed what, when, and what changes were made.

❻ Are we covering endpoints, SaaS apps, cloud services, and servers?

Many backup strategies focus heavily on on-prem servers or core databases, but today's environments are far more distributed. Critical data often lives in:

  • Employee laptops and mobile devices

  • Cloud storage like Google Drive, OneDrive, and Dropbox

  • SaaS platforms like Microsoft 365, Google Workspace, Salesforce, and Slack

  • Cloud-hosted servers and databases

If it has business data, it needs backup protection—regardless of where it lives.

❼ How frequently do we review and update our backup policies?

Backup strategies aren't "set it and forget it." Your environment changes constantly—new apps get deployed, teams adopt new tools, and data volumes grow. What worked a year ago might be dangerously outdated today.

Set a reminder to review your backup strategy quarterly—technology changes fast.

❽ Do we back up our security and configuration data?

When disaster strikes, recovering applications and data is just part of the equation. Without the right configuration and security settings, you may find yourself scrambling to rebuild systems manually.

❾ Do we have a ransomware-specific recovery plan?

A generic disaster recovery (DR) plan isn't enough. Ransomware incidents present unique challenges, including legal implications, containment needs, public relations concerns, and uncertainty about the extent of the infection.

Ransomware isn't just a technical problem—it requires legal, communication, and business continuity responses.

A ransomware-specific recovery plan should include:

  • Isolation Procedures: How to Prevent the Spread Across Systems.

  • Forensics and evidence collection: Preserving logs and artifacts for investigation.

  • Communication Protocols: What to Share with Employees, Partners, and Potential Customers.

  • Clean restore workflows: Ensuring recovered data isn't re-infected.

  • Decision trees: When to involve law enforcement, legal counsel, or insurance.

❿ Have we done a backup audit in the last 12 months?

Backups tend to be out of sight, out of mind—until something goes wrong. That's why a periodic backup audit is essential. It's your opportunity to verify what's really being backed up, how fast it can be restored, and whether your systems and processes are keeping up with current risks.

A backup audit is like a fire drill—better to find problems during practice than during the emergency.

A solid backup audit should cover:

  • Coverage gaps: Are all critical systems, SaaS apps, and endpoints included?

  • Recovery tests: Can we restore data within our RTO/RPO?

  • Retention policies: Do we keep data long enough to catch delayed ransomware infections?

  • Access controls and logging: Who has access, and is it being tracked?

  • Compliance and Documentation: Are We in Alignment with Industry Regulations and Internal Policies?

Take Action Before It's Too Late

In today's threat landscape, backups are more than a safety net—they're a strategic asset. But simply having backups isn't enough. You need to know that they work, cover everything that matters, and can withstand a real-world ransomware attack.

The ten questions in this article are meant to spark a deeper conversation inside your organization. If you couldn't confidently answer all of them, you're not alone—and now is the perfect time to close those gaps.

Schedule a backup review. Better yet, conduct a full audit. You'll gain clarity on your true readiness and may uncover issues that could save your business days—or even weeks—of downtime in a crisis.

Get Your Free Backup Audit Checklist

Want to make sure your current backup setup is secure, compliant, and recovery-ready? Download our free backup audit checklist by filling out the form below:

hbspt.forms.create({ portalId: "47453230", formId: "378f9643-1e9d-41e1-80c7-e510dc10a7d5", region: "na1" });

Frequently Asked Questions

What are the most important backup questions to ask?

The single most important question is: when did we last successfully perform a full restore test — not a backup job that reported "success," but an actual recovery of systems and data? After that, the highest-value questions cover recovery time (how many hours to bring the business back), isolation (are backups immutable or air-gapped so ransomware can't reach them), retention (do we keep clean copies longer than an attacker's typical dwell time of weeks to months), and coverage (are SaaS apps, endpoints, and cloud services backed up, not just on-prem servers). If you can't confidently answer those five, you have a resilience gap, not a backup.

What is the difference between RTO and RPO?

RTO (Recovery Time Objective) is how long you can afford to be down — the maximum acceptable time to restore systems and resume operations after an incident. RPO (Recovery Point Objective) is how much data you can afford to lose, measured as the time between your last good backup and the moment of failure. If your RPO is one hour, you back up at least hourly; if your RTO is four hours, your entire restore process must complete within four hours. Most organizations set these targets on paper and never test whether their infrastructure can actually meet them.

What is the 3-2-1 backup rule?

The 3-2-1 rule says keep 3 copies of your data, on 2 different media types, with 1 copy stored offsite. The modern ransomware-hardened version is 3-2-1-1-0: add 1 copy that is offline or immutable (air-gapped from the network) and verify 0 errors by regularly testing restores. The extra "1" is what saves you from ransomware — if every copy is online and reachable with the same credentials, malware can encrypt or delete all of them at once.

How can ransomware get into backups?

Ransomware reaches backups three main ways. First, it spreads laterally across the network and encrypts any backup repository it can reach with stolen credentials. Second, it deletes or disables backup jobs and recovery points once it gains admin access to the backup console. Third — the quietest — it stays dormant for weeks while corrupting or encrypting files that then get backed up as "good" data, so every retained version contains the infection. Immutability, network isolation, separate credentials, and long retention windows defend against all three.

How often should you test backup recovery?

Test a full restore at least quarterly, and after any major infrastructure change (new applications, migrations, or backup software upgrades). A successful backup job is not proof of recoverability — it only confirms data was written, not that it can be read back into a working system within your RTO. Critical systems warrant monthly restore tests. Treat it like a fire drill: you want to find the broken step during practice, not during an actual ransomware event when every hour of downtime costs money.

What does immutable backup mean?

An immutable backup is a copy that cannot be modified, encrypted, or deleted for a fixed retention period — not even by an administrator with full credentials. It is typically enforced by write-once storage, object-lock in cloud storage, or hardened backup appliances. Immutability is the strongest single defense against ransomware because it removes the attacker's ability to destroy your recovery points even after they compromise the backup system itself.

Should backups be isolated from the network?

Yes. Backups stored on the same domain, reachable with the same credentials, and always online are the first thing ransomware encrypts after it spreads. Isolation means at least one of: immutability (can't be altered for a set period), air-gapping (offline or physically separated storage), or strict credential separation so the backup system isn't accessible from a compromised production account. The goal is a recovery copy the attacker cannot reach even with full control of your production environment.

Do you need a separate ransomware recovery plan?

Yes — a generic disaster recovery plan is not enough. Ransomware adds problems a hardware failure never has: you must contain lateral spread, preserve forensic evidence, decide whether to involve law enforcement, legal counsel, and cyber insurance, manage communications with staff and customers, and ensure restored data isn't re-infected from a dormant payload. A ransomware-specific plan documents isolation procedures, clean-restore workflows, and a decision tree for who gets called and when, so nobody improvises those choices under pressure.

What should a backup audit cover?

A backup audit verifies coverage (all critical systems, SaaS apps, and endpoints included), recovery (can you actually restore within RTO/RPO), retention (long enough to roll back past a dormant infection), access (who can touch the backup system and is it logged), and configuration (are security and system settings backed up, not just data). Run one at least every 12 months. Its job is to replace assumptions with evidence — turning "we think we're covered" into "we tested it and here's the proof."

Advertisement