When does a cloud or managed service provider count as a CMMC ESP for FedRAMP?
A defense contractor that runs its email, file storage or security monitoring through a cloud platform or managed service provider needs a clear answer to one question: does that provider count as an external service provider (ESP) under CMMC Level 2? Under 32 CFR 170.4, a provider counts as an ESP only if CUI or security protection data, such as log and configuration data, is processed, stored or transmitted on its assets. If a cloud offering will hold CUI, it must be FedRAMP Authorized at the Moderate baseline or higher on the FedRAMP Marketplace, or meet equivalent security requirements under DoD policy. The answer then depends on three things: the provider type, the data flow through its assets, and the assessment type the contract requires. A provider that touches only security protection data is assessed as a security protection asset, while a non-cloud ESP that handles CUI is assessed as part of the contractor's own scope.
Responsibility is split, and the split needs to be written down. The contractor owns its controls and the evidence that they operate, including the on-premises infrastructure that connects to the cloud or ESP service, which stays in scope whatever the provider does. The provider's responsibilities are recorded in a customer responsibility matrix, which the contractor documents or references in its system security plan. Preparing the SSP, the matrix and the supporting evidence can be work for an implementation partner, but only an independent assessor or certification body issues assessment results. Before the next assessment, confirm which offering is named in the contract, whether that exact offering appears on the FedRAMP Marketplace, and whether the provider's matrix covers every requirement it performs in whole, in part or jointly.
How each provider type is assessed
When a cloud service provider stores, processes or transmits CUI, table 4 of 32 CFR 170.19(c)(2) requires the provider to meet the FedRAMP requirements that DFARS 252.204-7012 sets for cloud services. For Level 2, the cloud offering must be FedRAMP Authorized at the Moderate baseline or higher, or meet equivalent security requirements under DoD policy. The contractor's job is to prove the provider qualifies and to show how the service fits into its own system security plan.
- Named offering: Record the exact provider, service offering and impact level in the SSP, not just the parent company name.
- Marketplace status: Confirm the authorization is listed on the FedRAMP Marketplace with a current status for that specific offering.
- Equivalency evidence: If the provider claims equivalency rather than authorization, collect the complete body of evidence and confirm it is within the required review periodicity under current DoD CIO policy.
- Incident reporting terms: Confirm the provider's agreement supports the reporting, malware, media preservation, forensic access and damage assessment duties in DFARS 252.204-7012.
- On-premises connections: Keep your own infrastructure that connects to the cloud service in your assessment scope.
Confirm with your assessor which offering and authorization documents they will accept before you sign a new cloud agreement.
A provider that handles only security protection data, such as log, configuration or monitoring records, is not assessed the same way as one that touches CUI. Under table 4 of 32 CFR 170.19(c)(2), a cloud or non-cloud provider in this position is treated as a security protection asset. The provider's services still matter for your assessment, but the assessor reviews them as assets that support your security functions rather than as an external environment that stores CUI.
- Asset classification: Document the provider as a security protection asset in your asset inventory and SSP.
- Data flow mapping: Show exactly which logs, configuration files or alerts leave your environment and where they land.
- Protection of the data: Describe how security protection data is encrypted, access controlled and retained at the provider.
- Scope boundary: Identify whether any CUI could reach the provider through a log or ticket, because that would change the classification.
- Ongoing review: Recheck the classification when the provider adds services or when your data flows change.
Ask your assessor to confirm in writing that the provider is a security protection asset and not an ESP handling CUI.
A non-cloud external service provider that handles CUI is assessed as part of the contractor's own assessment under table 4 of 32 CFR 170.19(c)(2). The provider's people, tools and facilities are reviewed against every Level 2 requirement that applies to the services it performs. Under 32 CFR 170.16(c)(3) and 170.17(c)(6), the contractor must document the provider's use and services in the SSP and obtain a service description and customer responsibility matrix from the provider.
- SSP entry: Describe the provider, the services used, the CUI involved and the reason the service is in scope.
- Service description: Obtain the provider's written description of the services it delivers to your environment.
- Customer responsibility matrix: Require a matrix that names each party with security responsibilities and maps every in-scope requirement the provider handles wholly, partly or jointly.
- Evidence access: Confirm your assessor can review the provider's personnel, records and tools as needed for the requirements it covers.
- Optional certification: If the provider holds a valid CMMC Level 2 or Level 3 Certificate of CMMC Status, assessors may treat the requirements it owns as validated, though its personnel must still take part and the inherited controls must be shown to be maintained.
Confirm with the provider and your assessor whether the provider's certificate would reduce the evidence your assessor needs.
Under 32 CFR 170.4, an external service provider is an external person, technology or facility used to provide or manage IT or cybersecurity services. The definition counts a provider as an ESP only when CUI or security protection data, such as log and configuration data, is processed, stored or transmitted on its assets. A vendor that has no access to either category is generally not an ESP for scoring purposes, even if it provides IT services to your company.
- Test the data path: Check whether the provider's systems ever receive CUI, including through support tickets, screenshots, email attachments or backups.
- Document the decision: Record the reasoning in your SSP or scoping file so an assessor can follow it.
- Watch for drift: A helpdesk or managed print vendor may gain access to CUI later, which would change its status.
- Contract language: Add terms that restrict the provider from handling CUI or security data unless you approve the change.
- Assessor agreement: Ask the assessor to confirm the boundary before the assessment starts.
Because the classification drives the entire assessment, confirm it with your assessor and do not rely on the vendor's own description of its services.
What the FedRAMP Moderate rule requires for cloud CUI
A contractor may store, process or transmit CUI in a cloud offering at Level 2 only if that offering is FedRAMP Authorized at the Moderate baseline or higher on the FedRAMP Marketplace, or if it meets equivalent security requirements under DoD policy (32 CFR 170.16(c)(2) and 170.17(c)(5)). The test is applied to the specific offering the contractor uses, not to the provider's brand or its other products. Before the assessment, confirm the provider name, the service offering, the impact level and the authorization status on the Marketplace, then check that the same offering appears in the system security plan. A cloud service that is authorized at a lower baseline, or a sibling product from the same company that is not listed, does not satisfy the rule.
When the contractor relies on equivalency instead, DFARS 252.204-7012(b)(2)(ii)(D) requires it to make sure the provider meets requirements equivalent to the FedRAMP Moderate baseline. The same clause also requires the provider to support the incident reporting, malware handling, media preservation, forensic access and damage assessment duties in that clause. In practice, that means the contract with the cloud provider must give the contractor and DoD the access and preservation rights those duties depend on, and the contractor should be able to show how a reported incident would reach its own reporting timeline. Ask the provider in writing which of these duties it accepts and where the terms appear in its agreement.
Assessors will check the equivalency evidence against current DoD CIO policy, so the contractor should collect the provider's documentation in its final form, dated and within the periodicity that policy requires. Confirm the exact requirements with the current DoD CIO policy and the DFARS clause text, since they change over time. An implementation partner can help map the provider's evidence to the contractor's SSP and track renewal dates, but the contractor owns the decision to use the cloud service, and only the independent assessor reaches a conclusion on the result.
How assessors verify FedRAMP status and equivalency
An assessor does not take a provider's word for FedRAMP status or equivalency. The checks below follow the order an assessor typically works through: confirm the authorization in public records, match it to the exact offering in the SSP, then test the evidence behind any equivalency claim. Gather the matching records before the assessment starts so each check can be answered from the file.
Check the FedRAMP Marketplace listing
An assessor looks up the provider on the FedRAMP Marketplace and confirms four things: the provider, the service offering, the impact level and the status. The authorization must be at the Moderate baseline or higher, and it must be current. A provider that is in process, or authorized at a lower impact level, does not satisfy the requirement for CUI. Take a dated screenshot or record of the listing and keep it in the assessment folder.
Match the offering named in the SSP
Authorization belongs to a specific service offering, not to a company name. The assessor checks that the offering named in the system security plan is the one listed on the Marketplace. A provider may hold a listing for one product line while the contractor uses another, a government region or a separate tenant. Any mismatch leaves the CUI in an unauthorized service, so confirm the exact product name, deployment model and region before writing the SSP.
Confirm equivalency evidence is complete
When a cloud offering is claimed as FedRAMP Moderate equivalent instead of listed, the assessor reviews the body of evidence the provider supplies. The evidence must be complete, unaltered and refreshed within the periodicity set by current DoD CIO equivalency policy. Ask the provider for a written inventory of its evidence, the dates of each item and a statement of which items are overdue. Gaps in this file are the most common reason an equivalency claim fails.
Check evidence is intact and current
Completeness is not enough. The assessor checks that each artifact is intact, which means it has not been edited or replaced since issue, and that it falls within the required review cycle. Expired assessment reports, missing continuous monitoring deliverables or unsigned attestations stop the equivalency claim even when the provider's marketing says it meets the baseline. Ask the provider for the most recent version of each item and the date it was last reviewed.
Expect no re-evaluation of the offering
For equivalency claims, the assessor verifies the evidence and its currency, but does not independently rate the offering against the FedRAMP Moderate baseline. The contractor should not expect the assessor to accept an argument that the offering is "close enough" on its own judgment. Equivalency rests on the evidence file and the DoD CIO policy in force at the time, so the decision on whether to rely on the provider is made against that file.
Gather the verification file early
Before the assessment, assemble one folder per cloud provider: the Marketplace record or equivalency evidence inventory, the SSP entry naming the offering, the provider's customer responsibility matrix and the contract clause that requires FedRAMP equivalence. Confirm with the provider who maintains each artifact and when it is next due. An implementation partner can help organize this file, but the organization owns the statements in its SSP and the independent assessor decides what is accepted.
Building a customer responsibility matrix the assessor will accept
A customer responsibility matrix is the document that splits each in-scope Level 2 requirement between your organization and the external service provider (ESP). Assessors check it before they check anything else about an ESP, so the first job is to make it complete. The provider's service description and matrix must name every party with security responsibilities, and must cover every in-scope requirement the provider performs wholly, partly or jointly. A requirement left out of the matrix is one an assessor cannot credit to the provider, which leaves you holding the evidence for it. Ask the provider to confirm, in writing, that each requirement it touches is listed with its role, and that the matrix names the specific service offering you are buying rather than the provider's general product line.
Currency matters as much as coverage. The matrix must be current on the day of the assessment, so tie its review date to changes in the provider's service, your contract, and the offering named in your System Security Plan. Under 32 CFR 170.16(c) and 170.17(c), the ESP's use and services must be documented or referenced in your SSP, and the matrix requirements must be captured there too. Build a cross-reference table in the SSP that points each inherited requirement to the matrix row and to the evidence you hold. Name every party in the table, including any sub-provider the ESP relies on for the service, and record who approved each row on your side.
Whatever provider you use, your own on-premises infrastructure that connects to the cloud or ESP service stays inside the assessment scope. The gateways, identity connectors, network links, endpoints and administrator workstations on your side are your responsibility to document and assess, and no provider matrix removes them. Requirement SC.L2-3.13.6 covers your network communications, so confirm which parts of that boundary you own and which the provider owns before the assessment. Confirm these points with your assessor and your provider early, because gaps found late usually sit in the connection between the two environments.
When an ESP should pursue its own certification
A non-cloud external service provider can seek its own CMMC certification, which can shorten each customer's assessment. Four decisions shape whether that path is worth the effort: the voluntary route itself, what a valid certificate lets assessors accept, the minimum assessment type a customer contract sets, and the cost trade-off.
The voluntary certification route
Under 32 CFR 170.19(c)(2)(ii), an ESP may voluntarily undergo a CMMC certification assessment to reduce its effort during its customers' assessments. The provider decides whether to go first, and it owns the scope, the evidence and the assessment outcome. Before committing, confirm which of your customers will accept a provider certificate and which still expect their own assessment of your services.
What a valid certificate lets assessors accept
Under CAP v2.0, when a non-cloud ESP holds a valid Level 2 or Level 3 Certificate of CMMC Status, assessors may treat the requirements it is responsible for as validated. This is a reduction in re-testing, not an exemption. Your personnel must still take part in the customer's assessment, and the inherited requirements must still be shown to be maintained between assessments.
The minimum assessment type set by contract
The customer's contract sets the minimum assessment type that the ESP's services must meet, and that minimum can be higher than a self-assessment. A provider certificate helps only when it matches what the contract requires for the relevant level. Ask each customer in writing which assessment type it requires for your services before you choose between a self-assessment and a certification assessment.
The cost trade-off to confirm
Certification costs the provider an assessor fee, internal preparation and evidence upkeep, and these recur over the certification cycle. The saving comes from fewer repeated assessment requests across customers, and it depends on how many customers rely on your certificate. Ask your assessor for a written quote for the chosen scope, and ask your customers how much of their own assessment effort they expect the certificate to remove.
Steps to document ESP use before an assessment
This sequence turns a loose list of outside providers into a documented, verifiable picture of which external services touch CUI or security protection data, how each is classified, and what evidence supports it. The output is an SSP that matches the provider documentation an assessor will check.
Inventory every external provider touching CUI
Start by listing every external people, technology or facility provider that supports IT or cybersecurity services for the in-scope environment, including managed service providers, cloud hosts, backup and logging services, and support vendors with remote access. Under the ESP definition in 32 CFR 170.4, a provider counts only if CUI or security protection data such as log and configuration data is processed, stored or transmitted on its assets, so mark each provider against those two data types. The step is done when the list names each provider, the service it performs, and the data it touches, and the contractor's owner has signed off on the list.
Classify each provider as cloud or non-cloud
For each provider that handles CUI or security protection data, record whether the service is a cloud service or a non-cloud service, because the rule that applies depends on that answer. Under table 4 of 32 CFR 170.19(c)(2), a cloud provider handling CUI must meet FedRAMP requirements, a provider handling only security protection data is assessed as a security protection asset, and a non-cloud ESP handling CUI is assessed as part of the contractor's own assessment. The step is done when each provider carries one of these classifications with a short written reason that a reviewer can check.
Verify FedRAMP status or equivalency evidence
For each cloud offering that handles CUI, confirm FedRAMP Moderate or higher authorization on the FedRAMP Marketplace by provider, service offering, impact level and status, and check that the exact offering named in the SSP is listed. Where a provider claims equivalency instead, collect the evidence that it meets the FedRAMP Moderate equivalent requirements under DoD policy, including the body of evidence and its periodicity, and confirm the incident reporting and related DFARS 252.204-7012 obligations are in the contract. The step is done when each cloud provider has a saved Marketplace record or equivalency package in the assessment file, with the date it was checked.
Obtain service descriptions and responsibility matrices
Request a current service description and a customer responsibility matrix from each non-cloud ESP and from each cloud provider whose services the contractor relies on, showing which requirements the provider performs wholly, partly or jointly. Ask the provider to name all parties with security responsibilities and to confirm which Level 2 requirements sit with the contractor. The step is done when the contractor holds written documents from each provider that map every in-scope requirement the provider touches, and the contractor has noted any gaps to resolve with the provider.
Document ESP use in the SSP
Write each provider into the system security plan with its services, the data it handles, its classification, the FedRAMP or equivalency reference or its non-cloud status, and the location of its responsibility matrix. Under 32 CFR 170.16(c) and 170.17(c), the use and services of a non-cloud ESP must be documented in the SSP, and the customer responsibility matrix requirements must be documented or referenced there. The contractor's own on-premises infrastructure that connects to the cloud or ESP service remains in scope, so describe those connections too. The step is done when the SSP names every provider from the inventory and each entry points to evidence in the file.
Confirm the matrix is current and complete
Before the assessment, check that each responsibility matrix is dated, reflects the current service and contract terms, and covers every in-scope requirement that the provider performs wholly, partly or jointly, since CAP v2.0 directs assessors to check exactly these points. Compare the matrix against the SSP and the inventory so that no provider or requirement is missing from either. Where a non-cloud ESP holds a valid Level 2 or Level 3 Certificate of CMMC Status, confirm that certificate as well, while noting that its personnel must still take part and the inherited requirements must still be shown to be maintained. The step is done when the contractor can show a matched set of current matrices, SSP entries and provider evidence, and an internal reviewer has confirmed it.
Questions contractors ask about ESPs and FedRAMP
Is a managed service provider that only monitors logs an external service provider?
It can be, but only if CUI or security protection data is processed, stored or transmitted on the provider's assets. Under 32 CFR 170.4, an external service provider is external people, technology or facilities used to provide or manage IT or cybersecurity services, and a provider counts as an ESP only when that data touches its systems. A log-monitoring provider receives audit logs, which are security protection data, so it usually counts as an ESP. Its treatment then depends on whether it is cloud or non-cloud and whether it handles CUI as well. Confirm the boundary with your assessor and document the provider's data flows before the assessment starts.
Is a FedRAMP Ready or In Process offering enough for CUI?
Usually not. For Level 2, a cloud offering may hold CUI only if it is FedRAMP Authorized at the Moderate baseline or higher on the FedRAMP Marketplace, or if it meets equivalent security requirements under DoD policy. Ready and In Process statuses describe progress toward authorization, not an authorization, so an assessor will not accept them as the basis for CUI. Check the provider, service offering, impact level and status on the Marketplace, and confirm the exact offering named in your SSP is listed. Ask the contracting officer whether any equivalency route applies to your contract.
Does a commercial SaaS tool that never sees CUI need FedRAMP?
No, as long as the tool does not process, store or transmit CUI or security protection data. The FedRAMP requirement attaches to cloud services that handle CUI, and a provider handling no CUI or security protection data is outside the ESP definition in 32 CFR 170.4. Be careful with the boundary, though. Collaboration, ticketing and email tools often hold CUI by accident, and a tool that receives log or configuration data becomes a security protection asset. Document the data flows, restrict the tool to non-CUI content, and have the assessor confirm the scoping decision.
What must a contractor do if a provider loses its FedRAMP authorization?
Treat it as a change to a requirement your assessment depends on, and act before the next assessment or contract milestone. The contractor's obligations do not transfer to the provider, so you should document the status change, assess whether CUI in that service must move or stop, and update the SSP and any plan of action that covers the affected requirements. Check the DFARS 252.204-7012 obligations for cloud services as well, since they include incident reporting and access for forensic review. Confirm the required steps and timing with your contracting officer and assessor, because the contract terms may set them.
How does a customer responsibility matrix differ from an SSP?
The SSP describes how your entire system meets the Level 2 requirements, while the customer responsibility matrix describes which requirements the provider performs, which you perform, and which are shared. Under 32 CFR 170.16(c)(3) and 170.17(c)(6), your SSP must document the non-cloud ESP's use and services, and the provider's service description and matrix supply the detail behind that entry. Assessors check that the matrix is current, names every party with security responsibilities, and covers each in-scope requirement the provider performs wholly, partly or jointly. Your SSP is your document; the matrix is a shared input you should reference in it.
Can we build the responsibility mapping in-house?
Yes, a contractor can prepare its own mapping, and many do. The organization owns its controls, so it is responsible for the mapping and for proving that every inherited requirement is maintained. The work includes reading each provider's documentation, confirming what it actually does, assigning owners and collecting current evidence. Outside help is commonly used to prepare or review this work, for example through an implementation partner that organizes evidence, while the assessor remains independent. Ask your assessor which provider documents they will accept, and ask any outside party whether it is barred from later assessing your organization.
Where ESP evidence usually breaks down
Most external service provider problems in a CMMC assessment are documentation problems, not technology problems. The cards below cover the failures assessors see most often, from an SSP that names the wrong cloud product to draft documents presented as final. Each one has a specific check you can run before an assessor does.
SSP names the platform, not the offering
An SSP that says the company uses a major cloud provider does not show which service holds CUI. Assessors check the FedRAMP Marketplace by provider, service offering, impact level and status, and they confirm that the exact offering named in the SSP is listed. Before the assessment, list each cloud service that stores, processes or transmits CUI, then match each one to a Marketplace entry at the Moderate baseline or higher. Record the offering name exactly as it appears on the Marketplace.
Matrix leaves shared requirements unassigned
A customer responsibility matrix often lists the provider's controls and the customer's controls but leaves shared requirements with no owner. Assessors check that the matrix is current, names every party with security responsibilities, and covers every in-scope requirement the provider performs wholly, partly or jointly. Walk the Level 2 requirements one at a time and mark each as provider, customer or shared, with a named owner for each shared item. Gaps often sit in logging, key management and incident notification.
Undocumented MSP remote access
Managed service providers often reach into in-scope systems through remote tools, jump hosts or vendor accounts that never appear in the SSP. Because a non-cloud ESP that handles CUI or security protection data is assessed within the contractor's scope, unrecorded remote access becomes an unassessed path into the boundary. Inventory every account, tool and network path the provider uses, document who approves each one, and confirm that its activity is logged and reviewed. Ask the provider to show those logs during your readiness review.
Relying on a general compliance report
A provider's SOC 2 report, ISO certificate or internal audit letter does not show that its services meet Level 2 requirements. Assessors look for evidence mapped to the NIST SP 800-171 requirements the provider covers, and for FedRAMP Moderate or equivalent status for cloud services handling CUI. Ask the provider which Level 2 requirements its report actually tests, which ones it does not, and how the gap is handled in your customer responsibility matrix. Treat any unmapped area as your responsibility until it is shown otherwise.
Draft documents presented as final
Assessors accept evidence only in final form, and a requirement is MET only when every applicable assessment objective is satisfied with that final evidence. A draft matrix, an unsigned service description or a provider procedure marked as pending review will not count, even if the work behind it is complete. Before the assessment, version-control each ESP document, confirm that its approval date and signatory are present, and remove drafts from the evidence folder. Ask each provider for a dated, signed copy of its current matrix.
Who owns ESP controls and who prepares the evidence
The contracting organization owns every CMMC requirement that applies to its environment, including the requirements that an external service provider performs on its behalf. Owning a control means the organization decides how it is designed, who is accountable for it, and whether the evidence is current. Outside parties can operate parts of the control, but they cannot take over accountability for it. The contractor also writes the system security plan and decides the assessment scope, and it is the signatory for affirmations and SPRS entries.
- Accountability: Name an internal owner for each in-scope requirement, including those performed by a provider.
- Scope and SSP: Document every external service provider, its use and its services in the system security plan.
- Provider oversight: Collect and review the provider's service description and customer responsibility matrix, and confirm they are current.
- Evidence: Keep final, dated evidence for the contractor's own controls and for the provider services it relies on.
- Affirmations: Confirm the affirming official's statements match what the environment actually does.
Before relying on any provider, ask what evidence it will give you and how often that evidence is refreshed.
An external service provider is an outside person, technology or facility used to provide or manage IT or cybersecurity services. It becomes an ESP for CMMC purposes only when CUI or security protection data, such as log and configuration data, is processed, stored or transmitted on its assets. A provider in that position is responsible for the controls it performs and for the service documentation it hands to customers. The provider does not decide the contractor's scope or issue the contractor's results.
- Service description: Publish a document that states which services are provided, how they work and what they cover.
- Customer responsibility matrix: Show which party performs, shares or inherits each in-scope requirement, and keep it current.
- FedRAMP status for cloud: For a cloud service that handles CUI, hold FedRAMP Moderate authorization or meet equivalent requirements under DoD policy.
- Voluntary certification: A non-cloud ESP may undergo its own CMMC certification assessment to reduce the effort of customer assessments.
- Personnel participation: Make staff available to take part in customer assessments when inherited requirements are reviewed.
Confirm with the provider which of these documents it can supply, under what terms, and who signs them.
An implementation partner prepares the systems, controls and evidence that the contractor and its providers will be assessed on. This work includes building or hardening environments, configuring logging and access controls, drafting procedures, mapping responsibilities and organizing artifacts so an assessor can verify them. The partner works on the contractor's infrastructure and under its direction. It does not own the controls, it does not decide the scope, and it does not issue reports or certificates.
- Environment preparation: Configure systems, backups, logging and access controls within the contractor's own infrastructure.
- Documentation support: Draft or update the system security plan, procedures and responsibility matrices for the contractor to review and approve.
- Evidence organization: Structure final evidence so each requirement can be traced to artifacts an assessor can test.
- Readiness testing: Run internal checks or mock assessments and report gaps for the contractor to remediate.
- Independence limit: Do not perform the independent assessment for the same engagement.
Ask for a written scope that names each deliverable and states which parts the contractor must still perform itself.
Only an independent assessor issues assessment results. For Level 2 certification assessments, that role belongs to a C3PAO authorized or accredited by The Cyber AB. The assessor tests the contractor's environment against the assessment objectives, including how an external service provider's services are covered. For a cloud offering, the assessor verifies FedRAMP status or the equivalency evidence. For a non-cloud ESP, the assessor reviews its customer responsibility matrix and confirms the inherited requirements are shown to be maintained.
- Verification: Check FedRAMP Moderate status on the FedRAMP Marketplace by provider, offering, impact level and status.
- Matrix review: Confirm the customer responsibility matrix is current and covers every in-scope requirement the provider performs.
- Independence: Keep the assessor separate from consultants who prepared the evidence, so the assessment is not self-review.
- Results: Score the assessment and submit results under the program process, which the contractor cannot substitute with its own report.
- Scope limits: Assess only the scope the contractor and its providers document and defend.
When selecting an assessor, verify its authorization and check its conflict of interest statement before sharing any preparation work.
How DeployOpen prepares ESP evidence for assessment
DeployOpen starts by building an inventory of every external service that touches the client's CUI or security protection data, including cloud platforms, managed services, logging and monitoring providers, and remote support tools. The inventory records the provider, the specific service offering, where data is processed, stored or transmitted, and which people or technology the provider supplies. Only after this inventory exists can the team decide which providers count as external service providers under the scoping rules, because a provider that handles neither CUI nor security protection data is not an ESP. Before any hands-on work, the scope, deliverables and timelines are agreed in writing, so the client knows exactly which services and boundaries are covered.
With the inventory agreed, DeployOpen drafts the entries that the client's system security plan must carry for each ESP, along with the provider's customer responsibility matrix. For each in-scope requirement, the matrix should name who performs it, who owns it and how the client verifies it. The team checks that the matrix is current, names every party with security responsibilities, and covers each requirement the provider performs wholly, partly or jointly. For a cloud offering, DeployOpen collects the offering name and impact level as they appear on the FedRAMP Marketplace, so the assessor can compare the SSP entry against the listing. Clients should confirm the offering, not just the provider, because a provider may list several offerings with different authorization status.
The evidence package is then assembled for the independent assessor, who makes every determination. DeployOpen prepares configuration exports, contract terms, service descriptions, network diagrams showing the client's on-premises connections to each service, and the responsibility matrix, all in final form and with the dates they were produced. Any evidence that is still a draft is flagged for completion before the assessment. DeployOpen does not issue reports, attestations or certificates, and it does not decide whether a requirement is met. Clients should ask their assessor early which ESP evidence it will accept, and whether any provider holds its own Certificate of CMMC Status that could reduce the assessment effort for inherited requirements.
How DeployOpen scopes and documents CMMC external service providers
DeployOpen works on the systems and paperwork around an external service provider, not on the provider's own certification. We help you establish which providers count as ESPs, which of them hold CUI, and what evidence your System Security Plan and the provider's customer responsibility matrix need before an assessor arrives. Assessors and certification bodies make the final determinations.
How we scope
- Engagements are fixed-scope, with the provider list, deliverables and timeline agreed in writing before work starts.
- We list each cloud, managed service and other external provider and record whether it processes, stores or transmits CUI or security protection data.
- We map which providers are cloud offerings that need FedRAMP Moderate or equivalent status, and which non-cloud ESPs must be assessed inside your scope.
How we build
- We build the connection design between your on-premises environment and each provider, documenting the boundary your own infrastructure keeps in scope.
- We draft SSP sections that describe each ESP's use and services, and cross-reference the provider's responsibilities side by side with yours.
- We test the claimed shared controls with you, checking that each one has a named owner, a configuration and evidence an assessor can sample.
How we hand over
- You receive a provider inventory with CUI handling, FedRAMP marketplace listings checked by offering and impact level, and open items for each provider.
- You receive a customer responsibility matrix review that confirms every in-scope requirement a provider performs wholly, partly or jointly is covered.
- You receive an evidence index with owners, retention and refresh dates, so the assessor can verify status without a rebuild.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so provider changes can be re-checked as they happen.
- We help you request current FedRAMP status, equivalency documentation and responsibility matrices from each provider before you rely on them.
- We confirm with your Affirming Official, contracts team and assessor which provider evidence is still missing, so gaps are closed before the assessment.
