Your IT provider may be part of your CMMC assessment even when it never stores your contract drawings. Administrator passwords, security logs, and configuration data can bring an external provider into the discussion.
This guide helps Austin and Houston contractors distinguish ordinary vendors, External Service Providers (ESPs), and Cloud Service Providers (CSPs). It focuses on Level 2 provider treatment; Level 1 has different scoping provisions.
Discuss your provider scope: Austin: 512-257-1433 | Houston: 281-815-8784.
What makes a company an External Service Provider?
Under 32 CFR 170.4, an ESP supplies or manages IT or cybersecurity services on an organization’s behalf, and CUI or Security Protection Data must be processed, stored, or transmitted on the ESP’s assets. The definition includes external people, technology, and facilities; it is not limited to a company with its own physical data center.
Apply the definition to the actual engagement. A vendor name, job title, administrator role, or contract label does not replace reviewing the services, assets, and data flows. Review hosted management platforms and provider-used systems rather than focusing only on physical ownership.
If the provider handles neither CUI nor SPD, it does not meet the CMMC ESP definition on that basis. That does not remove physical-access safeguards, other contractual obligations, or the need to assess relevant assets correctly.
What is Security Protection Data?
SPD is security-relevant data stored or processed by Security Protection Assets used to protect the assessed environment. Examples include operating configurations, security logs, vulnerability status, and passwords granting access to in-scope systems.
Practical examples to examine: RMM inventory and configuration records, SIEM logs, MDR alerts, vulnerability findings, privileged credentials, and security-related network diagrams. Classify information by its content and use; not every diagram or business record is automatically SPD.
SPD and CUI are different classifications, but a record can require review for both. An alert may include file contents; a ticket may contain a screenshot; an investigation may upload a document sample. Verify what is collected and where it goes.
Provider examples: MSP, MSSP, cloud backup, and ordinary vendors
These examples are starting points. Confirm the facts rather than assigning a category from a provider’s industry alone.
| Provider example | Data handled | CMMC treatment to evaluate |
|---|---|---|
| Cloud storage or cloud backup handling CUI | CUI, possibly SPD | CSP requirements apply. Verify the exact offering, boundary, FedRAMP Moderate-equivalent evidence, and applicable incident obligations. |
| MSP operating RMM or remote administration | SPD; possibly CUI | ESP when the definition is met. Review management platforms, technician devices, credentials, support records, and actual access. |
| MSSP providing SIEM or MDR | SPD, if records contain no CUI | SPD-only services are assessed as Security Protection Assets. Check whether payloads, attachments, or investigations introduce CUI. |
| Cloud password manager holding in-scope admin credentials | SPD | Evaluate the service as an ESP and security-protection dependency; document customer and provider responsibilities. |
| Cabling or camera installation with neither CUI nor SPD handling | Neither, under this assumed arrangement | Not a CMMC ESP on that basis. Configuration work, passwords, security-system functions, or data access can change the analysis. |
| Janitorial or ordinary office supply service | Neither, under this assumed arrangement | Not an ESP solely for that work. Physical access, visitors, sensitive documents, and other applicable safeguards still matter. |
In scope does not automatically mean FedRAMP
Cloud service handling CUI: apply the FedRAMP requirements referenced by the CMMC scoping rule. DFARS 252.204-7012 requires the applicable Moderate-equivalent security requirements and associated incident-related obligations. Verify the precise service offering and implementation, not only a brand name or a claim of government readiness.
Cloud or non-cloud service handling SPD without CUI: the provided services are assessed as Security Protection Assets. The CMMC ESP provision does not impose FedRAMP solely for SPD-only handling. Other applicable requirements still need review.
Non-cloud ESP handling CUI: its provided services are assessed within the contractor’s scope. Being an ESP does not itself make a non-cloud service subject to FedRAMP. Review its CUI-handling safeguards and applicable contract obligations.
See the short ESP/FedRAMP comparison. For cryptographic-module evidence, read when FIPS-validated encryption is required. FIPS and FedRAMP address different questions.
Do ESPs need their own CMMC certification?
ESP status alone does not create a blanket requirement for a separate certification. The scoping rule provides for assessment of relevant ESP services as part of the contractor’s assessment and permits voluntary ESP certification to reduce assessment effort. CUI-handling CSPs follow the cloud-service treatment described above.
A provider may independently need a CMMC status because of its own contract, subcontract, or other applicable obligation. Therefore, avoid promising that an ESP never needs certification. The required assessment type follows the applicable customer contract requirement.
If a provider presents its own assessment or certification evidence, check the scope, services, versions, validity, and customer responsibilities. A certificate covering a different environment does not automatically cover the service your organization uses.
What belongs in the SSP and responsibility matrix?
The rule calls for documenting the ESP relationship and provided services in the contractor’s System Security Plan. The ESP’s service description and customer responsibility matrix should describe the division of responsibilities.
Identify the service and boundary: data handled, systems used, integrations, locations, and downstream providers.
Assign control responsibilities: what the customer implements, what the provider implements, and what is shared.
Identify evidence: who supplies configuration records, reviews, logs, tests, and assessment interviews.
Define operations: access approvals, patching, alert review, escalation, containment authority, and incident coordination.
Maintain the relationship: changes, exceptions, review dates, offboarding, data return, and access removal.
Assign concrete owners. A service agreement saying “security is included” does not establish who performs each relevant task or produces evidence.
Questions to ask before onboarding an ESP
What information reaches your systems? Include credentials, logs, configuration files, attachments, and investigation samples.
Can we prevent unnecessary CUI collection? Check the supported settings and test them.
Which services and assets support our environment? Include subcontracted security and hosted management tools.
Will you support our assessment? Agree on evidence availability and responsible contacts.
Who can take action after an alert? Document approval requirements and response authority.
What changes trigger reassessment? New integrations, collection features, providers, or access can change the result.
How ESPs relate to the five asset categories
An ESP is a provider relationship; a Security Protection Asset is an asset category. A single engagement may involve multiple services and assets with different treatment. Keep the provider analysis separate from the five Level 2 asset categories and the overall CMMC assessment scope.
What this means for BCS customers in Austin and Houston
When BCS provides remote administration, security monitoring, or other IT services that process CUI or SPD on provider assets for a customer’s assessed environment, the engagement can place BCS in the ESP role. The determination depends on the actual services and implementation.
A limited cabling installation with no CUI or SPD handling can have different treatment from ongoing RMM, credential management, or MDR support. We review the engagement rather than assigning one classification to every BCS project.
BCS can work alongside your IT team to map provider dependencies, identify gaps, clarify responsibilities, and prepare implementation evidence. Explore CMMC consulting in Austin and Houston or start with a free cybersecurity risk assessment conversation. Detailed reviews and remediation are scoped separately; readiness support does not guarantee certification.
Austin: 512-257-1433
Houston: 281-815-8784
Lampasas: 512-865-4000
Primary references
32 CFR 170.4: ESP, SPD, and asset definitions
32 CFR 170.19(c): Level 2 scoping and ESP requirements
DFARS 252.204-7012: safeguarding and incident reporting
Guidance reviewed October 25, 2026. Confirm current requirements and the obligations applicable to your engagement.