Shared responsibility with your cloud provider under CMMC

An authorization is your provider's evidence, not yours

The most expensive sentence in cloud compliance is “our provider is authorized, so we are covered.” It is half true, which is what makes it dangerous. A Federal Risk and Authorization Management Program authorization is a statement that a named set of services, run by a named company, inside a described boundary, was assessed against a control baseline. It says nothing about how you configured those services, who you gave administrative rights to, where your backups land, or whether the ticketing system your engineers paste error messages into is inside the boundary or outside it. When an assessment team arrives, the provider is not the one being assessed. You are.

This is not a gotcha invented by assessors. It is the ordinary structure of every cloud contract ever written. Providers publish shared responsibility models precisely because they are not willing to be responsible for what customers do inside a tenant, and no serious provider has ever claimed otherwise. The failure is on the buying side: a compliance lead reads a marketing page that says the platform “supports CMMC,” and hears a promise that was never made. Supporting a framework means the platform can be configured to satisfy controls. It does not mean it has been.

The practical consequence shows up as a gap in the evidence binder. You can point at a certificate. You cannot point at the artifact that proves your own half. That artifact has a name, it is boring, and almost nobody asks their provider for it until the week before an assessment.

The clause that actually governs

When controlled unclassified information is involved in a Department of Defense contract, the operative text is usually DFARS 252.204-7012, the clause on safeguarding covered defense information and cyber incident reporting. Most discussion of that clause stops at its headline requirement, which is to implement the security requirements in NIST Special Publication 800-171. The cloud paragraph sits further down and is more specific than people expect.

If a contractor intends to use an external cloud service provider to store, process or transmit covered defense information, the clause requires the contractor to ensure that the provider meets security requirements equivalent to the FedRAMP Moderate baseline, and that the provider complies with the clause's paragraphs on cyber incident reporting, malicious software submission, media preservation and protection, access to additional information and equipment for forensic analysis, and cyber incident damage assessment. Read that second half again. It is not a security-posture requirement. It is a set of obligations your provider has to actually perform, on your timeline, after something goes wrong.

There is a separate and frequently confused case. If the cloud service is what you are selling to the government — a hosted product the agency logs into — a different regime applies, built on the DoD Cloud Computing Security Requirements Guide and its own clause. That is a provisional-authorization conversation with impact levels, not a 7012 conversation. Firms that sell software and also use software sometimes end up in both at once, and the two paths have different evidence, different sponsors and different timelines. Work out which one you are in before you buy anything.

What “FedRAMP Moderate equivalent” means, and what it does not

The word equivalent in that clause did real damage for years, because it was read as “roughly as good as,” which is an argument rather than a fact. The Department of Defense CIO issued a memorandum on FedRAMP Moderate equivalency in early 2024 that narrowed it considerably. The shape of the requirement, and you should read the memo rather than take our summary as the last word, is that a provider claiming equivalency needs a body of evidence assessed by a FedRAMP-recognized third-party assessment organization against the full Moderate baseline, delivered with the standard package artifacts, plus an attestation from the provider. The memo is notably unfriendly to the idea that a provider can be equivalent while carrying open gaps.

Two things follow from that. First, equivalency is a documented, assessed claim, not a self-description — if a provider tells you they are equivalent, the correct response is to ask which assessment organization produced the body of evidence and when. Second, an actual authorization listed on the FedRAMP Marketplace is easier to defend than an equivalency claim, and it is public, which means you can check it in about four minutes without asking anyone's permission.

The authorization boundary is a list of named services

This is the detail that surprises the most competent people. Cloud authorizations do not cover a company. They cover an offering, and inside that offering they cover an enumerated set of services in a described boundary. Large providers publish which of their services are in scope for which baseline, and the list is never the whole catalog. New services routinely ship before they are in any authorization boundary at all, which is entirely normal and completely fine unless you have put controlled information into one.

The same is true of regions and tenancy. A provider may operate a commercial environment and a government environment with different boundaries, different personnel rules and different service availability. Choosing the government environment usually costs more, offers fewer services, and lags the commercial one on new features. Sometimes that trade is required and sometimes it is not, and the way to find out is to read the authorization details for the specific offering rather than to reason from the provider's brand.

Export control is a separate question layered on top, and it is a common reason firms end up in a government tenant even when the security baseline alone would not have required it. If the information includes export-controlled technical data, the analysis adds the citizenship and location of the people with access and the physical location of the data. That is not a FedRAMP question and a FedRAMP answer will not resolve it. Ask your contracting officer or your export counsel which regime attaches to the data you are receiving, in writing, before you pick a tenant.

Inheritance is a claim you have to evidence

The document that makes the table above real is the customer responsibility matrix. FedRAMP packages carry an artifact that walks control by control and states which are the provider's, which are the customer's, and which are shared. It is the single most useful piece of paper in this entire subject and most buyers have never seen theirs.

Ask for it by name. Some providers publish theirs; some will release it under a non-disclosure agreement; some will hand you a shorter summary under the same name. Then do the unglamorous work: for every control the matrix marks as yours or shared, write down what you actually do and where the proof lives. That mapping is your system security plan for the hosted portion, and building it takes days rather than months if you start from the matrix instead of from a blank template.

Inheritance without that mapping is the most common finding we see described. The contractor believes a control is covered upstream, the provider's own matrix says it is a customer responsibility, and nobody compared the two documents until an assessor did it for them.

The obligations standard cloud terms do not carry

Go back to the second half of the 7012 cloud paragraph, the part about incident reporting, malicious software, media preservation, forensic access and damage assessment. Now open the agreement you actually signed with your provider. On ordinary commercial terms, most of those obligations are simply absent. There is a general security commitment, an uptime commitment, a notification promise with no hard clock, and an explicit statement that you are responsible for your own content.

That mismatch is not evidence of a bad provider. It is evidence that you bought a commercial product and inherited a federal obligation, and nobody reconciled the two. There are three honest ways out. Buy the government-market offering, where these terms are more often addressed. Negotiate an addendum, which is realistic if you are large and unrealistic if you are not. Or design so that the artifacts the clause wants live somewhere you control — your own logging, your own snapshots, your own retention — and the provider's cooperation is a convenience rather than a dependency. The third option is the one small firms can actually execute, and it is worth designing for on day one rather than discovering on day nine hundred.

Whichever you pick, rehearse it. The clause contemplates reporting a cyber incident to the government inside a short window measured in hours, and reporting through the department's portal requires credentials that take real time to obtain. A firm that has never logged in, never tested the reporting form and never confirmed who holds the certificate will discover all three problems on the worst day of its year.

Validated is not the same word as compatible

Encryption is where careful firms lose points on a technicality that is not really a technicality. The requirement is for validated cryptography, and validation is a specific thing: a module tested by a laboratory and issued a certificate under the Cryptographic Module Validation Program, published with a number you can look up. “Uses AES-256” is not validation. “FIPS-compatible mode” is not validation. A product that ships a validated module but is not configured to operate it in the validated mode is, for this purpose, not validated either.

The practical ask is short. For every place controlled information sits still or moves — storage, database, backup, transit, laptop disks, mobile devices — get the certificate number and the configuration setting that puts the module in the validated mode. Providers who have done this before answer in a day. Providers who have not will send you a datasheet, which is your answer.

The assets nobody puts on the diagram

The scoping rules for a Level 2 environment treat anything that provides security functions for your controlled environment as in scope, whether or not that thing ever touches the information itself. That category sweeps in more than people expect.

Your managed service provider. If an outside firm holds administrative credentials to your environment, they are part of your security boundary, and their practices are part of your evidence. This is the single most common surprise for firms with fewer than fifty people, because outsourced administration is the sensible choice for a company that size and nobody told them it had a compliance consequence.

Your identity provider. Single sign-on is a security function by definition. If it sits in a different tenant from the one you scoped, you have two environments, not one.

Your endpoint management and your security monitoring. Same logic. The tool that can push software to every laptop is a control over every laptop.

Backup, logging and ticketing. Backups are the classic leak: a carefully drawn boundary with a backup job replicating to a general-purpose account outside it. Ticketing is the subtle one, because nobody puts a document in a ticket — they paste an error message, a file path, a customer name, a screenshot. Over a year that adds up to a searchable copy of your controlled data in a system nobody scoped.

The rules governing external service providers were adjusted between the proposed and final versions of the program rule, and the treatment of providers who handle controlled information versus those who only provide security functions is exactly the kind of detail worth reading in the current text rather than in an article. Read 32 CFR 170.19, and if your provider arrangement is unusual, get the reading confirmed by your assessment organization before you build around it.

Where this goes wrong

• Treating the provider's certificate as your evidence — it describes their half of a boundary you are jointly inside
• Never obtaining the customer responsibility matrix, so inheritance is assumed rather than mapped
• Using a service that is outside the authorization boundary because the brand is inside it
• Commercial terms with a federal clause, and no plan for the forensic and preservation obligations
• Backups, logs or tickets landing outside the scoped environment while the diagram still shows one box
• Encryption that is compatible rather than validated, with no certificate number on file
• An administrator with keys to everything who was never scoped, usually an outside firm
• No rehearsal of incident reporting, and no confirmed holder of the credentials it requires

What to ask, in the order that saves time

• Which exact offering are we on, and what is its authorization status and baseline
• Which services are inside the boundary, and which of those are we using
• Send the customer responsibility matrix, under NDA if needed
• Which cryptographic modules are validated, with certificate numbers and the settings that enable them
• What will you notify us about, and how fast, in writing
• What will you preserve and hand over if we have to support a forensic request
• Where do backups, logs and support tickets physically live
• Who outside our company holds administrative credentials to this environment
• Does any export-control restriction attach to this data, and does the tenant satisfy it

Bottom line

The provider is responsible for the platform. You are responsible for the tenant, the configuration, the accounts, the placement of the data and the ability to prove all four. The document that divides those two lists already exists and is called a customer responsibility matrix; the single highest-value thing you can do this month is obtain yours and map it. After that, the questions are concrete: which services, which region, which certificate, which clock on notification, and who else holds the keys. None of that requires an outside firm. It requires somebody inside your company to own the boundary and be willing to write down where it runs.

Frequently asked questions