A legal-technical analysis of the 2023 CL0P ransomware campaign against Progress Software's MOVEit Transfer platform — exploring data processor responsibilities, Art. 33 notification obligations, and the cascading risks of supply chain dependencies.
In May 2023, the Russian-affiliated ransomware group CL0P exploited a critical zero-day SQL injection vulnerability (CVE-2023-34362) in Progress Software's MOVEit Transfer platform, simultaneously breaching over 2,700 organisations and exposing data belonging to more than 66 million individuals. The attack was not a direct intrusion against its victims: it was a supply-chain compromise, in which CL0P targeted a software product used by data processors, who in turn held personal data belonging to downstream controllers' employees and customers.
From a GDPR perspective, the breach raises four interconnected legal questions: (1) whether data processors fulfilled their Art. 32 security obligations by using unpatched, critically vulnerable software; (2) whether controllers met their Art. 28 due diligence obligations before entrusting data to processors relying on third-party infrastructure; (3) whether the 72-hour notification clock under Art. 33 was observed in a multi-tier supply chain where the breach was discovered by the processor, not the controller; and (4) the extent of joint civil liability under Art. 82 between controllers and processors when the original technical failure traces to a fourth party outside the formal GDPR chain.
This case study analyses each question with reference to primary GDPR text, EDPB Guidelines, and the specific facts of the Zellis–BBC–CL0P scenario. It also situates MOVEit within the broader history of large-scale supply-chain breaches (SolarWinds, Equifax, Blackbaud) and draws practical compliance lessons for organisations structuring processor relationships.
On 27 May 2023, the Russian-affiliated ransomware group CL0P (also known as TA505) began exploiting a previously unknown SQL injection vulnerability in MOVEit Transfer, a managed file transfer (MFT) software developed by Progress Software (formerly Ipswitch, Inc.). The attack represented a paradigmatic example of a supply-chain breach: rather than attacking organisations directly, CL0P compromised the software tool they relied upon to move sensitive data, accessing hundreds of organisations simultaneously through a single entry point.
To understand the GDPR implications of this attack, it is essential to map the layered chain of data processing relationships that MOVEit enabled. Many organisations affected by the breach were not direct MOVEit customers but downstream data subjects whose data had been shared with a vendor that used MOVEit — sometimes without their explicit awareness.
The following diagram illustrates the supply chain structure that made this attack so devastating from a GDPR perspective. The BBC, British Airways, and Boots — all household UK organisations — were compromised not by a direct attack, but because their payroll provider Zellis used MOVEit to transfer HR data, and Zellis in turn had not applied Progress Software's patch in time.
This structure raises a fundamental GDPR question: when a data processor (Zellis) is breached through a vulnerability in software it uses from a third party (Progress Software), who bears the notification obligation toward supervisory authorities and data subjects? The answer — detailed in Section 4 — lies in the articulation between Articles 28, 33, and 34 GDPR.
The following timeline reconstructs key events based on official disclosures, regulatory alerts, and investigative journalism. Understanding the chronology is essential to assessing compliance with GDPR's 72-hour notification requirement under Article 33(1).
CVE-2023-34362 is a critical SQL injection vulnerability in MOVEit Transfer's web application layer. SQL injection attacks exploit insufficient input validation: when user-supplied data is directly incorporated into SQL database queries without proper sanitisation, an attacker can inject arbitrary SQL commands, bypassing authentication and accessing or modifying database contents.
In this specific case, the vulnerability affected MOVEit's web application on all supported versions and allowed unauthenticated attackers to submit crafted HTTP requests to MOVEit's web interface — accessible on the open internet — that would be processed by the underlying Microsoft SQL Server or Azure SQL database engine. The OWASP Top 10 consistently ranks SQL injection among the most critical web application security risks, making the vulnerability's presence in a data-transfer tool handling sensitive corporate information a direct Art. 32 GDPR concern. Art. 32(1) requires controllers and processors to implement "appropriate technical and organisational measures" — including, per Art. 32(1)(a), pseudonymisation and encryption, and more broadly, per Art. 32(1)(b), "the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems." A SQL injection vulnerability in a tool specifically designed to transfer sensitive files falls squarely within the scope of what Art. 32 is intended to prevent. Furthermore, the vulnerability's presence also raises Art. 25 (data protection by design) issues: insufficient input validation in a data-transfer product indicates that security was not built into the development process as a foundational requirement.
Once SQL injection granted initial access, CL0P deployed LEMURLOOT, a custom webshell written in C#, specifically designed to target MOVEit Transfer. A webshell is a malicious script uploaded to a compromised server that allows an attacker to execute system commands remotely through a web browser or HTTP requests.
According to CISA's advisory, LEMURLOOT authenticated incoming HTTP requests using a hard-coded password and was capable of: downloading files from the MOVEit database, extracting Azure system settings (critical for cloud-hosted instances), retrieving file records, and — crucially — creating new administrator-level accounts with randomised usernames bearing the LoginName value "Health Check Service", designed to blend into legitimate system activity and evade detection.
The "Health Check Service" account creation tactic highlights a failure not of perimeter security alone, but of behavioural anomaly detection. SIEM systems configured to alert on new admin account creation should have flagged this activity. The question MOVEit customers should ask is not only "were we patched?" but "were our logs monitored in real time, and did our detection rules cover this pattern?"
The speed of the attack — exploitation across thousands of targets within hours on a Saturday — reveals a structural monitoring challenge. Weekend timing is a well-known attacker strategy: Security Operations Centres (SOCs) are often understaffed on Saturdays, and automated alerting pipelines may not be configured to escalate with the same urgency as weekday incidents. From a GDPR Article 32 perspective, this raises questions about whether affected organisations maintained security measures "appropriate to the risk," including 24/7 monitoring.
Additionally, many victims — like the downstream clients of Zellis — had no direct visibility into their processor's infrastructure. They could not monitor Zellis's MOVEit deployment, and had no mechanism to detect that their employees' payroll data was being exfiltrated. This is precisely the gap that Article 28's processor agreement requirements are intended to close.
The MOVEit breach is not simply a cybersecurity incident — it is a defining case study in how the GDPR's allocation of responsibilities between data controllers and data processors operates under conditions of supply-chain attack. This section analyses the case through Articles 4, 28, 32, 33, and 34 GDPR.
Zellis determines neither the purposes nor the means of processing BBC employees' payroll data — that determination is made by BBC (controller). Zellis processes data on BBC's instructions. The distinction determines who bears primary notification obligations.
Art. 28(1) requires controllers to use only processors "providing sufficient guarantees" of security. Art. 28(3)(f) requires processor contracts to mandate security measures under Art. 32. Critically, Art. 28(2) requires written authorisation from the controller before a processor can engage a sub-processor — raising the question of whether Zellis's use of MOVEit was covered in its DPAs with BBC and others.
Both Progress Software (as a vendor), Zellis (as processor), and the controllers share responsibility for maintaining "appropriate technical and organisational measures." Failure to apply a critical patch within the exploitation window — or to detect a webshell creating admin accounts — is a strong indicator of inadequate security under Art. 32(1)(b).
Art. 33(1): controllers must notify the competent DPA "without undue delay and, where feasible, not later than 72 hours" after becoming aware of a breach. Art. 33(2): processors must notify the controller "without undue delay" upon becoming aware. The 9-day gap between exploitation (27 May) and Zellis's disclosure (5 June) warrants scrutiny under this framework.
Art. 34(1) requires communication to affected individuals when the breach is "likely to result in a high risk to the rights and freedoms" of those persons. Exposure of payroll data, National Insurance numbers, and bank details clearly meets this threshold, creating a direct obligation for BBC, BA, and Boots to notify their employees individually.
The SQL injection vulnerability in a data transfer tool suggests insufficient security testing at the design phase. Art. 25(1) requires that "data protection principles are implemented in an effective manner" and that "appropriate technical and organisational measures" are built in by default. CVE-2023-34362 suggests input validation was not a mandatory security requirement in MOVEit's development process.
The table below maps each relevant GDPR provision to the specific potential violation in the MOVEit context and the factual evidence supporting it. This is an analytical framework, not a finding of infringement — final determinations rest with supervisory authorities.
| Article | Potential Violation | Evidence from MOVEit Case | Exposure |
|---|---|---|---|
| Art. 32(1)(b) | Failure to ensure ongoing resilience and confidentiality of processing systems | Zellis continued to operate MOVEit Transfer in production despite the platform carrying an unpatched critical SQL injection flaw that allowed unauthenticated remote access. Exploitation occurred before the patch was available, but absence of compensating controls (WAF, anomaly detection) is documented. | HIGH — Zellis |
| Art. 28(1) | Controllers failed to verify processor provides "sufficient guarantees" of security | BBC, British Airways, Boots had no direct visibility into Zellis's infrastructure, and their DPAs did not appear to require ongoing security certification or patch management standards for the tools Zellis used to transfer their data. | MED — Controllers |
| Art. 28(2) | Processor engaged sub-processor (Progress Software's platform) without adequate written authorisation or sub-processor security clauses | Zellis's DPAs with controllers did not demonstrably require notification of critical software vulnerabilities or mandate security standards for the file-transfer tooling used in processing. | MED — Zellis |
| Art. 33(1) | Failure to notify supervisory authority within 72 hours of becoming aware | Exploitation began 27 May; Zellis confirmed the breach on 5 June (9 days later). Controllers were notified on 5 June, potentially triggering their own 72-hour clock from that date — though the ICO's guidance implies that informal awareness may start the clock earlier. | HIGH — Zellis / Controllers |
| Art. 33(2) | Processor failed to notify controller without undue delay | Zellis notified downstream controllers on 5 June, 9 days after exploitation began on 27 May. "Without undue delay" under EDPB guidance typically means hours, not days — particularly for a breach of confirmed payroll data exfiltration. | HIGH — Zellis |
| Art. 34(1) | Failure to notify data subjects when high risk to rights and freedoms is established | Exfiltrated data included National Insurance numbers, bank account details, and payroll figures — clearly meeting the "high risk" threshold. Controllers (BBC, BA, Boots) issued public statements but the speed and individual character of data subject notifications varied. | MED — Controllers |
| Art. 25(1) | Data protection by design: insufficient security testing at development phase | CVE-2023-34362 represents an OWASP Top-3 vulnerability class (SQL injection) in a product whose core function is handling sensitive corporate data. The CISA advisory notes the flaw was tested as early as July 2021, suggesting Progress Software's QA processes did not catch or remediate it. | MED — Progress Software (vendor, not processor) |
| Art. 5(2) | Accountability: inability to demonstrate compliance with processing principles | The cascade from Progress → Zellis → BBC/BA/Boots illustrates a chain where no party could demonstrably account for the full security perimeter of the processing operation — a structural failure of the accountability principle. | HIGH — All parties |
What makes the MOVEit breach analytically significant — beyond its scale — is that it reveals a structural gap in GDPR's processor accountability chain under supply-chain attack conditions. Consider the position of Zellis's clients: they had contracted with Zellis (their processor) and presumably reviewed Zellis's security credentials. But they had no visibility into, and no contractual relationship with, Progress Software — Zellis's software vendor.
Under GDPR, the controller is responsible for assessing whether their processor provides sufficient guarantees (Art. 28(1)). But does that assessment extend to the security of every software tool the processor uses? The MOVEit case suggests that the answer, in practice, must be yes — or at minimum, that processor DPAs (Data Processing Agreements) must explicitly address sub-vendor security standards. The BBC could not audit Progress Software's secure development lifecycle, yet it bore responsibility for the breach affecting its employees' data.
This is what distinguishes the MOVEit case from a conventional direct breach: it is a case of nth-party risk, where the liability chain is several steps removed from the original controller, yet GDPR's accountability principle (Art. 5(2)) leaves no room for passing responsibility down that chain. The EDPB's Guidelines on Personal Data Breach Notification (07/2022) confirm that controllers cannot exempt themselves from Art. 33 obligations simply because the breach occurred at a processor's infrastructure.
The Zellis/BBC scenario illustrates why GDPR Art. 28(2) — requiring written authorisation before a processor engages a sub-processor — is not a bureaucratic formality. Had BBC's DPA with Zellis explicitly required notification of all sub-processing tools used (and security certifications for each), BBC would have had contractual grounds to demand timely notification and potential indemnification. The MOVEit case became a catalyst for legal teams across Europe to audit their DPAs for nth-party risk provisions.
The GDPR's accountability framework is not limited to notification obligations. Articles 82 and 83 create distinct civil liability and administrative sanction regimes that were directly implicated by the MOVEit breach. Understanding how these provisions apply to a supply-chain attack — where the technical failure occurred at a software vendor outside the formal processor chain — is one of the case's most significant legal lessons.
Art. 82(1) GDPR grants any person who suffers material or non-material damage as a result of a GDPR infringement the right to receive compensation from the controller or processor responsible. In the MOVEit scenario, this creates overlapping liability exposure. Affected employees of BBC, British Airways, and Boots — whose payroll data, National Insurance numbers, and bank details were exfiltrated — are entitled to seek compensation from their employers as data controllers, regardless of the fact that the breach originated at Zellis, a downstream processor.
Art. 82(3) provides a partial exoneration: a controller or processor is not liable if it can prove the damage was "not in any way attributable to it." This is a high bar. In the Zellis scenario, controllers like BBC would need to demonstrate they conducted adequate due diligence on Zellis's security practices under Art. 28(1) — a difficult argument if their DPAs did not require Zellis to maintain patch management policies or notify controllers of critical software vulnerabilities in their processing infrastructure.
The joint and several liability mechanism under Art. 82(4) is particularly relevant here: where both a controller and a processor are responsible for damage, each may be held liable for the full amount of damages, with the right to seek a proportional contribution from the other party. This creates strong incentives — in litigation or settlement — for BBC to seek indemnification from Zellis, and for Zellis to in turn pursue Progress Software through contract law (though Progress, as a mere software vendor, falls outside the formal GDPR processor definition).
Art. 83 GDPR distinguishes two tiers of administrative fines. Violations of security obligations under Art. 32, or of processor requirements under Art. 28, attract fines of up to €10 million or 2% of global annual turnover (Art. 83(4)). Violations of core principles, including the accountability principle under Art. 5(2) and special category data protections under Art. 9, attract the higher tier of up to €20 million or 4% of global annual turnover (Art. 83(5)).
In the context of MOVEit, the most probable fine exposure for controllers like BBC or British Airways falls under Art. 83(4): failure to implement adequate technical measures under Art. 32 (by not contractually requiring their processor to maintain current security patches), and failure to comply with Art. 28 processor requirements (if DPAs did not cover sub-processor security). For Zellis itself, the exposure is more direct: as a processor that failed to patch a known critical vulnerability within the exploitation window, the absence of adequate security measures under Art. 32(1) is well-evidenced.
The UK Information Commissioner's Office (ICO) confirmed it was investigating the MOVEit breach in the UK. British Airways had already received a £20 million fine from the ICO in 2020 following the 2018 Magecart breach — a precedent that informed the legal risk calculus for the 2023 incident. As of the time of writing, formal enforcement decisions against Zellis or the downstream controllers had not been published, though the ICO's investigation remains ongoing. Several affected organisations issued public statements confirming they had notified the ICO, implying compliance with the Art. 33 72-hour obligation — though the adequacy of those notifications is a separate matter. [L3]
A structurally important — and unresolved — question is whether Progress Software bears any direct GDPR exposure. Progress is not a GDPR data processor: it does not process personal data on behalf of MOVEit customers; it produces software that customers deploy in their own environments. However, the US Securities and Exchange Commission (SEC) opened a formal investigation into Progress Software in October 2023, examining whether the company met its disclosure obligations regarding the vulnerability. In parallel, class action litigation in the United States named Progress as a defendant. Under EU law, Progress's GDPR exposure would likely need to be routed through product liability frameworks or tortious claims rather than direct GDPR enforcement — a gap in the regulation that the NIS2 Directive (transposed from October 2024) begins to address by imposing security obligations on ICT product manufacturers.
MOVEit does not exist in isolation. Supply-chain and third-party data breaches have been a defining feature of the cybersecurity landscape since 2017. Comparing MOVEit to three structurally similar cases — Equifax (2017), SolarWinds (2020), and Blackbaud (2020) — clarifies what is distinctive about the MOVEit incident from a GDPR liability perspective and what it shares with prior enforcement patterns.
Equifax, a US credit reporting agency, suffered a breach through an unpatched Apache Struts vulnerability (CVE-2017-5638). The flaw had been public and patchable for 68 days before exploitation. The breach exposed 147 million individuals' SSNs, birth dates, and financial data.
Enforcement: US FTC settlement of USD 575 million; UK ICO fine of £500,000 (pre-GDPR cap); FCA fine of £11.16 million in 2023 for failing to protect UK consumer data.
Nation-state actors (APT29/Cozy Bear) compromised SolarWinds' software build pipeline, injecting malicious code into the Orion platform used by 18,000+ organisations, including US federal agencies. Unlike MOVEit, the compromise was at source — in the vendor's own build process, not through a post-deployment vulnerability.
Enforcement: SEC charged SolarWinds with securities fraud (2023) for misleading investors about cybersecurity practices. EU regulatory action was limited by the primarily US-government nature of the victims.
Blackbaud, a cloud software provider used extensively by charities, universities, and healthcare organisations, suffered a ransomware breach affecting hundreds of its clients' donor and beneficiary data. Blackbaud paid the ransom and initially withheld key facts from clients — including that financial data had been exfiltrated — for months.
Enforcement: ICO fine of £7.5 million (2023) for security failures and inadequate breach notification. FTC order (2024) requiring comprehensive security programme. This is the closest structural precedent to Zellis's position in the MOVEit case.
Across all three precedents and MOVEit, supervisory authorities have consistently held that: (a) failure to patch known vulnerabilities is treated as inadequate security under the applicable framework; (b) processors who delay or mischaracterise breach notifications face higher sanctions than those who notify promptly; and (c) scale alone does not determine liability — the Blackbaud fine (£7.5M) was issued against a company far smaller than the BBC or British Airways. The MOVEit case's distinctive contribution to this body of precedent lies in the fourth-party risk question: whether a controller can be held liable for a breach that traces to a vendor its processor used, with no direct contractual relationship to the controller.
The MOVEit breach produced a set of operational conclusions that legal and compliance teams across the EU and UK translated into immediate DPA audit programmes and procurement policy revisions. The following lessons are grounded in the specific failures identified in the case and the EDPB and ICO guidance that followed.
Selecting a processor based on ISO 27001 certification or a generic security questionnaire is insufficient. DPA due diligence must now explicitly ask: what critical third-party software does this processor use for data transfer and processing, and what are their patch management and vulnerability disclosure policies?
Art. 28(2) clauses requiring written authorisation for sub-processors should be expanded to require disclosure of critical software dependencies, evidence of timely patch management, and contractual rights for the controller to audit or require independent security audits of the processor's infrastructure — including the tools it uses.
Controllers must contractually require processors to notify them within a defined window — the EDPB recommends this be shorter than the controller's own 72-hour obligation. A DPA clause requiring 24-hour processor-to-controller notification gives controllers adequate time to assess and notify their DPA without breaching Art. 33(1).
CVE-2023-34362 was exploited before a patch existed. Organisations should maintain compensating controls for critical data-transfer infrastructure: Web Application Firewalls (WAFs) filtering SQL injection patterns, behavioural anomaly detection for new admin account creation, and network segmentation isolating file-transfer services from the broader environment.
The MOVEit attack was launched on a Saturday precisely because SOC staffing is typically reduced. Art. 32's "appropriate measures" standard must include 24/7 monitoring of critical infrastructure — not as a best practice, but as a baseline expectation that supervisory authorities will apply when assessing whether a breach was detectable and preventable.
The NIS2 Directive, transposed into EU member state law from October 2024, imposes supply-chain security obligations directly on operators of essential services and important entities — requiring risk assessments of their vendor relationships. Where GDPR focuses on personal data, NIS2 covers the broader security posture, creating overlapping obligations that together more directly address the Progress Software / Zellis gap.
This tool operationalises the legal analysis above into executable logic — mapping GDPR notification obligations (Art. 33, 34, 28) onto a decision-tree classifier. It was built to show how legal reasoning can be encoded into interactive software. The underlying Python classifier is available on GitHub.
The risk score is a heuristic orientation tool, not a legally binding assessment. The weighting logic is derived from the risk factors enumerated in EDPB Guidelines 9/2022 on Personal Data Breach Notification (§§ 3.1–3.4), which identify data sensitivity, scale, breach type, and likelihood of harm as the primary factors bearing on notification obligations. The score does not replace a legal analysis and should not be relied upon as professional advice. High scores correlate with scenarios where EDPB Guidelines indicate a prima facie notification obligation; low scores indicate scenarios where the threshold is less likely to be met, but a documented risk assessment is still required under Art. 33(5).
Given a hypothetical data breach scenario, the tool determines notification obligations under Articles 33 and 34 GDPR, assesses whether Art. 28 processor obligations apply, and produces a risk score with recommended actions.
Sources are cited in standard author-date-title format. All URLs verified as accessible as of March 2026. Web sources cited with full title and publication details.