10 Real-World Government Cloud Security Patterns

Government cloud security is often discussed at the policy level (FedRAMP, FISMA, CJIS) without much attention to what the patterns actually look like in practice. This post is about the practical side — the specific controls and architectural decisions that make government cloud deployments work in the real world. Ten patterns, drawn from state and local government deployments we've worked on, that a government IT team can apply without waiting for federal guidance.

1. Choose the Right Cloud Region From the Start

The first decision is which cloud region to use. "Azure" isn't an answer; "Azure US Government" is. The difference matters for FedRAMP scope, CJIS eligibility, and data residency.

• Azure Government: FedRAMP High, DoD IL4/IL5 depending on the specific service. Physically separate from Azure Commercial. Microsoft personnel supporting Government are US citizens with background checks.
• AWS GovCloud (US): Same idea. FedRAMP High, ITAR-compliant, separate from commercial AWS.
• Google Cloud for Government: Growing footprint, FedRAMP High in specific regions.
• Azure Commercial, AWS Commercial: Fine for most state and local workloads that aren't under CJIS or FedRAMP-restricted. Cheaper and more feature-rich than the government regions.

The trap: Deploying into commercial cloud and then discovering you need to migrate to a government region because of data classification. Get the data classification right before you deploy.

2. CJIS Compliance as a Continuous Control Story

Criminal Justice Information Services (CJIS) data has strict requirements: MFA, encryption, audit logging, personnel background checks, physical security. The cloud story here has gotten better — Microsoft, AWS, and several specialty providers support CJIS workloads — but the compliance has to be continuous, not annual.

The controls we put in place:

• CJIS-eligible cloud region (Azure Government, AWS GovCloud, or specialty vendors like Mark43)
• CJIS Security Addendum signed with the vendor
• MFA enforced on every user account touching CJIS data
• FIPS 140-2 Level 3 HSM-backed encryption for CJIS data at rest
• Full audit logging with CJIS-required retention
• Annual security awareness training for all personnel with CJIS access
• Background checks documented and current

Common failure: A user who had CJIS access in a previous role retains it after transferring. Automated quarterly access reviews catch this.

3. FedRAMP Inheritance, Not Duplication

If your agency has systems hosted on a FedRAMP-authorized cloud service, you inherit the controls the CSP has already implemented. Don't duplicate them.

What you inherit: Physical security, platform patching, hypervisor security, most of the infrastructure controls.

What you still own: Identity and access, configuration of the services you deploy, application security, data classification, user training, incident response procedures that involve your users.

The SSP (System Security Plan) should document the inheritance boundary clearly. Auditors find this quickly.

4. Landing Zone Designed for FISMA Boundaries

A FISMA boundary is the scope of a system security plan. It defines what's in and what's out. Cloud landing zones for government should be structured so that boundaries are enforced by account/subscription structure, not by hope.

Typical structure:

• Separate account or subscription per FISMA boundary
• Shared services account for cross-boundary services (identity, logging, DNS)
• No direct peering between boundaries without explicit approval
• IAM boundaries enforced at the organization level

This makes the SSP documentation simpler and the audit evidence clearer.

5. Continuous ATO via Policy as Code

The traditional ATO (Authority to Operate) process is a binder and a point-in-time review. Modern government cloud aims for continuous ATO, where controls are enforced continuously by policy as code and compliance evidence is automated.

Tools that support it:

• Azure Policy and Defender for Cloud with NIST 800-53 initiative definitions
• AWS Config with Security Hub and the NIST/FedRAMP packs
• OpenSCAP for OS-level benchmarks
• Prowler or ScoutSuite for third-party assessment
• GRC tools like Xacta, RegScale, or eMASS for the documentation side

Every control has an automated check. Failures generate findings. Findings are remediated or accepted with risk acceptance documentation. The evidence for an ATO review is the current state of the automated checks, not a manual assessment.

6. Supply Chain Risk Management Takes Executive Orders Seriously

EO 14028 and subsequent federal guidance has pushed SBOM (Software Bill of Materials) requirements and secure software supply chain practices into scope for government. Even at the state and local level, procurement is catching up.

What to require from vendors:

• SBOMs for all deployed software (SPDX or CycloneDX format)
• Signed artifacts where possible (sigstore, GPG, Authenticode)
• Documented build provenance
• Security patching SLAs in the contract

7. Zero Trust as Implementation, Not Slogan

Zero trust is mandated by federal executive order for federal agencies. State and local are following. The framing that matters: no implicit trust based on network location. Every request is authenticated and authorized, regardless of where it came from.

Components we implement:

• Strong identity with MFA
• Device health verification via MDM
• Application-level authorization, not network-level
• Micro-segmentation within cloud networks
• Continuous monitoring for anomalies

This is a multi-year program, not a switch to flip. Start with identity and MFA; work toward full zero trust over time.

8. Secure SCADA and OT Connectivity

State and local governments run utilities, water treatment, transportation systems with OT/SCADA controls. These systems are often air-gapped or should be. Cloud connectivity to OT environments has to be one-way where possible.

Patterns:

• Data diodes or unidirectional gateways for SCADA telemetry
• No inbound control from the cloud to operational equipment
• Separate networks for OT with strict ACLs
• OT security monitoring integrated with central SIEM

Colonial Pipeline, Oldsmar water — these incidents have raised the stakes. State and local OT security is under scrutiny.

9. Incident Response Aligned With CISA

CISA (Cybersecurity and Infrastructure Security Agency) provides threat intelligence and incident response support for state and local government. Alignment with their playbooks accelerates response when things go wrong.

What this looks like:

• Registered with CISA for threat intelligence sharing
• Known CISA contacts and reporting procedures in your incident response plan
• Tabletop exercises that include CISA scenarios
• Integration of CISA KEV (Known Exploited Vulnerabilities) into patching priorities

10. Public Records and Transparency Don't Go Away

Governments are subject to public records laws — FOIA at the federal level, state equivalents elsewhere. Cloud data is subject to the same laws as data on-prem.

What we document:

• Where all government data lives
• How requests are handled
• Which vendors have access and under what terms
• Retention schedules aligned to state records laws

This is not a security control exactly, but it's a compliance requirement that cloud adoption can quietly break if ignored.

What We'd Actually Do

For a state or local government agency starting cloud work:

1. Data classification first. Know what data you have and what rules apply.
2. Pick the right cloud region based on the classification, not convenience.
3. Landing zone with FISMA boundaries before workloads.
4. Policy as code for NIST 800-53 controls from day one.
5. MFA and zero trust identity before anything else.
6. SIEM with CISA integration for continuous monitoring.
7. Quarterly access reviews automated from IAM.
8. Annual tabletops including CISA scenarios.

Three Takeaways

1. Region choice is the first compliance decision. Get it right before deploying.
2. Continuous ATO via policy as code is the modern model. Binders and annual reviews are obsolete.
3. Zero trust is a multi-year implementation. Start with identity, work outward.