The FBI Criminal Justice Information Services Security Policy is the most technically demanding compliance framework most software engineers will encounter. It is also the least well-documented from an engineering perspective — most available guidance is written for policy officers, not architects and developers. This article covers what the CJIS Security Policy actually requires technically for cloud-deployed systems, the specific architectural decisions it constrains, and where teams consistently make mistakes that create audit findings.
What CJIS Protects and Who It Applies To CJIS controls access to Criminal Justice Information — a defined category that includes criminal history records, biometric data, identity data, and the outcomes of criminal justice processes. Any software system that stores, processes, transmits, or provides access to CJI is subject to the CJIS Security Policy regardless of whether the system is operated by a law enforcement agency directly or a technology vendor on their behalf. This vendor applicability is frequently misunderstood. If you are building software for a police department, sheriff's office, or court system that handles CJI, your system and your team are subject to CJIS requirements — not just your government client. This includes your cloud infrastructure, your development environment if it handles real CJI data, and your personnel who have access to CJI.
The CJIS Cloud Challenge CJIS was written before cloud computing existed in its current form. The Security Policy has been updated to accommodate cloud deployments, but the updates create specific constraints that differ from how most cloud-native systems are designed. The core CJIS cloud requirement: CJI must be encrypted when stored in the cloud, the government agency must retain control of the encryption keys, and the cloud provider must not have access to the plaintext CJI. This customer-controlled encryption requirement is more stringent than the default configuration of most cloud services and rules out several common cloud architecture patterns.
Encryption Requirements CJIS requires Advanced Encryption Standard with a minimum key length of 256 bits for data at rest and in transit. AES-256 is the baseline — not a choice. For cloud deployments, this maps to: S3 server-side encryption with customer-managed KMS keys, RDS encryption using customer-managed KMS keys, EBS volume encryption for any EC2 instances handling CJI, and TLS 1.2 or higher for all data in transit with specific cipher suite requirements. The customer-managed key requirement has operational implications. You are responsible for key rotation — CJIS requires rotation at least every two years, though annually is better practice. You are responsible for key access policies — the policy must restrict key usage to authorized identities and log every use. And you are responsible for key backup and recovery — losing access to your KMS key means losing access to your encrypted CJI data. AWS Key Management Service with customer-managed keys satisfies CJIS encryption requirements when configured correctly. AWS CloudHSM is an option for agencies with requirements for FIPS 140-2 Level 3 validated key storage, which some state CJIS policies require beyond the federal baseline.
Data Residency CJI must remain within the United States. For AWS deployments, this means: all AWS regions used must be US regions, no data replication to non-US regions even for disaster recovery, CloudFront distributions must be configured to restrict edge locations to US points of presence, and third-party services integrated into your application must also store and process data within the US. The third-party service requirement is where modern architectures create compliance risk. If your CJIS application uses a third-party monitoring service, error tracking platform, or analytics tool that stores data outside the US — even temporarily — you have a potential CJIS violation. Audit every data flow out of your application before deployment.
Audit Logging Requirements CJIS requires comprehensive audit logging with specific retention and protection requirements. Every access to CJI must generate an audit record containing: the identity of the user who accessed the data, the date and time of access, the type of action performed, and the data or record accessed. Audit logs must be retained for a minimum of one year with three years recommended. Audit logs must be protected against modification and deletion — the same object lock approach recommended for HIPAA applies here. And audit log review must occur at regular intervals — the Security Policy requires log review at least every seven days for interactive access and at least every 24 hours for automated system access. The 24-hour automated review requirement surprises most teams. It means your system must have automated log analysis that runs at least daily and alerts on anomalies. A SIEM or log analysis pipeline is not optional for CJIS compliance — it is a policy requirement.
Personnel Security Requirements CJIS personnel screening requirements apply to anyone with access to CJI — including vendor employees. For cloud-deployed systems, this means: developers who access production systems containing real CJI must complete a fingerprint-based background check through the FBI CJIS Division, operations personnel with production access have the same requirement, and cloud provider employees must be covered either by the CSP's CJIS compliance program or excluded from access to your CJI through technical controls. AWS operates a CJIS compliance program that covers AWS personnel who could potentially access customer data. The terms of this program and the documentation you need for your CJIS audit are available through the AWS artifact portal under the CJIS section. For your own team, establish a clear inventory of who has production access to systems containing CJI and ensure each person has completed the required background check before access is granted. Many audit findings relate to access granted before background checks were completed.
Network Security Requirements CJIS requires that systems handling CJI be protected by a network firewall, that CJI not be accessible from the public internet without an approved VPN or encrypted tunnel, and that wireless access to CJI-handling systems meet specific encryption and authentication requirements. For cloud deployments: CJI systems must run in a private VPC with no public IP addresses. Access for authorized users must go through a VPN or AWS Client VPN with certificate-based authentication. Security groups must follow least-privilege principles — only necessary ports open to necessary source addresses. AWS WAF should be deployed in front of any web-facing components even within the private network boundary. The no-public-internet requirement creates design constraints for systems that need to be accessible to multiple agencies or across geographic areas. The approved solution is a managed VPN infrastructure or AWS Direct Connect for agency-to-agency connectivity, not public internet access with application-layer authentication.
Common Audit Findings After reviewing multiple CJIS-audited systems, certain findings appear consistently. Audit logging gaps — particularly missing audit records for read access to CJI records, where teams implement logging for write operations but not reads. Encryption key management failures — customer-managed KMS keys configured but with overly permissive key policies that allow AWS service roles broader access than necessary. Personnel access reviews not performed — CJIS requires periodic review of who has access to CJI systems; many organizations implement the initial access controls but do not perform the required ongoing reviews. Third-party data flows — monitoring and analytics tools sending data outside approved boundaries discovered during audit.
What CJIS-Compliant Architecture Looks Like A CJIS-compliant cloud deployment uses: US-only AWS regions with data residency controls documented, customer-managed KMS keys with restrictive key policies and annual rotation, all CJI systems in private VPCs with no public internet access, VPN or Direct Connect for user and agency access, comprehensive audit logging with object lock protection and automated daily review, personnel background checks documented for all individuals with production access, and a documented System Security Plan that maps each CJIS Security Policy control to the specific technical implementation in your system. The System Security Plan is the document your auditor actually reviews. It must demonstrate that you have read and understood each applicable CJIS control and implemented a specific technical or administrative measure to satisfy it. Building the SSP alongside the system — not after — is the practice that distinguishes teams that pass audits from teams that spend months remediating findings.