Are You Really Just a Processor? 4 SaaS Patterns That Quietly Make You a Controller Under GDPR

Your data processing agreement ("DPA") says "processor." Your product says otherwise. If any of the patterns below describe your product, you may already be a controller for processing you never planned for — with transparency, deletion, and breach obligations running directly to end users you have no relationship with.

Since 2024, data protection authorities have started testing the gap between what DPAs say and what products do — sanctioning vendors for processing beyond their processor mandate and customers for failing to control what their vendors did with user data.

TL;DR

• If your product independently determines why customer data is processed — or shapes essential processing parameters like data categories, data subjects, retention, or recipients — you are likely a controller for that processing, regardless of what your DPA says.
• Controller status under Article 28(10) is determined by factual conduct — not by a regulatory decision.
• While the status question is settled, the timing is less so: when exactly controller obligations attach — from the start of own-purpose processing, from the point of awareness, or only from a formal finding — remains open. No enforcement decision or European Data Protection Board guidance has addressed the temporal dimension.
• Commercial exposure — customer audits, M&A flags, contract renegotiations — typically precedes regulatory action.
• Operating as a processor for your core service and as a controller for specific own-purpose operations (analytics, model training) is a normal dual-role architecture for mature SaaS — not a compliance failure.
• The problem is being a controller without knowing it — and without the transparency notices, legal basis documentation, and DPA carve-outs that controller status requires.
• Reclassification does not mean you have to stop what you are doing. In most cases the processing can continue with a proper legal basis, an updated DPA, and — where applicable — a joint-controller arrangement. Below: a 13-question diagnostic and four patterns with enforcement examples and compliance paths.

What 4 SaaS product patterns lead to reclassification?

The primary regulatory anchors are the European Data Protection Board’s ("EDPB") Guidelines 07/2020 on controller/processor concepts and key Court of Justice of the European Union ("CJEU") rulings and data protection authority decisions, cited in the patterns below.

Note on other regimes: The UK GDPR uses the same controller definition; the role analysis above applies in substance, though the regulatory and adequacy frameworks differ post-Brexit. Other jurisdictions define controllership in broadly similar terms but are not covered here.

A note on "purposes and means." The patterns above focus on purpose — because that is where reclassification risk concentrates. But in each pattern, the vendor also typically determines essential means, which reinforces the controller finding. The distinction matters because Article 4(7) defines a controller as the entity that determines purposes and means of processing. The EDPB separates "essential means" (the type of personal data, duration of processing, categories of data subjects, and categories of recipients — four elements) from "non-essential means" (technical and organizational choices like which cloud provider or encryption standard to use) (Guidelines 07/2020, sections 38–41). A processor may determine non-essential means without becoming a controller.

In practice, these patterns overlap. A single product can act as a processor for its core service while running two or three own-purpose operations on the side — analytics, model training, and an embedded SDK. Each involves a different legal mechanism, but the compliance response is typically one DPA restructuring project that accounts for all of them. The question is which pattern to address first.

Where to start. If you match multiple patterns, start with whatever is hardest to undo. Pattern 2 (ML/AI training) has the highest remediation cost — you cannot un-train a model, and non-EU regulators have already ordered model deletion in analogous cases. Pattern 3 (embedded SDKs) is next: joint-controllership exposure exists from the moment the SDK fires, but switching to a processor-only alternative is straightforward. Pattern 1 (analytics) is the most reversible — you can stop cross-customer use and restructure the DPA. Pattern 4 (infrastructure telemetry) is largely about documentation and opt-out controls where available. For enforcement status and how these priorities shift for mid-market SaaS, see mid-market calibration below.

Does your SaaS show common reclassification patterns? Take the test

13 questions, 3 minutes. Each question maps to one of the four patterns in the detailed sections that follow. Your answers show which patterns are relevant to your product and where to focus your reading. The legal mechanism differs by pattern, but the practical consequence is the same: controller obligations you did not plan for.

Not legal advice. This self-assessment does not constitute legal advice or substitute for a classification review by qualified counsel. A "no flags" result does not confirm processor status — it means this test did not surface a flag.

Already know the framework? Skip to detailed analysis →

The sections below examine each pattern in detail — what triggers it, how regulators have responded, and what the compliance path looks like. If the test flagged specific patterns, start there; otherwise, read in order — each pattern builds on the controller/processor framework introduced above.

Pattern 1 — When does your own product analytics lead to controller classification?

Common claim. "We only use telemetry (usage and performance data) to run the service for the customer."

What changes it. This is about your product’s analytics — the data your B2B SaaS collects on how customers use your platform. (For telemetry your infrastructure provider collects as part of running your environment — AWS, Azure, GCP — see Pattern 4.)

The problem starts when you reuse that data for your own goals — ranging from borderline (roadmap planning) to clearly own-purpose (building prospect lists), with cross-customer benchmarks, sales outreach, and internal R&D in between. Once you independently determine how to use the data, those become your own purposes under GDPR Article 4(7) — not the customer’s instructions. A common counterargument is that the customer accepted terms of service describing analytics or model training, so those activities fall within "documented instructions" under Article 28(3)(a). The EDPB addressed this in Guidelines 07/2020, sections 80–81: instructions must relate to the processing the controller engaged the processor to carry out — not to processing the vendor designed for its own benefit. A blanket acceptance of terms does not convert own-purpose processing into instructed processing.

Regulator anchor. EDPB Guidelines 07/2020, illustrative example "Service provider referred to as data processor but acting as controller" (p. 26):

"MarketinZ decides to use GoodProducts customer database also for other purposes than advertising for GoodProducts, such as developing their own business activity. The decision to add an additional purpose to the one for which the personal data were transferred converts MarketinZ into a data controller for this set of processing operations and their processing for this purpose would constitute an infringement of the GDPR."

Worked examples.

Austria — vendor-side reclassification. The Austrian DSB found that Microsoft's own-purpose processing — including tracking via cookies containing unique identifiers — in Microsoft 365 Education is incompatible with a processor role (D135.027, October 2025; D135.026, January 2026). The DSB applied Article 4(7) to Microsoft as a private SaaS vendor. Note: both decisions are administratively issued and not yet legally final as of July 2026. Appeals are expected and the findings may be modified or overturned.

Denmark — customer-side enforcement. The Datatilsynet enforced against Google Workspace for Education (Case 2023-431-0001). It did not formally classify Google’s role, but implicitly accepted that Google processes data for its own purposes — and enforced against the municipalities. The Datatilsynet found that all 53 municipalities lacked a lawful basis for letting Google process their data for its own purposes. (The primary decision was issued in January 2024; separately, earlier decisions in the Chromebook enforcement saga criticized municipalities for insufficient control over sub-processors.)

EU Commission — both sides exposed. The EDPS Microsoft 365 Decision shows the customer-side risk. The EDPS found that the European Commission failed to limit Microsoft’s purposes through documented instructions, and sanctioned the Commission — not Microsoft.

Status: The Commission (Case T-262/24) and Microsoft Ireland (Case T-265/24) appealed in May 2024. The EDPS closed enforcement proceedings in July 2025 after the Commission submitted compliance measures, but the appeals — which challenge the original findings — remain pending.

Jurisdictional note: The EDPS applied Regulation 2018/1725 (the EU institutions’ own data protection law), not the GDPR — but the controller/processor definitions are identical.

The takeaway: when a vendor processes data for its own undisclosed purposes, both sides are exposed — the customer for failing to control what the vendor does, the vendor under Article 28(10) for the processing it controls independently. A transparent legal framework that accounts for the vendor's independent processing upfront addresses the exposure for both sides.

Sub-variant — Security log aggregation

The same logic applies when any multi-tenant SaaS vendor — not just security companies — pools customer logs into shared threat-intelligence feeds, signature databases, or datasets sold as separate products. Two things point toward controller status:

• Own purpose — selling or licensing threat feeds to customers who never contributed the data
• Essential means — the vendor decides the type of data, duration, categories of data subjects, and recipients — all four essential-means elements

The market already reflects this risk: major security vendors offer controls over telemetry and threat-intelligence sharing, and some (e.g. Palo Alto Networks) openly acknowledge dual processor/controller roles — while others keep processor-only DPAs for everything. No data protection authority has tested this sub-pattern directly yet.

Enforcement calibration. Enforcement so far has involved hyperscaler vendors in education and public-sector contexts — Microsoft 365 Education, Google Workspace for Education, the Commission's M365 deployment. No data protection authority has yet reclassified a B2B SaaS vendor under Article 28(10) for own-product analytics (as of July 2026). The legal test is sector-neutral — the enforcement gap is practical, not doctrinal (see mid-market calibration).

Compliance paths. The enforcement gap does not remove the legal risk — the doctrinal test applies regardless of company size. If you are reclassified as controller for own-purpose analytics, first decide whether you are a separate controller or a joint controller with the customer. Joint controllership is more likely when your processing serves both sides at once — e.g. a benchmark that helps your product and your customer's decisions. Separate controllership is more likely when the processing serves only you — e.g. using customer data for prospect outreach the customer never asked for. If joint, you also need an Article 26 arrangement: a written agreement spelling out who handles privacy notices, user requests, and breach notifications. Then pick one:

1. Get your own legal basis. GDPR requires a specific justification before you can process personal data — the two most realistic are consent and legitimate interest. Contractual necessity (Art. 6(1)(b)) is unlikely here — the vendor's contract is with the customer, not with the end users whose data it processes, and Art. 6(1)(b) requires processing to be necessary for a contract with the data subject. Legitimate interest requires a completed legitimate interest assessment ("LIA"). Whether this path works depends on whether you have a direct relationship with end users. In practice, it usually means adding a compliance layer to the product: a transparency notice for end users, a consent flow if consent is the chosen basis, and a channel for data subject rights requests.
2. Restructure to stay within processor scope. If obtaining an independent legal basis is not practical, limit analytics to what the customer's documented instructions authorize — removing the own-purpose component.
3. Anonymize before cross-customer use. Genuine anonymization so the resulting dataset is no longer personal data. Aggregation alone does not equal anonymization — the EDPB requires irreversibility, and for small-cohort benchmarks achieving it is difficult.

Pattern 2 — When does ML/AI training change your role?

Common claim. "We train our models on customer data only to make the service better for you."

What changes it. Pattern 1 covers reusing customer data for analytics — dashboards, benchmarks, reports — processing you can stop and reverse. This pattern is different: absorbing customer data into a model makes that data part of your product. You cannot un-train a model — and if the legal framework is not in place when enforcement arrives, remediation options narrow significantly (see Enforcement calibration below).

You are building a model for yourself — one you deploy to other customers or to the public. The own-purpose finding from Pattern 1 applies here with a harder edge: unlike analytics, you cannot un-train a model. The fact that the contributing customer also benefits from the improved model does not, by itself, keep you in a processor role. The test looks at who decided to train, not who benefits.

Major SaaS vendors changed course without waiting for regulators to act:

• Zoom — updated terms prohibit using customer communications content to train AI models (Aug 2023).
• Slack — clarified that generative AI features do not use customer data for training; traditional ML features offer an opt-out (May 2024).
• Adobe — Terms of Use expressly prohibit using customer content to train generative AI models (Jun 2024).

Regulator anchor. The CNIL flagged the controller-or-processor question in AI training chains as a priority in its 2023 AI action plan — a policy signal, not enforcement, but it names the exact question: who is responsible at each stage of the AI pipeline?

The reclassification mechanism is Article 28(10) GDPR, restated in EDPB Guidelines 07/2020, section 150: a processor that determines purposes and means is considered a controller by operation of law (discussed in detail in the CCPA comparison below).

Enforcement calibration. As with Pattern 1, no regulator has formally reclassified a B2B SaaS vendor for AI training as of July 2026. But the legal basis is clear — EDPB Guidelines 07/2020 section 150 plus the factual test data protection authorities already apply to large language model providers — and the risk extends beyond fines.

Looking beyond the EU for the outer bound of enforcement remedies: in extreme cases, regulators have ordered model deletion. The Korean Personal Information Protection Commission (January 2025) ordered Alipay to destroy a scoring model built on approximately 40 million users' data transferred without authorization from KakaoPay. In the US, the Federal Trade Commission uses "algorithmic disgorgement" — ordering companies to delete not just the improperly collected data, but also any models trained on it.

Neither example involved GDPR reclassification, and neither carries precedential weight in the EU — but both illustrate the enforcement ceiling when the legal basis for training data is challenged. Remediation costs increase sharply once a model exists — a factor that weighs in favor of establishing the legal framework before training begins.

Compliance paths. A reclassification finding does not require you to stop training — it requires a compliant framework. The joint-vs-separate controller question applies the same way as in Pattern 1 — joint when the resulting model serves both sides, separate when it serves only you. A vendor-side LIA covers separate-controller exposure only; joint controllership additionally requires an Article 26 arrangement. Then pick one:

1. Get your own legal basis. consent or legitimate interest (with a completed legitimate interest assessment) for each contributing customer’s personal data. Note: if the training data includes special-category data (Article 9), a lawful basis under Article 6 alone is not enough — you also need an Article 9(2) exception, most commonly explicit consent. Easier if users sign up individually (freemium, self-serve); significantly harder if all access runs through an enterprise admin.
2. Restructure the training pipeline. If obtaining an independent legal basis is not practical, stop training on customer data. Unlike Pattern 1 (where you can simply turn off the dashboard), stopping is not enough — you may also need to address the existing model. Options: deletion, retraining on compliant data, or — if genuine anonymization can be demonstrated (see path 3) — keeping the model in service. Note: if your model qualifies as a general-purpose AI model or feeds a high-risk system, check whether EU AI Act provider obligations apply separately (see AI Act interaction below).
3. Anonymize before training. EDPB Opinion 28/2024 sets out when an AI model can be considered anonymous — and therefore outside the scope of the GDPR. The assessment is case-by-case, not categorical.

Intermediate technical measures — such as aggregation, pseudonymization, or privacy-preserving training techniques — may reduce the volume of personal data in the pipeline, but do not automatically place the processing outside GDPR scope. A blanket assumption that aggregation equals anonymization is the gap most often flagged in practice.

Regulatory signals. No regulator has formally reclassified a vendor for AI training yet — but the pattern is already in enforcement sights, and several cases illustrate where the line is moving:

• Optimove / CNIL (Dec 2025) — EUR 1 million fine. Mobius (Optimove) copied ~46 million Deezer user records to improve its own platform without instructions, then kept the data three years post-contract. Enforced as processor-duty violations (Art. 28, 29, 30), not reclassification — but the underlying conduct overlaps with the factual pattern that would trigger reclassification analysis.
• Garante v. OpenAI (Mar 2023) — the Garante treated OpenAI as a controller for training-data processing from the start (not a reclassification case).
• Irish Data Protection Commission / Google PaLM 2 (Sep 2024) — cross-border statutory inquiry into whether Google conducted a DPIA before processing EU/EEA personal data to develop PaLM 2. No public decision as of July 2026.
• Meta / EU LLM training (2024–2025) — Meta paused EU training after Irish Data Protection Commission concerns (Jun 2024), resumed in May 2025 citing legitimate interest. EDPB Opinion 28/2024 addressed the anonymity question. The Higher Regional Court of Cologne upheld Meta's Art. 6(1)(f) basis (May 2025); noyb and several supervisory authorities continue to challenge the approach.
• EDPB ChatGPT Taskforce — the Taskforce Report stated that data subjects should be "clearly and demonstrably" informed that their content may be used for training.

AI Act interaction. If you consider path 2 (stop training on customer data), check first whether an alternative data source meets the EU AI Act’s data quality standards. Often the real constraint is not the AI Act's data quality requirements themselves, but finding training data that meets those requirements without relying on customer personal data.

The same facts that give rise to GDPR reclassification can also make you a "provider" in the AI Act sense (Regulation 2024/1689). A SaaS vendor that merely uses a third-party model internally is a "deployer" (Art. 3(4)); one that fine-tunes or trains a model and ships the result under its own brand crosses into "provider" — a role upgrade that parallels the GDPR reclassification this article discusses.

The AI Act uses "provider" to mean the entity that develops an AI system or has it developed and places it on the market under its own name or trademark — a distinct concept from "processor" or "infrastructure provider" as used elsewhere in this article. Provider obligations depend on the model and risk tier:

• General-purpose AI model provider — Art. 53 obligations, applicable from August 2025.
• High-risk AI system provider — Art. 10 data governance, applicable from December 2027 (standalone high-risk systems) and August 2028 (high-risk AI embedded in products), following the Omnibus amendment delay.

The two regimes pull in opposite directions. GDPR pushes you to collect less data and limit its use. The AI Act’s data governance rules (Art. 10) may require representative, bias-examined training datasets. For vendors whose only realistic training source is customer data, this creates a regulatory squeeze: you may need customer data to comply with the AI Act, but the GDPR says you cannot use it without a separate legal basis. The squeeze is real but narrowing. Regulatory relief is in progress — the Digital Omnibus on AI broadens the bias-detection exception, and EDPB Opinion 28/2024 accepted legitimate interest as a lawful basis for AI model training under accountability conditions — but neither eliminates the need to map both regimes before choosing a compliance path.

Limits: the AI Act does not override GDPR (Art. 2(7)). Art. 10(5) provides an exception for processing special-category data for bias detection and correction — originally limited to high-risk systems, but the Digital Omnibus on AI (adopted June 2026, awaiting Official Journal publication as of July 2026) extends this exception to all AI systems and models, with safeguards. It is still not a general basis for training on customer data.

Watch for AI-enabled support tools

A common version of this pattern: in multi-tenant B2B SaaS, support ticket text, attached screenshots, and resolution outcomes get pooled across customers to train the vendor’s suggestion model. The reclassification logic is the same as the general AI-training pattern above, but tickets add a specific risk: they are unstructured and often contain health or financial data the customer never meant to share. That can trigger Article 9 and may require a DPIA.

Vendors are already responding (as of July 2026, based on publicly available terms):

• Zendesk — offers opt-out controls; addresses AI training in supplemental terms.
• Intercom — restricts third-party AI providers from training on customer data, but says nothing about whether Intercom itself can train on it. DPA is silent on AI training as a separate processing purpose.
• Freshdesk (Freshworks) — offers opt-out controls; addresses AI training in supplemental terms. DPA is silent on AI training as a separate processing purpose.

The DPA silence is itself a gap worth examining: if the vendor trains its support-suggestion model on ticket data but the DPA does not list AI training as a separate purpose, the reclassification risk from Pattern 2 applies by default.

Pattern 3 — When does embedding a third-party SDK lead to joint controllership?

Common claim. "We just embed Google Analytics / Intercom / Meta Pixel. Their data handling is their responsibility."

What changes it. The previous two patterns involved a vendor’s own purposes — analytics or model training. This pattern shifts the lens: the risk comes not from what you do with the data, but from what the SDK provider does with it after you enable the flow — and your liability for enabling it. Under the Fashion ID ruling, embedding an SDK that causes personal data to flow to a provider processing for its own purposes is a strong indicator of joint controllership for the collection and transmission. There is no transition from processor to controller, and Article 28(10) does not apply.

Why include this in a guide about processor reclassification? Because the starting point is the same: a SaaS vendor calls itself a processor in its DPA, then discovers it was never actually a processor for SDK-driven data flows.

Important distinction. This pattern applies only when the SDK provider processes for its own purposes. If the SDK provider acts strictly as a processor under your instructions and a compliant DPA — e.g. a payment processor handling transactions solely on your behalf, or an error-tracking tool like Sentry operating under a processor DPA without own-purpose data use — the Fashion ID logic does not apply. That ruling turned on the recipient having its own purposes. This carve-out reading follows from the decision’s logic; the Court did not address the point expressly.

Where that condition is met, the logic reverses. The core idea is simple: you chose to embed it, so you caused the data to flow. That makes you partly responsible. The CJEU found in Fashion ID paragraph 78 that Fashion ID "exerts a decisive influence over the collection and transmission of the personal data of visitors to that website to the provider of that plugin, Facebook Ireland, which would not have occurred without that plugin."

Joint controllership applies even if you never see the data yourself — the CJEU held that Fashion ID was a joint controller even though it had no access to the data Facebook collected.

Overlap with Pattern 2. If the SDK provider trains on the data you send through it (e.g. an AI API with training enabled by default), both patterns apply: you are a joint controller for the data flow under Pattern 3, and the provider needs its own legal basis for training under Pattern 2. Each requires a separate compliance path.

Regulator anchor. Fashion ID (C-40/17, decided under Directive 95/46 but interpreting the same controller definition carried into GDPR Article 4(7)), paragraph 74:

"[A] natural or legal person may be a controller […] jointly with others only in respect of operations involving the processing of personal data for which it determines jointly the purposes and means. By contrast […] that natural or legal person cannot be considered to be a controller […] in the context of operations that precede or are subsequent in the overall chain of processing for which that person does not determine either the purposes or the means."

Worked example. Finnish Deputy Data Protection Ombudsman, January 2023, Helmet libraries (the shared online library of Helsinki, Espoo, Vantaa, and Kauniainen). The libraries were controllers from the start — not reclassified processors — but the facts match the Fashion ID pattern: they embedded a third-party tool that sent data to a recipient (Google) processing for its own purposes. The authority enforced on lawful basis and security grounds, not on the controller-determination analysis itself. What happened: the library ran Google Analytics and Google Tag Manager, and visitors’ search data ended up at Google. As the EDPB CEF 2022 Cloud report summarized the Finnish authority’s finding (p. 20):

"[The controllers] did not have a lawful basis for processing (the cookie banner did not work), and the controllers were also considered to have breached Articles 25 and 32 of the GDPR. […] [P]ublic authorities should not use citizens’ personal data as a means of payment, and a public authority should effectively assess whether a free service (such as a web analytics service) is in fact paid for with personal data."

Enforcement was directed against the embedding libraries, not against Google.

Worked example 2. IMY, August 2024 (Apoteket AB and Apohem AB). IMY fined two pharmacies a combined SEK 45 million (Apoteket: SEK 37M; Apohem: SEK 8M) for inadequate security measures when using the Meta Pixel. The pixel transmitted personal data to Meta — including national ID numbers and browsing activity on health-related product pages, affecting up to 930,000 individuals. IMY enforced on Article 32 security grounds only — it did not assess joint controllership with Meta. The pharmacies paid SEK 45M. Meta paid nothing.

Norway followed the same path. The Norwegian Datatilsynet (2025) found six websites unlawfully sharing personal data — including health data and children’s data — with Meta and/or Snap through embedded pixels (NOK 250,000 fine against Kristiansand Municipality; five reprimands). The CNIL’s 2025 mobile app recommendations confirm the underlying logic: the app publisher is the controller for SDK-driven processing; the SDK provider becomes an independent controller for any processing it carries out for its own purposes.

Enforcement calibration. Most enforcement actions in this space have targeted the embedder — on lawful-basis and security grounds, not on a formal joint-controllership finding. Some actions, like the CNIL’s cookie-consent fines and the Hamburg supervisory authority’s finding, have also reached the SDK provider — but these involved consent-mechanism failures, not a B2B SaaS vendor’s product-level SDK embedding. No authority has formally applied Fashion ID joint-controllership analysis to that scenario (as of July 2026). But the pattern is consistent: the embedder pays.

Compliance paths. In many cases, you do not need to remove the SDK — but you do need the right legal arrangement, and where that is not available, replacement may be necessary. If you have embedded an SDK whose provider processes data for its own purposes:

1. Formalize joint controllership. If the SDK provider processes for its own purposes, set up an Article 26 arrangement and secure a lawful basis (typically consent for marketing-related SDKs; legitimate interest may be available for SDKs serving fraud detection, security, or essential functionality) for the collection and transmission.
2. Load it conditionally. Fire the SDK only after establishing a valid lawful basis — the Fashion ID court’s reasoning indicates the embedder must independently establish lawfulness for collection and transmission. Consent is the most common choice for advertising and analytics SDKs, but legitimate interest can work for SDKs that serve a genuine security or operational need.
3. Swap it out. If the SDK provider will not enter an Article 26 arrangement or its terms make compliance impractical, replace it with a processor-only alternative that works under your documented instructions and a compliant DPA.

Pattern 4 — When does your infrastructure provider’s telemetry break the processor narrative?

Common claim. "AWS / Microsoft / Google are processors under our enterprise agreement."

What changes it. The previous pattern dealt with tools you actively chose to embed. This one concerns processing you did not choose — but may be enabling. Like Pattern 1, this involves own-purpose processing — but here the infrastructure provider, not you, initiates it. The telemetry may include or derive from your customers’ personal data flowing through the service. The hyperscaler processes telemetry and diagnostic data for its own purposes that you never asked for and often cannot turn off. Unlike Pattern 3, where you chose to embed a specific tool knowing what data it sends, here the telemetry collection is determined unilaterally by the provider. Your options are limited to opt-out controls (where they exist) and contract negotiation.

Regulator anchor. EDPB CEF 2022 Cloud report section 3.2 (pp. 12–13). The CEF report looked at public-sector cloud use, and enforcement pressure has so far focused on public bodies — but the controller/processor definitions it applies are sector-neutral.

In plain English: if your cloud service provider ("CSP") processes your customers' data for its own purposes, it is considered a controller for that processing — and you may be enabling it.

"In some cases, SAs noted that the CSP may contractually envisage data processing activities for which it acts as a controller, i.e. it processes data relating to the activities of the public body for its own purposes. In particular, the role of the hyper-scalers is not always clear, especially regarding the processing of telemetry/diagnostic data that takes place for the CSPs' purposes. As a result, CSPs would become independent controllers, if they alone decide the means and purposes of this processing. […] This can lead to situations in which a public body enables the processing of personal data from civilians and employees entrusted to the public body, by a commercial enterprise for its own purposes in violation of GDPR."

Hyperscaler telemetry chains often include sub-processors the customer cannot identify — which collides with EDPB Opinion 22/2024, the most important EDPB statement on sub-processor oversight since Guidelines 07/2020. Its holdings raise the bar specifically for telemetry:

• Controllers should have the identity of every sub-processor readily available at all times — not only upon request.
• The duty to verify sub-processor guarantees applies at every risk level, though the depth of the check scales with risk — you always check, but you check harder when the stakes are higher.
• Processors should proactively notify controllers of sub-processor changes, rather than relying solely on a published list.

For hyperscaler telemetry, this raises the bar: if you cannot name all sub-processors in the telemetry chain, you risk non-compliance with GDPR Article 28(2). Most enterprise hyperscaler agreements offer only a web-published list — which the Opinion suggests is not enough for high-risk processing.

Worked examples. The most telemetry-specific analysis to date is a DPIA commissioned by SLM Rijk, the Dutch government’s strategic vendor management body. It concluded that Microsoft should be classified as a joint controller for diagnostic telemetry in Office 365 ProPlus. This was a commissioned assessment, not a regulatory finding. The EDPS and Austrian DSB decisions discussed in Pattern 1 also involved telemetry, but as part of broader own-purpose processing — they are primarily Pattern 1 cases.

Enforcement calibration. So far, enforcement has hit the customer side only. The EDPS issued corrective measures against the Commission for failing to control Microsoft’s purposes; the Danish Datatilsynet enforced against municipalities for, among other things, permitting Google’s own-purpose processing. No data protection authority has yet reclassified a hyperscaler as controller under Article 28(10) for telemetry processing (as of July 2026). The vendor-side exposure is legally clear but untested. That said, customer-side enforcement means you are the one who pays — even when the hyperscaler’s conduct is the root cause. That makes your DPA and supplementary measures the lever you actually control.

Compliance paths. Unlike Patterns 1–3, you have limited leverage — you cannot rewrite AWS’s or Microsoft’s telemetry terms. Three realistic paths:

1. Audit for opt-out controls and sub-processor visibility. Check your provider’s DPA and service settings for telemetry opt-outs — Microsoft’s EU Data Boundary and some AWS settings give you partial levers, though coverage varies by service tier. Also verify you can identify all sub-processors in the telemetry chain, per EDPB Opinion 22/2024.
2. Document the gap. Where opt-out is not available, record the residual risk in your DPIA (Articles 24 and 35) and keep it ready for data protection authority inquiries.
3. Assess whether a supplementary arrangement is needed. For high-risk processing (e.g. health or financial data flowing through the hyperscaler), assess whether your DPIA adequately documents the residual risk — and whether a supplementary arrangement with the provider is both available and proportionate to the processing at issue.

Which reclassification patterns lack direct enforcement so far?

These two patterns rest on the same legal logic as the four patterns above, but no regulator has tested either one yet and no established compliance path exists for either. Keep them on your radar — but until the compliance path clarifies, focus on the four patterns above unless your product's facts make one of these two unavoidable.

When does a marketplace structure lead to joint controllership?

Under GDPR, if your marketplace decides how listings are ranked, matched, or surfaced, you may be a joint controller with the merchants whose data you process. Those decisions determine how personal data is used — and that makes you partly responsible alongside your merchants.

The CJEU confirmed this in Russmedia Digital (C-492/23, 2 December 2025). The case involved a classified-ads platform — think of any site where users post listings and the platform controls how those listings appear, get ranked, and reach an audience. The Court held that the platform operator qualifies as a controller — whether jointly with or independently of the advertising user. Why? Because the platform sets the rules: how ads are uploaded, structured, ranked, shown to users, and monetized. It did not matter that the platform had no knowledge of what any specific ad contained.

Russmedia was about a platform that never claimed to be a processor, so the court did not address reclassification directly. But the core question is the same: who decides the purposes, and who shapes the means of processing? No regulator has yet enforced on who is controller in a marketplace setup, but Russmedia gives this pattern a much stronger doctrinal footing. For SaaS marketplaces that claim processor status in their merchant DPAs, Russmedia's reasoning would support a finding that they were controllers all along.

A separate but reinforcing obligation comes from the Digital Services Act ("DSA", Regulation 2022/2065). DSA Art. 30 requires online marketplaces to collect, verify, and store trader identity information. That is a legal obligation placed on the platform — not processing done on the trader’s instructions. In our view, this makes the platform a controller for that processing, though the DSA itself does not say who is controller or processor under GDPR.

If your platform controls ranking or matching, the practical first step is to check whether you have an Article 26 arrangement — or at minimum a role-allocation clause in your merchant terms — that covers the controller role Russmedia’s reasoning would support.

When does a white-label reseller chain create reclassification risk?

A white-label reseller that adds its own processing purposes on top of the upstream vendor’s service — marketing automation, churn analysis, and reseller-only dashboards — is likely a controller for those purposes. If the reseller originally operated as a processor, the legal mechanism is the same Article 28(10) reclassification as in Patterns 1, 2, and 4. If it had independent purposes from the start, no reclassification is needed — it was a controller all along. The EDPB CEF 2022 Cloud report flagged gaps in reseller contracts but stopped short of a role finding. So far, enforcement has focused on contracting discipline — sub-processor rules and instruction documentation — not on reclassification itself.

The practical step is to check whether your merchant terms or reseller agreements allocate controller and processor roles, and revisit if the EDPB or a national supervisory authority issues guidance on marketplace or reseller classification.

What changes after reclassification — beyond the regulatory risk?

The patterns above cover how reclassification happens — whether through own-purpose analytics, model training, SDK embedding, infrastructure telemetry, or the emerging marketplace and reseller scenarios. This section covers what happens next — the practical consequences that are often more disruptive than a regulatory fine.

Your data transfer basis may stop working

If you are a US-headquartered SaaS vendor, your EU customers' data flows to you under a transfer mechanism — typically Standard Contractual Clauses ("SCCs"), Module 2 (controller-to-processor). Those SCCs assume you are a processor acting on the customer's instructions.

If you are reclassified as a controller, Module 2 SCCs no longer cover the reclassified processing — the module covers controller-to-processor transfers only. You need a new transfer basis — either Module 1 SCCs (controller-to-controller), which requires renegotiating with every EU customer, or independent certification under the EU-US Data Privacy Framework ("DPF"), which covers all EU customers at once.

DPF certification is the faster path: it is entity-specific (you self-certify at dataprivacyframework.gov) and eliminates the need for per-customer SCC renegotiation. If you are not yet DPF-certified and get reclassified, the gap between reclassification and establishing a new transfer basis is a live compliance exposure.

The DPF's adequacy has been challenged (Latombe v. Commission, Case T-553/23, rejected on the merits September 2025; appeal pending as Case C-703/25 P). If the appeal succeeds, DPF-certified vendors would need a fallback transfer mechanism — most likely SCCs with supplementary measures.

No EDPB or data protection authority decision has directly addressed the intersection of Art. 28(10) reclassification and Chapter V transfer obligations. The conclusion that Module 2 SCCs cannot cover a reclassified controller follows from the modular structure of the 2021 SCCs, but no authority has stated it in those terms.

Your customer contracts may break

Most enterprise DPAs contain a core warranty: the vendor will process data "only as a processor" and "solely on the controller's documented instructions." When you are reclassified, that warranty is breached — not because you changed the contract, but because your conduct changed your legal status.

The practical cascade:

• Termination rights. A warranty breach typically constitutes material breach, giving the customer termination-for-cause rights. In practice, customers rarely exercise this immediately — switching vendors is expensive — but the right creates leverage in renegotiations.
• Indemnification exposure. Enterprise SaaS agreements usually include indemnification for GDPR violations. But indemnity caps — typically 1–2x annual contract value — may be grossly inadequate relative to the regulatory exposure that reclassification creates.
• M&A impact. Unresolved reclassification risk is a red flag in due diligence — see mid-market calibration below for why this is typically the highest-impact commercial consequence.
• Insurance gaps. Cyber insurance policies typically cover data breaches, not structural compliance failures like incorrect role classification. No publicly reported coverage dispute has tested this scenario, so coverage is uncertain.

No court has adjudicated a contractual warranty-breach claim arising from Art. 28(10) reclassification. The exposure is real — particularly the question of whether standard indemnity caps can absorb the downstream liability — but the more immediate commercial consequence is the leverage shift in customer relationships.

Civil liability adds a separate layer. Article 82 GDPR gives any person who suffers damage the right to claim compensation directly from the controller — including a reclassified vendor that never interacted with those data subjects. Individual awards remain modest (EUR 100–500 in typical German cases), but Germany's 2023 collective-action law (Österreichische Post, C-300/21, confirmed no minimum-seriousness threshold) enables mass claims that can produce significant aggregate exposure. No Art. 82 claim has yet targeted a vendor reclassified from processor to controller.

How realistic is enforcement for a mid-market SaaS?

Most enforcement examples in this article involve hyperscalers (Microsoft, Google), public-sector contexts (the European Commission, Danish municipalities), or companies processing data at consumer scale (pharmacies, libraries) — though a few involve mid-market companies in specific sectors (Fashion ID, Arity). If you are a Series B SaaS with 500 customers and $40 million in revenue, your risk profile is different.

Data protection authorities select enforcement targets thematically, not by company size. The CNIL publishes annual priority themes (2026: recruitment, the unique electoral register, sports federations). The EDPB runs annual coordinated enforcement actions (2026: transparency obligations). None of the announced 2026 themes directly targets controller/processor classification. No supervisory authority has published a strategy of "working down the stack" from hyperscalers to mid-market vendors, and no enforcement action has targeted a mid-market B2B SaaS vendor for controller/processor misclassification as of July 2026.

The realistic risk ranking for a mid-market B2B SaaS vendor:

1. M&A due diligence flags — the highest-impact commercial risk. Acquirers now embed GDPR posture into technical due diligence, and open classification questions create contingent liability that acquirers struggle to quantify. A processor-only DPA that does not match the product's actual data flows is a red flag specialized privacy counsel will find — and it can reduce deal values or delay closing.
2. DPA negotiation friction — most enterprise DPA reviews are checkbox exercises: sub-processors, transfer mechanisms, audit rights. But when a customer's privacy team sees own-purpose analytics, model training on aggregated usage data, or third-party SDKs collecting independently — none of which the DPA accounts for — the conversation shifts from standard terms to role classification. That is a harder negotiation — it requires either restructuring the DPA into a dual-role framework or explaining why the processing is genuinely within the customer's instructions. Either path adds weeks and involves senior legal on both sides.
3. Data protection authority investigation — low probability for a compliant mid-market B2B SaaS. Typically requires a data breach notification, a complaint from an EU customer, or a thematic sweep hitting your sector.

This does not mean reclassification risk is irrelevant at mid-market scale — it means the consequences arrive through commercial channels before regulatory ones. Building the right legal framework is cheaper when you choose the timing than when a due diligence review or a customer's privacy team forces it.

When does the CCPA "service provider" badge fail under GDPR?

This section covers CCPA and touches Texas’s Data Privacy and Security Act ("TDPSA").

The four patterns above are GDPR-native. Many SaaS vendors selling into the EU built their data-handling framework around the California Consumer Privacy Act ("CCPA") first and assume it translates. The two labels are not interchangeable — GDPR Article 28(10) provides that where a processor determines purposes and means, it is considered a controller — by operation of law, without a formal regulatory decision. A vendor can pass the CCPA "service provider" test and still be reclassified as a controller under GDPR if its conduct goes beyond the customer's instructions.

In practice, independently determining even one essential means — such as which categories of data to process, retention periods, or recipient access — is a strong indicator of controllership, though the assessment remains context-dependent.

Note: CPRA also introduced a "contractor" category (§1798.140(j)) as a middle tier between service provider and third party, but it has not featured in enforcement and is not analyzed here.

The CPRA (operative January 1, 2023) and the CPPA’s implementing regulations, including Section 7050 (effective March 2023), tightened the rules. Three changes matter:

• Restricted use beyond the business purposes specified in the contract
• Added stricter sub-contracting requirements
• Limited "service improvement" to the service provided to the same business (as shown in the table above)

This narrowed the gap with GDPR — but did not close it. GDPR requires the processing contract to specify subject-matter, duration, nature, purpose, data types, and data-subject categories (Art. 28(3)), plus records of processing activities (Art. 30) — a more granular standard than CCPA's contractual requirements.

The enforcement pattern tells the same story each time:

• Sephora ($1.2M, California AG, Aug 2022) — failed to maintain CCPA-compliant service-provider contracts, so data transfers to third-party trackers qualified as "sales"; separately, Sephora failed to honor Global Privacy Control opt-out signals.
• Tractor Supply ($1.35M, CPPA, Sep 2025) — service-provider and third-party contracts lacked privacy provisions required by the CCPA and CPPA regulations.
• DoorDash ($375K, California AG, Feb 2024) — shared data with marketing cooperatives without opt-out.
• General Motors ($12.75M settlement, California AG, May 2026; court approval pending) — sold driving data to LexisNexis Risk Solutions and Verisk — which intended to build driver-rating products for auto insurers — without telling drivers. First CCPA enforcement based on data minimization and purpose limitation.

The SaaS takeaway: if you disclose data for money or anything of value, that is a "sale"; if you disclose it for cross-context behavioral advertising (even without consideration), that is "sharing." Both engage opt-out obligations. What the parties call it does not matter.

California is not the only state where this failure mode has consequences. The Texas AG’s January 2025 action against Allstate/Arity under the TDPSA mirrors Pattern 3: Arity embedded its SDK in third-party apps and sold the collected driving data to insurers. The Texas court dismissed for lack of personal jurisdiction (April 2025) — a procedural outcome; a federal class action in Illinois is proceeding.

The failure mode is the same in both regimes: the recipient acts beyond the agreed boundaries, and the label stops protecting the recipient.

What this means in practice. If your customers span both regimes, your DPA needs to pass two gates at once: the CCPA service-provider contract requirements and the GDPR instruction-documentation requirements. Many off-the-shelf US SaaS service-provider agreements were not built to satisfy both.

Structurally, a dual-regime DPA needs two things:

• Section 7050-compliant purpose restriction — lists the permitted business purposes (CCPA side).
• Article 28(3)(a) instruction schedule — spells out each processing operation the processor may carry out (GDPR side).

But structure alone is not enough: having the right DPA reduces reclassification risk without eliminating it. If your product actually determines purposes or essential means (what data, how long, who sees it) beyond what the schedule allows, both labels fail on the facts. Align the product behavior to the schedule, not just the schedule to the product.

The four patterns in this article are not edge cases — they describe how most B2B SaaS products actually work. The question is not whether your product touches one of them, but whether your legal framework accounts for it before a customer audit, an M&A review, or a regulatory inquiry forces the conversation.

Need to figure out where your SaaS sits on these 4 patterns?

Whether you need a one-time classification review or ongoing support as your product evolves, reach out to our Privacy & AI Compliance team at info@buzko.legal.

* * *

This article is for informational purposes only and does not constitute legal advice.