SB 53 Critical Safety Incident Reporting: What Counts, Deadlines, and Who to Notify

SB 53, California’s Transparency in Frontier Artificial Intelligence Act, creates a specific, deadline-driven duty for frontier AI developers to report certain safety incidents to a state authority. Our general SB 53 explainer covers the law’s incident-reporting duty at a summary level, alongside the law’s other obligations (frontier AI frameworks, transparency reports, whistleblower protections). This guide goes deeper on that one duty only: the exact statutory definition of a reportable incident, the mechanics of the 15-day and 24-hour clocks, exactly who gets notified, what a compliant report has to contain, and how the Attorney General enforces it.

SB 53 added Chapter 25.1 (beginning at Business and Professions Code § 22757.10) to the Business and Professions Code. It was signed September 29, 2025. The incident-reporting duty itself lives in § 22757.13.

What counts as a “critical safety incident”

SB 53 does not use “safety incident” loosely. It defines “critical safety incident” in § 22757.11(d) as any one of four specific events:

1. Unauthorized access to, modification of, or exfiltration of the model weights of a frontier model that results in death or bodily injury.
2. Harm resulting from the materialization of a catastrophic risk.
3. Loss of control of a frontier model causing death or bodily injury.
4. A frontier model that uses deceptive techniques against its own developer to subvert that developer’s controls or monitoring — outside the context of an evaluation designed to elicit that behavior — in a manner demonstrating materially increased catastrophic risk.

Category 2 depends on a second defined term, “catastrophic risk,” which the statute limits to a foreseeable, material risk that a frontier developer’s activities involving a frontier model will contribute to the death of, or serious injury to, more than 50 people, or to more than $1 billion in property or economic damage, arising from provision of expert-level assistance in creating a chemical, biological, radiological, or nuclear weapon; a cyberattack on critical infrastructure carried out with materially reduced human oversight; a model taking action with materially reduced human oversight that constitutes a criminal offense; or a model evading its developer’s control causing death or bodily injury. A near-miss that doesn’t clear one of these four gates — a jailbreak that was caught before causing harm, for example, or a security flaw that was patched before exploitation — is not a “critical safety incident” under this definition, whatever internal severity label a developer’s own incident-response process assigns it.

The 15-day duty and the 24-hour duty are triggered differently

SB 53 sets two separate clocks, and which one applies depends on the incident’s urgency, not its category:

• 15-day reporting (§ 22757.13(c)(1)). The default rule: a frontier developer must report a critical safety incident to the Office of Emergency Services within 15 days of discovering it. The clock starts at discovery, not at the moment the incident occurred — if a developer only learns of a weight exfiltration six weeks after it happened, the 15 days runs from the discovery date, not the breach date.
• 24-hour disclosure (§ 22757.13(c)(2)). If the incident, once discovered, poses an imminent risk of death or serious physical injury, the developer must disclose it within 24 hours — and the recipient changes too: it goes to an authority with jurisdiction, including law enforcement or a public safety agency, rather than (or in addition to) the routine 15-day OES filing.

In practice this means the same underlying event can trigger both duties: an imminent-danger incident still needs to reach the right emergency responder within 24 hours, and the fuller OES report on the 15-day timeline still applies to it as a critical safety incident.

Who actually gets notified

The statute names two distinct recipients depending on which clock applies:

• Cal OES (the Governor’s Office of Emergency Services) is the named recipient for the standard 15-day critical safety incident report. The Attorney General is responsible for establishing the reporting mechanism developers use to file.
• Law enforcement or public safety agencies with jurisdiction are the recipients for the 24-hour imminent-risk disclosure — the statute doesn’t route those through OES first.

One detail worth flagging for compliance teams: reports filed with OES under this section, along with catastrophic-risk assessments filed under § 22757.12 and covered-employee whistleblower reports, are explicitly exempted from the California Public Records Act. A critical safety incident report is not a document a competitor or journalist can obtain through a routine CPRA request. Separately, starting January 1, 2027, OES is required to publish an annual report with anonymized, aggregated information drawn from the incidents it has reviewed — so the underlying reports stay confidential while the aggregate trend data becomes public on a yearly cycle.

What a compliant report has to contain

Section 22757.13(a) sets a floor for report contents. A critical safety incident report must include, at minimum:

1. The date of the critical safety incident.
2. The reasons the incident qualifies as a critical safety incident (i.e., which of the four § 22757.11(d) categories it falls under, and why).
3. A short and plain statement describing the critical safety incident.
4. Whether the incident was associated with internal use of a frontier model (as opposed to external, third-party use).

That fourth requirement matters operationally: it means a developer’s own internal red-teaming, internal deployment, or internal research use is explicitly in scope for reporting, not just incidents involving external customers or the public.

Enforcement: who it applies to, and the penalty

The 15-day/24-hour reporting duty in § 22757.13 applies to every frontier developer — the statute does not limit it to large developers. That’s a narrower scope than some of SB 53’s other duties: the quarterly catastrophic-risk assessment requirement under § 22757.12, for instance, applies specifically to “large frontier developers,” defined in the statute as a frontier developer that, together with its affiliates, had annual gross revenues exceeding $500 million in the preceding calendar year.

The penalty provision, § 22757.15, is where that distinction resurfaces: it authorizes a civil penalty of up to $1,000,000 per violation, scaled to severity, against a large frontier developer that fails to report an incident as required by § 22757.13 (among other violations, including failing to publish a required framework or transparency report, or making false or misleading statements). The penalty is recoverable only in a civil action brought by the Attorney General — there is no private right of action under this chapter. Smaller frontier developers are still bound by the underlying § 22757.13 reporting duty; the statute’s explicit $1,000,000 civil-penalty mechanism in § 22757.15 is written against “large frontier developer.” Developers below the $500 million threshold should not read that as reporting being optional for them — the duty in § 22757.13 itself is not qualified by developer size, and the Attorney General retains general enforcement authority over the chapter.

Building this into an incident-response process

Treating SB 53 incident reporting as a compliance afterthought — something legal handles once someone tells them an incident happened — tends to blow the 24-hour clock, since that window starts at discovery and 24 hours is not long enough to route a decision through multiple approval layers. Frontier developers with California exposure typically need three things in place before an incident occurs, not after: a triage step in the existing incident-response process that asks whether an event meets one of the four § 22757.11(d) categories; a pre-identified path to file with OES (and, separately, to reach the right law-enforcement or public-safety contact for imminent-risk cases) so the 24-hour clock doesn’t get spent finding out who to call; and a template that already captures the four required fields from § 22757.13(a) so the report itself isn’t the bottleneck. None of this is exotic incident-response practice — it’s the same discipline security teams already apply to breach-notification deadlines under state data-breach laws, pointed at a new, AI-specific trigger.

How CASRAI’s NIKOLAI tracks this

CASRAI’s own NIKOLAI project — an independent, unendorsed frontier-AI-safety reference dictionary — maps the exact mechanics this guide walks through in its Incidents track (N7). The Incident Reporting Deadline and Recipient element is defined generically as a reportable incident having to reach a named recipient within a set deadline, sometimes shortened for imminent harm — which is precisely the shape of SB 53’s 15-day discovery clock and its shorter window for imminent-risk events, with Cal OES as the named recipient. NIKOLAI’s N7 track cross-references this obligation alongside comparable incident-reporting practices at other frontier developers, so the same element can be used to compare SB 53’s requirement against other jurisdictions’ incident rules as they emerge.

NIKOLAI doesn’t interpret or adjudicate what counts as a reportable incident under SB 53 — that determination stays with the statute and the Attorney General’s guidance — CASRAI simply tracks and maps the terminology via NIKOLAI as an independent reference.

Frequently asked questions

Does a near-miss or a caught jailbreak count as a critical safety incident?

Not under the statutory definition. SB 53 defines “critical safety incident” as one of four specific triggering events in § 22757.11(d), and three of the four require an actual outcome — death, bodily injury, or a materialized catastrophic risk — not merely an attempted or contained one. A vulnerability that was identified and patched before causing harm doesn’t meet the statutory bar, whatever severity a developer’s internal taxonomy assigns it.

Is the 15-day clock measured from the incident or from when we found out about it?

From discovery. Section 22757.13(c)(1) starts the 15 days when the frontier developer discovers the critical safety incident, not when the incident itself occurred.

Do smaller frontier developers have to report incidents, or only “large frontier developers”?

All frontier developers are bound by the § 22757.13 reporting duty regardless of size. The $500 million revenue threshold defines “large frontier developer” for other parts of SB 53, such as the quarterly risk-assessment duty, and it’s also the term used in the § 22757.15 civil-penalty provision specifically for failure to report — but that doesn’t relieve smaller developers of the underlying duty to report, and the Attorney General retains general enforcement authority over the chapter.

Can a critical safety incident report be obtained through a public records request?

No. Reports filed with the Office of Emergency Services under § 22757.13, catastrophic-risk assessments filed under § 22757.12, and covered-employee whistleblower reports are all explicitly exempt from the California Public Records Act.

Where does the Attorney General publish enforcement information for SB 53?

The California Department of Justice maintains a dedicated SB 53 page at oag.ca.gov/sb53 covering the Attorney General’s role under the Transparency in Frontier Artificial Intelligence Act.

How does this relate to SB 53’s other obligations, like the frontier AI framework and transparency reports?

Incident reporting is one duty among several created by the same chapter. For the full picture — the frontier AI framework requirement, transparency reports, whistleblower protections, and how the pieces fit together — see our general SB 53 guide. For background on which companies the term “frontier developer” actually captures, see What Is a Frontier AI Model?