Co-managed IT: who is responsible for what?
An internal IT team can know the organisation inside out and still need help. Support requests compete with projects. Security tools need attention. A complex infrastructure problem can absorb the time of the person who is also expected to keep everything else moving.
Co-managed IT adds an external partner to that team. Before agreeing the service, however, there is a question both IT and leadership need answered:
Who will do the work, who can make decisions, and who will make sure an issue reaches a resolution?
How does co-managed IT work?
Co-managed IT combines the knowledge of your internal people with additional operational capacity or specialist expertise.
The arrangement can take several forms. Your team might handle everyday support while a partner provides advanced engineering. Alternatively, an external service desk might handle routine requests while your internal team leads applications and projects. Patching, vulnerability management or security operations can also be agreed as specific services.
The right split depends on your systems, people and priorities. First-, second- and third-line support need explicit owners, including any application suppliers involved.
A useful agreement describes actual work: the systems covered, tasks to complete, service hours, dependencies and evidence you should receive.
A co-managed IT responsibility matrix: an example
The following table illustrates one possible division of work. It is a starting point for a discussion, rather than a standard contract or a list of services automatically included.
For your own agreement, replace broad team labels with named roles and record any exclusions.
| Area | Your internal team or business | External partner, where included | Boundary to agree |
|---|---|---|---|
| Everyday user support | Provides business context and any support it retains. | Handles the agreed first-line requests and escalates unresolved issues. | User contact route, support hours and ticket ownership. |
| Complex technical issues | Supplies system context and manages retained application support. | Investigates agreed escalations and delivers specialist engineering. | Who owns each support layer and coordinates vendor involvement. |
| Patching and maintenance | Identifies critical dependencies and approves disruption. | Deploys agreed updates, checks failures and reports exceptions. | Asset coverage, maintenance windows, reboots and emergency authority. |
| Vulnerability management | Helps prioritise business impact and approves changes or exceptions. | Assesses agreed findings, completes assigned fixes and verifies results. | An owner and due date for each finding, including supplier dependencies. |
| Accounts and access | HR and system owners authorise starters, leavers and permissions. | Makes agreed account changes and maintains the technical record. | Approval source, notification deadlines and privileged access. |
| Security alerts and incidents | Names the business incident lead and communication decision-makers. | Performs agreed monitoring, triage, containment and escalation. | Coverage, permitted actions, escalation contacts and handover. |
| Backup and recovery | Defines acceptable disruption and which services recover first. | Operates agreed backup checks, restore testing and recovery tasks. | Systems covered, recovery objectives, test frequency and failure ownership. |
| Projects and procurement | Approves requirements, budget and business acceptance. | Provides agreed design, sourcing, implementation and handover. | Separate project scope, acceptance criteria and ongoing support owner. |
| Compliance evidence | Responsible specialists confirm requirements and approve decisions. | Implements assigned technical controls and supplies agreed evidence. | Who owns each requirement, evidence record and unresolved gap. |
A broad label such as “shared” leaves too much open. A task can involve several people while still having one person responsible for coordinating it.
How does your internal IT team keep control?
Control becomes practical when the agreement describes authority.
Your IT lead should know which changes they approve, which routine tasks the provider can carry out, and which emergency actions are authorised in advance. A scheduled update and an urgent decision to isolate a device may need different approval rules.
Agree administrative access too: named accounts, appropriate permissions, logging and a process for granting or removing access. Your organisation should have a clear record of its tenants, domains and critical accounts.
Visibility supports that control. Agree how both teams access tickets, documentation, change records and reporting. Where they use separate tools, define how information moves between them.
Include an exit process covering access removal, documentation, open issues and data handover, with any notice periods and charges made clear.
Who is accountable when something goes wrong?
The provider should be accountable for the work it has agreed to perform, measured against the agreed service commitments. Your organisation remains responsible for its business priorities, budgets and authorised risk decisions.
Both sides also need a practical answer to ownership during an incident.
Assign a named ticket owner or incident coordinator. Where another team takes over, agree that the handover is complete only when it has been acknowledged. Record the next action, owner and update time.
Involving a software supplier should not leave users chasing three organisations for a status update. Someone needs to coordinate the investigation and communicate progress.
For the wider governance question, see who owns cyber security when you outsource IT support.
Two examples of responsibilities in practice
These are illustrative scenarios, not customer case studies.
Example 1 (illustrative): a security patch fails
The partner deploys an update within the agreed window, but a device fails to install it.
If patching is in scope, the assigned delivery owner investigates and records the exception. If the fix requires disruption, the internal application owner approves the change within the agreed process.
If installation has to be delayed, the authorised risk owner considers the exposure, any temporary safeguards and the next review date. The issue stays visible until the agreed fix or exception has been verified.
“Update attempted” should not silently become “work completed”.
Example 2 (illustrative): an account is compromised outside normal hours
The incident plan needs to identify who sees the alert, who investigates it, and who can disable the account or isolate an affected device.
It also needs a business escalation contact and a route for decisions about service disruption and communications.
Continuous monitoring does not automatically include continuous human response. Define those commitments separately, including time zones, emergency authority and the process if the primary contact cannot be reached.
The people involved should be able to follow the plan without negotiating responsibilities during the incident.
Six questions to settle before signing
- What is covered? List systems, locations, users, activities, service hours and exclusions.
- Who owns each task? Name the delivery owner, approver and escalation contact, including existing suppliers.
- What happens at the boundary? Define handovers, dependencies and the process for work outside the agreed scope.
- How will performance be measured? Distinguish response targets from resolution commitments and agree reporting and review frequency.
- Which decisions need approval? Cover routine changes, emergency actions, additional spending and risk exceptions.
- How will the arrangement change or end? Agree scope reviews, project handover, documentation, access removal and exit responsibilities.
Use strategic IT consultancy to connect operational findings with investment and roadmap decisions. Where assurance requirements apply, governance, risk and compliance work can help organise control ownership and evidence.
Frequently asked questions
Does co-managed IT replace our internal IT team?
It is designed to add agreed capacity or expertise alongside the team you retain. Your agreement should describe both the external partner's work and your internal responsibilities.
Can we keep everyday support and outsource only specialist work?
Yes. A partnership can focus on advanced engineering, patching, vulnerability management or other selected work. Define the escalation process and any dependencies on your internal team.
Who approves changes in co-managed IT?
The person or role named in the agreement. Routine tasks may be authorised in advance; higher-impact changes may need specific approval. Emergency actions should have their own authority and notification rules.
Does co-managed IT automatically include 24/7 support?
No. Support hours, monitoring, alert triage, human response and incident leadership are separate commitments. Check the coverage for each service you are buying.
What happens if an issue involves several providers?
Agree a coordinator and escalation process before service begins. Each provider performs its assigned work, while the coordinator tracks actions, obtains acknowledged handovers and keeps the organisation informed.
Discuss your co-managed requirements or explore co-managed IT.
Make the responsibilities clear before the partnership starts
Cloud Agile builds co-managed engagements around the operational work and specialist capability your team needs, with responsibilities and service coverage agreed for the engagement.
Start with your team's priorities and a list of the work that needs additional support. That provides a practical basis for deciding what stays internally, what a partner delivers and how performance will be reviewed.
Discuss your co-managed requirements