DPIAs for Recruitment Tools: What the ICO Actually Found Employers Getting Wrong

Summary: Article 35 of the UK GDPR requires a Data Protection Impact Assessment before processing that is likely to result in a high risk to individuals, and AI-based candidate screening meets that threshold. The ICO's own recruitment-sector audits found many employers had not completed a DPIA before implementing an AI tool, and where DPIAs existed, they frequently fell short of the minimum requirements. The gap between having a DPIA and having an adequate one is where most exposure sits.

Why recruitment screening triggers the requirement

Article 35 requires a DPIA where processing uses innovative technology and is likely to result in high risk. AI-based screening involves systematic evaluation of people based on automated processing, at scale, often affecting their access to employment. That combination is exactly what the DPIA requirement was built to catch.

Where processing also includes automated decision-making with legal or similarly significant effects, a DPIA is not optional or borderline. It is mandatory.

What the ICO's audits actually found

The ICO's recruitment-focused audits of AI providers and the employers using their tools generated close to 300 recommendations, which the regulator distilled into a small set of core findings.

DPIAs were often missing entirely. Some employers had implemented AI screening tools without completing a DPIA at all, despite the requirement attaching before processing begins.

Completed DPIAs frequently lacked a data flow map. Understanding what personal data moves where, and through which processing steps, is foundational to identifying risk. A DPIA without this is descriptive rather than analytical.

Less intrusive alternatives were often not considered. A DPIA is supposed to weigh whether the chosen approach is necessary and proportionate, including whether a less invasive method could achieve the same purpose. Skipping this step turns the DPIA into a formality rather than a genuine risk assessment.

Lawful basis was inconsistent across documents. The lawful basis stated in the DPIA frequently did not match what was stated in the privacy notice or the Record of Processing Activities. That inconsistency itself is a compliance gap, independent of which basis was actually correct.

What a DPIA for a screening tool needs to contain

A genuine data flow map. What data enters the tool, where it is processed, what happens to outputs, and where data is stored or shared, including any third-party processor involved.

An honest necessity and proportionality assessment, including whether a less intrusive method was considered and why it was rejected in favour of the automated approach.

A clearly stated, consistent lawful basis, matching across the DPIA, the privacy notice, and the Record of Processing Activities. Under Article 6, note that the newly available recognised legitimate interests basis at Article 6(1)(ea) is specifically excluded from use for significant automated decisions under Article 22B(4), so this basis cannot be relied on for solely automated screening decisions.

Special category data handling, where relevant, with the specific Article 9 condition identified if the tool processes or infers data such as racial or ethnic origin, or health information.

Fairness and bias testing, documented rather than asserted, addressing whether the tool has been tested for discriminatory outcomes and what the results were.

The controller and processor relationship with the vendor, made explicit. Where the AI provider is a processor, the DPIA should reflect the written instructions given to them and how compliance is monitored, not simply assume the vendor's own documentation covers it.

When to do it

The ICO's guidance is specific on timing: a DPIA should ideally be carried out at the procurement stage, before a tool is selected, not retrofitted after deployment. This lets the assessment actually influence which tool is chosen and how it is configured, rather than documenting risks in a tool already locked in.

A DPIA is not a one-time document either. It should be kept current as the processing and its impacts evolve, which in practice means revisiting it when a tool is materially updated or used in a new way.

Frequently asked questions

Does a vendor's own compliance documentation satisfy our DPIA requirement? No. As the data controller, the employer must complete its own DPIA covering the specific features used, the data processed, and the risks to candidates. Vendor documentation is an input, not a substitute.

Is a DPIA required even if a human makes the final decision? Likely yes, if the tool is used at scale to systematically evaluate candidates using innovative technology, regardless of whether the final call sits with a person. The high-risk threshold under Article 35 is about the processing, not solely about automated decision-making.

What is the most common single point of failure in employer DPIAs? Missing consideration of less intrusive alternatives, and a data flow map thin enough that it does not actually support risk analysis.

Do we need a new DPIA for every new hiring tool? Each tool with a materially different processing profile needs its own assessment, or at minimum a meaningful update to an existing one. Treating one DPIA as covering an entire, evolving stack tends to produce exactly the inconsistency the ICO flagged.

Can we rely on legitimate interests as our lawful basis? Ordinary legitimate interests under Article 6(1)(f) may be available depending on the processing. The newly introduced recognised legitimate interests basis at Article 6(1)(ea) is expressly unavailable for significant automated decisions under Article 22B(4).