Co-managed IT works when an employee knows where to ask for help and both technical teams know who acts next. Use this matrix as a starting point for a service discussion. The assignments below are illustrative, not a prescribed split for every organization.
Separate decisions from delivery
For each service, name the internal role that approves the outcome and the team that performs the work. The approver needs authority to decide; the operator needs access, capacity, and a clear trigger. Assign a backup for absences. “Shared” is not a useful answer unless it comes with a routing rule.
Start with the work you want to retain. An internal IT manager might own architecture and application priorities while an MSP handles support and routine maintenance. Another team may keep the service desk and buy only security operations or infrastructure coverage. Document actual duties before comparing tool bundles.
Use a responsibility matrix for everyday operations
Replace these example role names with your own before contracting. Add service hours, escalation contacts, exclusions, and acceptance evidence to every row. A request should have one active owner even if several people contribute.
| Activity | Internal owner / decision | MSP delivery role | Evidence of completion |
|---|---|---|---|
| New employee access | Manager approves role; internal IT approves access profile | Creates agreed accounts and enrolls device | Approved request and sign-in check |
| Employee departure | HR or authorized manager specifies timing and data owner | Revokes access and transfers approved assets | Timestamped access and device checklist |
| Help desk | Internal IT sets priorities and application boundaries | Owns intake, triage, updates, and scoped resolution | One ticket with next owner and next update |
| Patching | System owner approves maintenance windows and exceptions | Deploys updates and investigates failures | Coverage report and exception list |
| Security alerts | Leadership approves containment authority in advance | Investigates scoped alerts and performs authorized containment | Incident timeline and action record |
| Backup and restore | Business owner sets recovery priorities and accepts results | Monitors backup jobs and performs agreed restores | Restore test and business acceptance |
| Network changes | Internal IT approves design and business impact | Implements scoped change with rollback plan | Change record and validation |
| Application vendor issues | Application owner validates business function | Coordinates vendor when included in scope | Vendor case and user acceptance |
| Projects and spending | Budget owner approves scope and cost | Estimates work and delivers approved milestones | Acceptance record and cost reconciliation |
Write the handoff rule beside the task
Define the trigger that transfers work, the information that must accompany it, and the response expected from the receiving team. Keep the authoritative ticket or change record visible to both teams. A forwarded email without acceptance should not end responsibility.
For example, an MSP can complete first-line troubleshooting for a finance application, then hand the case to the internal application owner with the error, affected users, tests performed, vendor case number, and business deadline. The MSP remains responsible for user updates until the receiving owner accepts the handoff, if that is the agreed rule.
- State who owns the ticket while waiting for a vendor.
- Name the person who resolves a disputed priority.
- Record who tells employees about an outage or workaround.
- Define escalation when the next team cannot accept the work.
Test an after-hours incident
Suppose an employee reports a suspicious sign-in on Saturday. Who receives the report? Who can investigate the account, revoke sessions, or isolate a device? Which actions are preauthorized, and which require the on-call business contact? The answer must match the contracted hours and access permissions.
Walk through a failed backup and an office internet outage as well. An answering service, alerting platform, and staffed response team perform different jobs. Record which service you are purchasing and what happens when the designated approver is unreachable. Do not assume that business-hours help desk coverage includes weekend security response.
Keep administrative access and tools accountable
Name the owner of each tenant, domain, management platform, backup repository, and vendor account. Use individual administrative identities and the access controls agreed for the environment. Record how permissions are approved, reviewed, and removed. Emergency access should have an owner and a documented test.
If both teams manage the same devices, decide which system controls patching, protection, and configuration. Overlapping policies can create conflicting changes. When the provider supplies a tool, document the records and exports the organization can retain at exit. Store credentials through an approved secure process; the responsibility table should contain roles and references, not secrets.
Accept the operating model before calling onboarding complete
Run a small set of representative checks: a new starter request, a support escalation, an approved change, a restore, and an out-of-hours call if that coverage is in scope. Both teams should be able to locate the record, name the next owner, and explain the evidence required to close it.
Keep failed checks on an exceptions list with an owner and an agreed resolution date. Avoid declaring the model complete because monitoring agents are installed. The operational handoffs matter as much as technical deployment.
Review the boundaries when circumstances change
Use the service review to examine tickets passed between teams, requests waiting for approval, duplicated work, failed changes, and recovery exceptions. Ask whether internal IT is gaining capacity for the priorities that justified co-management.
Update the matrix when staffing, locations, applications, coverage hours, or budgets change. Put material changes into the service schedule with pricing and acceptance criteria. A current matrix is an operating agreement; an old matrix can conceal unowned work.
Sources and further reading
Primary references for the topics identified below. Examples, checklists, and purchasing recommendations are editorial guidance.
- CISA: Risk considerations for managed service provider customers ↗
Security considerations when defining and overseeing outsourced services.
Published by Bay Area Managed IT. Examples are illustrative; they are not provider quotes, audited results, or local market survey findings. Read our editorial approach →
Describe the capability your internal team needs.
Share your location, organization size, service needs, and timing to request provider matching.
Request a provider match →