Built for Government-Grade Security

Yes, in the sense the phrase can be used. CJIS compliant software is a claim about controls rather than a certificate. The platform is aligned with the latest FBI CJIS Security Policy, with controls built on NIST SP 800-53 and independently audited. The CJIS Security Addendum, the document that underpins any CJIS compliance claim, is available on request.

It is worth being precise about language, because CJIS compliance is not a certification anyone can hand you. There is no CJIS certifying body issuing a badge. What exists is the CJIS Security Policy, a set of controls, and a vendor's ability to evidence that it meets them. Any vendor selling CJIS compliant software as CJIS certified is describing something that does not exist.

So the useful test of CJIS compliance is documentary rather than declarative. Ask for the Security Addendum, ask where data is hosted, ask which cryptographic modules are validated, and ask whether personnel are US based. Those four answers separate CJIS compliant software from marketing copy, and they are what your state CJIS Systems Officer will actually assess when reviewing CJIS compliance.

No, and it matters that the answer is direct. Essential Personnel is not itself FedRAMP authorized and does not hold a FedRAMP ATO.

The nuance that causes confusion is the hosting layer. The platform runs entirely in AWS GovCloud (US), which is itself FedRAMP High authorized as infrastructure. That is a genuine control inheritance and worth stating in a security review, but it is not the same as the application holding its own FedRAMP authorization, and any vendor that blurs the two is misleading you about what CJIS compliant software and FedRAMP each mean.

For most municipal and county agencies FedRAMP is not the applicable framework anyway. CJIS alignment and SOC 2 Type II are what state and local procurement typically asks for, whether the buyer is a law enforcement agency or a municipal HR team. If your jurisdiction genuinely requires FedRAMP, raise it early rather than late, because that is a scoping question rather than a paperwork one.

Entirely in AWS GovCloud (US), primary in us-gov-east-1 and replicated to us-gov-west-1. Infrastructure and personnel are US based, and no data or resources leave the United States.

AWS GovCloud is the isolated region built for US government workloads and sensitive data, with access restricted to vetted US persons. That is a meaningfully different posture from commercial regions, and it is the first thing to check when a vendor says government grade.

Environments are hardened with restricted network access and redundant systems, running high availability with a cross region replica. Ask any vendor to name their region. AWS GovCloud is a specific answer; hosted on AWS is not.

At rest using FIPS 140-3 validated cryptography, and in transit over TLS 1.2 and above using FIPS 140-3 validated ciphers. Key management is aligned with NIST SP 800-57.

The word doing the work there is validated. Plenty of products use strong algorithms without using a FIPS 140-3 validated module, and for CJIS purposes that distinction is the whole point. FIPS 140-3 is a validation of the cryptographic module itself rather than a claim about the algorithm.

If your review asks vendors about encryption, ask specifically whether the module is FIPS 140-3 validated rather than whether data is encrypted. Everyone answers yes to the second question.

Yes. Customer instances are fully isolated, without shared databases.

This is a bigger deal than it sounds in a security review. Most SaaS is multi tenant with logical separation, meaning your records and another agency's records sit in the same database distinguished by a tenant identifier. That is normal and usually fine, and it is also the thing a CJIS reviewer will probe hardest.

Fully isolated instances remove that question. It also changes the blast radius of a misconfiguration, which is the real world risk rather than the theoretical one.

SOC 2 Type II is maintained annually, with annual third party audits and internal security reviews, and the report is available on request.

The Type II part matters. A Type I report says controls were designed appropriately on a given date. A SOC 2 Type II report says an auditor tested that those controls actually operated over a period, usually twelve months. Vendors sometimes say SOC 2 without saying which, and the difference is substantial.

When you get the report, read the exceptions section rather than the cover page. A SOC 2 Type II with a couple of noted exceptions and clear remediation is more informative than a clean summary you never opened.

Through hierarchical role based access control enforcing least privilege, with administrators controlling exactly who can view and manage each type of information, plus administrative oversight and full auditability of access.

The hierarchical element is what makes this workable in a public safety agency. A flat permission model forces you to choose between giving a supervisor too much and giving them too little, and agencies end up over granting because under granting stops people working.

Specialist role permissions handle the sensitive categories, which is how wellness and critical incident data reaches designated staff without being visible to everyone with a login. That is a security control and a trust control at the same time, and the wellness data on the Safety and Wellness side depends on it, as does policy acknowledgement in Guidance.

Single sign on is supported via SAML and OIDC providers, and multi factor authentication meets AAL2 standards and is enforceable agency wide.

Both single sign on and multi factor authentication matter, for different reasons. Single sign on means deprovisioning actually works: when your identity provider disables an account, access ends everywhere rather than depending on someone remembering this system exists. For agencies with turnover that is the single most valuable security control available.

The AAL2 detail is worth noting because multi factor authentication is not one thing. AAL2 is the NIST assurance level CJIS expects for advanced authentication, so multi factor authentication that meets it is a specific claim rather than a generic one. Single sign on is an optional line item at $800 per year per agency, listed on the pricing page.

Continuous monitoring using Cloudflare WAF, CrowdStrike Falcon and Amazon GuardDuty, with automated alerting and centralized logging.

Naming the stack is unusual and useful. Most vendors answer this question with the phrase continuous monitoring and nothing else, which tells a reviewer nothing. A named web application firewall, endpoint detection and cloud threat detection layer is something your IT team can actually assess.

Centralized logging is the part that matters after an incident rather than during one. Detection tells you something happened; logging tells you what it touched.

Encrypted backups with cross region disaster recovery, running against the us-gov-west-1 replica, plus redundant systems within the primary environment.

Cross region is the meaningful qualifier. Backups held in the same region as production protect you against a database failure and not against a regional outage, and the difference only becomes visible on the day it matters.

Recovery objectives, retention periods and incident notification timelines are the numbers to pin down in contracting rather than take from a web page. Ask for RPO, RTO and the breach notification window in writing, and get them into the agreement.

The SOC 2 Type II report and the CJIS Security Addendum are both available on request, and a Trust Center publishes certifications, compliance reports and security practices.

For most agencies those two documents plus the hosting and encryption specifics answer a standard security compliance software questionnaire outright. Bring your own questionnaire rather than accepting a summary, because the gaps in a vendor's standard security compliance software packet are usually the interesting part. Every security compliance software vendor has a prepared answer set; your questionnaire is what finds the edges.

If your jurisdiction has its own supplemental requirements, put them on the table before procurement rather than during. Security compliance software reviews stall far more often on a missing document than on a missing control.

Infrastructure and personnel are US based, no data or resources leave the United States, and access is governed by least privilege with full auditability.

For a CJIS review the personnel question usually goes further than that, into background screening and signed addenda for anyone with potential access to criminal justice information. The CJIS Security Addendum is the document that covers it, and it is the piece your CJIS compliance review will ask for. It is available on request.

Put the specifics in writing during contracting rather than relying on any web page, including this one. Ask which roles can access agency data, under what circumstances, whether access is logged, and what screening those individuals have completed. Any vendor that cannot answer all four in writing has told you something.