CCTV footage, incident records and data protection

A security operation produces personal data continuously: CCTV footage, access logs, incident reports naming individuals, pocket notebooks, body-worn video where it is used. Data protection law applies to all of it, and the practical question for a contractor is usually who is responsible for what — because the system is frequently the client's and the people operating it are yours.

Whose data is it

Where a contractor operates a client's CCTV system, responsibilities are typically split in ways that ought to be written down and frequently are not. Who decides retention, who handles a subject access request, who authorises a disclosure to police, who is accountable if footage is shared inappropriately.

Those are questions for the contract and for advice against current ICO guidance, which is revised. What is worth flagging operationally is that "it is the client's system" is not an answer to any of them — the officer pressing the button is the contractor's, and the incident record is yours, and the request will often arrive at the contractor first.

Requests arrive at the wrong person, at the wrong time

Subject access and police requests for footage rarely come through a formal channel. Somebody turns up at a gatehouse, or rings the control room at nine at night, and an officer has to decide what to do — with no guidance, under pressure, from a person who may be entirely legitimate.

The workable control is a standing instruction that no footage is released by an officer, ever, with a named person to route requests to and a form of words to use. That removes the judgement from the moment it cannot safely be made.

Retention is where most contractors are quietly wrong

Footage and incident records are commonly kept far longer than any stated policy, because deletion requires a decision and storage is cheap. That is an exposure in both directions: holding personal data with no justification, and — where a policy says thirty days and the system holds ninety — being unable to explain the discrepancy.

Incident reports are the sharper version, because they name people and describe behaviour, and contractors hold them indefinitely by default. Worth setting a retention period deliberately, long enough for a claim and no longer.

In practice: the request at the gate

A man arrives at a site reception asking for footage of himself from the previous week, politely and with identification. The officer on duty, wanting to be helpful and having no instruction to the contrary, walks him to the control room to look at it.

Nothing was released and nothing was recorded. The client learned about it a fortnight later from a complaint, and what concerned them was not the incident but that the contractor had no procedure making the outcome predictable.

Common mistakes

• –No written split of data responsibilities between contractor and client
• –No standing instruction on what an officer does with a footage request
• –Retention that quietly exceeds the stated policy
• –Incident reports kept indefinitely by default
• –Footage viewed informally with no record that it happened
• –Officers deciding disclosure questions under pressure with no route to escalate

One practical test: ask an officer what they would do

Ask an officer what they would do if somebody arrived at the gate asking to see footage of themselves, politely and with identification.

Any answer other than routing it to a named person means the judgement is being made at the gate, under social pressure, by somebody with no guidance. A standing instruction and a form of words removes the decision from the moment it cannot safely be made.

• –Give officers a standing instruction never to release footage
• –Name who requests are routed to
• –Write down the split of data responsibilities with the client
• –Set retention deliberately and check the system matches the policy
• –Record when footage is viewed, not only when it is released

Worth adding: check the system against the policy

Retention policies are written and systems are configured separately, frequently by different people at different times. A policy saying thirty days on a system holding ninety is a discrepancy nobody can explain, and it is found by looking rather than by asking.

Worth checking once per site, because the answer is set at installation and nobody revisits it.