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. And that’s the thing people miss, right? They treat the SSP like a form to fill out instead of the foundation document. 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. 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. 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. So if I’m a contractor and my SSP says, “We use Microsoft 365 and laptops,” that’s not gonna cut it. 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. 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. 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. So this is where the SSP tells the story. 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. And if the document says “implemented” but the evidence shows “planned,” that is not merely a drafting problem. It is a credibility problem. 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. 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. Yeah, like, the existence of a POA&M can actually show maturity if it’s managed well. 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. 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. 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. Give me an assessor-style example. 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. 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. 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. And closure is not just, “We think it’s fixed.” 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. 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. 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. 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. So this is where compliance stops being a snapshot and becomes a system. 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. And notably, both documents treat monitoring as structured governance, not casual observation. Strategy first, then program, then implementation, then analysis, response, and review. 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. So what do assessors expect to actually see? 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. Which means “we monitor continuously” is not enough. You need to show the cadence and the criteria. 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. So the three documents really do form a loop. 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. 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. 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. 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. A tidy administrative summary, which is my favorite kind. [calmly] And a practical one. Thanks, Eric. Thanks, Roz. We’ll keep unpacking CMMC evidence with an assessor’s lens next time. Goodbye, gentlemen. Goodbye, Paul. Goodbye, Roz. Goodbye, Paul. Goodbye, Eric.
Audio Coursesby Jellypod