Your engineering team ships a feature that scores users using behavioral data. Your PM marks it done on Friday. By Monday, your legal team explains you violated Article 35 of GDPR without filing a single document.
A DPIA is not a post-launch checkbox — it is a gate that opens before high-risk processing begins. This article explains when your product roadmap triggers a mandatory DPIA, what the assessment must contain, and how to catch it before the sprint closes.
When a DPIA is mandatory
Article 35 GDPR requires a DPIA whenever processing is "likely to result in a high risk" to the rights and freedoms of natural persons [source: https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/obligations/when-data-protection-impact-assessment-dpia-required_en]. Three processing categories always require one:
- Systematic and extensive profiling that produces legal or similarly significant effects on individuals
- Large-scale processing of special category data such as health, biometric, or criminal record data
- Systematic monitoring of publicly accessible areas at large scale
If your next sprint contains a feature that meets two or more of these criteria, you must complete a DPIA before go-live. National supervisory authorities also publish blacklists of processing types that always require a DPIA — controllers must consult their authority's list as part of scoping [source: https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/obligations/when-data-protection-impact-assessment-dpia-required_en].
What the assessment must document
A GDPR-compliant DPIA is not a paragraph in your privacy notice. The EDPB template structures the assessment around four sections [source: https://www.edpb.europa.eu/system/files/2026-04/edpb_dpia_template_explainer_2026_v1_en.pdf]:
Description of the processing — what data you collect, the purposes, the retention period, who has access, and the legal basis you rely on. Necessity and proportionality — a documented case that the processing is limited to what is strictly necessary to achieve its purpose. This is where the product spec gets tested against the data minimisation principle. Engineers tend to collect more signals than the model actually needs; this section forces the conversation before launch. Risk assessment — identification of risks to data subjects, probability and severity of harm, and existing controls that reduce each risk. Think of it as a threat model for privacy rather than security. Measures to address risk — technical and organizational controls, residual risk after controls are applied, and sign-off from your DPO if one is appointed [source: https://www.edpb.europa.eu/system/files/2026-04/edpb_dpia_template_explainer_2026_v1_en.pdf].If residual risk remains high after applying controls, GDPR requires you to consult your lead supervisory authority before processing begins [source: https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/obligations/when-data-protection-impact-assessment-dpia-required_en]. This consultation can take weeks to months depending on the authority and the complexity of the processing. Not building that timeline into your release plan is a planning error that surfaces at the worst possible moment — the day before launch.
How roadmap features silently cross the threshold
The most common failure mode is incremental. A feature looks low-risk in isolation. Then a series of changes — adding behavioral scoring, connecting it to a recommendation engine, expanding the user base to include EU customers — crosses the DPIA threshold without anyone noticing.
Three patterns consistently create DPIA obligations that product teams miss:
Adding ML-driven personalization to existing pipelines. Routing a user activity log through a model that influences pricing, content ranking, or eligibility decisions introduces systematic profiling. The data was already being collected; the model adds the scoring layer that triggers Article 35. Teams discover this obligation only when a privacy engineer finally reviews the feature spec. Expanding scope to employees or children. A B2B analytics product that adds workforce analytics features is now processing data about employees — a category supervisory authorities scrutinize closely [source: https://www.securityscientist.net/blog/when-to-do-gdpr-dpia-complete-guide-2026/]. Adding age-gating to a consumer product signals the team already knows it is approaching the children's data processing boundary. Neither scenario is low-risk by default. Cross-product data joins. Merging the user table from your marketing platform with behavioral data from your product to power a customer health score is the textbook "matching or combining datasets from separate sources" criterion. Each dataset may be proportionate in isolation; the combination creates a richer profile that changes the risk picture entirely. The DPIA must address the combined dataset, not each source separately.Wiring the DPIA trigger into your sprint workflow
A DPIA is most painful when discovered in a post-launch review. It is cheap when caught during the design phase. The structural fix is making the assessment a part of your ticket-creation process, not a quarterly compliance audit.
Feature privacy screen
Add a privacy screen to your product requirement template. A short set of yes/no questions — does this feature collect new categories of data, create a scoring or ranking of users, monitor user behavior at scale, or process data about children or employees — that maps directly to the nine EDPB criteria. If two or more answers are yes, the ticket auto-routes to your privacy or legal team before sprint planning begins. This adds a few minutes to ticket creation and removes weeks of post-launch remediation.
Documentation minimum
Once a DPIA is triggered, the four-section EDPB structure is your documentation floor [source: https://www.edpb.europa.eu/system/files/2026-04/edpb_dpia_template_explainer_2026_v1_en.pdf]. Keep the assessment in a controlled document system with version history. Supervisory authorities expect to see that the assessment was completed before processing began — not backdated after a complaint or enforcement inquiry.
Supervisory authority consultation
If the DPIA leaves residual risk high, you must consult your lead supervisory authority before the feature goes live [source: https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/obligations/when-data-protection-impact-assessment-dpia-required_en]. Build that timeline into your roadmap. Skipping the consultation and hoping the feature flies under the radar is not a risk mitigation strategy. It is deferred liability with interest.
Keeping the DPIA current
A DPIA is not a one-time file. Article 35(11) of GDPR requires a review whenever the processing is likely to change the risk profile for data subjects [source: https://commission.europa.eu/law/law-topic/data-protection/rules-business-and-organisations/obligations/when-data-protection-impact-assessment-dpia-required_en]. In practice, any significant change to a feature — a new data source, a new processing purpose, a new recipient category — should trigger a DPIA review. Treat the DPIA register as a living document reviewed alongside your risk register, not a closed audit finding.
Set a calendar trigger tied to major release milestones. If a feature that previously cleared a DPIA is getting a significant capability expansion, the previous assessment does not automatically extend to the new version. Document the delta and re-assess the risk.
DPIA obligations surface late when privacy is bolted on rather than built in. CloudAnzen maps your data flows to GDPR Article 35 requirements and flags features that need a DPIA before the sprint closes — so you consult the supervisory authority on your timeline, not theirs. Talk to us.