Governance plays a central role in managing vendor and processor agreements under GDPR. Organisations acting as data controllers are legally required to ensure that every processor handling personal data on their behalf operates under a binding written contract that reflects GDPR obligations. Without structured, continuous governance, those agreements quickly become outdated, unmonitored, and legally exposed. The sections below walk through the most common questions organisations face when building and maintaining processor agreement oversight.

If you have questions about how this applies to your organisation, feel free to get in touch with us, and we will be happy to help.

What obligations does GDPR place on organisations managing processors?

Under GDPR, a data controller is legally required to use only processors that provide sufficient guarantees of technical and organisational measures to protect personal data. This obligation extends beyond selecting the right vendor at the start of a relationship. Controllers must actively ensure ongoing compliance, document their processor relationships, and verify that processing activities remain within agreed boundaries throughout the contract lifecycle.

Article 28 of GDPR is the central reference point. It requires that any processing by a processor is governed by a contract or other legal act that is binding on the processor. The contract must set out the subject matter, duration, nature, and purpose of the processing, the type of personal data involved, and the categories of data subjects. Critically, it must also specify the obligations and rights of the controller.

Beyond the contract itself, controllers must be able to demonstrate compliance. This means maintaining records of processing activities under Article 30, conducting due diligence before engaging processors, and periodically reviewing whether processors continue to meet the required standards. GDPR does not treat processor management as a one-time task. It is an ongoing responsibility that demands structured attention.

What must a data processing agreement include under GDPR?

A data processing agreement (DPA) under GDPR must include a defined set of provisions that bind the processor to specific obligations. At minimum, the agreement must state that the processor acts only on documented instructions from the controller, ensures confidentiality obligations are in place for all personnel with access to the data, implements appropriate technical and organisational security measures, assists the controller in fulfilling data subject rights, and deletes or returns data at the end of the contract.

The agreement must also address sub-processing. Processors must not engage another processor without prior written authorisation from the controller, either specific or general. Where general authorisation is given, the processor must inform the controller of any intended sub-processor changes, giving the controller the opportunity to object.

Additionally, the DPA must grant the controller the right to conduct audits or inspections, either directly or through a mandated third party. This audit right is not optional. It is a GDPR requirement that ensures the controller retains practical oversight of how the processor handles personal data. Agreements that omit or water down this right are non-compliant on their face.

How does governance prevent processor agreement drift over time?

Processor agreement drift occurs when the actual processing activities carried out by a vendor diverge from what the data processing agreement originally captured. This happens gradually as business relationships evolve, services are expanded, new data categories are introduced, or sub-processors are quietly added. Continuous governance prevents this drift by treating processor agreements as living documents subject to regular review, not static artefacts filed away after signing.

Effective governance creates a structured cycle around processor relationships. This includes scheduled reviews of DPAs against current processing activities, change management procedures that trigger agreement updates when services are modified, and monitoring mechanisms that flag when processors notify changes to their sub-processor chains. Without this cycle, organisations routinely discover during audits or incidents that their agreements no longer reflect reality.

The challenge is that drift is rarely dramatic. A processor adds a new analytics tool. A SaaS vendor migrates infrastructure to a different cloud region. A supplier expands its support team to a third country. Each change individually seems minor, yet collectively they can shift the risk profile of a processing relationship significantly. Governance provides the institutional discipline to catch and address these changes before they become compliance gaps. This is precisely the kind of structural, always-active oversight that we design our governance services around.

Who within an organisation is responsible for managing processor agreements?

Responsibility for managing processor agreements sits with the data controller as a legal entity, but within an organisation it is typically distributed across several functions. Legal or compliance teams own the contractual framework and ensure DPAs meet GDPR requirements. Procurement or vendor management teams handle the operational relationship. The Data Protection Officer, where one is appointed, provides oversight and guidance. IT and security teams assess the technical measures processors claim to have in place.

The challenge is that when responsibility is spread across functions without clear coordination, gaps appear. A procurement team might onboard a new vendor without involving legal. An IT team might approve a tool without triggering a DPA review. Effective governance addresses this by establishing clear role-based accountability, ensuring that every processor relationship has a named owner and a defined review process rather than relying on informal knowledge held by individuals.

Management ownership is essential here. Processor agreement compliance cannot be treated as a purely technical or legal function. Senior leadership must understand the organisation’s processor landscape, approve material processing relationships, and ensure adequate resources exist to maintain oversight. GDPR accountability flows upward to the board, which means the governance structures supporting processor management must be visible at that level.

What happens when a processor fails to meet GDPR requirements?

When a processor fails to meet GDPR requirements, the legal and operational consequences fall primarily on the controller. Under GDPR, a processor that determines the purposes and means of processing beyond its instructions becomes a controller itself and bears direct liability for that excess processing. However, for failures within the scope of the agreed relationship, the controller remains accountable to supervisory authorities and data subjects for ensuring the processor was properly selected and supervised.

In practice, a processor failure can trigger several consequences. Supervisory authorities may investigate the controller for failing to conduct adequate due diligence or for using a processor that did not provide sufficient guarantees. Data subjects may exercise their rights or bring complaints. The controller may face fines, reputational damage, and operational disruption, particularly if the failure involves a personal data breach that must be notified under Article 33.

The DPA itself becomes central in these situations. A well-drafted agreement gives the controller contractual remedies against the processor, including the right to terminate, demand remediation, and seek indemnification. An inadequate or missing DPA leaves the controller exposed with no enforceable recourse against the vendor. This is why governance around agreement quality, not just agreement existence, matters so much.

How should organisations handle sub-processors under GDPR?

Organisations should manage sub-processors by maintaining a clear, up-to-date record of all sub-processing relationships authorised within each processor engagement. Before authorising a sub-processor, the controller should ensure the processor has imposed on that sub-processor the same data protection obligations that exist in the main DPA. The sub-processor chain must be traceable, documented, and subject to the same level of scrutiny as the primary processor relationship.

GDPR requires that processors obtain either specific or general written authorisation from the controller before engaging sub-processors. General authorisation is common in practice, particularly with cloud-based services where sub-processor lists can change frequently. However, general authorisation must still include a mechanism for the processor to notify the controller of changes, giving the controller a genuine opportunity to object before the change takes effect.

Organisations often underestimate the complexity of sub-processor management. A single SaaS tool may rely on dozens of sub-processors spanning multiple jurisdictions, including countries outside the European Economic Area. Each international transfer must have an appropriate legal basis, such as Standard Contractual Clauses. Governance structures that track sub-processor notifications, assess transfer risks, and document authorisation decisions are not optional extras. They are the operational backbone of GDPR compliance for any organisation with a diverse vendor landscape.

Managing processor and sub-processor agreements under GDPR is not a one-time legal exercise. It is a continuous governance responsibility that demands clear ownership, structured review cycles, and the organisational discipline to keep agreements aligned with reality. If you want to build that kind of permanent governance capability in your organisation, contact us, and we will show you how we can help.

Frequently Asked Questions

How often should we formally review our data processing agreements?

As a general rule, DPAs should be reviewed at least annually, but certain triggers should prompt an immediate review regardless of schedule. These include significant changes to the services provided, a processor notifying changes to their sub-processor list, a personal data breach, changes to applicable law or regulatory guidance, or contract renewal. Building these triggers into your vendor management process ensures reviews happen when they matter most, not just on a calendar basis.

What is the difference between a data processing agreement and a standard vendor contract?

A standard vendor contract governs the commercial relationship — pricing, service levels, liability, and termination. A data processing agreement is a legally required instrument under GDPR that specifically governs how personal data is handled within that relationship. The two can exist as separate documents or be combined, but the DPA provisions must stand on their own and meet the specific requirements of Article 28. A commercial contract alone, even a detailed one, does not satisfy the GDPR obligation.

Can we rely on a processor's standard DPA template, or do we need to negotiate our own?

Many processors, particularly large SaaS and cloud vendors, offer their own standard DPA templates, and in some cases these are GDPR-compliant on their face. However, relying on them without review is a risk. Standard templates are drafted to protect the processor's interests and may omit or dilute provisions that matter to your organisation, such as audit rights, breach notification timelines, or sub-processor controls. At minimum, you should review any template against your own compliance requirements before signing.

What practical steps can we take right now if we suspect our processor agreements are out of date?

Start by conducting a rapid audit of your current processor landscape — compile a list of all vendors handling personal data on your behalf and check whether a signed DPA exists for each one. For agreements that do exist, compare the processing activities described in the DPA against what the vendor actually does today. Prioritise the highest-risk relationships, such as those involving sensitive data categories or large volumes of data subjects, and address those first. Even a structured gap analysis is a meaningful and defensible first step toward compliance.

Do we need a DPA with every vendor, or only those handling sensitive personal data?

The GDPR requirement applies to any processor handling personal data on your behalf, not only those processing sensitive categories. If a vendor processes any personal data — including names, email addresses, or IP addresses — under your instruction, a binding DPA is required. The risk level may influence how detailed your due diligence is, but it does not change whether a DPA is legally necessary. Organisations that limit DPAs to high-risk vendors are routinely exposed when lower-profile vendor relationships come under scrutiny.

How do we handle processors based outside the European Economic Area?

When a processor is located outside the EEA, the DPA must be accompanied by a valid international transfer mechanism. The most commonly used mechanism is the European Commission's Standard Contractual Clauses (SCCs), which must be incorporated into or appended to the DPA. You must also carry out a Transfer Impact Assessment to evaluate whether the legal environment in the destination country undermines the protections the SCCs provide. This is not a formality — regulators have taken enforcement action against organisations that transferred data on the basis of SCCs without conducting the required assessment.

What common mistakes do organisations make when setting up processor governance for the first time?

The most common mistake is treating DPA compliance as a one-time legal task rather than an ongoing operational process — getting agreements signed and then filing them away without any review cycle. A second frequent error is failing to assign clear ownership, leaving processor relationships managed informally across teams with no single accountable person. Organisations also commonly overlook sub-processors entirely, focusing only on the primary vendor relationship while the downstream processing chain goes untracked. Building a simple register, assigning named owners, and scheduling periodic reviews addresses all three of these gaps from the outset.

Related Articles

Share

  • June 8, 2026