Digital forensics, from evidence handling to admissibility

Digital forensics is the branch of forensic science that identifies, collects, examines, and analyzes data from digital systems while preserving its integrity, so that what happened can be established and proved. It is also called cyber forensics or computer forensics, and it serves cybersecurity rather than replacing it.

Enterprise security teams need that capability for a practical reason. Regulatory notification obligations turn on the scope of a breach, and scope is a question about evidence rather than about alerts. Evidence only exists if someone preserved it before it rotated away, which makes forensics an architecture problem long before it becomes an investigation.

This guide covers the forensic process, what digital evidence is and what protects it, the branches of the discipline, how attackers attack the record itself, the standards and rules that decide what holds up, and the readiness work that has to happen first.

What is digital forensics?

The discipline goes by several names. NIST calls it digital forensics and notes it is "also known as computer and network forensics", describing it as "the application of science to the identification, collection, examination, and analysis of data while preserving the integrity of the information" (NIST SP 800-86, August 2006). Cyber forensics and computer forensics are near-synonyms for the same practice, and this page treats them as one topic rather than three.

The material it works on has a settled definition too. The National Institute of Justice defines digital evidence as "information stored or transmitted in binary form that may be relied on in court", and notes that it "is now used to prosecute all types of crimes, not just e-crime" (NIJ).

Is digital forensics the same as cybersecurity?

No. Digital forensics is a sub-discipline of forensic science applied to digital systems, and cybersecurity is the broader practice it serves. Cybersecurity works to prevent, detect, and stop attacks. Forensics starts after something has happened and asks a narrower question: what occurred, and can the answer be proved?

That distinction is easier to hold if you separate the three questions the neighboring disciplines answer.

Caption: The three disciplines overlap in tooling and staffing, but they answer different questions and are judged by different outcomes.

Incident response owns containment, eradication, and recovery, and forensics feeds it rather than duplicating it. The workflow that carries findings through triage and case management belongs to incident investigation, and the integrated motion that joins detection, investigation, and response is covered under threat detection, investigation, and response.

Why does digital forensics matter?

Because the questions a regulator, an insurer, or a court asks are evidentiary rather than operational. Which records were accessed, by whom, and when. Whether the copy presented is the same as the original. Whether anyone can show who handled it. An organization that stopped the attack but cannot answer those questions has solved the security problem and left the legal and regulatory one open.

How the forensic process works

NIST SP 800-86 describes the process as four basic phases, and this is the model most enterprise programs build on.

1. Collection: identifying, labeling, recording, and acquiring data from possible sources.
2. Examination: forensically processing collected data and extracting data of particular interest.
3. Analysis: analyzing examination results using legally justifiable methods to derive useful information.
4. Reporting: reporting results, describing actions used, and recommending improvements.

‍

‍

Do not confuse those four phases with NIST's definition of the discipline, which names identification, collection, examination, and analysis. The definition describes what the field does. The phases describe how a case runs.

The publication is also unusually direct about its own limits. NIST states the guide "should not be used as a guide to executing a digital forensic investigation", and adds that it should not be construed as legal advice or used as the basis for investigations of criminal activity. It is a framework for building a capability, not a runbook for running a case.

The handling counterpart to those phases comes from UK policing. The ACPO Good Practice Guide for Digital Evidence sets out four principles, of which the first is load-bearing: "No action taken by law enforcement agencies, persons employed within those agencies or their agents should change data which may subsequently be relied upon in court." The same document prints two dates, a cover reading March 2012 and running headers reading Version 5 (October 2011), so cite both.

Two techniques sit inside the middle phases. File carving recovers files from raw storage by their content signatures when filesystem metadata is gone or unreliable. Timeline analysis orders artifacts from multiple sources into a single sequence of events, which is usually where isolated findings become an account of an intrusion.

Documentation is not a phase. It runs through all four, because the record of what was done to the evidence is itself evidence. The triage, case management, and reporting workflow that picks up where the forensic process ends is covered under incident investigation.

Digital evidence and what protects it

What makes digital evidence usable is not the tool that collected it. It is the record of how it was handled.

Evidence disappears at different speeds, and collecting in the wrong order destroys the fastest-moving material first. RFC 3227, published as BCP 55 in February 2002 and still the reference, puts it plainly: "When collecting evidence you should proceed from the volatile to the less volatile." Its seven-tier example order was written for a single 2002-era host, so the useful move is to map each tier onto where that data lives in a modern enterprise.

RFC 3227 tier (2002)Modern enterprise equivalentRegisters, cacheCPU and hypervisor state, rarely collectable at scaleRouting table, arp cache, process table, kernel statistics, memoryLive host memory, container process state, network device tablesTemporary file systemsEphemeral container filesystems, serverless execution scratch spaceDiskEndpoint and server volumes, attached cloud block storageRemote logging and monitoring dataIdentity provider logs, cloud audit logs, centrally held endpoint telemetryPhysical configuration, network topologyCloud resource inventory, network device configuration, infrastructure-as-code stateArchival mediaBackups, object storage, log archive tiers

Caption: The RFC 3227 order of volatility rewritten for the environments enterprise teams actually investigate, most volatile at the top. The left column is quoted from RFC 3227 section 2.1; the right column is this page's mapping.

Acquisition is where integrity is won or lost. Forensic imaging makes a verified, bit-level copy of storage media so the original is never worked on, and the copy is what gets examined. Hashing supplies the proof: a hash digest computed at acquisition and recomputed later demonstrates that the working copy still matches the source. Evidence integrity is that property, and it is what turns a file into something a third party can rely on.

What is a write blocker?

A write blocker is a hardware or software control placed between an investigator's system and a piece of evidence media that permits read operations but blocks every write. It exists so that the act of examining a drive cannot alter the drive, which is what the first principle in the ACPO Good Practice Guide requires.

Chain of custody is the documented record of who handled a piece of evidence, when, and what they did to it. It sounds like paperwork and it decides cases. The clearest recent illustration comes from an EU institutional source, and its structure is worth copying. The Commission's informal guidance on contingency arrangements for the e-evidence system, which the Commission services state does not represent the Commission's official position, sets one functional requirement drawn from Article 19(5) of the Regulation: where the EU's own transmission system cannot be used, the fallback channel must be "swift, secure and reliable" and must allow "the recipient to establish authenticity". It then names, channel by channel, how that can be met. For secure electronic transfer, integrity can be confirmed "for example by requiring the service provider to communicate, or otherwise make available, a hash digest of the e-evidence for the purposes of integrity verification". For physical delivery, such means "may allow the recipient to establish authenticity where they provide a documented chain of custody and reliable evidence of dispatch and receipt" (Informal Commission guidance on contingency arrangements, last updated 11 July 2026).

Practitioner-level collection guidance is maintained rather than frozen. SWGDE's Best Practices for Digital Evidence Collection, document 18-F-002-2.0, carries a publication date of 20 November 2025. Two artifact classes that surface repeatedly during collection, indicators of compromise and network metadata, have their own dedicated coverage.

The branches of digital forensics

The branch you need is decided by where the evidence lives, not by what the attacker did.

Caption: Ten branches of digital forensics organized by the evidence source that defines each one.

Cloud is the branch where citing the current instrument matters most. NIST's active publication is SP 800-201, the NIST Cloud Computing Forensic Reference Architecture, finalized in July 2024, whose stated goal is "to provide support for a cloud system's forensic readiness". Its predecessor, NIST IR 8006 on cloud computing forensic science challenges, dates from August 2020. Lead with the newer one. Detection in that environment is a separate discipline, covered under cloud detection and response.

Mobile has its own NIST guidance in SP 800-101 Rev. 1, Guidelines on Mobile Device Forensics, published May 2014 and superseding the 2007 original. The revision is current, the original is not, and the two are frequently conflated.

The list keeps growing at the edges. INTERPOL runs standing expert groups on drone forensics, automotive and vehicle forensics, and digital forensics on shipborne equipment, a useful reminder that any device with storage eventually becomes an evidence source.

Network forensics and pcap analysis

Network forensics reconstructs an intrusion from what crossed the wire. Packet capture analysis, usually shortened to pcap analysis, is the core technique: reading captured traffic to establish which hosts talked to which, over what protocols, carrying what. Flow records and network device state fill the gaps where full capture is impractical.

It has one structural advantage over host-based branches, because network evidence is generated and stored away from the endpoint and therefore survives actions taken on the endpoint. It has one structural weakness too: you cannot capture retroactively, so the coverage decision has to have been made before the incident.

Draw the scope line clearly. This page covers network evidence, meaning what is preserved and what it proves. Using network data to find attacks in the first place is a different job, covered under network traffic analysis and network detection and response.

Malware forensics

Malware forensics, in the enterprise sense, is evidence recovery from an incident that involved malicious code: what was dropped, what executed, what it touched, and what persistence it left. That is a narrower question than classifying or reversing the sample, and the taxonomy side belongs to the malware page.

Anti-forensics and evidence tampering

Anti-forensics covers techniques that destroy, alter, hide, or fabricate the evidence record. Treating it as a detection and mitigation problem is the only useful framing here, so what follows describes what these techniques do to the record and what signal survives them.

The most important recent change is structural, and it shows up in the MITRE ATT&CK catalogue. The anti-forensics surface now spans two tactics that used to be one. TA0005 is titled Stealth and covers concealment behaviors that leave defensive systems intact. A separate tactic, TA0112 Defense Impairment, was created on 14 April 2026 and last modified on 12 May 2026, and covers techniques that "degrade, disable, or undermine the effectiveness and trustworthiness of security controls and monitoring mechanisms". It carries 18 techniques.

Caption: Where the main anti-forensics techniques sit in ATT&CK v19.2. Current placements are as published by MITRE. The "formerly" column reflects lineage recorded in research rather than lineage MITRE prints on the technique pages.

Attribute that change to the right release. The tactic restructuring shipped in ATT&CK v19.0 on 28 April 2026. The current release, v19.2 in August 2026, is ATT&CK's first Agile release, a narrower-scope model that publishes targeted updates to Groups, Software, and Campaigns outside the standard biannual cadence, and it moved Groups and Software rather than the tactic structure. The version number advanced without the taxonomy advancing.

The practical consequence is that log clearing and security tool tampering are now cataloged separately from indicator removal, so detection coverage mapped against the old single-tactic view will read as more complete than it is.

Anti-forensics has also industrialized. A recognized class of tooling now abuses vulnerable signed drivers to disable endpoint detection and response agents before credential access, lateral movement, and high-impact actions such as ransomware deployment. What that implies about evidence matters more than the technique: if the evidence source runs on the host the attacker controls, it is not a reliable evidence source.

Cloud ephemerality is the other structural limitation. Containers and serverless functions routinely terminate and are reclaimed before anyone decides to preserve them, so the evidence was never destroyed by an attacker. It simply expired.

Standards, admissibility, and currency

Authenticity and reliability are different things, and two legal systems said so within a few weeks of each other in 2026.

Admissibility

In US federal practice, Rules 902(13) and 902(14) of the Federal Rules of Evidence, both effective 1 December 2017, let certain electronic records be self-authenticated by the certificate of a qualified person instead of live testimony. Rule 902(14) is the one enterprise teams should know: it covers "data copied from an electronic device, storage medium, or file, if authenticated by a process of digital identification", which in practice means a matching hash. Neither subdivision is touched by the amendment cycle open for public comment from 14 August 2026 to 15 February 2027, which covers Evidence Rules 104 and 902(1).

Self-authentication is not the same as being believed. In the Committee Note accompanying its revised draft of proposed Rule 707, the Advisory Committee on Evidence Rules wrote that if AI output is the equivalent of expert testimony, self-authentication under Rule 902(13) is not enough, because "that rule covers authenticity, but does not assure reliability under the preponderance of the evidence standard applicable to expert testimony" (Report of the Advisory Committee on Evidence Rules, 17 May 2026). That is the sharpest primary statement available of the gap between proving a record is what you say it is and proving it can be relied on.

Rule 707 itself is proposed but not adopted, and remains under committee consideration as of August 2026. At its 7 May 2026 meeting the Advisory Committee declined to recommend action, revised the draft, retitled it "Evidence Produced by Artificial Intelligence and Presented at Trial Without an Expert" after commenters found "machine-generated" overbroad, and referred it, with the problem of deepfakes, to further study.

On the civil side, Rule 37(e) of the Federal Rules of Civil Procedure supplies remedies where electronically stored information that should have been preserved is lost because a party failed to take reasonable steps to preserve it. That is what converts forensic readiness into a legal duty.

Cross-border evidence

Regulation (EU) 2023/1543 on European Production and Preservation Orders applied from 18 August 2026, and its companion Directive (EU) 2023/1544 applied from 18 February 2026. Under the Regulation, service providers "are required to designate an establishment or appoint a legal representative in the Union", and must respond "within 10 days, and within 8 hours in cases of emergency", against comparators the Commission gives as up to 120 days for a European Investigation Order and an average of 10 months for a Mutual Legal Assistance procedure (European Commission). Penalties run to 2% of a provider's total worldwide annual turnover (Regulation (EU) 2023/1543, Official Journal text).

The Commission itself pre-published a fallback. Anticipating that the decentralised IT system would not be uniformly operational, the Commission services issued informal guidance on the Article 19(5) contingency route, last updated 11 July 2026 and opening with the observation that the Regulation "will apply from 18 August 2026". A disclaimer must travel with any use of it: the guidance "has been prepared by the Commission services", "does not represent the official position of the European Commission and does not bind the Commission in any way", and only the Court of Justice of the European Union can authoritatively interpret EU law. Technical specifications for the system sit in Commission Implementing Regulation (EU) 2025/1550, and the guidance points to Section 3.3 of that act.

UK practice adds a third layer: Version 2 of the Forensic Science Regulator's Code of Practice, reported in the Regulator's annual report for 2024 to 2025, removed the accreditation requirement for incident examination and scheduled its return.

Standards and legal currency, verified 2026-08-25

Caption: Standards and legal instruments this page relies on, with the status each carried when it was checked on 25 August 2026.

The claim that these standards are uniformly stale does not survive contact with the SWGDE catalogue. Some instruments are old because they were right the first time, and RFC 3227 is one of them.

Caption: Four sources worth re-checking on this topic, and the specific way each one misleads a careless reader.

Forensic readiness versus forensic response

Forensic readiness is the pre-incident architecture work that makes an investigation possible: retention settings, an inventory of evidence sources, and decisions about what to preserve before it rotates. Response is what happens afterwards. NIST SP 800-86 backs the enterprise framing, stating that "practically every organization needs to have the capability to perform digital forensics."

Caption: Readiness and response are different activities with different owners, and only one of them fails silently.

The retention arithmetic

Readiness becomes a calculation here. Frontline investigation data for 2025 put the global median dwell time at 14 days, up from 11, and the median for cyber espionage and North Korean IT worker incidents at 122 days (M-Trends 2026, 23 March 2026, grounded in over 500,000 hours of investigations). The tail is what breaks investigations: "with threats like BRICKSTORM achieving dwell times of nearly 400 days, standard 90-day log retention policies leave organizations completely blind to the initial access vector and the full scope of the intrusion."

Set that against a common default. Audit log retention in a widely deployed enterprise productivity suite defaults to 180 days, changed from 90 days on 17 October 2023 (auditing solutions documentation). A 122-day dwell time sits outside a 90-day window and inside a 180-day one, and against a 400-day intrusion both lose. Sharper still, audit records from non-user entities such as service principal actions and system events "are retained for a fixed period of one year", and that "retention period isn't configurable" by custom policy. Ten-year retention needs a per-user add-on license and is not retroactive, so it cannot rescue an investigation into something that already happened.

Across all 2025 investigations, organizations first detected malicious activity internally 52% of the time, up from 43% in 2024, and finding intrusions yourself shortens the period over which evidence has to survive. Detection and retention are two halves of one problem.

What the six-government guidance asks for

The most on-point standards work here is not a forensics standard. In February 2025 the NCSC, with the Australian Signals Directorate, CISA, the Canadian Centre for Cyber Security, the FBI, and NCSC-NZ, published guidance on digital forensics and protective monitoring for network devices and appliances, setting out "the minimum requirement for forensic visibility, to help network defenders secure organisational networks both before and after a compromise".

Its volatile data collection list is effectively RFC 3227 rewritten for 2025 network appliances, covering process trees, memory maps, loaded modules, kernel and per-process memory, firewall and packet-processing rules, network connections, ARP entries, CAM tables, DHCP leases, active sessions, crash dumps, and system logs.

A blog post on 29 July 2026 extended the argument under a new label, and the shift matters when you search for either document: the 2025 guidance says forensic visibility, the 2026 blog says forensic observability. The blog states that "forensic observability is particularly important for edge devices such as firewalls, VPN gateways and other network appliances", and describes defenders on a compromised appliance falling back on reverse engineering, with the blunt summary that "they can have fewer tools available to them than the attacker".

A readiness checklist

• Inventory every evidence source before you need one.
• Record the retention window on each source.
• Check which retention windows you cannot configure.
• Preserve identity provider and help desk logs deliberately.
• Keep network evidence off the endpoints it describes.
• Test that an export is actually retrievable.
• Re-check defaults after every platform migration.

One case pattern makes the identity item concrete. When initial access is a legitimate credential reset obtained through a help desk, host artifacts show nothing anomalous, because nothing anomalous happened on the host. The record lives entirely in identity provider and help desk logs, the logs least likely to be retained long enough.

What makes a log forensically useful is narrower than what makes it operationally useful: a trustworthy timestamp, a resolvable actor, an interpretable action, and a retention window longer than the dwell time you expect. Which sources exist and what they emit belongs to security telemetry and network metadata, aggregation to SIEM and network detection and response. Two investigation types lean hardest on this groundwork: insider threats, where the activity is authorized and only the intent is not, and data breach scoping, where the notification clock runs on evidence you either kept or did not.

Modern approaches to digital forensics

Tooling questions here are usually asked as "which tool is best" and are better answered by category, because the category determines what evidence you get and the maintenance status determines whether you can trust it.

Caption: Forensic tooling by category, with the maintenance signal that decides whether a given tool can be relied on.

Two failure modes get bundled together and should not be. The first is dormant software presented as current. Memory forensics is the clearest case: the Volatility Foundation announced on 16 May 2025 that with the official release of Volatility 3, Volatility 2 was deprecated and its repository archived, and the repository itself carries that archive date. It still turns up on tool lists badged for the current year.

The second is maintained but vulnerable, which a last-release-date check scores as healthy. A documented intrusion campaign installed an outdated build of an open-source DFIR collection and orchestration platform on compromised hosts and used it to pull further tooling, reducing the need to deploy custom malware (trade coverage of the campaign, 11 October 2025). The project is actively maintained and a patched release exists. The attacker simply chose an unpatched build, taking advantage of a medium-severity authorization flaw carrying a CNA-assigned base score of 5.5 (NVD, CVE-2025-6264, record last modified 17 June 2026). Sorting a tool list by last release year would miss that entirely.

How Vectra AI thinks about digital forensics

Vectra AI's position follows from the through-line of this page: if the evidence source runs on the host the attacker controls, it is not a reliable evidence source. Attack Signal Intelligence is built on continuously observed behavior across network, identity, and cloud, held centrally and independently of the endpoints it describes, which is what makes a reconstruction possible after the fact rather than only during the event. The second half matters as much as the first. Findings have to be defensible to people who were not in the room, so the output is structured for executives, auditors, and operators as well as for the analyst who produced it.

‍