When encryption is required
The key idea is the physically secure location. Inside a controlled area, such as a records room or a data center with access control and visitor logs, the policy relies on physical protection. Once CJI travels outside that boundary or rests on a device or system outside it, encryption is required. That covers a lot of everyday cases: a mobile data terminal in a patrol car, a laptop at home, a cloud environment, a backup sent off site, a link between two buildings over a public network and the connection between a vendor and its customer agency.
- CJI in transit over any network outside a physically secure location.
- CJI at rest on devices, storage or systems outside a physically secure location.
- Backups and removable media that leave the secure area.
- Remote access and mobile connections to CJI systems.
FIPS 140 validated modules versus approved algorithms
This is where many organizations get caught. The policy asks for encryption performed by a cryptographic module that has been validated under FIPS 140-2 or FIPS 140-3 through the federal Cryptographic Module Validation Program. Using an approved algorithm, such as AES with a suitable key length, is not the same thing. A product can use AES and still run it in a module that was never validated, or in a configuration outside the validated mode. Auditors may ask which module performs the encryption, which validation certificate covers it and whether the module runs in its approved mode. FIPS 140-2 validations are being retired over time in favor of FIPS 140-3, so check the status of each certificate you rely on.
- A validated module has a certificate number you can look up.
- An approved algorithm alone does not prove validation.
- The module must run in the validated mode and version.
- Track certificate status as older validations are retired.
Key management basics
Strong encryption is only as good as the handling of its keys. The policy expects keys to be protected, limited to the people and systems that need them and managed through their life cycle. Write down who can create, use, rotate and destroy keys, where they are stored and how access to them is logged.
- Store keys separately from the data they protect.
- Limit key access to named roles and log every use.
- Rotate keys on a defined schedule and after suspected exposure.
- Destroy retired keys in a way you can document.
Encryption in the cloud and on mobile devices
Cloud environments, including government regions such as AWS GovCloud and Azure Government, offer encryption services that use validated modules, but you still need to turn them on, configure them correctly and decide who holds the keys. Record which services store or move CJI, which encryption setting each uses and which module certificate covers it. Mobile devices need full device encryption with a validated module, encrypted connections back to agency systems and the ability to wipe a lost device. Mobile device management makes this enforceable and gives you the configuration records auditors ask for. For vendors, our page on CJIS compliant software explains how hosting choices fit into agency review.
- Enable and configure encryption on every cloud service that touches CJI.
- Decide and document who manages the keys.
- Encrypt mobile devices and their connections, and keep remote wipe ready.
How Cjis records your encryption evidence
Cjis keeps encryption proof next to the controls it supports. The requirements checklist splits encryption into items such as CJI in transit, CJI at rest, backups, mobile devices and key management, each with an owner, a due date and a priority. In the evidence locker you attach the module validation certificate numbers, configuration exports, cloud encryption settings and mobile device management reports for each item. When a certificate status changes or a configuration is updated, you replace the evidence and the history stays. The mobile device and configuration management CJIS policy templates cover the written side. The readiness assessment asks about FIPS 140 validated encryption in transit and at rest, so a gap shows in your score early, and the agency report lists the evidence for your CSA or customer agency. To see how that evidence is used, read our CJIS audit guide, and for the other controls around encryption, the CJIS compliance checklist. Cjis is an independent compliance tool, not affiliated with, endorsed by or certified by the FBI or the CJIS Division, and it is not legal advice. Cjis never stores CJI, only evidence that contains no CJI.
- Encryption items in the checklist with owners and dates.
- Certificate numbers and configuration exports in the evidence locker.
- Encryption evidence included in the agency report.
Is AES encryption enough for CJIS?
Not by itself. The encryption must be performed by a module validated under FIPS 140-2 or FIPS 140-3 and running in its validated mode.
Do we need to encrypt CJI inside our secure facility?
Inside a physically secure location the policy relies on physical controls, but many organizations encrypt anyway. Confirm your state rules with your CSA.
How do we prove a module is validated?
Record the validation certificate number for each module and keep configuration evidence showing it runs in the validated mode.