A plan of action and milestones, or POA&M, is a list of what is wrong and what you are doing about it. NIST SP 800-53 asks for one in CA-5. NIST SP 800-171 asks for one in requirement 3.12.2. FedRAMP and CMMC both rely on one. Every assessor will read yours.
What they look for is not a short list. A long, well-managed POA&M is more convincing than a short one that looks as though it was written the night before. Assessors read it to answer two questions: do you know where your gaps are, and are you actually closing them? This article covers the fields a POA&M needs, how to write milestones that hold up, what a POA&M cannot do for you, and how to keep it alive between assessments.
What a POA&M is for
CA-5 asks you to develop a plan of action and milestones documenting planned remediation of weaknesses found during control assessments, and to update it at a defined frequency based on findings from assessments, independent audits, and continuous monitoring. Requirement 3.12.2 in 800-171 Rev. 2 is shorter: develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities.
Both treat the POA&M as a management tool, not an assessment artifact. It should exist because you use it to run remediation, not because an assessor will ask for it. Assessors can tell the difference. A working POA&M has dated updates, changed milestones with reasons, and closed items with evidence. A POA&M written for the assessment has none of those.
The fields that matter
Templates vary. FedRAMP publishes its own, and many organizations build one in a spreadsheet or ticketing system. Whatever the format, each item should carry these fields.
- Not done:
Identifier. A unique ID that never changes, even after closure.
- Not done:
Weakness. What is wrong, specifically enough that someone else could verify it.
- Not done:
Source. How it was found: self-assessment, scan, audit, incident, continuous monitoring.
- Not done:
Affected requirement or control. The 800-171 requirement or 800-53 control, by number.
- Not done:
Affected assets. Which components, or "all in-scope endpoints."
- Not done:
Date identified.
- Not done:
Risk rating. Your assessment of severity, with the basis for it.
- Not done:
Owner. A role and a named person accountable for closure.
- Not done:
Interim mitigation. What reduces the risk until the fix lands.
- Not done:
Remediation plan. What will be done.
- Not done:
Milestones. The steps, each with a date.
- Not done:
Resources. Budget, staff, or purchases the plan depends on.
- Not done:
Scheduled completion date.
- Not done:
Status and history. Current status, and a log of changes to dates and milestones with reasons.
- Not done:
Closure evidence. What shows the weakness is fixed, and who verified it.
The weakness description and the closure evidence are the two fields most often left thin. Without the first, nobody can tell whether the fix addresses the problem. Without the second, nobody can tell whether it was fixed.
Writing milestones an assessor believes
A milestone is believable when it is specific, dated, owned, and in a sensible order. Compare two versions of the same hypothetical item, covering missing multi-factor authentication for local administrator logons on in-scope servers.
A weak entry:
Weakness: MFA not fully implemented.
Milestone: Implement MFA. Due: Q4.
A stronger entry:
Weakness: Local console and local administrator logons on the 12 in-scope servers do not require MFA, contrary to requirement 3.5.3. Remote and network logons already require it.
Interim mitigation: Local administrator passwords are unique per server and rotated after each use; console access is physically restricted to the server room.
Milestones: Select an MFA method compatible with the server operating systems (by a set date). Pilot on two non-production servers (by a later date). Roll out to all 12 and disable password-only local logon (by a later date). Verify by attempting password-only logon on each server and record the result (by the completion date).
Owner: Infrastructure lead.
The second version tells an assessor exactly what is broken, how exposed you are meanwhile, and how they will know it is done. It also shows the work has been thought through, which is what makes the dates credible.
What a POA&M cannot do
A POA&M records a gap. It does not close one, and several regimes say so explicitly.
DoD scoring. Under the DoD Assessment Methodology used for SPRS scores, a requirement that is not implemented loses its points whether or not it appears on a POA&M. A POA&M is evidence of management, not credit for implementation.
CMMC. The CMMC program rule in 32 CFR Part 170 restricts POA&Ms sharply. At Level 1, none are permitted. At Levels 2 and 3, a POA&M can support conditional status only if the assessment meets a minimum score, the items on it are among those the rule allows, and the items are closed within 180 days, confirmed by a closeout assessment. The rule generally limits POA&M items to lower-weighted requirements and excludes some outright, including the system security plan requirement. Read section 170.21 of the rule for the exact conditions before you rely on one.
Authorization programs. FedRAMP and agency authorizations expect POA&M items to be remediated within defined timeframes and reported on a schedule. An item that sits open past its deadline becomes its own problem.
The practical lesson: fix what you can before an assessment, and use the POA&M for what genuinely cannot be finished in time.
Keeping it alive
A POA&M that is updated once a year tells an assessor that remediation is managed once a year. Treat it as a live register.
Update on a fixed cadence. FedRAMP, for example, expects monthly updates as part of continuous monitoring. Set a frequency, state it, and meet it.
Add items as they are found. Findings from scans, monitoring, incidents, and internal reviews go in when found, not when the next assessment nears. Our article on continuous monitoring under 800-53 covers how findings flow in.
Record every date change, with the reason. Slipped dates are normal. Unexplained slipped dates are not.
Close with evidence. Attach the record that proves the fix, and have someone other than the implementer verify it where you can.
Keep closed items. Do not delete them. A history of closures is the best evidence that the process works.
Keep it consistent with the plan. Every requirement your system security plan marks as partial or planned should have a POA&M item, and every open item should match a plan entry.
Common mistakes
Vague weaknesses. "Logging gaps" cannot be verified or closed.
Dates nobody believes. A dozen large items all due in the same month, with no resources listed, reads as fiction.
Everything rated high. If every item is high risk, the rating carries no information.
No interim mitigation. An open gap with nothing reducing the risk in the meantime invites the question of why it was accepted.
Risk acceptance hidden in the POA&M. If a weakness will not be fixed, that is a risk acceptance, which needs a decision by someone with the authority to accept it. Record it as one.
When a control fails between assessments, the same principles apply; our article on what to do when a control fails mid-period covers the response side. Our CMMC framework page has more on how conditional status works within the program.
How TrustLynce helps
TrustLynce routes control failures found by continuous monitoring to the owning team, with a record of each result, so new weaknesses reach your plan of action when they occur rather than at the next assessment. See continuous monitoring.