CA.L2-3.12.2 Operational plan of action: evidence

What the CMMC Level 2 operational plan of action requires

A defense contractor's Level 2 system will develop deficiencies and vulnerabilities after it is implemented, whether from a patch that breaks a security setting, a scanner finding on a legacy server, or configuration drift nobody noticed. CA.L2-3.12.2 asks the organization to identify those deficiencies and vulnerabilities, develop a plan of action to correct or reduce them, and implement that plan. The risk it addresses is straightforward: a known weakness left without a managed path to closure stays open indefinitely. Under the CMMC Scoring Methodology, this requirement carries 3 points, and it cannot be placed on a POA&M, so it must be MET before the organization can reach Conditional or Final Level 2 status.

The distinction matters because the two artifacts look alike on paper. An assessment POA&M records requirements found NOT MET during an assessment and must be closed within 180 days of that assessment under 32 CFR 170.4. An operational plan of action covers temporary vulnerabilities and deficiencies, in a format the contractor chooses, with no remediation timeline. The DoW CMMC FAQ (July 2026) indicates that a significant change introducing a temporary deficiency after initial compliance may be handled this way, while a requirement found NOT MET during an assessment needs a POA&M. Confirm with your assessor which path each finding follows before you choose one.

The absence of a fixed deadline is what makes this requirement hard. Without a date forcing action, plans drift, owners change and items quietly age out. Assessors test the mechanisms behind the plans: a documented procedure for developing, implementing and maintaining them, and entries that name the deficiency, the planned correction, an accountable owner and current status. Closures should be backed by evidence such as a change ticket, a rescan result or an updated configuration baseline. Set a standing review cadence and keep dated records of each step. As an illustrative case, a scanner flags an unpatched library on an enclave server that cannot be updated until the vendor certifies a fix. The plan records the compensating measure, the owner, the review interval and the test that will confirm closure.

Which systems, data and teams fall under this operational plan of action

An operational plan of action covers deficiencies in the systems that handle CUI, wherever they come from. The cards below cover the boundary, the sources that surface findings, the owners who fix them and the outside providers whose findings enter the plan, so scope decisions are made before the first deficiency is logged.

The CUI handling system boundary

Start with the systems that store, process or transmit CUI, plus the security protection assets that protect them. The boundary decides which deficiencies belong in the plan of action at all. Confirm in writing which hosts, enclaves, identity services and endpoints sit inside it, and record the decision in the system security plan so the plan of action and the SSP describe the same environment.

Vulnerability scanning and ticketing sources

Scanners, asset inventories and ticketing systems are where temporary deficiencies first appear. Greenbone Community Edition schedules scans and stores results, and GLPI can track tickets, problems and changes that document each deficiency. Decide which tool is the system of record for each finding so a deficiency is not logged twice or lost between tools.

Teams that own remediation

Each deficiency needs a named owner, usually in system administration, network engineering, application development or security operations. Assign owners by system, not by ticket queue, and write down who approves a plan and who verifies that the fix was implemented. An assessor will look for evidence that the plan was carried out, so unclear ownership is one of the most common gaps.

External providers whose findings enter the plan

Managed service providers, cloud operators and third-party testers can report deficiencies in systems you rely on. Include contractual rights to receive their findings, and decide whether their findings are handled under your operational plan or a different process. Scope cloud services explicitly, because a service inside the CUI boundary brings its findings into your plan of action.

Specialized assets and scoping decisions

Operational technology, test equipment and other specialized assets may or may not be inside the CUI boundary, and that choice changes how many deficiencies the plan must cover. Confirm with your assessor's scoping guidance and your own data flow analysis before excluding any asset, and document the reasoning. Illustrative example: a test bench that never stores CUI may sit outside the boundary, but only if its network path is also isolated.

When an operational plan of action applies and when a POA&M is required

When an assessor finds a requirement NOT MET, the contractor has a POA&M situation, not an operational plan of action situation. Under the CMMC scoring rules, each requirement carries a point value that is subtracted from the maximum score of 110 when it is not met. Requirements worth more than 1 point cannot be placed on a POA&M, so a NOT MET result on a higher-value requirement must be corrected before a Conditional or Final Level 2 status is possible. Requirements worth 1 point may be carried on a POA&M within the limits of 32 CFR 170.21, which must be closed within 180 days of the assessment. CA.L2-3.12.2 is a 3-point requirement, so it can never be placed on a POA&M.

Assessment finding: The artifact is a POA&M tied to the assessment, with a closure date within the 180-day window.
Point value check: Confirm the requirement's value under the scoring methodology before deciding whether a POA&M is allowed.
CA.L2-3.12.2 exception: A NOT MET result on this requirement means the plan of action must be in place and met, not deferred.
Evidence in final form: Closure evidence must be final, not draft, before the requirement can be counted as MET.
Ownership: The organization owns the POA&M. An implementation partner can help prepare the fix and evidence, but the assessor decides the result.

Before the assessment, confirm which requirements on your environment have a point value above 1 and whether any open item is already on a POA&M.

How an assessor tests CA.L2-3.12.2

This table compares the three NIST SP 800-171A assessment objectives for CA.L2-3.12.2 with the mechanism objective that sits behind them. Read each row as a question the assessor asks, the evidence they request, and the gap that most often turns a requirement NOT MET. A requirement is MET only when every applicable objective is satisfied with evidence in final form, not drafts.

Assessment objective	What the assessor examines	Evidence requested	Common findings leading to NOT MET
Identify deficiencies and vulnerabilities	Whether the organization has a documented way to find deficiencies and vulnerabilities in organizational systems, and whether the results feed into the plan	Assessment results, scan and review outputs, and a list of identified deficiencies with dates and affected systems	Findings from assessments or scans exist but are not recorded, or the deficiency list omits known weaknesses
Develop a plan of action	Whether a plan exists for each identified deficiency, with a described correction or risk reduction and an owner	Operational plan of action in final form, linked to each deficiency, showing the corrective step and responsible party	Deficiencies are known but no plan is written, or the plan is a draft, lacks owners, or does not say what will change
Implement the plan	Whether the corrective actions were carried out and whether the vulnerability was reduced or eliminated	Change records, patch or configuration evidence, retest results, and closure notes tied back to the plan entry	Actions are listed as planned but no implementation evidence exists, or closure is claimed without retesting
Mechanisms to develop, implement and maintain the plan	Whether the organization has a process, defined roles and a repeatable method for updating the plan over time	Written procedure for the plan, a tracking system or register with version history, and records showing periodic review	The plan is created once and never reviewed, or no one is assigned to maintain it after a significant change

How to build the operational plan of action step by step

This sequence turns deficiencies found by scanning, monitoring and assessment into tracked corrections, each with an owner, an action, a verified fix and a closing record that an assessor can follow from start to finish.

Collect deficiency intake from scanning and monitoring
Gather every candidate deficiency from vulnerability scans, control monitoring results, incident records, change reviews and internal audit findings into one intake register. Record the affected system, the requirement it touches, the source report and the date it was logged. The step is done when every intake item traces back to a source record, so an assessor can see where each deficiency came from. Tools such as DefectDojo or the Greenbone reports can serve as the source, provided their findings are exported or linked into the register.
Triage and rate each deficiency by risk
Review each intake item to confirm it is a real deficiency, remove duplicates and decide whether it is a temporary deficiency that an operational plan of action can cover or a requirement found NOT MET that belongs on a POA&M. Assign a risk rating based on the affected asset, the data involved and the likelihood and impact of exploitation, and record the rationale. The step is done when each item has a rating, a disposition and a recorded reason, which shows the assessor that the triage was deliberate.
Write the plan with owners and actions
For each accepted item, write the corrective or risk-reducing actions, name an accountable owner and a responsible implementer, and describe how the team will know the action worked. Because an operational plan of action has no fixed remediation deadline under 32 CFR 170.4, the plan can set a target date in your own process, but it does not have to match a regulatory clock. The step is done when every item has a written plan, a named owner and an approval record, which covers the plan of action element of the assessment objectives.
Carry out the plan and log progress
The owner executes the actions through the normal change process, so configuration changes, patches or compensating measures go through the same review as any other change. Record each action taken, the evidence produced (change tickets, configuration exports, patch records) and any changes to the plan. The step is done when the work is recorded as completed in the tracking system with links to the supporting change records, showing the implementation objective is being met in practice.
Verify the fix with a retest
Confirm that the deficiency is actually corrected or the vulnerability is reduced by rerunning the scan, repeating the monitoring check or testing the control that failed. Keep the retest output and compare it against the original finding. The step is done when the verification result is attached to the item and the retest shows the deficiency no longer appears, or the residual risk has been reviewed and accepted in writing by an authorized person.
Retire the item and record the closure
Close the item only after verification, record the closure date, the verifier, the evidence references and any residual risk, and move the item to a closed state rather than deleting it. Keep closed items available for later assessment so the history of deficiencies and corrections can be reviewed. The step is done when the register shows a complete, traceable record for every item, which is the evidence an assessor will sample.
Review the register on a regular cycle
Review open and closed items at a recurring interval set by your governance process, look for patterns such as repeated deficiencies on the same system, and feed lessons into the risk assessment, configuration baselines and monitoring. Update the plan of action procedure if the review shows gaps. The step is done when each review is minuted and any changes to the process are recorded, showing the plan is maintained rather than a one-time exercise. Confirm the review cadence with your assessor or C3PAO before the assessment.

Evidence that passes for the operational plan of action

An assessor testing CA.L2-3.12.2 looks for a trail that runs from a detected deficiency to a documented plan, then to completed work and verified results. The cards below cover the artifacts that form that trail and the open-source tools that can produce them, while the organization keeps ownership of its procedure.

The written operational plan

The operational plan of action is the core artifact. It records each temporary deficiency or vulnerability, the affected system, the corrective steps, the responsible owner and the status. Under 32 CFR 170.4 it has no fixed remediation timeline and may use a format the contractor chooses, so the assessor checks for completeness and approval rather than a due date. Confirm that the document is final, dated and approved, since drafts do not satisfy the assessment objectives.

Tickets and work records per action

Each action in the plan should trace to a ticket or work record showing who opened it, when work started, what was changed, and who closed it. Assessors use these records to test the implementing objective of CA.L2-3.12.2. Records that are edited after closure or that lack an owner weaken the trail. Keep the ticketing system as the system of record and reference its IDs in the written plan.

Scan and monitoring outputs that triggered actions

The plan should point to the evidence that identified each deficiency, such as vulnerability scan reports, configuration review results or monitoring alerts. These outputs show the identifying objective was met. Preserve the raw report with its scan date, target scope and scanner version, not only a summary written later. An action with no triggering output is hard to justify to an assessor.

Verification results after the fix

Closing an action requires proof that the fix worked. Retain a re-scan, a configuration check or a test result taken after the change, dated later than the remediation record. This evidence supports the claim that the plan was carried out and that the vulnerability was reduced or eliminated. Without verification, a closed ticket shows activity but not outcome.

Change records linked to fixes

Many corrective actions alter configurations, software or access settings. Link each fix to its change record, including the approval, the implementation window and any rollback plan. This shows that corrections went through the organization's normal change control rather than ad hoc edits. Assessors also check whether a change that introduced a temporary deficiency is recorded with its plan.

Keeping evidence current between assessments

Operational plans are living records, so evidence must stay current between assessments. Set a recurring review of open items, record closures as they happen, and retain prior versions of the plan so history is visible. Confirm with your assessor how often they expect the plan to be reviewed and how they want version history presented, since the rule does not set a fixed interval for this artifact.

Open-source tools that produce this evidence

Greenbone Community Edition (AGPL-3.0-or-later) stores scan results in PostgreSQL and provides a web interface for review, which supports the trigger evidence. DefectDojo (BSD-3-Clause) imports and deduplicates findings from over 500 report formats, helping track each finding to its action. GLPI (GPL-3.0-or-later) manages tickets, problems and changes under ITIL practices. Confirm each tool fits your environment, and remember that your organization still owns the procedure the tools support.

What meeting CA.L2-3.12.2 costs in money and effort

This table breaks down the cost components of running an operational plan of action for CA.L2-3.12.2, showing who is paid, whether each cost is one-time or recurring, and what drives it up or down. Use the last column to build the questions you put to any quote, since no price or duration is published for this work and each figure depends on your environment.

Cost component	One-time or recurring, and who is paid	What drives it up or down	What to ask for in a quote
Tooling and licenses	Mostly one-time setup, then recurring hosting and support. Paid to the vendor or open-source operator, or to the implementer for setup.	Choice of open-source tools such as DefectDojo (BSD-3-Clause) or GLPI (GPL-3.0-or-later), which carry no license fee but need hosting. Commercial tools add recurring subscriptions. Confirm each license term before adoption.	A bill of materials listing each tool, its license, hosting location, and who maintains upgrades and backups.
Internal engineering and remediation time	Recurring. Paid as staff time or to contractors who fix the deficiencies the plan covers.	Number and complexity of deficiencies found after implementation, and how many systems share the fix. Clear ownership and tested change control shorten the work.	A remediation estimate per deficiency class, the named owner for each action, and what the implementer will and will not perform.
Plan upkeep and evidence records	Recurring. Paid as staff time to record each deficiency, the action taken, its status and the verification evidence.	Volume of operational changes and how often the plan is reviewed. Keeping records in a ticketing system from the start avoids reconstructing history at assessment time.	The record format, review cadence, retention period, and whether the implementer drafts the plan or only supports your team.
External testing or review	Recurring or per event. Paid to an independent tester or consultant, separate from the assessor.	Scope of testing, such as vulnerability scans or penetration tests that confirm a fix worked. Frequency and the number of systems in scope are the main levers.	Test scope, method, deliverables, retest terms, and confirmation that the tester does not issue any compliance report.
Assessor sampling during a C3PAO assessment	Per assessment event. Paid to the C3PAO, the independent assessor, not to DeployOpen or other implementers.	Number of plan entries the assessor samples and the depth of evidence requested. Complete, dated records of implementation shorten sampling. Fees are set by the assessor.	The assessor's fee schedule and scope in writing, plus the evidence list the assessor will request. Confirm the current assessment requirements with the Cyber AB and DoW guidance before budgeting.

Who owns the plan, who prepares the evidence and who assesses it

The organization owns CA.L2-3.12.2. Its leadership decides which deficiencies are acceptable to carry, who is accountable for each corrective action, and whether a finding is handled through an operational plan of action or a POA&M. Only the organization can show that the plan is actually carried out, because the assessor looks for records of work performed by the people responsible for the system.

Ownership decisions: Naming the accountable owner for each plan and approving scope, priority and closure.
Triage rules: Deciding which findings are temporary deficiencies after a change and which are NOT MET findings that must go on a POA&M.
Execution records: Tickets, change records and sign-offs showing that corrective steps were implemented.
Plan maintenance: Reviewing open items on a regular cadence and retiring items once the underlying issue is resolved.
Governance: Briefing management and keeping the plan consistent with the system security plan.

Before relying on any template or tool, confirm internally who signs the plan and how closure is approved.

Where operational plans of action usually fall short

Most gaps in operational plans of action come from confusing them with assessment POA&Ms, or from treating the plan as a document instead of a working record. The cards below cover the failure points an assessor is likely to test, and a practical way to close each one before evidence is requested.

Using an operational plan for a NOT MET requirement

An operational plan of action covers a temporary deficiency that appears after a requirement was implemented. A requirement found NOT MET during an assessment belongs on a POA&M, and CA.L2-3.12.2 is worth more than 1 point, so it cannot sit on a POA&M to reach Conditional or Final status. Before relying on an operational plan, check the requirement's status at the last assessment and confirm that the deficiency arose after initial compliance.

Plans with no owners or verification

A plan that names no accountable person and no check for completion is not a plan of action in the sense the assessment objectives describe. Each entry should record who owns the correction, the vulnerability or deficiency it addresses, the steps taken, and how someone confirms the risk is reduced. Ask whether every open entry has a named owner and a verification step that a second person can review.

Plans written after the assessment

Assessors look for evidence that the plan was developed and maintained as the deficiency came up, not reconstructed when an assessment was scheduled. An entry created weeks after a finding, with dates that cluster just before the review, invites questions about the mechanism itself. Keep entries as they are identified, record dated revisions, and retain the history of each change rather than overwriting it.

Drafts presented as final evidence

Assessors may only credit evidence in final form, and a plan that exists only as an unapproved draft does not show the mechanism is operating. Confirm which version was approved, by whom, and on what date, and keep the approved version separate from working notes. Before an assessment, remove or label drafts so the reviewer can see exactly which document governs each entry.

Scan findings never triaged

Vulnerability scanning often produces findings that never become plan entries, because no one decides whether they reflect a deficiency that needs correction. Triage each finding into one of three outcomes: remediate, accept with a documented reason, or add to the plan with an owner. Open-source tools such as Greenbone Community Edition store scan results in PostgreSQL, and DefectDojo can deduplicate imported findings, so the triage record can be tied to the original result.

Tickets closed without proof of fix

A ticket marked resolved in a service desk is not evidence that a vulnerability was reduced or eliminated. Require each closed ticket linked to a plan entry to hold the change record, a rescan or configuration check result, and the reviewer's sign-off. GLPI's Assistance module can track tickets and changes through their lifecycle, which makes it straightforward to block closure until the proof field is filled.

How much effort and outside help does an operational plan of action need?

What drives the effort of an operational plan of action for CA.L2-3.12.2?

The effort scales with how many deficiencies and vulnerabilities your systems produce, how many systems sit inside the CUI boundary, and how well your existing tools already surface problems. CA.L2-3.12.2 asks for three things: identifying the deficiencies to address, developing a plan to correct or reduce them, and implementing that plan. Each new finding needs a documented entry, an owner, a chosen corrective action and proof that the action was carried out. Organizations with many assets, frequent changes or scattered tickets spend the most time on upkeep, while a small, stable boundary with a single system of record for findings usually needs far less. Ask any provider to break its quote down by system count, number of expected findings and the tools it will connect to.

Can our own team write and run an operational plan of action in-house?

Yes, the organization owns its controls and the plan, and nothing in the CMMC rule requires an outside firm to write it. The plan can use a format you choose, and it has no fixed remediation timeline. What your team needs is a repeatable process: a way to log deficiencies, a named owner for each corrective action, evidence that the fix was implemented, and records that an assessor can review in final form. Teams that already run an IT service management tool or a vulnerability management process usually adapt those workflows. Outside help is most useful for designing the process, configuring the tools and preparing evidence, while an independent assessor is the only party that judges whether 3.12.2 is MET.

How does an operational plan of action differ from a POA&M, and why can't 3.12.2 go on a POA&M?

An operational plan of action covers temporary vulnerabilities and deficiencies found after implementation, in a format you choose, with no remediation timeline. A POA&M is used for requirements found NOT MET during an assessment and must be closed within 180 days. CA.L2-3.12.2 is a 3-point requirement, and the CMMC scoring rules do not allow a requirement worth more than 1 point on a POA&M. That means 3.12.2 must be MET to reach Conditional or Final Level 2 status. Treat it as a practice that must work at all times, not as a deferral mechanism. Confirm the current classification of any specific finding with the DoW CMMC FAQ and your assessor before you rely on it.

What does the day-to-day work look like for the engineering and security team?

The work is continuous and mostly routine. Typical activities include:

Reviewing new scanner results and assessment findings each cycle, then deciding which ones need an operational plan entry
Assigning an owner, a corrective action and a verification step for each entry
Recording evidence that the fix was carried out, such as a change record, a configuration export or a retest result
Checking that plans remain current after changes to systems, staff or the CUI boundary

When these steps are tied to a ticketing system and a findings tracker, the team can show a consistent history. When they live in email and spreadsheets, evidence gaps tend to appear at assessment time.

Which open-source tools can hold the findings and tickets behind an operational plan of action?

Open-source tools can hold the records, but they do not decide whether a requirement is MET. GLPI's Assistance module can track tickets, problems and changes following ITIL practices, which gives each corrective action an owner and a history. DefectDojo can import and reimport findings from more than 500 report formats and deduplicate them, which helps keep one record per deficiency. Greenbone Community Edition runs scan tasks and stores results in PostgreSQL, providing a source of vulnerability evidence. Confirm that each tool meets your evidence and retention requirements, and test that exports are accepted by your assessor before you commit to a workflow.

Does the Phase II suspension or the Rev. 2 enforcement statement change how we approach 3.12.2?

No. The Department of War suspended CMMC Phase II on 13 July 2026, and the CMMC rule still incorporates NIST SP 800-171 Rev. 2, which the Department said it will enforce in the interim. CA.L2-3.12.2 is a Rev. 2 requirement, so the operational plan practice applies to the controls in your boundary either way. The suspension changes when third-party certification may be required, but it does not remove DFARS 252.204-7012 obligations or the Phase I self-assessment and SPRS posting duties. Because the schedule has changed, confirm your contract's current requirements with the contracting officer and the DoW CIO pages before you set your budget.

What should we ask an outside provider to put in a quote for this work?

Ask for a written scope that names the systems in the CUI boundary, the number of assessment objectives covered for 3.12.2, and the tools to be configured or integrated. Request separate line items for process design, tool setup, evidence preparation and any recurring upkeep, and say whether each is one-time or ongoing. Ask who performs each task, what evidence the provider will deliver, and how changes to scope are priced. Confirm in writing that the provider prepares evidence only and that an independent assessor performs the assessment. DeployOpen works from a written scope and does not publish a price list, so the quote follows from the scope you agree on.

How DeployOpen prepares operational plan of action evidence

DeployOpen prepares the systems, records and written plans that show how your organization finds, tracks and corrects deficiencies after implementation under CA.L2-3.12.2. Your organization owns the controls and the plans, and an independent assessor decides whether the evidence meets the requirement.

How we scope

Agree in writing which systems, ticketing sources and scanning tools feed the operational plan of action process.
Define which deficiency types go to an operational plan of action and which must become a POA&M instead.
Name the owner who approves each plan, along with the review cadence your organization commits to.

How we build

Configure a ticketing workflow that records each deficiency, its owner, planned corrective action and status.
Connect vulnerability scanning and finding-import tools so deficiencies enter the plan with a traceable source.
Test that each plan moves from identified to planned to implemented, with dated changes kept in the record.

How we hand over

Deliver a written operational plan of action procedure your staff can follow without DeployOpen present.
Provide finished plan records and ticket history in final form, not drafts, so assessors can review them.
Document how each record maps to the three assessment objectives of NIST SP 800-171A for 3.12.2.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, agreed in writing.
Review operational plans on a set schedule to confirm corrective actions are carried out and closed.
Confirm with your assessor and sponsor how they expect plan evidence to look before a formal assessment.