Shared Responsibility for a Mac Fleet: What Your MSP Owns

Quick answer: your assessor assesses you, not your MSP. An external provider can implement a requirement on your behalf and it still counts, but only if you can produce evidence that it was implemented. A responsibility matrix that says "MSP" next to a requirement and nothing else is not evidence.

What does the rule require you to document?

32 CFR 170.16 requires External Service Provider relationships to be documented in the System Security Plan. Where a cloud provider supplies a customer responsibility matrix, those items must be documented or referenced in the SSP too.

The CMMC Assessment Guide is encouraging about who does the work. Satisfaction of security requirements may be accomplished by other parts of the enterprise or by an External Service Provider. A requirement is considered MET if adequate evidence is provided that the enterprise or ESP implements the requirement objectives.

Read the condition carefully. Adequate evidence, provided. The delegation is permitted. The evidence obligation does not transfer with it.

Is your MSP an ESP or a CSP?

32 CFR 170.4 defines an External Service Provider as "external people, technology, or facilities that an organization utilizes for provision and management of IT and/or cybersecurity services on behalf of the organization." A Cloud Service Provider is "an external company that provides cloud services based on cloud computing."

Most Mac-focused MSPs are ESPs. Some are also CSPs, usually because they resell or operate a hosted platform. The distinction is worth getting right, because the two paths diverge sharply.

Under 32 CFR 170.16(c)(3)(ii), where a non-CSP ESP is used, "the ESP services used to meet OSA requirements are assessed within the scope of the OSA's assessment against all Level 2 security requirements." That is the full set, not a subset. Compare that with a Security Protection Asset under 170.19(c), which is assessed only against requirements relevant to the capabilities provided.

And the FedRAMP question is separate again. It attaches under DFARS 252.204-7012(b)(2)(ii)(D) only where a cloud service provider stores, processes, or transmits covered defense information. We worked through that in does your Mac MDM need FedRAMP authorization.

Who owns the macOS baseline?

This is where most matrices go vague. NIST SP 800-171 Rev 2 requires you to "establish and maintain baseline configurations and inventories of organizational systems," and separately to "establish and enforce security configuration settings for information technology products employed in organizational systems."

Those are two different jobs and they often sit with two different parties. Selecting the baseline is a decision about risk and business need. Enforcing it is an operational task an MSP can absolutely own. Deciding to deviate from it is a decision only you can make.

Write it down that way. Baseline selection, enforcement, and deviation approval as three separate rows, with a named owner for each.

Who owns evidence collection and retention?

The most commonly orphaned pair. An MSP is happy to run vulnerability scans under RA.L2-3.11.2 and patch under SI.L1-3.14.1. Fewer are contractually obliged to retain the dated output for as long as you need it, and almost none are obliged to hand it over on the timeline an assessment runs to.

Four rows worth making explicit for a Mac fleet:

• Who runs the activity, and on what cadence.
• Who retains the output, in what system, for how long.
• Who can produce it on request, and within how many business days.
• What happens at contract termination. Evidence you cannot retrieve is evidence you do not have.

That last row is the one people discover too late. Continuous monitoring evidence is covered in more depth in continuous monitoring for a macOS fleet.

What does a usable responsibility matrix look like?

One row per requirement, not one row per service. Requirement-level granularity is what an assessor works from, and a matrix organised by vendor offering cannot be mapped onto an assessment without a translation step you will end up doing under pressure.

Each row needs five fields: the requirement identifier, who implements it, who retains the evidence, where that evidence lives, and the date the arrangement was last confirmed. The last field is the one that keeps it honest, because MSP scope drifts and nobody sends a notification when it does.

If your provider will not commit to a row, that is useful information. It is much cheaper to learn it now than during a POA&M closeout. For the questions to ask before signing, see vetting an MSP or ESP for CMMC.

Sources

• 32 CFR 170.4 definitions; 170.16; 170.16(c)(3)(ii); 170.19(c)
• DFARS 252.204-7012(b)(2)(ii)(D)
• NIST SP 800-171 Rev 2, requirements 3.4.1 and 3.4.2
• CMMC Assessment Guide Level 2, v2.13

Verified against primary sources on August 1, 2026. This is not legal advice.