Plan of Action

Official Source Material

Develop and implement plans of action designed to correct deficiencies and reduce or eliminate vulnerabilities in organizational systems.

Determine if:

[a] deficiencies and vulnerabilities to be addressed by the plan of action are identified;
[b] a plan of action is developed to correct identified deficiencies and reduce or eliminate identified vulnerabilities; and
[c] the plan of action is implemented to correct identified deficiencies and reduce or eliminate identified vulnerabilities.

Source: CMMC Assessment Guide - Level 2, Version 2.13, September 2024

Practitioner Guidance

How to meet it

This is your operational plan of action, not the assessment POA&M, and confusing the two costs you.

The assessment POA&M is the plan of action and milestones defined in 32 CFR 170.4 and constrained by 32 CFR 170.21, and it exists only around a CMMC assessment. It is limited to select low-weight requirements and must close out within 180 days of the conditional status date. The plan this requirement asks for is the standing document you run all year to track deficiencies and vulnerabilities to closure. Keep them as separate artifacts with separate names, because they answer different questions under different rules.

The operational plan of action is also how a temporary deficiency scores as MET.

32 CFR 170.24(b)(1)(ii) states that temporary deficiencies appropriately addressed in operational plans of action, meaning the plan includes deficiency reviews and shows progress toward correction, are assessed as MET. Take the common encryption gap: a required patch moves you off the FIPS-validated module version, the exact build the government certified, while revalidation is pending. That gap does not have to fail the affected requirement if this document exists and shows the deficiency being worked. That makes CA.L2-3.12.2 one of the highest-leverage requirements in the whole set.

Every entry gets an owner, steps, and dates.

The guide's checklist is ownership, clear actionable steps or milestones, responsibility for each step, milestones to measure progress, and completion dates. Format is irrelevant: a spreadsheet tab, a ticket type in your tracker, or a document all work. Content and follow-through are what the objectives test.

Objective [c] is the one that fails: the plan must be worked, not just written.

Entries that sit unchanged through four quarterly reviews show a plan that was developed for [b] and never implemented for [c]. Review the plan on a schedule. Update milestones as they pass, and close entries with evidence. Have someone other than the fixer verify the fix where it matters.

Feed it from everything that finds problems.

Scan findings from RA.L2-3.11.2, deficiencies from CA.L2-3.12.1 assessments, incident lessons, and audit findings all identify the items [a] asks about. One intake and one document beats a scatter of lists. Not every flaw earns an entry. Fix the one-off misconfiguration on the spot. Reserve the plan for deficiencies that take time, resources, or coordination, plus the recurring problem that needs a root-cause task.

What falls short

A plan of action written once for a gap assessment and never touched again. Static entries with expired dates show [c] was never done.
Findings tracked only inside the vulnerability scanner console. The scanner shows detections, not decisions, and nothing demonstrates a developed plan with owners and milestones for [b].

Edge cases

A permanent gap that will never close, such as a machine that cannot run endpoint protection without breaking, does not belong on a plan of action at all. That is an enduring exception: describe it and its mitigations in your system security plan, the document that says how each requirement is met, where 32 CFR 170.24(b)(1)(i) assesses it as MET.