Data Recovery Case File · Solid State & Flash · The Priority List

Recover Files From a Failed SSD: the Priority List

His enquiry did something almost no enquiry does, and it improves the job in four separate ways. A Surface Book laptop, non-responsive, with repair declared not possible: "I'm not concerned about the laptop, but I do need the data. Stupidly I have not backed it up in a while." Then, numbered: the local mail store holding his archived email from 2017 onward, sent and received; the contacts saved in the same client; everything in his desktop folders; and his locally stored browser bookmarks. Finally the two questions worth asking any lab: "have you experience in getting data from this type of SSD, and what would be the realistic outcome?" Both get answered below — but the priority list deserves its own paragraph first, because it changes what recovery even means for him, and almost nobody supplies one.

The decode: why the list matters, what the SSD question turns on, and the honest outcome

Why a priority list changes the job: four ways, and they are all practical. It defines success, so nobody is guessing whether a recovery has worked — if the mail store and the desktop are back, it has. It allows staged delivery, so the most important material can be extracted and handed over first rather than everything arriving at the end. It makes partial results meaningful: where a drive yields only some of its contents, effort goes where he has said it should rather than into whatever the catalogue happened to list first. And it can act as a cost lever, because a defined subset is sometimes a smaller job than an exhaustive one. Most people ask for "everything", which is understandable and is very often not what they actually need.

What his SSD question turns on: "this type of SSD" is the right thing to ask, because Surface devices are not one thing. Some generations use a removable module of a small form factor, reachable without touching the board — in which case the module comes out, is read on native equipment, and the failed machine becomes irrelevant. Others integrate storage onto the mainboard, which makes this board-level work with correspondingly different odds and honesty. That single question decides the route, and it is the first thing an assessment establishes rather than something to be assumed from a model name.

The question that outranks it: encryption. Modern Windows devices are frequently encrypted by default, and the consequence is absolute: without a legitimate key, a perfectly imaged drive yields nothing readable. So before any physical work is quoted, the encryption status is established and — if it is on — the key is located. It lives in one of a few places: the account signed in when protection was enabled, a printout or file saved at setup, or an organisation's IT if the device was ever managed. This archive's position does not vary: legitimately-held keys only, and where no lawful key exists the limit is stated plainly rather than worked around. That check costs nothing and it should always precede the bench.

His realistic outcome, honestly: where the storage is removable and either unencrypted or accompanied by his own key, the outcome is good and his four categories are all straightforwardly recoverable. Where storage is board-integrated, the work is specialist and the odds are stated per assessment rather than promised. One technical note on his first two items: archived mail and contacts in a desktop client live in a local database, not as individual messages. They are recovered as a store and then opened in the same client, which restores mail and contacts together — so those two priorities are effectively one recovery, and verification means loading that store and reading a message from 2017 rather than counting files.

On the bench

The order of questions was preserved. Encryption status was established first, and the key question settled with him in writing before any physical work was quoted. The storage type was then determined rather than assumed — removable module or board-integrated — and the route followed accordingly: the module read on native equipment where it came out, board-level assessment with findings in writing where it did not. Decryption, where required, ran against his own credential through Passware Kit Forensic, the only kind of key this bench turns. Extraction then followed his numbered list in his order: the local mail store lifted whole and opened in the same client to confirm archived and sent mail from 2017 onward and the contacts alongside it, the desktop folders extracted and verified by opening, and the browser profile recovered for its bookmarks. Delivery was staged, most important first.

The outcome

The prioritised material recovered and verified in the order he set, delivered in stages. Free assessment, one fixed written figure including VAT; where a chip has to be removed, 50% of parts and labour is payable upfront with the balance only on success — otherwise no recovery, no fee. Three things worth copying from how he asked: supply a priority list, because it defines success, permits staged delivery, makes partial results meaningful and can reduce scope; ask what type of storage your machine actually has, since removable and board-integrated are different jobs with different odds; and settle the encryption question before anything else, because without a lawful key a perfect image is unreadable. Archived mail, incidentally, comes back as a database rather than as messages — recovered whole and reopened in the client that wrote it.

Our case files are drawn from genuine enquiries received by our laboratory over the past ten years, anonymised to protect client confidentiality. Each one describes the diagnostic and recovery procedure our engineers apply to that fault, using the equipment listed.