Checklist de offboarding y recuperación de accesos para MSP pequeños

Respuesta corta: El offboarding es un flujo de seguridad, no sólo una tarea de cierre de cuenta. Un MSP pequeño necesita remover o transferir accesos, documentar riesgos abiertos y dejar evidencia de que la responsabilidad operativa terminó de forma limpia.

El offboarding empieza antes del último día

El offboarding de cliente se complica cuando empieza después de la última factura, el aviso de cancelación o la solicitud del nuevo proveedor. Para entonces, el MSP puede estar recuperando accesos, explicando excepciones viejas y cerrando tickets bajo presión.

El aviso de CISA para managed service providers y sus clientes recuerda que el acceso del MSP trae riesgo real. Por eso el offboarding debe tratar la limpieza de accesos como trabajo de seguridad, no como un favor posterior al cierre comercial.

Trata el offboarding como el reverso del checklist de onboarding: lo que se otorgó, conectó, monitoreó, documentó y cobró ahora necesita dueño claro.

Nombra el estado final

Antes de remover algo, define qué significa cierre limpio:

• quién queda como dueño de cuentas administrativas;
• si los agentes RMM se remueven o se transfieren;
• quién controla backups e historial de restore;
• qué documentación se exporta;
• qué tickets siguen abiertos;
• qué riesgos acepta el cliente;
• qué vendors deben ser notificados.

El objetivo no es castigar al cliente. El objetivo es evitar que acceso escondido se vuelva riesgo escondido.

El NIST Cybersecurity Framework 2.0 ayuda a describir ese estado final: gobierno, identificación, protección, detección, respuesta y recuperación necesitan dueño claro después de que el MSP sale. El registro de offboarding debe hacer visible esa propiedad.

Inventario de accesos

Revisa al menos estas superficies:

• proveedor de identidad y roles de admin global;
• acceso delegado en Microsoft 365 o Google Workspace;
• portales de RMM, PSA, documentación, backup, EDR, DNS, dominio, firewall y hosting;
• contraseñas y secretos compartidos;
• portales de vendors donde el MSP aparece como contacto;
• alertas de monitoreo que todavía notifican al MSP;
• cuentas break-glass del cliente.

Para tenants de Microsoft, la introducción a GDAP y la guía de roles de mínimo privilegio sirven porque el acceso administrativo delegado debe ser intencional, limitado y revisable. El offboarding debe remover o transferir ese acceso con intención, no dejarlo como una relación olvidada.

Conecta esto con la base de seguridad. Offboarding también es control de accesos.

Propiedad de backup y restore

Los backups son el lugar más peligroso para dejar ambigüedad. Confirma:

1. qué datos siguen protegidos;
2. quién puede restaurarlos;
3. quién recibe alertas de falla;
4. si la retención continúa después del contrato;
5. si el cliente tiene credenciales y propiedad de facturación;
6. qué evidencia de prueba de restore existe.

Si los backups terminan, dilo claro. Si continúan bajo el cliente u otro proveedor, registra el handoff.

La guía de ciberseguridad para pequeños negocios de la FTC apunta a preparación práctica de recuperación. Durante offboarding, la propiedad del backup y la responsabilidad de restore deben quedar explícitas antes de que el MSP deje de recibir alertas o conservar credenciales.

Handoff de vendors y documentación

La coordinación con vendors no debe convertirse en un proyecto gratis interminable después de la cancelación. Lista vendors, contactos, casos activos, fechas de renovación y bloqueos conocidos. Luego identifica qué hará el MSP durante offboarding y qué requiere aprobación separada.

La documentación debe exportarse en un formato usable cuando el contrato lo permite. No dejes al cliente con capturas de un sistema al que no puede entrar.

Tickets abiertos y excepciones

Cada punto abierto necesita estado final:

• cerrado antes del offboarding;
• transferido al cliente;
• transferido al nuevo proveedor;
• convertido en proyecto;
• registrado como riesgo aceptado;
• bloqueado por falta de aprobación o acceso.

Usa el modelo de mesa de servicio para mantener el cierre factual.

Paquete final de evidencia

El paquete final puede ser simple:

• fecha de offboarding;
• accesos removidos o transferidos;
• vendors notificados;
• documentación exportada;
• backups transferidos o terminados;
• riesgos y tickets abiertos listados;
• decisiones del cliente registradas;
• exclusiones restantes declaradas.

Esta evidencia protege a ambos lados. Muestra que el MSP no dejó control silencioso y muestra a dónde se movió la responsabilidad.

Error común

El error común es mezclar offboarding de seguridad con la discusión comercial. Una cancelación puede ser frustrante, pero la limpieza de accesos debe mantenerse disciplinada.

Cuándo subir el nivel

Si el offboarding toma días de investigación, probablemente el onboarding y la documentación fueron demasiado débiles. Usa el cierre para mejorar el siguiente intake, registro de accesos y revisión mensual.