Knowing how to write a POA&M is one of those skills every ISSO is assumed to have and almost nobody is taught. The Plan of Action and Milestones is the document that tells your Authorizing Official: here’s what’s still wrong with the system, here’s what we’re doing about it, and here’s when it will be fixed. Write it well and open findings become managed risk the AO can accept. Write it badly and the same findings become reasons to sit on your authorization.
This guide covers how to write each field, how to build milestones that survive contact with reality, and two worked examples — one CAT I, one CAT III — you can pattern off directly.
What a POA&M Is Actually For
A POA&M entry exists because something failed: a control assessment, an ACAS scan, a STIG check. The entry is not a confession — it’s a risk management instrument. It converts an open weakness into a bounded, scheduled, resourced plan, which is exactly the form an AO needs in order to accept the residual risk and authorize anyway. That framing changes how you write: every field should answer a question the AO’s staff will actually ask.
Writing entries is half the job; keeping them moving is the other half, which I covered in POA&M Management: How ISSOs Actually Track and Close Findings. This post is about getting the entry right the first time.
How to Write a POA&M, Field by Field
| Field | What good looks like |
|---|---|
| Weakness description | Specific enough that someone new could find the deficiency: the control, the asset scope, and what’s deficient — not a copy-paste of the scanner plugin text |
| Source | The exact origin: assessment finding number, scan date and plugin ID, STIG rule ID. This is how closure evidence gets traced later |
| Severity / risk rating | Taken from the actual finding for this system — never copied from a similar entry on another package |
| Resources required | Named and honest: labor hours, funding, a tool purchase, an engineering change window. “Existing resources” is only true if it’s true |
| Milestones | Discrete, verifiable steps with dates — the heart of the entry (more below) |
| Scheduled completion date | Driven by the milestone chain, not picked to look good in a briefing |
| Point of contact | The person who can actually move the work — usually not the ISSO |
| Mitigations | What’s reducing the risk right now, while the fix is pending — this is what the AO is really accepting |
Milestones: Where POA&Ms Live or Die
A milestone is a verifiable event, not a vibe. “Work with engineering to address finding” is not a milestone; nobody can say the day it finished. “Patch deployed to all 14 production servers, validated by rescan” is a milestone — it happened on a date or it didn’t.
Three rules that keep milestone chains honest. First, three to five milestones per entry — one milestone means you haven’t broken the work down; ten means you’re tracking tasks, not milestones. Second, each milestone gets its own date, and the dates come from the people doing the work, not from what sounds acceptable in eMASS. Third, when a date slips — and dates slip — you update the milestone with a documented reason and a new date before it goes overdue, not after the assessor notices. A slipped-but-explained milestone is normal risk management; a silently overdue one reads as an unmanaged package, and it’s one of the fastest credibility killers in an eMASS review.
Worked Example 1: CAT I Finding
Weakness: Domain controllers (3 assets) running an OS version past end of extended support; no vendor security patches available. Identified by ACAS scan 2026-06-12 and STIG review. Maps to SI-2 (Flaw Remediation) and CM-6.
Mitigations in place: Assets isolated to a management VLAN with ACLs restricting inbound traffic to administrative subnets; enhanced audit logging forwarded to SIEM; weekly credentialed scans monitoring for exploitation indicators.
Milestones: (1) Replacement server hardware delivered — Aug 15. (2) New OS built, STIGed, and validated in staging — Sep 12. (3) Domain controller roles migrated, one per maintenance window — Oct 10. (4) Legacy assets decommissioned and removed from the boundary; closure rescan attached — Oct 24.
Notice what makes this acceptable to an AO despite being a CAT I: the mitigations are concrete and currently active, the milestones are hardware-and-calendar realistic rather than optimistic, and closure is defined by evidence (the rescan), not by assertion.
Worked Example 2: CAT III Finding
Weakness: Session lock banner text on 6 workstations does not match the current DoD-mandated wording (AC-8). Identified during control self-assessment 2026-06-20.
Milestones: (1) Corrected banner pushed via GPO — Jul 18. (2) Spot-check of all 6 workstations documented with screenshots — Jul 25.
Low-severity entries earn short, plain plans. Two milestones, two dates, done. Padding a CAT III with five milestones and a six-month timeline signals that your team can’t calibrate effort to risk — and calibration is precisely what the POA&M is supposed to demonstrate.
The Mistakes That Get POA&Ms Rejected
- Scanner text pasted as the weakness description. Plugin output describes a signature, not your system. Translate it: which assets, which control, what’s actually deficient.
- Completion dates chosen politically. A date picked to look good in a quarterly brief will slip, and documented slippage on top of an unrealistic baseline is worse than an honest longer estimate.
- Mitigations left blank on high findings. An open CAT I with no interim mitigations is an unmanaged risk — that entry alone can stall an authorization decision.
- One giant entry covering many findings. Bundling 40 scan findings into “remediate vulnerabilities” makes closure untrackable. Group only what shares a single remediation action.
- No closure evidence defined. Every entry should say what artifact proves it’s done: rescan, screenshot, updated config export. Entries without defined evidence linger forever — the daily and weekly review rhythm from my RMF Continuous Monitoring Checklist is what keeps them moving instead.
Stop building your POA&M from scratch
The POA&M Tracker ($37) is the exact spreadsheet I use for every entry in this post — field-by-field structure, milestone tracking, aging flags, and closure evidence columns already built.
Final Thoughts
Learning how to write a POA&M well is learning to speak the AO’s language: bounded weakness, active mitigations, verifiable milestones, honest dates, defined evidence. Every field is an answer to a question someone reviewing your package will ask — write it so they never have to ask twice. Do that consistently and your POA&M stops being the scariest document in the package and becomes the one that proves your program actually manages risk.
Leave a Reply