Co-Managed SOC: contract model and responsibility matrix, not a black box
Co-managed SOC is a contract model where the internal security team and an external SOC provider share the same tenant. They split responsibility per alert type and function in a RACI matrix. Hybrid splits responsibility by time: the internal team covers daytime, and the provider covers off-hours. Co-managed splits responsibility by function within the same tenant, 24/7. It fits organisations that want to keep their existing security team and extend it with 24/7 capability.
Boundaries: managed, hybrid, co-managed
Fully managed SOC hands detection and response entirely to the provider. A hybrid model splits responsibility by time, as Managed vs in-house SOC explains. Co-managed SOC is a third model: shared tenant usage with a clear RACI matrix per alert type. Both sides work in the same SIEM/XDR. Every action has a named owner.
| Trait | Managed | Hybrid | Co-managed |
|---|---|---|---|
| Split logic | None, all with the provider | By time (day/night) | Functional (RACI per alert type) |
| Tenant | At the provider | Two worlds with handover | Shared |
| Fits | SMEs without an in-house team | Team with business-hours coverage | Existing security team with domain knowledge |
Responsibility axes in the co-managed model
Co-managed splits responsibility by function. A RACI matrix assigns each axis to the internal team or the provider. Every axis has a named owner.
- Detection engineering
- L1 triage 24/7
- L2/L3 investigation
- Response execution inside the customer tenant
- Threat hunting and purple team
- Reporting and governance
- Compliance evidence (FINMA, ISG, DORA)
Contract levers that make a co-managed SOC work
- Shared tenant usage in the provider SIEM/XDR with documented data access
- RACI matrix per alert type instead of a blanket service handover
- Escalation matrix with named roles on both sides
- Quarterly governance board with KPI review and rule changes
- Change process for detection rules with joint sign-off
A contract that assigns both sides blanket responsibility for detection and response creates grey zones. In practice, real attack detection falls through these grey zones. RACI per alert type is a minimum requirement.
When co-managed is the right answer
- An existing security team with domain knowledge that you want to retain.
- Regulatory requirements (FINMA, ISG, DORA) that explicitly demand internal accountability. See SOC for FINMA-regulated institutions.
- OT or production-critical environments where response decisions need process knowledge an external team does not have.
- Environments with high detection-engineering requirements, where the internal team and provider maintain use cases jointly.
Governance and operations
Co-managed relies on a quarterly governance board with KPI review and a shared change process for detection rules. Both sides also need an escalation matrix with named roles. Without these three elements, the model drifts towards managed or in-house operations within months. In practice, the provider either dominates operations or becomes a log supplier. Both outcomes cost more than choosing the corresponding model deliberately.
Placement in SOC operations
SOC as a Service Switzerland explains how the internal team and ANOMAL interact in ongoing operations.
Frequently asked questions
What exactly separates co-managed from hybrid?
Hybrid splits by time: internal analysts by day, provider off-hours, with handover. Co-managed splits by function: both sides work concurrently in the same tenant, but each alert type has clearly assigned owners. Hybrid needs handover points, co-managed needs a RACI matrix.
From what size does co-managed make sense?
Co-managed makes sense once at least two to three internal security roles provide business-hours coverage. Below that, fully managed SOC is cleaner economically and operationally. See [Managed vs in-house SOC](/en/soc/managed-vs-inhouse-soc).
Who owns the detection rules in a co-managed model?
The customer always owns the detection rules under the contract. The provider contributes baseline rules and threat intel, but changes in the customer tenant run through a shared change process with sign-off. This keeps the rule set portable even in a provider switch.
What does onboarding look like for co-managed?
The phases follow standard onboarding, as [SOC onboarding Switzerland](/en/soc/soc-onboarding-switzerland) explains. Both sides draft the RACI matrix together in phase 1 and include it in the contract before go-live.
What happens if internal capacity drops?
A clear contract defines a fallback mode where the provider temporarily takes over responsibility axes from the internal team. It specifies an explicit surcharge and a return clause. Without that mechanism, every wave of internal attrition becomes a detection risk.
Related terms
- SOCaaS SOC as a Service (SOCaaS) is a SOC operated by an external provider and delivered as an ongoing service.
- SOC A Security Operations Center (SOC) is the team that constantly monitors an organisation's IT for attacks and intervenes during incidents.
- Runbook A runbook is a detailed operational procedure outlining the technical steps for a specific task.
- Playbook A playbook is a predefined procedure describing how a SOC responds to a specific type of security incident.