El handover es el producto: qué contiene un safe delete de verdad

La cuenta más peligrosa de tu empresa probablemente pertenece a alguien que ya no trabaja allí. Y no es una hipótesis: cuando Beyond Identity encuestó a 1.121 empleados y directivos en Estados Unidos, Reino Unido e Irlanda, el 83% de los exempleados admitió que aún podía acceder a cuentas de una empresa anterior. Y no hablamos de un acceso puntual, por descuido: acceso continuado, meses después de la despedida.

Llevo dos décadas en operaciones corporativas, buena parte de ellas operando sistemas de producción donde la checklist de salidas era mi problema. He hecho arqueología forense sobre los accesos de un contractor que ya no estaba: la cuenta de servicio que sobrevivió un año a su dueño, el colaborador de GitHub de hace dos proveedores, el buzón que siguió recibiendo respuestas de clientes seis meses después de vaciarse la silla. Del arco de despliegue — find, deploy, sustain, hand over — escribí en la pieza sobre el modelo forward-deployed. Este artículo abre en canal la última fase, porque es la que nadie pregunta en una llamada comercial y la primera que te va a preguntar el auditor.

Todo el mundo diseña el primer día. Casi nadie diseña el último.

Nuestra industria lleva una década comprimiendo comienzos. Matches en días, runbooks de onboarding, accesos automatizados desde el primer día — progreso real, y nosotros mismos competimos en eso. A los finales, en cambio, no les ha llegado nada de esa ingeniería. Un proyecto termina como ha terminado siempre: una invitación de calendario, un último standup y el acuerdo tácito de que alguien «limpiará las cuentas» en un sprint que nunca llega.

La causa de la asimetría cabe en una frase: los comienzos se venden; los finales se heredan. El arranque del proyecto es aquello por lo que se evalúa al proveedor, así que ahí fue el esfuerzo de diseño. El final le pertenece a quien se queda con el inventario de accesos en las manos — normalmente, a ti.

Un proyecto que termina sin una pasada de desaprovisionamiento no está terminado. Se ha quedado abandonado tal cual.

El acceso sobrevive a las personas porque el inventario no es de nadie

¿Por qué el acceso de un ingeniero sobrevive a su marcha? No es malicia, y rara vez es incompetencia. El acceso se acumula por una docena de puertas y se va por una sola:

• El proveedor de identidad cubre las cuentas que federaste — y nada más.
• Las licencias de SaaS en la sombra: la herramienta de analítica, el rastreador de errores, el panel de feature flags que alguien dio de alta con una tarjeta corporativa el primer año.
• Las credenciales compartidas en el vault del equipo — o peor, en un mensaje fijado de Slack.
• Los tokens de API y secretos de CI de larga vida, creados para una migración y jamás rotados.
• Las autorizaciones OAuth a cuentas personales: el «Sign in with Google» de una herramienta que nadie recuerda haber aprobado.
• Los accesos del lado del proveedor: los que los sistemas de tu partner mantienen en nombre de su ingeniero.

El offboarding falla como problema de inventario antes de fallar como problema de seguridad. El día que alguien se va, solo puedes revocar lo que puedes enumerar — y si la enumeración empieza ese día, ya has perdido. En los datos de Beyond Identity, el 74% de los directivos dijo que su empresa había sufrido daños por el acceso de un exempleado, y el 56% de los que conservaron acceso admitió haberlo usado con intención de hacer daño. Yo le daría más peso al descuido que a la malicia — pero al auditor no le importa el motivo, solo la puerta abierta.

Un safe delete es un entregable, no una limpieza

En Conectia el handover es una fase de cada proyecto, con su propio artefacto. Esto es lo que contiene un «safe delete» cuando se hace como producto y no como tarea pendiente:

1. El libro de accesos, mantenido desde el primer día. Cada credencial, licencia, token y autorización emitida al ingeniero, registrada cuando se concede — no reconstruida al final. La última semana de un proyecto es demasiado tarde para empezar a recordar.
2. Documentación de lo construido. Arquitectura, decisiones, runbooks, el porqué de las partes no obvias. Si no está escrito antes de la última semana, el conocimiento se marcha con la persona el último día.
3. Cuentas de trabajo transferidas, no abandonadas. Repositorios, paneles, consolas cloud — propiedad reasignada a una persona con nombre de tu lado, con el contexto para operarlas. Borrar una cuenta que es dueña de recursos de producción es un incidente en sí mismo; un safe delete primero transfiere y después revoca.
4. Rotación de credenciales, no solo revocación. Las cuentas personales se desactivan; los secretos compartidos que el ingeniero pudo haber visto se rotan. Una contraseña del vault que quien se va llegó a leer es, a efectos prácticos, una contraseña comprometida.
5. La decisión sobre el buzón, hecha explícita. Reenviado, archivado bajo reglas de retención, o cerrado — alguien elige, por escrito. El buzón que sigue recibiendo respuestas de clientes que ya nadie lee es el artefacto más común que he encontrado en la arqueología post-salida.
6. Borrado del lado del proveedor. Cerramos nuestras propias copias: contenido corporativo, credenciales y accesos a repositorios en nuestros sistemas, contabilizados y eliminados. Tu offboarding solo es tan completo como el de tu proveedor.
7. Una firma que conservan ambas partes. Un documento con lo que se entregó, lo que se revocó, lo que se rotó y quién lo verificó. No por ceremonia — por la auditoría, dieciocho meses después, cuando alguien pregunte «¿quién tenía acceso a producción en el tercer trimestre?».

Nada de esto es exótico. Cada punto es algo que un equipo de operaciones competente podría hacer. La diferencia entre poder hacerlo y haberlo hecho está en si alguien se hace cargo del final como proceso — con checklist y firma — o si se da por hecho.

Tu auditor encuentra el final antes que un atacante

Si vas camino de SOC 2 o ISO 27001, el control de accesos es donde los proyectos externos te acaban pasando factura. Ambos marcos esperan que demuestres que el acceso se concede por necesidad, se revisa periódicamente y se revoca al terminar — y «terminar» incluye al contractor cuyo statement of work caducó sin que nadie se diera cuenta. Con el RGPD hay todavía más en juego: un ingeniero externo con acceso a datos personales está dentro de tu perímetro de tratamiento, y un acceso que sobrevive al proyecto es un punto abierto en tus obligaciones del artículo 32, no solo una consola IAM desordenada.

Este es el patrón que he visto repetirse en auditorías corporativas: las altas están documentadas de maravilla, porque contratar siempre tiene un responsable. En las bajas, en cambio, la evidencia empieza a escasear — el ticket de revocación que falta, la revisión de accesos con un nombre que nadie reconoce. El final de un proyecto externo es donde tu rastro de auditoría es más débil, porque es el momento en que la responsabilidad pasa de una organización a otra y cada una puede asumir, con argumentos razonables, que la tiene la otra.

Un artefacto de handover firmado cierra ese hueco con un solo documento. Es la evidencia de compliance más barata que producirás, y solo puede producirse a tiempo.

La mayoría de los finales son inofensivos. Esa es la trampa.

El argumento más fuerte contra todo lo anterior: la mayoría de los proyectos terminan bien. La persona correcta, una salida limpia, nada explotado — y en ese escenario, el protocolo de arriba solo produjo papeleo que nadie llegó a leer. Es verdad, y no voy a fingir lo contrario.

Pero un protocolo de salidas no existe para el caso típico. Existe para la cola de la distribución — el recorte de presupuesto que termina tres contratos en una semana, el ingeniero cuya salida fue menos amistosa de lo que sugería el hilo de despedida, la auditoría que aterriza dos años después. Que el 83% de los que se van conserve acceso no significa que el 83% de los finales salga mal; significa que casi todos los finales dejan la puerta abierta para el que sí. La cola es donde se concentra el coste, y no eliges de antemano en qué final estás. El mismo argumento lo hice sobre el arco de despliegue completo; en la salida es donde más se nota.

Cinco líneas que querría firmadas antes del último día

Si te llevas una sola cosa de este artículo, que sea operativa. Antes de que termine cualquier proyecto externo — el nuestro incluido — pon estas cinco líneas delante de tu partner:

1. «Envíame el libro de accesos.» Si no existe, el offboarding será una excavación, no una checklist.
2. «¿Quién responde de cada cuenta el último día?» Una persona con nombre por sistema, de tu lado, confirmada antes de la última semana.
3. «¿Qué secretos compartidos se rotan, y cuándo?» Revocar a la persona sin rotar lo que vio es medio trabajo.
4. «¿Qué borráis de vuestro lado, y quién puede probarlo?» Las copias de tu proveedor son parte de tu perímetro.
5. «¿Dónde está la firma?» Una página, dos firmas, archivada donde tu próxima auditoría pueda encontrarla.

Un partner que opera un modelo de despliegue real responde las cinco sin consultar con legal — las respuestas son su proceso, puesto por escrito. Si las preguntas causan sorpresa, la sorpresa es la respuesta.

La industria aprendió a diseñar el match. El handover sigue tratándose como un detalle de última hora, y los números dicen que ese detalle acaba costando caro. Nosotros convertimos el final en un entregable porque yo he sido quien ha tenido que auditar lo que queda después, y nadie debería heredar ese trabajo de nosotros. El staffing termina en el match. El despliegue termina en el handover — y si el final es parte de lo que compras, es lo que incluyen nuestros forward-deployed engineers.