'Our MSP handles that' is the start of an answer, not the answer. In the CMMC ecosystem the services a provider performs and the assets it touches are examined as part of your assessment scope, so the finishing move is always evidence in your hands: a standing package the provider delivers on a schedule (its own security posture and personnel access model, subcontractor and tooling disclosures, incident-notification terms with a clock, backup and restore-test results, vulnerability and patching summaries scoped to your environment, and access recertification for its technicians), a per-service responsibility matrix with the evidence hand-off named, and contract terms that survive the relationship ending. This article is the ask-list, the cadence, and the red flags — with the provider's view of each item in the toggles.
You can outsource the work, not the accountability
Most small and midsize defense contractors run their systems through a managed service provider, and much of the work named in NIST SP 800-171 is genuinely better done by one: patching at scale, monitoring around the clock, backup infrastructure, identity administration. None of that moves the obligation. Your contracts carry the requirements, and in the CMMC ecosystem the services an external service provider performs and the assets it touches are examined as part of your assessment scope — how those services and assets are treated is determined by the current CMMC scoping guidance and the assessor, not by what either party assumed when the service agreement was signed.
'Our MSP handles that' is therefore the start of an answer, not the answer. It names who operates the work; it says nothing about whether the work happens, whether anyone can show it happening, or who holds the record. The finishing move — the part only you can perform — is evidence in your hands: filed, dated, and producible without the provider's goodwill on the day someone asks.
This article is written to the buyer — the OSC, the Organization Seeking Certification, whose contracts carry the requirements. But every ask lands on a provider's desk, so the recurring toggle sections read the same ground from both chairs: the OSC pane is what to ask for and how to judge what comes back; the ESP pane is the provider's view — what a good provider hands over unprompted, and how to say yes efficiently. Pick a seat once; the choice applies to every toggle on this page and is remembered in this browser, and both versions are in the page if you print it.
Nothing here asserts what the CMMC program requires of your specific environment today — the treatment of provider assets, the state of rulemaking, and which revision your contracts reference are all moving parts. Read your contracts, defer to the current CMMC scoping guidance and the assessor, and track the moving pieces on the policy status page.
The standing evidence package: what arrives without being chased
The single most reliable maturity signal in a provider relationship is whether evidence arrives on a schedule, without being requested. A provider that has been through client assessments before knows what the questions will be and delivers the answers as a subscription. A provider that has not will treat every request as a special project — and the delay you experience in month three of the relationship is the delay you will experience at assessment time, with stakes.
The package worth asking for covers six things:
- The provider's own security posture and personnel access model — how its staff authenticate into your systems, whether accounts are named per technician, and how the provider's own environment is secured. Your provider's administrative credentials are among the most dangerous objects in your environment, and how they are protected is your business.
- Subcontractor and tooling disclosure — the RMM platform, the ticketing system, the after-hours NOC, any offshore delivery center. These are inside your supply chain whether or not anyone wrote them down; Rev. 3's supply chain family (03.17.03) is aimed at exactly this kind of unexamined dependency.
- Incident-notification terms with a clock — a written commitment to notify you of incidents affecting your environment or your data within a defined timeframe. 'We would obviously tell you' is not a process; a clause with a number in it is.
- Backup and restore-test results — not backup success alone, but restore tests with dates, scope, and elapsed time. Recovery is proven, not assumed; this is the operating heart of a resilient backup and disaster-recovery practice.
- Vulnerability and patching summaries scoped to your environment — completion by ring and platform, deferrals with their compensations, and aging against the response times you declared. A multi-tenant aggregate tells you about the provider's book of business, not about you.
- Access recertification for the provider's technicians in your systems — a periodic export of who can touch your environment, reviewed on a cycle, with reductions actioned and the provider's own accounts included in the review.
The tracking instrument for all of this already exists on this site: the ESP client evidence package checklist is a register built for exactly this hand-off, usable from either seat. It seeds a twelve-item starter package — each row naming the item, what it demonstrates, its cadence, and its format — and wraps the table in the delivery mechanics that make the stream real: retainable files rather than portal access, screening that keeps other tenants' data out of your reports, a client acknowledgment closing each cycle, and a quarterly delivered-versus-agreed reconciliation. It ships in print, Markdown, and CSV forms, the last as an acknowledgment register you can file deliveries against.
As the buyer, your job is to turn this list into an agreed register and then hold delivery to it — the asking is one meeting; the judging is a filing habit you keep every month afterward.
- Agree the package once, in writing: item, cadence, format, and who produces it. Strike what the service does not cover — an honest 'not included' beats a silent gap you discover at the worst moment.
- Insist on files you can retain, delivered to a location you own. Evidence you cannot file is evidence you do not have, and a portal login is not an archive.
- Judge the stream, not the promise: numbers should move month to month, and bad news should appear. A package with no deferrals, no missed windows, and no investigated alerts is describing a fictional environment.
- Acknowledge each delivery and keep the acknowledgment — the loop protects both sides, and it becomes your oversight record when someone asks how you monitor the provider.
From the provider's seat this list is not a burden — it is a product specification. Build the package once as a service artifact, generate it per client from the same pipeline, and the fiftieth client costs little more than the first.
- Hand the package over unprompted, on a stated cadence — arriving with it before the client asks is the cheapest trust you will ever buy.
- Screen every report before it leaves: no other client's names, hostnames, ticket numbers, or aggregate metrics from which another tenant is identifiable. One cross-tenant leak in an evidence package is an incident, not a formatting nit.
- State gaps instead of skipping them: a cycle where an item cannot be produced ships with a one-line reason and a make-up date.
- Keep your own delivery and acknowledgment records — they are your evidence that the service ran, in renewal conversations and in disputes.
Every item above should land as a retainable file — an export, a report, a signed record — in a location the client owns. Dashboard access is a view, not a record: it disappears with the relationship, and it proves nothing about what was true last March.
The responsibility matrix: who does what, in writing
Underneath the evidence stream sits a more basic document: per service, who does what, for each requirement family, with the evidence hand-off named. Rev. 3 sharpens the expectation — its external-services requirement language looks for providers bound to your security requirements, responsibilities defined on both sides, and you overseeing the provider's performance — but the document earns its keep under any revision. The MSP responsibility matrix on this site is the working version: we-do / you-do / shared, family by family, with the column most matrices skip — who evidences each row.
The matrix is also a diagnostic. A provider who cannot produce one is telling you the service has never been mapped against the requirements your contracts carry. A provider who produces one that has never been reviewed with you is telling you where the gaps live — every row filled in unilaterally is an assumption, and unexamined assumptions cluster exactly where responsibility is least clear: log retention, parameter choices, incident hand-offs, and the practices that sit between named owners.
As the buyer, treat the matrix as a two-party document with a review date, not a PDF the provider attached to the proposal — completing it together is where the real shape of your service becomes visible for the first time.
- Complete it in one sitting, together, per service line — the conversation surfaces more gaps than the finished document ever will.
- Chase the evidence column hardest: for every 'we do' row, ask what you receive, how often, and in what format. That column, filled in, becomes the standing package above.
- Review it annually and at every service change; a matrix describing last year's service shape is a map of the wrong territory.
- Where a row says 'shared', ask for one more sentence naming which half is whose — 'shared' with no split is how asset inventory, vulnerability management, and backup end up with two owners and no owner.
From the provider's seat, the matrix is the document to author before any client asks — per service line, versioned, and honest about boundaries. The provider who arrives with a clear split beats the one who makes each client reverse-engineer it.
- Publish it per service tier, not per client — then record per-client deviations as a short addendum instead of maintaining fifty divergent documents.
- Say what the service does not cover, in the matrix itself. The client's assessor will find the boundary with or without you; better it comes from you, early and in writing.
- Review it with each client annually and version the changes — a matrix that quietly drifted from the service is worse than none, because it is confidently wrong.
- Wire each 'we do' row to a package item: a matrix row with no evidence stream behind it is a claim, not an implementation.
Contract terms that actually matter
The matrix records intent; the contract records what you can insist on when intent runs out. Five terms do most of the work, and all five are cheapest to raise at renewal, while the relationship is good and the leverage is mutual:
- Incident notification with a defined timeframe — notification of incidents affecting your environment or your data within a stated number of hours, with the clock's starting point defined. Without a number, notification happens on the provider's schedule — and during an incident, that is the busiest schedule in the building.
- Data location and return — where your data lives, including inside the provider's tooling and backups, and its return in usable form on request and at exit.
- Subcontractor disclosure and change notice — who else touches your environment, and advance notice when that roster changes. Your supply chain obligations reach through the provider to the provider's providers.
- The right to receive evidence at assessment time — named cooperation when an assessor examines provider-operated services: responses within a stated window, participation in interviews if asked, and delivery of the records the engagement generates. A provider surprised by this clause is planning not to be in the room.
- Offboarding — return of administrative ownership of your tenants and systems, hand-over of every credential the provider holds, export of logs and configurations in standard formats, and a deletion attestation for what stays behind. The exit is negotiated at the start, while everyone still likes each other — or it is negotiated never.
As the buyer, you rarely get these terms by asking on the day you need them — put all five on the table at every renewal, and treat the provider's reaction to the offboarding clause as information about how the relationship will end.
- Raise terms at renewal, not mid-incident: mid-crisis is the worst negotiating position there is, and the notification clock you want must exist before the first incident, not after it.
- Ask for the provider's standard terms first — a mature provider has a clause library, and what is missing from it tells you what has never been tested.
- Get the offboarding procedure as a document, not just a clause: named steps, elapsed-time expectations, and what happens to backups and log archives after exit.
- Keep every executed agreement and amendment where your assessment team can reach it — the agreement itself is evidence relevant to the external-services requirements.
From the provider's seat these five clauses are predictable enough to prepare for — the efficient move is a standard rider you offer before being asked, priced honestly, rather than fifty bespoke negotiations entered defensively.
- Commit only to what you can operate: an eight-hour notification clock you honor beats a two-hour clock you miss, and a missed clock is a breach conversation.
- Price assessment-time cooperation into the service rather than treating it as a favor — it is billable, bounded, and increasingly the reason clients choose you.
- Build offboarding as a runbook you can hand over on request; nothing reassures a buyer like a provider unafraid of the exit.
- Disclose subcontractor changes proactively, on a defined notice period — discovered disclosure reads as concealment even when it was only disorganization.
Monthly, quarterly, annually: what the rhythm looks like
Cadence is what separates an evidence stream from an evidence pile. The exact schedule is whatever the two of you agree in the register, but a workable default looks like this:
| Cadence | What should arrive | What you do with it |
|---|---|---|
| Monthly | Patch completion by ring with deferrals; backup success plus any restore-test results; monitoring and log-review summary; vulnerability extract with aging against declared response times; identity-coverage numbers | File each item, acknowledge receipt, and read for movement — figures identical to last month's are a template, not a measurement |
| Quarterly | Access recertification export covering provider-managed and technician accounts; technician roster changes with rules-of-behavior acknowledgments; the delivered-versus-agreed reconciliation | Reconcile the quarter against the register: every item at or past its cadence has a delivery date and an acknowledgment, and every gap gets a reason and a make-up date |
| Annually | Responsibility-matrix review with sign-off from both parties; subcontractor and tooling confirmation; offboarding-commitment reconfirmation; package-composition review | Re-open the matrix and the register together — services drift, and the annual pass is where the paper catches up to the service |
The quarterly reconciliation is the keystone, and it is built into the evidence package checklist as a standing section: items agreed against items delivered, with gaps named, dated, and dispositioned rather than quietly skipped. It takes minutes per quarter, and it converts a stack of reports into a defensible oversight record — the artifact that answers 'show us how you monitor the provider' with dates instead of adjectives.
As the buyer, the cadence work is mostly a filing discipline — a short block of time each month and one brief quarterly meeting — and it is the cheapest insurance in this entire article, because it turns the provider's work into your record.
- Name one owner for the filing — whoever owns the provider relationship — and give the packages a permanent home your assessment team can reach without asking around.
- Put the quarterly reconciliation on the calendar as a recurring meeting with the provider: fifteen minutes, both parties initial the result.
- Let the annual pass be honest: strike items the service no longer covers and add what it now does, in the register, with a date beside the change.
From the provider's seat the rhythm is an automation problem: report generation wired to the delivery calendar, bundled per client, screened for tenant bleed, with your own delivery log serving as the service's institutional memory.
- Bundle to the cadence — one monthly package with a cover sheet listing contents against the register beats twelve loose emails to whoever opened the ticket.
- Automate the boring majority and hand-review the exceptions; the cross-tenant screening step is the one stage that never gets skipped.
- Treat a client who never acknowledges deliveries as a risk signal, not a relief — an unacknowledged stream will be remembered as an undelivered one.
Red flags: what you hear, and what it usually means
None of these answers is disqualifying on its own — busy providers say clumsy things — but each is a thread worth pulling, and a pattern of them is your answer. The third column is the polite version of the pull.
| What you hear | What it usually means | What to ask next |
|---|---|---|
| "We're SOC 2, you're covered." | A report about the provider's own environment, on the provider's chosen scope, is being offered in place of evidence about yours. | "Which of the services you run for us does that report examine — and what per-client evidence do we receive for the rest?" |
| "That report is internal-only." | The evidence exists, but you will not be holding it — which at assessment time is the same as it not existing. | "What client-releasable version can you produce, and on what cadence?" |
| "Everything is in the portal." | Access is being offered in place of delivery; when the relationship ends, so does your evidence. | "Can you deliver monthly exports to a repository we own?" |
| "Our team shares an admin account — it keeps things simple." | No per-technician attribution in your systems: you cannot say who did what, and neither can the provider. | "When can we move to named per-technician accounts, and what is the interim record of who used the shared one?" |
| "Our baseline handles all those settings." | Parameter decisions that are yours to make and defend are being made silently by a multi-tenant default nobody signed off on. | "Can we get the list of values enforced in our tenant, so we can ratify or change each one on the record?" |
| "No client has ever asked us for that." | You may be this provider's first client carrying these obligations — which means the evidence pipeline you need does not exist yet. | "How many of your clients hold DoD contract clauses like ours, and what do you deliver to them today?" |
| "We'll pull all that together if you ever get assessed." | Evidence produced on demand is reconstruction, not record — and the operating history that cannot be reconstructed is the part assessors weight most. | "What can you deliver on a standing monthly cadence, starting next month?" |
The common thread is the direction of custody. Every deflection above keeps the record on the provider's side of the table; every good answer moves it to yours. A provider can be excellent at operations and still fail you here — what these rows probe is not whether the work happens, but whether you will be holding proof that it happened on the day it counts.
The finishing move — and a word for the provider reading this
The whole discipline compresses to one sentence: for every service you buy, know who does the work, hold the evidence that it happened, and rehearse the exit. The matrix answers the first, the standing package the second, the contract terms the third — and the cadence is what keeps all three true next year, not just the week the documents were signed.
If you are the provider — the MSP or MSSP whose desk these asks will land on — this entire article has a mirror image written for your seat: the ESP Rev. 3 readiness guide covers the same ground as a service-design problem — the reusable evidence package, per-client parameter handling, and how to turn everything above from an interruption into a product line. The clients worth keeping are about to start asking for all of it; the providers worth keeping will have already answered.
The Rev. 3 shifts that make provider evidence urgent — the new supply chain family, organization-defined parameters, and the sharpened external-services expectations — are mapped in the Rev. 3 overview, and every requirement named here links into the full Rev. 3 mapping.
Sources
- NIST SP 800-171 Rev. 3 — Protecting CUI in Nonfederal Systems (May 2024) ↗
- NIST SP 800-171A Rev. 3 — Assessing Security Requirements for CUI (May 2024) ↗
- NIST SP 800-161 Rev. 1, Update 1 — C-SCRM Practices (November 2024) ↗
Cloud consoles and federal guidance change; confirm control text and clause language against the official publication that applies to your contract. This article is independent education and does not by itself establish compliance or confer CMMC certification.