Is Your PaaS a Joint Controller? What CNIL's May 2026 Cloud Guidance Actually Says

On May 28, 2026, France's data protection authority, the CNIL, published guidance titled "Quelles qualifications pour les acteurs de l'informatique en nuage (cloud) ?" — "What qualifications for cloud actors?" It's a practical framework for deciding, purpose by purpose, whether a cloud provider is a GDPR processor, a controller, or a joint controller alongside its customer.

Within a few weeks, several English-language law-firm summaries had condensed it to a single headline: public SaaS/PaaS providers "will often be deemed joint controllers," while private clouds stay processors. That line has been repeated across enough legal blogs that it's starting to read like settled fact.

It isn't what the CNIL actually wrote. We read the French text directly, worked through all seven of the CNIL's own examples, and built the decision framework below from the primary source. The real picture is both more nuanced and, for most PaaS/SaaS builders, considerably less alarming than the "public cloud = joint controller" shorthand suggests.

The three-purpose framework CNIL actually uses

The CNIL doesn't classify a cloud provider once, globally. It classifies each purpose of processing separately, because a single vendor relationship typically involves at least three distinct purposes with different default answers:

1. Service delivery — the processing needed to run the service the customer is paying for.
2. Service improvement — processing the provider does (or the customer asks it to do) to improve the product.
3. Security "of" the cloud vs. security "in" the cloud — infrastructure-level security vs. customer-configured security.

This structure matters because it explains why a provider can be a straightforward processor for 95% of what it does and a joint controller for one narrow slice — without either party realizing the slice exists.

1. Service delivery — the default is processor, not joint controller

For the processing that makes the product work (storing data, running queries, executing the customer's configuration), the CNIL's default position is unambiguous:

"En principe, le client est responsable des traitements qu'il met en œuvre sur le service d'informatique en nuage." — In principle, the client is the controller for the processing it carries out on the cloud service.

The client is controller because it (a) chose the provider freely after reviewing the offer, and (b) retains a "marge de manœuvre" — meaningful control over what data it processes, how it configures the service, and how it deletes it. The provider, in turn, is "en principe" a processor, because it acts on the client's instructions. The CNIL adds an explicit clarification that matters a lot for infrastructure providers with opinionated defaults:

"Le fait que le fournisseur décide de la plupart des moyens essentiels du traitement ne suffit pas à le qualifier de responsable du traitement." — The fact that the provider decides most of the essential means of processing is not, by itself, enough to make it a controller.

That single sentence is the part the "public cloud = joint controller" narrative drops. A PaaS provider making the infrastructure decisions — which database engine runs behind the scenes, how backups are scheduled, which regions are available — does not, on its own, convert it into a joint controller for the customer's own application data. The CNIL's worked example is a CRM built on cloud infrastructure: the business using the CRM is controller (it decides why and how its own customers' data is used), the CRM/cloud vendor is processor (it only executes instructions needed to run the CRM).

Where service-delivery joint control does show up: the CNIL's only example here is first-party plus vendor-purpose trackers — a SaaS provider dropping cookies that measure the client's site traffic and feed the vendor's own product-improvement pipeline at the same time. That's joint control for the tracker deployment specifically, not for the underlying application.

2. Service improvement — three scenarios, and only one is joint control

This is where most of the real classification work happens, and the CNIL lays out three concrete cases:

Case 1 — provider is sole controller. The provider improves its own product using data pulled from multiple customers, for the provider's own purposes, and the client has no visibility into the specifics or ability to instruct the provider. CNIL's example: a SaaS storage vendor analyzes usage data across many customers to fix a "file search" feature that's confusing users. The provider alone decides the purpose (better search) and the means (which usage signals to analyze) — the provider is controller for that analysis, full stop, not the customer and not jointly.

Case 2 — client is controller, provider is processor. The client defines what improvement it wants and the means to get there; the provider just executes. CNIL's example: a bank asks its cloud vendor to analyze usage data (login frequency, action patterns) to speed up a slow banking app. The bank set the objective and the method — it's controller, the vendor is processor carrying out the bank's instructions.

Case 3 — joint controllers. Both sides jointly decide the objective and the essential means, because the improvement serves both parties' interests simultaneously. CNIL's example: an energy-equipment retailer and its SaaS ticketing vendor jointly redesign the ticket-priority algorithm — for the retailer, to handle urgent outage tickets correctly; for the vendor, to adapt the product for a new vertical (energy). They jointly decide which ticket fields matter and jointly define priority tiers. That co-design is what triggers Art.26.

Notice the pattern: the deciding factor is never "is this a public SaaS product." It's whether one party unilaterally decides purpose-and-means (processor/controller split) or whether both parties co-design the objective and the data categories used to reach it (joint control). A standard, non-negotiable SaaS contract doesn't by itself create joint control — a joint design process does.

3. Security — split cleanly along a different line

The CNIL draws a distinction most engineering teams already understand intuitively: security "of" the cloud (infrastructure-level — server patching, network filtering, data-center access control) is generally the provider's own responsibility as controller, since customers don't configure it and it isn't client-specific. Security "in" the cloud (encryption key management, access control configuration, IAM policy) is generally the customer's responsibility as controller, with the provider as processor executing the customer's security instructions.

Crucially, the CNIL notes these aren't independent: a server-side vulnerability the provider fails to patch can render the customer's own access controls moot (their worked example is exactly this — an unpatched SaaS server flaw exposing a database despite the customer's 2FA and access controls). And a customer misconfiguration (an admin panel left open on a shared PaaS instance) can widen the attack surface for everyone on that infrastructure. The classification is clean; the practical risk still runs both directions.

Why the "public cloud = joint controller" summary is misleading

The secondary-source framing isn't fabricated — it's a real compression of a genuine finding buried in the guidance: joint control is more likely to arise on multi-tenant public infrastructure than on a bespoke private cloud, simply because service-improvement work on public platforms more often pools data across many customers (which is Case 1 or Case 3 territory, not Case 2). But "more likely to arise in some scenarios" got rounded up to "usually is," and that rounding matters if you're deciding whether you need a Joint Controller Agreement or a standard Data Processing Agreement under Art.28.

The CNIL's own framework, read directly, says the opposite of "usually": for the processing that actually delivers the product — which is most of what a PaaS or SaaS vendor does — the default remains client-controller / provider-processor, explicitly regardless of how much infrastructure decision-making the provider retains. Joint control is the exception that arises around specific improvement or tracking activities, not the default state of the relationship.

A practical decision framework for developers

Map your own product surface against the CNIL's three purposes before you ever get to the JCA-vs-DPA question:

Five engineering-level signals that a feature has drifted from "processor executing instructions" into "provider unilaterally deciding purpose and means" — and is heading toward Case 1 or Case 3 territory:

• You're aggregating identifiable usage data across tenants for a roadmap decision, without a documented instruction from any specific customer to do so.
• There's no customer-facing lever (setting, opt-out, contract clause) that lets a specific client stop or shape that particular processing.
• The output benefits your product generally, not the specific customer whose data fed it.
• A designer or PM from your team and a stakeholder from the customer's team met to jointly define the feature's data categories and objective — this is the exact Case 3 pattern from CNIL's energy-ticketing example.
• You can't point to a single instruction-giving customer for a given processing activity — because it's driven by pooled signal, not one client's direction.

If two or more of these are true for a specific processing activity, treat it as a joint-controller candidate for that activity only — not for your whole platform — and get a written arrangement in place before shipping it, not after a DPA audit finds it.

How this fits with Art.26 arrangements

None of this changes the mechanics of what to do once you've identified joint control — Art.26 GDPR still requires a transparent arrangement between joint controllers determining who does what, and Art.26(3) still means data subjects can enforce their rights against either party regardless of your internal split. We covered the full arrangement structure, a JCA template, and eight EDPB/DPA enforcement cases in our Art.26 joint controllers guide — that post's PaaS example ("This is NOT joint control: the PaaS provider acts on the ISV's instructions... Exception triggering Art.26: if the PaaS provider uses aggregated, identifiable customer data from the ISV's workloads for its own purposes") maps directly onto the CNIL's Case 1/Case 2 split above. The May 2026 guidance doesn't overturn that analysis; it gives you the CNIL's own worked examples to argue it with, which matters if you ever need to justify a classification decision to a French regulator specifically.

The CNIL's guidance also underlines something worth internalizing operationally: document the classification reasoning per processing activity, not per contract. Their own text says as much — "en cas de doute, il est important de documenter la réflexion qui a été menée." A single blanket "we are the processor" line in your DPA doesn't survive a challenge if one specific feature (say, a co-designed analytics dashboard for one enterprise account) has drifted into joint-control territory while the rest of the platform stays firmly processor.

The takeaway for teams building on a PaaS

If you're a small team building a SaaS product on top of managed infrastructure — sota.io included — the CNIL's framework is good news read correctly: hosting your application data on infrastructure whose defaults you didn't choose does not make your PaaS provider a joint controller for your customers' data. What would: your infra provider unilaterally mining your workload data across tenants for its own product decisions, or co-designing a feature with you that blends both your roadmaps. Ask any PaaS you're evaluating a direct question — "do you process aggregated customer workload data for your own purposes, and under what classification?" — and you'll get a faster, more honest answer than any marketing page will give you.

Sources

• CNIL — "Quelles qualifications pour les acteurs de l'informatique en nuage (cloud) ?", published May 28, 2026 (primary source for all CNIL quotes and worked examples above)
• CNIL — "Responsable du traitement, sous-traitants : comment bien identifier son rôle ?" (linked companion guidance referenced by the cloud page)
• EDPB Guidelines 07/2020 on the concepts of controller and processor in the GDPR, version 2.1, adopted July 7, 2021 (the underlying EDPB criteria the CNIL guidance explicitly builds on)
• GDPR Art.4(7)/(8) — definitions of controller and processor
• GDPR Art.26 — joint controllers
• GDPR Art.28 — processor