Cloud Security for Defense Contractors: The Definitive Guide

The Defense Contractor Cloud Security Challenge

Defense contractors operate in a cloud security environment that commercial enterprises don't face. The requirements stack is uniquely complex:

• DFARS 252.204-7012 — The foundational contractual requirement for CUI safeguarding, mandating adequate security and cyber incident reporting
• CMMC 2.0 — 110 NIST 800-171 controls with mandatory third-party assessment
• ITAR/EAR — Export control regulations governing technical data handling
• FedRAMP — Authorization requirements for cloud service providers used for federal workloads
• NIST SP 800-171 — The 110 security requirements that underpin CMMC Level 2
• Program-specific requirements — Classified program handling rules that layer on top of everything else

A commercial company building a SaaS product worries about SOC 2 and GDPR. A defense contractor handling CUI for a DoD missile defense program worries about all of the above simultaneously.

Understanding this regulatory stack — not just checking individual boxes — is the difference between compliance theater and genuine security.

Understanding CUI and Why It Changes Everything

Controlled Unclassified Information (CUI) is the central concept that drives most defense contractor cloud security requirements.

What Is CUI?

CUI is government-created or government-owned information that requires safeguarding or dissemination controls consistent with applicable laws, regulations, and government-wide policies. It's not classified, but it's not publicly releasable either.

For defense contractors, common CUI categories include:

Technical Information:

• Controlled Technical Information (CTI) — technical data related to military or space applications
• Export Controlled — ITAR-controlled technical data

Acquisition and Contracting:

• Contract data with sensitive terms or pricing
• Source selection information
• Proprietary business information

Law Enforcement and Privacy:

• Personally identifiable information (PII) when created under a federal program
• Personnel records for cleared employees

How CUI Flows in Defense Contracting

CUI enters contractor environments through:

• Contracts and statements of work
• Government-furnished information (GFI)
• Prime-to-sub information sharing
• Contractor-generated data that is deliverable to DoD

Understanding your CUI flows is prerequisite to designing a compliant cloud architecture. You cannot protect CUI you don't know you have.

Building a CUI-Compliant Cloud Architecture

The CUI Boundary

The CUI boundary is the logical and physical perimeter around systems that process, store, or transmit CUI. Every system within this boundary must meet all 110 NIST 800-171 controls.

The single most impactful decision in your cloud security architecture is how you define this boundary.

Broad boundary (common mistake): The entire corporate cloud environment handles CUI. All systems are in scope. Compliance burden is enormous.

Tight boundary (correct approach): CUI is isolated in a dedicated environment — dedicated AWS accounts, Azure subscriptions, or GCP projects. Only the systems that need to touch CUI are in the CUI account. Corporate business systems operate in a separate, non-CUI environment with no CUI data flows.

Account/Subscription Architecture

AWS Pattern:

Management Account (org-level policies, consolidated billing)
├── Security Account (centralized logging, SIEM, Security Hub)
├── CUI Production Account (CMMC-compliant workloads)
├── CUI Dev/Test Account (CMMC-compliant)
└── Corporate Account (non-CUI business systems)

Azure Pattern:

Management Group (top-level policy)
├── Security Subscription (Sentinel, Defender)
├── CUI Landing Zone
│   ├── CUI Production Subscription
│   └── CUI Dev Subscription
└── Corporate Landing Zone

This account separation creates a hard boundary between CUI and non-CUI environments. The management account controls organization-wide security policies. The security account centralizes audit logging. CUI accounts are strictly controlled for CUI workloads.

Network Architecture

VPC/VNet Design for CUI:

1. Dedicated VPC for CUI — No VPC peering to corporate networks without inspection
2. Tiered subnet architecture — Public (web-facing only), private (application tier), restricted (data tier)
3. No direct internet access from data tier — Private subnets for CUI databases, with NAT for outbound only
4. VPC flow logs enabled — Full flow logging to centralized security account
5. PrivateLink for AWS services — Avoid routing CUI through public internet for service API calls

Identity Architecture

IAM Design Principles:

• No long-lived access keys — Use IAM roles and temporary credentials everywhere
• Least privilege by default — Every role and policy starts with zero permissions, add only what's needed
• Privileged access workstations — Separate endpoints for privileged cloud operations
• Break-glass accounts — Emergency access accounts with additional controls and monitoring
• Service account lifecycle management — Regular review and revocation of unused service principals

CMMC-Specific Cloud Controls

Access Control (AC) in the Cloud

The access control family is consistently the most finding-rich in CMMC assessments. Key areas:

MFA enforcement: Use AWS IAM Identity Center (SSO) with MFA enforcement at the organization level. Apply SCPs to prevent console access without MFA. Use hardware security keys (FIDO2/U2F) for privileged access.

Least privilege: Conduct quarterly IAM access reviews. Use AWS IAM Access Analyzer to identify overly permissive policies. Use CloudTrail Insights to identify unused permissions.

Session management: Configure IAM role session durations. Set CLI session timeouts. Enforce idle session termination for console access.

Account lifecycle: Disable accounts immediately upon personnel departure. Review contractor access quarterly. Audit service accounts annually.

Audit and Accountability (AU) in the Cloud

Comprehensive logging configuration:

CloudTrail:
  - Management events: ALL (Read and Write)
  - Data events: S3 (all buckets in CUI account), Lambda, RDS
  - Insight events: Enabled
  - All regions: True
  - Log file validation: Enabled
  - CloudWatch Logs integration: Enabled
  - S3 bucket: Log archive account (separate from CUI account)

VPC Flow Logs:
  - All VPCs: Enabled
  - Destination: Centralized S3 in security account
  - Retention: 3 years

S3 Access Logging:
  - All CUI buckets: Enabled
  - Server access logs → centralized log bucket

Log retention: DoD requirements for CUI audit logs are typically 3 years. Configure S3 lifecycle policies and CloudWatch retention accordingly.

Configuration Management (CM) in the Cloud

Infrastructure as Code: All CUI infrastructure deployed via IaC (Terraform, CloudFormation). No console-deployed resources in CUI accounts. IaC pipelines include security scanning (checkov, tfsec) that blocks non-compliant deployments.

AWS Config: Enable AWS Config in all CUI accounts. Deploy conformance packs mapped to NIST 800-171. Configure automatic remediation rules for known-good states.

Change management: Require PR reviews with security approval for IaC changes. Log all deployments with change ticket references. Implement change freeze windows for CUI environments.

Cryptography (SC) in the Cloud

Encryption at rest — all CUI:

• EBS volumes: Encrypted with customer-managed KMS keys
• S3 buckets: SSE-KMS with CUI-specific key
• RDS/Aurora: Encrypted at rest
• Secrets Manager/Parameter Store: KMS-encrypted
• ECR container images: Encrypted

Encryption in transit — all CUI:

• ALB/NLB: TLS 1.2 minimum, TLS 1.3 preferred
• CloudFront: TLS policy minimum TLSv1.2_2021
• API Gateway: Enforce HTTPS
• RDS: SSL required (parameter group)
• All internal service communication: TLS with certificate validation

FIPS requirements: Systems handling certain categories of CUI may require FIPS 140-2 validated cryptography. AWS GovCloud (US) endpoints are FIPS-validated. Standard commercial region endpoints are not. Understand your FIPS requirements before selecting regions.

DFARS 252.204-7012 Requirements

DFARS 252.204-7012 is the contractual provision that makes NIST 800-171 compliance a contract requirement. It has specific requirements beyond the NIST controls themselves:

Adequate Security

"Adequate security" means meeting NIST SP 800-171 requirements. Contractors must implement all applicable requirements in NIST SP 800-171 by the time of contract award.

Cyber Incident Reporting

Within 72 hours of discovering a cyber incident, contractors must:

1. Report to DoD via the DIBNet portal (dibnet.dod.mil)
2. Preserve and protect images of known compromised systems
3. Submit malware samples to DoD
4. Report to US-CERT

This 72-hour clock starts from discovery, not from confirmation. Early reporting is required even if the scope is uncertain.

Cloud Service Provider Requirements

CSPs used to process, store, or transmit CUI covered by DFARS must:

• Meet FedRAMP Moderate baseline security controls
• Be included in the System Security Plan
• Comply with DFARS cyber incident reporting requirements

This means the CSP itself (AWS, Azure, GCP) must be FedRAMP authorized for CUI processing. All three major cloud providers have FedRAMP Moderate authorization for their commercial regions, and GovCloud-equivalent authorizations at higher levels.

ITAR Cloud Data Handling

ITAR (International Traffic in Arms Regulations) governs the export of defense articles, services, and related technical data. ITAR cloud compliance requirements are distinct from and add to standard CUI requirements.

ITAR Data Categories

ITAR applies to "defense articles" listed on the United States Munitions List (USML). This includes technical data — including software, schematics, test data, and engineering specifications — related to USML items.

If your organization provides engineering services, product development, or technical analysis for defense programs, you almost certainly have ITAR data.

ITAR Cloud Data Residency

General rule: ITAR data must remain under U.S. jurisdiction. Access from foreign nationals is an export, even if the data stays in the U.S.

For cloud storage: Data must be stored in U.S.-region cloud facilities. Ensure your bucket/container/volume region configurations are U.S.-only. Use service control policies to prevent resource creation outside approved U.S. regions.

For cloud services: Ensure global cloud services (CDN, global load balancing, global databases) don't route ITAR data through non-U.S. regions. Explicitly configure data residency for each service.

ITAR Access Controls

Foreign national access: Access to ITAR data by foreign nationals (regardless of their U.S. residency status) is an export requiring authorization. Your cloud environment must prevent foreign national access without proper authorization.

Access control implementation:

• Verify citizenship/clearance status as part of IAM access provisioning
• Implement attribute-based access controls (ABAC) that include nationality/citizenship attributes where technically feasible
• Maintain an access roster for ITAR programs with periodic review

ITAR and Multi-Cloud

Organizations using multiple cloud providers for ITAR programs must apply ITAR requirements consistently across all environments. An ITAR-compliant AWS environment doesn't mean your Azure or GCP environments are ITAR-compliant.

Incident Response for Defense Contractors

72-Hour DFARS Reporting

The DFARS 72-hour reporting requirement creates specific operational requirements:

Detection capability: You must be able to detect cyber incidents quickly. This requires real-time monitoring of your CUI environment with alert thresholds that don't let significant events go unnoticed for days.

Incident response readiness: Your IR team must know how to access and navigate the DIBNet reporting portal, what information is required for the initial report, and who in your organization has authority to submit the report.

Forensic preservation: You must preserve system images and data for DoD forensic investigation. This requires clear procedures for isolating and imaging affected systems without destroying evidence.

Cloud-Specific Incident Response

Cloud incidents have specific characteristics that differ from on-premise incidents:

Ephemeral infrastructure: Cloud instances can be terminated and recreated rapidly. IR procedures must include creating snapshots and preserving evidence before termination.

API-driven attacks: Many cloud compromises involve API credential theft and abuse. Log analysis for API call patterns is essential for detecting these attacks.

Shared responsibility boundaries: During an incident, understanding where provider responsibility ends and your responsibility begins is critical for scoping the investigation.

Continuous Compliance Operations

The Post-Certification Problem

Many defense contractors achieve CMMC certification and then experience gradual compliance drift as operational tempo resumes and compliance receives less attention. The result is a cycle of stressful certification sprints followed by compliance degradation.

Continuous Monitoring Architecture

A sustainable compliance operations model includes:

Real-time configuration monitoring: Continuously evaluate cloud resource configurations against CMMC control mappings. Alert — and where appropriate, automatically remediate — deviations immediately.

Access review automation: Quarterly automated IAM access reviews that identify stale accounts, excessive permissions, and missing controls.

Evidence collection automation: Continuously generate and preserve assessment-ready evidence for all 110 controls. When assessment time arrives, evidence review is complete.

Patch and vulnerability management: Automated scanning and patch compliance reporting for all CUI system components.

Metrics That Matter

Mean Time to Detect (MTTD): How quickly does your monitoring identify a new compliance issue? For CMMC continuous monitoring, this should be measured in minutes, not hours.

Mean Time to Remediate (MTTR): How quickly do you close identified issues? Manual ticketing workflows measured in days don't meet continuous monitoring standards.

Compliance Coverage: What percentage of your 110 controls are continuously monitored? Target 100% automated coverage.

Evidence Freshness: How current is your assessment evidence? Real-time evidence collection means your evidence is never stale.

Conclusion: Building for the Long Haul

Defense contractor cloud security is not a project with a completion date. CMMC certification is a milestone, not a destination. The contractors who build durable, continuously-operating compliance programs will outperform their peers at assessment time and throughout the year.

The technical components are well-defined: account segmentation, comprehensive logging, least-privilege IAM, encryption everywhere, continuous monitoring. The operational challenge is maintaining these controls at production velocity — as developers move fast, requirements evolve, and the threat landscape shifts.

Autonomous governance platforms close the gap between the technical requirements and operational reality, enabling defense contractors to maintain genuine compliance continuously rather than sprinting to achieve it periodically.

Related reading:

• The Complete Guide to CMMC 2.0 Compliance in 2026
• NIST 800-171 Compliance: From Manual Checklists to Autonomous Enforcement
• Multi-Cloud Governance: Managing AWS, Azure, and GCP Under One Policy