Client onboarding checklist for small MSPs

Short answer: Client onboarding is complete when the MSP can support the environment without guessing. Collect ownership, access, assets, backups, vendors, ticket routes, risks, and exceptions; then prove that monitoring, restore paths, escalation, and documentation work before declaring the client managed.

Onboarding is risk intake

A new client is not onboarded because the contract is signed, the welcome email went out, and the RMM agent is installed. They are onboarded when your team can support the environment without guessing, chasing passwords, or discovering critical systems during an outage.

For a small MSP, onboarding is where margin is either protected or quietly destroyed. Every missing admin account, unknown backup, undocumented vendor, unclear emergency rule, and unsupported application becomes future unpaid work.

Treat onboarding as risk intake first. Convenience can come later.

Start with the decision boundary

Before the first tool deployment, define what the MSP is taking responsibility for and what still belongs to the client, vendor, or project queue. The NIST Cybersecurity Framework 2.0 is useful here because it starts with governance and identification, not only protection tools. In small-MSP language, that means you need a named business owner, a technical contact, an asset picture, and a written list of decisions that are not yours to make silently.

Document the boundary in plain language:

• Recurring support covers these systems.
• Monitoring covers these systems.
• Security baseline covers these controls.
• Projects are required for these gaps.
• Client approval is required for these risks.
• Vendor cooperation is required for these dependencies.

This is also where the promise in what is a small MSP becomes real. If the sales conversation implied unlimited support, onboarding is where you either narrow the promise or start carrying risk for free.

If that boundary is not clear during onboarding, it will be argued during an emergency.

First 48 hours

Do not try to document everything at once. Start with the things that can hurt the client or your team immediately.

• Confirm business owner, billing contact, technical contact, and escalation contact.
• Confirm approved ticket intake channels and after-hours rules.
• Inventory admin access for Microsoft 365, Google Workspace, domain registrar, DNS, firewall, backup portals, RMM, PSA, documentation, and line-of-business apps.
• Require named admin accounts and MFA where the platform supports it.
• Identify who owns current backups and whether any restore path has been tested.
• Record critical sites, internet circuits, servers, network gear, and business-critical applications.
• Ask what issue would stop revenue, payroll, shipping, appointments, production, or compliance work.
• Open an exceptions list for anything unknown, unsupported, refused, or waiting on a vendor.

This is not busywork. It tells you where a weekend emergency is likely to come from.

Go-live blockers

Some onboarding findings should stop managed service from going live. Others can be accepted as visible risk. A small MSP needs that distinction because the owner often feels pressure to "just start."

Treat these as go-live blockers:

• No approved business owner or emergency contact.
• No administrative access to core identity, DNS, backup, firewall, or documentation systems.
• No way to create tickets or route urgent requests.
• No known backup status for systems the client expects you to protect.
• No agreement on after-hours or emergency handling.
• No written list of unsupported systems and open risks.

Treat these as accepted exceptions only when the client understands the risk:

• A legacy server remains in service until a project is approved.
• A vendor account stays active because the client needs continuity.
• A backup gap remains temporarily while data locations are confirmed.
• A line-of-business app is supported by a vendor, not by the MSP.
• Patch or endpoint coverage is incomplete while devices are discovered.

Treat these as paid remediation or project work:

• Rebuilding broken backup coverage.
• Cleaning years of stale admin accounts.
• Replacing unsupported servers or applications.
• Restructuring identity, DNS, firewall, or remote access.
• Documenting a complex environment that was sold without discovery.

If a finding changes recurring work, connect it to the managed services pricing guide before the monthly plan absorbs the labor.

Access and identity

The CISA advisory for MSPs and their customers is blunt about the risk created by MSP access. During onboarding, treat privileged access as one of the first deliverables, not as cleanup you will do later.

Your intake should capture:

• Which identities are authoritative for the client.
• Which admin accounts exist today.
• Which admin accounts are shared and need replacement.
• Which accounts have MFA exceptions.
• Which vendors have privileged access.
• Which former employees, contractors, or vendors still have access.
• Which emergency account exists and how it is protected.
• Which technician accounts your MSP will use.

For Microsoft tenants, use delegated access deliberately. The Microsoft GDAP introduction and least-privileged role guidance are useful references because they push the MSP away from broad permanent admin access. The small-MSP version is simple: ask for the access needed for the task, document it, and review it.

This is where onboarding connects to the security baseline for small MSPs. If you start recurring service without named access, MFA expectations, vendor access review, and offboarding cleanup, the security baseline is already behind.

Assets, coverage, and stack fit

Small MSP onboarding should create a usable asset picture, not a perfect CMDB fantasy. You need enough inventory to know what you support, what you monitor, what you patch, and what you exclude.

Capture:

• Users and mailboxes.
• Workstations, laptops, servers, and shared devices.
• Firewalls, switches, wireless, printers, and storage.
• Cloud tenants and core SaaS applications.
• Backup jobs and protected data locations.
• Security tools already installed.
• Domain, DNS, certificate, and registrar ownership.
• Vendor contracts, renewal dates, portals, and support contacts.

The CIS Controls place inventory and control of assets near the front for a reason: you cannot protect, patch, monitor, or price what you cannot identify. For a small MSP, that does not mean delaying onboarding until inventory is perfect. It means every unknown becomes an exception with an owner and next action.

If the client environment exposes tool gaps, use the tool stack selection framework before buying another product. The question is not whether a tool looks complete. The question is whether your team can operate the coverage, alerts, reporting, billing, and support workflow every week.

Backup and restore intake

Backups deserve a separate onboarding section because clients often believe backup exists when only part of the environment is covered. The FTC small business cybersecurity guidance emphasizes practical recovery preparation for small businesses. Your onboarding should translate that into proof.

Ask:

• What data would stop the business if lost?
• Which systems are currently backed up?
• Which Microsoft 365 or Google Workspace data is covered?
• Which servers, databases, workstations, and application folders are excluded?
• Who receives failure alerts today?
• Has a restore been tested recently?
• What retention does the client expect?
• Who owns backup billing and admin access?

Do not treat "we have backups" as an answer. Treat it as a starting claim to verify. The NIST NCCoE guide on protecting data from ransomware and other data loss events for MSPs is a useful reminder that backup work only matters when recovery can be executed, not when a product exists.

After intake, use the backup restore testing checklist to turn that claim into measured recovery evidence.

First week operating baseline

Once immediate risk is visible, build the first operating baseline.

1. Create the client record in your PSA or documentation system.
2. Define ticket intake channels and emergency rules.
3. Import or discover users, devices, servers, and network assets.
4. Document recurring vendors, renewal dates, and support contacts.
5. Review endpoint protection, patch status, local admin exposure, and remote access.
6. Verify backup monitoring and perform at least one restore-path check.
7. Define alert ownership for identity, endpoint, backup, and infrastructure events.
8. Create an exceptions list for anything the client declines, postpones, or has not approved.
9. Schedule the first monthly review if the client is on managed service.

The exceptions list matters. It prevents "I thought you handled that" conversations later and gives the first monthly review something concrete to follow.

The exception register

Do not let exceptions live in the technician's memory. During onboarding, every exception should have enough detail that the service desk, owner, and client can understand it later.

Record:

• What is missing, risky, unsupported, or unknown.
• Who owns the decision.
• What happens if the item fails.
• Whether it blocks go-live.
• Whether it is included, out of scope, or project work.
• What the next action is.
• When it must be reviewed again.

This register becomes the bridge between onboarding, security baseline, service desk, and pricing. It also protects the client relationship because it turns hidden risk into a decision.

Service desk handoff

Onboarding fails when the discovery work never reaches the people who answer tickets. The small MSP service desk model should receive a simple handoff:

• Who can approve work.
• Who can request emergencies.
• What systems are supported.
• What systems are monitored.
• What access is available.
• What vendors must be contacted.
• What recurring tasks begin now.
• What risks are open.
• What items need project pricing.
• Which tickets should be treated as security events.

If the queue cannot answer who owns the next action, the team may end up managing work from memory, chat, and whoever is loudest.

What to tell the client

Use plain language:

During onboarding we found these controlled items, these open risks, and these decisions that need your approval.

That is stronger than pretending everything is clean. A client who understands the baseline is easier to support than one who believes the MSP inherited unlimited responsibility.

Tie the conversation to price when needed. If onboarding discovers unmanaged backups, unsupported applications, stale servers, no emergency boundary, or security controls that require recurring review, those are not just technical findings. They affect scope, margin, and response expectations.

Common mistake

The common mistake is onboarding the easy things first: logos, email signatures, documentation folders, and tool deployment.

Those can wait. Start with admin access, backups, emergency definition, asset coverage, vendor dependencies, unsupported promises, and go-live blockers. That is where the real risk lives.

When to change level

Use a stronger onboarding process when the client has multiple locations, regulated data, old servers, custom applications, high staff turnover, active vendor disputes, cyber insurance requirements, or no clear owner for IT decisions.

Also raise the level when the client wants a fast start but cannot provide access, cannot name critical systems, or refuses basic controls. That is not a reason to skip onboarding. It is the reason onboarding needs an exceptions list before recurring support begins.