RMFInsider

Every ISSO inherits a POA&M eventually, and most inherit one that’s a mess. Dozens of line items, half of them with milestone dates that quietly slid by months ago, a few marked “in progress” that haven’t moved since the last assessment, and at least one finding nobody on the current team remembers the context for.

The Plan of Action and Milestones is supposed to be a living risk-tracking document. In practice, it often becomes a graveyard of findings that everyone agrees are a problem but nobody owns. This guide covers what a POA&M is actually for, how it gets out of control, and how to manage one in a way that doesn’t turn into a part-time job of its own.

---

What a POA&M Is Actually For

A POA&M exists to document known weaknesses, the plan to fix them, who’s responsible, and by when. Every finding from a vulnerability scan, a security control assessment, or a STIG check that can’t be remediated immediately gets a line item: what the weakness is, the risk it represents, the planned remediation, the resources required, and a milestone date.

That’s the theory. The reason it matters in practice is that the POA&M is one of the first things an assessor or an Authorizing Official looks at during continuous monitoring. A POA&M with accurate, moving milestones signals that risk is being actively managed. A POA&M full of stale dates signals the opposite, even if the underlying system is actually fine.

---

Real-World Example: The Milestone That Meant Nothing

I once took over a POA&M with a finding for an unpatched service that had a milestone date eight months in the past. When I asked the engineering team about it, nobody remembered the finding existed. The patch had actually been applied four months earlier, as part of a routine update cycle, but nobody had gone back into the POA&M to mark it resolved.

On paper, that finding had been overdue for months. In reality, it had been fixed and just never closed out. The gap wasn’t a security problem. It was a process problem: nothing connected the engineering team’s patch cycle back to the POA&M.

A POA&M is only as accurate as the feedback loop between the people doing the work and the person updating the document.

---

Why POA&Ms Spiral Out of Control

A few patterns show up again and again:

• New findings get added faster than old ones get closed, especially after a vulnerability scan or assessment cycle
• Milestone dates get set without input from the team actually doing the remediation work, so they’re unrealistic from day one
• Findings that depend on something outside the ISSO’s control (a vendor patch, a budget approval, another team’s system) sit untouched because nobody owns the dependency
• Closed items don’t get marked closed because updating the POA&M isn’t part of anyone’s regular workflow

None of these individually look like a crisis. Together, over a year or two, they produce a POA&M with a hundred-plus line items where maybe a third reflect current reality.

---

Real-World Example: The Finding Nobody Could Close

One recurring finding involved a legacy application that required an outdated TLS version to function with a piece of hardware that couldn’t be replaced without a much larger modernization project. Every quarter, the milestone date got pushed back, because the actual fix depended on a procurement effort that was years away.

The mistake wasn’t the finding itself. Some risks genuinely take years to resolve. The mistake was treating it like every other POA&M item, with a near-term milestone date that everyone knew was fiction. Once we reclassified it as a long-term risk with compensating controls (network segmentation and enhanced monitoring on that specific connection) and an honest multi-year timeline tied to the modernization project, it stopped being a recurring red flag during assessments. The risk was the same. The documentation finally matched reality.

---

Prioritization: Not Every Finding Deserves Equal Attention

A POA&M with a hundred line items doesn’t mean a hundred things need equal urgency. Risk-based prioritization means looking at severity, exploitability, and what the finding actually exposes, not just working through the list in the order findings were discovered.

A critical vulnerability on an internet-facing system and a low-severity configuration finding on an isolated internal tool are not the same kind of problem, even if they sit on the same list with similar-looking due dates. Spending equal effort on both means the high-risk item doesn’t get the urgency it needs, and the low-risk item consumes time that could go elsewhere.

---

A Practical Approach to Managing Yours

Build a recurring review into your schedule, even if it’s just monthly. The goal isn’t to close everything every month. It’s to catch the items that have quietly become stale, either because they’re done and unmarked or because the milestone date is no longer realistic and needs an honest update.

Connect the POA&M to the team’s actual workflow. If engineers patch systems as part of a regular cycle, build a step into that cycle to flag which patches correspond to open POA&M items. The closer the POA&M is to the actual work, the less it drifts.

Separate findings that are genuinely in progress from findings that are stuck waiting on something outside your control. For the second group, document the dependency explicitly and set milestone dates that reflect that dependency’s actual timeline, not an arbitrary thirty or sixty days.

Finally, when you do close an item, document how it was verified. “Patched” without evidence is the same as not closing it at all from an assessor’s perspective. A screenshot, a scan result, or a configuration export takes a few minutes and saves a much longer conversation later.

---

Final Thoughts

A clean POA&M isn’t one with zero findings. Systems always have something open. A clean POA&M is one where every line item reflects something real: a genuine open risk, an honest timeline, and a clear owner. That’s what continuous monitoring is actually supposed to look like, and it’s a lot less work to maintain than the alternative once it’s set up that way.

If you’re still building out your RMF documentation, the RMF Artifacts Checklist covers where the POA&M fits alongside your other core artifacts.