Standards for forensic capture

Listing standards in a report is easy. Meeting them is much less so, and telling the two apart is precisely the job of anyone assessing evidence. This guide explains what each standard requires and how to recognise those who cite without applying.

A premise worth more than the list

There is a substantive difference between a conformance reference and a certification. A reference means: this tool is built to that specification, and produces artefacts anyone can check. A certification is an attestation issued by an accredited body, after an audit, with a scope and an expiry.

Many products display badges suggesting the second while delivering the first. The question that dissolves the ambiguity is always the same: which verifiable artefact demonstrates this conformance? If the answer is a file you can open and examine, conformance is substantive. If it is an image on a website, it is not.

A standard is not a badge to hang: it is a constraint visible in the artefacts produced. If it leaves no trace in the file, it was not applied.

The overview

ISO/IEC 27037: the process reference

The international standard on handling digital evidence. It defines four phases — identification, collection, acquisition, preservation — and the documentation, traceability and repeatability requirements accompanying them.

The point where adherence is really measured is the interval between collection and acquisition: that is where a chain of custody breaks. Documenting today and «certifying» next week satisfies the letter of the list while leaving open exactly the window the standard aims to close. Developed further in chain of custody for photographic evidence.

SWGDE: the operational guidance

The Scientific Working Group on Digital Evidence publishes operational documents widely adopted in forensic practice. The one most relevant to field capture is 18-F-002, «Best Practices for Digital Evidence Collection».

A warning about how these documents get cited, because the imprecision is widespread: SWGDE codes identify documents with very specific subjects, and using them as generic labels is wrong. Two examples frequently encountered: 17-V-002 is not a general document on «forensic video and audio» but concerns data acquisition from digital video recorders; 23-I-001 is not about imaging in the forensic-copy sense, but about legal and scientific support for the admissibility of image examinations. Before citing a code, open the document and read its title.

Finally, worth flagging which document is not relevant: 18-F-003 concerns the mobile device as evidence from which data is extracted — a completely different scenario from a tool that creates evidence in the field. Claiming it would be wrong.

RFC 3161: timestamping

Defines the protocol by which a third-party authority attests that data existed at a given instant. The mechanism is described in the date of a photo: only the fingerprint travels, never the content.

Two clarifications separating correct use from loose use. First: an RFC 3161 timestamp is not automatically qualified. Public timestamping authorities are technically sound but are not qualified trust service providers under eIDAS; «accredited» does not equal «qualified». Second: timestamping only the media leaves the rest of the package uncovered — which is why the timestamp must also be applied to the signed inventory of supporting files.

BagIt (RFC 8493): the container

Specifies a packaging format for reliable transfer of file sets, originating at the Library of Congress. It provides a folder for content plus supporting files declaring composition and fingerprints.

The property that matters evidentially is not only integrity checking but the completeness check: every file present in the content must be declared. It prevents material being slipped in after sealing — a manipulation more insidious than editing an existing file.

CASE / UCO: interoperability

An ontology for structured representation of investigative data — exhibits, devices, locations, relationships between entities. It serves a practical goal: that the file can be imported into the analysis tools an expert already uses, without manual conversion.

It also has a defensive function towards the vendor: a package in a standard format outlives whoever produced it. If the maker shuts down, the evidence stays readable. That is the criterion for assessing any tool of this kind.

EXIF 2.32: metadata

Defines the fields a camera writes into the file. In a forensic context the requirement is not to enrich them but to preserve them: make, model and original date must remain as the device wrote them, and any addition must be declared and distinguishable.

Take care not to attribute to EXIF a weight it does not have: it can be edited with free tools and proves nothing on its own. It becomes reliable only when included in a signed manifest. Developed in EXIF metadata: what it actually proves.

eIDAS: the legal plane

Regulation (EU) 910/2014 is the only reference on the list operating on the legal rather than technical plane. Two relevant provisions:

• Article 41 provides that a qualified electronic time stamp enjoys a presumption of the accuracy of the date and time it indicates and of the integrity of the data it is bound to.
• Article 46 provides that an electronic document shall not be denied legal effect and admissibility as evidence solely on the grounds that it is in electronic form.

Hence a useful clarification: Article 46 says electronic form is not a ground for exclusion. It does not say any electronic file is solid evidence — challenges on date, integrity and provenance all remain available to the other side. It is a precondition, not a guarantee.

On content provenance

There is one area where a standard is frequently cited improperly: content provenance marking. LOCUS embeds an information block in the media that is inspired by C2PA and JUMBF but is not standard C2PA, and is not readable with Content Credentials ecosystem tools.

We say so because it is exactly the kind of claim a competent opposing party checks — and finds false, if it is. The authoritative guarantees remain the signed manifest, the RFC 3161 timestamps and the cryptographic fingerprints: the provenance block is an additional, self-asserted layer. Covered in photo authenticity in the age of AI.

How to test a conformance claim

Three questions, in order of usefulness:

Which file demonstrates it? Conformance to RFC 3161, BagIt, CASE/UCO produces specific files, present in the package and open to inspection. If they are absent, conformance is merely declared.

Can it be verified without the maker's software? Hashes and timestamps are checked with system tools. If the vendor's application is unavoidable, trust concentrates on them — which is the problem standards exist to avoid.

What does it declare it does NOT do? The most informative question. A tool listing only guarantees and no limits has not been described precisely, and unstated limits are exactly where an opposing party will look.

See also the standards page and the glossary.