What CJIS is, in plain terms
The FBI Criminal Justice Information Services (CJIS) Division publishes the CJIS Security Policy — the set of controls that protects Criminal Justice Information (CJI) wherever it's stored, transmitted, or accessed. CJI includes NCIC query data, state criminal-history records, fingerprint-based background-check data, and anything the FBI defines as criminal justice information.
Any agency that touches CJI — through NCIC, through a state system that feeds NCIC, through a records management system that pulls CJI, through a CAD that connects to dispatch — has to meet the policy. That includes the smallest rural police department, the smallest sheriff's office, the municipality's records clerk who runs background checks.
The 13 policy areas
- Information exchange agreements. Written agreements with every entity exchanging CJI with the agency. The MSP contract needs the CJIS Security Addendum.
- Security awareness training. Annually for every person with CJI access — sworn officers, civilian dispatchers, records staff, IT support. Documented, with completion records.
- Incident response. Written plan, table-top exercise annually, breach-notification process to the state's CJIS Systems Officer (CSO).
- Audit and accountability. Audit logging on every CJI-accessing system, retained per §5.4 (often longer than agencies are configured for), reviewed.
- Access control. Least-privilege on every account, separation of duties where staffing allows, session timeouts, account-management procedures.
- Identification and authentication. Advanced authentication (CJIS-grade MFA) on every CJI-accessing account, with FIPS-validated authenticators. The detail here matters — some MFA products are not FIPS-validated.
- Configuration management. Documented baseline configurations, change control, vulnerability management.
- Media protection. Encryption of CJI on portable media; secure disposal of media that held CJI.
- Physical protection. CJI workstations in physically secured spaces, with documented access controls.
- System and communications protection. FIPS-validated encryption (AES) of CJI at rest and in transit. Network segmentation between CJI-accessing systems and the rest of the agency network.
- Formal audits. Triennial CJIS audit by the state CSO, plus internal annual audits.
- Personnel security. Fingerprint-based background check on everyone with CJI access — including IT support staff, including remote support technicians. Documented.
- Mobile devices. Specific controls on phones, tablets, and laptops that touch CJI — encryption, remote wipe, container separation.
One note on versions: the “13 policy areas” framing comes from CJIS Security Policy v5.9.x, which most agencies still know by heart. The FBI released v6.0 on December 27, 2024, which realigns the policy to NIST SP 800-53 Rev. 5 and reorganizes the content into 20 finer-grained policy areas. The underlying controls below are the same; v6.0 just splits them into more named areas (separating planning, acquisition, maintenance, and integrity monitoring). If your state has adopted v6.0, expect the audit to reference the 20-area structure, but the technical requirements an MSP handles — MFA, encryption, logging, segmentation, screening — carry straight over.
What an MSP can own (and what stays with the agency)
An MSP serving a CJIS environment owns the technical work: the FIPS-validated MFA, the encryption configuration, the audit-log infrastructure, the patching cadence, the EDR, the SOC, the segmented network, the media-encryption tooling. The MSP also signs the CJIS Security Addendum, completes the CJIS security awareness training annually, and submits MSP staff with CJI access for the agency's fingerprint-based background check.
The agency owns the policy work: designating the Local Agency Security Officer (LASO), maintaining the written policies, conducting the annual training for sworn and civilian staff, the physical-security work on the building, the personnel decisions, and the relationship with the state CJIS Systems Officer.
The audit, in practice
Triennial CJIS audits from the state CSO are the formal review. They typically ask for:
- The current Information Exchange Agreement and CJIS Security Addendum.
- Training completion records for every person with CJI access, current year.
- Fingerprint-based background check documentation for every person with CJI access, current.
- The MFA configuration evidence — product, FIPS validation status, coverage report.
- The encryption configuration evidence — at-rest and in-transit, FIPS validation status.
- The audit-log retention configuration and a sample of recent logs.
- The written incident-response plan plus the last table-top exercise.
- The configuration baseline documents and the change-management records.
- The patching SLA evidence.
- The network diagram showing CJI segmentation.
If those ten documents are organized in one folder and current, the audit is a one-meeting conversation. If they're not, it's several meetings of getting them in order.
The three most common audit findings
- MFA gaps. Either MFA isn't deployed on every CJI-accessing account, or it's deployed using a product that's not FIPS-validated. CJIS requires FIPS validation for advanced authenticators — specific Microsoft Authenticator configurations qualify, generic SMS often doesn't, and not every TOTP app qualifies.
- Audit-log retention. The retention configured on the system is shorter than CJIS Policy §5.4 requires. Often Windows event logs default to a small ring buffer that overwrites within weeks; CJIS expects retention measured in years.
- Personnel security on IT support staff. The agency has fingerprint-based background checks for sworn and civilian agency staff, but not for the MSP's remote-support technicians who can RDP into CJI workstations. CJIS expects the same screening for anyone with logical access.
Mobile devices and CJI
The mobile-device policy area (CJIS §5.13) has specific controls when an officer's phone or in-car laptop touches CJI. Required: agency-configured encryption, remote wipe capability, container or workspace separation of CJI from personal data, screen-lock requirements, and access controls. Personal devices with CJI access are generally not acceptable; either the agency issues the device or the BYOD policy meets every §5.13 requirement (rare).
How a Micro-IT engagement works for CJIS-scoped agencies
Municipal clients with a CJI-accessing department (police, sheriff, dispatch) get the standard managed stack with CJIS-specific configuration: FIPS-validated Microsoft Authenticator MFA on every CJI account, FIPS-validated encryption at rest and in transit, segmented network on the Ubiquiti / Unifi stack with documented VLAN structure, audit-log retention configured to CJIS requirements, and the SOC's incident-response runbook updated for CJIS breach-notification flow. The CJIS Security Addendum is signed on contract day. MSP staff with CJI access complete the agency's security awareness training and are submitted for fingerprint-based background checks. See the municipal and county government IT support page for the full vertical posture.
CJI and CHRI: what they are and who can touch them
Criminal Justice Information (CJI) is the broad category the CJIS Security Policy protects — biometric data, identity-history data, biographic data, property data, and case or incident-history data the FBI defines as criminal justice information. Criminal History Record Information (CHRI), sometimes called “rap-sheet” data, is a subset of CJI: the record of arrests, charges, and dispositions tied to an individual. Because CHRI is more sensitive, it carries tighter controls on access, use, and dissemination.
Access to and use of CJI and CHRI is for the administration of criminal justice and certain authorized non-criminal-justice purposes only — for example, running a query during an investigation, or a fingerprint-based background check for a position the law allows. It is restricted to authorized personnel who have completed security awareness training and passed a fingerprint-based background check. It is not for personal use, not for commercial use, and not for sharing outside the receiving agency or other authorized entities. Looking up a neighbor, a date, or a family member is misuse, and misuse is auditable and sanctionable.
The MFA requirement and its deadline
CJIS calls multi-factor authentication “advanced authentication.” Under the Identification and Authentication policy area, every account that can access CJI has to authenticate with two or more different factors — something you know (a PIN or password), something you have (a token, security key, or authenticator app), or something you are (a fingerprint or face scan). A password alone does not meet the requirement.
The hard date is October 1, 2024. As of that date, advanced authentication became a sanctionable, auditable requirement (CJIS Security Policy v5.9.x, §5.6.2.2). An agency without acceptable MFA on every CJI-accessing account can now be cited at audit and, in some states, face denial of access to FBI CJIS resources. The practical work for agencies now: confirm MFA is deployed on every account that touches CJI — including remote-support and admin accounts — and confirm the authenticators meet the FIPS-validation detail, because some common MFA products and generic SMS codes do not qualify.
Does CJIS compliance apply in the cloud?
Yes. CJI in a cloud service is still CJI, and the policy follows the data. The common question — “is AWS CJIS compliant?” — has a precise answer: the FBI does not certify cloud providers. There is no FBI stamp that makes a platform “CJIS certified.” What providers like AWS GovCloud (US) and Microsoft Azure Government do is build environments capable of meeting the policy and sign the CJIS Security Addendum with the state, which puts their personnel through fingerprint-based screening and binds them to the controls.
That leaves a shared-responsibility model. The provider secures the infrastructure; the agency is still responsible for how CJI is configured, encrypted, access-controlled, and logged inside that environment — and for proving each control at audit. Choosing GovCloud or Azure Government does not transfer compliance; it makes compliance achievable. The agency, and its MSP, still own the configuration and the evidence.
