An identity verification system cannot be declared GDPR compliant simply because its provider has a privacy policy, an ISO certificate, or a European data centre. Compliance depends on the full processing operation: what data is collected, why it is needed, how identity is checked, where information is stored, which suppliers can access it, and what happens when the verification is complete.

For technical evaluation, the practical question is not whether a product is “GDPR certified.” The GDPR does not provide a universal product certification for identity verification. The more useful question is whether the proposed system can support a documented, lawful, proportionate, and secure processing model for the specific use case.

Start with the data flow, not the sales claim

Map the verification journey from capture to deletion. A typical process may include an identity document image, name and date of birth, facial image, selfie video, liveness signals, device information, IP address, location data, audit logs, and a verification result. These elements do not necessarily have the same legal status or retention requirement.

Biometric data used to uniquely identify a person is treated as a special category of personal data under the GDPR. That creates an additional compliance requirement beyond the ordinary lawful basis for processing personal data. A system that compares a selfie with a passport photograph may therefore require both a valid Article 6 lawful basis and an applicable Article 9 condition.

Ask the provider to show a current data-flow diagram that identifies:

• every category of personal and biometric data collected;
• the system component that processes each category;
• storage locations and transfer destinations;
• sub-processors and support access;
• the point at which raw images and biometric templates are deleted;
• which outputs are returned to the customer.

If the supplier cannot explain the flow in operational terms, its GDPR position is difficult to evaluate, regardless of how polished its compliance documentation appears.

Check necessity, proportionality, and the lawful basis

The organisation using the system remains responsible for defining a lawful purpose. “Fraud prevention” or “security” may describe a legitimate objective, but they do not automatically justify every method of identity verification. The assessment should explain why document checks, biometric matching, liveness detection, or continuous monitoring are necessary for the particular risk.

Data minimisation is a technical design requirement as well as a legal principle. If the customer only needs a pass/fail result, retaining a full identity document and selfie indefinitely is difficult to justify. Consider whether the system can return limited attributes, such as “over the required age” or “identity verified,” instead of exposing the underlying document data to every internal application.

Consent also needs careful treatment. It must be informed, specific, freely given, and capable of being withdrawn. In settings where people have no realistic alternative, consent may not be an appropriate basis. A provider should not decide this on the customer’s behalf; the controller must connect the lawful basis to the real relationship, purpose, and user journey.

Assess transparency and user control

A compliant verification experience should tell people what is happening before collection takes place. The privacy information should identify the controller, explain the purpose, describe the categories of data involved, state retention periods or the criteria used to set them, identify relevant recipients, and explain international transfers and individual rights.

Transparency becomes more important when artificial intelligence is used for face comparison, document authenticity checks, or fraud scoring. Users should be able to understand that automated analysis is involved and what role the result plays. If a verification failure can produce a legal or similarly significant effect, assess whether rules on automated decision-making apply and whether meaningful human review is available.

Do not accept “human review” as a label without examining the workflow. A reviewer should have access to sufficient evidence, authority to overturn an automated result, and a documented process for handling disputed decisions. The system should also record why a result was changed.

Review the vendor contract and accountability evidence

Most identity verification providers process data on behalf of another organisation, but the contractual relationship must reflect the actual allocation of decisions. The data processing agreement should cover processing instructions, confidentiality, security, assistance with data subject rights, breach support, deletion or return of data, audits, and sub-processor controls.

Technical evaluators should request evidence rather than relying on broad statements. Useful evidence includes:

• a completed technical and organisational measures document;
• penetration testing or independent security assessment summaries;
• access-control and privileged-account procedures;
• encryption practices for transmission and storage;
• logging, incident response, and breach notification procedures;
• backup deletion and disaster-recovery controls;
• the current sub-processor and hosting-region list;
• support-access restrictions and administrator audit trails.

Security claims should be connected to a specific control. “Bank-grade security” is not an assessment criterion. The relevant questions are who can access raw biometric material, whether access is time-limited, how keys are managed, and whether the customer can configure retention and deletion.

Pay close attention to international transfers and retention

European hosting does not by itself settle the transfer question. A provider may use support teams, cloud services, analytics tools, or backup infrastructure outside the European Economic Area. Review where data can be accessed, not only where the primary database is located.

The supplier should describe the transfer mechanism, supplementary safeguards where relevant, and the countries involved. Procurement documents should also distinguish between production data, diagnostic logs, training data, and service telemetry. A provider’s right to reuse customer images or biometric data for model training is a separate issue and should not be hidden inside general service terms.

Retention should be tied to a defined purpose and event. For example, raw document images may be needed during an investigation but not throughout the customer relationship. Ask whether deletion is automatic, whether it covers replicas and backups, and whether a verification token can be retained instead of the original biometric evidence.

Confirm that a DPIA and rights workflow are practical

Identity verification involving biometrics, systematic monitoring, or large-scale processing may require a Data Protection Impact Assessment. The organisation deploying the system should be able to describe the risks, safeguards, residual risk, and decision to proceed. The vendor can provide technical input, but it cannot complete the controller’s accountability assessment.

Test the operational handling of access, correction, deletion, restriction, objection, and portability requests. Some rights may interact with fraud-prevention or legal-retention obligations, but the process still needs a clear response path. A system that cannot locate a person’s records, distinguish identity data from security logs, or delete data selectively creates a significant governance problem.

A practical procurement decision

Before approval, require the supplier to answer the same use-case-specific questions in writing. Record the purpose, lawful bases, data categories, retention rules, transfer locations, vendor roles, automated-decision logic, security controls, and rights procedures. Then compare providers against evidence, not against generic “GDPR-ready” language.

The strongest identity verification GDPR compliant solution is therefore not necessarily the one with the most biometric features. It is the one whose data collection is proportionate, whose processing can be explained, whose controls can be configured and audited, and whose lifecycle ends when the stated purpose ends. In high-security environments, technical performance and privacy governance should be evaluated together; a system that verifies accurately but cannot control or account for the underlying data remains a weak procurement choice.