Welcome to the show! Paul Netopski, I want to start with the sentence that either saves an assessment or sinks it: "Our SSP says MFA is implemented" -- and then the assessor asks, "Where, exactly?" [matter-of-fact] Right. And "where, exactly" is the whole game. An SSP is not a shelf document, and it is definitely not marketing copy. It has to show the CURRENT status of each control and point an assessor to the evidence trail with enough precision that they can follow it without guesswork. The phrase I always use is "administrable truth." If your document says a control is met, partially met, or not yet fully implemented, that status has to line up with the rest of the record. Not in spirit -- in the actual paperwork, procedures, screenshots, plans, and operational practice. That "met, partially met, not yet" framing -- that's straight out of the pain from "POA&Ms: What Gaps Really Mean," right? Because a gap isn't fatal, but pretending there isn't one... that's fatal. Exactly. In "POA&Ms: What Gaps Really Mean," the lesson was simple: a POA&M is for a real, bounded gap. Your SSP has to tell the truth first. And that connects directly to our earlier episode, "The System Security Plan That Tells the Truth." If the SSP says a control is implemented, the assessor should be able to trace that claim to supporting artifacts fast. So let's make that practical. When you say "trace that claim," what does a good breadcrumb actually look like? A good breadcrumb names the supporting source and the exact location. Not just "see policy." Say: Access Control Policy, section 2.3; Incident Response Procedure, section 4.1; Backup Plan, appendix B; ticket workflow in the service desk process, section 5. If you're using a tool, say that too: centralized identity provider for MFA, EDR platform for endpoint monitoring, SIEM for log review, MDM for mobile enforcement. Assessors want to understand not just intention, but IMPLEMENTATION. And "section 2.3" matters. That little token -- 2.3, appendix B -- saves hours. An assessor should not have to hunt through a 40-page policy to find one sentence that supports one control. If they have to excavate, your document is underperforming. "If they have to excavate" -- that's gonna stick with me. So the SSP is basically a map, not a manifesto. That's a good way to put it. A map with status, references, and mechanisms. For every control, I want three things clearly visible. One: current state -- implemented, partially implemented, whatever is accurate. Two: supporting documents and exact locations. Three: the technical or procedural mechanism used to meet the requirement. If log review happens in a SIEM, say SIEM. If account reviews happen through your IAM platform plus a monthly review process, say both. Let me try to play this back -- slightly dangerously. If I write, "We review logs regularly per policy," that's too vague. But if I write, "Logs from servers and endpoints are aggregated in the SIEM; analysts review alerts daily under Monitoring Procedure section 3.2; weekly trend review documented in appendix B," now an assessor can follow the chain. Almost. The part I'd tighten is status and scope. Say whether that's fully operational now, and which systems it covers. That's the difference between a generic statement and an assessment-ready one. And that is why "The System Security Plan That Tells the Truth" is such a useful title. The truth is not just yes or no. The truth is: this control is implemented here, through these mechanisms, evidenced by these materials, at these exact locations. Okay, the phrase you just used -- "implemented here" -- that's where scoping gets real. Because under the CMMC Scoping Guide, "here" does not mean the same thing for every asset. [authoritative] Correct. Implementation can differ by asset type, and your SSP should reflect that reality. CUI assets, security protection assets, contract information systems, and external services do not always get described the same way. If your SSP flattens all of that into one generic paragraph, you've made the environment harder to assess and harder to defend. The term "flattens" is important. A control may apply directly to a CUI asset, indirectly through a security protection asset, differently to a contract information system, and partially through an external service. One control, multiple implementation stories. "Multiple implementation stories" -- that is the sentence. So, Paul Netopski, what should the SSP actually say when those stories diverge? It should say how the control is applied for each relevant asset type in scope. If MFA is enforced on CUI assets through the identity provider, say that. If a security protection asset like a log collector or boundary device supports the control in a different way, explain that. If a contract information system is in scope under the scoping guide but does not process CUI the same way, note the distinction. And for external services, identify what is inherited versus what remains your responsibility. That inherited-versus-your-responsibility split -- that's where people get fuzzy fast. They do. And fuzziness is dangerous. If you rely on an external service provider, your SSP should reference the documentation that proves the inheritance model and the exact scope it covers. That could be a Shared Responsibilities Matrix, FedRAMP Appendix J, or similar provider materials. Not just "cloud provider handles it." Which controls? Full inheritance or partial inheritance? For which service boundary? "Cloud provider handles it" is the regulatory version of "the check is in the mail." It tells you almost nothing. A Shared Responsibilities Matrix is useful because it allocates duties line by line. FedRAMP Appendix J serves a similar function in showing who does what, and where the boundary actually is. And that boundary word -- BOUNDARY -- is the thing listeners should underline, right? Because inheritance outside the actual subscribed service or configured scope may not exist at all. Exactly right. Inheritance is not a vibe. It's bounded. Your SSP should identify the external service, the covered function, the supporting inheritance documentation, and what your organization still must do. Configuration, user management, review, incident handling coordination -- whatever remains on your side needs to be visible. This is where the best SSP starts to feel less like a document and more like a guided tour for the assessor. [calm] Yes. The best SSP makes the assessor's job easier by connecting controls, scope, tools, and inheritance in one coherent narrative. That's really the throughline from "The System Security Plan That Tells the Truth" and "POA&Ms: What Gaps Really Mean." Tell the truth about status. Show the breadcrumbs. Explain the mechanism. Clarify the scope. Document what you inherit and what you own. And if you do that well, something subtle happens: the assessment stops being a scavenger hunt. It becomes a verification exercise. That's a very different posture. A scavenger hunt versus a verification exercise... yeah, that's the difference between "please trust us" and "here, you can see it." Thanks, Paul Netopski. Thanks, Roz the Rulemaker. And if your SSP still reads like a promise instead of a proof trail, maybe that's the place to start.
Audio Coursesby Jellypod