No, a DPIA Is Not a Vendor Privacy Assessment

(And Why Mixing Them Up Creates Risk You Can’t See)

It is surprisingly common for teams to treat a Data Protection Impact Assessment (DPIA) or Privacy Impact Assessment (PIA) as if it covers vendor privacy risk. On paper, it might seem efficient because why duplicate effort when the DPIA already includes questions about data processing.

But the reality is a DPIA and a vendor privacy assessment are not the same thing. And using one to do the job of the other leads to blind spots that can seriously weaken your third-party risk process.

A DPIA is designed to assess the risk of a data processing activity — especially when it could impact individuals’ rights and freedoms. It is driven by the data controller or business (your org), and the focus is on how your business uses data in a specific context (e.g., launching a new product, rolling out a new system, implementing surveillance tech).

Meanwhile, Third-party risk assessment is focused on the vendor — not just the processing. It is about evaluating how the vendor is complying with data protection laws, how they handle data, where it goes, how and where it is stored, whether it is reused or shared with sub-processor, what contractual or technical protections are in place.

You’re not just asking, “Is this lawful under GDPR?”You’re asking:

• Does the vendor actually follow through on what they claim?

• Do they understand their obligations as a processor or service provider?

• Can they limit their use of the data?

• How are they honoring opt out requests?

• Is their privacy policy updated?

• Are they adding sub-processors without telling us?

• Do their tools quietly train machine learning or AI on our customer data?

A DPIA won’t catch any of that.Because it’s not designed to.

Here’s why the confusion happens:

A lot of teams are trying to do more with less. They’re under pressure to move fast, show compliance, and not slow down the business. So when a DPIA already includes some vendor info, it’s tempting to treat that as “close enough.”But they reality is not.

A DPIA might ask what vendor you are using. But, pretty that's it. It doesn’t typically ask how that vendor handles retention, purpose limitation, or cross-border transfers — and whether you have documented that anywhere else.

Using a DPIA in place of a vendor assessment often means you are only looking at part of the picture and skipping the part that could expose you to contract gaps, regulator scrutiny, or data misuse downstream.

What’s the fix?

The two can complement each other — but they serve different roles.

• Use the DPIA when your org is making a decision about how it processes personal data.

• Use a Third-party risk assessment when you are deciding whether a third party can be trusted with that data and under what conditions.

  
  

If the vendor is involved in high-risk processing, sure, that might trigger a DPIA. But you still need to vet the vendor, not just assume they are covered because they show up in a DPIA report.

Why this matters

As more vendors integrate with AI, move data across borders, or reuse information for their own tools, privacy risk is no longer just about what your org does — it’s about what your vendors do, too.

If you are not assessing that, you are not managing it.

And if your privacy team is being asked to “just sign off” based on a DPIA, this might be a good time to revisit the process.

I’m writing more about this in my book on privacy-focused TPRM

Because the privacy risk we face through third-party relationships can’t be managed through borrowed frameworks or partial tools. If you have seen this confusion pop up in your org or you have been asked to approve a vendor based on a DPIA. I would love to hear how you handled it. Who actually owns privacy reviews for vendors in your org?