10 Questions to Ask Your Data Processor (Template)
Every organisation that uses a SaaS tool, a payroll provider, a marketing agency, or a cloud host is a data controller relying on a data processor. Under Article 28 GDPR, that relationship must be governed by a written data processing agreement (DPA). But a signed DPA is not the same as a safe one. The questions you ask before you sign determine whether that agreement actually protects you.
This post gives you the 10 questions to ask any data processor, why each one matters under Article 28, and a reusable template you can adapt for your own vendor due diligence.
What Article 28 GDPR requires of a data processor
Article 28 sets out the obligations a processor must accept. A compliant DPA must cover, at minimum:
- The subject matter, duration, nature, and purpose of the processing
- The type of personal data and categories of data subjects involved
- The controller's rights and obligations
- That the processor only acts on documented instructions from the controller
- That the processor keeps personal data confidential
- That the processor implements appropriate technical and organisational security measures
- That the processor does not engage a sub-processor without prior authorisation
- That the processor assists the controller with data subject rights, security, and breach notification
- That the processor deletes or returns personal data at the end of the engagement
- That the processor makes available information needed to demonstrate compliance and allows audits
The 10 questions below are designed to test whether a processor's DPA actually delivers each of these. A processor that answers clearly is a processor you can work with. A processor that hedges is a risk you should price in.
The 10 questions
1. What exactly do you process, and why?
Ask the processor to state the specific personal data they receive and the purpose of the processing. This should map to the subject matter and purpose clauses of the DPA. If the processor cannot describe what they process, they cannot document it, and you cannot rely on them to process it only on your instructions.
2. Who are the sub-processors, and how do you authorise them?
Article 28(2) requires a processor to obtain your prior specific or general written authorisation before engaging a sub-processor. Ask for the full list of sub-processors, what each one does, and how you will be notified of changes. A processor that refuses to name its sub-processors is a red flag.
3. Where is the data processed?
Data location matters for two reasons: security and transfers. Ask which countries the data is processed in, and whether any processing happens outside the UK, EU, or EEA. If it does, ask what transfer mechanism applies, such as adequacy regulations, standard contractual clauses, or another safeguard under Article 46.
4. What security measures do you have in place?
Article 28(3)(c) requires the processor to implement appropriate technical and organisational measures. Ask for specifics: encryption at rest and in transit, access controls, multi-factor authentication, logging, and how they handle security incidents. Ask whether they hold an independent certification such as ISO 27001 or SOC 2, and whether you can see the report.
5. How do you help me respond to data subject requests?
Under Article 28(3)(e), the processor must assist the controller in fulfilling its obligations to respond to data subject access requests. Ask how long it takes them to retrieve and return a data subject's data, and what the process is. This matters in practice. A DSAR has a one-month deadline, and your processor is part of that clock.
6. How do you notify me of a personal data breach?
Article 28(3)(f) requires the processor to notify the controller without undue delay after becoming aware of a breach. Ask for the notification SLA in hours, who to contact, and what information they provide. A processor that promises to notify you "as soon as possible" without a defined timeframe is not giving you what Article 28 requires.
7. What happens to the data when the contract ends?
Article 28(3)(g) requires the processor to delete or return all personal data at the end of the engagement. Ask whether they delete or return, how long the deletion takes, and whether they can certify deletion in writing. Also ask what happens to backups. A processor that keeps your data in backups for years after you leave is a liability.
8. Can I audit you?
Article 28(3)(h) gives the controller the right to audit the processor's compliance. Ask whether the DPA includes an audit right, how it is exercised, and whether independent audit reports or certifications are accepted in lieu of a full audit. For most organisations, a current SOC 2 or ISO 27001 report is a practical substitute.
9. Do you process data for your own purposes?
A processor must only act on your documented instructions. If the processor uses your data for its own analytics, product improvement, or marketing, that is a separate processing activity that needs its own lawful basis, and it changes the relationship. Ask explicitly whether they use your data for anything other than providing the service to you, and whether they train models on your production data. A responsible processor uses synthetic or anonymised data for product development, not your data.
10. What is your liability, and is it proportionate?
Article 28(3) requires the DPA to set out the processor's liability. Ask what the liability cap is, whether it covers data protection losses, and whether it is proportionate to the risk. A processor that caps liability at the value of the subscription is not taking responsibility for the data they hold on your behalf.
A template for your vendor due diligence
Use this template to record the answers and compare vendors. Copy it into a spreadsheet or document and fill in one row per processor.
| Question | What to look for | Answer | Risk (low/med/high) |
|---|---|---|---|
| 1. What do you process, and why? | Clear scope matching the DPA | ||
| 2. Who are your sub-processors? | Full list + change notification | ||
| 3. Where is the data processed? | UK/EU/EEA, or a valid transfer mechanism | ||
| 4. What security measures? | Encryption, access controls, certification | ||
| 5. How do you support DSARs? | Defined retrieval process and SLA | ||
| 6. How do you notify breaches? | Defined SLA in hours | ||
| 7. What happens at contract end? | Deletion/return + written certification | ||
| 8. Can I audit you? | Audit right or independent report | ||
| 9. Do you use data for your own purposes? | No, or a separate lawful basis | ||
| 10. What is your liability? | Proportionate, covers data protection losses |
How vendor due diligence fits your wider compliance
The answers to these questions feed directly into your Record of Processing Activities. Every processor you engage is a recipient of personal data, and Article 30 requires you to record the categories of recipients and any transfers to third countries. If you have not yet built your register, our guide to Article 30 walks through the requirements, and you can download a free RoPA template to get started.
Vendor due diligence is not a one-off exercise. Processors change their sub-processors, move infrastructure, and update their security posture. The questions above are worth re-running on a regular cycle, and the answers should be kept alongside the DPA so you can show a regulator that you have actually checked who holds your data and how.
The bottom line
A signed DPA is the starting point, not the finish line. The 10 questions above test whether a processor can actually meet the Article 28 obligations they have signed up to. Ask them before you sign, record the answers, and revisit them on a regular cycle. The processors that answer clearly are the ones worth working with.
If you are ready to move from scattered spreadsheets to a living record of who processes your data and where it flows, see pricing.