Ransomware recovery lead

When encryption lands, containment is somebody else's job for about an hour; after that the whole organization is waiting on the recovery lead. The role owns the recovery point decision, the wave plan, and the boundary between the dirty estate and the clean one. Every choice is a trade: the newest backup is the closest to the business's data and the most likely to carry the attacker back in. The lead is judged on whether services return in an order the business can use, whether anything is re-encrypted during return, and whether the after-action record turns the event into control uplift rather than a story.

• ·Assess recovery readiness before an incident: immutability, isolation, and which destructive actions are actually blocked.
• ·Map service dependencies and blast radius so the restore order is a plan, not a queue.
• ·Prove candidate recovery points in an isolated enclave before anything touches production.
• ·Record the trust decision — accepted or rejected, and why — for every candidate.
• ·Run forest recovery and credential rotation so recovered systems are not immediately reachable again.
• ·Stage reconnection behind gates, and hold the wave when the gate has not passed.
• ·Own the after-action record: timeline, decisions, gaps, control uplift, owner and date.

1. Hour 0Scope the impact
   Which services are down, which are degraded, and which are quietly fine. Establish the dependency map before promising anyone a time.
2. Hour 2Candidate triage
   Rank recovery points by how likely they are clean, not by how recent they are, and spend scarce restore capacity accordingly.
3. Hour 6Enclave proof
   Restore the leading candidate into isolation, scan it, boot it, and check for the persistence that would bring the intrusion back with it.
4. Day 2Identity first
   The forest comes back in an isolated recovery network with krbtgt double-rotated. Nothing else returns until it does.
5. Day 3Wave execution
   Bring services back in dependency order behind gates, while the business argues for its own service to go first.
6. Week 2After-action
   Write what worked, what did not, and the control changes that would have shortened this by days — each with an owner.

• Recovery readiness assessment

  Classify repositories by trust boundary, test destructive actions, and report the gaps with evidence.

  ran-101
• Dependency and blast-radius mapping

  Know what has to come back before what, and what the RPO gap costs in business terms.

  ran-110
• Recovery point trust decisions

  Integrity, security, application and business gates — and never promoting past one to save time.

  ran-120ran-130
• Clean rebuild and forest recovery

  Golden images, verified hashes, krbtgt double rotation and verified credential rotation.

  ran-201ran-210ran-220
• Running the recovery room

  Staff the roles, work injects on evidence under a clock, and file an after-action record that changes something.

  ran-401ran-410dr-405

• Backup and replication platforms with immutability and object lock
• Isolated recovery environments and clean-room enclaves
• Directory services and credential rotation tooling
• Golden image pipelines and hash verification
• Incident command tooling, dependency maps, and the after-action record

What separates a good analyst

• Refuses to promote an unproven recovery point, whatever the pressure.
• States the data loss in business terms before the business discovers it.
• Sequences by dependency instead of by whoever is loudest.
• Treats identity as the first service, not the last.
• Writes the after-action record while it is still uncomfortable.

• Cyber resilience lead — owns readiness across the estate rather than one event.
• IR manager — owns the whole response, not only the return to service.
• Business continuity manager — owns RTO/RPO with the business.
• Head of resilience or platform engineering leadership.