How co-managed IT works with your internal IT team

Co-managed IT is an arrangement where your internal IT team keeps ownership of the environment and a managed provider takes on defined parts of the work, such as after-hours support, security monitoring, or specialist projects. It suits companies whose IT staff know the business well but cannot cover every hour, every skill set, and every alert on their own. Done well, it gives the internal team depth and coverage without replacing them. The key is being explicit about who owns what.

When does an internal IT team need a partner?

Internal IT teams are usually small relative to what they support. A common pattern is one to three people covering help desk, infrastructure, security, vendors, and projects for the whole company. Signs that a partner would help:

• Tickets and projects compete for the same people, and projects keep slipping.
• Nobody is watching security alerts overnight or on weekends.
• A single person holds critical knowledge, and their vacation is a risk.
• Specialist work (a cloud migration, a firewall replacement, a compliance program) exceeds the team’s current experience.
• Leadership wants 24/7 coverage, but adding headcount to provide it is not practical.

The goal is to free the internal team for work that benefits from knowing the business, while the partner absorbs volume, off-hours coverage, and specialist depth.

Who owns what? Writing the responsibility split

Most co-managed arrangements that struggle do so because ownership was assumed rather than written down. A simple responsibility matrix, often called a RACI (Responsible, Accountable, Consulted, Informed), solves this. It does not need to be elaborate. A common starting split looks like this:

• Internal IT owns: business application knowledge, executive and VIP relationships, project priorities, final approval on changes to critical systems, and vendor relationships specific to the business.
• Partner owns: after-hours and overflow help desk tickets, 24/7 security monitoring and response, patching and backup monitoring, and documentation of the systems it manages.
• Shared, with a named lead for each: onboarding and offboarding, major projects, incident response, and quarterly reviews.

For every row, name who is accountable. Two parties can do the work, but only one should be accountable for the outcome.

How should escalation paths work?

Escalation should be predictable in both directions. Agree in writing on:

• Which ticket categories the partner resolves independently, and which must be handed to internal IT.
• What the partner can change without approval (routine patches, password resets) and what requires internal sign-off (firewall rules, production servers, finance systems).
• Who is called, in what order, for a security incident at 2 a.m., and what the partner is authorized to do before anyone answers. Isolating an infected endpoint should not wait for a phone call.
• How the partner hands work back, with notes that let internal staff pick it up without starting over.

Our managed SOC isolates a compromised endpoint in under 30 seconds, which only works if that authority has been agreed in advance.

Shared tooling and access without shared risk

A partner needs access to do the work. That access is also a risk, because a compromised provider account can reach every system it touches. CISA’s Cross-Sector Cybersecurity Performance Goals, voluntary goals intended in part to help small and medium-sized organizations start their cybersecurity efforts, added goal areas in version 2.0 that include risks from managed service providers and least privilege. In practice, that means:

• Named accounts only. Every partner engineer uses an individual account, never a shared admin login.
• Least privilege. Partner accounts get the rights their role requires, and nothing broader. Elevated access is time-limited where possible.
• Phishing-resistant MFA on every partner account, with no exceptions for convenience.
• Logging. Actions taken by partner accounts are logged and reviewable by internal IT.
• Agreed tooling. Decide which monitoring, ticketing, and remote-access tools are used, who owns the licenses, and who can see the data. Avoid running two overlapping toolsets that each see half the picture.

How do you get 24/7 coverage without burning out the team?

Round-the-clock coverage is one of the most common reasons to co-manage. A small internal team cannot staff nights and weekends sustainably, and an on-call rotation of two people wears down quickly. A partner with 24/7 US-based senior engineers takes the overnight and weekend load, handles what it can, and escalates only what needs internal judgment. Automation helps too: in our environment, automation resolves 85% of tickets before a human touches them, which keeps the human queue focused on work that needs a person.

How do you measure a co-managed partner?

Measure the partner on outcomes written into the agreement, and review them together every month. Useful measures include:

• Response time against SLA. Ours is a guaranteed 2-minute response.
• Resolution time for critical issues. Our target is 45 minutes.
• Uptime for the systems the partner manages, against a stated SLA such as 99.9%.
• Ticket volume handled by the partner versus escalated to internal IT.
• Patch compliance and backup success rates.
• Security incidents detected, contained, and closed, with time to containment.

Numbers alone miss part of the picture, so also ask the internal team quarterly whether the partnership is saving them time or creating work.

Put these measures on the same operating calendar as the rest of the business. A monthly review with a short written summary, plus a quarterly check on whether the split of responsibilities still matches company priorities, keeps the partnership managed as an operating relationship rather than a line on the vendor list.

How do you exit cleanly?

Plan the exit at the start. Leaving is easier when the agreement already specifies:

• Ownership of documentation, runbooks, and configuration records, which should belong to you.
• Return of all admin credentials and removal of partner accounts on a defined timeline.
• Ownership of tool licenses and the data inside them, including ticket history and monitoring data.
• A transition period during which the partner supports the handover.

On exit, remove every partner account and API integration, rotate any credentials the partner held, and confirm the removal with logs.

How Intelligent Group can help

Intelligent Group offers co-managed IT for companies that want to keep their internal team and add coverage, depth, and security operations. We start with a written responsibility split and escalation path, then work inside your tooling or ours as agreed. For organizations that later decide they want a single provider to own the full environment, fully managed IT is available, and the same documentation carries over.

Frequently asked questions

Will co-managed IT replace our internal IT staff?

It should not. The model is designed to support an internal team, taking on coverage and specialist work so internal staff can focus on business priorities. If a provider pitches co-management as a path to eliminating your team, clarify the intent before signing.

Who has final authority over changes to our systems?

Your internal IT team, for whatever the agreement designates as requiring approval. Routine, low-risk changes can be pre-approved for the partner, and urgent security containment should be pre-authorized so it is not delayed.

Do we have to switch to the partner’s tools?

Not necessarily. Some arrangements use the internal team’s existing tools, others use the partner’s platform, and many use a mix. The important part is agreeing on one source of truth for tickets and monitoring.

How long does it take to set up a co-managed arrangement?

It depends on the size of the environment and how much documentation already exists. The setup phase typically covers access provisioning, tooling integration, documentation review, and the responsibility matrix before the partner takes on live work.