The questions worth asking an MSP before you sign, and what a red flag answer actually sounds like.
TL;DR: Nobody tells you this part when you're shopping for an MSP, but whoever gets the keys to your GCC High tenant is now part of your compliance picture, for better or worse. We've got some pointed questions you should be asking before you sign anything, the kind that separate a provider who's actually built for this from one just saying the right words. Ask them, and listen closely to how they answer.
Picking an IT provider usually comes down to the basics, like whether they answer the phone, whether they're priced fairly, whether they actually show up when something's broken. But if you're a defense subcontractor handling controlled unclassified information, there's a layer underneath all of that nobody brings up in the sales pitch. Your provider's own habits and setup become part of your compliance picture the second they touch a system holding that data, whether that ever gets spelled out in the contract or not.
It's a little like handing someone a key to your house so they can let the dog out while you're gone. Most of us don't think twice past "can I trust this person." We don't ask whether they're actually going to lock the door behind them, whether they're the one showing up every time or someone they know is covering for them, or whether that key's going to end up copied and handed around without us ever hearing about it. Your MSP relationship works the same way, except the thing behind the door isn't your living room; it's data that the federal government has specific rules about protecting.
Prime contractors and federal auditors have gotten a lot more pointed lately about asking who else has their hands in a subcontractor's environment. You can lock your own systems down tight and still get flagged because the MSP running your help desk was routing tickets through an offshore team or logging in with remote access tools that wouldn't survive a second look. None of that has to be your mistake to become your problem.
And it's not just an isolated thing happening to a few unlucky companies. Compliance obligations across defense contracting are increasingly following the data itself, not just sitting with whoever originally collected it. Anyone who gets a hand in that data, your IT provider included, picks up a piece of the responsibility for protecting it too.
Let's go through the specific questions worth asking before you hand an MSP the keys to your GCC High tenant or enclave, and what it actually sounds like when their answer should give you pause.
Most people think of DFARS and NIST SP 800-171 as rules about your company. They're actually rules about your data, and that's a bigger circle than people realize. Any outside vendor with access to a system that touches CUI gets pulled into that circle right along with you, whether it's your MSP, a backup and recovery service, a document management platform, or a consultant who logs in every so often to check your setup. If they can see it, they're part of the picture.
Your MSP usually ends up carrying the most weight in that picture, and it's not hard to see why. A backup vendor might touch your environment once a month. Your MSP is in there constantly, handling support, patching, monitoring, all the stuff that keeps the lights on. If their technicians can get into a system holding CUI as part of that routine work, their staffing choices, the tools they use, and how seriously they take their own security become part of your compliance story. Doesn't matter if that's written into your service agreement or not.
That GCC High tenant we keep mentioning, by the way, is exactly what we broke down in the first post of this series, if you want the full picture of what it actually is before you keep reading. And that's exactly why "we do government cloud" shouldn't be enough to take at face value. A lot of providers can get a GCC High tenant up and running. Fewer of them have actually built the habits that keep it compliant six months later, U.S.-only staffing, remote access tools that would hold up to scrutiny, an honest acknowledgment of what they're on the hook for. That's the part that separates talk from a provider who's actually built for this.
There are four questions worth asking straight out, before you sign anything, no matter how good the sales pitch sounds.
First, will your support calls ever land with technicians overseas? You want a flat no here; it has to be a team made up entirely of screened folks working on U.S. soil. If you hear anything about a "global follow-the-sun helpdesk," that's a nice way of describing exactly the setup that conflicts with the personnel screening CMMC assumes you've got in place.
Second, is their own infrastructure actually built to CMMC Level 2 standards? You're looking for a direct yes here, specifically about the tools and the remote monitoring platform they use to get into your systems, since those tools are what's actually touching your environment day to day. "We don't hold CUI on our own servers, so this doesn't really apply to us" sounds reasonable until you realize it answers a completely different question than the one you asked.
Third, will they put a written acknowledgment of your compliance obligations in front of you to sign? You want a yes, something that spells out DFARS and CMMC obligations specific to the work they're doing for you. If what you get back is "we just use our standard service agreement for everyone," take that as a sign they haven't thought through what your contract actually requires of them.
Fourth, how do their technicians get into your tenant in the first place? This is the same access question that matters just as much during an actual migration, which we covered in detail in our post on GCC High migration timelines. The answer you're hoping for involves dedicated jump boxes, multi-factor authentication, U.S.-based access, and full session logging, not the same remote desktop tool they use for every client, regardless of what kind of data is on the other end.
Here's the tricky part about red flag answers: they usually sound pretty reasonable on the surface. "We run a follow-the-sun helpdesk" sounds like a selling point in almost any other conversation about IT support. Coverage around the clock, somebody always awake to help you. In this specific context, it's a direct problem, since it usually means technicians outside the U.S. touching your environment.
“We don't hold CUI on our own servers" is the same kind of trap, and it's worth understanding why once you know the real difference between GCC and GCC High, which we walked through earlier in this series. It sounds like a clean, honest answer, and maybe it even is true. But it dodges the actual question, which was never about where their data lives. It was about whether their access into your systems meets the same bar your systems are held to.
This is exactly why these four questions need to get asked directly, one at a time, instead of accepting a general "oh yeah, we work with compliance clients all the time" as good enough. That kind of answer feels reassuring in the moment, but it tells you nothing specific about staffing, tooling, or whether they've actually thought through what your contract requires of them. Vague confidence isn't the same thing as a real answer.
Here's something we see a lot: a provider sounds great on the phone, says all the right things, and none of it ever makes it onto paper. A verbal assurance during a sales call doesn't hold up if a prime contractor or an auditor ever starts asking pointed questions about who's touching your environment. Any MSP that's actually built for this work puts their DFARS and CMMC-related commitments in writing, specific to what they're doing for you, not buried somewhere in a generic terms-of-service document nobody reads past the first paragraph.
Whether your setup is a full GCC High migration or a smaller enclave built around just the systems that touch CUI, the kind we broke down in our post on CMMC enclaves, your MSP's documented commitments need to match what they're actually responsible for touching. A written commitment that's vague about scope doesn't help you much more than no commitment at all.
There's a practical reason this matters beyond having something to point to later. If your MSP is part of your compliance scope, and if they're touching CUI, they are, having their commitments documented makes your own NIST SP 800-171 self-assessment a lot easier to fill out accurately. You're working from an actual paper trail instead of trying to remember what got promised on a call six months back.
A provider who hesitates here, or tries to talk you into just trusting the relationship, is telling you something. The ones who've actually built their operations around this work don't flinch at putting it on paper. It's usually the ones who haven't done the work who'd rather you just take their word for it.
Something to keep in mind, CMMC Phase II certification requirements are suspended right now, but nobody hit pause on the self-assessment deadlines. Level 1 is still due by March 1, 2026, and Level 2 follows by March 1, 2027, under current Department of War guidance. That clock is running whether or not you've sorted out your MSP relationship yet, and you really don't want to be filling out that assessment while still guessing at how your IT provider actually accesses your systems.
We've touched on how GCC High, enclaves, and migration timelines all feed into this same self-assessment obligation throughout this series, and the part people tend to forget about is cost, which we broke down in our post on GCC High pricing. Rushing through MSP vetting doesn't just risk picking a provider who's slow to answer the phone. It risks turning in a self-assessment that doesn't hold up, and that's a much more expensive mistake to walk back later.
If your MSP can't give you a straight answer to the four questions we just went through, that's not a small thing to shrug off. That's a real gap standing between you and a self-assessment you can actually stand behind when a prime contractor comes asking.
We've covered a lot of ground across this series, GCC High, enclaves, pricing, migration timelines, and now the one piece that actually runs all of it day to day: the vendor you hand the keys to. This post walked through the four questions worth asking any MSP before you sign, what it sounds like when their answer should give you pause, and why getting their commitments in writing beats taking their word for it. None of this is complicated once you know what to listen for. It just takes actually asking the questions instead of nodding along.
None of that infrastructure or budget planning means much if the provider running your environment hasn't taken their own role in your compliance picture seriously. You can do everything right on your end and still end up exposed because the MSP you hired cut corners on staffing or tooling, and you usually don't find out until an audit or an incident forces the question.
Succurri has built its own operations around U.S.-based staffing, compliant tooling, and a willingness to put our obligations in writing, not because every client needs that level of scrutiny, but because the ones we work with do. When we take on a defense subcontractor's GCC High or enclave environment, that same scrutiny gets applied to how we run it ourselves, not just how we configure it on day one.
Have a conversation with Succurri before you sign with any MSP touching your GCC High or enclave environment. It's a lot easier to ask these questions now than to answer for them later.
1. Does my MSP really need to be CMMC compliant if they don't store our CUI?
If their technicians can access systems that store, process, or transmit your CUI, their access is part of your compliance boundary regardless of where their own data lives. "We don't hold CUI on our servers" answers a different question than the one that matters.
2. What's the biggest red flag when vetting an MSP for GCC High support?
A support model that routes technical staff offshore, or a refusal to sign anything beyond a standard commercial service agreement. Both tell you the provider hasn't built their operations around what your environment actually requires.
3. Should I get my MSP's compliance commitments in writing?
Yes. A written acknowledgment of DFARS and CMMC-related obligations, specific to the services they provide you, protects you during an audit and makes your own self-assessment easier to complete accurately.