Ransomware Recovery Readiness Checklist for IT Managers

Ransomware incidents are rarely decided by how fast the encryption wave is detected. They are decided by whether the recovery path still exists when detection finally happens. Attackers know this. Contemporary playbooks routinely include locating backup consoles, shortening retention, deleting snapshots, and disabling replication before the ransom note appears. If your readiness plan starts at “restore from backup” without proving those backups are unreachable and restorable, you are rehearsing optimism, not recovery.

This checklist is written for IT managers who own the operational outcome — whether you run backups in-house or through an MSP. It assumes you already understand why immutable backups and air-gapped copies matter. The goal here is a pass/fail readiness review you can run this quarter.

CISA’s #StopRansomware Guide remains the public baseline: offline or otherwise unreachable backups, tested restores, and an incident plan that does not treat ransom payment as the recovery strategy.

1. Know what “recoverable” means for the business

Before tooling:

• Critical systems are listed with owners, dependencies, and data stores (identity, DNS, core apps, file data, SaaS).
• Each critical system has an agreed RPO and RTO in writing — not “as soon as possible.”
• Leadership knows which systems are restored first and which can wait 72 hours.
• SaaS platforms (Microsoft 365, Google Workspace, CRM, ERP) are on the list, not assumed “the vendor backs it up for us” without evidence.

If RPO/RTO are fuzzy, fix that first; see RPO vs RTO explained.

2. Backup inventory and job health

• Every critical system maps to a named backup job or protection policy.
• Last successful backup age is within RPO for each system (checked at least weekly; daily for high-change systems).
• Failed and warning jobs page a human, not only a weekly PDF.
• Retention meets legal/operational needs and is long enough to outlast typical attacker dwell time before encryption (weeks, not three days, is the usual mistake).
• Exclusions are reviewed — temp folders are fine; “we excluded the SQL volume to save space” is not.

3. Separation: can one compromised admin wipe recovery?

This is the heart of ransomware readiness.

• Backup infrastructure uses accounts that are not the same daily domain / Entra ID global admin used for everything else.
• Backup consoles are not reachable from every workstation with standing admin rights.
• At least one copy is immutable, offline, or air-gapped so that a stolen backup-admin session cannot delete or encrypt it before retention expires.
• Cloud object-lock (or equivalent) is in compliance (or similarly hard) mode where the threat model includes compromised cloud admins — governance-only locks are weaker by design.
• MFA is enforced on backup consoles, cloud backup portals, and hypervisor management.
• Break-glass credentials for recovery are stored offline and tested; they are not in the same password vault the attackers will empty.

If every backup copy is deletable by the same privileged identity that manages Active Directory, you do not have a ransomware-resistant backup — you have a synchronized failure domain.

4. Offline / immutable copy validation

• You can name the specific technology providing the unreachable copy (object lock, locked appliance snapshots, tape, rotated disk, vault).
• Retention on that copy cannot be shortened by the standard backup operator role.
• Clock and retention settings were not “temporarily” disabled during the last storage migration and left that way.
• Capacity alerts exist so immutability does not silently fail because the vault filled up.

5. Restore capability — not backup success

Green backup jobs prove writes. Restores prove recovery.

• A documented restore test ran within the last 90 days for at least one Tier-1 system (prefer 30 days for the most critical).
• The test restored to an isolated network or host — not straight back into production AD.
• Application owners validated the restored data (login works, DB consistent, files open), not only that the VM powered on.
• Restore time was measured against RTO, including download/rehydration delays for cloud-only copies.
• Known failure modes from the last test have owners and due dates.

Untested backups are a hypothesis. After an incident, hypotheses are expensive.

6. Clean-room / isolated recovery environment

• You have a defined place to stage restores that does not trust production domain controllers by default.
• Malware scanning / integrity checks are part of the promote-to-production path.
• Identity recovery is sequenced (compromised AD/Entra recovery is planned, not improvised).
• Network allow-lists for the recovery environment are documented so responders are not inventing firewall rules under pressure.

Restoring a domain controller or file server into the same infected flat network is how organizations reinfect themselves on day two.

7. SaaS and endpoint reality check

• Microsoft 365 / Google Workspace backup (or native retention + eDiscovery you have actually exercised) covers mail, drives, and shared sites you care about.
• Endpoint backup or golden-image rebuild paths exist for executive and finance laptops that hold unique data.
• Mobile and contractor devices are classified: rebuild-only vs. data-bearing.
• Third-party integrations and API tokens are listed so “restored app, broken integrations” does not surprise you mid-incident.

8. People, vendors, and decision rights

• Incident roles are named (technical lead, communications, legal/cyber-insurance contact, executive decision-maker).
• MSP / backup vendor after-hours contacts and SLA expectations are current.
• Cyber insurance notification requirements are known before you need them.
• Ransom payment is a board/legal decision path, not an IT improvisation — and IT’s job remains proving whether payment is unnecessary because recovery works.
• A tabletop exercise in the last year walked “backups deleted, encryption spreading, CEO asking for ETA.”

9. Detection signals that protect the recovery path

Recovery readiness is not only backup engineering:

• Alerts exist for mass file changes, backup job disablement, retention changes, and unusual admin logins to backup systems.
• Privileged access to backup infrastructure is logged and reviewed.
• External backups of identity and DNS configs exist if those are on-prem single points of failure.

You cannot restore what you cannot stop encrypting forever — but you also cannot restore what was quietly deleted three weeks before anyone noticed.

10. Quarterly scorecard (pass / fail)

Score each section honest:

Three or more fails in the separation or restore rows means you are not ransomware-recovery ready, regardless of how many backup licenses you own.

How to use this checklist this month

Pick one Tier-1 system. Trace its copies. Ask which single compromised account can destroy them all. Run one isolated restore. Fix the first gap you find before expanding scope. Readiness compounds from proven recoveries, not from longer policy documents.

For the architectural baseline underneath this checklist, keep 3-2-1 and the ransomware-era extension to 3-2-1-1-0 in view — then treat this list as the operational proof that the architecture still matches reality after the last cloud migration, MSP change, or “temporary” admin exception that never got reverted.