In short
Responsible face recognition needs a purpose narrow enough to test, retention short enough to survive audit, human review that is a real control rather than a signature, and a fallback path that does not single people out. This page sets out the controls a deployment should carry.
This page is not legal advice
Biometric regulation differs by country, by state or province, and by sector, and it changes. Nothing here is jurisdiction-specific legal advice, and it should not be relied on as such. Customers must assess the laws and deployment requirements applicable in their own jurisdiction, with their own advisers. What this page offers is the engineering shape of the controls that such an assessment will ask about.
Every deployment has a population it serves worse
And a decision path a person has to be able to overrule. Both of those are design work rather than policy language, which is why they appear on an engineering page rather than only in a terms document.
The controls below are ordered roughly by how early they have to be decided. The first three are architectural — getting them wrong means rebuilding — and the last few are operational, which means they can be improved after go-live but usually are not unless someone plans to.
The controls
Fourteen things a defensible deployment carries
Each is stated as something you can check rather than something you can claim. A control that cannot be demonstrated is a description.
Purpose limitation
Name the population, the location, the trigger and the action. A purpose broad enough to justify anything cannot refuse the next reasonable-sounding request to reuse the system — and that request always comes.
Lawful authorisation
A basis for this specific purpose, recorded, with a named owner. Not a general basis for "security", which is not a purpose that can be tested.
Enrolment controls
Who may enrol, with what consent or authority, under what conditions, and how that is evidenced. Enrolment is where the lawful basis is either established or lost.
Watchlist governance
Every entry with a named authoriser, a recorded basis and an enforced expiry. A list that only grows becomes both operationally useless and legally indefensible.
Human review
A person sees the evidence and decides. Their decision is logged separately from the system’s output so the two can be compared — which is the only way automation bias becomes visible.
Retention
Per data category, enforced in software, with deletion logged. Captured images, templates, event records and audit entries have different appropriate lifetimes.
Template protection
Encrypted at rest, access-controlled, and treated as biometric personal data rather than as an opaque blob. A template cannot be reissued the way a password can.
Access logging
Every enrolment, search, export, configuration change and threshold change, with the identity of the person. Access to the audit record is itself logged.
Demographic testing
Both error types broken down by group, measured on the population that will actually use the system, with a stated plan for what happens if a difference is found.
Camera and environment validation
Measured capture conditions at each point, re-measured after any change. A system that works is a system whose inputs have been checked.
Fallback procedures
A route through for everyone the system cannot or should not serve, quick enough and unremarkable enough that using it does not single someone out.
Incident handling
A defined response for a biometric data incident, including who is told and how the audit log establishes what was accessed. Designed before, not after.
Data-subject requests
The ability to locate, export and verifiably delete one person’s data, and to show that it happened. Retrofitting this is substantially harder than building it in.
Pilot acceptance criteria
Agreed in writing before measurement starts, including the governance controls — not only the error rates. Criteria agreed afterwards are criteria that moved.
Human review
The failure mode that is invisible unless you measure for it
Automation bias is not an abstract concern. It is a predictable consequence of putting a confident-looking system in front of a person under time pressure, and it has a specific shape.
A system that presents a name and a percentage invites acceptance. A system that presents two images side by side, a score and the threshold in force invites comparison. The difference in interface design produces a difference in decision quality that no amount of training compensates for.
The measurable version of this is simple: log the operator’s decision separately from the system’s output and compare them periodically. If the human essentially never disagrees, the review step is adding a signature rather than oversight. That is a finding, not a reassurance, and it is only available if the two were recorded separately in the first place.
| Design decision | Review as a real control | Review as a signature |
|---|---|---|
| What the operator sees | Supported: Captured image and candidate image side by side, plus score and threshold. | Not supported: A name and a confidence percentage. |
| How the decision is recorded | Supported: Separately from the system’s output, with the operator identity. | Not supported: A single acknowledgement flag with no outcome. |
| Default action | Supported: Nothing consequential happens until a person decides. | Not supported: The action fires and the operator can theoretically stop it. |
| Alert volume | Supported: Configured to what the room can actually review. | Not supported: Whatever the system produces, reviewed by nobody. |
| Ongoing measurement | Supported: Agreement rate between operator and system tracked over time. | Not supported: Never measured, so the failure is invisible. |
| Dismissed alerts | Supported: Reviewed for pattern; a camera generating dismissals is telling you something. | Not supported: Discarded, along with the most useful data the system produces. |
Governance readiness checklist
Work through this before a deployment, and again before any expansion of it. The first four are the ones that are expensive to revisit.
-
Write the purpose in one testable sentence
Name the population, the location, the trigger and the action. If you cannot say what the system must refuse to do, the purpose is not yet narrow enough.
-
Record the lawful basis and name its owner
For this purpose specifically, with the assessment behind it, reviewed by whoever in your organisation owns that judgement.
-
Decide retention per data category and enforce it in software
Captured images, templates, event records and audit entries. Configure each explicitly and log every deletion so the period can be demonstrated.
-
Design the fallback path and cost its staffing
Quick, visible and unremarkable to use. This determines the recurring cost of the deployment more often than the licence does.
-
Define who may enrol, search, export and change a threshold
As four separate permissions, not one administrator role. Collapsing them removes the distinction an audit depends on.
-
Specify what the operator sees at the moment of decision
Both images, the score and the threshold. Not a name and a percentage, which invites acceptance rather than judgement.
-
Log operator decisions separately from system output
And plan to compare them. This is the only way automation bias is detectable, and it costs nothing at design time.
-
Measure both error types by demographic group
On the population that will actually use the system, with a stated plan for what you will do if a difference is found.
-
Establish the audit record by exercising it
Reconstruct a transaction from the log during commissioning. An audit trail that has never been used is an assumption.
-
Write the incident response before you need it
Including how the audit log establishes what was accessed. Templates cannot be reissued like passwords, so the harm assessment is different.
-
Build verifiable deletion for data-subject requests
Locate, export and delete one person’s data, and show it happened. Much harder to add later than to design in.
-
Set a review date for the whole assessment
Deployments drift and regulations change. An assessment with no review date is an assessment that will be out of date without anyone noticing.
Frequently asked questions
What makes a face recognition deployment lawful?
That depends entirely on your jurisdiction, your sector and the specific purpose, and nothing on this page is legal advice. What is universal is the shape of the assessment: a lawful basis for this specific purpose, a purpose narrow enough that it can be tested rather than merely asserted, proportionality between the intrusion and the problem, and controls that can be demonstrated rather than described. You must assess the laws and requirements applicable where you deploy.
How long should biometric data be kept?
The defensible default is: discard the captured image once the match resolves, keep the template only while the person’s entitlement or the lawful basis lasts, and keep the audit record for as long as it may be needed to answer a challenge. What matters as much as the periods is that they are enforced in software and that deletion is logged — a retention period that depends on someone remembering is not a control.
What does meaningful human review look like?
A person who sees the actual evidence — the captured image, the candidate image, the score and the threshold in force — and whose decision is recorded separately from the system’s output. The separate recording is what makes review measurable. If operators essentially never disagree with the system, review has become a signature rather than oversight, and that failure is invisible unless you deliberately look for it.
How should bias and demographic performance be handled?
By measuring it at your deployment rather than assuming a published aggregate applies. Error rates vary across age, sex and skin tone, and an aggregate figure averages that away. Measure both error types broken down by group, using the population that will actually use the system, and be prepared to act on a difference — by changing capture conditions, by changing the referral path, or by not deploying at that location.
What is a fallback path and why does it matter so much?
It is the route through for people the system cannot or should not recognise: children, wheelchair users, people in lawful head coverings, people whose appearance has changed, and people who simply decline. It matters because it determines the staffing, and the staffing usually dominates the business case. It also determines whether the deployment is experienced as a convenience or as something that singles people out.
Can a face match trigger an automatic consequence?
Automatically bookmarking video, notifying an operator or logging an event is reasonable. Automatically refusing entry, dispatching staff to intercept someone, or recording a person as identified are not, because all three treat a similarity score as established fact. Consequential action should require a person who has seen the evidence and whose judgement is separately recorded.
How do we handle a data-subject request about biometric data?
By being able to demonstrate rather than assert. That means knowing where every copy of a person’s template and captured images lives, being able to delete them verifiably, and having an audit log that shows the deletion happened. Design for this at the start: retrofitting verifiable deletion onto a system that was not built for it is substantially harder than building it in.
What should happen after a biometric data incident?
The same as any personal data incident, with two additions specific to biometrics. First, templates cannot be reissued the way a password can, so the containment question is different and the assessment of harm is more serious. Second, the audit log needs to be able to establish what was accessed and by whom — which means it has to have been designed for that before the incident, not after.
Next step
Design the governance with the system
Retention, review, fallback and audit are cheaper to design in than to retrofit, and they are what a deployment is judged on years later. Bring the purpose and the population, and the design conversation starts there.