Pursuant to the California Values Act Database Users Should Not Use Non-Criminal History Information Aside From Information Regarding Immigration or Citizenship Status for Immigration Enforcement Purposes: The Four-Condition Rule and the Records That Fail It

The rule is a four-way gate, and a record clears it only if all four conditions hold. Under the California Values Act — enacted as Senate Bill 54 in 2017 and codified at Government Code section 7284 et seq. — a database user may not use non-criminal history information for immigration enforcement purposes unless that information concerns immigration or citizenship status and the database is a designated California law enforcement agency database and access is authorized for a legitimate law enforcement purpose and no other limitation in the Act bars it. Anything short of that is prohibited. This article walks through the statutory text, the exemption categories, the immigration-status carve-ins at Government Code section 7284.6(a)(1)(C), and the failure scenarios that trip compliance officers.

What Government Code Section 7284.6 Actually Prohibits

The operative language sits in section 7284.6(a)(1)(C). It bars California law enforcement agencies from using agency resources to investigate, interrogate, detain, detect, or arrest a person for immigration enforcement purposes, and then lists six "unless" clauses that define what the agency may still do. The database language is the sixth. Read literally, it creates a narrow permission structure rather than a broad prohibition, which is why compliance training that says "we don't share immigration data" is technically wrong.

The statute distinguishes criminal history information from non-criminal history information without defining either term in the Act itself. "Criminal history information" picks up its meaning from Penal Code section 11105, which covers arrest and conviction records maintained by the Department of Justice. "Non-criminal history information" is a residual category — everything else in a records system, including booking notes, civil detainers, jail classification data, probation contact logs, and investigative field interviews that never produced a charge.

Four conditions must be satisfied simultaneously. First, the user must be a California law enforcement agency or an entity accessing an agency database through authorized channels. Second, the access must be for a legitimate law enforcement purpose unrelated to immigration enforcement. Third, any non-criminal history information used for immigration enforcement must concern immigration or citizenship status. Fourth, no other limitation in the Act — including the section 7284.6(a)(1)(A)–(F) carve-outs and the confidentiality provisions at section 7284.8 — may independently bar the use.

The Act was amended by AB 1036 in 2021 and AB 1747 in 2022, but neither amendment changed the structure of the database provision at 7284.6(a)(1)(C). Current compliance therefore tracks the 2017 text as interpreted by the California Department of Justice's guidance bulletins and by Attorney General opinions issued after 2018. If you're reading a training deck dated before 2021, check the underlying subsection citations before relying on it.

The Six Exemption Categories and Where Databases Fit

Section 7284.6(a)(1) lists six carve-outs. Only one of them — subsection (C) — concerns databases directly, and the other five are routinely confused with it in agency policies. Subsection (A) covers protecting public safety and preventing victimization; (B) covers serious and violent felonies defined at Penal Code section 667.5(c); (C) is the database access clause; (D) covers conditions of release from custody and probation supervision; (E) covers responding to federal immigration detainers under sections 7284.6(a)(1)(E) and 7284.6(b); (F) covers criminal history information sharing under Penal Code section 11105.

The table matters because agency legal teams often cite subsection (A) or (B) when responding to a database request and then tell staff "share everything that touches public safety." That reading inverts the statute. Subsections (A) and (B) authorize enforcement actions; subsection (C) authorizes records access; they are not interchangeable.

The sixth clause (F) is the one that agencies most often over-apply. A county sheriff responding to a federal inquiry might cite (F) as authority to share records when the records in question are civil in nature and therefore fall outside section 11105. That is a misapplication. Clause (F) authorizes sharing only of criminal history information as defined in the Penal Code; anything else needs to satisfy (C), and (C) carries four conditions.

Compliance officers should map every database field in their system to one of three buckets: criminal history (Penal Code § 11105), immigration or citizenship status (the (C) carve-in), and everything else. The "everything else" bucket is where the statute bites. Most agency data — booking logs, field contact cards, jail classification notes — lives in the third bucket and cannot be used for immigration enforcement no matter what the requesting agency asks for.

When Immigration or Citizenship Status Information Is Usable at All

The (C) provision — full citation is Government Code section 7284.6(a)(1)(C) — is the only subsection that allows non-criminal history information to be used for immigration enforcement, and only when that information is immigration or citizenship status. The category is narrower than agencies assume. Status means whether a person is a U.S. citizen, a lawful permanent resident, an asylee, a refugee, a nonimmigrant visa holder of a specified class, a person with Temporary Protected Status, or an undocumented noncitizen. It does not mean country of birth, nationality of a family member, primary language, place of birth, or a foreign address.

A driver's license issued under AB 60, California's 2013 law opening licenses to residents regardless of immigration status, does not itself establish status. AB 60 licenses carry a specific design marking but the license's existence tells you nothing about immigration status other than that the person satisfied DMV requirements. A justice information system that flags AB 60 license type and treats that flag as status information is technically incorrect. The flag is a licensing characteristic, not a citizenship or immigration status indicator.

Place of birth data sits in a gray zone. A California birth certificate showing birth in another country records an event, not a current status. A passport number in a booking file indicates claimed nationality, not verified status. If your database field is labeled "POB" or "Country of Nationality," it doesn't satisfy the (C) carve-in unless an authorized immigration verification process attached a status determination to that record. Most agency policies don't say this clearly, and that omission drives the majority of self-reported violations in internal audits.

Immigration status information becomes usable only when it is lawfully obtained and maintained by the agency for a legitimate law enforcement purpose. California DOJ guidance and Attorney General Bulletins from 2018 and 2019 emphasize that subsection (C) is not a sharing authorization for undocumented status discovered collaterally. A jail officer who learns during intake that an arrestee is undocumented cannot route that fact to a federal agency for immigration enforcement unless the request also satisfies (A), (B), or (D). The database provision alone doesn't supply authorization.

One more boundary: 8 U.S.C. § 1373 is a federal information-sharing statute that prohibits state and local restrictions on sharing citizenship or immigration status with federal immigration authorities. SB 54's drafters threaded section 7284.6 around § 1373 by permitting status sharing while prohibiting enforcement action. That distinction shapes database design: a system may record and (in limited circumstances) disclose status, but may not be structured to flag non-citizens for enforcement action. Systems that auto-generate federal alerts from status fields have drawn DOJ scrutiny.

Who Counts as a Database User Under the Act

"Database user" is not a defined term in the Act, but the operative restriction at section 7284.6(a)(1) attaches to "California law enforcement agency" and to any person acting on that agency's behalf. The category therefore reaches sworn officers, professional staff, contractors accessing records on an agency's behalf, and — via section 7284.6(f)'s prohibition on private entity use of agency databases for immigration enforcement — to private entities operating under memoranda of understanding with agencies.

Section 7284.6(c) prohibits California law enforcement agencies from allowing private entities to use agency databases for immigration enforcement purposes. That clause reaches the vendor layer most agencies overlook: a records management system vendor, a fusion center contractor, or a data analytics provider that ingests agency data under a customer agreement falls within the prohibition if the database is characterized as an agency database. Vendor contracts signed after January 1, 2018, should contain an express SB 54 compliance clause; contracts predating that date may need amendment.

The "authorized access" condition is where most violations actually occur. A sworn officer accessing a records system outside the scope of an authorized investigation is not within (C), even if the officer has login credentials. In practice, this means every database query for immigration enforcement purposes must trace back to a documented law enforcement purpose in the officer's case file. The statute doesn't require a warrant, but it does require the officer to be able to articulate the purpose if challenged.

State agencies are largely outside the Act's database provisions. The section 7284.6(a)(1) prohibitions apply to "California law enforcement agency," defined at section 7284.2(c) to include police departments, sheriffs, and the California Department of Justice when performing law enforcement functions. State agencies that maintain records for regulatory or administrative purposes — DMV, Franchise Tax Board, Department of Social Services — fall outside SB 54's database constraints, which is why advocates pushed for separate legislation covering those agencies in subsequent years.

Federal database users are entirely outside the Act's reach. A federal immigration officer accessing an FBI criminal history record through the National Crime Information Center is not a "database user" for purposes of section 7284.6. But the federal officer's access depends on a state or local agency having shared data in the first place, and that upstream sharing is exactly what (C) regulates. The statute's leverage is on the state agency, not the federal recipient.

The Five Failure Scenarios That Trigger Compliance Problems

Five patterns account for most of the database-access failures observed in agency audits and in DOJ enforcement actions filed after 2018. Naming them specifically helps staff recognize a violation in progress rather than in hindsight.

The first is the "status-adjacent field" failure. An officer pulls a booking record to answer a federal inquiry, sees a "Country of Birth: Mexico" field, and shares it as if it were status information. The field is not immigration or citizenship status under (C), and the disclosure violates section 7284.6(a)(1)(C). This failure is common in county jails where booking data is stored in records management systems with legacy field definitions.

The second is the "general criminal database query" failure. An officer queries a records management system using a name and date of birth, pulls a non-criminal field interview contact, and forwards it to a federal agency because the contact contains immigration notes. The contact record fails (C) because the notes aren't status information and the query wasn't for a legitimate law enforcement purpose.

The third is the "private vendor data pull" failure. A vendor operating under an agency MOU runs a bulk query for a federal client. Even if the agency authorized routine access, the vendor's use for immigration enforcement violates section 7284.6(c). Several audits flagged this pattern in fusion center arrangements.

The fourth is the "auto-alert" failure. A database is configured to automatically generate federal agency notifications based on status-adjacent fields (country of birth, foreign passport presence, non-citizen flag). Even where each individual disclosure passes (C), the automated structure itself functions as an immigration enforcement apparatus and typically cannot satisfy the legitimate-purpose condition because the notification isn't tied to a documented law enforcement purpose.

The fifth is the "detainer response" failure. Agencies sometimes respond to federal immigration detainer requests by sharing booking data beyond the limited information authorized under section 7284.6(b), which specifies the categories of information a California agency may share in response to a detainer — most notably criminal history information as defined in Penal Code section 11105 and the release date. Sharing non-criminal booking notes in the same response violates (C) unless the notes independently concern immigration or citizenship status.

Each failure is traceable to a specific statutory subsection, and each is fixable with field-level access controls, purpose-based logging, and staff retraining. The pattern in DOJ self-audit questionnaires issued since 2019 has been to ask agencies to enumerate database queries by purpose and by field accessed rather than by volume. That's the right compliance design.

How to Audit a Records System Against Section 7284.6

Auditing follows a fixed sequence. Each step produces a document; skipping any step means the audit can't support a compliance certification.

1: Pull a system data dictionary. List every field, its data type, and its acquisition source. Flag any field acquired through federal immigration channels separately — those fields are status-information-by-origin and need a distinct handling rule. 2: Classify each field into one of three buckets: criminal history (Penal Code § 11105), immigration or citizenship status as defined in section 7284.6(a)(1)(C), or non-criminal history not meeting either definition. Unclassified or ambiguous fields default to the third bucket. 3: List every downstream user, including contractors and vendors. Cross-reference against section 7284.6(c) and confirm each user has a written compliance clause signed after January 1, 2018. 4: Pull a six-month query log sample. Sort by purpose code and by field accessed. Identify anomalies: queries for immigration enforcement purposes that returned non-status fields, or queries where no documented purpose appears. 5: Test each auto-notification rule. Any rule that generates outbound transfers based on status-adjacent fields goes to legal counsel for review against (C) before the rule stays in production.

Failure handling: if any step reveals a violation pattern, the standard first response is to disable the affected access path and document the shutdown date. Compliance officers should log the detection, the affected records, and the remediation step in a central register that survives staff turnover. Most DOJ self-audit questionnaires ask for evidence of a remediation chain, not just a clean result.

The audit outputs matter beyond internal compliance. California DOJ has authority under section 7284.8 to investigate agency violations, and private plaintiffs may pursue declaratory relief under section 7284.8(c) and related sections. A documented audit is the agency's strongest defensive position when either forum opens a matter.

How Section 7284.6 Interacts With 8 U.S.C. § 1373

The federal information-sharing statute at 8 U.S.C. § 1373 prohibits state and local governments from restricting information sharing about citizenship or immigration status. SB 54's drafters cited § 1373's constraints during floor debate and built section 7284.6 to sit alongside it. That construction produces the statute's most counterintuitive feature: California agencies may share status information more freely than they may share non-status non-criminal information.

The practical consequence is a data-classification discipline that many agencies get backward. Staff trained on a simple "don't talk to ICE" heuristic often err by withholding status information the Act permits, which can expose the agency to federal compliance complaints. Staff trained on a "we handle every federal request the same" heuristic often err by sharing non-status records that the Act prohibits. Both errors are common.

The correct framework treats the two statutes as setting opposite default rules for two different data categories. For status information, the default is that sharing is permitted, and the agency needs a reason not to share. For non-status non-criminal information, the default is that sharing is prohibited, and the agency needs a reason under (A) through (D) or (F) to share. The database provision at (C) sits at the crossover point and supplies the rule that status information may be used for immigration enforcement when the access is for a legitimate law enforcement purpose.

Practitioners should also track the interaction with state sanctuary laws in other jurisdictions. California's SB 54 is the template for similar laws in Oregon, Washington, Illinois, New Jersey, and Colorado, but the database provisions differ. Oregon's HB 3464, enacted in 2021, uses the phrase "immigration enforcement purposes" without the database condition structure. Washington's Keep Washington Working Act uses a "civil immigration enforcement" prohibition and separate data-sharing rules. Cross-jurisdictional agency counsels need to read each statute separately rather than applying an SB 54 template to all five states.

Section 7284.6(e) requires the Attorney General to develop, on or before April 1, 2018, model policies limiting immigration enforcement in schools, health facilities, courthouses, and other public institutions. Those model policies interact with the database provision at 7284.6(a)(1)(C) because they affect what counts as a "legitimate law enforcement purpose" in institutional settings. Schools and health facilities adopting the model policies can define database access restrictions for on-site access that go beyond the statute's minimum.

Comparing SB 54 to Other State Data-Sharing Frameworks

State frameworks split on three dimensions: whether they use a database-specific provision, whether they carve in status information explicitly, and whether they reach private vendors. Comparing them side by side shows where California lands and what its practical posture means for cross-state agency counsel.

The comparison row most often missing from agency training materials is the private vendor reach. California and Illinois lead on vendor coverage; Oregon and Colorado cover vendors only partially. That difference matters for agencies procuring records systems across multiple states, because a single vendor contract may need state-by-state compliance riders rather than one national clause.

The second missing comparison is the specificity of the status carve-in. California's version is explicit and conditional; the other statutes tend to work through general prohibitions without defining which status information sharing remains permitted. The practical effect is that California agencies can articulate a clearer operational rule to line staff, but they need to follow the articulation precisely because it isn't the default message staff carry from other states.

A third comparison worth building internally is a row for jurisdiction-specific criminal history statutes. California Penal Code § 11105 defines criminal history information tightly and excludes many records that other states' definitions include. An agency that operates in both California and Arizona will find that a record treated as criminal history in Arizona falls outside § 11105 in California. Database field classifications should be state-specific for this reason.

What Records Count as Non-Criminal History Information

The category of non-criminal history information absorbs nearly every field in a modern records management system that isn't an arrest or conviction record. Working through the list field-by-field eliminates the ambiguity that drives most compliance disagreements.

Booking records are the most contested category. The booking form itself contains fields that are status-relevant (country of birth, foreign passport presence) and fields that are not (address, employer, vehicle information). The booking record as a whole is non-criminal history unless and until it produces a charge. Individual fields within the booking record must be classified separately for (C) analysis.

Field interview cards, probation contact logs, jail classification notes, and investigative notes that did not produce a criminal filing are non-criminal history information. So are civil detainers, protective order files where no criminal charge attached, and victim services records. Traffic collision reports and citation records sit in a middle zone — they are non-criminal history unless a criminal charge attached, but many agencies treat them as criminal history in their internal systems for convenience, which creates an audit miscategorization.

Criminal history information under Penal Code § 11105 is narrower than staff assume. It covers records of arrest and detention, records of conviction, and records of criminal proceedings maintained by the California Department of Justice. Records maintained by local agencies in their own systems are not necessarily "criminal history information" for purposes of the statute — the phrase points to the DOJ's summary criminal history database and to the records listed in Penal Code § 11105. An agency booking log maintained locally is not § 11105 information even when it records an arrest.

A record maintained locally that has both criminal and civil components — like a probation file where the underlying supervision is criminal but the file includes employment notes — must be treated as mixed. For (C) analysis, the criminal portion is governed by the (F) carve-out; the non-criminal portion by the (C) four-condition test. Treating a mixed file as unitary in either direction misreads the statute.

The safest operational rule for agency counsels is to maintain a written classification matrix listing every field and its bucket. Update the matrix annually. New fields added to a records system default to the "non-criminal history not meeting immigration status definition" bucket until classified otherwise. The default matters because the (C) prohibition bites on the third bucket; defaulting new fields to "criminal history" is the quiet path to violation.

How Supervisors Document a Legitimate Law Enforcement Purpose

The legitimate-purpose condition under (C) is the least specified in the statute and the most dependent on documentation discipline. Supervisors should require that every database query for immigration enforcement purposes carries a written case file annotation that records the date, the requesting agency, the field accessed, and the underlying law enforcement purpose. The annotation is what makes the condition measurable later.

Four elements survive scrutiny. First, the case file should document an underlying investigation — a pending charge, a probation supervision contact, a public safety concern — before the database query occurs. Retrofitting a purpose after a query is visible on logs and undermines the documentation. Second, the supervisor who approves the query should be designated at a rank above the querying officer and not the requesting federal agency's point of contact. Third, the case file should record which fields were accessed, not just what data was ultimately shared. Fourth, if the accessed fields include immigration or citizenship status information, the case file should state which status determination was attached and by what process.

The last element is where most agencies stumble. Status information isn't self-authenticating. A record saying "Country of Birth: Mexico" doesn't document status. A record saying "U.S. Immigration and Customs Enforcement confirmed status as X on [date] through [process]" does — but only if the process that produced it complied with SB 54 and with any related state privacy laws. The truncation that agencies often introduce — dropping the process note while keeping the status field — collapses the (C) carve-in because the status isn't verifiably attached.

Wrong failure handling for documentation: treating missing documentation as evidence of violation. The better practice is to treat missing documentation as a training opportunity and to distinguish between queries where purpose documentation is missing but the purpose is subsequently verified (correctable) and queries where no verifiable law enforcement purpose exists (a violation). The two categories require different responses.

Where supervisors face repeated purpose-documentation problems, the correction is process architecture, not retraining. Case management systems can be configured to require purpose codes before returning query results; that change is more durable than training. Several county counsels adopted this approach after 2020 DOJ guidance.

One piece of practical counsel that applies broadly: when an agency is uncertain whether a specific disclosure falls under (C), the safer path is to withhold the record and route the request to the agency's legal counsel for a same-day determination. The Act doesn't create an urgency exception, and federal requesters routinely work on multi-day timelines unless there's an active criminal investigation. Counsel delays cost the agency less than disclosed violations do.

FAQ

Does SB 54 prohibit all database sharing with federal agencies?

No. Section 7284.6(a)(1)(F) governs disclosure of criminal history information under Penal Code § 11105, and that sharing is permitted without the four-condition test that applies to non-criminal history information. The result is that a federal requester may see an arrest record but not the field interview card from the same incident. Misreading the statute as an absolute ban drives both under-sharing of criminal history and over-sharing of non-criminal records.

What exactly is "immigration or citizenship status" for purposes of the database provision?

Status means a legal determination of whether a person is a U.S. citizen, permanent resident, asylee, refugee, nonimmigrant visa holder of a specified class, a TPS beneficiary, or an undocumented noncitizen. It doesn't cover country of birth, nationality claimed in a booking field, primary language, foreign address, or AB 60 license issuance. A field labeled "POB" is not status information; a status verification attached to that field by an authorized process is.

Can an agency share a person's release date with federal immigration officers?

Yes, under section 7284.6(b), which authorizes California agencies to share specified information in response to a federal immigration detainer — including criminal history information and the release date. The limitation is that the response may only cover the categories in (b), and non-criminal booking notes not meeting (C)'s status carve-in are not among them. Release date sharing without additional non-criminal data complies; extending the response to investigative notes does not.

Does the Act reach vendors who host an agency's records management system?

Yes, if the vendor is operating as a private entity using an agency database. Section 7284.6(c) prohibits California law enforcement agencies from allowing private entities to use an agency database for immigration enforcement purposes. Vendor contracts should contain an SB 54 compliance clause, and the clause should be re-executed whenever the vendor changes subprocessor arrangements. Contract audits routinely find gaps from pre-2018 master agreements.

Who enforces the database provision if an agency violates it?

Two paths exist. California DOJ may investigate and seek remediation under section 7284.8's enforcement powers, and private plaintiffs may pursue declaratory relief under the same section. The 2021 AB 1036 amendments preserved both paths while clarifying the enforcement mechanism. There is no private right of action for damages against agencies under SB 54 itself; relief is declaratory and injunctive through the mechanisms the statute specifies.

Does a name-and-date-of-birth query that returns a non-status field count as a violation?

It does if the purpose was immigration enforcement and the field returned isn't immigration or citizenship status. The (C) test evaluates the field accessed and the purpose, not the query method. An agency that pulls a full booking record for an immigration enforcement purpose and then shares only the portions that happen to be status information still faces an audit question about the access to the non-status portions, and the safer design is to scope queries at the field level before results return.

How does California's approach differ from other sanctuary state statutes?

California is the only state among the six considered here with an explicit database-access provision tied to a four-condition test and an express status carve-in. Oregon, Washington, Illinois, New Jersey, and Colorado address databases through general prohibitions on enforcement action or through guidance directives. The practical burden in California is heavier documentation but also provides clearer operational rules that reduce ambiguity, provided staff are trained on the four conditions rather than the "no cooperation" shorthand.

If a federal agency already has the data from another source, does SB 54 still restrict the state agency?

Yes. The restriction attaches to the California agency's access and use, not to the federal recipient's preexisting knowledge. If the state agency learns a federal investigator already has a booking log from another state, the state agency still cannot use its own database to confirm, supplement, or check that record for immigration enforcement unless all four conditions are met. The statute regulates the agency's touch, not the outcome.

This article provides general educational information about California Government Code § 7284.6 and related provisions; it is not a legal opinion and no attorney-client relationship is created. Compliance obligations vary by agency type, by records system architecture, and by subsequent amendment, so agency counsels should confirm the current text of SB 54 and any related California Department of Justice guidance before relying on this article for operational decisions. Readers struck by the operational specifics should consult a qualified California attorney who handles law enforcement compliance matters before implementing database configuration changes. For immediate emergencies involving immigration enforcement at a state facility, contact local law enforcement and the agency's legal counsel directly.