TOOL 02 / ARTIFACTS
Can This Artifact Prove That?
Most digital forensic opinions do not fail on acquisition. They fail because an inference was stated more strongly than the artifact supports. Pick the claim you need to support, and see the artifacts that bear on it, what each one actually records — and, first, what no combination of them establishes.
- CLAIMS
- 6 covered
- ARTIFACTS
- 29 entries
- EACH ENTRY
- What it records · what it does not
- USE
- Report drafting · cross preparation
- COST
- Free · no sign-up
- SCOPE
- Windows and cloud artifacts
IN SHORT
A digital artifact records one specific thing, and the distance between what it records and what a party wants to say it shows is where most forensic opinions are attacked. Three distinctions do most of the work: a log records an account, not a person; access, a device connection and exfiltration are three different findings; and the absence of a record is frequently a fact about configuration rather than about conduct.
THE TECHNICAL QUESTION
Was a specific removable device attached to this machine, was the material browsed or opened from it, and does anything record a transfer?
The artifacts can place a specific device on the machine, show a user browsing folders on it, and show file-level activity around the same moment — a great deal short of the copy itself.
What none of these establishes
- That a byte-level copy occurred. No standard Windows artifact records the copy operation itself. The finding available is that a specific device was attached, that folders on it were browsed, and that file activity occurred in the same window — which is an inference, and has to be stated as one.
- Which files went, where the device has not been produced. Absent the media, the artifacts describe activity around files, not a manifest of what left.
- That the person named in the pleadings did it. The artifacts attach to a logged-on account and to a session, not to a human being.
- That nothing was copied, where the artifacts are thin. Connection history is capped, journals roll, and USB auditing may never have been enabled. Absence here is weak evidence of absence.
The artifacts that bear on it
SYSTEM registry — USBSTOR and MountedDevices
- WHAT IT RECORDS
- That a USB storage device with a given vendor, product and serial number was connected to the machine, with a small number of timestamps per device — typically a first-installed, a last-connected and a last-removed value.
- WHAT IT DOES NOT
- Record any file transfer, and does not supply a longitudinal count of connections. A device attached fifty times leaves the same handful of timestamps as one attached twice, so these values cannot be read as a history of how often it was used.
LNK shortcut files and jump lists
- WHAT IT RECORDS
- That a path was opened through the Windows shell, with the target path and, in a LNK file, the volume serial number of the media the target sat on — which is what ties a file to a physical volume rather than merely to a folder name.
- WHAT IT DOES NOT
- Distinguish opening a file from copying it. A LNK entry is the same whether the user read the document, printed it, or did nothing after double-clicking. Its absence does not show a file was not accessed.
Shellbags (USRCLASS.DAT)
- WHAT IT RECORDS
- That a folder was browsed in Explorer, including folders on media that is no longer present, with the view settings and a timestamp.
- WHAT IT DOES NOT
- Carry a volume serial number. Shellbags alone cannot attribute a browsed folder tree to a particular physical device — that link has to come from a LNK file, from the device itself, or from correlation with the registry.
$UsnJrnl change journal and $MFT
- WHAT IT RECORDS
- File creations, renames, deletions and attribute changes on the local volume, with timestamps, and the four $STANDARD_INFORMATION and four $FILE_NAME timestamps for each file in the master file table.
- WHAT IT DOES NOT
- Extend to the removable volume unless that volume is itself acquired and journaled. A copy TO a device produces a read on the source, which most configurations do not record, and a write on the destination, which is on media you may not have.
The removable device itself, where it can be produced
- WHAT IT RECORDS
- The files actually present on it, deleted content still recoverable from unallocated space, and file system timestamps that can be compared against the source machine.
- WHAT IT DOES NOT
- Establish who connected it or when the files arrived, absent corroboration. A device produced late may also have been used in the interim, and that use is itself examinable.
What would actually close the gap
- Producing the device and comparing its contents and file system metadata against the source, including hash comparison of the specific files at issue — noting that a hash match shows identical content and not the transfer path, the arrival date, or who put it there.
- Endpoint DLP, EDR file-write telemetry, or removable-media auditing where any of those were running, which can record the write that the operating system's own bookkeeping does not.
- Corroboration outside the machine for the step from account to person: badge records, CCTV, a phone in the same place, or an admission.
THE TECHNICAL QUESTION
Does anything record this document being opened through the shell or by an application, and on which account?
Several artifacts record that a path was opened through the shell or listed in an application's recent-files list. None of them records reading, and several record presence rather than use.
What none of these establishes
- That the file was read, understood, or its contents used. Every artifact above records an open or a launch, not comprehension and not attention.
- That the file was NOT opened, where the artifacts are silent. Last-access updating is off by default, object-access auditing is off by default, and MRU lists roll. Silence here is usually a statement about configuration, not about conduct.
- Who was at the keyboard. These are per-account records.
- That opening it was wrongful. An artifact records an act; whether the act breached a duty is a question for someone else.
The artifacts that bear on it
RecentDocs, typed paths and application MRU lists
- WHAT IT RECORDS
- That a path was recently opened or entered on this account, per user and per application.
- WHAT IT DOES NOT
- Distinguish opening from copying, or opening from a preview pane rendering the file without the user reading a word. MRU lists are also capped and roll, so an old entry may simply have been pushed out.
LNK files and jump lists
- WHAT IT RECORDS
- That a target path was opened through the shell, with the target's path, size and volume serial number, and a creation and modification time for the shortcut record itself.
- WHAT IT DOES NOT
- Establish duration, whether the content was displayed, or whether the file opened successfully. Automatic destinations are per-application and are absent for applications that do not participate.
UserAssist
- WHAT IT RECORDS
- GUI program launches on the account, with a run count and last-executed time.
- WHAT IT DOES NOT
- Record which document a program opened. That an editor ran is not that this file was opened in it.
$STANDARD_INFORMATION last-accessed timestamp
- WHAT IT RECORDS
- A last-accessed value in the master file table, where last-access updating is enabled.
- WHAT IT DOES NOT
- Distinguish a human opening a document from an indexer, an antivirus scan, a backup agent, or a forensic tool touching it. Last-access updating is disabled by default on modern Windows, so the value is frequently stale by design rather than informative.
Object-access audit events (Event ID 4663 and related)
- WHAT IT RECORDS
- A handle being requested against a specific object, by account, with the requested access mask — the closest thing to a read record that Windows produces.
- WHAT IT DOES NOT
- Exist at all unless object-access auditing was configured on that object and that system beforehand. It is off by default, and enabling it after the fact records nothing about the past.
What would actually close the gap
- Application-level logs where they exist — a document management system, a DLP agent, or a cloud tenant's own file-access auditing, all of which record access in a way the local file system does not.
- Corroborating two independent artifacts that would have to move together if the file really was opened, and stating what it means when only one did.
- Where the question is really about what the user then DID with the file, saying so and testing that question instead — it is usually answerable and the open is usually not the point.
THE TECHNICAL QUESTION
What was deleted, when, by what mechanism, and does anything distinguish a deliberate act from a routine one?
The artifacts can establish that deletion occurred, often when and by what mechanism, and sometimes that a wiping tool ran. Intent is a separate question and the artifacts do not answer it.
What none of these establishes
- Intent. Deletion, encryption, or the presence of a wiping tool does not establish a state of mind, and an examiner who opines on one has left their field — which is itself a Rule 702 problem before it is anything else.
- What the destroyed material was, where it was genuinely overwritten. The traces of the destruction are frequently more probative than the files would have been, but they are not the files.
- That deletion was outside routine practice, without knowing the routine. A retention policy, a sync client reconciling, or a disk cleanup produces the same file system evidence.
- Who did it, as distinct from which account did it.
The artifacts that bear on it
$UsnJrnl change journal
- WHAT IT RECORDS
- File-level creations, renames and deletions with timestamps — including a burst of deletions clustered in a short window, which is a pattern rather than a conclusion.
- WHAT IT DOES NOT
- Survive indefinitely. The journal is a capped rolling buffer and can cover days rather than months on a busy volume, so its coverage has to be stated alongside its contents.
$MFT records and unallocated space
- WHAT IT RECORDS
- That a file existed, its name, size and timestamps, and frequently its content, recoverable by carving on header and footer signatures where the data has not been overwritten.
- WHAT IT DOES NOT
- Show who deleted it or why, and cannot establish the content of material that was genuinely overwritten. Absence of recoverable content is consistent with overwriting, with reuse of the space by ordinary activity, and with the file never having been there.
Traces of a wiping or privacy tool
- WHAT IT RECORDS
- Installation records, Prefetch entries evidencing execution where Prefetch is enabled, registry keys, and characteristic overwrite patterns on disk.
- WHAT IT DOES NOT
- Establish intent, and does not establish what the destroyed material was. Some of these tools ship with the operating system or with legitimate software, and running one is not by itself wrongful.
Recycle Bin ($I / $R records)
- WHAT IT RECORDS
- Original path, original size and deletion timestamp for items sent to the bin, and the content itself until the bin is emptied.
- WHAT IT DOES NOT
- Cover deletions that bypassed the bin — shift-delete, deletion from a network share, deletion by an application, or scripted removal — so its silence covers a large part of the field.
Retention policies, sync clients and backups
- WHAT IT RECORDS
- The routine, automated deletions that account for a large share of what a timeline shows.
- WHAT IT DOES NOT
- Look different from a deliberate deletion at the file system level. This is the alternative explanation that has to be excluded before a deletion is characterised as anything, and excluding it is examinable work.
What would actually close the gap
- Establishing the routine first — the organisation's retention schedule, the backup and sync configuration, and what normal deletion volume on this machine looks like — so that a departure from it is a measured departure rather than an impression.
- Timing against events outside the machine: a resignation, a litigation hold notice, a demand letter. That correlation is argued by counsel from facts the examiner supplies, and it is not the examiner's opinion.
- Recovering the material from backups, shadow copies, a cloud tenant's own recycle bin, or the recipient's copy — which answers what was destroyed without needing to characterise why.
THE TECHNICAL QUESTION
Which account was authenticated in the session, on which device, and does anything outside the machine place a person in front of it?
Nothing inside the machine answers this. Every host and cloud artifact attaches to an account, a session, or a device — the step to a human being is made outside the evidence, or not at all.
What none of these establishes
- Identify a person. This is the single most common overreach in digital forensic testimony and the one the 2023 advisory committee note to Rule 702 names: attributing an act to a PERSON when the artifact establishes only an ACCOUNT or a DEVICE.
- Exclude concurrent or remote use. An interactive logon and a remote session can coexist, and the artifacts do not always make the distinction obvious.
- Establish that a person was present for the whole session. A logon is a moment; a session is a duration; activity within it is a series of moments, and none of the three implies continuous presence.
- Resolve the question by the volume of artifacts. Ten account-level records are still account-level records; they do not sum to a person.
The artifacts that bear on it
Windows logon and session events
- WHAT IT RECORDS
- That an account authenticated, by which logon type — interactive, remote, network, service — from which source, and when the session ended.
- WHAT IT DOES NOT
- Identify a person. Shared credentials, saved passwords, an unlocked machine, a remote session, and an account used by an administrator all produce the same record as the named user sitting down.
Cloud sign-in logs and session tokens
- WHAT IT RECORDS
- That a credential was presented, from which address, with which client, and whether a second factor was satisfied.
- WHAT IT DOES NOT
- Name a device or a person. An address identifies a network endpoint, and NAT, VPN pooling and DHCP reassignment sit between the address and any machine.
Per-user artifacts (shellbags, MRU, UserAssist)
- WHAT IT RECORDS
- Activity within one user profile, which narrows the question from the machine to the account.
- WHAT IT DOES NOT
- Distinguish the account holder from anyone else using that account, including someone who sat down at an unlocked screen.
Biometric or second-factor events
- WHAT IT RECORDS
- That a specific factor was satisfied — a fingerprint matched, a push was approved on a registered handset.
- WHAT IT DOES NOT
- Rule out the factor being satisfied by or for someone else, and does not survive the ordinary attacks on any authentication factor.
Evidence outside the machine
- WHAT IT RECORDS
- Badge records, CCTV, a phone's location, a concurrent call, a witness, an admission — the only category on this list that speaks to a person at all.
- WHAT IT DOES NOT
- Come from the forensic examination. It has to be preserved separately, and most of it has a shorter retention window than the machine does.
What would actually close the gap
- Corroboration outside the machine, obtained early — badge and CCTV systems commonly have the shortest retention of anything in the matter.
- Testing the alternatives explicitly on the record: who else had the credential, was the machine ever left unlocked, was remote access enabled, and what would each alternative look like in the artifacts.
- Stating the finding at the level it supports — 'the account was used' — and leaving the attribution to the finder of fact with the corroboration laid beside it.
THE TECHNICAL QUESTION
Is there a record of data leaving — a connection, a volume, a destination, a recipient — and does anything identify what left?
Network and cloud-side records can establish that a connection occurred and how many bytes moved. Identifying WHAT moved almost always requires the destination account or an agent that inspected the content.
What none of these establishes
- Establish what was uploaded, from network records alone. A byte count is a byte count. Inferring the identity of files from a transfer volume is an inference the data will not carry.
- Establish that data reached a particular person's possession, from a connection record. The account at the far end has to be tied to a person by something other than the log.
- Rule out exfiltration because nothing appears. The most common reason a channel shows nothing is that nothing was watching it, and the second most common is that the log has already rotated.
- Distinguish, without content inspection, a personal backup from a deliberate transfer of the employer's material. The network sees the same thing either way.
The artifacts that bear on it
Proxy, firewall and NetFlow records
- WHAT IT RECORDS
- The destination reached, the time, the duration and the byte counts in each direction.
- WHAT IT DOES NOT
- Identify the content, and over TLS cannot see it. These also have the shortest retention of any enterprise source, frequently rotating by size rather than by age.
Browser history, cache and session artifacts
- WHAT IT RECORDS
- That a site was visited, when, and sometimes that an upload interface was used.
- WHAT IT DOES NOT
- Record the file uploaded in most cases, and is trivially cleared. A cleared history is consistent with routine hygiene as well as with concealment.
Cloud tenant audit logs (the organisation's own)
- WHAT IT RECORDS
- File downloads, sharing-link creation, external sharing, and anonymous-link access within the organisation's tenant — which is often the clearest record available of material leaving.
- WHAT IT DOES NOT
- See anything on a personal account at another provider. The organisation's tenant records the departure, not the arrival, and the retention window depends on the licence tier.
Endpoint DLP and EDR telemetry
- WHAT IT RECORDS
- File reads and writes, process and network activity, and in a DLP product an inspection of the content itself against policy.
- WHAT IT DOES NOT
- Exist unless the agent was deployed on that endpoint and configured for that channel, and raw telemetry retention is commonly days to weeks at base licence tiers.
The destination account, where it can be reached
- WHAT IT RECORDS
- What actually arrived, when, and from where — the only source that answers the question directly.
- WHAT IT DOES NOT
- Come without process. It is usually a third-party subpoena, a preservation request to the provider, or a court-ordered inspection, and personal-account providers respond on their own timetable.
What would actually close the gap
- Preserving proxy, VPN and cloud audit logs immediately — these are the shortest windows in the matter and they close while the pleadings are still being drafted.
- Process directed at the destination: a preservation request to the provider, a subpoena, or a stipulated inspection of the personal account.
- Comparing hashes of the specific documents at issue against whatever is recovered — remembering that a match shows identical content and not the transfer path, and that a non-match does not exclude copying.
THE TECHNICAL QUESTION
Which source wrote this value, in what time zone, on what clock, and with what semantics?
A timestamp is a record of what one source wrote. Turning it into the time an act occurred requires reconciling the time zone, the clock, the semantics of the field, and at least one independent source.
What none of these establishes
- Establish the time an act occurred, standing alone. It records what one source wrote, subject to time zone, clock drift, and application-versus-filesystem semantics — and it is not the time of the act until it is corroborated.
- Establish that a timestamp was falsified, from a single anomalous value. Anomalies also come from restores, from archive extraction, from synchronisation clients, and from copying between file systems with different resolutions.
- Establish who altered a timestamp, where alteration is demonstrated. The manipulation is a finding; the actor is a separate question and usually an account-level one at best.
- Be repaired by precision. Reporting a value to the second says nothing about whether the clock behind it was right.
The artifacts that bear on it
$STANDARD_INFORMATION vs $FILE_NAME timestamps
- WHAT IT RECORDS
- Two independent sets of four timestamps for each file. Ordinary user-space tools write the first set; the second is maintained by the file system and is much harder to alter.
- WHAT IT DOES NOT
- Agree, where timestamps have been manipulated — and that disagreement is the classic signature of manipulation. It is a signature, not a demonstration of who did it or why.
Application timestamps and document metadata
- WHAT IT RECORDS
- What the application recorded — a created date, a last-saved date, a total editing time, an author string.
- WHAT IT DOES NOT
- Necessarily share semantics with the file system. 'Created' in a document's own metadata frequently means the creation of the template it descends from, not of this document, and copying a file resets some values while preserving others.
Event log and cloud service timestamps
- WHAT IT RECORDS
- The time the logging system wrote the record, usually in UTC on a service clock.
- WHAT IT DOES NOT
- Necessarily match the local clock on the endpoint. Clock drift, an incorrect time zone, and a machine that was never synchronised all move a host timestamp relative to a service timestamp, sometimes by hours.
Time zone and daylight-saving context
- WHAT IT RECORDS
- Nothing by itself — but it determines how every value above is displayed, and it is a setting on the examined machine, on the examiner's tooling, and in the report.
- WHAT IT DOES NOT
- Travel with the value. A timeline that mixes UTC and local timestamps without saying which is which is one of the most common defects in a forensic report, and it is fully avoidable.
What would actually close the gap
- Recording the clock source, the offset and the time zone for every system in the timeline, and normalising everything to a single stated reference — with the raw local values preserved beside the normalised ones.
- Corroborating each load-bearing timestamp with an independent source that was writing on a different clock: a mail server, a cloud audit log, a phone, a badge system.
- Comparing $STANDARD_INFORMATION against $FILE_NAME where manipulation is in issue, and stating what the comparison does and does not support.
The three distinctions underneath all of it
The most common way a computer forensic opinion fails is not bad acquisition — it is an inference stated more strongly than the artifact supports.
- Account, not person. Logs record an account and a session. Attributing that session to a human being requires something outside the machine — badge records, video, a phone in the same place, an admission — and the report should say which.
- Access, not exfiltration. A file being opened, a device being connected, and data actually leaving are three different findings supported by three different artifacts. Collapsing them is the error opposing counsel is looking for.
- Absence of evidence, not evidence of absence. Artifacts age out, get overwritten, and are disabled by configuration. That a record is not present may mean the event did not happen, or that the system was never keeping the record — and the difference is usually testable.
Why this is a Rule 702 question, not a style question
Calibrated language reads like caution. It is actually the standard. Rule 702 was amended effective 1 December 2023 to make explicit what the burden always was, and the advisory committee note accompanying the amendment identifies overstatement — including attributing an act to a person when the data supports only an account — as a specific target.
A witness who is qualified as an expert by knowledge, skill, experience, training, or education may testify in the form of an opinion or otherwise if the proponent demonstrates to the court that it is more likely than not that: (a) the expert’s scientific, technical, or other specialized knowledge will help the trier of fact to understand the evidence or to determine a fact in issue; (b) the testimony is based on sufficient facts or data; (c) the testimony is the product of reliable principles and methods; and (d) the expert’s opinion reflects a reliable application of the principles and methods to the facts of the case.
Subsection (d) is the one that matters here. An opinion can rest on a method that is beyond reproach and still fail, because the application of that method to these facts did not support the conclusion drawn from it. That is precisely the gap this tool catalogues. The guide to Daubert challenges to digital evidence sets out the six failure modes that account for most exclusions, and the Daubert exposure check turns them into twelve questions you can put to an expert.
Quick reference: the overreaches
The recurring errors, in the form in which they usually appear in a report or a deposition answer. The list is illustrative rather than exhaustive, and the same reasoning applies to any artifact.
| THE ARTIFACT | WHAT IT RECORDS | THE OVERREACH TO WATCH FOR |
|---|---|---|
| USB device connection history | That a device was attached, with a small number of timestamps | That anything was copied to it — no transfer is recorded — and that the timestamps are a count of how often it was used |
| Shortcut, jump list or MRU entry | That a path was opened through the shell | That the file was copied rather than opened, or that its absence shows the file was never accessed |
| Shellbags | That a folder was browsed | Attributing a folder tree to a physical device — shellbags carry no volume serial number |
| Amcache and ShimCache / AppCompatCache | That a binary was present and its metadata queried | That the program was executed. Only Prefetch, where enabled, supports an execution inference — and its absence proves nothing |
| A hash match | That two files have identical content | The transfer path, the arrival date, who put the file there, or that it came from this plaintiff. A non-match does not exclude copying |
| A log naming an account; an IP address | That a credential was used; that traffic reached a network endpoint | That a named person acted; that a particular device or person was behind the address |
| A timestamp | What one source wrote, on one clock, in one time zone | The time an act occurred — until it is corroborated against a source running on a different clock |
| Deletion, encryption, or a wiping tool | That data was removed or made unreadable, and often by what mechanism | Intent, and the content of what was destroyed |
Using this before a deposition
The output is organised the way a cross-examination runs. The “what none of these establishes” list is the sequence of concessions a well-prepared examiner will make readily and a poorly prepared one will resist — and resisting them is more damaging than any of the concessions. Reading it from the other side, it is also the list of statements that should already be in your own expert’s report, disclosed by them rather than discovered on cross.
The “what would close the gap” list is generally not another artifact from the same machine. It is a second source running on a different clock, a device that has to be produced, a provider that has to be served, or a badge system whose retention window is shorter than everything else in the matter — which is why working out the preservation windows usually has to happen before any of this is examinable at all.
What this tool does not tell you
- It is not an examination of your evidence. It describes what classes of artifact record in general. Whether a given artifact exists on a given machine, whether it survived, and what it says are all questions only an examination of the actual media can answer.
- It does not cover every artifact or every platform. The entries lean Windows and cloud because that is where most disputes sit. macOS, Linux, mobile handsets, embedded systems and vehicle telematics all have their own artifact sets, their own retention behaviour, and their own overreaches.
- Artifact behaviour changes with the operating system version and the configuration. Fields are added and removed between Windows releases, defaults change, and a setting can disable a source entirely. Anything load-bearing should be verified against the specific build in front of you, not against a description of it.
- It cannot tell you whether an artifact will be admitted. Authentication, hearsay, privilege, proportionality and the standing orders of your forum all sit between an artifact existing and a jury seeing it, and none of them is a technical question.
- It is not advice about your matter. Nothing here tells you what to plead, what to concede, what to ask for in discovery, or how a court would resolve any of it.
Questions counsel ask
Can a forensic examiner prove that files were copied to a USB drive?
Usually they can prove a great deal short of that. The registry records which USB storage devices were connected and when; shellbags record folders that were browsed; LNK files carry the volume serial number of the media they point at; and the change journal records file-level activity on the local volume. Together those place a specific device on the machine and show a user browsing it. What no standard Windows artifact records is the byte-level copy itself. A careful examiner states what the artifacts show, corroborates with the device where it can be produced, and does not present inference as observation.
Why does it matter that an artifact records an account rather than a person?
Because the gap between them is where opinions get excluded. Shared credentials, a saved password, an unlocked screen, a remote session and an administrator using the account all produce the same record as the named user sitting down. Attributing an act to a person when the artifact establishes only an account or a device is the failure the 2023 advisory committee note to Rule 702 specifically names, which makes it an admissibility argument under Rule 702(d) rather than merely a point for cross-examination.
If there is no evidence a file was opened, does that mean it was not opened?
Usually not. Last-access timestamp updating is disabled by default on modern Windows, object-access auditing is off by default, and recent-file lists are capped and roll. So silence in these artifacts is far more often a statement about how the system was configured than about what the user did. The difference between 'the record was deleted', 'the record rolled', and 'the record was never kept' is usually testable, and the testing is the work.
Does a hash match prove that a file was stolen?
It proves that two files have identical content. It does not show the transfer path, the date the file arrived, who put it there, or that it came from the party alleging the theft at all — the same document may have reached both parties from a common source. And a non-match does not exclude copying: a file that was opened and re-saved, converted, or edited will not match while still being derived from the original.
How should a forensic report state a conclusion that the artifacts only partly support?
At the level the artifact actually supports, with the alternative explanations identified and with what in the evidence does or does not rule them out. Under Rule 702 as amended on 1 December 2023 the proponent must show it is more likely than not that the opinion reflects a reliable application of the method to the facts of the case, so calibrated language is not hedging — it is the standard. An opinion stated at the right level survives cross-examination; the same opinion stated one level too strongly gives the other side its whole argument.
WHEN THE ANSWER DEPENDS ON THE ACTUAL MEDIA
This tool describes what classes of artifact record. Whether the artifacts on a particular machine support a particular claim is an examination, and it starts with a scoping call about the question you actually need answered.
Bring the output above and it becomes the agenda for the call.
A conflicts check and scoping call follow, normally within one business day. Please do not send privileged or case-sensitive material until conflicts have cleared.
Other tools
- TOOL 01 / RETENTIONPreservation Deadline Calculator
Enter an incident date, pick the systems in play, and see when each source's default retention window closes — with the licence tier every figure depends on stated beside it.
- TOOL 03 / RETENTION DILIGENCEExpert Vetting Checklist
The nine-step vetting procedure and the eight documents to request, as a checklist you can work through, save in your browser, and print for the file.
- TOOL 04 / RULE 702Daubert Exposure Check
Twelve questions about an expert's methodology, mapped to the six failure modes that account for most digital-forensics exclusions, with the remediation for each gap.
- TOOL 05 / DISCLOSURERule 26 Report Check
The six things Fed. R. Civ. P. 26(a)(2)(B) requires a retained expert's report to contain, quoted in full, as a checklist against the report on your desk.
- TOOL 06 / JURISDICTIONDaubert or Frye Lookup
Which admissibility standard each state applies to expert evidence, including the states whose posture is mixed, state-specific, or has recently changed — and the amended federal Rule 702.
- TOOL 07 / SCOPEEngagement Scope Estimator
Build a scope schedule from device count, device type, question complexity, deadline and deliverable — the drivers that move a forensic estimate, itemised.
Attorney advertising / expert services. This tool describes forensic practice and the procedural rules that govern expert evidence in general terms. It is not legal advice, it does not create an attorney–client or expert-engagement relationship, and it is not a substitute for checking the rules, standing orders, and case law of your own forum. Prior results do not guarantee a similar outcome.