A POA&M is a commitment, not a parking space
Every organization has gaps between what its policies require and what is currently true. The question an assessor, a customer, or a regulator asks is not whether gaps exist. It is whether the organization knows about them and is doing something specific about each one.
That is what a plan of action and milestones is for. It converts a known deficiency into scheduled work with a name attached.
The difference it makes
An unremediated gap with a documented plan, an owner, and a date is a managed problem. The same gap without one is simply a gap that has been written down.
The distinction is not cosmetic. It is close to the whole of what separates an organization that is behind from an organization that is not in control of its own security program, and experienced assessors read the difference quickly. A short POA&M with realistic dates and evidence of prior items closing on time is a good sign. A long one with dates that have all been revised twice is a different signal entirely.
What an entry has to contain
A usable entry answers the questions someone else would ask.
- The deficiency, stated specifically enough that its resolution is unambiguous. Not "improve access control" but the requirement that is unmet and where.
- Why it is not already done. Cost, a dependency on another project, a vendor limitation, or a decision to sequence it behind something else. An entry with no stated reason usually means nobody has actually looked.
- The risk in the meantime, and any compensating measure in place. This is what makes the delay a considered decision rather than an omission.
- A named owner. A role, not a department. Work assigned to "IT" is assigned to nobody.
- Milestones, where the work is large enough to have intermediate steps worth tracking. Milestones are what allow the organization to notice that an item is slipping before its completion date arrives.
- A completion date, chosen because it is achievable rather than because it is comfortably distant.
- Resources, where the work needs budget or people that have to be secured before it can start. An item whose funding was never approved will not close, and recording that early is more honest than discovering it at the deadline.
A worked example, from an unusually explicit source
Most standards require milestones and leave the reader to work out what an adequate one looks like. The Department of Homeland Security's POA&M guide is public and does not, and it prints a bad set beside a good one for the same finding. What follows is from version 3.0, dated July 28, 2022; the document is revised periodically, so check the current one before relying on any detail.
The finding is that vulnerability scanning does not cover the whole environment described in the system security plan. The guide's inadequate example is a single milestone: ensure vulnerability scanning covers the entire environment, by a date. Its adequate example is five: schedule a review of the environment inventory; update the system security plan and the scanner to reflect it; run a scan to confirm the inventory is covered; implement an ongoing process to keep the inventory, the plan, and the scans aligned; and run a further scan cross-checked against the inventory to verify.
The difference is not thoroughness for its own sake. The first restates the objective, so it can only ever be reported as done or not done, and nobody learns anything until the deadline arrives. The second describes work, so progress is observable while there is still time to act on it. And the fourth step commits to preventing recurrence rather than only correcting this instance, which is the difference between fixing a finding and fixing the reason it existed.
The guide states the underlying rule plainly: a milestone description should not simply repeat the description of the weakness. It requires at least two milestones on every entry, and asks that each be specific, measurable, assignable, realistic, and time-related.
Three further provisions in that guide are worth borrowing regardless of who the customer is.
The completion date is locked once the entry is approved. Slipping it requires recording a reason and requesting a waiver, which is an act somebody has to approve rather than an edit somebody can quietly make. That single design decision is most of what separates a commitment from a parking space, and no organization needs permission to adopt it.
A waiver is not compliance. The guide is explicit that granting one does not bring the system into compliance; it acknowledges non-compliance and records an accepted plan to remediate within a bounded period, with compensating controls in place. Organizations routinely treat an approved exception as the end of the matter. It is the opposite: a waiver is a promise with a deadline attached.
Closure requires evidence, and the person validating it should not be the person requesting it. The stated reason is separation of duties. The practical reason is that whoever wants an item closed is the worst available judge of whether it should be.
None of this binds a defense contractor, and the tooling and role names are particular to that department. It is quoted because the expectations are written down, which is unusual, and because an organization that met them would have a POA&M process nobody could reasonably criticize.
In the defense context specifically
For organizations pursuing CMMC, the POA&M has a formal role and formal limits, set out in the assessment guides and scoping guides on the DoD CIO's CMMC documentation page and in the rule itself, at 32 CFR 170.21.
A Conditional CMMC Status exists precisely to accommodate an organization that meets most requirements and has a plan for the remainder. At Level 2 it requires an assessment score of at least 0.8 of the total requirements, which is 88 of 110, and the open items must be closed within 180 days of the Conditional CMMC Status Date, verified by a POA&M closeout assessment. Miss that date and the conditional status expires.
The eligibility limits are tighter than most organizations expect. No requirement worth more than one point may go on a POA&M at all, with a single exception: SC.L2-3.13.11, CUI encryption, may be deferred where encryption is employed but is not FIPS-validated, which costs three points rather than five.
Six one-point requirements are excluded outright:
- AC.L2-3.1.20, External Connections
- AC.L2-3.1.22, Control Public Information
- CA.L2-3.12.4, System Security Plan
- PE.L2-3.10.3, Escort Visitors
- PE.L2-3.10.4, Physical Access Logs
- PE.L2-3.10.5, Manage Physical Access
The pattern in that list repays reading. Five of the six are points where a gap means CUI is actually exposed rather than merely undocumented. The sixth is the system security plan, which cannot be deferred because it is the document the assessment is conducted against. There is no assessing an organization that intends to describe itself later.
At Level 1 there is no POA&M at all. Every requirement must be met.
The practical consequence is that a POA&M cannot be a strategy. An organization planning to certify with a substantial POA&M and sort it out afterward has usually misjudged both what is eligible and how much time closing the items takes. The stronger position is full certification without open items, and that is a preparation question rather than an assessment-day one.
How they fail
POA&Ms fail in a small number of recognizable ways.
The perpetual item. Its completion date has moved four times. Nobody has ever decided not to do it, and nobody has ever done it. This is a decision the organization is making without recording that it is making one, and the honest resolution is either to schedule it properly or to move it to an accepted risk with an approver's name on it.
The item with no owner. Assigned to a function rather than a person, noticed by no one, closed by no one.
The date chosen for comfort. Set far enough out that nothing has to happen this quarter, which guarantees nothing happens next quarter either.
The POA&M nobody reads between assessments. Reviewed once a year, the week before someone external asks for it. A POA&M is an operational document or it is a work of fiction produced annually.
Where entries come from
Anything that identifies a gap should be able to deposit work here: the risk assessment, the annual policy review, incident and exercise reports, audit findings, self-assessments, and vulnerability management.
That is the test of whether the surrounding processes are connected to anything. A policy review that identifies operational work and does not produce POA&M entries has ended at the document. An incident report with recommendations that never became tracked items has been filed rather than acted upon.
Kenneth Ingham Consulting helps organizations plan remediation that reflects business priorities and real budgets, which is the difference between a plan that closes and a list that grows.