How should defense contractors scope systems and users for CMMC Level 1 when FCI flows across vendors and internal tools?

Why This Matters for Security Teams

CMMC Level 1 scoping is not just a paperwork exercise. For defense contractors, the boundary defines which systems and users are subject to safeguarding Federal Contract Information, and which can be excluded. If the scope is too broad, teams waste time and money hardening low-value assets. If it is too narrow, FCI can spill into unreviewed tools, shared drives, ticketing systems, email, or third-party platforms. That creates audit friction and operational risk.

The practical problem is that FCI rarely stays in one place. It moves through collaboration tools, file shares, internal workflows, and external providers, often without a clean owner or a complete asset inventory. Current guidance suggests starting with data flow mapping rather than assumptions about system purpose. The CMMC scoping logic should reflect where FCI is actually handled, not where a team hopes it lives. NIST’s control catalogue in NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces the need for clear access, auditability, and boundary definition.

In practice, many security teams encounter scope creep only after a self-assessment has already exposed an FCI path through an overlooked vendor or internal workflow.

How It Works in Practice

Effective scoping begins with a data-centric inventory. Identify every location where FCI is created, received, stored, processed, or transmitted, then trace the users, services, and systems that can touch it. That includes employees, contractors, shared mailboxes, endpoint devices, cloud workspaces, managed services, and any external application that receives or relays project data. The goal is to define a defensible enclave or set of in-scope assets that matches the actual flow of controlled information.

A common approach is to group systems into three buckets:

• In scope: assets that directly store, process, or transmit FCI.

• Connected to scope: systems that can impact the security of in-scope assets, such as identity services, admin workstations, or logging platforms.

• Out of scope: systems with no realistic path to FCI and no trust dependency on scoped assets.

That distinction matters because users are part of scope too. If a contractor account can access an FCI repository, the account management process, authentication method, and administrative path for that user are also relevant. This is where identity governance intersects with NHI control. If internal automation, integrations, or scripts handle FCI, teams should also review secrets and service credentials using the lens in the OWASP Non-Human Identity Top 10, because unattended credentials can silently expand the assessment boundary.

Documentation should show how FCI is separated from general business data, how vendors are constrained, and what technical or procedural controls prevent spillover. That usually means clear segmentation, least privilege, logging, and explicit handling rules for collaboration platforms and backups. Scoping also works best when contract owners, IT, security, and procurement agree on the asset list before the assessment starts. These controls tend to break down when FCI is embedded in shared SaaS workflows with weak role design because data paths become invisible to the teams defining the boundary.

Common Variations and Edge Cases

Tighter scoping often reduces assessment effort, but it also increases the burden of proving that excluded systems truly cannot reach FCI, requiring organisations to balance efficiency against evidentiary confidence. That tradeoff becomes harder in hybrid environments where project teams use shared SaaS tools, federated identity, and managed service providers.

There is no universal standard for this yet, but current guidance suggests treating vendor-hosted platforms as in scope when they store or transmit FCI, even if the contractor does not administer the underlying infrastructure. The same logic applies to internal tools that ingest FCI indirectly, such as help desk systems, document converters, and reporting pipelines. In those cases, the boundary should follow the information path, not the server ownership model.

One frequent edge case is automation. A script, RPA bot, or API integration may not be a “user” in the human sense, but if it can access FCI, its credentials and permissions need the same scrutiny as any privileged account. Another edge case is mixed repositories, where FCI sits alongside non-FCI content. Best practice is evolving, but organisations generally need a repeatable method for separating, labeling, or constraining those repositories so the assessor can understand what is genuinely in scope and what is not. For broader control context, the control family in NIST guidance helps translate boundary decisions into access, monitoring, and configuration requirements without overextending the scope definition.

Related resources from NHI Mgmt Group

• Why do contractors and vendors create more privileged access risk than internal users?
• How should security teams run SOX access reviews across multiple in-scope systems?
• Why do third-party vendors complicate identity governance more than internal users?
• How should organisations respond when agents start chaining tools across systems?