DEV Community

Custodia-Admin
Custodia-Admin

Posted on

GDPR Vendor Assessment: How to Evaluate Third-Party Tools Before You Add Them to Your Stack

#gdpr #privacy #saas #security

Every SaaS tool you add to your stack is a data protection decision. The moment you embed a chat widget, connect a CRM, or install an analytics script, you are sharing your users's personal data with another organisation. Under GDPR, that sharing carries legal weight — and legal risk.

This guide walks through how to assess third-party vendors before you sign up, what documents you need to obtain, the red flags to watch for, and how to build an ongoing vendor management practice that holds up to regulatory scrutiny.

Why Every SaaS Tool You Add Is a GDPR Risk

Most privacy conversations focus on your website's cookie banner or your privacy policy. Those matter — but they are downstream of a more fundamental question: who are you sharing data with, and on what legal basis?

When a visitor lands on your site, they don't just interact with you. They interact with every third-party tool you've loaded. Google Analytics sees their behaviour. Intercom or Crisp collects their messages. HubSpot or Salesforce stores their contact details. Your email marketing platform holds their inbox address. Each of these vendors processes personal data on your behalf.

If any of those vendors mishandles that data — suffers a breach, sells it to advertisers, transfers it to jurisdictions without adequate protections — your users are harmed and you bear responsibility. The GDPR is explicit: ignorance of what your processors do is not a defence.

The Controller/Processor Distinction

Before you can manage vendor relationships, you need to understand who is responsible for what.

You are the data controller. You decide what data to collect, why you collect it, and what happens to it. Responsibility for compliance sits with you. If a regulator investigates, they come to you first.

Your vendor is typically a data processor. They process personal data on your behalf, according to your instructions. They do not decide what data to collect or why — they just process it for the purposes you specify.

This distinction matters because:

  • Controllers must only engage processors that provide "sufficient guarantees" under Article 28 GDPR
  • Controllers are liable for processor failures if they didn't carry out adequate due diligence
  • Processors must only act on documented controller instructions — not their own commercial interests
  • Sub-processors (vendors your vendor uses) require your prior authorisation

Some vendors operate as joint controllers, not processors. An analytics platform that uses your data to train its own models, or a marketing platform that shares data across its customer base, may be a joint controller. This requires a joint controller agreement (Article 26) rather than a DPA, and involves more complex liability sharing.

What a Data Processing Agreement Must Contain

Under Article 28 GDPR, any vendor processing personal data on your behalf must sign a Data Processing Agreement (DPA). This is not optional. Processing without a DPA is a GDPR violation — regardless of how long you've been using the vendor or how small the amount of data involved.

A compliant DPA must cover:

  • Subject matter and duration of the processing
  • Nature and purpose of the processing
  • Type of personal data and categories of data subjects
  • Your obligations and rights as controller
  • A requirement that the processor only processes data on your documented instructions
  • A commitment that the processor ensures personnel are bound by confidentiality
  • Implementation of appropriate technical and organisational security measures (Article 32)
  • Agreement not to engage sub-processors without prior written authorisation
  • Assistance with data subject rights requests (access, erasure, portability)
  • Assistance with security obligations, breach notification, DPIAs, and prior consultation
  • Deletion or return of personal data at the end of the relationship
  • Provision of audit rights and ability to demonstrate compliance

Most established SaaS vendors provide a standard DPA. Check their privacy or legal pages — they often call it a "Data Processing Addendum" or link to it from their privacy policy. If you cannot find one, ask directly. If they don't have one or refuse to provide one, that is a significant red flag.

Vendor Due Diligence: 11 Questions to Ask Before You Sign Up

Before adding any new tool that will touch personal data, work through this checklist:

  1. Do they have a DPA available? If not, is there a process to request one? Vendors without a DPA are a non-starter for EU data.
  2. Where is data stored? EU/EEA storage is simplest. If data is stored or processed outside the EEA, what transfer mechanism is in place?
  3. Are they compliant with an applicable transfer mechanism? For US vendors, are they enrolled in the EU-US Data Privacy Framework (DPF)? Do they offer Standard Contractual Clauses (SCCs)?
  4. Who are their sub-processors? Reputable vendors publish a sub-processor list. Ask for it. Review it.
  5. Do they have an ISO 27001 or SOC 2 certification? These are indicators of mature security practices.
  6. What is their breach notification process? Under Article 33 GDPR, processors must notify controllers "without undue delay" after discovering a breach.
  7. What is their data retention policy? How long do they keep your data? What happens to it when you cancel?
  8. Do they sell or share data with third parties for their own purposes? Any vendor that uses your customer data to train models may be acting as a joint controller.
  9. What access controls do they operate internally? Who within the vendor organisation can access your data?
  10. Do they have a dedicated privacy or data protection contact?
  11. Can they support data subject rights requests? If a user submits a DSAR asking for erasure, can you instruct the vendor to delete their data?

Red Flags in Vendor Privacy Policies

  • "We may share data with our partners and affiliates." Vague language that often means the vendor treats your users' data as an asset it can monetise.
  • "By using our service, you grant us a licence to use your data to improve our products." This is the language of a joint controller, not a processor.
  • No mention of GDPR at all. For a vendor serving European markets, this suggests ignorance or avoidance.
  • Sub-processor lists that haven't been updated in years. Cloud infrastructure changes rapidly.
  • "We will retain data for as long as necessary for business purposes." This is a non-answer. Lawful retention requires specific purposes and defined periods.
  • No audit rights in the DPA. Article 28 requires that processors allow for and contribute to audits.

Sub-Processors and the Cascade of Accountability

Your vendor doesn't operate in isolation. They use their own vendors — cloud hosts, email delivery services, payment processors, monitoring tools. These are sub-processors, and under GDPR, they are part of your accountability chain.

Article 28 requires that processors must not engage sub-processors without your prior specific or general written authorisation. Most enterprise DPAs use the general authorisation model — you approve the vendor's right to engage sub-processors, provided they notify you of any changes and you have the right to object.

Data Residency and EU-US Transfer Mechanisms

Data residency — where personal data is physically stored and processed — is a live regulatory issue. Your options for lawful EU-US transfers:

  • EU-US Data Privacy Framework (DPF): If your US vendor is DPF-certified, data transfers are covered by the adequacy decision. Verify certification at the official DPF list.
  • Standard Contractual Clauses (SCCs): The 2021 SCCs are the most commonly used transfer mechanism. You may also need to conduct a Transfer Impact Assessment (TIA).
  • UK International Data Transfer Agreements (IDTAs): For post-Brexit UK data flows.
  • Adequacy decisions: Some countries (Canada, Japan, South Korea, New Zealand) have been granted adequacy status.

What to Do When a Vendor Can't Provide a DPA

  • Escalate within the vendor. The sales rep may not know about the DPA. Ask to be connected with legal or compliance.
  • Use your own DPA template. The ICO and other DPAs publish controller-to-processor contract templates.
  • Assess the risk. If the vendor processes only truly anonymised data, you may not need a DPA — but be rigorous.
  • Stop using the tool. If the vendor handles personal data but refuses to execute a DPA, continuing to use them is a GDPR violation.
  • Consider alternatives. Privacy-first options exist in most SaaS categories.

Reviewing Vendors You Already Use

  1. Inventory all current tools — every SaaS subscription, every API integration, every embedded script.
  2. Classify by data type — which tools handle personal data? Which handle sensitive personal data?
  3. Confirm DPAs exist for all tools handling personal data.
  4. Check transfer mechanisms — particularly for US vendors.
  5. Identify zombie tools — tools you're paying for but no longer actively use.
  6. Terminate or remediate — find compliant alternatives or stop using non-compliant tools.

Building a Vendor Register as Part of Your ROPA

Article 30 GDPR requires controllers to maintain Records of Processing Activities (ROPA). For each vendor, record:

  • Vendor name and contact details
  • Categories of personal data processed
  • Purpose of processing
  • Legal basis
  • Transfer mechanism (if outside EEA)
  • DPA status (signed, date, version)
  • Sub-processor list (version and date reviewed)
  • Retention period / deletion process
  • Security certification (ISO 27001 / SOC 2, with expiry date)
  • Date last reviewed

Vendor Assessment Template

Use this for every new vendor:

  • DPA available and signed?
  • Data stored in EEA?
  • Transfer mechanism (if non-EEA)?
  • DPF certification verified? (US vendors)
  • SCCs in DPA?
  • Sub-processor list available and reviewed?
  • ISO 27001 / SOC 2 certification?
  • Breach notification process documented?
  • Retention / deletion policy clear?
  • Data sold / used for vendor's own purposes?
  • Audit rights in DPA?
  • Data subject rights support confirmed?

Managing vendor relationships is one of the least glamorous parts of GDPR compliance — but it is one of the most consequential. A single un-DPA'd vendor processing EU personal data puts your entire compliance posture at risk.

If you want to understand exactly which third-party tools are running on your website right now, run a free scan at Custodia. You'll get a complete picture of your current tracker exposure, your consent management gaps, and where your biggest compliance risks are — in under 60 seconds.

This post provides general information about GDPR and vendor management. It does not constitute legal advice. Consult a qualified data protection professional for advice specific to your organisation.

Top comments (0)