The Ransomware Recovery Timeline: From Hour One to Day Seven

A hypothetical walkthrough of ransomware recovery at a contractor, showing what to do in each phase and which backup decisions determine how fast you return.

4 min readBy Ironfield Cyber Team

When ransomware hits, the first hours feel chaotic, and decisions made in them shape the next week. Consider a hypothetical 60-person commercial contractor that arrives Monday morning to find file shares locked and a ransom note on the screen of the server that hosts its accounting system. What follows is a realistic outline of how recovery should proceed, and where backups make or break the timeline.

This is an illustration, not a case study. Real incidents vary, but the phases are consistent.

Hour one: contain, do not clean up

The first instinct is to start fixing things. Resist it.

  1. Isolate affected machines. Disconnect them from the network by unplugging cables or disabling Wi-Fi. Do not power them off unless instructed, since memory can hold useful evidence.
  2. Call your incident contact. That means your IT provider or incident response firm, and your cyber insurer's hotline if you have a policy. Many policies require notification before certain steps.
  3. Preserve evidence. Do not wipe machines or delete the ransom note.
  4. Protect the backups. Immediately check that backup systems are disconnected from the affected network or that their credentials are changed. Attackers often try to destroy backups first.

Hours two to twelve: scope the damage

Responders determine what was affected, how the attacker got in, and whether they are still present.

  • Which servers, workstations, and cloud accounts show signs of compromise?
  • Were administrator accounts stolen?
  • Was data copied out? Many attacks now include theft before encryption.
  • Is the attacker's access closed? Restoring into an environment where they still have access invites a second attack.

At the same time, leadership decides how to run the business. Can project managers and superintendents work from phones and personal hotspots? Can payroll run manually? Having a rough fallback plan in writing before an incident makes this much easier.

Day one to two: decide about restoration

Leadership meets with responders to understand the options. The deciding factor is the state of your backups:

  • Clean, recent, accessible backups mean you can rebuild and restore with confidence.
  • Partial backups mean some data returns quickly and the rest takes longer.
  • No usable backups leave the business facing difficult choices, none of them good.

Paying a ransom is a business and legal decision with no guarantee of recovery, and it can raise legal considerations. It should involve counsel, your insurer, and law enforcement guidance, not a quick call made under pressure. Reporting the incident to the FBI and CISA is strongly encouraged.

Day two to four: rebuild in a clean order

Recovery is not simply pressing restore. A typical order:

  1. Rebuild or verify the identity systems, and reset all passwords, especially privileged accounts.
  2. Restore the most critical business systems, such as accounting and job cost, email, and the project platforms that do not live in the cloud.
  3. Bring back file shares in order of priority, starting with active projects.
  4. Rebuild user devices, either from a standard image or from verified clean state.
  5. Reconnect locations and jobsites in stages, scanning each as it returns.

Test each restored system before declaring it ready.

Day four to seven: stabilize and communicate

  • Monitor closely for signs that the attacker has returned.
  • Review obligations to notify customers, employees, or regulators if personal or contract-protected data was involved. This is where counsel is important.
  • Communicate with project owners, sureties, and key subs honestly and promptly.
  • Document what happened, in order, while memories are fresh.

The backup decisions that set the timeline

The speed of this entire process comes down to choices made before the incident:

  • Offline or immutable copies. At least one copy of your data that attackers cannot alter or delete with stolen credentials.
  • Recovery testing. A backup that has never been restored is a hope, not a plan. Test restores, and time them.
  • Recovery priorities. Decide in advance which systems come back first, and how long each can be down.
  • Separate credentials. Backup systems should not use the same administrator accounts as the rest of the network.
  • Cloud data coverage. Microsoft 365 and other cloud services need their own protection plan, since the provider's responsibility has limits.
  • Documentation. Keep network diagrams, license keys, and contact lists in a place that is not on the affected network, including on paper.

After the incident

Hold a review within a few weeks. Fix the root cause, whether it was a phished password, an exposed remote service, or a missing patch. Update the response plan and training. Tell your insurer what changes you made.

A practical next step

Ironfield Cyber helps contractors and energy companies design backup strategies that survive ransomware, test restores, and write response plans before they are needed. If you cannot say how long it would take to restore your accounting system, a restore test is a good place to begin.