Back to Newsroom
GDPR · NexCyber Editorial

Cloud Processors Face New GDPR Liability Rules After IQVIA Fine

The €5 million fine imposed by France’s CNIL on IQVIA in January 2024 marks a turning point for cloud infrastructure operators. For the first time, a data warehouse provider was held directly liable for failing to implement adequate safeguards—despite acting as a processor. This decision forces CTOs, CISOs, and DPOs to re-examine their role definitions, subcontractor chains, and contractual protections before the next enforcement wave hits.

The €5 million fine imposed by France’s CNIL on IQVIA in January 2024 marks a turning point for cloud infrastructure operators. For the first time, a data warehouse provider was held directly liable for failing to implement adequate safeguards—despite acting as a processor. This decision forces CTOs, CISOs, and DPOs to re-examine their role definitions, subcontractor chains, and contractual protections before the next enforcement wave hits.

The IQVIA Fine: What Changed for Cloud Data Warehouse Operators

The CNIL’s decision (Délibération SAN-2024-001) found IQVIA, a cloud-based health data warehouse operator, in violation of GDPR Articles 5(1)(f), 28, and 32. The authority ruled that IQVIA failed to:

  • Implement appropriate technical and organisational measures (TOMs) to ensure data security (Article 32)
  • Properly oversee its sub-processors (Article 28(3)(f))
  • Maintain sufficient records of processing activities (Article 30)

Critically, the CNIL rejected IQVIA’s argument that it was merely a processor following client instructions. The authority determined that IQVIA’s role extended beyond standard processing activities—particularly in how it structured and secured the data warehouse environment. This interpretation suggests that cloud operators providing infrastructure for sensitive data processing may now face heightened scrutiny, even when acting under a data processing agreement (DPA).

The fine’s sector-agnostic implications are clear: any cloud infrastructure operator handling personal data—whether in healthcare, finance, or industrial IoT—must now audit their security controls and role definitions. The CNIL’s reasoning aligns with recent guidance from the European Data Protection Board (EDPB), which has increasingly emphasised that processors cannot outsource their GDPR obligations through contractual clauses alone.

Why Role Clarity Matters: Processor, Sub-processor, or Controller?

The IQVIA case underscores the ambiguity in GDPR’s role definitions when applied to modern cloud architectures. The regulation distinguishes between:

  • Controllers (Article 4(7)): Entities determining the purposes and means of processing
  • Processors (Article 4(8)): Entities processing data on behalf of controllers
  • Sub-processors (Article 28(2)-(4)): Third parties engaged by processors to carry out processing activities

However, cloud infrastructure operators often straddle these categories. For example:

  • A cloud provider offering a managed data warehouse may determine technical means (e.g., encryption standards, access controls) while the client determines purposes (e.g., "analysing patient outcomes").
  • A multi-tenant SaaS platform may process data for multiple controllers but also use sub-processors for storage or analytics.

Key Questions to Resolve Role Ambiguity

  1. 1Who determines the "essential means" of processing? - If the cloud operator decides on encryption protocols, retention periods, or access management tools, it may be deemed a joint controller (EDPB Guidelines 07/2020). - If the client retains full control over these decisions, the operator is likely a processor.
  1. 1Does the operator provide "value-added" services? - Services like automated data categorisation, AI-driven analytics, or pre-configured dashboards may push the operator toward a controller role. - Pure infrastructure services (e.g., raw storage, compute) are more likely to qualify as processing.
  1. 1How are sub-processors engaged? - If the cloud operator unilaterally selects sub-processors (e.g., for CDN services or backups), it may assume controller-like responsibilities for those sub-processors’ compliance.

The Joint Controller Risk

The EDPB’s guidelines warn that joint controllership (Article 26) can arise even where parties have no formal agreement. In the IQVIA case, the CNIL implied that the operator’s control over the data warehouse’s technical architecture created shared responsibility. This interpretation aligns with the *Fashion ID* (C-40/17) and *Wirtschaftsakademie* (C-210/16) rulings, where the CJEU held that entities determining technical means could be joint controllers.

The Subcontractor Liability Chain: Lessons from Recent CNIL Cases

The IQVIA fine is part of a broader trend of regulators targeting sub-processor chains. In 2023, the CNIL fined:

  • Doctolib (€1.5 million) for failing to ensure its sub-processor (AWS) complied with GDPR’s international transfer requirements.
  • Microsoft Ireland (€60 million) for inadequate cookie consent mechanisms, despite acting as a processor for French public sector clients.

These cases reveal three critical risks for cloud operators:

1. Sub-Processor Oversight Gaps

GDPR Article 28(3)(f) requires processors to ensure sub-processors provide "sufficient guarantees" of GDPR compliance. The CNIL’s IQVIA decision found that the operator:

  • Did not verify its sub-processors’ security measures
  • Failed to document sub-processor engagements in its records of processing activities (Article 30)
  • Did not notify clients of sub-processor changes (Article 28(2))

Regulatory expectation: Cloud operators must audit sub-processors’ TOMs, not just rely on contractual clauses. The CNIL’s 2024 guidance (Lignes directrices sur les sous-traitants) states that processors must "actively monitor" sub-processors’ compliance, including through on-site audits or third-party certifications (e.g., ISO 27001, SOC 2).

2. International Transfer Risks

The *Schrems II* ruling (C-311/18) and the EDPB’s Recommendations 01/2020 require processors to assess sub-processors’ data transfer mechanisms. In the Doctolib case, the CNIL found that AWS’s reliance on Standard Contractual Clauses (SCCs) was insufficient because:

  • The sub-processor did not provide evidence of "supplementary measures" to protect data from U.S. surveillance laws.
  • The processor did not conduct a transfer impact assessment (TIA).

Regulatory expectation: Cloud operators must now:

  • Map all sub-processors’ data flows (including backups and disaster recovery sites).
  • Document TIAs for each sub-processor, even if the sub-processor is EU-based but owned by a non-EU entity (e.g., AWS EU operated by Amazon.com, Inc.).
  • Implement technical safeguards (e.g., encryption, pseudonymisation) to mitigate transfer risks.

3. Security Incident Liability

GDPR Article 33 requires processors to notify controllers of data breaches "without undue delay." However, the CNIL’s 2023 enforcement report shows that processors are increasingly held liable for:

  • Failing to detect breaches (e.g., unpatched vulnerabilities in sub-processor systems).
  • Delaying notifications (e.g., waiting for sub-processor confirmation before alerting the controller).

Regulatory expectation: Cloud operators must:

  • Implement real-time monitoring of sub-processor environments (e.g., SIEM integration).
  • Define contractual escalation paths for sub-processor incidents.
  • Conduct joint incident response drills with sub-processors.

Practical Audit Steps for Cloud Infrastructure Teams

To mitigate these risks, cloud infrastructure teams should conduct a three-phase audit:

Phase 1: Role Definition Review

  1. 1Map processing activities - Document all data flows, including sub-processor engagements. - Identify which party determines the "purposes" and "means" for each activity.
  2. 2Assess controller-like activities - Review whether the operator: - Sets encryption standards - Configures access controls - Provides pre-built analytics tools - If yes, consider a joint controllership agreement (Article 26).
  3. 3Update records of processing activities (RoPA) - Ensure RoPA includes: - Sub-processor details (Article 30(2)) - Data transfer mechanisms (Article 30(1)(d)) - Security measures (Article 30(1)(g))

Phase 2: Sub-Processor Due Diligence

  1. 1Inventory sub-processors - Use tools like AWS Artifact, Azure Compliance Manager, or third-party platforms to track sub-processor chains.
  2. 2Conduct transfer impact assessments (TIAs) - For non-EU sub-processors, document: - Applicable surveillance laws (e.g., FISA 702, CLOUD Act). - Supplementary measures (e.g., encryption, access controls). - For EU sub-processors owned by non-EU entities, assess whether the parent company can access data.
  3. 3Audit sub-processor TOMs - Request evidence of: - ISO 27001 or SOC 2 certifications. - Penetration test reports (annual). - Employee background checks (for sensitive data).

Phase 3: Contractual and Technical Safeguards

  1. 1Update data processing agreements (DPAs) - Include clauses requiring: - Sub-processor pre-approval (Article 28(2)). - Sub-processor audits (Article 28(3)(h)). - Joint liability for sub-processor breaches.
  2. 2Implement technical controls - Encryption: Ensure data is encrypted at rest (AES-256) and in transit (TLS 1.2+). - Access management: Enforce least-privilege access and multi-factor authentication (MFA). - Logging: Maintain immutable logs of all sub-processor activities (Article 30(1)(g)).
  3. 3Conduct breach simulations - Test incident response plans with sub-processors, including: - Notification timelines (Article 33). - Forensic investigation protocols. - Client communication templates.

Updating Data Processing Agreements Before Next Enforcement Wave

The IQVIA fine signals that regulators will scrutinise DPAs more closely in

Want the regulatory deep-dive ?

Our regulatory engineering team publishes implementation guides + practical checklists for each regulatory update.

Browse Knowledge Base →