photograph-style image of a desk surface with three distinct document stacks arranged side by side — each with a sticky note on top, slightly different in size and organization. One stack is neat and labeled, one is mid-organization with visible tabbed dividers, and one is a loose pile. Soft overhead lighting, no people, no visible text.

Three Scoping Mistakes That Add Months to Your CMMC Timeline

June 01, 20266 min read

CMMC Level 2 assessment timelines rarely collapse because of a technical failure. The controls themselves — access control, audit logging, configuration management, incident response — are well-documented, and the NIST SP 800-171A assessment procedures for evaluating them are specific. Contractors who implement controls correctly and document them accurately generally move through assessment on schedule.

What blows out timelines is scoping. Specifically, it is a decision made at the beginning of the program — or a decision that was never made at all — that forces the remediation work to restart from a different boundary than the one the controls were originally built around.

Three patterns account for the majority of assessment timeline failures at the scoping level. Each of them is correctable before assessment begins. None of them are correctable after the assessor has already started.


Mistake 1: Scoping the Entire Company by Default

The most common scoping mistake does not feel like a mistake when it happens. It feels like the conservative choice: put everything in scope, harden everything, leave nothing exposed. If the whole company is in scope, nothing gets missed.

What actually happens is that the remediation budget and timeline are built around an environment far larger than the CUI footprint requires, and the controls work is distributed across systems that will never handle Controlled Unclassified Information.

A defense subcontractor preparing for a Level 2 C3PAO assessment scoped their entire 180-person organization by default. The SSP listed 214 in-scope assets, including HR workstations, accounts payable systems, the marketing team's cloud storage, and conference room AV infrastructure. None of those systems processed, stored, or transmitted CUI. The remediation plan was built to bring all 214 assets into compliance with the applicable controls under AC.1.001, CM.2.061, and SI.1.210. Fourteen months into the program, a pre-assessment review identified that the actual CUI environment was concentrated in 23 systems used by the engineering and program management teams. The boundary was redrawn, and eight months of controls implementation work had to be re-scoped, re-documented in the SSP, and partially rebuilt around the corrected boundary.

The regulation at 32 CFR 170.19 does not require whole-company scope. It requires that the contractor identify and document the assets that will be assessed. For most defense contractors, the CUI environment is a defined subset of the business — and that subset, properly bounded and technically enforced, is the correct assessment scope.


Mistake 2: Documenting an Enclave That Does Not Technically Exist

The enclave strategy — logically or physically segmenting the CUI environment from the broader business network — is a legitimate and well-supported approach under the CMMC scoping rule. Contractors who implement it correctly can reduce their assessment scope and, with it, the remediation cost and ongoing maintenance burden of the program.

The failure mode is documenting the enclave before building it, then scheduling the assessment before the boundary is technically enforced.

A defense sub-tier manufacturer documented a CUI enclave in their SSP covering 18 systems in the engineering and production departments. The enclave diagram showed network segmentation between the CUI environment and the corporate network, with access control enforcement at the boundary. The contractor scheduled a C3PAO assessment nine months after SSP completion.

When the assessment began, the assessor requested network configuration records to verify the segmentation documented in the boundary diagram. The records showed that the VLAN separation described in the SSP had not been implemented. CUI assets were reachable from corporate workstations that the SSP categorized as out of scope. The access controls built to enforce the enclave boundary were configured on a boundary that did not technically exist in the network. The assessment was suspended. The contractor paid the full assessment fee, implemented the actual network segmentation, and rescheduled at full cost six months later.

The enclave in the SSP and the enclave on the network have to be the same enclave. An assessor evaluating CM.2.061 for configuration management and SC.3.177 for network segmentation will verify that the boundary diagram, the network configuration records, and the actual traffic flows are consistent. A boundary that exists only on paper fails that verification regardless of how well the documented controls are implemented.


Mistake 3: Omitting Asset Categorization From the SSP

The CMMC asset category framework — CUI Assets, Security Protection Assets, Contractor Risk Managed Assets, Specialized Assets, Out-of-Scope Assets — exists because not every system in an assessment environment is assessed against the same controls. An identity provider is a Security Protection Asset assessed against controls relevant to identity and access management. A CUI workstation is a CUI Asset assessed against the full 110-control set. A network printer with no CUI access path is an out-of-scope asset with no documentation requirement.

When an SSP lists in-scope systems without category designations, the assessor cannot determine which controls apply to which systems before beginning the assessment. The entire categorization exercise has to happen during the assessment itself, at the assessor's pace, which adds time, adds cost, and produces findings that should have been resolved before the engagement started.

A prime defense contractor submitted an SSP listing 61 in-scope systems. No asset category designations were included. The assessor could not distinguish CUI Assets from Security Protection Assets, could not verify which systems were being assessed against the full control set versus a subset, and could not evaluate whether the contractor's control implementations were mapped to the correct asset categories. The pre-assessment scoping review alone consumed three weeks before the first control objective under AC.2.006 was evaluated. Two systems that should have been categorized as out of scope were found to have CUI access paths that contradicted their implicit treatment in the SSP, requiring boundary redefinition mid-assessment.

Asset categorization is not a documentation formality. It is the framework that tells both the contractor and the assessor what the controls are protecting and how the assessment is structured. An SSP that does not include it forces the assessor to reconstruct that framework from evidence that was never organized to support it.


What the Correction Looks Like

All three of these patterns share a common correction: the scoping work has to happen before the remediation work, not alongside it or after it.

That means reviewing the contracts for DFARS 252.204-7012 references before any system is classified as in scope. It means identifying which systems actually process, store, or transmit CUI before the boundary is drawn. It means deciding whether an enclave strategy is appropriate and, if so, implementing the technical boundary before documenting it in the SSP. And it means assigning asset category designations to every in-scope system before controls implementation begins, so that the work is scoped to the correct controls from the start.

A contractor who completes those steps before the first remediation task is scheduled arrives at assessment with a boundary the assessor can verify, an SSP that accurately describes the environment, and a controls implementation record that maps to the correct assets. That alignment is what a defensible assessment position looks like — and it is built entirely at the scoping stage, before a single technical control is touched.


About Xact Cybersecurity

Xact Cybersecurity is a division of Xact IT Solutions, a cybersecurity compliance firm based in Marlton, NJ, specializing in CMMC Level 2 preparation and assessment readiness for defense contractors and members of the Defense Industrial Base. Xact IT Solutions holds the GTIA Cybersecurity Trustmark Assured credential, meaning its internal operations have been independently validated against the same standards they help clients achieve.

For defense contractors with questions about assessment scope, CUI boundary definition, or CMMC Level 2 readiness, the Xact Cybersecurity team offers a free 30-minute strategy call. Schedule at getready4cmmc.com/free-cmmc-strategy-call or contact the team directly at [email protected] | 856-282-4100 | 1 Executive Drive Suite 100, Marlton, NJ 08053.

Back to Blog