Encrypted Backups, Eight-Hour RTO

Immutability is the deciding property, not recency.

• On-prem NAS: disqualified as a first choice. It shares an authentication and network path with the compromised environment, the backup catalog is itself encrypted, and if the catalog is gone you cannot reliably identify which incremental set is clean. Restoring from it risks re-introducing the payload.
• Tape: viable but slow. Four-day recall blows an 8-hour RTO by an order of magnitude. Keep it as the deep-recovery / provable-clean fallback for systems that fail elsewhere.
• Immutable bucket: first choice for the order-entry tier. 30-day object lock means the attacker could not have altered or deleted it even with Domain Admin, which is the only source whose integrity does not depend on your compromised identity plane.

The caveat you must state The same service account that writes the bucket is Domain Admin, so the write path was reachable from the compromised estate. Immutability protects existing objects from deletion/overwrite, not from the attacker having pushed poisoned data in beforehand. So: restore into an isolated network first, verify content, and only then promote.

Judgement An 8-hour RTO is achievable from object storage, not from tape. Choose the source whose trustworthiness does not depend on the systems that were just compromised.

Restore into isolation, verify, then promote - never restore directly onto the production network.

Verification checklist, in order:

1. Clean credentials. The restored systems will carry the old domain password hashes and the compromised service account. Rotate the KRBTGT twice and reset privileged and service credentials before reconnecting, or you restore the attacker's access along with the data.
2. Restore point integrity. Confirm the object version and timestamp against the immutability window; check that the restore point predates the earliest evidence of compromise, not just the earliest encryption.
3. Shadow/partial-encryption ambiguity. The servers showing renamed files with intact contents suggest an incomplete or staged encryption run - meaning the dwell and staging time is longer than the encryption timestamps imply. Push the restore point earlier accordingly.
4. Persistent footholds. Image-level restores bring back scheduled tasks, services, and local accounts. Scan the restored image offline before boot in production.
5. Functional validation against the RTO, including the two of five systems that failed the last test - assume they still fail and have a manual workaround ready.

Judgement Recovery is not the end of the incident; a restored host with unchanged credentials is a re-entry vector, and the re-infection clock starts the moment it is reconnected.

Decision authority sits with executive leadership and legal/counsel, informed by you - not with the incident commander and never with the insurer alone.

Evidence they need before deciding

• Achievable restore time and confidence per tier, from actual test results, not vendor claims. You have a real data point: the last test failed 40% of systems.
• Whether decryption actually works and is complete - the partial-encryption servers suggest the operator may not be able to decrypt everything either.
• Legal exposure: sanctions screening of the wallet/actor, regulatory notification timelines, insurance policy terms.
• Whether payment is even necessary: if the immutable tier can restore the order-entry tier faster than negotiation, payment buys nothing and funds the next attack.

Your recommendation Restore from immutable storage in parallel with the negotiation decision, because these are not mutually exclusive and the 8-hour RTO does not pause for a board discussion. Do not pay on the basis of a decryption promise that has not been demonstrated on a sample.

Judgement Payment decisions go bad when the technical picture is presented as certain. Your job is to give a probability-weighted restore estimate with the failed test cited, so the decision is made on evidence rather than urgency.