CCPA Risk Assessments: Operationalising the Duty That Already Applies From 2026

The submission deadline is April 2028, so most firms have filed this under “later”. That is the mistake. The duty to conduct the assessments applies from January 2026, which means the work is already overdue the day you notice it.

The California Privacy Protection Agency finalised its regulations on risk assessments, automated decisionmaking technology and cybersecurity audits in 2025, and they took effect on 1 January 2026. Most of the commentary has fixed on the headline date that sits furthest away — the first submission to the CPPA, due 1 April 2028 — and read it as permission to wait. It is not. The obligation to actually carry out risk assessments for high-risk processing began in 2026. The 2028 date is when you hand over an attestation and a summary of work that was supposed to be happening all along. Treat it as a filing deadline and you will spend early 2028 reconstructing assessments for processing that has been running, unexamined, for two years.

What actually triggers an assessment

The regulations require a documented risk assessment before a business engages in processing that presents significant risk to consumers’ privacy. The triggering activities are specific, and worth mapping against your own processing inventory rather than assuming:

Free · 4 minutes

Do you know where AI is already being used in your business — and what it can see?

Fourteen questions on shadow AI, data exposure, oversight, and governance debt — the gap between how fast AI is arriving and how much control you have over it. Banded finding on screen, full sheet by email.

  • Selling or sharing personal information.
  • Processing sensitive personal information (with a narrow carve-out for certain employment contexts).
  • Using automated decisionmaking technology to make significant decisions about a consumer.
  • Using automated processing to infer characteristics from someone’s presence in a sensitive location.
  • Processing personal information to train an ADMT used for significant decisions, or to train facial-recognition, emotion-recognition, identity-verification or similar high-impact technology.

The point that catches firms out is that this is not a data-protection-impact-assessment badge you paste onto an existing GDPR artefact. The CCPA assessment has its own required substance, and a European DPIA will not satisfy it without rework. If you run inference models over applicant or employee data, use behavioural profiling, or feed personal data into training pipelines for anything that makes consequential decisions, you are almost certainly in scope — and the analysis you owe is closer to the risk-benefit reasoning I described for the CRA’s Annex I than to a checklist you tick and file.

The two clocks you are running against

There are two distinct timing rules, and conflating them is where the schedule slips. For any processing activity you initiate on or after 1 January 2026, the assessment must be completed before you commence the activity. For processing that was already under way before that date, you have a grace period — the assessment must be conducted no later than 31 December 2027. Both feed the same submission: for assessments conducted across 2026 and 2027, an attestation of completion and a summary go to the CPPA by 1 April 2028, with later annual submissions on a rolling basis thereafter.

Note what the submission is and is not. You do not send the full assessments to the CPPA in April 2028; you send an attestation and a summary. But the business must be able to produce the complete, unabridged assessment to the CPPA or the Attorney General on request. That distinction shapes the build. The summary is the shop window; the full, versioned assessment is the thing a regulator will actually pull, and it needs to exist, be dated, and be defensible.

What the assessment has to contain

Each assessment has to weigh whether the risks to consumers from the processing outweigh the benefits to the consumer, the business, other stakeholders and the public. In practice that means documenting, for each in-scope activity: the specific purpose of the processing; the categories of personal and sensitive information involved and why the volume is the minimum necessary; how the data is collected, used, disclosed and retained, and to which third parties; the concrete benefits; the specific risks, including discrimination, loss of control, economic, physical, reputational and psychological harm; the safeguards that reduce those risks; and the decision on whether to proceed. Where ADMT is involved, you also document its logic, assumptions, limitations and outputs.

The regulations are explicit that generic descriptions fail. “Improving our services” is not a purpose. “Security” is not a purpose. If your draft reads like marketing copy, it will not survive contact with a supervisor. This is the same documentation discipline arriving through California’s AI transparency and training-data laws: the state is systematically raising the evidential bar on how you describe what your systems do.

Why this is a pipeline, not a document

The instinct is to commission a batch of assessments, save them to a shared drive and move on. That fails for a mechanical reason: the assessments have to be reviewed and updated at least every three years, and within 45 calendar days of any material change to the processing. A static document set cannot meet a change-driven review obligation. What meets it is a workflow.

Concretely, the build has a small number of parts. A templated assessment structure so every activity is documented against the same fields, which is also what makes the April 2028 summary a query rather than a writing project. A trigger mechanism wired into change governance, so that a new vendor, a new model, a new data source or a materially changed purpose raises an assessment or a reassessment automatically — not when someone remembers. Version control, so each assessment carries a date, an author and a change history, and you can show a regulator the state of your reasoning at any point in time. And named ownership, because an assessment nobody owns is an assessment nobody updates.

This should not live in isolation from the rest of your governance. The high-risk processing you are cataloguing here is, in most firms, the same processing that belongs on the board technology risk register. Build the two off one inventory and the risk assessment stops being a parallel compliance chore and becomes the evidence layer under a risk picture the board already reviews.

The evidence a regulator will demand

When the CPPA asks, the credible answer is not “here is a document”. It is an inventory of in-scope processing, an assessment for each item dated before the processing began (or before end-2027 for legacy activity), a change log showing reassessments triggered by real events, and an owner who can talk through the risk-benefit reasoning without reading it back verbatim. If you can produce that, the April 2028 attestation is a formality. If you cannot, no amount of drafting in the first quarter of 2028 will make two years of undocumented processing look assessed.

The deadline that matters is not the one in 2028. It is the one that already passed on 1 January 2026, quietly, while everyone was looking at the far date.

Free interactive tool

Website compliance checklist

What your site has to do, based on what it actually does

Answer as much or as little as you like — the list builds as you go. Nothing is stored against your name and no email is required.

Free interactive tool

Interactive deadline calculator

Check which regulations apply to you and when

Regulation across the EU, UK, US and Asia-Pacific has moved considerably in the past eighteen months, and several headline dates have shifted more than once. Twelve questions, about three minutes.

Results are shown on screen — no email required. A dated summary is available to download, and can be sent on if that's more useful. What we do with your answers.

Most technology problems are not technology problems. They are control problems.

The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.

Full Governance by Sixteen Pillars

Govern your business. Prove your compliance.

A board assurance cockpit for EU-regulated financial firms — tamper-evident, hash-chained proof of governance across DORA, GDPR, NIS2, ISO 27001, the EU AI Act and MiCA. In development.

See what's coming