Co-managed security: a responsibility model that works

Begin with the work already being done

A co-managed security arrangement adds capability around an existing team. Before inviting proposals, map who currently administers identity, manages endpoints, changes cloud configurations and receives security alerts. Include the MSP, application suppliers and internal business owners. Describe the decisions that are delayed or repeatedly passed between teams. This turns a vague request for extra security into a specific support requirement. A new provider may improve an existing process without replacing the people or technology that already work well.

Separate accountability from task execution

One organisation can investigate a concern while another retains authority over the affected service. Record who performs each activity, who approves disruptive actions and who remains accountable for the business outcome. Avoid assigning several accountable owners to the same decision without a clear escalation rule. Use named roles in the agreement and maintain actual contacts in the operational directory. Agree an alternate for absence, holidays and out-of-hours decisions. A responsibility table that only says shared leaves the most difficult moment unresolved.

Follow one realistic handoff

Consider a suspicious sign-in affecting a privileged cloud administrator. The identity administrator may own the account, the monitoring provider may receive the evidence and the application team may understand the consequence of disabling access. Ask how those people exchange context, what evidence travels with the escalation and who approves containment. Walk through the sequence using a benign example. Do not assume that access to a security console gives the provider authority to change production identities. Record any decision that cannot yet be made.

Resolve the boundary with an existing MSP

Security work often depends on routine administration: enrolling a device, changing a policy, updating software or obtaining a configuration record. The RFP should identify which tasks the MSP already performs and how additional requests are authorised and charged. Ask each party to acknowledge the boundary before onboarding. Otherwise a security recommendation can become a ticket that nobody has budget or permission to complete. Include the route for a disagreement over responsibility and the owner who can resolve it without leaving the issue indefinitely open.

Review the agreement when the environment changes

New acquisitions, cloud accounts, regions and suppliers can change the service boundary. Define the trigger for reviewing coverage and approving additional work. In each service review, inspect unresolved handoffs, exceptions and decisions requiring management attention. A useful review produces named actions and dates rather than a second copy of dashboard statistics. Keep the responsibility model accessible to the operational teams and verify contact changes when staff move. Contract renewal should consider whether the model still fits the business, not merely whether the invoice remains acceptable. For an independent control review of those handoffs, see the cybersecurity audit evidence request guide.

For the next procurement discussion, read our related guides on SOC coverage and authority and network and identity boundaries. These cover complementary decisions; technical testing still needs its own scope and authorisation.

Prepare your requirements

Use the managed security services RFP builder to select your platforms, describe existing support and review suggested workstreams. You can edit your requirements before sending them through the contact form with an NDA or RFP. Approximate counts and business context are enough initially. Do not include credentials, personal records or live incident evidence. Service hours, delivery capacity and commercial commitments must be agreed in the proposal; submitting a form does not activate a service.