GDPR and Identity Verification

The EU General Data Protection Regulation, or GDPR, has applied since 25 May 2018. It regulates the processing of personal data, meaning any information relating to an identified or identifiable person. Identity verification, often called IDV, commonly involves document images, names, addresses, dates of birth, selfies, device data and fraud signals, so it is usually within scope.

The GDPR applies to organisations established in the European Economic Area, or EEA, and can also apply to organisations outside it that offer goods or services to people in the EEA or monitor their behaviour. It does not prescribe one approved verification method. Instead, it requires organisations to justify and limit each processing activity.

Identity data and biometric data

Identity document details, document numbers, photographs and contact data are personal data. They are not automatically special-category data under Article 9. However, biometric data is special-category data when it is processed for the purpose of uniquely identifying a natural person. This can include facial templates or face-matching data derived from a selfie and an identity-document portrait.

A plain photograph is not necessarily special-category biometric data in every context. The purpose and technical processing matter. If an organisation uses facial features to determine whether a selfie belongs to the document holder, it should generally assess the activity as biometric processing for unique identification and apply Article 9 safeguards. Data revealing racial or ethnic origin may also arise incidentally in images, but that does not by itself make routine document verification an Article 9 activity.

Lawful basis and consent

Every processing operation needs a lawful basis under Article 6. Common bases in IDV include compliance with a legal obligation, such as anti-money-laundering or age-assurance requirements; performance of a contract; and legitimate interests, subject to a documented balancing test. A company cannot treat its commercial preference for collecting more identity data as a lawful basis.

Where special-category biometric data is processed, an additional Article 9 condition is required. Explicit consent is one possible condition, but it must be freely given, specific, informed and easy to withdraw. It may be unsuitable where a person has no realistic choice or where verification is required by law. Other conditions can include substantial public interest grounded in EU or Member State law, or processing necessary for legal claims, depending on the facts and applicable national law.

• Consent should not be bundled into general terms or used as a substitute for a required Article 6 basis.
• Controllers should record the purpose, Article 6 basis and, where relevant, Article 9 condition for each verification flow.
• Children, vulnerable users and situations involving a power imbalance require particular care when relying on consent.

Minimisation, retention and security

The GDPR requires data minimisation: collect data that is adequate, relevant and limited to what is necessary for a defined purpose. A service that only needs to confirm that a customer is over 18 may not need to retain a full passport image or document number. Organisations should consider attribute-based responses, redaction, extraction without image retention and configurable vendor settings.

There is no universal GDPR retention period for identity data. The storage-limitation principle requires deletion or anonymisation when data is no longer necessary. Financial-crime, tax, immigration or sector-specific rules may require longer retention, often under national law. Organisations should set documented retention schedules for raw images, extracted data, biometric templates, audit logs and fraud records separately, rather than keeping all verification data for the same period.

When a DPIA is needed

A data protection impact assessment, or DPIA, is required before processing that is likely to result in a high risk to individuals' rights and freedoms. IDV deployments often meet this threshold where they involve large-scale special-category data, systematic profiling or fraud scoring, new technology, vulnerable people, or systematic monitoring. National data protection authorities may publish additional lists of processing requiring a DPIA.

A useful DPIA maps data flows, purposes, recipients, retention, security controls and cross-border transfers. It assesses necessity and proportionality, identifies risks such as identity theft, exclusion or biometric misuse, and records mitigations. If high residual risk remains after mitigation, the controller must consult its supervisory authority before starting the processing.

Practical impact on vendors and customers

The business deciding why and how people are verified is usually the controller. An IDV vendor acting only on documented instructions is generally a processor. In practice, roles can be mixed: a vendor may be an independent controller for product security, service improvement or its own fraud network. Contracts and privacy notices should describe these roles accurately rather than relying on labels.

Customers should conduct vendor due diligence on encryption, access controls, sub-processors, breach response, deletion tools, data-location options and international transfer mechanisms. Processor contracts must meet Article 28 requirements, including instructions, confidentiality, security, assistance with data-subject rights and audit provisions. Vendors need to support controller obligations, including access, deletion and objection requests where applicable, while preserving records that a legal obligation requires them to retain.

For identity verification, GDPR compliance is not a one-time consent screen. It is a continuing obligation to justify each data use, reduce collection, protect sensitive information and delete it on schedule.