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. It is also called the Criminal Justice Information Services Security Policy (CJISSECPOL), and its requirements apply to data both at rest and in transit. That holds inside and outside physically secure locations, and 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.

The FBI CJIS Information Security Officer prepares the policy, and the Advisory Policy Board and the Compact Council approve it, so requirements are set jointly. 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.

Free download: Map the FBI’s CJIS Security Policy v6.1 requirements to NIST 800-53, CSF 2.0, SOC 2 TSC, ISO 27001, 800-171, CMMC Levels 1-3, and HIPAA with the NIST 800-53 Multi-Framework Crosswalk.

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). Eighteen of the 20 NIST 800-53 control families make up CJIS policy areas 2 through 19, leaving out PM and PT. 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 identifiers match and 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.0 phased the policy onto the NIST 800-53 control catalog a few control families 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. Much of the 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 a few at a time. The first, Version 5.9.1 in October 2022, modernized Media Protection.

Version 5.9.2, released December 7, 2022, modernized Awareness and Training, Identification and Authentication, and System and Information Integrity. Its Identification and Authentication controls brought in the multi-factor authentication requirement for privileged and non-privileged accounts. Earlier versions already required advanced authentication, but only under certain access conditions.

Version 5.9.5, released July 9, 2024, was the last release before the full restructure. It modernized Configuration Management and added the priority markings that still set enforcement dates.

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 19 policy areas to 20. The Version 6.0 PDF logs the change as “Policy Modernization Completion.” The priority markings that still govern enforcement were added earlier, in Version 5.9.5.

Version 6.1 — Corrections on Top of 6.0

Version 6.1, dated June 25, 2026, is a corrections release, and 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 describe Version 5.9 or 5.9.1, since Version 5.9.5 already had 19. 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 1998 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. So 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 the order agencies implement a control and, for new requirements, 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), which arrived in version 6.0 and has been sanctionable since that version was published on December 27, 2024.
• Priority 2 (P2): Modernized controls that lower risk but rank below the P1 set. New P2 requirements 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. New P3 requirements 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. New P4 requirements carry no earlier deadline than the tiers above, becoming sanctionable when the zero cycle ends on September 30, 2027.

The zero cycle covers only new requirements. Requirements carried over from version 5.9 are sanctionable now whatever their tier, and non-modernized sections carry no marking and remain auditable and sanctionable. Where non-compliance is serious or unresolved, sanctions can extend to termination of CJIS services. Improper access, use or dissemination of criminal history record information can also carry state and federal criminal penalties.

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 included:

• 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 and currently sits at version 6.1, dated June 25, 2026. 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 18 of the 20 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. Priority 1 controls and every requirement carried over from version 5.9 are already sanctionable. New lower-priority requirements 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 18 of the 20 NIST SP 800-53 families, and area 20 covers Mobile Devices. Guides citing 13 policy areas describe version 5.9 or 5.9.1, since version 5.9.5 already had 19.

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 carried over from version 5.9, and those marked Priority 1, are sanctionable now.

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 18 of the 20 NIST SP 800-53 families. That means 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.