Privacy by Design for Surveillance: The Overview

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

Why this matters

This is the opening article of the privacy-and-compliance block, and it exists to give you the frame everything else hangs on. It is written for the security integrator, product manager, smart-building or retail lead, or city and enterprise security owner who is about to specify, buy, or build a surveillance system and senses — correctly — that "are we allowed to do this?" is not a question to leave for launch week. Get the posture right and the specific rules in the later articles become a checklist you can actually pass; get it wrong and you discover, after the cameras are up, that the cheapest-looking design choice created the most expensive legal exposure. No legal background is assumed: every term is explained in plain language and tied to the named law, and the goal is a way of thinking about surveillance that an engineer, a buyer, and a regulator can all recognise as sound.

The one idea: a camera pointed at people is a privacy product

Start with the fact that reframes everything else. The instant a camera records a space where identifiable people appear, the footage is personal data — information relating to an identified or identifiable person — and the system that holds it is doing something the law watches closely. This is not a European quirk; it is the baseline definition in the EU's General Data Protection Regulation (GDPR, Regulation (EU) 2016/679, Article 4(1)), and most modern privacy regimes echo it. A face, a gait, a car someone arrives in, a uniform with a name badge — any of these can make a recording "about" a specific person, which is all it takes.

That single fact has a consequence most teams underrate: you do not get to decide whether a surveillance system is privacy-sensitive. It is, by default, from the first frame. The only thing you decide is whether you treat it that way on purpose — designing for privacy from the start — or by accident, discovering the obligations after the system is live and the cheap shortcuts are baked in. The rest of this article, and this block, is about choosing the first path.

A useful mental model is to think of the camera as the easy part and the data as the product. Hardware records pixels; the system creates, stores, copies, exposes, and eventually must delete personal data about real people. Every one of those verbs is a place privacy law has something to say. Treating the deployment as "we put up some cameras" misses the actual thing you are operating: a personal-data pipeline that happens to start with a lens.

Two systems in one: recording video versus running biometrics

Here is the distinction that matters more than any other in surveillance privacy, and the one this block is built around: the gap between recording and watching video and running biometrics on that video is not a small step up in sensitivity. It is a jump into a different legal regime.

Recording identifiable video is processing personal data. The law treats that as serious but manageable: you need a lawful basis — a legitimate, documented reason such as protecting property or safety (GDPR Article 6) — plus transparency, security, a sensible retention period, and the other duties the later articles cover. It is the normal cost of running cameras.

Now turn on face recognition. The system stops merely recording a person and starts measuring them: it converts a face into a mathematical template designed to single that individual out from everyone else. Under GDPR that template is biometric data processed for the purpose of uniquely identifying a person, which is a special category of personal data (Article 9, with the definition in Article 4(14)). Special-category data is prohibited by default — Article 9(1) says you may not process it at all unless one of a short list of exceptions applies (Article 9(2)), the most relevant of which, for most products, is the data subject's explicit consent. The bar moves from "have a good reason" to "clear a near-ban." The European Data Protection Board — the EU body that interprets GDPR for cameras — underlines in its Guidelines 3/2019 on video devices that biometric processing such as facial recognition carries heightened risk and demands a higher level of safeguards and, where relevant, a formal impact assessment.

The US tells the same story in a different accent. Several states regulate biometrics directly, and Illinois' Biometric Information Privacy Act (BIPA, 740 ILCS 14) is the sharp one: it requires informed written consent before capturing a face template, and — unusually — it gives individuals a private right of action with statutory damages of $1,000 per negligent violation and $5,000 per intentional or reckless one. Plain video recording rarely carries that kind of personal liability; biometric capture without consent routinely does.

Question	Recording & viewing video	Running biometrics (e.g., face recognition)
What kind of data is it?	Personal data (GDPR Art. 4(1))	Special-category biometric data (Art. 9, Art. 4(14))
Default legal status	Allowed with a lawful basis (Art. 6)	Prohibited unless a narrow exception applies (Art. 9(2), e.g. explicit consent)
Typical US exposure	General privacy/tort and sector rules	Biometric statutes — Illinois BIPA: written consent, private right of action, $1k/$5k per violation
Impact assessment	Often required (Art. 35(3)(c), public-area monitoring)	Almost always required (Art. 35(3)(b), special-category at scale)
What it takes to add	Point the camera; document the basis	A separate lawful gate, consent mechanics, and often a redesign

The practical lesson is blunt: the most consequential privacy decision in a surveillance project is usually not "how many cameras" but "do we run biometrics?" — and it should be a deliberate, gated decision, never a checkbox someone enables because the camera supports it. We go deep on the EU side in GDPR for video surveillance, on the US side in BIPA and US biometric privacy law, and on how face recognition actually works in face recognition in surveillance.

Figure 1. The same camera, two legal regimes. Recording identifiable video is ordinary personal data with a lawful basis; running face recognition creates special-category biometric data that is prohibited by default. The step between them is the most important decision in the system.

Common mistake: enabling face recognition because the camera offers it. Many modern cameras and Video Management System (VMS) platforms — the software that ingests and records many camera streams — ship a face-recognition toggle. Flipping it on is a one-click action with a multi-year legal tail: in Illinois it can mean per-person, per-scan statutory damages; in the EU it can mean processing special-category data with no valid Article 9 basis. If you do not have explicit consent or another lawful exception and a completed impact assessment, the safe default is off.

Privacy by design: proactive, not bolted on

If the first idea is "this is a privacy product," the second is "so design for privacy from the start." That discipline has a name — privacy by design — and it is both a decades-old engineering philosophy and, today, a legal obligation.

The philosophy came first. In the 1990s, Dr. Ann Cavoukian set out seven foundational principles of privacy by design, later endorsed in a 2010 resolution by the global assembly of data protection authorities. The principles read like good engineering instincts: be proactive, not reactive (prevent privacy problems rather than remedy them after the fact); make privacy the default setting (the user should not have to do anything to be protected); embed privacy into the design rather than bolting it on; aim for full functionality (privacy and the system's job are not a zero-sum trade); protect data across its full lifecycle end to end; keep the system visible and transparent; and keep it user-centric, respecting the people in front of the lens. None of these are about a specific technology — they are about when and how you make decisions.

That philosophy is now law. GDPR Article 25 — titled "data protection by design and by default" — turns the idea into a requirement. Article 25(1) says the controller must build in "appropriate technical and organisational measures... designed to implement data-protection principles, such as data minimisation, in an effective manner" — and crucially, both at the time you determine how the system will work and during operation. In other words, the law expects privacy decisions at design time, not only at audit time. Article 25(2) adds the by default half: out of the box, the system should process "only personal data which are necessary for each specific purpose," and it spells out that this applies to how much you collect, how widely you process it, how long you store it, and who can access it. A standards counterpart now exists too: ISO 31700-1, published in 2023, is the first international standard on privacy by design, setting out 30 high-level requirements for protecting privacy across a product's lifecycle — useful as a framework even where it is not legally mandated.

The reason this ordering matters is practical, not philosophical. Privacy choices made at design time are cheap and effective; the same choices retrofitted after deployment are expensive and often impossible. You cannot un-collect footage you over-collected, un-share data you exposed to too many people, or consent-after-the-fact to biometric capture you already did. Bolting privacy on at the end is the surveillance equivalent of adding brakes after the car is built.

Figure 2. Privacy by design means deciding early. The reactive path treats privacy as a post-launch fix — costly, and some choices cannot be undone. The proactive path embeds the seven principles (now GDPR Art. 25 and ISO 31700) into procurement and design.

Common mistake: treating privacy as a launch-week compliance task. A privacy review that starts after the cameras are mounted can only document risk, not prevent it. By then the field of view, the resolution, the analytics, the retention default, and the access model are already chosen — and changing them means rework. Privacy by design moves that review to the specification stage, where a different camera angle or a disabled feature costs a sentence in a document instead of a re-cabling job.

Data minimisation: collect and expose the least that does the job

If privacy by design is the when, data minimisation is the single most important what. The principle, set out in GDPR Article 5(1)(c), is that personal data must be "adequate, relevant and limited to what is necessary" for the purpose. Article 25(2) then makes "necessary, by default" the starting configuration. For surveillance, that translates into a short list of levers you can pull at design time, each of which shrinks the amount of personal data the system creates or exposes.

The first lever is purpose: a camera should exist for a stated, specific reason, and that reason bounds everything else. "General security" is not a purpose; "detect intrusion at the loading dock after hours" is, and it tells you where to point the camera, when to record, and how long to keep the footage.

The second is field of view and privacy zones — blanking the parts of a scene you have no need to watch. The EDPB gives the textbook example: a camera covering a shop entrance should not also capture the public pavement or a neighbour's window, and where it unavoidably does, those regions should be masked. Less scene captured means less personal data created.

The third is resolution and frame rate: capture only the detail the purpose needs. A camera that exists to count how many people enter does not need a face-legible image; a lower resolution that still does the job is the more privacy-protective default.

The fourth is the sharpest, and it ties straight back to the biometric gate: disable analytics you do not need. The EDPB states the rule directly — if audio recording and facial recognition are not required for the purpose, "these video functions should be disabled." A feature that is off creates no data and carries no risk.

The fifth is retention — keep footage only as long as the purpose needs, which is usually days, not months. This deserves an article of its own, and it gets two: the engineering policy in retention policy: how long to keep footage, and the legal limits in retention limits and lawful deletion.

The sixth is accessibility — who can see what — which Article 25(2) calls out explicitly: by default, personal data should not be "made accessible... to an indefinite number of natural persons." This one rewards a quick piece of arithmetic. Take a 200-camera site watched by a 50-person security and operations team. If every account can pull up every camera by default, the number of person-to-camera viewing paths is:

200 cameras × 50 viewers = 10,000 access paths

Now scope each role to the cameras it actually needs — a lobby guard sees the 8 cameras on their floor, not all 200:

8 cameras × 50 viewers = 400 access paths

That is a 25× reduction in how widely each person's image can be watched (10,000 ÷ 400 = 25), achieved by configuration alone — no camera removed, no feature lost. That is data minimisation by default in one decision.

Figure 3. Data minimisation is a stack of design-time levers. Each one — purpose, privacy zones, resolution, disabled analytics, short retention, scoped access — shrinks the personal data the system creates or exposes, per GDPR Art. 5(1)(c) and Art. 25(2).

The DPIA: decide before you deploy

Privacy by design needs a forcing function — a step that makes a team actually do the thinking before the system goes live. In the EU that step is the Data Protection Impact Assessment (DPIA): a structured, written assessment of how a planned processing activity affects people's privacy, and what you will do about it. GDPR Article 35(1) requires one, prior to the processing, whenever a type of processing is "likely to result in a high risk to the rights and freedoms of natural persons."

Surveillance walks straight into the triggers the law lists. Article 35(3) says a DPIA is required in particular for "a systematic monitoring of a publicly accessible area on a large scale" (point (c)) — which describes a great many camera deployments — and for "processing on a large scale of special categories of data" (point (b)) — which is exactly what face recognition across a site is. Many surveillance projects hit one of these; biometric ones usually hit both.

The DPIA is not paperwork for its own sake. Article 35(7) says it must describe the processing and its purpose, assess whether the processing is necessary and proportionate, assess the risks to people, and set out the measures to address them — safeguards, security, minimisation. Done at the right time, it is simply privacy by design written down: it forces the purpose, surfaces the minimisation levers, flags the biometric gate, and produces a record you can show a regulator. Done at the wrong time — after launch — it becomes a description of risks you can no longer cheaply fix.

Figure 4. When a surveillance system needs a DPIA. Large-scale public-area monitoring (GDPR Art. 35(3)(c)) or large-scale biometrics (Art. 35(3)(b)) make it mandatory; the assessment belongs before procurement, not after launch.

Common mistake: doing the DPIA after the system is built. A DPIA written to "tick the box" once the cameras are live inverts its entire purpose. The assessment exists to change the design — to catch the over-wide field of view, the unnecessary face-recognition feature, the year-long retention default — while changing them is still cheap. Run it during specification, revisit it when the risk changes, and treat its output as design input, not as a launch artefact.

The posture a serious surveillance product takes

Pull the pieces together and a consistent posture emerges — the way a team that takes privacy seriously actually builds and operates a surveillance system. It is not a long list of restrictions; it is a small number of habits applied early.

Such a team starts from the assumption that the system handles personal data and designs accordingly, rather than discovering the obligations late. It treats the biometric decision as a gated, deliberate choice with its own lawful basis, consent, and assessment — never a default. It minimises by default across every lever: purpose-bound cameras, privacy zones over what it does not need to see, resolution matched to the job, analytics off unless required, short retention, and access scoped to need-to-know. It runs the impact assessment before procurement and uses it to shape the design. It builds the privacy-protecting mechanics into the pipeline — masking and redaction so footage can be used without over-exposing bystanders, covered in face masking, redaction, and privacy-preserving analytics — and it handles transparency and consent properly, the subject of consent and notice for surveillance and biometrics. And because the rules differ by place, it designs to the strictest jurisdiction it operates in, which is the job of regional regulation: a map of where the rules differ.

This overview is the map; the rest of this block is the territory. Each posture habit becomes a detailed article, and the block closes with a single runnable list in the surveillance compliance checklist. If you remember one thing from this article, make it the ordering: privacy is decided at design time, minimised by default, and gated hard at biometrics — and a system built that way is both more lawful and, usually, leaner and cheaper to run.

Figure 5. The privacy posture as a map of this block. Each design habit — minimise, gate biometrics, assess, mask, get consent, retain briefly, scope access — is detailed in a dedicated privacy-and-compliance article.

Where Fora Soft fits in

Privacy by design is where a slick surveillance demo and a deployable product diverge, because the demo never has to survive a regulator, a subject-access request, or a biometric-consent lawsuit. Fora Soft has built video streaming, real-time video, and computer-vision systems since 2005 — more than 625 shipped projects for 400+ clients — and the surveillance work sits exactly where video, analytics, and privacy law meet. When we design or integrate a video management system, we treat the biometric decision as a deliberate, gated choice rather than a default; we minimise by default — purpose-bound capture, privacy zones, scoped access, short retention — and we build masking, redaction, and audit logging into the pipeline instead of bolting them on later. The accuracy-vs-performance habit carries straight over to privacy: we lead with how the system behaves and what it exposes under real load, then the capability — because a feature that creates unmanaged personal data is a liability no matter how well it scores in a demo.

What to read next

• GDPR for video surveillance
• BIPA and US biometric privacy law
• The surveillance compliance checklist

Download the privacy-by-design starter guide (PDF) — the two-regimes distinction (video vs biometrics), the data-minimisation levers with their legal anchors, the DPIA-trigger quick test, the seven privacy-by-design principles mapped to GDPR Art. 25, and a posture checklist you can run before specifying a system.

Call to action

• Talk to a surveillance engineer — book a 30-minute scoping call to talk through your privacy by design surveillance plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Privacy by Design for Surveillance — Starter Guide — One-page printable starter guide for framing a surveillance deployment before procurement: the two-regimes distinction (recording video = personal data, GDPR Art.

References

1. Regulation (EU) 2016/679 (GDPR), Art. 25 — Data protection by design and by default, European Union. The legal anchor for this article: the controller must implement measures "designed to implement data-protection principles, such as data minimisation" at the time of design and during processing (25(1)), and by default process "only personal data which are necessary for each specific purpose," covering the amount collected, extent of processing, storage period, and accessibility (25(2)). Tier 1. https://gdpr-info.eu/art-25-gdpr/ (accessed 2026-06-09)
2. Regulation (EU) 2016/679 (GDPR), Art. 4(1) and Art. 4(14) — definitions of 'personal data' and 'biometric data', European Union. Establishes that recorded video of identifiable people is personal data (4(1)), and that biometric data is data resulting from specific technical processing of physical characteristics "which allow or confirm the unique identification" of a person (4(14)). Tier 1. https://gdpr-info.eu/art-4-gdpr/ (accessed 2026-06-09)
3. Regulation (EU) 2016/679 (GDPR), Art. 9 — Processing of special categories of personal data, European Union. The biometric gate: processing of biometric data for the purpose of uniquely identifying a person is prohibited (9(1)) unless a narrow exception applies (9(2), e.g. explicit consent) — the legal step-change between recording video and running face recognition. Tier 1. https://gdpr-info.eu/art-9-gdpr/ (accessed 2026-06-09)
4. Regulation (EU) 2016/679 (GDPR), Art. 5(1)(c) — data minimisation, European Union. Personal data must be "adequate, relevant and limited to what is necessary in relation to the purposes" — the principle behind every minimisation lever (purpose, field of view, resolution, analytics, retention, access). Tier 1. https://gdpr-info.eu/art-5-gdpr/ (accessed 2026-06-09)
5. Regulation (EU) 2016/679 (GDPR), Art. 35 — Data protection impact assessment, European Union. Requires a DPIA prior to processing where there is likely high risk (35(1)), and "in particular" for large-scale special-category data (35(3)(b)) and "systematic monitoring of a publicly accessible area on a large scale" (35(3)(c)) — the two triggers most surveillance systems hit; 35(7) lists the required contents. Tier 1. https://gdpr-info.eu/art-35-gdpr/ (accessed 2026-06-09)
6. EDPB Guidelines 3/2019 on processing of personal data through video devices (Version 2.0, 2020), European Data Protection Board. The video-specific interpretation of GDPR: biometric/facial-recognition processing entails heightened risk and demands a DPIA and stronger safeguards; data minimisation means disabling unneeded video functions ("if audio recordings and facial recognition are not required, these video functions should be disabled") and masking areas outside the purpose. Tier 2 (issuing-body guidance). https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-32019-processing-personal-data-through-video_en (accessed 2026-06-09)
7. Illinois Biometric Information Privacy Act (BIPA), 740 ILCS 14, Illinois General Assembly. The US biometric benchmark: informed written consent required before capturing a biometric identifier (15(b)), a published retention/destruction schedule (15(a)), and a private right of action with liquidated damages of $1,000 (negligent) or $5,000 (intentional or reckless) per violation (Section 20) — the personal-liability exposure that plain video recording rarely carries. Tier 1. https://www.ilga.gov/legislation/ilcs/ilcs3.asp?ActID=3004 (accessed 2026-06-09)
8. ISO 31700-1:2023 — Consumer protection: Privacy by design for consumer goods and services, Part 1: High-level requirements, International Organization for Standardization. The first international standard on privacy by design, published 31 January 2023, setting out 30 high-level requirements for protecting privacy across a product's lifecycle — the standards counterpart to GDPR Art. 25's legal obligation. Tier 1 (international standard). https://www.iso.org/standard/84977.html (accessed 2026-06-09)
9. Privacy by Design: The 7 Foundational Principles, Ann Cavoukian, Information and Privacy Commissioner of Ontario (originated 1990s; endorsed by the 2010 resolution of the International Conference of Data Protection and Privacy Commissioners). The origin of "proactive not reactive," "privacy as the default setting," and end-to-end lifecycle protection — the philosophy GDPR Art. 25 later codified. Tier 2 (foundational framework). https://iapp.org/media/pdf/resource_center/pbd_implement_7found_principles.pdf (accessed 2026-06-09)
10. EU Artificial Intelligence Act (Regulation (EU) 2024/1689), Art. 5 and high-risk biometric provisions, European Union / European Commission. Bans certain real-time remote biometric identification in publicly accessible spaces (Art. 5, applicable since 2 February 2025) and classifies many biometric systems as high-risk; under the Digital Omnibus political agreement of 7 May 2026, high-risk obligations apply from 2 December 2027 — a forward-looking layer above GDPR for AI-driven surveillance analytics. Tier 1 (statute) + Tier 5 (news for the amended date — verify at publish). https://artificialintelligenceact.eu/high-level-summary/ (accessed 2026-06-09)

Where sources differ in emphasis, the official law and issuing-body guidance control. GDPR Articles 25, 9, 5(1)(c), and 35 are quoted from the regulation text; the EDPB Guidelines 3/2019 supply the video-specific reading (the disable-unneeded-functions and masking examples). The EU AI Act high-risk timeline is in flux — the 2 December 2027 date reflects the May 2026 Digital Omnibus political agreement and should be re-verified against the Official Journal at publish, since 2 August 2026 remained an active date until formal adoption.