Face Masking, Redaction, and Privacy-Preserving Analytics

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

Why this matters

This article is the privacy-engineering layer of the surveillance compliance block, written for the security integrator, product manager, retail or smart-building lead, or city security owner who has to keep cameras useful without turning the system into a privacy liability. Masking and redaction are where the abstract principles of privacy by design for surveillance become concrete features you specify, buy, and switch on — and where a wrong assumption (that any blur equals anonymisation, that masking the live view protects anyone if you still record the original) quietly builds non-compliance into the product. You do not need a legal or machine-learning background to read this. Every term is defined in plain language and tied to the named law or standard, and the goal is to leave you able to tell a privacy control that actually removes risk from one that only looks like it does.

Four operations people blur into one phrase

"Masking" gets used for at least four different jobs, and a surveillance design goes wrong the moment they are treated as interchangeable. Pull them apart first.

Privacy masks (privacy zones) are fixed blanked-out regions of a camera's view. You point a camera at a car park, but its edge clips a neighbour's window — so you paint a box over that window, and the camera never records what is behind it. The mask is tied to the scene, not to any person, and it is set once at install time.

Dynamic masking (live anonymisation) is software that finds the people, faces, or licence plates in each frame and covers them as the video plays, in real time. Nothing in the scene is permanently off-limits; the system decides, frame by frame, what to hide. Think of it as a moving sticker that follows every person around the picture.

Redaction is the after-the-fact version: you have recorded footage, you need to share a clip — for an insurance claim, a court, or a data-subject request — and you obscure everyone who is not relevant before the file leaves your hands. Redaction is an export-time operation on stored video, not a live one.

Privacy-preserving analytics is the most different of the four: instead of hiding people in the video, you avoid keeping the video at all, and run the analytic on data that was never identifying in the first place — a count, a heat-map, an event — usually computed on the camera and sent onward as numbers.

Figure 1. Four operations, four places in the pipeline. Privacy masks blank fixed zones at the camera; dynamic masking hides people in the live view; redaction obscures third parties at export; privacy-preserving analytics emits counts and events instead of identifying video.

These four are not competitors — a serious system uses several at once. But they sit at different points in the pipeline, carry different costs, and — most importantly — land on different sides of the one line that decides their legal weight.

The line that governs everything: can it be undone?

Before any technique matters, fix the distinction the whole field turns on. Take an image of a person and obscure their identity. There are two fundamentally different things you might have done.

If the original — the un-obscured face — still exists somewhere, or the obscuring can be computed back into a recognisable image, you have pseudonymised the data. GDPR Article 4(5) defines pseudonymisation as processing personal data so it can no longer be attributed to a person "without the use of additional information," where that additional information is kept separately. The key consequence, stated plainly in GDPR Recital 26, is that pseudonymised data "should be considered to be information on an identifiable natural person" — it is still personal data, and every GDPR obligation still applies. A masked live view whose original recording sits in storage is pseudonymisation. A reversible blur is pseudonymisation. You have reduced exposure, which is valuable, but you have not left the regulation.

If the original is genuinely gone — the identifying pixels destroyed, with no key and no recoverable copy — you may have anonymised the data. Recital 26 says data protection principles "should not apply to anonymous information," so true anonymisation takes the footage outside GDPR entirely. But the bar is severe: the recital tests identifiability against "all the means reasonably likely to be used … either by the controller or by another person," taking account of available technology and its development. Anonymisation is not a checkbox you tick; it is a claim that nobody, using methods that exist now or are foreseeable, can get the identity back.

Figure 2. The spine of the article. Reversible obscuring is pseudonymisation — still personal data, still inside GDPR (Art. 4(5), Recital 26). Only genuinely irreversible obscuring reaches anonymisation and leaves GDPR's scope.

Hold this line in mind for every technique below. The question is never "did we blur it?" The question is "can the identity be recovered by any means reasonably likely to be used?" — and the answer decides whether you are still carrying personal data.

Privacy masks: the simplest control, standardised at the camera

Privacy masks are the oldest and cheapest privacy feature, and because they are configured on the camera itself they are also the most interoperable. The ONVIF standard — the common language that lets cameras and recording software from different makers work together, covered in ONVIF explained for engineers — standardises them in its Media2 Service Specification. A mask is defined as a polygon in coordinates normalised to the video source, the camera advertises how many masks and how many polygon edges it supports (many devices restrict to rectangles), and the VMS can list, create, modify, and delete masks over the standard interface. Some devices even support automatically updating the mask's position as the camera moves.

Because the mask is applied on the camera before the stream is encoded, the obscured region is never recorded in the first place. That makes a privacy mask one of the few controls that is genuinely irreversible by construction — there is no original behind it to recover. Its limit is exactly its strength: it is static. It blanks a fixed area of the scene, so it protects the neighbour's window but does nothing about the people walking through the car park you do mean to watch. For those, you need something that moves.

Dynamic masking: privacy in the live view, and the reversibility trap

Dynamic masking uses analytics to detect people, faces, or plates and cover them as the video plays. This is where the reversible-versus-irreversible line does real work, because dynamic masking ships in two very different forms that look identical on screen.

The reversible form masks the live view for ordinary monitoring but keeps the original footage, encrypted, so that an authorised investigation can lift the mask. Genetec's KiwiVision Privacy Protector is a clear example: operators see an anonymised view, and recovering the un-obscured footage requires an additional layer of access permission, used only when an event warrants it, with an audit trail recording who removed the anonymisation and why. This is a strong privacy-by-design pattern — it enforces data minimisation in daily use and dual control over re-identification — but in GDPR terms it is pseudonymisation, not anonymisation. The original exists; the data is still personal; retention limits, lawful basis, and data-subject rights all still apply. That is not a flaw, as long as you do not mistake it for leaving the regulation.

The permanent form burns the mask into the recording so no original is kept. Axis Live Privacy Shield, for instance, can apply either a solid-colour mask (the strongest privacy, you see only movement) or a mosaic/pixelated mask (low-resolution shapes), with the masking written into the stored video. Permanent masking is a genuine candidate for anonymisation — but only if the masking method is one that cannot be reversed, which is precisely where most teams trip.

Common mistake: masking the live view while recording the original unmasked. A system that shows operators a blurred feed but stores the raw, identifiable footage has not anonymised anything — it has pseudonymised the view and kept the personal data in full. Every GDPR duty (retention limit, lawful basis, subject access, breach exposure) applies to that stored original exactly as if no masking existed. The masked monitor is a useful access control, not a reduction in the data you hold.

Redaction: getting footage out the door without exposing bystanders

Redaction is the export-time job. A retailer gets a data-subject access request, a court orders a clip, a public-records law forces disclosure — and the footage shows other people who have their own privacy rights. The European Data Protection Board addresses this directly in its Guidelines 3/2019 on video devices: when other people are identifiable in material released for a subject access request, that part should be anonymised, "for example by blurring the copy," and it stresses that the blurring must leave "no retroactive ability to recover" the data for it to count as effectively anonymous.

That last clause is the whole game. Modern redaction tools use detection models to track and obscure every face or body in a clip — work that once took an editor hours per minute of footage and now runs in minutes — but the export is only anonymous if the obscuring is irreversible on the exported file and no link back to the source is shipped with it. Redaction done right is one of the clearest legitimate uses of irreversible obscuring in the whole pipeline, because by definition you are creating a disposable copy and destroying identity within it.

The trap under all of it: blur and pixelation are often reversible

Here is the finding that quietly invalidates a lot of "anonymised" footage. Blurring and pixelation feel like they destroy information. They do not destroy it; they scramble it — and scrambled information can be reconstructed.

In a 2016 study, Defeating Image Obfuscation with Deep Learning, researchers trained neural networks to identify people in images that had been obfuscated with the standard techniques. Against faces pixelated with 16×16 mosaicing — the kind of blocky censoring you see on television — the network identified the correct person about 57% of the time, rising to 72% when allowed five guesses, across a set of 530 individuals. Against YouTube's blur applied to faces, it exceeded 50% accuracy on a 40-face set. More recent work has gone further, reconstructing recognisable faces from blurred and pixelated images rather than merely matching them, because the identifying information was only obscured, not removed.

The lesson is not "never blur." It is that light blur and coarse pixelation are reversible, so they are pseudonymisation, not anonymisation — they keep the footage inside GDPR and can fail outright as a privacy measure. If you need an export to be genuinely anonymous, use a method that destroys the pixels: a solid fill over the region, or replacement, rather than a recoverable smudge. This is also why facial-recognition deployments, covered in face recognition in surveillance, cannot lean on a blur to escape the biometric rules in GDPR Article 9.

Figure 3. Why "we blurred it" is not anonymisation. Measured re-identification from obfuscated images (Defeating Image Obfuscation with Deep Learning, 2016) shows pixelation and blur are recoverable; only methods that destroy the pixels approach irreversibility.

Privacy-preserving analytics: the strongest move is not to keep the video

The techniques above all start from identifying video and try to obscure it. Privacy-preserving analytics inverts the problem: arrange the system so the identifying data is never retained at all. This is the most robust privacy posture, because there is nothing to reconstruct.

The cleanest version is edge metadata-only processing. Run the analytic on the camera or an edge box — the deployment choice covered in edge vs cloud video analytics — and send onward only the result: a person count, a dwell time, a queue length, a line-crossing event. The raw frames never leave the device, so the central system holds numbers, not faces. EDPB Guidelines 3/2019 point in exactly this direction under data minimisation, recommending that functions you do not need — facial recognition, audio — be disabled, and that systems mask or scramble what is not relevant to the purpose.

Walk the numbers once, because the gap is enormous. A retail camera streaming H.265 video at 4 Mbps to the cloud for people-counting sends, in a day:

raw video/day = 4 Mbps × 86,400 s ÷ 8 bits/byte
              = 43,200 megabytes
              ≈ 43.2 GB per camera per day  (every face in it)

Now run the count on the camera and emit one small record every 5 minutes:

metadata/day  = 288 records × ~200 bytes
              ≈ 57.6 KB per camera per day  (no face, ever)

That is roughly a 750,000-fold reduction in data — and, far more importantly, the identifying content drops to zero. The cloud never receives a recognisable image, so there is no biometric data to protect, no original to leak, and far less to retain under the limits we cover in retention limits and lawful deletion.

When you do need to retain richer data — for cross-camera search or trend analysis — you move to formal de-identification, and here a standards vocabulary keeps you honest. The Article 29 Working Party's Opinion 05/2014 on anonymisation techniques sorts the methods into two families: randomisation (adding noise, permutation, and differential privacy — which injects calibrated mathematical noise so individual records cannot be singled out) and generalisation (aggregation and k-anonymity, where each record is made indistinguishable from at least k−1 others, with l-diversity and t-closeness as refinements). ISO/IEC 20889:2018 standardises this terminology and classification, and NIST's NISTIR 8053 surveys de-identification of personal information; both are the reference points an auditor will recognise. The same Opinion warns that pseudonymisation is not anonymisation, and that any method must be tested against three residual risks: singling out an individual, linking records across datasets, and inferring new facts about a person. A technique that leaves any of the three open has not anonymised the data.

Figure 4. De-identification has a vocabulary. Randomisation and generalisation (Article 29 WP 05/2014; ISO/IEC 20889) are only anonymisation if they close all three re-identification risks — singling out, linkability, and inference.

A newer option sits between obscuring and not-keeping: synthetic replacement, where a generative model swaps each real face for a realistic but fictitious one that belongs to no actual person, so the scene stays usable for training or demonstration while the identities are gone. Used carefully it can be irreversible, but it inherits the same test — if the mapping back to the real face is stored or learnable, it is pseudonymisation again.

Putting the techniques side by side

The four operations and the de-identification path land differently on the line that matters. The table is the article compressed.

Technique	Applied where	Reversible?	GDPR status	Best for
Privacy mask (ONVIF)	On the camera, fixed zone	No — region never recorded	Outside scope for that zone	Excluding areas you must not film
Dynamic masking, reversible	VMS live view, original kept	Yes — by design, with key	Pseudonymisation — still personal	Daily monitoring with audited unmask
Dynamic / permanent masking	Burned into the recording	Only if pixels destroyed	Anonymisation if irreversible	Recording where identity is not needed
Redaction	At export of stored footage	Must be irreversible on the copy	Anonymous copy if unrecoverable	DSAR, court, public-records release
De-identified analytics	Edge / processing layer	No — identity never retained	Outside scope if no re-identification	Counting, heat-maps, trends

Common mistake: treating a blur slider as a compliance control. Whether an obscuring technique satisfies GDPR depends on irreversibility and on whether an original is retained — not on how strong the blur looks. A heavy mosaic over a stored-original recording is pseudonymisation; a solid fill on a destroyed-original export can be anonymisation. Specify the technique by its effect on recoverability, not its on-screen appearance.

The choice between these techniques comes down to one question asked early: what will you need from the data later? If an investigation might need the identity, you are in reversible-masking territory and you carry the data as personal. If you will never need the original, you can destroy it; and if you do not need the video at all, the strongest move is to keep only the count.

Figure 5. The choice in one tree. Needing to recover identity later means reversible masking (pseudonymisation); not needing the video at all points to edge metadata-only analytics, the strongest privacy posture.

Where Fora Soft fits in

We build video surveillance and computer-vision systems, and in that work privacy is an architecture decision made at the pixel and the pipeline, not a setting toggled at the end. The systems that hold up under both real load and a regulator's questions are the ones where the analytic runs at the edge and emits a count instead of a face, where masking is wired so the stored original is governed exactly as the personal data it remains, and where any "anonymised" export is produced by destroying pixels, not smudging them. We design these pipelines with realistic expectations — detection that masks people in real time carries a precision/recall range that depends on scene, lighting, and crowding, and a missed detection is an unmasked face, so the system is tuned and reviewed accordingly. The verticals where this matters most — video surveillance, computer vision, retail analytics, smart buildings — are exactly the ones we work in.

What to read next

• Privacy by design for surveillance — the data-minimisation posture these techniques implement.
• GDPR for video surveillance — lawful basis, special-category data, and the DPIA.
• Retention limits and lawful deletion — how long obscured and original footage may be kept.

Call to action

• Talk to a surveillance engineer — book a 30-minute scoping call to talk through your video redaction and privacy masking plan.
• See our case studies — 250+ shipped projects across video streaming, WebRTC, OTT, telemedicine, e-learning, surveillance, and AR/VR.
• Download the Privacy-Preserving Surveillance — Technique & Compliance Guide — One-page printable that turns the article into a pre-deployment checklist: the four operations (privacy masks, dynamic masking, redaction, de-identified analytics) and where each sits in the pipeline; the governing….

References

1. GDPR — Regulation (EU) 2016/679, Recital 26 (anonymous and pseudonymised data). Identifiability tested against "all the means reasonably likely to be used"; pseudonymised data is information on an identifiable person; principles do not apply to anonymous information. https://gdpr-info.eu/recitals/no-26/ — Tier 1 (primary law, read directly).
2. GDPR Article 4(5) — definition of pseudonymisation (data not attributable without additional information kept separately). https://gdpr-info.eu/art-4-gdpr/ — Tier 1 (primary law).
3. GDPR Article 4(14) and Article 9 — biometric data as special category (a face template is special-category data, prohibited by default unless an exception applies). https://gdpr-info.eu/art-9-gdpr/ — Tier 1 (primary law).
4. GDPR Article 25 — Data protection by design and by default (masking, minimisation as built-in measures). https://gdpr-info.eu/art-25-gdpr/ — Tier 1 (primary law).
5. EDPB Guidelines 3/2019 on processing of personal data through video devices (v2.0, 2020) — privacy-enhancing technologies that mask or scramble irrelevant areas; disable facial recognition/audio if not needed (data minimisation); for subject access, anonymise others by blurring with no retroactive recovery. European Data Protection Board. https://www.edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-32019-processing-personal-data-through-video_en — Tier 1 (issuing-body guidance).
6. Article 29 Working Party, Opinion 05/2014 on Anonymisation Techniques (WP216) — randomisation vs generalisation; differential privacy, k-anonymity, l-diversity, t-closeness; pseudonymisation is not anonymisation; the singling-out / linkability / inference risk test. https://ec.europa.eu/justice/article-29/documentation/opinion-recommendation/files/2014/wp216_en.pdf — Tier 2 (issuing-body guidance, EDPB predecessor).
7. ONVIF Media2 Service Specification — privacy masks (polygon masks in normalised coordinates; list/create/modify/delete; rectangle-only restriction option; camera-side application). ONVIF. https://www.onvif.org/specs/srv/media/ONVIF-Media-Service-Spec.pdf — Tier 1 (primary standard).
8. ISO/IEC 20889:2018 — Privacy enhancing data de-identification terminology and classification of techniques. International Organization for Standardization. https://www.iso.org/standard/69373.html — Tier 1 (primary standard).
9. NISTIR 8053 — De-Identification of Personal Information (Garfinkel, 2015). US National Institute of Standards and Technology. https://nvlpubs.nist.gov/nistpubs/ir/2015/nist.ir.8053.pdf — Tier 1 (standards-body report).
10. McPherson, Shokri, Shmatikov — "Defeating Image Obfuscation with Deep Learning" (2016), arXiv:1609.00408 — measured re-identification of pixelated (57% top-1 / 72% top-5, 530 individuals) and blurred (>50%, 40 faces) images. https://arxiv.org/abs/1609.00408 — Tier 5 (peer measured benchmark — used for the reversibility/accuracy claim).
11. Axis Communications — privacy in surveillance / AXIS Live Privacy Shield (real-time AI dynamic masking; solid-colour vs mosaic; permanent masking burned into video). https://whitepapers.axis.com/en-us/privacy-in-surveillance — Tier 4 (first-party vendor engineering).
12. Genetec — KiwiVision Privacy Protector (live anonymisation; un-masking gated by additional access permission and dual authorisation; audit trail of who removed it and why — a reversible/pseudonymisation pattern). https://resources.genetec.com/en-product-brochures/kiwivision-privacy-protector-brochure — Tier 4 (first-party vendor engineering).