Controlled Unclassified Information (CUI) is the federal government's framework for handling sensitive unclassified data — and for cloud engineering subcontractors, CUI requirements aren't a formality. They're specific technical obligations that affect every system that touches government program information.
This article covers what CUI handling requires in a cloud environment, and what prime contractors need to verify about their cloud engineering subs' CUI posture.
What Is CUI and Why Does It Matter for Cloud Subs?
CUI was established by Executive Order 13556 to standardize how agencies handle sensitive information that doesn't meet the threshold for classified status but still requires protection. Categories of CUI include:
- Export-controlled technical data (overlapping with ITAR/EAR)
- Personally Identifiable Information (PII)
- Law Enforcement Sensitive
- Privacy Act-protected data
- Controlled technical information (CTI) on DoD programs
The key regulation for defense contractors handling CUI is DFARS 252.204-7012 — which requires covered contractors to implement NIST SP 800-171 security controls and report cyber incidents. DFARS 252.204-7012 compliance requirements explains the full scope.
CMMC (Cybersecurity Maturity Model Certification) builds on these requirements, with Level 2 applying to programs involving CUI. Automated CMMC evidence collection covers how to manage this efficiently.
CUI in Cloud Systems: What Changes From Non-CUI Work
A cloud system handling CUI isn't just a cloud system with better access controls — it's a system with specific architectural requirements that affect how it's designed, deployed, operated, and monitored.
System boundary documentation: CUI-handling systems require a documented system boundary — what's in scope for the CUI protection controls versus what's outside it. This boundary must be defensible and accurate; system components that process or store CUI must be inventoried and documented.
FIPS 140-2 validated encryption: All CUI at rest and in transit must be encrypted using FIPS 140-2 validated modules. This is an explicit NIST 800-171 requirement (3.13.8, 3.13.10). Standard commercial TLS and at-rest encryption typically use validated algorithms, but the implementation matters — check your TLS configuration, key storage (AWS KMS has FIPS-validated options), and certificate chains.
Access control with formal least privilege: NIST 800-171 requires access to CUI to be restricted to individuals who need it for job functions. In cloud terms: IAM roles scoped to minimum required permissions, no wildcard policies on CUI storage, and documented access justification for every principal with CUI data access.
Audit logging and retention: All CUI system access events must be logged and retained per NIST 800-171 requirements (3.3.1, 3.3.2). Specifically: privileged user access, failed authentication attempts, configuration changes, and data access events. Logs must be protected from modification (immutable log storage in cloud terms — CloudWatch with log shipping to S3 with Object Lock, or equivalent).
Incident reporting: DFARS 252.204-7012 requires reporting of cyber incidents involving CUI to DoD within 72 hours. Cloud engineering teams handling CUI need a defined incident response procedure and the technical capability to detect and respond within the reporting window.
CUI Architecture Patterns for Government Cloud Programs
Envelope architecture: CUI data is stored in a separate, dedicated environment (separate AWS account, separate VPC, separate GovCloud partition) from non-CUI workloads. Network and IAM boundaries prevent CUI from leaking into non-CUI system components. This simplifies the system boundary definition and limits the scope of CMMC/NIST 800-171 compliance to the CUI envelope.
Infrastructure-as-code with compliance gates: CUI environments should be provisioned via IaC (Terraform, CloudFormation) with automated compliance checks that prevent non-compliant configurations from being deployed. AWS GovCloud IaC with Terraform covers the tooling and patterns in detail.
STIG-compliant compute baselines: VMs and containers in CUI environments should start from STIG-hardened baselines — CIS benchmarks or DoD STIG configurations. STIG compliance automation with Kubernetes covers automated STIG enforcement in container environments.
Zero trust access for CUI systems: CUI access should never be based purely on network position. Zero trust principles — authenticate every request, verify device health, apply least-privilege access — reduce the blast radius of any single compromised credential. Zero trust and credential elimination explains the implementation approach.
What Primes Should Verify From Cloud Subs Before CUI Subcontracts
Before subcontracting CUI-handling cloud work, primes should verify:
1. Does the sub have a System Security Plan (SSP)? A documented SSP is required for NIST 800-171 compliance and is the baseline evidence that the sub understands their CUI controls.
2. Has the sub completed a NIST 800-171 self-assessment? DoD requires contractors to submit a SPRS score for their NIST 800-171 implementation. Ask for the current score and summary of implementation status.
3. Can the sub demonstrate their CUI data boundary? System diagrams showing what processes and stores CUI, with documented access control and encryption configurations, are the technical evidence of CUI controls.
4. Is the sub on the path to CMMC Level 2 if the program requires it? CMMC Level 2 certification is required for programs with CUI. Subs who haven't started CMMC planning create compliance risk for the prime.
5. Does the sub have a 72-hour cyber incident response capability? The DFARS incident reporting requirement applies to subs as well as primes. Verify the sub has a written incident response plan with contact escalation procedures.
Learn about Rutagon's CUI-capable cloud engineering →
Frequently Asked Questions
What cloud platforms are acceptable for handling CUI?
AWS GovCloud (US-East and US-West), Azure Government, and Google Cloud's government regions are the primary options. These regions provide U.S.-based, U.S.-person operated infrastructure with the FIPS-validated service options required for CUI. Standard commercial cloud regions can be used with appropriate controls in some cases, but GovCloud is the cleaner path for CUI-heavy programs.
Does every federal IT subcontract involve CUI?
No. Many government IT contracts involve only publicly releasable data with no CUI designation. The prime's contract and the DD-254 (if a defense contract) specify whether CUI is involved. Programs with CUI typically call it out explicitly in the statement of work or security classification guide.
What is CMMC Level 2 and when does it apply to cloud subs?
CMMC Level 2 applies to contractor systems that process, store, or transmit CUI on DoD programs. It requires independent third-party assessment of 110 NIST SP 800-171 practices. Primes on affected contracts must flow CMMC requirements down to subs handling CUI. Full CMMC Level 2 certification is required for subs on affected programs by the rollout timeline specified in the prime's contract.
How does a CUI system boundary affect cloud architecture?
The system boundary defines the scope of CUI protection controls. Good boundary design minimizes the scope — only the components that actually process or store CUI are in scope for the full NIST 800-171 control set. An envelope architecture that isolates CUI in a dedicated cloud account or environment is the most defensible approach.
What is a SPRS score and why do primes ask about it?
The Supplier Performance Risk System (SPRS) is where DoD contractors submit their NIST SP 800-171 self-assessment scores. A higher score indicates better implementation of CUI protection controls. Primes can look up sub SPRS scores in the system. Primes increasingly use SPRS scores as a vetting criterion for CUI-handling subcontracts.