Checklist de onboarding de clientes MSP

Respuesta corta: El onboarding termina cuando el MSP puede soportar el entorno sin adivinar. Recopila responsables, accesos, activos, backups, vendors, rutas de tickets, riesgos y excepciones; después demuestra que el monitoreo, los restores, la escalación y la documentación funcionan antes de declarar al cliente administrado.

Onboarding es recibir riesgo

Un cliente nuevo no está onboarded porque el contrato está firmado, salió el correo de bienvenida y el agente de RMM quedó instalado. Está onboarded cuando tu equipo puede soportar el entorno sin adivinar, perseguir contraseñas o descubrir sistemas críticos durante una caída.

Para un MSP pequeño, el onboarding es donde el margen se protege o se destruye en silencio. Cada cuenta administrativa faltante, backup desconocido, vendor sin documentar, regla de emergencia poco clara y aplicación no soportada se convierte en trabajo futuro no cobrado.

Trata el onboarding primero como recepción de riesgo. La comodidad puede venir después.

Empieza por el límite de decisión

Antes del primer despliegue de herramientas, define qué responsabilidad toma el MSP y qué sigue perteneciendo al cliente, al vendor o a la cola de proyectos. El NIST Cybersecurity Framework 2.0 sirve aquí porque empieza con gobierno e identificación, no solo con herramientas de protección. En lenguaje de MSP pequeño, eso significa que necesitas un dueño de negocio, un contacto técnico, una imagen de activos y una lista escrita de decisiones que no debes tomar en silencio.

Documenta el límite con lenguaje claro:

• El soporte recurrente cubre estos sistemas.
• El monitoreo cubre estos sistemas.
• La base de seguridad cubre estos controles.
• Estos huecos requieren proyecto.
• Estos riesgos requieren aprobación del cliente.
• Estas dependencias requieren cooperación de vendors.

Aquí también es donde la promesa de qué es un MSP pequeño se vuelve real. Si la conversación comercial insinuó soporte ilimitado, onboarding es donde reduces la promesa o empiezas a cargar riesgo gratis.

Si ese límite no queda claro durante onboarding, se va a discutir durante una emergencia.

Primeras 48 horas

No intentes documentar todo al mismo tiempo. Empieza por lo que puede lastimar al cliente o a tu equipo de inmediato.

• Confirma dueño del negocio, contacto de facturación, contacto técnico y contacto de escalación.
• Confirma canales aprobados de entrada de tickets y reglas fuera de horario.
• Inventaria accesos administrativos para Microsoft 365, Google Workspace, registrar de dominio, DNS, firewall, portales de backup, RMM, PSA, documentación y aplicaciones críticas.
• Exige cuentas administrativas con nombre y MFA donde la plataforma lo permita.
• Identifica quién controla los backups actuales y si existe una ruta de restore probada.
• Registra sedes críticas, enlaces de internet, servidores, equipo de red y aplicaciones clave del negocio.
• Pregunta qué problema detendría ingresos, nómina, envíos, citas, producción o trabajo de cumplimiento.
• Abre una lista de excepciones para todo lo desconocido, no soportado, rechazado o pendiente de un vendor.

Esto no es trabajo de relleno. Te dice de dónde puede venir una emergencia de fin de semana.

Bloqueos antes de go-live

Algunos hallazgos de onboarding deben detener el inicio del servicio administrado. Otros pueden aceptarse como riesgo visible. Un MSP pequeño necesita esa distinción porque el dueño suele sentir presión por "arrancar ya".

Trata estos puntos como bloqueos de go-live:

• No hay dueño de negocio o contacto de emergencia aprobado.
• No hay acceso administrativo a identidad, DNS, backup, firewall o documentación central.
• No hay forma de crear tickets o enrutar solicitudes urgentes.
• No se conoce el estado de backup de sistemas que el cliente espera que protejas.
• No existe acuerdo sobre soporte fuera de horario o emergencias.
• No hay lista escrita de sistemas no soportados y riesgos abiertos.

Trata estos puntos como excepciones aceptadas solo cuando el cliente entiende el riesgo:

• Un servidor legacy sigue activo hasta que se apruebe un proyecto.
• Una cuenta de vendor queda activa porque el cliente necesita continuidad.
• Un hueco de backup queda temporalmente mientras se confirman ubicaciones de datos.
• Una aplicación crítica es soportada por el vendor, no por el MSP.
• La cobertura de parches o endpoints está incompleta mientras se descubren equipos.

Trata estos puntos como remediación pagada o proyecto:

• Reconstruir cobertura de backups rota.
• Limpiar años de cuentas administrativas obsoletas.
• Reemplazar servidores o aplicaciones no soportadas.
• Reestructurar identidad, DNS, firewall o acceso remoto.
• Documentar un entorno complejo que se vendió sin discovery.

Si un hallazgo cambia el trabajo recurrente, conéctalo con la guía de precios de servicios administrados antes de que el plan mensual absorba la labor.

Acceso e identidad

El aviso de CISA para MSPs y sus clientes es directo sobre el riesgo que crea el acceso de un MSP. Durante onboarding, trata el acceso privilegiado como uno de los primeros entregables, no como limpieza que harás después.

Tu intake debe capturar:

• Qué identidades son autoritativas para el cliente.
• Qué cuentas administrativas existen hoy.
• Qué cuentas administrativas son compartidas y deben reemplazarse.
• Qué cuentas tienen excepciones de MFA.
• Qué vendors tienen acceso privilegiado.
• Qué exempleados, contratistas o vendors todavía tienen acceso.
• Qué cuenta de emergencia existe y cómo está protegida.
• Qué cuentas de técnico usará tu MSP.

Para tenants de Microsoft, usa acceso delegado con intención. La introducción a GDAP de Microsoft y la guía de roles de mínimo privilegio sirven porque empujan al MSP lejos del acceso administrativo amplio y permanente. La versión para MSP pequeño es simple: pide el acceso necesario para la tarea, documéntalo y revísalo.

Aquí el onboarding se conecta con la base de seguridad para MSP pequeños. Si empiezas servicio recurrente sin accesos con nombre, expectativas de MFA, revisión de vendors y limpieza de offboarding, la base de seguridad ya empezó atrasada.

Activos, cobertura y fit del stack

El onboarding de un MSP pequeño debe crear una imagen usable de activos, no una fantasía de CMDB perfecta. Necesitas inventario suficiente para saber qué soportas, qué monitoreas, qué parcheas y qué excluyes.

Captura:

• Usuarios y buzones.
• Workstations, laptops, servidores y equipos compartidos.
• Firewalls, switches, wireless, impresoras y almacenamiento.
• Tenants cloud y aplicaciones SaaS centrales.
• Jobs de backup y ubicaciones de datos protegidas.
• Herramientas de seguridad ya instaladas.
• Ownership de dominio, DNS, certificados y registrar.
• Contratos de vendors, fechas de renovación, portales y contactos de soporte.

Los CIS Controls ponen inventario y control de activos cerca del inicio por una razón: no puedes proteger, parchear, monitorear ni cobrar bien lo que no puedes identificar. Para un MSP pequeño, eso no significa retrasar onboarding hasta que el inventario sea perfecto. Significa que cada desconocido se convierte en una excepción con dueño y siguiente acción.

Si el entorno del cliente muestra huecos de herramientas, usa el framework de selección de stack antes de comprar otro producto. La pregunta no es si una herramienta se ve completa. La pregunta es si tu equipo puede operar cobertura, alertas, reportes, facturación y soporte cada semana.

Intake de backup y restore

Los backups merecen una sección separada de onboarding porque los clientes suelen creer que tienen backup cuando solo una parte del entorno está cubierta. La guía de ciberseguridad para pequeños negocios de la FTC enfatiza preparación práctica para recuperación. Tu onboarding debe traducir eso en evidencia.

Pregunta:

• Qué datos detendrían el negocio si se pierden.
• Qué sistemas están respaldados actualmente.
• Qué datos de Microsoft 365 o Google Workspace están cubiertos.
• Qué servidores, bases de datos, workstations y carpetas de aplicaciones quedan excluidos.
• Quién recibe alertas de falla hoy.
• Si se probó un restore recientemente.
• Qué retención espera el cliente.
• Quién controla la facturación y el acceso administrativo del backup.

No trates "tenemos backups" como respuesta final. Trátalo como una afirmación inicial que hay que verificar. La guía de NIST NCCoE sobre protección de datos contra ransomware y otros eventos de pérdida para MSPs recuerda que el trabajo de backup solo importa cuando la recuperación puede ejecutarse, no cuando existe un producto.

Después del intake, usa la checklist de pruebas de restauración para convertir esa afirmación en evidencia medida de recuperación.

Primera semana operativa

Cuando el riesgo inmediato ya es visible, arma la primera línea operativa.

1. Crea el registro del cliente en tu PSA o sistema de documentación.
2. Define canales de entrada de tickets y reglas de emergencia.
3. Importa o descubre usuarios, equipos, servidores y activos de red.
4. Documenta vendors recurrentes, fechas de renovación y contactos de soporte.
5. Revisa protección de endpoints, estado de parches, exposición de admin local y acceso remoto.
6. Verifica monitoreo de backups y haz al menos una revisión de ruta de restore.
7. Define dueño de alertas para eventos de identidad, endpoint, backup e infraestructura.
8. Crea una lista de excepciones para todo lo que el cliente rechace, posponga o no haya aprobado.
9. Agenda la primera revisión mensual si el cliente está en servicio administrado.

La lista de excepciones importa. Evita conversaciones de "yo pensé que eso estaba incluido" más adelante y le da a la primera revisión mensual algo concreto que seguir.

Registro de excepciones

No dejes que las excepciones vivan en la memoria del técnico. Durante onboarding, cada excepción debe tener suficiente detalle para que la mesa de servicio, el dueño y el cliente puedan entenderla después.

Registra:

• Qué falta, qué es riesgoso, qué no está soportado o qué se desconoce.
• Quién es dueño de la decisión.
• Qué pasa si el punto falla.
• Si bloquea go-live.
• Si está incluido, fuera de alcance o requiere proyecto.
• Cuál es la siguiente acción.
• Cuándo debe revisarse otra vez.

Este registro se vuelve el puente entre onboarding, base de seguridad, mesa de servicio y precios. También protege la relación con el cliente porque convierte riesgo oculto en una decisión.

Handoff a mesa de servicio

El onboarding falla cuando el trabajo de descubrimiento nunca llega a quienes contestan tickets. El modelo de mesa de servicio para MSP pequeño debe recibir un handoff simple:

• Quién puede aprobar trabajo.
• Quién puede pedir emergencias.
• Qué sistemas están soportados.
• Qué sistemas están monitoreados.
• Qué acceso está disponible.
• Qué vendors deben contactarse.
• Qué tareas recurrentes empiezan ahora.
• Qué riesgos siguen abiertos.
• Qué puntos necesitan precio de proyecto.
• Qué tickets deben tratarse como eventos de seguridad.

Si la cola no puede contestar quién es dueño de la siguiente acción, el equipo puede terminar administrando trabajo desde memoria, chat y quien grite más fuerte.

Qué decirle al cliente

Usa lenguaje claro:

Durante onboarding encontramos estos puntos controlados, estos riesgos abiertos y estas decisiones que necesitan tu aprobación.

Eso es más fuerte que fingir que todo está limpio. Un cliente que entiende la línea base es más fácil de soportar que uno que cree que el MSP heredó responsabilidad ilimitada.

Conecta la conversación con precio cuando sea necesario. Si onboarding descubre backups no administrados, aplicaciones no soportadas, servidores obsoletos, ausencia de límite de emergencia o controles de seguridad que requieren revisión recurrente, esos no son solo hallazgos técnicos. Afectan alcance, margen y expectativas de respuesta.

Error común

El error común es hacer primero lo fácil: logos, firmas de correo, carpetas de documentación y despliegue de herramientas.

Eso puede esperar. Empieza por accesos administrativos, backups, definición de emergencia, cobertura de activos, dependencias de vendors, promesas no soportables y bloqueos de go-live. Ahí vive el riesgo real.

Cuándo subir el nivel

Usa un proceso de onboarding más fuerte cuando el cliente tenga varias ubicaciones, datos regulados, servidores viejos, aplicaciones a la medida, alta rotación de personal, disputas activas con vendors, requisitos de cyber insurance o ningún dueño claro para decisiones de TI.

También sube el nivel cuando el cliente quiere arrancar rápido pero no puede dar acceso, no puede nombrar sistemas críticos o rechaza controles básicos. Eso no es razón para saltarte onboarding. Es la razón para tener una lista de excepciones antes de iniciar soporte recurrente.