CJIS Compliance: What It Requires and Where Agencies Fail

Criminal Justice Information Services (CJIS) compliance means meeting the minimum security requirements in the FBI’s CJIS Security Policy for every system and every person that touches criminal justice information (CJI). A state CJIS Systems Agency audits the agency against the policy, and the agency carries the liability for what that audit finds.

This guide covers what compliance requires, who is bound and how, what auditors actually test, and the findings that recur across state audits. Readers who need the underlying basics can start with our complete guide to CJIS, which covers the FBI’s CJIS Division and the data it governs.

What Is CJIS Compliance?

CJIS compliance is the condition an agency evidences continuously through audit. The substance is meeting the policy’s minimum security requirements across the full lifecycle of criminal justice information, from creation, viewing, modification, and transmission through dissemination, storage, and destruction. The most current version of the CJIS Security Policy is 6.1, published June 25, 2026. Its requirements span technical controls, personnel screening, physical security, documentation, and vendor agreements.

CJIS compliance is the ongoing work of protecting criminal justice information for as long as an agency holds it. Agencies lock down their systems to CJIS Security Policy and NIST SP 800-53 levels, screen everyone who touches the data, document how it works, and show a state auditor the evidence roughly every three years.

There is no FBI-issued organizational CJIS certification. Compliance is assessed by the state CJIS Systems Agency (CSA) on a roughly three-year cycle, and the audited agency carries the liability for what that audit finds.

However, compliance measured against one version of the policy does not carry forward indefinitely. Because the control set changed substantially in December 2024, agencies that built their programs against the 2020 policy will still be measured against version 6.1 at their next audit.

Who Must Comply with CJIS?

Contractors, private entities, and noncriminal justice agency representatives must comply with CJIS. Its scope includes every individual with access to criminal justice information, along with everyone operating in support of criminal and noncriminal justice services.

The CJIS Security Addendum is the instrument that brings private contractors into scope. The contracting government agency must give every contractor employee a copy of the Addendum and the policy, and keep a signed acknowledgment available for audit.

The contractor’s obligation tracks the policy in effect when the contract is executed and all subsequent versions. So, a contract signed under version 5.9 does not freeze the contractor at the 2020 control set. The Addendum’s terms may be modified by the FBI, or by the parties with the FBI’s consent.

For cloud and hosted services, the agency remains accountable regardless of which provider stores the data. Auditors ask whether the shared-responsibility boundary is written down, because a documented boundary assigns every control to a named party.

Agencies should also check what their own state adds, since a CJIS Systems Agency may impose more stringent or additional protection measures than the federal minimum. Those decisions must be documented and kept current.

What CJIS Compliance Requires: Policy Areas and Control Families

The most current version of the CJIS Security Policy, version 6.1, organizes its requirements into 20 areas. Before it was superseded in December 2024, CJIS version 5.9 included 13 policy areas, which is why older guides still describe a 13-area structure.

The 20 policy areas fall into three groups:

• Area 1 — Information Exchange Agreements: The agreements that authorize data sharing in the first place, and usually the first document an auditor asks for.
• Areas 2 through 19 — the 18 NIST SP 800-53 control families: Access control, awareness and training, audit and accountability, assessment and authorization, configuration management, contingency planning, identification and authentication, incident response, maintenance, media protection, physical and environmental protection, planning, personnel security, risk assessment, system and services acquisition, system and communications protection, system and information integrity, and supply chain risk management.
• Area 20 — Mobile Devices: The requirements that apply once CJI leaves a physically secure location, which raises most modern scope questions.

For a team already running a NIST 800-53 or NIST Cybersecurity Framework (CSF) program, the middle eighteen will already be familiar. However, because CJIS prescribes specific values where NIST SP 800-53 Rev 5 leaves them open, a control that exists in both places can still fail a CJIS audit on its parameters. Teams running more than one program can map those control families across frameworks with the NIST CSF 2.0 Multi-Framework Crosswalk.

How Is CJIS Compliance Assessed?

CJIS compliance is assessed by showing that controls operate as documented, over time. Version 6.0 onward expects demonstrated operational effectiveness, which is a higher bar than documented intent. Auditors ask for records that show each control operating.

CJIS compliance testing covers five areas:

• Technical validation: Multi-factor authentication (MFA) enforcement across every access path, Federal Information Processing Standards (FIPS) validated encryption for data at rest and in transit, logging content and retention, hardening baselines, and patch status.
• Documentation review: The system security plan, agency policies, information exchange agreements, the plan of action and milestones (POA&M), and training records.
• Personnel verification: Fingerprint-based screening completed before access is granted, and access terminated promptly when someone leaves or changes role.
• Physical inspection: Whether physically secure locations are defined, controlled, and logged.
• Exercise testing: Incident response and contingency plans exercised, with records of each exercise.

Auditors pull a sample of access reviews and audit logs to check whether the review actually happened, and weekly audit-log review is the expectation. Evidence captured as the work happens tends to produce a defensible record without manual assembly at audit time.

Enforcement follows a separate timeline, set by the priority tier printed against each control in the policy.

• Priority 1: These requirements have been sanctionable since October 1, 2024.
• Priority 2 through Priority 4: These requirements are in a zero cycle that runs to September 30, 2027, during which findings are recorded but not sanctioned.

The policy states each tier and its enforcement date in its own LIST OF PRIORITIES. A control’s tier can be read straight from the policy document rather than inferred from secondary guidance.

Where Agencies Fail CJIS Audits

Agencies fail CJIS audits mostly on coordination and upkeep. Usually the agency knows the rule, though the document describing it no longer matches how the work is actually done.

The most useful public account comes from a state CJIS Systems Agency rather than a vendor. Utah’s Department of Public Safety published its common audit findings, and its documentation findings are specific. Agency policies are:

• Not documented at all. The control runs in practice with no written policy behind it, or the policy was written and never implemented.
• Not reviewed or revised recently. The policy set no longer matches the agency’s current environment.
• Copied from the CJIS Security Policy. The agency’s binder restates the FBI’s requirements as its own policy.
• Not tailored to the agency’s implementation. An auditor reading it learns nothing about how the agency operates.

The last two deserve attention, because they describe a policy set that looks complete and still fails. Pasting the federal text into an agency binder documents the FBI’s requirements, while the audit asks how this agency implements them.

Utah names three more findings that rarely appear in other guides.

• Role knowledge: The Terminal Agency Coordinator (TAC) or Local Agency Security Officer (LASO) is unfamiliar with the requirements they own.
• Security awareness training: Required topics are missing, or the training is not documented thoroughly enough to evidence.
• Incident response: Plans are written but not fully developed.

Utah’s own recommendation is to review the policy for the agency’s specific requirements, and to work with the LASO rather than treating compliance as an IT-only exercise.

Access control is the most frequent technical finding category, and its recurring items are specific.

One published account of MFA gaps names five recurring patterns:

• Perimeter without workstation coverage: MFA guards the network edge while internal workstations have no second factor.
• Legacy applications outside the identity provider: Older systems authenticate locally, so the MFA policy never applies to them.
• Administrative jump boxes: The most privileged access path is the one most often exempted for operational convenience.
• Undocumented exception accounts: Exemptions granted informally carry no written justification and no expiration date.
• Shared operational accounts: A credential used by several people ties its second factor to the credential rather than to a person.

Since that list comes from a single account, it reads as one auditor’s experience rather than a general finding. Each item is still worth checking directly.

How to Simplify CJIS Compliance

Simplifying CJIS compliance means making the evidence easy to produce. Every finding above is a documentation or upkeep gap with an artifact that would have closed it, and most teams running these programs can already point to the control. The harder part is showing an auditor the record of it operating.

Isora GRC is a governance, risk, and compliance (GRC) platform built for that work. The GRC Assessment Platform™ gives security teams one connected workspace to run assessments, manage vendors and assets, track risks, and prove compliance.

Exception Management

Exception Management documents, tracks, and resolves deviations from policy. Each exception carries a justification, its compensating controls, a mandatory expiration date, and automated review reminders, linked to the assets, vendors, and applications it applies to. A compensating control approved two years ago comes back for review while there is still time to act on it.

Risk Management

Risk Management turns assessment findings into a working risk register, so a stale POA&M shows up as an open item with an owner. Each risk carries an owner, a remediation plan with milestones, and a status workflow that runs through to closure, with an append-only audit log recording every change.

Reports & Scorecards

Reports & Scorecards generates audit-ready reports directly from live assessment data. An auditor asking why a control is marked satisfied can be walked back through the response, the evidence, and the control mapping in one place.

Inventory Management

Inventory Management maintains a connected record of vendors, assets, and systems, which is the basis for accurate audit scope. Every inventory item links to its assessment history, associated risks, and data classification, so the picture of which systems touch CJI stays current.

See how Isora GRC simplifies CJIS compliance →

Key Takeaways

CJIS compliance is a condition an agency evidences continuously, and the state CJIS Systems Agency audit is where that evidence gets tested. The agency carries the liability for whatever the audit finds, and no FBI-issued certificate stands in for it, so a vendor calling itself “CJIS certified” is describing something the FBI does not issue.

The most useful move for most teams is to read the agency’s own policy set and ask whether it describes that agency’s implementation or restates the FBI’s. Then, enforcement follows a priority schedule.

Keeping pace with those dates across every system, agency, and vendor in scope is the ongoing task. Isora GRC gives teams one place to assess against that control set, track exceptions and remediation as the work happens, and produce the audit-ready evidence a state auditor can trace.

See the GRC Assessment Platform™ in action →

CJIS Compliance FAQs

What is CJIS compliance?

CJIS compliance means meeting the minimum security requirements set out in the FBI’s CJIS Security Policy for the full lifecycle of criminal justice information. It covers technical controls, personnel screening, physical security, documentation, and vendor agreements. Compliance is demonstrated through a state CJIS Systems Agency audit.

Is there a CJIS certification?

No. The FBI does not issue an organizational CJIS certificate. Agencies are audited against the CJIS Security Policy by their state CJIS Systems Agency, typically on a three-year cycle. A vendor describing itself as “CJIS certified” is using a marketing term that the FBI does not confer.

Who has to be CJIS compliant?

Every individual and organization with access to criminal justice information, or operating in support of criminal and noncriminal justice services. That includes contractors, private entities, and cloud providers. Private contractors are brought into scope through the CJIS Security Addendum.

What is CJIS compliance testing?

CJIS compliance testing is the validation that controls operate as documented. It covers technical checks such as MFA enforcement and FIPS-validated encryption, documentation review, personnel screening verification, physical inspection, and incident-response exercises. Version 6.0 onward expects evidence of operational effectiveness over time.

How often are CJIS audits conducted?

CJIS audits are typically conducted every three years, run by the state CJIS Systems Agency or the FBI’s CJIS Audit Unit. Agencies are expected to be audit-ready continuously, because the policy expects ongoing monitoring and reviewed logs.

What happens if an agency fails a CJIS audit?

Consequences can include suspension of access to NCIC and Nlets, penalties under the Security Addendum, and loss of inter-agency data sharing. Willful violations can carry criminal liability. In practice most agencies enter a remediation process with a plan of action and milestones.

This content is for informational purposes only and does not constitute legal or compliance advice. See our full disclaimer.