CJIS audit logging requirements for file storage

CJIS audits used to be about logins and terminals. Since version 6.0 restructured the policy onto NIST SP 800-53 control families, Audit and Accountability is a full family of individual requirements, each with its own priority and sanction date. Most of them land on wherever CJI is stored, and for most agencies that is a file share holding case folders, evidence exports, and records attachments.

This guide walks the audit controls in CJIS Security Policy v6.1 that matter most for file storage, what each asks for in plain language, and what an auditor will want to see.

Requirements tagged Existing or Priority 1 have been sanctionable since October 1, 2024. Priority 2 through 4 requirements that are new in the modernized policy sit in a zero cycle, reviewed at audit but not sanctioned, until September 30, 2027.

The gap is rarely the login. Directory services and VPNs log authentication well. The gap is what happened after: which files a session opened, copied, renamed, or deleted. Native file-server auditing can record that in principle, but it is often switched off or narrowed because of the volume it produces, and its logs usually sit on the same system an intruder with administrator rights controls.

That leaves three common findings. Records that show a user signed in but not what they read, which fails the spirit of AU-3. Logs the storage administrator can edit or delete, which fails AU-9. And retention set by whatever fits on the server, which fails AU-11 the first time an investigation reaches back more than a few months.

The discussion text under AU-3 lists what each field typically means: event descriptions, time stamps, source and destination addresses, user or process identifiers, success or failure indications, and the filenames involved. For a file share, a record that passes reads like this: user, client IP address, protocol, operation (read, write, rename, delete, or permission change), full file path, outcome, and a UTC timestamp from a synchronized clock.

If any of those are missing, the record cannot answer the question an investigator or auditor will actually ask, which is who touched this specific file.

AU-9 is the control most file platforms quietly miss. The point of an audit record is that it holds up when someone with privileges has a reason to change it. The reliable way to meet it is to send every record off the storage system as it is written, to a SIEM or log store with its own access controls, so that no storage administrator can alter the copy an auditor reads.

Inside the storage system, limit who can view audit data to the roles that need it, and map a read-only reviewer role to the people who perform the weekly review, so reviewing the log does not require the right to change the system.

AU-6 asks for review and analysis at least weekly for inappropriate or unusual activity. On a busy share that is millions of events, and no one reads them. A review that works starts from what is unusual: a user reading far more files than normal, a service account touching shares it never uses, a session renaming files in bulk, access at hours that do not match the job. The weekly record then documents what was flagged, who looked, and what was escalated.

BrickStor SP writes three audit streams. The Hub audit log records every administrative action, including service actions run from the command line. User Behavior Auditing records every file read, write, delete, rename, and permission change per dataset, and denied access attempts are logged as well, with the user, role, client IP address, protocol, full path, outcome, and a UTC timestamp from an NTP-synchronized clock. The system log covers authentication and operating system events.

All three forward to the agency’s SIEM over TLS-protected syslog in RFC 5424 or CEF format, which puts the copy an auditor relies on outside the reach of any storage administrator. Inside the platform, audit views are limited to management roles, and a read-only Hub User role can be mapped to the review group. Local retention is set by time and capacity, and records can also be kept on a replication partner BrickStor for long-term retention.

For the weekly review, Active Defense analyzes file activity continuously, opens an incident when behavior breaks from a user’s normal pattern, and can terminate the session in under a second. The review starts from those incidents and the user behavior reports, not from the raw stream.

Pick one file holding CJI. Open it from a workstation, then find that event in your SIEM. Check that the record names the user, the client, the full path, the operation, the outcome, and the time. Then ask who could delete that record, and how you would know if they did. Those two answers are most of your AU-3 and AU-9 position.