Of California's three new privacy obligations, the risk assessment is the one most likely to be mistaken for paperwork. It is not. It is the only one that can end with a regulator expecting you to stop doing something, and its stated purpose says so: restrict or prohibit processing where the privacy risk to the consumer outweighs the benefits.
That framing matters, because a document written to justify a decision already made will read very differently from one written to test it. Only one of those survives being produced to an agency.
A builder's read, not legal advice. Counsel decides whether you are covered. This is what to have ready when they say you are.
What triggers one
The regulations do not leave "high risk" to judgement. An assessment is required where processing presents a significant risk, which they enumerate:
- Selling or sharing personal information
- Processing sensitive personal information
- Training or using automated decisionmaking technology for significant decisions
- Using biometrics for identity verification or profiling
- Making automated inferences in sensitive contexts
Read the third one carefully, because it catches teams who think they are out of scope. Training a model for these decisions triggers the requirement, not only running one in production. A model trained on employment data and never shipped still put you in scope for the training.
Significant decisions themselves are the familiar list: employment (hiring, work assignment, compensation, promotion, demotion, termination), plus housing, lending and credit, healthcare, and access to education. If you are still working out which of your systems meet the definition at all, what counts as ADMT is the scoping question and comes first; this piece assumes you already know the answer.
The dates, and which one bites first
| Obligation | Date | Applies to |
|---|---|---|
| Assess processing already running | 31 Dec 2027 | Activities that predate the regs and continue |
| First filing to the agency | 1 Apr 2028 | Information about 2026 and 2027 assessments |
| Refresh | Every 3 years | Or sooner on a material change |
| Produce on request | Within 30 days | Any covered assessment |
The 30-day production window is the one that decides how you write these. An assessment you would need six weeks to locate, reconstruct and explain is functionally not an assessment. Store them where they can be found by someone who did not write them.
Note also that the April 2028 filing is information about the assessments you conducted, not the assessments themselves. The deliverable is a summary; the underlying documents stay with you until asked for.
What the document has to do
Strip away the formatting and a compliant assessment answers a chain of questions honestly:
- 1.What processing is this, specifically? Not "we use AI in hiring" but which tool, on which data, at which step, affecting whom.
- 2.Why are we doing it? The business purpose, stated plainly enough that a non-specialist can weigh it.
- 3.What personal information goes in, and what comes out? Categories in, output type, and what the output is used for.
- 4.What are the risks to the consumer? Named, not gestured at. Wrongly denied a job, wrongly priced, wrongly flagged.
- 5.What safeguards exist, and what evidence shows they operate? This is where most drafts weaken, and where an auditor will push.
- 6.Do the benefits outweigh the risks? The actual question, answered rather than assumed.
Then it is documented, attested by an executive, and refreshed at least every three years or when the processing materially changes.
The parts engineering owns
Legal will draft the document. Four sections cannot be written without engineering, and they are the four an assessment is judged on:
The data inventory for that tool. What it actually reads, not what the design doc says. These diverge more often than teams expect, and the assessment is a bad place to discover it.
The output and its use. What the model emits, what threshold is applied, and what the system does next. The consumer experiences the consequence, not the score.
The safeguards, described as they are implemented. Human review that exists in the code, not in the process document. If the override rate is zero across thousands of decisions, the safeguard is decorative, and writing it down as a control makes that worse rather than better.
The evidence. Logs, evaluation results, access records. An assessment claiming a control operates, backed by nothing, is a signed statement you cannot support. This is the same reason an audit trail has to be turned on before you need it.
The failure mode worth naming
The predictable way this goes wrong is an assessment written to ratify a decision. Someone has already committed to the tool, so the document walks backwards from "we are keeping it" and the risk section becomes a list of mitigations rather than risks.
That is detectable, and it is worse than a thin assessment, because it is signed by an executive. The honest version records at least one risk you did not fully mitigate and says what you accepted and why. Regulators are considerably more comfortable with a business that names a residual risk than one that claims none exist.
What this means for your team
- The trigger list is specific, so check it rather than reasoning about it. Training a model for significant decisions counts, even before it ships.
- Write for the 30-day window. Findable and legible beats thorough and buried.
- Get the data inventory from the system, not the documentation.
- Record a residual risk if one exists. An assessment with no unresolved risk reads as one that was not really conducted.
- Fold this into the same exercise as what the ADMT rules require you to build. Same tools, same teams, same evidence.
If you have a tool in scope and no clear answer to what it reads or what it logged last week, that is the honest place to start. Tell us what the decision looks like and we will tell you what we would instrument first.
Sources
- California Privacy Protection Agency: CCPA updates, risk assessments, ADMT and cybersecurity audits
- Morgan Lewis: CCPA risk assessment requirements and best practices
- Thompson Coburn: California's 2026 CCPA regulations, summary and preparation guide