Case Study 2 — "Fully Recovered": The One-Paragraph Report That Became Evidence

DataField.Dev

Case Study 2 — "Fully Recovered": The One-Paragraph Report That Became Evidence

A recovery shop pulled a small business back from a ransomware attack and emailed a cheerful two-sentence summary: "Great news — fully recovered! All your data is back." Eight months later that sentence was Exhibit A in a lawsuit against the shop, because the recovery had been partial, the shop had no record of what it actually delivered, and a recovery report written for a happy client could not survive a hostile one.

Background

This is the book's third anchor case — the ransomware recovery — seen not at the moment of recovery but at the moment the paperwork is tested. Lindgren & Associates, a six-person accounting firm, was hit by ransomware on a Friday night. Their small RAID 5 file server was encrypted; the ransomware had run vssadmin delete shadows /all, destroying the Volume Shadow Copies; and their only off-site backup was an external drive a partner took home — which turned out to be roughly two months stale (Chapter 12 owns this scenario). They called a local data-recovery shop in a panic on Monday, the start of a busy quarter.

The shop did competent technical work. They imaged the array members before touching anything (the original is sacred — even in a hurry), reconstructed the RAID 5 stripe set and parity, restored what they could from the two-month-old backup, and carved a meaningful number of recent unencrypted documents from slack space and temp directories that the ransomware had not reached. By Wednesday the firm was operating again. It was, by any fair measure, a good recovery of a bad situation.

What the shop did not do was write it down properly. There was no evidence inventory, no record of the array's condition on receipt, no hash of anything, and — fatally — no honest accounting of what had not come back. The "report" was an email:

From: recovery@datarescue.example
Subject: RE: server — GOOD NEWS

Hi Dana — great news, your server is fully recovered! All your data is
back and running. Let us know if you need anything else. Invoice attached.

What went wrong

The trouble surfaced eight months later, in the middle of tax season. A client's IRS audit required Lindgren to produce a set of working papers and a reconciliation workbook from the prior year. The files were gone. They had lived only on the server, had been encrypted in the attack, were not in the two-month-old backup, and had not been among the documents carved from slack. They had never come back at all — and no one had ever said so, because the recovery report said "fully recovered."

Lindgren sued the recovery shop, alleging the loss of the audit files caused them professional liability exposure and the cost of reconstructing a year of records. Now the shop's casual email was the central document, and the Recovery vs. Forensics callout from this chapter played out in the worst possible way: a recovery report written for a service relationship was suddenly being read as evidence in litigation, and it could support nothing.

PLAINTIFF: "Your report says 'fully recovered' and 'all your data is back.'
            Was it, in fact, all of it?"
SHOP:       "No, not literally all — some recent files weren't in the backup
            and couldn't be carved..."
PLAINTIFF: "Where in your report do you say that?"
SHOP:       "We... didn't put that in the email."

PLAINTIFF: "Do you have a list of which files you recovered and which you
            did not?"
SHOP:       "Not a complete list, no."

PLAINTIFF: "Can you prove the files you returned were not altered between
            your shop and our office?"
SHOP:       "We didn't hash them, so... not really."

The shop had done good work and could prove almost none of it. There was no inventory establishing what arrived, no condition report, no hash list to show that what they delivered matched what they recovered, and — the wound that decided the case — a written claim of completeness that was simply false. Their competent recovery was now indistinguishable, on paper, from a careless one. The matter settled, expensively, against the shop.

The contrast

Set this beside Case Study 1. There, a forensic examiner facing a hostile expert won because her report drew its own lines: it stated what the evidence did not show, documented negative findings, and never over-claimed. Here, a recovery technician facing a hostile client lost because his report drew no lines at all: it stated only good news, documented nothing, and over-claimed completeness. The disciplines differ — one was proving facts for a court, the other restoring service for a client — but the report failed and succeeded on the same axes: an honest accounting of limits, a record tied to verifiable specifics, and a refusal to claim more than was true. A recovery report that had said "recovered approximately 85% of user data; the following categories were not recoverable: files created in the ~8 weeks before the attack that were both encrypted and absent from the backup; see attached inventory and SHA-256 manifest" would have been completely defensible — because it would have been true, and because the truth was already in writing before anyone went looking for it.

The analysis

Even a routine recovery report must quantify success honestly. "Fully recovered" is a claim, and an unqualified claim of completeness is the easiest sentence in the world to disprove. "Recovered 18,412 of an estimated 19,000 files; the remainder were unrecoverable for the stated reasons" is candid, accurate, and survives a hostile reader. The recovery report optimizes for restoring service, but its honesty about limits is exactly the same discipline a forensic report demands.
Document what you did NOT recover. The negative finding is as essential in a recovery report as in a forensic one. The shop's silence about the missing audit files was not a kindness to the client — it was the omission that destroyed both the client's records and the shop's defense. What you cannot recover is information the client needs more urgently than the good news.
Hash your deliverables, even with no court in sight. Integrity is about truth, not only admissibility (a lesson the recovery technician in Case Study 2 of Chapter 14 already knew). A SHA-256 manifest of the returned data would have let the shop prove that what it delivered matched what it recovered, and that nothing changed in transit — converting "we think we gave you everything" into "here is exactly what we delivered, provably unaltered."
The day a recovery becomes a case, your paperwork is all you have. The chapter's rule is blunt: write even routine recovery reports with enough rigor that, if the job ever turns into a case, the paperwork already holds up. The shop never imagined litigation — and that is precisely why it lost. You cannot add an inventory, a condition report, or a hash manifest after the dispute begins; by then it is too late, exactly as it is too late to add a chain of custody after a seizure is challenged.
A report written only for a happy reader fails the unhappy one. The email was perfect for a relieved client on a good day and useless for an adversary on a bad one. Professional reports — recovery or forensic — are written for the skeptical reader you hope never to meet, because that is the reader who decides what your work was worth.

Discussion questions

Rewrite the shop's two-sentence email as a proper recovery report for Lindgren: include an evidence/media inventory, the array's condition on receipt, the method, an honest success rate, an explicit list of categories not recovered, and a note about a SHA-256 deliverable manifest. Keep it client-readable but defensible.
The chapter's Recovery vs. Forensics callout says the two reports share a spine but optimize for different things. Using this case, identify two elements the shop could have borrowed from the forensic report (without turning a recovery job into a forensic one) that would have saved it — and two forensic elements (e.g., chain of custody, fact-vs-opinion separation) that would have been unnecessary overhead here.
⭐ Suppose the ransomware attack had also become a criminal matter or an insurance claim, so the recovered server data later needed to serve as evidence. Explain what the shop would have had to do differently from the first minute — and why "we did good technical work but documented none of it" is, for evidentiary purposes, nearly the same as having done nothing. Tie your answer to the cardinal rule and to chain of custody.
The shop's silence about the missing audit files was the omission that decided the case. Explain why, in both recovery and forensics, a documented negative result protects the writer as much as it informs the reader — and draft the one sentence the shop most needed to have written.
A relieved client on a Wednesday and a litigating client eight months later are the same person reading the same report with opposite intentions. How should that fact change the way a recovery technician writes every report — and what does it have in common with the forensic examiner's habit of "writing for the opposing expert"?