# CMMC Level 2 System Security Plan (SSP) outline

> **Review with counsel before use.** This outline is a starting structure for a System Security Plan under NIST SP 800-171 Revision 2, the version DFARS 252.204-7012 and CMMC Level 2 use today. It is not legal advice and it does not replace the requirements themselves. Your contract clauses, your assessor and your counsel decide what your SSP must contain.
>
> Outline from AccuSights, https://accusights.com/templates

---

A System Security Plan is required by requirement 3.12.4 (CA.L2-3.12.4). It cannot be put on a POA&M, and without one the DoD Assessment Methodology treats the assessment as not complete.

## 1. System identification

- System name and unique identifier
- Company legal name, CAGE code and address
- System owner, security contact and the senior official who affirms compliance
- Plan version, date and approver

## 2. System description and purpose

- What the system does and which contracts it supports
- The types of information it handles: FCI, CUI, and the CUI categories involved

## 3. Boundary and data flows

- The boundary of the assessed system: which networks, sites, cloud services and people are inside it
- A data-flow diagram showing where CUI enters, is stored, is processed and leaves
- Whether CUI is contained in an enclave or spread across the corporate network

## 4. Asset inventory by category

| Category | Treatment | Assets |
|---|---|---|
| CUI assets | Hold or move CUI. Fully in scope. | |
| Security protection assets | Protect CUI assets (firewall, identity provider, logging). In scope. | |
| Contractor risk managed assets | Can reach CUI but are not meant to; covered by policy. Documented here. | |
| Specialized assets | Test equipment, operational technology, government-furnished equipment. Documented, with their own risk treatment. | |
| Out-of-scope assets | Cannot reach CUI, separated physically or logically. | |

## 5. Environment

- Network architecture and segmentation
- Cloud services that store CUI, and how each meets the FedRAMP Moderate baseline or its equivalent under DFARS 7012
- Email and file platform (for example Microsoft 365 GCC High or a dedicated enclave)
- External service providers and what each is responsible for

## 6. Roles and responsibilities

- Who owns each requirement family
- Who approves access, changes and exceptions
- Who reviews logs and responds to incidents

## 7. Requirement implementation

For each of the 110 requirements, record:

- Requirement number and text
- Status: implemented, not implemented (with a POA&M reference where the rule allows one), or not applicable (with the reason)
- Implementation statement: how the requirement is met in this environment, in specific terms
- Responsible party, including any inherited from a provider
- Evidence: the policy, configuration, record or screenshot that proves it

| Family | Section | Requirements |
|---|---|---|
| Access Control | 3.1 | 22 |
| Awareness and Training | 3.2 | 3 |
| Audit and Accountability | 3.3 | 9 |
| Configuration Management | 3.4 | 9 |
| Identification and Authentication | 3.5 | 11 |
| Incident Response | 3.6 | 3 |
| Maintenance | 3.7 | 6 |
| Media Protection | 3.8 | 9 |
| Personnel Security | 3.9 | 2 |
| Physical Protection | 3.10 | 6 |
| Risk Assessment | 3.11 | 3 |
| Security Assessment | 3.12 | 4 |
| System and Communications Protection | 3.13 | 16 |
| System and Information Integrity | 3.14 | 7 |
| **Total** | | **110** |

## 8. Plan of action and milestones (POA&M)

- A reference to the separate POA&M for any requirement not yet met
- Note: only some requirements may sit on a POA&M for CMMC Level 2, and open items must be closed within 180 days

## 9. Plan maintenance

- Review at least yearly and after significant changes to the system
- Version history with the date and the approver of each change

More on CMMC: https://accusights.com/frameworks/cmmc/checklist and https://accusights.com/guides/cmmc/nist-800-171
