Unpacking MSSP Challenges in CMMC Environments

Eric Marquette

Alright everyone, welcome back to “CMMC Unlocked: Inside the Cybersecurity Maturity Model.” I’m Eric Marquette, joined as always by Ruby Sturt, Paul Netopski, and Roz the Rulemaker. Today we’re unpacking one of those trickier minefields—how the use of an MSSP’s SOC and SIEM changes your CMMC scope, especially with all the asset categories flying around. Paul, I know you’ve run into plenty of real-world tangles here—for folks newer to this, could you talk us through when an MSSP’s security tools actually end up in an organization’s assessment?

Paul Netopski

Absolutely, Eric. This is one of those spots where the scoping guides—Level 2 and 3—spell things out if you know how to decode them. Basically, a Managed Security Service Provider’s SOC or SIEM usually gets swept into scope if it provides what the guides call Security Protection Assets, or if it processes CUI or Security Protection Data. Back when I was at Draper, we worked with a SOC handling centralized logging. That meant the SIEM, the SOC staff, their processes—those were all documented in the asset inventory, covered in the SSP, mapped in the network diagram. Every one of those details matters because any asset handing log data, configuration files, or admin credentials that touch CUI, or defend systems that process CUI, is almost certainly in-scope.

Ruby Sturt

And that “out-of-scope creep” is real! I remember getting tripped up with it early on—like, you think you’ve got a nice tidy boundary, and suddenly, “oh no, our SOC staff manage patch rollouts for our workstations too, and bam, they’re pulled in.” It’s a nightmare for asset inventories if you’re not documenting things tightly.

Roz the Rulemaker

That’s right, Ruby. From a regulatory perspective, what really counts is whether the MSSP’s systems or people provide security functions for your CUI environment or interact with Security Protection Data. If so, they’re Security Protection Assets, plain and simple. Table 2 of the scoping guides lays that out very directly. So your documentation—asset inventory, SSP, network diagrams—all have to reflect those relationships with enough clarity that the assessor can follow your logic and, crucially, your boundaries. Let’s not forget: poorly defined boundaries are one of the top findings in DIBCAC’s recent assessments.

Paul Netopski

Exactly, Roz. The trick is drawing those boundaries. If, say, the MSSP just advises or augments your in-house team, you might avoid in-scope status for their infrastructure, but the second CUI or SPD touches their platform, you’re documenting everything from personnel with privileged access to how their SOC interfaces with your own network. Ultimately, whether the MSSP or your own team “owns” key security controls—and how that’s split—needs to show up in detail in the SSP and those network diagrams as part of the overall CMMC assessment scope.

Eric Marquette

So, to sum it up: meticulous scoping depends on knowing exactly how MSSP resources plug into your environment, classifying those assets properly, and drawing a line—on both your docs and your network diagram—that an assessor can follow. It sounds simple until you realize how easily those lines blur.

Ruby Sturt

Yeah, and it gets even more gnarly when you toss CUI into the SIEM logs. Like, suddenly your logs themselves are CUI assets? For folks still wrapping their heads around this—Paul, how does having CUI in aggregated log data affect the scope? And—oh, and this always makes me scratch my head—how do we really know if an MSSP is any different from a CSP here? Is it all FedRAMP and acronyms, or what?

Roz the Rulemaker

Good questions, Ruby. Parsing the distinction between an MSSP and a Cloud Service Provider is fundamental. The regulatory line is this: a Cloud Service Provider delivers scalable, on-demand computing resources—think infrastructure, platforms, or software as a service. If your SIEM or SOAR is run as a multi-tenant cloud service and you, the client, can rapidly scale or configure your own environment, that’s a CSP, and FedRAMP Moderate authorization applies when CUI is present. With an MSSP, you’re typically buying a managed service—often their staff operate systems on your behalf, but there may not be rapid provisioning or self-service in play. For CMMC, whether it’s an MSSP or a CSP, if they process, store, or transmit your organization’s CUI or security protection data, their system becomes subject to your assessment scope. The precise regulatory expectations hinge on what data lives where, and who really controls it.

Paul Netopski

And the location of the data’s a huge deal. I ran into this earlier with a defense subcontractor using a SOAR solution managed by an MSSP. The SOAR itself had privileged access—meaning it could sweep across the entire network, touch log data, trigger IR playbooks with CUI in the payloads. We had to clarify: which party held responsibility for data retention, incident records, and credential security? The key is that CUI in log files turns those logs into CUI assets, no matter whose system stores them. The organization and the MSSP both needed crystal-clear procedures and role delineations, all documented in the CRM and SSP.

Ruby Sturt

Honestly, it still feels like a potato-sack race—constantly tripping over who’s holding responsibility at different moments! And those role splits really come into the spotlight during assessments, especially when the assessor’s questioning “show me who has the audit logs, where are the keys, and who touches them in a response event.”

Eric Marquette

And that goes back to making sure your documentation is up to snuff. I mean, this is something we’ve touched on in previous episodes: documentation saves headaches later—especially for tracking who holds which responsibilities for IR data or managing privileged credentials across those external services.

Roz the Rulemaker

Precisely, Eric. The Customer Responsibility Matrix is your best friend here. It needs to map out, in granular detail, those handoff points—whether that’s incident response, log storage, or credential management—for every party involved. And from a regulator’s standpoint, having a CRM that’s vague or ambiguous is a sure-fire way to wind up with assessment findings requiring remediation.

Eric Marquette

Let’s get real for a minute about SOAR platforms, privileged access, and automation. It’s kind of a double-edged sword, right? On one hand, automation should reduce manual error and respond faster. On the other—especially when an MSSP is driving those automations—you can end up with a real mess if boundaries and access aren’t crystal clear. I actually had this experience during a gap analysis for a manufacturer, where the MSSP’s supposed responsibilities versus what the client was actually doing—well, let’s just say it derailed closing out POA&Ms for both Level 2 and Level 3 compliance.

Paul Netopski

That’s unfortunately way too common, Eric. When you grant an MSSP privileged access—think admin credentials or wide-reaching API hooks for SOAR—that MSSP can inadvertently wind up in scope not just for their SIEM platform, but for everything their automations touch. It’s a scoping headache, sure, but it’s also a data exposure risk. If the boundaries aren’t airtight in your network diagrams and SSP, you can trigger inheriting—or worse, sharing—security requirements across your entire assessment boundary.

Ruby Sturt

That’s wild. So “trust but document”—with, like, a microscope. For orgs stuck in this spot, what have you seen work? Like, is it all about segmentation, or can slapping an SLA on the problem work?

Paul Netopski

Great question. In my experience, it’s a mix—segmentation definitely helps, especially if you use firewalls or VDI to carve up the environment so the MSSP’s access is tightly limited. But you’ve got to pair that with rigorously drafted SLAs and, most importantly, a super granular CRM. Those matrices should leave no doubt who’s responsible for what, especially around privileged automations. Otherwise, your POA&Ms might pile up faster than you can close them.

Roz the Rulemaker

Let’s add that from a policy and assessment standpoint, the MSP or MSSP’s involvement must be reflected in everything from incident response planning to privileged access reviews. I’d recommend the CRM and SSP call out not just who does what, but also what monitoring, audit logging, and key management practices apply. Assessors will specifically look for this documentation, particularly in environments where automation blurs the lines of responsibility.

Eric Marquette

So there’s no easy button—just layers of segmentation, allocation of responsibilities, and documentation tight enough that nothing slips by, even with robots running some of the show.

Roz the Rulemaker

Building on that risk of blurred lines—let’s get into continuous monitoring and incident response. The crux here is delineation of accountability. You want everyone involved, from your team to your MSSP, to know their precise roles—or you end up with duplicative efforts or, worse, something falling through the cracks.

Paul Netopski

Exactly, Roz. You define who is on the hook for what. Continuous monitoring isn’t just a box to tick; it’s about making sure you don’t have overlap, or even worse, gaps where threats can sneak through. For organizations working with an MSSP, this means clearly articulating—maybe in your SSP or a procedural appendix—who’s handling the SIEM’s alerts, who’s triaging those alerts, and who’s authorized to escalate responses. Automation makes this even trickier because alerts might be generated by the SOAR tool, but someone still needs to review and act on them.

Ruby Sturt

And it’s one of the easiest places for confusion—like, you think the MSSP is watching that midnight alert, but it’s just been sitting there. That classic “whose job was this anyway?” vibe. Automated alerts and audit logs are brilliant but only if the follow-through is baked into incident response playbooks and escalations—and updated regularly as roles change.

Eric Marquette

Yeah, and looping back to earlier episodes—we talked about continuous compliance not just as a process but a living thing, right? Audit trails, alerting, playbooks—they should evolve as the mix of tools and providers changes, especially every time your MSSP relationship shifts or you add new automations into the workflow.

Roz the Rulemaker

That’s right. From a best practices point of view, I’d suggest orgs define, test, and document all communication protocols for incident detection, response, and escalation involving MSSPs. Not just what’s on paper, but making sure the steps—what we call procedural “muscle memory”—are verified in table-top or live-fire exercises. Compliance here isn’t about just having plans, but ensuring those plans are actionable, clear, and updated along with technology or contract changes.

Eric Marquette

All of this brings us to the part folks dread—actually ensuring compliance and accountability when working with an MSSP. SLAs seem like a silver bullet, but reality’s messier, right?

Paul Netopski

Very much so. SLAs are essential, but if they just state “the MSSP will keep us secure,” that’s as good as useless. You really need specificity: which compliance requirements does the MSSP own—what about incident response timelines, what CUI or security protection data they handle, who needs to be notified for which events? And you can’t “set and forget.” Regular compliance audits of the MSSP’s controls, procedures, and tools are a must. Sometimes, an MSSP’s controls will drift, or their understanding of a customer’s security needs will evolve. It’s on you to verify, not assume.

Ruby Sturt

Oh, and don’t get comfy—auditing has to be a routine, not a one-off. Even the slickest MSSPs can have blind spots, especially with fast-changing requirements. Documentation and reporting are your lifeline here. If it’s not written down—incident logs, changes in CRM, system changes, who did what—it basically never happened for compliance or assessment purposes.

Roz the Rulemaker

Exactly, Ruby. When DIBCAC reviews an environment, they want an evidence trail—logs, reports, updated SLAs, CRMs, and SSPs. If you can’t produce a comprehensive documentation set that reflects not just your technology but your MSSP’s practices, you’re unlikely to pass a CMMC assessment smoothly. And from a regulatory policy lens, this is about defensibility and transparency.

Eric Marquette

So, as we’re winding down today’s chat—maybe the takeaway is: there’s no shortcut. Getting MSSP relationships right under CMMC is all about boundaries, granularity, lived documentation, and relentless verification. And if you treat your CRM, SSP, and audit logs as living documents, not dusty checklists, you’re ahead of most.

Paul Netopski

Couldn’t agree more, Eric. And for anyone prepping for a CMMC assessment, start with holding your MSSP to the same rigor you want for your own team—because the assessor definitely will.

Ruby Sturt

I’ll just say—don’t wait for the panic button to get pressed, yeah? Build those relationships, review your docs, and chase the accountability before the auditors do.

Roz the Rulemaker

Well said, Ruby. Thanks to all our listeners for joining us as we dig deeper into these CMMC complexities. Remember, each episode adds another piece to the compliance puzzle—so stick with us for future insights and updates as the rules keep changing. Cheers, everyone.

Eric Marquette

Thanks for listening, Roz, Paul, Ruby—always a pleasure. Until next time, keep your boundaries clear and your logging even clearer.

Ruby Sturt

See ya next round—don’t let your SIEM eat your lunch!

Paul Netopski

Take care, everyone—good luck with your audits!

Roz the Rulemaker

Goodbye, folks—stay diligent and document everything!