From 1 January 2027, a person who was rejected, repriced or reassigned by an automated system can ask the business what it did and why, and the business has 45 calendar days to answer in plain language. The answer is not a form letter. Section 7222 of the California Privacy Protection Agency (CPPA) regulations lists four things it has to contain, and three of them can only be written if your system recorded something at the moment of the decision.
This piece is about that response: what it has to say, what you can lawfully leave out, and what your decision log needs to hold for the answer to be possible. It assumes you already know the rules cover you. If you do not, start with what counts as automated decisionmaking technology.
A definition first. An ADMT access request is a consumer's request, under section 7222 of the CCPA regulations, for information about a business's use of automated decisionmaking technology (ADMT) to make a significant decision about them. It sits next to the notice, opt-out and appeal rights, and it is the one that tests whether the other three left evidence behind.
When does the obligation start, and how long do you have?
Section 7200(b) of the CCPA regulations, as published by the CPPA with an effective date of 1 January 2026, says a business already using ADMT for a significant decision must be in compliance no later than 1 January 2027. A business that starts after that date must comply any time it is using ADMT for a significant decision.
The clock for answering is in section 7021. Within 10 business days of receiving an ADMT access request, the business must confirm receipt and describe how it will process the request, including a general account of its verification process. It must respond within 45 calendar days of receipt. The 45 days start the day the request arrives, regardless of how long verification takes. If the business cannot verify the person inside that window, it may deny the request. One extension is allowed, another 45 calendar days for a maximum of 90, but only if the consumer is told why before the first 45 run out.
Read that as a systems requirement, not a legal one. Verification happens inside the 45 days, so a manual process that waits a week for someone to notice the request has already spent a sixth of the window.
What must the response actually say?
Section 7222(b) requires plain-language explanations of the following, and the regulation's own wording is worth quoting closely because it forecloses the lazy version of each.
- 1.The specific purpose. The business must not describe the purpose in generic terms, and the regulation's own example of what fails is "to improve our services."
- 2.The logic of the ADMT. The explanation must let the person understand how the technology processed their personal information to produce an output about them. The regulation says this may include the parameters that generated the output and the specific output for that person.
- 3.The outcome. This covers how the business used the output in the decision, including whether the output was the sole factor, which other factors played a role if it was not, and, where a human took part in a way that falls short of the regulation's "human involvement" test in section 7001(e)(1), what that human's role was. If the business plans to use the same output for a further significant decision about the person, it has to say how.
- 4.Non-retaliation and how to use other rights. A statement that retaliation for exercising CCPA rights is prohibited, plus instructions and any online form or portal links. A link to the top of the privacy policy does not count. The link has to land on the section that holds the instructions.
Items 2 and 3 are the expensive ones. "Sole factor or not" is a question about your pipeline, and "what that human's role was" is a question about a person on a particular day.
What can you leave out?
Section 7222(c) removes two categories from items 2 and 3: trade secrets as defined in Civil Code section 3426.1(d), and information that would compromise the business's ability to detect and investigate security incidents, resist malicious, deceptive, fraudulent or illegal actions, or protect physical safety.
Two cautions from the text itself. First, the carve-out applies to the logic and outcome explanations, not to the purpose or to the rights notice in items 1 and 4. Second, under section 7222(f), if you deny a verified request in whole or in part, you must tell the person and explain the basis unless the law prohibits it, and if you deny only in part you must disclose the rest. "We can't tell you" is a partial denial with a paperwork duty attached, not a way out of answering.
My view: engineers will be tempted to treat the trade-secret carve-out as the default for anything involving a model. Do not design for it. Design the response so the person-specific facts (which inputs, what output, what happened next) can be produced from a log, and let counsel decide per request which sentences to redact. A system built on the assumption of redaction produces nothing to redact from.
What does the decision log need to hold?
Picture a 40-person HR-tech vendor whose customers use its tool to rank applicants, and one customer receives an access request from a rejected candidate. The customer now has 45 days, and the vendor has to supply most of the answer. For that to be a one-day task instead of a three-week reconstruction, the decision record needs, at minimum:
- the decision type, the tool and its version at the time
- the input categories actually used for this person (not the ones the model could use in theory)
- the output, in the form the model produced it
- what the business did with it: whether it was the only factor, and what else was considered
- whether a human reviewed it, who by role, and what they could change
- the notice version the person was shown, if any
That list is the same record described in how to build an audit trail for AI decisions, and the pre-use notice flow in building the pre-use notice and opt-out writes the last line. The access response is the first place all three come together, which makes it the cheapest test of whether they were built consistently.
One uncomfortable detail. Section 7101(e) says a business is not required to retain personal information solely to fulfil a consumer request, while section 7101(a) requires keeping the record of the request and how you responded for at least 24 months. Neither sentence tells you how long to keep decision logs. A log you deleted at 30 days cannot support a request that arrives at day 60, and the regulation will not rescue you from that. Choose a retention period on purpose, with counsel, rather than inheriting whatever your logging default was.
How should the request be received and answered?
Section 7222(d) says the method for submitting a request must be easy to use and must not use dark patterns, and a business may reuse its existing methods for requests to know, delete or correct. So you do not need a new inbox. You need the existing intake to recognise this request type, start the 10-business-day and 45-day timers, and route it to someone who can see the decision log.
Section 7222(e) requires verification under the regulation's Article 5, and if you cannot verify someone you must say so. Section 7222(g) requires reasonable security when sending the answer. Section 7222(h) allows a secure self-service portal for people with password-protected accounts, as long as it fully discloses what they are entitled to. For a business with accounts, a portal that renders the four items from the log is the version that scales, and it has a side benefit: the answer is generated from the record, so it cannot drift from it.
The 24-month requirement in section 7101 also means each request needs a ticket or log row with the date, nature, manner, response date, response nature and any denial basis. A shared spreadsheet satisfies that. A request that lived in one person's email does not.
When is building this the wrong answer?
Three situations, honestly.
If your tool does not make or substantially replace a significant decision, the access right does not attach and you should spend the effort on confirming that, not on a portal. If a human reviewer truly meets all three parts of the section 7001(e)(1) test, the same applies, though the burden of showing it is yours. And if you expect a handful of requests a year, a documented runbook and a person who owns it will serve you better than a custom build. Software earns its place when volume or a vendor's customers make manual reconstruction unrealistic.
What this means for your team
- Inventory every automated decision against the five significant-decision categories before 1 January 2027. The response can only be as good as the inventory.
- Write the four-part response template now, and try to fill it for a real past decision. Where you cannot, that is the logging gap.
- Decide the retention period for decision records on purpose, with counsel.
- Make intake start both timers on day one. The 45 days do not wait for verification.
- Keep a log row for every request, because the 24-month rule applies to how you answered, too.
This is general information about the regulation's text, not legal advice, and counsel should decide anything involving redaction or denial. If you are the engineering side of a business or a vendor that has to produce this response and want a straight read on what your records can and cannot answer, check your scope with the ADMT checker, read how we approach the work on the ADMT compliance engineering page, or tell us what your decision flow looks like.
Sources
- California Privacy Protection Agency: CCPA regulations, Title 11 Division 6 Chapter 1 (effective 1 January 2026), sections 7001(e)(1), 7021, 7101, 7200(b) and 7222.