CMMC scoping determines which systems, technologies, and facilities fall within the assessment boundary for a given CMMC level. For cloud engineering subcontractors, scoping decisions determine whether the sub must achieve their own CMMC assessment, operate within the prime's CMMC boundary, or is excluded from the assessment scope entirely.
Getting scoping right protects both primes and subs from compliance exposure — and from over-scoping assessments that drive unnecessary cost and delay.
CMMC Scoping Fundamentals
CMMC scoping is defined in the CMMC Assessment Process (CAP) guidelines. The scope determination identifies which systems, components, and personnel fall within the CMMC Level 2 (or Level 3) assessment boundary.
Assets that fall within CMMC scope: - Systems that process, store, or transmit CUI (Controlled Unclassified Information) - Systems that provide security protection for CUI systems - Contractor facilities where CUI is handled
Assets that can be descoped: - Systems that are explicitly isolated from CUI data flows (with documented and enforced controls) - External Service Providers (ESPs) that meet FedRAMP Moderate or equivalent — AWS GovCloud's FedRAMP High authorization covers many of the underlying infrastructure controls
The ESP carveout for cloud infrastructure: When a cloud provider is a FedRAMP-authorized ESP and the contractor doesn't process, store, or transmit CUI beyond what the cloud provider's environment handles, the cloud provider's inherited controls can reduce the in-scope control count. AWS GovCloud's FedRAMP High authorization covers a substantial portion of NIST 800-171 control requirements, allowing the contractor's CMMC assessment to focus on the remaining contractor-owned controls.
Rutagon's CMMC Boundary Management
When Rutagon delivers cloud infrastructure under a prime's CMMC-scoped program, there are two scenarios:
Scenario A: Rutagon operates within the prime's CMMC boundary. The prime has a CMMC assessment that covers the cloud environment. Rutagon operates as an authorized user/operator within that boundary. Rutagon's personnel must follow the prime's System Security Plan (SSP) requirements, CUI handling procedures, and access controls. The prime's ISSO has visibility into Rutagon's access and activities.
Scenario B: Rutagon has its own CMMC boundary. For programs where Rutagon processes CUI independently (rather than just accessing the prime's environment), Rutagon must have its own CMMC Level 2 compliance posture. This is applicable when Rutagon stores CUI-containing configuration files, processes CUI-bearing data in its development environment, or operates systems that are part of the prime's boundary but separately managed.
The scoping decision — which scenario applies — is made collaboratively with the prime's contracts and security teams before the teaming agreement is executed. Starting with clear scoping prevents mid-program compliance gaps.
CUI Identification and Handling on Cloud Programs
For programs where CUI flows through Rutagon-managed infrastructure:
CUI categories relevant to cloud programs: - Export Control CUI (EAR, ITAR-controlled technical data in design documents) - Defense CUI (acquisition-sensitive information, contractor bid/proposal information) - Privacy CUI (PII associated with government personnel) - Critical Infrastructure CUI (cloud architecture for systems supporting critical infrastructure)
Handling requirements in cloud contexts: - CUI-containing files in code repositories must be excluded from public repositories — private repositories with access controls and audit logging - CUI-bearing configuration values (database connection strings for systems processing CUI, API keys for CUI-processing services) handled through secrets management, not hardcoded in code - Access logs for CUI systems retained per the program's retention requirements - CUI marking on data products containing CUI according to the program's CUI marking plan
What Primes Should Require from Cloud Subs for CMMC Alignment
A CMMC-aligned sub agreement should specify:
CUI handling affirmation: The sub affirms that they understand and will comply with the prime's CUI handling requirements for any CUI they encounter.
Access control: The prime retains visibility into the sub's access to prime systems. Sub personnel access is provisioned and de-provisioned through the prime's access management process.
Incident reporting: The sub agrees to report any cybersecurity incidents involving prime systems within the timeframes required by the prime's Cybersecurity Incident Response Plan (CIRP) and DFARS 252.204-7012.
SSP awareness: Sub personnel operating within the prime's CMMC boundary have reviewed the relevant sections of the System Security Plan applicable to their work.
SPRS documentation: If the sub is processing CUI under a DFARS clause, the sub maintains a SPRS score reflecting their cybersecurity posture.
Explore CMMC-aligned cloud teaming with Rutagon → rutagon.com/contact
Frequently Asked Questions
Does Rutagon need its own CMMC certification to subcontract on defense programs?
It depends on whether Rutagon's scope includes CUI processing. For cloud infrastructure delivery that doesn't require Rutagon to access or process CUI (building the environment, configuring security controls, but not accessing the data that runs in the environment), Rutagon may operate outside the CMMC assessment boundary. For programs where Rutagon accesses CUI as part of delivery (reviewing data to support a migration, accessing CUI-containing systems for debugging), CMMC compliance posture applies. Scoping is determined per-program.
How does AWS GovCloud's FedRAMP authorization help with CMMC?
AWS GovCloud holds FedRAMP High authorization. The CMMC Assessment Process guidance allows contractors to leverage the inheriting controls from FedRAMP-authorized ESPs — reducing the in-scope control count for the contractor's assessment. Specifically, many NIST 800-171 physical protection, system protection, and configuration management controls are addressed by AWS's FedRAMP boundary. The contractor's CMMC assessment focuses on the residual controls not addressed by the inherited FedRAMP controls.
What is a SPRS score and does Rutagon maintain one?
SPRS (Supplier Performance Risk System) is the DoD database where defense contractors self-report their CMMC/NIST 800-171 compliance score. Contractors with DFARS 252.204-7012 obligations self-assess their NIST 800-171 implementation and submit the score to SPRS. For programs where Rutagon's DFARS obligations apply, Rutagon maintains an appropriate SPRS submission. Specific score details are not disclosed publicly.
How does CMMC Level 2 differ from Level 3 for cloud programs?
CMMC Level 2 requires third-party C3PAO assessment every 3 years (for prime contractors) and covers 110 NIST 800-171 practices. Level 3 adds approximately 24 additional NIST 800-172 requirements (largely focused on advanced persistent threat defense) and requires government-led assessments. Most defense programs with CUI handling require Level 2. Programs involving higher-sensitivity defense information or specific DoD priority programs may require Level 3. Cloud infrastructure for Level 3 programs requires additional controls beyond the standard GovCloud baseline.
What happens if a cloud sub has a security incident within a prime's CMMC boundary?
Per DFARS 252.204-7012, the prime has a 72-hour reporting obligation to DoD for any cyber incident involving systems covered by the clause. If Rutagon is operating within or has access to the prime's CMMC boundary systems and has a security incident, Rutagon must notify the prime immediately (within hours, not the full 72-hour window, to allow the prime time to meet their reporting obligation). The teaming agreement specifies this notification requirement explicitly.