The Surveillance Compliance Checklist

This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

If you specify, buy, build, or operate a video management system — the software that records and manages many camera streams, called a VMS — compliance is the part that decides whether the system is legal to switch on, not just whether it works. Get it wrong and the costs are real: regulators can order a system shut down, individuals in some places can sue the operator directly, and a face-recognition feature shipped without review can turn a security upgrade into a class action. This article is for security integrators, product managers, and smart-building, retail, and city security leads who have to deploy cameras and answer for them. It collects the whole of privacy by design for surveillance into a single ordered list, so nothing load-bearing is left to the end. Treat it as the capstone that ties the rest of the privacy block together.

A checklist, not a legal opinion

Most "CCTV compliance" pages online are one of two things: a vague reminder to "put up a sign and follow GDPR", or a wall of statute text with no order of operations. Neither helps a team that has to actually deploy. The useful artifact is an ordered checklist — the steps in the sequence you must take them, because several of them gate the ones after.

The order matters because compliance has dependencies. You cannot write the sign until you know the purpose. You cannot judge whether a data protection impact assessment is mandatory until you know whether the system does biometrics. You cannot set a retention period until you know the lawful basis it serves. Run the steps out of order and you will redo them.

The frame for the whole checklist is one idea from GDPR for video surveillance: video of an identifiable person is personal data, and running biometrics on that video — face recognition above all — is a second, much more sensitive kind of processing on top. Almost every item below gets heavier the moment biometrics enter the picture. So the single most useful question to answer first is: does this system identify people by their bodies, or just record what cameras see?

Below is the compliance gate — nine checkpoints between "we want cameras" and "the system is live". The rest of the article walks each one, in order, with the named law beside it.

Figure 1. The compliance gate: nine checkpoints between "we want cameras" and "the system is live". Each one feeds the next, and the biometric gate (step 5) makes several of the others much heavier.

1. Purpose and lawful basis

Everything starts with a single sentence per camera or zone: why does this camera exist? "Detect and investigate theft at the loading dock." "Monitor the lobby for after-hours intrusion." The purpose is not paperwork; it is the thing that decides whether every later step is necessary or excessive. A camera with no stated purpose cannot be justified, and a purpose like "general security" is too vague to defend.

With the purpose fixed, you choose a lawful basis — the legal reason you are allowed to process people's images at all. Under the General Data Protection Regulation (GDPR), Regulation (EU) 2016/679, Article 6 lists six possible bases, and for surveillance two matter. Most private operators rely on legitimate interests (Article 6(1)(f)): you have a genuine interest, such as preventing crime, and the processing is necessary for it and not overridden by the privacy rights of the people filmed. Public authorities acting in their official role generally cannot use legitimate interests for that role and rely instead on public task (Article 6(1)(e)) or a specific law.

If you rely on legitimate interests, the law expects you to document a Legitimate Interests Assessment (LIA) — a short, written three-part test. First, what is the interest (security of staff and stock). Second, is the camera necessary for it, or would a less intrusive measure do (better lighting, a locked door). Third, do your interests outweigh the intrusion on the people filmed, given where the camera points and who it captures. A camera over a till may pass; a camera into a neighbour's garden almost never does. The balancing test is where most over-reaching deployments fail, and writing it down is what makes the basis defensible.

The deeper treatment of each basis lives in GDPR for video surveillance; here the checklist point is simple. Name the purpose per camera, pick the basis, and if it is legitimate interests, write the LIA before you mount anything. The basis you pick also constrains later steps: it shapes the notice you must give and the retention you can justify.

2. The data protection impact assessment

The next checkpoint is the one teams most often skip, and it is frequently not optional. A data protection impact assessment (DPIA) is a structured study of a processing activity's privacy risks, done before the processing starts. GDPR Article 35 makes a DPIA mandatory where processing is "likely to result in a high risk" to people, and it names the surveillance case explicitly: a DPIA is required for "systematic monitoring of a publicly accessible area on a large scale". Large-scale public-space cameras are a textbook trigger, and so is large-scale processing of special-category data such as faces (Article 9). Regulators add more triggers: body-worn cameras with audio, automatic facial recognition, automatic number-plate recognition (ANPR), drones, and very high-resolution or multi-sensor cameras are all called out by the UK Information Commissioner's Office (ICO) as examples that need one.

A DPIA is not a form to rubber-stamp. Article 35(7) sets out what it must contain, and the four parts map cleanly onto an engineering review: a systematic description of what the system processes and why; an assessment of the necessity and proportionality of that processing against the purpose; an assessment of the risks to the people captured; and the measures you will take to reduce those risks — masking, retention limits, access controls, encryption. The output is a document, owned and dated, that you can hand a regulator.

There is a hard stop built into the process. If the DPIA finds a high risk you cannot reduce to an acceptable level, Article 36 requires you to consult your data-protection authority before deploying — prior consultation, not after-the-fact notification. In practice you almost never reach that point, because the act of doing the DPIA surfaces the fixes (shorten retention, mask the windows, drop the audio) that bring the risk down. The DPIA is less a hurdle than the worksheet where the rest of this checklist gets decided.

Figure 2. When is a DPIA mandatory? Large-scale public monitoring, biometrics, ANPR, audio, or other high-risk features trigger it. A residual high risk you cannot mitigate triggers prior consultation with the regulator under Article 36.

3. Data minimisation and privacy by design

With the risk study in hand, the next checkpoint is to cut the system down to what it actually needs — the principle GDPR calls data minimisation (Article 5(1)(c)) and data protection by design and by default (Article 25). The instinct on a security project is to capture everything at maximum resolution, all the time, with audio, just in case. The law treats that instinct as the problem, not the safe default.

Minimisation on a surveillance system is a series of concrete choices. Point cameras at the area you justified and no further; where the field of view spills into space you have no business watching — a neighbour's property, a private office, a bathroom corridor — blank it with a privacy zone that the camera never records. Record only what the purpose needs: motion or event recording instead of continuous where it fits, the recording-strategy lever covered in the storage block. Turn audio off unless you have a specific, separately justified reason for it, because recording sound is more intrusive and often needs its own basis. And resist biometrics: do not run face recognition because the camera could, only because the purpose actually requires identifying people rather than simply seeing them.

The techniques that let you keep the useful analytic while dropping the privacy risk — on-the-fly masking, redaction for exports, analytics on de-identified data — are covered in face masking, redaction, and privacy-preserving analytics. The checklist point is to design these in now, at specification time, when they are a setting, rather than bolt them on after a complaint, when they are a rebuild.

4. Notice and transparency

People have a right to know they are being filmed, who is filming them, and why — before they walk into shot. GDPR Articles 12 and 13 require this information to be given concisely and accessibly, and the European Data Protection Board (EDPB) — the body that issues official GDPR interpretation — spells out for cameras, in its Guidelines 3/2019 on video devices, exactly how to do it: a layered notice.

The first layer is the warning sign. It sits at the boundary of the monitored area, at roughly eye level, positioned so a person sees it before entering. It carries the essentials: that recording is taking place, the identity of the operator (the controller), the purposes, the most important impacts of the processing, and where to find the rest. The EDPB's point is that the sign should let someone "easily recognise the circumstances of the surveillance before entering the monitored area" — a sign visible only once you are already on camera is too late.

The second layer is the full detail required by Article 13 — the lawful basis, the retention period, who the footage may be shared with, the rights people have (access, erasure, objection), and how to complain. It does not go on the sign; it sits somewhere a person can reach without entering the monitored area: a notice at reception, a sheet at a desk, or a web page reached by a short URL or code on the sign. The mechanics of getting consent where consent is the basis, and the line between where notice is enough and where consent is required, are covered in consent and notice for surveillance and biometrics. For the checklist: design both layers, place the signs before the cameras' coverage begins, and make sure the operator named on the sign is the legal entity that actually controls the footage.

Figure 3. The layered notice the EDPB expects. A first-layer sign at the boundary carries the essentials before a person enters; a second layer holds the full Article 13 detail, reachable without walking into the monitored area.

5. The biometric gate: the heaviest checkpoint

This is the step that changes the weight of the whole project, and it deserves its own gate. There is a bright line in privacy law between recording people and recognising them. An ordinary camera that captures a face is processing personal data. A system that converts that face into a mathematical template and matches it against a database is processing biometric data for the purpose of uniquely identifying someone — and that is treated as a special, higher-risk category almost everywhere.

Under GDPR Article 9, biometric data used to identify a person is "special category" data whose processing is prohibited unless a specific condition applies — most often the person's explicit consent, or a substantial public interest set out in law. Legitimate interests is not enough for it. So a face-recognition deployment needs two legal layers: an Article 6 basis and an Article 9 condition. That is a materially higher bar than the plain cameras in the rest of the building.

In the United States the gate is enforced by people, not just regulators. Illinois's Biometric Information Privacy Act (BIPA), 740 ILCS 14, requires informed, written consent before you capture a face template (Section 15(b)), a published retention-and-destruction schedule (Section 15(a)), and — uniquely — it lets the individuals themselves sue, with statutory damages of $1,000 for negligent and $5,000 for reckless or intentional violations. A 2024 amendment (SB 2979) limited that to a single recovery per person rather than per scan, but the exposure is still measured in the millions for any sizeable deployment, and it is why face recognition is the highest-liability feature in this entire section. The full mechanics — Texas, Washington, the wave of state "sensitive data" laws, and the damages doctrine — are in BIPA and US biometric privacy law, and the technical pipeline in face recognition in surveillance.

A third layer now sits on top in Europe: the EU AI Act. Since 2 February 2025 its Article 5 has banned certain biometric uses outright — real-time remote biometric identification in public spaces for law enforcement (with narrow, authorised exceptions), untargeted scraping of faces to build recognition databases, and emotion recognition in workplaces and schools. Obligations for the high-risk biometric systems that remain legal — conformity assessment, logging, human oversight — apply from 2 December 2027 under the Act's agreed timeline. The checklist point is blunt: if the system identifies people by their faces (or other biometrics), stop and run a separate biometric review before anything else, because consent, retention, and the legal basis all change, and in some places the use may be prohibited regardless of consent.

Figure 4. The biometric escalation. Plain video needs a lawful basis, notice, and a retention limit. The moment a system recognises people by their bodies, it adds an Article 9 condition, BIPA-style written consent, and an EU AI Act check — a much heavier gate.

6. Retention and lawful deletion

The next checkpoint sets how long footage lives and proves it is gone when its time is up. There are two limits, not one: a floor set by evidence and sector rules that says how long you must keep footage, and a ceiling set by privacy law's storage-limitation principle (GDPR Article 5(1)(e)) that says how long you may. The EDPB reads that ceiling as a few days for ordinary cameras in most cases, with anything longer needing a documented reason. You pick a number inside the band, write it down per camera group, and let the recorder enforce it automatically.

Two engineering facts make this a real checklist item rather than a policy line. First, "delete" is not the same as "gone": a routine delete removes the file pointer but leaves the footage recoverable until it is overwritten, and copies in backups, replicas, and exported clips usually survive it. Lawful deletion has to reach every copy. Second, the GDPR right to erasure (Article 17) lets a person ask you to delete their footage, and you must respond within one month — which is only feasible if you know where every copy of their data lives. The full floor-and-ceiling model, the deletion mechanics, and the right-to-erasure workflow are in retention limits and lawful deletion. For the checklist: set the window, automate expiry across every storage tier, keep a separate legal-hold lane for the rare clip that must survive, and be able to erase one person's derived data on request.

7. Access control, security, and audit

Footage is only as private as the controls around it, and GDPR Article 32 requires "appropriate technical and organisational measures" to keep personal data secure. For a surveillance system that translates into a short, concrete list, and a regulator will ask for each item after any incident.

Start with who can see what. Access should be least-privilege: a guard sees live views of their site, an investigator sees recorded footage for a case, an administrator manages the system, and nobody has more than their role needs. Each person authenticates as themselves — shared "control-room" logins are the single most common finding, because they make the next item impossible. That next item is the audit log: a tamper-resistant record of who viewed, exported, or deleted footage, and when. Without it you cannot answer "who watched this?" — and after a misuse complaint, that is the first question.

Then comes protecting the data in transit and at rest: encrypt the camera-to-recorder and recorder-to-client links so footage cannot be intercepted on the network, and encrypt stored recordings so a stolen drive is not a breach. Track exports — every clip an operator copies to a USB stick or emails is a copy that escapes the system's retention and access rules, so it needs logging and a reason. Finally, anyone you let process footage on your behalf — a cloud VSaaS provider, an analytics vendor, a maintenance contractor — is a processor, and GDPR Article 28 requires a written contract binding them to use the data only on your instructions and to protect it. The checklist point: least-privilege roles, individual logins, an audit trail, encryption both ways, export tracking, and a signed agreement with every processor.

8. Data-subject rights in operation

A compliant system is not only built correctly; it can answer the people in it. GDPR gives individuals rights that a surveillance operator has to be able to honour on request, within one month (Article 12(3)), and the checklist item is having a working process for each — not discovering the gap when the first request arrives.

The two that bite hardest for cameras are access and erasure. A subject access request lets a person ask for a copy of the footage of themselves; to comply you must find the relevant clips and, crucially, redact other people in the frame before releasing them, because a third party's privacy does not disappear because someone else asked. That redaction capability is the same masking technology you designed in at step 3, now used in reverse. The right to erasure (Article 17) lets a person ask you to delete their footage, subject to the legal-hold exceptions covered above. People also have rights to object to the processing and, where the basis is consent, to withdraw it. The checklist point is operational: name who handles requests, set the one-month clock the moment one arrives, and make sure your VMS can actually search, redact, export, and delete by subject — because a system that cannot do those things cannot be operated lawfully no matter how well it was specified.

9. Governance, records, and the cross-region reality

The last checkpoint is the paperwork that proves the rest happened, plus the items that appear once a system grows beyond one site. GDPR's accountability principle (Article 5(2)) means you must be able to demonstrate compliance, not merely assert it. In practice that is a small set of living documents: a Record of Processing Activities (Article 30) listing what the cameras do and why; the DPIA and LIA from earlier steps; the processor contracts; and a breach-response plan, because Article 33 gives you just 72 hours to report a qualifying personal-data breach to the regulator.

Two more items appear at scale. If footage leaves its region — most often because it is recorded to or analysed in the cloud — GDPR Chapter V governs that cross-border transfer, and "the cloud region is in-country" does not by itself settle it, because support access from elsewhere can still be a transfer. And because the rules really do differ by jurisdiction, a system sold or operated across regions has to follow the strictest applicable rule, not the most convenient one; the map of where those rules diverge is in regional regulation: a map of where the rules differ. For the checklist: keep the records current, hold a 72-hour breach drill before you need it, document any cross-border flow, and design to the strictest region you operate in.

A worked example: a retail chain rolls out cameras

Walk the gate with a concrete case. A retailer is putting a 40-camera system into a new store: entrances, tills, stockroom, and the car park. The team runs the checklist in order.

Purpose and basis. Each zone gets a sentence — "deter and investigate theft at the tills", "monitor the stockroom door", "cover the car park for vehicle incidents". The basis is legitimate interests, and the team writes a one-page LIA showing the cameras are necessary and pointed only at the retailer's own space. The car-park cameras are angled down so they do not film the public pavement.

DPIA. This is a sizeable system in a publicly accessible space, so the team does a DPIA rather than guessing whether it is mandatory. The study flags one real risk: someone proposed face recognition on the entrance cameras to spot known shoplifters. That single proposal would convert the project into special-category processing — so it goes to the biometric gate, and for the first launch the team drops it.

Minimise, notice, retain. Tills record on motion plus a continuous low-frame baseline; the stockroom records on motion only; audio is off everywhere. Layered signs go up at both doors and the car-park entrance before the cameras' coverage starts, naming the retailer and linking to a full notice on the store's website. Retention is set to 30 days, comfortably inside the privacy ceiling and above the realistic window in which a theft or a slip-and-fall surfaces, and the recorder overwrites automatically.

Access, rights, records. Three roles are created — store guard (live only), loss-prevention investigator (recorded, with export logged), and administrator. Every login is individual; the audit log is on. The duty manager is named as the contact for access and erasure requests, with a one-month clock. The Record of Processing Activities, the LIA, and the DPIA go in a folder the area manager owns. The system goes live — without face recognition, which would have needed its own consent regime, its own retention schedule, and a BIPA review the chain was not ready to run. That deferral is the checklist working exactly as intended: the heaviest feature is the one you gate hardest.

The checklist, on one page

The nine checkpoints collapse into a single readiness list you can run before any deployment, grouped the way the work actually happens. The downloadable version below is the printable form of it — the primary compliance lead magnet for this section.

Figure 5. The compliance checklist as a single card — the nine checkpoints as checkbox items, grouped from purpose through governance, with the biometric gate marked as the step that changes everything after it.

Run it in order, because the steps depend on each other: purpose sets the basis, the basis and the biometric answer set whether a DPIA is mandatory, the DPIA sizes the retention and the controls, and the controls make the rights process possible. A system that can tick every box — and show the documents behind the ticks — is one you can switch on and defend. Download the surveillance privacy & compliance checklist to run it against your own deployment.

Common mistakes that fail the gate

The recurring failures are predictable, and each maps to a checkpoint someone skipped. The first is deciding the lawful basis last — deploying the cameras and reverse-engineering a justification, instead of letting the purpose drive the design. The second is skipping the DPIA on a large public-space or biometric system where Article 35 makes it mandatory, which leaves the highest-risk deployment as the one with no risk study. The third is the sign that comes too late — a notice visible only once you are already on camera, which fails the "before entering" rule. The fourth, and most expensive, is switching on face recognition as if it were a normal feature, when it needs explicit consent, a special-category condition, a BIPA review in the US, and an EU AI Act check — and may be prohibited regardless. The fifth is shared logins and no audit trail, so when misuse is alleged the system cannot say who looked. A deployment that names a purpose, runs the DPIA, places notice early, gates biometrics hard, and logs every access avoids all five.

Where Fora Soft fits in

Fora Soft has built video systems — surveillance, streaming, conferencing, and computer vision — since 2005, across 625+ projects, and on a surveillance build compliance is an architecture input, not a late review. In practice we design the checklist into the product: roles and least-privilege access with individual logins and a tamper-resistant audit log, encryption in transit and at rest, retention windows that expire automatically across every storage tier, masking and privacy zones available at specification time, and subject-access and erasure tooling that can search, redact, and delete by person within the legal deadline. When a client wants face recognition or number-plate reading, we treat the biometric gate as a hard branch in the design, not a toggle, because the legal weight is different and the system has to reflect that. The framing we hold to is accuracy-vs-performance: a privacy control you cannot demonstrate is not a control, and a compliance claim you cannot evidence is a liability. We build so the honest answer to "can you show this system is lawful?" is yes, with the documents to back it.

What to read next

• Privacy by design for surveillance: the overview — the framing this checklist operationalises.
• BIPA and US biometric privacy law — the detail behind the biometric gate's highest-liability item.
• Retention limits and lawful deletion — the floor-and-ceiling model behind checkpoint six.

Call to action

• Talk to a surveillance engineer — book a 30-minute scoping call to talk through your surveillance compliance checklist plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Surveillance Privacy & Compliance Checklist — Pre-Deployment — The primary compliance lead magnet for the section: a one-page printable that turns the article into an ordered, grouped pre-deployment readiness checklist with checkbox items for all nine checkpoints — purpose & lawful basis (GDPR Art.

References

1. GDPR — Regulation (EU) 2016/679, Article 6 (lawfulness of processing) and Article 5 (principles, incl. 5(1)(c) minimisation, 5(1)(e) storage limitation, 5(2) accountability). European Union (consolidated text). https://gdpr-info.eu/art-6-gdpr/ — The lawful bases for surveillance (legitimate interests, public task) and the principles the checklist enforces. Tier 1, read directly.
2. GDPR — Article 9, processing of special categories of personal data. European Union. https://gdpr-info.eu/art-9-gdpr/ — Biometric data used to identify a person is special category; prohibited unless a condition (e.g. explicit consent) applies. The legal basis for the biometric gate. Tier 1, read directly.
3. GDPR — Article 35 (data protection impact assessment) and Article 36 (prior consultation). European Union. https://gdpr-info.eu/art-35-gdpr/ — DPIA mandatory for large-scale systematic monitoring of public areas and large-scale special-category processing; the four required contents; prior consultation on residual high risk. Tier 1, read directly.
4. GDPR — Articles 12 and 13 (transparency and information to be provided), Article 17 (erasure), Article 30 (records), Article 32 (security), Article 33 (breach notification). European Union. https://gdpr-info.eu/art-13-gdpr/ — The notice, rights, records, security, and breach obligations across the checklist. Tier 1, read directly.
5. EDPB Guidelines 3/2019 on processing of personal data through video devices (v2.0, 2020). European Data Protection Board. https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-32019-processing-personal-data-through-video_en — The official camera-specific interpretation: layered notice (§7), storage periods (§8), lawful basis and special-category guidance. Tier 1, read directly.
6. Illinois Biometric Information Privacy Act (BIPA), 740 ILCS 14, §§15(a), 15(b). Illinois General Assembly. https://www.ilga.gov/legislation/ilcs/ilcs3.asp?ActID=3004&ChapterID=57 — Written consent before biometric capture, public retention/destruction schedule, private right of action with statutory damages (as amended by SB 2979, 2024). Tier 1.
7. Regulation (EU) 2024/1689 (the EU AI Act), Article 5 (prohibited practices). European Union / European Commission. https://artificialintelligenceact.eu/article/5/ — Prohibitions in force 2 Feb 2025 on real-time remote biometric identification in public for law enforcement (with exceptions), untargeted facial scraping, and workplace/school emotion recognition; high-risk biometric obligations from 2 Dec 2027. Verified by web search 2026-06-10. Tier 1.
8. CCTV and video surveillance — guidance on the data-protection principles, DPIAs, and signage. UK Information Commissioner's Office (ICO). https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/cctv-and-video-surveillance/ — Regulator guidance on when a surveillance DPIA is required (facial recognition, ANPR, audio, body-worn, drones) and how to comply with the principles. Verified by web search 2026-06-10. Tier 1 (regulator guidance), read directly.
9. IEC 62676-1-1, Video surveillance systems for use in security applications — System requirements. International Electrotechnical Commission. https://webstore.iec.ch/publication/28166 — The international standard for surveillance system and operational requirements; the engineering-standard backdrop to the compliance controls. Tier 1 (standard).