How should small defense contractors scope CMMC Level 1 before they start remediation?

Start with the contract boundary, not the tool list

CMMC Level 1 scoping works best when you define the Federal Contract Information boundary first, then trace where that information is created, stored, transmitted, and accessed. For small contractors, the practical goal is to include only the people, systems, facilities, and external providers that actually handle FCI, while excluding adjacent business systems that never touch it. That keeps the scope defensible and manageable.

In practice, the scope statement should answer two questions clearly: where can FCI exist, and who or what can reach it? If you cannot explain that chain in plain language, the scope is probably too broad or too vague to support remediation work.

External providers matter when they process, host, back up, support, or can access FCI, because the scope follows the information path rather than the org chart. A narrow, evidence-based boundary is easier to remediate and easier to defend during assessment. NHIMG’s Third-Party, B2B and Contractor Access Guide is useful here because contractor and supplier access often expands scope without anyone noticing.

What belongs in Level 1 scope, and what does not

Level 1 scope should include the assets that store or process FCI, the systems that transmit it, the admins and users who can touch it, and the facilities where that processing occurs. It should also include any external service that can administer those assets or recover FCI from backups, logs, or hosted platforms. If a system can neither contain nor influence FCI handling, it usually does not belong in the assessed boundary.

That same logic helps prevent common scope inflation. Shared corporate services, general productivity tools, and unrelated development environments are not in scope unless they are actually used for FCI. The question is not whether a system is important to the business, but whether it is part of the FCI handling path for the contract.

Contractors also need to distinguish direct handling from incidental proximity. A finance system, HR platform, or marketing tool may sit in the same company, but it should stay out of scope unless it stores or can access FCI. That distinction reduces control burden and keeps remediation effort aligned to the real compliance boundary.

Where remote support or cloud administration exists, privilege should be included in the scope review even if the underlying platform is owned by a third party. NHIMG’s Privileged Access Management Guide is relevant because administrative access is often the fastest way a small scope becomes a large one.

How to avoid over-scoping before remediation starts

The best pre-remediation move is to inventory FCI paths before you write controls. Start with documents, attachments, tickets, email, file shares, cloud storage, collaboration tools, and backups, then identify which of those actually contain or move FCI. After that, map the users, service accounts, vendors, and support teams that can reach those locations. That creates a scope that is evidence-driven instead of assumption-driven.

Over-scoping usually happens when teams treat every connected system as if it were in scope, or when they fail to separate “can technically access” from “actually processes FCI.” The remediation result is predictable: more systems, more controls, more exceptions, and more time spent fixing things that do not affect Level 1. A tighter scope lets a small contractor focus on the few assets that matter most.

Another useful discipline is to document exclusions explicitly. If a system is out of scope, record why, what prevents FCI from flowing there, and what would change the decision. That makes the boundary easier to defend if the environment changes later or if a reviewer asks why an adjacent system was excluded. For control design, NHIMG’s Authorisation Models Guide helps when you need to separate broad access patterns from the specific permissions that actually matter.

Practitioner Guidance

What to prioritise: Build an FCI asset and access inventory before remediation work begins. If you start by fixing controls without a clean scope, you will spend time hardening systems that may not need to be assessed at all.

What to verify: Confirm which systems can create, store, transmit, back up, or restore FCI, and verify who can administer them. Include managed service providers and cloud support paths if they can reach those assets.

Common mistake: Teams often scope by network segment or by business unit instead of by FCI flow. That usually produces either scope bloat or missed shared services that still matter.

Decision rule: If removing a system or provider would not change how FCI is handled, it should not be driving Level 1 remediation effort. If it can change the handling path, treat it as in scope until proven otherwise.

Practitioner takeaway: The quality of CMMC Level 1 remediation is mostly determined before remediation starts, because scope discipline decides whether you are fixing the real FCI boundary or paying to secure the wrong environment.

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 defence contractors scope CMMC Level 2 requirements before implementing controls in a complex environment?
• How should organisations scope a SOC 2 audit before they start remediation work?
• How should organisations scope an identity and access governance programme before they start implementation?