CJIS compliance in AWS, Azure and Microsoft 365

The shared responsibility model for CJI

Every major cloud provider describes security as shared. The provider secures the data centers, the hardware, the hypervisor and the core services. The customer secures what runs on top: accounts, network rules, operating systems in virtual machines, application code, data and the people who access it.

For CJI, this split matters because the CJIS Security Policy applies to the whole chain. A data center with excellent physical security does not help if an administrator account has no multi-factor authentication, or if a storage bucket with CJI is reachable from the internet. The audit looks at your system, and your system includes your choices in the cloud console.

The exact line moves with the service you use. With virtual machines you own the operating system and its patches. With a managed database the provider patches the engine, but you still own access, encryption settings and logging. With a SaaS suite like Microsoft 365, the provider runs the application, and you own tenant configuration, identities, sharing settings and data handling.

Government cloud offerings at a general level

Both large providers run separate environments for US government customers. They are built to meet federal requirements and to restrict who on the provider side can operate them. The names you will hear most often are:

• AWS GovCloud (US), an isolated set of AWS regions for US government workloads and regulated data.
• Azure Government, a separate Microsoft cloud for US government agencies and their partners.
• Microsoft 365 GCC, the government community cloud version of Microsoft 365 for state, local and tribal government.
• Microsoft 365 GCC High, a more restricted version aimed at stricter federal and defense requirements.

These environments often matter for CJI because they can limit provider personnel to screened US persons and support the contractual commitments a state may require. Commercial regions and commercial Microsoft 365 tenants are a different case, and whether they can hold CJI depends on the provider's arrangement with your state and on your own controls.

Product names, eligibility rules and features change. Check the provider's current documentation for the exact service you plan to use.

Provider arrangements with states vary

The CJIS Security Policy expects agreements and screening for anyone with unescorted or logical access to CJI, and that includes cloud provider personnel where they could reach it. Providers handle this through agreements with state CSAs, such as signing the CJIS Security Addendum with a state and supporting fingerprint-based checks of relevant staff.

These arrangements are made state by state. One state may have an agreement covering a given provider and service, another may not, and the scope can differ between services from the same provider. Arrangements also change as providers add services and states update their programs.

Do not assume that because a provider works with one state, your state is covered. Ask two questions and keep the answers in writing:

• Your CSA: does our state have an agreement with this provider, and which services and environments does it cover.
• The provider: which services are in scope for CJI in our state, and what documentation can we give the auditor.

Identity and multi-factor authentication stay with you

The provider gives you identity tools. Using them correctly is your job. For CJI this means:

• Unique accounts for every person, no shared admin logins.
• Multi-factor authentication for every account that can access CJI, including administrators and support staff.
• Password rules in line with NIST SP 800-63B style guidance: minimum length, checks against compromised password lists and no forced periodic change unless compromise is suspected.
• Least privilege for roles, with separate accounts or elevation for administrative tasks.
• Prompt removal of access when a person leaves or changes role.

If you use single sign-on, the identity provider becomes part of your CJIS scope. Its policies, logs and administrators need the same care as the cloud account itself.

Encryption and key management

CJI in transit and at rest outside a physically secure location must be encrypted with FIPS 140-2 or FIPS 140-3 validated modules. Cloud providers offer validated endpoints and encryption services, but you choose whether and how to use them.

• Turn on encryption at rest for every storage service, database and backup that can hold CJI.
• Use the provider's FIPS validated endpoints where the policy and your CSA expect them.
• Decide who controls the keys, and restrict and log key administration.
• Encrypt traffic between your users, your applications and any agency network.

Keep a record of which modules and settings you use. An auditor may ask for the validation certificate numbers or the provider documentation that shows them.

Logging, monitoring and incident response

Cloud platforms log a lot by default, but default retention is often short and nobody reads the logs unless someone is assigned to. The policy expects audit logs to be kept and reviewed.

• Enable activity and access logs for accounts, storage, databases and the identity provider.
• Send logs to a central place with retention that meets your state's requirements.
• Assign a person and a schedule to review logs, and record that the review happened.
• Document your incident response plan, including how you would report an incident affecting CJI to the agency and the CSA.

The provider will handle incidents in its own infrastructure, but it will not report your misconfiguration to your agency for you.

Personnel and vendor staff

The people on your side still need everything the policy asks for. Staff with unescorted physical or logical access to CJI need a state and national fingerprint-based record check before access, security awareness training at the right level and, for contractors, the CJIS Security Addendum certification page. That includes your cloud engineers, your support team and any managed service provider with console access.

This is where many vendors fall short. The cloud provider's screening covers the provider's staff, not yours.

Managed service providers deserve a separate look. If an outside firm manages your cloud tenant, your identity provider or your endpoints, its administrators have logical access, and the same screening, training and agreements apply to them. Ask the firm for its staff list, confirm each person's status with your agency or CSA and remove access for anyone who is not cleared.

Common mistakes in cloud environments

The same issues show up again and again when a team moves CJI into a cloud or a SaaS suite:

• Building in a commercial region or tenant because it was faster, then learning later that the state arrangement covers only the government environment.
• Treating the provider's compliance documents as proof for the whole system, with no evidence for the controls the customer owns.
• Leaving a test or staging environment with copies of real CJI and weaker controls than production.
• Turning on multi-factor authentication for users but not for break-glass or service administrator accounts.
• Sharing files with CJI through links that anyone in the organization, or anyone with the link, can open.
• Keeping logs for the default period only, which can be much shorter than what the state expects.

Each of these is easier to prevent at design time than to fix after an audit finding.

A checklist for CJI in the cloud

• Confirm with your CSA and the provider which environment and services are in scope for CJI in your state.
• Document the shared responsibility split for each service you use.
• Enforce unique accounts and multi-factor authentication for every person with access to CJI.
• Enable encryption at rest and in transit with FIPS validated modules, and record the settings.
• Restrict and log key management.
• Centralize logs, set retention and record each review.
• Keep background check, training and Security Addendum records for every person with access.
• Write and test an incident response plan that covers agency and CSA reporting.
• Keep evidence for each item: screenshots, exported settings, signed agreements.

How Cjis keeps your cloud evidence in order

Cjis turns each requirement into a task with an owner, status, due date and linked evidence. You attach configuration screenshots, exported settings and signed agreements to the control they prove, note which responsibilities belong to the provider and which to you, and keep personnel records next to the controls. The agency report exports it as one PDF or a read-only link per agency.

Cjis never integrates with your cloud console and never stores CJI. It holds compliance records and evidence that contains no CJI. Cjis is an independent tool, not affiliated with the FBI, the CJIS Division or any cloud provider, and not legal advice.