NIST 800-171 Cloud Compliance: The Practical Guide for AWS, Azure, and GCP

Why Cloud Changes Everything About NIST 800-171 Compliance

NIST SP 800-171 was written for on-premises environments. The 110 controls reference concepts like "organizational systems," "system boundaries," and "physical access" — language that maps cleanly to traditional data centers but requires significant interpretation for cloud environments.

Defense contractors running workloads in AWS GovCloud, Azure Government, or Google Cloud face a translation problem: how do you implement controls designed for physical servers when your infrastructure is API-driven, ephemeral, and shared?

The answer matters because C3PAO assessors will evaluate your cloud configurations directly. They will pull IAM policies, review security group rules, examine encryption settings, and test network segmentation. Documentation that says "we encrypt CUI at rest" means nothing if your S3 buckets have default encryption disabled.

This guide maps the most critical NIST 800-171 control families to specific cloud configurations across AWS, Azure, and GCP.

Access Control in Cloud Environments

Access Control (AC) contains 22 controls — the largest family. In cloud environments, this translates to three primary concerns:

IAM Policy Management

AC.L2-3.1.1 (Authorized Access) and AC.L2-3.1.5 (Least Privilege) require that every identity — user, service account, and role — has precisely the permissions needed and no more.

In practice, this means:

AWS: IAM policies should use explicit deny statements, avoid * resource wildcards, and leverage AWS Organizations SCPs to enforce guardrails. Every role should be reviewed quarterly using IAM Access Analyzer.

Azure: Use Azure RBAC with custom role definitions scoped to specific resource groups. Avoid the "Contributor" built-in role for CUI workloads — it grants far more access than most users need. Enable Privileged Identity Management (PIM) for just-in-time access.

GCP: Implement custom IAM roles at the project level. Use IAM Conditions to restrict access based on resource attributes. Leverage Organization Policy constraints to prevent overly permissive IAM bindings.

Multi-Factor Authentication

AC.L2-3.1.7 and IA.L2-3.5.3 require MFA for privileged and remote access.

All three cloud providers support MFA, but the implementation details matter:

• AWS: Enforce MFA via IAM policies with aws:MultiFactorAuthPresent condition keys
• Azure: Conditional Access policies with MFA requirements for all admin roles
• GCP: Enforce 2-Step Verification at the organization level via Admin Console

Session Management

AC.L2-3.1.10 requires session lock after a defined period of inactivity. In cloud consoles, this means configuring session duration limits — not just relying on browser timeouts.

System & Communications Protection in the Cloud

SC contains 16 controls focused on encryption and network segmentation.

Encryption Requirements

SC.L2-3.13.8 requires FIPS 140-2 validated cryptographic mechanisms for CUI protection.

This is where many cloud deployments fail. Default encryption in commercial AWS/Azure/GCP regions may not use FIPS-validated modules. You need:

• AWS: Use aws:kms with FIPS 140-2 Level 3 validated HSMs. In GovCloud, KMS endpoints are FIPS-validated by default. In commercial regions, use FIPS endpoints explicitly.
• Azure: Azure Key Vault with FIPS 140-2 Level 2 validated HSMs. For Level 3, use Azure Dedicated HSM or Managed HSM.
• GCP: Cloud KMS with FIPS 140-2 Level 3 validated modules (available in specific configurations).

Network Segmentation

SC.L2-3.13.1 requires boundary protection. In cloud terms, this means:

• VPC/VNet isolation for CUI workloads
• Security groups and NACLs restricting traffic to minimum necessary
• Private subnets for CUI-processing instances (no direct internet exposure)
• VPC Flow Logs or NSG Flow Logs enabled and reviewed

CUI Boundary Definition

The most critical architectural decision: where does your CUI boundary start and end?

In cloud environments, the boundary must encompass every resource that stores, processes, or transmits CUI — including:

• Compute instances and containers
• Databases and object storage
• Message queues and event buses
• Logging infrastructure that receives CUI-related logs
• CI/CD pipelines that deploy to CUI environments

Any resource that touches CUI or CUI-derived data is in scope for all 110 controls.

Audit & Accountability: Cloud Logging That Satisfies C3PAOs

AU controls require centralized, tamper-resistant logging with defined retention.

What to Log

AU.L2-3.3.1 requires logging of system-level events. In cloud environments, this means:

• AWS: CloudTrail (management and data events), VPC Flow Logs, S3 access logs, RDS audit logs, GuardDuty findings
• Azure: Activity Log, Diagnostic Logs, NSG Flow Logs, Azure AD sign-in logs, Key Vault audit logs
• GCP: Cloud Audit Logs (Admin Activity, Data Access, System Event), VPC Flow Logs, Cloud DNS logs

Retention and Protection

AU.L2-3.3.8 requires protecting audit information from unauthorized modification. Store logs in:

• Immutable storage (S3 Object Lock, Azure immutable blob storage)
• A separate account/subscription from the CUI environment
• Encrypted with keys managed outside the CUI boundary

The Review Problem

AU.L2-3.3.2 requires review and analysis of audit records. This is where most contractors fail — not because they don't collect logs, but because they have no systematic process for reviewing them.

A C3PAO will ask: "Show me evidence of your last three audit log reviews. What did you find? What actions did you take?"

If you can't answer that, the control is NOT MET regardless of how much logging infrastructure you have.

Configuration Management: Drift Is Your Enemy

CM controls require documented baseline configurations with change control.

In cloud environments, this means:

• Infrastructure as Code (Terraform, CloudFormation, Bicep) defining your baseline
• Continuous drift detection comparing actual state to declared state
• Automated alerting when configurations deviate from baseline
• Change management process that includes security review

The gap between "we use Terraform" and "we have continuous drift detection" is where most assessments find NOT MET findings. Terraform defines intent; it doesn't monitor reality between applies.

The GovCloud Question

Should you run CUI workloads in GovCloud regions?

For CMMC Level 2: GovCloud is not strictly required, but it significantly simplifies compliance. GovCloud regions are operated by U.S. persons, have FedRAMP High authorization, and use FIPS endpoints by default.

For contracts with specific requirements: Some contracts require GovCloud or equivalent. Check your contract clauses.

The practical answer: If you're a defense contractor processing CUI, GovCloud (AWS) or Azure Government reduces your compliance burden substantially. The infrastructure meets many SC and PE controls by default, letting you focus on the controls that require organizational implementation.

Common Cloud-Specific Assessment Failures

1. Default encryption without FIPS validation — Using cloud-provider default encryption that isn't FIPS 140-2 validated
2. Overly permissive security groups — Port 22/3389 open to 0.0.0.0/0
3. Public S3 buckets or blob containers — Even if they don't contain CUI, they indicate weak configuration hygiene
4. No log review evidence — Logs collected but never systematically reviewed
5. Shared accounts — Multiple users sharing a single cloud console login
6. Missing MFA on root/global admin — The most privileged accounts without MFA
7. No network segmentation — CUI and non-CUI workloads in the same VPC/VNet without isolation

PolicyCortex monitors your AWS, Azure, and GCP environments against all 110 NIST 800-171 controls in real time. Drift detection, evidence collection, and remediation — automated. Book a 15-minute demo to see your compliance posture live.