What your cloud covers. What's still on you. Mapped.
All 110 NIST 800-171 controls across the four FedRAMP-authorized clouds — M365 GCC High, Azure Government, AWS GovCloud, GCP Assured Workloads. Filter by your platform, see who handles what, lift the wording straight into your SSP. No email. No gate.
Cyber AB Registered Practitioner (in process)·UK government-cleared engineering team·Last verified 17 April 2026·Phase 2 enforcement begins 10 November 2026
requirements
objectives
platforms covered
fully inherits
"We're on GCC High, so we're mostly covered."
— first call, every week
It's the most common misread of CMMC. A FedRAMP-authorised cloud gives you the right foundation, but the controls themselves still get split between the platform, your service providers, and you. Even on the most mature platform, you own most of the work. Here's the actual split, control by control, for the four FedRAMP clouds DIB contractors actually run on.
On every FedRAMP cloud, more than a hundred of the 110 controls still need configuration, evidence, or your direct ownership.
What "inherited" means here. A control is inherited only when the platform handles it end-to-end — no customer configuration, no evidence to produce. On M365 GCC High, that's one control: SC.L2-3.13.4, where Microsoft's FedRAMP High authorisation handles tenant isolation and object-reuse protection at the platform layer. Microsoft's own placemat shows broader "inherited" coverage, but most of those controls still require you to configure, document, and evidence them. We've used the stricter definition because that's what the C3PAO will use.
Four labels. Each one tells you who has to prove it.
Every requirement gets one of these four labels for the platform you've picked. No overlap, no ambiguity. Same vocabulary your provider's CRM uses, same vocabulary the assessor will recognize.
Inherited
The platform handles it completely. Your role is to confirm the configuration in your SSP and show the inheritance source.
Shared
The platform supplies the capability. You configure it for your environment, evidence it, and own the policy that wraps it.
Customer
You build and operate it. The platform doesn't help. This is where most of your evidence collection and budget lands.
N/A
The control doesn't apply to your environment because of a legacy carve-out, scope decision, or platform equivalent. State the reason in your SSP.
Pick a platform. Filter by status. See what's on you.
No requirements match.
Try clearing the search or switching to a different status filter.
SRM is the framework. CRM is what your assessor will ask for.
Most CMMC content blurs these two. The distinction matters because 32 CFR 170.19(c)(2)(ii) names the CRM specifically — and it's the artifact a C3PAO will expect on assessment day. The SRM is upstream of that. Knowing which one you have, and which one you still need to produce, is the difference between a clean assessment and a finding.
Shared Responsibility Matrix
The strategic framework. Maps how responsibility for each control splits between the cloud provider, any external service providers, and you — usually collaboratively developed across all parties.
Useful for internal scoping, vendor selection, and contracting discussions. Not, on its own, sufficient for a CMMC assessment — assessors will ask for the customer-specific document next.
Customer Responsibility Matrix
The contract-specific document. Authored by each external service provider, identifying exactly which responsibilities the customer must fulfil for the service to support compliance. One CRM per ESP, ESP-authored, customer-validated.
This is what a C3PAO opens first. Required by 32 CFR 170.19(c)(2)(ii) for any service used to satisfy a NIST SP 800-171 control. If you use Microsoft 365 GCC High, you need Microsoft's CRM. If you also use an MSP, you need theirs too.
We configure the controls and write the CRM. Inside your tenant.
For contractors who'd rather not work through 320 assessment objectives themselves — configuring each customer-side control across the cloud platform, the MSP stack, every ESP — and then write the CRM that proves it. We do both ends.
What you get back: customer-side controls actually configured in your tenant, plus a CRM mapped per assessment objective for every external service in your boundary. SSP language. Evidence pointers tied to live configurations. Fixed fee. Your CUI never leaves your environment.
Talk about your CRMWalk your boundary. List every ESP.
One-hour scoping call. We list every service that touches CUI — cloud platform, MSP, email, file share, EDR, SIEM. Nothing gets forgotten.
Pull provider CRMs. Configure customer-side controls.
We retrieve each ESP's CRM — Microsoft, AWS, your MSP — and reconcile against the 320 assessment objectives. Then we configure the customer-side controls in your tenant: Conditional Access, audit, DLP, identity, the rest. Evidence captured as it lands.
Hand back a single CRM. Assessor-ready.
One document, mapped per assessment objective, with SSP language and evidence pointers. Lift the language into your System Security Plan. Your C3PAO opens it and starts checking, not asking.
Most contractors arrive at assessment with the SRM their cloud provider published and call it done. Then the assessor asks for the CRM — the version specific to their tenant, with evidence — and the engagement stalls. The matrix is the map. Someone still has to do the work.
Deepak Singh · Founder & Principal · Ancitus
Q01 Why does your matrix show one inherited control on GCC High when Microsoft says fifty-three?
Different definitions of inherited. Microsoft's product placemat counts a control as inherited if the platform contributes to meeting it. A C3PAO's stricter view: inherited only when the platform handles it end-to-end and the customer has nothing left to configure, document, or evidence. Most "inherited" entries on the placemat still need customer work, so we label them shared. We use the assessor's definition because that's the one that decides whether you pass.
Q02 Can my MSP write our CRM for us?
Your MSP can write their CRM — the document describing what their service handles for you. They can't write yours. Each ESP authors their own CRM, and you reconcile all of them against the 320 assessment objectives in your SSP. If you have GCC High, an MSP, an EDR vendor, and a SIEM provider, that's four CRMs to align. Most contractors don't have someone doing that reconciliation, which is the gap we fill.
Q03 Do we still need a CRM if we're self-assessing at Level 1?
If you only handle FCI and you're at Level 1, the bar is lower — but if any external service supports those 17 basic controls, you still need to know who owns what. Level 2 contractors handling CUI need full CRMs regardless of self-assessment vs. C3PAO. Phase 2 enforcement on 10 November 2026 makes third-party assessments mandatory for many Level 2 solicitations, and the CRM is the first artefact opened.
Q04 How long does a tenant-side configuration plus CRM take?
Typical engagement is 4–6 weeks for a single-tenant GCC High deployment with two or three ESPs in scope. Wider boundaries take longer. Fixed fee, scoped after the discovery call. Your CUI stays in your environment throughout — we work inside your tenant via the access controls you provision, not by exporting data.
Take the matrix. Or talk to us about the CRM.
Both options. No funnel tricks. The matrix is free regardless of whether you ever speak to us.
Get the controls configured. Get the CRM.
30 minutes. We'll scope your boundary, walk through your ESPs, and tell you what implementation looks like and roughly what it costs. The person you talk to is the person doing the work.
Book a discovery callDownload the matrix
One XLSX. Four tabs (one per platform). All 110 controls with SSP-ready language. Lift it straight into your documentation.
Download (XLSX, 48 KB)