The Enclave-Only Boundary

Apply the test 'does it process, store, or transmit CUI - or does it protect something that does?' rather than 'who owns it.'

• Engineering enclave (40 endpoints): CUI assets. Clearly in scope.
• MES server: CUI asset. It is used to view CUI drawings, even intermittently. Intermittency does not exempt an asset; it changes frequency of assessment sampling, not scope. In scope unless CUI access is removed and segmentation is demonstrated.
• SaaS ERP (no CUI, FedRAMP Moderate): Out of scope for CUI handling, provided no CUI path or credential/trust relationship bridges it into the enclave. Its authorization still matters as a prerequisite if it touches anything in scope.
• SIEM and vulnerability scanner: Security protection assets. In scope, but assessed for their protective function, not as general-purpose systems.
• Badge/access-control server: Security protection asset if it enforces physical access to areas housing CUI assets. In scope on that basis; if it only governs lobbies and parking, document the exclusion.
• Leased laptop used at customer sites: CUI asset (or specialized asset, depending on function) - it stores and transmits CUI off-site. In scope, and a strong candidate for remote-work controls.

Categories used here map to the scoping concepts in 32 CFR Part 170 (CUI assets, security protection assets, contractor risk managed assets, specialized assets, out-of-scope assets); confirm current terminology before finalizing the diagram.

Segmentation is permitted, but the burden of proof sits with the organization and must be current, not aspirational.

What must be true

• CUI access from the MES is removed - not 'rarely used.' No CUI shares, no mapped drives, no cached drawings, no shared service accounts with enclave reach.
• Network controls enforce the separation (ACLs, VLAN/firewall rules, no routing or trust relationship), and the separation is documented in the boundary diagram and data-flow description.
• Administrative tooling also respects the line: if a single domain admin account and a single SIEM collector span both sides, the isolation is cosmetic.

Evidence you would expect

• Current network diagram and data-flow diagram showing no CUI path.
• Firewall/proxy rule exports and a walkthrough or observation of the configuration.
• Asset inventory and a file-share scan showing no CUI on the MES.
• Interviews with the engineers who previously opened drawings, confirming workflow change and where they now view CUI.
• A change record and date for the isolation, so the assessor can judge whether it has been operating long enough to be credible.

If any of these are missing, the defensible position is to bring the MES into scope and assess it. Management's 'IT-owned' argument is not a scoping criterion.

The current diagram is not a boundary; it is a subset. Before assessment:

1. Redraw the boundary to include the MES (or the documented isolation), the SIEM and scanner, the badge server (if protective), and the leased laptop's remote-use profile. Out-of-scope items need their own depiction with the specific control that prevents CUI connectivity.
2. Add a data-flow view showing where CUI is created, received, stored, transmitted, and destroyed - including the leased laptop's path back into the enclave and any cloud synchronization.
3. Reconcile the asset inventory to the diagram; a mismatch between the two is itself a finding under configuration management and asset accountability.
4. Extend the SSP to describe each newly in-scope asset, its inherited vs. implemented controls, and the responsible owner.
5. Re-run scope validation with the C3PAO before the assessment window. Discovering a CUI-bearing MES mid-assessment is far more expensive than adding it now - it can force re-planning, additional sampling, and rescheduling.
6. Fix the governance story. The 'IT-owned' rationale signals that no one owns the boundary. Name an owner and a change process, because the boundary will drift the moment the assessment ends.