RMFInsider

Once you know how to write a good finding, the next question every ISSO hits is how to enter a POA&M in eMASS so it actually tracks, ages correctly, and survives an assessor’s review. eMASS is where the DoD’s POA&Ms officially live — not the spreadsheet on your desktop — and the tool has its own required fields, milestone structure, and status logic. This is the field-by-field walkthrough: what each field wants, how to set milestones and completion dates, and how to keep entries from silently going overdue.

If you haven’t nailed the underlying writing yet — what a defensible weakness description and milestone chain look like — read how to write a POA&M first. This post is about getting that content into eMASS correctly.

What a POA&M Is in eMASS (vs. a Spreadsheet POA&M)

A spreadsheet POA&M is a working draft; the eMASS POA&M is the record of authority. When you enter a POA&M item in eMASS, it links directly to the failed control and its assessment result, it drives the system’s risk posture that the AO sees, and its scheduled completion date is what the aging clock runs against. That linkage is the whole point — an eMASS POA&M item isn’t a standalone note, it’s tied to the control that generated it, so closure evidence traces cleanly back to the finding. Many teams still draft in a tracker first and transcribe into eMASS once the entry is solid, which is smart because eMASS entries are visible to reviewers the moment they exist.

Creating a POA&M Item — Every Required Field

From the system’s POA&M module, you create a new item and populate the standard fields. Here’s what each one actually wants:

eMASS field	What to put there
Control / AP	Link the item to the specific security control and assessment procedure that failed — this is what makes closure traceable
Weakness description	Your translated, system-specific description — assets, control, what’s deficient — not raw scanner text
Source of weakness	Assessment finding, ACAS scan (date + plugin), or STIG rule ID that identified it
Severity / raw & adjusted risk	Pulled from the actual finding; adjusted risk reflects your mitigations
Resources required	Honest labor, funding, or tooling needed — “existing resources” only if true
Scheduled completion date	Driven by the milestone chain, not chosen to look good
Milestones	Discrete, dated, verifiable steps (detailed below)
Comments / mitigations	What’s reducing the risk right now — what the AO is actually accepting

Setting Milestones and Scheduled Completion Dates

In eMASS, milestones are structured records with their own descriptions and dates — not one free-text blob. Add three to five milestones per item, each a verifiable event (“Patch validated by rescan on all 14 hosts”), each with its own date. The scheduled completion date for the whole item should equal the date of the final milestone; if it doesn’t, a reviewer will notice the arithmetic doesn’t add up.

The completion date field is the one eMASS watches. Every item carries a scheduled completion date, and eMASS compares it to today’s date to decide whether the item is on track or overdue. That single field drives most of your POA&M pain, which is why the next section matters more than any other.

Linking Findings to Controls and Test Results

The strength of eMASS is the linkage, so use it. When you enter the item, associate it with the control’s assessment procedure that was marked non-compliant. When you later remediate, you update the test result and attach closure evidence — a rescan, a screenshot, a config export — in the same lineage. An item that isn’t linked to its control, or whose closure evidence doesn’t tie back to the original finding, is exactly the kind of loose end that turns a routine review into a painful one. I’ve seen unlinked, orphaned items linger for years because nobody could reconstruct what they were even for.

Managing Overdue POA&Ms and AO Risk Acceptance

An overdue POA&M in eMASS is one of the fastest credibility killers there is — it signals an unmanaged package. The move is to manage the date before it goes red: when a milestone is going to slip, update the milestone and the scheduled completion date with a documented reason first, not after the assessor flags it. A slipped-but-explained item is normal risk management; a silently overdue one reads as neglect.

For items that genuinely can’t be closed — a fix that depends on a future funding cycle, or a legacy dependency — the path is formal AO risk acceptance, documented in eMASS, not an indefinitely extended completion date. Keeping all of this current is exactly the discipline the continuous monitoring checklist builds into your weekly rhythm so nothing ages out unnoticed.

Draft your POA&Ms before they hit eMASS

Entering clean items is far easier when you’ve drafted them somewhere forgiving first. The POA&M Tracker ($37) mirrors the eMASS fields — weakness, source, milestones, scheduled completion, aging flags — so you transcribe finished entries instead of composing them live in the system of record.

Keeping Your POA&M Audit-Ready

• Link every item to its control and finding. Orphaned items are the ones that never close.
• Match the completion date to the last milestone. Mismatches read as sloppy tracking.
• Update dates before they go overdue, with a documented reason — never let eMASS flag it first.
• Attach closure evidence in the same lineage as the finding, so a reviewer can trace open → fixed → verified without asking you.
• Use formal AO risk acceptance for items that can’t close, instead of endlessly pushing the date.

Final Thoughts

Knowing how to enter a POA&M in eMASS is mostly about respecting two things: the linkage to the control that generated the finding, and the scheduled completion date that eMASS uses to judge whether you’re managing the item. Get the content right in a draft, transcribe it into eMASS with clean links and honest dates, and keep the dates ahead of the aging clock. Do that and your POA&M module becomes the part of the package that proves your program works — not the part you dread opening.