Vendor privacy due diligence: a 12-point checklist before you sign

Every new tool is a small privacy decision. An email platform, a form builder, a support widget or an AI assistant can receive your customers' personal data the day you connect it. A short, repeatable check before you sign turns that decision from a guess into a record.

This checklist has twelve points. Most can be answered in an hour from the vendor's public pages and your account settings. It is guidance, not legal advice, and it does not replace a professional's view on an unusual or high-risk case.

#Why do you have to check vendors at all?

Article 28(1) of the GDPR says a controller must use only processors that provide sufficient guarantees to put appropriate technical and organisational measures in place. Article 28(3) says the relationship must be governed by a contract with specific content. The responsibility stays with you, even when the tool is run by someone else.

In October 2024 the European Data Protection Board adopted Opinion 22/2024 on controllers that rely on processors and sub-processors. Among other points, it says a controller should have the identity details of its processors and sub-processors readily available at all times, whatever the level of risk. A maintained list is therefore a practical requirement, not a nice extra.

#The 12 points at a glance

#1. What is the vendor's role?

The role depends on what the vendor does, not on its name. For the service you buy, an email platform or hosting provider is usually a processor. The same company can be a controller for its own purposes, for example fraud prevention or product analytics. Article 28(10) says that a processor that decides its own purposes and means becomes a controller for that processing. Our guide to the data processing agreement explains the roles in detail.

#2. Is there a data processing agreement?

If the vendor processes personal data for you, you need a DPA. Large vendors publish one and ask you to accept it in your account or sign it online. Accepting it is the step people forget. Save a dated copy.

If the vendor has no DPA and acts as a processor, you cannot use it lawfully for that purpose. Ask for one, or find an alternative.

#3. Does the DPA cover what Article 28(3) requires?

Article 28(3) lists the content. The processor must process only on your documented instructions, ensure confidentiality, apply security measures under Article 32, respect the conditions for sub-processors, help you answer data subject requests, help with security, breach and impact-assessment duties, delete or return the data at the end, and give you the information needed to show compliance and allow audits. It must also tell you if an instruction breaches the law.

Read the DPA with that list next to it. Most standard DPAs cover it. Check anything missing or vaguely worded.

#4. Who are the sub-processors?

A sub-processor is a company the vendor uses to process your data, such as a cloud provider. Article 28(2) and (4) require your authorisation, specific or general, and in the general case notice of changes with a chance to object. Look for a public list and a way to subscribe to changes. Without one, you cannot know who else handles your data.

#5. Where is the data stored and accessed?

Find the region where data is stored, whether you can pick it, and whether staff outside the EEA can access it, for example for support. Remote access can count as a transfer. Our page on data location explains how to record it. A region often depends on how you set up your account, so check your own settings and not only the marketing page.

#6. Which transfer tool applies?

If any processing or access happens outside the EEA, you need a transfer tool under Chapter V of the GDPR: an adequacy decision, certification under the EU-US Data Privacy Framework for US companies, or Standard Contractual Clauses. Check the vendor's name on the Data Privacy Framework list and note the date, and see whether its DPA includes SCCs as a fallback. Our guide to international data transfers explains each option.

#7. What security evidence is there?

Look for concrete measures: encryption, access control, logging, backups, staff training. Vendors often add certificates or audit reports. Treat them as evidence about a defined scope on a given date, not as a verdict on your use case.

Ask also whether the vendor offers two-step sign-in and roles on its own product.

#8. How fast do they report a breach?

If the vendor is a processor, Article 33(2) requires it to notify you without undue delay after becoming aware of a breach. You then have your own clock: 72 hours to notify the authority, where it is required. Many DPAs state a specific number of hours. Make sure it is short enough to work with that deadline. Our guide to the 72-hour rule shows what to do next.

#9. What happens at the end of the contract?

Article 28(3)(g) says the processor must delete or return the data at your choice when the service ends, unless the law requires storage. Check how you export, how long deletion takes and whether backups are covered. Ask what happens if you stop paying, since some tools take content offline immediately.

#10. Can you check them?

Article 28(3)(h) requires the processor to give you the information needed to show compliance and to allow and contribute to audits. For small buyers, the realistic form is access to reports, a security questionnaire answer or a call with the vendor. Note what is on offer and what you did with it.

#11. Retention, secondary use and AI training

Read the terms and the DPA for three things:

• Retention. How long does the vendor keep your data and logs while you use the service?
• Secondary use. May the vendor use your data to improve its products, for analytics or for marketing? That may make it a controller for that use.
• AI training. If the product includes AI features, does the vendor use your content to train models? Is it off by default, and can you control it?

Look for a plain statement. If the answer depends on a plan or a setting, write down which one you rely on.

#12. What cookies or trackers does the vendor add to your site?

Embedded forms, chat widgets, video players, maps and analytics add scripts and cookies to your pages. Under the ePrivacy Directive, Article 5(3), non-essential ones need consent before they load. Ask the vendor for a list of cookies and what each does, then sort them into necessary, statistics, marketing and preferences. Our guide to cookie consent explains what must be blocked, and a scan of your site in a real browser shows what actually loads.

#How do you record the result?

A check that lives in your head disappears when the next person takes over. For each vendor, write down:

• the vendor, the service and the purpose,
• its role,
• the DPA link, the date you accepted it, and a saved copy,
• the data it handles,
• its region and the transfer tool,
• the date of your review and who did it,
• open points and when you will revisit them.

Privacyboard keeps those records in a vendor list. You can add vendors from a catalog of 550+ common tools, where each entry holds the purpose, the data, a suggested role and a link to the vendor's published DPA. Entries come from the vendors' own public documentation and are reviewed in batches. They are starting points: roles and regions can depend on your plan, so confirm them in your own account. The same catalog is public in the vendor guide, and the list feeds the privacy policy, DPA, register and privacy center. Read more on the vendor list feature page. It does not monitor vendors' terms for you, so keep a review date.

#A short checklist to keep

1. Role confirmed and written down.
2. DPA found, accepted and saved with a date.
3. Article 28(3) points checked.
4. Sub-processor list found and change notice set up.
5. Region and remote access noted.
6. Transfer tool identified for any transfer outside the EEA.
7. Security evidence read for scope and date.
8. Breach notification time noted.
9. Deletion and export terms understood.
10. Audit information requested if the data is sensitive.
11. Retention, secondary use and AI training checked.
12. Cookies and trackers listed and handled in your banner.

#FAQ

#Do I need to do this for every tool?

For every tool that handles personal data, yes, but the depth can match the risk. A low-risk tool with a standard DPA needs a short check. A tool that handles sensitive data or many people's data deserves a closer look.

#What if the vendor will not negotiate its DPA?

Most small buyers accept the vendor's standard DPA. Check that it covers Article 28(3) and your transfers, record your decision, and switch tools if a vital point is missing.

#Are ISO 27001 or SOC 2 reports enough?

They are useful evidence about security within a defined scope and period. They are not a full privacy review and say nothing about your contract terms, data location or secondary use.

#How often should I review a vendor?

When you add or change how you use it, when the vendor announces a sub-processor or terms change, and at least once a year for tools that handle personal data.

#Who is responsible if a vendor has a breach?

You remain responsible as the controller for choosing a processor with sufficient guarantees, and the processor has its own duties under the GDPR. The contract sets how each side acts.

#Should I publish my vendor list?

Many customers expect it, and sub-processor lists are common for companies that process data for others. Our guide to the privacy center shows how.

#Sources

• Regulation (EU) 2016/679 (GDPR), Articles 28, 32, 33 and 44 to 49, EUR-Lex
• Commission Implementing Decision (EU) 2021/915 on controller-processor clauses, EUR-Lex
• Commission Implementing Decision (EU) 2021/914 on Standard Contractual Clauses for transfers, EUR-Lex
• EDPB Opinion 22/2024 on obligations following from the reliance on processors and sub-processors
• ePrivacy Directive 2002/58/EC, Article 5(3), EUR-Lex
• EU-US Data Privacy Framework: list of participants