Checkout the business version of this blog to fully understand the business side of this play.
An auditor will not ask whether you recorded the call. You obviously did — the file is right there.
They will ask you to prove six things about that file: that it is complete, when it was made, that it has not changed, that nobody could have removed it, who has touched it since, and that the copy you hand over is the same thing. A file in a bucket answers none of those. Every answer is a piece of evidence the pipeline had to produce at the moment it did the work, and a recording architecture audit is where you find out which ones it never produced.
This post walks the pipeline stage by stage and names the evidence each one owes. Recorder pools, scaling and storage tiers are covered in the recording pipeline at scale; this is about what that pipeline has to be able to prove.
What a recording architecture audit actually asks
The legal root is short. Federal Rule of Evidence 901(a) requires "evidence sufficient to support a finding that the item is what the proponent claims it is." One of the listed ways to meet it, 901(b)(9), is "evidence describing a process or system and showing that it produces an accurate result."
That clause is the design brief. You do not prove a recording by pointing at it; you prove it by describing the system that made it and showing the system is reliable. India's Bharatiya Sakshya Adhiniyam, 2023 has the same shape: section 63 requires a certificate that identifies the electronic record and describes the manner in which it was produced. If you want the legal side in full, start with what a chain of custody actually is. What follows is the engineering side.
The auditor asks | What proves it | Stage that owes it |
|---|---|---|
Is it complete? | Numbered segments, a manifest, gaps recorded as data | Capture |
When was it made? | Media-to-wall-clock mapping, plus an independent timestamp | Capture + manifest |
Has it changed? | Hashes written at capture and chained together | Write path |
Could it have been removed? | Retention no administrator can shorten | Storage |
Who has touched it? | An access log that is itself tamper-evident | Access |
Is this copy the original? | An export package that carries its own proof | Export |
None of those can be bolted on after the incident. Start with the first.
Completeness: prove nothing is missing
A recording that silently lost forty seconds is worse than one that visibly did, and completeness is the first thing a recording architecture audit checks. A gap you disclose is a fact. A gap the other side finds is a credibility problem for every other file you hold.
The fix is structural. Write the recording as numbered segments of a few seconds each, and append each one to a manifest as it lands. If the recorder crashes, the manifest shows exactly where the sequence stopped; when it restarts, it opens a new sequence that records the gap, its duration and the reason. Missing time becomes an entry in the evidence rather than an absence in it.
The recorder model changes how much a single failure costs. Composite recorders render the call in a browser and encode the screen — Jibri works "by launching a Chrome instance rendered in a virtual framebuffer and capturing and encoding the output with ffmpeg," and "only one recording at a time is supported on a single jibri." When that instance dies, the whole session's recording dies with it. Per-track capture writes each participant's media as it arrives — LiveKit's track egress with the passthrough preset "writes the track in its native container" — so a failure costs one track, not the session.
That is not the only difference between the two, and not the largest one for compliance. The bigger consequence — whether you can redact — belongs to composite vs per-track recording.
A complete set of segments still has to say when it was recorded. The timestamp inside the media is not that.
Time: the media clock is not the wall clock
Real-time media carries RTP timestamps, and RFC 3550 is explicit about what they are not: "RTP timestamps from different media streams may advance at different rates and usually have independent, random offsets." An RTP timestamp tells you how far apart two frames were. It does not tell you what time it was.
The bridge is the RTCP sender report, which pairs a wall-clock NTP timestamp with the RTP timestamp that corresponds to the same instant (RFC 3550, section 6.4.1). A recorder that keeps those pairs alongside its segments can map every frame to clock time and re-align per-track files later. A recorder that throws them away has files that can be played but not placed in time — and a recording architecture audit will ask exactly where each frame sits in time. Surveillance deployments hit the same problem across cameras, which is why four angles drift out of alignment.
Two more requirements finish the job:
- The recorder's own clock is disciplined and its offset is logged. A mapping to a wrong clock is precise and useless.
- An independent, trusted timestamp seals the manifest. A time-stamping authority under RFC 3161 provides "proof that a datum existed before a particular time," and it timestamps only a hash — the TSA is required "not to examine the imprint being time-stamped in any way (other than to check its length)." The media never leaves your infrastructure, and one request per manifest is enough.
Knowing when a recording was made only matters if you can show it has not changed since.
Integrity: hash the chain, not just the file
The common approach is to compute a SHA-256 hash of each file at write time and store it somewhere else. That catches modification: change one byte and the hash no longer matches. It does not catch deletion, which is where many pipelines fail a recording architecture audit. Remove a segment and its entry in the hash list, and what is left is internally consistent.
The fix is to chain them. Each segment's record includes the hash of the record before it, so deleting or reordering one breaks every link after it. This is a known, working pattern: AWS CloudTrail's log file validation hashes every log file, writes an hourly digest of those hashes, signs it, and "each digest file also contains the digital signature of the previous digest file," which makes it "computationally infeasible to modify, delete or forge CloudTrail log files without detection." Apply the same structure to recordings: segment hashes roll up into a per-session manifest, the manifest is signed, and each manifest points at the one before.
At archive scale — years of sessions — a Merkle tree does the same job more efficiently. RFC 6962, the Certificate Transparency spec, uses one to show "that any particular version of the log is a superset of any particular previous version," and an audit path proves a single entry exists in the tree without handing over the rest. For recordings, that means proving one session belongs to an untampered archive without disclosing every other session in it.
Approach | Detects edits | Detects deletion | Detects reordering | Proves one item cheaply |
|---|---|---|---|---|
Per-file hash | Yes | No | No | Yes |
Hash chain | Yes | Yes | Yes | No — replay the chain |
Merkle tree | Yes | Yes | Yes | Yes — audit path |
Detection is half the problem. The other half is making the deletion impossible, and the most common setting for that does not do what teams think it does.
Immutability: the WORM setting that doesn't protect you
S3 Object Lock has two retention modes, and the difference between them is the whole question an auditor asks.
Mode | What AWS documents | The auditor's question answered |
|---|---|---|
Governance | Users can't delete or alter lock settings "unless they have special permissions" — anyone with s3:BypassGovernanceRetention can | Who can delete this early? Anyone granted one IAM permission |
Compliance | Can't be overwritten or deleted "by any user, including the root user"; the retention period "can't be shortened" | Who can delete this early? Nobody, short of deleting the account |
Governance mode is what gets switched on, because it is reversible and safe to test. It then gets described as WORM in the compliance questionnaire. That is a policy, not immutability, and the distinction is exactly what the recording architecture audit question "who can delete this before retention ends?" is designed to find.
Compliance mode has a real cost, and it is worth stating plainly. A wrong retention period cannot be fixed: set ten years on the wrong prefix and you store that data for ten years. The workable pattern is to test in governance mode, move production to compliance mode, and set retention per class of record rather than per bucket. Litigation is handled separately with a legal hold, which "doesn't have an associated fixed amount of time and remains in effect until removed." On-premise object stores offer equivalents; ask them the same question.
That settles who can delete a recording. It leaves who can read one.
The access log is evidence too
Every play, download, export, retention change and legal hold is an event the audit will ask about: who, when, which object, from where. A log kept in the same place, editable by the same administrator, proves nothing about that administrator.
So the log gets the same treatment as the recordings: chained hashes, a separate store with its own lock, and no write path from the people it records. CloudTrail validation covers this for calls to the storage API. It does not cover your application — a support agent pressing play inside your own dashboard is invisible to it — so application-level access needs its own log, built the same way.
Everything so far lives inside your system. The final test happens outside it.
Passing a recording architecture audit: the export package
The copy you hand over is what gets examined, so the copy has to carry its own proof. The forensic video community is specific about format. SWGDE's guidance on acquiring video from recorders states that "a native file format or proprietary file format is likely to provide best evidence for legal authenticity purposes as it is closest to the original manner of recording." A convenient MP4 is fine as a working copy. It is not the evidence.
Nor can the file vouch for itself. SWGDE's video authentication guidance warns that metadata "is susceptible to alteration without affecting the playback of the file" and "cannot be relied upon in isolation." The proof travels beside the file:
In the package | What it proves |
|---|---|
Native segments or per-track files | Closest to the original recording |
Manifest with segment hashes and recorded gaps | Completeness |
Sender-report timing pairs and recorder clock offset | When each frame happened |
RFC 3161 timestamp tokens | Time, independent of your own clock |
Chain or Merkle proof for the session | Nothing changed, nothing removed |
Verified extract of the access log | Who touched it |
A hash of the package itself | The copy is the copy |
Both legal systems ask for the same number at the end. In the US, Rule 902(14) lets copied data self-authenticate "by a process of digital identification," and the Committee Notes explain this is "ordinarily" done by hash value. In India, the certificate in the BSA's Schedule asks for "the HASH value/s of the electronic/digital record/s" and the algorithm used — SHA1, SHA256, MD5 or another acceptable standard — in both the party's part and the expert's. The architecture decides whether you have had that hash since the moment of capture, or compute it the day before the hearing. Who signs, and how exports are handled, are the procedures and people that make footage usable later.
Every item in that package is produced where the recording is processed and stored. Which makes the location of that processing an audit question in its own right.
Where the chain has to run
If a hosted service records and stores for you, part of the custody chain runs inside the vendor's systems, and your evidence of what happened there is whatever the vendor chooses to expose. That can be perfectly adequate. Ask for it in writing: segment manifests, retention mode, access logs and export format.
Building on open source puts the whole chain in your hands. The recorders produce files; the manifest, the hash chain, the timestamp tokens and the log integrity are yours to build, and they are where the audit is actually passed. Because an SFU forwards media without decoding it — the property that makes it scale — per-track capture fits it naturally, while a composite recording has to mix, as an MCU does.
A commercial platform deployed on your infrastructure sits between the two. Samvyo is one such option: based on SFU architecture, with recording processing and storage kept on infrastructure you control, so the custody chain runs inside your own boundary. Where it does not fit: if nothing you record will ever need to be proven, all of this is overhead, and a hosted recording API is the simpler choice.
The Bottom Line
A recording architecture audit does not test whether you recorded. It tests whether the pipeline produced evidence of completeness, time, integrity, immutability, access and faithful export at the moment it did the work — and none of those can be reconstructed afterwards.
Check two things first, because they fail most often: whether your hashes are chained or merely stored, and whether your object lock is in compliance mode or only described as if it were.
What's Next
For the recorder models, scaling and storage tiers underneath every recording architecture audit, read what runs behind the recording pipeline at scale. For why storage and compliance break before live streaming does, see the compliance trap in recording at scale. The business companion covers what each regime in the EU, US and India actually demands.
Frequently Asked Questions
What does a recording architecture audit check?
It checks whether you can prove six things about a recording: that it is complete, when it was made, that it has not changed, that it could not have been deleted, who has accessed it, and that an exported copy matches the original. Each of those needs evidence the pipeline produced at capture time — segment manifests, timing data, chained hashes, locked retention, a tamper-evident access log and a self-proving export package.
Is SHA-256 hashing enough to pass a recording architecture audit?
It proves a file has not been modified, but not that a file has not been removed. If someone deletes a segment and its hash entry, what remains is consistent. Chaining the hashes — each record including the hash of the previous one — makes deletion and reordering detectable too.
What is the difference between S3 Object Lock governance mode and compliance mode?
In governance mode, any user with the s3:BypassGovernanceRetention permission can delete a locked object early. In compliance mode, no user can, including the root user, and the retention period cannot be shortened. Only compliance mode answers "who can delete this before retention ends?" with "nobody."
Why can't I use the timestamps inside the video file as proof of when it was recorded?
RTP media timestamps measure the spacing between frames, not the time of day, and each stream starts from a random offset. Wall-clock time comes from RTCP sender reports, which the recorder has to keep, plus a disciplined recorder clock. For time that does not depend on your own systems, add an RFC 3161 timestamp over the manifest hash.
Does an RFC 3161 timestamp send my recording to a third party?
No. The time-stamping authority receives only a hash of the data and is required not to examine it beyond checking its length. The recording itself never leaves your infrastructure.
Is composite or per-track recording better for audits?
Per-track capture limits the damage of a recorder failure to one track and keeps each participant's media separate, which matters later for redaction. Composite recording produces one polished file but depends on a single recorder instance for the whole session. Many deployments capture per-track and compose afterwards.
Can we keep recordings and their audit evidence on our own infrastructure?
Yes, if the platform lets recording processing and storage run on infrastructure you choose. Samvyo works this way, so the manifests, hashes and logs that make up the custody chain stay inside your own boundary. You still own the retention and key-management decisions.
