4.5 Outsourcing, Cloud & Vendor Management

Controller and Processor in the Cloud

Outsourcing to a cloud or Software-as-a-Service (SaaS) vendor is one of the most common real-world GDPR scenarios, and the CIPP/E tests it heavily through role analysis.

Under Article 4(7)-(8), the controller determines the purposes and means of processing, while the processor processes personal data on behalf of the controller. In a typical cloud arrangement the customer is the controller and the provider is a processor that may act only on the controller's documented instructions (Article 29 and Article 28(3)(a)). The provider's status does not change just because it is large, sets standard terms, or has more technical expertise than the customer.

The exam also tests joint controllership under Article 26: where two parties jointly determine purposes and means (the CJEU found this in Wirtschaftsakademie C-210/16 for a Facebook fan-page operator and Fashion ID C-40/17 for a site embedding a Like button), they must allocate responsibilities in a transparent arrangement. Distinguishing processor from joint controller is a frequent question hinge.

Article 28 Contracts (the DPA)

Whenever a controller uses a processor, Article 28(3) requires a binding written contract (which may be electronic) — commonly a Data Processing Agreement (DPA). It must set out the subject matter, duration, nature and purpose of processing, the type of personal data, and the categories of data subjects, and must bind the processor to the following obligations:

• (a) Process only on documented instructions, including regarding transfers to third countries;
• (b) Ensure persons authorised to process are under a duty of confidentiality;
• (c) Take all Article 32 security measures;
• (d) Respect the sub-processor conditions in Article 28(2) and (4);
• (e) Assist the controller in responding to data subject rights requests (Chapter III);
• (f) Assist with Article 32-36 duties — security, breach notification, DPIAs, and prior consultation;
• (g) At the controller's choice, delete or return all personal data at the end of the service and delete existing copies;
• (h) Make available information needed to demonstrate compliance and allow and contribute to audits and inspections.

A missing or non-compliant DPA is itself an infringement that supervisory authorities can fine. The Commission has also published standard contractual clauses for controller-processor relationships (Decision 2021/915) that can satisfy Article 28(3) — distinct from the international-transfer SCCs (Decision 2021/914). Confusing the two sets of SCCs is a recurring exam trap.

Sub-Processors

Cloud providers rarely act alone; they rely on sub-processors such as infrastructure (IaaS), payment, support, or analytics vendors. Article 28(2) forbids a processor from engaging another processor without prior authorisation from the controller.

That authorisation can be:

• Specific — the controller approves each named sub-processor individually; or
• General written — the processor must inform the controller of any intended addition or replacement of sub-processors, giving the controller the chance to object to those changes.

Under Article 28(4), when a processor engages a sub-processor it must impose the same data protection obligations as in its own DPA, by contract, in particular sufficient guarantees of appropriate security. Critically, where the sub-processor fails to fulfil its obligations, the initial processor remains fully liable to the controller for the sub-processor's performance.

Long sub-processor chains — common with hyperscale clouds that nest providers several layers deep — are exactly why cloud due diligence cannot stop at the direct vendor. Note: no supervisory-authority approval is required for ordinary sub-processing; the gatekeeping is contractual between controller and processor.

When a Processor Becomes a Controller

A recurring exam trap concerns Article 28(10): if a processor infringes the GDPR by determining the purposes and means of processing — that is, goes beyond the controller's documented instructions — it is considered a controller in respect of that processing and bears controller obligations and liability.

Worked Example

A SaaS HR vendor is hired to host an employer's staff records (clearly a processor role). The vendor then, on its own initiative, decides to reuse the uploaded employee data to build and sell an analytics product. For that reuse the vendor has set its own purpose (commercial product development) and means, so under Article 28(10) it acts as a controller for that new processing — and must itself satisfy a lawful basis, transparency, and all controller duties, with direct fining exposure.

The tell-tale signs of a controller role:

• Reusing data for the vendor's own benefit, not the customer's;
• Deciding why and the essential means of processing;
• Determining retention periods or disclosures independently;
• Acting outside documented instructions.

By contrast, a processor making purely technical choices (which encryption library, which data centre design) within the controller's instructions stays a processor. The exam often dresses this up as "the vendor improved its algorithms using customer data" — that is a controller activity for the new purpose, regardless of whether the underlying data is special category.

Due Diligence and Cross-Border Cloud

Article 28(1) says a controller may use only processors providing sufficient guarantees to implement appropriate technical and organisational measures so that processing meets the GDPR and protects data subject rights. This makes vendor due diligence a legal obligation under the accountability principle (Article 5(2)), not just good practice. Practical checks the exam expects:

• Security posture — certifications and audit reports such as ISO/IEC 27001, SOC 2 Type II, and adherence to approved codes of conduct or certification under Articles 40-42 (which can serve as an element of "sufficient guarantees");
• The DPA terms and the sub-processor list (and the change/objection process);
• Breach-handling and assistance commitments;
• Data location and transfers — where the cloud provider or any of its sub-processors are outside the EEA, Chapter V transfer rules apply on top of Article 28.

The Two-Layer Outcome

A single cross-border cloud deal can require both:

1. An Article 28 DPA (the controller-processor relationship), and
2. A Chapter V transfer tool — e.g., adequacy (DPF for a certified US provider) or SCCs plus a Transfer Impact Assessment and supplementary measures.

Missing either layer makes the arrangement unlawful even if the other is perfect. That dual requirement — relationship contract and transfer mechanism — is one of the most testable practical takeaways of the whole chapter.