§ PDF library

Ask The Library

Ask a question about disclosure, digital forensics or evidence handling and get an answer drawn from the text of our published UK guides, with citations you can open at the exact passage.

Ref · E-D · 2026 · §ASKClass · ConfidentialJuris · England & WalesStatus · Active

Ask the library

Ask a question in plain English. The assistant reads the full text of every guide and Knowledge Centre article, answers from what it finds and points you to the most relevant PDF.

Answers come from published material only and are general information, not legal advice. Conversations are saved in this browser.

Answers are drawn only from the wording of our published guides and Knowledge Centre articles, with a citation you can open at the exact passage. This is general information about our published material, not legal advice. Browse the full library or read the library FAQ.

Answers written from the guides

These are the questions visitors ask most often, each one answered in full from the wording of the published guides rather than a single FAQ line.

A witness offers screenshots of expired chats. How much weight can they carry?

Screenshots of expired chats can carry substantial weight if properly authenticated, but unauthenticated screenshots are the weakest class of messaging evidence.

The difference in evidential value comes

Sources: Signal And Ephemeral Messaging, WhatsApp Evidence

Put this to the assistant

The opponent says the messages expired innocently under settings predating the dispute. Does that end it?

No, it does not end the matter, but rather shifts the focus to what happened after the duty to preserve arose.

While it is true that "pre

Sources: Signal And Ephemeral Messaging

Put this to the assistant

Questions the guides already answer

Every pair below comes from a published guide. Open the guide for the full wording, or put the question to the assistant above.

Digital Forensics In Corporate Fraud Investigations

We suspect fraud but are not certain. Should we investigate before involving lawyers?
Involve them first: the privilege structure (§7) only protects an investigation built inside it, and the covert phase (§4) needs legal design around monitoring, scope and employment risk: in form a l look-arounds spend both protections and often tip the suspect: guide 97 Example 2 at higher stakes. Suspicion is exactly the moment the structure is cheap.
How do we investigate without the suspect finding out?
Server-side: holds, log exports and admin-level preservation invisible to users (§4), device work inside routine cover where lawful, and a need-to-know circle small enough to hold: most tip-offs are internal and accidental. The phase ends deliberately, with confrontation timed after preservation and with guide 97's letters ready for the personal estates.
Can forensics really prove a document was backdated or fabricated?
Frequently, from internal evidence: author in g artefacts against the claimed date, session and save-count patterns, resource anachronisms, absent transmission records and surviving true versions (§6, guides 87 and 109): Example 2's certificate is the standard demonstration: with conclusions graded to what the artefacts support. The strongest cases pair the internal evidence with the counterparty's clean copy.
Should we report to the police, and when?
Weigh it with advice (§7): referral can stay civil proceedings, affect insurance and regulatory positions, and remove control of tempo: while some duties and policy terms require or reward early report: the decision is strategic and matter-specific. What the forensic file guarantees is that which ever order is chosen, the evidence is ready for both standards.
Ask about this guide

File Wiping Anti Forensics And The Evidence They Leave Behind

The other side's laptop is completely empty. Can anything be recovered?
From wiped regions, honestly, no (§6); from what the tool missed (journals, shadow copies, alternate streams) and from the estate the party did not control (syncs, backups, counterparts), frequently a great deal (Example 1's 1,100 files). And the wipe itself, dated and scoped from the tool's artefacts, is often worth more than the content: courts infer against destroyers.
Can an expert tell the difference between routine clean-up and deliberate destruction?
Usually: routine tools run on schedules with long histories, target predictable locations and pre-date the dispute (Example 3); deliberate destruction is installed recently, executed in bursts, targets the disputed material selectively, and clusters around the duty date (Example 1): §7's timing and selectivity, with the journal showing whether bulk deletion preceded the run.
A phone was factory-reset before h and over. Is the evidence gone?
The device's contents, largely; the case, rarely: the reset is timestamped in firm w are and re-enrolment records, pre-reset cloud backups often survive (Example 2), counterparties hold their copies of every message, and the platform logged the account's activity. The reset becomes the exhibit; the backup becomes the evidence.
What if the data was encrypted rather than wiped?
Encryption conceals rather than destroys: the enablement is dated (§5), the data exists, and the with hold in g of keys after an order is a conduct question with serious consequences (guides 117-118): distinct from the technical impossibility of decryption, which the examiner states honestly. The court is told when, and asked to draw the conclusion.
Ask about this guide

OSINT Open Source Intelligence In Litigation

If information is public, can we just use it?
Gather it law full y, yes, but two cautions apply (§5, §6). First, public does not mean proven: open material is often wrong, stale or fabricated, so it must be verified, dated, attributed and corroborated before it is relied on. Second, gathering and using personal data still engages the UK GDPR and must be lawful and proportionate, and the gathering must stay within access laws and platform terms. Public material is a starting point for evidence, not evidence in itself.
Why is a screenshot not good enough?
Because it proves almost nothing on its own (§4, Example 1). A screenshot can be edited or fabricated, carries no reliable date, and has no verifiable link to a real source. Properly captured OSINT records the live URL, the page source, timestamps and metadata, is hashed, and its method is documented, so its authenticity and its state on the capture date can be proved. That is the difference between evidence that holds and an image that is challenged away.
Can we set up a fake profile to see a private account?
No (§6). Creating fake profiles to befriend or deceive a subject, logging into others' accounts, or circumventing access controls is unlawful or unethical, taints any evidence obtained and exposes the practitioner. OSINT works with genuinely public material gathered by honest means. Where information sits behind access controls, it is obtained by lawful process, disclosure, orders, not by deception or unauthorised access. The line is firm: public means public.
How do we know a social-media account belongs to the person?
By corroboration, not assumption (§5). Accounts are impersonated, shared and fake, so a name or photo is not enough. Attribution is built from corroborating evidence, consistent details across posts, connections, reused handles, and, where available, device and account forensics linking the account to the person (guides 105, 126). The honest position is stated: the account is attributed to the person where the evidence supports it, and left unattributed where it does not.
Ask about this guide

Damaged Computers And Data Recovery

The laptop will not turn on. Is the data gone?
Almost never, if the fault is power or board failure, which is the commonest presentation (§3): the storage is untouched and only the path to it is broken, so the drive is transplanted into working hard w are or read directly and the data recovered intact (§4, Example 1). Broken usually means the machine failed, not the storage. Send it for forensic recovery unaltered, do not let a repair shop tinker with it first.
The phone was smashed or soaked. Can anything be recovered?
Often yes: the screen and board may be destroyed while the memory chips survive, and where the board is dead the chips are removed and read directly (chip-off, §4). A wet phone should be powered off and sent promptly, drying and switching it on risks corrosion and can destroy what a proper recovery would retrieve (§5). The honest exceptions are a genuinely burned or shattered chip, where the data is gone.
How can you tell if a device was broken deliberately?
From the pattern, the timing and the account (§6): general damage suggests an accident, targeted damage to the storage suggests method; damage dated against the dispute is suspicious; and a claimed cause that the physical evidence contradicts, a "fire" that is really impact (Example 2), is a classic tell. Where a device was wiped before being smashed, the digital and physical evidence together tell the story (guide 110).
Does recovering a damaged drive also decrypt it?
No: physically recovering the storage and decrypting it are separate problems (§5). A chip-off of an encrypted phone yields encrypted data that still needs the key (guides 117 to 118), so a recovery commissioned without an encryption plan is only half done. Plan both from the start: recover the storage, then obtain the key by the recovery-key or compulsion routes.
Ask about this guide

Recovering Evidence From Deleted Microsoft 365 User Accounts

IT deleted the account last week. Is the data gone?
Almost certainly not yet: the account is soft-deleted and restorable in full for the platform's window (currently 30 days), One Drive has its own retention period, and any hold in place has made the mailbox inactive (§3). Restore today, hold, collect: Example 1's sequence. The answer changes with every day of delay.
What is an inactive mailbox and how do we get one?
A mailbox preserved after its user is deleted because a litigation hold or retention policy applied at deletion: no user, no licence, contents searchable and exportable for the hold's life. It is created by holding the mailbox before deletion, or by restore-hold-delete inside the soft-deletion window (§5): the mechanism a litigation-aware leaver process invokes for anyone relevant.
The account was hard-deleted a year ago with no hold. What now?
Reconstruction (§6): the custodian's correspondence from counterparts' mailboxes and external parties, their work product from shared stores, their chats from other members' copies, their activity from audit logs, and their stores from backups and devices where they exist: Example 2 rebuilt a central custodian this way with measured coverage. The account's stores are gone; the footprint largely is not.
Our leaver process deleted a relevant account after the dispute began. How bad is it?
It depends on the duty date and what remains: deletion after contemplation is a preservation failure (§7) whose consequences scale with the gap and its explanation: mitigated substantially by prompt, honest reconstruction and candid evidence about the process. Fix the process now for every other custodian; the second deletion is the one that turns a failure into a pattern.
Ask about this guide

How Lawyers Should Instruct A Digital Forensic Expert

Does the Forensic Science Regulator's Code apply to a defence-instructed expert?
Yes: the Code regulates forensic science activities in the criminal justice system of England and Wales regardless of who instructs, and the declaration requirement applies to every practitioner's report: Example 1's defence expert learned this at the admissibility hearing. Ask the Code question at selection; check the declaration before service.
Our preferred expert cannot declare full compliance. Can we still instruct them?
Often yes: non-compliance is declared, not concealed, with the mitigations annex (competence, method validity, documentation, equipment, environment) prepared per the Regulator's guidance: and the court weighs the evidence accordingly. What is fatal is the missing declaration or the unprepared annex, not honest non- compliance in an activity where accreditation is still building.
Will the court see our letter of instruction?
In civil work the report must state the substance of all material instructions (CPR 35.10), and the court can order disclosure of the instructions themselves where there are reasonable grounds to think the statement is inaccurate or incomplete: Example 2's sentence reached the judge that way. Draft every letter on the assumption that it will be read.
Can we comment on the expert's draft report?
On accuracy, completeness, comprehensibility and compliance with the rules, yes; on the opinion, no: the line between clarifying and author in g is the independence the report asserts, and opposing counsel will probe draft history and communications where they suspect it was crossed. The Guidance for the Instruction of Experts in Civil Claims sets out the permitted scope.
Ask about this guide

Collecting Evidence From Microsoft Teams Private And Shared Channels

We collected the whole team. Why would private channels be missing?
Because "the whole team" means the team's group mailbox and Share Point site, and private channels write to neither: their messages go to member mailboxes and their files to separate sites (§3). The collection was complete for standard channels and blind to the rest: Example 1's omission, and the reason the census comes first.
A private-channel member has left the company. Is their contribution lost?
Not necessarily: their compliance copies persist in their mailbox as long as it exists (inactive mailboxes under hold survive the leaver process), other members' mailboxes hold the same messages for their overlapping membership periods, and the channel site, audit layer and device caches supply alternates (§8, Example 2). What loses the contribution is a mailbox purged before anyone held it: the clock the census exists to beat.
How do we know the census is complete?
From the administration layer: Teams admin data, directory records and Graph enumeration list channels by type with creation, membership and site details, and audit logs record channel lifecycle events: the census is drawn from those records and reconciled against them, not from asking users. On contested completeness, an independent examiner's enumeration under agreed terms settles it (§7).
Can deleted private channels be recovered?
Within the platform's restore window (currently around 30 days, verify per matter), the channel can be restored; afterwards, message copies survive in member mailboxes subject to retention, and the channel's site follows its own deletion and retention rules (§4). Two clocks, both checked: and the audit layer proves the channel existed either way.
Ask about this guide

Can You Prove Who Deleted A File

If a file is gone, how can anyone know who deleted it?
Because deletion writes records the deleter does not see: the platform's audit event naming the account, the recycle bin's metadata naming the profile and time, the file system's journal recording the transaction (§3-§4): Example 1's purge sequence was reconstructed entirely from those. The content's absence and the act's record are separate things.
Does emptying the recycle bin remove the evidence of deletion?
It removes the item and, in time, the bin's metadata file: but the emptying is itself an audited or journaled event, the metadata file persists in unallocated space for a period, and the platform's second-stage store holds cloud items longer (§3-§4). Emptying the bin usually adds a second attributed event rather than removing the first.
The laptop came back wiped. Is there anything to find?
Often the most important thing: the wiping tool's installation and execution records, its settings, the overwrite pattern and the change journal it did not target (§5, Example 2): deliberate erasure after a duty arose is stronger evidence than the erased files would have been. The device is imaged first and the tool's receipt read second.
Can we prove it was the person and not just their account?
To the extent the corroboration allows: session and device from sign-in records, presence from badges or calendar, their own messages about it, and the exclusion of alternatives (shared login, unattended desk, sync, policy) (§6): the report grades the attribution accordingly. "Account X on device Y at 23:12" is a finding; the name follows when the lattice supports it.
Ask about this guide

Recovering Previous Versions Of Cloud Documents

Are prior versions really "documents" we have to disclose?
They are documents; whether they fall within scope is an issues-and-proportionality question answered in the DRD (§7). Where a document's date, authorship or content history is in issue, its ladder is usually squarely relevant; for the bulk of a corpus, agreed limits are normal. What is not acceptable is silently producing finals only because the export defaulted that way.
The version history on our key document is missing. Does that look bad?
It looks like a question, and the audit log usually answers it: version limits, migrations, moves and copies flatten ladders innocently every day (Example 2), while user-initiated version deletion during a dispute is logged and looks exactly as bad as it is. Establish the cause from the records before anyone characterises it, in either direction.
Can the platform tell us who made a specific change?
To the account that saved the version containing it, yes: diffs localise the change to a rung, the rung names the account and time (§6): with co-authoring caveats (several editors in one session) and the guide 105-107 disciplines joining account to person. Example 1's 23:40 deletion was attributed exactly that way.
We only have the document as an email attachment. Is that enough?
It is a snapshot with a date bracket, useful for hash-matching and for proving a state existed: but it has no ladder. Find the original platform location and collect there (§5); the attachment then corroborates the rung it matches. Collecting only copies is the most common way a case loses history it never knew it had.
Ask about this guide

Geolocation Evidence

Which location source is the most reliable?
It depends on the conditions, but as a rule a good GPS fix is the most precise (metres), Wi-Fi positioning is moderate (tens of metres), and cell-tower data is only approximate (an area), with photograph EXIF as good as the fix the camera had (§3, §4). No single source is authoritative in all conditions, which is why the method is not to pick the best source but to converge several, each at its honest confidence (§6).
The other side says a cell record puts our client at a specific address. Is that right?
Almost certainly overstated: a cell-tower connection places a phone within that cell's coverage, an area that can span hundreds of metres or kilometres, not at a specific point (§4, Example 1). It is one of the commonest over claim s. A specific address is merely one place within the cell's area, and more accurate sources, GPS, Wi-Fi, EXIF, should be brought in to test whether the client was actually there.
Does location data prove our client was there, or just their phone?
Strictly, the device (§6): phones are lent, left and shared, so location records place the device, and attribution to the person requires corroboration. Usually the device is with its owner, but not always (Example 2), so the honest finding distinguishes the two and reaches the person through other evidence, other location sources, messages, CCTV, a wearable, converging on the same conclusion.
The sources disagree. Does that ruin the evidence?
Not at all, it can be the most revealing part: contradiction between sources is examined, not ignored (§6, Example 2). A conflict may show a device was left behind, a fix was stale, or clocks differed, and resolving it often exposes the truth. What is not acceptable is silently dropping the inconvenient source. Honest handling of contradiction is a strength of a proper geolocation analysis, not a weakness.
Ask about this guide

SaaS Platforms As Undiscovered Repositories

A key witness says they have almost no relevant documents. Is that the end of it?
Often it is the beginning: the question "what documents do you have?" misses the applications where modern work is recorded (§2). Ask what platforms they work in all day (§3): the CRM, the project tool, the messaging app: and the record is usually there in quantity (Example 1's 400 interactions), with a change history and audit trail the witness never thought about.
How do we even find out what SaaS platforms a business uses?
By triangulation (§3): the identity provider or SSO lists sanctioned applications, end point exam in at i on finds installed and browser-used ones, network and CASB logs catch the rest, and expense and card records reveal the department a l and shadow subscriptions IT never sees (Example 2). No single source is complete; together they map the estate the asset register does not.
Can data in a CRM or project tool really be collected for disclosure?
Yes, as structured data (§5-§6): through the platform's export or its API, preserving the records, their change histories, comment threads and audit trails, and rendering them into review in a form that keeps the structure and context (§6's format problem). Flattening them to screenshots loses the very history and links that make them valuable; proper collection keeps them.
What makes the audit trail so useful?
It is the platform's own neutral record of who did what and when: created, viewed, edited, exported, deleted (§5,
Ask about this guide

Cryptocurrency And Blockchain Tracing

Isn't cryptocurrency untraceable?
Usually the opposite (§2, Example 1). Most crypto runs on public blockchains, permanent, open ledgers that record every transaction forever, so funds are often more traceable than money in the banking system. The difficulty is not seeing the transactions but tying an address to a person, and dealing with deliberate obfuscation like mixers. A specialist can frequently follow the funds and, through exchanges and devices, name the holder.
If we can trace the funds, do we know who owns them?
Not from the ledger alone (§5). The blockchain records addresses, not names, so tracing shows the flow of value, not who controls it. Attribution comes from off-chain evidence: exchange know-your-customer records where funds are cashed in or out, wallet software and keys on a person's devices, recovered seed phrases, and behavioural links. Tracing and attribution are two different tasks, and naming the owner depends on the second.
What is a seed phrase, and why does it matter so much?
A seed phrase is the master secret that controls a wallet's keys and there for e its funds (§3). Because ownership of crypto is control of keys, possession of the seed phrase is powerful evidence of ownership, and one recovered from a person's own device, cloud note or notebook (Example 2) can prove control of addresses they deny owning. It is among the most compelling attribution evidence, which is why devices, backups and notes are examined, not just the ledger.
The funds went through a mixer. Is the trail dead?
Not necessarily (§6, Example 1). Mixers pool and shuffle funds to break the link between source and destination, and they complicate tracing, but analytics and timing can some time s see through enough of the mixing to continue the trace, and the funds often surface again at an attributable exchange. A mixer lowers confidence and may in some cases defeat the trace, but it is an obstacle to be assessed honestly, not an automatic dead end.
Ask about this guide

MacOS And Apple Silicon Forensics

Can you just image the Mac's hard drive like any other computer?
Not on Apple Silicon (§4). The storage is soldered to the board, so there is nothing to remove; it is hard w are- encrypted, so it is unreadable at rest without the machine and its keys; and secure boot blocks the old trick of imaging it from external media. The classic pull-and-image method simply does not work. The Mac is instead acquired live and logically, on the running, unlocked machine, which is where its data is readable (§5).
What is the single most important thing when seizing a Mac?
Keep it powered on and unlocked (§7, Example 1). A running, unlocked Apple Silicon Mac can be acquired; a switched-off, locked one may be an encrypted brick without the credentials. The reflex from old training, to power a machine down, is exactly wrong here. So the machine is kept awake and unlocked, prevented from locking or sleeping into a locked state, protected from remote wipe, and acquired as soon as possible while access lasts.
Is a live logical acquisition as good as a full image?
For a modern Mac it is the correct and defensible method, not a compromise (§5, Example 2). Because no physical image is obtainable, the live logical or targeted collection, taken from the unlocked machine, hashed, documented and validated, is the sound approach, and done properly it is as accountable and reproducible as a classic image. The rigour, integrity, documentation, validation, is unchanged; only the technique adapts to a machine whose data is readable only while it runs.
The Mac is locked and we do not have the password. Can you break in?
Honestly, usually not by direct attack on a powered-off Apple Silicon machine (§6, Example 3). The credible answer is not a promise to crack it but the lawful alternatives: obtain the password by cooperation or an order (guide 117), and reach the same data through the iCloud account and any backups, which often hold much of it (§8). A reputable expert states this limit plainly rather than overpromising, and pursues the routes that actually work.
Ask about this guide

MacOS System Artefacts

Can you tell whether someone actually opened a file, not just that it was there?
Yes, that is exactly what system artefacts are for (§4, Example 1). Recent-items lists, quick-look thumbnails, file- system events and unified-log entries together can show that a specific file was opened or previewed, and when. This activity evidence is often far more telling than the mere existence of the file, especially in confidential it y and employment disputes where the issue is use, not just possession. The artefacts distinguish a file that sat unopened from one that was actively used.
What is Knowledge C and why is it useful?
It is one of the macOS activity databases (§3, §4), a record of user and device activity, including application usage and when the device was awake and in use, over time. It is useful because it gives a clear, timestamped picture of when the machine and its applications were actually used, helping reconstruct user behaviour and presence at the device. Read alongside the unified logs and other artefacts, it is a valuable part of the activity timeline, interpreted, like all artefacts, for what it specifically shows.
There are no log entries for the period we care about. Does that clear our opponent?
Not necessarily, this is the log-rotation trap (§6, Example 2). The unified logs retain only a limited window, and older entries are aged out to save space, so an absence of entries for an earlier period may simply mean the logs have rotated, not that nothing happened. A gap is not proof of inactivity. An honest analysis says so, preserves promptly to save what remains, and looks to earlier Time Machine backups, which often preserve artefacts since rotated off the live machine.
Can the artefacts show what someone searched for?
Often yes (§4, Example 3). Spotlight and related artefacts can evidence what was searched for on the machine, which can reveal interest, intent and preparation that the content of files does not convey (guide 125). Combined with application-use records, this can be powerful behavioural evidence. It is interpreted carefully, a search shows interest and activity, attributed to an account with care, not a completed act, but what a person sought on a machine frequently illuminates why they were doing what they did.
Ask about this guide

RAID NAS And Server Recovery

Can you just image one disk from the server?
Not use full y, on a striped or parity RAID: a single member holds only interleaved fragments, every file sliced through, and reads as gibberish (§2). The array must be reassembled from forensic images of every member, using the solved geometry (§4). The exception is a mirror (RAID 1), where one member is a readable whole, but even then the array metadata matters for currency.
A disk failed and IT put in a new one and rebuilt the array. Is the evidence gone?
Possibly, and this is the single most damaging thing that can happen (§5, Example 1): a rebuild recalculates and overwrites stripes. Caught early, enough original stripes may survive on forensic images of the members to reconstruct; run to completion, the overwritten data is gone. Stop any rebuild at once, image every member including the failed and replacement disks, and recover on the copies.
The array has lost two disks. Can it be recovered?
It depends on the parity: a single-parity array (RAID 5) survives one failure, not two, so two losses put it beyond reconstruction from the survivors alone (§5). A double-parity array (RAID 6) survives two. Where the array is beyond parity, partial recovery of what the survivors cover is attempted, and the estate, backups, replicas, end point s, carries the rest (Example 2, §8).
Do we have to shut the business server down to preserve it?
Usually not: live server storage is preserved by snapshots and live forensic acquisition that capture the relevant data while the system keeps running (§6), and by targeted, documented collection of the relevant shares rather than wholesale imaging. Downtime is reserved for where the array itself must be imaged member by member, which is planned to minimise disruption.
Ask about this guide

Proving Who Created Or Edited A Document

The document's author field names my client. Doesn't that settle it?
No: the field records the application's registered user on the machine where the document (or its template, or the document it was copied from) was created, and it is editable (§3): Example 1's field named a template; Example 3's date was reset by a copy. It is evidence of environment, corroborated by the platform ladder and the end point before it becomes evidence of a person.
Can we prove who inserted a specific clause?
Frequently: the version ladder's diffs localise the change to a rung, the rung names the saving account and time, and the end point and transmission records corroborate the session (§4-§5): Example 1's 19:52 check-in. Co- author in g adds caveats about session granularity, and the account-to-person step needs its own corroboration, stated as such.
What about an anonymous document with all metadata stripped?
The stripping is rarely complete: PDF XMP data often preserves source fields, end point s hold a u to recovery drafts and recent-file entries, the template and application build narrow the population, and stylistic comparison adds weight (§3, §5-§6): Example 2's letter was attributed through all four. The counterpart's copy may also carry what the author cleaned from theirs (§8).
Several people edited the document together. Who is the author?
Each contributor of each change, at the granularity the platform retained: per-save attribution always, per- paragraph where the application kept it (§4): the report attributes the material changes to accounts and sessions and states where the granularity runs out. "Author" becomes a schedule, not a name: which is usually the truthful answer for collaborative documents.
Ask about this guide

AI Generated Documents Provenance And Detection

Can you tell if a document was written by AI?
Not reliably from the text, and no honest examiner will claim to (§4). AI-text detectors produce false positives and negatives and are easily defeated, so a "this was written by AI" opinion based on the prose does not survive scrutiny. What can be established, objectively, is provenance: whether the document's metadata and creation history support its claimed origin, and whether it exists where a genuine document would (§5). That, not text analysis, is the reliable answer.
How do you prove a document is fabricated?
By provenance and corroboration, not prose (§5, Example 1). A genuine email exists in mailboxes, on servers and in backups; a genuine file has a consistent creation and revision history and copies in the cloud and with others. A fabricated document typically exists only where the party produced it, contradicts its own creation metadata, and is absent from every system that should hold it (§8). That objective absence and inconsistency, not how the text reads, exposes the fake.
Why do we need the native file and not a printout?
Because provenance lives in the native file and its system context (§5). A printout or screenshot strips the metadata, the author in g records, the creation and revision history, the very things the analysis depends on, and flattens the document into an image that cannot be tested. To examine provenance you need the electronic original with its metadata intact, obtained from the system where it lives, with integrity preserved.
Our opponent's submissions cite cases we cannot find. What does that mean?
It may mean the authorities were hallucinated by an AI tool used in drafting and never verified (§3, Example 2), an increasingly common and serious problem. The check is the simplest one: verify each c it at i on against a primary source. Authorities that exist nowhere are a real risk to the party relying on them, engaging duties to the court, and the safeguard is verification, not any attempt to "detect AI" in the writing.
Ask about this guide

APFS And The Apple File System

If a file was deleted from an Apple device, is it recoverable?
Often, and more reliably than on older systems (§4, §5, Example 1). APFS uses copy-on-write, so changes write new data and leave old data recoverable, and it takes snapshots, point-in-time pictures of the whole file system, that frequently hold deleted files and earlier versions intact. A document gone from the live file system is very often recovered whole from a snapshot that predates its deletion, or from remnants in free space, provided the device is preserved before the data is overwritten or the snapshots pruned.
What is an APFS snapshot, and why does it matter?
A snapshot is a frozen picture of the entire file system at a moment in time (§4). The operating system and Time Machine create them automatically, so a device usually holds several without the user knowing. They matter because they can preserve files as they were at a past moment, including material since deleted or altered, making them the richest source of prior states on an Apple device and a powerful way to prove what existed on the device, and when.
Can we prove a document was altered after it was signed?
Frequently, using APFS (§5, §7, Example 2). Because APFS retains earlier data, a prior version of the document can often be recovered from a snapshot or copy-on-write remnants, and compared with the version relied on. If the comparison shows a change made after the purported date, that exposes the alteration or backdating (guide 109). The interpretation is done carefully, reading timestamps and clone relationships correctly, so the comparison rests on a sound understanding of each recovered version.
Why does it matter whether something is a clone?
Because a clone is not an independent copy (§3, §6, Example 3). APFS clones share the same underlying data until one is changed, so two apparent copies may really be one object with two names, not two separate duplicates that were made and moved. Mistaking a clone for independent duplication overstates the facts. Establishing the clone relationship before drawing conclusions about copying or distribution is essential to an accurate account, which is why interpretation matters as much as recovery.
Ask about this guide

The Defensible Multi Source Evidence Bundle

Why not just rely on the strongest single source?
Because a single source, however strong, is a single point of failure (§5, Examples 1 and 3). A phone can be left behind, a screenshot can be challenged, one clock can be wrong. Corroborating a central fact across several independent sources makes the case far more resilient: if one strand is undermined, the others hold. The strength of a modern case is in convergence, so the assembly rests load-bearing facts on more than one source wherever it can.
Our sources seem to contradict each other. Is the case lost?
Usually not, examine the contradiction rather than fear it (§5, Example 2). Most apparent contradictions between well-collected sources are clock artefacts: different time zones, daylight saving, a DVR running fast, a server in UTC. Normalising every source to a common clock on the master timeline resolves the great majority of them (§4). Where a contradiction is real, it is examined and explained honestly, which is far safer than hiding it and having the opponent expose it.
Why does the timeline matter so much?
It is the spine of the whole bundle (§4). Placing every event from every source on one timeline, with all clocks normalised, is what makes convergence visible and contradiction resolvable. Without it, the sources are just separate exhibits and the court cannot see how they fit; with it, the case reads as one coherent sequence. Most of the work, and most of the errors, in a multi-source case are in building the timeline correctly.
Can one weak exhibit really undermine a strong bundle?
Yes, if it is load-bearing (§6, Example 3). A bundle is only as defensible as its least sound source, and if a casually captured, un-provenanced exhibit carries a central part of the case, its collapse under challenge can undermine confidence in the whole and leave that fact unsupported. That is why integrity, hashing, provenance and method, is maintained to the same standard across every source, and why load-bearing facts are corroborated so no single exhibit is indispensable.
Ask about this guide

Browser History And Internet Artefacts

Does a website in the browser history mean our client went there?
Not necessarily, and this is the crux (§4, Example 1). A page loads adverts, trackers, images and redirects from many other domains automatically, and prefetch and background sync add more, so the history and cache routinely contain URLs the user never chose. The browser records how each URL was reached, typed, clicked, redirected, prefetched, and that transition data, not the bare presence of the address, tells you what was a deliberate visit.
Our client cleared their history. Is it gone?
Usually not entirely: deleted browsing records are often recoverable from unallocated space, database free pages and cache remnants (§5), and, importantly, if the browser was signed into a syncing account, the history was copied to the cloud and survives the local clearing (§8, Example 2). Clearing the device does not clear the account. The clearing itself, if done after a duty to preserve arose, may also be a point in its own right (§7).
Can we tell who was actually using the browser?
Only with care: the browser records a profile's activity on a device, not certainly a person's (§6, Example 3). On a shared computer or one with several profiles, the history may belong to someone else, so attribution is tested through the profile, the login state, the session artefacts and the timing against known presence, and corroborated. A search or visit is laid at a particular person's door only when that evidence supports it, not on the assumption that the device is theirs.
What about private or incognito browsing?
It leaves a sparser trace, but not always nothing: private modes avoid saving normal history, yet remnants can survive in memory, DNS cache and related system artefacts (§5), and the destinations and network may still hold records (§8). So private browsing limits the local record without guaranteeing invisibility, and its gaps are stated honestly rather than read, in either direction, as proof.
Ask about this guide

Vehicle Infotainment And Telematics Forensics

What can a car actually tell us?
Often a great deal: which phones were paired to it and when, and frequently copies of those phones' contacts, calls and messages; the destinations and journeys entered into its navigation; door, ignition, gear and speed events from its modules; and, on many vehicles, the seconds around a collision (§3). But it varies enormously by make and model, so the honest first step is to establish what this particular vehicle records and what can be extracted (§5).
Does the car prove who was driving?
No, and this is the key limit: the car records the vehicle and the paired device, not the person (§6, Example 1). It can show a phone was in the car and where the car went, but attribution to a driver or passenger requires corroboration, usually the paired phone's own records placing it with a person. The honest finding is stated at the level the evidence supports: the car places the device, the phone places the person.
The car has been driven since. Is the data gone?
Some of it may be: continued use overwrites journey history, changes the paired-device list and cycles event buffers (§5). But the telematics or connected-car cloud is a separate source with its own retention and often holds the journeys the car itself has overwritten (§4, Example 2), and the paired phone holds the originals of the copied data. Preserve promptly, but a used car is not always a lost case.
Can we get the journey data from any where other than the car?
Yes: the manufacturer's connected-car cloud and the insurer's telematics black box both record journeys, locations and status independently of the vehicle, reachable through the owner's account or the provider by lawful request (§4, §8). The companion app on the phone mirrors much of it too. These cloud sources often outlast the car's own overwriting history, which is why they are preserved in parallel.
Ask about this guide

Recovering Deleted CCTV And DVR Footage

How long do we have before CCTV footage is gone?
Often days, some time s only a few weeks, and occasionally less: retention is set by the disk size, the number of cameras and the recording settings, and busy multi-camera systems can hold as little as three or four days (§3, Example 1). The first step is always to find the retention period so the deadline is known, and then to preserve the footage before the loop reaches it. Assume the clock is short until proven otherwise.
Can we just film the CCTV monitor on a phone?
You can, but it is weak evidence and a poor substitute (§6, Example 3): a filmed screen is low quality, loses the metadata, and is easily challenged on timing and authenticity. The real evidence is the recorder's own native export with its metadata intact. Where the recorder still holds the footage, export it properly; the filmed monitor is a last resort for footage that no longer exists any other way.
Footage was deleted from the DVR. Can it be recovered?
Sometimes, if you act fast: user-deleted or not-yet-overwritten footage can be carved from the DVR's storage (§5, Example 2), and the recorder's log may record that the footage existed and who deleted it. But a running DVR keeps overwriting the residue, so the system must be taken out of service and imaged immediately. Footage the loop has already recorded over is genuinely gone.
The timestamp on the footage looks wrong. Does that matter?
It matters a great deal, and it is very common: DVR clocks are routinely set wrong, never adjusted for daylight saving, or drifted (§6). The recorder's clock is checked against a known reference to establish the offset, and the footage is then placed on the true timeline and reconciled with other sources like phone records or transaction logs (§7, Example 3). Never rely on the on-screen stamp without checking it.
Ask about this guide

Shared Mailboxes Delegated Access And Who Really Sent The Email

The email came from the executive's address. Isn't that proof she sent it?
No: a delegate with send-as rights produces an identical header, and a compromised session produces the same again (§3, §7): Example 1's approval was sent by an assist an t and looked exactly like the director's own. The audit log, permission history and sign-in context prove the actor; the From line proves only the mailbox.
Why would a shared mailbox be missed in disclosure?
Because it is not a custodian: scoping by named individuals collects their mailboxes and leaves the team inbox untouched, unheld and expiring on its own retention (§5, Example 2). The permission census finds it; the DRD names it as a source; the hold reaches it. Ask every relevant team which inboxes they actually work from.
What is the difference between send-as and send-on-behalf, and why does it matter?
Send-on-behalf marks the real sender visibly ("A on behalf of B"); send-as does not: the message appears to be B's alone. For attribution, send-on-behalf is answered on the face of the message (if the marker survived production); send-as is answered only from the mailbox audit log (§3, §6): which is why logging status is the first question in any disavowal.
Can we prove who created a forwarding rule?
Usually: rule creation is an audited event recording the acting account, session and time, and the sign-in log joins the session to a device and location (§4, §6): Example 3's rule was attributed to an external session without MFA. The rule's timing against the dispute is often the most telling fact, and the configuration export documents exactly what it did.
Ask about this guide

Remote Employee Collection

Can a device be collected forensic all y without anyone touching it?
Often, yes: a remote forensic agent images or targets it over the network under the examiner's control, hash- verified like a bench image (§3); and much of the evidence is collected cloud-side from the mailbox, drives and SaaS without the device at all (guides 111 to 114). Where only the device holds something, deleted or local-only data, an agent, shipped image or order reaches it. Distance no longer means the evidence is unreachable.
Can we just ask the employee to send us the relevant files?
Only if they are cooperative and the material is low-stakes, and even then under supervision (§3): an adverse custodian, or anyone whose conduct is in issue, must never self-collect, because it invites selective disclosure and destruction (§4, Example 2). For those, examiner-controlled or cloud-side collection that needs no cooperation is used, and the court compels access if it is withheld.
The custodian works from home abroad. Does that change things?
Substantially: a device or custodian in another jurisdiction engages cross-border collection, data-transfer and some time s blocking-statute questions before any technical step (guide 116). Cloud-side collection may still reach the estate through the UK-controlled provider account, but collecting from a device abroad is a legal exercise first: take the cross-border advice before acting.
How do we collect from a personal device without invading privacy?
Through the independent-examiner model (§7, Example 3): an agreed independent examiner images the device but applies agreed search terms and date ranges and discloses only the relevant material, holding the private remainder and never passing it to the other side. Combined with collection by consent or order and data minimisation, it reconciles the right to the evidence with the right to a private life.
Ask about this guide

Data Exfiltration To Cloud Storage

The data went to a personal cloud account. Can we even prove it?
Yes, and usually well: the corporate machine's sync database or browser artefacts name the files and the account (§4), the platform audit log records the downloads or shares (§5), the network bounds the volume, and the destination account: reached through process: holds the material itself (§6). Example 1 was proven at both ends to the minute. The cloud feels elusive and is in fact doubly-recorded.
The employee just shared a folder rather than downloading anything. Is that exfiltration?
Squarely: sharing corporate content to a personal or external address, or creating a link and taking it away, moves the data to the employee's control without a d own load or a USB trace (§3, Example 2): and it is logged as a sharing event with the destination in the platform audit trail, which is why that log is exported first when downloads and USBs come up empty.
Can we get into the employee's personal cloud account?
Through process, not self-help: a preservation letter and undertakings first, then delivery-up and imaging orders, commonly via an independent examiner who reports only on your material and protects the employee's private data (§6, guide 97 §7): the account holds both the manifest and the files. Where the holder will not cooperate, the provider's records are reached by disclosure. Plan the route early; the account can be emptied in minutes.
The employee had a sanctioned personal cloud for home-working. Does that defeat the claim?
Only for what it sanctioned: the innocent-explanation pass (§7, Example 3) separates policy-permitted sync of the employee's working folder from unsanctioned transfers outside it, and the genuine exfiltration usually stands out clearly against the baseline. Running the pass first protects both sides: it narrows an over-broad claim to what will survive, and clears what was legitimate.
Ask about this guide

Deepfakes And Synthetic Media

Can you just run a deepfake detector and get an answer?
No, not a reliable one on its own (§4, Example 3). Detection tools are indicative, produce errors, are defeated by post-processing and are outpaced by new generators, so a detector's verdict is evidence, not proof. The reliable approach pairs media-forensic analysis, read with an understanding that compression itself creates artefacts, with provenance: where the file came from, its capture device and its corroboration (§5). Together those answer the question far more safely than any single tool.
How do you prove a video or recording is fake?
By combining forensic tells with absent provenance (Example 1, §5). Media analysis may indicate synthesis or manipulation, and provenance asks whether the recording has a capture device, a native original and a corroborating web of contemporaneous copies and independent event evidence. A fabrication typically has the tells and lacks the provenance, existing only where the producing party supplied it (§8). That combination, not either element alone, exposes the fake.
The other side says our genuine recording is a deepfake. What do we do?
Authenticate it positively, do not merely deny the denial (§6, Example 2). Trace it to the device that captured it, recover the native original with its metadata and capture time and place, identify the people who held copies at the time, and corroborate the event with independent evidence like CCTV or location. A bare "it's a deepfake" carries no weight against a recording embedded in that web of provenance. The liar's dividend is beaten by proof, not by argument.
Does a clean forensic result mean the recording is genuine?
Not by itself (§6). Absence of manipulation tells does not prove authenticity, just as the presence of some artefacts does not prove fakery, since ordinary compression and re-sharing also leave marks. A clean result is one input; authenticity is established positively through provenance and corroboration. The honest conclusion combines both and is stated at a level of confidence, rather than treating a clean scan as a certificate of genuineness.
Ask about this guide

FileVault The Secure Enclave And Apple Encryption

Can you break File Vault or extract the key from the chip?
No, and a reputable expert will not claim to (§4, §6). FileVault's encryption is strong and the key is protected in hard w are by the Secure Enclave, which cannot be defeated by direct attack or by extracting the key. The realistic route is never cryptanalysis but authentication: obtaining the user's credential by cooperation or order, or a lawful recovery key. Anyone promising to break the encryption should be treated with caution; the honest and effective approach is to find a lawful way to authenticate.
What is a File Vault recovery key, and why does it matter?
It is a key created when File Vault is enabled that can unlock the disk instead of the password (§5). It matters because it is a clean, lawful route into an encrypted device that avoids any need to break anything. The practical task is to find where it lives: the user may hold it, an or g an is at i on may hold an institutional one for a managed device, or it may be escrowed in the user's iCloud account. Locating a recovery key often opens a device that otherwise looked inaccessible.
Why can't you just copy the disk and decrypt it else where?
Because the encryption is bound to the machine (§3, §4). The keys are tied to that specific Secure Enclave, so the encrypted storage cannot be moved to another computer and decrypted there, the classic imaging workaround does not work. Decryption happens only on the original machine, and only on authentication. This machine-binding is a core reason the old forensic methods fail on Apple devices and why access is about authenticating on the device itself, not about the disk.
The device is company-owned. Does that help?
Often significantly (§5, Example 2). A corporate or managed Apple device is frequently enrolled in a device- management system, and the or g an is at i on may hold an institutional File Vault recovery key or the means to unlock it. As owner and administrator, the employer can law full y provide access, without compelling the individual or attacking the encryption. So establishing how a device is managed is an early and valuable question, the or g an is at i on is often the cleanest lawful source of access to a managed device.
Ask about this guide

Forensic Evidence From Cloud Infrastructure AWS Azure Google Cloud

Our systems are all in AWS. Can you image the server?
There is no server to image in the traditional sense (§2): the evidence is in the account: the control-plane log of who did what (§3), the data-plane access logs (§4), and snapshots of any running instance's storage (§5). The right first step is not imaging but preserving those logs and snapshots through AWS's own mechanisms before retention and auto-scaling remove them.
Someone deleted our production database. Can we prove who?
Usually to the identity, often to the person: the deletion is a single control-plane API call recorded with the calling identity, source IP and time (§3, Example 2), and the identity and sign-in logs join it to a session and account. Automation is distinguished from a human by the nature of the calling identity, and the person behind a role is found from the identity provider's logs and the end point.
We think data was taken from cloud storage, but there is no access log. Is it hopeless?
Object-level logging is off by default and its absence is a common first finding (§4), but not the end: the control plane records the access-permission changes that enabled it, network-flow logs record the egress volume, snapshots hold the store's prior state, and the destination account (§8) holds what left (guide 111). The case shifts to the alternates, and the report states which carried it.
A former engineer still had access to our cloud account. How serious is that?
Potentially very: unrevoked credentials let a leaver read, take or destroy the estate, and the control-plane log records what ever they did (Example 2, Example 3): the failure to revoke is itself a finding, and the acts are attributed to their identity. Preserve the logs, revoke access, snapshot what is perishable, and examine the leaver's end point s for the credentials and code they took.
Ask about this guide

Detecting Backdated Or Manipulated Documents

Can a backdated document really be detected if the forger changed all the dates?
Usually: the dates are the easy part; the application build, fonts, features, revision identifiers and drafting signature inside the file (§3-§4), and the ladder, logs, recipients and backups outside it (§5), are the hard part, and forgers rarely manage all of them: Example 1 failed on its producer string, Example 2 on its revision IDs and empty world. The careful forger who ages the internals still cannot insert the document into last year's backups.
The other side says our document is fabricated because its file date is recent. What now?
Run the exam in at i on yourself, first: the recent date is usually a copy or export artefact (guide 108 §4, Example 3 here), and the platform record, the recipients' copies and the period backups will corroborate the true date: the party that proves authenticity holds the hearing. Demand the native and the corroboration through §11's requests if the accuser has them.
What if the document only exists as a scan or a PDF?
The scan carries the scanner's metadata and the PDF its producer's, both dateable (§4), and the external tests (§5) apply in full: where was the document sent, backed up, referenced? The absence of a native original where one should exist is itself a red flag; the paper original, if claimed, is examined by a questioned-document specialist under guide 100's matching.
How confident can an expert be that a document is forged?
As confident as the graded evidence allows (§7): "created no earlier than [date]" from an anachronism is near- certain; "absent from every expected store" is strong but circumstantial; "fabricated" combines both and excludes the alternatives. Honest reports state the grade and its basis; overclaimed ones are dismantled by the first innocent explanation the examiner failed to address.
Ask about this guide

Preserving Evidence After A Cyber Attack Or Ransomware Incident

Won't preservation slow down our recovery when every hour of d own time costs money?
Marginally and in parallel, not serially: imaging designated systems and export in g logs runs alongside containment, and the §3 order in g exists precisely to avoid gating the rebuild: hours of examiner work against Example 2's two-year alternative. The expensive version of preservation is the one attempted retrospectively.
Should we pay the ransom, and does forensics bear on it?
That is a legal-strategic decision taken under advice: sanctions screening on the attribution evidence, insurer position, data-recovery realities and leak-site risk all feed it: and the preserved artefacts (strain, communications, exfiltration analysis) are its factual inputs: Example 3's firm declined from an evidenced position. Forensics does not make the call; it makes the call informed.
How can we possibly know within 72 hours what data was affected?
Often only part i all y: which the regime anticipates: the initial report states what is assessed, staged supplementation follows the analysis, and the §3-preserved logs are what let the assessment converge quickly: Example 1's hour-60 answer. What the clock punishes is not incomplete knowledge but unassessed assertion.
The attackers cleared the server logs. Is the investigation over?
No: log-clearing is expected tradecraft and §8's whole design answers it: the network layer, identity provider, EDR telemetry, backup systems and external sources each hold independent copies of phases the attacker could not reach: and the clearing itself, documented per guide 110, is evidence. Single-source dependence is the vulnerability; the layered harvest is the cure.
Ask about this guide

Wearables And Fitness Tracker Forensics

Is the data on the watch itself?
Only recently: the watch is a relay with limited storage, holding recent readings until they sync (§4). The fuller history is cached in the companion app on the paired phone, and the complete, detailed, long-term record lives in the manufacturer's cloud, which is usually the real source (§3, Example 2). So the account, not the watch, is what you preserve and collect first; extracting the watch alone yields a fragment.
How accurate is fitness-tracker data?
Indicative, not clinical: consumer sensors estimate, heart rate optically, sleep from movement, steps from motion, and can be wrong (§6). That does not make the data useless; it makes it evidence to be presented as indicative and corroborated against other sources, not asserted as medical measurement. Its accuracy and any gaps are explained honestly, so the court knows the weight it can bear.
Does the watch prove who was doing the activity?
No, only that whoever was wearing it did (§6, Example 3). Usually that is the owner, but not invariably, so attribution requires corroboration, the paired phone's location, messages, other evidence, and the finding is stated at the level the data supports. The wearable records a body's activity; identifying whose body, and where, comes from the corroborating sources beside it.
Can we get the other side's wearable data?
By the proper routes: preservation and disclosure of the relevant records, or a data export from the account, and for a party's own data a subject-access request is often a lawful, proportionate route (§4). Because this is special-category health data, collection is scoped to the relevant metrics and period and minimised, and handled with heightened care (§7). It is obtained law full y and proportionately, not scraped indiscriminately.
Ask about this guide

Who Accessed Or Downloaded A Confidential Document

Can we find out who opened a document on Share Point?
Usually, within the audit retention window: the unified audit log records access, d own load, share and related events with the acting account, client and IP (§3): Example 1's forty-one accounts came from one search. The account is then joined to a person through §7's lattice, and the event type read for what it proves (§5): a preview is not a read.
How long do access logs last?
Months by default on the major platforms, longer with premium licensing or retention policies, days on busy on- premises servers, and anything from days to indefinite on SaaS systems (§6): the tenant's actual configuration is the first fact, and export is the first act. Logs allowed to expire after proceedings are contemplated are a preservation failure.
The file server has no access logs. Is the trail cold?
The server's trail never existed if audit in g was off (Example 2), but the endpoint's did: shortcut files, recent-file lists, sync databases and browser artefacts on the device that opened the file prove local access independently (§4, §8). Sequester the device before it is reissued; the trail is on it.
The log says my client's account accessed the record. Is that the end of it?
No: the event's semantics may be a preview or a search render (Example 3), the d own load may be a sync client's, and the account may have been used by someone else: the defensive lattice of §7 tests each. Access allegations built on a single log line without semantics, baseline or corroboration are the ones that fail at the hearing.
Ask about this guide

Custodian Abroad Cross Border Collection

The court has ordered disclosure. Can we just image the custodian's device abroad?
No: an English order does not make it lawful to collect and export data in another country, whose law governs the data (§2). Depending on the jurisdiction, self-help collection may breach data-protection, labour, secrecy or blocking-statute law, and in some places be a criminal offence (§4, Example 1). Engage local counsel first and choose a route lawful where the data sits.
What is a blocking statute and why does it matter so much?
It is a law that criminalises gathering or export in g evidence located in the country for foreign proceedings otherwise than through official channels (the French statute is the classic example, §4). It matters because the ordinary collection English disclosure expects can be a crime where the data sits, and the only lawful route may be a letter of request through the foreign court (§5, Example 1): slow, but lawful.
Is moving the data to England just a logistics question?
No: it is a restricted international transfer under the UK GDPR needing a lawful transfer mechanism (adequacy, the IDTA or Addendum, or a litigation derogation) and usually a transfer risk assessment (§3). Treating it as mere logistics is a data-protection breach in the collection itself. Data minimisation, transferring only relevant material, reduces both the risk and the volume crossing the border.
Can cloud-side collection avoid the whole problem?
It can avoid much of it where the data sits in a UK-controlled corporate account, because collection happens server-side without a foreign act or a foreign-device search (§5, Example 2): but it does not dissolve local law, the custodian's personal data is still processed and their local rights and the provider's data-centre locations may still bite. It is often the cleanest route, but the local-law analysis still applies.
Ask about this guide

BitLocker FileVault And Full Disk Encryption

The laptop is Bit Locker encrypted. Is the data lost?
Almost certainly not, if it is a managed company device: Bit Locker recovery keys are routinely escrowed to the directory or the management console at setup, precisely so IT can unlock a device whose password is forgotten (§4, Example 1). The first step is to retrieve that key from the store the or g an is at i on controls, decrypt and image the volume: no attack on the encryption, no compulsion of any custodian, just the key the client already holds.
Where exactly do we find a recovery key?
Four common places (§4): the organisation's directory (on-premises or cloud), the device-management console, a cloud account the key was escrowed to, and dedicated escrow or key-management stores. For File Vault there may also be an institutional recovery key the or g an is at i on deliberately holds. And the custodian may have a printed or saved personal recovery key in their own records. Check these before treating the drive as locked.
Can you break Bit Locker or File Vault if there is no key?
No, not by brute force in any useful time, if the encryption is sound and the passphrase is strong (§6): modern full-disk encryption is genuinely secure, which is the whole point of it. The honest examiner says so rather than promising an impossible attack (guide 117 §3). But a truly keyless drive is the exception, usually a personal, unmanaged device, and even then the same data often exists unencrypted in the estate (§8).
A managed device's recovery key is missing from the console. What does that mean?
It is worth investigating, because it should be there: escrow may have been misconfigured or failed, or it may have been deliberately suppressed by a technical user before leaving (§6, Example 2). The management logs usually show which, and a deliberate suppression of the escrow key is itself evidence of obstruction, deployed alongside any anti-forensic findings (guide 110). The absent key can be part of the case, not just a problem.
Ask about this guide

Forensic Evidence From Dropbox Box And ShareFile

Do Dropbox, Box and Share File keep the kind of logs we need?
Business and enterprise tiers do: activity logs of views, downloads, edits, shares and deletions with user and timestamp, plus version histories and sharing records (§3): personal and small-business tiers log less and retain shorter, and export capability varies by product. The account's actual tier and retention are established first, and the desktop client corroborates what ever the platform kept.
The account has been deleted. Is the evidence gone?
Not necessarily: the desktop-client database on every machine that synced it survives the account, naming the files and the account (§4, Example 2 in reverse); the platform provider's server-side records are reachable by process; and collaborators hold their side of every share. The two-record method exists precisely so that a deleted account is not a dead end.
Someone shared a folder externally. How do we find out who reached it?
From the sharing and activity logs: the link's creation names the creator and time, and: where the platform logs link usage: the access record names who followed it and from where (§5, Example 1's lingering collaborator). Where the platform logs only that a link exists, the "who reached it" question is answered as far as it allows, and the collaborators' own records fill the gap.
We found a Dropbox client on a laptop but nobody admits to the account. What now?
The local database names the account and lists what it held (§4, Example 2); the network and expense records confirm its use and who paid; and the account is then reached through the party's cooperation once its existence is undeniable, or through process if it is personal. Shadow IT hides in exactly this way, and the end point is where it surfaces.
Ask about this guide

Collecting Without The Password

Can you just crack the password on a locked phone?
Sometimes, and often not: weak passwords and older devices may yield, but a modern phone with a strong passcode has sound encryption that brute force will not open in any useful time (§3). The honest assessment comes first, so effort is not wasted. And frequently it is unnecessary: the data may sit in an unlocked backup or a synced copy the lock does not guard (§6, Example 1).
Can a civil court make someone hand over their password?
Yes: a party's disclosure obligation can require them to provide the passwords and keys needed to access relevant material within their control, and the court backs this with unless orders (comply or be struck out) and adverse inferences (§4). Access is usually ordered on terms that an independent examiner opens the device and discloses only the relevant material, which protects privilege and privacy and makes compliance acceptable (Example 2).
Is there a law that forces someone to decrypt data?
In the criminal and investigatory context, yes: Part III of the Regulation of Investigatory Powers Act 2000 lets the authorities serve a notice compelling a key or the intelligible form of protected information, and failure to comply is itself an offence (§5). But it is a tool for the authorities on statutory conditions, not for private civil litigants, who use the disclosure-order routes of §4 instead.
Can we just try to guess the password or get into the account ourselves?
No: unauthorised access to a device or account is a criminal offence under the Computer Misuse Act 1990 (§7), and self-help access poisons the evidence and exposes whoever attempts it. Use the lawful route: the recovery key the or g an is at i on holds, the accessible backup, or a court order compelling the key. However tempting the shortcut, it is a crime and it ruins the case.
Ask about this guide

Can File Timestamps Be Trusted

The file says it was created after it was last modified. Is that proof of tampering?
Almost never: it is the signature of a copy, a cross-volume move, an extraction or a restore, which give the new file-system entry a fresh created date while preserving the content's modified date (§4): Example 1's leaver- process move. It becomes a question only when the copy cannot be traced and the other families disagree with the claimed history.
Which timestamps are most reliable?
Server-side stamps from synchronised platforms (version rungs, audit events, email server hops), corroborated by each other (§3, §7): they are written by clocks the user does not control and stored where the user cannot edit. Local file-system and document-internal stamps are indicative: useful, editable, and graded accordingly.
Can timestamps really be faked?
Yes, trivially, with free tools or a clock rollback: and the faking leaves traces: NTFS's second timestamp set, the journal's order in g, the logged clock change, the application build that postdates the claimed date, and the platform or transmission record that disagrees (§6): Example 2's resolution was exposed by all four. The forger controls the value, not the context.
Our device's clock was wrong. Are its timestamps useless?
No: a systematically wrong clock is calibrated against reference events (a received email, a server-logged sync, a dated photograph) to establish the offset, and the stamps corrected within stated bounds (§5, guide 96 §4). What is useless is a wrong clock nobody knew about; a known offset is just arithmetic.
Ask about this guide

Door Access Swipe Cards And Building Logs

How long are swipe logs actually kept?
Anywhere from weeks to a few years: it is a configuration and platform fact, not a standard: controller-local buffers are shortest, head-end databases longest, and visitor and alarm layers run their own schedules. The only safe assumption is that a window is closing, which is why the census and the ask happen in week one.
Can badge data alone prove someone was in the building?
It proves the credential was: the person follows from corroboration: CCTV at the reader, biometrics, journey coherence, paired device activity: per §5's ladder, and honest findings say which rung they stand on. Example 2 shows the ladder reaching certainty; a lone badge event never does by itself.
The logs show no exit for our witness. When did they leave?
Possibly unknowable from the doors: free-exit design logs entries only: so departure brackets from the estate's other diaries: turnstiles and barriers, alarm set events, last logins and prints, final Wi-Fi as so c i at i on, car park systems. The bracket is often tight enough to plead; the door log alone was never going to be.
Our client says a colleague borrowed their card. Hopeless?
Testable, both ways: lending is common and some time s true: the exam in at i on checks whose rhythm the events match, hunts simultaneity contradictions (the card here, the holder's login there), reads CCTV at the readers, and hears the alleged borrower. Where the ladder's rungs point away from the holder, the defence stands up; where they converge on them, Example 2 is how it ends.
Ask about this guide

Building A Digital Timeline For Litigation

Why can't we just build the chronology from the documents' visible dates?
Because visible dates mix zones, semantics and drifting clocks: Example 3's spreadsheet did exactly that and fell to its own lines: and because a chronology without artefact provenance cannot answer the first challenge put to it. Compilation makes a working draft; construction (§4-§6) makes evidence.
What does "normalising to UTC" actually involve?
Establishing each source's storage convention, converting every event to one UTC base, then presenting in relevant local time with the rule stated: plus drift calibration and DST checks: §4's procedure. It is bookkeeping, not magic: the point is that after it, any two events can be legitimately compared: and before it, none can.
How precise are digital timestamps really?
As precise as their clock and resolution: synced server logs are excellent to the second; device fields are good when the clock was; free-running DVRs are only as good as their calibration; some sources resolve only to minutes or days: which is why §5 grades confidence and §10 claims orderings only at supported resolution. Precision is per-source, established, never assumed.
The other side's chronology contradicts ours. How is that resolved?
By methodology: the frames, semantics, calibrations and provenance of both are compared, conflicts diagnosed to their cause (zone error, drift, field mix-up, or a genuinely contested stamp needing guide 108-109 treatment): Examples 1 and 3 are both stories of one chronology surviving that audit and one not. Courts follow the timeline that shows its working.
Ask about this guide

Forensic Collection Of Exchange Online Mailboxes

The custodian deleted emails months ago. Can they be recovered?
Run the four facts: if a hold predated the deletion, yes: the Purges/Versions layers kept them, dated; if no hold and the recoverable window has passed, not from the mailbox: and the architecture paths (device caches, counterpart tenants, backups, journals) take over, frequently successfully. The answer is never "probably": it is an hour's tenant lookup, and the honest report states which case applies and why.
Can a user or admin permanently destroy mail on a held mailbox?
Users, no: every user-level deletion route ends in a preserved layer while the hold stands, and the attempts are enumerable (Example 1). Admins can release holds and alter retention: actions that are themselves audit-logged and, mid-dispute, approximately confessional. The practical assurance: a hold placed early and left alone converts the mailbox into an append-only record: which is why the week-one hold is this block's recurring hero.
How do we prove the other side received and read an email?
In layers of strength: transport trace (delivery to their tenant: strong, window-bound); their mailbox's collected copy (existence at collection); audit read-events where licensing and configuration recorded them (guide 57: genuine read evidence, not universal); and conduct corroboration (replies, forwards, actions consistent with knowledge). Read receipts are weak and refusable. The report stacks what exists and names each layer's weight: "delivered, present, and acted upon" usually suffices where "read at 14:32" is unavailable.
What about the OST file on the laptop: is it worth collecting?
Frequently decisive: the OST is the mailbox as last synced: which means it can preserve what tenant-side deletion later removed, capture the pre-purge state of a mailbox whose hold came late, and survive the account's deletion entirely. Guides 41 and 48's imaging disciplines apply; the comparison of OST contra tenant is itself a deletion chronology. In leaver and spoliation matters, the device cache is standard scope, not an afterthought.
Ask about this guide
Instruct the practice

Bring us in early. Defensibility is built, not retrofitted.

Whether you are responding to a regulator, preparing for disclosure, or scoping an internal investigation, start the chain of custody with a short, confidential conversation.

WhatsApp