Scenario Analysis: Ransomware Struck — How Is a 4-Hour Recovery Possible?

This article is a composite, anonymised account of recurring real-world cases; times and details are constructed for teaching purposes.

Picture a mid-sized trading company: 35 users, a file/ERP server at the centre, a sales team in the field. Monday 07:40 — the chief accountant opens the shared folder; a meaningless extension has been appended to every filename, and each folder holds a "your files have been encrypted" note. The same note sits printed on the office printer — it ran all night. This is the fork between two possible stories: the prepared business's four hours, and the unprepared one's week.

Minute by Minute: the Prepared Scenario

Time	Action	Why it matters
07:40	Discovery; the IT support line is called	The user does not "poke at the system"; the plan is triggered
07:50	Server and affected segment isolated from the network; Wi-Fi off	Encryption's spread is stopped — controlled isolation, not panic shutdown
08:10	Scope check: which machines, which shares, entry-point trail	Thanks to the inventory, "what do we have" is already answered
08:30	Decision: clean recovery — no ransom negotiation	An immutable backup exists; the bargaining table is never set
08:45	Server restored on the hypervisor from the 02:00 snapshot	The backup sits in immutable storage the attacker could not delete
10:30	ERP and file shares tested; passwords reset, MFA verified	The restore was rehearsed in drills — the duration is a measurement, not a guess
11:15	Staged bring-up from clean clients; two suspect machines reimaged	No infected endpoint re-enters the network
11:40	Operations resume: a sales invoice is issued	Total: about 4 hours; data-loss window: the last 6 hours of records

The Same Morning, Unprepared

Let the comparison be honest: when the same attack hits a business whose backup sat on the same server (and encrypted with it), with no drills and no inventory, the chronology runs differently — day one is lost to "maybe it will fix itself", day two to data-recovery firms, day three to contacting the address in the ransom note. Even when paid, the decryptor takes days to run and full recovery is not guaranteed; meanwhile sales have stopped, delays have been explained to customers, and the team is asking what happened to the payroll files. The difference is not technical but calendrical: the same event — a four-hour operational interruption in one business, a week-long crisis in the other.

The Five Preparations Behind the Four Hours

• 1. An immutable backup: attackers' first move is deleting or encrypting the backups; the backup in this scenario survived because it sat in storage with a write-protection window.
• 2. A rehearsed restore: the gap between "we have backups" and "we restore in this many hours" is quarterly drills; the restore that began at 08:45 was not being attempted for the first time that morning.
• 3. A written response sequence: who isolates, who decides, who handles communication — the recovery plan's single page is the panic moment's most valuable document.
• 4. Network segmentation: on a segmented network the encryption stayed in one zone; on a flat network, every client would have been hit the same night.
• 5. Target-time awareness: RTO/RPO targets accepted by management in advance (4-hour return / at most 8 hours of data) made that morning a matter of execution, not debate.

After the Recovery: the Work That Does Not Close

Returning to operation does not close the case. The next 72 hours' list: definitive identification and closure of the entry route (in this scenario, a remote access left exposed), rolling resets of all passwords, verification of endpoint protection against the incident logs, and a gap analysis against the layered defence model. If personal data was affected, the breach-notification process under data-protection law runs with management and counsel — notification has its own clock, and "we recovered, so no need" is not a defensible position.

Apply the Scenario to Your Own Business

Test your own 07:40 with three questions: Can an attacker reach your backups too? When was your last restore drill, and how many hours did it take? Does the person at the end of the phone know what to do in the first 15 minutes? If any of the three lacks a clear answer, this article's timeline does not yet apply to you — but it can: the distance is not technology, it is setup and habit.

Yamanlar Bilişim's Role

For our customers we build these five preparations as a standard package, put the drills on a calendar, and take over the response when the moment comes: isolation, recovery, root cause and report. The goal is the same everywhere: a ransom note that means the restore button, not a negotiation.

FAQ