By Ned Butler, Lead Certified CMMC Assessor (CCA), Redspin

During CMMC assessments and compliance consulting, we’ve noticed a pattern: when organizations get to CA.L2-3.12.2, they often blur the line between a Plan of Action and Milestones (POA&M) and an Operational Plan of Action (OPA).

It’s not a small mix-up. It signals a disconnect between what an organization is still building and what it is temporarily fixing.

The confusion is understandable. Both documents describe plans for addressing security issues. Both get tracked and managed. Both may sit in the compliance folder alongside assessment findings. From a distance, they may look like very similar. But they serve fundamentally different purposes, carry different requirements, and shouldn’t be used interchangeably.

Here’s how to tell them apart, and what we’re seeing organizations get wrong in the field.

Table of Contents

• The Confusion in Practice
• What the Regulation Says
• POA&M vs. OPA: Side-by-Side
• Understanding the POA&M
• Understanding the OPA
• A Real-World Example: The FIPS Patch Problem
• Common POA&M and OPA Mistakes
• How to Know Which One You Need
• Frequently Asked Questions
• How Redspin Can Help

The Confusion in Practice

We regularly sit with compliance teams who ask: “Aren’t these the same thing?” The honest answer is no; they are fundamentally different tools serving different purposes.

But again, the confusion makes sense. Both documents describe plans to address security issues. Both get tracked and managed. Both can end up sitting alongside assessment findings and other compliance documentation.

The problem starts when teams treat them interchangeably. We’ve seen assessments delayed because a POA&M was submitted where a OPA was required. We’ve watched remediation efforts stall because teams tried to use POA&M timelines for operational issues that don’t have fixed deadlines. And we’ve documented cases where a temporary control glitch was left in limbo because no one was clear on which plan should address it.

The distinction matters because the two tools have different legal and operational weight.

Get it right, and your remediation efforts stay on track. Get it wrong, and you’re creating confusion both internally and for your assessor.

What the Regulation Says

The CMMC rule (32 CFR Part 170) is clear about these distinctions, even if organizations don’t always read it that carefully.

Plan of Action and Milestones (POA&M):

According to 32 CFR Part 170, a Plan of Action and Milestones is “a document that identifies tasks needing to be accomplished. It details resources required to accomplish the elements of the plan, any milestones in meeting the tasks, and scheduled completion dates for the milestones, as defined in NIST SP 800-115.”

Operational Plan of Action (OPA):

An Operational Plan of Action, as used in CA.L2-3.12.2, is “the formal artifact which identifies temporary vulnerabilities and temporary deficiencies (e.g., necessary information system updates, patches, or reconfiguration as threats evolve) in implementation of requirements and documents how they will be mitigated, corrected, or eliminated.”

And the regulation makes one particularly important distinction:

“An operational plan of action does not identify a timeline for remediation and is not the same as a POA&M, which is associated with an assessment for remediation of deficiencies that must be completed within 180 days.”

In other words: A POA&M addresses assessment findings that need to be remediated. An OPA manages temporary deficiencies in controls you’ve already implemented.

POA&M vs. OPA: Side-by-Side

Understanding the POA&M

In the context of 32 CFR Part 170, a POA&M is born from a formal assessment.

When a C3PAO assesses your security controls and marks something as “Not Met,” you’re required to document a plan to fix it. That’s your POA&M.

Here’s what makes it different from an informal plan: it has teeth.

The 180-day deadline isn’t a suggestion. Your certification depends on closing it. Assessors expect POA&Ms to contain specific details on the unmet control(s):

• A clear explanation of what’s missing and why
• Defined remediation steps with responsible parties
• Resource requirements and budget implications
• Milestones with specific completion dates
• Evidence of active progress

A weak POA&M reads like a placeholder: “We will implement MFA by Q3.”

A strong one shows you’ve thought it through: “We will deploy Okta MFA to all Windows workstations in phase 1 (IT devices, 30 days), phase 2 (admin accounts, 45 days), and phase 3 (user accounts, 75 days). IT Director owns coordination; Identity team owns configuration. Budget: $X,000. Evidence: deployment reports and configuration audits weekly.”

Understanding the OPA

An OPA is different.

It’s not created by a C3PAO or tied to an assessment finding. It’s an internal operating tool your organization uses to document temporary issues that arise during normal business.

Think of OPAs as your mechanism for saying: “We’ve implemented this control, but right now, in this specific circumstance, we have a temporary gap. Here’s how we’re handling it.”

OPAs address things like:

• Vendor patches that temporarily invalidate FIPS-validated cryptography
• Rollout glitches affecting a small subset of equipment
• Temporary workarounds while a permanent solution is being built
• System maintenance windows where controls are briefly offline
• Known risks with documented mitigations

The key distinction is when the problem occurs.

An OPA documents something that happens after implementation. An OPA is not a substitute for implementing a control that doesn’t exist yet. It’s for managing temporary disruptions in a control that does exist.

A Real-World Example: The FIPS Patch Problem

Here’s a scenario we see regularly.

An organization implements FIPS-validated cryptography on their firewall, documented and verified. CMMC requirement met.

Then the firewall vendor releases a critical security patch. The organization applies the patch to address the vulnerability, which is the right move.

But now there’s a problem.

The patched firmware version hasn’t been re-validated against the FIPS standard yet. The version on the firewall is no longer the validated version. The organization has a temporary deficiency.

This is exactly what an OPA addresses. The organization documents:

• What happened: Firewall updated to address CVE-XXXX
• The deficiency: Updated version is not yet FIPS-validated
• How it’s mitigated: Vendor validation expected by [date]; organization monitoring for release. In the meantime, the firewall provides equivalent security through [mitigation strategy]

No POA&M is needed because this is not a CMMC assessment finding. The control was implemented and is functioning. The organization is managing a temporary gap while waiting on the vendor.

Now contrast that with an organization that never implemented FIPS-validated cryptography in the first place. That’s different. If that results in a “Not Met” during the assessment and the deficiency is eligible for POA&M, you’re now dealing with a POA&M and the applicable 180-day remediation window.

Same security requirement. Very different circumstances. Very different plan.

Common POA&M and OPA Mistakes We See

Mistake #1: Treating routine vulnerabilities as OPA items.

We have seen organizations documenting every vulnerability in an OPA. Not every security issue is a temporary deficiency. If a vulnerability has a clear fix available and your team has a process to remediate it, it doesn’t need an OPA entry, it’s identified in your Vulnerability Management System and remediated via RA.L2-3.11.3 and SI.L1-3.14.1. OPAs are for issues that don’t have an immediate remedy, or for temporary gaps in already-implemented controls.

Mistake #2: Using vague timelines in POA&Ms

Weak POA&Ms use fuzzy language: “We will address this as soon as resources allow” or “We’re working on a solution.” Assessors expect specificity. Commit to dates, resources, and checkpoints.

Mistake #3: Leaving mitigation details out of the OPA

An OPA that simply lists a problem isn’t enough. CA.L2-3.12.2 calls for documenting how temporary deficiencies will be “mitigated, corrected, or eliminated.” Your OPA needs to answer that question. What’s happening now? What’s the temporary risk? What are you doing about it? And how are you managing the issue until it’s resolved?

Mistake #4: Resubmitting the NIST 800-171 implementation POA&M

This one shows up regularly. An organization spent months or years implementing NIST SP 800-171 controls before CMMC existed. They created a comprehensive project-level POA&M for that work: “Phase 1: Deploy access controls, Phase 2: Implement encryption,” and so on. It was sound – a detailed plan for a major multi-phase initiative.

The issue is one of context and purpose. The NIST 800-171 implementation POA&M was a project plan answering the question: “How do we build security controls into our environment from scratch?” That’s valuable work, and it was the right document for that time. However, it is not what we are looking for when we assess CA.L2-3.12.2. What we are looking to see is that deficiencies and long-term vulnerabilities uncovered after controls implementation are identified with plans of action to correct, reduce, or eliminate them developed and implemented.

How to Know Which One You Need

The key is understanding which situation you’re actually in.

Assessment finding “Not Met”? Create or update a POA&M. Assign an owner, break the remediation into milestones, and commit to closure within the required 180-day window.

Temporary operational issue in an already-implemented control? Document it in your OPA. Describe the issue, explain how it’s being mitigated, and track progress toward resolution.

Still not sure?

Ask yourself two questions:

1. Did an assessor mark this as a finding, or did we discover this internally?

And

2. Are we trying to implement something that isn’t there, or manage a temporary deficiency in something we’ve already implemented?

Those answers will usually point you toward the right document.

OPAs and POA&Ms are both valuable compliance tools. But they serve different purposes, and the regulation is clear about what each should do. In our assessments, we find that organizations that treat them distinctly show better compliance maturity overall. They manage their remediation efforts more effectively, they communicate more clearly with assessors, and they’re less likely to be surprised by findings.

Frequently Asked Questions

What’s the difference between a POA&M and an OPA in CMMC?

A POA&M and an OPA both address security deficiencies, but they serve different purposes.

In the CMMC assessment context, a POA&M is associated with eligible deficiencies identified during an assessment and carries a defined remediation period. An OPA is used to manage temporary vulnerabilities or deficiencies that arise in controls that have already been implemented.

Can every CMMC “Not Met” requirement go on a POA&M?

No. POA&M use for CMMC certification is subject to specific eligibility requirements. A “Not Met” finding does not automatically mean the deficiency can be deferred through a POA&M.

Should every vulnerability go into our OPA?

No. Routine vulnerabilities that can be addressed through your established vulnerability management and remediation processes don’t automatically need an OPA.

An OPA is intended for vulnerabilities without a current fix and temporary deficiencies that need to be formally documented and managed until they can be corrected or eliminated.

What should an OPA document?

At minimum, it should clearly identify the temporary vulnerability or deficiency and explain how it will be mitigated, corrected, or eliminated.

The goal is to demonstrate that the organization knows the temporary gap exists and is actively managing it.

What should a strong POA&M include?

A strong POA&M should clearly describe the deficiency, remediation steps, responsible parties, required resources, milestones, completion dates, and evidence of progress.

It should function as an actionable remediation plan, not simply a list of open findings.

How Redspin Can Help

Knowing that you have a gap is only the beginning. You also need to know what kind of gap it is, how it should be documented, and what needs to happen next.

Redspin works with federal contractors across CMMC readiness, remediation, ongoing compliance, and certification. Our teams see firsthand where organizations get tripped up. not just in what the requirements say, but in how they’re implemented and demonstrated in the real world.

Whether you’re trying to clean up existing POA&Ms, understand your operational plans of action, prepare for an assessment, or build a compliance program that keeps working after certification, Redspin can help.

Not Sure Whether It’s a POA&M or an OPA?

It’s worth figuring that out before you’re sitting across the table from your assessor.

Get the documentation right. Get the remediation path right. And make sure your compliance program reflects what’s actually happening in your environment.