Federal Migration Guide: Snowflake to Azure Government¶

Status: Authored 2026-04-30 Audience: CISO, AO (Authorizing Official), ISSM, compliance officers, acquisition leads, federal program managers Scope: FedRAMP Moderate-to-High gap analysis, Snowflake Gov region limitations, IL coverage gaps, procurement path, ATO strategy

1. The compliance forcing function¶

This document exists because of a specific compliance reality: Snowflake Government holds FedRAMP Moderate authorization as of April 2026. For federal systems that require FedRAMP High, DoD IL4/IL5, or certain CMMC 2.0 Level 2 controls, Snowflake creates a compliance ceiling that cannot be resolved by customer-side controls alone.

This is not a marketing argument. It is a factual gap in platform authorization that either blocks your ATO or requires compensating controls that are more expensive than migration.

2. FedRAMP Moderate vs High: what is the actual gap¶

Authorization levels¶

What FedRAMP High adds¶

FedRAMP High includes 311 controls beyond Moderate, covering:

What this means for your ATO¶

If your system's security categorization is High (per FIPS 199), your ATO package must demonstrate compliance with all 421 FedRAMP High controls. When Snowflake provides 110 (Moderate), you must either:

1. Accept risk -- Your AO accepts a platform that does not meet the required authorization level. Most federal AOs will not sign this.
2. Implement compensating controls -- You build and evidence 311 additional controls yourself, on top of Snowflake. This is technically possible but costs more than migration.
3. Use a different platform -- Migrate to a FedRAMP High-authorized platform. Azure Government inherits FedRAMP High, and csa-inabox maps controls to implementation.

csa-inabox control coverage¶

csa-inabox provides:

• NIST 800-53 Rev 5 mappings -- csa_platform/csa_platform/governance/compliance/nist-800-53-rev5.yaml
• Control narratives -- docs/compliance/nist-800-53-rev5.md
• Bicep modules with control evidence -- Each infrastructure module references its control IDs
• Tamper-evident audit chain (CSA-0016) -- Exceeds AU (Audit) family requirements
• Purview classification automation -- Addresses RA (Risk Assessment) and SI (System Information) controls

3. DoD Impact Level coverage¶

IL4 (Controlled Unclassified Information)¶

IL5 (Higher sensitivity CUI + mission-critical)¶

IL6 (Classified)¶

Neither Snowflake nor csa-inabox addresses IL6. This requires Top Secret cloud infrastructure (Azure Top Secret or AWS Secret Region).

4. Snowflake Gov region limitations¶

As of April 2026, Snowflake Government operates in a single region (us-gov-west-1) with these limitations:

Key observation: Many of the capabilities Snowflake markets (AI, streaming, containers, clean rooms) are either not available or limited in the Gov region. You are paying for a commercial feature set but receiving a subset.

5. CMMC 2.0 Level 2 considerations¶

For DIB primes and subcontractors¶

CMMC 2.0 Level 2 requires compliance with all 110 practices in NIST SP 800-171 Rev 2. The data platform must support these practices.

csa-inabox documents CMMC mappings in csa_platform/csa_platform/governance/compliance/cmmc-2.0-l2.yaml with narratives in docs/compliance/cmmc-2.0-l2.md.

6. HIPAA considerations¶

For HHS, IHS, tribal health, and healthcare-adjacent agencies:

See examples/tribal-health/ for the IHS / tribal health worked implementation and csa_platform/csa_platform/governance/compliance/hipaa-security-rule.yaml for the control mapping.

7. Procurement path¶

Federal acquisition vehicles¶

Cost comparison for procurement¶

Procurement timeline¶

Tip: If your agency has an existing Azure ELA, procurement is often a task order modification rather than a new solicitation.

8. ATO strategy¶

Approach A: Inherit Azure Gov authorization¶

The fastest path to ATO:

1. Inherit Azure Government's FedRAMP High authorization as the cloud service provider (CSP) authorization
2. Document customer-responsible controls in your System Security Plan (SSP)
3. Implement csa-inabox control mappings (NIST 800-53 YAML + Bicep modules)
4. Evidence controls using Azure Monitor, Purview audit, tamper-evident chain
5. Assess with your 3PAO or agency security team

Timeline: 8-16 weeks for the ATO documentation (can run in parallel with migration Phases 1-3)

Approach B: Reciprocity from existing Azure ATO¶

If your agency already has an ATO for an Azure Government system:

1. Leverage the existing Azure ATO as a reciprocal authorization
2. Document the data platform as an extension of the existing system
3. Evidence the additional controls specific to the data platform
4. Brief the AO on the incremental risk

Timeline: 4-8 weeks (reduced scope because Azure is already authorized)

Approach C: Continuous ATO (cATO)¶

For agencies with a continuous ATO program:

1. Add the data platform to the continuous monitoring scope
2. Configure automated control testing (Azure Policy, Purview scans)
3. Feed results into your cATO dashboard
4. Maintain ongoing authorization through automated evidence

csa-inabox's compliance-as-code approach (YAML + Bicep + automated scanning) is well-suited to cATO programs.

ATO documentation deliverables¶

9. Data residency and sovereignty¶

Snowflake Gov data residency¶

• Data resides in Snowflake's Gov region (us-gov-west-1, typically hosted on AWS GovCloud)
• Snowflake manages the infrastructure; customer has limited visibility into physical location
• Cross-region replication within Gov is not available (single region)

Azure Gov data residency¶

• Data resides in Azure Government datacenters (physically separate from commercial Azure)
• Azure Government is a separate cloud instance, not a logical partition
• Multiple Azure Gov regions available (US Gov Virginia, US Gov Texas, US Gov Arizona, etc.)
• Cross-region replication available for disaster recovery
• Tenant-binding ensures data cannot leave the Azure Gov boundary

ITAR compliance¶

Both Snowflake Gov and Azure Gov support ITAR data residency. Azure Gov's advantage is:

• Physically separate infrastructure (not shared with commercial)
• Cleared operations personnel in Azure Gov datacenters
• Multiple regions for DR without leaving the ITAR boundary

10. Risk register¶

Document these risks in your migration risk register:

11. Migration-specific compliance steps¶

During migration (parallel-run phase)¶

• Maintain Snowflake ATO documentation until decommission
• Add Azure Gov to your system boundary in the SSP
• Document dual-platform architecture as a transition state
• Ensure audit logging is active on both platforms
• Verify data classifications are consistent across platforms

Post-migration¶

• Update SSP to remove Snowflake from system boundary
• Archive Snowflake audit logs (retain per your retention policy)
• Update POA&M to close Snowflake-related findings
• Update continuous monitoring plan to reference Azure-only controls
• Brief the AO on the completed migration and reduced risk posture

Related documents¶

• Why Azure over Snowflake -- executive white paper
• Security Migration -- technical security controls migration
• TCO Analysis -- cost justification for procurement
• Master playbook -- Section 6 for compliance considerations
• docs/compliance/nist-800-53-rev5.md -- NIST 800-53 control narratives
• docs/compliance/cmmc-2.0-l2.md -- CMMC Level 2 practice mappings
• docs/compliance/hipaa-security-rule.md -- HIPAA safeguard mappings
• docs/GOV_SERVICE_MATRIX.md -- Azure Gov service availability matrix

Last updated: 2026-04-30 Maintainers: CSA-in-a-Box core team