Ransomware Data Recovery: What Can Be Recovered, and in What Order

What recovery means, and why the word hides four different problems

When an incident call opens with the words "we have been encrypted", four separate problems are being described at once, and they have different owners, different clocks and different evidence. Treating them as one problem is the most common reason recoveries stall in week three.

Data. Files, databases, mail stores, object storage and the backups themselves. The question is whether a usable copy exists, whether it predates the intrusion, and whether anyone has ever proved it restores. Encryption is loud; a silently corrupted backup is quiet and much more expensive.

Systems. Operating systems, hypervisors, domain services, the applications that make the data meaningful, and the configuration that ties them together. A restored database on a rebuilt server with the wrong service account permissions is not recovered, it is merely present.

Identity. Credentials, session tokens, certificates, service accounts, federation trusts, and every place an attacker could have left a key under the mat. If identity was compromised - and in the 2026 survey data it was the entry point in 79% of attacks - then every credential that existed at the time of the intrusion has to be treated as suspect, whether or not it was used.

Trust. The part nobody budgets for. Customers, regulators, insurers and your own staff need to believe the environment is clean. That is an evidence problem, and evidence has to be collected while the wreckage is still there.

Each of these can be recovered, degraded or lost independently. An organisation can restore every byte and still fail, because it restored an environment the attacker still had credentials for. It can also lose a large fraction of its data and recover commercially, because the data that mattered was in a system with an older, tested copy. The point of a recovery plan is to know which case you are in within the first day.

The order of operations that responders, insurers and courts all expect

The sequence is not arbitrary and it is not new. The incident response plan covers the general shape; the ransomware-specific ordering comes from the StopRansomware Guide published by CISA with MS-ISAC, the NSA and the FBI (current edition September 2023), and it has survived contact with real incidents better than most frameworks:

1. Determine what is affected and isolate it. Coordinated isolation, not a race to unplug machines one at a time. If several subnets look affected, isolate at the switch.
2. Do not power off unless a device cannot be disconnected from the network. Memory holds keys, injected code and connection state that will not exist after a reboot.
3. Preserve evidence from a sample. A disk image and a memory capture from representative affected hosts, plus telemetry exports, before anything is rebuilt.
4. Find the way in. Restoring into an environment where the entry vector is still open restores the intruder along with the data.
5. Eradicate and close. Remove persistence, close the vector, rotate credentials.
6. Restore into a clean, isolated environment, in dependency order, and validate before reconnecting.

The reason this order is enforced rather than suggested is that skipping step three or step four destroys the two things you cannot recreate later: the evidence that proves how the attacker got in, and the boundary of what they touched. Rebuilding first is the single most expensive mistake in ransomware recovery, because it converts a solvable forensic question into an unknowable one, and it usually produces a second incident three weeks later when the same credential is reused.

There is one legitimate exception. If the environment is still being actively encrypted and containment has failed, stopping the spread takes precedence over evidence collection on the hosts you are about to lose anyway. Even then, capture what you can from a host that is already encrypted and idle, because encrypted hosts are stable and are often the best evidence you have.

The first two hours: capture these before anyone touches a rebuild

Recovery decisions are made from evidence, and the window to collect it closes as soon as the first server is reimaged. The list below is the practical minimum for an organisation of any size, ordered by how quickly the artefact disappears.

• Volatile state on a sample of hosts. Memory image, running processes and loaded modules, network connections, DNS cache, mounted shares. If you cannot image memory, at minimum capture the process list, the listening ports and the content of any unusual service configuration.
• Ransom notes, in full, from every distinct location. Filename, hash and body text. The note is the fastest way to identify the family and it is frequently the only artefact the encryption left intact.
• Encrypted file samples and their extensions. Two files from two different directories, plus their exact sizes, so a decryptor can be tested against a known sample rather than against production data.
• Checkpoint and temporary files the encryptor left behind. Some families write progress files next to large files. Akira, for example, writes .arika checkpoint files recording the original file size, how far encryption progressed, the configured encryption percentage and the key material encrypted with RSA. Those files are normally deleted after a completed run but survive an interrupted one, and they change what is recoverable. They are worth more than most forensic artefacts and they are routinely wiped by well-meaning clean-up.
• Identity provider logs. Sign-ins, MFA events, token issuance, application consents, mailbox rule changes, new device registrations. Export before retention rolls over and before anyone resets a password, because resets generate noise that obscures the original access.
• Perimeter and remote access telemetry. VPN, firewall, proxy and DNS logs, with retention raised the moment an incident is declared. Attackers frequently enter weeks before they encrypt; the log that proves the entry date is the log that decides which backup is safe.
• Backup catalogue state. Which jobs ran, which finished, which failed, and what the backup infrastructure itself logged. If the backup server was domain-joined, assume its credentials were harvested and its job history is part of the crime scene.
• Asset and dependency information. The restore order cannot be improvised; it needs a dependency map, and the one in your CMDB is probably stale. A photograph of the real dependency chain, drawn on a whiteboard by the two people who know, is worth more than a stale diagram.

None of this requires a forensics retainer. It requires a checklist, a named person and the discipline to run it before the rebuild pressure arrives, which is usually within four hours.

Blast radius is bigger than the encrypted files, and it is where most recoveries fail

Encryption is a visible symptom. The damage that determines recovery time is usually in the configuration around the data, and it is invisible until something does not work after the restore.

Check for changes to: Active Directory objects, group policy, privileged group membership, certificate services templates and the CA itself; hypervisor and storage management interfaces; backup job definitions, retention settings and repository credentials; cloud identity, role assignments, conditional access policies, storage bucket policies and logging configuration; firewall rules and remote access configuration; DNS records that could redirect mail or authentication; software deployment and update infrastructure; and any management agent that can execute code across the estate.

The 2026 Sophos survey of 2,158 organisations across 17 countries, fielded in the first quarter of 2026, found that 56% of attacks succeeded in encrypting data, and that 16% involved both encryption and theft. That second number matters for recovery scoping: an attack that also stole data has a disclosure obligation running in parallel with the rebuild, and the data that was taken is not restored by any backup. If exfiltration is possible it should be assumed until the egress logs say otherwise, and the assessment belongs in the first day rather than the third week.

Why having backups is not a recovery plan

Almost every organisation that loses data to ransomware had backups. In the 2026 data, 66% of organisations that had data encrypted recovered it from backups, up from 54% the previous year - a genuine improvement, and still a description of the survivors rather than a guarantee. The failures cluster into a short list of recurring causes.

• The backup system was inside the blast radius. Domain-joined backup servers, repository credentials stored in a share the attacker could read, backup consoles reachable from the same management network. If the attacker can delete your backups with a domain account, they are not backups, they are another copy.
• Volume Shadow Copies were deleted. Most ransomware deletes them as a matter of routine. Any recovery plan that depends on previous versions rather than on a separate repository is a plan with one control the attacker removes first.
• The chain was incremental and the base is gone. Differential and incremental chains fail when a link is missing or corrupt, and corruption is exactly what an interrupted encryption run leaves behind on a repository that was mounted at the time.
• Nobody ever restored. A job that reports success proves that bytes were written, not that an application can start from them. The only backup that counts is one that has been restored to a clean host and opened by the application owner within the last quarter.
• Retention was shorter than dwell time. Thirty days of retention against an intrusion that began sixty days ago gives you thirty days of poisoned copies. This is the failure mode that turns a backup estate into an archive of the encrypted state.

The practical test is not a dashboard. It is a question with a number in the answer: what was the timestamp of the last successful full restore of our most important system, performed by someone who is not the person who built the backup job? If the answer is a date more than a quarter old, the recovery plan is a hope with a licence.

Which restore point: RPO against attacker dwell time

Restore point selection is the decision that most affects how much data you lose, and it is usually made in a hurry by someone looking at the most recent successful job. The correct restore point is the newest copy that predates the attacker's first access, not the newest copy that exists.

That means the entry date has to be established from logs before the restore is chosen. In practice this is where the timeline work earns its keep: a VPN login from a service account three weeks earlier, a new remote management tool installed on a server, an impossible-travel sign-in that was dismissed as noise. Once the entry date is known the arithmetic is simple and unforgiving. If the attacker was present for 21 days and retention is 30 days, the safe window is nine days wide and everything inside it is a compromise candidate. If the attacker was present for 45 days, there is no safe copy at all and the recovery becomes a rebuild plus a data reconstruction exercise, which is a different budget and a different conversation with the board.

The 2026 survey data puts recovery time at an average of three weeks, with 55% of organisations fully recovered within a week (16% in under a day), 83% within a month, and 3% taking longer than three months. Those averages are pulled up by exactly this problem: the organisations that took months are usually the ones whose safe restore point was old enough to require reconstructing business state rather than restoring it.

Two practical consequences. Retention has to be sized against realistic dwell time rather than against storage cost, which makes a 90-day immutable window a recovery control and not a luxury. And the restore should be tested against a second, older copy before it is trusted, because a copy that restores cleanly while containing the attacker's persistence is worse than an older copy that is genuinely clean.

The four copy classes, and what each one actually survives

Not all copies are equal, and the differences only show up under attack. It helps to sort them by what removes them.

Online, same-domain copies - snapshots, replicas, backup appliances joined to the domain. They survive disk failure, deletion and operator error. They do not survive an attacker with domain admin, which is the attacker you have. Treat them as operational convenience, not as ransomware recovery.

Online but credential-isolated copies - a separate repository with its own identity, no trust relationship to production, reachable only from a management network that production cannot route to. These survive most ransomware because the attacker cannot authenticate. They fail when the isolation is nominal: shared passwords, a single jump host, or an agent on every production server with write access to the repository.

Immutable copies - object storage with a write-once retention policy, or an appliance that enforces one. The relevant detail is whether immutability is enforced by the storage layer or merely configured by the backup application. Object lock in compliance mode, where even the account root cannot delete before expiry, is the version that survives a compromised administrator. Deletion protection set from the console the attacker reached is not.

Offline copies - tape, removable media, or a repository that is physically disconnected between jobs. The only class that survives total administrative compromise. It is also the slowest to restore from, and the one most likely to have been skipped in the last two cycles because nobody tested it.

A workable design uses all four, with the offline and immutable tiers carrying the ransomware use case and the online tiers carrying everyday restores. The question that separates a design from a diagram is throughput: a 40 TB restore over a 1 Gbps link is roughly 89 hours at line rate, and real restore throughput sits well below line rate. Any recovery time objective shorter than that has to be met by keeping a warm copy, not by hoping the link is faster than it is.

Restore order: identity, then storage, then workloads, then data

Restoring alphabetically, or by whichever team shouts first, produces the longest possible outage. The order that works follows dependencies, and it starts with the layer everything else authenticates against.

Identity first. Domain controllers, the identity provider, DNS, DHCP, certificate services and time. Nothing else can be trusted to start correctly until these are healthy, because everything else asks them for permission. This is also where the hardest decisions live: if Active Directory was touched, the rebuild is not a restore, it is a rebuild followed by a credential reset campaign.

Storage and virtualisation second. Hypervisor hosts from clean media, storage presented, network configuration applied from a known-good source rather than from a running-config backup taken after the intrusion.

Core infrastructure third. The backup infrastructure itself, monitoring, logging and the management plane, in that order - you want the ability to observe and the ability to restore before you start restoring business systems.

Business applications fourth, in revenue and safety order, with the data restore following the application rather than preceding it. Bringing up an application against an empty database and then loading data produces cleaner results than restoring a database and hoping the application accepts its state.

The whole sequence runs in an isolated segment with its own egress control, and systems move to production only after validation. This sounds slow. It is faster than a second incident, and it is what insurers now expect to see in the claim file.

The domain controller problem: KRBTGT, golden tickets and the day the restore becomes a rebuild

Active Directory is the system where a restore and a rebuild diverge most sharply, and it is the most common reason a technically successful recovery fails a security review.

The specific issue is the krbtgt account. Its secret signs every Kerberos ticket-granting ticket in the domain. If an attacker obtained that secret - and a domain admin level compromise is precisely what produces it - they can mint tickets for any account, with any group membership, with a lifetime of their choosing, without touching a single credential. Restoring a domain controller from a backup taken before the intrusion does not help if the backup contains the same krbtgt secret, and it does not help if you restore an old copy and leave the compromised password valid.

Microsoft's documented procedure is to reset the krbtgt password twice, with a replication cycle between the resets, so that tickets signed with either the current or the previous key are invalidated. That has to happen after the environment is contained, with service accounts and trusts evaluated first, because it invalidates every Kerberos ticket in the domain and will break whatever was holding a long-lived ticket. Expect application outages; schedule it deliberately rather than discovering it at 2am.

Around that core task, the domain rebuild checklist includes: reset every privileged account password twice where replication permits; rotate service account passwords and managed service account secrets; revoke and reissue certificates from a CA that was itself rebuilt, because a CA private key in attacker hands makes every certificate it issued a forgery candidate; clear and re-establish federation trusts and their signing certificates; remove all delegated permissions, then re-delegate from a documented model rather than from the old ACLs; and audit group policy objects and logon scripts for anything the attacker added, because both are excellent persistence mechanisms that survive a password reset.

The honest consequence is a schedule. A domain rebuild with a full credential reset typically takes days, not hours, and no business application should be returned to production before it is complete. Attempting to shortcut it produces the classic pattern: a recovered environment, a month of quiet, and a second encryption event that costs more than the first.

Virtualisation: when the unit of failure is a datastore, not a server

Recovery planning written for physical servers translates badly to a hypervisor estate, because the failure boundary changes. On a hypervisor, the attacker encrypts datastores and virtual disk files, and a single datastore usually holds dozens of machines. Recovery inverts: instead of restoring server by server, the platform has to be rebuilt before any workload can start, because the storage layer itself is the casualty.

That produces a sequencing consequence that is easy to miss. Identity comes first if Active Directory was affected, then a storage assessment, and that assessment decides everything that follows: it tells you whether you are running a restore exercise or a salvage-and-negotiation exercise. Only then does the hypervisor get rebuilt from clean media, with the management plane brought up on an isolated network, before any workload is registered.

Specific things to check before trusting a restored virtual machine: that the disk chain is complete rather than a snapshot delta pointing at a missing parent; that any VMware Tools or integration agents are reinstalled rather than restored from the compromised image; that the virtual hardware version and firmware type match what the OS bootloader expects; and that the machine does not carry a scheduled task or service installed during the intrusion window. A VM that boots is not a VM that is clean, and a hypervisor that boots is not a hypervisor whose management network was rebuilt.

Databases: why a restored instance still will not open

Databases are where restore projects quietly go wrong, because the backup can be perfect and the recovery still fails. The reasons are structural rather than exotic.

The backup is not a database. A file-level copy of a database's data files is only usable if it is crash-consistent with the transaction log at the same instant. Copying files from a running instance produces a set that the engine may refuse to attach, or may attach and then fail a consistency check on. Volume snapshots of a virtual machine are crash-consistent by construction, which is usually good enough and sometimes is not.

The log chain has a hole. Point-in-time recovery needs an unbroken log sequence from the last full backup to the target moment. If log backups were on the volume that was encrypted, the chain ends at the last full backup and the recoverable point is much older than the plan assumed.

Encryption touched pages, not files. Some ransomware encrypts selected blocks inside large files rather than the whole file. A database file with a partially encrypted extent may still let the engine start and then fail when a query reaches the damaged page, which produces a recovery that looks complete for days and then is not. Page-level checksums and a full consistency check after restore are the only way to know.

The application no longer matches the data. Restoring a database from three weeks ago against an application tier that has since been patched, or restoring the application and not the database, produces schema and migration mismatches that get mistaken for corruption.

The practical rule is to restore the database to an isolated instance, run the engine's own consistency check, run the application's own health checks against it, and reconcile row counts and key business totals against an independent source - a bank statement, a shipment count, a nightly extract held elsewhere. Reconciliation is not bureaucracy. It is the only step that proves the data is the data you think it is.

Partial encryption: the files you can recover without any key

Not every encrypted file is fully encrypted, and the gap is large enough to change recovery outcomes. Two mechanisms create it.

Intermittent encryption. To keep throughput high on large files, several families encrypt only a fraction of each block and leave the rest in clear. Akira is the best documented example: for large files it divides the file into blocks, encrypts a configured percentage of each block and leaves the balance untouched, and while encrypting very large files it writes a temporary .arika checkpoint recording the original size, progress, percentage and key material. When a run is interrupted, those checkpoints survive and the original file is often still present under its original extension with the checkpoint beside it. Tooling that understands the layout can reconstruct a usable file, sometimes completely, from the unencrypted regions plus the checkpoint.

Interrupted runs. Encryption killed mid-file leaves a file that is partly original and partly ciphertext. The original header, the file signature and often the first and last extents are intact, which means carving can recover some formats - media, archives, plain documents - while complex containers such as mail stores and databases usually cannot be reassembled reliably.

What this does not give you is general purpose recovery. Carving produces files without names, without folder structure and without timestamps, at whatever completeness the original encryption percentage allows. It is genuinely useful for a media archive or a document share, where the value is in the content. It is close to useless for an ERP database. Knowing which of your datasets is which is a decision to make before an incident, not during one.

Public decryptors: what No More Ransom actually covers

The No More Ransom project, run by Europol's European Cybercrime Centre with the Dutch police and private partners, is the first place to check and it is free. As of its own published figures it has helped more than six million people, offers over 120 tools capable of decrypting more than 150 ransomware families, and is available in 37 languages. The mechanism is the Crypto Sheriff: upload two encrypted files and the ransom note, and the service matches the artefacts against the toolset.

Three caveats decide whether it helps you.

Identification has to be right. File extension, note filename, note text and a sample hash are the discriminators. Families reuse each other's extensions, rebrands share code, and a tool run against the wrong variant does not merely fail - it can write over the ciphertext and destroy the only copy you had. Work on copies, never on originals, and keep the originals read-only.

Coverage is variant-specific, not family-specific. A decryptor published for a 2023 build is usually broken by the next build. Akira is the worked example: Avast released a decryptor for an early variant in June 2023, the operators changed the encryptor and the tool stopped working; a researcher published a GPU-assisted key-recovery method in March 2025 for certain Linux and ESXi variants, which requires substantial compute and covers neither the Windows encryptor nor later builds. There is no public decryptor for the current variants. A family name on a support page is not an assurance that your build is covered.

It recovers files, not systems. A decryptor does not rebuild a domain, remove persistence, restore a hypervisor or answer a regulator. It is one component of a recovery, and it is only worth attempting once you have a preserved sample and a clean place to write the output.

Vendor decryptors: decryption is not recovery

When a ransom is paid, the buyer usually receives a decryptor. What arrives is a binary with a key, and the gap between that and a working business is where the second half of the cost lives.

The documented failure modes are consistent across families. Decryption runs at a small fraction of the speed the encryption did, so a large estate takes days or weeks rather than hours. Large files fail: database files, virtual disks and mail stores are the ones that break, because they are the ones most likely to be partially written. Files without the expected trailer are skipped rather than repaired - in one published case the encryptor had been interrupted by a server crash, the partially encrypted files lacked the signature the decryptor needed, and the vendor tool restored one file and then errored on the next. Virtual machines decrypted successfully can still fail to boot, because the guest's own metadata was damaged. And the key is often usable only through the vendor's tool, so a second incident has no fallback.

The professional version of that story is a specialist writing a bespoke decryptor against the specific damaged layout, which is expensive, slow, and effective in the cases where the damage is systematic. It is not something to plan for. The recoverable conclusion is simpler: treat any decryptor, bought or free, as a data extraction tool that needs a clean target, a full consistency check and a reconciliation step, never as a substitute for a restored environment.

Paying: what the 2026 numbers actually say

The payment decision is usually framed as a moral question. It is more usefully framed as an evidence question, because the published data on outcomes is now reasonably specific.

In the 2026 Sophos survey, 48% of organisations whose data was encrypted paid a ransom - the lowest rate in three years - and 66% recovered from backups. Median demand fell to 698,000 dollars and the median payment to 769,000 dollars, with 51% of those who paid paying less than demanded. The mean recovery cost excluding any ransom was 1.7 million dollars, up 11% year on year. Two percent reported getting no data back at all. Read together, those figures describe a market where payment is neither necessary for most victims nor sufficient for the ones who do it, and where the cost that dominates is the recovery, not the ransom.

Payment also carries legal exposure that has nothing to do with the attacker. The US Treasury's OFAC advisory on ransomware, updated in September 2021, states that facilitating a ransom payment to a sanctioned person is prohibited, that sanctions liability is strict, and that organisations which pay without appropriate risk-based controls can face enforcement. In practice that means a payment decision needs a sanctions screen on the group and its known wallets, legal sign-off, and a documented process - which is why incident responders route it through counsel rather than through the negotiator alone. Several jurisdictions add their own constraints: insurers may exclude reimbursement, boards may have disclosure duties once materiality is assessed, and in some sectors a payment itself invites regulatory attention.

The evidence-based recommendation is narrow and unglamorous: exhaust backup restore and public decryption first, establish what payment would actually buy with a proof-of-decryption test on expendable files, and treat payment as a commercial decision with a legal opinion attached rather than as a technical recovery step. What payment reliably buys is speed on the files the seller chooses to decrypt correctly. What it does not buy is a clean environment, the absence of a second extortion, or protection from the regulator.

Negotiation mechanics if you do proceed

Negotiation is a specialised commercial activity and it is the one part of a ransomware incident where inexperience is visibly expensive. A few structural points matter regardless of who runs it.

• Never negotiate directly from a compromised mailbox. Use a dedicated communicator on clean infrastructure, with the identity of the negotiating entity separated from the operational response where possible.
• Buy a proof of decryption before buying a key. Test decryption on a set of expendable files that includes at least one large container and one database export. A seller who refuses a small test is telling you what the outcome will be.
• Establish what is actually being sold. Files, a decryptor, deletion of stolen data, or a promise not to publish. The last one is unenforceable and is usually resold to the next buyer regardless.
• Expect deadline pressure to be manufactured. Publication timers are a tactic, and the standard response - a clear statement that disclosure is already being prepared with counsel - removes most of its value.
• Document everything. Offers, counters, proofs and wallet addresses belong in the incident file, because the insurer, the board and possibly a regulator will ask for them.

What negotiation cannot fix is the part of the loss that exists because the environment was not recoverable in the first place. The organisations that negotiate well are usually the ones that already know their restore timeline and can credibly say so.

Stolen data and the second extortion

Encryption is increasingly the noise, not the business model. In the 2026 data, 16% of attacks both encrypted and stole data, and the theft-only cases sit outside that figure entirely. For a stolen-data case the recovery work is different: the systems may never have been encrypted, and the entire incident is a disclosure and containment problem.

The sequence that works is unglamorous. Establish what was taken, by dataset rather than by folder, from the exfiltration logs and the staging artefacts the attacker left; identify the data subjects and their categories, because notification obligations turn on personal data and special categories, not on file counts; preserve the exfiltration evidence in a form that survives a legal challenge; and assume publication is a scheduling question rather than a threat. Where a leak site is involved, monitoring it is a source of information about scope, not a negotiation lever.

Two practical errors recur. The first is treating a leak-site listing as proof of content: listings often include samples that misrepresent the volume, in both directions. The second is notifying before scope is known, which produces a second, corrected notification and a credibility problem. The deadline pressure is real, but a notification built on an assessed dataset is worth more than a fast one built on a rumour.

The regulatory clocks that start before recovery finishes

Recovery work and disclosure obligations run in parallel, and the second one has hard deadlines that do not move because the environment is down. The clocks that most often apply:

GDPR, article 33 and 34. Where personal data has been breached, notification to the supervisory authority is due within 72 hours of becoming aware, unless the breach is unlikely to result in a risk to rights and freedoms, and notification to data subjects follows where the risk is high. Article 33(4) allows staged notification, which is the provision that makes a disciplined approach possible: notify within the deadline with what is known and what is being investigated, then supplement.

NIS2, article 23. For essential and important entities in scope, an early warning within 24 hours of becoming aware, an incident notification within 72 hours with an initial assessment, and a final report within one month. The 24-hour early warning is the one that catches organisations out, because it lands while the incident is still being scoped.

Sector rules. Financial entities under DORA have their own incident classification and reporting timelines; healthcare, energy and telecommunications carry sector-specific obligations; and US-listed issuers must file a material cybersecurity incident on Form 8-K within four business days of determining materiality. The materiality determination is itself a documented process, and it is not a decision to make for the first time during an incident.

Contractual clocks. Customers, processors and payment schemes impose their own notification windows that are often shorter than the statutory ones. Those obligations are in contracts nobody reads during an incident, which is why the summary belongs in the incident response plan and the notification matrix belongs in the incident file.

The workable pattern is to assign the notification decision to counsel and the communications lead on day one, working from the evidence the response team is collecting anyway. A recovery team that discovers on day four that it owed a 24-hour warning has a second problem, and it is a regulatory one.

Evidence: what the insurer and the lawyer will ask for

Recovery decisions and claim decisions draw on the same evidence, and the file that satisfies one usually satisfies the other if it is built properly. What is asked for, in rough order of importance:

• A timeline with timestamps and sources: first access, lateral movement, privilege escalation, staging, encryption, detection, containment. Each entry attributed to a log or artefact rather than to recollection.
• Scope with the method used to establish it, including what was examined and found clean, not only what was found compromised.
• Chain of custody for images and copies: who collected, when, from which device, hash at collection and hash at analysis.
• The decision log for restore point selection, including why a later copy was rejected. Insurers increasingly ask why data loss was as large as it was.
• Cost records contemporaneous, itemised and separated into response, recovery, business interruption and any ransom. Reconstructed cost claims are the most commonly reduced part of a settlement.

This is one of the places where an outside firm earns its fee: not because insurers demand a brand, but because the artefact set is a specialist deliverable and it is much cheaper to collect once, properly, than to reconstruct afterwards. The forensics evidence guide covers the legal-standard version of the same material.

Validation before reconnection

The last mile is where recoveries that looked successful turn into repeat incidents. Validation is a checklist, not a feeling.

Confirm that the rebuilt environment has no path to the old one: separate credentials, separate management network, no shared service accounts, no restored trust relationships to systems that were not rebuilt. Confirm that logging and monitoring are live before the first business system returns, or you will be blind for exactly the period that matters. Confirm that the entry vector is closed and that the fix is evidenced - the patched appliance, the disabled account, the removed remote access tool - rather than asserted.

Then validate functionally, with the business owner present: the application opens, the reconciliation totals match, the integrations authenticate, the scheduled jobs run, the backups of the new environment complete and are themselves restorable. Return systems in waves with a defined observation window between them, so a problem is attributable to one wave rather than to the whole estate. Keep heightened monitoring for at least a month, because the documented pattern for repeat compromise is measured in weeks.

What recovery costs and how long it takes

Public numbers are averages and averages hide the distribution, but they are a better starting point than intuition. The 2026 Sophos figure for mean recovery cost excluding ransom is 1,700,200 dollars, an 11% increase on the prior year, with 20% of organisations reporting costs in the highest band. Recovery time averages three weeks: 55% inside a week, a further 28% inside a month, 14% between one and three months, and 3% beyond three months.

For planning, the useful output is not the average but your own two numbers: the time to restore your most important system from its best copy, measured, and the time to rebuild identity from clean media, measured. Everything else in a recovery plan is derived from those two, and neither is knowable from a vendor datasheet. An organisation that has measured them can give its board a credible worst case in the first hour of an incident, which is worth more than any framework maturity score.

If you are a thirty-person company: the realistic sequence

Most guidance is written for organisations with an incident response retainer, a security team and a tested DR site. The realistic sequence for a small business is shorter and much cheaper, and it still works.

Hour one. Disconnect the affected machines from the network by cable or by disabling the switch port, leave them powered on, and photograph the ransom note. Do not delete anything, do not run a clean-up tool, do not let anyone reinstall Windows "to get back to work".

Hour two. Call the insurer's incident line if you have cyber cover - the policy usually requires notification and often pays for the specialists - then your IT provider, then your lawyer if personal data is involved. Establish one person who speaks for the company and one person who speaks to the attacker, if anyone does.

Day one. Work out which systems are affected and which are not, find the last good backup and check whether it is offline or immutable, and check No More Ransom against two sample files and the note. Change the passwords on everything that is still reachable from outside, starting with email, remote access and the backup console.

Days two to seven. Rebuild identity and the file server from clean media in that order, restore the data that the business actually needs to trade, and accept that some history will not come back. In most small-business cases the honest answer is that two datasets matter and the rest is replaceable, and the recovery gets much faster once someone says so out loud.

What makes that sequence feasible is decided months earlier: an offline copy that is actually offline, a documented inventory of the two systems that matter, and a phone number for someone who has done it before. None of those require a security budget, only a decision.

What to fix afterwards so the next one is cheaper

Recovery capability is a set of specific controls, and the 2026 evidence points at a short list.

Immutable, credential-isolated backups with a tested restore. The 66% who recovered from backups are the positive case. The test has to be a real restore to a clean host, quarterly, owned by someone who is not the backup administrator.

Retention sized to dwell time. Ninety days minimum for the tier that carries the ransomware case, with the retention enforced by the storage layer.

Identity hardening, because identity is the entry point. The 2026 data found 79% of attacks beginning with compromised identity, and that 97% of the organisations whose attacks began with credentials had MFA in place somewhere - the gap is coverage and enforcement, not deployment. Phishing-resistant authentication for administrators, no standing domain admin, and session and token controls on the identity provider.

Recovery time measured, not assumed. Two numbers on a page, reviewed annually: restore time for the most important system, rebuild time for identity.

An incident response plan with the notification matrix attached, tested in a tabletop that includes the person who answers the phone at 2am. The planning guide covers the structure; the point here is that a plan nobody has rehearsed fails at the first unusual decision.

Egress visibility. If 16% of attacks include theft, then outbound data volume is a detection surface, and a business that cannot say what normal egress looks like cannot say whether data left.

Choosing outside help without being sold a miracle

Ransomware response attracts a specific kind of vendor, and the questions that separate a competent one from an expensive one are not technical.

Ask what they will do in the first four hours, and listen for evidence collection and containment rather than for a decryption product. Ask how they price: time and materials with a capped estimate is normal, a percentage of recovered data is not. Ask for the name and role of the person who will actually be on the engagement, not the partner who took the call. Ask whether they will work alongside your insurer's panel firm or replace it, because two lead responders is a slow response. Ask what happens if the data is unrecoverable - a good firm says so early and pivots to reconstruction, while a bad one keeps billing against hope.

Two red flags are decisive. A guaranteed restoration timeline is a sales claim, not an engineering one; nobody can promise a decryptor speed on data they have not seen. And any proposal that starts with rebuilding before scoping has misunderstood the problem: the correct first paid hour is spent establishing what is recoverable and how the attacker got in, because both answers change the plan that follows.

Where this leaves the decision

Data recovery after ransomware is mostly determined before the incident, by choices that are individually boring: whether the immutable copy is genuinely immutable, whether retention outlasts an intrusion, whether the restore has been tested by someone other than its author, and whether identity was hardened to the point where the credential route was closed. Everything in the response phase is easier or harder according to those four answers.

If you are reading this during an incident rather than before one, the order is still the same and it is still worth following under pressure: preserve, contain, scope, then decide. The organisations that emerge with their data and their reputation are rarely the ones that moved fastest; they are the ones that knew, on day one, which copy was clean and which systems had to be rebuilt rather than restored.