Quick answer: Treat a face-function request as a project-review decision before enabling it. Establish the purpose, actual data processing, exact product support and applicable requirements. A feature label or consent checkbox alone does not establish that the use is appropriate or lawful.
On this page
Ask what the customer needs to achieve
Finding an incident clip, counting entries, verifying access and matching a person against a watch list are different purposes. Ask what decision follows the result, who is affected and why a less intrusive approach would not meet the need. Record the site location, operator, affected people and responsible privacy/legal reviewer. Employment, retail, public-space and access-control contexts can raise different obligations. Do not promise a function first and ask the customer to supply a justification afterwards.
Inspect the processing, not just the feature name
| Label | What to establish before enabling |
|---|---|
| Face detection | How a face is detected, whether measured/numerical features are created, and what is retained or transmitted. |
| Face capture | Which images/metadata are saved, their use, access, retention and whether additional biometric processing occurs. |
| Recognition or verification | Whether measurements are compared with enrolled records, for which decision, and with what required safeguards. |
| Face/attribute search | Which attributes or representations are used, where the data originates and whether the search supports the approved purpose. |
The Canadian privacy regulator’s private-sector guidance explains that face detection using a numerical facial representation can collect biometric information even if the representation is deleted quickly. A photograph alone and extracted facial measurements are not automatically the same thing. Consequently, “detection,” “capture” or “counting” is not a reliable exemption label. Ask for the implementation details needed to classify the actual deployment: inputs, templates/representations, locations, transfers, retention and purpose. Do not infer those details from an attractive demo or a catalog AI row.
Keep product support separate from authorization
The current catalog lists Face Detection and Face Recognition under AI by NVR for CS-N220 P16H-AI. That establishes a printed capability label, not the full implementation, processing-channel count or permission for a site. Confirm exact model/revision, firmware, software and requested configuration in writing. Also distinguish VCA Search from identity matching. A search result may help review footage without establishing who a person is. A feature label is not proof of a person’s identity or a guaranteed match.
Obtain the project’s applicable review
For Canadian private organizations, the OPC guidance addresses an appropriate purpose, necessity, effectiveness, proportionate impact and less intrusive alternatives, alongside consent and other privacy duties. Consent does not make an otherwise inappropriate purpose acceptable. Provincial and other applicable requirements still need review.
In the United States, review the relevant state, local and sector requirements for the actual activity and operator, including any applicable biometric-data duties. Use the state-law project checklist to organize the official source, scope, review date and customer decision. Do not assume an exemption or borrow another jurisdiction’s retention period for the site.
The customer’s qualified reviewer should identify the actual requirements and any filings, notices, consent, contractual or impact-assessment steps before collection begins. Product support cannot replace that decision. Keep the reviewer’s written scope and conditions with the project record.
Consider a less intrusive way to meet the purpose
Consider a supported perimeter/tripwire alert with human response for an after-hours boundary event, time/channel/event search with ordinary playback for an incident, or an appropriate non-face credential process for entry management. These options may reduce identity matching, but their names do not establish that they are outside privacy rules or free of biometric processing. Confirm the actual data and implementation for the exact system, and obtain the customer’s approval of the selected purpose and configuration.
Define controls and a human decision process
- Approve the purpose, locations, affected people and actual data flow.
- Complete the required review and prerequisites before enrollment or collection.
- Limit authorized access, exports and administrative changes to the agreed roles.
- Define retention, deletion, access requests and incident response for the actual system.
- Test representative conditions and record missed events and incorrect matches.
- Require appropriate human review and a safe alternative where a result could affect a person.
NIST’s 2019 demographic-effects research documented performance differences across tested algorithms and groups. It is not an assessment or endorsement of CASE or its current implementation. Lighting, pose, image quality and operating thresholds belong in the actual acceptance test. Do not promise zero errors or treat a single automated result as proof of identity.
Document the decision and default state
| Item | Decision / evidence | Owner / review date |
|---|---|---|
| Purpose and location | ____________________ | ____________________ |
| Actual data flow and approved function | ____________________ | ____________________ |
| Applicable review, notice/consent and alternatives | ____________________ | ____________________ |
| Access, retention, deletion and security | ____________________ | ____________________ |
| Acceptance tests, limits and human response | ____________________ | ____________________ |
Until the supported function and required approvals are established, leave the proposed face-based function disabled and record that state. Do not enable it temporarily on real customers or staff merely to make a sales demonstration.
Use named permissions and the handover record to assign control and review ownership. A new purpose, location, version or data path may require reassessment; the first review does not automatically cover every later use.
FAQ
Is face capture always outside biometric rules?
No. Establish the actual measurements, representations and use rather than relying on the label. Use the AI NVR planning guide to record the exact technical scope before the reviewer decides what may be enabled.
Does a printed Face Recognition function authorize its use?
No. Product support and the project’s applicable approval are separate questions.
Can the installer simply collect a signed consent form?
Consent is only one possible requirement. The responsible reviewer must assess the actual purpose and applicable obligations.
Send the exact devices/versions, proposed purpose and required data-flow questions to security camera technical support. Keep the legal/privacy decision with the customer’s responsible reviewer and include the resulting scope, limitations and required human response in the project records.
References
References reviewed October 30, 2026. The OPC source is published 2025 guidance for private organizations; NISTIR 8280 is December 2019 research. These sources do not establish current CASE implementation, deployment approval or an all-jurisdiction legal review.
- OPC — guidance for processing biometrics in private organizations
- NISTIR 8280 — face-recognition demographic effects research
