12 mins

MSSP Shared Responsibility Model: What Stays Yours in 2026

Last Updated

August 31, 2026

Key Takeaways:

The shared responsibility model for managed security is a three-way split: the cloud provider secures the platform, the MSSP operates detection and response, and the customer retains accountability for identity, data classification, asset inventory and the decision to act.
Four things never transfer under any contract: data classification, privileged identity ownership, asset inventory accuracy, and the authority to approve containment.
NIST SP 800-61r3 replaced the four-phase incident response lifecycle with six functions in April 2025, and the responsibility split reads differently under each one.
Evidence custody is contractual rather than automatic, and it decides whether an investigation survives a change of provider.
The duty to notify a regulator stays with you even when the incident starts at your provider.
Four contract clauses decide all of the above: scope, response authority, retention period, and exit terms.

Hiring a managed security services provider (MSSP) moves the work, not the accountability. Three things never move: the decision to act on what the provider finds, the accuracy of the asset and data inventory you hand them, and the duty to notify a regulator. The split is three-way rather than two-way, and the parts you keep are the parts nobody will remind you about

‍

The three-party split

Responsibility for a monitored environment divides three ways, not two: the cloud provider secures the platform, the MSSP operates detection and response on top of it, and you retain everything that requires a decision or a record. Most contracts document only the boundary between you and the provider, which leaves the second boundary, the one between the provider and the platform, undefined until an incident tests it.

Function	Cloud provider	MSSP	You
Log collection	Generates platform telemetry and exposes it through connectors	Configures and operates ingestion, monitors connector health	Decide which sources are onboarded and fund the retention
Detection engineering	Ships built-in analytics rules	Tunes rules, writes custom analytics, manages false positives	Approve any suppression that accepts a risk
Triage	None	Owns first and second line entirely	Supply the business context the provider cannot infer
Containment	Provides the control surface	Executes within pre-granted authority	Grant that authority in advance, own anything out of scope
Eradication	Platform-side remediation	Recommends and executes agreed actions	Own rebuilds, patching and credential resets
Evidence retention	Retains per platform default only	Collects artefacts, hands them over on request	Own the retention policy and the custody chain
Regulatory notification	Notifies you of its own incidents	Supplies facts and timeline	Hold the duty
Identity lifecycle	Provides the directory service	Monitors and alerts on anomalies	Own joiner, mover and leaver processes
Asset inventory	Inventories its own resources	Monitors what is in agreed scope	Own accuracy and completeness
Patching	Patches the platform	Reports missing patches	Own remediation and the maintenance window

Read down the "You" column and a pattern appears. Almost nothing in it is an operational task. It is decisions, approvals, records and funding, which is the kind of work that has no alert attached to it and no queue to sit in. Your MSSP will tell you when a connector breaks. Nobody will tell you that a staging server was stood up outside the agreed scope eight months ago, because from the provider's side it does not exist. That is how the split degrades: not through a failure on the provider's side, but through the quiet decay of the column nobody monitors. In one investigation, a development server exposed cloud credentials to the public internet and the organisation learned about it from an outside security researcher rather than from monitoring.

Understanding what a managed SOC operates on your behalf is only half the exercise. The other half is knowing what stays behind.

‍

What never transfers

Four things stay with you regardless of what the contract says, because no provider can hold them on your behalf.

Data classification. Nobody outside your organisation can decide what counts as sensitive, because the judgement depends on context only you hold. NIST SP 800-61r3 places data inventories, including classifications, owners and physical and logical locations, with the organisation under subcategory ID.AM-07, and notes that those inventories are what tell responders which data may have been involved in an incident.
Privileged identity ownership. You decide who holds administrative access and you revoke it, which means every standing grant in your tenant is a decision you made or failed to revisit. A provider can alert on misuse after the fact; it cannot prevent the grant.
Asset inventory accuracy. SP 800-61r3 puts current, automatically updated inventories of hardware under ID.AM-01 and of software, services and systems under ID.AM-02 with the organisation, explicitly including the identification of shadow IT. An MSSP monitors what you told it exists, so an inaccurate inventory becomes a monitoring gap without anyone raising an alert.
The authority to approve containment. SP 800-61r3 states that the incident response team should be aware of the division of responsibilities, including authority to act on the organisation's behalf, and that this includes restrictions on what the provider may decide unilaterally, such as making and implementing operational decisions to contain an incident. Granting that authority in advance is your decision, and so is the consequence of not granting it.

‍

Mapping the split to the six CSF 2.0 functions

NIST Special Publication 800-61 Revision 3, finalised in April 2025, replaced the four-phase Preparation, Detection and Analysis, Containment, Eradication and Recovery, and Post-Incident Activity lifecycle with the six functions of the Cybersecurity Framework (CSF) 2.0. It supersedes SP 800-61r2, the 2012 Computer Security Incident Handling Guide. If your incident response plan still names four phases, it is mapped to a withdrawn document.

Six functions is not the same thing as the six-step incident response process taught elsewhere. The steps describe what an analyst does during an incident; the functions describe where responsibility sits across a whole security programme, most of it before an incident starts. For readers who still think in phases, Table 1 of SP 800-61r3 provides the crosswalk from each old phase to its corresponding functions.

Function	What SP 800-61r3 covers	Typical MSSP ownership	What stays with you
Govern (GV)	Strategy, policy, roles and authorities, supplier requirements	None. Supplies input to your policy at most	All of it, including the incident response policy and the contractual requirements you set for suppliers
Identify (ID)	Asset and data inventories, risk assessment, improvement from lessons learned	Contributes findings and post-incident reports	Inventory accuracy, risk decisions, and acting on what the reports say
Protect (PR)	Identity and access, training, data security, platform security, logging	Recommends configuration, may implement within scope	Access decisions, training your people, funding log generation and retention
Detect (DE)	Continuous monitoring and adverse event analysis	Owns almost all of it: monitoring, correlation, alerting, declaring incidents	Deciding what is in scope, and monitoring the provider itself under DE.CM-06
Respond (RS)	Incident management, analysis, reporting and communication, mitigation	Triage, investigation, containment and eradication within granted authority	Granting that authority, and the notification duty under RS.CO-02
Recover (RC)	Restoration, integrity verification, recovery communication	Verifies indicators are cleared, supports validation	Rebuilds, restoration priority, and declaring recovery complete

The shape of the table is the finding. SP 800-61r3 places Govern, Identify and Protect below the incident response line in its own lifecycle model, treating them as preparation rather than response. Those three functions are almost entirely yours, and they are the three nobody buys an MSSP to cover. Your provider's work concentrates in Detect, Respond and Recover, which is roughly half the model.

One row runs against the pattern. DE.CM-06 is a High-priority Detect subcategory requiring that external service provider activities and services are monitored to find potentially adverse events, including the remote and on-site administration and maintenance those providers perform on your systems. It is the only place in the framework where the provider is the thing being watched rather than the one watching. Most contracts have nothing to say about it.

‍

What CISA tells MSP customers to own

CISA's guidance for managed service provider customers splits responsibility by role inside the buying organisation rather than by party, and each level owns a different artefact. It is a useful second cut across the same problem: the table in the previous section tells you which party holds a function, this one tells you who inside your organisation is accountable for making sure that holds.

Decision level	What CISA places here	The artefact you must own
Senior executives and boards	Strategic decision-making, and awareness of the systems and technologies in use across the organisation	A current statement of which services are outsourced and what those services touch
Procurement professionals	Operational decision-making, and the contract terms that define the relationship	Log and records maintenance requirements, direct access to security logging and anomaly analysis telemetry from all provider-managed systems, and the ability to examine supporting systems on demand
Network and system administrators, front-line staff	Tactical decision-making, and the day-to-day controls that survive the contract	Access control over provider accounts, independently held network logs, and offsite backups of critical data

The middle row is the one that fails in practice, and it fails for a structural reason rather than a careless one. It is the only row written before the relationship starts. Executives can restate what is outsourced at any point, and administrators can tighten access next week. Telemetry access and audit rights, once left out of a signed contract, cost a renewal cycle to recover, and the moment you discover they are missing is usually the moment you need them. CISA's framing of the underlying question is worth borrowing verbatim in your own procurement conversations: who is responsible for security and operations when outsourcing IT services to a provider.

‍

Where handoffs fail

The split fails in five predictable places, and four of them are documentation gaps rather than technical ones.

Assets outside agreed scope. The provider monitors what was onboarded, so everything else is invisible by design rather than by error. The failure surfaces when a person stumbles into it, which is how confidential HR files surfaced in employee search results at one organisation: a migration had moved personal drives into shared SharePoint sites, permissions inherited from team sites holding dozens of members, and an employee searching for "salary" found other people's compensation letters.
Out-of-hours approval authority undefined. The provider detects something at 03:00 and cannot reach anyone empowered to say yes. Nothing is broken, and nothing happens either, until someone reaches a decision-maker at breakfast.
Log retention shorter than the investigation window. Dwell time exceeds the retention period, so by the time the investigation reaches back to the first suspicious event, the evidence has aged out. This one is technical, and it is the only one on this list you cannot fix retrospectively.
Containment permissions not pre-granted. Isolation requires an approval loop that costs more time than the containment saves, so the provider recommends rather than acts. The authority exists in the onboarding conversation and not in the contract.
Evidence handling unspecified. Artefacts get collected in a format and location nobody agreed to, and nobody owns them afterwards. That becomes a real problem only when you change providers, which is covered in the next section.

Every authority source in this category is normative. NIST, CISA and the cloud providers describe how responsibility should divide. None of them shows what it looks like when the division holds on paper and fails in practice, because small misconfigurations escalate in ways a framework cannot anticipate.

‍

Evidence and chain of custody

Five forensic artefacts are produced during an incident, and the contract decides who holds each one and whether it survives a change of provider.

Endpoint images. Usually captured by the provider's tooling and stored in the provider's environment, in a proprietary or tool-specific format. Portable only if the contract names an export format and a handover trigger.
Log exports. Held wherever the SIEM lives, which for a Microsoft-first environment means your own tenant, not the provider's. This is the one artefact you are most likely to already own, and the one whose usefulness depends entirely on how long your log retention actually runs.
Memory captures. Taken by whoever reached the machine first, held by them, and rarely mentioned in a contract at all. Least portable of the five, and the hardest to recreate after the fact.
The incident timeline. Assembled by the provider's analysts from sources across the estate, and the artefact that carries the most reconstruction cost if it is lost. The evidence trail from a multi-phase BEC ran from October 2025 to February 2026 across four separate events, including two fraudulent payment requests three months apart and an attacker who survived a password reset and session revocation. A timeline like that is not rebuilt from memory.
The final report. Delivered to you, usually as a PDF, and the only artefact most organisations reliably keep. It is also the least useful for a subsequent investigation, because it is a conclusion rather than the evidence behind it.

SP 800-61r3 subcategory RS.AN-07 acknowledges that formal chain-of-custody procedures are not performed for every incident, while still treating collected incident data as evidence to be retained under the organisation's own preservation procedures and retention policies. That obligation is yours. Nothing in the framework assigns it to whoever happens to be holding the artefact.

‍

Regulatory notification: who tells whom, and when

The notification duty sits with you in every scenario. Your provider supplies facts, timeline and technical detail. It does not discharge the obligation, and no contract clause can move it.

Trigger	Who holds the duty	Who supplies the facts	Shape of the window
Personal data exposure	You, as the controller of the data	Provider confirms scope, records affected, and access evidence	Clock typically starts at awareness, not at confirmation, so an unresolved investigation does not pause it
Material operational disruption	You, and your provider separately if it is regulated in its own right	Provider supplies impact assessment and restoration timeline	Often two-stage: an initial notification on a short clock, a full report later
Incident originating with the provider	Still you, for your own regulators	Provider notifies you, then supplies what it chooses to disclose	Your clock starts when the provider tells you, which is why the contract must define how fast that is
Incident originating at the cloud provider	Still you	Platform status and post-incident reports, usually published rather than tailored	Clock starts at the platform's disclosure, which you do not control
Extortion or ransomware	You, with additional reporting duties in many jurisdictions	Provider supplies containment status and encryption scope	Payment-related reporting may run on a separate and shorter clock than breach notification

The third row is the one to read twice. When the incident starts at your provider, your obligation is unchanged but your clock is now downstream of someone else's decision to tell you. That timing is a contract term, not a courtesy, and it belongs in the same clause set as scope and retention.

SP 800-61r3 carries four separate recommendations under subcategory RS.CO-02, covering compliance with current notification law, notification of affected third parties in line with regulatory, legal and contractual requirements, and notification of law enforcement and regulators according to the criteria in your response plan and with management approval. GV.OC-03 goes further upstream, placing incident notification and data breach reporting requirements inside the organisation's own cybersecurity requirements rather than treating them as an afterthought.

‍

When the provider is the breach

If the compromise starts with your security provider, the detection, verification and notification burden all land on you. The standard managed services contract does not cover this scenario, and the provider is not well placed to investigate itself.

The provider's standing access, and what it reaches. Enumerate every account, service principal and connector the provider holds in your tenant, and what each one can read or change. Do it while the relationship is healthy, because the enumeration is much harder to complete when access is the thing under suspicion.
Who detects a compromise originating with your detector. SP 800-61r3 answers this directly. Subcategory DE.CM-06 is a High-priority requirement that external service provider activities and services are monitored to find potentially adverse events, explicitly including the remote and on-site administration and maintenance those providers perform on your systems. It is the only point in the framework where the provider is the thing being watched.
Your notification duty when the incident is theirs. Unchanged, as set out in the previous section. What changes is the timing, because your clock now starts when the provider chooses to tell you.
What you can independently verify without their cooperation. CISA's guidance for managed service provider customers tells customers to keep their own network logs and offsite backups of critical data, and to maintain direct access to security logging and anomaly analysis telemetry from all provider-managed systems. That is the difference between investigating and asking.
The contractual right to audit or revoke. The ability to examine the systems supporting your contracted service on demand, and to cut provider access unilaterally without a support ticket. Both are contract terms. Neither is a default.

This is not a hypothetical failure mode. Joint guidance on protecting managed service providers and their customers was issued by CISA, the NSA, the FBI and the national cyber security centres of the United Kingdom, Australia, Canada and New Zealand, aimed at both providers and the organisations that buy from them. SP 800-61r3 puts it more plainly still: service providers often have privileged access to organisational systems and may hold sensitive data, so the risk of malicious insiders, or of the provider itself being compromised, should be considered and addressed.

‍

Contract clauses to check

Four clauses decide everything above, and three of them are cheaper to fix at renewal than during an incident.

Scope definition. Name what is monitored, and say explicitly what happens to everything else. A scope clause that lists inclusions without stating that exclusions are unmonitored leaves both parties assuming the other is watching. Add a mechanism for adding assets mid-term, because the assets that cause problems are the ones stood up after signature.
Response authority. Set out what the provider may do without asking, who it asks when it must, and how quickly that person can be reached at 03:00. This is the clause that converts a detection into a containment. Without it your provider recommends and waits, which is a slower failure than no detection at all because it looks like coverage. Settle this before signature, alongside the wider question of how to evaluate a provider's ability to handle a live incident.
Retention period. State how long, in what format, and where the data physically sits. Set the period against your likely dwell time rather than against a budget line. An investigation that has to reach back four months needs logs that go back further than four months, and this is the only item on the page you cannot fix retrospectively.
Exit and data portability. Define what you get back, in what format, and how quickly. SP 800-61r3 subcategory GV.SC-10 requires that cybersecurity supply chain risk management plans include provisions for activities occurring after the conclusion of a partnership or service agreement, which is the exit clause stated as a control rather than a negotiating preference. Portability is also where workspace ownership becomes concrete, because whether your detections and history leave with you or stay with the provider depends on who holds the SIEM workspace.

Two of CISA's procurement requirements for managed service provider customers belong in the same clause set: direct access to security logging and anomaly analysis telemetry from all provider-managed systems, and the ability to examine the systems supporting your contracted service on demand. Both are cheap to write in and effectively impossible to add later.

‍

Final Thoughts

Four clauses decide whether that distinction holds in practice or fails quietly: what is in scope, what your provider may do without asking, how long the evidence survives, and what you get back when the relationship ends. Most organisations find out which of those they got wrong during an incident, when the cost of finding out is at its highest. The cheaper version takes an hour with your current agreement and the table at the top of this page.

If you want a second read on where your responsibilities actually sit, book a call with CyberQuell and go through the scope, authority, retention and exit terms in your existing contract.

Last Updated:

August 31, 2026

FAQs

Find answers to commonly asked questions about our cybersecurity solutions and services.

Does hiring an MSSP transfer regulatory responsibility?

No, it does not. Outsourcing the operational work of detection and response moves who performs the task, not who answers for it. Your provider supplies facts, scope and timeline during an incident; the duty to notify a regulator remains yours, including when the incident originates with the provider itself.

Who decides when to isolate a compromised machine?

Whoever the contract says, and there are only two configurations. Under pre-granted authority the provider isolates immediately within agreed limits, which is faster but means containment happens without a conversation. Under approval-based authority the provider recommends and waits for a named person to say yes, which preserves control but adds an approval loop that can cost more time than the containment saves. Pick one deliberately, and define who is reachable out of hours.

What happens to assets outside the agreed scope?

They are unmonitored, and the provider is not at fault for that. A managed service watches what was onboarded, so anything stood up after signature, or never declared, is invisible by design rather than by error. Keeping the asset inventory accurate is your responsibility under NIST SP 800-61r3 subcategories ID.AM-01 and ID.AM-02, and a scope-addition mechanism in the contract is what stops the gap widening over the term.

Does the cloud provider's shared responsibility model still apply?

Yes, and it stacks rather than replaces. The cloud provider secures the platform, your MSSP operates detection and response on top of it, and you retain identity, data classification, asset inventory and the decision to act. Hiring an MSSP adds a party to the model; it does not remove the boundary you already had with the platform.

How long should a provider retain logs after we terminate?

Long enough to cover your likely investigation window, which is usually longer than the notice period. Attacker dwell time is routinely measured in months, so a retention term set to match a 30 or 90 day exit leaves you unable to investigate anything that started before the relationship ended. Set the retention period against dwell time, state the export format, and confirm the data survives termination rather than being deleted with the tenant.

What happens if the breach starts with our security provider?

The detection, verification and notification burden all land on you. Your regulatory duty is unchanged, but your clock now starts when the provider chooses to tell you, which makes that timing a contract term rather than a courtesy. SP 800-61r3 subcategory DE.CM-06 is a High-priority requirement to monitor external service provider activities, including the remote and on-site administration they perform on your systems, and joint guidance from CISA, the NSA, the FBI and four allied cyber security centres addresses this scenario directly.

Does NIST SP 800-61r3 still use the four-phase incident response lifecycle?

No. SP 800-61r3, finalised in April 2025, replaced the four-phase Preparation, Detection and Analysis, Containment, Eradication and Recovery, and Post-Incident Activity model with the six functions of the Cybersecurity Framework 2.0: Govern, Identify, Protect, Detect, Respond and Recover. It supersedes SP 800-61r2, the 2012 Computer Security Incident Handling Guide. An incident response plan still mapped to four phases is mapped to a withdrawn document.

Latest