What Version 6.1 Changed, and When

Published September 14, 2026 · Updated October 13, 2026

A great deal of vendor content describes version 6.1 as the release that restructured the CJIS Security Policy onto NIST control families. That is not what happened, and the error matters, because it puts the change two years later than it occurred and sends agencies looking for a transition they have already been living through.

The arc, not the release

Modernization was staged across several versions.

Version 5.9, June 2020, is the pre-modernization baseline. Thirteen policy areas. Most CJIS guidance still circulating on the open web describes this structure.

Version 5.9.5, July 2024, was the last release before the restructure. It is also where the priority and implementation markings first appeared. Section 1.4 of the current policy states this directly: priority and implementation markings were added to the modernized controls effective in version 5.9.5.

Version 6.0, December 2024, is the restructure. Twenty policy areas replacing thirteen, organized on the NIST SP 800-53 Rev. 5 control families.

Version 6.1, June 25, 2026, incorporates the calendar year 2025 changes. It is a corrections and updates release on top of 6.0, not a second redesign. The Requirements Companion Document for v6.1 states that recommended changes to version 6.0 were approved by the Advisory Policy Board in June 2025 and subsequently approved by the Director.

So an agency asking “what do we need to do differently for 6.1” is asking a smaller question than it thinks. The larger question, “what did the restructure change,” was answered in December 2024 and most agencies have not fully absorbed it yet.

What the restructure actually did

The current policy has 20 policy areas. Policy Area 1 covers information exchange agreements. Policy Areas 2 through 19 correspond to the NIST SP 800-53 Rev. 5 control families: Access Control, Awareness and Training, Audit and Accountability, Assessment Authorization and Monitoring, 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. Policy Area 20 covers mobile devices.

The controls carry NIST identifiers. AC-2. CA-7. SI-4. Each has a control statement, a discussion section, and a list of related controls.

That is not a formatting change.

The consequence most agencies have not priced in

Under the legacy policy-area structure, CJIS compliance was substantially a training and policy-management discipline. Confirm personnel completed security awareness training. Maintain written policies covering the thirteen areas. Keep the signed agreements current. Produce them at audit.

The 800-53 structure asks a different question. It asks whether a control operates.

CA-7 is the clearest example. It requires a system-level continuous monitoring strategy, names 20 metrics to monitor, and requires an established frequency for both monitoring and assessment of control effectiveness. There is no version of satisfying CA-7 with a document. It requires evidence generated over time.

CA-2 Control Assessments and its enhancement CA-2(1) Independent Assessors point the same direction. So does CA-5 Plan of Action and Milestones, which presumes findings exist and are tracked to closure.

The practical translation: CJIS compliance moved out of training administration and into information systems audit. The skill set that satisfies it is closer to what a financial statement auditor or an IT general controls assessor does than what a training coordinator does.

For a fifteen-officer department where the chief is also the TAC, that is a significant shift and nobody has funded it.

What changed specifically in 6.1

Because it is a corrections release, the changes are targeted rather than structural. Two that have practical operational cost:

SC-13 and SC-28 require a symmetric cipher key of at least 256-bit strength for CJI in transit and at rest.

Vulnerability scanning frequency for confirming that applicable software or firmware updates are installed moved from quarterly to at least monthly, or following any security incident involving CJI.

The second one is worth pausing on. Monthly is four times the previous cadence. An agency running quarterly scans through a managed service provider has a contract to revisit, and the cost difference is real for a small department.

Where the Security Addendum sits

Worth knowing if you use vendors, which every agency does.

The CJIS Security Addendum is the instrument that binds contractors. It is published separately from the policy and is currently a version 5.9-era document, carrying document identifier CJISD-ITS-DOC-08140-5.9, dated June 1, 2020, while the policy itself sits at 6.1.

That is not an error on anyone's part. The Addendum is a legal instrument with its own amendment process, modifiable only by the FBI or by the parties to the appended agreement. It does mean that the document your vendor signed and the document your agency is assessed against are on different versions, and the gap is yours to close through contract terms rather than the Addendum's.

What to do with this

If your compliance program was built for 5.9, the work is not updating it for 6.1. It is rebuilding it for 6.0's structure and then applying 6.1's corrections on top.

Start by mapping what you have to the 800-53 control identifiers. Most agencies find they hold substantial evidence for the training and policy controls and almost nothing for the assessment and monitoring families, because those did not exist as a distinct obligation before.

That gap is the honest starting position for most agencies. Naming it is more useful than a maturity score that averages it away.