SaaS Contracts · Memo

Multi-Tenant Data Isolation in SaaS DPAs After CPPA's ADMT Rulemaking

The CPPA's automated decisionmaking regulations have pulled multi-tenant data isolation out of the security appendix and into the substantive obligations of the data processing addendum. I am going to walk through the drafting moves that survive the new rules.

For most of the past decade, multi-tenant data isolation in SaaS DPAs was a security topic. The DPA recited that the processor would maintain logical separation among tenants, that access controls would prevent cross-tenant access, and that audit logs would be available on request. The substantive privacy obligations sat elsewhere: in the CCPA-mandated service-provider terms, in the GDPR Article 28 processor obligations, and in any sector-specific overlay (HIPAA, GLBA, FERPA). The isolation language was largely template work.

The California Privacy Protection Agency's automated decisionmaking technology rulemaking has changed that. The final ADMT regulations, adopted under Civ. Code section 1798.185 authority, require pre-use notice, opt-out, and access rights for certain significant decisions made about California consumers using automated decisionmaking technology. The rules apply to businesses that use ADMT, but the operational implementation runs through the SaaS processors that host the models, the training data, and the inference logs. The DPA is now the document where the allocation of ADMT obligations actually gets written down.

Why multi-tenant architecture creates a specific drafting problem

The CPPA's framework treats the business as the controller of automated decisions about its consumers. In a multi-tenant SaaS deployment, the business's data sits alongside data from every other tenant, processed by the same model weights, generating inferences through the same pipeline. The processor's contractual position is that each tenant is logically separated and that the model itself is not a controller because the processor does not make decisions about any tenant's consumers; the tenant does.

That position is defensible in most architectures, but it depends on drafting that does the work. The DPA needs to allocate three distinct categories of ADMT-adjacent risk: training-data contributions across tenants, inference logs that may aggregate signals across tenants, and model updates that propagate changes derived from one tenant's data to other tenants' deployments. Each category has a separate isolation analysis and a separate set of drafting choices.

Training-data contributions across tenants

The first question is whether the processor uses tenant data to train or improve the shared model. The honest answer for many modern SaaS products, particularly those with AI features, is yes in some form. The drafting needs to address what 'training' means, what data is excluded by default, what the tenant must opt in to before any contribution occurs, and what happens to model artifacts that have already incorporated the tenant's data when the tenant terminates the agreement.

The clean DPA drafting moves: a default-off training contribution that requires affirmative tenant consent; a definition of training that captures fine-tuning, retrieval-index incorporation, embedding-store contributions, and reinforcement-learning-from-human-feedback signal; an exclusion for evaluation logs and aggregate metrics that do not flow back into the model weights; and an exit obligation that requires the processor to remove tenant-specific contributions from any model on termination, with a documented procedure for what that removal means and what residual artifacts may persist. I have seen too many DPAs that recite a 'no training on customer data' commitment without defining training. The commitment is unenforceable if the term is undefined.

Inference logs and cross-tenant signal

The second category is the inference log. Modern SaaS products generate detailed logs of model inputs, model outputs, and the surrounding context. The logs are useful for debugging, for monitoring quality, and for compliance reporting. They also constitute a potential cross-tenant signal source: if the processor analyzes log patterns across tenants to improve model performance, the analysis may use one tenant's data to derive insights that benefit other tenants.

The CCPA's service-provider framework restricts processors from using personal information beyond the limited purposes specified in the contract. The ADMT regulations add that businesses deploying ADMT need to be able to explain the logic of automated decisions to consumers. If the processor's log analysis materially affects the model's decisional logic, that affects the explanation the business must provide. The DPA should specify what log data the processor may use, for what purposes, with what cross-tenant aggregation permitted, and what the tenant can audit. The aggregation-permitted category is where drafting attention is concentrated. A blanket prohibition is unrealistic; a vague permission is dangerous.

Model updates and propagated changes

The third category is model updates. When the processor releases a new model version, the tenant inherits behavior that may have been shaped by other tenants' interactions. From a CCPA-compliance perspective, the tenant is still the controller of the decisions made about its consumers; the model is a tool. But the tenant cannot meaningfully exercise control if the model's behavior shifts in ways the tenant cannot anticipate or audit.

The drafting moves: notice obligations for material model changes, with a definition of material that the tenant can rely on; an option for the tenant to pin a specific model version for a contracted period; a regression-test report or behavioral-change documentation that the tenant receives with each major update; and a right to refuse a model update for a defined transition window, with the processor obligated to maintain the prior version for that window. Not every SaaS vendor will agree to these terms, but the enterprise tenants who care about ADMT compliance are increasingly insisting on at least notice and pinning.

Audit rights at the tenant level

The traditional DPA audit right is the SOC 2 report or an equivalent third-party attestation. The ADMT regulations push toward more granular tenant-level audit. The tenant needs to be able to verify, on demand, that its data is not being used outside the contracted purposes, that its inference logs are isolated, and that any model contributions have been removed on termination.

The drafting compromises that I see working: the processor commits to maintain tenant-specific audit logs, made available to the tenant on a defined cadence or upon reasonable request; the processor commits to support an independent audit of the tenant's specific deployment, at the tenant's expense, with reasonable notice; the processor commits to provide a contractual representation, signed by an authorized officer, that no cross-tenant data sharing has occurred outside the permitted purposes during the audit period. The combination of programmatic audit logs, contractual representation, and on-demand audit gives the tenant defensible posture for its own ADMT compliance.

The service-provider versus contractor distinction

The CCPA distinguishes between service providers (who process personal information on behalf of the business) and contractors (a slightly different category with similar but not identical obligations). The CPPA's regulations apply the same restrictions to both categories for most purposes, but the precise contractual language differs. A SaaS DPA needs to identify, explicitly, whether the processor is a service provider or a contractor and to use the corresponding contractual representations.

For multi-tenant deployments, the service-provider framing is usually the right one. The contractor framing is more often used for vendors who receive personal information for limited business purposes beyond service delivery. The CPPA enforcement actions through 2024-2025 have focused on processor compliance with the service-provider restrictions in particular. The DPA should mirror the regulatory language as closely as the commercial deal permits.

Exit obligations and isolation on termination

The most underweighted DPA section in multi-tenant SaaS is the termination section. The standard recital is that the processor will delete or return tenant data on termination. In a multi-tenant model architecture, that recital is unenforceable on its face. The processor cannot delete the model weights that incorporated tenant signals; it cannot delete the embeddings that derived from tenant queries; it cannot delete the prompts that informed the system messages.

The drafting needs to acknowledge this. The DPA should specify what categories of data are deleted on termination (tenant-specific records, identifiable inference logs, retrieval indices), what categories are retained in transformed or aggregated form (model weights, embeddings, training derivatives), and what the processor commits to do with respect to the retained categories (no further use for the tenant's identifiable purposes, no re-identification, no sharing). The tenant should expect that some retained signal will persist; the question is what the processor commits to do with it.

How CPPA enforcement signals interact with the drafting

The CPPA's enforcement priorities through 2024-2025 have included service-provider compliance, the deletion-on-termination obligation, and the cross-context behavioral advertising restrictions. The ADMT regulations layer pre-use notice and access rights onto these existing obligations. A DPA that addresses the categories above is more defensible against a CPPA enforcement action than a DPA that recites generic isolation language without operational specifics.

The specific enforcement signal that I weigh most heavily is the CPPA's stated interest in evidence-based compliance. The agency has indicated, in enforcement advisories and in informal guidance, that it expects processors to produce documentation when asked. The DPA should require the processor to maintain that documentation and to make it available to the tenant on reasonable request. The reciprocal obligation should be in the tenant's interest as well: the tenant will need the documentation if it faces a consumer rights request or a CPPA inquiry.

What I would not assume

The CPPA's ADMT regulations are new. The final text was adopted in 2025 and the operational compliance dates extend into 2026 and beyond. The case law on processor obligations in the ADMT context does not yet exist; the enforcement record is still being built. Counsel drafting DPAs should expect that the operational expectations will shift as the agency issues guidance and as the first enforcement actions are resolved. The drafting moves I describe are defensible against the regulations as written. They may need to be adjusted as the regulatory expectations are refined. The most durable drafting principle is to write the DPA to a level of specificity that allows the tenant to audit its compliance posture and to demonstrate it to regulators. Generic isolation language is no longer sufficient. Outcomes in specific matters depend on the architecture, the deployment, and the regulatory posture.

Sergei Tokmakov, Esq., CA Bar #279869. This memo is attorney commentary on legal questions and is not legal advice. Reading it does not create an attorney-client relationship. Past matter outcomes depend on facts and the responding party; nothing here is a prediction of result.