CJIS Security Policy v6.1: what AI use leaves in the audit record.
For the CJIS security officer, agency records supervisor, agency IT and the vendors that handle CJI, this page sets out what CJIS Security Policy v6.1 asks of an audit record and what the record Verillian keeps shows when staff use AI on enrolled devices.
What the policy asks, control by control
| What the policy asks | A Verillian record shows | It does not show |
|---|---|---|
| The policy covers every entity with access to CJI, or that runs a system used to process, store or transmit it. 1.2 | Each governed AI service staff used from an enrolled device, and when. | What any prompt contained, CJI included. Whether AI may be used around CJI is decided by your agency with its CJIS Systems Agency. |
| Name the event types to log, including 'events sufficient to establish what occurred'. Give a rationale that they support 'after-the-fact investigations of incidents', and review the list annually. Generate records for those event types. AU-2, AU-12 | One entry for each captured request that leaves an enrolled device for a provider your signed policy names, with a ruling of allowed, redacted or blocked. | The event types your agency selects, the rationale or the annual review. Not log-ons, permission use or other events on your systems that AU-2 lists. |
| Each audit record establishes the type of event, when and where it occurred, its source and outcome, and the identity of any individuals, subjects or objects associated with it. AU-3 | A time, the AI service, the ruling and the kind of request on each entry. The user and device are the ones the checkpoint reports. | Which person was at the keyboard. An entry is attributed to the user and device the checkpoint reports. |
| Limit personally identifiable information in audit records to the 'minimum PII necessary to achieve the purpose for which it is collected'. AU-3(3) | Values your policy sets to redact are replaced before a prompt leaves the device. Content in an entry is encrypted under a key your agency holds. | Values the policy does not flag. Redaction is best effort; only the Claude API format is verified, so an entry can hold what staff typed. Whether that fits your privacy risk assessment is for your agency. |
| Alert audit and system personnel 'within one (1) hour in the event of an audit logging process failure', then restart the logging processes and verify they are logging. AU-5 | Nothing is claimed here. Alerting and restarts sit in your own monitoring of the systems that log. | Whether your staff were alerted, or whether a logging process restarted. |
| Review and analyze audit records weekly for 'inappropriate or unusual activity', report findings, and adjust the review when risk changes. AU-6(1) and (3) add automated integration and correlation across repositories. AU-6 | Entries can be searched and exported as a plain file from the admin console your agency runs. | The weekly review, who receives the findings, or correlation with your other logs. Those run in your own tools and staff. |
| Use internal system clocks for time stamps that meet 'hundredths of a second' and use Coordinated Universal Time, a fixed offset from it, or include the local offset. AU-8 | A time on each entry. | Whether the stamps meet that interval and form. Check a sample export with your auditor before you rely on it. |
| Protect audit information and audit logging tools 'from unauthorized access, modification, and deletion', and alert named personnel when that is detected. The AU-9 text does not name signing or hash chaining. AU-9 | Each entry is signed on its device and chained by hash to the entry before it. A signed field that changes is detectable: your own admin server checks each entry as it arrives and flags one that does not link or verify. | Deletion of the newest entries, which leaves no gap, or deletion by someone who controls the host. Who can reach the server, and who gets an alert, stay with your program. |
| Retain audit records 'for a minimum of one (1) year or until it is determined they are no longer needed for administrative, legal, audit, or other operational purposes'. AU-11 | Entries are kept on infrastructure your agency runs. | The period your agency applies, or any hold beyond one year. This page states no retention setting for Verillian. |
| Protect CJI at rest outside physically secure locations with cryptographic modules 'certified FIPS 140-3' with a symmetric key of at least 256-bit strength, or 'FIPS 197' with the same key strength. SC-28 | Content in an entry is sealed with AES-256-GCM under a key your agency holds. | Whether the module is certified, or whether your CJIS Systems Agency accepts it as meeting the FIPS 140-3 or FIPS 197 route. No certification is claimed. |
| Limits | Requests captured on enrolled devices that go to a provider your signed policy names. A provider the policy leaves unnamed is not governed. | That nothing was omitted, anything inside a vendor's own cloud, or whether a prompt held CJI. A record on your own infrastructure does not make an agency meet the policy. |
Source: FBI CJIS Security Policy, version 6.1, 06/25/2026, which replaces version 6.0 of 12/27/2024. Read in full on October 8, 2026, at le.fbi.gov/file-repository/cjis_security_policy_v6-1_20260625.pdf. Quoted text and control numbers are from that document.
Aligned: CJIS Security Policy v6.1 / NIST 800-53 AU-family. Not certified. This is not legal advice or an audit opinion. Your CJIS Systems Agency and its auditors decide what satisfies your controls.
To read one entry against these controls, bring a sample request to a demo. We read every request and reply.
Questions about CJIS and AI records
Does the CJIS Security Policy require tamper-evident or hash-chained audit logs?
Not in the AU controls. AU-9 asks agencies to protect audit information and audit logging tools from unauthorized access, modification and deletion, and to alert named personnel when that is detected. It does not name signing or hash chaining. A signed, linked record gives detection something to work with, and what satisfies AU-9 is a decision for your agency's assessors and its CJIS Systems Agency.
Does the CJIS Security Policy say anything about AI?
Version 6.1 has no AI-specific control and no requirement for an AI audit log. Its one mention of artificial intelligence is in the SI-3 discussion of malicious code protection, which lists artificial intelligence techniques among nonsignature-based detection mechanisms. Whether the policy reaches a given AI tool turns on whether the tool has access to CJI or runs on a system that processes, stores or transmits it (1.2), a question for your agency to settle with its CJIS Systems Agency.
What changed between version 6.0 and 6.1?
Version 6.0 is dated 12/27/2024 and version 6.1 is dated 06/25/2026. The policy's change table describes 6.1 as incorporating calendar year 2025 changes. Its summary lists three sets of Advisory Policy Board approved corrections and additions to the modernized policy from spring 2025, plus administrative changes the Security and Access Subcommittee approved on November 14, 2025. Guides written for earlier versions may number requirements differently, so check any control number against 6.1.
What about the contractors that handle CJI for an agency?
Section 3.2.6 defines a contracting agency as one that enters an agreement with a private contractor subject to the CJIS Security Addendum, and says it shall appoint an Agency Coordinator. Section 3.2.7 describes that coordinator as a staff member who manages the agreement. A contractor that enrolls its own devices holds its own entries, on its own infrastructure, so whether the agency can read them is a term for the contract. A model a vendor calls from its own hosted service is outside what an enrolled device sends.
See an entry next to these controls.
Thirty minutes, a sample request, ruled live, with the signed record open between us.