A platform company sells a product to a business. That business uses the platform to serve its own customers. The platform now holds data belonging to people it has no direct relationship with — people who never signed up for its service, never agreed to its privacy policy, and may not even know the platform exists.

Call the business the C1 — the direct customer. Call the business's customer the C2 — the customer's customer. The platform processes C2 data as a function of serving C1. This is the C2 problem, and it sits at the heart of how modern SaaS platforms, fintech companies, and enterprise software providers must think about privacy.

An accounting platform processes the invoices, payment records, and personal details of its customer's clients. A payroll platform processes the salary data, tax identifiers, and bank account numbers of its customer's employees. An e-commerce platform processes the purchase history, shipping addresses, and payment information of its customer's buyers. In every case, the platform is processing C2 data at scale, often across millions of C2 individuals, and the regulatory question is: who is responsible for that data?

The regulatory framework

Three major privacy regimes address this question. Each uses different terminology but arrives at a structurally similar answer — with critical differences in liability, obligation scope, and enforcement.

GDPR: Controller and Processor

Under the General Data Protection Regulation, the C1 (the business) is typically the data controller — the entity that determines the purposes and means of processing personal data (Article 4(7)). The platform is typically the data processor — the entity that processes personal data on behalf of the controller (Article 4(8)).

Article 28(1) establishes the foundational obligation: the controller must use only processors that provide "sufficient guarantees to implement appropriate technical and organisational measures" such that processing meets GDPR requirements. This is not a passive obligation. The controller must affirmatively vet the processor before engaging it.

Article 28(3) mandates a written contract between controller and processor that specifies, at minimum, the subject matter and duration of processing, the nature and purpose, the type of personal data and categories of data subjects, and the controller's obligations and rights. The contract must also require the processor to process data only on documented instructions from the controller (Article 28(3)(a)), ensure that persons authorised to process data are bound by confidentiality (Article 28(3)(b)), implement security measures per Article 32 (Article 28(3)(c)), and assist the controller in responding to data subject requests under Chapter III (Article 28(3)(e)).

This last point is where C2 rights become architecturally significant. When a C2 — the business's customer — exercises their right to access, erasure, or portability, the request goes to the C1 (the controller). But the data lives on the platform. Article 28(3)(e) requires the platform to assist the C1 in fulfilling that request. The platform must have the technical capability to locate, extract, correct, or delete a specific C2's data on instruction from the C1. If the platform cannot do this, the C1 cannot comply with the GDPR, and the processor relationship is non-compliant.

On sub-processing, Article 28(2) requires the processor to obtain "prior specific or general written authorisation" from the controller before engaging another processor. Article 28(4) requires the same data protection obligations from the contract between controller and processor to be imposed on any sub-processor. And critically: where a sub-processor fails to fulfil its obligations, the initial processor "shall remain fully liable to the controller for the performance of that other processor's obligations." The chain of accountability runs from C2 through C1 through the platform through its sub-processors — and liability flows in the opposite direction.

Article 82 makes this concrete on damages. Both controllers and processors can be held directly liable by data subjects for material or non-material damage resulting from GDPR violations. A processor is liable for damage "only where it has not complied with obligations of this Regulation specifically directed to processors" or where it has acted "outside or contrary to lawful instructions of the controller." The platform is not shielded simply because it was acting on the C1's behalf.

CCPA/CPRA: Business and Service Provider

Under the California Consumer Privacy Act (as amended by CPRA), the analogous relationship uses different terms. The C1 is the business — the entity that collects consumers' personal information and determines the purposes and means of processing (Section 1798.140(d)). The platform is the service provider — an entity that processes personal information on behalf of a business pursuant to a written contract (Section 1798.140(ag)).

The CCPA/CPRA imposes a critical contractual requirement to qualify as a service provider rather than a "third party." The written contract must prohibit the service provider from "retaining, using, or disclosing the personal information for any purpose other than for the specific purpose of performing the services specified in the contract for the business" (Section 1798.140(ag)(1)(A)). The contract must also prohibit the service provider from selling or sharing the personal information, and from combining C2 data received from the business with personal information received from other sources or collected from its own interactions with the consumer (Section 1798.140(ag)(1)(B)).

This anti-commingling requirement is distinctive to CCPA/CPRA and architecturally consequential for platforms. If the platform serves a thousand C1 businesses, and each C1's customers (C2s) are end consumers, the platform must ensure that C2 data received from Business A is never combined with data received from Business B or with data the platform collects directly. This is a data isolation requirement that must be enforced in the platform's data architecture, not just in its legal agreements.

On consumer rights, the obligation structure differs from GDPR. Under CCPA/CPRA, the business (C1) is responsible for responding to consumer (C2) requests for access, deletion, and correction. The service provider (platform) is not directly obligated to respond to C2 requests — but it must cooperate with the business in fulfilling them. The CPRA also requires that the contract permit the business to monitor the service provider's compliance, including through assessments, audits, or other testing at least once every twelve months (Section 1798.140(ag)(1)(D)).

On sub-processing, CPRA requires that if a service provider engages a sub-processor, it must notify the business and enter into a contract with the sub-processor containing the same restrictions. The service provider bears responsibility for the sub-processor's compliance.

DPDP Act: Data Fiduciary and Data Processor

India's Digital Personal Data Protection Act, 2023 maps the C1-platform relationship through the concepts of Data Fiduciary and Data Processor. The C1 is the Data Fiduciary — "any person who alone or in conjunction with other persons determines the purpose and means of processing of personal data" (Section 2(i)). The platform is the Data Processor — "any person who processes personal data on behalf of a Data Fiduciary" (Section 2(k)).

Section 8(1) of the DPDP Act establishes a principle that is stricter than GDPR in one crucial respect: the Data Fiduciary is responsible for complying with the Act "irrespective of any agreement to the contrary" and irrespective of any failure by the Data Principal to carry out their duties. This means the C1 cannot contractually transfer its DPDP obligations to the platform. The C1 remains liable regardless of what the contract says. This non-delegable liability is absolute.

Section 8(2) requires that a Data Fiduciary may engage a Data Processor "only under a valid contract." Section 8(5) requires the Data Fiduciary to protect personal data "including in respect of any processing undertaken by it or on its behalf by a Data Processor, by taking reasonable security safeguards." The Fiduciary's duty to secure C2 data extends to data held by the platform, not just data held by the Fiduciary itself.

On breach notification, Section 8(6) places the obligation on the Data Fiduciary — not the Data Processor — to notify the Data Protection Board and each affected Data Principal. If a breach occurs at the platform (Data Processor), the Fiduciary (C1) must still deliver the notification. This requires the platform to have detection, classification, and reporting capabilities sufficient to inform the C1 in time for the C1 to meet the 72-hour intimation deadline under the DPDP Rules.

On data erasure, Section 8(7)(b) is explicit: the Data Fiduciary must "cause its Data Processor to erase any personal data that was made available by the Data Fiduciary for processing to such Data Processor." The platform must implement deletion capabilities that respond to C1 instructions to erase C2 data — and the C1 must have the contractual and technical mechanism to issue those instructions.

The DPDP Act is notably lighter on processor-specific obligations than GDPR. There is no equivalent to GDPR Article 28's detailed list of mandatory contractual terms. The Act places the entire weight on the Fiduciary and expects the Fiduciary to govern its Processor through contract. For platforms, this means the contractual relationship with C1 customers in India will be the primary governance mechanism — and the platform should expect increasingly prescriptive contracts from Indian C1 customers as DPDP enforcement begins.

What this means architecturally

The regulatory analysis leads to concrete architectural requirements for any platform that processes C2 data.

Data isolation. C2 data received from different C1 customers must be logically — and in some cases physically — isolated. CCPA's anti-commingling requirement makes this explicit, but the principle applies universally. A platform that mingles C2 data across C1 boundaries cannot fulfil deletion requests accurately, cannot prevent cross-C1 data leakage, and cannot comply with purpose limitation requirements under any jurisdiction.

DSR fulfilment APIs. The platform must expose capabilities — typically APIs — that allow C1 customers to locate, access, export, correct, and delete specific C2 data. GDPR Article 28(3)(e) requires this. DPDP Section 8(7)(b) requires this. If the C1 cannot instruct the platform to delete a specific C2's data and receive confirmation that the deletion occurred, the entire controller-processor relationship is non-compliant.

Breach detection and notification pipeline. The platform must detect breaches affecting C2 data and notify the affected C1 within a timeframe that allows the C1 to meet its own regulatory obligations. Under DPDP, the C1 must notify the Board within 72 hours. Under GDPR, the controller must notify the supervisory authority within 72 hours. The platform's detection-to-notification latency must be measured in hours, not days.

Sub-processor governance. If the platform engages sub-processors — cloud providers, analytics services, support tools — the same obligations flow down. GDPR Article 28(4) and CCPA/CPRA both require this contractually. The platform must maintain a registry of sub-processors, ensure contractual flow-down of obligations, and notify C1 customers of sub-processor changes.

Audit and compliance evidence. The C1's regulators may require the C1 to demonstrate that its processor (the platform) is compliant. GDPR Article 28(3)(h) requires the processor to make available all information necessary to demonstrate compliance and allow for audits. CPRA requires monitoring at least annually. The platform must maintain audit-ready evidence of its security controls, processing activities, and compliance posture — not as a favour to its C1 customers, but as a contractual and regulatory obligation.

The overlooked truth

Most platform companies think about privacy in terms of their own users. The privacy policy on the website. The cookie consent banner. The terms of service. These address the direct relationship between the platform and its C1 customers.

But the larger privacy surface — often by orders of magnitude — is the C2 data. A platform with ten thousand business customers, each serving a thousand end consumers, processes data on ten million C2 individuals. Those ten million people never signed the platform's privacy policy. They may not know the platform exists. And yet, under every major privacy regulation, the platform has obligations to them — obligations that flow through the C1 relationship but are no less real for being indirect.

The C2 problem is not a legal edge case. It is the central privacy architecture problem for every platform business. The platform that solves it — that builds data isolation, DSR fulfilment, breach detection, sub-processor governance, and audit capability into its core architecture — is the platform that can serve regulated C1 customers in every jurisdiction. The platform that ignores it is one regulatory inquiry away from discovering that its entire C1 customer base is non-compliant, and that the non-compliance originates in the platform itself.