Most teams read the California pre-use notice as a launch task: add a notice to the signup flow for the new scoring feature. That reading misses the customers you already have. Section 7220(b)(2) of the CCPA regulations says that if you collected someone's personal information for one purpose and later plan to run it through automated decisionmaking technology (ADMT) for a significant decision, the notice is due before that processing starts. Data you collected in 2022 does not get a pass.
This piece is about timing and delivery, the two parts of section 7220 that decide whether a notice counts. The content of the notice, and how to build it as a component, is covered in building the pre-use notice and opt-out. If you are not sure your tool is covered at all, start with what counts as ADMT.
A definition first. A pre-use notice is the disclosure section 7220 of the California Privacy Protection Agency (CPPA) regulations requires a business to give a consumer before using ADMT to make a significant decision about them. It must explain the specific purpose, the right to opt out (or the appeal route that replaces it), the right to access, the ban on retaliation, and how the technology works.
When does the pre-use notice have to appear?
Section 7220(b)(2) sets two triggers, and a launch checklist usually catches only the first.
- 1.New collection. The notice must be presented prominently and conspicuously at or before the point you collect the personal information you plan to process with ADMT.
- 2.Repurposed data. If you already hold the information for a different purpose and later plan to use it in ADMT for a significant decision, you must give the notice before processing it for that purpose.
The deadline sits on top of both. Section 7200(b) says a business already using ADMT for a significant decision before 1 January 2027 must be compliant by that date, and a business that starts on or after it must be compliant whenever it uses ADMT. The CPPA regulations took effect 1 January 2026, and the ADMT obligations carry their own later date.
So there are three populations to think about, not one: people signing up after the notice ships, people already in your database when the tool starts scoring them, and people your tool is scoring right now.
What does this mean for existing customers?
Picture a 30-person lending platform that has collected loan applications since 2022. In November 2026 the team adds a model that re-scores existing applicants for credit-limit changes. Credit limit setting is one of the financial decisions the regulations treat as a significant decision. Nobody is signing up. Nobody sees the new signup flow. Under section 7220(b)(2), the notice still has to reach each of those people before the model touches their record.
That turns the notice from a page into a delivery job with a gate. The engineering question is: for each person in scope, what is the evidence they were shown the current notice for this specific purpose before the first run? A decent answer is a record per person, per decision type, per notice version, with a timestamp, and a processing job that refuses to score anyone without a matching row.
The alternative is the one most teams will drift into: ship the notice in the product, assume anyone who logs in sees it, and score everyone in a batch job that logs in as nobody. The batch job is where the regulation and the architecture disagree.
Where does the notice have to be delivered?
Section 7220(b)(3) requires the notice to be presented in the manner in which the business primarily interacts with the consumer. A business that talks to customers mostly by email cannot satisfy this with a banner in an app they rarely open. A business whose customers live in a mobile app cannot rely on a paragraph in a PDF.
Three more delivery rules are easy to miss:
- Plain language and readable on a small screen. Section 7003(a) and (b)(1) require easy-to-read, non-technical language and a format readable on smaller screens.
- The languages you already use. Section 7003(b)(2) requires the disclosure in the languages in which you ordinarily provide contracts and other information to consumers in California. If your onboarding is in Spanish, so is the notice.
- Accessibility. Section 7003(b)(3) points online notices to generally recognized standards such as the Web Content Accessibility Guidelines 2.1.
None of these is hard. All of them are routinely absent from a notice that was written by counsel and pasted into a template.
Can one notice cover several uses?
Yes, within limits. Section 7220(e) allows a consolidated notice when it includes everything the article requires for each use. The regulation's own examples include one ADMT used for multiple purposes (productivity monitoring that feeds both work allocation and demotion decisions), multiple tools for a single purpose, and the systematic, regular use of one ADMT, so you do not have to re-notify someone each time you run the same tool for the same purpose.
The opinion here is that consolidation is a data-model question before it is a design question. If your notice record is keyed by decision type and tool version, a consolidated notice is a join across a few rows. If it is a hardcoded paragraph, every new use becomes a legal edit and a deploy. Section 7220(a) also lets you fold the pre-use notice into your notice at collection, but only if that notice contains everything subsections (b) and (c) require. Treat that as a permission to merge documents, not to shorten them.
One more line from the text matters here. Section 7220(c)(1) forbids describing the purpose in generic terms such as "to make a significant decision." The notice has to name the specific decision. A consolidated notice that lists five uses must still describe each one specifically.
What goes wrong in practice?
Three failures follow from the text above.
The batch job with no gate. The notice exists, but the scoring job does not check for it. This is the existing-customer problem in its purest form, and the fix is a precondition in the job, not a policy memo.
The version drift. The tool changes, the output type changes, the inputs gain a new category, and the notice still describes the old model. Section 7220(c)(5) requires the notice to explain how the ADMT processes personal information, the categories that affect the output, and how the output is used. Tie the notice version to the tool version so a model change fails a release check until someone reviews the text.
The human-in-the-loop claim. If a person touches the decision but does not meet the three-part human involvement test in section 7001(e)(1), the notice must describe what that person's role is (section 7220(c)(5)(B)). Teams that say a human reviews everything often discover the notice has to say what the human actually does, which is a more exposing sentence.
When is this the wrong thing to build?
If your tool does not make or substantially replace a significant decision, none of this attaches, and a pre-use notice for a recommendation widget is noise that makes your real notices harder to find. We would also not be the right call if you only need counsel to confirm scope: that is a law-firm question, and what you need from engineering comes after it.
If you do have a covered decision and a backlog of existing customers, the build is small but specific: a notice record keyed to decision type and tool version, a delivery path that matches how you talk to customers, and a gate on the processing job. The ADMT checker will tell you whether a given tool is likely in scope, and our ADMT compliance engineering service covers the delivery work. If you would rather talk through your own decision inventory, get in touch. This is engineering analysis, not legal advice.
Sources
- California Privacy Protection Agency: CCPA regulations, Title 11 Division 6 Chapter 1 (effective 1 January 2026), sections 7001(e), 7003, 7200(b) and 7220.