Co-Managed IT Roles & Responsibilities through A Clear Ownership Matrix

If you’re an SMB with a lean internal IT team, co-managed IT can be the best of both worlds: you keep control and context in-house, while your MSP extends your capacity and security depth.

But co-managed only works when ownership is explicit.

Without a clear co-managed IT ownership model, you end up with what we call the ownership problem:

• Tickets bounce between teams because “it’s not ours.”
• Tools drift (multiple admins, inconsistent configs, expired licenses).
• Security alerts get acknowledged but not resolved.
• Projects stall because no one owns the plan, the change window, or the rollback.

That’s why you need a co-managed IT roles and responsibilities matrix for SMBs—not as paperwork, but as a daily operating system.

The ownership problem (and where it shows up first)

In co-managed environments, confusion usually clusters around four areas:

1) Tickets

You get duplicate work, slow response times, and messy escalations when:

• Users don’t know where to submit requests
• The help desk doesn’t know what’s “standard” vs “custom”
• Internal IT gets pulled into every issue “just in case”

2) Tools

Co-managed setups often include overlapping tools: RMM, ticketing, EDR, email security, backup, MDM, password management, SIEM, vulnerability scanning.

If you don’t define who owns:

• Admin access
• Configuration standards
• Alert routing
• License management
• Vendor renewals

…you’ll eventually pay twice and still miss something.

3) Security

Security is where ambiguity becomes risk. If an EDR alert fires at 2:00 AM, someone needs to:

• Triage it
• Contain it
• Investigate scope
• Remediate root cause
• Document and report

If “someone” isn’t named, you’re relying on luck.

4) Projects

Projects fail in co-managed models when there’s no single owner for:

• Requirements and success criteria
• Change management and approvals
• Scheduling and communication
• Testing and rollback

Your co-managed IT RACI matrix template (simple, usable, and specific)

A RACI matrix is a practical way to define ownership:

• R = Responsible (does the work)
• A = Accountable (owns the outcome; final decision maker)
• C = Consulted (provides input)
• I = Informed (kept in the loop)

In a co-managed model, you typically have three parties:

• Internal IT (your team)
• LeafTech (MSP)
• Vendors (SaaS providers, ISP, firewall vendor, etc.)

Below is a starting point you can copy into a spreadsheet. It’s intentionally opinionated—because the goal is clarity.

Co-managed IT roles and responsibilities matrix for SMBs (starter)

Here is the standalone HTML `

Use this as a baseline, then adjust based on your team’s strengths and what you want to keep in-house.

MSP vs internal IT responsibilities (SMB): the clean split that reduces friction

Here’s a practical way to think about it:

Internal IT should usually own (Accountable)

• Business context and priorities
• Access approvals and least-privilege decisions
• Application ownership (what the business uses and why)
• Policy decisions (security posture, acceptable risk)
• Budget ownership and vendor selection

LeafTech (MSP) should usually own (Responsible)

• Standardized execution (tickets, onboarding, patching, monitoring)
• Tooling administration and alert routing
• Documentation and runbooks
• After-hours coverage (if you want it)
• Deep technical troubleshooting and remediation

Vendors should be accountable for

• Their service uptime and platform fixes
• Their escalation paths and support SLAs
• Their security advisories and platform-level incident communications

This split keeps your internal IT team in control without forcing them to be on-call for everything.

Who owns patching in co-managed IT? (the answer that prevents security gaps)

Patching is the most common “assumed” responsibility—and one of the easiest places to get burned.

A clean co-managed approach looks like this:

• LeafTech: Responsible/Accountable for OS and third-party patch deployment via RMM, reporting, and remediation of failed patches.
• Internal IT: Accountable for exceptions: line-of-business app constraints, maintenance windows, and risk acceptance.
• Vendors: Consulted when patching impacts their app requirements or when a vendor advisory dictates timing.

Example patching rules you can adopt

• Critical security patches: deploy within 7 days
• High severity: within 14 days
• Medium: within 30 days
• Exceptions must be documented with owner + next review date

Co-managed IT, ownership model for tickets, tools, security, and projects

To make the matrix operational, define ownership at three levels:

1) Intake ownership (where work enters)

• One ticketing system
• One support email/portal
• Clear categories (access, hardware, network, app, security)

2) Tool ownership (where work is executed)

• One RMM for patching/monitoring
• One EDR for endpoint protection
• One backup standard

If you keep some tools in-house, that’s fine—just decide who is admin, who maintains policies, and who responds to alerts.

3) Outcome ownership (who closes the loop)

Every ticket and alert needs:

• A named closer
• A definition of “done”
• Documentation updates when the fix becomes repeatable

Practical examples (RACI-style) you can plug into your matrix

These are the scenarios SMBs constantly ask about.

Example 1: New user setup

• Internal IT: A (approves access and role-based permissions)
• LeafTech: R (creates the account, assigns licenses, configures the device, enables MFA, and applies baseline policies)
• Vendor: I (only if SaaS licensing or support is involved)

Escalation rule: if access request is non-standard (new app, elevated permissions), internal IT must approve before execution.

Example 2: EDR alert (possible malware)

• LeafTech: R/A for triage, containment, investigation, and remediation steps
• Internal IT: A for business-impact decisions, such as isolating a device, disabling an account, or notifying leadership
• Vendor: C if escalation to EDR vendor support is required

Escalation rule: any “high confidence” alert triggers immediate containment and a same-day incident summary.

Example 3: SaaS outage (e.g., Microsoft 365, QuickBooks Online, CRM)

• LeafTech: R for confirming scope, user comms template, workaround guidance
• Vendor: A for restoring service
• Internal IT: C/A for business continuity decisions (alternate workflows, customer comms)

Escalation rule: if an outage impacts revenue operations, internal IT leads business comms, while the MSP provides technical status updates.

Example 4: Network change (new VLAN, Wi-Fi changes, firewall rules)

• Internal IT: A for approving change and timing
• LeafTech: R/A for design, implementation, testing, rollback plan
• Vendor: C if ISP or managed firewall provider is involved

Escalation rule: no production network change without a documented rollback and a scheduled window.

Example 5: Procurement (new laptops, firewall refresh, licensing)

• Internal IT: A for standards and budget
• LeafTech: R for sourcing, quotes, compatibility validation, staging
• Vendor: C/I depending on warranty, lead times, and licensing terms

Escalation rule: any non-standard device requires internal IT sign-off.

Co-managed IT responsibilities for vendors (SaaS / ISP / firewall)

Vendors are part of your operating model whether you like it or not. The mistake is treating them as “someone else’s problem.”

In your matrix, define:

• Who opens vendor tickets
• Who owns vendor account portals
• Who is listed as the authorized contact
• What information is required to escalate (logs, screenshots, timestamps)

A practical pattern:

• LeafTech: Opens and manages vendor cases for infrastructure and security tools.
• Internal IT: Owns vendor relationships tied to business applications and contracts.
• Vendors: Accountable for platform fixes and SLA commitments.

Shared IT support model escalation rules (simple and enforceable)

Escalation rules keep co-managed from turning into chaos. Here’s a starter set:

• L1 → L2: If not resolved within 30 minutes of active troubleshooting
• L2 → L3/Internal IT: If it requires business process knowledge, policy decisions, or non-standard access
• Any → Security Escalation: If it involves suspected compromise, credential exposure, or repeated failed logins
• Any → Vendor Escalation: If it is a confirmed platform issue outside your environment

Also define:

• After-hours coverage expectations
• What counts as an emergency
• Who can approve disruptive actions (device isolation, account lockout)

Downloadable-style: Co-managed IT governance checklist

Copy/paste this into a doc and treat it like a quarterly tune-up.

Governance checklist (weekly)

1. Review open ticket aging (by category and owner)
2. Confirm escalations followed the rules (no silent handoffs)
3. Spot-check documentation updates for repeat issues

Governance checklist (monthly)

1. Patch compliance report reviewed and exceptions documented
2. EDR alert summary reviewed (trends, repeat offenders, false positives)
3. Backup success rate reviewed and failures remediated
4. Admin access review (who has global admin, firewall admin, RMM admin)
5. Vendor cases reviewed (SaaS/ISP/firewall) and SLAs validated

Governance checklist (quarterly)

1. Update the co-managed IT RACI matrix (roles change fast)
2. Run a restore test (file-level and image-level, if applicable)
3. Review MFA and conditional access policies
4. Review endpoint standards (encryption, local admin, device health)
5. Review the network diagram and asset inventory
6. Confirm incident response contacts and the tabletop exercise schedule

CTA: Map your current responsibilities in a fit call

If you’re seeing slow tickets, tool sprawl, or security alerts that don’t feel “owned,” you don’t need another meeting. You need a clear matrix.

In a short fit call, we’ll help you map your current model into a co-managed IT roles-and-responsibilities matrix for SMBs—including tickets, tools, security, projects, and vendor boundaries—so you can move faster with fewer surprises.

If you want, reply with:

• Your internal IT headcount
• Your top five recurring ticket types
• The tools you use for ticketing, RMM, EDR, and backup

…and we’ll suggest a clean first-pass ownership model you can adopt immediately.