Checklist de offboarding para clientes MSP: accesos, agentes y datos

Un cliente se va.

Tú cierras la factura.

Pero un agente sigue instalado, una sesión todavía funciona y nadie sabe qué datos deben conservarse.

Ahí empieza el riesgo.

El offboarding no es un botón. Es un cierre controlado que debe proteger al cliente, al MSP y la evidencia de lo que ocurrió.

> Descarga la plantilla XLSX de offboarding para MSPs. Incluye 26 controles, progreso automático y pestañas en español, inglés y portugués.

1) Define quién autoriza el cierre y cuándo ocurre

No empieces desinstalando agentes.

Primero deja por escrito:

• quién solicitó la terminación;
• quién está autorizado para aprobar acciones;
• fecha, hora y zona horaria del corte;
• servicios, ubicaciones, usuarios y endpoints incluidos;
• periodo de transición, si existe;
• obligaciones contractuales todavía pendientes;
• quién recibirá documentación, secretos y reportes;
• qué acciones requieren una aprobación adicional.

Esto evita el peor escenario: retirar acceso demasiado pronto, interrumpir una operación o entregar información a un contacto que ya no está autorizado.

El SLA del MSP también debe explicar qué pasa durante la terminación: qué canales siguen activos, cuándo deja de correr el soporte y cómo se manejan incidentes abiertos.

2) Congela el inventario antes de mover nada

Necesitas una foto final del entorno.

Antes de revocar o eliminar, registra:

• endpoints administrados y su último contacto;
• usuarios y cuentas con acceso;
• agentes, herramientas remotas y utilidades instaladas;
• licencias, suscripciones y renovaciones;
• integraciones, webhooks, claves API y aplicaciones empresariales;
• respaldos y ubicaciones donde existen copias;
• tickets, proyectos, incidentes y cambios abiertos;
• equipos offline, extraviados o inaccesibles.

Usa el mismo alcance con el que comenzaste el servicio. Si el checklist de onboarding de endpoints decía que había 42 equipos y ahora tu consola muestra 39, no asumas que los otros tres desaparecieron. Investiga y registra la excepción.

3) Prepara un paquete de entrega que el cliente pueda usar

No entregues una carpeta llena de archivos sin contexto.

El paquete de salida debería incluir, según el alcance contratado:

• inventario final de hardware y software;
• estado de parches, alertas y riesgos conocidos;
• tickets abiertos y su siguiente acción;
• diagramas de red y dependencias relevantes;
• runbooks y procedimientos vigentes;
• contactos de proveedores;
• licencias y activos propiedad del cliente;
• ubicación, vigencia y responsabilidad de los respaldos;
• decisiones pendientes que el nuevo proveedor o equipo interno debe conocer.

Marca qué documento es definitivo, cuál es sólo una referencia y qué información vence después del corte. Si entregas secretos, usa un canal cifrado separado y confirma que el destinatario pudo abrirlos.

Los reportes RMM para clientes pueden servir como evidencia inicial, pero el paquete de salida también necesita contexto: pendientes, excepciones y decisiones.

4) Revoca accesos, sesiones y credenciales

Deshabilitar una cuenta no siempre termina todas las sesiones existentes.

Microsoft explica que algunas aplicaciones conservan sus propias cookies o tokens de sesión; por eso, además de bloquear nuevos inicios, puede ser necesario revocar sesiones y desprovisionar el acceso dentro de cada aplicación.

Como referencia de control, NIST SP 800-171 Rev. 3 incluye acciones de terminación como deshabilitar acceso y revocar autenticadores y credenciales. No significa que esa publicación sea obligatoria para todos los MSPs; sí muestra por qué el cierre debe ser oportuno y verificable.

Revisa al menos:

1. cuentas de técnicos, administradores y subcontratistas;
2. usuarios del cliente dentro del RMM, PSA, documentación y portales del MSP;
3. sesiones activas y refresh tokens;
4. acceso remoto, VPN y herramientas de soporte;
5. Microsoft 365, nube, SaaS y portales de proveedores;
6. contraseñas compartidas;
7. claves API, secretos, llaves SSH y códigos de recuperación;
8. integraciones, aplicaciones empresariales y webhooks;
9. dispositivos registrados o de confianza;
10. cuentas de emergencia y accesos temporales.

Si una credencial fue conocida por el MSP, el cierre debe indicar quién la rotará, cuándo y cómo se verificará. Nuestra guía de sesiones activas en un RMM explica por qué cerrar el navegador no equivale a revocar acceso.

5) Retira o transfiere agentes sin perder trazabilidad

Un agente no debe quedarse instalado por costumbre.

Tampoco debe desinstalarse sin confirmar el destino del endpoint y la autorización correspondiente.

Clasifica cada dispositivo:

Después revisa tareas programadas, scripts, políticas, despliegues automáticos, túneles, cuentas locales y herramientas auxiliares que el MSP haya creado. El agente visible suele ser sólo una parte del acceso operativo.

En Lunixar RMM puedes usar el inventario y el último estado reportado para conciliar endpoints. La autorización, transferencia y verificación final siguen siendo responsabilidades del proceso de offboarding.

6) Decide qué datos se devuelven, se conservan y se eliminan

“Borrar todo” puede ser tan incorrecto como “guardar todo para siempre”.

Separa la información en tres grupos:

1. Devolver: inventarios, reportes, documentación, configuraciones y activos que pertenecen al cliente.
2. Conservar: facturación, aprobaciones, evidencia contractual o registros que deban mantenerse por un periodo definido.
3. Eliminar: copias operativas, exportaciones temporales, secretos y datos que ya no tengan una finalidad válida.

NIST SP 800-63A establece, dentro de su alcance de identidad digital, que la información personal asociada a cuentas terminadas debe eliminarse conforme a una política documentada de retención y disposición. La idea útil para un MSP es simple: define el periodo y la razón antes de conservar información.

Cuando tengas que sanitizar medios o copias, NIST publicó en 2025 la SP 800-88 Rev. 2, que organiza la sanitización según sensibilidad, tipo de medio y nivel de esfuerzo necesario para impedir la recuperación.

No conviertas estas referencias en asesoría legal automática. El contrato, el tipo de datos, la jurisdicción y las obligaciones fiscales o regulatorias determinan lo que realmente debes hacer.

7) Cierra licencias, renovaciones y facturación

Los costos olvidados también forman parte del offboarding.

Revisa:

• licencias compradas por el MSP para el cliente;
• licencias propiedad del cliente pero administradas por el MSP;
• suscripciones con renovación automática;
• dominios, DNS, certificados y hosting;
• servicios de respaldo, correo, seguridad y nube;
• garantías y contratos con terceros;
• cargos finales, créditos o consumo pendiente;
• fecha exacta en que termina la facturación recurrente.

No canceles un recurso del cliente sólo porque aparece en tu tarjeta o portal. Primero define si se cancela, se transfiere o se reasigna, y quién acepta el cambio.

8) Obtén evidencia y aceptación, no sólo una despedida

El cierre debería responder estas preguntas:

• ¿Qué se completó?
• ¿Qué no pudo completarse?
• ¿Qué acceso se revocó, transfirió o rotó?
• ¿Qué agentes siguen pendientes y por qué?
• ¿Qué información se entregó?
• ¿Qué datos se conservarán y hasta cuándo?
• ¿Qué riesgos residuales aceptó el cliente?
• ¿Quién ejecutó y quién aprobó cada acción?

Usa una matriz final:

El acta no necesita veinte páginas. Necesita alcance, resultados, excepciones, responsables y aceptación.

9) Descarga y adapta la plantilla

Preparamos una hoja de cálculo para ejecutar el proceso:

Descargar checklist de offboarding para clientes MSP (.xlsx)

Incluye:

• 26 controles agrupados en seis fases;
• columnas para responsable, fecha límite, evidencia y excepción;
• estados desplegables;
• progreso automático;
• pestañas ES, EN y PT;
• fuentes oficiales y recordatorio contractual.

Úsala como base. Agrega los sistemas, proveedores, plazos y aprobaciones reales de cada cliente.

FAQ: offboarding para clientes MSP

¿Cuándo debe comenzar el offboarding?

Desde que existe una notificación válida y una fecha de terminación confirmada. La preparación puede iniciar antes; las acciones destructivas o de revocación deben respetar la hora autorizada.

¿Debo desinstalar todos los agentes inmediatamente?

No sin conciliar inventario, propiedad, conectividad y autorización. Algunos endpoints pueden estar offline, en transición o administrados temporalmente durante la entrega.

¿Bloquear una cuenta termina todas las sesiones?

No siempre. Algunas aplicaciones emiten sus propios tokens o cookies. Verifica la revocación de sesiones dentro de cada plataforma crítica.

¿Cuánto tiempo debe conservar datos el MSP?

No existe un plazo universal. Defínelo con base en contrato, finalidad, sensibilidad, legislación y obligaciones aplicables. Documenta la fecha de eliminación.

¿La plantilla reemplaza un contrato o asesoría legal?

No. Es una herramienta operativa. Adáptala con asesoría profesional cuando existan requisitos legales, fiscales, regulatorios o de privacidad.

Un buen cierre también demuestra profesionalismo

El onboarding gana al cliente.

El offboarding demuestra cómo trabajas cuando la relación termina.

Con Lunixar RMM para MSPs puedes centralizar inventario, estado de endpoints, alertas y reportes que ayudan a construir evidencia. El cierre correcto añade lo que ninguna consola decide por ti: autorización, transferencia, revocación, retención y aceptación.

Sin accesos olvidados.

Sin agentes huérfanos.

Sin datos guardados “por si acaso”.