Ransomware Resilience Assessment Checklist
Ransomware resilience is ability to contain identity abuse, limit spread, restore priority services, and make defensible decisions under pressure. A backup job marked successful is not proof of recovery. CISA recommends offline, encrypted backups, regular availability and integrity tests, golden images, incident planning, and least-privilege access. NIST incident-response guidance frames recovery and lessons learned as planned work.
Set recovery assumptions first
Inventory services by business consequence, dependency, data source, recovery owner, and acceptable restoration check. Give each service a recovery point objective and recovery time objective only when business owner has approved them. Treat targets as planning inputs, not promises. Keep offline contact list, recovery runbook, credentials process, and architecture dependencies available without relying on compromised identity system.
Resilience evidence map
| Area | Completed example | Evidence | Owner | Pass/fail | Exception or remediation |
|---|---|---|---|---|---|
| Backup isolation | finance database has encrypted copy in separate access boundary | backup policy, recovery account review | backup owner | Pass | quarterly restore due |
| Backup restore | 2026-07-29 copy restored to isolated environment; integrity query passed | job ID, checksum, test log | recovery owner | Pass | no production restore tested |
| Privileged identity | 14 admin accounts reviewed; two stale accounts disabled | access export, disable record | identity owner | Pass | break-glass test open |
| Segmentation | workstation VLAN cannot reach backup management network | firewall rule and denied-flow test | network owner | Pass | supplier jump host review due |
| Service recovery | invoicing accepts synthetic transaction after rebuild | business check signed by finance | service owner | Fail | dependency queue not restored |
A pass means observed evidence meets planned test criterion. It does not mean attacker cannot reach environment. A fail produces bounded remediation: identify failed dependency, owner, target test date, and evidence needed to change status. Never erase failed tests after a later pass; retain sequence.
Backups: verify restoration, not storage
Maintain copies outside routine administrator reach and test whether authorized recovery staff can locate, decrypt, restore, and validate them. Test both data and dependencies: keys, images, infrastructure templates, software media, configuration, DNS, and credentials process. Measure elapsed time separately for retrieval, restore, validation, and business handoff. A valid checksum confirms copy integrity, not application usefulness.
Use isolated recovery environment. Do not attach recovered system to trusted production network before malware review, identity decisions, and authorization. Record source backup time, target environment, operator, commands or runbook version, data sanitization, validation result, and cleanup. If recovery requires unavailable individual knowledge, that is resilience gap.
Identity and segmentation tests
Test emergency revocation for privileged and service accounts, session invalidation, break-glass process, and identity-provider outage procedure. Separate daily user identities from administrator identities. Confirm old accounts, external access, API tokens, and dormant service principals are identified; do not publish account data in exercise record.
Segmentation needs observed paths. Test that expected business flows work and disallowed lateral paths fail between user networks, servers, backup management, identity infrastructure, and recovery environment. Document test source, destination, protocol, rule version, and result. A network diagram alone is design intent, not proof.
Recovery drill and decisions
Run scenario without touching production: suspected encryption, account compromise, unavailable collaboration tools, and request to restore priority service. Decide who authorizes isolation, credential rotation, restore order, and return to service. Preserve logs and decisions. After drill, compare actual times and blockers with assumptions; revise runbook, not history.
Recovery closure test
A recovery row closes only after service owner performs agreed business check on isolated restored service. For invoicing, capture restored queue version, synthetic invoice ID, ledger result, elapsed retrieval/restore/validation times, and cleanup confirmation. If database restores but queue replay fails, mark service recovery failed even when backup checksum passes; identify queue owner and repeat exact blocked stage. Return-to-service decision remains with authorized operations, not drill facilitator or backup operator.
Review cadence
Run restore, identity, segmentation, and decision tests on planned cadence and after material architecture, identity-provider, backup, or supplier changes. Review open exceptions at each exercise. Escalate missed recovery evidence to business owner; a missed test is operational information, not administrative noise.
Limits
This checklist is evidence-planning guidance, not ransomware prevention guarantee, certification, legal advice, or regulatory compliance determination. Obtain qualified review for legal, contractual, safety, and notification decisions.
Sources
Worked recovery observation
Choose one payroll application and trace backup creation, immutable-copy setting, restore authorization, isolated restore network, and application smoke test. Expected behavior: restore produces usable records without reconnecting recovered host to production before validation. Edge case: backup job reports success but key-management access is unavailable; mark recovery unproven. Closure test: retain restore timestamp, operator, source recovery point, checksum or record-count comparison, defects, and approved follow-up owner.
Worked closure check
For payroll recovery drill, retain recovery-point timestamp, backup and runbook revision, isolated environment identity, business-check result, recovery owner, and operational decision. Evidence demonstrates this restore exercise only; it cannot guarantee ransomware prevention, service recovery, compliance, certification, or legal readiness. Re-test affected stage after key-management, queue, identity, or backup-architecture changes. Independent reviewer follows one synthetic invoice from restore source through validation and cleanup, leaving failed dependencies and return-to-service authority in the open register.