Co-Managed SOC and SOC-as-a-Service Guide: Models, Responsibilities and Contract Terms

Buying security operations from a provider moves work off your team, but it does not move accountability, and it gives an outside organisation standing access to your most sensitive telemetry and often to your tenant. Most organisations that cannot staff a 24x7 security operations centre end up with some mix of an in-house team, a co-managed arrangement and a fully outsourced SOC-as-a-Service or managed detection and response (MDR) contract. The model matters less than whether responsibilities, response authority, data ownership and exit are written down before something goes wrong. This guide compares the sourcing models, sets out a responsibility (RACI) split, lists the contract terms that decide whether the service works in an incident, and treats provider access to your environment as the privileged non-human and third-party identity risk it is. It is written for SOC leads, CISOs and procurement or vendor-risk teams designing or renewing a managed SOC arrangement.

Key takeaways

• Accountability stays with you. A provider can run detection and triage, but the organisation still owns risk decisions, regulatory notification and the consequences of a missed alert.
• Write the RACI before the contract. The joint advisory on managed service provider (MSP) threats from the Five Eyes agencies tells customers to state in the contract whether the provider or the customer owns hardening, detection and incident response.
• Response authority is the hardest clause. Decide in advance which containment actions the provider may take without asking (isolate a host, disable an account, revoke sessions) and which need your approval.
• Provider access is privileged access. Provider accounts, API integrations and delegated admin relationships into your tenant are some of the most powerful identities you have and must be scoped, monitored and removed at exit.
• Own your data and your detections. Logs, detection content, case history and playbooks should be retrievable in usable formats, with retention set in the contract, or the exit will be a restart from zero.

The sourcing models compared

Terms are used loosely in the market, so define them in your own requirements rather than relying on a provider's label. The working definitions below are the ones this guide uses.

• In-house SOC: your staff, your SIEM and EDR, your processes. Full control and context, highest fixed cost, hardest to staff around the clock. See the SOC Guide.
• Co-managed SOC: you keep a security team and usually own the platform (SIEM, data lake or XDR); a provider adds out-of-hours monitoring, tier 1 and 2 triage, content engineering or threat hunting. Both parties work the same queue and the same tools.
• SOC-as-a-Service (SOCaaS): the provider supplies the platform, the people and the process as a subscription. You supply log sources and contacts. Fastest to start, least control over tooling and detection content.
• MDR: usually built around the provider's own or a named EDR/XDR stack, with an emphasis on active response (host isolation, process termination) rather than log monitoring alone. See the MDR Guide.
• Traditional MSSP monitoring: alert forwarding and device management, often with limited investigation. Still common for firewall and network device management.

Choosing a model: decision guidance

The UK NCSC's SOC guidance stresses that a SOC should be proportionate to the threats you face and that there is no one-size-fits-all model. In practice the decision turns on four questions.

• Do you have people who can make risk decisions at 03:00? If not, a provider must be able to act on your behalf, which pushes you towards MDR or SOCaaS with pre-approved containment.
• Do you already own a SIEM or security data lake? If you have invested in a platform and detection content, co-managed keeps that investment and keeps the content yours. If you have nothing, SOCaaS avoids building one first; the guide in this series on building a SOC from scratch covers the in-house route.
• How unusual is your environment? OT, mainframe, heavy custom SaaS or complex cloud estates need context a generic service lacks. Co-managed lets your team supply it; a pure service will miss things unless you pay for onboarding and custom use cases.
• What do regulators expect? Financial entities under DORA must manage ICT third-party risk including exit strategies; see the DORA Guide. Outsourcing does not move notification duties.

Small organisations (no dedicated security staff) usually get the most from an MDR or SOCaaS contract with clear containment authority and a named internal decision-maker. Mid-sized organisations with two to six security staff tend to fit co-managed: the provider covers out-of-hours triage and the team handles escalations, tuning and business context. Large organisations often run an in-house SOC and buy co-managed capacity for surge, specialist hunting or follow-the-sun cover. A hybrid that starts as SOCaaS and moves to co-managed as the team grows is common; plan for that move in the first contract.

Responsibilities: a RACI for a co-managed SOC

R = responsible (does the work), A = accountable (owns the outcome), C = consulted, I = informed. Adjust per contract; the point is that every row has exactly one A, and it is usually you.

The joint advisory from NCSC-UK, ASD's ACSC, CCCS, CISA, NSA and FBI on protecting MSPs and their customers asks customers to specify whether the provider or the customer owns hardening, detection and incident response, and, where a provider monitors your systems, to require visibility into the provider's own activity, notification of suspected or confirmed events and analysis by a SOC. Those three requirements map directly onto the RACI rows above.

Contract terms that decide the outcome

NCSC's guide to choosing a managed service provider asks for a clear responsibilities matrix, incident notification timeframes, a documented incident management process, defined response and resolution times in SLAs, liability, responsibility for the provider's own third parties, and termination terms that give you flexibility. For a SOC service, turn those into measurable clauses.

SLAs that measure the right thing

• Define the clock: state whether time starts at event ingestion, alert creation or analyst pickup. Ingestion delay can hide minutes or hours.
• Measure human response, not automation: ask for time to first analyst action and time to customer notification separately.
• Include quality: escalations you reject as noise, and incidents you found that the provider did not, are as important as speed.
• Tie credits to repeat misses: service credits are rarely significant; a right to terminate after repeated critical SLA failures is worth more.

Provider access to your tenant is an identity risk

A managed SOC needs access: API connectors into your cloud and SaaS tenants, agents with response capability on every endpoint, accounts in your SIEM and often delegated administrative roles. Each is a non-human or third-party identity that an attacker who compromises the provider can use. ATT&CK records this route as T1199 Trusted Relationship, and abuse of provider cloud accounts as T1078.004 Cloud Accounts. The 2021 Kaseya VSA incident, where attackers exploited a vulnerability in on-premises remote management software to deploy ransomware through MSPs to their downstream customers, is the reference case; CISA's guidance afterwards told customers to route MSP access through a dedicated VPN, keep MSP accounts out of administrator groups, limit them to the systems they manage and disable them when not in use.

• Delegated admin in Microsoft 365 and Entra ID: use granular delegated admin privileges (GDAP), which Microsoft describes as granular, time-bound, least-privilege partner access that the customer must explicitly grant, instead of broad legacy delegated admin. A SOC rarely needs Global Administrator; security reader and specific response roles usually suffice. See the GDAP and MSP Delegated Admin Access Guide.
• API connectors and service principals: inventory every app registration, OAuth grant and API key the provider uses, record its scopes, prefer read-only for monitoring and separate the identity that can take response actions. Rotate or revoke at exit. See the Third-Party Access Guide.
• EDR and response agents: the provider console that can isolate hosts can usually also run scripts on them. Ask how provider console access is authenticated, which staff have it and whether script execution is logged to you. Watch for unexpected use of remote access tooling (T1219 Remote Access Tools).
• Named accounts, not shared ones: the joint MSP advisory says customers should contractually prohibit reuse of admin credentials across customers and require MFA on all provider accounts that access their environment.
• Monitor the monitor: send provider sign-ins and actions to a log the provider cannot alter, and alert on provider accounts acting outside agreed hours, locations or scopes.

How to implement or switch provider

1. Write requirements and the RACI first. List log sources, crown-jewel assets, account classes, containment actions you will pre-approve and regulatory clocks you must meet.
2. Assess providers against the contract table. Ask for sample monthly reports, a sample incident timeline, their own access model to customer tenants and how they segregate customer data. Use the MDR Buyer's Guide for vendor questions.
3. Run a time-boxed pilot. Onboard a representative subset (identity provider, EDR on a pilot ring, one cloud account). Run the provider in shadow mode alongside your current process for two to four weeks and compare what each finds.
4. Test response, not just detection. Run a purple team exercise or a controlled simulation and measure time to notify and time to contain against the draft SLA. See the Purple Teaming Guide.
5. Grant access in least-privilege steps. Start with read-only monitoring roles, then add response roles once runbooks are signed off. Record every identity granted in your NHI inventory.
6. Go live by phase. Expand log sources and response authority in rings, with a hypercare period and weekly reviews.
7. Keep a rollback path. Until the old service or internal process is retired, keep it able to receive alerts. For a switch between providers, overlap contracts for at least one full alerting cycle and never remove the outgoing provider's access before the incoming one is proven.
8. Exercise exit annually. Export detection content and a month of case data in the contracted format and confirm you can actually load it.

Detection and measurement

Monitor the service as well as the threats. Useful logging includes provider account sign-ins and role activations, connector and API calls made by provider identities, response actions taken on endpoints, and the health of every contracted log source. Map these to NIST CSF 2.0 DE.CM-01 (networks and network services are monitored) and DE.AE-02 (potentially adverse events are analysed), and the provider relationship itself to GV.SC-07 (supplier risks are monitored over the relationship).

• Mean time to notify by severity: from alert creation to customer notification, against the SLA.
• Mean time to contain for pre-approved actions: the number that matters most in ransomware cases.
• Escalation precision: percentage of escalations your team agrees were worth raising.
• Customer-found incidents: incidents your team or a third party found that the provider missed. The target is zero.
• Log source coverage and silence: percentage of contracted sources reporting, and time to detect a silent source.
• Provider access hygiene: provider identities with standing high privilege, and days since the last access review.

See the Security Operations Metrics Guide for definitions and pitfalls.

Common failure patterns

• Nobody authorised to act. The provider detects ransomware staging at night, sends an email and waits. Fix it with a containment authority matrix and a reachable on-call decision-maker.
• Detection content locked in the provider's platform. At renewal you discover years of tuning cannot be exported. Put content ownership and export format in the contract.
• Silent log sources. A firewall or cloud audit log stops sending and nobody notices for weeks. Require source-health alerting as part of the service.
• Over-privileged provider access. A provider holds Global Administrator or domain admin "for convenience". The joint MSP advisory says to limit provider accounts to the services they manage and keep them out of internal administrator groups.
• Provider-held data becomes the target. Support and case systems hold customer artefacts that can be abused. In the Okta support system breach, attackers used session tokens found in HAR files that customers had uploaded to support cases, and a customer's own monitoring raised the alarm weeks before the provider confirmed it. Keep your own detection on provider-facing access and treat anything you send a provider as sensitive.
• Access left behind at exit. Service principals, API keys and EDR consoles from the previous provider stay active. Make removal and a deletion certificate part of the exit checklist.

Framework mapping

Practitioner checklist

• Document which sourcing model you are buying in your own words, not the provider's label.
• Agree a RACI with exactly one accountable party per activity, signed by both sides.
• Write a containment authority matrix by asset class and account class, with an out-of-hours approver.
• Put time to notify, time to contain, data ownership, log retention and content export into the contract.
• Inventory every provider identity (accounts, service principals, API keys, EDR console users) and scope each to least privilege.
• Use GDAP or equivalent time-bound delegated roles instead of standing global administrator access.
• Log provider sign-ins and actions to a store the provider cannot modify, and alert on out-of-scope activity.
• Pilot in shadow mode and run a response exercise before go-live.
• Review provider access quarterly and test the exit process annually.

Standards and references

• ASD's ACSC, NCSC-UK, CCCS, CISA, NSA and FBI: Protecting Against Cyber Threats to Managed Service Providers and their Customers
• NCSC: Choosing a managed service provider (MSP)
• NCSC: Building a Security Operations Centre
• CISA: Kaseya Ransomware Attack: Guidance for Affected MSPs and their Customers
• NIST: SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• NIST: Cybersecurity Framework 2.0
• Microsoft Learn: Introduction to granular delegated admin privileges (GDAP)
• MITRE ATT&CK: Trusted Relationship

Related NHI Mgmt Group resources: SOC Guide · MDR Guide · GDAP and MSP Delegated Admin Access Guide · Third-Party Risk Management Guide · AI SOC Guide