Direct answer: Start with purpose, necessity and alternatives. If face recognition is not necessary, do not use it; if it is, never make it the only verification method. Do the impact assessment, separate consent, security and filing, and accept the device, process, contract and evidence together—not the hardware first and compliance later.
This guide is for managers, HR, admin/security, IT/security, legal/compliance, product and vendors at companies using or considering face recognition for access control, attendance, visitors, quality inspection or customer analytics. Information is current to 30 October 2026. It is public regulation, judicial interpretation, national standards and project method, not legal advice; the specific scenario, consent, impact assessment, filing, employee relations and contract liability are governed by the rules, regulator requirements, company policies and legal counsel.
Face information is sensitive personal information. Avoid it if you can; if you must use it, never make it the only verification method. Do the impact assessment, separate consent and alternatives before buying devices, algorithms or vendor platforms; file when stored face records reach 100,000.
What should an enterprise decide first in 2026?
Start with purpose, necessity and alternatives. Avoid face recognition if you can; if you must use it, never make it the only verification method, and complete the impact assessment, separate consent, security and filing.
Face recognition is not an "access-control upgrade"; it processes sensitive personal information. China's Measures for the Security Management of Face Recognition Technology Applications, effective 1 June 2025, require a specific purpose and sufficient necessity, the least-impact method and strict protection. The company must answer "why face, is there a non-face method, who is affected, what if it fails" before choosing hardware.
| Scenario | Purpose/necessity | Alternative | Main risk | Recommendation |
|---|---|---|---|---|
| Employee access | Entry/exit security | Card, QR, phone, manual check | Forced sole verification, employee relations | Optional, not sole |
| Attendance | Working time/scheduling | Card, phone, time clock | Contactless collection, continuous monitoring | Prefer non-face |
| Visitor registration | Visitor safety/appointment | ID + manual, QR | Over-retention, no notice | One-time authorisation |
| Quality/workstation | Safety/process compliance | Badge, sensor, manual | Continuous monitoring, false match | Only necessary identification |
| Customer analytics | Marketing/footfall | Anonymous counting, manual observation | No notice, profiling, discrimination | Not recommended |
| Public-area monitoring | Public safety | Ordinary video | Beyond public-safety necessity, private spaces | Strictly limited |
Scenario judgement is editorial; purpose/necessity, alternatives and legality depend on the actual scenario, affected people, company policies and regulator requirements.
Which practices are most likely to cross the line?
Access, attendance, visitors, quality inspection and customer analytics carry different risks. Forced face scans, private spaces, minors, unmarked public areas and employee monitoring most easily cross the line.
The Measures set hard boundaries: if another non-face method can achieve the same purpose, face recognition must not be the only verification method; if a person refuses face verification, provide another reasonable and convenient method; do not mislead, defraud or coerce someone by citing service access or service quality; public-area installation must be necessary for public safety, with prominent notice, and must not be inside private spaces such as hotel rooms, public bathrooms, changing rooms or toilets. The Supreme People's Court interpretation also says bundled consent or "no consent, no service" cannot be used as a valid defence.
| Practice | Why high-risk | Possible breach | Alternative |
|---|---|---|---|
| "No face, no entry/no work" | Face as sole verification, no choice | Non-unique verification/forced consent | Card/QR/manual |
| One checkbox, bundled consent | Not separate consent; cannot refuse | Separate consent/standard terms | Separate pop-up/written consent |
| Face devices in offices/changing rooms/toilets | Private space/continuous monitoring | Private-space prohibition/necessity | Remove or use ordinary access control |
| Contactless face analytics in stores/malls | No notice, profiling, marketing purpose | Notice/consent/necessity | Anonymous footfall counting |
| Minors' face data without guardian consent | Minors' sensitive information | Guardian consent/special rules | Do not collect, or guardian process |
| Default cloud upload/long retention | Wider exposure, over-retention | Device-local/shortest retention | Edge storage/periodic deletion |
The high-risk list is editorial; specific illegality, liability and defences depend on the Measures, the Personal Information Protection Law, the Supreme People's Court interpretation and the facts.
How should non-unique verification and alternatives be designed?
Non-unique verification is not "add another card reader". People who refuse face scans need a reasonable, convenient alternative, without bundling, inducement or service downgrade.
"There is an alternative" does not mean "the alternative is usable". If the card reader is in a guard room, needs extra approval, has a long queue, or invites manager retaliation, it is still forced in practice. Test the alternative as the main path: how does a person who refuses/withdraws consent enter, clock in, register as a visitor, handle exceptions? Is it equally convenient, free, and without impact on performance/service?
| Scenario | Alternative design | Acceptance evidence | Common failure |
|---|---|---|---|
| Employee access | Card/QR/phone/manual; same entrance | On-site test, queue time | Alternative at a side door/needs approval |
| Attendance | Card/phone/time clock; no performance penalty | Attendance rule, employee notice | No face scan = absence |
| Visitors | ID + manual/QR; one-time authorisation | Visitor flow, notice | Face-only registration |
| Quality/workstation | Badge/sensor/manual; only necessary identification | Workstation flow, false-match handling | Continuous monitoring/no exit |
| Withdrawal | Online/offline easy withdrawal; stop and delete | Withdrawal record, deletion proof | Withdrawal link cannot be found |
| Exception/failure | Manual fallback; no denial of service due to failure | Drill record, SOP | System down = full stop |
Alternatives are editorial; "reasonable and convenient" depends on the scenario, group, company policy and regulator requirements. Do not use bundling, inducement or service downgrade to force consent.
How should impact assessment, notice and consent work?
The impact assessment covers purpose, necessity, impact, risk and measures; consent must be separate and revocable; notice must be clear; minors also need guardian consent.
Face information is sensitive personal information. Before processing, tell people who the processor is and how to contact them, the purpose/method/retention, necessity/impact and how to exercise rights. Consent-based processing needs separate, informed, voluntary and explicit consent, with an easy withdrawal method. The Measures also require a personal-information protection impact assessment before processing, with the report and processing records kept for at least three years; redo it when purpose/method changes or a major security incident occurs. Minors under 14 need guardian consent and special rules.
| Item | What to write/do | Evidence | Common gap |
|---|---|---|---|
| Purpose/necessity | Specific purpose; why non-face is insufficient; least-impact method | Assessment report, scenario note | "Improve management efficiency" is too vague |
| Notice | Processor, purpose/method, retention, necessity/impact, rights | Notice text, on-site sign | Only says "for security" |
| Separate consent | Not bundled; voluntary, explicit; revocable | Consent record, withdrawal entry | One checkbox for everything |
| Minors | Guardian consent; special processing rules | Guardian consent, rules | Collecting students/children directly |
| Impact assessment | Legality, necessity, impact, risk, measures | Report (≥3 years) | No report/box-ticking |
| Retention/deletion | Shortest necessary; delete on expiry/withdrawal/termination | Retention policy, deletion log | Default long retention |
| Re-assessment | Purpose/method change or major incident triggers a new assessment | Change log, incident log | No review after launch |
The notice/consent/assessment checklist is editorial; specific notice, separate consent, impact assessment and minors' rules depend on the Measures, the Personal Information Protection Law and company policies.
How should the 100,000 filing and system security be accepted?
At 100,000 stored face records, file with the provincial cyberspace regulator within 30 working days. Use encryption, audit, access control and intrusion protection; keep face data on the device in principle.
The Measures require a filing when the number of stored face records reaches 100,000, within 30 working days of reaching that number, with the provincial or higher cyberspace regulator; change within 30 working days and cancel within 30 working days on termination. The 30 May 2025 filing announcement also required organisations that already reached 100,000 before 1 June 2025 to file by 14 July 2025. The "100,000" is stored face records, not employees or customers.
Security is not "the vendor says it is encrypted". The Measures require encryption, security audit, access control, authorisation management, intrusion detection and defence; unless law/administrative regulation or separate consent provides otherwise, face information should be stored on the face-recognition device and not transmitted over the internet; retention should be the shortest necessary. Systems subject to MLPS/CII must also meet those obligations.
| Check | Pass standard | Evidence | If failed |
|---|---|---|---|
| Filing trigger | Accurately count stored face records; start at 100,000 | Ledger, counting method | Fix count/stop adding |
| Filing timing | Within 30 working days; change/cancel as required | Filing receipt, change log | File immediately/pause |
| Filing materials | Entity, purpose/method, volume/security, rules/SOP, impact assessment | Material list | Complete/redo assessment |
| Local storage | On-device in principle; no default cloud upload | Architecture, config | Change architecture/stop transfer |
| Encryption/access | Encryption, least privilege, authorisation, audit | Config, logs, access table | Remediate/restrict |
| Intrusion defence | Detection/defence/patching/incident response | Scan report, drill | Add controls/downgrade |
| Retention/deletion | Shortest necessary; delete on expiry/withdrawal/termination | Deletion log, policy | Delete/audit |
The filing/security checklist is editorial; specific materials, counting, storage and security requirements depend on the Measures, the filing announcement and the regulator.
What should the vendor contract and acceptance checklist cover?
Write data ownership, deletion, subcontracting, security incidents, audit and exit. Accept the alternatives, notice, consent, assessment, filing, security and drills.
A face-recognition project usually involves device vendors, algorithm vendors, system integrators, cloud/operations and property/security. The contract should state who determines the purpose, who is the personal-information processor, where data is stored, whether it is used for training, whether it is subcontracted, the incident-notice deadline, deletion/export, audit rights, model/device retirement and exit. Do not accept "the vendor is responsible for compliance" as a one-line answer; put the obligations and evidence into the contract.
| Clause | What to write | Evidence | Red flag |
|---|---|---|---|
| Role/purpose | Processor/entrusted party; purpose/scope; no use beyond scope | Contract, DPA | "Vendor may use data freely" |
| Storage/transfer | Device/local/cloud; region; internet transfer | Architecture, config | Default cloud upload |
| Training/reuse | No training/reuse/resale; anonymisation boundary | Contract, logs | "De-identified data may be used for model optimisation" |
| Subcontracting | Subprocessor list, approval, equivalent obligations | Subprocessor list | Hidden third parties |
| Security incident | Notice deadline, response, compensation, regulator communication | Incident SOP, drill | "As soon as possible" with no deadline |
| Deletion/exit | Delete on expiry/termination; export; device return | Deletion proof, handover | Reports only, data not deleted |
| Audit/retirement | Audit rights; model/device retirement/replacement | Audit record, exit plan | No export when the service ends |
Contract clauses are editorial suggestions, not a substitute for legal review; specific roles, data, subcontracting, incidents and exit liability depend on the contract, DPA, vendor and deployment.
How should the work be sequenced over 90 days?
Inventory scenarios and alternatives first, then assessment/consent/filing/system changes/drills. Do not buy hardware first and add compliance later; finish training and drills before launch.
Face-recognition projects often arrive "hardware first, compliance later". Start with the scenario inventory and alternatives, then decide whether to buy. The impact assessment, notice/consent and filing can run in parallel with technical selection, but testing, training and drills must finish before launch. For employee-facing projects, communicate early, explain the alternative path and withdrawal method.
| Phase | Actions | Outputs | Owner |
|---|---|---|---|
| Weeks 0–2 | Inventory scenarios, groups, purpose, alternatives, existing devices and vendors | Scenario list, alternatives | Admin/HR/IT |
| Weeks 3–4 | Decide whether to use; impact assessment; design notice/separate consent/withdrawal | Assessment report, notice | Legal/compliance |
| Weeks 5–6 | System/device selection; local/encrypted/access/audit; contract/DPA | Architecture, contract, config | IT/procurement |
| Weeks 7–8 | Test alternatives; employee/visitor communication; training; exception/withdrawal drills | Test record, training record | Admin/HR |
| Weeks 9–10 | File if 100,000 threshold; launch checks; signage/notice | Filing receipt, launch checklist | Compliance/IT |
| Weeks 11–12 | Review; audit; retention/deletion; next assessment | Review table, audit record | Compliance/security |
The 90-day plan is an editorial suggestion; filing, assessment, employee communication, procurement and launch timing depend on the company, regulator and vendors.
Who should read this, who should not, and what decision does it support?
It fits companies using access, attendance, visitors, quality inspection or customer analytics. It does not fit teams wanting contactless marketing, employee surveillance or forced sole verification.
Who should read: managers, HR, admin/security, IT/security, legal/compliance, product and property/park operations; teams deploying face recognition for access/attendance/visitors/inspection, or facing employee/customer objections, regulator questions or vendor proposals. Who should not: teams wanting "contactless" customer profiling/marketing, continuous employee monitoring or face as the only verification method; projects without a clear purpose, alternatives and impact assessment; teams expecting a checklist to replace legal advice. Decisions supported: whether to use face recognition, scenario/necessity, alternatives, notice/consent/impact assessment, 100,000 filing, system security, contract and 90-day launch acceptance.
Lingyi Information is a website and enterprise AI project services company, not a law firm or security-assessment body. This article does not replace legal advice, a personal-information protection impact assessment, MLPS assessment or a regulator determination. Scope is confirmed case by case; Lingyi does not promise filing approval, a compliance conclusion, recognition accuracy or employee/customer acceptance.
FAQ
Is face recognition mandatory for office access?
No. If another non-face method can achieve the same purpose, face recognition must not be the only verification method; a person who refuses must be offered another reasonable and convenient method. Cards, QR codes, phones and manual checks can be alternatives, and the alternative must not be made deliberately difficult or punitive.
What if an employee refuses a face scan?
Provide a non-face alternative; do not force, bundle, induce or downgrade service. Put the alternative into the policy and make it actually usable. For employee-facing projects, communicate purpose/scope/retention/withdrawal early and keep consent/refusal/withdrawal records; handle labour relations under the law and company policy.
How is the 100,000 filing counted?
It is the number of stored face records processed by the face-recognition application, not employees, customers or devices. File with the provincial or higher cyberspace regulator within 30 working days of reaching 100,000; change/cancel within 30 working days. Organisations that already reached 100,000 before 1 June 2025 were required by the filing announcement to file by 14 July 2025.
Can face data be uploaded to the cloud?
Unless law/administrative regulation or separate consent provides otherwise, face information should be stored on the face-recognition device and not transmitted over the internet. If cloud/central management is needed, assess legality, necessity, separate consent, encryption/access/audit and region/retention item by item; do not assume a "vendor cloud" is compliant.
Can we use face analytics in stores/malls?
High risk. Face identification, footfall analytics and profiling marketing in stores/malls often involve no notice, non-necessity and exceeding public-safety necessity; the Supreme People's Court interpretation lists illegal face verification/identification/analysis in business/public venues as an infringement of personality rights. Use anonymous footfall counting instead of face profiling.
If the vendor says data is de-identified/anonymised, is compliance done?
Check whether it is truly anonymised and irreversible, and whether the purpose can still identify a person. De-identification/encryption is not anonymisation; if re-identification is possible, it may still be personal information. The contract should cover purpose, training/reuse, subcontracting, deletion and audit—not just "de-identified".
Bottom line
For enterprise face recognition, ask "why is non-face insufficient, and what is the alternative?" first. Then do notice/separate consent/impact assessment, non-unique verification, device-local storage, security and 100,000 filing; write data/deletion/subcontracting/incident/exit into the contract, and accept the alternative path and withdrawal drill before launch.
Method and limits
This article is public regulation, judicial interpretation, national standards and project method, not a legal opinion or compliance certification for any company, scenario, device, vendor or filing. It uses no unpublished customer data, employee records or regulatory case files. The scenario tables, checklist and 90-day plan are editorial suggestions; purpose/necessity, notice/consent, impact assessment, filing, security and contract liability are governed by the rules, regulator requirements, company policies and legal counsel.
Sources
Information is current to 30 October 2026; each official/primary page governs its own scope and version.
- Measures for the Security Management of Face Recognition Technology Applications (CAC/MPS Order No. 19, effective 1 June 2025): cac.gov.cn. Specific purpose/necessity, notice/separate consent, impact assessment, non-unique verification, device-local storage, 100,000 filing and system security.
- Personal Information Protection Law of the PRC: npc.gov.cn. Face information is sensitive personal information; separate consent, impact assessment, minimisation and rights.
- Supreme People's Court interpretation on civil cases involving face recognition (Fa Shi [2021] No. 15): court.gov.cn. Forced/bundled consent, business/public-venue use, property alternative verification and civil liability.
- GB/T 41819-2022, Information security technology—Security requirements of face recognition data (effective 1 May 2023): National Standards Full-text Platform. Security requirements for collection, storage, use, transfer and deletion; a reference for design and acceptance.
- Announcement on filing for face recognition technology applications (30 May 2025): cac.gov.cn. Filing timing, the 14 July 2025 deadline for the existing 100,000 threshold, online filing and change/cancellation.