CA.L2-3.12.4 System security plan: requirements and evidence

What the CMMC system security plan requirement asks for and why it decides the assessment

If your organization is preparing a Level 2 self-assessment or certification and your system security plan (SSP) is missing or out of date, the assessment cannot be completed until it is fixed. CA.L2-3.12.4 requires you to develop, document and periodically update an SSP that describes your system boundary, the environments where the system operates, how each security requirement is implemented, and how the system connects to other systems. The Level 2 requirements are the NIST SP 800-171 Rev. 2 set, and CA.L2-3.12.4 is the Level 2 version of its requirement 3.12.4. The requirement carries no point value under 32 CFR 170.24, so it does not affect your score in the way a technical control does. Its weight is procedural: without an up-to-date SSP at the time of assessment, the assessment cannot be finished. That is why this requirement, not a control with a higher score, often decides whether an assessment proceeds.

The SSP cannot be placed on a plan of action and milestones. Under 32 CFR 170.21, CA.L2-3.12.4 is one of six requirements that may never be placed on a POA&M, so a missing or stale SSP cannot be deferred with a remediation date. The practical consequence is that the SSP must exist and reflect the current system before assessment day, and the assessor will check that the document matches what is actually deployed. The Department of War suspended CMMC Phase II on 13 July 2026 and started a 60-day review, but Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. Confirm the current timing with your contracting officer and the DoW CIO About CMMC page before you set your own internal dates.

The SSP is often the hardest document to keep current because it is only as accurate as the last change to the environment. Each new cloud service, subnet, remote access path, vendor connection or change in how a requirement is met can make a section wrong. The update frequency you define must be at least annual under the CMMC Assessment Guide, but a plan that is reviewed once a year and changed only at that point will drift. Assign a named owner, tie SSP reviews to change control and to each significant change in scope, and keep records of reviews and updates, since the NIST assessment guidance treats those records as evidence. Ask your assessor or Registered Practitioner Organization which SSP format and evidence they expect before you invest in a template.

Which systems, boundaries and connections the SSP must cover

The SSP is only as accurate as its boundary. The decisions below determine which systems, services and connections the plan must describe, and each one changes how large and how detailed the document becomes. Settle them before writing, because an assessor will test the SSP against what is actually running.

The CUI-handling system boundary

The boundary is the first decision. It sets which assets store, process or transmit CUI and which support them, such as identity, logging and administration systems. The SSP must name every component inside that boundary and explain why each one is there. Check that the boundary matches your data flow diagrams, not only your org chart. A boundary drawn too narrowly is a common reason an assessor finds the SSP does not describe the real system.

Enclaves and segregated environments

If CUI is confined to a separate enclave, the SSP must describe that enclave as its own system with its own components, and must describe how it is isolated from the rest of the network. Document the enforcement points, such as firewalls and access control lists, and show how traffic into and out of the enclave is controlled. Each enclave that is left out of the SSP is an undocumented path for CUI, so confirm that the enclave description covers every route in and out.

Cloud and managed service providers

Any cloud service or managed service provider that stores, processes or transmits CUI, or that can administer systems inside the boundary, belongs in the SSP. The plan must name the provider, the service, where the data resides and what responsibilities the provider carries and which ones you keep. Ask each provider for its own assessment evidence and document how that evidence feeds your implementation statements. Do not assume a provider's certification covers your configuration.

Remote and mobile access paths

Remote sessions, VPN concentrators, virtual desktops and mobile devices that reach CUI each create a connection the SSP has to describe. Document how each path authenticates users, what devices it accepts and where session logs are kept. Include administrative access from outside the office, because support staff often reach the boundary by routes that were never added to the plan. Walk each path with the people who use it before writing it down.

Third-party and external system connections

Every connection to another system, whether a customer portal, a subcontractor exchange, a software update source or a service that sends data in, is a connection the SSP must record. For each one, state the direction, the data exchanged, the protection in transit and the owner of the connection. Keep a current inventory of these links and tie it to the document, since connections are the part of an SSP that changes most often between reviews.

Specialized assets such as OT and test equipment

Operational technology, lab instruments, machine controllers and test equipment often sit outside standard IT inventories yet connect to systems that handle CUI. Decide whether each one is inside the boundary, and if it is, document its configuration, access and update method. If an asset is excluded, the SSP should still explain why it does not handle CUI and how it is separated. Confirm the treatment of these assets early, because their documentation is often the slowest part to assemble.

What the SSP must contain and how an assessor reads it

The system security plan is the document an assessor reads first, because it defines what is being assessed. The CMMC Assessment Guide Level 2 lets a contractor choose its own SSP format, but it sets minimum contents: the assessment scope, the environment of operation, how each requirement is implemented, the connections to other systems, and an update frequency of at least annually. A format that omits any of these leaves the assessor with no basis for testing the rest of the 110 Level 2 requirements. Before writing, confirm the current version of the Assessment Guide, since the Department of War has changed CMMC timing and the guidance it points to.

NIST SP 800-171A breaks CA.L2-3.12.4 into eight assessment objectives, and an assessor checks each one against the document. The SSP must document the system boundary and the environment of operation. Any requirement judged not applicable needs a recorded decision and approval, not silence. Each requirement must have a description of how it is implemented, and the SSP must name the connections to other systems. The organization must also define an update frequency and show that it meets it, which means dated revisions and records of reviews. Ask whether the boundary in the SSP matches the actual asset inventory, cloud tenants and enclaves, because a mismatch there invalidates the scope of every other finding.

Read the SSP as the baseline against which the other requirements are checked. An assessor who finds a control described in the SSP will look for the configuration, log, ticket or policy that proves it, and a description with no matching evidence is a gap. For this reason, the implementation statements should cite the artifacts that back them, such as the audit log settings, access review records or change tickets listed under the other domains. Organizations often assign one owner per requirement family and require that owner to confirm the statement before each review cycle. If the SSP and the evidence disagree, the disagreement is itself a finding, so reconcile them before the assessment begins.

How an assessor tests CA.L2-3.12.4

This table compares what an assessor does, what they ask you to produce, and where SSPs usually fail for CA.L2-3.12.4. Read each row as a test the assessor runs against your SSP and your live environment. A NOT MET mark in a Level 2 self-assessment produces a No Score in SPRS, so the SSP needs to match the system before you score anything.

Test area	What the assessor does or asks for	Where it usually fails
Examine the SSP and development records	Reviews the final SSP and the procedures and records for how it was developed, covering the system boundary, environment of operation, requirements marked not applicable, and how each requirement is implemented	SSP is a draft, or the development records do not show who approved the final version
Interview SSP owners	Asks the people who write and maintain the SSP how it is kept current, who signs off on changes, and how it reflects the system as it runs today	Owners describe a process that the document does not show, or cannot name who updates the SSP after a change
Test the SSP against the live environment	Compares the boundary, asset list, connections to other systems and implementation statements with the network, cloud accounts and configurations the assessor can observe	SSP boundary omits a cloud tenant, remote access path or external service that carries CUI
Confirm requirement implementation statements	Checks that each requirement marked implemented has a description that matches how the control actually works, with a traceable reference to the supporting configuration or record	Requirements marked implemented with generic text that could apply to any system
Check the defined update frequency	Looks for an update frequency that the organization has defined and follows, with the CMMC Assessment Guide minimum of at least annually as the baseline for the SSP contents	No update frequency is stated, or the SSP shows a revision date older than the defined interval
Review SSP review and update records	Requests records of past SSP reviews and updates, such as change entries tied to system changes, to show the document tracks the environment over time	No review history exists, or changes to systems were made without a corresponding SSP update
Review enterprise architecture documentation	Requests network diagrams, data flow diagrams and architecture records that support the boundary and connections described in the SSP	Diagrams are out of date, do not show the same boundary as the SSP, or are missing for external connections
Confirm evidence is in final form	Accepts only final evidence for MET determinations under the assessment objectives in NIST SP 800-171A, so drafts or unsigned versions do not count	Drafts, placeholder text or unreleased revisions are presented as the current SSP

How to write an SSP an assessor can test

This sequence turns the system security plan from a narrative document into a set of connected records: a boundary, an inventory of what sits inside it, a decision log for exclusions, requirement-by-requirement implementation statements, and a dated review history. Each record gives the assessor something specific to test against the requirements.

Define the boundary from the data flow
Start by tracing where CUI enters, is processed, is stored, and leaves your environment, and draw the boundary around the systems that touch it. Include the people and roles who handle that data, not just the hardware. Owners are usually the compliance lead with the engineering or IT lead who knows how data actually moves. The output is a boundary diagram and a short written scope statement that match each other. You know the step is done when someone outside the project can follow a single CUI record from entry to deletion using only the diagram.
Inventory environments and external connections
Within the boundary, list every environment the system runs in, such as on-premises networks, cloud tenants, enclaves, remote endpoints, and managed services, and state what each one hosts. Then record every connection to another system, including identity providers, email relays, backup targets, and service providers, with the direction of traffic and the data it carries. The output is an environments list and a connections register that cross-references the boundary diagram. Confirm the register against firewall rules, cloud network configuration, and identity federation settings, because gaps usually appear where an integration was added and never documented.
Decide and approve not-applicable requirements
Go through all 110 Level 2 requirements and identify any that do not apply to your system, such as a control covering a technology you do not use. Each exclusion needs a written rationale tied to the boundary and an approval by a named accountable official, because an assessor will test the reason, not just the list. The output is an approved not-applicable list with rationale and approver names and dates. Avoid excluding requirements to simplify the assessment; an unjustified exclusion is one of the fastest ways to lose credibility with an assessor.
Describe how each requirement is implemented
Write one implementation statement for each applicable requirement that names the mechanism, the system component that performs it, the responsible role, and where the evidence lives. Statements should describe the implementation as it exists today, not as planned. Engineers write the technical content and the compliance lead checks that each statement matches the boundary and connections. The output is a requirement-by-requirement implementation matrix. The step is done when each statement points to a real artifact, such as a configuration export, a policy, or a log source, that an assessor could ask to see.
Set and record the update frequency
Define how often the SSP is reviewed and updated, and write that frequency into the plan itself. Confirm the value against the CMMC Assessment Guide's minimum of at least annually and against any internal change triggers, such as a new connection, a cloud migration, or a material personnel change. The output is a documented update schedule and a list of event-driven triggers. Assessors test whether the organization actually follows the schedule it wrote, so the trigger list should be specific enough that someone can tell when an update is required.
Run and record the SSP review cycle
At each scheduled review and after each trigger event, check the boundary, inventory, exclusions, and implementation statements against the current environment, then revise and approve the document. Keep the prior versions and a record of who reviewed what and when. The output is a review log and a version history that show the SSP was maintained, not written once. Assessors commonly ask for this record because a plan that matches the environment on the assessment date, with a visible history of updates, is far easier to test than one that appears to have been drafted shortly before the assessment.

Evidence that passes for the SSP and how to keep it current

An assessor judges CA.L2-3.12.4 on the SSP and the records that prove it is accurate and maintained. The cards below cover the artifacts that carry that weight and how each one stays current between assessments.

The final SSP with version and approval

The SSP itself is the core artifact. Assessors accept it only in final form, meaning a version that has been reviewed and formally approved by the person accountable for the system, with the version number and approval date visible on the document. A draft SSP does not count as final evidence, even if its content is accurate. Confirm that the approved version matches the environment you are actually assessing, and that the document follows the minimum contents in the CMMC Assessment Guide Level 2, including scope, environment of operation, implementation of each requirement, connections and an update frequency of at least annually.

System boundary and data flow diagrams

The boundary diagram shows which assets store, process or transmit CUI and which sit outside the assessed scope. Data flow diagrams show how CUI moves between users, servers, endpoints, cloud services and external parties. Assessors compare these diagrams against the real network, so each change to hosts, subnets, cloud accounts or enclaves needs a matching diagram update. Check that every component named in the boundary appears in the inventory and that no inventory entry sits outside the diagram without a stated reason.

Environment and connection inventories

The environment of operation and the list of connections to other systems are where SSPs most often drift from reality. Keep an asset inventory that records owner, location, function and whether each asset is in scope, and a connection register listing each external system, service provider, remote access path and trust relationship with its purpose. Review both on the same cadence as the SSP. Ask whether a new SaaS tool, managed service or contractor VPN appears in the connection register before it carries CUI.

Not-applicable approvals with rationale

When a requirement does not apply to the system, the SSP must say so and the decision must be approved. Each not-applicable entry needs a written rationale tied to the system design, such as a control that covers a component you do not operate. An unexplained omission reads as a gap to an assessor. Recheck each approval when the boundary changes, because a justification that held for an on-premises design may fail once the same workload moves to a cloud service.

Review and update records

Assessors look for proof that the SSP is maintained, not only that it exists. Keep dated records of each review, the reviewer, what changed and the approval that followed. Define the update frequency in the SSP itself, and set it at least annually, then record each event that triggers an earlier update, such as a major system change or a new connection. Confirm that the record history matches the version history of the document, so no revision appears without a review behind it.

Enterprise architecture documentation

NIST SP 800-171A lists enterprise architecture documentation among the potential evidence for CA.L2-3.12.4, because it shows where the assessed system sits within the wider organization. Maintain architecture diagrams that show the security zones, identity and management planes, and the path from the assessed boundary to shared services. Update them when the architecture changes, and confirm they agree with the SSP's description of connections. Architecture material that contradicts the SSP weakens both documents at assessment.

What writing and maintaining the SSP costs

This table compares the cost components of producing and keeping a system security plan current, showing who is paid, whether each cost is one-time or recurring, and what drives it up. Use it to build a written scope and to ask potential partners where their quote lands. No price or duration figures are supplied here, so treat every line as a question to answer in your own environment.

Cost component	One-time or recurring	Who carries the effort and what drives it
Internal engineering and architecture time	One-time, then recurring	Engineers describe each requirement's implementation, boundary and connections. Drivers are the number of environments, connected systems and requirements that need explanation. Lower it by reusing one accurate architecture diagram and inherited control statements.
Compliance lead time to write the document	One-time, then recurring	A compliance lead assembles the SSP, sets the update frequency and checks each section against the assessment objectives. Drivers are document structure and how much detail already exists. Lower it by keeping the SSP in a structured, versioned wiki instead of ad hoc files.
SSP repository tooling and licenses	Recurring	Commercial document or GRC licenses are priced per user or module, so confirm what the vendor charges. Self-hosted open-source wikis and GRC platforms can remove license spend, but hosting, backups and access control remain your cost. Confirm capabilities such as version history and role-based permissions before you commit.
External consultant or implementation partner time	One-time, plus any retainer	Partners can prepare the boundary description, implementation narratives and evidence mapping under a written, fixed scope. Drivers are scope size and how complete your existing documentation is. Ask for named deliverables, a review cycle and what is excluded.
External review and independent sign-off	One-time per assessment cycle	Only an independent assessor or C3PAO issues assessment results. Review by your own advisers is a preparation step, not an assessment. Ask whether the quote includes a pre-assessment review of the SSP and how many review rounds are included.
Recurring review and update effort	Recurring	The SSP must be updated at the frequency you define, and the CMMC Assessment Guide expects at least annual updates. Drivers are system change rate, new connections and personnel changes. Lower it by linking SSP sections to change control records so updates happen as part of normal work.
Assessor effort when the SSP is weak	Recurring, avoidable	Vague or outdated SSPs increase assessor questions, retesting and delays, and an SSP that is not current at assessment time means the assessment cannot be completed. Lower it by reviewing the SSP against the minimum contents before the assessment starts.
Requirements marked not applicable	One-time, then recurring	Each not-applicable decision needs a documented justification that reviewers can check. Many exclusions increase review time and create disputes. Reduce the count through clear scoping, and confirm the justification approach with your assessor or partner.

Which self-hosted tools can hold the SSP and its version history

An SSP only satisfies CA.L2-3.12.4 if it is current, approved and traceable to a dated history. The three tools below cover different parts of that job: a wiki with version control, a wiki with role-based editing, and a framework tracker that holds assessment records. Confirm each tool's fit against your own SSP format before you commit to one.

XWiki for version history

XWiki keeps every change to a page under version control, recording what changed, when and by whom. For CA.L2-3.12.4, that history is how you show an assessor when each part of the SSP was written and revised, and that the update frequency you defined was followed. Use the compare view to show what changed between two reviews and the rollback function to recover an earlier approved version. Confirm that the history retention meets your records policy and that an approver sign-off can be recorded on the page itself.

BookStack for controlled editing

BookStack assigns abilities through roles and lets you override permissions per role at the shelf, book, chapter or page level. You can give most staff read access to the SSP while limiting edit rights on the final SSP pages to named approvers. This matters because an assessor will test whether the document in front of them is the approved version, not a working draft. Confirm that the permission model is granular enough for your SSP structure and that approval status is recorded somewhere an assessor can inspect.

CISO Assistant for assessment records

CISO Assistant is an AGPL-3.0-only project that ships more than 200 frameworks, including NIST SP 800-171 content can be checked against your environment, and it runs assessments against frameworks with automatic mapping between them. It can hold the assessment records that sit beside the SSP, such as the results that show your system matches what the SSP describes. Confirm that its framework library includes the CMMC Level 2 requirements and their assessment objectives in the version you deploy, and find out how it records review dates and reviewer identity.

Who owns the SSP, who can help, and where the assessor stops

Your organization owns the SSP in full. Someone with authority over the system must state what the system is, where it runs, how each requirement is actually implemented and which requirements are approved as not applicable. Those are management decisions, and an assessor will look for evidence that the people accountable for the system made and approved them. The update cycle belongs to you as well, including the update frequency you define and the records of each review.

System boundary and environments: Decide which assets, users and data flows are in scope and document the environment of operation.
Implementation statements: Write or approve how each Level 2 requirement is met in your environment, in your own words.
Not-applicable decisions: Record each requirement you treat as not applicable, with the reason and the approver.
Approval and review records: Keep signed or otherwise attributable approvals, with dates, for each SSP version.
Update frequency: Define how often the SSP is reviewed and changed, meeting at least the annual minimum in the assessment guide, and keep records of each review.

Before any assessment, confirm that a named individual can explain every statement in the SSP without reading it aloud.

How long, costly and hard is a CMMC SSP to write and keep current?

How much effort does a first CMMC system security plan take?

A first SSP usually takes longer than most teams expect, because the document can only be written after the team has mapped its system boundary, its environments and its connections. The effort is driven by how many systems hold or process CUI, how many external service providers and cloud tenants sit in scope, how many separate network segments exist, and whether current configuration documentation already exists. An organization with one well-documented enclave will move much faster than one with shared mail, file, and engineering environments that were never inventoried. Ask any provider for a written scope that lists the systems, sites, users and third parties covered, the number of review rounds included, and what the client must supply, such as network diagrams, asset inventories and policy documents.

Can a small contractor write its SSP in-house?

Yes, a small contractor can write its own SSP, and the CMMC Assessment Guide lets organizations choose the format. The SSP must still describe the assessment scope, the environment of operation, how each requirement is implemented, connections to other systems and an update frequency. The hard part is not the prose but the accuracy: each statement must match the systems as they actually run, and the evidence behind it must be in final form. Teams that lack an engineer who understands their own network often struggle most with the boundary and connection sections. A consultant or implementation partner can help with that technical mapping, but the organization remains responsible for the document's accuracy.

How often must the SSP be updated?

The Assessment Guide's minimum for the SSP's update frequency is at least annually, and the organization must define its own frequency in the SSP and then meet it. In practice, the plan should also be revised after material changes, such as a new cloud tenant, a changed authentication method, a new service provider, a merger or a significant network redesign. SP 800-171A also treats records of SSP reviews and updates as potential evidence, so the revision history matters as much as the current text. Confirm the exact update triggers your assessor expects before you commit to a review calendar.

Can a consultant write the SSP, and what must the organization still approve?

A consultant can draft the SSP, map systems to requirements and prepare the supporting diagrams, but the organization owns the content it declares. Leadership should review the boundary, confirm that each implementation statement is true, and formally approve the document and its update schedule. Staff who operate the systems must verify the technical descriptions, because an assessor will test them against interviews, configurations and logs. Independent assessors do not write the SSP for the organization, and a consultant's draft does not replace the organization's own attestation. Ask for a written scope that names who signs off on each section and which items remain the client's responsibility.

What happens if the SSP is missing or out of date at assessment?

If the SSP is missing or not current when the assessment takes place, the assessment cannot be completed. The CMMC rule gives CA.L2-3.12.4 no point value because it is a precondition for scoring the other requirements, and it cannot be placed on a plan of action and milestones. In a Level 2 self-assessment, marking CA.L2-3.12.4 NOT MET produces a No Score result in SPRS. An organization that discovers a gap should correct the SSP before the assessment date, since no deferred remediation path exists for this requirement.

How does the Phase II suspension affect the SSP obligation?

The suspension of CMMC Phase II does not remove the SSP requirement. The Department of War suspended Phase II on 13 July 2026 and started a 60-day review by a CMMC Reform Task Force, but Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. Because Level 2 self-assessments still score CA.L2-3.12.4, a contractor that wants an accurate SPRS entry needs a current SSP regardless of when certification becomes mandatory. Confirm with your contracting officer and the current DoW CIO guidance how the review outcome affects your contracts.

How DeployOpen prepares the SSP and its evidence

DeployOpen works on the CA.L2-3.12.4 system security plan as part of a fixed-scope engagement that prepares systems, controls and evidence for your assessment. The organization owns the plan and its control decisions, while an independent assessor makes the final judgment on whether the requirement is met.

How we scope

Agree in writing which systems, enclaves and environments fall inside the SSP boundary before any documentation starts.
Confirm the environment of operation, including cloud accounts, data centers and any external service providers that touch CUI.
List the connections to other systems and the update frequency your organization will commit to, which must be at least annual.

How we build

Draft the SSP against each Level 2 requirement, recording how it is implemented, who owns it and where the evidence lives.
Document requirements approved as not applicable with the reasoning and approval, so the assessor can follow each exclusion.
Map the SSP to the NIST SP 800-171A objectives for CA.L2-3.12.4 and check each objective has evidence in final form.

How we hand over

Deliver the SSP in your document system with version history, approvals and a named owner for each section.
Provide a review record showing who checked the plan, when, and which changes were made as a result.
Walk your internal owners through the plan so they can answer assessor questions about their own controls.

How we support

Offer an optional retainer to review the SSP after system changes, new connections or each annual update cycle.
Keep the SSP aligned with configuration changes and new evidence as the environment evolves between assessments.
Confirm with your assessor or Cyber AB-authorized provider which SSP format and evidence they expect before drafting begins.

CA.L2-3.12.4 System security plan