Mastering the Maintenance "MA" Family for CMMC Level 2

Eric Marquette

Alright, welcome back to CMMC Unlocked! I’m Eric Marquette, here with Paul Netopski and Roz the Rulemaker, and today we’re diving into the Maintenance family—yep, that’s the “MA” controls at CMMC Level 2. Now, this isn’t the flashiest family in the model, but I gotta say, it’s one of the trickiest for organizations to really get right. Paul, I always think of that time we worked with the small defense contractor who had no idea—literally none—where half their USB sticks used for diagnostics had gone, remember? That kicked off a whole compliance audit for them.

Paul Netopski

Absolutely. And Eric, that’s spot on. The CMMC MA family is about much more than just “doing maintenance.” It covers six distinct controls: routine maintenance (MA.L2-3.7.1), controlling the who, what, and how—meaning tools, techniques, mechanisms, and personnel (that’s MA.L2-3.7.2), sanitizing equipment before it leaves your space (3.7.3), scanning any diagnostic media for malicious code before plugging it in (3.7.4), multifactor authentication for remote maintenance and making sure you terminate those sessions when done (3.7.5), and then supervision—so if someone doesn’t have the right clearance, you’ve gotta directly oversee them (3.7.6).

Roz the Rulemaker

From a regulatory side, what’s significant is that these objectives really focus on traceability and control. When you break them down, they all circle back to one point: can you prove, at any given time, who performed what maintenance, with what tools and under what authorization level, especially if you get surprise audited? And the pitfalls I see, Eric, are absolutely things like lost removable media—but also things like vague policies for vetting maintenance staff. Some organizations just assume the vendor “must already be vetted,” which usually isn’t enough.

Eric Marquette

Yeah and with the removable media, that contractor I mentioned, they just tossed flash drives in a desk. No log, no chain of custody, nothing. When auditors showed up asking to see documentation for every piece used during system diagnostics… whew, panic city. That’s the kind of simple but costly oversight we’re talking about today.

Paul Netopski

Exactly. And sometimes, the challenge isn’t a technical one. It’s about process, oversight, and records—disciplines that a lot of organizations underestimate for something as routine as “maintenance.”

Roz the Rulemaker

That’s why when you look at the assessment objectives, they’re pretty explicit. You’ve got to control your tools, control your personnel, you must sanitize equipment that leaves your organization. And—this is a big one for the legal folks listening—if you’re audited or, worse, part of any legal action stemming from poor maintenance practice, lack of documentation is, frankly, indefensible.

Eric Marquette

Alright, so let’s shift a bit. Let’s talk about how organizations can actually put these MA controls into practice—not just on paper. I mean, I’ve seen some pretty wild “logging systems” out there, like a whiteboard in the server closet. Paul, when it comes to controlling maintenance tools and techniques, what are you actually seeing in the field that works?

Paul Netopski

Great question. The most effective approach I’ve seen is treating maintenance tools like sensitive assets—think check-in, check-out logs, even basic digital inventory solutions. For software tools, whitelisting and requiring signatures ensures that only approved diagnostic tools run on your systems. But it’s not just about the tools themselves. Personnel vetting—actually tracking who’s cleared to do which tasks, and who’s supervising—is a huge part. Enforcement here goes beyond a policy doc; it requires a demonstrable process.

Roz the Rulemaker

And from the legal and regulatory side: always, always document your processes. If you’re sanitized equipment before off-site maintenance, keep logs—who did it, when, and what media was wiped. If there’s diagnostic media or test programs, run malware scans and keep those scan reports. Sometimes organizations skip this because it feels like busywork, but it’s exactly the evidence needed during an assessment or—if it escalates—a legal discovery.

Eric Marquette

That’s something we’ve harped on in earlier episodes—document what you do, and do what you document. Even digital signatures on logs help, right?

Paul Netopski

Yes. And, building on that, let’s not forget how these maintenance controls intersect with other CMMC domains. Like, take MA.L2-3.7.5—the one about requiring multifactor authentication for remote maintenance. This links back to Identification and Authentication (IA) and Access Control (AC) families; you’re enforcing identity assurance as part of your layered defense. Policy hygiene in one family bolsters your compliance in others.

Roz the Rulemaker

Exactly, Paul. And don’t overlook Media Protection (MP) either—if you’re scanning diagnostic media for malware, that’s just as much about media control and protection as it is about maintenance protocol. The families build on each other, and audit trails for one often support requirements in another.

Eric Marquette

And I’ll just say, for anyone listening who’s thinking, “That sounds overwhelming”—it kind of is, at first! But most issues we see are from cutting corners. Start small, like making a habit to scan every thumb drive and storing logs centrally—not in someone’s email or on a sticky note. You get the hang of it, and it pays off every single time someone comes knocking for proof.

Eric Marquette

Now, here’s where things get extra spicy—outsourced maintenance. Whether it’s MSPs, MSSPs, or, these days, a cloud service provider, the lines get blurry pretty quick. Roz, can you help break down what organizations need to know about scoping and assessment boundaries here?

Roz the Rulemaker

Absolutely. So, let’s set out the landscape. If you’re using external service providers—whether that’s an MSP doing staff augmentation or an MSSP operating your SOC—your assessment scope must reflect those relationships. For Level 2, if that provider touches CUI or handles Security Protection Data, they’re in scope for your CMMC assessment, period. It’s less about what they call themselves and more about what they do. The same goes for Infrastructure as a Service: if CUI is processed or stored by the provider, that boundary belongs in your documentation and, crucially, in your SSP.

Paul Netopski

And one key point from the tech requirements—outsourced staff, especially if remote, are seen by assessors as equivalent to internal staff. If your MSP’s got admin passwords or stores security protection data offsite, you’d better have documented procedures for how that’s managed. Actually, I saw this very recently: MSP was holding SPD, hadn’t addressed it in the SSP, and—boom—extra scrutiny during the CMMC assessment. It’s all about linkage in the documentation: asset inventory, network diagram, SOPs, everything matching up.

Eric Marquette

Yeah, and something that isn’t always clear—MSPs aren’t automatically Cloud Service Providers. It depends on the technical relationship. Like, if you subscribe directly to a cloud service and the MSP just configures it, that’s one thing. But if the MSP owns the cloud environment and segments it out for you, different story—that’s CSP territory. It’s all about who owns the data, the infrastructure, and how access is managed. Gets complicated fast.

Roz the Rulemaker

And don’t forget the legal side—contracts with third parties must clearly spell out who’s responsible for maintenance, for security, for documentation. If responsibilities are vague—or worse, implied—it’s a compliance risk. I’ve worked on legal reviews where that simple omission led to weeks of audit back-and-forth. Crystal clear delegation is the only safe option.

Paul Netopski

That’s right. And for those dealing with specialty environments like VDI—or Virtual Desktop Infrastructure—make sure it’s configured so that CUI doesn’t accidentally spill out to endpoints. If you don’t prevent CUI processing outside the approved boundary, suddenly your “out-of-scope asset” isn’t so out of scope anymore.

Eric Marquette

So the takeaway is: Document, clarify, and—honestly—over-communicate with your providers. Map those boundaries and responsibilities in the SSP, and make sure your logs, assets, and network diagrams tell one clear story. That’s how you avoid surprises in an assessment—or, frankly, in a courtroom. Alright, that’s all we’ve got for today on mastering the CMMC MA family! Paul, Roz, thanks as always, and thanks to everyone listening—make sure to catch us next time as we dig into the realities of Virtual Desktop Infrastructure and CUI boundaries. Until then, stay secure and stay compliant!

Paul Netopski

Thanks, Eric. Great discussion, Roz. See you all next time.

Roz the Rulemaker

Thank you both, and thanks to our listeners. Keep those maintenance logs tight and your contracts tighter! Take care, everyone.