GDPR Article 35 is the rule that requires a data protection impact assessment before processing is likely to create high risk to individuals. It is used to identify risks, describe the processing, assess necessity and proportionality, and set controls such as minimisation, access restriction, and encryption.
What Article 35 Means in Practice
GDPR Article 35 is the point where privacy compliance becomes a structured risk exercise, not a box-ticking form. It requires organisations to identify high-risk processing, understand why the activity is sensitive, and document the rationale before they proceed.
The practical value of Article 35 is that it forces a clear description of the processing operation, the purposes, the data involved, the necessity of the activity, and the proportionality of the design. That makes it easier to spot where the processing is unusually intrusive, opaque, or difficult to control.
Because the threshold is “likely to create high risk”, the article is not limited to obvious breaches or incidents. It also captures processing patterns that may be lawful in principle but still need deeper review because scale, sensitivity, monitoring, matching, or automated decision effects can materially raise individual risk.
How a DPIA Supports Compliance
An Article 35 assessment is more than a narrative description of risk. It should connect the processing purpose to the data categories, explain necessity and proportionality, and show how the organisation intends to reduce exposure through design choices and control measures.
That is why a good DPIA normally examines minimisation, access restriction, retention limits, transparency, and security safeguards together. If the assessment only lists controls without explaining why they are needed for the specific processing, it misses the core logic of the article.
In practice, the article also encourages earlier privacy review in the project lifecycle. The assessment should happen before launch, or before a significant change, so the organisation can reshape the processing rather than simply documenting a decision after implementation.
A useful way to handle the work is to treat the DPIA as an evidence-backed record of decision-making. The assessment should make it obvious what was considered, what residual risk remains, and why the final design is acceptable or not.
What Good Evidence Looks Like
Article 35 works best when the assessment is grounded in concrete information, not generic statements. The strongest inputs are accurate data maps, a clear processing description, data categories, recipient groups, storage locations, access paths, and any automated logic that changes the impact on individuals.
That evidence matters because high-risk processing often fails in the details. A vague inventory can hide secondary uses, broad access, weak segregation, or unclear retention, all of which make the risk analysis less reliable.
Good assessments also distinguish between necessity and convenience. A control can be technically effective and still be excessive if the same purpose can be achieved with less personal data, less visibility, or shorter retention.
Where the processing involves outside parties, the assessment should also track who can see, handle, or influence the data. Vendor access, shared environments, and data transfers can all change the risk profile even when the internal system design looks sound.
Why Article 35 Matters for Security Design
Article 35 is closely tied to privacy by design because it pushes security and privacy controls into the architecture conversation. The article does not replace security engineering, it gives the organisation a formal reason to justify controls before data is exposed to unnecessary risk.
That is especially important when the processing creates concentration risk, visibility gaps, or a poor ability to explain decisions to individuals or regulators. In those cases, the assessment is often the only place where the business, legal, privacy, and security perspectives are forced into one documented judgment.
When used well, the DPIA becomes a decision record for trade-offs. It shows why the organisation accepted a certain design, what controls were relied on, and what review or monitoring is needed if the risk profile changes later.
Risk and Threat Considerations
Article 35 matters because the failure is usually not the assessment itself, but the processing that was launched without properly understanding its effect on people. If the DPIA is rushed, superficial, or detached from the actual system design, the organisation can miss high-risk processing patterns until they become a regulatory, operational, or privacy incident.
Failure mechanism: Weak screening, incomplete data mapping, or optimistic control assumptions can cause the organisation to understate necessity, overstate safeguards, and approve processing that still exposes individuals to disproportionate risk.
Impact: The result can be unlawful or poorly controlled processing, regulatory scrutiny, delayed launches, costly redesign, and a greater chance that downstream controls do not match the real exposure.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art. 35 — Data Protection Impact Assessment | Article 35 directly defines DPIA requirements for high-risk processing. |
| Recommendation — Perform a DPIA before high-risk processing begins and document necessity, proportionality, and mitigations. | ||
| NIST SP 800-53 Rev 5 | RA-3 — Risk Assessment | Article 35 is fundamentally a structured risk assessment activity for processing. |
| PT-4 — PII Processing and Transparency | DPIAs require clear processing descriptions and transparency about how personal data is used. | |
| AC-6 — Least Privilege | Article 35 commonly leads to access restriction as a mitigation for high-risk processing. | |
| Recommendation — Assess processing risk early and record residual risk before authorising deployment. Map processing purposes and data uses so privacy impacts are explicit and reviewable. Apply least privilege to limit who can access personal data involved in high-risk processing. | ||
| ISO/IEC 27001:2022 | A.5.34 — Privacy and protection of PII | Article 35 supports privacy controls and risk treatment for personal data processing. |
| Recommendation — Integrate privacy impact review into information security governance for personal data processing. | ||
Practitioner Guidance
Why practitioners should care: Treat Article 35 as a decision-quality checkpoint, not a document to complete after the design is fixed. The assessment should surface whether the processing is genuinely justified, controllable, and proportionate before it is approved.
What to watch for: Be cautious when the activity involves new technology, large-scale monitoring, sensitive data, profiling, or broad internal and third-party access. Those are the situations where a shallow DPIA usually fails to expose the real risk.
Practitioner takeaway: A strong Article 35 process gives the organisation an auditable explanation for why the processing can proceed, and just as importantly, for what must change if it cannot.
Related resources from NHI Mgmt Group
- How should security teams use DLP and DSPM together for GDPR Article 32 compliance?
- Who is accountable when Article 32 controls fail during a GDPR investigation?
- When should organisations create a RoPA under GDPR Article 30?
- What should privacy teams do when AI systems use personal data for automated decision-making under GDPR Article 22?