03.12.02 Plan of action and milestones: evidence guide

What the 03.12.02 plan of action and milestones asks for

The 03.12.02 plan of action and milestones requirement asks you to keep a system-level plan that records how you will fix the weaknesses found in security assessments and the known vulnerabilities affecting the system, with each item tied to planned remediation. The plan must be updated from what assessments, audits or reviews and continuous monitoring turn up. In NIST SP 800-171 Rev. 3, this is requirement 03.12.02. NIST lists CA-5 from SP 800-53 Rev. 5 as the source control, so an assessor will read the requirement alongside the plan of action and milestones practices that CA-5 describes. The requirement is about tracking, not about having a document that looks complete on the day of an assessment.

The risk it addresses is simple to state and common in practice: a finding is known, someone has noted it, and nothing happens after that. A scanner flags a missing patch, an assessment records a weak access review, and the item sits in a spreadsheet or a ticket queue with no owner, no date and no link to the system it affects. Assessors look for the gap between what was found and what was closed. Hard parts usually come from three places: deciding who owns each remediation and who accepts a delay, setting realistic completion dates and recording why they moved, and keeping one register when findings arrive from vulnerability scanners, internal assessments, external audits and monitoring tools that describe the same weakness in different words. Before you rely on any plan, confirm with your contracting officer or assessing body which Rev. 2 or Rev. 3 version and which ODP values apply to your contract, because the plan must map to the requirements you are actually assessed against. Ask who will assign owners and approve dates, how duplicate findings will be merged, and where the register will be kept and reviewed. Those decisions shape the rest of the requirement.

Which systems, findings and teams belong on the POA&M

A POA&M is only as useful as its boundary. The decisions below set which system the plan covers, which sources feed it, which third parties add findings and which teams carry the remediation. Settle them in writing before the first entry is recorded, because each one changes how many items the plan holds and how often it must be updated.

Set the system boundary first

Decide which system the POA&M covers, matching the system security plan boundary. A plan for the whole enterprise and a plan for a CUI enclave produce very different item counts and owners. Items outside the boundary belong in a separate risk register, not in the plan the assessor reviews. Confirm the boundary with the assessing authority before you start, because changing it later can invalidate earlier entries.

Map every assessment source

Record which periodic security assessments, internal audits, external audits and reviews feed the plan. Each source should produce findings with a unique identifier so a weakness can be traced from the assessment report to its remediation milestones. Without that trace, the plan cannot show that it was updated from assessment results, which is what 03.12.02 asks you to demonstrate.

Feed vulnerability scan results

Decide whether scanner output enters the POA&M automatically or after review. Automatic import keeps known vulnerabilities current but can flood the plan with duplicates and low-value items. A triage step, with deduplication and an owner per finding, keeps the plan readable. Confirm how your scanner tags repeat findings across scan cycles before you connect it.

Include continuous monitoring signals

Decide which monitoring alerts count as findings that need a milestone. Continuous monitoring produces a steady stream of events, so define the threshold for turning a signal into a planned remediation item. Items that are closed as false positives should keep a recorded rationale so the plan shows why no action was taken.

Assign cloud and third-party findings

Identify which cloud providers, managed service operators and external assessors contribute findings. Their reports may cover shared controls, so decide who owns the remediation milestone and who verifies closure. Where a provider cannot commit to a date, record the dependency in the plan and confirm the contract terms that govern it.

Name an owner for each remediation team

Assign each item to a named remediation team, such as platform engineering, identity, or endpoint operations, and a single accountable owner who signs off closure. Assessors look for clear ownership and evidence of closure, so an item with no owner usually stays open. Review ownership at each update cycle, because team changes are a common cause of stalled milestones.

How an assessor tests 03.12.02 with examine, interview and test methods

This table maps each assessment method in SP 800-171A Rev. 3 for 03.12.02 to the objects an assessor looks at and the evidence that satisfies it. Read it as a checklist of what to have ready before an assessor arrives, and note where the test method asks for a working mechanism rather than a document.

Method and object	What the assessor checks	Evidence to have ready	Where it usually fails
Examine: policy and procedures	Whether a security assessment and monitoring policy and POA&M procedures exist, are current and name who does what	Approved policy, POA&M procedure with owners, review dates and approval records	Procedure describes a tool or role that no longer matches how work is done
Examine: security assessment plan and report	Whether the findings that feed the POA&M come from a defined assessment with scope and method	Assessment plan, dated assessment report, list of weaknesses identified	Findings from a later assessment or audit never reach the POA&M
Examine: POA&M records	Whether each weakness and known vulnerability has a planned remediation, owner and milestone	POA&M entries with weakness description, planned actions, milestones, status and closure evidence	Entries lack owners, dates or closure evidence, or closed items are deleted
Examine: security assessment evidence	Whether the POA&M ties to supporting evidence such as scan output or audit results	Scan reports, audit findings and continuous monitoring outputs linked to POA&M items	Scanner results exist but are not linked to a tracked remediation item
Interview: POA&M development and implementation staff	Whether people responsible for the POA&M can explain how items are created, prioritized and closed	Named roles, short walkthrough of the update cycle, examples of recent items	Staff describe the process differently or depend on one person
Interview: personnel with information security responsibilities	Whether security staff know how assessment results flow into remediation planning	Record of how findings reach the POA&M owner and how status is reported upward	Security staff are unaware the POA&M exists or cannot say when it was last updated
Test: POA&M mechanisms	Whether the process, tool or workflow that develops, implements and maintains the POA&M works as documented	Demonstration of creating, updating and closing an item, with an audit trail of changes	Spreadsheet or tracker is edited with no version history or access control
Common finding: stale POA&M	Whether the POA&M was updated after the most recent assessment, audit or monitoring cycle	Dated entries that correspond to the latest assessment or scan results	A POA&M exists and is accurate for an earlier assessment but was not updated after a later one

Building a POA&M that survives an assessment

This sequence turns scattered assessment findings and known vulnerabilities into one controlled plan of action and milestones that an assessor can trace from finding to closure. Each step hands over a specific artifact, so the record stays current between assessments.

Define the POA&M procedure and owners
Write a short procedure that states what qualifies for a POA&M entry, who may open, approve, and close items, and how entries are reviewed. Name a single accountable owner for the POA&M and a named owner for each affected system. The output is an approved procedure and a roles table that the assessor can read alongside your security assessment and monitoring policy. Confirm the procedure against the 03.12.02 assessment objectives in SP 800-171A Rev. 3 before sign-off.
Set one intake point for findings
Route findings from internal assessments, external audits, vulnerability scans, penetration tests and continuous monitoring into one register, so no source bypasses the plan. Deduplicate findings that multiple tools report for the same weakness before they become items. The output is a single intake queue with a timestamp and source recorded for every finding, which lets you show that the POA&M is updated from every source the organization uses.
Record each item with its required fields
For each accepted finding, record the weakness or known vulnerability, the affected system component, the owner, the planned remediation action, and a milestone with a completion target. Link the item to the requirement it affects, such as the 03.12.02 record itself and the related requirement family. The output is a complete item record with no blank required fields. An incomplete entry is the most common reason a POA&M fails review, so reject items that lack an owner or a milestone before they enter the plan.
Set review triggers tied to assessments and monitoring
Define the events that force a POA&M review: completion of a formal assessment, an audit finding, a significant change to the system, a new critical vulnerability, or a monitoring alert that indicates a weakness. Document the trigger list and the cadence for routine review in the procedure. The output is a dated review log showing each trigger, the review performed, and the changes made. Assessors look for evidence that the plan moves when the environment moves, not only at the time of the last audit.
Validate closure with evidence
Close an item only after the owner submits evidence that the remediation was completed, such as a configuration export, a rescan result, a change record, or a test report. A second person who did not perform the fix should verify the evidence and approve the closure. The output is a closure record that links each closed item to its evidence file and the approver. Mark items closed without evidence as open, because an assessor will request the proof for any item shown as complete.
Retain prior versions for traceable change
Keep every version of the POA&M with its date, author, and a summary of changes, and never overwrite a closed or revised item. Store versions in a controlled repository with access logs. The output is a version history that lets you show when a milestone moved, why it moved, and who approved the change. Ask your assessor which format they expect for the submitted plan, and confirm that your retention approach meets your contract and record-keeping obligations.

Evidence that passes 03.12.02 and how to keep it current

A POA&M is only as credible as the trail behind it. The artifacts below connect each open weakness to the assessment that found it, the remediation work that closes it, and the validation that proves closure. Each one should be refreshed after every assessment, audit or monitoring cycle, not assembled in the weeks before an assessor arrives.

The POA&M procedure

This is the written procedure that says how weaknesses enter the plan, who owns each entry, how priorities and target dates are set, and when an item may be closed. Assessors check the procedure first, and then check whether the register follows it. Review it at a fixed interval and after any change to the assessment process, so the written steps match what the team actually does. Confirm that it names the roles responsible for the plan, not only the tool that holds it.

The POA&M register with dated versions

The register lists each weakness with its source, affected system, owner, planned milestones, status and expected completion date. Keep it under version control or in a system that records every change with a timestamp and author, so earlier states can be shown. Export a dated copy at each review cycle. Check that closed items remain visible with their closure evidence rather than disappearing from the record.

Source assessment and audit reports

Each entry should trace back to the finding that created it, whether that came from a security assessment, an internal audit, a vulnerability scan or a continuous monitoring result. Keep those reports as issued, with their dates and scope, and reference the specific finding identifier in the register. Between audits, log new findings as they arrive instead of waiting for the next formal assessment, so the register never trails the most recent results.

Closure validation records

Marking an item complete is not enough. Keep records that show the remediation was tested or independently checked, such as a rescan result, a configuration export, a test ticket or a reviewer's sign-off. The record should name who validated the fix and when. Schedule validation at closure rather than batching it, because an unverified closure is the most common gap an assessor will question.

Change history after each cycle

An assessor looks for evidence that the plan changed when findings changed. Record each update with the triggering event, such as a scan cycle, a monitoring alert or an audit, plus the entries added, re-prioritized, re-dated or closed. Review the history at each cycle to confirm that updates happen on schedule, and that target dates moved only with a documented reason. Missing history between cycles is a common reason a plan looks stale.

Linked security assessment plan and report

The POA&M sits alongside the security assessment plan, which defines what is assessed and how, and the security assessment report, which records what was found. Each POA&M entry should point to a specific section of the report, and the plan should state how often assessments occur. Confirm that the plan and report are current for the same system boundary as the POA&M, because a mismatch in scope is easy for an assessor to spot.

Why a POA&M entry cannot always buy time

A POA&M entry does not buy time in every contract. For defense contractors, whether an open weakness can sit on a plan of action and milestones depends on which version of SP 800-171 the contract uses and how CMMC scores the practice. NIST's change analysis traces 03.12.02 to Rev. 2 requirement 3.12.2 and classifies the change as significant, because Rev. 3 asks for more detail and adds foundational tasks. A POA&M written against the Rev. 3 wording may therefore not match the Rev. 2 requirement the assessor scores.

CMMC Level 2 still uses Rev. 2, so the practice is assessed as CA.L2-3.12.2. Under the scoring methodology in 32 CFR 170.24 it carries 3 points, and under 32 CFR 170.21 it cannot be placed on a POA&M to reach Conditional status. A contractor with an open gap in this practice cannot close the difference by planning the fix. The organization should check which practices its scoring depends on, and whether any open item is one the rule excludes from a POA&M, before it relies on a remediation schedule in a submission.

The rules around this topic have changed recently, so treat the detail here as a starting point. Ask the contracting officer which DFARS 252.204-7012 wording and which SP 800-171 revision apply to each contract, and confirm the current CMMC status with the sponsoring agency and your assessor. Record the answers in the system security plan so the POA&M, the SPRS score and the contract language line up.

What keeping a POA&M costs in money and effort

This table breaks down what it costs to keep a plan of action and milestones for 03.12.02 current, separating one-time setup from recurring upkeep. Read each row for who is paid, whether the cost recurs, what drives it up, and what to request in a written quote. No dollar figures are given because none are supplied for this topic.

Cost component	Who is paid or who spends time	One-time or recurring	Main driver and how to reduce it
Tooling	Software vendor or internal platform team	Both: setup once, licenses or hosting recur	A spreadsheet or self-hosted tracker can hold the POA&M. Licensing varies by tool, so confirm license terms before choosing. Reduce by reusing existing ticketing systems where they can record owner, milestone and status.
Engineering time to deduplicate and route findings	Internal security engineers or implementation partner	Recurring with each assessment or scan cycle	Driven by the number of sources (scanners, assessments, audits, continuous monitoring). Reduce by agreeing one intake path and deduplication rules before data flows in.
Owner time for remediation planning	System owners, engineering leads, asset owners	Recurring	Driven by the number of open weaknesses and the number of systems in the boundary. Reduce by grouping items by owner and by fixing root causes that close several findings at once.
Evidence upkeep	Compliance lead and control owners	Recurring	Each closed milestone needs supporting evidence that an assessor can examine. Reduce by capturing evidence at closure instead of rebuilding it later.
Assessor sampling and external review	Independent assessor or auditor, paid by the organization	Recurring at each assessment	Depends on the assessment type and how many POA&M entries are sampled. Confirm in writing how the assessor will sample and what the scope of sources and systems covers.
Training	Staff who open, update or close POA&M items	One-time onboarding, then periodic refresh	Driven by staff turnover and by how many people update entries. Reduce by writing a short procedure that defines required fields and closure criteria.
Scope definition	Compliance lead and system owners	One-time, revisited when the boundary changes	Driven by the number of systems and data flows in scope. A narrower, well-documented boundary reduces the number of sources feeding the POA&M.

Open-source tools that feed the POA&M register

A POA&M is only as current as the findings that feed it. The three tools below each cover a different input: vulnerability scan results, findings from other security tools, and assessment and audit tracking. None of them replaces the organization's own decision on what goes on the register, who owns each item, and when it closes.

DefectDojo for finding consolidation

DefectDojo imports and reimports findings from more than 500 security tool report formats through its UI or API, and the open source edition includes this capability. It also offers a generic findings import for reports outside those formats. Its deduplication relies on per-tool hashcode fields, so the team should confirm that the fields chosen for each scanner give stable identities across repeat scans. Otherwise the same weakness may appear twice on the 03.12.02 register, or a closed item may reopen under a new identifier. Check that each entry keeps an owner, a remediation target and a closure record that an assessor can trace.

Greenbone for scheduled vulnerability evidence

Greenbone Community Edition, built on OpenVAS, runs scan tasks on a schedule through gvmd, which stores results in PostgreSQL and manages users and permissions. Analysts review results in the Greenbone Security Assistant web interface. For 03.12.02, the scan history is the raw record that shows when a known vulnerability was found and whether later scans still detect it. Confirm the scan frequency, scope and credential handling against the organization's own risk assessment, and keep exported reports with the POA&M entry they support. Scanner output alone does not establish a planned remediation, so each finding still needs a documented decision.

CISO Assistant for assessment tracking

CISO Assistant ships more than 200 frameworks, including NIST CSF, ISO 27001 and others, and runs audits and compliance assessments against them with automatic mapping between frameworks. Teams use it to link assessment findings to the requirement they affect, which helps show that each POA&M item traces to a specific SP 800-171 requirement and assessment result. Confirm that its mappings match the framework version your contract cites, since Rev. 2 and Rev. 3 differ, and check that the audit trail records who changed a status and when. The tool supports the register but does not replace the assessment itself.

Who owns the POA&M, who helps build it, and who checks it

Your organization owns the POA&M. That includes the decision to accept, remediate, defer or retire each weakness, the named owner for every item, the target dates and the judgment about whether a milestone has been met. NIST places responsibility for implementing SP 800-171 and for any compliance issues with the federal agency that holds the contract, and the POA&M is one of the artifacts that shows how the organization is managing that responsibility. Outside help can shape the tooling, but the entries and the decisions behind them have to come from people inside the organization who can explain them to an assessor.

Named owners: Assign an accountable person to each item, not only a team, and record who approved any change to a target date.
Risk decisions: Document why an item is being accepted, mitigated or deferred, including any compensating controls.
Source linkage: Tie each entry to the assessment finding, audit observation or scan result that created it.
Status updates: Update milestones on a schedule the organization defines and keep the history of changes.
Closure evidence: Confirm that a fix actually works before marking an item closed.

Before relying on the register, check that every item has an owner, a documented decision and closure evidence that someone inside the organization has reviewed.

Where POA&Ms usually fall short and how to close each gap

A POA&M for 03.12.02 is only useful if it stays current, names an accountable owner for every item, and can be traced back to evidence. The gaps below appear repeatedly in assessment preparation, and each one has a practical fix that keeps the register working between assessments.

Entries without owners or milestones

An item that lists a weakness but no accountable owner, target date or interim milestone cannot show planned remediation. Assessors reviewing 03.12.02 look for a plan they can follow, not a list of problems. Give every item a named owner from the system's operations or security team, a completion date and at least one intermediate milestone. Check each week that no open item lacks these three fields.

Register updated only before assessments

A POA&M that is refreshed the week before an assessment shows the organization reacting to the assessor, not running a remediation process. The requirement expects updates driven by assessments, audits and continuous monitoring. Set a recurring review cadence, record the date of each change, and keep a short history of status transitions so the register shows how it was maintained over time. Ask whether your last update date matches your last monitoring cycle.

Scan findings that never reach the POA&M

Vulnerability scanners often produce results that stay in the scanner console, so known weaknesses never enter the POA&M at all. This is a gap under 03.12.02, which covers known vulnerabilities as well as assessment findings. Route scanner output into the same tracking tool, deduplicate repeated findings, and assign each high-risk finding a POA&M entry or a documented risk decision. DefectDojo can import and deduplicate findings from many scanner formats, and Greenbone Community Edition runs scans on a schedule, so you can confirm the import path works before your next scan cycle.

Closed items without validation evidence

Marking an item closed without retaining proof that the fix works is one of the most common reasons assessors reject a POA&M. Each closure should link to evidence such as a rescan result, a configuration export, a test record or an updated system security plan section, with the reviewer's name and date. Set a rule that an item cannot move to closed until its evidence is attached. Ask a second person to verify a sample of closed items each quarter.

No link to the system security plan

When a POA&M item is not tied to the system security plan, the register and the plan can describe different systems. An assessor may find a control described as implemented in the plan while the POA&M shows it open, or the reverse. For each item, record the affected requirement, the system component and the plan section it changes. When remediation finishes, update the plan in the same change so both documents agree. Verify this by picking three open items and tracing each to its plan section.

What buyers ask before hiring help with a POA&M

Can our organization keep a POA&M ourselves without outside help?

Yes. The organization owns its plan of action and milestones, and nothing in SP 800-171 Rev. 3 or SP 800-171A Rev. 3 requires an outside firm to write or keep one. The plan must record planned remediation of weaknesses found in assessments and of known vulnerabilities, and it must be updated from assessments, audits and continuous monitoring. Teams with a named owner, a working ticketing or findings process, and staff who can close items on schedule often manage this in-house. Outside help is most useful when the internal team lacks time or experience with the assessment method, or when the findings are not yet sorted into a usable backlog.

What drives the effort of setting up a POA&M?

The main drivers are how many findings exist, how many systems fall in scope, and how well current findings are recorded. Each item needs a description of the weakness, an owner, a planned remediation, and dates that the organization can track. Organizations that already run vulnerability scanning and assessments usually have raw inputs to start from, but those inputs often contain duplicates and inconsistent severity ratings that must be cleaned up first. Ask any provider to break the effort into intake, consolidation, first population of the plan, and the update routine that follows.

How long does it take to set up a POA&M?

No duration is fixed by the standard, and any figure a provider gives should come from the written scope for your environment. The time depends on the number of systems, the volume of existing findings and whether the assessment evidence is already organized. Ask the provider to state the assumptions behind the schedule, the deliverables at each milestone, and what your staff must provide and when. A fixed-scope agreement agreed in writing before work starts makes these assumptions visible.

What does the work need from our internal staff?

Internal staff must supply the knowledge the plan depends on: system owners who can confirm weaknesses and accept remediation dates, security staff who can validate severity, and an accountable executive who approves risk decisions. Engineers must be available to close items and provide evidence of closure. Plan for periodic updates after each assessment, audit or monitoring cycle, because the plan is only accurate if someone maintains it. Ask the provider to list these roles and the hours they require in the written scope.

Can a partner issue the assessment that feeds our POA&M?

No. DeployOpen prepares systems, controls and evidence, including support for planning remediation records, but it does not issue audit reports, attestations or certifications. Assessments against SP 800-171 are performed by the federal agency or by an assessor the regulation recognizes, depending on the contract. Confirm with your contracting officer or assessing body which assessment applies and what evidence it will review before you agree on a plan.

How does a POA&M differ from the System Security Plan?

The System Security Plan describes how the system meets each requirement today. The POA&M records the gaps: the weaknesses and deficiencies found, the planned remediation, the owner and the milestones for closing each gap. Both documents must agree, so a requirement shown as implemented in the System Security Plan should not carry an open item unless the assessment says otherwise. Keep the two documents linked through a shared identifier for each requirement, such as 03.12.02, so reviewers can trace each gap to the control it affects.

Does the POA&M need to be updated after each assessment?

Yes. The requirement is that the plan is updated based on findings from security assessments, audits or reviews and from continuous monitoring. Each new finding should be added, each closed item should carry evidence of closure, and dates should be revised with a recorded reason. Ask any provider how the update routine will work, who approves changes and where the history is kept, because reviewers look at how the plan changed over time as well as its current content.

How DeployOpen prepares a POA&M for assessment

DeployOpen works on 03.12.02 Plan of action and milestones as part of a fixed-scope engagement. We help the organization set up the POA&M process, connect it to the findings that feed it, and prepare the records an assessor will examine, while the organization keeps ownership of its controls and remediation decisions.

How we scope

Confirm which systems, assessment findings and monitoring sources feed the POA&M for the defined boundary.
Agree in writing who owns each POA&M entry, its update cadence and the approval path for closures.
Record which contract or assessment requirements the POA&M must satisfy before work starts.

How we build

Configure the POA&M workflow so each weakness has a remediation task, milestone, owner and status field.
Connect vulnerability scanning and findings imports so new items enter the POA&M with traceable sources.
Document the procedure for updating the POA&M after assessments, audits and continuous monitoring reviews.

How we hand over

Deliver the POA&M records, procedure document and an export showing entries, dates and closure evidence.
Walk the organization's assessment team through how each entry links to its assessment finding.
Provide a checklist mapping the five assessment objectives for 03.12.02 to the records that show them.

How we support

Offer ongoing support as a retainer for POA&M updates, tool upgrades and periodic reviews of open items.
Help the organization review entries against new assessment results before its next formal review.
Confirm with the organization's assessor which evidence format they expect before the handover is final.