Who Owns What in Co-Managed Security? A Practical RACI Map

At 2 a.m., an endpoint is beaconing, a patch window is open, and a user is waiting for a call. If nobody can say who owns that moment, your co-managed security model is already at risk. This guide builds a practical RACI map for the IT director who must explain exactly who monitors, who triages, who contains, who isolates an endpoint, who patches, and who communicates with users. The working premise is simple: engagements with mssp providers may not fail on coverage alone; they can fail when handoffs go unowned. To keep the split defensible, we anchor the map in NIST SP 800-61 Revision 3, finalized in April 2025, a CSF 2.0 Community Profile that supersedes Rev. 2 and is free to use voluntarily. You will move through what breaks when nobody owns the handoff, the three documents to have ready, monitoring, triage, containment, endpoint isolation, patching, user communications, a consolidated RACI table with one owner and one clock per line, plain-language business explanations, five handoffs that break in practice, and how to take the map into your next contract review.

What Breaks When Nobody Owns the Handoff

Your coverage is contractual. It has a number, a log source list, and a monthly report that shows green. The seam between your team and your provider has none of those things, so nobody examines it until an incident forces the question.

Here is a test rather than an argument. Pull your last three incident reviews. If any ended in a debate about who should have called the user, who should have isolated the endpoint, or who should have patched it, you did not have a coverage hole. You had an unowned handoff.

Mid-market teams feel this hardest. A lean internal group plus an external provider means every handoff crosses an organizational boundary: two ticketing systems, two clocks, two vocabularies for the same event. Your provider’s “contained” may be your “still investigating.”

A named owner per activity buys something concrete: a defensible answer to who was responsible that holds up in a board question, a client audit, or an insurance questionnaire. That is a governance artifact, not a runbook. Choosing between detection and response models is a separate decision; see our comparison of EDR, XDR and MDR ownership models.

What follows is six responsibility lines: monitoring, triage, containment, endpoint isolation, patching, and user communications. Each gets an owner, an escalation trigger, and an example response clock, labeled as a starting point to negotiate. A consolidated table you can copy and attach to your statement of work closes the section.

Prerequisites: Three Documents to Have in Hand

Before you can assign a single responsibility line, gather the evidence that turns the conversation into a document review rather than a debate.

The current provider contract and statement of work. Read it for how “response” and “notification” are defined, not for what services are listed. Undefined terms are where ownership quietly defaults to you, because the provider’s obligation ends at the edge of its own wording. Where the language is silent, treat that silence as a gap you must negotiate. The same diligence applies to every third party touching your environment, as this guide to auditing third-party threats explains.

Your internal on-call roster, stated honestly. Write down the hours your team can actually be reached, not the hours the org chart implies. A split built on imaginary 24/7 internal coverage collapses on the first overnight incident.

A 12-month incident and near-miss log. Capture timestamps for detection, acknowledgement, first action and closure. This log is your only real evidence of where handoffs already leak, and it converts opinion into pattern.

An asset and identity inventory current enough to trust. You cannot assign an owner for endpoints, accounts or cloud tenants you cannot enumerate.

A named business sponsor and a written obligations list. Confirm notification duties against your sector and jurisdiction with counsel, not with a vendor template.

Those items give you the raw material. The next question is what structure to hang them on.

Anchor the Map in NIST SP 800-61 Rev. 3, Not in a Vendor Brochure

With those documents in hand, you still need a structure that names activities before you negotiate them. NIST supplies one, and it is free.

Rev. 3, approved March 2025 and now in force, is what makes this a framework review rather than a vendor conversation, because its recommendations map onto CSF 2.0 functions.

Because Rev. 3 is a CSF 2.0 Community Profile, its recommendations map onto the Cybersecurity Framework 2.0 functions. That mapping is what makes it a RACI backbone rather than narrative reading. You inherit named activities, each traceable to governance functions, instead of prose you have to reinterpret mid-incident. If the risk side of that picture is still thin on your side, our NIST risk assessment guide for mid-market organizations covers the groundwork.

The publication is free to use, and nongovernmental organizations may adopt it voluntarily, so quoting its activity structure in a contract annex carries no licensing obstacle. NIST also states that naming any product does not imply endorsement, which keeps the framework clear of the vendor-brochure problem.

Order matters. Let the framework name the activities, then negotiate who owns each one. Choose managed cybersecurity solutions after you can describe that split, not before. Monitoring is the first line to assign.

Line One: Monitoring, Who Watches and on What Schedule

Monitoring is the collection and alert generation across endpoint, identity, network and cloud sources, plus someone watching that queue during hours your team does not cover. Log-source coverage is a long-standing problem rather than a modern one: NIST’s guide to computer security log management addresses log generation, log protection, and the breadth of sources organisations must manage.

The plausible split puts the provider on tooling, log ingestion and first-pass alert generation. Your team owns the context that says what normal looks like here, such as the finance system that reboots at month end. That context is what stops the provider from escalating a scheduled maintenance event at 2 a.m.

Settle in writing who is accountable when a source stops sending logs. A silent feed is an invisible coverage gap, and it usually surfaces mid-incident rather than before one.

Then define the escalation trigger as two separate steps: what converts a raw alert into a tracked ticket, and what converts a ticket into a phone call to a human who is awake. The second step is the one engagements skip.

Set an example clock, clearly an example to negotiate rather than a benchmark: alert acknowledged within 15 minutes, internal notification within 30 minutes for high-severity alerts. No published benchmark supports those figures; they are starting positions.

Before signing, ask shortlisted MSSP providers for the written list of log sources included, excluded and addable, and compare it against the questions in our MDR procurement checklist. The excluded column is where coverage claims quietly shrink.

Line Two: Triage, Who Decides What Is Real

Acknowledged alerts arrive with a verdict attached, and triage is where that verdict gets tested. Triage answers three questions: is this genuine, how bad is it for the business, and does it need containment now. Name the human on each side who makes that call, with a deputy for each, not “the SOC” and “the team.”

Plausible split: your provider runs first-pass triage against a documented playbook, closing obvious false positives and escalating the rest. Your team owns business-impact classification, because only you know that a down order system costs more per hour than a stalled marketing laptop. That split only works if you have negotiated the middle, where the provider quietly closes something you would have wanted to see. Build a mandatory-notify list: alert types always reported regardless of the provider’s verdict, such as new admin account creation, impossible-travel logins, or a first-seen executable on a finance endpoint.

Put thresholds in writing, including the stop-and-ask point. Below it, the provider acts under pre-authorization. Above it, the provider calls and waits. Example clocks to negotiate, not benchmarks: triage verdict within 30 minutes of acknowledgement, internal severity confirmation within 60 minutes.

Then ask any shortlisted managed IT security services providers two questions: how do you handle a disagreement with our classification, and who breaks the tie? If the answer names no individual, you have found the gap before an attacker does. AI-driven threat detection speeds the first pass, but the business-impact call still belongs to someone on your payroll.

Line Three: Containment, Who Can Act Without Asking

Triage tells you the incident is real. Containment decides what you are allowed to do about it, which is where authority meets liability: the action may degrade or disconnect something that is running a revenue process.

Write the split before you need it. A workable model is that the provider recommends and executes containment actions from a predefined list, while your team or the business sponsor authorizes anything with operational impact beyond it. Pre-authorization is the fix. List what the provider may do unilaterally at 3 a.m., such as disabling a single account or blocking an external address, and what requires a call first, such as isolating a production server or disabling a service account with broad access.

Name the break-glass authority, the one person who can approve an out-of-hours shutdown, and give the provider that number plus a deputy’s. Without it, the decision waits until morning. Documented pre-authorization also answers the liability question later, because the decision was made by policy rather than by whoever happened to answer the phone.

Agree in advance what evidence must be captured before containment: volatile memory, running processes, active network connections. Otherwise you are choosing between stopping the incident and proving what happened. Build the evidence list into your NIST risk assessment framework review so it survives staff changes.

Example clock, negotiable: containment decision within 60 minutes of a confirmed high-severity incident.

That decision point, and who may fire it, is also what makes endpoint isolation the most contested line in the map.

Line Four: Endpoint Isolation, the Most Contested Line

Containment stops spread; isolation stops one host and the person using it. That dual effect makes endpoint isolation the first line the business pushes back on and the first place ownership drifts. The provider detects and isolates per policy. Your team owns user impact: spare hardware, reimaging, and getting the person working again.

Set isolation criteria before the incident. A known-bad process, beaconing traffic, or a ransomware indicator should trigger isolation as a policy lookup, not a 3am debate about seniority. Document those triggers first; this mid-market endpoint security buyer’s guide compares how EDR and XDR platforms support them.

Pre-write the user message. Someone specific must tell the affected employee their machine is offline and what to do instead. Name who authorizes reconnection, and define the evidence required before a host returns to the network. A typical standard: clean rescan, removal of the identified process, and confirmation the host is patched. Write the standard down so it is not negotiated under pressure.

Example clock, negotiable: isolation executed within 15 minutes of a confirmed endpoint compromise, user notified within 30 minutes. Ask managed security services providers to show the isolation policy in writing, including who can override it and how each override is logged.

Isolation is visible and immediate; patching is the slower version of the same argument, where ownership of the fix window decides whether the vulnerability actually closes.

Line Five: Patching and Remediation, Who Owns the Window

Once a host is back online, the next question is how it became vulnerable in the first place. Patching bundles two jobs that teams routinely conflate: the vulnerability decision, meaning what matters and what gets fixed first, and the maintenance action, meaning deploying the change inside an approved window. NIST SP 800-40r4 defines enterprise patch management as identifying, prioritizing, acquiring, installing, and verifying, which is a clean way to see where the seam falls.

The split. The provider owns scanning, prioritization input, and reporting. Your team owns change approval and the business calendar. The provider deploys only to covered endpoints, so list those endpoints by name rather than assuming coverage.

The handoff that breaks. A prioritized vulnerability list that arrives without an owner and a date becomes a report nobody acts on. Refuse a line item without both. The same discipline underpins any vulnerability management program for mid-market organizations.

Risk acceptance. Decide who can formally accept risk in writing, how long an exception lives, and who reviews it when it expires. An exception nobody revisits is unowned risk with a timestamp.

Emergency patching. Agree the process before you need it, including who approves an unplanned outage. Example clock, negotiable: critical vulnerability triaged within 24 hours, remediated or formally risk-accepted within 7 days. Ask MSSP providers how patching is priced and whether it covers third-party applications, not just the operating system.

Next: who actually calls the user at 2am.

Line Six: User Communications and the 2am Call

Patching settles what gets fixed. This line settles who gets woken, and it is the one your business will remember, because it happens at 2 a.m.

Two audiences, two owners

The affected user receives a short practical message from your team: what happened, whether the device is offline, what to do next. Technical notification to your internal on-call contact comes from the provider. Keep those separate. The provider is not the right voice for the employee; your service desk is.

One hop, not a group chat

Write it plainly: the provider calls the named on-call person. The on-call person calls the business sponsor. One hop. A group chat where everyone assumes someone dialed is how a high-severity incident waits until morning.

Publish the escalation ladder

Document tiers, contact order, time to acknowledge per tier, and what the provider does when nobody answers. An unanswered call is a defined outcome, with the next tier engaged and the attempt logged, not a dead end.

Who notifies regulators, insurers, and clients

Confirm each obligation and its deadline with counsel. Requirements differ by sector and jurisdiction, and a provider’s default assumption is not a legal opinion. Put the named owner and the clock in the same table as everything else.

Example clock, negotiable: on-call contact reached within 15 minutes, business sponsor within 60. Log every attempt. Test the full ladder with your provider regularly, quarterly is a common starting point, though your own incident cadence and any applicable business-continuity standard should set the interval. Those six lines are what the consolidated table captures.

The Consolidated RACI Table: One Owner and One Clock per Line

The escalation ladder is one line item in a larger map. Consolidate all of them into a single table, because a split held across separate documents dissolves at the first staff change.

The last two columns are what turn a discussion into something enforceable. Closure is where ownership dissolves fastest, so assign it anyway.

Add an “unassigned by agreement” column so a blank cell is a deliberate decision, not an oversight.

Then attach the agreed version to the statement of work. Managed cybersecurity solutions differ in how far they will commit to clocks and evidence; this table surfaces that before you sign, not at 2am.

Explaining the Split to the Business in Plain Language

The RACI table is an internal instrument. Give the business a one-page translation instead, built on four questions: what can happen, how fast we would know, what we would do, and who decides. Keep it free of severity labels and product names. Executives do not need your tiers; they need to know the business has an answer.

Three questions will follow, so answer them before they are asked. Cost of an outage versus cost of an incident: state how you weigh a planned disruption against an uncontrolled one, using your own figures. Liability: name which party owns each decision, and note that the split is documented. Diligence: show the map, the clocks, and the last review as evidence of a managed process.

Then handle the question that always comes: why pay a provider and still staff an internal on-call rotation? The answer is named ownership, not duplicated work. Your team owns business impact, user impact, and change approval; the provider owns monitoring, first-pass triage, and execution within pre-authorized limits. Two roles, one function.

Frame the provider as a named participant in your cybersecurity risk management, the approach SP 800-61 Rev. 3 formalises.

Finally, keep the page current. Update it after every incident review, incorporate joint lessons-learned sessions, and reflect staffing changes on both sides. A document drawn from last year’s org chart describes an organization you no longer have, which is how handoffs quietly revert to assumption.

Five Handoffs That Break in Practice

A plain-language page wins the meeting. Handoffs are where that map gets tested.

1. The ticket handoff. If the provider’s platform and your ITSM are not integrated, alerts the provider closes never appear on your side. Your incident log then understates reality. Fix: one shared queue, or a mandatory mirrored ticket for every alert above a set severity.
2. The severity disagreement. The provider closes something as benign, and you learn about it from a user. Fix: a mandatory-notify list of alert types that overrides the verdict and reaches a named internal contact regardless of severity.
3. The after-hours gap. When an incident lands at 2am, nobody is certain who is on call. Fix: one published ladder, a deputy at every tier, and a quarterly test call to confirm both ends still answer.
4. The unowned remediation. A prioritized list arrives with no owner and no date, so it becomes a report nobody acts on. Fix: refuse any line item without both, and log every risk exception with an expiry date someone reviews.
5. The staff-change handoff. Your champion at the provider or on your team leaves, and the split quietly reverts to assumption. Fix: keep the agreed map in the contract and review it after every severity-1 incident.

These five are practitioner judgment, offered to test against your own incident history rather than accepted as benchmarks. Close them and the map survives contact with a real incident.

Take the Map Into Your Next Contract Review

The handoffs are the diagnosis. The contract is the treatment.

Step 1: Pick your three highest-harm lines. Choose the three responsibility lines where failure would hurt most. For many mid-market teams that means containment, endpoint isolation, and user communications. Write owner, escalation trigger, and clock for each one before your next provider conversation.

Step 2: Compare versions. Fill the table twice, your version and the provider’s, and negotiate every gap.

Step 3: Attach it. Append it to the statement of work so ownership survives staff changes on either side.

Step 4: Test the ladder. Run the after-hours escalation end to end and log each hop’s duration.

Step 5: Review it. Reopen the map after every severity-1 incident and at least annually, and keep it in plain language so the business can read it too. SP 800-61 Rev. 3, voluntary, free, and supplier-neutral, is the activity backbone.

Bring the table, not the brochure, to the next conversation.

Conclusion

Co-managed security rarely fails because a tool is missing. It fails at the seams. The map in this guide gives you the owner, the clock, and the negotiation point for each line.

Start with your three highest-harm lines before the next provider conversation.

Then bring the table, not the brochure. Ownership you can point to is ownership that survives contact with a real incident.