A co-managed service is an operating model where an external team shares responsibility for day-to-day security work with an internal team. It is commonly used when skills, capacity, or coverage are limited, and it depends on clear boundaries, agreed runbooks, and ongoing communication to avoid gaps.
What Co-Managed Service Means in Security Operations
A co-managed service is a shared operating model, not a handoff. It works best when the external provider and the internal team split responsibilities clearly, so monitoring, triage, escalation, and remediation stay aligned with the organisation’s own risk tolerance and priorities.
In security operations, the model is usually chosen to extend coverage without losing internal control. The practical value comes from combining outside capacity and specialist depth with internal knowledge of business context, asset criticality, and acceptable response paths.
How Responsibility Is Split
The most important design question is who owns which activity. A useful co-managed arrangement distinguishes between routine monitoring, alert review, investigation, containment, change approval, and final remediation authority, rather than assuming both teams will “just collaborate” on everything.
That split should be explicit enough to survive staff turnover, shift changes, and incident pressure. Clear runbooks, escalation thresholds, and decision rights reduce the chance that two teams both assume the other is acting, or that neither team feels authorised to move.
Operating Requirements That Make It Work
Co-managed service model depend on dependable communication and shared context. The external team needs enough visibility into the environment to act effectively, while the internal team needs enough transparency to verify what was done, why it was done, and what remains open.
Runbooks, service levels, ticketing workflows, and review cadence are part of the service design, not administrative overhead. In practice, the model fails when handoffs are informal, the scope is vague, or the external team is measured only on speed without regard to business impact.
For service accounts, shared consoles, and other operational access used in the arrangement, organisations often need stronger governance than a standard outsourcing relationship. Service Account Security Guide is a useful reference for the access and governance issues that often sit underneath shared operational delivery.
Why Co-Managed Service Is Used
Most organisations adopt this model when they have some in-house capability but not enough coverage, specialist depth, or around-the-clock operating capacity. It is also common when leadership wants to retain local control over sensitive systems while outsourcing repeatable security work.
The model can be a strong fit for teams that need to mature gradually. It lets the internal function stay involved in daily security operations, learn from the provider’s processes, and avoid the knowledge loss that can happen in a full outsourcing model.
Risk and Threat Considerations
Co-managed service creates risk when responsibility boundaries are unclear, because gaps in monitoring or response can persist between teams. Shared operating models also increase the chance of misconfiguration, delayed escalation, and inconsistent remediation if each side assumes the other has ownership.
Failure mechanism: Ambiguous decision rights, incomplete runbooks, or poor access governance can leave alerts unhandled, actions duplicated, or privileged operational access used in ways the internal team cannot independently verify.
Impact: Attackers or operational failures can gain more time to persist, expand exposure, or exploit delayed response, while the organisation loses confidence in who can act, what was changed, and whether controls are being executed consistently.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | AC-2 — Account Management | Co-managed delivery depends on clearly owned accounts and delegated access boundaries. |
| IA-5 — Authenticator Management | Shared operations often rely on credentials and secrets that must be governed across teams. | |
| IR-4 — Incident Handling | Shared security operations require clear handling, escalation, and containment responsibilities. | |
| Recommendation — Define account ownership and review delegated access used by the shared service. Control credential issuance, rotation, and revocation for jointly operated access. Assign incident-handling authority and escalation paths across both teams. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Co-managed services require explicit access rules for provider and internal personnel. |
| Recommendation — Document and enforce access rules for all shared operational activities. | ||
| CIS Controls v8 | CIS-5 — Account Management | Shared service models rely on disciplined account ownership, lifecycle, and review. |
| Recommendation — Maintain account inventory and revoke shared access when it is no longer needed. | ||
Practitioner Guidance
Governance implication: Treat the co-managed model as a control arrangement, not just a staffing model. The internal team should retain enough ownership to approve boundaries, verify execution, and understand how decisions are made during incidents or exceptions.
What to watch for: Repeated ambiguity around escalation, access, or remediation is usually a sign that the service design is too loose. If the provider cannot explain how work is handed off, checked, and closed, the model needs tighter operating rules before it scales.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 27, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
