Ransomware recovery looks different in a 200-person company than in the case studies written about large enterprises. There is no security operations center and no dedicated incident response team. There are two or three IT generalists, an outside provider or two, a cyber insurance policy and a leadership team that has never been through an incident. The technical steps are the same as anywhere. The constraints on who performs them, and in what order, are what shape the first week.
This post walks through what recovery involves at that scale, where the time goes and what can be prepared in advance by a small team.
The starting position
A company of this size typically runs between fifty and a few hundred servers, most of them virtual, plus Microsoft 365 or a similar cloud suite. Identity is a single directory. Backups are handled by one product writing to one or two repositories. The same few administrator accounts can reach nearly everything. That concentration is efficient in normal times, and it means an attacker who obtains one privileged account can usually reach the backup server as well as production.
How the first week tends to unfold
| Period | Main activity | What slows it down |
|---|---|---|
| First hours | Contain: isolate networks, disable accounts, stop the spread | Uncertainty about scope, fear of making it worse |
| Day 1 | Engage insurer, incident response firm and legal counsel | Finding policy details and contacts when systems are down |
| Days 1 to 3 | Establish what is affected and when the intrusion began | Missing logs, forensics working alongside recovery |
| Days 2 to 4 | Rebuild identity and core services in a clean environment | No documented build order, credentials stored on affected systems |
| Days 3 to 7 | Restore business systems in priority order | Restore throughput, choosing safe restore points |
| Weeks 2 to 4 | Restore remaining systems, rebuild endpoints, return to normal | Staff exhaustion, backlog of ordinary work |
The timings vary widely. The sequence is consistent, and the restore itself is only one part of it.
Whether the backups survived
Everything else depends on one fact established in the first hours: is there a backup the attacker could not alter? Attackers routinely look for the backup server, delete restore points and remove repository contents before encrypting production. If the only copies sat on storage reachable with a domain administrator account, they are often gone.
A copy that is immutable at the storage layer changes the position entirely. The backup server may be compromised and its catalog lost, but the restore points remain and can be imported by a rebuilt server. What survives a compromised backup server goes through that scenario in detail.
Choosing where to restore from
Intruders are often present for days or weeks before encryption starts. The most recent backup may contain their tools or accounts. Restoring it brings the problem back. The incident response firm will estimate when the intrusion began, and restore points are chosen from before that date for systems that hold executable code, with more recent points used for data. This is why retention needs to reach back further than a week or two. Choosing a clean recovery point describes the method.
Rebuilding the foundation first
Business applications cannot start without identity, name resolution and networking. Those come first, and they are usually rebuilt, not restored, so that nothing from the compromised environment carries over. The backup server is in the same category. A fresh installation that imports the immutable repository is safer than trusting the original. Trusting the backup console after ransomware explains why.
A small team should know this order in advance. A one-page list of the first ten systems to bring back, with their dependencies, saves a day of discussion at the worst time.
Restore speed sets the timeline
Once restores begin, the pace is set by how fast data can be read from the repository and written to production storage. A company with 20 TB of critical systems restoring at a sustained 300 MB per second needs about 19 hours for the data alone. At 50 MB per second, which is not unusual from a small NAS or a cloud tier over a modest link, the same restore takes nearly five days. Knowing that figure beforehand is the difference between telling the business two days and telling it a week. Mass VM recovery planning covers how to order and parallelize a large restore.
People are the scarcest resource
Three administrators cannot work around the clock for a week. Decisions degrade after the second night. A realistic plan assigns shifts from the start, uses the outside providers for hands-on restore work and keeps one person free to coordinate and communicate. Leadership needs a single point of contact and updates at fixed times, so that the people doing the work are not interrupted every hour.
What to prepare beforehand
Five preparations make the largest difference at this scale. An immutable backup copy outside the reach of domain accounts. Printed or offline copies of the insurance policy, key contacts and the system build order. Recovery credentials and encryption keys stored somewhere that does not depend on the affected environment. A measured restore speed for the largest critical system. And one rehearsal a year in which the team restores a core system as if the directory were unavailable. Running a cyber recovery drill gives a format for that exercise.
Where ARTESCA fits
ARTESCA is object storage software used as a backup target, deployed on servers the customer runs. Immutability is provided by S3 Object Lock on each object, and in compliance mode no account, including ARTESCA administrators, can remove a lock before it expires. The repository has its own administrative accounts, separate from the production directory, so a compromised domain account does not give access to it.
ARTESCA can span several servers and grows within the same deployment from roughly 50 TB to 8.5 PB. It is used as a target for Veeam and other backup software.
The measure that matters
For a company of 200 people, a good outcome is being back in operation within days with data intact, without having paid for a decryption key. That outcome is decided before the incident, by whether an untouchable copy exists, whether the team knows the order of work and whether anyone has measured how long the restore will take.