Co-Managed IT Renewal: Define What Your Team Owns Before You Extend the MSP
Co-managed IT sounds simple. Your internal team keeps control, and the provider adds people and expertise where you need help.
Internal IT starts handling escalations the service desk could not close. The MSP waits for approvals nobody knew the customer had to provide. Projects sit outside the monthly fee. Security alerts move between providers. One strong internal employee becomes the translator for the entire relationship.
Both teams may be working hard. The operating model can still be wrong.
Before you renew a co-managed IT agreement, define the work your team will retain, prove the provider owns the work you expect it to own, and price the gaps between them. Renew a responsibility model, not a collaboration label.
Start with the work, not the logo on the ticket
A co-managed agreement often describes broad categories such as help desk, monitoring, patching, backup, cybersecurity, and projects. Those labels are too broad for a renewal decision.
“The MSP handles patching” leaves several jobs unanswered. Who approves the maintenance window? Who tests a line-of-business application? Who resolves a failed deployment? Who accepts an exception? Who reports the risk to leadership? Who owns the device that never checks in?
Turn every service category into work that can be assigned and tested. Use a responsibility record with these fields:
| Work item | Primary owner | Provider task | Internal task | Trigger or schedule | Evidence | Escalation owner |
|---|---|---|---|---|---|---|
| Endpoint patching | Named role | Deploy approved patches and investigate failures | Approve windows and application exceptions | Monthly cycle | Coverage and exception report | Infrastructure lead |
| New-user setup | Named role | Create listed accounts and prepare managed device | Approve access and confirm role | Approved request | Ticket and access record | IT manager |
| Backup failure | Named role | Review job, correct supported issue, and escalate | Decide business priority and approve recovery work | Failed-job alert | Job history and ticket | Systems owner |
| Firewall change | Named role | Prepare and implement approved rule | Validate business need and risk | Approved change | Change record and configuration history | Network owner |
NIST Cybersecurity Framework 2.0 gives buyers a useful standard for the security portion of this model. It says cybersecurity roles, responsibilities, and authorities should be established, communicated, understood, and enforced. It also calls for supplier and customer security roles to be coordinated internally and externally, with supply-chain security requirements integrated into contracts and other agreements.
An outsourced activity still needs an understood role, authority, and agreement.
Map the recurring work your team still performs
The invoice does not show how much managed service your internal team supplies for free.
Review the last six to twelve months of tickets, changes, incidents, projects, invoices, service reports, and meeting notes. Ask your team where its time went. Focus on recurring work that was necessary to make the provider successful:
- Reclassifying or escalating tickets
- Supplying missing asset, user, or application context
- Coordinating carriers, software vendors, and security providers
- Approving routine changes one by one
- Testing patches and application changes
- Correcting documentation
- Reviewing alerts that lacked business context
- Chasing open problems across several queues
- Completing work that landed outside scope
- Training provider staff after account turnover
Some of that work should stay internal. Business priority, risk acceptance, access approval, budget decisions, and communication with leadership rarely belong entirely to the MSP.
The renewal problem is hidden labor, not retained labor. If an IT manager spends ten hours every week translating between the business and the provider, decide whether that is a necessary leadership function, a correctable service gap, or an operating cost the company has never priced.
Assign each repeated task to one of four states: intentionally internal, included in the provider scope, separately billable, or currently unowned.
Test five boundaries that usually create friction
A responsibility matrix can look complete and still fail at the handoffs. Use current-term evidence to test the boundaries where co-managed services get messy.
Service desk to internal escalation
Pull a sample of tickets that reached internal IT. Why did they move?
Some escalations are healthy. The provider may need business approval, application expertise, physical access, or a decision outside its authority. Others expose a scope or capability problem.
For each escalated ticket, record the reason, elapsed time, internal labor, final owner, and whether the same issue is likely to happen again. Then decide whether the next term needs better documentation, broader access, a different skill tier, a scope correction, or a clean internal owner.
Monitoring to action
Monitoring is useful only when an alert reaches somebody who can make a decision or take an action.
Choose representative alerts from endpoints, servers, backups, networks, identity systems, and security tools. Trace each one from detection to closure. Confirm who reviewed it, what context was available, which action followed, when internal IT joined, and what evidence shows the condition was fixed.
A dashboard can be green while internal IT still does the investigation. Price the work, not the dashboard.
Operations to project work
Routine support and project work need a visible border.
Ask what happens when a ticket reveals a larger fix: replacing a firewall, rebuilding a server, migrating an application, redesigning identity, remediating technical debt, or onboarding a new location. Does the provider diagnose the problem inside the base service? Who scopes the project? Is planning billable? Can another provider perform the work? Does the MSP continue operational support during the change?
Review every change order from the current term. A monthly service that repeatedly discovers predictable out-of-scope work may need a different commercial design.
Security to IT operations
Security work crosses tools and teams fast. An MDR provider may flag an endpoint. The MSP may administer it. Internal IT may own the identity platform. A business leader may need to approve disruption.
Do not duplicate the detailed managed IT incident ownership test. For this renewal, confirm the everyday security handoffs: vulnerability remediation, patch exceptions, privileged access reviews, risky sign-ins, failed security agents, backup alerts, phishing reports, policy changes, and evidence requests.
Assign the first action, final decision, authority limit, response clock, and escalation path for each. If another provider is involved, include that provider in the map.
Business hours to after-hours support
“24/7” does not tell you whether the overnight team can resolve your problem.
Match critical business workflows to the provider’s intake, triage, engineering, dispatch, and vendor-coordination coverage. Confirm what is staffed, what is on call, what triggers a premium fee, and which customer approvals are required.
The after-hours support renewal checklist goes deeper on response clocks and escalation depth. Your co-managed responsibility map should show who on the internal team remains on call, for which decisions, and with what backup.
Check whether the model depends on one person
Co-managed IT often works because one capable employee knows the environment, the contract, the provider team, the business owners, and every workaround. That person makes a weak model look strong.
Test the relationship without the usual translator. Choose a normal request, an escalated issue, a change, and a critical alert. Ask whether another internal employee and the provider can complete the work using the current documentation, access, contacts, and approval rules.
Check both sides:
- Does the provider rely on one technician who knows your environment?
- Does internal IT rely on one manager to approve every material action?
- Can backup contacts access the portals and records they need?
- Are recurring exceptions documented or trapped in memory?
- Can either team explain open risks and current priorities without a weekly verbal download?
If the answer is no, require current documentation, backup roles, access validation, and handoff procedures. Do not add another vague promise to “collaborate closely.”
Price the next term as an operating model
Compare more than the monthly MSP fee.
Build the next-term cost from the provider fee, expected projects, variable charges, retained internal labor, specialist services, overlapping tools, and coverage the business still needs elsewhere. Then compare that total with the outcomes and capacity you receive.
A lower provider fee may be a poor value if senior internal staff spend their week moving tickets and coordinating vendors. A broader service may also be wasteful if the internal team already has the skill and capacity to own the work.
Use staffing plans in the decision. If the company expects the MSP to cover a vacancy, new location, acquisition, cloud migration, compliance demand, or after-hours workload, put that change into the responsibility map and price it now. The old split may not survive the next year.
Review the bundled technology separately. The MSP tool-stack renewal audit helps reconcile tools, coverage, tenant ownership, evidence, overlap, and exit rights. A tool license does not prove either team is operating it well.
Put the renewal into a decision state
Use the evidence to make one of these decisions:
Renew as scoped when the responsibility map matches reality, both teams have enough capacity, current-term evidence supports delivery, and retained internal work is understood.
Renew with corrections when the provider still fits but the agreement needs clearer tasks, authority, reporting, staffing, support hours, or escalation rules. Put the corrections into the signed scope or a controlled schedule referenced by it.
Redesign the co-managed model when too much work is bouncing between teams, internal capacity has changed, or the company needs a different division of operations, security, projects, and strategy.
Run a competitive review when the provider cannot define the service, repeatedly fails the assigned work, lacks the needed skills or coverage, or will not provide evidence and transition terms.
Use a short bridge when the notice deadline is close and material ownership, staffing, or transition questions remain open. Do not sign a long term just because the current model is hard to replace quickly.
The managed IT versus co-managed IT guide can help if you are reconsidering the model itself. This renewal test is narrower. It asks whether the division of work you already bought is clear, staffed, and worth the combined cost.
Renew the split you can prove
A co-managed relationship should give internal IT more leverage. The provider should add capacity and specialist depth without stripping the company of control or business context.
That only works when both sides know where the line is.
Bring the agreement, statement of work, invoices, ticket exports, change orders, service reports, access records, project backlog, staffing plan, and escalation history into the review. Build the responsibility map. Test the handoffs. Price the internal work. Fix the written scope before the signature.
If your co-managed IT agreement is approaching renewal, request a Contract and Spend Risk Review. Catch Advisors will help you find blurred ownership, hidden internal labor, scope gaps, and buying leverage so you can decide what to renew, correct, redesign, or compare.