Safeguard
Compliance•

Security risk assessment vs GDPR DPIA: what Article 35 adds

A DPIA assesses risk to people, not to the company. See when GDPR Article 35 requires one, what it must contain, and how it fits your risk register.

Safeguard Security Team
3 min read

A security risk assessment looks at risks to your organization, such as outages, breaches and fines. A GDPR data protection impact assessment looks at risks to the rights and freedoms of individuals from a specific kind of processing. Article 35 requires a DPIA when processing is likely to result in a high risk to people.

When a DPIA is required

Article 35(1) says a DPIA is needed before processing that is likely to result in a high risk to the rights and freedoms of natural persons, with particular attention to new technologies. Article 35(3) lists three cases where one is always required:

  • Systematic and extensive evaluation of personal aspects based on automated processing, including profiling, where decisions produce legal or similarly significant effects.
  • Large scale processing of special categories of data, or of data on criminal convictions and offences.
  • Large scale systematic monitoring of a publicly accessible area.

Supervisory authorities may publish lists of processing that does or does not require a DPIA. Check the list from the authority that applies to you.

What it must contain

Article 35(7) sets a minimum:

  1. A systematic description of the processing and its purposes.
  2. An assessment of whether the processing is necessary and proportionate.
  3. An assessment of the risks to data subjects' rights and freedoms.
  4. The measures planned to address those risks, including safeguards and security measures.

The controller also seeks the advice of the data protection officer where one is designated, and, where appropriate, the views of data subjects or their representatives. Article 35(11) requires a review when the risk changes.

How it differs from a security assessment

  • Whose risk. The DPIA centers on harm to individuals. A security assessment centers on harm to the organization.
  • What is asked. The DPIA also asks whether the processing is necessary and proportionate, which is a design question, not only a security one.
  • When. A DPIA happens before processing starts and is revisited when risk changes.
  • Who contributes. Privacy, legal, product and security all take part.

How they connect

The risk analysis in a DPIA can reuse your scales and method, as long as impact is defined in terms of people. For example, impact levels might describe the sensitivity of exposed data and the possible consequences for individuals, such as fraud or discrimination.

Record DPIA outcomes in your risk register when residual risk stays significant, so the owner and review date are tracked in one place.

A practical flow

  1. Screen new projects with three or four questions about the data and the processing.
  2. If the screening flags high risk, run the full DPIA.
  3. Feed identified security risks into the register.
  4. Re-screen when scope or technology changes.

This article is not legal advice. Ask counsel how Article 35 applies to your processing.

Quick check

Does every project need a DPIA?

No. It is required where processing is likely to result in high risk to individuals. Keep a record of why you decided one was not needed.

Can the security team run the DPIA alone?

It should not. The assessment covers necessity, proportionality and rights, which need privacy and legal input.

Sources

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.