System Security Plan

The system security plan is the one document a CMMC assessment cannot proceed without.

The plan is the document that describes your system and how it meets each requirement. 32 CFR 170.24(c)(2)(i)(5) requires one in place at the time of assessment, describing each information system in the CMMC assessment scope. The absence of an up to date plan results in a finding that an assessment could not be completed, due to incomplete information and noncompliance with 48 CFR 252.204-7012. Every other requirement failure costs points. This one stops the assessment itself. Out of date carries the same consequence as missing, so a plan written for the environment you had two migrations ago does not protect you.

There is no POA&M escape for this requirement.

32 CFR 170.21(a)(2)(iii) names CA.L2-3.12.4 among the requirements that may never appear on a POA&M, the plan of action and milestones that defers unmet requirements. There is no conditional status to fall back on if the plan is not ready. Finish the system security plan before you schedule the assessment, and treat every review between now and then as a chance to find what it fails to describe.

Objectives [a] through [h] are the table of contents. Write to the letters.

Describe the boundary for [b] and the environment of operation for [c]. Identify the non-applicable requirements for [d]. Describe the implementation method for each security requirement for [e] and the relationships and connections to other systems for [f]. Define an update frequency for [g], and demonstrably honor it for [h]. An assessor walks these letters in order, so a plan organized around them assesses smoothly and a plan organized around a marketing template does not.

Objective [e] wants a narrative per requirement: what you do, not what the requirement says.

For each security requirement, write a brief description of how your organization implements it, addressing the objectives, and reference the policy or procedure that carries the detail. Avoid two failure modes. The shell plan only points elsewhere for every answer. The kitchen-sink plan buries implementation statements in hundreds of pages of pasted boilerplate. Both force the reader to hunt, and the reader is scoring you. The guide is explicit that the plan may be a collection of documents. The narrative is the map that makes the collection usable.

The environment of operation is people, facilities, and workflow, not an operating system inventory.

Objective [c] asks where and how the system operates. Cover what the business does, where CUI, the Controlled Unclassified Information you handle, enters and moves, who touches it, and in what physical surroundings. A few honest paragraphs covering the people, the technology, and the facilities give the assessor the context every later answer hangs on.

Objective [d] is the commonly missed letter: not applicable is a ruling, not a self-assessment.

Requirements you treat as non-applicable must be identified and approved by the designated authority. Under 32 CFR 170.24(c)(2)(i)(8), the ruling comes from the DoD CIO: an adjudication that a requirement is not applicable, or that an alternative security measure is equally effective. That adjudication must be included in the system security plan to receive consideration during an assessment. Claiming adjudicated non-applicability on your own authority and documenting nothing invites the assessor to score the requirement as unmet.

The boundary description in [b] is what makes every scoping argument stick.

Say which assets are inside, which are outside, and what separates them, with a diagram. The enduring exceptions that 32 CFR 170.24(b)(1)(i) assesses as MET also live here, described with their mitigations. When an assessor questions whether a device is in scope or a gap is acceptable, the answer either sits in the system security plan already or turns into a finding.

Update on a defined cycle, and prove it.

Objective [g] wants the frequency defined, and [h] wants it honored. The guide's stated norm is at least annually, and 32 CFR 170.4 caps any periodic interval at one year anyway. Keep a revision history with dates and what changed, and update off-cycle when the environment shifts: a new cloud service, a dropped connection to a partner, a moved office. The revision log is the cheapest evidence in the whole plan, and it is the first place an assessor looks to test whether the document is alive.