CA-5: Plan of Action and Milestones

To meet the ca-5: plan of action and milestones requirement, you must maintain a system-specific POA&M that records control assessment findings and known vulnerabilities, assigns accountable owners, and tracks planned remediation actions through closure. The POA&M must stay current and support risk decisions, prioritization, and evidence-ready reporting. ¹

Key takeaways:

• Your POA&M is the authoritative backlog for security/control weaknesses, with owners, due dates, and status tied to assessment results. ¹
• Auditors look for operational discipline: intake, triage, risk acceptance, and closure validation, not a static spreadsheet.
• Evidence quality matters as much as the plan: you need traceability from finding → POA&M item → remediation → retest/closure.

CA-5 requires a POA&M per system that turns assessment results into managed remediation work. The control is simple in concept: document what’s wrong, what you will do about it, and how you will track progress until the weakness is corrected or the risk is explicitly accepted. In practice, many programs fail CA-5 because the POA&M is treated as an afterthought (a file updated before an audit) rather than a living operational artifact that drives accountability and informs authorizing officials, leadership, and system owners.

For a Compliance Officer, CCO, or GRC lead, the fastest path to operationalizing CA-5 is to standardize the POA&M data model, define a tight workflow for intake-to-closure, and create repeatable evidence that proves the process runs continuously. Your POA&M should be anchored to findings from control assessments and to known vulnerabilities in the system environment. ¹

This page gives requirement-level implementation guidance you can put into action immediately: who owns what, what fields you must capture, how to run governance and exceptions, what artifacts to retain, and what auditors commonly challenge.

Regulatory text

Requirement excerpt: “Develop a plan of action and milestones for the system to document the planned remediation actions of the organization to correct weaknesses or deficiencies noted during the assessment of the controls and to reduce or eliminate known vulnerabilities in the system; and” ¹

Operator interpretation (what you must do):

• Maintain a system-level POA&M (not just an enterprise list) that captures weaknesses/deficiencies found during control assessments and known vulnerabilities impacting the system. ¹
• For each item, document the planned remediation action(s) and track milestones until the weakness is corrected or the risk is otherwise dispositioned through your governance process. ¹

Plain-English interpretation of CA-5

CA-5 is the control that prevents “we found problems” from turning into “we forgot about them.” Your POA&M is a controlled backlog of security and compliance debt. It answers four questions an assessor will press on:

1. What did you find?
2. What are you doing about it?
3. Who is accountable and by when?
4. How do you know it’s fixed?

If your program already has a ticketing system, vulnerability management workflow, or engineering backlog, CA-5 does not force you to replace it. It does require you to prove that those mechanisms produce a complete, system-specific, auditable record of planned remediation actions tied back to assessment results and known vulnerabilities. ¹

Who it applies to (entity and operational context)

CA-5 applies wherever NIST SP 800-53 is in scope, including:

• Federal information systems (agency-operated systems).
• Contractor systems handling federal data, where NIST 800-53 is contractually flowed down or required by an authorization boundary. ¹

Operationally, you should treat CA-5 as “always on” for:

• Systems undergoing initial authorization, reauthorization, or continuous monitoring.
• Systems with regular control assessments, penetration tests, vulnerability scans, or configuration compliance checks that produce findings.
• Shared services and inherited controls, where your POA&M must still reflect system impact and ownership (even when remediation sits with a platform team).

What you actually need to do (step-by-step)

1) Define the POA&M scope per system

• Identify the system boundary (what is “the system” for POA&M purposes).
• Decide what sources feed the POA&M: control assessments, internal audits, vulnerability scans, penetration tests, change reviews, incident postmortems, and exception reviews.
• Write a short “POA&M Operating Procedure” that states which sources are in scope and who is responsible for intake and maintenance.

2) Standardize the POA&M record (minimum data fields)

Create a required field set so every item can be assessed consistently. A practical minimum:

• Unique POA&M ID
• System name / boundary identifier
• Finding source (assessment, scan, audit)
• Finding reference (report name, control ID, test step)
• Weakness description (clear, testable statement)
• Risk statement (what could happen, in this system)
• Severity/priority (your defined rubric)
• Corrective action plan (what will be changed)
• Milestones (intermediate deliverables)
• Owner (single accountable person) and owning team
• Target completion date and status
• Dependencies/constraints
• Risk disposition (open, mitigated, accepted, transferred)
• Closure evidence link and closure approval

This structure is what turns a document into an operational control.

3) Build the intake and triage workflow

• Intake: A single channel where findings arrive (assessment deliverables, scan exports, audit observations).
• De-duplication: Merge duplicates across tools (common with recurring scanner findings).
• Triage: Confirm applicability to the system boundary, validate evidence quality, and assign an owner.
• Prioritization: Align remediation order with risk to mission and exposure. Document the rationale for items that remain open.

4) Tie POA&M items to execution systems (tickets, epics, change records)

Auditors want traceability, not copy/paste updates. Create links from each POA&M item to:

• Engineering ticket(s) where remediation is executed
• Change records if remediation requires approvals
• Exception records if remediation is deferred
• Retest results that prove resolution

If you use Daydream to map CA-5 to control owners and recurring evidence artifacts, treat that mapping as part of your operating model: one owner accountable for POA&M quality, plus technical owners accountable for fixes.

5) Establish governance: review cadence and escalation triggers

Define:

• Who chairs POA&M reviews (often ISSO, system owner, or GRC lead).
• Who must attend (technical owners, vulnerability management, change management, compliance).
• What triggers escalation (missed dates, stalled dependencies, repeated re-openings, disputed risk ratings).

You don’t need bureaucracy. You need predictable decision-making and documented outcomes.

6) Close items with verification, not optimism

Closure should require:

• Evidence the corrective action was implemented (config evidence, PR/commit reference, new control setting, system diagram update).
• Evidence the weakness is resolved (retest, rescan, assessor validation, or control re-performance).
• Approval by an authorized role (system owner, security lead, or governance body).

7) Manage exceptions and risk acceptance explicitly

Some items cannot be fixed quickly (legacy constraints, third-party limitations, mission dependency). For those:

• Record the compensating controls
• Record the rationale and approving authority
• Record the planned revisit point (tie to future modernization or contract renewal)

CA-5 expects the POA&M to document planned remediation actions; if you accept risk, document that disposition so your backlog remains truthful. ¹

Required evidence and artifacts to retain

Keep artifacts in a system-of-record that survives staff turnover:

• Current POA&M export or system report ¹
• Control assessment reports and test results that generated findings
• Vulnerability scan reports and exception notes (where applicable)
• Ticket/change links showing remediation work
• Meeting notes or decision logs for POA&M reviews (including approvals and deferrals)
• Closure packets: before/after evidence, retest results, closure approval
• Role assignments: POA&M owner, system owner, remediation owners

A clean evidence chain is the difference between “we fixed it” and “prove you fixed it.”

Common exam/audit questions and hangups

Expect these questions:

• “Show me your system POA&M and the last time it was updated.”
• “Pick a sample of findings from the latest control assessment. Where are they in the POA&M?”
• “Pick a sample of POA&M items marked closed. Show retest or validation evidence.”
• “For overdue items, show escalation and decision history.”
• “How do you ensure scanner findings are complete and not filtered without approval?”
• “How do you handle inherited/shared-control weaknesses?”

Common hangups:

• Items closed without verification evidence.
• Target dates that are routinely missed without documented escalation.
• POA&M missing findings because they stayed in an engineer’s backlog instead of the compliance record.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails CA-5	Fix
“POA&M = spreadsheet updated before audits”	No operational process, no continuous tracking	Put POA&M behind an intake workflow with ownership and review minutes
No link to assessment findings	Breaks traceability to “weaknesses noted during assessment”	Require a “finding reference” field for every item 1
Closing without retest	Closure becomes subjective	Require rescan/retest artifact and approver sign-off
Mixing enterprise and system POA&Ms	System boundary accountability gets lost	Maintain system-level views, even if stored in a central tool 1
Deferrals handled informally	Risk decisions become invisible	Use a documented risk acceptance/exception path with approvals

Enforcement context and risk implications

No public enforcement cases were provided in the supplied source catalog for this requirement, so this page does not cite enforcement outcomes.

Operational risk is still material: weak POA&M discipline creates a predictable pattern of repeat findings, unresolved vulnerabilities, and poor audit outcomes because the organization cannot prove remediation governance. CA-5 also becomes a management reporting issue: leadership cannot make credible risk decisions if the remediation backlog is incomplete or stale.

Practical 30/60/90-day execution plan

First 30 days (stand up the minimum viable POA&M)

• Assign a single accountable POA&M owner per system (or per authorization boundary).
• Standardize the POA&M template/fields and publish the operating procedure.
• Import the latest assessment findings and known vulnerability backlog into the POA&M.
• Start closure criteria: require evidence links and a defined approver.

By 60 days (make it operational and auditable)

• Integrate POA&M items with tickets/change records; enforce link requirements.
• Run recurring POA&M review meetings and capture decision notes.
• Implement escalation for overdue items and document dispositions.
• Perform an internal sample test: trace findings → POA&M → ticket → closure evidence.

By 90 days (tighten governance and continuous monitoring)

• Add quality checks: duplicate detection, stale items, missing owners, missing dates.
• Align risk acceptance workflow to POA&M so deferrals and compensating controls are recorded.
• Build a management reporting view for open items, overdue items, and top recurring weakness categories.
• If you use Daydream, map CA-5 to the control owner, implementation procedure, and recurring evidence artifacts so evidence collection is routine rather than event-driven.

Frequently Asked Questions

Do I need a separate POA&M for each system?

CA-5 is written “for the system,” so you need a system-specific view even if you store everything in a central platform. Keep boundary-level traceability so you can show exactly what is open for a given system. ¹

Can my vulnerability management tool or ticketing system count as the POA&M?

Yes, if it captures the required POA&M fields, includes assessment-derived weaknesses, and supports end-to-end traceability and closure evidence. If those pieces live in multiple tools, define which tool is the system-of-record and how links are enforced. ¹

What is the minimum auditors expect to see for closure?

Closure should include proof the fix was implemented plus proof the weakness is gone (retest/rescan or assessor validation), along with an approval record. Without validation evidence, “closed” often fails sampling.

How do we handle POA&M items we cannot remediate due to third-party constraints?

Keep the item open with a clear corrective action plan that includes the third party dependency, or document an approved risk disposition with compensating controls and a revisit trigger. Treat contract renewal and vendor roadmap as milestones you can track.

What belongs in the POA&M versus a risk register?

Put actionable remediation work tied to specific weaknesses/vulnerabilities in the POA&M. Put broader, ongoing enterprise risks in the risk register, then link them when a POA&M item is a mitigation for that risk.

How do we prevent the POA&M from becoming a dumping ground?

Enforce entry criteria (clear weakness statement, source reference, owner, target date) and exit criteria (validated closure). Run periodic hygiene reviews to merge duplicates and reject items that lack actionable remediation.

Footnotes

1. NIST SP 800-53 Rev. 5 OSCAL JSON