TL;DRTL;DR GDPR vendor management goes far beyond signing a DPA. Article 28 requires active due diligence, specific TOM verification, sub-processor oversight, and ongoing monitoring. Recent enforcement cases, including the ICO's first-ever processor fine, show that both controllers and processors face direct liability for security failures in the vendor chain.
Most organisations have a DPA in place with every vendor that touches personal data. That is no longer enough. The regulators have noticed.
In August 2024, the UK Information Commissioner's Office fined Advanced Computer Software Group Ltd £3.07 million for a 2022 ransomware attack that compromised the personal data of 82,946 individuals, including NHS patients. Advanced was not the controller. It was the processor. It was the first time the ICO had fined a processor directly under the UK GDPR. The central finding: Advanced had failed to implement appropriate technical and organisational measures, including multi-factor authentication on a customer account that attackers exploited to gain access. The fine was a signal, not an anomaly. Under Article 28 GDPR, the obligation to use only processors who provide sufficient guarantees to implement appropriate TOMs sits with the controller, not the processor. If your vendor assessment process does not verify those guarantees, you are carrying the risk.
By the end of 2024, cumulative GDPR fines across the EU had reached approximately €5.88 billion (Data Privacy Manager, 2025). Vendor chain failures account for a growing share. This article explains what GDPR vendor management actually requires, what a meaningful technical and organisational measures assessment looks like in practice, what a compliant DPA must contain, and what happens when organisations get it wrong. For the broader GDPR compliance framework, see our GDPR compliance guide and the GDPR guidebook.
The enforcement shift: processors are now in scope
Until 2024, EU and UK regulators focused enforcement almost exclusively on controllers. The Advanced decision changed that. The ICO confirmed directly: processors are subject to independent enforcement where their own failures cause or contribute to a breach. Article 32 GDPR imposes security obligations directly on processors. Article 28 requires controllers to verify that processors meet them. Both angles now carry enforcement risk.
What Article 28 GDPR actually requires
TL;DRTL;DR Article 28 GDPR requires controllers to use only processors who provide sufficient guarantees to implement appropriate technical and organisational measures. That is an active, ongoing obligation, not a one-time contract signature. It requires due diligence before engagement, a compliant DPA in writing, and ongoing monitoring throughout the relationship. Processors must not engage sub-processors without the controller's written authorisation.
Article 28 GDPR is deceptively short. In practice it imposes five distinct obligations that most vendor onboarding processes do not fully address.
1. Sufficient guarantees: before you sign
The controller must carry out due diligence before appointing a processor. This is not satisfied by receiving a vendor's standard terms. It requires assessing whether the processor has actually implemented measures adequate for the personal data being processed. The nature of the assessment must be proportionate to the risk: a processor handling special category health data for 80,000 individuals requires more scrutiny than a processor handling names and email addresses for a low-risk newsletter distribution service.
2. Written contract with mandatory minimum content
The DPA must exist in writing and must cover all of the elements in Article 28(3): the subject matter, duration, nature and purpose of processing, the type of personal data and categories of data subjects, and the specific obligations and rights of the controller. Critically, it must specify that the processor processes only on the controller's documented instructions, implements appropriate TOMs, assists with data subject rights, enables audits, and deletes or returns data at the end of the relationship. For more on DPA structure, see our data processing agreement guide.
3. Sub-processor authorisation
A processor must not engage sub-processors without the controller's prior written authorisation, whether specific or general. Where general authorisation is given, the processor must notify the controller of intended changes and allow the controller a right to object. This obligation chains down: sub-processors must be bound by the same data protection obligations as the processor. If your DPA with a vendor does not include a clear sub-processor notification and consent mechanism, you have a gap.
4. Article 32 security obligation: directly on processors
Article 32 requires processors to implement technical and organisational measures appropriate to the risk, including encryption, pseudonymisation, ongoing confidentiality and integrity of systems, and the ability to restore personal data after incidents. This obligation applies to the processor directly, independently of the controller. The Advanced case made clear that a processor cannot hide behind inadequate TOM verification by the controller: if the processor's own systems lacked basic controls, the processor carries enforcement risk.
In practice, what I see in data protection assessments is that this is the section most organisations handle badly: they obtain a DPA, receive a certification summary, and consider the job done. That is the gap regulators are now finding.
5. Ongoing monitoring
Due diligence at onboarding does not extinguish the Article 28(1) obligation. The EDPB's Opinion 22/2024 on processor and sub-processor obligations confirmed that controllers retain a continuous duty to verify that their processors maintain sufficient guarantees throughout the relationship. Certification (SOC 2 Type II, ISO 27001) at the point of onboarding may be insufficient if not refreshed. For more on certification-based verification, see our vendor assessment platform.
Technical and organisational measures: what verification actually looks like
TL;DRTL;DR TOMs under Article 32 cover four core areas: encryption and pseudonymisation, ongoing confidentiality and integrity of systems, ability to restore data after incidents, and regular testing of security measures. Verifying these through vendor questionnaires requires specific, evidence-backed questions, not checkbox compliance. The Advanced case identified gaps in MFA deployment, vulnerability scanning, and patch management as the specific TOMs that failed.
The term 'technical and organisational measures' appears throughout GDPR but is never exhaustively defined. That is deliberate. The measures must be appropriate to the specific risk. In practice, this creates a verification challenge: how do you know whether a vendor's TOMs are actually sufficient before you engage them, and how do you maintain that verification over time?
The following categories reflect what regulators and assessors look for in practice, drawn from the Advanced enforcement case and from standard vendor security questionnaire frameworks. For a structured approach to third-party evaluation, see our due diligence questionnaire (DDQ) guide.
Access control and authentication
The ransomware attack on Advanced succeeded because a customer account lacked MFA. Attackers accessed healthcare systems through that single point of failure. The ICO found that even partial MFA deployment, covering most but not all systems, was insufficient. Security measures must cover the entire data lifecycle, not just the majority of it.
Questions to ask vendors in this category, drawn from GDPR-specific and security questionnaire frameworks:
| Question | What you are verifying |
|---|---|
| Is multi-factor authentication enforced for all systems that process personal data, including administrative and service accounts? | Complete MFA coverage, not partial deployment |
| Does your company have a documented access control policy covering role-based access, least privilege, and periodic access reviews? | Formal governance of who can access personal data and on what basis |
| How are privileged access rights managed and logged? Are access logs reviewed, and at what frequency? | Monitoring of high-risk access, not just prevention |
| What is your process for revoking access when an employee leaves or changes role? | Timely de-provisioning (a frequent gap in processor assessments) |
Incident detection and breach notification
Article 33 GDPR requires controllers to notify supervisory authorities of breaches within 72 hours. That clock starts when the controller has reasonable awareness. If your processor does not have effective detection and notification procedures, you will miss that deadline through no fault of your own. For more on breach notification obligations, see our GDPR data breach notification guide.
| Question | What you are verifying |
|---|---|
| Does your organisation have a documented security incident response plan? When was it last tested? | Existence and currency of incident response capability |
| What is your internal procedure for identifying, assessing, and notifying controllers of a personal data breach? What is your target notification timeframe? | Whether the processor's notification timeline gives you room to meet your own 72-hour obligation |
| How often does your organisation perform vulnerability scans on systems processing personal data? Are findings tracked to remediation? | Regular scanning with documented follow-through |
| What is your target patch cycle for critical and high-severity vulnerabilities on production systems? | Timely patching, not ad hoc remediation |
| Has your organisation undergone a penetration test in the last 12 months? Are you able to share a summary of findings and remediation steps? | Independent validation and willingness to evidence it |
Encryption and data handling
| Question | What you are verifying |
|---|---|
| Is personal data encrypted at rest and in transit? What encryption standards are used? | Technical baseline for confidentiality |
| Do you use pseudonymisation or anonymisation for any personal data? In which processing contexts? | Risk reduction through technical design |
| What controls prevent personal data from being accessed, copied, or transferred outside of your agreed processing environment? | Data exfiltration controls |
| How is personal data disposed of at the end of the processing relationship or retention period? | Article 28(3)(g) deletion obligation is enforceable |
Organisational measures
Technical measures alone are not sufficient. Article 32 requires organisational measures alongside technical ones: governance, training, policies, and internal accountability structures.
| Question | What you are verifying |
|---|---|
| Does your organisation have a named individual or team responsible for information security and data protection? | Accountability structure (absence is a red flag) |
| Are employees who handle personal data trained on GDPR and data protection obligations? How often? | Organisational awareness as a TOM |
What a compliant DPA must contain
TL;DRTL;DR A GDPR-compliant DPA must go beyond the Article 28(3) minimum. It must contain a precise description of processing in an annex, a TOM schedule with specific measures rather than generic commitments, a sub-processor list with the controller's right to object, breach notification timelines consistent with the controller's 72-hour obligation, data subject rights assistance obligations, and deletion or return obligations with a defined timeline.
The DPA is both a legal document and an operational tool. In enforcement proceedings, it is also evidence. A DPA that describes the processor's security obligations as 'reasonable technical and organisational measures' tells a regulator nothing about what the controller verified before engagement. A DPA that specifies encryption standards, MFA requirements, patch cycle targets, and breach notification timelines is both harder to breach and harder to disclaim.
Processing description annex
The mandatory description of processing must cover: the subject matter and duration of the processing; the nature and purpose of processing; the types of personal data involved; the categories of data subjects; and the specific instructions the processor is authorised to follow. Vague descriptions such as 'provision of software services' are common and inadequate. If your DPA does not specify what personal data categories the processor can access, you cannot verify that access controls are appropriately scoped.
TOM schedule: the most commonly neglected section
Most DPAs include a TOM schedule. Most of those schedules are generic. A compliant TOM schedule should specify, at minimum: the encryption standard and key management approach; access control requirements including MFA; the patch management cycle; monitoring and logging requirements; incident response timelines; data retention and deletion procedures; and physical security measures where applicable. Schedules that refer to 'industry-standard security measures' are unverifiable and provide no protection in enforcement proceedings.
Sub-processor provisions
The DPA must address sub-processors explicitly. At minimum it should: list authorised sub-processors or provide a mechanism for notification of changes; require the processor to obtain the controller's written consent before engaging new sub-processors; impose equivalent data protection obligations on sub-processors; and require the processor to remain liable to the controller for sub-processor failures. For more on how to document your processing chain, see our RoPA guide.
Breach notification timing
Article 28(3)(f) requires processors to assist the controller in meeting Article 33 notification obligations. Practically, this means the DPA should specify the processor's notification obligation to the controller in concrete terms. 'Without undue delay' is the GDPR minimum but is not specific enough for operational purposes. A well-drafted DPA specifies a 24-hour or 48-hour notification timeline from the processor to the controller, giving the controller sufficient time to assess and notify the supervisory authority within the 72-hour window.
Enforcement cases: where vendor management fails
TL;DRTL;DR GDPR enforcement in the vendor chain is no longer theoretical. Processors face direct fines where their own security failures cause breaches. Controllers face liability for inadequate due diligence when vendor failures lead to breaches of their own customers' data.
Advanced Computer Software Group Ltd: ICO fine, 2024 (UK GDPR)
Fine: £3.07 million. The ICO's first processor fine under UK GDPR. Advanced's healthcare subsidiary suffered a ransomware attack after attackers exploited a customer account without MFA. The ICO found inadequate TOMs including gaps in MFA deployment, insufficient vulnerability scanning, and poor patch management. Critically, the ICO stated that security measures must cover the entire lifecycle of personal data processing: partial TOM coverage is not sufficient.
Lesson: MFA must be complete, not partial. Vulnerability scanning must be systematic. Patch management must operate to a defined cycle. These are not aspirational standards: they are the baseline the ICO now expects of processors handling sensitive data.
Vodafone Germany: BfDI fine, 2025 (GDPR)
Fine: €45 million. Two separate fines: €15 million for poor internal data protection controls and €30 million for security flaws in handling customer data through a third-party portal. The security failures in the customer-facing portal were specifically linked to inadequate oversight of the technical and organisational measures applied to vendor-operated systems.
Lesson: A controller cannot outsource responsibility for TOM adequacy to the vendor. If the security failure is in a vendor-operated portal or system, the controller is accountable for having procured and operated it without adequate oversight.
Capita plc: ICO fine, 2025 (UK GDPR)
Fine: £8 million (Capita plc, as controller) and £6 million (Capita Pension Solutions Limited, as processor), totalling £14 million. For organisations evaluating AI vendor risk, these cases set a clear precedent. In March 2023, hackers accessed Capita's network after a malicious file was downloaded onto an employee device. Despite a high-priority security alert being raised within ten minutes, Capita did not quarantine the device for 58 hours. Nearly one terabyte of data was exfiltrated, affecting 6.6 million individuals across pension and staff records, including special category data.
The ICO found breaches of Articles 5(1)(f) and 32 UK GDPR: Capita had failed to implement appropriate technical and organisational measures, including inadequate privileged access management, penetration test findings that were siloed within business units, and an under-resourced security operations centre.
Lesson: For controllers that rely on outsourced processors: a processor's own security failures are a direct risk to you. For processors: Article 32 obligations are direct, independent, and enforceable regardless of what the DPA says.
The controller liability trap
Under Article 82 GDPR, controllers and processors are jointly and severally liable for damage caused by processing that infringes the GDPR. In practice, this means that if a processor's security failure leads to a breach affecting your customers, those customers can sue you, the controller, for the full amount. You may then seek to recover from the processor under the indemnity provisions of your DPA. If your DPA does not contain a specific, enforceable indemnity provision, that recovery may not be available.
Building a GDPR vendor management programme
A programme that meets Article 28 requirements in practice has four operational components: a structured assessment process at onboarding, a compliant DPA with specific TOM obligations, a sub-processor visibility mechanism, and a periodic review cycle. Publishing your compliance posture through a trust center can also accelerate vendor qualification from the other side.
Whisperly's vendor assessment platform automates the assessment workflow, tracks DPA status and sub-processor lists, and flags when certifications or assessments require renewal. For organisations managing their own compliance documentation, our GDPR compliance guide covers the broader Article 28 framework, and our data processing agreement guide covers DPA drafting in detail. For a complete overview of supplier evaluation processes, see our supplier due diligence checklist.
The test is not whether you have a DPA. It is whether your DPA would survive a regulatory inspection. Schedule a demo to see how Whisperly structures vendor assessment and DPA management across your processing chain.
Processor DPAs and vendor assessments are two of the 12 areas regulators examine in a GDPR audit. See our GDPR audit readiness checklist for the complete list.
Further Reading on Whisperly
Questions & Answers
What is the difference between a controller and a processor under GDPR?+
A controller determines the purposes and means of processing personal data. A processor processes personal data on behalf of the controller, following the controller's instructions. Both carry direct obligations under GDPR: controllers must ensure they only use processors with sufficient guarantees, and processors must implement appropriate TOMs and comply with the controller's documented instructions. The distinction matters because both can now face direct enforcement action, as confirmed by the Advanced decision in 2024. For a full breakdown, see our GDPR compliance guide.
What must a GDPR Data Processing Agreement contain?+
Under Article 28(3) GDPR, a DPA must specify: that the processor processes only on the controller's documented instructions; confidentiality obligations; the obligation to implement appropriate TOMs under Article 32; sub-processor authorisation requirements; assistance obligations for data subject rights and breach notification; deletion or return of data at the end of the relationship; and the processor's cooperation with audits. In practice, effective DPAs go further, including a specific TOM schedule, a processing description annex, and concrete breach notification timelines. See our data processing agreement guide for a full template breakdown.
What are technical and organisational measures under GDPR?+
TOMs are the security and governance controls that processors and controllers must implement to protect personal data against unauthorised access, loss, alteration, or destruction. Technical measures include encryption, MFA, vulnerability scanning, and patch management. Organisational measures include staff training, access policies, incident response plans, and internal accountability structures. The adequacy of TOMs is assessed relative to the risk and nature of the data being processed. The ICO's Advanced fine demonstrates that incomplete TOM coverage, even where most systems are protected, is insufficient.
Can a processor be fined directly under GDPR?+
Yes. Article 83 GDPR provides for fines against both controllers and processors. The ICO's 2024 fine against Advanced Computer Software Group Ltd confirmed that processors face direct enforcement where their own security failures cause or contribute to a breach. Processors are directly subject to Article 32 security obligations and Article 28 contractual obligations.
How often should you reassess a vendor's GDPR compliance?+
Article 28(1) imposes an ongoing obligation on controllers to use only processors with sufficient guarantees. The EDPB's Opinion 22/2024 confirms this is a continuous duty. In practice, most organisations should reassess at least annually or when material changes occur: new processing activities, security incidents, regulatory guidance updates, certification renewals, or changes in the controller's own risk profile. For organisations managing vendor relationships at scale, see our vendor assessment platform.
Written by
Anja Beric
Anja Beric is an Attorney at Law specialising in IT Law and Data Protection. She holds an LL.M from University College London and advises clients ranging from startups to multinational corporations on IT contracts, data protection compliance, and complex commercial legal matters in the technology sector. Described by Legal 500 as part of a team that takes a "client-centred approach" and acts as "partners who truly care about clients' success".
Reviewed by: Tamara Zavisic, AI Governance Specialist