CCTV footage as evidence: from system export to certification
After an incident in a shop, a warehouse or a shared courtyard, the first question is always the same: did the cameras record it? Almost always the answer is yes, and the matter seems settled. It reopens weeks later, when that footage has to reach a loss adjuster, an investigator or the opposing party in a dispute, and the recording turns up with no verifiable date, in a format that is no longer the one the system produced.
Between the existence of a recording and its usefulness in a proceeding sits a step that almost nobody controls: the export from the system. That is the moment the footage loses its verifiable date, its continuity with the original and its starting quality, and that is why a challenge from the other side works even when what the camera captured is entirely genuine.
Why CCTV footage arrives in a dispute already weakened
CCTV footage loses evidentiary weight not when someone tampers with it, but when the path between the recorder that captured it and the file handed over is undocumented. Under the authentication standard applied in most jurisdictions, the party producing a recording has to support a finding that the item is what that party claims it is, and the strength of that support is what the court weighs. In day to day operation this turns into three recurring breaking points, all of them located at the moment of export. The recorder's proprietary format gets converted to something readable, and the delivered copy no longer matches the original bit for bit. The system clock, rarely synchronised, produces an on-screen time that does not line up with the other records. Finally the retention period expires, the system overwrites and the original is gone.
Proprietary formats, re-encoding and compression
Video recorders export in a proprietary container, readable only with the player supplied by the manufacturer. To hand over something the other side can actually open, the operator converts the file into a common codec, and from that point the copy no longer corresponds bit for bit to the recording held on the DVR or NVR. If the clip is then forwarded through a messaging app it takes a second round of compression that lowers the resolution and strips whatever metadata survived. What arrives is a working copy, not a forensic copy: useful to understand what happened, weak as soon as someone disputes that it matches the original. Anyone handing over a clip that has passed from device to device almost always overestimates how well it will hold.
An unsynchronised system clock
The time burned into surveillance images is worth exactly as much as the internal clock of the system that generated it, and that clock usually comes from a manual setting made at installation and never checked again. A few minutes of drift are enough for the sequence of events to fall apart against the other records, from a till receipt to the time written in a report. Whoever challenges footage almost always starts here, because it is the point where perfectly authentic recordings can still end up unusable. The problem of altered date and time in a video looks identical on fixed installations, with one aggravating factor: on a surveillance system nobody has any reason to check the clock before the day it matters.
Retention limits and overwriting of the original
How long camera recordings last depends on how the system storage was sized: when the space runs out, the system writes over the oldest images without warning anyone. Overwriting is not a fault, it is the designed behaviour, and it is also what keeps the installation inside the storage limitation principle that data protection law imposes on personal data.
Under the GDPR storage limitation principle, personal data must be kept in a form that permits identification for no longer than is necessary for the purposes of the processing, and video images of identifiable people are personal data. The European Data Protection Board takes the same line in its guidelines on processing personal data through video devices, where retention beyond a few days has to be justified by the controller rather than assumed. In practice the window to act on an incident is measured in hours, not weeks, and once overwriting has run its course the exported copy is all that is left.
Retention varies with the setting in which the system operates.
| Setting | Typical retention | What has to be documented |
|---|---|---|
| Workplace, protection of company assets | 24 to 48 hours, extendable with a documented reason | purpose of the installation, worker information, proportionality assessment |
| Retail premises open to the public | 24 to 48 hours as a rule, up to about a week if justified | signage before the field of view, register of processing activities |
| Residential building, shared areas | a few days, on the shortest term that meets the purpose | who the controller is and who is authorised to view the images |
| Public space monitoring | set by the national rules that authorise the installation | legal basis, retention schedule, access log |
What evidentiary weight does CCTV footage carry
A surveillance recording is treated as documentary evidence, and a court can base a finding on it as long as its correspondence to what the camera actually captured is not credibly disputed. The producing party does not have to prove the recording is perfect, but has to offer enough to support a finding that it is what it is claimed to be, which is exactly the ground covered by the admissibility requirements for digital evidence.
Authentication and the burden on the party producing the recording
Authentication of video is usually satisfied in one of two ways: a witness who was present testifies that the recording fairly represents what they saw, or the party shows that the recording system worked properly and that the file was handled without alteration from capture to production. The second route is the only one available for surveillance footage of an event nobody watched at the time, and it depends entirely on documentation. Without it, the footage does not disappear from the case, it simply carries less weight, and the discussion shifts from what the images show to how the file got to the hearing. The same reasoning applies to audio and video recordings in civil litigation.
Lawfulness of the installation as a precondition
Recordings made in places open to the public are usable in principle, but a system installed outside the rules weakens even the genuine images it produces. Where cameras cover a workplace, most European jurisdictions require prior information to workers, a documented purpose limited to safety, organisation or asset protection, and in several countries a form of consultation with worker representatives. Signage before the field of view and a defined list of people authorised to view the images belong to the same set of conditions. None of this is about the footage itself, yet all of it is raised as soon as the recording becomes inconvenient for the other side.
What it means to certify the export of a recording
Certifying an export means fixing, at the moment the file leaves the system, four elements that an ordinary export does not preserve: the identifier of the camera that captured the scene, the system time read on the recorder, the real moment the operation was performed, attested by a timestamp, and the cryptographic hash of the exported content. The first two say where the footage comes from, the third says when it was taken out, the fourth lets anyone, months later, verify that the file they received is identical to the one that came off the recorder. The ISO/IEC 27037 standard applies the same logic to the identification and collection of digital evidence, yet on surveillance systems that step is almost always skipped. Without those four data points the digital chain of custody of a recording starts at an indeterminate moment and continues on the memory of whoever used the recorder.
Camera identifier, system clock and a timestamp on the export
The camera identifier and the system time live only inside the installation, and the export does not carry them along: whoever receives the file sees a video and a file name, with no way of knowing which lens it came from or what time the recorder was showing. A qualified electronic timestamp solves the opposite problem, establishing when the export actually happened, independently of the clock of the computer used for the operation, which anyone can move. Under the eIDAS Regulation a qualified electronic timestamp carries a presumption of accuracy of the date and time it indicates and of the integrity of the data it is linked to. The two pieces of information work together: one places the scene in the time of the installation, the other places the export in real time, and the gap between them becomes a declared fact rather than an omission to explain at a hearing.
| Element | With an ordinary export | With a certified export |
|---|---|---|
| Content of the clip | re-encoded into a common codec, no longer matching the original bit for bit | cryptographic hash of the exported file, comparable at any time |
| Camera identifier | survives only in the memory of the person who ran the export | recorded as context data alongside the file |
| System time of the installation | burned into the images, not verifiable from outside | declared and bound to the file at the moment of the export |
| Real moment of the export | the date of the computer used, which can be changed | timestamp issued through a qualified trust service provider |
| Continuity up to delivery | left to what the operator remembers | documented by the digital seal applied at the export |
Organisations running surveillance systems use TrueScreen to fix the camera identifier, the system time and the real moment of the export in a single verifiable document.
Certification at source of surveillance footage
TrueScreen certifies the clip at the very moment it is exported from the system, sealing the context data that an export normally loses together with the video. What sets it apart from common practice is where the seal lands: not on a copy that has already travelled through email and messaging, but on the file just off the recorder, while its correspondence to the original recording can still be demonstrated. The clip is bound to the cryptographic hash of its content, the camera identifier, the system time read on the installation and a qualified timestamp issued through a qualified trust service provider integrated into the platform, along with that provider's digital seal. The result is a document that travels with the file through every later step, and that lets an organisation certify an exported file with the same rigour applied when someone chooses to certify a video as it is being filmed.
The typical case comes from retail. A store records a shortfall at the checkout: the loss prevention manager finds the fifteen useful minutes on the recorder, exports them and certifies them in the same operation, together with the camera identifier and the system time read on the installation. Three weeks later, when the file reaches the law firm, the original recording has already been overwritten. What remains demonstrable is that the delivered file is identical to the one that came off the system that day at that time, so the discussion is about what the footage shows rather than how it got there.
Preparing delivery to an insurer, an authority or the opposing party
Handing surveillance footage to a third party holds up when access to the images follows a recognised route and when the file arrives with something that attests to its origin and integrity. A private individual does not normally get direct access to someone else's recordings: they submit a request to the controller of the installation, or, once proceedings are under way, counsel obtains the material through the procedural route available in that jurisdiction. In urgent cases, though, the decisive move comes before either path: asking in writing for the deletion to be put on hold within the first twenty-four hours, before overwriting makes every request academic. Where law enforcement is acting, the acquisition is documented in a record describing the installation, the storage medium used and how the material was taken.
The sequence below keeps the number of points at which the footage can be attacked to a minimum.
- Ask the controller of the installation in writing to suspend overwriting, stating the time window of interest and the reason for the request.
- Identify the useful interval and note the camera identifier, before touching the export function at all.
- Export in the recorder's native format. If a copy readable without the manufacturer's player is needed, produce it in addition to the original file, not instead of it.
- Certify the file in the same operation as the export, so that the hash and the timestamp refer to the content just taken off the system.
- Record the system time shown on the recorder and its offset from real time, so that whoever reads the footage knows how to translate the on-screen clock.
- Prepare the access request or the form the organisation requires, attaching the reason for the request and the reference details of the incident.
- Deliver the certified file together with the document attesting the export, and keep an identical copy for later comparison.
When footage has to go to an insurer or to the opposing party, TrueScreen produces the document attesting the integrity of the file and the moment of its export, sealed by a qualified trust service provider. That is the material a forensic IT expert works on, and the same material that supports insurance claims certification and the handling of digital evidence for law firms, instead of reconstructing after the fact a history that nobody documented while it was happening. The reference framework for identifying and collecting the file remains ISO/IEC 27037, whose principles align with the handling practices published by the National Institute of Standards and Technology. The presumption attached to a qualified timestamp comes instead from the eIDAS Regulation.
