For an Information Technology (IT) manager, bringing in a Managed Service Provider (MSP) can create one of two very different outcomes. In the best version, the MSP becomes an extension of the internal team: adding after-hours coverage, specialist expertise, monitoring, security capacity, project resources, and a reliable escalation path. In the worst version, responsibilities overlap, tickets bounce between teams, changes happen without communication, and the internal manager spends more time coordinating the provider than the provider saves.
The difference is rarely the service catalog alone. It is the operating model. A successful co-managed IT relationship works when the internal team and external provider agree on ownership, tools, escalation, communication, and success measures before day-to-day pressure exposes the gaps.
This guide is written for IT managers who want outside capacity without losing internal authority or business context. It focuses on the practical habits that make an IT manager-MSP partnership work over time, including how to divide responsibilities, protect decision rights, manage change, share documentation, and keep the relationship focused on outcomes rather than ticket volume.
Start With the Right Mental Model: Co-Managed Does Not Mean Outsourced
A co-managed relationship is not a halfway version of fully outsourced IT. It is a deliberate partnership in which the internal team remains part of the operating model and the MSP is added where external scale or specialization creates value. The internal IT manager usually retains the deepest knowledge of business priorities, internal politics, legacy decisions, application dependencies, user expectations, and upcoming organizational change. The MSP brings breadth, coverage, standardized tooling, cross-client experience, and specialist resources.
The goal is not to decide which side is more capable overall. The goal is to place each responsibility with the side best positioned to own it. A small internal team may be excellent at user support and business applications but have no practical way to staff overnight network monitoring. An MSP may have excellent cybersecurity engineers but still need the internal manager to explain why a legacy application cannot be patched during month-end close. Both forms of expertise matter.
Innovative Network Solutions Corp (INSC)’s co-managed IT model is built around augmenting an existing IT department with tools, techniques, talent, and 24/7 support rather than displacing the internal team. That principle should be visible in the way responsibilities are designed from the first week.
Best Practice 1: Define Ownership Before You Share Tools
The fastest way to create conflict is to give both teams access to the same environment without defining who is responsible for what. Before shared administrator access, ticket queues, monitoring agents, or project work begin, document the service boundaries.
A practical responsibility map should answer questions such as:
- Who owns end-user support during business hours?
- Who owns after-hours support and infrastructure alerts?
- Who approves firewall, identity, and security-policy changes?
- Who patches servers, workstations, network devices, and line-of-business applications?
- Who reviews backups and who performs recovery tests?
- Who owns Microsoft 365 administration and license changes?
- Who communicates with third-party software and internet vendors?
- Who leads a security incident and who communicates with leadership?
- Which projects can the MSP initiate, and which require written internal approval?
The document does not need to be bureaucratic. It does need to be explicit. If both teams think the other side owns a control, it becomes a gap. If both teams think they own it, it becomes duplication or conflict.
Best Practice 2: Protect the Internal IT Manager as the Business Context Owner
A capable MSP should make the internal IT manager more effective, not route around them. The internal manager should remain the primary interpreter of business context unless leadership intentionally assigns that role elsewhere. That includes priorities, acceptable downtime, application criticality, executive expectations, user-impact decisions, and the timing of major changes.
This matters because technically correct decisions can still be operationally wrong. A firmware update may be necessary, but applying it during a critical production window may create a larger business risk than deferring it for two days. A cloud migration may be architecturally sound, but the internal manager may know that a client contract, acquisition, office move, or application rollout changes the timing.
Strategic support should therefore complement internal leadership. IT Strategy and virtual Chief Information Officer services can provide roadmaps, lifecycle planning, budgeting, and executive-level guidance, but the strongest recommendations are built with the internal manager rather than handed down to them.
Best Practice 3: Create Clear Escalation Lanes
Co-managed relationships fail when every problem becomes a negotiation over who should take it. Establish an escalation model for incidents, user issues, infrastructure alerts, security events, and projects. The internal team should know exactly when to bring in the MSP, and the MSP should know when to return control or request a business decision.
For example, a single user unable to print may stay with the internal team, while a widespread authentication failure moves immediately to the MSP. A routine workstation issue may remain local, while a firewall outage routes to the MSP’s Network Operations Center (NOC), a dedicated team that monitors and responds to infrastructure events. A suspected compromise may bypass normal ticket priority entirely and activate the agreed security escalation path.
Define the handoff rules while systems are healthy. During an outage or security incident, there is no time to discover that the two teams have different definitions of critical priority.
Best Practice 4: Use One Shared Source of Operational Truth
If the internal team tracks work in email, the MSP tracks work in a ticket platform, network documentation sits in a spreadsheet, and project decisions live in chat messages, the relationship will become opaque. Successful co-managed environments create a shared operational record even if the two organizations keep separate internal systems behind it.
At minimum, both sides need visibility into active incidents, ownership, priority, status, recent changes, known problems, and planned work. Documentation should cover network topology, critical systems, administrative ownership, vendor contacts, recurring maintenance, backup design, escalation procedures, and business-specific constraints.
The benefit is bigger than convenience. Shared documentation reduces dependency on individual memory. It also makes vacations, staff turnover, incident response, and project handoffs safer because the operating knowledge belongs to the relationship rather than to one person.
Best Practice 5: Standardize Change Management
Many co-managed disputes begin with a sentence like, ‘We did not know that was being changed.’ The technical change may be perfectly reasonable, but uncoordinated work destroys trust. Both teams should agree on what counts as a standard change, what requires approval, what requires a maintenance window, and how emergency changes are documented afterward.
A lightweight process can be enough. The change record should identify what is changing, why, who owns it, expected user impact, rollback steps, timing, and approval when needed. Larger initiatives should be handled as projects rather than a collection of loosely related tickets.
For migrations, office changes, infrastructure refreshes, and major deployments, INSC’s Projects and Professional Services can add dedicated technical and project capacity while the internal IT manager retains visibility into scope, dependencies, and business timing.
Best Practice 6: Make Security Ownership Explicit
Security is the area where vague co-management is most dangerous. An MSP may provide tools, monitoring, patching, and response support, but the business still needs to know who owns each control. Do not assume that ‘the MSP handles security’ means every security responsibility is covered.
Define ownership for Multi-Factor Authentication (MFA), privileged access, endpoint protection, vulnerability remediation, email security, firewall administration, security awareness training, backup protection, incident response, cyber-insurance evidence, and vendor-risk questions. For each area, identify who configures the control, who monitors it, who approves exceptions, and who receives alerts.
INSC’s cybersecurity services can provide a managed security layer across endpoints, email, networks, authentication, and threat detection, but the internal manager should still understand how that layer connects to business policies and risk decisions.
Best Practice 7: Agree on Service Level Objectives and Decision Rights
Service Level Objectives (SLOs) define measurable performance targets for areas such as response times, support coverage, issue prioritization, and resolution expectations. In a co-managed Information Technology (IT) relationship, these objectives should be paired with clearly defined decision rights so both the internal team and the Managed Service Provider (MSP) understand who is responsible for each type of action. Fast response only creates value when the responding engineer also knows what they are authorized to do.
For each incident priority, determine whether the MSP can take corrective action immediately, should notify the internal IT manager before proceeding, or must wait for explicit approval. The same approach should cover user account changes, software licensing, firewall modifications, server restarts, vendor escalations, and other operational decisions. Clear SLOs and decision rights reduce unnecessary delays, prevent unauthorized changes, and help both teams work together with greater consistency and accountability.
Best Practice 8: Build a Communication Rhythm That Is Not Ticket-Driven
If the only time the IT manager speaks with the MSP is when something is broken, the relationship will remain reactive. Establish a regular operating cadence that looks beyond open tickets.
Monthly operational reviews can cover recurring incidents, patch status, backup health, capacity, device inventory, security findings, and upcoming changes. Quarterly Business Reviews (QBRs) can step back further and examine roadmap priorities, lifecycle risk, budget planning, major projects, and business changes that may affect technology.
The most useful metrics are not simply number of tickets closed. Look at repeat incidents, aging problems, response performance, unresolved risk, patch exceptions, backup success, project progress, user-impact trends, and whether strategic work is actually moving forward. A co-managed relationship should reduce operational friction over time, not merely process it faster.
Best Practice 9: Use the MSP to Add Depth, Not Just More Hands
It is tempting to measure an MSP by how many extra technicians are available. Capacity matters, but the larger benefit is access to expertise that would be difficult to hire and retain internally for occasional needs. An IT manager may need a cloud architect for a migration, a network engineer for segmentation, a security specialist for an incident, or a project manager for an office move. Hiring each specialty full time makes little sense for most SMBs.
A co-managed provider should make those specialists available without requiring the internal manager to build a separate vendor relationship for every domain. That is where managed IT services become a capability platform for the internal department rather than a replacement for it.
Warning Signs the Co-Managed Relationship Is Not Working
Most problems show up early if the IT manager knows what to watch for:
- The MSP repeatedly makes changes without notifying the internal team.
- Tickets move between teams without a clear owner or next action.
- The provider tries to bypass the IT manager for routine technical decisions.
- Documentation is incomplete or accessible to only one side.
- Security alerts do not have a defined escalation and communication path.
- The MSP reports activity but cannot show whether risk, downtime, or recurring problems are improving.
- Strategic meetings turn into ticket reviews rather than roadmap conversations.
- The internal team feels watched or displaced instead of supported and extended.
These signals do not always mean the provider is wrong for the business. Often they mean the operating model was never fully designed. Revisit boundaries, escalation, decision rights, documentation, and communication before assuming the relationship itself has failed.
How INSC Fits a Co-Managed IT Department
INSC positions co-managed IT as augmentation for existing internal teams. That can include 24/7 help desk and network monitoring, endpoint management, cybersecurity, cloud administration, project resources, vendor management, and strategic planning. The internal IT manager does not need to give up the systems or responsibilities the team already handles well.
The strongest starting point is a capability discussion rather than a service-package discussion: what does the internal team want to keep, where is it overloaded, which responsibilities have no clear owner, and which specialist capabilities are missing? From there, the relationship can be designed around gaps instead of forcing the business into a generic division of labor.
Conclusion
A successful IT manager-MSP partnership is not created by signing a co-managed services agreement. It is created by clarity. The internal team and provider need clear ownership, shared visibility, reliable escalation, controlled change, explicit security responsibilities, measurable service expectations, and a communication rhythm that includes strategy as well as operations.
When those pieces are in place, the value of co-managed IT becomes much easier to see. The internal IT manager keeps business context and decision influence while gaining 24/7 coverage, specialist depth, standardized tooling, additional project capacity, and a stronger escalation path. Instead of being the person who has to know and do everything, the IT manager becomes the person who coordinates a broader technology capability around the needs of the business.
Want an MSP That Strengthens Your Internal IT Team Instead of Replacing It?
INSC can assess your current team structure, identify the areas where outside coverage or specialist depth would create the most value, and design a co-managed model around what you want to keep in-house. Schedule your free consultation or reach us at (866) 572-2850 or sales@inscnet.com.
Frequently Asked Questions (FAQs)
1. What should an IT manager expect from a co-managed MSP?
An IT manager should expect defined responsibilities, transparent ticket and documentation access, a clear escalation path, specialist technical resources, predictable support coverage, security coordination, and regular operational and strategic reviews. The MSP should extend the internal team’s capability without undermining the manager’s business context or decision role.
2. How should responsibilities be divided between internal IT and the MSP?
Responsibilities should be divided according to capability, coverage, and business context rather than by a generic template. A common model is for internal IT to retain business applications, user relationships, and day-to-day priorities while the MSP owns 24/7 monitoring, infrastructure maintenance, security operations, backup, specialized engineering, and larger projects. The exact split should be documented and reviewed as the business changes.
3. Should the MSP and internal team use the same ticketing system?
They do not necessarily need the same internal platform, but they do need a shared source of truth for active work, ownership, priority, changes, and status. If each side keeps separate systems, the integration or communication process must prevent tickets and decisions from disappearing between them.
4. Who should lead a cybersecurity incident in a co-managed environment?
The answer should be decided before an incident occurs. The MSP may lead technical containment and investigation if it manages the security stack, while the internal IT manager coordinates business impact, leadership communication, application owners, and third parties. The incident plan should name the technical lead, business decision-maker, escalation contacts, communication process, and approval authority.
5. How often should an IT manager meet with the MSP?
Operational communication may happen daily through tickets and team channels, but a structured monthly service review is useful for trends, risk, backup health, patching, recurring incidents, and upcoming changes. A Quarterly Business Review should focus on roadmap, budget, lifecycle, security priorities, projects, and business changes rather than simply re-reading ticket statistics.
6. How can I tell whether co-managed IT is delivering value?
Measure whether the relationship is reducing recurring incidents, closing security and maintenance gaps, improving after-hours coverage, shortening escalations, completing projects faster, and freeing internal staff for higher-value work. Ticket volume alone is not a sufficient measure because a healthy environment may actually generate fewer user-facing incidents over time.
