CA Controls Unlocked: Security Plans, POA&Ms, and Continuous Monitoring

Paul Netopski

Welcome to CMMC Unlocked. I’m Paul Netopski, and today we’re getting practical. For CMMC Level 2, there are three core compliance documents that have to work together: the System Security Plan, the POA&M, and continuous monitoring. If your SSP is weak, everything downstream gets shaky.

Eric Marquette

And that’s the thing people miss, right? They treat the SSP like a form to fill out instead of the foundation document.

Paul Netopski

Exactly. NIST SP 800-18 defines the system security plan as a formal document that provides an overview of the security requirements for the information system and describes the security controls in place or planned for meeting those requirements. That means the SSP is where you explain what the system is, what information it handles, what boundary you are protecting, and how the controls are actually implemented or planned.

Roz the Rulemaker

And from a governance perspective, it also establishes accountability. NIST 800-18 is very clear that the plan identifies the system owner, authorizing official, designated contacts, and assignment of security responsibility. So it is not just technical narrative. It is also responsibility made visible.

Paul Netopski

Right. From an assessor standpoint, the first question is usually not, “Do you have a control?” It is, “Show me where the system is defined.” Your SSP should describe the system name and identifier, FIPS 199 categorization, system type, operational status, general description and purpose, environment, interconnections, and the laws or policies affecting the system. And for CMMC, that maps directly to the CA family expectation that a system security plan is developed, documents the boundary, environment, implementation methods, and is updated with the defined frequency.

Eric Marquette

So if I’m a contractor and my SSP says, “We use Microsoft 365 and laptops,” that’s not gonna cut it.

Paul Netopski

No, that is far too thin. An assessor is looking for boundaries and relationships. What is in scope? What is outside the authorization boundary? What systems interconnect? What information types are processed, stored, or transmitted? NIST 800-18 spends real time on boundary analysis because weak boundaries create weak control statements.

Roz the Rulemaker

And if the boundary is vague, every later claim becomes harder to defend. Your access control story, your monitoring story, your remediation story — all of it.

Paul Netopski

That’s exactly right. The SSP also needs to document control selection and how controls are implemented. NIST 800-18 says describe each control, how it is implemented or planned, any scoping guidance applied, and whether it is a common control. Under RMF in NIST 800-37, that same planning function carries forward: requirements are defined, allocated, controls are selected, tailored, allocated, and documented in the security plan.

Eric Marquette

So this is where the SSP tells the story.

Paul Netopski

Yes. The SSP tells the story of control design and implementation. Assessors use it as the baseline in the CA domain. NIST 800-18 says the system security plan should form the basis for authorization, supplemented by the assessment report and the plan of action and milestones. So when an assessor tests a practice, they compare the evidence to the story in the SSP. If your SSP says multifactor authentication is enforced for remote access, I expect to see that in configuration, policy, and operation.

Roz the Rulemaker

And if the document says “implemented” but the evidence shows “planned,” that is not merely a drafting problem. It is a credibility problem.

Paul Netopski

Correct. Practical advice: keep the SSP current. NIST 800-18 calls it a living document and says review and update it at least annually, and also whenever significant changes occur. If your architecture changed, if interconnections changed, if the system owner changed, the SSP should reflect that. For CMMC Level 2, a current SSP is not optional. It is the baseline against which your control assessment begins.

Paul Netopski

Once the SSP establishes the baseline, the next document is the POA&M. And this is where a lot of companies get nervous, because they think a POA&M is a confession. It is not. It is your remediation record.

Eric Marquette

Yeah, like, the existence of a POA&M can actually show maturity if it’s managed well.

Paul Netopski

Exactly. NIST defines a plan of action and milestones as a document that identifies tasks needing to be accomplished, details resources required, milestones, and scheduled completion dates. DHS Attachment H goes further and operationalizes it as the centralized mechanism for tracking weaknesses and vulnerabilities until remediation is verified and the item is closed.

Roz the Rulemaker

That emphasis on tracking matters. In a disciplined program, a weakness is not allowed to drift around informally in emails and meeting notes. It is entered, assigned, dated, prioritized, and governed through status.

Paul Netopski

And that maps directly to CMMC CA.L2-3.12.2: identify deficiencies and vulnerabilities, develop a plan of action, and implement that plan. A solid POA&M entry includes the weakness description, remediation tasks, milestones, responsible personnel, needed resources or cost estimates, and target completion dates. DHS also requires root cause analysis and criticality assessment. That is good practice because it separates symptom from cause.

Eric Marquette

Give me an assessor-style example.

Paul Netopski

Sure. If an assessment finds unsupported software on engineering workstations, a weak POA&M says, “Upgrade software by Q4.” A stronger POA&M says: weakness identified through assessment or scan; root cause is ineffective software lifecycle tracking; milestone one, identify affected assets; milestone two, test replacement version; milestone three, deploy; milestone four, validate removal of unsupported instances; assigned owner; target dates; and evidence required for closure. That is actionable.

Roz the Rulemaker

And it creates accountability because delay now has to be explained. DHS guidance is explicit that delays, cancellations, waivers, and accepted risks require justification and artifacts.

Paul Netopski

Right. POA&Ms support risk management by forcing prioritization. DHS uses criticality aligned to risk factors, and high-criticality weaknesses are remediated faster, especially for internet-facing systems. Even if your environment is not DHS, the principle holds: not all gaps are equal. Your POA&M should show how you prioritize by risk, not by convenience.

Eric Marquette

And closure is not just, “We think it’s fixed.”

Paul Netopski

Correct. NIST 800-37 says assessment findings feed remediation, reassessment, updated plans, and authorization decisions. DHS says closure requires validation of remediation evidence. So assessors will look for proof: scan results, configuration screenshots, ticket records, approved change evidence, retest results. If the gap was control effectiveness, they will want evidence the control now operates as intended.

Roz the Rulemaker

There is also the residual risk piece. Some deficiencies are mitigated, some are accepted. But accepted risk is not a shrug. In the sources, risk acceptance is formal and documented.

Paul Netopski

Exactly. A POA&M is used alongside assessment findings, not instead of them. The assessment report identifies the deficiency. The POA&M shows what you will do about it. Then validation evidence shows whether you actually did it. If remediation is deferred, the record should explain why, what the interim posture is, and who accepted that risk. That is what mature programs do, and that is what assessors are looking for.

Paul Netopski

The third document — or really, the third process — is continuous monitoring. This is what proves the SSP stays true over time and the POA&M stays alive until issues are actually resolved.

Eric Marquette

So this is where compliance stops being a snapshot and becomes a system.

Paul Netopski

That’s a good way to put it. NIST SP 800-137 defines information security continuous monitoring as maintaining ongoing awareness of information security, vulnerabilities, and threats to support organizational risk management decisions. NIST 800-37 monitor step says organizations assess control effectiveness, document changes to the system and environment, conduct risk assessments and impact analyses, and report the security posture on an ongoing basis.

Roz the Rulemaker

And notably, both documents treat monitoring as structured governance, not casual observation. Strategy first, then program, then implementation, then analysis, response, and review.

Paul Netopski

Exactly. A CONMON program should define what you monitor, how often, how results are analyzed, who receives reports, and what responses are triggered. NIST 800-137 is specific here: the strategy should be grounded in risk tolerance, include meaningful metrics, ensure continued effectiveness of controls, verify compliance with requirements, maintain visibility into assets, ensure knowledge of changes, and maintain awareness of threats and vulnerabilities.

Eric Marquette

So what do assessors expect to actually see?

Paul Netopski

They are looking for defined monitoring frequencies, evidence those activities occur, and evidence the outputs feed decisions. For example: vulnerability scanning schedules, review of component inventories, configuration checks, audit log review, incident monitoring, patch and flaw remediation status, and periodic reassessment of controls. NIST 800-137 says organizations establish metrics and frequencies based on factors like control volatility, impact level, threat information, vulnerabilities, risk assessment results, weaknesses, and reporting requirements.

Roz the Rulemaker

Which means “we monitor continuously” is not enough. You need to show the cadence and the criteria.

Paul Netopski

That’s right. And in RMF terms, monitoring outputs trigger ongoing risk response. Updated assessment reports, updated plans of action and milestones, updated plans. That linkage is critical. If continuous monitoring identifies a new weakness, the POA&M should be updated. If architecture changes, the SSP should be updated. NIST 800-37 is explicit that those risk management documents get updated based on monitoring activities.

Eric Marquette

So the three documents really do form a loop.

Paul Netopski

They do. The SSP tells the story. The POA&M tracks the gaps in that story. Continuous monitoring proves whether the story remains accurate and whether the gaps are shrinking. And for CMMC CA.L2-3.12.1 and 3.12.3, that matters because you must define assessment frequency, assess with that frequency, and monitor controls on an ongoing basis.

Roz the Rulemaker

I’ll add one procedural point. A monitoring program should also define how findings are reported upward. NIST 800-137 emphasizes reporting to support decisions across organizational tiers. If the information never reaches decision-makers, the program is not functioning as intended.

Paul Netopski

Well said. And one final practical note: automation helps, but it does not replace judgment. NIST 800-37 and 800-137 both encourage automation where possible, especially for assessment and monitoring, but they also acknowledge some monitoring cannot be automated. So the standard is not flashy tooling. The standard is reliable awareness and documented response.

Eric Marquette

That feels like the perfect takeaway. Build the SSP so assessors can understand the environment, keep the POA&M honest, and make CONMON the process that keeps both of them current.

Roz the Rulemaker

A tidy administrative summary, which is my favorite kind.

Paul Netopski

[calmly] And a practical one. Thanks, Eric. Thanks, Roz. We’ll keep unpacking CMMC evidence with an assessor’s lens next time. Goodbye, gentlemen.

Eric Marquette

Goodbye, Paul. Goodbye, Roz.

Roz the Rulemaker

Goodbye, Paul. Goodbye, Eric.