How should defense contractors approach CMMC compliance when they handle both FCI and CUI?

How CMMC Scope Changes When a Contractor Handles Both FCI and CUI

CMMC compliance starts with information scoping, not with a checklist. When a defence contractor handles both Federal Contract Information and Controlled Unclassified Information, the control expectation is driven by the higher-risk data set and by where that data can actually flow. That means the contractor must identify which contracts, users, endpoints, enclaves, and third-party services touch CUI, then separate that scope from general business systems where possible. If scope is vague, every downstream decision becomes harder to defend.

FCI and CUI are not interchangeable categories. FCI usually supports a baseline hygiene posture, while CUI raises the bar for access control, monitoring, incident handling, and evidence that the controls are consistently operating. A contractor that treats CUI as a paperwork exercise often discovers the real issue later, when a system diagram, asset inventory, or account review cannot prove where the sensitive data resides. For practical planning, the most useful first step is to identify the boundary of systems in scope and confirm that the boundary matches how the work is actually performed.

That scoping step also determines what evidence matters. Assessment readiness depends on showing that the controls are not only written down but also enforced in daily operations. If a shared identity store, remote admin path, or file repository can reach CUI from outside the intended boundary, the compliance problem becomes broader than the original contract requirement.

What Evidence Matters Once FCI and CUI Share the Same Environment

The hard part of mixed FCI and CUI environments is not understanding the label, but proving control separation. In practice, contractors need a defensible inventory of in-scope systems, accounts, storage locations, and connections. They also need to show how CUI is protected wherever it moves, including backups, collaboration tools, ticketing systems, and managed service arrangements. NIST’s control catalogue is useful here because it forces teams to connect scope to concrete safeguards rather than to generic policy language, and CMMC assessment usually depends on that same discipline. NIST SP 800-53 Rev 5 Security and Privacy Controls

• Keep an inventory of every asset that stores, processes, or transmits CUI, not just the primary production system.
• Separate user populations and administrative paths where CUI exposure would otherwise extend across the whole enterprise.
• Confirm that logging, incident response, and access reviews cover the full CUI boundary, including cloud and third-party services.
• Retain evidence that controls operate in practice, such as review records, configuration baselines, and access approvals.

Where FCI and CUI coexist, the practical issue is often inheritance: a system considered “low sensitivity” may still become in scope because it authenticates users, stores attachments, or supports a workflow that moves CUI indirectly. That is why contractors should trace data movement, not just system ownership. The guidance breaks down when the organisation cannot show a stable boundary or cannot evidence who can reach CUI from adjacent business tools.

Where Contractors Usually Misjudge Mixed-Data CMMC Scope

Tighter scoping often reduces assessment burden, but it also increases the need for disciplined architecture and documentation, so organisations must balance a smaller boundary against the cost of enforcing it. The common mistake is assuming that FCI systems can be treated separately while CUI systems are handled only at the application layer. In reality, identity, network, backup, and support tooling can collapse that separation if they are shared without clear controls.

There are also genuine edge cases. Some contractors run a single environment where FCI and CUI are both present, but the CUI is segmented well enough that only a subset of users and assets sit in the compliance boundary. Others use cloud services or managed providers that introduce shared-responsibility gaps, especially where the contractor assumes the provider’s baseline settings are enough. That assumption is not consensus-safe unless the contractor can verify what is actually enforced, what is inherited, and what remains their responsibility.

The most useful distinction is operational, not semantic: if CUI can affect the same authentication plane, administrator access, or storage plane as general project data, the organisation should treat that as a stronger scope and evidence problem. NIST Cybersecurity Framework 2.0 helps frame that boundary and recovery discipline, but it does not replace the CMMC requirement to prove the controls that protect the sensitive set. The guidance stops working when teams rely on labels instead of demonstrating separation, control operation, and traceable ownership.

Risk and Threat Considerations

Mixed FCI and CUI environments create a material exposure problem because the lower-sensitivity category can become a path into the higher-sensitivity one. The key risk is not the label itself, but weak boundary control around accounts, shared services, and data movement. If CUI is reachable through the same systems that support ordinary contract work, the contractor may overstate its actual containment.

Failure mechanism: Scope drift, shared identities, excessive permissions, and incomplete logging let a compromise or misconfiguration spread from general contractor operations into the CUI boundary. The same mechanism can also undermine assessment readiness when the organisation cannot prove where CUI resides or who can access it.

Impact: The contractor may lose control over protected contract information, fail an assessment, or be unable to demonstrate that required safeguards operate across the full in-scope environment. That can create delivery delays, remediation cost, and downstream contract risk.

Practitioner Guidance

What to prioritise: Define the CUI boundary before tuning controls. If the team cannot list the exact systems, identities, and services in scope, it should assume the assessment will focus on boundary weakness rather than on individual control gaps.

What to verify: Verify that access reviews, logging, incident response, and backup coverage all extend across the actual CUI path, not just the primary application. The strongest evidence is a repeatable chain from contract data classification to technical enforcement and then to retained operating records.

Common mistake: Treating FCI as a lighter version of the same environment and then allowing shared authentication, shared storage, or shared administration to erase the separation. That shortcut usually creates the very evidence problem the contractor was trying to avoid.

Practitioner takeaway: For mixed FCI and CUI work, compliance succeeds when scope is engineered, not assumed; the contractor should be able to prove where CUI lives, who can reach it, and how the controls are enforced every day.

Related resources from NHI Mgmt Group

• How should defense contractors scope systems and users for CMMC Level 1 when FCI flows across vendors and internal tools?
• How should defense contractors prepare for CMMC 2.0 when their next solicitation may require compliance at contract award?
• Why does CMMC 2.0 create more risk for contractors that handle CUI through cloud and service providers?
• What is the difference between ITAR compliance and CMMC readiness for defense contractors?