A Data Protection Impact Assessment for an Identity Verification Flow: Article 35, WP248 and Two Regulators' Lists

A product team wants to add selfie-to-document matching to onboarding, and the data protection officer asks one question: do we need an impact assessment before this goes live? The answer comes from three layers of text that point the same way for most verification flows but say it in different words: the Regulation itself, the guidelines of the European data protection authorities, and the lists that each national authority publishes. This article reads the three layers in order, then goes through the assessment part by part, with the questions a verification flow raises at each part.

For information; not legal advice.

Two existing articles touch the subject. Biometric data under GDPR and UK GDPR mentions the assessment in a few sentences, as one of the documents that sit next to the lawful basis and the special category condition. Retention and erasure of identity data in verification callbacks covers one of the mitigations an assessment would record. This article is a guide to preparing the assessment: when it is required, who does what, what each part must contain, what to do with a high residual risk, and when to redo it. A sibling on international transfers of biometric data covers the transfer question that the assessment must answer in its own words.

Layer one: what Article 35 says

Article 35(1) requires an assessment where a type of processing, in particular using new technologies and taking into account its nature, scope, context and purposes, is likely to result in a high risk to the rights and freedoms of natural persons. The controller must carry it out prior to the processing, and a single assessment may address a set of similar processing operations that present similar high risks. Article 35(2) adds that the controller shall seek the advice of the data protection officer, where designated.

Article 35(3) lists three cases in which an assessment is in particular required. The first is a systematic and extensive evaluation of personal aspects based on automated processing, including profiling, on which decisions are based that produce legal effects or similarly significantly affect the person. The second is processing on a large scale of special categories of data referred to in Article 9(1), or of data on criminal convictions and offences. The third is a systematic monitoring of a publicly accessible area on a large scale. The Article 29 Working Party stresses, in the guidelines described below, that the words "in particular" make this list non-exhaustive.

Two readings follow for a verification flow, and both are ours rather than statements of the texts. Biometric data processed to identify a person uniquely are special category data under Article 9(1), so Article 35(3)(b) is engaged once the processing is on a large scale. And a flow that ends in an automated refusal to open an account looks like the decisions that Article 35(3)(a) and Article 22 are concerned with, which is a reason to examine it even if the decision is made partly by people. Article 22(1) gives the data subject the right not to be subject to a decision based solely on automated processing that produces legal effects or similarly significantly affects them, and Article 22(3) requires, where the exceptions for contract or explicit consent are used, at least the right to obtain human intervention, to express a point of view and to contest the decision.

Article 35(10) offers a way out for some processing: where processing under Article 6(1)(c) or (e) has a legal basis in Union or Member State law that regulates the specific operation, and an assessment was carried out as part of a general impact assessment when that law was adopted, paragraphs 1 to 7 do not apply unless Member States deem an assessment necessary. The guidelines note that an assessment made when legislation is drafted may need a specific one before the actual processing, because the adopted text can differ and the technical details may be missing. A business that verifies identity because an anti-money-laundering rule requires it should not assume this exemption applies; checking it is a question for counsel.

Layer two: the nine criteria of WP248

The guidelines on impact assessments of the Article 29 Working Party, reference WP 248 rev.01, were adopted on 4 April 2017 and last revised and adopted on 4 October 2017. The ICO's guidance says they have been endorsed by the European Data Protection Board. The guidelines set out nine criteria that indicate likely high risk: evaluation or scoring; automated decision-making with legal or similar significant effect; systematic monitoring; sensitive data or data of a highly personal nature; data processed on a large scale; matching or combining datasets; data concerning vulnerable data subjects; innovative use or application of new technological or organisational solutions; and processing that in itself prevents data subjects from exercising a right or using a service or a contract. In most cases, the guidelines say, a processing that meets two criteria would require an assessment, and in some cases one criterion is enough. A controller that concludes that processing meeting the criteria is still not likely to result in a high risk should justify and document the reasons, and record the views of the data protection officer.

Three entries in the guidelines read close to a verification flow. Under sensitive data, the guidelines describe the special categories of Article 9, and under innovative use they give the example of combining fingerprint and face recognition for improved physical access control. Under the last criterion they say the processing operations covered include those that aim at allowing, modifying or refusing access to a service or entry into a contract, and give the example of a bank screening customers against a credit reference database to decide whether to offer a loan. Under matching or combining datasets, the guidelines describe datasets from two or more operations performed for different purposes or by different controllers, combined in a way that would exceed the reasonable expectations of the data subject.

Putting these side by side, a flow that captures a selfie and a document, compares the faces and decides whether the customer may proceed meets, on our count, the criterion of sensitive data where the comparison is used to identify a person uniquely, and the criterion of refusal of access to a service, and, if the result is combined with screening against other lists, matching of datasets. Whether it meets the criterion of innovative use is conditional: the guidelines tie novelty to the achieved state of technological knowledge and to the particular application, so established face matching does not become innovative merely because it uses biometrics, and the sensitive-data and service-access criteria stand as separate grounds. Whether the flow also meets the large-scale and vulnerable-person criteria depends on the customer base. The guidelines treat the number of data subjects, the volume of data, the duration and the geographical extent as the factors for large scale.

A useful warning comes from reading a second source. The Irish Data Protection Commission's page on impact assessments sets out the criteria too, and its list includes "Data transfer across borders outside the European Union (recital 116)", plus a recommendation that assessments be re-assessed after three years. Neither appears in the nine criteria or the text of the guidelines of 4 October 2017. The page appears to reproduce an earlier stage of the guidance; that is our inference, not a statement on the page. The practical lesson is to cite the dated text you rely on, and to treat cross-border transfers as a risk factor in any case, because the guidelines themselves list international transfers among the elements whose change can alter the risk.

Layer three: the national lists

Article 35(4) requires each supervisory authority to establish and make public a list of the kind of processing operations that are subject to the requirement, and to communicate it to the Board. Article 35(5) allows a second list of operations for which no assessment is required. Under Article 35(6) the authority applies the consistency mechanism first where the processing is related to offering goods or services, or monitoring behaviour, in several Member States, or may substantially affect the movement of personal data within the Union. The guidelines add that the processing of any type of biometric data could be considered relevant for the development of such a list.

The ICO list. The Information Commissioner's list is described as the processing operations for which the ICO requires a DPIA, based on the European guidelines, and it says it complements and further specifies them. Its entry for biometric data reads: "Any processing of biometric data for the purpose of uniquely identifying an individual." The entry adds that a DPIA is required for any intended processing involving biometric data for that purpose when combined with any other criterion from the guidelines, and lists as examples facial recognition systems, workplace access systems and identity verification, and access control or identity verification for hardware or applications, including voice, fingerprint and facial recognition. A second entry is closer to onboarding. Under "denial of service" the list names decisions about an individual's access to a product, service, opportunity or benefit which are based to any extent on automated decision-making, including profiling, or which involve the processing of special category data, with examples of credit checks, mortgage or insurance applications and other pre-check processes related to contracts. The ICO's page on when to do an assessment shows the same two entries in summary form, and it adds that the ICO list contains ten operations beyond the three in Article 35(3). Reading the two entries together, a customer-onboarding verification that identifies a person by face and decides access to a service is within the wording of both; the examples in the biometric entry are access-control settings, and the closest example in the second entry is a pre-check before a contract.

The CNIL list. The French authority's list is a table of types of processing, the criteria of the European guidelines that each meets, and examples. Its biometric entry, in French, is: "Traitements de données biométriques aux fins d'identifier une personne physique de manière unique parmi lesquelles figurent des personnes dites « vulnérables » (élèves, personnes âgées, patients, demandeurs d'asile, etc.)". In our translation: processing of biometric data for the purpose of uniquely identifying a natural person, among whom there are persons said to be vulnerable, such as pupils, elderly people, patients or asylum seekers. The criteria it lists against the entry are the collection of sensitive data and vulnerable persons, and its examples are fingerprint-based checking of patient identity and access to a school canteen by hand-contour recognition. The contrast with the ICO entry is worth noticing: the CNIL entry is framed by the presence of vulnerable persons among the data subjects, so a reader who stopped at this list would not conclude that all biometric identification triggers it. The sensible reading is that each list is one input; the criteria of the guidelines and Article 35(1) still apply, and the CNIL's entry does not limit them.

Which list applies. The list that binds a controller is that of the authority competent for it, and a business with customers in several countries should check the lists of the authorities concerned; the Regulation provides the consistency mechanism so that lists about cross-border services are aligned. The UK has its own regime. The version of Article 35 on legislation.gov.uk keeps the same structure, and in paragraphs 4 and 5 it names "the Commission" as the body that publishes the lists, with the amendments marked on the page. The ICO's guidance pages carry a notice that they are under review because of changes made by the Data (Use and Access) Act.

Who does what

The controller is responsible for ensuring that the assessment is carried out. Someone inside or outside the organisation may carry it out, but the controller remains ultimately accountable. The ICO says the same: an assessment can be outsourced, and a processor can be asked to do it where it performs the operation, but the controller remains responsible. The controller must seek the advice of the data protection officer where one is designated, and the guidelines say the advice and the decisions taken should be documented within the assessment. The ICO says that if the controller does not follow the officer's advice, it should record its reasons.

The provider of a verification service is usually a processor. Article 28(3)(f) requires the processing contract to provide that the processor assists the controller in ensuring compliance with the obligations pursuant to Articles 32 to 36, taking into account the nature of processing and the information available to the processor. Article 36 is the prior consultation article, so assistance with the assessment is part of what the contract must cover. The guidelines add two useful points for product relationships. An assessment can be useful for the data protection impact of a technology product used by different controllers, and the controller deploying it remains obliged to carry out its own assessment for the specific implementation, which can be informed by one prepared by the product provider. Each product provider or processor should share useful information without compromising secrets or disclosing vulnerabilities. For a buyer this means a request for the provider's own documentation is reasonable, and also that it never replaces the buyer's assessment of its own deployment; the buyer guide on provider security and privacy lists what to ask.

Writing the five parts

Article 35(7) sets the minimum content: a systematic description of the processing and its purposes, including where applicable the legitimate interest pursued; an assessment of necessity and proportionality; an assessment of the risks to the rights and freedoms of data subjects; and the measures envisaged to address the risks, including safeguards, security measures and mechanisms to demonstrate compliance. The ICO turns this into seven steps: identify the need, describe the processing, consider consultation, assess necessity and proportionality, identify and assess risks, identify measures to mitigate the risks, and sign off and record outcomes. The guidelines add a checklist in their second annex of criteria for an acceptable assessment; it also asks that interested parties be involved. For the process and the structure of a report, the international standard is number 29134 of ISO and IEC, in its second edition of May 2023, whose abstract says it gives guidelines for a process on privacy impact assessments and a structure and content of a PIA report.

Part one: describe the processing. The ICO asks for the nature, scope, context and purposes of the processing. Nature covers how the data are collected, stored and used, who has access, who receives them, whether processors are used, retention periods, security measures and the use of new technologies. Scope covers the nature, volume and sensitivity of the data, the extent and frequency of processing, its duration, the number of data subjects and the geographical area. Context covers the source of the data, the relationship with the individuals, how far they control their data and expect the processing, whether children or vulnerable people are included, and previous experience with this type of processing. Purpose covers the reason for processing, the intended outcome for individuals and the expected benefits. The guidelines add, in the annex, that the assets on which personal data rely (hardware, software, networks, people, paper) be identified.

For a verification flow, the description works well when built from the session itself, step by step, and the table below is our suggestion for what to collect.

The seven rows are the places where the nature, scope and context questions get their answers. The sibling article on callbacks covers the last two rows in detail.

Part two: necessity and proportionality. The ICO asks whether the plans help to achieve the purpose and whether there is another reasonable way to achieve the same result. It lists the compliance measures to describe here: the lawful basis, how function creep is prevented, how data quality and minimisation are ensured, how privacy information is provided, how individuals' rights are supported, measures to ensure processors comply, and safeguards for international transfers. The annex of the guidelines gives the matching list by article: purpose limitation, lawfulness, minimisation, limited storage, the information duties of Articles 12 to 14, the rights of access, portability, rectification, erasure, objection and restriction, the relationship with processors under Article 28, the safeguards for international transfers under Chapter V, and prior consultation under Article 36. For a face match the "other reasonable way" question has a concrete form, which the sibling article on biometric data covers: is there a non-biometric route for the customer who declines, and is it documented?

Part three: risks. The ICO asks the controller to consider the impact on individuals and any harm, whether physical, emotional or material, and lists what to look at: inability to exercise rights, inability to access services or opportunities, loss of control over the use of personal data, discrimination, identity theft or fraud, financial loss, reputational damage, physical harm, loss of confidentiality, re-identification of pseudonymised data, or any other significant economic or social disadvantage. It adds an assessment of the security risks, including illegitimate access to, modification of or loss of personal data. On the threshold it says that harm does not have to be inevitable to qualify as a risk; it must be more than remote; and a significant possibility of very serious harm, or a high probability of widespread but more minor harm, may each count as high risk. The guidelines define a risk as a scenario describing an event and its consequences, estimated in terms of severity and likelihood. They also say the assessment takes the perspective of the data subject, as opposed to risk management focused on the organisation.

Applying that list to a verification flow gives scenarios such as the following. They are examples of the method, not a register for any real system.

• A leak of document images and selfies; the harms to look at are identity theft or fraud, financial loss and loss of confidentiality.
• A wrongful rejection of a genuine customer; the harms are inability to access services and, if the errors are not evenly spread, discrimination.
• Use of the captured images for a purpose the customer did not expect, such as training a model; the harms are loss of control over personal data, and function creep is named by the ICO as something to prevent.
• Retention beyond the purpose; the harm is a larger store of sensitive data for an attacker to reach.
• Access to readable images from a country whose authorities can compel disclosure; the transfer sibling article sets out how the assessment of that risk proceeds.
• A callback that carries more personal data than the receiving system needs; the harm is a second place where the data must be protected.

A single worked row shows the columns that a completed register needs. The ratings and names are placeholders chosen to show the layout; they are not a finding about any flow.

The data protection officer advises; the controller decides and accepts the residual risk, and where the officer's advice is not followed, the record says why.

Part four: measures. For each risk the ICO asks the controller to record its source and then to consider options for reducing it: not collecting certain data, reducing the scope, reducing retention periods, taking additional technological security measures, training staff, anonymising or pseudonymising where possible, writing internal guidance, using a different technology, putting data-sharing agreements into place, changing privacy notices, offering individuals an opt-out where appropriate, and implementing new systems to help individuals exercise their rights. It asks for a record of whether each measure would reduce or eliminate the risk.

Part five: consultation. Article 35(9) requires the controller to seek the views of data subjects or their representatives where appropriate. The guidelines say that consent to processing is obviously not a way of seeking the views of data subjects, that the controller should document the reasons if its final decision differs from those views, and that it should document its justification for not seeking them. The ICO says the views should be sought unless there is a good reason not to, and gives as acceptable reasons that consultation would compromise commercial confidentiality, undermine security, or be disproportionate or impracticable. For a flow aimed at a customer base that does not yet exist, the ICO suggests a more general public consultation or targeted research, such as market research with a certain demographic or contacting relevant consumer groups.

Sign-off, residual risk and prior consultation

At the end the ICO asks the controller to record the additional measures planned, whether each risk has been eliminated, reduced or accepted, the overall residual risk, and whether the regulator must be consulted. It says not every risk must be eliminated, but if a high risk remains the controller needs to consult the ICO before going ahead. Article 36(1) is the corresponding rule in the Regulation: the controller consults the supervisory authority prior to processing where the assessment indicates that the processing would result in a high risk in the absence of measures taken to mitigate it. Under Article 36(2), if the authority considers the intended processing would infringe the Regulation, it provides written advice within up to eight weeks of receiving the request, a period that may be extended by six weeks taking into account the complexity of the processing. Article 36(3) lists what the controller provides: the respective responsibilities of the controller, joint controllers and processors; the purposes and means; the measures and safeguards; the contact details of the data protection officer; the assessment itself; and any other information requested.

The guidelines give examples of unacceptable high residual risk: significant or even irreversible consequences which the data subjects may not overcome, such as an illegitimate access resulting in a threat to life, a layoff or financial jeopardy, and cases where it seems obvious the risk will occur, for example where a well-known vulnerability is not patched. They add that the obligations to retain a record of the assessment and to update it remain regardless of whether consultation is needed. On publication, the guidelines say it is not a legal requirement but the controller should consider publishing at least a summary or a conclusion, and that a published version need not reveal security risks or trade secrets.

Review: when to redo it

Article 35(11) requires the controller, where necessary, to review whether processing is performed in accordance with the assessment, at least when there is a change of the risk represented by the processing operations. The guidelines call carrying out an assessment a continual process, not a one-time exercise, and give changes that can alter the risk: a new technology coming into use, personal data used for a different purpose, a change in the context, and also certain changes that lower the risk. Their footnote names the elements to look at, which include recipients, data combinations, security measures and international transfers.

For a verification flow the following events are, in our reading, review triggers: a new matching or liveness component; a new class of document or customer; a new processor or a processor's change of location; a change in what the callback carries; a change in retention; a new use of the stored data; and a change in the law of a country to which data are transferred.

Questions to put to a provider

• Does the provider hold an assessment or equivalent documentation for the service itself, and will it share it under confidentiality, as the guidelines contemplate?
• Which of the controller's questions in the description table can the provider answer from its own records: capture, comparison, retention, deletion, and what each callback carries?
• Does the processing contract commit the provider to assist with assessments and prior consultation, as Article 28(3)(f) requires?
• What are the provider's sub-processors and their locations, so that transfers can be assessed?
• Which errors does the provider measure, and can it give the controller the data needed to assess wrongful rejections by group?
• What notice does the provider give of a change of component, location or sub-processor, so that the review trigger is not missed?

What a platform can contribute

A NeuroVision integration has controls that serve retention and erasure decisions: retention in days is a setting of each scenario, erasure endpoints and an erasure confirmation webhook are available, and a callback can omit personal data. These controls are inputs to the measures part of an assessment; the assessment itself remains the controller's. To discuss the facts you need for your own assessment, contact the team.

Sources

All sources were fetched on 28 October 2026.

• Regulation (EU) 2016/679 (General Data Protection Regulation), Official Journal text, Publications Office of the European Union.
• Guidelines on Data Protection Impact Assessment (DPIA) and determining whether processing is "likely to result in a high risk" for the purposes of Regulation 2016/679, WP 248 rev.01, Article 29 Data Protection Working Party, adopted 4 April 2017, last revised and adopted 4 October 2017.
• How do we do a DPIA?, Information Commissioner's Office, United Kingdom.
• When do we need to do a DPIA?, Information Commissioner's Office, United Kingdom.
• Examples of processing "likely to result in high risk", Information Commissioner's Office, United Kingdom.
• Liste des types d'opérations de traitement pour lesquelles une analyse d'impact relative à la protection des données est requise, Commission nationale de l'informatique et des libertés, France.
• Data Protection Impact Assessments, Data Protection Commission, Ireland.
• UK GDPR, Article 35, legislation.gov.uk, The National Archives, United Kingdom.
• Information technology, Security techniques, Guidelines for privacy impact assessment, standard 29134 of 2023, standard page with abstract, Edition 2, May 2023, International Organization for Standardization.