Skip to main content
Privacy Track
Category: Impact Assessments & Documentation

Article 35

Simply put

The evidence provided does not contain any material describing Article 35 in the context of the GDPR or data privacy law (which would typically concern Data Protection Impact Assessments). The sources supplied instead refer to unrelated legal instruments, such as Article 35 of the Constitution of India, Article 35 of the New York Penal Law on the defense of justification, and Article 35 of the Charter of the United Nations. A reliable definition cannot be generated from this evidence.

Formal definition

Insufficient and non-relevant evidence: none of the supplied sources address Article 35 of Regulation (EU) 2016/679 (GDPR) or any equivalent data protection provision. Producing a definition of the GDPR Article 35 concept (commonly associated with Data Protection Impact Assessments) from these sources would require inventing content not present in the evidence packet, which is not permitted. The reader should supply source material relating to the relevant privacy instrument, and should verify the correct provision and its scope against the current official text of the applicable Regulation.

Why it matters

The evidence digest supplied for this entry does not contain any material relating to Article 35 of the General Data Protection Regulation (GDPR) or to data protection law generally. Instead, the sources address entirely unrelated legal instruments: Article 35 of the Constitution of India (concerning legislation to give effect to fundamental rights provisions), Article 35 of the New York Penal Law (the defense of justification, including the use of physical force), and Article 35 of the Charter of the United Nations (bringing disputes to the attention of the Security Council or General Assembly). None of these bear on privacy, personal data, or the GDPR.

Because a glossary entry for Privacy Track must be accurate and citable within a compliance program, a substantive definition cannot responsibly be generated from this evidence. In GDPR practice, Article 35 is commonly associated with the Data Protection Impact Assessment (DPIA), but that association cannot be documented or verified from the sources provided here, and drafting context around it would require introducing factual claims not supported by the evidence digest. Readers should not treat the unrelated instruments above as relevant to data protection.

To produce a reliable entry, source material relating to Article 35 of Regulation (EU) 2016/679 (GDPR), or the corresponding provision of the UK GDPR or applicable national implementing law, should be supplied. Any definition should then be verified against the current official text of the applicable Regulation, as scope, thresholds, and supervisory authority guidance can vary between jurisdictions and evolve over time.

Who it's relevant to

Content and research teams supplying evidence
This entry cannot be completed because the evidence packet contains no material on Article 35 GDPR or data protection law. Those preparing source material should supply digest entries drawn from the relevant privacy instrument, for example, the official text of Regulation (EU) 2016/679, UK GDPR, or applicable national implementing law, so that an accurate definition can be produced without fabrication.
Readers seeking a data protection definition
Practitioners looking for guidance on the GDPR concept commonly associated with Article 35 should not rely on this placeholder entry, and should verify the correct provision and its scope against the current official text of the applicable Regulation. The instruments cited in the current evidence (Indian constitutional law, New York Penal Law, and the UN Charter) are unrelated to privacy and should not be treated as authority in a compliance context.

Inside Article 35

Data Protection Impact Assessment (DPIA)
Article 35 of the GDPR requires a controller to carry out a DPIA where a type of processing, in particular using new technologies, is likely to result in a high risk to the rights and freedoms of natural persons. It is an assessment tool undertaken prior to processing, distinct from the Article 28 Data Processing Agreement and from record-keeping obligations.
High-risk trigger threshold
The obligation is triggered by processing 'likely to result in a high risk,' assessed in light of the nature, scope, context, and purposes of the processing. Article 35 gives examples typically associated with high risk, such as systematic and extensive evaluation based on automated processing including profiling, large-scale processing of special category data (Article 9) or criminal offence data, and systematic monitoring of a publicly accessible area on a large scale. Whether a given case meets the threshold is subject to assessment.
Minimum content of the assessment
Article 35 generally requires the DPIA to contain at least a systematic description of the envisaged processing operations and purposes, an assessment of the necessity and proportionality of the processing in relation to the purposes, an assessment of the risks to the rights and freedoms of data subjects, and the measures envisaged to address those risks, including safeguards and mechanisms to ensure the protection of personal data.
Supervisory authority DPIA lists
Supervisory authorities may establish and publish lists of processing operations that require a DPIA, and may also publish lists of operations for which no DPIA is required. These lists can vary between member states, so the position for a given activity should be verified against the relevant national authority's list.
Role of the Data Protection Officer
Where a DPO has been designated, the controller is generally expected to seek the advice of the DPO when carrying out a DPIA. The DPIA remains the controller's responsibility, and the DPO's role is advisory.
Relationship to prior consultation (Article 36)
Where a DPIA indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk, the controller is required to consult the supervisory authority before processing, under the separate Article 36 prior consultation obligation. Article 35 and Article 36 are linked but distinct provisions.

Common questions

Answers to the questions practitioners most commonly ask about Article 35.

Does every processing activity require a Data Protection Impact Assessment?
No. A DPIA under Article 35 is generally required where processing is likely to result in a high risk to the rights and freedoms of natural persons, in particular using new technologies. It is not a universal obligation for all processing. Supervisory authorities publish lists of processing operations that do (and in some cases do not) require a DPIA, and these lists can vary between member states. Where the likelihood of high risk is unclear, controllers typically carry out a threshold or screening assessment to decide whether a full DPIA is needed, and should document that reasoning.
Is a DPIA the same as a Data Processing Agreement?
No, these are distinct instruments and should not be conflated. A DPIA under Article 35 is an internal risk assessment process the controller carries out before high-risk processing to identify and mitigate risks to individuals. A Data Processing Agreement under Article 28 is a contract governing the relationship between a controller and a processor and setting out the processor's obligations. One is an assessment; the other is a contractual instrument. They serve different purposes and are triggered by different circumstances.
Who is responsible for carrying out a DPIA?
The controller is responsible for ensuring a DPIA is carried out. Where a Data Protection Officer has been designated, the controller is generally required to seek the DPO's advice, though the DPO does not assume responsibility for the assessment itself. A processor may be asked to assist and provide information, but the accountability for the DPIA rests with the controller. Input from other stakeholders, such as engineers, security teams, and business owners, is typically needed to describe the processing accurately.
At what point in a project should a DPIA be conducted?
A DPIA should generally be carried out prior to the processing, ideally early in the design of a project or system so that its findings can influence design choices. This aligns with data protection by design and by default principles. A DPIA is typically treated as an ongoing process rather than a one-off document, and controllers should review and, where appropriate, revisit it if the nature, scope, context, or purposes of the processing change or if the risk profile evolves.
What should a DPIA record contain?
Article 35 sets out minimum content, which generally includes a systematic description of the envisaged processing operations and their purposes, an assessment of the necessity and proportionality of the processing in relation to those purposes, an assessment of the risks to the rights and freedoms of data subjects, and the measures envisaged to address those risks. Where relevant, the views of data subjects or their representatives may be sought. Controllers should verify the precise requirements against the current official text.
What happens if a DPIA indicates a high residual risk?
Where a DPIA indicates that the processing would result in a high risk that cannot be mitigated by measures the controller takes to reduce it, the controller is generally required to consult the supervisory authority before proceeding (prior consultation). This is distinct from the situation where identified risks can be adequately mitigated, in which case processing may proceed subject to the documented safeguards. The threshold for prior consultation is a matter of assessment and may benefit from checking applicable regulator guidance.

Common misconceptions

A DPIA is required for every processing activity involving personal data.
A DPIA is generally required only where processing is likely to result in a high risk to the rights and freedoms of natural persons. Many routine processing activities will not meet this threshold, though the threshold itself is a matter of assessment and supervisory authorities may publish lists indicating where a DPIA is or is not required.
A DPIA and a Data Processing Agreement are the same document.
They are distinct instruments. A DPIA under Article 35 is a risk assessment carried out by the controller before high-risk processing, whereas a Data Processing Agreement under Article 28 is the contract governing the controller-processor relationship. They serve different functions and should not be conflated.
Completing a DPIA means the processing is fully compliant and can always proceed.
A DPIA is one element of accountability, not a guarantee of compliance. Where the assessment shows a high residual risk that the controller cannot mitigate, prior consultation with the supervisory authority under Article 36 is generally required before processing. Compliance remains context and risk dependent.

Best practices

Screen processing activities against the high-risk criteria in Article 35 and any DPIA lists published by the relevant supervisory authority before starting, and document the screening outcome even where you conclude no DPIA is required.
Carry out the DPIA prior to commencing the processing, so that identified risks and mitigations can genuinely influence design decisions rather than being documented after the fact.
Ensure the assessment covers the minimum content set out in Article 35, including a systematic description of the processing, a necessity and proportionality analysis, a risk assessment, and the measures envisaged to address the risks.
Where a DPO has been designated, seek and record the DPO's advice on the DPIA while keeping the assessment and decision as the controller's responsibility.
Where residual risk remains high after mitigation, treat prior consultation with the supervisory authority under Article 36 as a separate step to be assessed before processing begins.
Verify the applicable DPIA lists and any national derogations against the current official text and the relevant authority's guidance, since positions can vary between member states and evolve over time.