Talk to usTry the demo

Buyer Guide: Evaluating an Identity Verification Provider on Security and Privacy

Evaluation and benchmarks

For: Security reviewer shortlisting an identity verification provider

A checklist for the security reviewer who shortlists a provider: roles, the information security standard, the data processing agreement, subprocessors, erasure, and the testing evidence to ask for.

For information; not legal advice.

You are shortlisting identity verification providers, and the questionnaire on your desk has two hundred rows. This guide shrinks the security and privacy part of it to the questions that decide the outcome, and it names the primary text and the kind of evidence behind each one. It is written for the security reviewer who owns the questionnaire, with the data protection officer and the procurement lead as the colleagues who will take the privacy and contract rows, and it answers one question: what should a provider be able to show you before you let it process the identity documents and face images of your customers?

The guide names no vendor and ranks none. It treats every provider statement, including the statements of the Company that publishes this page, as a claim to be matched with evidence. The privacy provisions come from the General Data Protection Regulation (GDPR) and the guidelines of the European Data Protection Board; the information security standard comes from its publisher; the testing evidence comes from the US federal identity guidelines, the US federal face recognition evaluation programme and a testing laboratory's public explanation of its method. Your own jurisdiction may differ, and your counsel decides what applies to you.

Start from evidence, not from assertions

The EDPB guidelines on controllers and processors give the buyer's side of the problem in one clause. They say that the guarantees "provided" by the processor are those that the processor is able to demonstrate to the satisfaction of the controller, because those are the only ones that can effectively be taken into account when assessing compliance. They add that this often requires an exchange of documentation, and they name examples: a privacy policy, terms of service, a record of processing activities, a records management policy, an information security policy, reports of external data protection audits and recognised international certificates. The assessment is a form of risk assessment that depends on the type of processing entrusted to the processor, and the guidelines say they cannot provide an exhaustive list of what a processor must show. So the working method is to sort every answer into three grades: a statement, a document, and independent evidence. A statement is a sentence in a questionnaire or on a web page. A document is something you can read and file, such as a contract annex or a policy with a version. Independent evidence is a result produced by someone who is not the provider, with a method you can read. Record the grade next to each answer, and do not let a statement stand in for a document.

The obligation does not end when the contract is signed. The EDPB describes the duty to use only processors providing sufficient guarantees as a continuous one, and it says the controller should, at appropriate intervals, verify the processor's guarantees, including through audits and inspections where appropriate. Plan the review as a cycle, not as a gate.

Roles and the nature of the data

Who is controller, who is processor

Everything below assumes that you, the customer, decide why and how the personal data of your users is processed, and that the provider processes it on your behalf. That is the processor relationship, and it is the one the GDPR regulates in Article 28. Article 28 starts with a duty on you: where processing is to be carried out on behalf of a controller, the controller shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures. Check the role in the provider's own documents. A provider that describes itself as a controller for the same data, for example for the improvement of its own models, changes the contract you need, and the Regulation says a processor that determines the purposes and means of processing is considered a controller for that processing. Ask the question directly: for which purposes, if any, does the provider process the data of your users for its own account?

Biometric data is a special category

A face image compared with a document portrait is biometric data when it is used to identify a person. The Regulation lists biometric data for the purpose of uniquely identifying a natural person among the special categories of personal data whose processing is prohibited unless one of the listed conditions applies. Article 35 requires a data protection impact assessment, prior to the processing, where a type of processing is likely to result in a high risk, and it names processing on a large scale of special categories of data as a case in which an assessment is required. Your impact assessment will need facts from the provider: the data flow, the locations, the subprocessors, the retention and the deletion mechanism. The questions in this guide are therefore also the input to a document that you may have to write anyway. For the way the Regulation and the UK regime treat biometric data in a verification flow, see the article on biometric data under the GDPR and the UK GDPR.

Information security management

What the standard is and what a certificate says

The international information-security management standard published as ISO/IEC 27001:2022 defines requirements that an information security management system must meet. Its publisher describes it as giving organisations of any size guidance for establishing, implementing, maintaining and continually improving such a system. It preserves the confidentiality, integrity and availability of information by applying a risk management process. Conformity, in the publisher's words, means that an organisation has put in place a system to manage risks related to the security of data owned or handled by the company.

The publisher is also clear about three limits that matter to a buyer. First, organisations can decide whether they want to go through an external process at all: some implement the standard for the practices it contains, and others also want an external certificate to reassure customers. Second, a certificate from a body whose own competence has been independently confirmed by a recognised oversight body may bring an additional layer of confidence. Third, the standard should always be referred to with its full reference, which includes the edition year. From these three points follow concrete questions.

  • Does the provider hold an external certificate, or does it say only that it follows the standard?
  • Who issued the certificate, for which legal entity, with which scope statement, and until when?
  • Does the scope cover the service you will use, and the people, sites and systems that handle your data?
  • Does the answer give the edition year of the standard, or does it say only "ISO"?
  • Can the provider say whether the issuing body's own competence was confirmed by a recognised oversight body?

Read the certificate itself, and do not rely on a logo. The publisher notes that anyone who wants to use a logo to show that the standard is met should contact the body that issued the certificate. Treat the standard as a baseline for the management system, and ask separately for the technical controls that protect your data.

Technical measures: use the security article as the frame

The GDPR gives the technical frame in Article 32. It requires the controller and the processor to implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk, including as appropriate the pseudonymisation and encryption of personal data, the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services, the ability to restore availability and access in a timely manner after an incident, and a process for regularly testing, assessing and evaluating the effectiveness of the measures. Turn each clause into a question about the service.

  • Encryption: what is encrypted in transit and at rest, who holds the keys, and can the callbacks to your systems be encrypted or stripped of identity fields?
  • Access: which roles exist, how are administrator actions logged, and can you restrict API use to a list of addresses?
  • Resilience and recovery: what happens to your sessions if a component fails, and how fast can service and data be restored?
  • Testing: when was the last independent security test, who performed it, and can you read a summary of the findings and their remediation?

The OWASP list of API security risks gives a second checklist for a service that you integrate through an API. It names broken object level authorization, broken authentication, broken function level authorization, improper inventory management and unsafe consumption of APIs among the ten risks. Ask how the provider tests for each, and how it keeps an inventory of its API versions, because the list notes that a proper inventory of hosts and deployed API versions mitigates problems such as deprecated versions and exposed debug endpoints.

The data processing agreement

What the processor article requires the contract to contain

The Regulation requires that processing by a processor is governed by a contract or other legal act that is binding on the processor, and that sets out the subject-matter and duration of the processing, its nature and purpose, the type of personal data and the categories of data subjects, and the obligations and rights of the controller. The contract must stipulate that the processor does eight things, and the list works as a review checklist.

  1. Processes the personal data only on documented instructions from the controller, including with regard to transfers to a third country.
  2. Ensures that persons authorised to process the data have committed themselves to confidentiality.
  3. Takes all measures required under Article 32.
  4. Respects the conditions for engaging another processor.
  5. Assists the controller with requests to exercise data subject rights.
  6. Assists the controller with the obligations on security, breach notification and impact assessment.
  7. At the choice of the controller, deletes or returns all the personal data after the end of the services, and deletes existing copies unless law requires storage.
  8. Makes available all information necessary to demonstrate compliance, and allows for and contributes to audits, including inspections, by the controller or another auditor mandated by the controller.

The contract has to be in writing, including in electronic form. The EDPB goes further and recommends that the necessary signatures are included, to avoid difficulties in demonstrating that the contract is in force. Ask whether the provider's standard agreement already contains the eight points, and mark every point that is missing or that is phrased more weakly.

Points that the standard text leaves to the negotiation

The EDPB guidelines identify details that the Regulation leaves open and that the contract should settle. On the audit right, the contract should say how often and how information flows, and the controller keeps the final choice of the type of audit; the guidelines add that even where an auditor is proposed by the processor, the controller retains the right to contest the scope, methodology and results. The guidelines list the information that the processor should provide on request: the functioning of the systems, security measures, how data retention requirements are met, data location, transfers, who has access, the recipients and the subprocessors used. That list is a ready-made annex for your own contract: ask for each item in writing.

Subprocessors and transfers

The processor shall not engage another processor without prior specific or general written authorisation of the controller. In the case of general authorisation, the processor shall inform the controller of any intended changes concerning the addition or replacement of other processors, giving the controller the opportunity to object. The EDPB explains what you need to make the decision: a list of intended subprocessors that includes, for each, its locations, what it will be doing and proof of the safeguards it has implemented.

The guidelines also describe the practical difference between the two forms of authorisation. The main difference lies in the meaning given to silence: under general authorisation, the controller's failure to object within the set timeframe can be interpreted as authorisation. In both cases the contract should include the timeframe for approval or objection and the practical steps that follow an objection, for example the time within which the parties decide whether the processing should be terminated.

Ask these questions, and put the answers in the contract annex.

  • Is the current list of subprocessors available, with the location and role of each?
  • Is the authorisation specific or general, and how much notice of a change do you get?
  • What is the objection procedure, and what happens to your service if you object?
  • Does each subprocessor carry the same obligations by contract?

On the last point, the Regulation says the same data protection obligations must be imposed on the other processor, and that where it fails to fulfil them the initial processor remains fully liable to the controller. The EDPB adds that the whole chain of processing activities needs to be regulated by written agreements.

Transfers deserve their own line. The general principle of the Regulation is that a transfer of personal data to a third country or an international organisation takes place only if the conditions of the transfer chapter are complied with by the controller and the processor, including for onward transfers. The EDPB points out that if the controller's instructions do not allow transfers to third countries, the processor will not be allowed to assign the processing to a subprocessor in a third country, nor to have the data processed in one of its own divisions outside the Union. So the data location question is not only "where is the primary database"; it is also where support staff, backups, logs and analytics subprocessors sit.

Incidents

The Regulation requires the processor to notify the controller without undue delay after becoming aware of a personal data breach. The processor's duty to notify the controller is not tied to a risk test in the text. The controller, in turn, has to notify the supervisory authority without undue delay and where feasible not later than 72 hours after having become aware of it, unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. Where the notification is not made within 72 hours, it must be accompanied by reasons for the delay. That deadline runs from the controller's awareness, so the interval you allow the provider is part of your own deadline. Write a concrete notification time into the agreement and name the contact. Ask also what the provider's incident record shows: how it classifies incidents, how it tests its response, and whether it will share a summary of any incident that touched your data.

Retention and erasure

Three provisions fit together. The storage limitation principle requires that personal data be kept in a form which permits identification of data subjects for no longer than is necessary for the purposes of the processing. The right to erasure obliges the controller to erase personal data without undue delay where one of the listed grounds applies, among them that the data are no longer necessary for the purposes for which they were collected, that the data subject withdraws the consent on which the processing is based and there is no other legal ground for the processing, or that the data have been unlawfully processed. The right does not apply to the extent that processing is necessary, among other listed cases, for compliance with a legal obligation that requires the processing, or for the establishment, exercise or defence of legal claims. And the processor must, at the choice of the controller, delete or return the personal data when the services end.

The EDPB gives detail on the last point. If the controller chooses deletion, the processor should ensure that the deletion is performed in a secure manner, and should confirm to the controller that the deletion has been completed within an agreed timescale and in an agreed manner. The design guidelines add that the controller should have systematic procedures for deletion or anonymisation embedded in the processing, that deletion of certain data should be automated, and that the controller should test whether deleted data can be recovered. The UK regulator's erasure guidance addresses backups, which is where many promises fail: the data may remain in the backup environment for a period until it is overwritten, and the key is to put it beyond use.

Questions for the provider

  • Is there a self-service way to erase the data of one verification, or of every verification of one user, and is it an interface you can call from your own systems?
  • Is the retention period a setting that you control, and what happens at its end?
  • Does an erasure produce a confirmation event and a journal that records what was destroyed, when, why and by whom?
  • What happens to backups, logs and subprocessor copies, and how long do they live?
  • What survives an erasure, such as a verdict or an identifier, and does it contain no personal data?
  • At the end of the contract, is deletion or return your choice, and when do you receive written confirmation?

Test the answers in the pilot. Create a verification, erase it, and read back what remains. A provider that supports a documented erase call lets you do this in an afternoon, and the result is better evidence than any paragraph in a questionnaire.

The US federal identity guideline is a useful second reference for biometric data in particular. It requires providers to have a documented and publicly available deletion process and a default retention period for all biometric information, consistent with the regulations of the regions and sectors served. It recommends that providers support the deletion of all of a subscriber's biometric information on the subscriber's request, and it requires a provider that does not to document its justification publicly. That is a requirement of a US federal programme and not of your jurisdiction, but it shows what a mature provider can be expected to publish.

Testing evidence

Security and privacy answers tell you how the provider protects data. Testing evidence tells you whether the verification itself works, and a procurement file that lacks it is incomplete. Three kinds of evidence matter, and each has a typical way of being misread.

Attack detection for liveness

Presentation attack detection testing follows part 3 of its standards series, and the laboratory whose public explanation is used here describes three kinds of test: a subsystem test that evaluates attack detection only, a data capture test that evaluates the coupled attack and quality checks, and a full system test that evaluates the biometric comparison of the whole subsystem. For subsystem evaluations the reported metrics are the attack presentation classification error rate, the bona fide presentation classification error rate and the associated non-response rates. The explanation also says that the configuration of the product is recorded before any attack is applied, and that the version is referenced in the confirmation letter, as is the exact device configuration, because the capture device affects the results. The laboratory states that its testing shows whether a solution conforms with the testing and reporting requirements of the standard, which by itself does not translate to a formal approval of the vendor's product. Letters are posted by written vendor consent.

Turn these facts into questions.

  • Which of the three test types was run, and does it match how you will use the product?
  • Does the letter name the version and the device configuration that you will run in production, or an older one?
  • What error limits applied, and what were the measured rates, including the rate at which genuine users were rejected?
  • Does the provider describe the result as conformance with a test method, or does it claim an approval that the laboratory itself does not claim?

The US federal identity guideline sets a concrete bar for remote biometric collection: attack detection that meets an impostor attack presentation accept rate below 0.07, and tests that conform to the 2023 edition of part 3 of the standards series. It also requires providers to have their biometric recognition and attack detection algorithms periodically tested by independent entities, such as laboratories or research institutions, for their performance characteristics, including performance across demographic groups. A separate technical specification addresses a different threat: biometric data injection attacks. Its scope covers definitions of the attack, use cases on the main biometric system hardware for enrolment and verification, and guidance on creating a test plan for the evaluation of injection attack detection, while presentation attack testing is outside it. So a presentation attack letter does not answer a question about injection, and you should ask which of the two the evidence covers. For a longer treatment of how to read a laboratory letter, see the article on presentation attack detection testing.

Face comparison accuracy

The US federal evaluation programme for one-to-one verification publishes a table of false non-match rates over several datasets. The page defines the false non-match rate as the proportion of mated comparisons below a threshold set to achieve a specified false match rate, and the false match rate as the proportion of impostor comparisons at or above that threshold. One algorithm from each developer appears in the summary table, and the table is ordered initially by rank on one dataset at one false match rate. A buyer who sees a rank quoted by a provider should therefore ask what was ranked and how.

  • Which algorithm and which version was evaluated, and is it the one that runs in the service you will buy?
  • On which dataset, at which false match rate, and what were the other datasets in the same table?
  • Is the figure presented as reported by the vendor, and does the provider avoid presenting it as an endorsement by the programme?
  • How does the accuracy on the evaluation images relate to the capture conditions of your users?

The US federal identity guideline adds a demographic requirement: biometric verification technologies must provide performance for applicants of different demographic types that is no more than 25 % worse than the performance for the overall population, with a fixed threshold. It also requires providers to make the results of their algorithm performance and operational tests publicly available, which may be in summary form. Ask for the equivalent for your user population, and ask whether the provider has measured it. The article on how to read a face recognition evaluation walks through the table.

Document validation

The same guideline sets performance measures for automated validation of physical documents: a document false acceptance rate of 0.1 or less and a document false rejection rate of 0.1 or less. It recommends that providers have their evidence validation technology periodically tested by independent entities. Ask for the rates measured on your own mix of document types, since a figure measured on a different mix says little about yours. The article on automated document validation explains the two rates.

Grading the answers

When the file is complete, grade each answer rather than counting them. An item with independent evidence and a document outweighs ten statements. An item with only a statement is a risk to be priced or to be closed in the contract, not a pass. Keep a separate list of the items that the provider could not answer, and ask whether the gap is a missing document or a missing control. A provider that says plainly that an item is not available is giving you better information than one that answers every row with the same sentence.

A compact version of the checklist follows, in the order of this guide.

  1. Role and purposes: processor only, or also controller for any purpose?
  2. Impact assessment input: data flow, locations, subprocessors, retention, deletion.
  3. Management system: issuer, entity, scope, validity and edition year of the standard.
  4. Technical measures: encryption, access, recovery, independent security testing.
  5. Agreement: all eight contract points of the processor article, in writing, with signatures.
  6. Audit right: how, how often, who chooses the auditor.
  7. Subprocessors: list, locations, authorisation form, notice, objection.
  8. Transfers: where data, support, logs and backups sit.
  9. Incidents: notification time and contact.
  10. Retention and erasure: interface, journal, backups, confirmation.
  11. Attack detection evidence: test type, version, device, error limits.
  12. Injection evidence: separate from presentation attack evidence.
  13. Face comparison evidence: algorithm, dataset, threshold, population.
  14. Document validation rates on your own mix.

Where this sits in a verification flow

The Company's own statements are a worked example of the grading above, and they should be read as claims and matched with documents. The trust center states that the Company holds ISO/IEC 27001:2022 and gives the holder, issuer, validity and scope, which are the items of the management system questions. Erasure endpoints, a callback option that omits names, document data and images from the session event while keeping the session identifier, which links to the session, and encryption of the callback body give the integrating team controls for deletion and data minimisation, and retention in days is a setting of each scenario. The check results of database checks stay in the callback whatever that option says. Access controls include an IP allowlist, roles, a login log and token expiry, and callback bodies can be encrypted. Read the trust center and the data protection overview, and ask us for any checklist item that the public pages do not answer.

To see how these steps look in your own scenario, contact the team.

Sources

All sources were fetched on 27 October 2026.

Ready to talk?

Tell us what you are building and we will help you plan the integration.

Talk to us