Skip to content
ControlVerdict
Sign in
CA.L2-3.12.4CMMC Level 2Level 2

System Security Plan

Submit your own example

Practice statement

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.

Quoted verbatim from NIST SP 800-171 Rev. 2 §3.12.4.Source

The source document’s non-normative “Discussion” section is not reproduced here. ControlVerdict quotes normative text verbatim or omits it — it never paraphrases a standard. Follow the source link above for the full context.

Assessment Objectives(8)

An assessor determines each objective separately. “Mostly implemented” is not a result — every objective below has to stand on its own.

  1. [a]

    a system security plan is developed;

    1 example covers this

  2. [b]

    the system boundary is described and documented in the system security plan;

    1 example covers this

  3. [c]

    the system environment of operation is described and documented in the system security plan;

    1 example covers this

  4. [d]

    the security requirements identified and approved by the designated authority as non-applicable are identified;

    No example covers this objective yet. Submit your own example.

  5. [e]

    the method of security requirement implementation is described and documented in the system security plan;

    1 example covers this

  6. [f]

    the relationship with or connection to other systems is described and documented in the system security plan;

    1 example covers this

  7. [g]

    the frequency to update the system security plan is defined; and

    1 example covers this

  8. [h]

    system security plan is updated with the defined frequency.

    1 example covers this

Objective text quoted verbatim from NIST SP 800-171A via the CMMC Level 2 assessment guide.

Implementation examples(1)

Submit your own example
  • addresses
    CA.L2-3.12.4System Security Plan
    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.

    • [a]

      a system security plan is developed;

    • [b]

      the system boundary is described and documented in the system security plan;

    • [c]

      the system environment of operation is described and documented in the system security plan;

    • [e]

      the method of security requirement implementation is described and documented in the system security plan;

    • [f]

      the relationship with or connection to other systems is described and documented in the system security plan;

    • [g]

      the frequency to update the system security plan is defined; and

    • [h]

      system security plan is updated with the defined frequency.

    SSP kept in version control: boundary diagram, per-practice narrative, quarterly refresh

    ControlVerdict Corpus@cv-corpusOSCJul 31, 2026
    Community is just starting — add yours. No verdicts yet.

    Implementation

    AO coverage. Claims objectives [a], [b], [c], [e], [f], [g], and [h]. Out of scope for this example: [d] (identifying requirements approved as non-applicable) — this OSC's authorizing official has not designated any Level 2 requirement non-applicable, so there is nothing to document and the objective cannot honestly be demonstrated by this pattern. An organization with an approved non-applicable determination should cover [d] with a separate narrative and the approval record.

    The plan exists and is owned. The SSP is a set of Markdown files under version control, owned by the ISSO, with pull requests required for changes. Rendering to a PDF for customers is a build step, so the document a customer receives and the document we maintain cannot drift apart.

    Boundary. A dedicated section states what is inside the assessment boundary and — just as importantly — what is outside and why: corporate IT that cannot reach the enclave, the guest network, and the separately scoped manufacturing cell. Assets inside the boundary are enumerated by category with counts that reconcile to the asset inventory.

    Environment of operation. Describes the physical sites, the hosting model, the identity architecture, network segmentation, the user populations and their roles, and the data flows for CUI from receipt through storage, processing, and transmittal back to the customer. Diagrams are generated from a text source so a diagram change is a reviewable diff.

    How each requirement is implemented. Every practice has a narrative describing the actual mechanism, the responsible role, and where the evidence lives — written to be understood by an assessor who has never seen our environment. Practices implemented by an external service provider say so explicitly and name the shared-responsibility split.

    Connections to other systems. A table lists every external system with a connection to the boundary: the customer file exchange portal, the provider's remote management platform, the payroll integration, and the backup destination. Each entry names the interface, the data crossing it, the authorization document, and the security requirements imposed.

    Update frequency [g] and practice [h]. Policy sets a quarterly review and an immediate update on material change — new system, new connection, changed provider, or a practice implemented differently. Each quarterly review closes with a signed change log entry, even when the conclusion is that nothing changed.

    Accepted gap. The manufacturing cell narrative is thinner than the enclave narrative because that scope is still being formalized. Its current state is described honestly rather than aspirationally, and the completion is a plan-of-action item.

    What the evidence looks like

    • SSP document set with commit history showing quarterly reviews and change reasons
    • Boundary section and generated diagram, reconciled to the asset inventory count
    • External connections table with the authorization reference for each entry
    • Two practice narratives showing mechanism, responsible role, and evidence location
    • Signed change log entry from the most recent quarterly review

    Environment

    Defense electronics supplier, ~260 staff. One CUI enclave plus a separately scoped manufacturing cell. The SSP is authored as Markdown in a private repository with the boundary diagram generated from a text source.

    Tools

Discussion(0)

No discussion on this control yet

Edge cases, scoping questions, and “would this pass?” scenarios belong here.

Sign in to start a thread.