If you're building software for law enforcement—whether it's a case management system, mobile app for officers, or crime analytics platform—you need to understand CJIS compliance. The FBI's Criminal Justice Information Services (CJIS) Security Policy is the baseline security standard for accessing criminal justice information in the United States.
After 16 years building law enforcement systems deployed across 15+ US jurisdictions, we've learned CJIS compliance the hard way—through audits, security assessments, and real-world deployments. This guide distills that experience into practical, technical guidance for software developers.
Disclaimer: This isn't legal advice (we're engineers, not lawyers), but it is battle-tested technical knowledge from building production law enforcement systems that pass CJIS audits.
Understanding CJIS Compliance
CJIS (Criminal Justice Information Services) is the FBI division that manages criminal justice data. CJI (Criminal Justice Information) is the actual data—anything related to criminal history, warrants, arrests, etc.
What Qualifies as CJI?
- Criminal history records
- Warrants and protection orders
- NCIC (National Crime Information Center) data
- Fingerprints and biometric data
- Case files and investigative data
Technical Requirements Breakdown
The CJIS Security Policy covers 13 core security areas. Here's what software developers need to implement:
Access Control
Identification & Authentication
Audit & Accountability
System Communications Protection
Configuration Management
Media Protection
Physical Protection
Incident Response
Security Awareness Training
Information Exchange
System Integrity
Personnel Security
Mobile Devices
Architecture for CJIS Systems
┌─────────────────────────────────────────┐
│ Law Enforcement Users │
└─────────────────────────────────────────┘
↓ MFA + VPN
┌─────────────────────────────────────────┐
│ Application Layer (Web/Mobile) │
│ - Role-based access control │
│ - Session timeout (30 min inactive) │
│ - Audit logging │
└─────────────────────────────────────────┘
↓ TLS 1.3
┌─────────────────────────────────────────┐
│ API Layer (Backend) │
│ - Authentication/Authorization │
│ - Business logic │
│ - Audit trail generation │
└─────────────────────────────────────────┘
↓ Encrypted connection
┌─────────────────────────────────────────┐
│ Database Layer │
│ - AES-256 encryption at rest │
│ - Row-level security │
│ - Backup encryption │
└─────────────────────────────────────────┘Data Encryption Requirements
Encryption Standards:
- Data at Rest: AES-256 encryption minimum
- Data in Transit: TLS 1.3 (minimum TLS 1.2)
- Backups: Must be encrypted with same standards
- Key Management: Secure key storage and rotation
// C# example: Encrypting sensitive data
using System.Security.Cryptography;
public class CJISEncryption
{
public static byte[] Encrypt(string plainText, byte[] key)
{
using (Aes aes = Aes.Create())
{
aes.KeySize = 256; // AES-256 for CJIS
aes.Key = key;
aes.GenerateIV();
using (ICryptoTransform encryptor = aes.CreateEncryptor())
{
byte[] plainBytes = Encoding.UTF8.GetBytes(plainText);
byte[] encrypted = encryptor.TransformFinalBlock(
plainBytes, 0, plainBytes.Length
);
// Prepend IV for later decryption
byte[] result = new byte[aes.IV.Length + encrypted.Length];
Buffer.BlockCopy(aes.IV, 0, result, 0, aes.IV.Length);
Buffer.BlockCopy(encrypted, 0, result, aes.IV.Length, encrypted.Length);
return result;
}
}
}
}Access Control & Authentication
CJIS mandates strict access controls to ensure only authorized personnel access CJI data.
Required Controls:
- Multi-Factor Authentication (MFA): Required for all remote access
- Role-Based Access Control (RBAC): Users only see data they're authorized to access
- Session Timeout: 30-minute inactive timeout mandatory
- Password Requirements: Minimum 12 characters, complexity rules, 90-day expiration
- Account Lockout: 5 failed login attempts triggers lockout
Audit Trail Implementation
Every action must be logged with tamper-proof audit trails. These logs are critical for CJIS audits and security investigations.
// Example audit log entry
{
"timestamp": "2026-01-05T14:32:18Z",
"user_id": "officer_12345",
"action": "READ",
"resource": "case_file_67890",
"ip_address": "10.0.1.45",
"result": "SUCCESS",
"mfa_verified": true,
"session_id": "abc-123-xyz"
}What to Log:
- User login/logout events
- Data access (who viewed what and when)
- Data modifications (create, update, delete)
- Failed access attempts
- System configuration changes
- Administrative actions
Retention: Minimum 12 months, recommend 24+ months
Mobile App Considerations
Mobile devices for law enforcement require additional security controls due to their portability and risk of loss or theft.
Required Features:
- Full device encryption
- MDM integration
- Remote wipe capability
- VPN for all data transmission
- Jailbreak/root detection
- Offline data encryption
Best Practices:
- Minimize cached data
- Auto-logout after inactivity
- Certificate pinning
- Biometric authentication
- Screen capture prevention
- Regular security updates
Common Pitfalls to Avoid
After 16 years and dozens of CJIS audits, here are the most common mistakes we've seen (and made):
Forgetting Session Timeouts
30-minute inactive timeout is mandatory. Many developers forget to implement or test this.
Insufficient Audit Logging
Logging authentication but not data access is a common gap. Log everything.
Weak Password Policies
CJIS requires 12+ characters with complexity. Enforce this programmatically.
No Encryption at Rest
Database encryption is non-negotiable. Don't assume the cloud provider handles it.
Missing MFA for Remote Access
All remote access must use MFA. VPN alone is not sufficient.
Poor Key Management
Encryption keys hardcoded or stored insecurely. Use KMS or similar.
No Background Checks
All developers with CJI access need FBI fingerprint-based background checks.
Inadequate Testing
Penetration testing and vulnerability scanning required before going live.
Real Implementation: CJIS-Compliant Case Management System
Client: Metropolitan police department with 2,000 officers
Timeline: 12 months (including security reviews)
Tech Stack: .NET, SQL Server, Azure Government Cloud
Security Measures:
- • AES-256 encryption at rest and in transit
- • MFA via Azure AD with FIDO2 hardware tokens
- • 15 different role-based access levels
- • Complete audit logging (24-month retention)
- • 30-minute session timeout enforced
- • Annual penetration testing
Result: Passed CJIS audit on first attempt, deployed to 15 precincts
Frequently Asked Questions
Do I need CJIS compliance for law enforcement software?
If your software accesses Criminal Justice Information (CJI)—NCIC data, warrants, criminal history—yes, absolutely. Even indirect access through APIs requires compliance.
Can I use cloud services?
Yes, but use government cloud (AWS GovCloud, Azure Government) or ensure your cloud provider signs a CJIS Security Addendum. Standard commercial cloud without addendum is not compliant.
What about contractors and developers?
All personnel with access to CJI need FBI fingerprint-based background checks and annual CJIS security awareness training. This includes developers, even if they only see test data.
How often is recertification needed?
Annual security awareness training for all personnel. Biennial CJIS Security Policy audits are typical. Some states require more frequent audits.
What's the penalty for non-compliance?
Loss of access to FBI systems (NCIC) and state criminal justice databases. For law enforcement agencies, this is catastrophic—officers can't run warrants, check criminal history, or access critical information.
