- Findings from assessments, the risk register's mitigate decisions, and incident lessons learned
- Realistic resource information — hours, licenses, budget — for each entry, or the entry is a wish
- The evidence index (ATL-008), so closure evidence has a filed home
ATL-006TRACKEREDITORIAL REVIEW COMPLETE
Plan of Action & Milestones (POA&M) Template
A tracker for the weaknesses the organization has committed to fix: each entry a deficiency with a named responsible person, the resources it actually needs, dated milestones, a scheduled completion that is managed rather than wished at, and closure only against retained evidence.
Using this artifact
Purpose, inputs, and completion
Purpose. A plan of action and milestones is the organization's managed commitment to fix what it knows is broken — with names, dates, resources, and proof of finish. It is not a parking lot for findings, and moving a weakness onto it changes nothing about the weakness; only the milestones do that. This template provides the columns and the operating discipline that keep the commitment real.
When to use it. Feed it from assessments, the risk register's mitigate decisions, and incident lessons; open entries promptly, while the finding is still embarrassing enough to fund. Review every open entry monthly with the responsible people present, and treat a slipped date as a decision to record, not an awkwardness to hide. Close entries only when the evidence is named, filed, and verified — the closure column, not the status column, is where a POA&M earns its credibility.
- Open one entry per deficiency, written as the observed weakness — not as the project name of the intended fix.
- Assign a named responsible person and the resources required before setting dates; dates without resources are fiction with a deadline.
- Break the work into two to four dated milestones so slippage is visible mid-course, not discovered at the end.
- Record slips by adding the new date alongside the old one with a reason — never by overwriting history.
- Close entries only against evidence: name it, file it where the evidence index says, and record who verified it.
Keeping it honest
Evidence, validation, and failure modes
- A dated record of known deficiencies with owners, resources, and milestone history
- A slip history showing schedule changes were decided and explained, not silently rewritten
- Closure records tying every finished entry to named, filed, verified evidence
- Pick any closed entry and produce its closure evidence within ten minutes from the location recorded; failure means the entry is not actually closed.
- Sort open entries by original scheduled completion; any entry past its date with no recorded slip reason and no escalation is aging invisibly, which is the failure this tracker exists to prevent.
What looks done but is not
- The parking-lot POA&M: entries added to make findings feel handled, with no resources, no milestones, and no intention — a to-do list wearing a governance costume.
- Slips overwritten in place, so the tracker always shows a plausible future and never shows the three re-baselines behind it.
- Closure by assertion: status flipped to Closed on someone's say-so, with nothing retained that a reviewer could examine.
Mapped relationships
Practices and requirements this artifact relates to
Brilliant at the Basics practices
NIST SP 800-171 Rev. 2
NIST SP 800-171 Rev. 3
Relationships are mapped support, not equivalence: completing this artifact documents work relevant to these requirements and does not by itself address any of them. Retention: Retain closed entries with their closure evidence for at least three years; a closed line whose evidence cannot be produced reopens itself at assessment time.
Full document
Preview — exactly what prints
TRACKER · GOVERNANCE & PROGRAM MANAGEMENTv1.0 · REVIEWED 2026-08-06
Plan of Action & Milestones (POA&M) Template
Brilliant at the Basics Resource Center · brilliantatthebasics.us · published by inDirectIT, Inc.
Independent educational material. Not affiliated with, sponsored by, approved by, or endorsed by the U.S. Department of War. Does not establish compliance, certification, or contractual standing.
Purpose
A plan of action and milestones is the organization's managed commitment to fix what it knows is broken — with names, dates, resources, and proof of finish. It is not a parking lot for findings, and moving a weakness onto it changes nothing about the weakness; only the milestones do that. This template provides the columns and the operating discipline that keep the commitment real.
How to use it
Feed it from assessments, the risk register's mitigate decisions, and incident lessons; open entries promptly, while the finding is still embarrassing enough to fund. Review every open entry monthly with the responsible people present, and treat a slipped date as a decision to record, not an awkwardness to hide. Close entries only when the evidence is named, filed, and verified — the closure column, not the status column, is where a POA&M earns its credibility.
What a POA&M is — and is not
A managed commitment, not a parking lot
An entry on this tracker is a promise with a name, a date, and a budget attached. Listing a weakness here does not reduce it, does not address any requirement, and does not make the weakness acceptable in the meantime — it makes the weakness owned. Entries that sit for months without resources or milestone movement are not being managed; they are being stored, and a reviewer will read them exactly that way.
Write the weakness as observed ('backup restore has never been tested for the file server'), not as the fix's project name ('backup modernization initiative'). The weakness is the fact a reviewer verifies; the project is just one way to end it.
The tracker
The working table. The CSV download carries the same columns for spreadsheet use.
Rows beginning EXAMPLE: show the expected shape — replace them with your own. Requirement references are mapped relationships, not equivalence claims.
| ID | Weakness or deficiency | Associated requirement reference | Source of finding | Responsible person | Resources required | Milestones (with dates) | Scheduled completion | Actual completion | Status | Evidence of closure |
|---|---|---|---|---|---|---|---|---|---|---|
| EXAMPLE: POAM-004 | VPN authentication uses password only — no MFA | Rev. 2 3.5.3 (mapped) | Internal assessment, 2026-06 | J. Rivera (IT lead) | 12 MFA tokens; 2 admin days; MSP change window | 1) Pilot group live 2026-09-15; 2) All users enrolled 2026-10-01; 3) Password-only path disabled 2026-10-15 | 2026-10-15 | In progress | Configuration export + authentication log sample, to be filed per evidence index at closure | |
Aging discipline
POA&Ms do not fail loudly; they fail by quietly getting old. These rules make age visible.
- Every entry gets a scheduled completion the day it is opened
- An entry with no date is not yet a commitment; do not add it until someone will commit.
- Slips are recorded, never overwritten
- Keep the original date, add the new one, and write the reason — the slip history is the management evidence.
- Any entry slipping twice goes to the executive review by name
- Any entry older than a year is re-justified from scratch or escalated as a de facto acceptance
- Send de facto acceptances to the risk register for a real decision.
- The monthly review walks every open entry, not just the interesting ones
Closure evidence
An entry closes when a stranger could verify the fix from what you kept — not before.
Good closure evidence shows the fixed state, not the effort: a configuration export after the change, a log sample demonstrating the new behavior, a retest result against the original finding. File it where the evidence index says it lives, and record here who verified it and when. 'Ticket closed by MSP' is a receipt for work billed, not proof of a weakness ended.
Closure log
| POA&M ID | Evidence of closure (what it is) | Where filed (evidence index ID) | Verified by | Date verified |
|---|---|---|---|---|
Document control, version history, and approval
An artifact without an owner, a review date, and an approval trail is a snapshot, not a record. Complete this section before the document is used, and update it at every review.
| Field | Entry |
|---|---|
| Document owner (named person) | |
| Suggested owner role | IT leader or compliance lead |
| Approval authority | Executive sponsor |
| Review frequency | Monthly working review of all open entries; executive review quarterly and at every scheduled-completion slip |
| Next scheduled review | |
| Storage location of the completed document | |
| Retention | Retain closed entries with their closure evidence for at least three years; a closed line whose evidence cannot be produced reopens itself at assessment time. |
Version history
| Version | Date | Author | Summary of change | Approved by |
|---|---|---|---|---|
Review and approval
| Reviewed by | Role | Date | Signature / initials |
|---|---|---|---|
Complete this offline — and mind what you write down
Fill this in inside your own environment, not on any public website or unapproved cloud tool. A completed copy may reveal your security posture: never include CUI, export-controlled data, credentials or keys, unremediated vulnerability details, network diagrams, or customer-sensitive information beyond what the artifact strictly needs, and store the completed document with the same care as the systems it describes.
What completing this artifact does and does not do
This is independent educational material. Completing it documents your work and produces records a reviewer can examine — it does not, by itself, implement a safeguard, satisfy any NIST SP 800-171 requirement, establish compliance with DFARS or CMMC, or replace your own analysis within your defined system boundary. Requirement references are mapped relationships, not equivalence claims. Tailor every section to your technical, operational, contractual, regulatory, and safety requirements.