How should organisations scope a System Security Plan for CMMC compliance?

Why This Matters for Security Teams

A system security plan is not a paper exercise for CMMC. It is the assessment object that shows whether the organisation can defend the system boundary it claims, and whether those claims match the actual flow of CUI and FCI. Weak scoping usually creates one of two problems: either the boundary is drawn too narrowly and misses connected services, or it is drawn so broadly that control ownership becomes unclear. Both outcomes increase assessment risk and remediation cost. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces the need to understand assets, dependencies, and governance before trying to prove control coverage. For CMMC, the SSP should make the assessor’s job straightforward: identify the in-scope system, explain how it stores, processes, or transmits covered information, and show where supporting services sit relative to the boundary. That includes identity services, logging, remote access, backups, and cloud integrations when they materially affect the protected environment. Current guidance suggests treating “shared” infrastructure cautiously, because shared does not mean out of scope if it can influence confidentiality or integrity. In practice, many security teams discover boundary weaknesses only after a supplier connection, admin path, or cloud dependency has already undermined the original scope decision, rather than through intentional scoping discipline.

How It Works in Practice

Scoping a CMMC SSP starts with asset and data mapping, then moves to control assignment. The organisation should identify every component that touches CUI or FCI, define whether it is inside the boundary, and document the trust relationships that make that decision defensible. This includes user endpoints, servers, SaaS platforms, identity providers, management planes, backup systems, and any third-party service that can administer or route data into the environment. A practical SSP usually documents:

• What information types are handled, and where each type is created, stored, processed, or transmitted.
• What systems sit inside the assessment boundary versus what supports the boundary from outside.
• Which connections are approved, monitored, and restricted, including remote administration and API integrations.
• Which controls are inherited from a parent organisation, cloud provider, or managed service.
• How identities, privileges, and secrets are governed across the scoped environment.

This is where identity architecture matters. If a cloud console, CI/CD pipeline, or privileged service account can access CUI, then its controls and dependencies belong in the scoping conversation even if the data itself is hosted elsewhere. The same is true for non-human identities that maintain, move, or transform information. NHI governance is often overlooked, yet it can determine whether the assessor views a connected service as part of the security boundary. The OWASP Non-Human Identity Top 10 is relevant when those identities are used to automate access, orchestration, or data handling. The SSP should also cross-reference the control baseline so each in-scope component has a clear control owner. In many environments, mapping the boundary to control inheritance is more important than producing a large asset inventory, because assessors need to see how the organisation prevents uncontrolled access and unmanaged pathways. These controls tend to break down when the environment relies on ad hoc exceptions, shadow SaaS, or unmanaged privileged integrations because the documented boundary no longer matches operational reality.

Common Variations and Edge Cases

Tighter scoping often reduces assessment complexity, but it also increases the burden of proving that excluded assets truly cannot affect the CUI or FCI environment. Organisations have to balance a narrower boundary against the risk of hidden dependencies, especially where cloud tenancy, shared identity services, or centralised logging create indirect access paths. Best practice is evolving for modern hybrid and SaaS-heavy environments, and there is no universal standard for this yet. Edge cases usually involve services that are not obvious data repositories. A ticketing platform, remote support tool, backup vault, or endpoint management console may not store CUI directly, but it can still expose it through attachments, sessions, exports, or admin actions. That is why scope decisions should be based on actual data flow and administrative reach, not on system labels alone. Where a provider hosts parts of the environment, the SSP should distinguish between inherited controls, customer-responsible controls, and exclusions that depend on contractual or technical separation. For organisations with automated workloads, NHI controls are part of the edge-case analysis, not an afterthought. If machine credentials can pivot across environments, their lifecycle, rotation, and least-privilege design can affect scope and evidence quality. A detailed SSP should make those dependencies visible rather than treating them as implementation detail. In borderline cases, the safest approach is to include the supporting service in scope until the organisation can demonstrate a defensible separation model.

Related resources from NHI Mgmt Group

• How should organisations govern AI use when responsibility is split across security, legal, HR, and compliance?
• What should organisations do when system scope changes for an AI agent?
• What do security teams get wrong when choosing a CMMC compliance partner?
• How do organisations know if IAM is actually improving security and compliance?