Data protection impact assessment: when a DPIA is required

The question usually arrives late. The system is chosen, the contract is signed, the rollout date is in the diary, and somebody asks whether a data protection impact assessment was done. One of the two possible answers is that it is now too late, because the law wants the assessment finished before the processing starts.

Below: the statutory trigger, the regulator's list underneath it, the four HR cases that reach it most often, what the assessment must contain, who you must consult, and when you cannot proceed without going to the regulator first. General information about the law in the United Kingdom, not legal advice.

A DPIA is a process with stages, named participants, recorded advice and a sign-off, which is the shape of work that disappears into email. See how New Dynamics workflows let you define the stages, assign the participants and build in the approvals, so a process you may have to evidence leaves a record of itself.

The rule: prior to the processing

Article 35(1) of the UK GDPR is the whole trigger:

"Where a type of processing in particular using new technologies, and taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall, prior to the processing, carry out an assessment of the impact of the envisaged processing operations on the protection of personal data."

Two phrases settle most arguments. "Prior to the processing" sets the deadline before the first record is collected, not at go-live. "A type of processing" means you screen the kind of activity, not prove harm.

The Information Commissioner's Office states on what a DPIA is that "failure to carry out a DPIA when required may leave you open to enforcement action, including a fine of up to £8.7 million, or 2% global annual turnover if higher".

The three cases the statute settles itself

Article 35(3) names three types of processing that require a DPIA in every case:

• "(a) a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing, including profiling, and on which decisions are based that produce legal effects concerning the natural person or similarly significantly affect the natural person";
• "(b) processing on a large scale of special categories of data referred to in Article 9(1), or of personal data relating to criminal convictions and offences referred to in Article 10"; and
• "(c) a systematic monitoring of a publicly accessible area on a large scale."

The regulator's list adds ten more

Article 35(4) requires the regulator to publish a list of processing operations needing a DPIA. The ICO's list of ten is the one to screen against, and the entries differ in strength. Some require an assessment alone; others, in the ICO's words, require one "only when they occur in combination with one of the other items, or any of the criteria in the European Guidelines".

Four entries reach HR, and the ICO's own examples name the workplace twice:

• Denial of service, which needs no combination: "Decisions about an individual's access to a product, service, opportunity or benefit that is based to any extent on automated decision-making (including profiling) or involves the processing of special category data."
• Large-scale profiling, which also needs no combination: "any profiling of individuals on a large scale".
• Biometrics: "Any processing of biometric data for the purpose of uniquely identifying an individual", with "Workplace access systems/identity verification" among the listed applications.
• Tracking: "Processing which involves tracking an individual's geolocation or behaviour", with "Processing location data of employees" among the listed applications.

The four HR cases, checked against the list

Monitoring workers

The ICO's employment guidance on monitoring workers is direct: "You must carry out a DPIA before undertaking any processing likely to cause high risk to workers' and other people's interests." Its own examples of high risk processing are "processing biometric data of workers", "keystroke monitoring of workers", "monitoring that may result in financial loss (such as performance management)" and "using profiling or special category data to decide on access to services". The same page sets the order of events: if you go ahead, "you must provide information about it to your workers before you begin monitoring".

Large-scale special category data

Article 35(3)(b) makes this automatic, and the catch is "large scale", which the UK GDPR does not define. The ICO says to weigh the number of individuals, the volume, variety and duration of the data and the geographical extent, and gives as an example "a hospital (but not an individual doctor) processing patient data". In HR the Article 9 data is usually health: occupational health reports, absence records carrying diagnoses, adjustment records. Trade union membership and data revealing racial or ethnic origin sit in the same category. No headcount threshold is published.

Automated decision making in recruitment

Two routes reach the same answer. Article 35(3)(a) catches systematic and extensive automated evaluation on which significant decisions rest, and the denial of service entry catches decisions about access to an "opportunity" based to any extent on automated decision making. A sift that ranks or rejects candidates with no person looking sits inside both.

One qualification. The ICO's examples under denial of service are credit checks, mortgage or insurance applications and "other pre-check processes related to contracts". Recruitment is not among them, so the fit comes from the wording rather than a worked example. Our post on AI recruiting tools covers the wider duties an automated sift brings. Article 22 itself was replaced by new Articles 22A to 22D by section 80(1) of the Data (Use and Access) Act 2025, in force for the remaining purposes from 5 February 2026, but the Article 35(3)(a) trigger was not touched.

Biometric clocking in and out

Two ICO pages read differently here. The Article 35(4) list treats biometric identification as needing a DPIA "when combined with any other criterion" from the European guidelines. The employment guidance on biometric data for time and access control states it with no condition: "Yes, you must carry out a DPIA whenever you intend to process biometric data to uniquely identify a worker. This is because processing biometric data is considered high risk. You must complete your DPIA before starting the processing."

Act on the employment guidance. It is the specific guidance for this situation, it uses "must", which that guidance reserves for legislative requirements, and workplace biometrics involve systematic monitoring and special category data anyway, so the combination the list asks for is present. It also says what the document must show: where a reasonable less intrusive option exists, "you should be able to justify why you don't use this method. You must document all of this in your DPIA."

What the assessment must contain

Article 35(7) sets the minimum and reads as a contents page. "The assessment shall contain at least":

• "(a) a systematic description of the envisaged processing operations and the purposes of the processing, including, where applicable, the legitimate interest pursued by the controller";
• "(b) an assessment of the necessity and proportionality of the processing operations in relation to the purposes";
• "(c) an assessment of the risks to the rights and freedoms of data subjects referred to in paragraph 1"; and
• "(d) the measures envisaged to address the risks, including safeguards, security measures and mechanisms to ensure the protection of personal data and to demonstrate compliance with this Regulation taking into account the rights and legitimate interests of data subjects and other persons concerned."

The ICO's guidance on how to do a DPIA reads paragraph (a) as nature, scope, context and purposes, and wants retention periods, security measures, who has access, the processors involved and "which screening criteria you flagged as likely high risk".

Who you have to consult

The data protection officer, if you have one. Article 35(2) is short: "The controller shall seek the advice of the data protection officer, where designated, when carrying out a data protection impact assessment." Article 39(1)(c) puts the matching duty on the officer, "to provide advice where requested as regards the data protection impact assessment and monitor its performance pursuant to Article 35". On monitoring, the ICO says you "must seek and record their independent advice on the outcome of the DPIA before making any final decisions". Decide against that advice and you record why. Article 37(1) says who needs an officer at all.

The people affected, where appropriate. Article 35(9) provides that "where appropriate, the controller shall seek the views of data subjects or their representatives on the intended processing, without prejudice to the protection of commercial or public interests or the security of processing operations". The ICO makes that a default: "You should seek and document the views of individuals (or their representatives) unless there is a good reason not to", and where existing employees are covered you "should design a consultation process to seek the views of those particular individuals, or their representatives". Information security staff, processors and relevant experts come in too, and drafting can be handed to a supplier, but "You can outsource your DPIA, but you remain responsible for it."

When you must consult the regulator

Article 36(1) sets the test: the controller must consult the regulator "prior to processing where a data protection impact assessment under Article 35 indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk". The ICO reads that as a residual risk test and marks the limit: "If your DPIA identified a high risk but you have done things to reduce the risk so it is no longer high, you need not consult us."

Where it is required, you cannot proceed until it has happened. The ICO's page on consulting the ICO says what to send, including the purposes and methods of the intended processing, the safeguards, your DPO's contact details and the DPIA itself. It will say within 10 days whether the submission is accepted, and where it advises under that process "we will get back to you within eight weeks of receipt of your DPIA. In complex cases, we can extend this to a maximum of 14 weeks". The outcome need not be advice: the ICO may issue an official warning, and "if we have more significant concerns, we may impose a limitation or ban on your intended processing".

Publishing it, and how long to keep it

There is no duty to publish a DPIA. The ICO treats publication as a choice that helps you: "To aid transparency and accountability, it is good practice to publish your DPIA", with redaction or a summary where full disclosure would reveal commercially sensitive information or undermine security.

No official source we could open sets a retention period, and we will not invent one. The ICO's instruction is different: "You need to keep your DPIA under review. You may need to repeat it if there is a substantial change to the nature, scope, context or purposes of your processing." Article 35(11) requires a review "at least when there is a change of the risk represented by processing operations". Keep it while the processing runs, and keep the superseded versions.

What the Data (Use and Access) Act 2025 changed

It did not remove the DPIA duty and it did not abolish the data protection officer. What changed is who the article points at. On legislation.gov.uk the only amendment recorded to Article 35 since the Brexit corrections of 31 December 2020 is one word substituted on 30 September 2026 by the Data (Use and Access) Act 2025 (Consequential Amendments and Transitional Provision) Regulations 2026, Schedule 3 paragraph 41. Articles 36, 37 and 39 carry the same substitution on the same date, so each now reads "the Commission". The commencement regulations setting that date also brought into force section 118 of the Act, the "abolition of the office of Information Commissioner", and section 119, the "transfer of functions to the Information Commission". The only change to the DPO provision itself was inserting "and tribunals" into Article 37(1)(a) on 20 August 2025, and legislation.gov.uk records no outstanding effects for Articles 35, 36, 37 or 39.

Every ICO DPIA page opened for this post carries the notice "Due to changes made by the Data (Use and Access) Act, this guidance is under review and may be subject to change." The statutory text is settled; the guidance wording may be reissued, so read the live page.

A template is not the assessment

The ICO publishes a sample DPIA template and you may use it, but the form is not the obligation: "You don't have to use this template. You can make your own to suit your needs, or use an existing project-management method, as long as it covers all the key elements of the process." What cannot be skipped is the work the form holds: the screening decision and its reasons, the description of the processing, the DPO's advice, the views of the people affected, the risks, a mitigation with an owner against each, the residual risk, the sign-off and the review date.

Frequently asked questions

When is a data protection impact assessment required?

Whenever a type of processing is likely to result in a high risk to people's rights and freedoms, and in every case for the three types in Article 35(3) of the UK GDPR: systematic and extensive automated evaluation on which significant decisions are based, large-scale processing of special category or criminal offence data, and systematic monitoring of a publicly accessible area on a large scale. The ICO publishes ten further categories under Article 35(4), and the assessment must be done before the processing starts.

Is a DPIA a legal requirement or just good practice?

A legal requirement where the trigger is met, because Article 35(1) says the controller shall carry out the assessment. The ICO says failing to do one when required may leave you open to enforcement action, including a fine of up to £8.7 million, or 2% of global annual turnover if higher. Where the trigger is not met, the ICO still calls it best practice and advises documenting any decision not to.

Do we need a DPIA before introducing employee monitoring?

The ICO's employment guidance says you must carry one out before any processing likely to cause high risk to workers' and other people's interests, and names keystroke monitoring, workers' biometric data and monitoring that may result in financial loss, such as performance management, among its examples. If you go ahead, you must tell workers before the monitoring begins.

Do we need a DPIA for fingerprint or facial recognition clocking in?

Yes. The ICO's guidance on biometric data for time and access control says you must carry out a DPIA whenever you intend to process biometric data to uniquely identify a worker, because that processing is considered high risk, and that it must be completed before the processing starts. It also expects the document to justify why a less intrusive option, such as a swipe card, is inadequate.

Who has to be consulted on a DPIA?

Your data protection officer, if you have designated one, under Article 35(2), with their advice recorded. Under Article 35(9) you must seek the views of the people affected or their representatives where appropriate, which for an employer usually means staff or their representatives. Information security staff, processors and relevant experts should also be involved, and outsourcing the drafting moves none of the responsibility.

Does a DPIA have to be published, and how long do we keep it?

Publication is not required. The ICO calls it good practice for transparency and accountability, and suggests redacting sensitive detail or publishing a summary instead. No official source sets a retention period. What the ICO does require is that the assessment is kept under review and repeated where there is a substantial change to the nature, scope, context or purposes of the processing.

Your next step: screen what is already in flight

1. List the HR processing you plan to start or change in the next six months: monitoring tooling, a clocking system, an automated sift, a diversity dashboard, a case management rollout.
2. Screen each one against Article 35(3) and the ICO's ten categories, and write down the answer with its reason. A decision that no DPIA is needed is itself a document you may have to produce.
3. For anything that triggers, book the assessment before the implementation date rather than beside it, and name who signs it off.
4. Ask your data protection officer for advice in writing at the start, decide how you will consult staff or their representatives, and put a review date in the finished DPIA.

For the policies and records underneath all of this, read and download our employee data protection guide. The guide is free to read, and the PDF uses our short download form.

Want the stages, participants and approvals of a process like this to leave a record you can show a regulator? Book a New Dynamics demo and bring the project you are least sure about. You can also email contact@new-dynamics.com.