How it actually works
The program is built and operated in the tenant you already own: where the boundary sits, the grain an assessment is scored at, and how the record is kept.
Each configuration item we manage knows three things about itself: how it is assessed, how it is deployed, and how it is documented.
The mechanisms
Each mechanism here carries enough detail to argue with.
Whose environment is it, and where does the CUI actually sit
Your own estate is what the first question decides: how much of it an assessor has to walk through.
Your assessment scope is drawn around the systems holding the regulated data. The answer is therefore not a matter of taste. It decides how much of your environment an assessor has to look at, and it decides how much of your provider the assessor examines with it.
32 CFR §170.19(c); CMMC Scoping Guide — Level 2, v2.13.
Enclave models answer by moving the data into a space the provider owns and rents back. The boundary lands on the provider's side. Everything follows from that: the provider now holds regulated data on its own systems. It must then meet the FedRAMP requirements for a cloud provider, or have its services examined inside your assessment.
Your tenant and your data are yours from day one, and everything we build runs on Microsoft 365's own tools inside it. The design keeps your CUI in your own tenant, not on our systems. Under the CMMC rule, a provider whose systems hold your CUI either meets FedRAMP requirements as a cloud provider or has its services examined as part of your assessment. Certifying the provider itself is voluntary (32 CFR 170.19(c)(2)). Our services and people sit inside your assessment scope — your SSP, your Shared Responsibility Matrix, and your assessor interviews.
The other answer leaves the boundary where it already is. Your tenant stays the tenant. The work happens inside it, under your ownership, and the provider is assessed as part of your scope rather than alongside it.
Your environment, your data, your documentation — we operate within your tenant and never own it.
You do not have to trust a description of our conduct. You can answer where things are from your own side of the boundary.
The difference shows up twice, and the second time is the expensive one. It shows up at the assessment. It shows up again at the end of the engagement, because whoever owns the environment is the one still holding it afterwards.
Consolidating CUI into a FedRAMP-authorized cloud environment can often be assessed remotely, typically avoiding on-site travel — the C3PAO makes the determination; the design places your CUI boundary in your own cloud tenant.
The environment keeps running when we stop. The tenant stays where it is, under your own administrators.
Leaving does not mean moving — the environment stays where it is and a successor is granted access to it, because the tenant was never ours to hand over.
The documentation is the part that is easiest to assume you are renting. You can read that against the contract in front of you, because documentation you cannot take with you was never yours to begin with.
The system security plan, the POA&M and the responsibility matrix are delivered as final documents you own outright — not as a licence to read ours.
The documentation you are left holding decides whether the next assessment starts from something or from nothing.
The environment transfers intact. The reasoning does not, and you should know that now rather than find it out later.
What does not transfer is the reasoning behind each decision — a successor inherits the environment intact and still has to relearn why it was built the way it was.
The environment stays yours whatever else happens. That is the part of this you can settle before you sign anything, and it is the reason the rest of this page is worth your time.
The thirteen requirements no query can answer
Your tenant can answer most of Level 2 by query. It cannot answer these thirteen, and they are where readiness programs quietly come apart.
Every check is written down before it is trusted: a name, a place to look, and the value expected there — so evidence collection is enumerable and independently checkable.
97 of the 110 Level 2 requirements are evidenced from the tenant; 5 of those are physical protection, inherited from the cloud platform. The other 13 are covered by formal attestation artifacts.
Others cannot be settled that way at all. Nothing in a tenant establishes that training happened, that people were screened, or that an incident response was rehearsed. Those are activities somebody performed, and the only evidence they leave is the evidence somebody deliberately produced at the time.
| Family | Requirement | What the activity actually is |
|---|---|---|
| Awareness and Training | AT.L2-3.2.1 | Role-specific security training actually delivered, to named people, on dated occasions. |
| Awareness and Training | AT.L2-3.2.3 | Insider-threat awareness delivered and recorded, not merely mandated by a policy. |
| Security Assessment | CA.L2-3.12.1 | A periodic assessment of the controls themselves, performed and written up. |
| Security Assessment | CA.L2-3.12.2 | A plan of action that is actually worked and updated, rather than authored once. |
| Security Assessment | CA.L2-3.12.3 | Ongoing monitoring of the controls, with the monitoring itself evidenced. |
| Security Assessment | CA.L2-3.12.4 | A system security plan kept current as the system changes. |
| Incident Response | IR.L2-3.6.2 | Incidents reported to the right authorities, within the window, with the reporting evidenced. |
| Incident Response | IR.L2-3.6.3 | The incident response actually exercised, with an execution record from the exercise. |
| Maintenance | MA.L2-3.7.2 | Maintenance controlled and approved, with a record of what was done and by whom. |
| Maintenance | MA.L2-3.7.4 | Media checked for malicious code before it touches the system. |
| Maintenance | MA.L2-3.7.6 | Maintenance personnel supervised, with the supervision recorded. |
| Media Protection | MP.L2-3.8.8 | Portable media without an identifiable owner kept off the system, and that rule enforced. |
| Personnel Security | PS.L2-3.9.1 | Individuals screened before access is granted, with the screening evidenced. |
This is where most programs fail, and the failure is rarely dramatic. The work happened. Nobody wrote down that it happened, in a form anybody else can read, before the memory of it went stale.
CMMC Assessment Guide — Level 2, v2.13; NIST SP 800-171A determination statements.
The standard is simple, even if you never hire anyone. Evidence is not a category. Naming the artifact turns an assertion into something an assessor can pick up and test.
An attestation names the party who performed the activity, the period it covers, and the specific supporting record — and is signed by the provider, the client's System Owner, and the client's Authorizing Official.
The grain of proof
Your assessment is decided at a finer grain than most compliance work is organized by. That difference comes from the published scoring rules, and the work here is organized to match them.
CMMC Assessment Guide — Level 2, v2.13; NIST SP 800-171A determination statements.
CMMC Assessment Guide — Level 2, v2.13, p10.
NIST SP 800-171A §2.1; CMMC Assessment Guide — Level 2, v2.13, p9.
NIST SP 800-171A defines the assessment objectives under each of the 110 Level 2 requirements — 320 objectives in all — and a requirement is not met if any one of its objectives is not met.
Evidence, responsibility, and narrative are bound at the assessment-objective level — the grain the assessment is scored at — with 2,735 per-objective evidence bindings across the 320 objectives in one reference build, each naming what is examined, interviewed, or tested.
Responsibility is resolved per objective, not per control — for every one of the 320 objectives, the record states what the cloud platform inherits, what stays with the customer, what a provider shares, and what is split.
The system security plan is written at the same grain: a subsection for every assessment objective, not one narrative per control.
You can ask, for any single objective, who answers for it, what evidence carries it, and where the written plan addresses it. The difference has nowhere to hide when the record is kept at the grain being scored.
The traceability chain is walked in both directions — down from assessment objective to evidence when the documentation is authored, and up from evidence back to objective when it is validated — and both directions have to produce the same answer.
The life of the record
Your record is not prepared for a season. It is compiled through gates that refuse to render a not-ready document, kept current by live checks, and changed through governed channels — a loop, not a line.
A document that fails its readiness gate is not generated — a missing value is a build failure, not a blank in the deliverable.
All of it is live and always ready to generate — and a document that would fail is simply never generated.
A version change is a transaction, not a file edit — the approval record, the re-render of every document that cites it, and the archive of the prior version happen together or not at all.
NIST SP 800-128 — Guide for Security-Focused Configuration Management of Information Systems; NIST SP 800-171, §3.4 (Configuration Management).
The documentation does not decay between assessments; it converges on reality, and every correction carries its date.
When live checks find that reality moved, the documented value is updated with a dated history entry — the documentation converges on reality on a schedule instead of decaying between assessments.
When the record is compiled ready and kept current, the assessment stops being an event you prepare for — it is a Tuesday.
A client-specific deviation is never an edit to the shared baseline — it lives in its own override, and every entry carries a reason, an approver, and a date.
A sealed record verifies with a standard PDF reader, offline, against a published root — no provider system in the loop, and the embedded time is attested by a third party the provider does not control.
IETF RFC 3161 — Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP).
The last step in a deployment, and why it is the one to ask about
Any provider can run a deployment. What happens at the end of one is where they differ.
The catch is self-report. The claim comes from the same thing that did the work, so the claim and the work share a blind spot.
The difference is between asking the tooling and asking the tenant. The tenant answers the question that will actually be put to you.
The deploy sequence ends in a verification gate that reads the tenant's actual state rather than the deploy scripts' exit codes, and fails the run when what was built does not match what was specified.
What gates the work before you see it
Deliverables clear a quality gate before delivery, the package is pinned to a named guide version, and even inherited claims trace to a checksummed source.
-
Deliverables pass a quality gate before delivery — a document carrying placeholder text does not ship as final — and the same class of checks that gates client deliverables gates this website.
-
Each engagement's documentation package is pinned to a named version of the official assessment guide, so when the guide moves, the difference is explicit rather than silent.
-
Authority documents are stored with their content hash — even a claim inherited from the cloud platform is pinned to a checksummed source document.
What a review cycle produces in a month when nothing goes wrong
Your record at the end of a month is the difference between a control that is operated and one that was only ever implemented.
A quiet month has to leave a trace anyway. Without one, the record is somebody's word for it, offered later, when it needs to carry the most weight and can be checked the least.
Controls run month over month with attributable, tamper-evident change records.
So the month is built to end in a record rather than in a report. The reports are the input. The record is what one particular person did about them.
Before a review report reaches a client, it passes a pre-send review for how it reads to a non-specialist — findings are logged and tracked to resolution, and a serious finding stops the send.
The client's Authorizing Official approves the evidence package in writing, from the client's own mailbox. The approving reply is recorded by its message id on the approval ledger, and every sealed record in the engagement resolves to the approval that authorized it.
The acknowledgment does not come from the provider. It comes from the client's own Authorizing Official, so the record is a statement by the party carrying the risk rather than by the party being paid to reduce it.
The artifacts that carry the most risk — the plan of action, a risk acceptance, an incident record — take two acknowledgments before the record is sealed, not one.
Every finding traceable to a claim-and-evidence pair; remediation ships as Evidence of Done.
Where this goes next
Your contracts already decide which of the mechanisms above reaches you, and a scoping conversation is where that gets read.