MSP onboarding · 13 minute read

MSP onboarding checklist: 10-step client template

Use this free MSP client onboarding checklist to move from signed scope to accepted service. The template combines a 10-step process, 16-question discovery questionnaire, pilot controls, recovery checks, and downloadable CSV and Markdown files.

Use the free template Read the full process Use the discovery questions Download CSV Download Markdown

Last reviewed November 8, 2026Tool-neutral operating plan

MSP onboarding process at a glance

Four stages from discovery to client acceptance

A reliable MSP onboarding process confirms the service boundary, validates assets and privileged access, proves the management workflow on a representative pilot, and closes only after every exception has an owner and the client accepts the evidence.

1. Confirm scope
Record services, exclusions, contacts, approvals, operating hours, and escalation paths.
2. Validate discovery
Reconcile assets, identities, tools, access, backup, recovery, and existing risks.
3. Prove a pilot
Enroll representative systems and test monitoring, alerts, automation, and rollback.
4. Reconcile and accept
Explain every asset state, assign open actions, and document client acceptance.

Copy-ready template

MSP client onboarding checklist: the ten essential handoffs

Add an owner, due date, status, and evidence link to every line. Do not mark an item complete from a plausible total or verbal assurance; attach the record that proves it.

The downloadable CSV includes owner, due-date, status, evidence, and notes columns for importing into a PSA or project board. The Markdown version also includes all 16 client discovery questions.

1Confirm scope, exclusions, approval rights, escalation paths, and an authorized successor or incapacity contact.
2Reconcile client assets across discovery, identity, network, and purchasing records.
3Create named technician identities with MFA and client-scoped least privilege.
4Assign one accountable owner to patching, security, backup, and remote access.
5Export the original configuration and prove at least one recovery path.
6Enroll a representative group of authorized, noncritical pilot endpoints.
7Test alert delivery, escalation, ownership, and closure evidence.
8Promote automation through observe, pilot, broad, and exception rings.
9Reconcile every managed, excluded, offline, retired, and failed asset.
10Record client acceptance, open risks, owners, due dates, and the first review.

Client discovery template

MSP onboarding questionnaire: 16 questions to ask

Send these questions before kickoff, then validate the answers against exports, discovery data, contracts, and named system owners. An unanswered question becomes an onboarding action, not an assumption.

1Which business workflows, locations, teams, and operating hours are most important to protect?
2Who can approve access, changes, outages, purchases, exceptions, and after-hours work?
3If the owner or primary approver is incapacitated or dies, who is legally authorized to direct the MSP, and where is that authority documented?
4Which users, devices, servers, networks, cloud services, applications, and vendors are in or out of scope?
5How many active, spare, shared, remote, offline, unsupported, and retired endpoints should exist?
6Which identity tenants, domains, directories, MFA methods, and emergency accounts are currently used?
7Which line-of-business applications are critical, and who owns their vendor relationship and support contract?
8How are offices, network segments, Wi-Fi, VPN, internet circuits, and remote locations connected?
9Which RMM, MDM, patching, endpoint-security, backup, and remote-access tools have management authority today?
10Where are administrator, service, vendor, encryption, and recovery credentials stored and reviewed?
11Which compliance, cyber-insurance, data-residency, logging, retention, and notification requirements apply?
12What is backed up, who owns recovery, what are the required RPO and RTO, and when was the last restore proven?
13Which maintenance windows, blackout periods, reboot rules, and change-approval paths must technicians follow?
14How should incidents, security events, outages, and missed response targets be routed and escalated?
15Which known failures, unsupported systems, recurring alerts, vendor disputes, and technical-debt items already exist?
16What evidence and success criteria will the client use to accept onboarding and begin the first service review?

UK onboarding notes

MSP onboarding process for UK clients

For a UK client, convert the signed agreement into an explicit responsibility matrix before any privileged access is granted. The UK National Cyber Security Centre recommends clear service levels and liability, defined security-incident notification, least-privilege access protected by 2-step verification, agreed patching and tested backup recovery, accessible security logs, regular health reporting, and a documented contract review or termination path.

Name the MSP and client owner for every service, security control, third party, and incident decision.
Record response, restoration, and security-notification times in the SLA and escalation plan.
Use named least-privilege accounts with 2-step verification and a written access-removal workflow.
Agree patching, backup frequency, restore testing, log access and retention, and health-report evidence.
Track obsolete accounts and infrastructure through remediation, acceptance, or a dated exception.
Define contract review, renewal, termination, data return, account revocation, and provider handover before go-live.

Source: UK NCSC, Choosing a managed service provider (MSP). Adapt the controls to the client's size, sector, risk, and signed legal obligations.

Ten phases from signed scope to accepted service

Adapt the sequence to the client and the agreement. Test enrollment and every high-impact action on authorized, noncritical systems before broad deployment.

1. Turn the agreement into an operating boundary

Translate the signed scope into a working record of locations, people, systems, business hours, responsibilities, exclusions, approval rights, and escalation contacts. A technician should not have to infer what the MSP is allowed to manage during an incident.

Name the client approver, technical contacts, after-hours decision maker, authorized successor or incapacity contact, and MSP service owner.
Document covered and excluded users, sites, networks, devices, cloud services, and line-of-business applications.
Record response targets, maintenance windows, blackout periods, data-retention expectations, and the change-approval path.

2. Establish a trustworthy asset baseline

Build an inventory from more than one source before deploying management agents. Compare discovery results with identity, network, purchasing, directory, and existing-tool records so unknown systems are visible rather than silently omitted.

Assign a stable identifier to each device and record its owner, location, operating system, role, criticality, and support status.
Separate servers, workstations, mobile devices, network equipment, virtual systems, and cloud resources.
Create explicit states for managed, excluded, retired, offline, unsupported, duplicated, and unexplained assets.

3. Secure identity and privileged access

Give each technician an attributable identity and only the access needed for assigned clients and tasks. CISA guidance for MSP relationships emphasizes MFA, least privilege, separation between customer environments, and avoiding credential reuse.

Require MFA for technician, administrator, remote-access, and emergency accounts.
Use named accounts and client-scoped roles; do not share administrator credentials across customers.
Document account provisioning, elevation, emergency access, review, suspension, and offboarding.

4. Map every management authority

Record which system controls patching, security policy, antivirus, firewall, encryption, local administrators, remote access, software deployment, backup, and restart behavior. Resolve overlapping ownership before automation is enabled.

Identify RMM, MDM, Group Policy, endpoint security, backup, identity, and vendor-management tools already present.
Find policies or scripts that could reinstall an old agent or reverse a new configuration.
Choose one accountable owner for every control and document deliberate coexistence periods.

5. Preserve evidence and recovery paths

Capture the original state before removing tools or changing security controls. Onboarding is not complete if the team cannot reconstruct what changed, recover a device, or operate when the primary management path is unavailable.

Export existing inventory, configurations, policies, alert routes, scripts, audit logs, and recovery instructions.
Verify backup scope, recent job status, protected credentials, restore ownership, and a tested recovery result.
Keep an out-of-band contact and access method for loss of the RMM, identity provider, or primary network.

6. Enroll a representative pilot

Start with authorized lab or noncritical systems that represent the client rather than the easiest identical endpoints. Include remote users, servers, line-of-business applications, constrained networks, and devices that are not always online.

Verify installer origin, device identity, tenant placement, check-in, inventory, monitoring, patch visibility, and audit history.
Test remote support only with documented authorization and visible session evidence.
Exercise an offline device, failed job, pending restart, rejected approval, and rollback path.

7. Build alerts around decisions

An alert is useful only when it reaches an accountable person with enough context to act. Start with a small set of client-relevant conditions, prove delivery and escalation, then tune from measured noise and missed events.

For each alert, record its owner, severity, business impact, evidence, response, escalation, and closure condition.
Test delivery during business hours and after hours, including failure of the primary channel.
Suppress duplicates only after confirming the authoritative alert still reaches the right queue.

8. Introduce automation in rings

Keep discovery and observation separate from remediation until the collected data is trustworthy. Promote scripts, patches, reboots, and policy changes through small rings with explicit approvals and stop conditions.

Document the purpose, scope, trigger, timeout, success condition, evidence, and rollback for each automation.
Use observe, pilot, broad, and exception rings instead of deploying to every endpoint at once.
Require human approval for actions that can interrupt service or expand privileged access.

9. Reconcile the full environment

Compare the final managed population with the original asset baseline. Every difference should be explained as healthy, offline, excluded, retired, failed, duplicated, or assigned to a named recovery action.

Verify monitoring, alerting, patch authority, remote support, backup visibility, security-tool health, and reporting by device class.
Investigate unexplained count changes instead of accepting a plausible total.
Remove obsolete accounts, agents, scheduled tasks, services, integrations, tokens, and unattended-access paths.

10. Close with client acceptance

Review the service boundary, evidence, exceptions, risks, communications, and first reporting cycle with the client. Assign every unresolved item to an owner and date instead of treating acceptance as the end of remediation.

Deliver the current asset list, support route, escalation contacts, maintenance calendar, and known-exception register.
Confirm incident notification, vulnerability disclosure, business-continuity, and offboarding expectations.
Record acceptance, open actions, owners, due dates, and the date of the first service review.

Frequently asked questions

Discovery, evidence, and acceptance

What should an MSP client onboarding checklist include?

An MSP client onboarding checklist should cover the signed service boundary, contacts and approvals, asset discovery, privileged access, tool ownership, backup and recovery, representative endpoint enrollment, alert testing, controlled automation, final reconciliation, and client acceptance.

How should an MSP use this onboarding checklist template?

Copy the ten-step template into the MSP's project or ticketing system, assign an owner and due date to each item, attach evidence, and adapt the sequence to the signed agreement. Test high-impact actions on authorized noncritical systems before broad deployment.

What is the difference between MSP discovery and onboarding?

Discovery gathers facts about the client, including people, locations, assets, systems, risks, and existing tools. Onboarding turns those facts and the signed scope into controlled access, deployed services, tested operating procedures, documented exceptions, and client acceptance.

What should an MSP ask in a client onboarding questionnaire?

Ask about business-critical workflows, scope and exclusions, contacts and approval rights, asset counts, identity and MFA, critical applications, networks, management tools, privileged credentials, compliance, backup recovery targets, maintenance windows, escalation, known risks, and acceptance criteria. Validate the answers against evidence rather than treating the questionnaire as the inventory.

How long should the MSP onboarding process take?

The schedule depends on client size, asset accuracy, access, and risk. Plan the work in four controlled stages: confirm scope before kickoff, validate discovery and access, enroll a representative pilot, then reconcile every asset and obtain client acceptance. Do not shorten the process by skipping recovery, alert, or rollback tests.

What should a UK MSP onboarding process include?

A UK MSP onboarding process should turn the contract into a responsibility matrix, define service and incident-notification times, document least-privilege access protected by 2-step verification, agree patching and backup-recovery expectations, preserve security logs, schedule health reporting, and record how obsolete accounts, infrastructure, renewal, and termination will be handled. These controls align with the UK National Cyber Security Centre's guidance for choosing and working with an MSP.

Evidence register

Track all 30 onboarding controls in one public CSV.

The companion register adds MSP and customer owners, evidence links, source systems, acceptance criteria, exceptions, and review dates across authority, discovery, access, RMM, security, backup, service desk, documentation, communication, and acceptance. Keep credentials and other secrets in an approved vault; link to the record instead of copying secrets into the register.

Open the evidence register Download the 30-control CSV Download the 16-question questionnaire

Relationship disclosure: the external MSP operations resource library is also maintained by the Nizlo team. The register is public, ungated, and designed for vendor-neutral use.

Plan the full client lifecycle

Define a clean exit before management begins.

Ownership, access, evidence, automation, agent removal, and data-retention expectations are easier to reconcile when both parties agree on them during onboarding.

Define response and restoration clocks in the MSP SLA template Read the MSP client offboarding checklist

Test Nizlo during a controlled pilot

Use your own onboarding criteria for 14 days.

Qualified MSP and IT operators can evaluate Nizlo without a credit card on authorized lab or noncritical Windows or macOS systems. Nizlo remains Windows-first, so verify required workflow depth on each platform. Founding Tester discounts are awarded by successful paid upgrade order: the first five receive 75% off for life, the next five 50%, and the next ten 25%. Applying or starting a trial does not reserve a position.

Start the 14-day trial

Share this resource

Cite the canonical checklist

Editors, educators, and resource librarians can link directly to this public, ungated version. The checklist and both downloads remain available without registration.

Nizlo. "MSP Client Onboarding Checklist (Free CSV Template)." Last reviewed November 8, 2026. https://nizlo.com/guides/msp-client-onboarding-checklist