Sub-processor change notices under US privacy laws

Almost everything written about sub-processor change notices is about GDPR Article 28. If your clients are US companies and your contracts are CCPA service-provider terms or state-law processor terms, the rules are different, and in some states lighter than people assume.

This page covers what the statutes in California, Colorado and Virginia say when a service provider or processor brings in a new sub-processor, such as a new cloud host, an enrichment vendor or an AI tool. Then it covers the part the statutes don't answer: how to tell 80 clients and prove you did. If you sell data or APIs to businesses, Pacts for data vendors covers the wider picture.

All three laws require a written contract that passes your obligations down to the sub-processor. They differ on whether the client must be told and whether it gets a say.

California. Under the CCPA, the definitions of "service provider" and "contractor" each include this paragraph: if the service provider "engages any other person to assist it in processing personal information for a business purpose on behalf of the business... it shall notify the business of that engagement, and the engagement shall be pursuant to a written contract binding the other person to observe all the requirements set forth in paragraph (1)" (Cal. Civ. Code § 1798.140(ag)(2); (j)(2) is the same for contractors). The statute doesn't say when or how the business has to be notified, and it doesn't give the business a right to object. The CCPA regulations add that the subcontract itself has to meet the regulations' contract requirements (Cal. Code Regs. tit. 11, § 7051(b)).

Colorado. The Colorado Privacy Act says that, notwithstanding the controller's instructions, a processor shall "engage a subcontractor only after providing the controller with an opportunity to object and pursuant to a written contract... that requires the subcontractor to meet the obligations of the processor with respect to the personal data" (C.R.S. § 6-1-1305(3)(b)). That is the only one of the three that puts the client's chance to object before the engagement.

Virginia. The Virginia Consumer Data Protection Act requires the controller–processor contract to say that the processor will "engage any subcontractor pursuant to a written contract... that requires the subcontractor to meet the obligations of the processor with respect to the personal data" (Va. Code § 59.1-579(B)(5)). There is no express duty to notify the controller and no express right to object.

In practice it means telling the client before the new sub-processor starts, with enough detail to decide. The Colorado statute doesn't say what the notice contains or how long the client gets. To decide whether to object, a client needs to know:

• who the sub-processor is;
• what it will do for you;
• which client data it will touch;
• where it processes that data;
• when the change takes effect, and how to raise a concern before then.

The length of the window is set by your contract, not by the Colorado statute. GDPR practice usually builds in a window too; the EU rules are covered in notifying clients under GDPR and LGPD. What happens if a client does object is also a contract question, for you and your counsel rather than the statute.

The notice you owe is often defined in paper you already sent. Many DPAs promise advance notice by email, a set number of days, or a subscription to a sub-processor list. If you sent your own DPA, or signed a client's, those terms apply on top of the statute, and they can be stricter than all three laws above.

So before a vendor change, pull up the DPA each affected client is on and read its sub-processor clause. If different clients are on different versions, the obligations may differ too. That's a common result of signing each client's paper. If your clients are California businesses, the CCPA service-provider contract terms page covers the rest of what that contract has to contain.

A public list shows what changed. It doesn't show who was told. California's statute says "notify the business", and Colorado's requires an opportunity to object before the engagement. In both cases the question afterwards is the same: can you show which clients were told, when, and which version of your terms each one is on?

For a 30-person data vendor with 80 clients, that usually means an email blast and a spreadsheet. The email goes out, and three months later nobody can say who opened it, who replied, or which clients are still on the old DPA. For an agency sitting between brands and platforms, the same change may need to go both ways. Pacts for agencies covers that position.

One way to keep the record is to treat the change as a new version of your terms and ask every client to accept it. That's how Pacts handles it.

When you publish a material change to a template, such as a DPA with an updated sub-processor annex, Pacts drafts a re-acceptance campaign covering every client contact who isn't yet on the new version. Before anything goes out you write a short note on what changed; the note is required. Clients who accepted the old version get an email with your note and a link to accept the new one. Nothing is updated silently. Each send is recorded, the template page shows how many clients have re-accepted, and you can nudge the rest. A coverage board shows, across your client book, who is on current terms and who isn't. Each acceptance comes with a certificate recording the exact text accepted and its SHA-256 hash.

What Pacts doesn't do: it doesn't collect or manage objections. If a client objects, they tell you, and your contract decides what happens next. If you're weighing a signature tool for this instead, see clickwrap vs e-signature.