Cloud MSSP vs Co-Managed SOC: Who Owns Response

Accurate as of October 2026; vendor programs change.

A hyperscaler MSSP badge or a co-managed SOC engagement confirms that an alert fired, not what it means or what to do about it. Your team, or your provider's, still decides that, and the contract decides which one of you it is.

Buyers compare these models because the labels promise the same thing: MSSP, co-managed SOC, and MDR all claim shared security operations, but they split triage and response authority differently. Teams find out how differently when an incident hits and the gap matters most.

A cloud MSSP badge certifies a technical bar, not an operating model. Co-managed SOC splits the work across five decisions. Response authority draws the real line between the three models, and the right fit depends on your team's size and risk appetite.

TL;DR:

• A cloud partner designation validates specific capabilities, sometimes including 24/7 monitoring. It doesn't establish the provider's response permissions, your SLAs, or who owns each investigation.
• Co-managed SOC arrangements divide five decisions: platform and log sources, detection content and tuning, triage, response authority, and exit terms. Each one can sit with you, the provider, or both.
• Response authority is the real contractual distinction across notify-only, co-managed SOC, and MDR services; the service label doesn't determine it. Spell out which actions are pre-authorized, which need approval, and who executes each one.
• Cloud and identity alerts strain shared models: the context needed to triage them sits outside the SOC's view.
• The right model depends on your team's size, in-house platform expertise, and how much response authority you're willing to delegate.

What a hyperscaler cloud MSSP badge does and does not tell you

A hyperscaler MSSP badge confirms a partner cleared a technical bar. It says nothing about what that partner can do inside your specific contract, and the badges themselves cover more than a one-time certification.

AWS's validated MSSP partners run 24/7 security monitoring through dedicated SOCs. Their incident response follows NIST's phases (preparation, detection and analysis, containment, eradication, recovery, and post-incident activity) through either a fully outsourced or a collaborative model. AWS tightened the underlying competency criteria in June 2025 to require core partner requirements plus technical validation in at least one security category, such as identity and access management or incident response.

Microsoft's Azure Expert MSP designation covers Azure managed-services capabilities across a partner's whole practice. Microsoft is retiring it: new enrollments stopped September 15, 2026, renewals end January 2027, and existing partners keep benefits through their anniversary date.

Google Cloud's certified MSSP directory lists partners that build on Google Security Operations and Google Threat Intelligence alongside customers' existing security tools.

A badge signals validated capability. Your contract spells out the permissions, obligations, and remedies that actually bind the engagement. These programs prove the capability exists; their public descriptions don't replace the service agreement. Confirm escalation procedures and contractual service levels directly with the provider.

What a badge doesn't answer:

• Which services and telemetry sources your contract actually covers 24/7, and whether investigation and authorized containment run around the clock too
• Whether the partner can take response actions, such as isolating a host, revoking a token, or disabling an account, versus only notifying you
• What mean time to detect and mean time to respond look like in production, not in a sales deck
• Whether the partner tunes detection content to your environment or runs it on default rules

A badge is a useful procurement signal, but it can't tell you whether a provider's operating model fits your requirements. A certified partner can run a notify-only program, a co-managed arrangement, or a full MDR engagement, and the badge alone doesn't say which. If you're evaluating outsourcing SOC operations, ask the operating-model question separately from the certification question.

How vendors carve up a co-managed SOC

Co-managed SOC offerings vary by provider, so you need to define the responsibility split explicitly in each contract. The five decisions below give you a practical framework for doing that.

1. Platform and log sources

Platform ownership is the first thing to settle: it decides who's on the hook when a log source goes dark. In many co-managed deals, you own the platform license and infrastructure while the provider staffs the SOC that watches it. In others, the provider brings its own platform and you license access to it. If you're sizing this decision against your own headcount, start from a basic SOC team structure before deciding how much to outsource.

2. Detection content and tuning

Your team, the provider's team, or both can write and maintain detection rules, correlation logic, and tuning thresholds. A provider that inherits your existing detection content (often stale) without a tuning pass inherits your false-positive rate too.

3. Triage

Most co-managed deals put first-line triage with the provider's SOC analysts, who escalate to your team for anything that needs business context the SOC doesn't have, such as whether an admin account should be active at 3 a.m. or a vendor integration is expected.

4. Response authority

Response authority is an important procurement question that gets less scrutiny than it deserves. Does the provider have standing authority to contain a threat? Does every containment action need your approval first? Or is it some negotiated mix of the two? Approval requirements can delay containment when your contacts are unavailable.

5. Exit

Exit terms decide whether you keep what the engagement built or start over with the next provider. Do you retain the detection content, the tuning history, and the institutional knowledge of what's normal in your environment, or does that leave with the provider? Agree on this before signing, while both sides can still negotiate calmly.

Response authority is the contractual hinge

Response authority separates these three arrangements in practice, more than their labels do. The table below is a practical comparison, not a standardized taxonomy: current service documentation shows that who investigates and who can act vary within each row, MDR included.

A notify-only service leaves response execution with you. A co-managed SOC splits monitoring, investigation, and response between you and the provider. MDR handles detection, investigation, and response, but whether execution is pre-authorized or needs approval depends on the contract, not the label.

Validate detection coverage and integration depth too, separately from investigation and response capabilities. Sophos's MDR service shows the range: an Authorize mode that pre-authorizes response and reports afterward, a Collaborate mode that requires your written consent before response actions, and a Notify Only mode limited to detection and alerting, all three within one provider's MDR line. That's also where MDR and MSSP diverge on paper versus in an actual incident.

Compare SLA definitions directly instead of assuming metrics from the service label. Identify the clock's start and stop points, severity tiers, covered hours, approval pauses, exclusions, and remedies. Vendors define these response-time clocks differently, so check each one. MDR evaluation criteria walks through the specific questions to ask before you compare two quotes.

Why cloud and identity alerts strain the shared model

Cloud and identity alerts are hard to investigate remotely when the provider lacks cloud audit logs, identity telemetry, resource ownership information, or business context. An unexpected role-assumption event might be an approved workload change, or it might be unauthorized use of compromised credentials. Telling them apart means correlating cloud audit logs with workload ownership, identity activity, and change records.

Identity signals carry the same ambiguity. Okta's new-device detection relies on browser cookies, so a sign-in from a browser with no stored cookie reads as a new device with "limited accuracy." That alone doesn't settle anything: it could be a legitimate laptop change or something worth a closer look, and investigators need more session, identity, and device context either way.

Co-managed SOC engagements that work well for on-premises and endpoint telemetry strain once most of a customer's alert volume shifts to cloud and identity sources. Good investigations need real telemetry and maintained organizational context, and providers get that through scoped integrations, read-only access, shared asset and change records, and a reliable escalation path.

Containment needs its own authorized response permissions on top of that. AWS Security Incident Response customers, for example, can opt in to grant containment permissions separately from investigation, so visibility and authority don't have to be one all-or-nothing grant. That means building containment-ready processes before an incident starts, not during one. That's the case for cloud incident response planning.
Decision criteria: which shared model fits

Weigh budget alongside staffing, platform expertise, coverage needs, and your willingness to delegate response. Fit comes before cost, and the three criteria below decide it.

Team size and what it already owns

A two-person team can't sustain continuously staffed triage on its own; check whether its on-call escalation capacity matches the provider's expected workload. A larger team that already staffs after-hours coverage has more room to keep response authority in-house.

In-house platform expertise

A team that already runs its SIEM well and just needs more eyes on alerts is a good fit for a notify-only or co-managed arrangement. A team with no SIEM expertise and no desire to build it is a better fit for a provider that owns the full stack, platform included.

Appetite for delegated response authority

This is as much a cultural and governance question as a technical one. Some organizations are comfortable pre-authorizing containment actions for high-confidence alerts. Others require a human in the loop for every action, which caps how fast any provider can move regardless of its technical capability.

The model you choose decides who owns the verdict

Every model here answers the same question differently: who reaches the verdict, and who acts on it. A notify-only service keeps both with you. A co-managed SOC splits them by agreement. MDR concentrates both with the provider for in-scope threats, under whatever authorization mode the contract sets.

Answer the questions above before you read a vendor's pitch deck. Delegating investigation and containment doesn't remove your responsibility for risk acceptance, governance, business decisions, or incident work outside the provider's scope.

Frequently asked questions about cloud MSSP and co-managed SOC models

What is the difference between a cloud MSSP badge and a co-managed SOC?

They answer different questions. The badge tells you a partner cleared a hyperscaler's technical bar; it doesn't tell you how that partner operates day to day. Co-managed SOC is one specific way a badged partner can choose to operate. Ask about the operating model as its own decision, separate from the badge; a vendor's sales team may default to whichever arrangement is easiest for them to deliver.

Does MDR replace the need for an internal security team?

No. MDR is an operating model where a provider investigates in-scope threats and, depending on the agreement, is pre-authorized or needs approval to respond. Many organizations still keep an internal team for governance, escalation, and the alerts that fall outside the MDR provider's scope.

What should be in a co-managed SOC contract?

At minimum: which sources, systems, hours, and investigation duties are in scope, plus severity definitions and measurable service levels. Add approval deadlines, fallback contacts, and what happens when you're unreachable, along with access controls, action logging, and data handling.

Also cover whether forensics, eradication, and recovery are included, who owns and can port the logs, cases, detection rules, and runbooks, and the liability, exclusions, termination, and transition-assistance terms. Sophos's MDR contract, for example, shifts into pre-authorized response once reasonable attempts to reach a customer's designated contacts go unanswered. Write the same kind of fallback into your own agreement.

Can an organization move from notify-only to co-managed without switching providers?

Often, yes, if the provider offers more than one tier. Moving between tiers usually changes scope, integrations, permissions, runbooks, staffing, and contract terms. It's rarely just a configuration toggle.

‍