How to Audit Third-Party Data Processors Under GDPR

Every organisation that engages a third-party vendor to process personal data on its behalf must ensure that vendor provides "sufficient guarantees" under GDPR Article 28. This is not a contractual formality — it is a substantive accountability obligation, and supervisory authorities treat inadequate processor management as a serious compliance failure that reflects on the controller's overall data governance.

This guide covers what a data processor is, what Article 28 requires, how to audit processors effectively, and how to manage the ongoing obligations that come with your processor relationships.

What Is a Data Processor

Article 4(8) of GDPR defines a processor as "a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller." The key phrase is "on behalf of" — a processor acts on the controller's instructions and processes data for the controller's purposes, not its own.

Common examples of processors include: cloud hosting providers, payroll bureaus, email marketing platforms, CRM systems, HR software vendors, customer support tools, and any analytics platform that processes personal data you provide or generate. A vendor that processes personal data only for its own purposes — such as an analytics company that aggregates your data with others for its own insights product — is not a processor; it is a joint controller or independent controller, and different rules apply.

The distinction matters because Article 28 requirements attach specifically to processor relationships. Getting the classification wrong — treating an independent controller as a processor — leads to incorrect contractual structures and potential liability misalignment.

Article 28 Requirements

Article 28 imposes two primary obligations on controllers:

1. Use only processors providing sufficient guarantees. Before engaging a processor, you must assess whether it provides "sufficient guarantees to implement appropriate technical and organisational measures" such that processing will meet GDPR requirements and protect data subjects' rights. "Sufficient" is not defined in the regulation — it requires genuine assessment, not a checkbox exercise.

2. Enter into a Data Processing Agreement (DPA). Every controller-processor relationship must be governed by a contract or other legal act binding the processor with respect to the controller.

What a DPA Must Contain (8 Mandatory Clauses)

Article 28(3) specifies that the DPA must stipulate that the processor:

1. Processes personal data only on documented instructions from the controller, including with regard to transfers to third countries, unless required by EU or member state law (in which case the processor must inform the controller unless prohibited).
2. Ensures that persons authorised to process the personal data are under a confidentiality obligation or are subject to a statutory obligation of confidentiality.
3. Implements appropriate technical and organisational security measures under Article 32.
4. Respects the conditions for engaging sub-processors — specifically, requiring prior written authorisation from the controller, and flowing down equivalent obligations to any sub-processor.
5. Assists the controller in fulfilling obligations to respond to data subject rights requests (access, rectification, erasure, restriction, portability, objection) given the nature of the processing.
6. Assists the controller with security, breach notification, DPIA, and prior consultation obligations, taking into account the nature of the processing and information available to the processor.
7. Deletes or returns all personal data to the controller on termination of the processing services, and deletes existing copies unless EU or member state law requires storage.
8. Makes available all information necessary to demonstrate compliance and allows for and contributes to audits and inspections by the controller or a mandated auditor.

These eight clauses are the minimum. Many DPAs include additional provisions on incident response timelines, data breach notification, and specific security standards.

How to Audit Processors

Audit rights in a DPA are worthless unless exercised. A practical processor audit programme has three components:

Pre-Engagement Assessment

Before signing a DPA, conduct a questionnaire-based assessment covering: the vendor's security policies and certifications; where personal data is stored and processed (data residency); sub-processor list and how sub-processors are managed; breach notification capabilities and track record; staff training and background check procedures; and data deletion/return procedures.

Certifications to look for: ISO 27001 (information security management) and SOC 2 Type II (security, availability, confidentiality controls) are the two most relevant. ISO 27001 certification from an accredited certification body is a strong indicator of a mature security programme. SOC 2 Type II reports should be reviewed rather than just acknowledged — look at the exceptions section, not just the opinion.

These certifications reduce but do not eliminate the need for direct assessment. A vendor can be ISO 27001 certified and still have GDPR-specific gaps.

Contractual Audit Rights

Ensure the DPA includes clear audit rights — the right to conduct audits of the processor's processing activities and security measures, either directly or via an appointed third party. Large processors (cloud hyperscalers, major SaaS platforms) often resist direct audits and instead provide audit reports (SOC 2, ISO 27001 certificates) in lieu. This is acceptable in many cases under Article 28(3)(h), but retain the contractual right to conduct direct audits where circumstances require it.

Annual Review

At minimum annually, review the processor's compliance posture: has their certification lapsed, have there been security incidents, have they changed their sub-processor list in ways that require assessment, have their terms changed? Many vendors notify customers of DPA and sub-processor changes — implement a process to review these notifications rather than accept them automatically.

Sub-Processor Management (Article 28(2))

Article 28(2) requires that processors obtain authorisation from the controller before engaging a sub-processor. There are two authorisation models:

Specific authorisation: The controller approves each sub-processor individually before the processor engages them. Provides maximum control but is operationally intensive for processors with large or frequently changing sub-processor lists.

General authorisation: The controller gives advance approval for categories of sub-processors or allows the processor to add sub-processors with prior notice. Most large SaaS vendors operate this model. The key requirement is that the processor informs the controller of intended sub-processor changes and the controller retains the right to object.

Maintain a sub-processor register as part of your processor management programme. When a processor notifies you of a sub-processor change, assess the new sub-processor's compliance posture before the 30-day objection window expires.

International Transfer Addenda (Article 46 SCCs)

Where a processor (or sub-processor) processes personal data outside the EEA, you need a transfer mechanism under Article 46. The European Commission's Standard Contractual Clauses (SCCs, adopted June 2021) are the standard mechanism. The Module 2 SCCs (controller to processor) should be incorporated into or annexed to your DPA.

Incorporating SCCs is not sufficient on its own — you must also conduct a Transfer Impact Assessment (TIA) for each transfer destination, evaluating whether the legal framework of the recipient country provides equivalent protection to the EEA. Document your TIA methodology and conclusions.

Maintaining a Processor Register

As part of your Article 30 ROPA, maintain a processor register that records: the processor's name and contact details; the categories of processing carried out; sub-processors used; data transfer destinations and transfer mechanisms; the DPA reference and version; and the date of last review. This register is the accountability artefact that demonstrates your processor management programme to a supervisory authority.

Annual review is the minimum — build triggers into your procurement and vendor management process so the register is updated whenever a new processor is engaged, a DPA is amended, or a sub-processor change notification is received.

---

Last updated: May 2026. For informational purposes only — not legal advice.

Frequently Asked Questions

We use hundreds of SaaS tools — do we need individual DPAs with all of them?

Yes, if they process personal data on your behalf. In practice, most SaaS vendors provide standard DPA documentation accessible via their website or on request, and you should execute or accept these before the tools go into active use with personal data. The standard to apply when selecting a DPA is whether it contains all eight Article 28(3) elements. Some vendor DPAs are inadequate — they lack proper audit rights, do not address sub-processor management, or omit the data deletion obligation. Where a vendor's standard DPA has material gaps, you should negotiate amendments or, if they refuse, assess whether the processing risk justifies proceeding and document your assessment.

What does "sufficient guarantees" mean in practice for a small vendor with no certifications?

For vendors without ISO 27001 or SOC 2, "sufficient guarantees" must be demonstrated through alternative means. Request evidence of security policies (acceptable use, access control, patch management, incident response), information about how personal data is protected in transit and at rest, staff training practices, and any penetration testing results. The EDPB guidance on Article 28 acknowledges that smaller vendors may not hold formal certifications but still need to provide substantive evidence of appropriate security measures. Document your assessment — the existence of a reasoned assessment is itself part of accountability under Article 5(2), even if the conclusion is that certain residual risk remains.

What happens when a processor suffers a data breach?

Under Article 28(3)(f), the processor must notify you without undue delay after becoming aware of a personal data breach. Your DPA should specify a notification timeline — typically 24 or 48 hours — and the content of the notification (nature of the breach, categories and approximate number of records affected, contact point at the processor, likely consequences, measures taken). Once notified, you as the controller take on the GDPR Article 33 obligation to assess whether the breach is likely to result in a risk to data subjects and, if so, notify your supervisory authority within 72 hours of becoming aware. The processor's notification to you starts your 72-hour clock.

Sources

• EUR-Lex, Regulation (EU) 2016/679 (GDPR), Articles 4(8), 28, and 46: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX%3A32016R0679
• European Data Protection Board, Guidelines 07/2020 on the concepts of controller and processor: https://edpb.europa.eu/our-work-tools/our-documents/guidelines/guidelines-072020-concepts-controller-and-processor_en
• European Commission, Standard Contractual Clauses for international transfers (2021): https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en
• ICO (UK), Contracts and liabilities between controllers and processors — detailed guidance: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/contracts-and-liabilities/contracts-and-liabilities-between-controllers-and-processors-multi-topic-guide/