A Plan of Action and Milestones (POA&M) is the record of every known weakness in a system, who will fix it, how and by when, and most programmes treat it as paperwork rather than as a live risk register. POA&Ms are required by NIST SP 800-53 control CA-5, by NIST SP 800-171 requirement 03.12.02, by FedRAMP authorisation and continuous monitoring, and by the CMMC programme rule, which sets hard limits on what may appear on one. This guide explains what each regime actually requires, gives a field-by-field template you can adopt, and shows how to run the POA&M as an operational tool with metrics, deviation handling and closure evidence. It is written for compliance leads, system owners, ISSOs and security engineers who maintain authorisation packages or prepare for CMMC and FedRAMP assessments.
Key takeaways
- A POA&M is a control, not an appendix. NIST SP 800-53 CA-5 requires you to develop it and update it at a defined frequency from assessments, audits and continuous monitoring, and PM-4 requires an organisation-wide process for it.
- Every finding needs an owner, a plan and a date. FedRAMP's template makes POA&M ID, affected controls, weakness source, asset identifier, point of contact, remediation plan, detection date and scheduled completion date mandatory fields.
- CMMC limits what you may defer. Under 32 CFR 170.21 a POA&M is never allowed for Level 1, Level 2 needs a score ratio of at least 0.8 and excludes named requirements, and every POA&M must be closed out within 180 days of the Conditional status date.
- Deviations are tracked, not deleted. Risk adjustments, false positives, operational requirements and vendor dependencies each have defined meanings and approval paths; operational requirements and vendor dependencies stay open risks.
- Measure age, not count. Overdue items by severity, mean time to close and slipped milestone rate tell an authorising official far more than the total number of open lines.
What a POA&M is and where it is required
NIST SP 800-53 Rev. 5 defines the system-level requirement in CA-5: develop a plan of action and milestones to document the planned remediation actions that correct weaknesses or deficiencies found when controls are assessed and to reduce or eliminate known vulnerabilities, and update it at an organisation-defined frequency based on control assessments, independent audits or reviews, and continuous monitoring. The guidance notes that POA&Ms are required in authorisation packages and are subject to federal reporting requirements set by OMB. CA-5(1) adds automation support so that the POA&M stays accurate, current and available. PM-4 sits at programme level: a process to develop, maintain and report POA&Ms for the security, privacy and supply chain risk management programmes, and to review them against the organisation's risk management strategy. The PM-4 guidance is explicit that non-federal organisations also benefit from documenting and tracking planned remediations.
| Regime | Where the POA&M requirement sits | What is distinctive |
|---|---|---|
| NIST SP 800-53 Rev. 5 (RMF systems) | CA-5, CA-5(1), PM-4 | Part of the authorisation package; the authorising official reads it to understand residual risk. |
| NIST SP 800-171 Rev. 3 | 03.12.02 Plan of Action and Milestones | Same core wording: document remediation of weaknesses from security assessments and reduce known vulnerabilities, update from assessments, audits or reviews and continuous monitoring. |
| CMMC (32 CFR Part 170) | Section 170.21 | Conditional status only; score threshold, excluded requirements and a 180-day closeout assessment. |
| FedRAMP (Rev. 5 legacy playbook) | CA-5 plus the FedRAMP POA&M Template | Monthly update, fixed remediation time frames, deviation request types and escalation triggers for late items. |
FedRAMP status note: on 24 June 2026 FedRAMP marked its Rev. 5 playbook pages, including the POA&M page and template, as legacy content kept for reference during the transition to the FedRAMP Consolidated Rules for 2026. The FedRAMP practices described below are taken from that legacy material (checked 27 October 2026). Confirm the current requirement in the consolidated rules before relying on any FedRAMP-specific value.
Anatomy of a good POA&M entry: the template
The FedRAMP POA&M Template (version 3.1 in the legacy asset set) is the most detailed public model and works well outside FedRAMP. It has Open, Closed and Configuration Findings tabs with identical columns, plus a tab for SSP (PL-2) deficiencies. The fields below follow its column set; adapt names to your tooling but keep the meaning.
| Field | What to record | Common mistake |
|---|---|---|
| POA&M ID | Unique, stable identifier in a schema the assessor can reuse (FedRAMP instructs assessors to use the CSP's schema for risk exposure table items) | Reusing IDs after closure, which breaks the audit trail |
| Controls | Every SP 800-53 or 800-171 control the weakness affects, for example RA-5, SC-13 | Listing one control when the weakness spans several |
| Weakness name and description | Plain description of the deficiency and its effect | Pasting a scanner title with no context |
| Weakness detector source and source identifier | Scanner, assessor, pen test or audit, and its finding or plug-in ID; CVE where relevant | Source that does not match the assessment report, so items cannot be traced |
| Asset identifier | Host names, images, accounts or components affected | "Multiple" with no list |
| Point of contact and resources required | Named owner (role and person), budget, people or vendor support needed | Owner is a team mailbox; no resourcing so the date is fiction |
| Remediation plan and milestones | Ordered steps with interim dates, including compensating controls in place now | One line saying "will patch" |
| Original detection date and scheduled completion date | Detection date drives the deadline; scheduled date is what you commit to | Resetting the detection date when a scan re-finds the issue |
| Status date and comments | Date of last update and what changed | No history, so slippage is invisible |
| Original and adjusted risk rating | Scanner or assessor rating, and any approved adjustment | Adjusting the rating without a documented rationale |
| Vendor dependency, last vendor check-in, product | Whether a fix depends on a supplier and when you last chased it | No check-in evidence |
| Risk adjustment, false positive, operational requirement, deviation rationale, supporting documents | Deviation type, approval status and the evidence | Deviations claimed but never approved |
The FedRAMP template also carries columns for CISA Binding Operational Directive 22-01 tracking and due date, which matter where an item is a known exploited vulnerability. If you are not under FedRAMP, keep a "known exploited" flag anyway and check items against the CISA KEV catalogue, because it is the strongest single signal for re-prioritising a line.
Remediation time frames and deviation types
NIST leaves the update frequency and remediation timing to the organisation (CA-5 uses an organisation-defined parameter). FedRAMP's legacy guidance sets concrete values, and many non-federal programmes copy them.
| Item | FedRAMP legacy rule | Practical note |
|---|---|---|
| Critical and High | Remediate within 30 days of discovery | FedRAMP will not approve an operational requirement for a High; you may mitigate it instead |
| Moderate | Remediate within 90 days of discovery | Ten or more Moderate items aged over 90 days was a detailed finding review trigger, over 120 days a corrective action plan trigger |
| Low | Remediate within 180 days of discovery | Still tracked; do not let lows age silently into permanent residents |
| Late Highs | Five or more High items aged over 30 days triggered a detailed finding review; over 60 days a corrective action plan | Track this count monthly; it is the number agencies watched |
| Update cadence | POA&M updated at least monthly | Monthly is a sensible default for any regime |
- Risk adjustment (RA): a reduction in the scanner-defined risk level, justified by mitigating factors or compensating controls that reduce likelihood or impact. It needs assessor validation or authorising official approval.
- False positive (FP): the reported vulnerability does not exist on the system. Once validated it moves to the Closed tab; until then it is pending.
- Operational requirement (OR): the finding cannot be remediated, for example because the system would not work or the vendor will not fix the product. An approved OR is still an open risk and must be reassessed periodically.
- Vendor dependency (VD): the fix depends on a supplier, such as a COTS patch not yet released. In the FedRAMP model a VD is not a deviation request and needs no approval, but High-risk VDs must be mitigated to Moderate through compensating controls within 30 days and the vendor must be contacted at least monthly, with evidence.
For how to write the underlying exception and acceptance decision, see the Security Exceptions and Risk Acceptance Guide and the Vulnerability Risk Acceptance and Exception Template. For setting organisation-wide deadlines, see the Remediation SLAs and Vulnerability Exceptions Guide.
CMMC POA&M rules in detail
CMMC is the regime where a POA&M decision can decide contract eligibility, so read 32 CFR 170.21 itself. The rules as published in the eCFR (checked 27 October 2026):
| CMMC level | POA&M allowed? | Conditions in 170.21 |
|---|---|---|
| Level 1 self-assessment | No | A POA&M is not permitted at any time. |
| Level 2 (self-assessment or C3PAO certification) | Yes, with limits | Assessment score divided by the total number of Level 2 requirements must be at least 0.8; no POA&M item may carry a point value above 1, except SC.L2-3.13.11 CUI Encryption where encryption is used but not FIPS-validated; AC.L2-3.1.20, AC.L2-3.1.22, CA.L2-3.12.4, PE.L2-3.10.3, PE.L2-3.10.4 and PE.L2-3.10.5 may not be on a POA&M. |
| Level 3 (DIBCAC certification) | Yes, with limits | Score ratio of at least 0.8 for Level 3 requirements; IR.L3-3.6.1e, IR.L3-3.6.2e, RA.L3-3.11.1e, RA.L3-3.11.4e, RA.L3-3.11.6e, RA.L3-3.11.7e and SI.L3-3.14.3e excluded. |
| Closeout | Mandatory | A POA&M closeout assessment within 180 days of the Conditional CMMC Status Date; it assesses only the NOT MET requirements on the POA&M. Performed by the organisation (Level 2 self), a C3PAO (Level 2 certification) or DCMA DIBCAC (Level 3). If not closed out in time, Conditional status expires. |
Two consequences follow. First, CA.L2-3.12.4 is the system security plan requirement, so a missing SSP cannot be deferred: see the System Security Plan Template and Guide. Second, because 180 days is short, size every CMMC POA&M item so it can be finished and evidenced well inside the window. For scoring and assessment mechanics, see the CMMC 2.0 Level 2 Assessment Guide and the NIST SP 800-171 and CMMC 2.0 Guide.
Running the POA&M: a step-by-step operating model
- Define the inputs. List every source that can create an item: control assessments, the security assessment report, authenticated vulnerability scans, configuration compliance scans, penetration tests, audits, incident lessons learned and supplier notices. FedRAMP required a POA&M line for every risk in the assessment report's risk exposure table.
- Set the rules before the first item. Document deadlines by severity, the update frequency (the CA-5 parameter), who may approve deviations, and when a group of findings becomes one item versus many. FedRAMP allowed assessors to combine unauthorised external services into one assessment risk, but required separate POA&M items because plans differ.
- Choose the system of record. A spreadsheet works for a single small system; at scale use a GRC or ticketing platform that exports to the required template. CA-5(1) is the control that asks for this automation.
- Link items to work. Every POA&M ID should map to change tickets or engineering tasks so status is pulled, not typed. Milestones should be interim and verifiable, for example "test patch in staging by 12 November".
- Review monthly with owners. Focus the review on overdue items, vendor dependencies and pending deviations; FedRAMP's collaborative continuous monitoring guidance makes the same point, since routine on-time items rarely need discussion.
- Close with evidence. Move an item to Closed only when a rescan, configuration export or assessor check proves the fix. FedRAMP expected items closed after the assessment report to be validated by the assessor at the annual assessment.
- Escalate predictably. Define thresholds that move an item from owner to CISO to authorising official, mirroring the FedRAMP escalation triggers for aged Highs and Moderates.
- Roll back cleanly. If a remediation breaks the system, reopen the item, record the failed attempt, apply or confirm compensating controls, and set a new milestone rather than quietly extending the date.
Organisation size changes the tooling, not the rules. A small contractor preparing for CMMC Level 2 can run one well-kept workbook with a weekly owner check-in. A cloud provider with several authorisations needs a single POA&M source per boundary, automated scanner ingestion, and a reporting layer per authorising official. PM-4 also allows multiple POA&Ms at system, mission and organisation level: keep them consistent so the same weakness is not tracked three ways.
Where identity fits
A large share of POA&M items in practice concern accounts and credentials: shared administrator logins, service accounts with interactive rights, API keys without rotation, certificates near expiry and missing MFA on privileged paths. These items age badly because the fix touches applications owned by other teams. Treat them as first-class POA&M entries with the affected account or key named in the asset identifier, the owning application team as point of contact, and an interim compensating control such as vaulting or IP restriction recorded straight away. See the Service Account Security Guide and the Service Account Inventory Template.
Measuring whether the POA&M works
- Overdue items by severity: count of open items past their scheduled completion date, split Critical/High, Moderate, Low. Target zero overdue Highs.
- Median days to close by severity: compare with your own deadlines (for FedRAMP-aligned programmes, 30, 90 and 180 days).
- Milestone slip rate: percentage of items whose scheduled completion date moved in the month. A high rate means plans are not resourced.
- Deviation share: percentage of open items carried as operational requirements or risk adjustments; rising values suggest the deviation route is being used to avoid fixing.
- Vendor dependency check-in currency: percentage of VDs with a vendor check-in in the last 30 days.
- Reopen rate: items closed and then re-found by the next scan, which shows weak closure evidence.
Log POA&M changes themselves: who changed a date, rating or status and when. An authorising official or C3PAO who sees a scheduled date rewritten without a comment will question every other line.
Framework mapping
| Framework | Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev. 5 | CA-5, CA-5(1), PM-4; inputs from CA-2, CA-7, RA-5; response from RA-7 | System and programme POA&M, assessment, continuous monitoring and risk response |
| NIST SP 800-171 Rev. 3 | 03.12.02 (with 03.12.01 Security Assessment and 03.11.02 Vulnerability Monitoring and Scanning) | Contractor systems handling CUI |
| NIST CSF 2.0 | ID.RA-06 risk responses are chosen, prioritised, planned, tracked and communicated; ID.IM-01 improvements identified from evaluations | Outcome language for non-federal programmes |
| CMMC | 32 CFR 170.21 | Conditional status, limits and closeout |
| FedRAMP | Legacy POA&M Template and continuous monitoring playbook; Consolidated Rules for 2026 | Monthly POA&M, deviation requests, escalation triggers |
Common failure patterns
- Dates set to pass review, not to finish work: every item scheduled for the last day of the allowed window, then extended. Resourcing fields stay blank.
- Detection date reset on rescan: treating a re-found vulnerability as new hides its true age and defeats the 30/90/180 day logic.
- Operational requirements as a parking lot: items marked unfixable once and never reassessed, although FedRAMP treats approved ORs as open risks needing periodic review.
- Vendor dependency with no evidence: no record of check-ins and no compensating control for High VDs.
- CMMC POA&M built on an excluded requirement: planning to defer the SSP or a listed physical access requirement, which 170.21 does not allow, and discovering it at assessment.
- Two sources of truth: the POA&M workbook says closed while the ticketing system and the scanner say open, so the assessor trusts neither.
Practitioner checklist
- Set and document the CA-5 update frequency and severity deadlines before the first assessment.
- Adopt a template with at least the FedRAMP mandatory fields: ID, controls, weakness, detector source, asset, owner, plan, detection date, scheduled completion date, status date.
- Ensure every risk in the latest assessment report has a matching POA&M item.
- Record deviation type, rationale, approver and evidence for every risk adjustment, false positive and operational requirement.
- Log monthly vendor check-ins for every vendor dependency and apply compensating controls to High items.
- For CMMC, confirm the 0.8 score ratio and that no excluded or over-weighted requirement is on the POA&M; plan closeout well inside 180 days.
- Close items only with re-test evidence, and keep closed items for the next assessment.
- Report overdue Highs, median time to close and milestone slip rate to the authorising official monthly.
- Name accounts, keys and certificates explicitly in identity-related items, with an interim control recorded.
Standards and references
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls (CA-5, PM-4)
- NIST: SP 800-171 Rev. 3 Protecting Controlled Unclassified Information (03.12.02)
- eCFR: 32 CFR 170.21 Plan of Action and Milestones requirements
- FedRAMP: Legacy Rev. 5 playbook, POA&M guidance and POA&M Template
- FedRAMP: Consolidated Rules for 2026
- NIST: Cybersecurity Framework 2.0
- CISA: Known Exploited Vulnerabilities Catalog
Related NHI Mgmt Group resources: NIST Risk Management Framework (SP 800-37) Guide · FedRAMP Guide · Remediation SLAs and Vulnerability Exceptions Guide · Risk Register Template