Evaluating Facial Recognition for Commercial Security

Customers considering facial recognition are usually worried about the result of a weak decision: an unauthorized person still gets through, an innocent person is wrongly flagged, or sensitive face data is exposed after the system has become difficult to unwind. The practical answer is to start with the security outcome and test less intrusive controls first.

Approve facial recognition only when the organization can demonstrate a specific legitimate need, evidence that the system will work, a benefit proportionate to the privacy impact, and no reasonably effective less intrusive alternative. It must also resolve consent or other lawful authority, meaningful choice, real-site accuracy, human review, data control and deletion. For broad retail screening or general entry monitoring, those conditions may support a decision not to proceed.

This framework helps privacy, legal, IT and security leaders decide whether to reject a proposal, redesign it as a narrower verification use, or authorize a controlled pilot. It is operational guidance, not legal advice.

Define the customer outcome before evaluating the technology

Begin with one measurable problem. “Improve security” is too broad to justify biometric processing or to test whether the project worked.

A decision-ready problem statement records:

• the event to prevent, detect or investigate;
• the people, entrance or zone in scope;
• the operational or safety consequence;
• the evidence that the problem exists;
• the performance gap in current controls;
• the person accountable for the outcome; and
• the conditions that would end the project.

For example, a controlled research area may need to confirm that the person presenting an active credential is its assigned holder. That is a different decision from scanning every visitor against a watchlist at a public entrance. The first proposes a one-to-one check after a person claims an identity. The second attempts one-to-many identification across a broader population.

The Office of the Privacy Commissioner of Canada’s 2025 guidance for businesses processing biometrics defines verification as comparing a probe template with one reference template, while identification compares it with multiple templates. The guidance says uniquely identifying biometric information is sensitive because it is linked to identity, stable over time and difficult to change.

Write the desired outcome without naming facial recognition. This prevents a vendor feature from becoming the problem definition. Use baseline evidence such as denied-access events, tailgating observations, lost-credential records or investigation failures. Do not collect extra personal information simply to support the business case.

Apply the necessity and proportionality gate first

The first approval gate should decide whether biometrics are justified at all. The OPC guidance directs organizations subject to PIPEDA to evaluate legitimate need, effectiveness, minimal intrusiveness and proportionality. It also says an initiative should not go forward when the organization cannot explain how it meets those criteria.

Use this comparison before requesting a biometric price:

Customer need	Less intrusive option to test	Evidence facial recognition would need
Stop credential sharing	Photo on credential, supervisor check, anti-passback or PIN	Verified sharing still occurs and creates a material consequence
Control a staff entrance	Badge or mobile credential, door monitoring and tailgate control	Existing controls cannot meet the defined assurance level
Admit expected visitors	Pre-registration, intercom, staffed reception or QR credential	A documented failure that identity matching would reliably correct
Investigate an incident	Properly placed ordinary video, access events and synchronized time	A narrow search need with lawful data sources and governance
Detect a person of concern	Trained response, access rules and incident intelligence	A valid watchlist, proportionate use, reliable matching and fair review

Record the cost, effectiveness, accessibility, privacy impact and operational burden of each alternative. Convenience alone provides a weak reason to expose customers, employees, tenants or visitors to biometric processing. Safeguards can reduce risk, but the OPC cautions that safeguards alone cannot make an otherwise inappropriate collection appropriate.

Use a stop rule: reject or redesign the proposal when the purpose is speculative, the incident evidence is weak, a less intrusive control can achieve the outcome, or the expected benefit does not justify the intrusion.

Prefer verification when it can meet the need

One-to-one verification can narrow collection compared with one-to-many identification. A person first claims an identity, such as by presenting a credential, and the system checks the live sample against that person’s enrolled template. One-to-many identification searches a probe against a database to find a possible identity.

The OPC recommends considering verification before identification and avoiding large centralized biometric databases when viable alternatives exist. It also recommends keeping a biometric template under the individual’s control when that is the most secure way to meet the purpose.

That distinction changes the customer’s exposure:

Design choice	Verification question	Identification question
Population	Who chooses to enrol?	Who may be scanned, including non-enrolled people?
Reference data	Where is the single enrolled template kept?	Who created the watchlist and on what authority?
Consequence	What happens when an enrolled person cannot match?	What happens when an uninvolved person is a possible match?
Alternative	Can the person use a badge, PIN or staffed route?	Can the security outcome be achieved without scanning everyone?
Scale	How many templates are active?	How many probes and reference templates are searched?

Ask the vendor to classify every function precisely. Face detection, face comparison, demographic classification and ordinary video recording involve different processing. A camera specification that says “AI ready” does not establish which functions are enabled, where analysis occurs or what data is retained.

Resolve consent, choice and jurisdiction before design approval

The legal analysis depends on the organization, activity, relationship and jurisdiction. Section 5(3) of Canada’s Personal Information Protection and Electronic Documents Act limits collection, use and disclosure to purposes a reasonable person would consider appropriate in the circumstances. PIPEDA does not govern every Ontario organization or every employment relationship, so privacy and legal advisers should document which federal, provincial, sector-specific, employment, labour, contractual and human-rights duties apply.

The OPC’s biometric guidance says express consent is generally appropriate when sensitive biometric information is involved. It also says consent to collect a photograph or video does not automatically authorize extracting biometric information from it. When biometrics are not integral and essential, organizations must provide another means of access or participation without creating obstacles.

General notice can leave a material gap. In the OPC’s 2020 Cadillac Fairview investigation, mall directory kiosks captured facial images and generated biometric representations without valid consent. Entrance decals referring to video for safety and security did not explain the broader facial processing and were insufficient for meaningful consent. The finding is tied to its facts and applicable laws, but it demonstrates why an ordinary camera sign should not be treated as approval for a new biometric purpose.

Before approval, document:

• who is affected and whether participation is genuinely voluntary;
• the lawful authority and form of consent for each affected group;
• the biometric data collected and any raw image retained;
• the exact purpose, recipients, meaningful residual risks and complaint route;
• an accessible non-biometric path with comparable service;
• how consent can be withdrawn and data deleted; and
• the trigger for renewed consent or review when the purpose or system changes.

Test accuracy in the real operating environment

Accuracy is a property of the complete deployment, not a single vendor percentage. Camera height, angle, illumination, image compression, motion, occlusion, enrolment quality, database size, matching threshold and human workflow all affect the result.

NIST’s current Face Recognition Technology Evaluation demographic-effects summary reports that false negatives are strongly affected by image quality, including exposure and camera angle, and that false-positive variation can occur across demographic groups even with good images. NIST testing is a comparative technical resource. It does not certify a buyer’s particular product, threshold, camera layout or legal compliance.

Require a site acceptance plan that measures at least:

• false-match rate and false non-match rate at the proposed threshold;
• performance in daylight, darkness, backlight and expected seasonal conditions;
• performance with normal head pose, eyewear, hats and accessibility needs;
• results for the people who will actually use or be exposed to the system;
• time and evidence required for a trained person to review a possible match;
• the fallback route when a person does not match;
• adverse actions prevented until authorized human review is complete; and
• complaints, correction, appeal, incident and shutdown procedures.

Document sample sizes and limitations. A small demonstration can confirm workflow and reveal obvious failures, but it cannot prove rare error rates or equal performance across all people. Do not let a polished demo replace evidence from the actual environment.

Ontario organizations should also assess human-rights impacts when biometric output influences access, service, employment or housing decisions. The Ontario Human Rights Commission and Law Commission of Ontario Human Rights AI Impact Assessment asks who benefits, who could be harmed, which alternatives exist, whether biometric tools are used and whether results differentiate on protected grounds. The tool does not provide a definitive legal answer, and it recommends independent legal advice.

Make the buyer, not the vendor, control the data lifecycle

Map the data before signing a contract. Follow the live image, raw sample, template, match score, watchlist record, decision, audit log and backup from collection to final deletion.

Require written answers to these questions:

• Does processing occur at the device, on site or in a vendor cloud?
• Are raw images retained, or only templates? For how long and why?
• Can the template be used by another deployment or reconstructed into a usable image?
• Which customer and vendor roles can view, search, export or administer the data?
• Which subcontractors, support teams and regions receive it?
• Can any sample, template or result train a model or improve a shared service?
• How is the watchlist created, corrected, reviewed and retired?
• What happens to device, cloud, log and backup copies after withdrawal, expiry or termination?
• Can the customer verify deletion and export the configuration and audit history?
• How quickly must the vendor report an incident and support investigation?

The contract should prohibit undisclosed secondary use, cross-customer linking and vendor training with customer biometric data. It should define encryption, keys, privileged access, logging, vulnerability handling, breach support, data return, deletion evidence and termination assistance.

The OPC guidance requires retention only as long as necessary for the stated purpose and permanent destruction from devices, cloud storage and backups after that period, subject to applicable legal obligations. A default storage period or cheap cloud capacity does not provide a retention rationale.

Use reject, conditional-pilot and proceed gates

Make the final decision visible. A committee should not leave a proposal in indefinite “review” while equipment or licences are quietly activated.

Decision	Minimum finding
Reject or redesign	Purpose is broad, need is unproven, a less intrusive option is effective, authority is unresolved, the watchlist source is unacceptable, affected people lack meaningful choice, or the vendor cannot provide data control and deletion evidence
Conditional pilot	Purpose is narrow, legal and privacy review supports a limited test, alternatives have been documented, participation and fallback are defined, data is isolated, and written success and stop criteria exist
Proceed	The pilot demonstrates effectiveness and acceptable error behaviour, every deficiency is closed, consent or authority is operational, responsibilities are assigned, and monitoring, complaints, deletion and shutdown are tested

A pilot approval should state location, population, duration, maximum enrolment, data flow, threshold, permitted decisions, human reviewer, fallback, success measures, complaint route, deletion date and automatic shutdown date. It should not silently become production.

The approver should receive the evidence packet, not a vendor assurance summary. Include the problem statement, alternatives analysis, privacy and human-rights assessments, legal advice record, architecture, data-flow map, threat assessment, vendor terms, accuracy results, accessibility review, operating procedures, training, acceptance results and residual-risk sign-off.

Ask procurement questions that expose a weak proposal

Use the same questions for every bidder:

1. What exact customer problem does your proposed system solve, and how will we measure the result?
2. Is this verification, identification, classification or detection? Which functions can be permanently disabled?
3. Which less intrusive options did you evaluate, and why would they fail here?
4. What independent results apply to this exact algorithm version and operating mode?
5. How do threshold and database size change false matches and false non-matches?
6. Which groups and real-world conditions were missing from the testing?
7. What action can follow a possible match, and where is human review mandatory?
8. Where do samples, templates, scores and logs travel, and who can access them?
9. Can you contractually prohibit model training, secondary use and cross-customer linking?
10. How will you prove deletion from devices, cloud systems, support copies and backups?
11. What non-biometric path remains available, and how will its service level compare?
12. How do we export our records and disable the biometric function without losing ordinary access control or video?

Facial recognition can create a new category of consequence while trying to solve an existing security problem. The strongest design starts with the customer’s outcome, rejects unnecessary biometric processing and makes any narrow use prove its value under real conditions.

Use this assessment before adding biometric functions to an existing Ontario video-surveillance privacy program or requesting a proposal for commercial security cameras. Securitron Canada can help document the security objective, compare alternatives and define testable acceptance conditions for a privacy and legal review.