DPIA for IT Projects: A Security Team's Guide to Article 35
When a DPIA is mandatory under GDPR Article 35, the WP248 criteria, what the assessment must contain, and how security teams contribute to it.
A data protection impact assessment (DPIA) is where GDPR compliance and system design meet. Article 35 requires one before starting processing that is likely to result in a high risk to individuals, which in an IT context means new platforms, large migrations, monitoring tools, analytics pipelines and anything involving sensitive data at scale. The DPO usually owns the document, but the substance depends heavily on architects and security engineers: what data flows where, who can access it, what can go wrong and which controls reduce the risk. This guide explains when a DPIA is required, what it must contain, and how security teams can contribute effectively without turning it into a copy of the corporate risk register.
When a DPIA is required
The Article 35 triggers
Article 35(1) requires a DPIA 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. Article 35(3) lists three cases where a DPIA is required in particular:
- (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;
- (b) processing on a large scale of special categories of data (Article 9(1)) or of criminal convictions and offences data (Article 10);
- (c) systematic monitoring of a publicly accessible area on a large scale.
Article 35(4) requires each supervisory authority to publish a list of processing operations that require a DPIA, and Article 35(5) allows it to publish a list of operations that do not. These national lists are binding context for your screening, so check your national supervisory authority's list.
The WP248 nine criteria
The Article 29 Working Party guidelines on DPIA (WP248 rev.01, endorsed by the EDPB) give nine criteria for identifying likely high risk:
| # | Criterion | IT project examples |
|---|---|---|
| 1 | Evaluation or scoring | Fraud scoring, credit risk models, user behaviour analytics |
| 2 | Automated decision-making with legal or similar significant effect | Automatic account suspension, automated CV rejection |
| 3 | Systematic monitoring | Employee activity monitoring, UEBA, CCTV analytics |
| 4 | Sensitive data or data of a highly personal nature | Health records, biometrics, location history, private communications |
| 5 | Data processed on a large scale | Customer data platforms, national-scale services |
| 6 | Matching or combining datasets | Data lake joining CRM, web analytics and support data |
| 7 | Data concerning vulnerable data subjects | Employees, children, patients |
| 8 | Innovative use or new technological or organisational solutions | Biometric access control, machine learning on personal data, IoT |
| 9 | Processing that prevents data subjects from exercising a right or using a service or contract | Access to a service gated by a risk score |
The rule of thumb from WP248: processing that meets two or more criteria will require a DPIA in most cases. Note criterion 7 in particular. Employees are considered vulnerable because of the power imbalance with their employer, so many internal security tools such as DLP, insider threat analytics or TLS inspection tick criterion 3 and 7 at once.
A simple screening step
Put a short screening questionnaire into your project intake or architecture review process. It saves the DPO from discovering a monitoring tool after it is already deployed.
# Example DPIA screening record attached to an architecture review
project: ueba-rollout
screened_by: "security-architecture"
screened_on: "2026-09-20"
personal_data: true
wp248_criteria:
evaluation_or_scoring: true # risk scores per user
automated_decision_significant: false # analyst reviews before action
systematic_monitoring: true # continuous endpoint and log analysis
sensitive_or_highly_personal: false
large_scale: true # all 6,000 staff
matching_datasets: true # HR, IAM, proxy and EDR data joined
vulnerable_subjects: true # employees
innovative_technology: true # ML-based anomaly detection
prevents_rights_or_service: false
criteria_met: 6
on_national_dpia_list: "check with DPO"
outcome: dpia_required
dpo_consulted: true # Art. 35(2)
What a DPIA must contain
Article 35(7) sets the minimum content:
- (a) a systematic description of the envisaged processing operations and purposes, 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;
- (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.
Article 35(2) requires the controller to seek the advice of the data protection officer, where one is designated. Article 35(9) adds that, where appropriate, the controller should seek the views of data subjects or their representatives; for employee monitoring, that often means works council or staff representative consultation, depending on national law.
What the security team brings
Security engineers are well placed to deliver large parts of (a), (c) and (d). The challenge is framing the work correctly.
Describing the processing
A systematic description is essentially a data flow diagram with context. For each flow, capture the source, destination, data categories, hosting location, processors involved, retention and access roles. If you already maintain records of processing activities and an asset inventory, reuse them. Include third-country locations, since international transfers change the risk picture.
Threat modelling, reframed around people
Use your usual method (STRIDE, attack trees, kill-chain analysis), but score impact on individuals, not on the company. The same technical threat can have very different privacy impact:
| Threat | Company-centric impact | Data subject impact |
|---|---|---|
| Analyst misuses UEBA console to look up a colleague | Low (no outage, no data loss) | High (intrusion into private life, potential retaliation) |
| Exfiltration of risk scores | Medium (reputational) | High (stigmatisation, employment consequences) |
| Model drift produces false positives | Low | Medium to high (unjustified investigations) |
| Excessive log retention | None | Medium (data kept longer than necessary) |
Remember that the DPIA covers risks beyond security breaches: function creep, lack of transparency, inaccurate data, inability to exercise rights. Security teams should flag these when they see them in the design, even if the DPO leads on them.
Proposing measures
For each significant risk, propose measures and state their effect on likelihood or severity. Typical security contributions:
- Pseudonymisation of user identifiers in analytics, with re-identification restricted to a documented escalation step.
- Role-based access to consoles, with dual control for sensitive lookups and logging of all queries.
- Encryption in transit and at rest, with keys managed separately.
- Retention limits enforced technically (TTL, partition drops), not just by policy.
- Minimisation: collecting only the telemetry fields needed for the stated purpose.
These map directly to Article 32 and to data protection by design under Article 25.
Residual risk and prior consultation
After measures are applied, assess the residual risk. If the DPIA indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk, Article 36 requires the controller to consult the supervisory authority prior to processing. The authority provides written advice within a period of up to eight weeks, which may be extended by six weeks.
For project planning, that means two things. First, run the DPIA early enough that design changes are still possible; the cheapest mitigation is often a change in architecture. Second, if residual risk may stay high, build the potential consultation period into the timeline rather than discovering it a week before go-live.
Keeping the DPIA alive
Article 35(11) requires the controller to carry out a review, where necessary, at least when there is a change of the risk represented by the processing. Practical triggers to wire into change management:
- new data categories or new data sources joined to the dataset;
- new processors, hosting regions or third-country access;
- a new purpose or a new population of data subjects;
- significant architecture changes, such as moving from on-premises to SaaS;
- a relevant security incident or near-miss;
- a change in the state of the art that makes an existing measure weaker.
Store the DPIA alongside the system's architecture documentation, version it, and link it from the change request template so reviewers can check whether an update is needed.
DPIA checklist for IT projects
- Screening done at project intake using the WP248 criteria and the national list.
- DPO consulted and their advice recorded.
- Data flows documented, including processors and third-country access.
- Necessity and proportionality addressed for each data category.
- Threats scored for impact on data subjects.
- Measures mapped to risks with owners and implementation dates.
- Residual risk assessed; prior consultation decision recorded.
- Review triggers linked to change management.
Scope of this guide
This article is technical guidance for security and IT teams contributing to data protection impact assessments. It is not legal advice. Confirm whether a DPIA is required, its conclusions and any prior consultation with your data protection officer or legal counsel.