Most summaries of California's risk assessment rules describe a document you write once, before launch. Section 7155(a)(3) of the California Privacy Protection Agency (CPPA) regulations says otherwise: when a material change hits the processing, the business must update the assessment as soon as feasibly possible, and no later than 45 calendar days from the date of the change. For a team that ships a model update every few weeks, that sentence turns the risk assessment from a launch artifact into something that has to keep pace with the release calendar.
This post reads section 7155 the way an engineering lead has to: what counts as material, which clocks run at the same time, and what a change log needs to hold so the 45 days are a ticket, not a surprise. It is a builder's read, not legal advice. Counsel decides what is covered and what is material. This is what to have ready when they ask.
What is a risk assessment, and who has to write one?
A risk assessment, under the CCPA regulations effective 1 January 2026, is a documented analysis of a high-risk processing activity. Section 7150(b) lists the triggers: selling or sharing personal information, processing sensitive personal information, using automated decisionmaking technology (ADMT) for a significant decision, certain automated inferences about applicants and employees, and training an ADMT or a facial-recognition system on consumers' personal information. Section 7154 states the goal: restricting or prohibiting the processing if the privacy risks outweigh the benefits.
The people who write it are not only lawyers. Section 7151(a) says employees whose job duties include participating in the processing must be included in the process, and it gives the example of the person who decides how the business collects the data, who has to hand that information to whoever is conducting the assessment. Engineering is in the room by regulation. For what the document contains, see what actually goes in a CCPA risk assessment.
What counts as a material change?
Section 7155(a)(3) defines it in two parts. A change relating to the processing is material if it creates new negative impacts or increases the magnitude or likelihood of impacts already identified under section 7152(a)(5), or if it diminishes the effectiveness of the safeguards identified under section 7152(a)(6). The regulation then offers examples: changes to the purpose of the processing, to the minimum personal information necessary to achieve that purpose, or to the risks consumers raise, such as numerous consumers complaining to the business about the privacy risks of its processing.
Notice what is missing. There is no list of engineering events. Nothing says a model version bump is material, and nothing says it is not. The test is effect: did the change add a harm, make a known harm likelier or larger, or weaken a control the assessment relied on? So the useful move is to take your own assessment and read it backwards. Every impact and every safeguard it names is a thing a release can touch.
Here is how I would sort the common engineering events, with the caveat that counsel has the last word:
- Probably material: swapping the model or its vendor for one that scores people; adding an input field that the assessment said the tool did not read; changing the threshold that decides who is rejected or reassigned; removing or shortening the human review step the assessment cited as a safeguard; retraining on a new population of consumers' data.
- Probably not material: interface copy, latency work, moving between hosting regions with the same access controls, refactors with no change in inputs, outputs or thresholds.
- Genuinely arguable: a vendor's silent model upgrade behind a stable API name, and a retrained model with identical features but different data. If you cannot tell whether your vendor changed the model, that gap is itself the finding.
Which clocks run at the same time?
Section 7155 and its neighbours put six dates on one processing activity. They run in parallel, which is where teams lose track.
| Clock | Rule | Source |
|---|---|---|
| Before launch | Conduct and document the assessment before initiating the processing | 7155(a)(1) |
| Every three years | Review and update as necessary, at minimum | 7155(a)(2) |
| 45 days | Update after a material change, no later than 45 calendar days from the date of the change | 7155(a)(3) |
| 31 December 2027 | Assessment due for processing that began before 1 January 2026 and continues | 7155(b) |
| Five years | Retain every version for as long as the processing continues or five years after completion, whichever is later | 7155(c) |
| 30 days | Hand over the reports when the CPPA or the Attorney General asks | 7157(e) |
On top of those, section 7157(a)(1) requires the information for assessments conducted in 2026 and 2027 to reach the CPPA by 1 April 2028, and section 7157(c) requires a member of the executive management team to submit it, attesting under penalty of perjury. That executive is signing a statement about assessments your team has to keep current.
A worked example: one model change, 45 days
Picture a 30-person HR-tech company whose tool ranks applicants for its customers. It completed its assessment in the autumn of 2026, and it named two safeguards: a reviewer who can overturn any ranking, and a rule that the model never reads a candidate's address. On 8 March 2027 the team ships a retrained model that, to improve accuracy, takes postcode as an input.
That change touches both sides of the test. It adds an input the assessment said was never read, and a postcode can act as a proxy for a protected characteristic, which is exactly the kind of discrimination harm listed in section 7152(a)(5)(B). The 45 days run from 8 March, so the updated assessment is due no later than 22 April 2027. If the team learns about the change from a customer complaint instead of its own release process, the clock started anyway.
Nobody in that story did anything unusual. The model change was reasonable. The failure would be that the release went out with no step asking whether it touched an assessed processing activity.
What should the change log hold?
You do not need a platform. You need four things, and they all exist in most teams already, just not connected.
- 1.A registry of assessed processing. One row per assessment: the ID, the tool, the model identifier and version, the input fields, the decision thresholds, and the named human safeguards. This is the thing you read backwards.
- 2.A release gate that asks one question. A required field on the pull request or release ticket: does this change the model, inputs, thresholds, vendor or review step of anything in the registry? If yes, an assessment ID is mandatory. A path-based check on the config and model directories catches the careless cases.
- 3.A due date that is computed, not remembered. When the gate fires, open a ticket with the due date set to the change date plus 45 days. Counsel may decide the change is not material, and that decision is recorded on the ticket, which is itself evidence.
- 4.Immutable versions. Section 7155(c) requires retaining the original and updated versions, so an assessment edited in place in a shared document fails the retention rule even if the content is right. Store each version as a dated, read-only file.
On retention, the text says to keep each assessment for as long as the processing continues or five years after its completion, whichever is later. It does not say whether the five years run from the first version or the latest. The cautious reading is to hold every version until five years after the most recent update completes, and to ask counsel before choosing the shorter one.
The same discipline applies to vendors. If a supplier can change a model without telling you, your change log cannot see it, which is why the vendor contract terms under the ADMT rules should include notice of material model changes. And the shadow tools nobody registered are the cases that never get an assessment at all.
When this is overkill, and when we are the wrong call
If you run one assessed tool, release it quarterly, and keep the model fixed between releases, a spreadsheet registry and a checklist item in the release template is enough. Building tooling for that would cost more than the risk it removes. And if counsel has not yet decided whether you are covered by section 7150(b) at all, start there: the ADMT checker gives a first read on scope, but it is not a substitute for that decision.
The build work becomes worth outside help when there are many assessed activities, several vendors with models you cannot inspect, or release cycles shorter than 45 days. That is ADMT compliance engineering: the registry, the gate and the evidence trail, wired into the pipeline you already run. If that is your situation, tell us what the decision looks like and we will tell you what we would instrument first.
Sources
- California Privacy Protection Agency: CCPA regulations, Title 11 Division 6 Chapter 1 (effective 1 January 2026), sections 7150, 7151, 7152, 7154, 7155 and 7157, read in full text on 14 October 2026
- California Privacy Protection Agency: CCPA updates, confirming the effective date and approval by the Office of Administrative Law
