Tutorials Enterprise

Compliance Recording and Archive Obligations

Professional · ~18 min

Overview

Broadcasters are generally required to record what they transmit and keep it for a defined period, so that complaints, disputes, and regulatory queries can be assessed against what actually aired rather than against what was scheduled. It is an unglamorous system with unusually strict requirements: it must never miss anything, the recording must be demonstrably of transmitted output, and retrieval must be fast enough to answer a query. This guide covers what that implies.

What You Need

A recording path fed from transmitted output, not from the playout source
Storage sized for the full retention period at your chosen quality
Accurate, continuous timecode and date stamping
A retrieval mechanism that finds material by time quickly
Monitoring that alerts when recording stops
A documented retention policy matching your regulatory obligations

Steps

Record what was transmitted, not what was played out

The recording must reflect what audiences actually received, so it should be taken as close to the transmission point as practical: after switching, continuity, and any downstream processing. Recording the playout source instead means a fault introduced downstream is invisible in your own evidence, which defeats the purpose.

Record continuously, with no gaps

The obligation covers everything transmitted, so the recording cannot stop for maintenance, file rollover, or reconfiguration. Systems record in overlapping segments with redundant recorders precisely so that no moment is unrecorded. A gap is a compliance failure regardless of whether anything of interest happened during it.

Stamp everything with accurate time

The recording is only useful if you can locate a specific moment quickly, and its evidential value depends on the timing being trustworthy. Continuous timecode and date locked to a reliable reference is what makes "show us what aired at 21:47 on the fourteenth" answerable in minutes rather than hours.

Choose quality against purpose, not against instinct

Compliance recordings exist to evidence what was said and shown, not for reuse. A modest bitrate is generally sufficient and dramatically cheaper across a long retention period. Recording at broadcast quality for compliance purposes is a common and expensive over-engineering.

Match retention to your actual obligation

Retention periods are set by regulation and vary by jurisdiction and content type, and some material, anything subject to an active complaint or legal process, must be preserved beyond the standard period. Automate the standard expiry and provide a hold mechanism that prevents deletion of specific material.

Monitor the recorder as critical infrastructure

A compliance recorder that silently stopped last Tuesday is a serious problem discovered at the worst moment. Alert on recording stopping, on storage filling, and on any gap in the timeline. Verify periodically by retrieving a random moment and confirming it exists and is playable.

Pro Tips

Record from transmitted output. Recording the source hides exactly the faults you need evidence of.
Compliance recordings do not need broadcast quality. Modest bitrate across a long retention is the right trade.
Alert on the recorder stopping. Silent failure is the characteristic risk of a system nobody watches.
Provide a legal hold that overrides automatic expiry, and test that it actually prevents deletion.
Test retrieval periodically. A recording you cannot find quickly is nearly as bad as one you do not have.

Knowledge Base

What You'll Learn

Compliance recording is evidence infrastructure rather than an archive. Below: what it has to prove, and why retrieval speed shapes the design as much as retention.

What the Recording Has to Prove

A compliance recording is evidence, and understanding what it must establish explains its unusual requirements.

It must show what was actually transmitted, not what was scheduled, not what was in the playout server, but what left the building. Complaints and regulatory queries concern what audiences received, and a fault introduced after playout is precisely the kind of thing that gets queried.

It must be complete, because a gap cannot be distinguished from a deliberate omission. A recording with holes undermines confidence in the whole system, which is why continuous redundant recording is standard rather than cautious.

It must be reliably timed, since queries arrive as "what did you broadcast at this time on this date" and the answer has to be locatable and defensible.

What it does not need to be is high quality. It is not a production master and will never be reused for broadcast. Confusing compliance recording with archiving leads organisations to store far more data than the obligation requires, at considerable cost across years of retention.

Why Retrieval Speed Shapes the Design

Retention gets the attention and retrieval is what determines whether the system is actually useful.

Queries are time-based and frequently urgent. A complaint about something broadcast last night, a regulator asking about a specific transmission, or a dispute about whether a commercial aired all require producing a specific few minutes from potentially years of continuous recording, quickly.

This shapes several design decisions. Material is stored in short segments with time-based naming so a moment can be located arithmetically rather than by searching. Recent material, where the overwhelming majority of queries land, stays on faster storage, with older material tiered down. And an index mapping time to storage location is maintained separately, because scanning storage to find a moment does not scale.

The tiering decision deserves care: cold storage is attractive for years of recordings and retrieval from it can be slow and separately charged. Where a query might arrive with a deadline, the retrieval characteristics matter more than the storage price, which is the opposite of the usual archive calculation.

Where This Fits

This guide covers one specific part of broadcast ingest. The wider picture, baseband, file-based, and IP ingest, metadata capture, QC gates, and never losing the source, is in Broadcast Media Ingest: How Enterprise Pipelines Actually Work, which frames the discipline as a whole and links out to the detailed guides underneath it, including this one. If you are starting from scratch rather than solving a specific problem, read that first and come back here.

FAQ

Q: Why must broadcasters record their own output?
A: So that complaints, disputes, and regulatory queries can be assessed against what actually transmitted rather than against what was scheduled. It also protects the broadcaster, providing evidence of what was and was not broadcast when something is alleged.

Q: Does a compliance recording need to be broadcast quality?
A: No. It exists to evidence what was said and shown, not for reuse, so a modest bitrate is generally sufficient and much cheaper across a long retention period. Recording at full broadcast quality for compliance purposes is a common and expensive over-engineering.

Q: Where in the chain should the recording be taken from?
A: As close to the transmission point as practical (after switching, continuity, and downstream processing) so it reflects what audiences received. Recording the playout source instead means faults introduced downstream do not appear in your evidence, which defeats the purpose of having it.

Q: How long do compliance recordings have to be kept?
A: It depends on jurisdiction and content type, and is set by regulation rather than by preference. Automate the standard expiry, and provide a hold mechanism that prevents deletion of anything subject to an active complaint or legal process, then test that the hold actually works.