Ransomware readiness has to assume attackers may target backups, identity systems, and recovery accounts before encryption starts. Recovery plans should prove what survives that sequence.
- Clarify who can authorize containment, customer communication, legal escalation, and recovery tradeoffs.
- Validate backup restoration, privileged access, and executive update timing before an incident.
- Keep evidence collection and business decisions connected during the first day of response.
Ransomware planning has to start before encryption
Many ransomware exercises still begin at the wrong point: files are encrypted and the team starts recovery. Real incidents often begin earlier. Attackers may steal credentials, disable security tools, delete backups, change retention settings, create persistence, and map sensitive data before the business sees the ransom note.
Readiness should assume the recovery environment is also a target.
Protect backup administration separately
A backup is not isolated if the same compromised identity can administer production and delete recovery copies.
Review who can:
- delete backup jobs
- change retention
- disable immutability
- rotate backup credentials
- restore sensitive systems
- access recovery keys
- administer storage accounts or backup vaults
These permissions should be limited, monitored, and separated from normal domain or cloud administration where possible.
Test recovery after identity failure
A restore test should include the uncomfortable scenario: primary identity systems are unavailable or untrusted.
Ask:
- Can the team access backup tooling without normal SSO?
- Are break-glass accounts protected and tested?
- Are recovery credentials stored outside the compromised environment?
- Can administrators rebuild identity services from trusted media and known-good configuration?
- Does the team know which systems must come back before normal login works?
If the answer is unclear, the recovery plan depends on assumptions.
Look for backup tampering signals
Detection should include recovery infrastructure, not only endpoints and servers.
Monitor for:
- backup job deletion
- retention reduction
- failed backup runs across many systems
- new backup administrators
- changes to immutable storage settings
- unusual restore attempts
- disabled alerts
- access from unfamiliar locations
Backup telemetry should be visible to the security team before a crisis.
Decide what executives must approve
Ransomware recovery is full of business decisions. Executives may need to approve shutdowns, customer notices, legal escalation, insurer contact, public communications, and whether to restore partial services before the full environment is trusted.
A readiness plan should name those decisions before the incident.
The first-day executive briefing should answer:
- what is confirmed
- what is still unknown
- which systems are contained
- which backups appear usable
- what business processes are stopped
- what decisions are needed in the next four hours
Prove what survives
The best ransomware plan is evidence-backed. The team should be able to show recent restore tests, protected backup accounts, immutable copies, monitored backup changes, and tested break-glass access.
If those controls are missing, the plan may still look complete on paper while failing under pressure.
Use the visual as a reminder to separate confirmed facts, scope, containment, and recovery decisions.
Incidents often begin with a message, token, reset workflow, or account recovery path that deserves fast validation.
Backups matter when the team can prove what can be restored, by whom, and within which business deadline.
How to use this backup guidance
Businesses that need recoverable data for finance, customer operations, email, file storage, line-of-business systems, and cloud applications.
The organization can identify critical data, schedule automated backups, and run at least one restore test without disrupting production.
Get specialist help when backups are reachable from compromised admin accounts, recovery has never been tested, or downtime would create contractual or safety consequences.
- Critical data inventory with system owner, backup location, retention period, and recovery priority.
- RPO and RTO targets for payroll, customer service, email, file storage, website, and operational systems.
- Restore test results showing whether full, partial, and offline recovery actually work.
- Access controls, encryption status, immutability settings, and separation from normal administrator accounts.
DefendArm Recovery Proof Model
A backup only counts as protection after the business proves what it can restore, how fast, and under which failure conditions.
- Priority: name the data and systems the business cannot operate without.
- Separation: keep at least one recoverable copy away from normal production credentials.
- Integrity: verify encryption, immutability, retention, and backup job health.
- Restore: test full and partial recovery against realistic business deadlines.
- Continuity: document manual workarounds for the workflows that cannot wait.
- Questions to ask ITWhat data was restored in the last test, who approved the result, and what recovery time was measured?
- Signals to verifyCheck failed jobs, skipped systems, shared admin credentials, backup deletion permissions, and restore speed.
- Artifacts to produceMaintain a backup inventory, restore test log, recovery priority list, and offline access plan.
- Owner to assignAssign a system owner for each critical backup and one recovery coordinator for cross-system drills.
- Assuming cloud storage or SaaS retention is the same thing as a recoverable backup.
- Testing only full restore while ignoring the partial recovery executives usually ask for first.
- Letting ransomware-era backups remain deletable by the same accounts used in production.
- Setting RPO and RTO targets without asking the business what downtime actually costs.
Use these references for the article's identity governance claims about lifecycle controls, privileged access, MFA strength, and audit visibility.
Turn this identity guidance into a review of MFA strength, privileged access, lifecycle controls, and audit visibility.