It is a decision document, not a homework assignment
Someone is going to read your plan and then sign something, or decline to. That is the entire purpose of the artifact, and it is stated flatly in the federal guidance that most state and local security programs are built on. NIST Special Publication 800-37 Revision 2, published in December 2018, puts the plan of action and milestones inside the authorization package next to the system security plan and the assessment report, and describes what happens to it there: the plan "is reviewed by the authorizing official to ensure there is agreement with the remediation actions planned to correct the identified deficiencies." Agreement is the test. A plan embarrasses you when it makes agreement hard, because the reader cannot tell what is actually broken, how much it matters, who is fixing it, or what is protecting the data between now and then.
Teams in state and local government meet this document from several directions at once, and the directions do not agree on its name. A state revenue or health agency handling federal tax information owes the IRS Office of Safeguards both a plan of action and milestones and a separate Corrective Action Plan on the IRS template. An agency spending federal grant money owes a corrective action plan under the single audit rules in 2 CFR part 200. A cloud vendor selling into that agency may be tracking vulnerabilities under a program that no longer uses the term at all. The underlying discipline is the same in every case. The formats and the deadlines are not.
Everything below is drawn from the published rules and standards themselves, with the citation attached. None of it requires a subscription to read.
Four questions, in the order the reader asks them
What is actually wrong. Not which control identifier was marked deficient. The reader already has the assessment report. The row exists to say what the assessor found in your system that differs from what the control expects.
How much it matters, in the reader's terms. Criticality is not a scanner severity copied across. IRS Publication 1075 states the expectation directly in its PM-4 guidance: plans "must include a risk-based criticality of each finding, actions to mitigate vulnerabilities and actions to correct deficiencies found in assessments."
Who owns it. A person or an office, named. Publication 1075 makes this an explicit requirement rather than a courtesy: agencies "must ensure that the individual and/or office responsible for correcting each weakness is identified in the appropriate POA&M."
When, and what is true in the meantime. A date the reader can hold you to, plus the honest answer to the question the date provokes, which is what protects the data before that date arrives.
The rows that should not be there
The fastest way to lose an experienced reader is volume. A plan with ninety rows, most of them trivial, tells the reader that nobody triaged anything and that the important items are buried somewhere in the middle. The guidance is explicit that triage happens first and that not every deficiency earns a row.
SP 800-37 Rev. 2 says it in one sentence: "Plan of action and milestones entries are not necessary when deficiencies are accepted by the authorizing official as residual risk." Publication 1075 says the same thing from the other side, in its guidance on risk response: "the response may be to accept risk or reject risk, or it may be possible to mitigate the risk immediately, so a plan of action and milestones entry is not needed. However, if the risk response is to mitigate the risk and the mitigation cannot be completed immediately, a plan of action and milestones entry is generated."
Read those two together and the shape of a good plan appears. Decide the risk response first. Fix what can be fixed now and close it out in the assessment record. Take formal acceptance for what will not be fixed. What remains, the mitigations that take real time, is the plan. A document padded with same-day configuration changes and with risks the authorizing official already accepted is not thorough. It reads as a team that skipped the decisions and handed the reader an inbox.
The opposite failure is worse and easier to commit by accident. A finding that quietly disappears because nobody wanted a row for it is a finding the reader will locate anyway, because the assessment report still contains it. SP 800-37 is clear that deficiencies stay in the assessment reports even when no plan entry follows them, and that those reports are retained as an audit trail. The assessment report is the record of what was found. The plan is the record of what you are doing about it. They are checked against each other.
"Other than satisfied" is not one condition
Assessors working from NIST SP 800-53A Revision 5 record exactly two findings against each determination statement: satisfied, or other than satisfied. That second label covers two very different situations, and confusing them produces remediation plans that fix the wrong thing.
The first situation is a real deficiency. SP 800-53A describes it as "potential anomalies in the operation or implementation of the control that may need to be addressed by the organization." The second is an evidence problem: a finding of other than satisfied "may also indicate that the assessor was unable to obtain sufficient information to make the determination called for in the determination statement." Nothing is broken. The assessor could not see it.
Those two need different rows. The first needs engineering work, a budget and a date. The second needs an artifact produced, a report exported, a procedure written down, a screenshot captured with a timestamp. Teams routinely respond to the second by rebuilding a control that was already working, which burns a quarter and leaves the evidence gap exactly where it was.
SP 800-53A also gives you the sentence structure for a good finding statement, because it is the structure the assessor was told to use. For each finding of other than satisfied, assessors "indicate which parts of the control are affected by the finding" and "describe how the actual state of the control differs from the planned or expected/desired state." Write your row the same way. Actual state, expected state, gap. A row that restates the control text back at the reader is the single most common tell that the writer did not understand the finding.
The same discipline, six different readers
A team that has written one of these documents often assumes the next one works the same way. The contents rhyme. The constraints do not, and the constraints are where plans get rejected.
| Regime | What the document is and what it must carry | The constraint that catches teams out |
|---|---|---|
| Agency authorization under the RMF | Plan of action and milestones inside the authorization package. Tasks with a recommendation for completion before or after authorization, resources required, milestones, and scheduled completion dates (SP 800-37 Rev. 2, Task A-6). | The authorizing official reviews it for agreement. A plan can be accurate and still fail because the official does not accept the schedule. |
| Federal tax information (IRS Pub. 1075) | An agency plan of action and milestones covering self-assessments, internal inspections and external audits, plus a Corrective Action Plan responding to the IRS Safeguards review findings. | The plan is updated quarterly at minimum, new weaknesses are entered within two months, and the Corrective Action Plan is submitted semi-annually on the version Safeguards sent, with the format unaltered. |
| Single audit (2 CFR part 200) | A corrective action plan that is "a document separate from the auditor's findings," naming the contact person responsible, the corrective action, and the anticipated completion date (2 CFR 200.511(c)). | Repeat findings are exposed by design. The summary schedule of prior audit findings must "describe the reasons for the finding's recurrence" (200.511(b)). |
| CMMC Level 2 | A plan covering only select requirements scored NOT MET, closed out by a POA&M closeout assessment (32 CFR 170.21). | Some requirements cannot go on the plan at all, the assessment score divided by the total number of requirements must be at least 0.8, and closeout must be confirmed within 180 days of the conditional status date. |
| FedRAMP, 2026 rules | Providers file vulnerability reports, not a plan of action and milestones. Reports go out at least monthly in a consistent human-readable format. | The word moved. Under rule VER-AGM-MAP it is the agency that maintains plans of action and milestones, using the provider's reported vulnerability information. |
| GovRAMP | Continuous monitoring against a tiered control set: 40 controls at Security Snapshot, 60 at Core, 80 at Ready, 300-plus at Authorized. | Cadence scales with the tier. Core is monitored quarterly; Ready and Authorized are monitored monthly, with annual reassessment. |
One document rarely satisfies two of these at once, and pretending otherwise is how a team ends up submitting an IRS Corrective Action Plan in a spreadsheet layout the Office of Safeguards did not issue. Track the findings once in whatever internal system you like. Render them separately, per audience, in the format that audience requires.
Dates: the field that does the most damage
Two date fields matter and they are not interchangeable. There is the completion date you originally committed to, and there is the date you now expect. A plan that carries both, with a sentence explaining the gap, survives review. A plan where the original date was overwritten with the new one does not, because the reader can see the same row in last quarter's copy.
The guidance treats the historical record as untouchable. SP 800-37 Rev. 2 directs that "organizations ensure that information needed for oversight, management, and auditing purposes is not modified or destroyed when updating security and privacy plans, assessment reports, and plans of action and milestones." The same principle governs reassessment: when a control is remediated and re-tested, assessors "update the assessment reports with the findings from the reassessment, but do not change the original assessment results." The original finding stays. So should the original date.
Slipping a date is normal work. Nobody is surprised that a firmware upgrade waited on a maintenance window or that a control depends on a procurement that has not cleared. Slipping a date without saying so reads as concealment, and it converts a routine schedule conversation into a question about whether the rest of the document is honest. Where a date depends on something outside your control, name the dependency in the row. A milestone that reads "pending vendor release, currently expected in the vendor's next quarterly update" is more credible than a confident date with nothing behind it.
A milestone is an event somebody else can observe
SP 800-37 lists what belongs in the plan: tasks to be accomplished with a recommendation for completion before or after authorization, the resources required to accomplish them, milestones established to meet the tasks, and scheduled completion dates for both. Three of those four fields are routinely filled with restatements of the first.
"Implement multi-factor authentication" is a task. It is not a milestone, because there is no moment at which an outside reader could confirm it happened. "Multi-factor authentication enforced for the administrator group, verified by a failed login attempt from an unenrolled device and a policy export dated after the change" is a milestone. The difference is observability. A milestone that only the writing team can confirm is a status update wearing a milestone's clothes.
Resources required is the field teams most often leave blank, and leaving it blank is itself a signal. A remediation with no named budget, no assigned engineer and no vendor engagement behind it is a wish, and an authorizing official who has read a few hundred of these knows which rows will still be open next year. Writing "existing staff, approximately 40 hours, no procurement required" is a small sentence that does a lot of work.
Criticality that carries information
If every row is High, the ranking has told the reader nothing and they will build their own. SP 800-37 asks for "a prioritized approach to risk mitigation that is uniform across the organization," guided by a risk assessment, and informed by the categorization of the system, the specific deficiencies, and the effect those deficiencies have on the ability of the organization to perform its mission.
FedRAMP's rules for 2026, which launched on June 24, 2026, offer a vocabulary worth borrowing even for teams who will never touch a federal cloud authorization. Providers evaluate each vulnerability along axes that are far more useful than a raw severity score: whether it is internet-reachable, whether it is likely exploitable, and what the potential impact on the customer agency would be. One rule in that set is a good discipline for any remediation plan. Providers "must assume the exploitation of vulnerabilities can be automated unless they have evidence proving otherwise." Optimism about exploitability is the assumption most often wrong in a security document.
- Control text restated — the row repeats the requirement instead of describing the actual state of the system.
- Owner is a department — "IT Operations" cannot be called. A named individual or office can.
- Every date is fiscal year end — a calendar artifact, not a plan, and the reader recognizes it instantly.
- "Compensating control" with nothing behind it — the phrase means the control that reduces this specific risk, described well enough to assess.
- Closed with no artifact named — closure that cannot be verified without a phone call is not closure.
- Everything rated High — a ranking that ranks nothing forces the reader to redo the triage you were supposed to do.
The state and local layer: three plans, one program
A state agency running a benefits or revenue program on federal data can owe three of these documents simultaneously, on three clocks, to three audiences, describing an overlapping set of weaknesses.
Federal tax information brings Publication 1075, whose current revision is 11-2021. It requires an annual Safeguard Security Report, with an initial report submitted at least 90 days before the agency's planned receipt of tax data, plus the Corrective Action Plan cycle described above. Federal grant dollars bring the single audit, whose reporting package must reach the Federal Audit Clearinghouse within 30 calendar days after the auditee receives the auditor's report or nine months after the end of the audit period, whichever is earlier, and which includes both the corrective action plan and the summary schedule of prior audit findings. The agency's own authorization process brings a plan of action and milestones under the state's security policy, which in most states is modeled on the NIST catalog and inherits CA-5 nearly verbatim.
The repeat finding is what ties these together and what damages a program most. A weakness closed on paper in one document and still open in another is discoverable by anyone who reads both, and the single audit rules make the comparison mandatory rather than optional. If a finding recurs, write the reason plainly. The reasons are usually structural, a vacancy that was never filled, a system scheduled for replacement, a budget request that did not survive the session, and structural reasons are far more persuasive than a second promise on the same row.
The two weeks after you receive the findings
What the 2026 FedRAMP rules did to the vocabulary
The FedRAMP Consolidated Rules for 2026 are worth reading even for teams with no cloud authorization ambitions, because the program that did more than any other to popularize the plan of action and milestones has stopped asking providers for one. The provider-facing rules replace it with vulnerability response, and the replacement is more precise about the thing that matters most in any remediation plan: the current status of an open item.
Instead of open or closed, a vulnerability is remediated when it is eliminated and no longer detected, fully mitigated when the risk is negligible but the vulnerability is still there, partially mitigated when the risk is reduced but exploitation is still possible, overdue when the provider intends to fix it but will not do so inside the expected timeframe, or a false positive when it was never present in an exploitable state. There is one more category, and it is the interesting one. Anything not fully mitigated or remediated within 192 days of evaluation must be categorized as an accepted vulnerability, and every accepted vulnerability must be reported with an "explanation of why this is an accepted vulnerability."
That is a forcing function worth stealing. An item that has been open for six months is no longer a plan, it is a decision, and requiring somebody to write the sentence explaining the decision is how a plan stops accumulating fiction. The same rules also move the plan of action and milestones itself to the customer side: agencies use the provider's reported vulnerability information to maintain their own plans. If you are the vendor in a state deal, expect the agency to build its record from what you report, and write your reports knowing they will be pasted into a document you never see.
Closing a row so it stays closed
Closure is where credibility is either earned or lost for the next cycle. Under the risk management framework, remediated controls are reassessed, and the assessor determines whether the fix was implemented correctly, is operating as intended, and produces the desired outcome. The closure entry should let that reassessment happen without a conversation.
Name the artifact and its date. "Closed" is not evidence. "Closed 2026-07-14; policy export and screenshot of the enforced setting attached as CAPATT4; verified by an independent scan on 2026-07-16" is evidence, and it also survives the personnel change that will eventually separate the person who fixed the thing from the person who has to defend it. IRS Publication 1075 goes as far as prescribing a file-naming convention for corrective action plan attachments, either in a logical order or by finding number, which tells you how much of the reviewer's frustration comes from attachments nobody can match to a row.
The row-level checklist
- The weakness is described as actual state versus expected state, not as a repetition of the control language.
- The row exists because the risk response was mitigation, not because a finding needed somewhere to go.
- A named individual or office owns it, and that person knows they own it.
- Criticality is risk-based and differentiates between rows rather than defaulting to the top of the scale.
- Milestones are observable events with dates, not paraphrases of the remediation.
- Resources are stated, including the case where no new money is required.
- The original completion date is preserved alongside any revised date, with the reason for the change.
- Interim protection is described for anything that will stay open past the next reporting cycle.
- Closure names the artifact and the verification, filed so a reviewer can match it to the finding number.
Bottom line
The plan of action and milestones is the one document in a security package written entirely in the first person about your own shortcomings, which is exactly why it is read closely. Its authority comes from evident judgement: rows that exist for a reason, criticality that discriminates, owners with names, milestones an outsider could check, and a schedule history that was never rewritten. The statutory backdrop is old and stable. FISMA has required agencies to maintain "a process for planning, implementing, evaluating, and documenting remedial action" since it was enacted, and the control that operationalizes it, CA-5, has survived every revision of the NIST catalog largely unchanged. What changes is the format and the audience. Write the findings once, honestly, and render them into whichever shape the reader in front of you requires.
Frequently asked questions
No. NIST SP 800-37 Rev. 2 states that entries "are not necessary when deficiencies are accepted by the authorizing official as residual risk," and IRS Publication 1075 makes the same point for deficiencies that can be mitigated immediately. Decide the risk response first. The plan carries the mitigations that take time. Every finding still stays in the assessment report regardless of whether it earns a row.
It depends on the regime. The NIST control CA-5 leaves the frequency to the organization. IRS Publication 1075 fixes it for agencies handling federal tax information at quarterly as a minimum, with new weaknesses entered within two months of an assessment, and a separate Corrective Action Plan submitted semi-annually. Check the governing document before assuming an annual cycle is acceptable.
Yes, and dates slip routinely. What damages credibility is overwriting the original date rather than showing both. SP 800-37 Rev. 2 directs that information needed for oversight and auditing is not modified or destroyed when plans are updated, and the same principle applies to assessment results, which are never rewritten after a reassessment. Keep the original commitment visible and explain the change.
In some programs, yes. Under the CMMC program rule at 32 CFR 170.21, only select requirements scored NOT MET are eligible, several named requirements are excluded outright, the assessment score divided by the total number of requirements must be at least 0.8, and closeout must be confirmed within 180 days of the conditional status date. Other regimes are less prescriptive, but a program that names ineligible requirements will not negotiate on them.
Send what the agency needs to write its rows without calling you. FedRAMP's 2026 rules are a useful model here: providers report detection time, evaluation time, whether the issue is internet-reachable, whether it is likely exploitable, the estimated impact on the customer, and whether it is or is likely to become overdue. Agencies then use that reporting to maintain their own plans of action and milestones.