Biometric Data Governance Under GDPR and ISO 27701

The emergency meeting request landed in CISO Maria Petrova’s inbox with a thud. The subject line read: “URGENT: Biometric Auth - Go/No-Go for Q3 Launch.”

Maria knew what was behind it. Her company, a fast-growing FinTech called Finura, was preparing to launch in-app payment verification using facial and fingerprint recognition. Product saw a market-defining feature. The board saw faster adoption. Fraud teams saw fewer fake accounts. The COO saw less friction. Maria saw a different picture: special-category personal data, DPIA triggers, vendor dependency, retention risk, consent withdrawal, operational resilience, and a breach scenario that could not be solved by issuing a new password.

During the call, pressure arrived immediately. “The competition is months behind us,” the Head of Product argued. “We cannot afford to delay.”

Then the questions started.

Had explicit consent been designed and recorded? Was there a valid GDPR Article 6 lawful basis and Article 9 condition? Was the biometric vendor vetted as an ICT third party under DORA expectations? Had anyone completed a Data Protection Impact Assessment before engineering began? Could Finura prove that a revoked facial template would be deleted from live systems, backups and vendor environments?

The silence said everything.

Biometric data governance is different because the identifier is the person. A password can be rotated. A card can be replaced. A compromised facial template, fingerprint pattern, voiceprint, palm vein template or iris-derived identifier cannot be meaningfully changed. When biometric data is used for unique identification, GDPR treats it as special category data. ISO/IEC 27701:2025 expects a privacy information management system, or PIMS, that can prove why the processing is necessary, how it is controlled, who approved it, how long it is retained, which suppliers touch it, and how rights requests and incidents are handled.

The problem is that many organizations buy a biometric identity product, complete a security questionnaire, add a generic privacy notice and assume encryption solves the issue. It does not. Encryption is necessary, but biometric governance requires a connected operating model.

Clarysec’s approach combines ISO/IEC 27701:2025 PIMS governance, ISO/IEC 27001:2022 control evidence, GDPR accountability and cross-framework mapping through Zenith Controls: The Cross-Compliance Guide Zenith Controls. In Zenith Controls, the biometric governance cluster is anchored around ISO/IEC 27002:2022 control 5.34, Privacy and Protection of PII, supported by 5.17, Authentication Information, 8.5, Secure Authentication, 8.10, Information Deletion, 8.24, Use of Cryptography, and supplier controls such as 5.20, Addressing Information Security Within Supplier Agreements.

The goal is not to slow innovation. The goal is to make biometric authentication, identity proofing, workplace access and fraud prevention defensible, proportionate, secure and audit-ready.

Why biometric governance fails in mature companies

A company can have a strong security program and still have weak biometric governance.

Consider a SaaS provider launching facial verification for customer onboarding. The security team requires TLS, encrypted storage, administrator MFA, access controls and logging. The vendor says biometric templates are “irreversible.” Product documents fraud reduction as the business justification. Legal reviews the data processing agreement. Procurement checks the vendor box.

Then the auditor asks five questions:

1. Where is the biometric processing activity recorded?
2. What is the GDPR Article 6 lawful basis and, where applicable, Article 9 special-category condition?
3. Was a DPIA completed before processing began?
4. Can you prove biometric templates are deleted when the purpose expires?
5. What happens if the biometric vendor suffers a breach or changes subprocessors?

If the answers are scattered across email threads, procurement tickets, product notes and a vendor portal, the program is not audit-ready.

GDPR Article 5 requires lawfulness, fairness, transparency, purpose limitation, data minimisation, accuracy, storage limitation, integrity, confidentiality and accountability. Article 6 requires a lawful basis. Article 9 adds a stricter condition when biometric data is processed for the purpose of uniquely identifying a person. Article 4 definitions matter because processing includes collection, storage, use, disclosure, erasure and destruction. Pseudonymisation only helps when additional identifying information is separately protected with appropriate technical and organisational measures.

For non-EU companies, GDPR may still apply when they offer goods or services to individuals in the EU or monitor behaviour taking place in the EU. That makes biometric onboarding, fraud scoring, remote workforce access, call centre voice verification and customer identity proofing relevant far beyond Europe.

The governance failure is rarely one missing control. It is usually the absence of a connected evidence chain.

The Clarysec evidence chain for biometric PIMS

Clarysec treats biometric use cases as lifecycle-governed PII processing, not as standalone authentication features. The evidence chain begins before the system is purchased, configured or deployed.

In Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, the Controls in Action phase, Step 23, describes ISO/IEC 27002:2022 control 5.34 this way:

Names, addresses, IDs, health records, financial details, this data tells a story about real people. When it is mishandled, stolen, or misused, the consequences go far beyond compliance failures. It becomes a matter of personal violation, reputational damage, and legal exposure.

That message becomes sharper for biometric identifiers. A biometric template is not just login data. It is tied to physical or behavioural characteristics of a person and may be used to uniquely identify that person.

A defensible biometric governance workflow connects seven decisions to seven evidence types:

This is the difference between “we use biometrics securely” and “we can demonstrate biometric data governance under GDPR and ISO/IEC 27701:2025.”

Lawful basis is not a checkbox

Biometric projects often fail at the lawful basis stage because teams confuse security value with legal permission.

GDPR Article 6 requires a lawful basis such as consent, contract necessity, legal obligation, vital interests, public-interest task or legitimate interests where applicable. Article 9 generally prohibits processing biometric data for unique identification unless a specific exception applies, such as explicit consent, employment and social protection obligations under law, vital interests, substantial public interest, healthcare, public health, legal claims, or research and archiving with safeguards.

A biometric time clock for employees, fingerprint door access, facial onboarding and voice authentication may require different analysis. The same technology can produce different lawful basis outcomes depending on purpose, user choice, power imbalance, local law, proportionality and availability of non-biometric alternatives.

Clarysec’s Enterprise Data Protection and Privacy Policy Data Protection and Privacy Policy makes the baseline clear:

All processing shall be based on a valid legal ground (e.g., consent, contract, legal obligation).

From section “Policy Implementation Requirements,” policy clause 6.1.1.

For special-category data, Clarysec’s PII Processing Inventory and Lawful Basis Policy PII Processing Inventory and Lawful Basis Policy tightens the evidence requirement:

[Conditional] The Process Owner / Business Owner MUST record the special category processing condition in REG02 before processing special category PII.

From section “Controller purpose and lawful basis records,” policy clause 4.2.6.

For SMEs, Clarysec applies the same discipline in a simpler operating model. The SME Data Protection and Privacy Policy-sme Data Protection and Privacy Policy - SME states:

The Privacy Coordinator must maintain a register of all personal data processing activities, including data categories, purpose, lawful basis, and retention periods

From section “Governance Requirements,” policy clause 5.2.1.

And it adds:

The lawful basis (e.g., consent, contract, legal obligation) must be documented in the processing register

From section “Policy Implementation Requirements,” policy clause 6.1.2.

For biometric data governance, the processing register is not administrative housekeeping. It is the control point where the organization proves that the biometric use case is known, classified, justified and bounded.

DPIA first, rollout second

If there is one operating rule for biometric systems, it is simple: do not let procurement outrun the DPIA.

Biometric technologies often involve special-category PII, unique identification, systematic monitoring, fraud profiling, vulnerable data subjects, workplace imbalance, innovative technology or automated decision support. These are classic DPIA triggers. The DPIA is not only a privacy form. It is where the organization tests necessity, proportionality, alternatives, residual risk, safeguards, transparency, retention, supplier dependency and incident impact.

The Enterprise Data Protection and Privacy Policy requires formal analysis for high-risk systems:

Threat modeling and Data Protection Impact Assessments (DPIAs) are mandatory for high-risk processing systems.

From section “Policy Implementation Requirements,” policy clause 6.3.4.

The PIMS-specific Privacy Risk Assessment and DPIA Policy Privacy Risk Assessment and DPIA Policy is more direct:

[Controller] The Process Owner / Business Owner MUST refer processing involving large scale, systematic monitoring, profiling, automated decisions, special category PII, criminal conviction or offence data, vulnerable PII principals, innovative technology, or materially changed processing to the Privacy Lead / PIMS Manager in REG04 before processing begins.

From section “DPIA triggers and requirement determination,” policy clause 4.2.2.

A biometric DPIA should answer at least these questions:

• What biometric modality is processed, such as face, fingerprint, voice, iris, palm or behavioural pattern?
• Is biometric data used for unique identification or only local device verification?
• Is the organization a controller, processor, joint controller or subprocessor?
• What non-biometric alternative exists, and is it equally available?
• Is explicit consent required, and can it be freely given and withdrawn?
• Are raw biometric images, audio or templates stored?
• Where are templates stored, such as device secure enclave, central system or vendor cloud?
• Who can access templates, matching scores and biometric logs?
• What retention applies to enrolled users, rejected applicants, dormant accounts and terminated employees?
• How are deletion and backup expiry proven?
• What happens after false positives, false rejects or automated decision errors?
• What subprocessors are involved, and where is data processed?

At Finura, the DPIA became the central governance document. It did not cancel the launch. It turned a risky idea into a controlled implementation plan.

Explicit consent and the problem of forced convenience

Biometric programs often rely on consent because it feels intuitive. A person enrolls their face, voice or fingerprint, so surely they agreed. GDPR-grade consent must be specific, informed, unambiguous and freely given. When Article 9 explicit consent is required, the standard is higher.

In employment contexts, or where access to a necessary service depends on biometric enrollment, consent can be hard to defend unless a genuine alternative exists. A “convenient” biometric option becomes problematic if the alternative is hidden, slower, punitive or unavailable.

Clarysec’s Consent and Preference Management Policy Consent and Preference Management Policy provides the operational rule:

[Conditional] The Privacy Lead / PIMS Manager MUST mark consent as explicit in REG05 before processing begins where explicit consent is required for the selected purpose.

From section “Consent Request and Capture,” policy clause 4.2.5.

For biometric systems, REG05 should show:

• The exact consent wording.
• The biometric purpose, such as authentication, fraud prevention, access control or identity proofing.
• Whether consent is explicit.
• The date, channel and notice version.
• The withdrawal method.
• The non-biometric alternative.
• Whether refusal affects access to a service.
• The system trigger that stops processing after withdrawal.

The SME Data Protection and Privacy Policy-sme states:

Privacy by design and by default must be enforced in all new systems and services

From section “Governance Requirements,” policy clause 5.3.1.

In biometric systems, privacy by default means users are not silently enrolled, raw images are not retained without justification, biometric matching is not repurposed for analytics without reassessment, and alternatives are not buried behind support tickets.

Classify the full biometric data set

A biometric system cannot be governed if the biometric data is invisible in the asset inventory.

Clarysec’s Enterprise Data Classification and Labeling Policy Data Classification and Labeling Policy states:

Ensures that personal data subject to GDPR, DORA, or other privacy laws is classified correctly (e.g., tagged as “Confidential” or “Restricted”).

From section “Roles and Responsibilities,” policy clause 4.6.1.

For SMEs, the Data Classification and Labeling Policy-sme Data Classification and Labeling Policy - SME establishes the protection expectation:

All data classified as “Confidential” must receive the highest level of protection:

From section “Governance Requirements,” policy clause 5.2.

Classification should include more than the template database:

ISO/IEC 27001:2022 reinforces this discipline. Clauses 4.1 to 4.4 require the organization to determine context, interested-party requirements, ISMS scope and dependencies. Clauses 6.1.1 to 6.1.3 require risk assessment, risk treatment, Statement of Applicability and risk owner approval. If biometric systems affect confidentiality, integrity, availability or privacy, they belong in scope.

Security controls: encryption is only one layer

Biometric security requires layered control. Encryption matters, but it cannot fix weak lawful basis, excessive retention, uncontrolled vendor access or missing deletion evidence.

The Zenith Blueprint Controls in Action phase, Step 20, explains ISO/IEC 27002:2022 control 8.24, Use of Cryptography:

This control isn’t about simply “turning encryption on”; it’s about embedding cryptography into the organization’s design, policy, and lifecycle management.

Clarysec’s PII Security and Access Control Policy PII Security and Access Control Policy sets the PIMS rule for sensitive PII:

[Both] The Information Security Lead MUST define encryption or approved compensating protection requirements in REG12 before high-impact, sensitive or externally transmitted PII is stored, transmitted or made accessible.

From section “Encryption and secure storage,” policy clause 4.5.1.

REG12 should define biometric safeguards such as encryption at rest, encryption in transit, key ownership, key rotation, administrative MFA, access approval, segregation between identity data and biometric templates, logging of enrollment, match, export and deletion events, monitoring for unusual template access, secure deletion, and incident triggers for template compromise.

In Zenith Controls, ISO/IEC 27002:2022 control 5.17, Authentication Information, and 8.5, Secure Authentication, are especially important because biometrics are often embedded in authentication flows. The question is not only whether biometric login is secure. It is whether fallback methods, recovery flows, liveness detection, privileged access and biometric bypass paths are also controlled.

Retention, deletion and the biometric graveyard

Biometric systems often retain more data than teams realise: failed enrollments, old templates, dormant users, support bundles, archived databases, snapshots and backups. This creates the biometric graveyard problem. The data is no longer operationally useful, but it remains highly sensitive.

The Enterprise Data Protection and Privacy Policy states:

Personal information (PII) shall not be retained longer than necessary.

From section “Policy Implementation Requirements,” policy clause 6.5.1.

The Zenith Blueprint Controls in Action phase, Step 19, explains ISO/IEC 27002:2022 control 8.10, Information Deletion:

This control ensures that data is not kept longer than necessary, and when it is no longer needed, it must be securely and reliably deleted.

For biometric data, deletion must be designed into the system. Rules should cover consent withdrawal, account closure, employee termination, failed onboarding after appeal periods, dormant accounts, device replacement, vendor contract termination, legal holds, backup expiry and cryptographic erasure where appropriate.

Auditors will not accept “the vendor handles deletion” unless you can prove how, when, under which trigger and with what evidence.

Supplier governance: the vendor is part of the control environment

Most organizations do not build biometric engines from scratch. They rely on vendors for face matching, voice verification, liveness detection, access control hardware, SDKs, fraud scoring, cloud storage or support analytics. That makes supplier governance central.

The Enterprise Data Protection and Privacy Policy requires vendor reassessment:

Procurement and Legal and Compliance teams shall verify compliance with Article 28 of the GDPR and require annual reassessment of all high-risk vendors.

From section “Enforcement and Compliance,” policy clause 8.5.2.

The Processor, Subprocessor and Third-Party Privacy Management Policy Processor, Subprocessor and Third-Party Privacy Management Policy adds a PIMS approval gate:

[Conditional] The Data Protection Officer / Privacy Advisor MUST provide advice in REG04 or REG12 before approval of a relationship involving high residual privacy risk, special category PII, large-scale processing, systematic monitoring, or unresolved role classification.

From section “Due diligence and risk assessment,” policy clause 4.2.4.

The SME Third-Party and Supplier Security Policy-sme Third-Party and Supplier Security Policy - SME reminds smaller businesses that contracts are a control surface:

Contracts must include mandatory clauses covering:

From section “Governance Requirements,” policy clause 5.3.

The Zenith Blueprint Controls in Action phase, Step 23, describes ISO/IEC 27002:2022 control 5.20, Addressing Information Security Within Supplier Agreements:

Trust, when it comes to suppliers, cannot rest on assumptions. It must be codified.

Biometric contracts should cover processor role, purpose limitation, subprocessor approval, data location, encryption, access controls, incident notice, audit rights, deletion, return of data, support access, breach cooperation, model training restrictions and exit assistance.

For DORA-covered financial entities, biometric identity vendors may be ICT third-party service providers. DORA applies from 17 January 2025 and expects financial entities to manage ICT risk, incident reporting, operational resilience testing and ICT third-party risk. If biometric onboarding supports a critical or important function, supplier contracts, incident escalation, resilience testing and exit plans become operational resilience evidence as well as privacy evidence.

NIS2 also matters for many cloud, SaaS, managed service, managed security, digital infrastructure and ICT service management providers. Its risk-management expectations overlap strongly with ISO/IEC 27001:2022 and the biometric PIMS evidence chain.

Cross-compliance mapping for biometric data governance

Biometric governance should not create separate silos for GDPR, ISO/IEC 27701:2025, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 and COBIT 19. One evidence model can support many obligations.

For NIS2 entities, significant incidents may require early warning within 24 hours, incident notification within 72 hours and a final report within one month. If a biometric identity platform is disrupted or compromised, security, privacy and operational reporting workflows may all be triggered.

Audit lens: what reviewers will ask

Different auditors test biometric governance from different angles. Clarysec uses Zenith Controls to connect ISO/IEC 27002:2022 controls with privacy, authentication, supplier, encryption, deletion, incident and audit evidence.

Common audit findings include technical controls without governance decisions, Article 6 lawful basis without Article 9 condition, DPIAs completed after go-live, consent records without deletion triggers, vendor contracts without biometric-specific clauses, and incident playbooks that treat biometric template compromise like ordinary credential compromise.

A practical approval workflow for biometric onboarding

A Clarysec-guided organization handling facial verification for customer onboarding would follow a structured path:

1. Create a processing record in REG02.
2. Identify controller, processor and subprocessor roles.
3. Record the Article 6 lawful basis and Article 9 condition where biometric data is used for unique identification.
4. Record data categories such as selfie, document image, biometric template, liveness result, matching score, audit logs and support exports.
5. Trigger REG04 DPIA before implementation.
6. Assess necessity, proportionality and non-biometric alternatives.
7. Define explicit consent in REG05 where required.
8. Classify raw images and templates as Restricted or highest sensitivity.
9. Define REG12 security requirements for encryption, key management, access, logging, monitoring, export restrictions and deletion.
10. Review vendor due diligence, subprocessor list, hosting location, incident notice, audit rights and deletion certificate process.
11. Add retention rules for successful onboarding, failed onboarding, withdrawn consent, appeals, fraud investigations and backups.
12. Approve residual risk with named owners.
13. Store audit evidence in the PIMS evidence repository.
14. Review effectiveness after launch and after vendor changes.

This gives the CISO technical control evidence, the DPO privacy accountability, procurement contractual gates, product a launch path and auditors a traceable story.

Turn biometric risk into trust

Back at Finura, Maria did not cancel the biometric feature. She reset it. Product and engineering integrated PIMS requirements into the development lifecycle. The consent flow became explicit and separate. The vendor contract gained stronger deletion, audit, breach and subprocessor commitments. REG02, REG04, REG05 and REG12 became the evidence backbone. Cryptographic erasure was implemented for revoked data. The launch moved by one quarter, but it went live on a foundation of trust.

That is the point of biometric data governance. It does not ban innovation. It makes innovation defensible.

Your next steps are straightforward:

1. Inventory every biometric use case, including workplace access, customer onboarding, device authentication, fraud prevention and voice verification.
2. Classify the data and confirm whether it is used for unique identification.
3. Record lawful basis and any special-category condition in the processing register.
4. Run a DPIA before new or materially changed processing begins.
5. Validate explicit consent and alternatives where required.
6. Review supplier contracts and subprocessors.
7. Define encryption, access, logging, monitoring and deletion evidence.
8. Map the evidence to ISO/IEC 27701:2025, GDPR, ISO/IEC 27001:2022, NIS2, DORA, NIST CSF 2.0 and COBIT 19 expectations.

Clarysec can help you turn biometric data governance into an audit-ready PIMS workflow. Start with Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, validate your cross-framework mapping with Zenith Controls: The Cross-Compliance Guide Zenith Controls, and operationalize the evidence through Clarysec’s ISO/IEC 27701:2025 PIMS policy set, including the PII Processing Inventory and Lawful Basis Policy, Privacy Risk Assessment and DPIA Policy, Consent and Preference Management Policy, PII Security and Access Control Policy, and Processor, Subprocessor and Third-Party Privacy Management Policy.

Biometrics can strengthen security and improve user experience. Only governed biometrics earn lasting trust.