Building Your CMMC System Security Plan (SSP): A Guide for Arizona Contractors

The SSP is the document your C3PAO will scrutinize most

The System Security Plan is the cornerstone of your CMMC compliance program. It documents how your organization implements each of the 110 NIST SP 800-171 security controls, describes your CUI environment boundary, and maps the responsibilities between your team, your MSP, and your cloud providers.

When a C3PAO conducts your CMMC Level 2 assessment, the SSP is the first document they review. Every control implementation statement, every boundary diagram, every inherited control must be accurate and current. A weak SSP doesn’t just delay your assessment. It can fail it.

SSP structure

Your SSP should cover:

  • System description: What your CUI environment looks like, hardware, software, network topology, data flows
  • System boundary: Which systems are in scope and which are out of scope for CUI processing
  • Control implementation: For each of the 110 controls, how your organization satisfies the requirement
  • Interconnections: How your systems connect to external networks, cloud services, and business associates
  • Shared responsibility: Which controls your MSP or cloud provider handles vs. which you handle internally

Defining your CUI boundary

The most critical decision in your SSP is scoping. A smaller, well-defined boundary means fewer systems to secure, fewer controls to document, and a faster assessment. Arizona defense subcontractors often make the mistake of including their entire IT environment in scope when only a subset actually processes CUI.

Best practice: isolate CUI processing to a defined enclave, separate network segment, dedicated workstations, restricted cloud tenant. Document the boundary clearly in your SSP with network diagrams showing exactly where CUI lives and how it’s protected from the rest of your environment.

Documenting shared responsibility

If you use an MSP or cloud provider for any portion of your security controls, your SSP must document the shared responsibility. For example:

  • Your MSP handles patch management (3.14.1) but you handle physical security (3.10.1)
  • Your cloud provider encrypts data at rest (3.13.11) but you manage access controls (3.1.1)
  • Your security tools provide audit logging (3.3.1) but you review the logs (3.3.5)

Each inherited control needs documentation from your provider showing how they satisfy it. Your SPRS score must reflect the actual implementation status of every control, including inherited ones.

Building your SSP

Asteroid IT helps Arizona defense contractors build comprehensive SSPs using Continuum GRC (FedRAMP-authorized). We document every control, map shared responsibilities, and prepare your evidence packages for C3PAO assessment.

We serve defense contractors across Chandler, Mesa, Tucson, and the greater Phoenix area.

Call us at 480-937-7021 or schedule a conversation.

Scroll to Top