Written sign-off before go-live
The RACI approval is an approval task assigned to the account manager, with the client IT lead’s written approval attached. Until it is answered Approved, the go-live tasks stay locked.
Co-Managed IT Onboarding Checklist Template
In co-managed IT, the outages and arguments rarely come from what either team does badly. They come from the work each team assumed the other was doing.
A co-managed client keeps its own IT staff and buys the MSP to fill specific gaps: after-hours cover, security monitoring, project capacity, depth on a platform nobody internal knows well, or simply someone to cover the IT manager’s holiday. That makes onboarding a different job. You are not taking over an environment. You are joining a team that already runs it, with its own habits, its own tools and its own view of who does what. This free co-managed IT onboarding checklist gives account managers, service managers and onboarding leads a structured way to set that relationship up. It records why the client chose co-managed IT, builds a responsibility split as a RACI, defines the access model, routes tickets and escalations between the teams, settles tool overlap and change approval, and gets the client IT lead’s written sign-off before go-live. Reviews at 30, 60 and 90 days follow. A conditional phase covers internal staff working in your tools.
Fully Managed Onboarding Takes Over. Co-Managed Onboarding Draws the Lines.
For a fully managed client, the MSP Client Onboarding Checklist is the right tool: you collect the credentials, run discovery, deploy your agents, document the estate and cut the service desk over to your team. A co-managed client still needs much of that technical work for the devices and services you will look after, and the RMM Agent Deployment Checklist handles the rollout. What neither covers is the part that makes co-managed IT succeed or fail: an agreed answer to “whose job is this?” for every recurring task, alert and request.
That answer has to be specific. “The MSP does security” leaves open who isolates a laptop at 2am, who tells the insurer and who decides whether to shut down the file server. The 2022 joint advisory on protecting MSPs and their customers, from CISA, the UK’s NCSC and partner agencies, advised customers to make sure their contract says whether the MSP or the customer owns each specific responsibility, and advised restricting MSP accounts to the systems the MSP manages. In a co-managed relationship both points carry more weight, because two teams with admin rights share one estate.
This checklist is about the client’s IT staff, not yours. Onboarding a technician who joins your own service desk is covered by the MSP Technician Onboarding Checklist.
Fully managed
One team runs the estate
Access: the MSP holds admin rights; the client holds break-glass accounts.
Tickets: every request goes to the MSP service desk.
Main risk: something in the estate nobody discovered.
Co-managed
Two teams share the estate
Access: both teams hold admin rights, scoped to the work each owns.
Tickets: routed between two queues by an agreed set of rules.
Main risk: a task, alert or change that falls between the teams.
What the Co-Managed IT Onboarding Checklist Covers
Seven phases take a co-managed client from the reasons for the arrangement to a reviewed, working split. Phase 4 appears only when the client’s IT team will use the MSP’s tools.
Phase 1
Phase 1: Goals & Scope
- Name the MSP team — the account manager, service manager and onboarding lead, plus the client IT lead and their manager as contacts
- Record why the client chose co-managed IT — the gaps the MSP fills and what the internal team intends to keep
- Confirm the scope from the agreement — services, sites, users, devices and hours the MSP covers, and what is excluded
- Confirm whether the client team will use your tools — answer Yes if the client’s IT staff will work in your PSA, RMM or documentation platform
- Hold a kickoff with both teams — introductions, named contacts on each side and how the teams will talk day to day
Phase 2
Phase 2: Responsibility Split (RACI)
One row per recurring activity. Each row has exactly one accountable party, even when both teams do some of the work.
- Draft the RACI by service area — service desk, patching, backups, security monitoring, projects, vendors, user administration and after-hours
- Define the service desk tiers — which team takes first, second and third line, and who handles executives and on-site visits
- Define security incident roles — who watches the alerts, who can isolate a device, who declares an incident and who contacts the insurer
- Define after-hours and absence cover — who is on call when, and how the internal team’s holidays and sickness are covered
- Agree vendor and licence ownership — who manages each supplier, renewal, warranty and Microsoft 365 licence change
Phase 3
Phase 3: Access Model
Access follows the RACI. Each team gets the rights its rows need, through named accounts that can be traced and removed.
- Create named, MFA-protected accounts for MSP staff — no shared logins, scoped to the systems the RACI gives the MSP
- Set up delegated access to Microsoft 365 — a GDAP relationship with least-privileged roles, approved by the client
- Agree break-glass ownership — who holds the emergency admin accounts and when either team may use them
- Agree the shared documentation — where diagrams, procedures and credentials live, and which team can see and edit each
- Turn on audit logging for admin activity — directory, Microsoft 365, firewall and RMM, kept long enough to investigate an incident
Phase 4 — If the Client Uses Your Tools
Phase 4: Client Team Access to MSP Tools
Shown only when the client’s IT staff will work in your tools. Their access must be limited to their own organisation.
- Create named accounts for the client’s IT staff — in each tool they will use, with MFA and no shared logins
- Assign roles scoped to their own organisation — no visibility of other clients’ tickets, devices, documents or credentials
- Test what they can see — sign in with a test account in the same role and confirm no other client appears anywhere
- Train them on your tools and conventions — ticket statuses, time entries, priorities and how to hand a ticket to your team
- Record who has access and review it at 30 days — and remove accounts the day the client tells you someone has left
Phase 5
Phase 5: Tools, Tickets & Changes
- Decide tool ownership per device group — one RMM and one EDR per device, with any second agent removed or set to a passive mode
- Agree how tickets move between teams — which queue receives each request type and how a ticket is handed across
- Set handoff response targets — how quickly each team picks up a ticket passed by the other, by priority
- Agree the escalation path — named escalation contacts on both sides, and when a disagreement goes to the account manager
- Agree change management — who approves changes, who sits on the CAB, the change windows and the emergency change rule
Phase 6
Phase 6: Sign-Off & Go-Live
The client must approve the RACI before go-live. The account manager records the client IT lead’s written approval as an attachment.
- Compile the co-managed operating guide — the RACI, access model, ticket routing, escalation and change rules in one document
- Approve the RACI with the client — the account manager attaches the client IT lead’s written approval and answers Approved or Not approved
- Go live — switch on the agreed ticket routing, alerting and monitoring, and tell both teams the date
- Run a joint check at the end of the first week — tickets misrouted, alerts nobody picked up and access that is missing
Phase 7
Phase 7: 30, 60 & 90-Day Reviews
- Hold the 30-day review — tickets that bounced between teams, handoff targets missed and RACI rows that caused confusion
- Hold the 60-day review — remaining tool overlap, an access review for both teams and any changes to the RACI
- Hold the 90-day review — with the client IT lead and their manager, to confirm the model is working and agree what changes
- Update the RACI and operating guide — record every change and get written approval again if accountability moved
- Hand over to the regular service rhythm — the monthly report, QBR agenda and an annual RACI review date
A Starting-Point RACI for a Co-Managed Client
R is responsible for doing the work, A is accountable for the outcome, C is consulted before and I is informed after. The split below is one common arrangement, where a small internal team handles day-to-day support and the MSP brings tooling, security operations and out-of-hours cover. It is an illustration, not a recommendation: every client’s split depends on what it is buying and what its own staff are good at.
| Activity | Client IT team | MSP | Questions to settle |
|---|---|---|---|
| First-line service desk (business hours) | A, R | C | Which requests go straight to the MSP? |
| Second and third-line support | A | R | Who decides when a ticket escalates? |
| Out-of-hours support | I | A, R | Which systems are covered, and at what priority? |
| Patching | C | A, R | Who agrees maintenance windows and exclusions? |
| Backup monitoring and restore tests | I | A, R | Who requests a restore, and who approves it? |
| Security alert monitoring and containment | I | A, R | What can the MSP isolate without asking first? |
| Declaring a security incident | A | R, C | Who calls the insurer and the regulator? |
| User joiners, movers and leavers | A, R | I | Who removes access when a leaver is urgent? |
| Projects | A | R | How is project time scoped and approved? |
| Vendors, renewals and licences | A, R | C | Who places the order, and through which channel? |
Five rules that keep a co-managed RACI working
- One A per row. Two accountable parties means neither is. Split the row if both teams genuinely own part of it.
- Access follows the RACI. If the MSP isn’t responsible for user administration, its accounts shouldn’t need that right.
- Every alert has an owner. Map each alert source to a queue. An alert sent to both teams is often actioned by neither.
- Changes go through one process. Both teams use the same change approval, or each team’s changes surprise the other.
- The RACI is reviewed, not filed. Revisit it at 90 days, at each QBR where something went wrong and whenever the internal team changes.
Why Onboard Co-Managed Clients in CheckFlow?
One template for both kinds of co-managed client
A single answer in the first phase decides whether the tool-access phase appears. Conditional logic handles the client whose IT team works in your PSA and the one who never will, without two versions.
Reviews that actually happen
The 30, 60 and 90-day reviews are tasks with relative due dates and named owners, so they arrive on time. The notes from each one stay with the client’s record, ready for the next QBR or a renewal conversation.
Co-managed clients need the same consistency as any other, and more coordination. The MSP process management guide explains which processes to standardise first, and CheckFlow for MSPs shows how to run them across fully managed and co-managed clients alike.
Change approval is easier to agree when both teams can see the same process. The IT Change Management Checklist gives a shared starting point, and the Privileged Access Review Checklist keeps the admin rights held by both teams under regular review.
Frequently Asked Questions
What is co-managed IT?
Co-managed IT is an arrangement where a business keeps its own IT staff and uses a managed service provider for part of the work. The MSP typically adds tools, security monitoring, out-of-hours cover, project capacity or specialist skills, while the internal team keeps day-to-day support and knowledge of the business. It works when both sides agree in writing who is responsible for each activity, and how work moves between them.
What should a co-managed IT RACI include?
Every recurring activity either team might assume belongs to the other: service desk tiers, patching, backups and restores, security monitoring and incident response, user administration, projects, vendors and licences, and out-of-hours cover. For each, record who is responsible, who is accountable, who is consulted and who is informed, with exactly one accountable party per row. Add the questions behind each row, such as who may isolate a device without asking.
Should the client’s IT team have access to the MSP’s tools?
Often yes, because shared tools make handoffs easier and give the internal team visibility. The risk is that MSP tools are built to reach many clients. Give each internal user a named account with MFA and a role limited to their own organisation, then sign in with a test account in that role to confirm no other client’s tickets, devices or documents are visible. Review those accounts regularly and remove leavers promptly.
How do you avoid duplicate agents in co-managed IT?
Decide tool ownership per device group during onboarding: one RMM and one EDR per device, owned by one team. Two active security products on one machine cause performance problems and conflicts. Microsoft notes that Microsoft Defender Antivirus does not switch to passive mode automatically on Windows Server when another antivirus product is installed, so it has to be set to passive mode or disabled by hand. Record the decision in the RACI and check for strays at the 60-day review.
What happens if the client’s IT lead leaves?
Treat it as a trigger to review the arrangement, not just a contact change. Remove the leaver’s access to your tools and shared documentation, confirm who now holds the break-glass accounts and check which RACI rows they were accountable for. Many co-managed clients lean on the MSP more heavily while they recruit, so agree any temporary change in scope and price in writing rather than absorbing it.
Is CheckFlow free for this template?
14-day free trial, no card required. The Business plan is $10 per user per month after the trial. Full details at checkflow.io/pricing.