1Overview
CA.L2-3.12.4 closes the Security Assessment family with the requirement that anchors the entire program: the system security plan. It requires that the organization develop, document, and periodically update system security plans that describe the system boundary, the environment of operation, how security requirements are implemented, and the relationships with or connections to other systems. It carries a single point, but it is one of the named exclusions that cannot be placed on a plan of action, because the SSP is the document an assessment is conducted against.
The system security plan, the SSP, is the description of how the organization meets its security requirements. It defines what is in scope by describing the system boundary and its environment of operation, records how each security requirement is implemented, notes any requirements approved as non-applicable, and captures the system's connections to other systems. Every other control is described somewhere in this document, which is why an assessor reads the SSP first and measures the environment against it. Its single point understates its role: without an SSP, there is nothing to assess, which is why it is named as a requirement that cannot be deferred. It has eight assessment objectives, the most in this part of the family, covering the plan's development, its required contents, and its ongoing update.
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.
The requirement names development, documentation, and periodic update of the SSP, and the eight assessment objectives detail the contents it must carry. The plan must be developed; the system boundary described and documented; the environment of operation described and documented; requirements approved as non-applicable described and documented; the method of implementing each requirement described and documented; the relationship with or connection to other systems described and documented; the frequency to update the plan defined; and the plan updated at that frequency. Together these make the SSP a complete and current description of the system and how it is secured.
2The Assessment Objectives
NIST SP 800-171A decomposes 3.12.4 into eight objectives: develop the plan, document its six required elements, and keep it updated.
A system security plan is developed. The SSP exists.
The system boundary is described and documented in the SSP. What is in scope is defined.
The system environment of operation is described and documented in the SSP. The operating environment is recorded.
The security requirements identified and approved by the designated authority as non-applicable are identified. Any requirements treated as non-applicable are identified and carry the approval of the designated authority, rather than being set aside informally.
The method of implementing each security requirement is described and documented in the SSP. How each requirement is met is recorded.
The relationship with or connection to other systems is described and documented in the SSP. Connections to other systems are recorded.
The frequency to update the SSP is defined. How often the plan is updated is set.
The SSP is updated with the defined frequency. The plan is kept current.
The eight objectives are development [a], the six documented contents [b] through [f] plus the boundary and environment, and the update cycle [g] and [h]. The common gaps are at objective [e], where implementation of each requirement is not fully described, and at [h], where the plan is developed but never updated as the system changes. The assessor reads the SSP against the environment, so all eight have to hold.
3Failure Patterns
The failures are about an SSP that is incomplete or out of date.
No SSP, or a skeletal one
Without a developed SSP, or with one that omits the required contents, there is no complete description to assess against. The plan has to be developed and carry all its required elements.
Implementation not described
An SSP that lists requirements but does not describe how each is implemented leaves the assessor without the account the objective calls for. The method of implementing each requirement has to be documented.
Boundary or connections unclear
An SSP that does not clearly define the system boundary or document connections to other systems leaves scope and data flows ambiguous. Both have to be described and documented.
Never updated
An SSP written once and left as the system changes drifts from reality, describing an environment that no longer exists. A defined update frequency and actual updates keep it current.
4Ownership
This is a security and compliance-owned control, drawing on the whole program.
| Role | Responsibility for this control |
|---|---|
| Security or compliance lead | Develops, documents, and updates the SSP across all its required contents. Owns the SSP. |
| IT and system administrator | Supplies the boundary, environment, implementation, and connection detail the SSP records. |
| Program lead | Defines the update frequency and confirms the SSP is kept current. |
5Tooling
The control is delivered by a complete, maintained system security plan.
| Objectives | Tooling | What it provides |
|---|---|---|
| [a] | System security plan document | The developed SSP. |
| [b], [c], [f] | Boundary, environment, and connection documentation | The system described in scope and context. |
| [d], [e] | Requirement implementation and non-applicability records | How each requirement is met or why it does not apply. |
| [g], [h] | Defined update frequency and update process | The SSP kept current as the system changes. |
The caveat is that the SSP has to be both complete across all its contents and kept current. A plan missing implementation detail, boundary, or connections, or one that is never updated, fails the objectives the assessment reads first. Because this control is a named exclusion, it cannot be deferred, so all eight objectives have to hold at assessment.
6Evidence
The satisfied version of 3.12.4 is a complete, current SSP.
| Evidence | What it demonstrates |
|---|---|
| System security plan | Objectives [a] through [f]. A developed plan documenting boundary, environment, non-applicable requirements, implementation, and connections. |
| Defined update frequency | Objective [g]. How often the SSP is updated. |
| SSP update history | Objective [h]. The plan kept current. |
The evidence is the SSP itself, complete across its required contents, together with a defined update frequency and a history of updates. Because the assessment is conducted against the SSP and this control cannot sit on a plan of action, the plan has to be complete and current at the time of assessment.
The SSP is the document the assessment is measured against
Every control is described somewhere in the system security plan, and an assessor reads it first, so a plan that is complete and current is foundational, and as a named exclusion it cannot be deferred. Building an SSP that fully describes the system and stays current is central to the onsite readiness work this practice does.
Start CMMC Readiness or call 802-335-26627Sources
- NIST Special Publication 800-171 Rev 2, Protecting Controlled Unclassified Information in Nonfederal Systems and Organizations, requirement 3.12.4. csrc.nist.gov
- NIST Special Publication 800-171A, Assessing Security Requirements for Controlled Unclassified Information, assessment objectives 3.12.4[a] through 3.12.4[h]. csrc.nist.gov
- 32 CFR 170.21, Plan of Action and Milestones Requirements, which names CA.L2-3.12.4 among the requirements that may not be placed on a plan of action. ecfr.gov