Co-managed IT sounds simple in principle: your internal IT person handles the day-to-day, the MSP handles the specialist work. In practice, the arrangement breaks down the moment an incident happens and both teams are waiting for the other to take ownership. The fix is not a better working relationship. It is a written responsibility matrix, agreed before anything goes live, reviewed every quarter. This article gives you that matrix, built specifically for a Mac-first business.
Why informal co-managed arrangements fail, and what formal ones look like
Most businesses running co-managed IT do not have a formal one. They have an internal IT person alongside an MSP contract, with no written line between them. That looks like co-managed IT, but it behaves like break-fix with a managed service contract attached.
The symptoms are recognisable: tickets fall between teams because neither is sure who owns them. Incidents generate a conversation about responsibility before anyone starts fixing. The MSP handles requests that should stay internal, or the internal IT person escalates things the MSP never needs to see. Both sides develop workarounds. Neither has a clear picture of the whole.
The difference between this and a formal co-managed arrangement is a single document.
The written responsibility matrix: what it is and why it exists
A responsibility matrix is a document that lists every IT function and names which team owns it, internal, MSP, or shared, along with who is the escalation point when something goes wrong. It is not a contract amendment. It is a working reference that both teams use when scope is unclear. Without it, co-managed IT has no defined operating model, only assumptions.
The quarterly review: why the matrix goes stale
Responsibilities shift when the business changes. New headcount, a compliance requirement, a platform migration, any of these can move a function from one column to another. The matrix needs a named owner and a quarterly review date. In Dr Logic’s experience, this is the most commonly skipped step in co-managed arrangements. The matrix gets agreed, then never updated, and within six months neither team is working from the same set of assumptions.
The responsibility matrix: a starting point for Mac-first businesses
This is the centrepiece of a working co-managed arrangement. Use this as a starting template and add rows for any function specific to your environment. The three columns reflect the most common split; some rows will be adjusted depending on your internal IT team’s capabilities.
| IT Function | Internal IT Owns | MSP Owns | Shared (with Escalation Path) |
|---|---|---|---|
| Passwords resets and account unlocks | Yes | - | - |
| Device connectivity and Wi-Fi issues | Yes | - | - |
| Peripheral and printer support | Yes | - | - |
| App access issues (non-MDM) | - | Yes | - |
| MDM configuration and policy enforcement | - | Yes | - |
| Security monitoring and incident response | - | Yes | - |
| Cyber Essentials programme management | - | Yes | - |
| Device enrollment and zero-touch deployment | - | Yes | - |
| Device wipes on offboarding | - | Yes | Internal IT triggers, MSP executes |
| New starter account provisioning | - | - | Yes - internal IT notifies, MSP provisions |
| App installation (MDM-managed) | - | - | Yes - internal IT requests, MSP pushes |
| IT strategy and vendor advisory | - | - | Yes - depends on whether an internal IT Director or CTO exists |
| Hardware procurement | - | - | Yes - internal IT specifies; MSP procures or advises |
Helpdesk and first-line support
Internal IT owns first-line. The scope is password resets, device connectivity, app access issues, and peripheral problems. Escalation to the MSP should be reserved for issues requiring DMS (formerly MDM) intervention, security investigation, or infrastructure access. The line should be explicit. Internal IT should not escalate routine requests, and the MSP should not handle requests that do not require specialist capability. When this boundary is unclear, both teams become less efficient and ticket resolution time suffers.
Device management and DMS
This is the most commonly unclear area in a Mac fleet. Who holds the Jamf or Apple Business admin account? Who pushes configuration profiles? Who enrols new devices? Who handles wipes on offboarding? The recommended split: the MSP owns DMS (formerly MDM) configuration, policy enforcement, and compliance reporting. Internal IT owns day-to-day device requests, app installs, profile queries, and reports DMS anomalies to the MSP. The MSP should not need the internal IT person to action DMS changes on their behalf. That creates a bottleneck and a dependency that undermines the model.
Security operations and cyber essentials
The MSP owns this. Security monitoring, incident response, Cyber Essentials programme management, CE renewal cycle, and evidence collection. Internal IT supports by enforcing local policies and flagging anomalies upward. Security operations should not be a shared function in a co-managed model. If the internal IT person is also the Cyber Essentials evidence owner, the arrangement has a single point of failure. If that person leaves, the certification lapses.
Onboarding and offboarding
Shared, with a defined handoff. Internal IT owns the HR-to-IT notification workflow, they know when a new starter is joining and when someone is leaving. The MSP owns technical execution: device enrolment, account provisioning, offboarding checklist (DMS wipe, account deactivation, licence recovery). The handoff point should be named and the timeline agreed in writing. For offboarding, same-day execution is the standard, access should not remain active after a departure is confirmed.
IT strategy and vendor relationships
This depends on whether the business has an IT Director or CTO internally. If yes: internal owns strategy, the MSP executes. If not: the MSP provides strategic guidance as part of the managed service. This should be explicit in the contract, not assumed. Many co-managed arrangements drift into the MSP providing strategic advice informally, without it being scoped or paid for. That creates ambiguity about what is included and resentment on both sides when expectations diverge.
The Apple-specific questions most responsibility matrices miss
Generic co-managed IT guidance is written for Windows environments. These are the Apple-specific ownership questions that rarely appear in standard templates but consistently cause problems in Mac-first businesses.
Who holds the Apple Business admin account?
One person. Not shared. The Apple Business admin account is the root of the entire Apple deployment infrastructure, it controls device enrollment, app licensing, and the DMS integration. If the internal IT person holds it, the MSP cannot act without them. If the MSP holds it, the business has a dependency on a third party for access to its own device estate.
Dr Logic’s recommended approach: the business holds the admin account, and the MSP holds a Managed Apple Account with admin-level access. This gives the business sovereignty over its own Apple infrastructure while allowing the MSP to operate fully without requiring the internal IT person to be present for every action.
What happens to DMS access when the internal IT person leaves?
The most commonly overlooked offboarding scenario in a co-managed setup. If the internal IT person holds credentials to the DMS or Apple Business account, their departure creates an access gap, potentially affecting the ability to enrol new devices or push emergency security policies until access is recovered. The responsibility matrix should name this explicitly: all IT system credentials are stored in the shared vault (1Password or equivalent), never in personal accounts, and access is reviewed at every quarterly matrix review.
Three signs your co-managed arrangement is working, and three signs it is not
Working:
- Tickets resolve at the right tier without escalation confusion. Routine requests stay internal. Specialist work reaches the MSP without delay.
- The quarterly review produces action points. It is not just a sign-off, both teams leave with something to change.
- Both teams can answer “who do I call if X happens?” without needing to ask the other team first.
Not working:
- The MSP is handling first-line requests because the internal IT person is at capacity.
- Incidents generate a conversation about ownership before anyone starts resolving them.
- The responsibility matrix has not been updated in six months, and both teams are operating from different assumptions about what is included.
If you are running a co-managed arrangement and want to pressure-test your responsibility matrix against what actually works in practice, Dr Logic can review your current setup. We co-manage IT for Mac-first businesses across the UK and can identify where the gaps are before they become incidents. Talk to our IT support team.
Related articles
- Co-Managed IT vs Fully Outsourced IT: Which Model Actually Fits Your Business?
- What Good IT Support Actually Looks Like: A No-Nonsense Guide for UK Businesses Choosing or Reviewing an MSP
- After 30 Mac Deployments: The Prerequisites Nobody Warns You About
FAQs
What is a co-managed IT responsibility matrix?
A responsibility matrix is a written document that lists every IT function in your business and names which team owns it: internal IT, the MSP, or both. It includes escalation paths for each function. Without one, co-managed IT has no defined operating model, only informal assumptions that break down under pressure.
Who should hold the Apple Business admin account in a co-managed arrangement?
The business should hold the primary admin account, not the MSP. The MSP should operate via a Managed Apple Account with admin-level access. This approach gives the business full control over its Apple infrastructure while allowing the MSP to act independently on a daily basis. It also prevents a dependency that becomes critical if the MSP relationship changes.
How often should a co-managed IT responsibility matrix be reviewed?
How often should a co-managed IT responsibility matrix be reviewed? Quarterly. Business changes, new headcount, new compliance requirements, platform migrations, shift responsibilities between teams. A matrix that was accurate six months ago may no longer reflect how either team is operating. Quarterly review with a named owner is the standard that prevents the matrix from becoming a historical document rather than a working one.
