An Equality Impact Assessment asks whether a policy is a defensible decision. A Data Protection Impact Assessment (DPIA) asks whether the processing that policy triggers is a defensible use of people’s data. The two sit side by side: the EqIA handles the equality dimension, the DPIA handles the privacy dimension, and for a trans-inclusion policy that touches gender data, name or gender-marker changes, or records that reveal someone’s gender history, both are needed. A policy can clear the equality test and still fail the data-protection test — and under the UK GDPR, a DPIA is not optional where the processing is likely to result in a high risk to people’s rights and freedoms.
This explainer sets out when the law makes a DPIA mandatory, what it must contain, and how it links to your EqIA. It is the “what and when” companion to the DPIA prompt set, which gives you the drafting questions; here we cover the legal triggers and the privacy-by-design controls a completed DPIA has to evidence.
When a DPIA is legally required
Article 35 of the UK GDPR makes a DPIA mandatory where processing is “likely to result in a high risk to the rights and freedoms of natural persons.” The Regulation names three triggers directly, and the ICO’s Article 35(4) list adds more. The triggers most likely to bite on trans-inclusion processing are:
- Large-scale processing of special-category data. Gender reassignment data — transition status, gender identity declaration, name-change history connected to gender, Gender Recognition Certificate (GRC) status — is treated as Article 9 special-category data by ICO practice. Sex data is likewise treated as special-category where it could reveal or be used to infer a protected characteristic, as the EHRC Services Code makes clear.
- Systematic and extensive evaluation of personal aspects. Monitoring, profiling, or analytics that systematically assesses staff or service users on the basis of gender data crosses this threshold.
- Vulnerable data subjects. Employees in power-asymmetric contexts, people accessing safeguarding or health services, and anyone whose gender history could expose them to distress or harassment if disclosed, all fall within the ICO’s vulnerability factor.
- Combining datasets. Merging HR records with facilities access logs, payroll with pension data, or monitoring data with complaint records can create inference vectors that neither dataset carries alone.
A DPIA is not triggered by a single field in a form. It is triggered by the processing — the whole flow of collecting, storing, accessing, using, sharing, retaining, and disposing of data — when that flow engages special-category data at scale or on vulnerable people. If your policy introduces a name and pronoun change process, a gender-marker update, a monitoring exercise, or a records-handling change for transitioning staff, ask whether the processing crosses the threshold. If more than one trigger applies, the mandate is clear.
A practical signal: if your EqIA has identified that the policy engages gender reassignment or sex as protected characteristics, the DPIA is almost always needed alongside it, because the same data that makes the equality analysis live makes the data-protection analysis live.
What a DPIA must cover
A DPIA is a thinking process, not a form. Article 35(7) sets the minimum a completed DPIA must contain, and the ICO’s DPIA guidance expects the reasoning to be shown on the record.
A lawful basis for each operation, and a Schedule 1 condition for the special-category data
Every processing operation needs an Article 6 lawful basis — consent, legitimate interests, legal obligation, and so on — identified per operation, not as a blanket for the whole policy. Where the data is special-category, an Article 9(2) condition must also apply, and under the Data Protection Act 2018 a Schedule 1 condition is usually required on top. For equality-of-opportunity monitoring, Schedule 1 Part 2 paragraph 8 is the condition most EqIA and DPIA work runs under. For employment-side processing, Schedule 1 Part 1 applies. Name each condition for each operation; do not assume one will cover everything.
A necessity and proportionality test
For each data category, the test is whether the same purpose could be achieved with less data, less sensitive data, or shorter retention. This is the data-minimisation principle (Article 5(1)(c)) in operational form. “We always collect this” is a failure, not a justification. The necessity analysis for sex, gender, and GRC data should be applied at each lifecycle stage — most stages have no lawful purpose to hold it. Where the Gender Pay Gap reporting guidance requires birth-sex recording for GRC holders, that data must be firewalled from operational reuse: a legally-mandated collection does not license repurposing.
The risks to data subjects
The DPIA has to name what could go wrong. For trans-inclusion processing the risks are specific:
- Outing. Inference disclosure — a name-change history plus role continuity revealing trans status to someone who would otherwise not know — is the typical accidental-breach vector. The ICO’s inference doctrine treats inferred special-category data as special-category data, with the same safeguards applying.
- Criminal disclosure. Under Gender Recognition Act 2004 section 22, disclosing protected information about a GRC holder’s gender history obtained in an official capacity is a criminal offence unless an exception applies. Unauthorised onward disclosure is not merely a governance lapse; it is an offence.
- Dignity and trust harm. Distress, harassment, or loss of confidence in the employer or service follows from a breach, even one that does not reach the criminal threshold.
- Re-identification. Small-headcount reporting, combined datasets, and legacy records can all re-identify someone a published figure was meant to anonymise.
The mitigations — privacy by design
For each identified risk, the DPIA records the existing safeguards, the residual risk, and the additional safeguards available. The controls that matter most for trans-inclusion processing are:
- Need-to-know access. Role-based access, not blanket access; logged and reviewable. GRC-holder records should be segregated from the general personnel record where possible, with single-person or very-narrow access.
- Legacy records handling. Pre-transition records carry inference risk long after the event. The DPIA should address how historical name, sex-marker, and role data is stored, who can see it, and whether it can be pseudonymised or separated.
- Retention tied to purpose. Retention periods must be reasoned against the purpose, not inherited from a default schedule. The DPIA records the period, the deletion trigger, and who is responsible for verifying deletion actually happens.
- Purpose-limitation firewall. Data collected for one purpose — monitoring, pay-gap reporting, a complaint investigation — must not be silently reused for another. The DPIA should name the purpose and flag that reuse outside it requires a fresh assessment.
- Subject access request handling. When the data subject requests their own data, GRC status is theirs to know; when a third party requests it, GRA section 22 restrictions apply. The DPIA should record how SARs are handled.
If residual risk remains high after available safeguards, Article 36 makes prior consultation with the ICO mandatory before the processing continues. That is not a step a self-serve template can take for you; it is a referral to specialist advice.
Who owns it, and when it is reviewed
A DPIA needs a named owner, a review date, and a trigger for early review — the same governance discipline as an EqIA. Where the organisation has a Data Protection Officer, Article 35(2) requires the DPO to be consulted on the DPIA and their advice recorded. Where no DPO is required (some charities use the exemption under DPA 2018), equivalent senior accountability must be engaged on the record.
A DPIA is assessed against a specific version of the processing. When the policy is redrafted, the monitoring exercise changes, or a new dataset is combined, the DPIA re-runs from the top — it is not amended in the margin. Review triggers should include a change in processing, a breach, a change in law (the post-For Women Scotland data-architecture questions are a live example), or a complaint. An undated, unowned DPIA cannot be defended as current.
The DPIA–EqIA link
The DPIA and the EqIA are not alternatives and not duplicates. The EqIA assesses impact on people with protected characteristics under the Equality Act 2010; the DPIA assesses risk to the same people’s data under the UK GDPR and DPA 2018. They cross-reference: the equality-of-opportunity purpose that justifies collecting monitoring data under Schedule 1 paragraph 8 is the same purpose the EqIA is testing, and the proportionality reasoning in both should be consistent. A policy that an EqIA has found to be a proportionate equality decision can still founder if the DPIA shows the data handling is not necessary, not minimised, or not adequately safeguarded. Run them together; do not let one substitute for the other.
Take this further
- The DPIA prompt set gives you the drafting questions — what data, why, who sees it, how long it is kept — to work through before you collect or use gender-history information.
- The EqIA/DPIA Wizard carries your processing description through a structured six-stage DPIA and exports a dated record for your data-protection file.
- The managing privacy, dignity and safeguarding resource covers the front-line handling dimension that a DPIA’s controls must operationalise.
- Where gender-history data is sensitive, contested, or likely to be tested by the ICO, a data subject access request, or a tribunal, specialist consulting review of the completed DPIA adds the forensic depth a self-serve tool cannot — the three preflight gates (lawful basis, necessity, DPO consultation), the inference-risk assessment, and the defensibility position that survives challenge.
This resource provides general information and does not constitute legal advice. It explains when a DPIA is required and what it must cover; it does not draft one for you. Take specialist advice where your processing warrants it.