A backup is not a recovery capability
Ransomware recovery is the ability to restore priority business services to a trustworthy state within agreed time and data-loss limits. A green backup dashboard proves that jobs ran; it does not prove that retained data is clean, credentials are available, dependencies are understood, or staff can rebuild while the normal network and communications channels are unavailable.
Define recovery time objective and recovery point objective with business owners for each service. Then identify the dependency chain: identity, DNS, network, hypervisor or cloud control plane, secrets, certificates, databases, applications, file data, endpoints, telephony, and external providers. A four-hour application target is meaningless if the only identity service needed to administer it has no tested recovery path.
CISA recommends offline, encrypted backups and regular availability and integrity testing. The Canadian Centre for Cyber Security likewise frames ransomware preparation, response, and recovery as an organization-wide discipline. Convert those principles into evidence: restore logs, measured timings, checksums or application validation, screenshots of isolated recovery, signed exercise findings, and closed corrective actions.
1. Decide what must return first
Create a service recovery catalogue. For each service, name the business owner, technical owner, maximum tolerable outage, RTO, RPO, minimum viable operating mode, upstream dependencies, data sensitivity, restoration procedure, and validation authority. Rank by safety, legal obligation, revenue, customer impact, and dependencies—not by which server is easiest to restore.
Define a minimum viable business. It may use a small clean identity environment, a limited set of laptops, manual order intake, an alternate phone line, and read-only access to selected records. Document capacity assumptions and the point at which manual processing becomes unsafe or unsustainable.
Test the order. Identity, networking, name resolution, time, certificate services, and backup control often precede application recovery. Build a dependency graph and identify circular dependencies, such as a password vault that requires identity services whose recovery credential is stored only in that vault.
2. Make recovery data resistant to the production compromise
Maintain multiple recovery copies with at least one isolated from ordinary production credentials and write paths. Depending on platform and risk, isolation may be offline media, immutable object storage with locked retention, a separately administered backup environment, or a combination. Encryption protects confidentiality but does not stop an attacker who has deletion authority; immutability does not help if retention was too short or the account controlling it was compromised.
Separate backup administration from domain and cloud administration. Require multi-factor authentication, dedicated privileged accounts, restricted management hosts, alerts on deletion and retention changes, and an audit destination outside the protected environment. Do not mount backup repositories permanently to general-purpose servers or expose the console to user networks.
Back up more than business data: identity-system state and recovery procedures, network and security-device configurations, infrastructure-as-code, encryption keys where recoverable by design, certificate material, SaaS configuration and exports, software installers, licence information, golden images, and contact lists. Track unsupported hardware or software that cannot be rebuilt on available replacement equipment.
3. Prepare a clean-room recovery path
Assume the production identity plane, administrator endpoints, remote-management tools, and collaboration tenant may be suspect. Predefine an isolated recovery network with controlled Internet access, clean DNS, logging, endpoint protection, patch sources, forensic storage, and no automatic trust to production. Preserve configuration templates offline and test their deployment.
Maintain break-glass credentials and recovery keys in a protected location that remains accessible when normal identity is unavailable. Use more than one custodian and a checked sign-out process. Test credentials without exposing them in routine exercises, rotate them after use, and monitor every invocation. Ensure cloud emergency-access accounts, hypervisor access, network console access, and backup-console recovery are covered.
Keep trusted installation media or reproducible images and a known-good configuration baseline. Restore systems into the clean zone, patch them, rotate credentials, scan for compromise, and validate configuration before reconnecting. CISA warns against re-infecting clean systems and recommends prioritizing restoration from offline encrypted backups.
4. Write decisions and communications for degraded conditions
The incident plan must identify who can declare an incident, isolate networks, engage external response, notify insurers, approve emergency spending, communicate with customers and staff, and accept recovered services. List primary and alternate contacts for executives, legal counsel, privacy, communications, managed providers, cyber insurer, law enforcement, the Canadian Anti-Fraud Centre, and the Canadian Centre for Cyber Security.
Store printed and offline copies because email, chat, single sign-on, and cloud drives may be unavailable or monitored by the attacker. Establish an out-of-band conference bridge and alternate email or messaging channel in advance. Prepare holding statements, but route notification decisions through legal and privacy counsel because obligations depend on jurisdiction, contract, sector, and the facts of the breach.
Include evidence-preservation guidance. Isolation normally takes priority, but indiscriminate power-off can destroy volatile evidence. The CISA response checklist advises isolating affected systems and notes that powering down should be used when disconnection is not possible, with the trade-off understood. Define who coordinates forensic capture so recovery actions do not erase the facts needed for scoping and notification.
5. Exercise restores, not presentations
Run monthly sample restores and at least an annual end-to-end recovery exercise, adjusting frequency to business risk and change rate. Select samples unpredictably across systems, dates, tiers, and storage locations. A restore test should begin with access to the isolated recovery copy and finish with application-owner validation, not merely extraction of files.
Measure actual recovery point, elapsed time by phase, manual effort, failed dependencies, data integrity, security validation, and time to minimum viable service. Test a scenario in which production administrator credentials are unusable and a recent backup may contain attacker persistence. Include restoration of identity and a critical application, not only a file share.
Record findings as owned remediation items with severity and due date. Re-test failed controls. Report RTO and RPO misses to business owners and either improve capability or formally revise the objective. An unclosed exercise finding is accepted outage risk, whether or not it appears on a technical dashboard.
6. Use a gated return to production
Recovery begins only after containment and scoping are sufficient to avoid immediate re-compromise. Establish clean credentials from a trusted system, remove known persistence, close exploited paths, patch or mitigate vulnerable systems, and monitor for the observed indicators and behaviours. If the initial-access path is unknown, state that uncertainty and apply compensating restrictions rather than declaring the environment clean.
Use service-specific acceptance gates: infrastructure validation, security scan, credential rotation, data integrity check, application smoke test, business-owner sign-off, monitoring confirmation, and rollback point. Reconnect in dependency order and limited groups. Keep recovered systems segmented from unrecovered assets.
After stable operations, hold a lessons-learned review that covers technical response, business decisions, communications, third parties, privacy assessment, and recovery metrics. Update the plan and architecture, share appropriate indicators with authorities or sector partners, and schedule validation of every material correction.
Implementation checklist
- Document business-approved RTO, RPO, minimum viable mode, dependencies, and recovery order for each critical service.
- Maintain encrypted recovery copies, including at least one isolated from normal production credentials and write paths.
- Separate backup administration and alert on deletion, retention, identity, and configuration changes.
- Back up identity, configurations, infrastructure-as-code, keys, certificates, installers, licences, and contacts—not only data.
- Build and test an isolated clean-room network with logging, security tooling, and controlled patch access.
- Protect and test break-glass access for cloud, identity, network, hypervisor, and backup platforms.
- Keep printed and offline response plans, call trees, decision authorities, and alternate communications.
- Run representative restores through application-owner acceptance and record actual RTO and RPO.
- Exercise a scenario where production credentials and collaboration systems are unavailable.
- Require containment, credential rotation, security validation, business sign-off, and monitoring before reconnection.
- Track exercise and incident findings to verified closure.
- Review reporting and privacy obligations with qualified legal and privacy counsel for the applicable Canadian jurisdictions.