The CJIS Security Policy: What It Covers and What Changed

The CJIS Security Policy is the FBI’s minimum security standard for protecting criminal justice information. The most current version of the CJIS is 6.1, dated June 25, 2026, and runs 473 pages long. In 2026, the CJIS Security Policy is also a public document.

Most people assume a law-enforcement security standard is controlled. Yet CJIS Version 6.0 and later may be posted and shared without restriction. Today, Version 6.1 is available on the FBI’s CJIS Security Policy Resource Center for anyone to download the requirement itself.

This guide explains what the CJIS Security Policy is, how it’s structured, what’s changed in the last two releases, and how contractors are bound to its requirements.

What Is the CJIS Security Policy?

The CJIS Security Policy is the FBI’s set of minimum security requirements for protecting criminal justice information across its full lifecycle. Also called the Criminal Justice Information Services Security Policy (CJISSECPOL), its requirements apply to data both at rest and in transit, inside and outside physically secure locations, from creation and viewing through modification, transmission, dissemination, storage, and destruction.

The CJIS Security Policy is a set of security requirements to protect criminal justice information, from creation to destruction. The most current version is 6.1, published on June 25, 2026.

The Federal Information Security Modernization Act of 2014 is the CJIS Security Policy’s legal grounding. It provides further legal basis for the Advisory Policy Board-approved requirements that protect criminal justice information. Those requirements sit on top of the FBI’s underlying statutory authority to acquire and exchange criminal history records under 28 U.S.C. § 534.

To ensure requirements are set jointly, the FBI CJIS Information Security Officer prepares the policy, and the Advisory Policy Board and the Compact Council approve it. However, because it sets “minimum” security requirements, the CJIS Security Policy acts as a floor, rather than a ceiling. More specifically, state CJIS Systems Agencies can and do impose stricter protection measures on top of the federal text itself.

Finally, to clear any confusion, some guidance still treats CJIS as controlled because earlier versions of the policy were handled more strictly.

What’s Inside the CJIS Security Policy: 20 Policy Areas

The CJIS Security Policy organizes its requirements into 20 policy areas. Here, the structure matters more than the number, since CJIS policy areas 2 through 19 map straight onto the NIST 800-53 control families.

Modernizing the CJIS Security Policy meant re-hosting the CJIS requirements inside a control catalog that federal security agencies already use, according to the IACP’s account. NIST SP 800-53 is the federal control catalog published by NIST (the National Institute of Standards and Technology). The 18 Control Families of 800-53 make up CJIS policy areas 2 through 19, respectively. Now, only areas 1 and 20 still carry the “Policy Area” label, while the rest sit under their NIST family headers.

For organizations with an established NIST 800-53 program, the benefits of CJIS modernization are clear. When the control families and the control identifiers match, and the assessment artifacts transfer, teams mapping 800-53 to CJIS have already done most of the underlying control work.

But the caveat is equally concrete — and it’s where a lot of teams get stuck. Where CJIS prescribes specific values, NIST 800-53 leaves them organization-defined. For example:

• NIST 800-53 AC-7 says to enforce a limit of some organization-defined number of failed logon attempts.
• CJIS sets that number at five, within a fifteen-minute window, and with release by an administrator.

The control is the same, but CJIS provides the exact value that NIST 800-53 leaves open. So, checking those prescribed values is just about the only CJIS-specific work a NIST program still has to do.

CJIS Security Policy v6.1: Version History and What Changed

The CJIS Security Policy reached Version 6.1 on June 25, 2026, but the release that reshaped it was Version 6.0 in December 2024. The point releases between Version 5.9 and Version 6.1 phased the policy onto the NIST 800-53 control catalog one control family at a time. That phase-in is why so much guidance written against the older 13-area structure is now wrong.

Version 5.9 — The Pre-Modernization Baseline

Version 5.9, dated June 1, 2020, organized the CJIS Security Policy into 13 policy areas. It folded in the calendar-year 2019 APB changes, including Mobile Device Management clarifications in Section 5.13.2. Most CJIS content still in circulation describes this structure. The Version 5.9 PDF shows the original layout.

Versions 5.9.1 Through 5.9.5 — Modernization Phased In

Between 2022 and 2024, the 5.9.x point releases added modernized control families to the old 13-area structure one at a time. Version 5.9.2, released December 7, 2022, introduced the multi-factor authentication requirement the policy calls advanced authentication. Version 5.9.5, released July 9, 2024, added the modernized Configuration Management and System and Information Integrity control families. It was the final release before the full restructure.

Version 6.0 — The Restructure

Version 6.0, dated December 27, 2024, completed the modernization. The Security Policy Modernization Task Force restructured the entire policy onto NIST 800-53 Rev. 5 control families, expanding 13 policy areas to 20. The Version 6.0 PDF logs the change as “Policy Modernization Completion.” It also introduced the phased priority timeline that still governs enforcement.

Version 6.1 — Corrections on Top of 6.0

Version 6.1, dated June 25, 2026, is a corrections release. Its change entry reads “Incorporate Calendar Year 2025 Changes.” It covers the Spring 2025 APB papers titled “Addressing Omissions, Corrections, and Additions to the Modernized CJIS Security Policy.” It also folds in administrative changes the Security and Access Subcommittee approved on November 14, 2025. Version 6.1 keeps the 6.0 structure intact, so an agency that mapped its program to 6.0 keeps that mapping under 6.1.

Guides citing 13 policy areas are describing the June 2020 version, six years out of date. That framing has been copied forward into a good deal of recently published content.

The CJIS Security Addendum: How Contractors Are Bound

The CJIS Security Addendum is the contractual instrument that brings private contractors into scope. It applies where a private entity controls or manages a criminal justice system, or has been given connectivity to FBI CJIS systems. The basis for contractor access rests on a 2014 Office of Legal Counsel opinion. That opinion found that non-governmental entities performing authorized criminal justice functions may access these records under statutory controls.

The Addendum augments the CJIS Security Policy and defines “adequate security” by reference to OMB Circular A-130. It also incorporates several federal authorities by reference. Those include the NCIC 2000 Operating Manual, the CJIS Security Policy, and 28 CFR Part 20, the federal regulation governing criminal history record information. Beyond that, the Addendum creates specific obligations:

• Distribution and acknowledgment: The contracting government agency gives every contractor employee a copy of the Addendum and the policy, and keeps a signed acknowledgment on file for audit.
• A rolling obligation: The contractor maintains a security program consistent with the CJIS Security Policy in effect at signing and every later version. A contract signed under version 5.9 still carries a version 6.1 obligation.
• Escalation: Violations are reported to the CJIS Systems Officer and the Director of the FBI, and can justify terminating the agreement. The FBI may suspend or terminate access.
• Data on exit: On termination, the contractor deletes or returns records containing criminal history record information.
• Post-termination audit: The FBI may perform a final audit after the contract ends.

The Addendum published at the current resource center link is dated June 1, 2020 and carries document ID CJISD-ITS-DOC-08140-5.9. the current published Addendum is a Version 5.9-era instrument, while the policy itself sits at 6.1. It can be modified, but only by the FBI or by the parties to the appended agreement with the FBI’s consent.

Is the CJIS Security Policy Mandatory?

The CJIS Security Policy applies to all entities with access to or operating in support of FBI CJIS Division services and information. It is applied through the CJIS advisory process, taking federal law and state statutes into consideration.

A chain of agreements set the requirements in motion:

• The agreement between an agency and its state CJIS Systems Agency
• The user agreements that grant system access
• The Security Addendum for contractors

Breaking the policy breaks those agreements, with compliance verified through audits. The FBI’s CJIS Audit Unit reviews each state CJIS Systems Agency on a roughly triennial cycle. In turn, each state agency audits the local agencies and contractors that connect through it. Those audits are where prescribed values and priority-tagged controls get checked against how an organization actually operates.

The enforcement clock is explicit. The Advisory Policy Board scored each modernized control by risk and tagged it Priority 1 through Priority 4, and the policy’s list of priorities defines each tier. The tag sets both the order agencies implement a control and when auditors can sanction it.

• Priority 1 (P1): The highest-risk modernized controls, sanctionable since October 1, 2024 alongside the pre-modernization “Existing” requirements. This tier holds the roughly two dozen controls that most directly cut breach risk. Examples include multi-factor authentication (IA-2), account management (AC-2), least privilege (AC-6), remote access (AC-17), and continuous monitoring (CA-7).
• Priority 2 (P2): Modernized controls that lower risk but rank below the P1 set. They sit in the zero cycle and become sanctionable when it closes on September 30, 2027. Examples include configuration change control (CM-3), the configuration management plan (CM-9), user-installed software restrictions (CM-11), and contingency planning (CP-1 and CP-2).
• Priority 3 (P3): Lower-risk modernized controls, mostly the procedural and supporting requirements behind the higher tiers. They share the same zero cycle and the same September 30, 2027 date. Examples include security authorization (CA-6), internal system connections (CA-9), change impact analyses (CM-4), and contingency training (CP-3).
• Priority 4 (P4): The lowest-risk modernized controls, last in the recommended implementation order. They carry no earlier deadline than the tiers above, becoming sanctionable when the zero cycle ends on September 30, 2027.

Non-modernized sections carry no marking and remain auditable and sanctionable. Consequences for failure include suspension of access to NCIC and NLETS, penalties under the Security Addendum, and loss of inter-agency data sharing.

How to Simplify CJIS Compliance

The most challenging part of CJIS is proving that each requirement is met across every system and agency in scope, with evidence a state auditor can trace.

Isora GRC is the GRC Assessment Platform™ that gives security teams one connected workspace to run assessments, manage vendors and assets, track risks, and prove compliance. Capabilities inclued:

• Assessment Management: Teams run structured assessments against the control set their program already uses and distribute them across departments, agencies, and vendors. Because policy areas 2 through 19 are the NIST 800-53 families, an existing 800-53 program carries most of the way over, with the CJIS-prescribed values checked on top.
• Reports & Scorecards: Findings carry full lineage from questionnaire response to control to risk, so an auditor can see the response, the evidence, and the mapping in one place.

See how Isora GRC simplifies CJIS compliance →

Key Takeaways

The CJIS Security Policy is the FBI’s public standard for protecting criminal justice information. It runs 473 pages, currently sits at version 6.1 dated June 25, 2026, and anyone can download it from the FBI to read the exact requirement they are audited against.

The structure is the most useful thing to know. Policy areas 2 through 19 are the eighteen NIST 800-53 control families. An organization with an established 800-53 program has already done most of the underlying control work and only applies the CJIS-prescribed values on top.

Enforcement then runs on a priority schedule. The highest-risk Priority 1 controls have been sanctionable since October 1, 2024, and the rest become sanctionable when the zero cycle closes on September 30, 2027.

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

See the GRC Assessment Platform™ in action →

CJIS Security Policy FAQs

What is the CJIS Security Policy?

The CJIS Security Policy is the FBI’s minimum security standard for protecting criminal justice information across its full lifecycle. That covers creation, viewing, modification, transmission, dissemination, storage, and destruction, at rest and in transit. It is prepared by the FBI CJIS Information Security Officer and approved by the Advisory Policy Board and the Compact Council.

What is the current version of the CJIS Security Policy?

Version 6.1, dated June 25, 2026. It replaced version 6.0 of December 27, 2024. Version 6.1 incorporates calendar-year 2025 changes, meaning corrections, omissions, and additions, rather than restructuring the policy.

How many policy areas does the CJIS Security Policy have?

Twenty. Area 1 covers Information Exchange Agreements, areas 2 through 19 are the 18 NIST SP 800-53 control families, and area 20 covers Mobile Devices. Guides citing 13 policy areas are describing version 5.9 from June 2020.

Is the CJIS Security Policy publicly available?

Yes. Version 6.0 and later is a publicly available document and may be posted and shared without restrictions, per section 1.5 of the policy. The current PDF is published on the FBI’s CJIS Security Policy Resource Center.

Is the CJIS Security Policy mandatory?

It applies to all entities with access to, or operating in support of, FBI CJIS Division services and information. It is enforced in practice through the state CJIS Systems Agency relationship, user agreements, and the Security Addendum. Requirements marked Priority 1 have been sanctionable since October 1, 2024.

What is the CJIS Security Addendum?

The CJIS Security Addendum brings private contractors into scope where a private entity manages a criminal justice system or is given connectivity to FBI CJIS systems. The contracting government agency must give every contractor employee a copy and keep a signed acknowledgment available for audit. It may only be modified by the FBI, or by the parties with the FBI’s consent.

Does the Security Addendum lock a contractor to one version of the policy?

No. It requires a security program consistent with the CJIS Security Policy in effect when the contract is executed and all subsequent versions. That makes it a rolling obligation, so a contractor signed under version 5.9 is still expected to keep pace with 6.1.

Does the CJIS Security Policy follow NIST 800-53?

Yes, structurally. Policy areas 2 through 19 of version 6.1 are the 18 NIST SP 800-53 control families, so an organization with an established 800-53 program has already done much of the underlying control work. CJIS prescribes specific values for parameters that 800-53 leaves open, so the mapping still needs CJIS-specific checks.

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