POA&M Automation for DoD Programs: What It Is, Why It Matters, and How to Do It Right

If you've worked in a DoD program office or on a government IT system going through the Risk Management Framework (RMF), you've spent time on POA&Ms. Probably more time than you wanted to.

A Plan of Action and Milestones is supposed to be a simple document: here are the vulnerabilities we know about, here's what we're doing about them, here's when we'll be done. In practice, it becomes a sprawling spreadsheet that three different people maintain, that never quite matches the STIG scan results, and that the ISSO has to manually reconcile every time an assessor asks for it.

This article is a practical look at what POA&M automation actually means, what it can and can't do for your program, and what to look for if you're evaluating tools.

The short version of the argument: a POA&M is not a document you maintain. It's an output. If it's generated from the same record that produces your SSP and your SAR, it cannot drift away from them. If it's maintained separately, in a spreadsheet or in a tool that only knows about findings, drift is the default and reconciliation becomes somebody's permanent job.

What a POA&M actually is (and isn't)

Under the RMF process defined in NIST SP 800-37, a POA&M is a document that identifies tasks needing to be accomplished to remediate known vulnerabilities or weaknesses in an information system. It's a required artifact for Authorization to Operate (ATO) packages and is reviewed by the Authorizing Official (AO) as part of ongoing continuous monitoring.

Every open finding from a STIG checklist, every unresolved vulnerability from a scan, every security control that can't be fully implemented, these all become POA&M items. For any system of meaningful size, that can be dozens to hundreds of open items at any given time.

The problem isn't the concept. The problem is the operational reality of keeping that document accurate, current, and traceable across the entire lifecycle of a system, especially when the findings come from multiple scan tools, multiple STIG checklists, and multiple assessment events.

What manual POA&M management costs you

The standard approach most programs use is a spreadsheet, usually derived from the DISA POA&M template. Someone on the team is responsible for updating it, usually the ISSO or a system administrator who has other primary duties.

Here's what that typically looks like in practice:

• Scan results come in as separate reports, SCAP content results, manual STIG checklist CKL files, vulnerability scanner output, and someone has to manually cross-reference each finding against the existing POA&M to determine what's new, what's been remediated, and what's changed.
• Finding IDs don't stay stable. DISA updates STIGs regularly. A CAT I finding from six months ago may have a different Vulnerability ID in the current version, which breaks any manual tracking you had tied to that ID.
• Inherited controls create confusion. Many findings apply to the platform or infrastructure layer, not the application itself. Knowing which items are your responsibility vs. inherited from a cloud service provider or enclave owner requires judgment that a spreadsheet can't capture.
• Status goes stale fast. A finding marked "in remediation" six months ago may still be open. Without active tracking, the POA&M becomes a historical document rather than an accurate current-state view.
• ATO package prep is painful. When an assessment is coming, pulling together a current, accurate POA&M from scattered sources under time pressure is where hours disappear.

For a program with a large or complex system, maintaining a manual POA&M honestly takes significant recurring staff time, time that skilled security personnel should be spending on actual security work, not spreadsheet maintenance.

What POA&M automation actually looks like

Automation doesn't mean the POA&M manages itself. It means the system handles the data ingestion, correlation, and tracking work that humans shouldn't be doing manually.

A well-designed POA&M automation tool does several things:

Ingests findings from your scan sources

Rather than exporting a SCAP results file and manually reviewing it, the tool ingests the output directly, XCCDF results, CKL files, STIG Viewer exports, and maps those findings to existing POA&M items automatically. New findings get created. Remediated findings get flagged for review. The delta between two scan runs becomes visible without a manual diff.

Tracks findings across STIG version changes

When DISA releases an updated STIG, Vulnerability IDs and rule content can change. Good automation handles that mapping so a finding doesn't get orphaned or duplicated because the ID changed in the new version.

Maintains milestone and ownership tracking

Each POA&M item needs a responsible owner, a scheduled completion date, and a current status. The tool keeps those fields current, surfaces items that are approaching or past their milestone dates, and gives the ISSO a single view of the program's remediation posture without manual assembly.

Keeps the provenance of every item

An assessor asking "where did this come from?" should get an answer from the system, not from somebody's memory. A POA&M item should trace back to the finding that created it, the assessment that produced that finding, and the piece of evidence sitting behind it. That chain is what makes the POA&M defensible rather than merely present, and it's the difference between a tool that tracks items and a tool that holds a record.

Proposes, but doesn't decide

Ingest, correlation, deduplication and first-draft text are mechanical, and a machine should do them. Accepting a finding, setting a risk rating, agreeing that an item is closed, these are professional judgements a named person is accountable for. Automation worth having produces proposals that a practitioner accepts, and records both facts: that a machine proposed it, and that a person accepted it, and when. A tool where a parser or a model writes authoritative data into the record has quietly moved accountability somewhere nobody can point at.

Generates compliant output

The output the AO actually needs, a POA&M document in the required format, should be a one-click export, not a multi-hour formatting exercise. The data is already in the system; the tool just needs to render it correctly. The same applies to machine-readable output: OSCAL for the systems downstream of you, and a POA&M export your system of record will accept.

The STIG scanning connection

POA&M automation and STIG compliance tracking are two sides of the same problem. Every open STIG finding is a potential POA&M item. Every closed finding needs to be traceable back to a STIG check with evidence.

Programs that try to manage these separately, STIG checklists in one place, POA&M in another, create a reconciliation burden that compounds over time. The most efficient approach is a unified system where STIG status directly drives POA&M state: an open CAT I automatically surfaces as a high-priority POA&M item, and when the STIG check is marked compliant with evidence, the POA&M item closes with traceability intact.

Two failure modes on the STIG side feed straight into POA&M quality. The first is applicability: if nobody re-derives which STIGs apply when a technology enters the inventory, a checklist that should have been assessed simply never was, and the POA&M is silently incomplete rather than visibly wrong. The second is the update: when DISA releases a new version, an update that replaces your checklist instead of merging into it takes your status, comments and findings with it, and the POA&M items tied to them are orphaned.

This integration also matters for continuous monitoring. Under RMF, ATOs aren't one-time events, they require ongoing monitoring and periodic reassessment. A system that keeps STIG status and POA&M state synchronized gives the ISSO a real-time view of authorization posture rather than a point-in-time snapshot that goes stale between assessments.

Why the POA&M has to come from the same record as the SSP

This is the part that most POA&M tooling gets structurally wrong, and it's worth being precise about it.

Under NIST SP 800-37 Rev 2, the authorization package is three artifacts: the System Security Plan, the Security Assessment Report, and the POA&M. They are not three separate documents that happen to be submitted together. They are three views of the same system at the same moment. The SSP says how a control is implemented. The SAR says what the assessor found when they tested it. The POA&M says what you're doing about what they found.

If those three are maintained in three places, they will disagree. Not might, will. A control implementation gets updated in the SSP and the corresponding POA&M item doesn't move. An item is closed in the POA&M and the SAR still describes the weakness as open. Nobody notices, because noticing requires somebody to read three documents side by side, and the person who does that is usually the assessor.

Two practical consequences follow. The first is OSCAL: once the POA&M is generated rather than typed, emitting it as machine-readable OSCAL alongside the DOCX a human reviewer reads costs nothing extra, and the systems downstream of you consume the same facts your reviewers do. The second is your system of record. eMASS and Xacta are repositories that receive authorization data. A tool you actually work in should sit upstream of them and export to them, not try to replace them, and it should be able to round-trip so the work you do doesn't have to be re-keyed.

What to look for

If you're evaluating tools for your program, here are the questions that actually matter:

• Does the POA&M come out of the same record as the SSP and SAR? This is the first question, not the last one. A tool that manages POA&M items in isolation has solved the tracking problem and left you the consistency problem, which is the expensive one.
• Can you trace an item back to its evidence? Finding, assessment, evidence artifact. If the chain breaks anywhere, you're defending the item from memory.
• Does it ingest native scan formats? XCCDF results, CKL files, and common vulnerability scanner outputs should be importable without manual transformation.
• Does it handle STIG versioning? DISA updates STIGs frequently. The tool should manage version transitions without breaking your historical finding data.
• Can it operate in your environment? If you're working in a classified or air-gapped environment, a cloud-only SaaS tool won't work. You need something that can be deployed on-premise or in a government cloud environment.
• Does it produce compliant output? The POA&M format expected by your AO matters. The tool should output in a format your assessors will accept without reformatting.
• Who owns the data? For CUI-handling programs, you need clarity on where your finding data lives and who can access it.
• Does it track inherited controls? Knowing which findings are your responsibility vs. inherited from the enclave or CSP layer is essential for accurate risk representation.
• Does it export to your system of record? If eMASS is where the program's authorization data lives, the tool should export to it cleanly, ideally round-trip, rather than becoming a second place the truth is kept.
• What is the machine allowed to change? Ask it plainly. Every tool in this market now has an AI story; far fewer have an answer to which acts a model may perform and which ones stay a named person's. Anything a machine produces should be a proposal until an authorized practitioner accepts it.

How CertiField approaches this

We built CertiField because we ran into these problems on our own programs and couldn't find a tool that addressed them well for small-to-mid-size DoD software teams.

CertiField is Alethia Software's operational RMF platform for DoD system authorization. It connects system architecture, security evidence, controls, assessments, findings and POA&Ms in one authorization record and generates SSPs, SARs, POA&Ms, OSCAL and authorization packages from that record.

Applied to everything above, that means:

• Findings arrive from scan and checklist ingest already bound to the control they bear on and the evidence behind them, so a POA&M item carries its provenance instead of acquiring it later.
• The POA&M export is generated from the same record the SSP and SAR are generated from, so the three artifacts can't tell an assessor three different stories.
• STIG applicability is ranked against the technologies the system actually runs, and DISA catalog updates merge into existing checklists rather than replacing them, so a version bump doesn't orphan the items tied to it.
• Output goes out as OSCAL and as the documents reviewers read, and eMASS import and export round-trips, so CertiField sits upstream of your system of record rather than competing with it.
• Nothing a machine produces, importer, parser or model, writes authoritative data. It's a proposal carrying its own explanation until an authorized practitioner accepts it, and the record keeps both halves of that.
• After the ATO, the same record carries continuous monitoring: inventory drift, evidence that's aged out, and the reassessment scope an architecture change actually creates, rather than a rebuild of the whole package.

It's also designed to run in the environments where DoD programs actually operate, including government cloud and disconnected deployments, because a tool that can only run in a commercial cloud environment isn't useful for a significant portion of the programs that need it most. AI can point at a local model or be switched off entirely.

We use CertiField on our own systems. Alethia is CMMC Level 2 certified by a C3PAO, and CertiField is part of how we maintain that posture. We built it to solve a real problem we had, not as a theoretical product.

Bottom line

POA&M automation isn't about making compliance easier to fake, it's about making accurate, current compliance status easy to maintain. The programs that run into problems at assessment time are usually the ones where the POA&M stopped reflecting reality months before the assessors showed up.

If your program is managing STIGs and POA&Ms manually, the question isn't whether automation would save time, it's whether the current approach is sustainable as your system grows and your assessment frequency increases.

And when you do go looking at tools, ask the structural question before the feature questions. Plenty of products will track POA&M items well. Far fewer can tell you that the POA&M, the SSP and the SAR came out of the same record, which is the thing that determines whether you spend the week before an assessment reviewing your package or reconciling it.