Every competent DFIR team can tell you what happened. They can reconstruct the timeline, recover deleted files, map network connections, and produce a forensically sound disk image in under an hour. The problem, one that has quietly embarrassed investigators for decades, is the next sentence. The one that starts with “and therefore, the person responsible was…”

cover

That transition, from artifact to accountable human being, has no rigorous standard. It gets handled differently depending on the examiner, the organization, the jurisdiction, and occasionally the mood of whoever is writing the report. That gap is exactly what the FACT Attribution Framework (v1.1, published December 2025 on Zenodo) is designed to close.

In brief

  • FACT stands for Forensic Compliance, Analyze Evidence, Correlate & Sequence, Testify & Transfer Findings, four stages that make up the full attribution lifecycle.
  • The framework draws a hard, explicit line between identification (device, account, action) and attribution (person, accountability), and treats conflating the two as an error, not a shortcut.
  • It wraps existing DFIR lifecycles in legal bookends: authority and compliance at the start, reporting and testimony-ready reasoning at the end.
  • FACT defines who is authorized to make each type of claim in an investigation, keeping examiner roles clean and conclusions defensible.
  • Version 1.1, the current release, reflects review by practitioners, attorneys, analysts, and instructors, and provides the legal and logical architecture that current DFIR processes generate evidence for, without replacing any of them.

The problem FACT is solving

There is a specific failure mode in digital investigations that almost nobody talks about openly, probably because it is embarrassing. An examiner recovers an artifact, ties it to an account, ties the account to a name, and writes that name into the final report next to the word “perpetrator.” The chain of reasoning in between usually gets summarized as “forensic analysis confirmed.” This works fine until the report reaches a courtroom, an HR panel, or a regulator. At that point, someone asks a simple question: how do you know a specific human being performed that action? And the answer, more often than it should be, is “…because the artifact was on their device.”

Brett Shavers, the framework’s author, is direct about this: “DF/IR doesn’t usually fail on the technical work. It fails at the exact moment someone gets impatient and confuses activity with identity, and then confuses identity with attribution.” FACT draws a hard line between identification (this device, this account, this action, at this time) and attribution (this specific person bears responsibility for that action). Those are not the same claim and they do not require the same evidence standard. Every examiner knows this intuitively. Very few frameworks force them to work it explicitly.

The distinction matters more today than it did ten years ago. Shared accounts, cloud-synced credentials, VMs, roaming profiles, and multi-user endpoints have made the device-to-person equation genuinely ambiguous in a large percentage of real investigations. The old mental shortcut, “the file was on their laptop, QED,” is increasingly a liability, both legally and professionally.

A typical insider-leak case makes the gap visible. An employee is accused of exfiltrating a sensitive document. The examiner recovers the file from the workstation, finds a matching copy in a cloud account tied to the corporate credentials, and reconstructs a network connection at 2 AM. The draft report names the employee. The case reaches arbitration, and defense counsel shows that the workstation was shared across a hot-desking rotation, that the corporate SSO cached the credentials on every machine in the pool, and that the cloud account was a team resource. The attribution collapses, and the organization is left with no defensible finding on a genuine incident.

The four stages of FACT

The framework is built around the acronym that gives it its name. Each letter represents a stage in the attribution lifecycle, and the stages are designed to be sequential and mutually reinforcing.

Forensic Compliance is the opening stage, and it sets the legal and procedural boundaries for everything that follows. Before a single artifact is examined, FACT requires that the investigator establish the authority under which the investigation is being conducted, validate that evidence acquisition meets applicable legal and jurisdictional requirements, and document the chain of custody from the start. This is not a box-ticking exercise: the stage explicitly determines who is authorized to conduct the investigation and what conclusions they are permitted to reach. An examiner working under a corporate HR mandate has a different authorization envelope than one operating under a court order, and FACT makes that boundary visible.

Analyze Evidence is the stage most DFIR practitioners are already comfortable with. It is where artifacts are examined, validated, and characterized: file metadata, registry keys, log entries, network telemetry, volatile memory contents. FACT does not prescribe specific tools here. You can use Volatility, YARA-X, or any combination of forensic tools appropriate to the case. What FACT adds is a requirement that findings at this stage stay at the identification level, with attribution deferred to the later stages. “This artifact was present on this device at this timestamp” is an identification. “This person created this artifact” is not, yet.

Correlate & Sequence is where the framework earns its complexity. This stage requires investigators to build the explicit logical bridge between the artifact evidence and the identity claim. Correlation might involve account linkage, biometric authentication records, physical access logs, behavioral patterns, communications metadata, or geolocation data. Sequencing imposes temporal coherence: the claimed attributable actions must fit into a consistent, evidence-supported timeline. For mobile evidence in particular, this is where most attribution claims either solidify or collapse, a challenge anyone who has worked on Android pattern-of-life analysis will recognize immediately. FACT does not tell you what correlation evidence is sufficient; it forces you to state what you have, what it supports, and what its limitations are.

Testify & Transfer Findings closes the cycle. This is the stage where conclusions must be articulated in a form that can survive scrutiny: legal proceedings, administrative hearings, regulatory reviews, or organizational governance processes. FACT distinguishes between the examiner role (who can state what the evidence shows) and the attribution role (who has the authority and the full evidentiary basis to say who is responsible). Keeping those roles clean is not procedural pedantry. It is what prevents examiners from being cross-examined into corners because they overclaimed their conclusions in the report.

What makes FACT structurally different from most existing frameworks is its explicit treatment of authority and role separation throughout the lifecycle. Most DFIR models describe what to do. FACT also describes who is permitted to do what, and what each role is allowed to conclude.

This matters in practice because attribution claims carry legal weight that identification claims do not. An examiner can testify to artifact characteristics without exposing themselves to challenge on the question of intent or identity. An investigator or decision-maker with broader contextual authority can make the attribution claim, provided the underlying examination record supports it. FACT creates a documented handoff between those layers rather than letting them blur together in a single report signed by someone who was only authorized to do the technical work.

The framework also handles the AI-era complications that are starting to appear in DFIR work. When autonomous agents act on behalf of users, or when LLMs generate outputs that get confused with user-generated content, the device-to-person attribution chain becomes even less reliable. A scenario discussed in recent DFIR circles illustrates the problem: an enterprise chatbot with broad system access is manipulated through a long prompt chain to copy a customer database to an external location. The artifacts on disk include a system service account, a scheduled task, and a network connection. The naive reading is that the user whose credentials were in the logs did it. The actual actor was an agent acting on a prompt, and the user is at most negligent about their own prompt hygiene. FACT’s insistence on explicit, documented logical steps from artifact to person makes it a more future-proof methodology than frameworks that assume a simpler attribution environment.

Adoption and practical fit

FACT v1.0 was released in December 2025 after pre-release review by 36 practitioners spanning law enforcement, corporate DFIR, consulting, academia, and the legal sector. The feedback, according to Shavers, was consistent: existing frameworks do not provide a structured, defensible approach to person-level attribution, and FACT fills that gap without replacing anything already in use. Version 1.1 followed shortly after, incorporating multidisciplinary expert feedback and formalizing the attribution pathway. The full specification is published on Zenodo under a DOI-registered citation, the same record linked in the introduction.

For practitioners, the immediate question is where FACT fits relative to existing process. The answer is: at the edges. FACT does not replace your acquisition workflow, your tool stack, or your incident response playbook. It provides the legal and logical architecture that those processes generate evidence for. Think of it as the framework that answers the question your current lifecycle doesn’t ask: can you defend not just what you found, but who you said did it, and on what authority?

Concretely, FACT is designed to sit alongside the established DFIR and evidence-handling guidance that most organizations already follow. NIST SP 800-86 covers integrating forensic techniques into the incident response lifecycle. ISO/IEC 27037 prescribes identification, collection, acquisition, and preservation of digital evidence. The older RFC 3227 guidelines on evidence collection and archiving still show up in many IR playbooks. What those documents do not prescribe, and what FACT adds, is the explicit attribution layer and the role separation needed to defend person-level conclusions downstream of the technical work.

For teams that want to adopt FACT, the on-ramp is intentionally low. A practical first step is to map your current investigative workflow against the four stages: identify where authority is established, where identification claims stop, where correlation begins, and where conclusions are documented for handoff. Then define, in writing, who in your organization is authorized to make each type of claim. Most teams complete this exercise in a single working session and immediately surface gaps that previously lived as informal practice.

In environments subject to DORA, NIS2, or sector-specific compliance requirements, the attribution question has stopped being optional. Regulators are starting to ask for more than technical findings. They want to know who was responsible, how that determination was made, and whether the chain of reasoning is defensible. FACT provides exactly that structure. Being free, openly licensed, and DOI-registered on Zenodo also removes the usual barriers to adoption.

It is worth being explicit about what FACT does not do. It does not produce evidence on its own, and it does not substitute for sound forensic acquisition or sound investigative judgment. Where authority structures are unclear, where roles overlap, or where the organization is unwilling to keep identification and attribution separate in the final report, FACT will document those weaknesses rather than resolve them. The framework’s value scales with the rigor of the process around it.

FAQ

What is the FACT Attribution Framework?

FACT (Forensic Compliance, Analyze Evidence, Correlate & Sequence, Testify & Transfer Findings) is a legally grounded investigative model designed to bridge technical digital evidence and defensible human attribution in DFIR and incident response contexts.

How does FACT differ from existing DFIR frameworks?

Existing frameworks focus on documenting activity. FACT adds a structured, legally accountable pathway from artifact to person, drawing a hard line between identification and attribution and defining who is authorized to make each type of claim.

Who should use the FACT Attribution Framework?

FACT is relevant for digital forensics examiners, incident responders, corporate investigators, law enforcement analysts, and attorneys involved in cases where person-level attribution must be established and defended under scrutiny.