A POA&M template is a table with one row per security weakness: the requirement it affects, what is wrong, how it was found, who owns the fix, the resources needed, dated milestones and a completion date. It pairs with the system security plan (SSP), which describes the system's boundary and how each requirement is implemented. Below are copyable templates for both, built for NIST SP 800-171, each with a filled-in example.
We write SSPs from the configuration we deploy and keep plans of action within the CMMC rule's limits as part of our CMMC compliance services; we are not a C3PAO and certify no one. Use these templates alongside our NIST 800-171 checklist, and see CMMC Level 2 requirements for how a self-assessment is scored. This is general information, not legal advice.
What is a system security plan?
It is the document that describes the system holding controlled unclassified information (CUI) and how each security requirement is met. Revision 2 of NIST SP 800-171, which CMMC Level 2 still uses, asks for SSPs that describe system boundaries, the environments the system operates in, how security requirements are implemented and the system's connections to other systems (requirement 3.12.4). Revision 3 expands the list in 03.15.02: the system components, the information types, threats of concern, the operating environment and dependencies, the safeguards in place or planned, the people in system roles, a review at a frequency you set, and protection of the plan itself from unauthorized disclosure.
NIST adds a practical note: an SSP can be a collection of documents, including ones that already exist, so you can reference your network diagram and policies instead of copying them. Under CMMC, the SSP is not optional. The Department's FAQ says that marking the SSP requirement (CA.L2-3.12.4) as not met produces no score at all, and 32 CFR 170.21 never allows it on a plan of action.
System security plan template
Copy this table into a document and keep the section numbers. The sample entries describe a fictional 18-person machine shop and are illustrations only.
| Section | What to include | Sample entry |
|---|---|---|
| 1. System identification | System name, unique identifier, responsible organization, system owner, security officer and the government point of contact for CUI | CUI enclave; owner: operations director; security officer: IT provider's lead engineer |
| 2. Purpose and information types | What the system does and which CUI categories it handles, using the National Archives CUI Registry names | Receives, stores and shares drawings marked CUI from two prime contractors |
| 3. Users | Number of users and of privileged users, by role | Nine users; two administrators |
| 4. Boundary and environment | A network diagram, the components in scope, connections to other systems, cloud services and outside providers | A separate cloud tenant, nine managed laptops and one firewall; managed by an outside provider |
| 5. Asset inventory | Hardware and software lists, or a reference to the inventory system, with owners | Inventory exported monthly from the device management console |
| 6. Threats of concern | The threats you plan for, which Revision 3 asks you to describe | Phishing aimed at engineers; stolen laptops; a compromised supplier account |
| 7. Requirement implementation | For each requirement: status, how it is met, who is responsible and where the evidence is | See the sample rows below |
| 8. Outside providers | Each cloud or managed service provider's role and the customer responsibilities it assigns to you | Cloud provider's customer responsibility matrix referenced in section 7 |
| 9. Related documents | Policies, procedures, the incident response plan and the plan of action | Links to the policy library |
| 10. Review and change record | How often the plan is reviewed, and every change with date and approver | Reviewed every six months and after major changes |
| 11. Distribution and protection | Who may read the plan and where it is stored | Restricted to the security officer, the IT provider and the Affirming Official |
Section 8 matters more than it looks. When you use a cloud or managed service provider for a CMMC Level 2 environment, 32 CFR 170.16 says the security requirements from its customer responsibility matrix must be documented or referred to in your SSP, and a provider that is not a cloud service must also be described in the SSP and assessed within your scope.
What does a filled-in SSP entry look like?
Write each entry from the system as configured, not from a policy you hope to follow. Four illustrative rows, using Revision 2 numbering with the Revision 3 number in brackets:
| Requirement | Status | How it is met | Responsible | Evidence |
|---|---|---|---|---|
| 3.5.3 Multifactor authentication (03.05.03) | Implemented | Sign-in policy requires MFA for every enclave account; administrators use phishing-resistant methods | IT provider | Policy export and MFA registration report, dated |
| 3.3.1 Create and retain audit logs (03.03.01) | Implemented | Cloud and laptop logs sent to a central log platform and kept for one year | IT provider | Retention settings and the monthly review record |
| 3.13.11 FIPS-validated cryptography for CUI (03.13.11) | Planned | Laptops are encrypted, but the module in use is not FIPS-validated; replacement tracked as POAM-02 | IT provider | Plan of action item POAM-02 |
| 3.12.4 System security plan (03.15.02) | Implemented | This document, reviewed every six months and after major changes | Security officer | The change record in section 10 |
NIST's own SSP template offers three statuses for each requirement: implemented, planned to be implemented, or not applicable, with a rationale required for anything marked not applicable.
POA&M template
The plan of action and milestones, POA&M or POAM for short, tracks every requirement that is not yet met. NIST's CUI plan of action template uses eight columns: the weakness, the responsible office, a resource estimate (funded, unfunded or reallocated), the scheduled completion date, milestones with interim dates, changes to milestones, how the weakness was identified, and status. For CMMC work, add the requirement number, its point value and whether the rule allows it on a plan of action.
| Column | What to enter |
|---|---|
| Item ID | A unique number, such as POAM-01 |
| Requirement | The requirement number and title the weakness affects |
| Weakness | What is not met, in one or two sentences |
| How identified | Self-assessment, vulnerability scan, audit, incident or monitoring |
| Point value | 5, 3 or 1 under the CMMC scoring method in 32 CFR 170.24 |
| Allowed on a CMMC plan of action? | Yes or no under 32 CFR 170.21, with the reason |
| Responsible owner | A named person, not a department |
| Resources | Funded, unfunded or reallocated, with an estimate |
| Milestones | Interim steps with dates |
| Changes to milestones | Any revised date and the reason |
| Scheduled completion | The target date; for CMMC, within 180 days of the conditional status date |
| Status and closure evidence | Open, in progress or closed, and what proves the fix |
What does a filled-in POA&M look like?
Three illustrative rows for the same fictional shop:
| ID | Requirement and weakness | Points and eligibility | Owner and milestones | Due |
|---|---|---|---|---|
| POAM-01 | 3.1.10 Session lock with pattern-hiding displays: shop-floor PCs lock after 30 minutes, but the policy says 15 | 1 point; allowed | IT provider: change the policy in week one, confirm on every device in week two, update the SSP | Within 30 days |
| POAM-02 | 3.13.11 FIPS-validated cryptography: laptops are encrypted, but the module is not FIPS-validated | 3 points; allowed, because encryption is in use but not validated | IT provider: choose a validated configuration, pilot it on two laptops, roll out, record the validation evidence | Within 90 days |
| POAM-03 | 3.1.9 Privacy and security notices: no sign-in banner on enclave systems | 1 point; allowed | IT provider: approve banner text with the owner, deploy by policy, capture a screenshot | Within 14 days |
What can go on a CMMC POA&M?
Revision 3 of NIST SP 800-171 lets organizations document SSPs and plans of action as separate or combined documents in any format, and requires the plan of action to be updated after assessments, audits or reviews, and continuous monitoring. CMMC adds hard limits in 32 CFR 170.21 for a conditional Level 2 status:
- The assessment score must be at least 80 percent of the maximum, which is 88 of 110.
- Only 1-point requirements may be included, plus FIPS encryption (SC.L2-3.13.11) when encryption is used but not validated.
- Six requirements can never be included: external connections, control of public information, the system security plan, escorting visitors, physical access logs and managing physical access.
- Every item must be closed and confirmed by a closeout assessment within 180 days, or the conditional status expires.
Some gaps therefore have to be fixed before you claim any status. Multifactor authentication rolled out only to remote and privileged users, for example, loses 3 points under 32 CFR 170.24, so it cannot sit on a plan of action. For a C3PAO assessment, the Department's FAQ adds that the closeout assessment can be finalized only once; if items are still not met, the conditional status ends and a new assessment is needed.
The FAQ also separates a plan of action from an operational plan of action. A plan of action closes gaps found in an assessment within 180 days; an operational plan of action records routine work, such as patches or temporary deficiencies that appear after the requirements were met, with no fixed deadline.
Who maintains the SSP and the POA&M?
The security officer named in section 1 owns both, with the system owner approving changes. Update the SSP whenever the boundary, a provider or a configuration changes, and on the review schedule you set. Update the plan of action after every assessment, audit or monitoring finding, and close items only with evidence attached. For CMMC, the Affirming Official should read both before each yearly affirmation, because the affirmation is a statement to the government.
How does NetSys help with SSPs and POA&Ms?
We start with where CUI arrives, who opens it and where it is stored, then draw an enclave boundary and run a gap assessment with a scored, prioritized remediation plan. We implement the requirements inside the boundary, write the SSP requirement by requirement from the configuration we deployed, keep open items on a plan of action within the limits the rule allows, and organize the evidence by requirement. Afterwards we run monitoring and patching in the enclave, hold quarterly control reviews and prepare an annual affirmation package for leadership. Agreements run month to month.
Have a plan that was written from a template and never matched to the systems? Book a call and we will compare it with your configuration.
Frequently asked questions
What does the SSP and POA&M template cover?
The SSP template covers system identification, purpose and CUI types, users, boundary and environment, inventory, threats, requirement-by-requirement implementation, outside providers, related documents, the review record and distribution. The POA&M template covers each open weakness with its requirement, owner, resources, milestones, completion date, status and, for CMMC, the point value and whether it is allowed.
Who maintains the system security plan?
A named security officer, with the system owner approving changes and an IT provider supplying the technical detail. The plan must change when the system does, so tie updates to change management and review it on a fixed schedule as well.
How do we validate the SSP and POA&M?
Check every SSP statement against the live system using the three methods in NIST SP 800-171A: examine configurations and records, interview the people responsible, and test that each safeguard works. Then check every plan of action item against 32 CFR 170.21 and score the result with the 32 CFR 170.24 method before anything goes into SPRS.
Does NIST provide official SSP and POA&M templates?
Yes. NIST publishes a CUI SSP template and a CUI plan of action template as Word documents on its SP 800-171 Revision 2 page. Revision 3 says the format is up to you, so the templates above follow NIST's fields and add the CMMC columns.
Can the system security plan go on a POA&M?
No. Under 32 CFR 170.21 the SSP requirement (CA.L2-3.12.4) can never be included in a plan of action, and the Department's FAQ says an SSP marked as not met means the assessment produces no score. Write the SSP first.
Sources and further reading
- NIST SP 800-171 Rev. 2: requirements 3.12.2 and 3.12.4, with the CUI SSP template and CUI plan of action template, checked October 2026.
- NIST SP 800-171 Rev. 3: requirements 03.12.02 and 03.15.02 and the guidance on SSP and plan of action formats, checked October 2026.
- NIST SP 800-171A Rev. 3: the examine, interview and test methods, checked October 2026.
- 32 CFR Part 170, CMMC Program, eCFR: plan of action limits, scoring and provider documentation, checked October 2026.
- CMMC Program FAQs, revised July 13, 2026 (PDF): no score without an SSP, closeout assessments and operational plans of action, checked October 2026.
Discuss cmmc 2.0 compliance services for your business.
Tell us about your current systems, the result you need and your timeline. We will discuss the work, responsibilities and pricing before you decide on an engagement.