Every time an organisation shares personal data with a third-party supplier, it creates a privacy relationship that needs to be understood before the contract is signed. The supplier might be a cloud provider, payroll bureau, HR platform, marketing tool, analytics service, call centre, IT support company, recruitment platform, or software vendor. Each relationship can involve different legal responsibilities.

The key question is not simply, “Are we sharing data?” The real question is, “What role is each party playing?” A supplier may be a data processor, an independent controller, or a joint controller. That classification determines what contract is required, which obligations apply, who must respond to individuals, what happens if there is a breach, and where liability may sit.

Vendor privacy management is one of the most operationally demanding areas of a privacy programme. It requires legal review, procurement controls, security assessment, contract negotiation, risk scoring, ongoing monitoring, and clear ownership. It is also one of the areas most often handled poorly. Organisations sometimes rely on vendor assurances, generic confidentiality clauses, or standard terms that do not meet UK GDPR requirements.

This guide explains data processing agreement requirements GDPR teams need to understand, the difference between processor and controller relationships, and how to build a vendor management process that protects your organisation.

What is the difference between a data processor, a data controller, and a joint controller in a supplier relationship?

Before choosing the right contract, you need to classify the relationship correctly. This should be based on what the parties actually do with the data, not what the contract happens to call them.

Data controller: the party that determines the purpose and means of personal data processing

A controller decides why personal data is processed and how the main processing activities are carried out. If your organisation decides to collect customer data for marketing, employee data for payroll, or user data for analytics, it is likely acting as a controller for those purposes.

A supplier can also be an independent controller if it uses the data for its own purposes. For example, some professional advisers, insurers, payment providers, or fraud prevention services may act as controllers depending on the service and the level of independence they have.

Data processor: the party that processes personal data strictly on the controller’s instructions

A processor processes personal data on behalf of the controller and only on the controller’s documented instructions. Examples may include a payroll provider, cloud hosting provider, outsourced IT provider, email delivery platform, or HR system vendor, depending on the arrangement.

This is where a Data Processing Agreement, or DPA, is required. A processor cannot decide to use the personal data for unrelated purposes. If it does, it may become a controller for that processing and create serious compliance risk.

Joint controller: when two or more parties share the purpose and means of processing

Joint controllers decide the purposes and means of processing together. This does not mean both parties do exactly the same work. One may operate the platform while the other manages the customer relationship. The key issue is whether they jointly determine why and how the personal data is processed.

A joint controller agreement GDPR arrangement should clearly explain each party’s responsibilities, including transparency, individual rights handling, security, breach response, and communication with individuals.

Why getting the classification wrong creates legal liability — and how courts and regulators have ruled

Incorrect classification can lead to the wrong contract, poor transparency, weak accountability, and unclear breach responsibility. Calling a supplier a processor does not make it one. Regulators and courts look at the reality of the processing relationship.

If a vendor makes independent decisions about purposes, it may be a controller. If two parties jointly design a shared service and both influence the purpose and means, they may be joint controllers. Privacy teams should therefore classify vendors before contract signature, not after an incident.

What must a Data Processing Agreement contain to comply with GDPR Article 28?

Article 28 UK GDPR requires a contract or other legal act between a controller and processor. This contract must include specific terms. A standard services agreement or non-disclosure clause is not enough.

The eight mandatory elements of a GDPR-compliant DPA — line by line

The DPA Article 28 requirements include several mandatory elements. The contract must set out the subject matter and duration of processing, the nature and purpose of processing, the type of personal data, the categories of data subjects, and the obligations and rights of the controller.

It must also require the processor to process data only on documented instructions, ensure confidentiality, apply appropriate security measures, follow rules on sub-processors, help the controller respond to individual rights requests, assist with security and breach obligations, delete or return personal data at the end of the service, and make information available to demonstrate compliance.

These terms should be specific. A vague statement that the vendor “will comply with data protection laws” is not enough.

Sub-processor obligations: the notification requirement and the flow-down of terms

Processors often use sub-processors, such as cloud infrastructure providers, support platforms, data centres, or specialist service providers. The controller should know who these sub-processors are and how changes will be managed.

Sub-processor GDPR obligations usually require prior specific or general written authorisation from the controller. Where general authorisation is used, the processor should notify the controller of intended changes so the controller has an opportunity to object. The processor must also flow down equivalent data protection obligations to the sub-processor.

Audit rights: what a compliant DPA must entitle the controller to do — and what vendors routinely resist

Article 28 requires processors to make available the information needed to demonstrate compliance and allow for audits or inspections. In practice, vendors may resist broad audit rights, especially large SaaS providers.

A practical compromise may include independent audit reports, security certifications, compliance documentation, penetration test summaries, or structured questionnaires. However, privacy teams should ensure the controller still has meaningful assurance. Audit rights should not be removed entirely or replaced with empty assurances.

Data deletion and return at contract end: the specific obligations Article 28 imposes

At the end of the services, the processor must delete or return personal data, depending on the controller’s choice, unless law requires storage. The contract should explain how this happens, what timelines apply, whether backups are included, and whether deletion certificates or confirmation will be provided.

This is often neglected. Without clear exit terms, data may remain in vendor systems long after the business relationship ends.

The difference between a DPA and a standard confidentiality or non-disclosure clause

A confidentiality clause protects information from unauthorised disclosure. A DPA does much more. It governs processing instructions, security, sub-processors, individual rights, breach support, audits, deletion, international transfers, and accountability.

A non-disclosure agreement may be useful, but it does not replace Article 28. The GDPR vendor contract clauses must address the legal processing relationship, not only secrecy.

How should organisations assess vendor privacy risk before onboarding a new supplier?

Vendor contracting should not begin with the legal document. It should begin with risk assessment.

Vendor risk classification: a tiered, risk-based approach to due diligence

A low-risk supplier that receives only business contact details does not need the same review as a cloud platform storing customer records or an artificial intelligence tool analysing employee behaviour.

A tiered model may classify vendors as low, medium, high, or critical risk based on data sensitivity, volume, access level, processing purpose, system integration, transfer location, and business importance. This supports proportionate due diligence.

The due diligence questionnaire: the privacy and security questions to ask before signing

A data processor due diligence checklist should ask what personal data the vendor processes, where it is stored, who can access it, whether sub-processors are used, how data is secured, how breaches are reported, how deletion works, and whether international transfers occur.

It should also ask for policies, certifications, audit reports, incident history, retention details, and evidence of staff training.

Security certifications as proxy evidence: ISO 27001, SOC 2, and Cyber Essentials assessed

Certifications such as ISO 27001, SOC 2, and Cyber Essentials can provide useful assurance, but they are not a substitute for legal review. A certificate may show that controls exist, but it may not cover the exact service, region, data flow, or processing activity you are using.

Privacy teams should review scope, date, exclusions, and relevance.

High-risk vendor scenarios: what additional scrutiny is required and how to document it

High-risk vendors may include those processing special category data, large volumes of customer data, children’s data, employee monitoring data, financial data, health data, biometric data, or data used for profiling and automated decision-making.

Additional scrutiny may include a Data Protection Impact Assessment, security review, legal review, executive approval, transfer risk assessment, and enhanced contractual controls.

Reviewing a vendor’s own privacy policy and standard data processing terms

Many vendors provide standard terms. These should be reviewed carefully. Check whether the vendor’s privacy policy suggests it uses customer data for its own purposes. Check whether the DPA includes all Article 28 terms. Check whether sub-processors, transfer mechanisms, breach timelines, and deletion rules are acceptable.

This is the core of a strong vendor privacy risk assessment.

How do international data transfers affect vendor contracts and what must be in place?

Vendor contracts become more complex when personal data is transferred outside the UK or European Economic Area.

When a vendor processes or stores data outside the UK or EU

An international transfer may occur if personal data is sent to, accessed from, or stored in a country outside the relevant protection framework. Cloud providers can create hidden transfer issues because support, hosting, backup, and sub-processing may occur in multiple countries.

Privacy teams should not ask only where the vendor is headquartered. They should ask where data is hosted, where support staff can access it, and where sub-processors operate.

UK IDTA versus EU Standard Contractual Clauses: which mechanism applies and how they interact

For UK transfers, organisations may use the UK International Data Transfer Agreement, known as the IDTA, or the UK Addendum to the EU Standard Contractual Clauses, depending on the arrangement. For EU transfers, the EU Standard Contractual Clauses may be relevant.

International data transfer vendor contracts should clearly state which mechanism applies. If both UK and EU data are involved, the contract may need both EU SCCs and the UK Addendum.

Transfer Impact Assessments: when they are required, what they must cover, and how to document them

A Transfer Impact Assessment, or TRA, assesses whether the transfer mechanism provides appropriate protection in practice. It may consider the destination country, laws and practices, the type of data, access risks, technical safeguards, contractual controls, and supplementary measures.

The TRA should be documented and linked to the vendor record.

Cloud providers and international transfers: the hidden transfer complexity in standard SaaS agreements

Standard SaaS agreements often include global hosting, support, diagnostics, telemetry, and sub-processors. A cloud vendor may process data in one country but allow support access from another. Backups may be stored in a different region.

Privacy teams should map these flows carefully before approving the vendor.

How should an organisation manage vendor privacy relationships on an ongoing basis?

Vendor risk does not end at contract signature. Suppliers change systems, add sub-processors, update terms, suffer incidents, and change business models.

Building and maintaining a processor register — and integrating it with the ROPA

A processor register should record each processor, processing activity, data categories, system owner, contract status, sub-processors, transfer mechanisms, risk rating, review date, and business owner.

This should link to the Record of Processing Activities, or ROPA. If the ROPA says a processor handles payroll data, the processor register should show the contract, DPA, risk review, and transfer details.

Annual vendor reviews: what to assess, how to score risk, and how to document findings

Annual reviews should check whether the vendor still provides the same service, whether data categories have changed, whether sub-processors have changed, whether security certifications remain valid, whether any incidents occurred, and whether contract terms still meet requirements.

High-risk vendors may need more frequent review.

Sub-processor change notifications: what your DPA should require and what to do when you receive one

When a vendor notifies you of a sub-processor change, do not ignore it. Assess the new sub-processor, location, service provided, data involved, transfer mechanism, and objection deadline.

Record your decision. If the change creates unacceptable risk, follow the objection process in the DPA.

Managing a supplier breach: your obligations as a controller when your processor suffers an incident

If a processor suffers a breach, the controller may still have notification and accountability obligations. The processor should notify the controller without undue delay and provide enough information to assess the incident.

Your incident response plan should include supplier breaches. Privacy, legal, security, procurement, communications, and the business owner may all need to act quickly.

FAQs

Can an organisation rely on a vendor’s own standard terms instead of a separate Data Processing Agreement?

Yes, if the vendor’s standard terms contain all required Article 28 clauses and are appropriate for the processing. A separate document is not always required, but the contractual terms must meet GDPR requirements. Privacy teams should review the terms rather than assuming they are adequate.

Who is liable if a data processor causes a data breach — the processor or the controller?

Both may face risk, depending on the facts. A processor can have direct obligations and liability under UK GDPR, and may also be contractually liable to the controller. The controller remains responsible for choosing suitable processors and managing the relationship. Liability will depend on the cause of the breach, contractual terms, and each party’s role.

What should an organisation do if a vendor refuses to sign a DPA or provide audit rights?

Treat this as a risk warning. Ask whether the vendor’s standard terms meet Article 28. If they refuse to provide required protections, the organisation should consider whether the vendor can lawfully be used. For high-risk processing, refusal to provide meaningful assurance may justify rejecting the supplier.

Conclusion

Vendor privacy risk is one of the most significant and growing sources of data protection exposure. Organisations increasingly rely on cloud platforms, outsourced services, analytics tools, artificial intelligence providers, and specialist vendors. Each relationship can introduce legal, operational, security, and reputational risk.

A robust approach to vendor classification, DPA negotiation, international transfer review, sub-processor management, and ongoing supplier oversight is not an administrative nicety. It is a direct risk management function.

Stop relying on vendor assurances. Our Vendor Risk And Data Processing Agreements For Privacy course gives your privacy and procurement teams a rigorous, repeatable process for managing supplier data risk.

For related learning, explore Data Mapping And Records Of Processing Activities ROPA, Privacy Impact Assessments PIA And DPIA Practical Workshop, and Privacy Incident Response And Breach Notification Basics.