StealthTech
A defense contractor going through readiness prep almost always asks the same question at some point: does our IT company count as an “external service provider,” and if so, what does that actually obligate us to do? It’s a fair question, because the CMMC ecosystem uses the term loosely in conversation while the assessment methodology treats it with a lot more precision. Getting this wrong doesn’t just create paperwork gaps — it can sink an assessment before the assessor ever looks at a technical control, because scoping errors surface on day one of a compliance review.
What “External Service Provider” Actually Means Under CMMC
An external service provider, or ESP, is any external entity that provides services to a contractor’s organization involving the security or processing of information — including CUI — on the contractor’s behalf. That’s the working definition pulled from CMMC scoping guidance, and it’s broader than most contractors assume. It doesn’t just mean “the company that manages our servers.” It captures any third party whose people, systems, or processes touch the environment in-scope for the assessment, whether that touch is direct (an engineer logging into a server that stores CUI) or indirect (a security operations center watching alerts generated by that server).
The confusion usually starts because contractors mentally equate “ESP” with “our MSP.” That’s often true, but it’s not the whole picture. Cloud hosting providers, managed detection and response vendors, backup and disaster recovery services, VoIP providers, and even a bookkeeping firm with remote access into finance systems can all be ESPs depending on what they touch and how. The definition is functional, not categorical — it asks what the provider does, not what industry it’s in.
That functional framing is worth sitting with, because it’s the source of most confusion downstream. A provider can look low-risk from a general business standpoint and still be squarely in scope for CMMC purposes simply because of where its access sits relative to CUI. Conversely, a vendor that carries real cybersecurity risk in the abstract can sit entirely outside the assessment boundary because it never actually touches the relevant systems. Contractors who sort vendors by gut feel about “how sensitive” the relationship seems, rather than by where the access physically lands, are the ones who get surprised when an assessor asks about a provider nobody flagged in advance.
The ESP Definition Assessors Actually Use
Assessors don’t take a contractor’s word for who is or isn’t an ESP. They trace data flows and access paths documented in the System Security Plan and cross-reference them against the network diagram, the asset inventory, and the CUI flow diagram required under NIST SP 800-18. If a third party shows up anywhere in that trail — as a system administrator, a monitoring tool vendor, a help desk with remote access, or a cloud tenant administrator — that party gets evaluated against the ESP criteria regardless of what the contractor calls the relationship internally.
This matters because CMMC scoping guidance draws a hard line between an ESP that is “in scope” for the assessment and one that merely happens to interact with the business. A payroll processor that never touches the CUI environment isn’t an ESP for CMMC purposes even though it’s technically an external vendor. A remote monitoring and management tool with an agent installed on every endpoint in the CUI enclave is squarely in scope, even if nobody on the contractor’s team thinks of the MRM vendor as “our security provider.” The test is functional reach into the assessment boundary, not the vendor’s job title.
The practical implication is that contractors need an accurate, current asset inventory and network diagram before they can even answer the ESP question honestly. We routinely find that the diagram a client hands us during onboarding is a year or two out of date — a new SaaS tool got added, a legacy vendor’s access was never fully removed, a shadow IT subscription appeared because a department head needed something fast. Every one of those gaps is a potential ESP that never made it into the SSP, and every one of them is something a competent assessor will eventually find by tracing actual data flows rather than trusting the document on file.
Security Protection Assets vs. Everything Else an ESP Touches
Once a provider is confirmed as an ESP, the next question is what kind of ESP it is, and this is where the CMMC scoping guide gets specific. Two categories matter most in practice:
- CUI Service Providers — external parties that process, store, or transmit CUI on the contractor’s behalf, or that provide security functions for assets that do. An MSP hosting file shares containing CUI, or managing the firewall protecting a CUI enclave, falls here.
- Security Protection Asset providers — external parties that provide, operate, or manage a Security Protection Asset (SPA) such as a SIEM, EDR platform, or vulnerability scanning tool used to protect the CUI environment, even if the provider itself never directly handles CUI.
The distinction drives how much of the ESP’s own environment gets pulled into the assessment. A CUI service provider generally needs to demonstrate that its people, practices, and technology meet the same rigor as the contractor’s own controls for the overlapping scope. An SPA-only provider has a narrower obligation tied specifically to the asset it operates, but that obligation is still real — a poorly secured SIEM operated by a third party is still a documented finding waiting to happen. Contractors evaluating a cybersecurity partner should ask directly which category the relationship falls into before signing anything, because it changes what evidence gets requested later.
Why MSPs Almost Always Qualify as an ESP
Here’s the part most MSPs and their clients underestimate: it is extremely difficult for a full-service managed IT provider to avoid ESP status once a defense contractor client has CUI in scope. Patch management touches every endpoint. Remote monitoring and management tools have privileged access baked in by design. Help desk staff routinely need administrative rights to resolve tickets. Backup agents replicate data — including CUI, if the backup job isn’t carefully scoped — off the contractor’s network entirely.
This is exactly why the relationship between a contractor and its managed IT services provider needs to be treated as an assessment dependency, not a vendor convenience. An MSP that doesn’t understand its own ESP status will make scoping decisions — which endpoints get the RMM agent, which backup jobs pull from which file shares, whether a help desk ticketing system stores attachments containing CUI — without realizing those decisions directly shape the client’s assessment boundary. We’ve seen contractors walk into a mock assessment only to discover their MSP’s ticketing platform had been quietly storing screenshots of CUI-bearing screens for two years, because nobody had ever mapped that data flow.
The size of the MSP doesn’t change this calculus much. A boutique regional provider with a handful of technicians carries the same ESP obligations as a national managed security firm the moment its access touches the CUI boundary — the assessment doesn’t scale scrutiny down because the provider is small. What does change with provider size is usually maturity: larger firms are more likely to already have a documented shared responsibility framework, a CRA template, and staff familiar with CMMC vocabulary, while smaller regional shops sometimes need to build that documentation from scratch alongside their first defense industrial base client. Neither situation is disqualifying, but contractors evaluating a new provider should ask directly whether this is the vendor’s first CMMC-scoped engagement or their fifteenth.
The Documentation Burden: Shared Responsibility and the CRA
Once ESP status is established, the paperwork changes shape. The contractor’s System Security Plan has to describe, in enough detail for an assessor to follow, which controls the ESP is responsible for and which remain with the contractor. This shared responsibility matrix isn’t optional boilerplate — assessors will ask pointed questions about specific controls and expect a clear, defensible answer about who owns each one.
For CUI service providers specifically, there’s an additional expectation: the contractor needs some form of assurance that the ESP’s own practices meet the applicable requirements, whether that’s a signed attestation, a shared assessment, or in some cases a parallel CMMC certification if the ESP itself is pursuing one. The CyberAB marketplace lists organizations that have gone through this process voluntarily, and an increasing number of contractors are steering their vendor selection toward providers already listed there rather than building the assurance case from scratch.
This is also where a Customer Responsibility Matrix, or CRA, earns its keep. A CRA — typically produced by the ESP for cloud and platform services — spells out exactly which NIST SP 800-171 requirements the provider handles versus which remain the customer’s obligation. Without one, contractors default to assuming their cloud provider “handles security,” which is almost never entirely true and is the single most common gap we find during readiness assessments. A contractor relying on cloud transformation work with a provider that can’t produce a CRA is carrying risk it hasn’t quantified yet.
Contractors sometimes push back on this level of documentation, arguing that it feels excessive for a relationship that’s worked fine for years without a single incident. The response we give every time is that assessors aren’t evaluating whether the relationship has worked so far — they’re evaluating whether the contractor can demonstrate, on paper, that the division of responsibility was deliberate rather than assumed. A relationship that’s functioned well by accident looks identical, on paper, to one that’s never been tested, and an assessor has no way to distinguish the two without the documentation to back it up.
ESPs Handling CUI vs. ESPs Touching Only the Security Boundary
It’s worth separating two scenarios that get conflated constantly. The first is an ESP that has direct access to CUI — file storage, email, a document management system, a help desk that can view attachments. The second is an ESP that never touches CUI directly but secures the boundary around it — a managed firewall service, a SOC watching EDR telemetry, a vulnerability management vendor running authenticated scans against CUI assets.
Both are ESPs. Both get documented in the SSP. But the depth of scrutiny differs. A CUI-handling ESP effectively extends the assessment boundary into its own environment for the overlapping scope, meaning its personnel vetting, its own access controls, and its own incident response procedures become relevant evidence. A boundary-only ESP gets evaluated more narrowly — the assessor wants to know the SPA is properly configured, monitored, and maintained, and that the contractor retains oversight rather than treating the tool as a black box. Contractors who’ve been through a DFARS 252.204-7012 requirements review already know this distinction matters just as much for incident reporting obligations as it does for scoping — an incident touching an ESP-managed asset still triggers the contractor’s own reporting clock.
What Changes for Your MSP Relationship Once ESP Status Is Confirmed
Confirming ESP status isn’t a one-time checkbox — it reshapes the ongoing relationship in a few concrete ways. Contract language needs to explicitly address security responsibilities, breach notification timelines, and audit cooperation, not just uptime and response SLAs. Access needs to be documented and periodically reviewed, including a clear record of who at the MSP has standing privileged access versus who gets temporary elevated access for specific tickets. Change management on anything touching the CUI boundary — a new RMM policy, a firewall rule change, a backup job modification — needs a paper trail that an assessor can review months later.
This is also the point where contractors should ask whether their provider offers co-managed IT arrangements versus a fully outsourced model, because the shared responsibility split looks very different depending on which model is in place. A co-managed arrangement often keeps more control — and more documentation burden — with the contractor’s internal team, while a fully outsourced MSP relationship pushes more of that burden (and more of the assessment evidence) onto the provider. Neither model is inherently better for CMMC purposes, but the contract and the SSP both need to reflect whichever one is actually happening on the ground, not whichever one sounds better in a sales conversation.
Common Mistakes Contractors Make When Scoping Their ESP
The mistakes tend to repeat across engagements, and most of them come down to treating ESP evaluation as a compliance afterthought instead of an architectural decision made up front. A few show up constantly during readiness work.
Contractors frequently assume that because a provider is “just IT support” and not a dedicated cybersecurity firm, it doesn’t count as an ESP — a categorization error that has nothing to do with how CMMC actually defines the term. Others fail to separate their environment cleanly enough to limit which assets an ESP actually touches, so a vendor brought on for a narrow purpose — say, cloud-based VoIP — ends up with far broader network visibility than the engagement required, expanding the assessment boundary unnecessarily. Still others never ask their cloud or SaaS vendors for a CRA at all, discovering during the assessment itself that nobody can say definitively who’s responsible for a given control.
A subtler mistake involves data retention and disposal. An ESP that once had access to CUI — a former MSP, a decommissioned monitoring tool, a backup vendor whose contract ended — still represents residual risk if their access wasn’t fully revoked and their copies of the data weren’t accounted for. This ties directly into the kind of access control discipline covered in employee offboarding under CMMC, except applied to vendor relationships instead of employees. Assessors ask about vendor offboarding just as readily as they ask about staff offboarding, and “we switched providers two years ago” is not an acceptable answer if nobody can confirm the old provider’s access was actually terminated.
There’s also a tendency to under-scope the review of new tools an existing ESP introduces mid-contract. An MSP that adds a new remote access utility, swaps its ticketing platform, or rolls out a new patch management agent across the client base isn’t necessarily doing anything wrong — but if that change touches the CUI boundary and nobody updates the SSP or re-evaluates the shared responsibility matrix, the contractor is now out of sync with its own documented environment. The fix isn’t complicated: any material change to how an ESP delivers its service should trigger a quick internal review, not just a note in a change log that nobody revisits until the next annual assessment.
Building an ESP Relationship That Survives a C3PAO Assessment
The contractors who move through a C3PAO assessment with the fewest ESP-related findings share a pattern: they treated the MSP relationship as a compliance partnership from the start, not a vendor contract bolted onto a security requirement after the fact. That means a few specific things in practice.
The SSP names every ESP explicitly, describes what each one touches, and states plainly which NIST SP 800-171 controls each party owns. The contractor has a signed agreement, CRA, or attestation on file for every ESP that handles CUI or manages a Security Protection Asset. Access reviews happen on a defined cadence, not only when someone remembers to run one. Incident response plans name the ESP’s role explicitly — who calls whom, within what window, and who owns the reporting obligation to the DoD under DFARS 252.204-7012. And the contractor’s leadership understands, in plain terms, which parts of their security posture they’ve delegated and which parts they still own — a distinction that ties directly into the kind of oversight a good vCIO relationship is built to maintain.
None of this requires a contractor to become a cybersecurity expert overnight. It requires choosing an MSP that already operates this way with other defense industrial base clients, and that can produce the documentation an assessor will ask for without a scramble. Contractors in manufacturing and engineering sectors, where CUI often lives inside CAD files and production data rather than obvious document repositories, tend to have the most ESP touchpoints simply because so many specialized tools plug into their environment — another reason the SPA versus CUI-service-provider distinction matters as much as it does.
The CyberAB Marketplace and Vetting ESPs Proactively
Contractors don’t have to build ESP vetting from a blank page. The CyberAB marketplace lists Registered Practitioner Organizations and other credentialed providers, giving contractors a starting point for vendor selection that carries some built-in assurance. It’s not a substitute for a contract-level CRA or a documented shared responsibility matrix, but it narrows the field to providers who’ve already demonstrated some familiarity with the framework rather than learning CMMC vocabulary during the sales call.
This proactive vetting matters more as the DoD’s threat picture keeps shifting. Guidance from CISA on nation-state cyber threats makes clear that supply chain and third-party access remain among the most exploited paths into defense industrial base networks — which means the ESP relationship isn’t just a compliance checkbox, it’s an actual attack surface that deserves the same scrutiny a contractor would apply to its own internal systems.
Conclusion
External service provider status under CMMC isn’t a label contractors get to assign themselves — it’s determined by what a provider actually touches, and it carries real documentation and accountability obligations once confirmed. Most full-service MSPs qualify, whether they’ve formally acknowledged it or not, which makes the strength of that relationship one of the more consequential decisions a contractor makes on the road to certification. Getting the scoping right, documenting the shared responsibility clearly, and choosing a provider who treats CMMC as core to the relationship rather than an add-on request are what separate a clean assessment from a delayed one.
If your organization is planning its CMMC compliance journey, contact Stealth Technology Group today at (617) 903-5559 or visit the website to learn how modern cybersecurity infrastructure can accelerate your path toward certification readiness.
