03.15.02 System security plan: requirements and evidence

What the 03.15.02 system security plan must contain and why assessors check it first

Requirement 03.15.02 asks the organization to maintain a system security plan (SSP) that describes the system in enough detail for someone outside the team to understand what protects CUI, where it sits and what is still missing. The plan must define the system's components, name the information types it stores, processes and transmits, describe the specific threats of concern, document the operating environment and connections to other systems, summarize how each security requirement is met, state which safeguards are in place or planned, and identify the people who hold system roles. It must also be reviewed at a defined frequency and protected from unauthorized disclosure. When a contracting officer or assessor asks for the SSP, they are asking whether you can show your own boundary before they test anything inside it.

This is a new family in Rev. 3, the Planning family (03.15), which NIST added to match the SP 800-53B moderate baseline. In Rev. 2 the same substance sat in requirement 3.12.4, and NIST's change analysis traces 03.15.02 back to that requirement. Under CMMC Level 2, which still assesses Rev. 2, 3.12.4 is scored with no points because an assessment cannot be completed without an SSP, and it cannot be placed on a plan of action and milestones. Undocumented CUI systems and unclear boundaries are the most common reasons an assessor cannot finish testing other requirements, so the SSP is the document every other control result is read against. Confirm with your contracting office which revision applies to your contract before you draft, since the revision determines how the SSP is scored.

Requirement 03.15.02 has one organization-defined parameter: how often the SSP is reviewed and updated. NIST does not assign that value. If a federal agency does not specify it, your organization must set it and document the choice, and an assessor will test whether the frequency is defined and followed. Decide the value, record the trigger events that force an earlier update (such as a new connection, a major system change or a security incident), and assign an owner who keeps a revision history. A plan that names a review frequency and then shows no review records will fail the same test as a plan with no frequency at all.

Which systems, boundaries and people the SSP must cover

Before any section of the system security plan is written, the organization has to decide what the system is. Each decision below changes which components, connections and people the plan must describe, and therefore how long the document is and how much work each review takes.

Systems that store, process or transmit CUI

The plan's boundary starts with every system that stores, processes or transmits CUI, including email, file shares, collaboration tools, backups and endpoints used by people who handle CUI. Each one must be named as a component and tied to the information types it carries. Ask for a data flow map before drafting, because systems discovered late usually force rewrites of the component list and the requirement narratives. Expect the plan to grow with every additional CUI-bearing system, and expect review effort to grow with it.

Enclaves and shared services inside the boundary

A dedicated CUI enclave keeps the plan focused, while shared identity, logging or patching services that support the enclave must be described as part of the system or as an external connection. The choice determines whether a shared directory or SIEM appears as a component with its own safeguards or as a documented interconnection. Confirm with the assessing authority how shared services are scoped before the boundary is drawn, since the answer changes how many requirements each shared service must satisfy.

External service providers and cloud components

Cloud platforms, managed email, hosted ticketing and outsourced security services often hold or handle CUI on the organization's behalf. The plan must identify each provider, describe the connection and state which safeguards the provider supplies and which the organization retains. Gather the provider's shared responsibility documentation and any contractual terms on CUI handling, because a provider that cannot describe its own controls will leave gaps the plan has to explain or the organization has to close.

Connections to other systems and parties

Every connection that carries CUI out of the boundary, such as a transfer to a prime contractor, a subcontractor portal or a government system, belongs in the operating environment section. Document the direction, the protocol, the owner on each side and the agreement that governs the exchange. Missing connections are a common reason a plan fails review, because the assessor will look for the data paths described in the plan and compare them against what the systems actually do.

Named people in system roles

The plan must identify the people who hold system roles, including the system owner, security officer, administrators and anyone who maintains the plan. Role assignments are not static, so decide whether the plan names individuals or positions and who updates it when staff change. Confirm that each named role matches an actual responsibility in access control and incident response, since assessors interview these people to test whether the plan describes how the system is run.

Operational scope and review frequency

The plan should state the review frequency the organization has set for itself, which is the organization-defined parameter for 03.15.02, and the triggers that prompt an early update, such as a new CUI system, a change in provider or a significant incident. Decide these before the first version is approved. A narrow boundary with a fixed quarterly review is easier to keep current than a broad boundary reviewed only when someone remembers to, and the review effort should be planned against the number of components the plan covers.

How to write the SSP in a sequence that an assessor can follow

Writing the system security plan in this order lets each section rest on the one before it, so an assessor can trace a requirement from the system boundary to the safeguard that meets it. Each step names the output that the next step depends on.

Define the system boundary and components
Start by drawing the boundary of the system that stores, processes or transmits CUI, then list every component inside it: servers, endpoints, network devices, cloud tenancies, applications and the enclave's management tools. Assign each component an owner and a function. The output is a boundary diagram and a component inventory that match each other. You know the step is done when every asset named in the diagram appears in the inventory and no inventory item sits outside the boundary without a stated reason. Asset management tools such as GLPI's Assets module can seed the list, but someone must confirm it against the real environment.
Inventory the information types
Identify each type of CUI and other information the system processes, stores and transmits, and record where each type lives inside the boundary. Work from the contracts and CUI markings that govern the data, not from memory of what the team handles. The output is a table that maps information types to components and to the flows between them. The step is complete when every component in the inventory can be tied to at least one information type, and any component that carries none is either removed from scope or explained.
Document threats and the operating environment
Describe the specific threats of concern for this system, such as targeted phishing of staff who handle CUI or unauthorized access through a remote maintenance path, and describe the operating environment in which the system runs. Record the connections to other systems, including external service providers, shared cloud services and any exchange of CUI with other organizations. The output is a threat statement and a connection register. An assessor will check that each connection on the diagram appears in the register and that the threats match the environment the plan describes.
Summarize requirements and safeguards
For each of the 97 Rev. 3 requirements that applies to the system, record a short summary of how the safeguard works and whether it is in place or planned. Where the organization has set an organization-defined parameter, record the value next to the requirement it applies to. The output is a requirement-by-requirement table with a status and a responsible role for each entry. The step is done when no applicable requirement is left blank and each planned safeguard carries a target that the organization can show to an assessor.
Name the people in system roles
Identify the people who hold system roles, including the system owner, security officer, administrators, incident contacts and anyone who approves changes to the plan. Record each role's responsibilities and the person or team that fills it. The output is a roles table that other sections of the plan can point to. The step is complete when every role referenced in the requirements summary is filled, and each name or group is current enough that an assessor interviewing staff would find the same people.
Set the review frequency
Choose the frequency at which the plan will be reviewed and updated. Rev. 3 leaves this value to the organization as an organization-defined parameter for 03.15.02, so write the chosen value into the plan and make sure the assessment procedure can see it defined. The output is a stated review interval and a named owner for the review. The step is done when the interval appears in the plan, the owner is in the roles table, and the review is entered in the organization's calendar or ticketing system so it produces evidence.
Approve, protect and version the plan
Obtain documented approval of the plan from the people with authority over the system, then store the approved version under restricted access so that only authorized roles can read or change it. Keep a version history that records what changed, when and by whom, and retain prior versions. The output is an approved plan, an access list for the repository and a change log. The step is complete when an assessor can see the approval, the access restriction and the history of the last review without asking the team to reconstruct them.

How an assessor tests the SSP against SP 800-171A

An assessor testing 03.15.02 checks whether the system security plan exists, describes the system accurately, and is actually run as a living document. SP 800-171A Rev. 3 assesses the requirement with 11 determination statements, plus one statement that confirms the organization-defined frequency for reviewing the plan has been set. Each statement is tested using some combination of three methods: examine (reading documents and artifacts), interview (asking the people responsible), and test (observing a process working). The assessor will usually start with the security planning policy and procedures, then the plan itself, then the review and approval records that show the plan has been maintained.

On the examine side, the assessor reads the system security plan against the components the requirement lists: system components, information types stored, processed and transmitted, specific threats of concern, the operating environment and connections to other systems, an overview of the security requirements, the safeguards in place or planned, and the people in system roles. Gaps are common where the plan describes a network diagram that no longer matches the current architecture, or where the enterprise architecture referenced in the plan is out of date. Before the assessment, confirm the review frequency you set as your ODP value appears in the plan and in the procedures, because an undefined frequency fails the ODP check regardless of how well the rest is written.

Interviews matter because the assessor tests whether the people who own the plan understand it. Expect questions for the plan owner, the system security officer and system developers about how the plan was developed, who approved it, and what changed after the last review. The test method then looks at the process itself: the steps for drafting, updating and approving the plan, and evidence of an actual review cycle, such as dated revisions and approval records. Before the assessment, run one full review cycle and keep its records, since a plan with no review history is hard to show as maintained. Confirm the exact scope of the assessment with your assessor, because the methods they apply can differ by assessment type.

What assessors request and where SSPs usually fail

This table compares how an assessor tests each part of the system security plan, what evidence they ask for, and the findings that appear most often. Read each row as a question to answer before an assessment, not as a checklist to finish once. The main takeaway is that a plan that is complete on paper still fails when its contents, review record and approval trail no longer match the live environment.

Test area	Evidence requested	Common findings
SSP content	The current plan, with system boundary, component inventory, information types, threats, operating environment, external connections, requirement overview and system roles	Components listed that were decommissioned, cloud services or subcontractor connections missing, and information types that do not match what the system stores or transmits
Safeguards described	Descriptions of safeguards in place and planned, with a link from each to the requirement it supports	Safeguards described generically, planned items without target dates, or statements that conflict with configuration exports and screenshots
Review and update process	Documented review procedure, the defined review frequency, and the history of prior reviews and updates	A review date printed on the cover with no record that the review happened, or review steps that are not followed in practice
Change tracking	Change log or revision history tied to system changes such as new components, boundary moves or staff role changes	The plan not updated after a migration, new tool or personnel change, so the plan describes an earlier system
Approval records	Signed or otherwise recorded approval by the people named as accountable for the system, with the version approved	No approval on record, approval of a draft, or approval by someone without documented authority for the system
Interview readiness	Staff with planning and implementation responsibilities who can explain the plan and its connections	Staff unaware the plan exists, or system owners describing a different architecture from the one in the plan
Protection of the document	Access restrictions on the plan, a list of who can read or edit it, and how copies are kept	Plan stored in an open shared folder or emailed widely, with no record of who holds copies
ODP value	The review frequency the organization set, where it is defined, and proof it is applied	No frequency defined, a frequency set in the plan that differs from the policy, or a frequency the team has not met

Evidence that satisfies 03.15.02 and how to keep it current

An assessor testing 03.15.02 looks for a plan that matches the system as it runs today, with a visible history of who approved it and when. The cards below cover the documents, records and inventories that back the plan, and the routine that keeps each one accurate between assessments.

Approved SSP and version history

The plan itself must be a single approved document with a named owner, an approval date and a clear version number. Keep every prior version so an assessor can see how the plan changed over time. Check that the version in the document repository is the one the approver signed, and that no unapproved draft is circulating as the current plan. Document version control in the repository should record what changed, when and by whom, so confirm your wiki or document tool retains that history before you rely on it.

Defined review frequency and review records

03.15.02 has one organization-defined parameter: the frequency at which the plan is reviewed and updated. Assessors check that you set a value, that it is written into the SSP or its governing procedure, and that each review actually happened on that schedule. Record each review with its date, the reviewer, the changes made or the reason none were needed. A missed review is easier to explain than a plan that was never reviewed at all.

Approval sign-offs and change triggers

Each approval should show the name and role of the person who accepted the plan and the date they did so. Between scheduled reviews, define the events that force an update: a new information type, a new external connection, a major system change or a significant finding from an assessment. Keep a short log linking each trigger to the plan revision it produced. This shows the plan follows the system rather than trailing it.

Boundary diagram and information type list

The boundary diagram shows which components fall inside the CUI environment and how traffic enters and leaves it. The information type list records each category of CUI the system stores, processes or transmits. Both must match the SSP text word for word on component names and connections. Confirm them against the live environment at each review, because a diagram drawn at deployment often misses later cloud services, remote access paths and integrations.

Access controls on the SSP document

The SSP describes security weaknesses and planned safeguards, so it is itself CUI-sensitive and must be protected from unauthorized disclosure. Restrict read and edit rights to people with a defined system security role, and record who holds each role. Confirm that permissions are set per role at the level of the space or page where the plan lives, and review those grants at each plan review. Note any access changes in the review record so the protection is evidenced, not assumed.

Network and asset inventories the SSP cites

Where the SSP lists servers, endpoints, network devices or software, the cited inventory is evidence in its own right. Keep the asset inventory in a system of record that can be exported, and reconcile it against the SSP component list at each review. Confirm whether inventory entries are created manually or collected automatically by an agent, and note any gaps, such as unmanaged devices or shadow cloud accounts. An inventory that disagrees with the plan will be the first thing an assessor finds.

What writing and maintaining an SSP costs in money and effort

This table breaks down the cost components of drafting and keeping a system security plan current, showing who is paid for each, whether it is one-time or recurring, what drives it up and how to keep it down. Use it to structure a quote request, since no supplied figures set prices or hours for any organization's environment.

Cost component	One-time or recurring	What drives it	How to keep it down
Tooling or licenses	Recurring	Whether the SSP lives in a commercial GRC suite, a wiki or a document editor, and the number of users who need edit rights	Self-hosted open source such as XWiki or BookStack can remove license spend, but confirm hosting, backup and access-control effort in the quote
Engineering and compliance time to draft	One-time	Number of components, the depth of each requirement narrative and how many system roles must be described	Reuse existing architecture and policy documents, and draft against the 03.15.02 requirement elements in a fixed order
Asset and architecture data collection	One-time, then recurring as the system changes	Size of the inventory, how current the network diagrams are and whether asset records are maintained manually	Use an asset inventory such as GLPI with agent-based discovery so component and connection data is not rebuilt by hand
Review and update cycles	Recurring	The review frequency the organization sets for its ODP, plus unscheduled updates after major changes	Tie reviews to change control events and keep a dated revision history so each review is a short delta, not a rewrite
External review or consultant support	One-time and recurring if retained	Whether the SSP is written from scratch, how many systems and enclaves are in scope and the depth of gap analysis required	Ask for a fixed-scope deliverable with named documents, and keep internal ownership of the final text
Assessor time	Per assessment	The assessment method chosen, the completeness of the SSP at the start and the number of interviews and examined artifacts	Provide a complete, current SSP and evidence index before the assessment begins so the assessor does not need to request missing material

Who writes the SSP, who reviews it and who may not

Your organization owns the system security plan. Only your people can state what the system is, what it stores and transmits, which safeguards are in place and which are planned, and who holds each system role. A named owner, usually the information security lead or the system owner, is accountable for the plan's accuracy, approves each version and signs off on the review cycle that the organization sets for 03.15.02. System owners and engineers supply the facts that the plan depends on, because they know the architecture, the connections and the operating practices in day-to-day use.

Accountable owner: Name one person who approves the plan and answers for it to the contracting agency or assessor.
System owner facts: Require written input from each system owner on components, data flows, connections and roles.
Approval record: Keep a dated approval for each version, so the plan's status at any point is provable.
Review schedule: Set the review frequency that the plan itself states, and assign who runs each review.
Protection of the plan: Decide who may read the plan, since it describes weaknesses and planned safeguards.

Before accepting a draft from anyone else, check that every statement about your environment matches what your system owners and configuration records show.

Which open-source tools can hold and version the SSP

Can XWiki keep a version history of the system security plan?

Yes. XWiki keeps every change to a page under version control, recording what changed, when and by whom, so you can compare any two versions and roll back to an earlier one. That history supports the 03.15.02 expectation that the plan is reviewed at a defined frequency and that its updates are traceable. An assessor will want to see that reviews and approvals happened, so the history should show dated revisions tied to named reviewers. Confirm with your own environment that XWiki's version control meets your retention and approval workflow, and check the license terms, which are LGPL-2.1-or-later, with your legal team before embedding it in a product or service.

How does BookStack restrict who can read or edit the SSP?

BookStack assigns abilities through the roles given to each user, and permissions can be overridden per role at the shelf, book, chapter or page level. You can therefore keep the SSP in a restricted book that only personnel with system security planning responsibilities can edit, while a wider group reads it. This supports the requirement to protect the plan from unauthorized disclosure. Test the permission model with your own accounts before relying on it, because inherited permissions can expose content if a shelf is configured loosely. BookStack is licensed under MIT, which you should confirm against your own internal licensing review.

Can GLPI Assets hold the component inventory the SSP refers to?

GLPI's Assets module can record computers, monitors, software, network equipment, peripherals, printers, phones and racks, entered manually or pushed by the GLPI Agent through native inventory built into GLPI since version 10. The SSP must describe the system's components, so an up-to-date inventory gives you a source to cite rather than a list retyped each review. Assessors will still expect the SSP itself to explain how components connect and handle CUI, so GLPI supports the plan rather than replacing it. Confirm that the asset types you need, such as cloud resources, are covered in your environment. GLPI is licensed under GPL-3.0-or-later, so review the obligations with your legal team.

Can CISO Assistant track SSP-related assessments against frameworks?

CISO Assistant, licensed under AGPL-3.0-only, ships more than 200 frameworks, including NIST CSF, and can run audits and compliance assessments against them with automatic mapping between frameworks. It can record the status of 03.15.02 and related requirements, so the SSP's safeguards in place or planned line up with assessment results. It does not write the plan or issue an assessment result; your organization owns the findings, and an independent assessor reaches the conclusions. Confirm that the framework content it ships for NIST SP 800-171 matches the revision your contract requires, since Rev. 2 and Rev. 3 differ, and verify any mapping before you rely on it.

Is an open-source wiki enough to meet the SSP requirement on its own?

No tool satisfies 03.15.02 alone. The requirement calls for a plan that covers components, information types, threats, the operating environment and connections, requirements, safeguards, system roles and protection from disclosure, and the organization must write and maintain that content. The tools hold, version, restrict and track the document; they do not decide the content. Expect to define a review frequency yourself, because it is an organization-defined parameter, and to show that reviews were carried out. Your implementation partner can prepare the structure and evidence, but the organization owns the plan and an assessor tests it.

What should I confirm before choosing these tools for the SSP?

Start by confirming that each tool runs in your own infrastructure and meets your data handling rules, because the SSP itself describes sensitive system details. Check the access model, backup approach and audit logging of each tool, and make sure the SSP's protection is applied consistently across them. Review the license terms for XWiki, BookStack, GLPI and CISO Assistant with your legal team, since they differ in copyleft obligations. Ask whether the chosen tool version receives security fixes in your support model. A fixed-scope engagement can cover the configuration, but the choice and its risks stay with your organization.

How do these tools fit with a CMMC or DFARS assessment?

They support the evidence trail rather than the assessment outcome. Under the CMMC scoring method, the system security plan practice (CA.L2-3.12.4 in Rev. 2 terms) is not given points and cannot be placed on a plan of action and milestones, so an SSP that is missing or outdated can block an assessment. A versioned, access-controlled SSP with a current component inventory and tracked assessment status helps show that the plan exists and is maintained. Confirm which revision of SP 800-171 your contract references, because that determines which requirement numbers the assessor uses.

Gaps that make an SSP fail review

A system security plan is judged on whether it describes the system as it actually runs today and whether the organization can show who approved it and when. The gaps below are the ones that most often turn a plan into a finding, and each one has a concrete check you can run before an assessor does.

Plan written once, never updated

An SSP that describes the environment at the time of its first draft is out of date after the first architecture change, new subcontractor or cloud migration. Assessors compare the plan against the live system, and the examine and interview steps for 03.15.02 look at whether reviews and updates actually happen. Check that every significant change ticket asks whether the SSP needs an update, and that the plan's revision history shows real updates rather than a single date.

Boundary that ignores the network

The plan must describe the system's components and its connections to other systems. A diagram that shows the enclave but omits remote access paths, backup services, managed endpoints or a SaaS tool that touches CUI leaves the assessor with a boundary the network does not match. Reconcile the SSP against an inventory generated from your asset management and network records, and list each external connection with its purpose and the data it carries.

Review frequency left undefined

03.15.02 has one organization-defined parameter: how often the SSP is reviewed and updated. Leaving it blank, or copying a number from a template without thinking about your change rate, means the requirement is not fully met, because the assessment includes a check that the value is defined. Set a frequency your team can meet, write it into the SSP and your policy, and keep dated evidence that each review happened on schedule.

No record of approval

A plan that nobody signed is hard to defend, because the assessor cannot tell whether the authorizing official accepted the risk or whether the document is a working draft. Record who approved each version, the date, and the scope they approved. Keep the approval record with the SSP in your version control or document system so the approved version can be retrieved and compared with the current one.

SSP left unprotected

The SSP itself describes your defenses, which makes it sensitive. Many plans sit in general file shares or email attachments, where anyone with access can read the attack surface. Store the SSP in a restricted repository with role-based access, log who opens and changes it, and limit distribution to people with a need to know. Confirm that your document platform keeps version history so an unauthorized edit can be detected and reversed.

Treating 3.12.4 POA&M habit as the SSP

Under Rev. 2, the system security plan was tracked as requirement 3.12.4, and CMMC still uses that identifier. Under Rev. 3, the same content sits in 03.15.02, which means teams that assess themselves against the old numbering can miss it. Map your evidence to 03.15.02 if you are on Rev. 3, and confirm with the contracting officer which revision applies to your contract, since a plan of action and milestones cannot be used to close the SSP requirement.

What changed from Rev. 2's 3.12.4 and why it matters for CMMC

Rev. 3 withdrew the Rev. 2 requirement 3.12.4 and moved its substance into 03.15.02. NIST's Rev. 2 to Rev. 3 change analysis traces 03.15.02 back to 3.12.4 and classifies the change as minor. The practical meaning is that the system security plan requirement did not disappear; it was renumbered and placed in the new Planning family. Any organization that already maintains a plan built around 3.12.4 is largely working from the same obligation, but its assessment references, evidence index and SPRS mapping need to use the new identifier.

The consequence for CMMC Level 2 is more significant than the renumbering. CMMC Level 2 still assesses against Rev. 2, so the requirement is still CA.L2-3.12.4. Under 32 CFR 170.24 it carries no point value, because an assessment cannot be completed without a system security plan. Under 32 CFR 170.21 it cannot be placed on a plan of action and milestones. An SSP gap therefore does not reduce a score; it stops the assessment. Before any assessment date is set, confirm that the plan covers every element of 03.15.02, including the defined review frequency, and that it has been reviewed and approved within that frequency.

Contract status still points to Rev. 2. DoW Class Deviation 2026-O0025, Revision 3 has contracting officers use a revised DFARS 252.204-7012 that names SP 800-171 Revision 2 explicitly, and it cites a 13 July 2026 DoW CIO memorandum requiring baseline compliance with Rev. 2 while CMMC Phase 2 is suspended. A proposed FAR overhaul rule would move contractors to Rev. 3, but it was not final as of October 2026. Ask the contracting officer which revision governs each contract, and build the plan so it satisfies both numbering schemes while the deviation and proposed rule remain open.

Questions buyers ask about the 03.15.02 system security plan

How long does it take to write a system security plan?

No researched figure fixes a duration, so the honest answer depends on the system. The main drivers are how many components sit inside the CUI boundary, how many information types the system handles, how many external connections need describing, and whether the team already has an accurate asset inventory and architecture diagrams. A small enclave with one cloud account and documented configuration will move much faster than a hybrid environment with shared services and several subcontractor links. Ask any partner for a written scope that lists the components, connections and information types they will document, because that list sets the effort.

Can our internal team write the SSP without outside help?

Yes, if the team understands the system well enough to describe it accurately and has someone who can own the document over time. 03.15.02 asks for specific content: system components, information types, threats of concern, the operating environment and connections, a summary of the requirements, the safeguards in place or planned, and the people in system roles. Gaps usually appear in the threat description and in the safeguard statements, where a claim must match what the system actually does. Internal teams often underestimate the time needed to collect evidence for each claim, so plan for that work before deciding to do everything in-house.

What does an implementation partner add to the SSP work?

A partner prepares the systems, configuration records and evidence that the plan describes, and helps write the plan from that evidence. DeployOpen plans, implements, documents and hardens self-hosted open-source platforms inside the client's own environment, so the SSP can reflect systems that were built and documented against the requirements. A partner does not own the controls, and it does not approve the plan or issue any assessment report. Under a fixed-scope engagement, the written scope should name the SSP sections, the systems covered and the review cycle the client will run afterward.

Who sets the review frequency for the system security plan?

The organization sets it. 03.15.02 has one organization-defined parameter, the frequency at which the plan is reviewed and updated, and NIST does not assign a value. If a federal agency specifies a value in the contract or agreement, that value applies. Otherwise the nonfederal organization must define one and be able to show it follows the defined frequency. Pick a cadence that matches how often the system changes, and add triggers for event-driven updates such as a new connection, a new information type or a significant configuration change. Confirm the expected value with the contracting agency before you write it into the plan.

Will an assessor write or approve our system security plan?

No. An assessor checks the plan against the SP 800-171A Rev. 3 procedures for 03.15.02, which use examine, interview and test methods. The assessor reviews the plan, interviews people with planning and implementation responsibilities and tests the review and approval process. Writing or approving the plan is the organization's job, and the independent assessor or certifying body is the party that reports on it. Expect the assessor to compare what the plan says with what staff and systems show, so statements in the plan need supporting records.

How does the SSP connect to the CMMC POA&M rule?

Under CMMC Level 2, the SSP practice, CA.L2-3.12.4, carries no point value in the scoring methodology, because an assessment cannot be completed without a system security plan. 32 CFR 170.21 also bars it from a plan of action and milestones. That means a missing or inadequate SSP cannot be deferred into a POA&M and must be in place before an assessment can proceed. Note that Rev. 3 withdrew the Rev. 2 requirement 3.12.4 and moved its content into 03.15.02, while CMMC still uses Rev. 2 numbering. Confirm with the contracting officer which version and assessment rules apply to your contract, since the DoD guidance on Rev. 2 and Rev. 3 is changing.

What should we ask for in a quote for SSP work?

Ask for the scope in writing before the price: the systems and boundary covered, the SSP sections delivered, the number of connections and information types described, the evidence review, and the review support after handover. Ask whether the work is one-time, recurring or both. The plan itself is a one-time build, but reviews, updates after system changes and assessment support recur. Ask who provides which artifacts, which items the client must supply, and how revisions are handled. DeployOpen does not publish a price list, and a quote follows from the written scope.

How DeployOpen prepares the SSP and its evidence

DeployOpen works on the system security plan as part of the system it describes, not as a standalone document. We prepare the plan from the platforms, boundaries and controls that exist in the client's own environment, and we leave ownership of every control and the final plan with the organization. Independent assessors, not DeployOpen, review the plan and issue any report.

How we scope

Agree in writing which systems, enclaves and connections the plan will cover before work starts.
Identify the information types the in-scope platforms store, process and transmit, with the client's data owners.
Confirm the review frequency the organization will assign to the organization-defined parameter for this requirement.
Name the people who hold system roles so the plan records accountable owners for each area.

How we build

Document system components, operating environment and connections to other systems from the actual deployment.
Map each Rev. 3 requirement to the safeguards in place or planned, and record status for each one.
List specific threats of concern for the platforms in scope and link each threat to the safeguards that address it.
Draft the plan in a version-controlled wiki so changes are traceable and earlier versions can be restored.

How we hand over

Deliver the plan with an evidence index pointing to configurations, diagrams, inventories and review records.
Walk the organization's staff through the plan so system owners can answer assessor questions about it.
Document the approval and review process, including who approves updates and how access to the plan is restricted.
Confirm with the organization and its assessor which evidence formats they accept before handover.

How we support

Update the plan when the system changes, using the change records the client already keeps.
Offer ongoing support, upgrades and continuous testing as a retainer after the initial engagement.
Refresh inventory and boundary evidence at the review frequency the organization has defined.
Prepare evidence for an external assessment on request, while the assessor and the organization own the outcome.