RMFInsider

A POA&M milestone that does not slip is one that describes a single piece of work, has an owner who agreed to the date, has the resources named in the resources field rather than assumed, and has a date derived from when the work can actually start, not from when the finding was written. When a milestone does slip anyway, the correct response in eMASS is to add a new milestone with the revised date and a comment explaining why, leaving the original milestone in place so the history is visible; editing the original date to make the slip disappear is the single fastest way to lose an AO’s trust in your entire POA&M. That is the whole method. The rest of this post is the detail that makes it work under a real assessment schedule with real system administrators who have other jobs.

If you have not entered a POA&M item in eMASS before, start with how to enter a POA&M in eMASS for the field-by-field walkthrough and how to write a POA&M for the weakness and mitigation language. This post assumes you know the screens and focuses on the milestones themselves.

Why milestones slip

I have managed POA&Ms with several hundred open items across multiple systems, and the slips fall into four causes with remarkable consistency:

• The milestone is the whole fix. “Remediate finding V-12345” with a date 90 days out is not a milestone; it is the scheduled completion date wearing a disguise. There is nothing to report progress against, so nothing gets reported until the date passes.
• The date was picked by the ISSO alone. The person doing the work was not asked, or was asked in a hallway and said “sure, probably.” Sixty days later the change window they needed turns out to be quarterly.
• The resources field says “N/A” or “existing staff.” The fix needs a license, a hardware purchase, a contract modification, or a vendor patch that does not exist yet, and none of that was written down, so nobody started procuring it.
• The dependency was invisible. The fix requires the enterprise service owner, the network team, or another system’s change, and that organization was never told they were on your POA&M.

Every one of those is a writing problem before it is a scheduling problem. Fix the writing and the schedule gets a lot more honest.

Milestone granularity: one milestone, one verifiable action

The test for a good milestone is whether someone other than the owner can look at the system and tell if it was done. “Implement fix” fails that test. “Change request CR-2026-0417 approved by the CCB” passes. “Patch deployed to the two production database servers and confirmed in ACAS scan dated after deployment” passes. For a typical technical finding I use three to five milestones:

• Root cause confirmed and remediation approach documented (owner: sysadmin, usually within two weeks of the finding).
• Resources obtained or change request approved (owner: whoever controls the resource; this is the milestone that exposes hidden dependencies).
• Fix implemented in test or on a pilot host and validated (owner: sysadmin).
• Fix deployed to all affected assets (owner: sysadmin, tied to a change window).
• Validation evidence captured: rescan, updated STIG checklist, or screenshot, uploaded to eMASS and associated with the item (owner: ISSO).

For a documentation or process finding (a plan out of date, a review not performed) two milestones are usually enough: draft complete and reviewed, and final approved and uploaded. Do not manufacture granularity for its own sake. The goal is that each monthly POA&M review has something to move, and that when the AO staff asks “where are you on this,” the answer is a milestone number, not a story.

Dating milestones so the dates mean something

Work backward from the constraint, not forward from today. Ask the owner three questions: when can you start, what has to happen first, and what is the next change window after the work is done. The milestone date is the answer to the third question plus the time to capture evidence. If the answer to “what has to happen first” involves procurement, add the procurement lead time your organization actually experiences, which in my experience is never the number on the acquisition slide.

Then check the result against your component’s remediation timelines. DoD components publish expected remediation windows by severity, and while the exact numbers vary by component and by AO, the pattern is consistent: CAT I findings are expected closed within weeks, CAT II within a few months, CAT III within a longer window, and anything past those becomes a conversation with the AO about risk acceptance. If the realistic date for a CAT I is outside your component’s window, the milestone plan needs an interim mitigation milestone up front, dated early, so the AO can see the exposure being reduced while the permanent fix is in progress. A CAT I with nothing scheduled for the first 60 days looks like negligence even when the permanent fix genuinely takes 120.

One more rule: never date a milestone on the last day of a month or quarter because it looks tidy. Date it on the actual change window. Tidy dates are how a POA&M gets forty items all due on September 30, and on October 1 the delinquency report looks like a crime scene.

The resources field is a forecast, not a formality

eMASS asks for the resources required to remediate, and the temptation is to type “existing personnel” and move on. Resist it. The resources field is where you tell the system owner and the AO what this finding will cost, and it is the evidence you will need later when the milestone slips because the resource was never funded. Write it as specifics: labor hours by role, licenses or hardware with an approximate cost and the funding source if known, contract actions, and dependencies on other organizations. If the honest answer is “unknown until the vendor quotes,” say that and put the quote as milestone one. A POA&M with resources documented is a budget input; a POA&M without them is a list of complaints.

When a milestone slips: how to document it in eMASS

It will happen. The response has three parts, and the order matters.

• Do not edit the original milestone’s date. eMASS tracks milestone changes, and AO staff run reports on them. A milestone whose date has been pushed four times with no comments is a red flag; a milestone with a visible history and a reason for each change is a managed risk. Add a new milestone with the revised date, or use the milestone change comment to explain, depending on how your organization has configured the workflow.
• Write the reason in the comments field, dated and specific. “Vendor patch for CVE-XXXX-XXXX delayed to Q1; interim mitigation (host firewall rule restricting port 8443 to management subnet) implemented 15 Sep 2026; revised deployment milestone 20 Nov 2026 aligned to the November change window.” That comment answers every question the AO staff would otherwise email you.
• Reassess the residual risk and the interim mitigation. If the slip extends exposure on a CAT I or a high-severity CVE, the ISSM needs to know before the delinquency report tells them, and the AO may need to formally re-accept the risk for the extended period.

If the scheduled completion date for the whole item is going to move, that is a bigger event than a milestone slip and it should come with the ISSM’s concurrence and, depending on your AO, a formal risk acceptance memo. The POA&M management post covers the review cadence that catches these before they become delinquent; the short version is that a monthly review where every open item gets its milestones looked at will surface a slip 30 days earlier than the delinquency report does.

What the AO will tolerate, and what they will not

Every AO is different and the AO staff will tell you their thresholds if you ask, which surprisingly few ISSOs do. The pattern I have seen across several AOs:

• Tolerated: a slip with a documented cause outside the program’s control (vendor, enterprise dependency, funding), an interim mitigation in place, a revised date tied to a specific event, and the ISSM informed before the original date passed.
• Tolerated once: a slip caused by underestimating the work, with an honest revised plan and better granularity the second time.
• Not tolerated: silent slips discovered on the delinquency report, dates edited without history, the same item slipping quarter after quarter with the same comment copied forward, and CAT I items with no interim mitigation.
• Career-limiting: a milestone marked complete with no evidence uploaded, discovered during the next assessment.

The AO is accepting risk on behalf of the mission, and what they are actually judging when they read your POA&M is whether the numbers in it can be trusted. A POA&M where a third of the items have slipped but every slip is explained and mitigated is more credible than a POA&M where nothing has ever slipped, because the second one is either fiction or the findings were never real.

Reporting on milestones without rebuilding the spreadsheet

The POA&M export from eMASS gives you the items, milestones, dates, and status in one file. Pull it monthly, filter for milestones due in the next 30 and 60 days, and send that list to the owners before the review meeting rather than during it. Pull the items past their scheduled completion date separately and make sure every one has a current comment. The reports and where to find them are covered in eMASS reports explained. The point is to make the delinquency report boring, because everything on it was already known, explained, and being worked.

A quick before-you-save checklist for each milestone

• Describes one action someone else could verify.
• Has a named owner (by role, with the person recorded in comments) who agreed to the date.
• Date is tied to a real constraint: a change window, a procurement lead time, a dependency completion.
• Resources field names what the milestone consumes.
• For CAT I and high-severity items, an interim mitigation milestone exists and is dated early.
• Evidence expected at completion is stated so there is no debate later about what “done” means.

Milestones are the part of the POA&M that turns a list of findings into a plan the AO can actually watch. If you want a tracker built around this method, with milestone history, resource fields, slip comments, and a 30/60/90 day view that you can hand to the ISSM without reformatting, the POA&M Tracker is the one I use alongside eMASS.