Embedded Files
Universities that run a regulated research enclave rarely run every piece of it themselves. Identity may come from central IT, workloads from a cloud provider, monitoring from a managed security provider, door access from a facilities group, and the handling of paper and portable media from researchers.
Each of those relationships touches a CMMC requirement.
An assessor can only mark a requirement MET when every party’s piece of it is described, owned, and demonstrated. This edition of Ask the Assessor looks at how shared responsibility is assessed, what documentation should be in place, and what assessors expect in three common university scenarios.
RRCoP Community Question to the Assessors
How are shared responsibilities assessed during an assessment?
We’re asking about both external service providers to the university (e.g., Cloud Service Providers) as well as internal university service providers.
Why are we asking?
Many universities have centralized services that an enclave leverages, such as identity, as well as third-party services that may support both the university and the enclave. Some of these are managed by a different university team than the one managing the enclave, some are managed by the same team, some responsibilities are carried out by researchers, and some are managed by outsourced third parties. All combinations exist.
We also asked the assessors to help us understand:
What is the best way to document who is responsible for what?
What should we ask for from our service providers, whether internal or external?
How should we document situations where we rely on end users or researchers to implement a control?
How complete should shared responsibility documentation be, and what should it contain to demonstrate that a control is holistically implemented?
published: October 2026
[RRCoP Question and Use Cases] [View & Download Full Fraizer & Deeter Responses]
Assessor Response:
HOW SHARED RESPONSIBILITIES ARE ASSESSED
C3PAOs do not score a requirement based on who owns it. Instead, we assess whether all applicable assessment objectives are satisfied and supported by adequate evidence. A shared practice is MET only when each party’s responsibility is described, assigned to a named owner, and demonstrated. Pointing at a provider and saying “they handle that” does not meet the bar.
Scope drives the rest. Not every third party or university service supporting the environment is automatically an External Service Provider (ESP). Whether a provider is treated as an ESP depends on the services it performs and how CUI or Security Protection Data is handled.
Likewise, centralized university services may support an assessed enclave without bringing every function or asset within that department into scope. The people, processes, technologies, and facilities used to satisfy CMMC requirements for the enclave need to be accounted for and assessed as applicable.
How we look at each type of party:
External cloud providers: If the environment stores, processes, or transmits CUI, we expect FedRAMP Moderate authorization or documented equivalency, plus the provider’s customer responsibility matrix. We read that matrix against your SSP and check that every responsibility the provider hands back to you is accounted for on your side.
External security and managed service providers: Providers that only deliver security functions, such as monitoring or managed endpoint protection, are in scope for those functions. We look for a service description tied to specific practices, evidence the work is performed for your environment, and someone who can speak to it.
Internal university services: Central identity, networking, and facilities teams are held to the same standard. A written service agreement or Memorandum of Understanding (MOU) is not required, but it gives everyone something to point to when ownership is unclear.
Researchers and end users: These are users carrying out your policy within your environment, not service providers. We look at how you set expectations and how you confirm they are being followed.
Documenting Shared Responsibility
A responsibility matrix is one of the clearest ways to document shared implementation. For an in-scope ESP, this is typically the provider’s Customer Responsibility Matrix (CRM). For internal university services, a similar shared responsibility matrix can be used to document which CMMC requirements or assessment objectives each party supports, how they are implemented, and where supporting evidence is maintained.
Where responsibility is split, it says who does which part. A statement like “Central IT provides MFA” is too vague. We want to see something closer to “Central IT enforces MFA through the identity platform for the enclave application group, and the enclave team controls which accounts are in that group and reviews membership quarterly.”
Describe the same thing in the SSP, since that is where we start reading.
From every provider, internal or external, ask for:
A service or responsibility description that maps to the requirements they support.
Their policies and procedures for those requirements.
Configuration or operational evidence that shows the practice working, such as screenshots, exports, tickets, and logs.
A named person who will take part in the assessment.
For cloud providers that handle CUI, the FedRAMP Moderate authorization (or equivalency documentation) and their CRM.
Applicable contracts, SLAs, MOUs, or other agreements that support the documented responsibilities, including security or incident-reporting obligations where relevant.
Where you rely on end users or researchers to carry out a control, document it differently. The control is still yours, so write the expected behavior into a procedure, get a signed acknowledgment from each person, and describe how you verify it.
In the matrix, list the researcher as the performer and the enclave owner as accountable, and point to the training records, inventory, or spot-check results that prove it is happening.
How Complete Is Complete Enough?
For each CMMC practice, the documentation should say who performs which part, how they perform it, and where the evidence lives. It should also say how the pieces connect, so that someone reading it can follow a requirement from the policy statement to the person doing the work to the evidence that proves it.
Complete enough that someone who has never seen your environment could trace any practice from the requirement to the people and evidence behind it. For in-scope third parties, we expect real evidence from the service provider or a walkthrough with their staff. A generic SOC 2 report or marketing sheet does not do that. For practices you have delegated to researchers, show how you communicated the expectation and how you check that it is happening.
The test we apply is simple. Pick any practice at random and ask whether the team can show the requirement, each party’s piece, the person who performs it, and the evidence, without anyone saying “I think that’s handled by another team.” If so, the documentation is complete enough. If we have to chase answers across three teams during the assessment, it is not.
RRCoP Community Shared Responsibility in Practice
Example 1: Cloud Provider + MSSP + University Facilities
An enclave at a university leverages a third-party cloud provider as well as a managed (security) services provider (MSP/MSSP), but the enclave system owners manage personnel, and a facilities team manages the physical security of campus.
We asked: What documentation does an assessor expect from each party? Who needs to participate in the assessment?
Assessor Response
Each party owns a different slice, so we look at each one differently.
Cloud provider: FedRAMP Moderate authorization or equivalency and the CRM, as described above. The service provider’s staff generally do not join the assessment. We rely on the authorization package and your evidence of your own configuration. The most common gap we find is a customer responsibility in the matrix that nobody has picked up on the university side.
MSSP: What we ask for depends on what they touch. If they handle CUI, the cloud provider expectations apply to them too. If they only provide security functions such as monitoring, a SIEM, or managed endpoint protection, they are an ESP and in scope for those functions. We expect a service description that ties to specific practices (audit review, incident response, vulnerability scanning), evidence they perform those tasks for your enclave, and an agreement that covers incident reporting. Someone from the MSSP who understands the service should be available to answer questions.
Enclave system owners: Personnel security, awareness training, and related practices belong to the university, so expect normal interviews and document review covering screening, termination procedures, and training records.
Facilities team: They are internal, so they are in scope for the physical protection practices. We look for physical access procedures, a way to review who has access, visitor handling, and key or badge management. We expect a walkthrough of the relevant spaces and a conversation with someone from facilities who actually runs those processes. A note from the system owner saying facilities handles it will not be enough.
Who participates: the enclave owners and the staff doing the daily work, a representative of the MSSP, and someone from facilities.
RRCoP Community Shared Responsibility in Practice
Example 2: Cloud Provider + Central University Identity
An enclave at a university leverages a third-party cloud provider, and the enclave system owners manage the environment, but leverages the university’s larger identity system with MFA.
We asked: What documentation does an assessor expect from each party? Who needs to participate in the assessment?
Assessor Response
The cloud provider piece is the same as in Example 1. The identity system is the more interesting part. If the university identity platform authenticates enclave users, it supports a security function and is in scope for the practices it provides.
We assess it against what it actually does for the enclave: the MFA practices, account management, and the audit logging it generates. We do not assess everything else the campus identity platform does, but your SSP needs to draw that boundary clearly so the scope does not grow beyond what is needed.
We would expect:
Documentation showing how the identity platform enforces MFA for the enclave. A conditional access policy or authentication rule applied to the enclave’s applications works well.
Evidence that the policy is applied with no exemptions. We commonly ask to see the policy live and test an account.
Documentation of who administers the identity platform, who can change the policy, and how privileged identity accounts are controlled.
Your side of the matrix: who approves enclave accounts, how access is removed, and how group membership is reviewed. The identity team cannot do these for you.
Evidence of where identity logs go and who reviews them, since those logs often belong to the identity team but matter to your audit practices.
Who participates: the enclave system owners and a knowledgeable person from the identity team who can demonstrate the policy and answer questions. If the identity team treats the assessment as someone else’s problem, that is a real risk to your timeline. Bring them in early and make sure they know they will be asked for evidence.
RRCoP Community Shared Responsibility in Practice
Example 3: Researchers + Physical CUI and Portable Media
An enclave at a university is managed by enclave system owners, including endpoints, but relies on the researcher(s) to manage physical CUI and portable media containing CUI.
We asked: What documentation does an assessor expect from each party? Who needs to participate in the assessment?
Assessor Response
Researchers here are not service providers. They are users carrying out your policy, and that changes what we ask for.
You cannot hand a control to researchers and leave it there. The practices for media handling, physical protection, and portable storage are still yours, and you have to show they are being carried out. Researchers are where the practice is performed, but the enclave owner is accountable for it.
We would look for:
Written procedures that tell researchers exactly what to do: how to mark, store, transport, and sanitize or destroy physical CUI and media.
Training and acknowledgment, such as a signed responsibility statement, so there is proof each researcher knows their duties.
An inventory of where physical CUI and portable media are held, and a method for keeping it current.
Oversight. Spot checks, a recurring attestation, or a review of storage spaces all work. We want to see that you verify and do not just assume.
Technical safeguards where they apply, such as encryption on portable media.
Anything holding CUI, including a researcher’s office, a locked cabinet, or a USB drive, is part of what we assess. Expect us to inspect representative storage locations and interview researchers who actually hold CUI.
We do not need every researcher, but we need a fair sample, and a researcher who cannot explain how they protect the material will hurt you more than a missing document.
Who participates: the enclave system owners and a sample of researchers with CUI responsibilities, with preference for those holding physical CUI or portable media.
Summary From the Assessors
Across all three examples, the assessment goes better when ownership is written down before the assessor arrives.
Gaps in shared responsibility rarely come from a control nobody implemented. They come from a control each party assumed the other one covered.
For more information, Contact: Bob Woosley | Frazier & Deeter National Practice Leader | bob.woosley@frazierdeeter.com
Frazier & Deeter FULL Responses
Ask_the_Assessor_October_2026_2.pdfPage updated
Google Sites
Report abuse