SSP and POA&M: the two documents every assessor asks for

When an assessor sits down, two documents come out before anything else: the System Security Plan (SSP) and the Plan of Action & Milestones (POA&M). They are not paperwork you produce to satisfy a checkbox. They are the map an assessor uses to navigate your environment and the ledger of what you have not yet fixed. Get them right and the rest of the assessment has a spine. Get them wrong and every control becomes an argument.

What a System Security Plan must actually describe

NIST SP 800-171 treats the SSP as a required control in its own right, not an optional artifact. Its job is to describe your system boundary and how each of the 110 security requirements is implemented within it. A serviceable SSP answers four questions without ambiguity.

• The boundary. What is in scope? Which networks, hosts, cloud tenants, and services store, process, or transmit CUI — and, just as importantly, what is deliberately out of scope and why. An assessor cannot evaluate a boundary you have not drawn.
• The controls. For each requirement, how it is met — the specific technology, configuration, or process that satisfies it. "We use MFA" is a claim; "MFA is enforced via [platform] for all network and remote access, per policy [ref]" is a description an assessor can test.
• The roles. Who owns what. Which people or roles are responsible for administering, monitoring, and maintaining each area — and where a managed provider or enclave carries part of the responsibility.
• The data flows. How CUI moves through the environment: where it enters, where it rests, where it leaves, and the safeguards at each transition. This is what turns a boundary diagram into a defensible scope.

The SSP is also where inheritance is documented. If controls are satisfied by a cloud service or a managed enclave, the plan must say so and reference the shared-responsibility split. An assessor who cannot trace a control to an owner will treat it as unowned.

What a POA&M is — and how it is meant to be used

The POA&M is the honest companion to the SSP. Where the SSP describes what is implemented, the POA&M records what is not, along with a concrete plan to close each gap. A useful POA&M line names the deficient control, describes the remediation, assigns an owner, and sets a milestone date. It is a project plan, not a confession — and a well-run POA&M is a sign of a mature program, not a failing one.

What the POA&M is not is a way to make a gap disappear. Under the DoD Assessment Methodology, an item on the POA&M is still an unmet control and still subtracts from your SPRS score. The plan communicates intent and timeline; it does not restore points.

The limits under CMMC

This is where teams get caught. Under CMMC, a passing assessment does not require every single control to be met on day one — a limited POA&M is permitted — but the allowance is narrow and conditional, and it comes with hard rules.

• Not every control is POA&M-eligible. The highest-weight requirements — the ones the methodology scores at 5 points — generally cannot be left open on a POA&M. If one of those is unmet, it is a failed assessment, full stop.
• There is a minimum score to qualify. To close an assessment with a POA&M at all, you must clear a defined score threshold. Fall below it and no plan will bridge the gap; you remediate first, then reassess.
• There is a closeout clock. POA&M items must be resolved within a fixed window — on the order of 180 days — and verified. Miss the closeout and the conditional status lapses.

The practical takeaway: a POA&M is a short bridge over a few low-weight gaps, not a runway for the hard controls. Anything foundational must be genuinely done before assessment day. This verification regime is the whole point of DFARS 252.204-7021 layering CMMC on top of the long-standing 800-171 obligation in DFARS 252.204-7012.

Documentation gaps that become findings

Most SSP and POA&M findings are not exotic. They are the same recurring failures of discipline, and they are avoidable.

• The SSP does not match reality. The plan describes a control the environment does not actually implement, or vice versa. Assessors sample; the moment the document and the system disagree, credibility drops for everything.
• Vague implementation statements. "Access is restricted appropriately" tells an assessor nothing testable. If a statement cannot point to a configuration or a policy, it will be probed.
• An undefined or overbroad boundary. A scope that quietly sweeps in systems you cannot defend, or omits systems that touch CUI, is a finding waiting to happen.
• A stale POA&M. Milestone dates months in the past with no closure, or items that never move, signal that no one is running the plan.
• No owners. Controls and POA&M items without a named responsible party read as aspirational rather than operational.

Keeping them living documents

The single biggest mistake is treating the SSP and POA&M as deliverables that get filed after the assessment. They are operating documents. When you change a firewall rule, migrate a workload, add a CUI data flow, or onboard a new tool, the SSP should change with it. When you close a gap, the POA&M item closes with evidence. When you discover a new one, it opens.

• Tie updates to change management. Any material change to a CUI system triggers an SSP review. Make it a step in the process, not an annual scramble.
• Review the POA&M on a cadence. Monthly at minimum: what closed, what slipped, what is newly open, and whether any closeout clock is at risk.
• Keep the evidence next to the claim. When the SSP says a control is met, the artifact that proves it should be findable. That is what makes the annual affirmation in SPRS defensible.

Where Atom fits — and where we do not

We build SSPs that describe the environment accurately enough to survive sampling, and POA&Ms that are real project plans with owners, dates, and a closeout discipline that respects the CMMC limits. Then we keep both current as your environment changes, so the documents an assessor asks for are the same ones you use to run the program. We are direct about one boundary: Atom is not a C3PAO and does not issue CMMC certifications. We prepare the documentation so the certifying assessment has nothing to argue with.