MSP onboarding · 13 minute read

MSP client onboarding checklist

Good onboarding turns a sales promise into a verified operating system: known assets, scoped access, controlled management, tested recovery, useful alerts, and a client who knows exactly how support works.

Last reviewed September 26, 2026Tool-neutral operating plan

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, 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.

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 systems. 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.

Apply for the Founding Tester pilot