What Is A System Security Plan?

The request usually arrives in a contract clause or a supplier questionnaire: send us your system security plan. For a small contractor, that is often the first time anyone in the building has heard the phrase, and the government pages that rank for it are written for federal security officers, not for the operations manager who has to produce the document by the end of the month.

A system security plan is less mysterious than it sounds. It is a written description of one system: what it is, what it holds, what has to protect it and how that protection is actually done. This article gives a plain-English definition, lists what the plan has to contain, flags the revision trap that catches CMMC contractors, and then maps each section of the plan to the policies and procedures a company already has or needs to write.

What Is a System Security Plan?

A system security plan (SSP) is the document that describes how a specific information system is protected. The NIST glossary definition reads: a formal document that provides an overview of the security requirements for an information system and describes the security controls in place or planned for meeting those requirements.

In plain terms, the plan answers four questions for anyone who has to trust your system without inspecting it themselves. What system are we talking about? What information does it handle? What security requirements apply? And for each requirement, what have you done about it, or what do you still plan to do?

Two words in that definition matter more than they look. System means a defined boundary, such as the network, laptops and cloud accounts that touch customer drawings, not the whole company. Planned means the plan is allowed to be honest about gaps. An SSP that marks a control as not yet implemented, with a plan to close it, is more useful than one that claims everything is done. For a shorter glossary entry, see the Bizmanualz security plan definition.

Who Needs a System Security Plan?

The requirement began with federal agencies and has since flowed down to the companies that work for them. There are three common routes by which a business ends up needing one.

Federal Systems

Federal agencies document the protection of each of their systems in a system security plan. NIST’s planning guide for these systems is NIST SP 800-18 Rev. 2, which treats the system security plan, system privacy plan and cybersecurity supply chain risk management plan together as system plans. It was published in June 2026 and supersedes Rev. 1 from 2006, so older SSP templates labelled “800-18” usually reflect the previous edition.

Contractors Handling Controlled Unclassified Information

This is the route most small businesses arrive by. If you hold controlled unclassified information (CUI) under a government contract, such as technical drawings, specifications or export-controlled data, your customer will usually point you at NIST SP 800-171 Rev. 3. Its requirement 03.15.02 is titled System Security Plan, and it tells you to develop the plan, review and update it at an organization-defined frequency, and protect the system security plan from unauthorized disclosure.

Defense Contractors Under CMMC

Defense contractors seeking CMMC Level 2 status are assessed against the NIST SP 800-171 requirements, and the SSP is the document that ties those requirements to your actual practices. The CMMC rule also names the SSP directly. Under 32 CFR 170.16, a contractor that uses an outside service provider to handle CUI must document that provider and its services in the SSP, and the artifacts used as evidence for the assessment must be retained for six years from the CMMC Status Date.

What Should a System Security Plan Include?

The clearest current list comes from requirement 03.15.02 of NIST SP 800-171 Rev. 3. In summary, the plan should:

1. Define the system components. The servers, laptops, network devices, cloud services and applications inside the boundary.
2. Identify the information types. What the system processes, stores and transmits, such as CUI, customer records or payroll data.
3. Describe the threats of concern. The specific threats your organization worries about for this system, not a generic list.
4. Describe the operating environment. Where the system runs, and every dependency on or connection to other systems.
5. Give an overview of the security requirements. The requirement set that applies, and why.
6. Describe the safeguards in place or planned. Requirement by requirement, what you do and what you have not done yet.
7. Identify the people in system roles. System owner, administrators, security contact and anyone else with a defined responsibility.
8. Include any other information needed to protect CUI. Anything else an assessor would need to understand the protection.

Most SSP templates add administrative sections on top of this: a cover page, version history, approval signatures and a list of attachments. Those are worth having, because an assessor will ask who approved the plan and when it last changed.

The Revision Trap: Rev. 2, Rev. 3 and CMMC

Before you write anything, confirm which edition of NIST SP 800-171 your contract actually names. This is the detail that trips up small contractors most often, because the two editions number the same requirements differently.

NIST has withdrawn NIST SP 800-171 Rev. 2 and replaced it with Rev. 3. The CMMC rule, however, still points at the older edition. 32 CFR 170.14 states: The security requirements in CMMC Level 2 are identical to the requirements in NIST SP 800-171 R2.

So a defense contractor preparing for CMMC Level 2 writes an SSP against the Rev. 2 requirement list, where the SSP requirement is numbered 3.12.4, while a contractor whose agreement cites Rev. 3 writes against the newer list, where it is 03.15.02. The practical rule is simple: number your implementation statements to match the edition in your contract, and note that edition on the cover page of the plan.

An SSP Is a Map to Your Policies and Procedures

The most useful sentence in the NIST guidance for a small business is buried in the discussion under requirement 03.15.02: System security plans can be a collection of documents, including documents that already exist. The same passage explains that effective plans reference policies, procedures and other documents that hold the detail, rather than repeating it.

That changes the job. You are not writing a 200-page security novel. You are writing a structured index that says, for each part of the plan, which documented policy, procedure or record proves it. The table below maps each SSP section to the documents it normally points at.

SSP section	What it says	What it points to
System identification and boundary	Name of the system, its owner and what is inside the boundary	Network diagram, asset inventory, data flow diagram
Information types	What data the system handles and how sensitive it is	Data classification policy, list of contracts carrying CUI clauses
Operating environment and connections	Where the system runs and what it connects to	Cloud service agreements, vendor list, interconnection records
Roles and responsibilities	Who owns, administers and secures the system	Organization chart, IT job descriptions, security officer appointment
Access control	How accounts are granted, reviewed and removed	Access control policy, user account procedure, onboarding and offboarding checklists
Awareness and training	How users learn their security responsibilities	Security awareness training procedure, training records, rules of behavior acknowledgements
Configuration and change	How systems are built, patched and changed	Configuration baseline, change management procedure, patch log
Incident response	How incidents are detected, reported and handled	Incident handling procedure, incident report form, contact list
Media and physical protection	How devices, backups and premises are protected	Media handling procedure, visitor log, key control records
Assessment and open items	Which requirements are met and which are still planned	Internal assessment results, plan of action and milestones

If a row has nothing to point at, that is the gap to close first. The same written procedures also serve other obligations, which is why companies that have already worked through compliance standards requiring policies tend to find the SSP faster to assemble.

A Worked Example: One Implementation Statement

The heart of an SSP is a series of implementation statements, one per requirement. Each statement should let a stranger understand what you do, who does it and where the proof lives. The example below is hypothetical, written for an imagined 40-person machine shop that stores customer drawings marked as CUI. It uses Rev. 2 numbering, as a CMMC Level 2 plan would.

Requirement	3.1.1: Limit system access to authorized users, processes acting on behalf of authorized users, and devices (including other systems).
Status	Implemented
Responsible role	IT administrator (primary), operations manager (approval)
How it is done	Every user has a named account. The operations manager approves new accounts on the access request form before the IT administrator creates them. Only company-owned laptops enrolled in device management can connect to the file server holding customer drawings. Shared and generic accounts are not permitted.
Where the proof lives	Access control policy; user account procedure; signed access request forms; quarterly access review log; device management enrollment report.

Notice what the statement does not do. It does not restate the whole policy, name software settings in detail or promise anything that is not happening. It describes the practice in a paragraph and points at the documents that hold the detail. An assessor can then pick any line and ask to see it.

How To Write a System Security Plan, Step by Step

Step 1: Draw the Boundary

Decide exactly which people, devices, applications and cloud services handle the sensitive information. A tight boundary means fewer systems to describe and protect. Isolating the work that involves confidential information into a smaller enclave is often the single biggest time saver.

Step 2: Inventory What Is Inside

List every component inside the boundary and draw a simple network and data flow diagram. This becomes the system identification section of the plan and the first attachment an assessor asks for.

Step 3: Confirm the Requirement Set

Read the contract clause and confirm which framework and edition applies. Set up one row per requirement so nothing is skipped.

Step 4: Collect the Documents You Already Have

Gather existing IT policies, onboarding checklists, backup procedures and vendor contracts. Map each one to the requirement rows it supports using the table above. Companies with established workplace policies and procedures usually cover more rows than they expect.

Step 5: Write the Missing Policies and Procedures

For each empty row, write the procedure first and the implementation statement second. A statement that points at a procedure nobody has written will not survive an assessment. This is where an editable manual saves the most time, because the procedure structure, responsibilities and forms are already drafted.

Step 6: Write Honest Implementation Statements

Use the worked example format for every requirement. Mark each as implemented, partially implemented or planned. Anything not fully implemented goes on the plan of action and milestones with an owner and a date.

Step 7: Approve, Protect and Review

Have the system owner sign the plan, store it with restricted access and set a review date. Update it whenever the boundary, the systems or the responsible people change. Tie the review to your broader IT governance frameworks so it happens on a schedule rather than when a customer asks.

System Security Plan vs Security Policy vs POA&M

Three documents get confused constantly. They work together, but each has a different job.

Document	Question it answers	Scope
Information security policy	What rules does the company set?	Company-wide statements of intent and rules
System security plan	How is this particular system protected, requirement by requirement?	One defined system and its boundary
Plan of action and milestones (POA&M)	What is not done yet, who will fix it, and by when?	Open weaknesses and planned remediation

NIST SP 800-171 Rev. 3 notes that organizations can document system security plans and POAMs as separate or combined documents in any format. Most small contractors keep them separate, because the POA&M changes weekly while the SSP changes only when the system does. When an assessment or a compliance audit arrives, both are requested together.

Frequently Asked Questions

What is an SSP in CMMC?

In CMMC, the SSP is the document that describes how the systems inside your assessment scope meet the Level 2 security requirements, which are the requirements in NIST SP 800-171 Rev. 2. It is the core document an assessment works from, and it must also describe any outside service providers that handle CUI for you.

Is there a standard system security plan template?

There is no single mandatory template for contractors. NIST publishes a security plan example outline alongside SP 800-18 Rev. 2, and many customers supply their own. Whatever format you use, it must cover the elements listed in the applicable requirement and include one implementation statement per requirement.

How often should a system security plan be updated?

NIST SP 800-171 Rev. 3 leaves the review frequency for the organization to define. In practice, set a fixed annual review and also update the plan whenever the system boundary, key systems, service providers or responsible people change.

Who should write the system security plan?

The person who runs the system day to day, usually the IT administrator or managed service provider, should draft the technical statements. The system owner, often an operations manager or executive, should review and approve it, because the plan commits the business to the practices it describes.

Should a system security plan be kept confidential?

Yes. The plan describes your systems, connections and weaknesses in detail, which makes it useful to an attacker. NIST SP 800-171 Rev. 3 requires the plan itself to be protected from unauthorized disclosure, so share it only with the customer or assessor who needs it.

Write the Procedures, Then the Plan

A system security plan is only as strong as the documents behind it. An assessor reads the plan, then asks to see the policy, the procedure and the record for a sample of requirements. If those exist, the plan is mostly a matter of organizing them. If they do not, no amount of polished SSP prose will hold up.

So start with the written controls: access, training, configuration, incident handling, media and physical protection. Then build the plan as the map that ties them to each requirement, and keep both current as the business changes.