A system security plan (SSP) is the written record of how you actually protect a system today, and a plan of action and milestones (POA&M) is the dated list of gaps you have not closed yet with the deadlines to close them. Together they are the two documents an assessor reads first when your firm pursues NIST 800-171 or CMMC compliance. The SSP is the honest photograph of your security right now. The POA&M is the to-do list attached to that photograph. Most SMBs I work with own neither document in a usable form, or they own a template someone downloaded, never filled in, and forgot. That gap is why good companies fail assessments they could have passed.
The 5 Basics at a Glance
Before we go section by section, here are the five principles that decide whether your paperwork survives review. Each one is a lesson from watching small firms hand over documents that looked finished and were not.
- An SSP describes reality, not intention. It records the controls you have running now, not the ones you plan to buy. An assessor tests what you wrote against what they see on your network.
- A POA&M is a promise with a date. Every open item needs an owner, a fix, and a deadline. A POA&M without dates reads as a wish list, and an assessor treats it that way.
- The two documents must agree with each other. Every gap named in the SSP should appear in the POA&M, and every POA&M item should trace back to a control in the SSP. Contradictions between them are the fastest way to lose credibility.
- They are living files, not one-time deliverables. Your environment changes every quarter. An SSP that has not been touched since last year is already wrong.
- They are business documents, not IT documents. Leadership funds the POA&M and signs off on residual risk. If the plans live only with your IT team, the gaps never get budget.
Who this is for: SMBs in the 25 to 500 employee range that handle controlled unclassified information (CUI), sell into the defense supply chain, or need to prove security maturity to win contracts and cyber insurance. If that is you, these two documents are not optional.
What a System Security Plan Actually Contains
A system security plan documents every control protecting a system that stores, processes, or transmits sensitive data, and it names who is responsible for each one. Think of it as the manual for your own security program, written so a stranger could audit it without a tour. The frameworks that require it, chiefly NIST SP 800-171 and CMMC, expect the SSP to cover the full scope of systems in play, not just the flashy parts.
When we build an SSP for a client, the file has to answer four plain questions for each system. What is this system and what data does it touch? Which security requirements apply to it? What controls are in place to meet those requirements? And who owns each control day to day. A reviewer should be able to read one page and understand your network boundary, your user roles, and your safeguards without guessing.
Which components a reviewer expects to see
An SSP is judged complete when it maps every applicable requirement to a described control, so start with scope. A defensible plan opens with a system boundary diagram, a data flow showing where CUI enters and leaves, and an inventory of hardware, software, and cloud services in scope. From there it works through administrative, physical, and technical safeguards, each tied to the requirement it satisfies.
Some teams argue an SSP should stay short and readable. Others argue it should be exhaustive enough to survive a hostile audit. Both views hold weight. A short plan gets read and used, but a thin plan leaves gaps a reviewer will punish. Our team lands in the middle: describe every applicable control in enough detail that someone outside your company could verify it, and no more. Where the requirement asks for encryption, name the standard and where it runs. Where it asks for access control, name the roles and how you remove access when someone leaves, which is a step we cover in depth in our guide on how to offboard employees without leaving security gaps.
Why SMBs get the SSP wrong
The most common SSP failure is writing intention as if it were reality. A plan that says multi-factor authentication is enforced on all remote access, when it runs on email only, is not a document error. It is a finding, and a serious one, because it signals the whole file may be aspirational. Assessors have seen thousands of these, and they test claims against evidence.
The opposite failure also happens: teams describe a control so vaguely that no one can confirm it exists. “We use strong passwords” tells a reviewer nothing. “We enforce a 14-character minimum with lockout after five failed attempts, verified in our identity platform” gives them something to check. The unbiased read is that an SSP earns trust through verifiable detail, and loses it through both exaggeration and vagueness. A pre-assessment review, which we run as part of our cyber security audits, catches these before an official assessor does.
What a POA&M Does That the SSP Cannot
A plan of action and milestones tracks every gap between the security you have and the security a framework requires, and it commits your firm to closing each gap by a stated date. If the SSP is the photograph, the POA&M is the punch list. You will almost never pass an assessment with zero open items, and pretending you have none is more suspect than admitting a handful with credible timelines.
The POA&M exists because compliance is a moving target and honesty scores better than perfection. A reviewer would rather see eight tracked weaknesses with owners and deadlines than a spotless SSP they do not believe. Under CMMC, some requirements can be closed on a POA&M with a limited remediation window while others cannot be deferred at all, so knowing which gaps are eligible matters as much as listing them.
How to write a POA&M an assessor respects
A POA&M is credible when every line carries a weakness, the control it maps to, a named owner, a corrective action, resources committed, and a milestone date. Skip any of those fields and the item reads as filler. The strongest POA&Ms we produce read like a project plan, because that is what remediation is.
There is real debate about how aggressive the dates should be. Aggressive deadlines show intent but invite failure if you miss them, and a missed POA&M date recorded in your own file becomes evidence against you next cycle. Conservative dates are safer but can signal a program that is not serious. We advise clients to set dates they can actually hit and then beat them, because a POA&M that closes items early builds the exact track record insurers and prime contractors want to see. Continuous network security monitoring is what turns those closures from claims into logged, provable events.
Keeping the POA&M honest over time
The POA&M only works if it stays current, which means reviewing it on a fixed cadence rather than the week before an audit. Items close, new weaknesses appear after a system change, and a stale POA&M drifts out of sync with the SSP fast. A quarterly review is the floor for most SMBs, monthly if you are in an active remediation push.
The counterargument is that constant editing burns time a small team does not have. That is fair, and it is why the review should be short and structured, not a rewrite. Walk the open items, update status and dates, add anything new from the last quarter’s changes, and close what is done with a note on the evidence. Firms that treat this as a standing rhythm, the way the financial advisory firm in our case study did, stop dreading assessment season because their file is always close to ready.
How the SSP and POA&M Work as One System
The SSP and POA&M are only useful when they reference each other, because a gap named in one and missing from the other exposes a broken process. An assessor cross-checks them deliberately. If your SSP admits a control is partially implemented but your POA&M has no matching remediation line, that mismatch tells them your paperwork and your program are not connected.
The practical rule our team enforces is simple. Every “planned” or “partially implemented” control in the SSP gets a corresponding POA&M entry, and every POA&M entry cites the SSP control it will satisfy. When both files move together, they form a live compliance record instead of two documents that happen to sit in the same folder. That coherence is also what makes ongoing managed security services worth the spend, because a managed security services provider can maintain the pair against real change instead of reconstructing them from scratch every year. For a fuller catalog of where these documents go wrong, our companion piece on the traps small firms miss with system security plans and POA&Ms is worth a read alongside this one.
Who Owns These Documents Inside an SMB
Ownership of the SSP and POA&M belongs to leadership, with IT and security supplying the technical detail, because the residual risk recorded in these files is a business decision. When the documents live only with a systems administrator, the gaps that need budget never reach the people who control budget, and the POA&M stalls.
Some leaders push back that this is IT’s job. In one sense it is, since IT knows which controls run where. But accepting a gap on a POA&M means accepting risk on behalf of the company, and that authority sits with an owner or officer, not an engineer. We recommend a named business owner for the POA&M who signs off on every deadline, with security and IT owning the technical accuracy of the SSP. That split keeps the plans truthful and funded. Training the wider staff to recognize the threats these controls defend against, which is what our security awareness training builds, closes the loop between the paperwork and the people, and it closes common compliance gaps that documentation alone cannot. As attackers begin using AI to probe defenses faster, a topic we cover in our piece on adversarial AI and in our work on AI enhanced security, the value of a current, honest SSP only grows.
Frequently Asked Questions
What is the difference between a system security plan and a POA&M?
A system security plan documents the security controls you have in place today, while a POA&M lists the gaps you still need to close and the dates you will close them by. The SSP is your current state, and the POA&M is your remediation plan. An assessor reads both and expects them to agree with each other.
Do all SMBs need an SSP and a POA&M?
SMBs that handle controlled unclassified information, sell into the defense supply chain, or must meet NIST 800-171 or CMMC need both documents. Many firms outside those requirements still benefit from an SSP because it forces an honest inventory of their controls. If a contract or an insurer asks for proof of your security program, these are the files they mean.
Can you pass a CMMC assessment with open POA&M items?
Yes, within limits. CMMC allows certain requirements to be closed on a POA&M with a defined remediation window, though some high-weight requirements cannot be deferred at all. The safest path is to close as much as possible before the assessment and carry only eligible, well-documented items with realistic dates.
How often should we update these documents?
Review the POA&M at least quarterly and update the SSP whenever your environment changes, such as a new cloud service, a network redesign, or a change in who handles sensitive data. A file that has sat untouched for a year is almost always out of date. Treating both as living documents is what keeps you close to audit-ready year round.
Who should write the SSP and POA&M?
IT and security own the technical accuracy of the SSP, while a business owner or officer owns the POA&M and signs off on the deadlines and accepted risk. Many SMBs bring in an outside partner to build the first version and then maintain it, because the initial mapping of controls to requirements is where most self-authored plans go wrong.
Get Your SSP and POA&M Assessment-Ready
The firms that clear NIST 800-171 and CMMC assessments are rarely the ones with perfect security. They are the ones whose documents tell the truth, agree with each other, and carry credible dates for every open item. An SSP that describes your real controls, paired with a POA&M that reads like a funded project plan, is worth more than a flawless-looking file an assessor cannot trust. The two work as a pair or not at all, and both have to stay alive as your systems change through the year.
If your current documents are a downloaded template with blank fields, or you are not sure your SSP and POA&M would survive a cross-check, that is a solvable problem and a common one. Our team maps your controls to the requirements that apply to you, builds both documents to hold up under review, and keeps them current so assessment season stops being a scramble. Book a free strategy call and we will tell you honestly where your paperwork stands and what it takes to get it ready.
