Requirement
NIST SP 800-171 REV.2 / CMMC 2.0 Level 2 - Control - CA.L2-3.12.4 – Develop, document, and periodically update system security plans that describe system boundaries, system environments of operation, how security requirements are implemented, and the relationships with or connections to other systems.
Understanding the Requirement
This control (from NIST SP 800-171 REV.2 / CMMC 2.0 Level 2) requires your organization to produce and maintain a System Security Plan (SSP) that clearly documents what your information system is, where it begins and ends, how and where it operates, which security controls are applied (or why any are non‑applicable), and how the system connects to other systems. The SSP should identify roles and responsible personnel, describe data types (for example, Controlled Unclassified Information), map the network and interfaces, and include a defined cadence for review and updates so the plan remains accurate over time.
Technical Implementation
- Create a baseline SSP document: Start with a concise template that includes system name, owner, authorizing official, and key contacts. Add sections for system purpose, users and roles, data types (e.g., CUI), and a summary of implemented controls versus planned controls.
- Define and document system boundaries and environment: Produce a clear statement of the system boundary (what is in scope vs out of scope) and a short narrative of the environment of operation (on-prem servers, cloud services, third‑party hosted components). Use a simple annotated network diagram to illustrate boundary points, ingress/egress, and trust zones.
- Map controls to implementation: For each required security control, record the implementation method (policy, configuration, tool, or compensating control), the responsible owner, and the verification method (logs, tests, or audits). Mark any control deemed non‑applicable and record the approved rationale and authority that approved the exclusion.
- Document interfaces and system relationships: List all external connections, API integrations, partner systems, and remote access methods. For each connection, document purpose, data flows, authentication methods, and any associated service agreements or security requirements.
- Maintain an inventory and reference lists: Reference your hardware and software inventory within the SSP (or provide a linked inventory file). Include versions, owner, and criticality so changes can trigger SSP updates.
- Establish update frequency and version control: Define a review cadence (e.g., every 6 months or after major changes) and a change management process for updating the SSP. Keep version history, approval signatures, and a changelog of why updates were made. Assign responsibility to an information security role and ensure system/network administrators are involved in reviews.
Example in a Small or Medium Business
A 40‑employee engineering firm that handles CUI creates an SSP to centralize how it meets security obligations. The IT manager drafts the SSP listing the primary system (on‑prem file server, employee workstations, and a cloud backup service), names the system owner and the security contact, and describes the system purpose (project file storage and collaboration). They include a network diagram showing the office LAN, firewall, VPN concentrator for remote access, and the cloud backup endpoint. Each required control is listed with the current implementation (e.g., MFA for VPN, disk encryption on laptops) and planned actions for missing controls (such as automated vulnerability scanning). The SSP documents all external links to client portals and the backup provider, and the firm’s CIO approves non‑applicability decisions with written rationale. The firm sets a bi‑annual review schedule and ties SSP updates to its change control process so any infrastructure change triggers an SSP update. During a quarterly security review, the IT manager updates the inventory and records a minor architecture change with an updated diagram and versioned entry in the SSP.
Summary
Producing a concise, authoritative System Security Plan that documents system boundaries, environment of operation, control implementation, and inter-system relationships gives SMBs a practical road map to meet CA.L2-3.12.4. Combine clear ownership, an inventory and network diagram, a mapped list of implemented and planned controls, and a defined review cadence to keep the SSP current. This mix of policy documentation and technical detail not only satisfies the requirement but also becomes a living tool for managing risk, guiding audits, and coordinating system changes.