Un protocolo simple para revocar accesos y proteger información ante la salida de personal: qué revisar, en qué orden y cómo asegurarse de que no quede una puerta abierta.
Cada vez que una persona deja una empresa —por renuncia, despido, fin de contrato o cualquier otra razón—, se abre una ventana de riesgo que la mayoría de las organizaciones no gestiona bien. Las credenciales de esa persona pueden seguir activas durante días, semanas o meses. Las sesiones iniciadas en aplicaciones web pueden permanecer abiertas. Los accesos compartidos de los que nadie lleva registro pueden quedar en el limbo.
El problema no es la persona que se va. Es que muy pocas empresas tienen un protocolo claro para revocar accesos de forma sistemática. Cuando la gestión se hace de manera informal —"que alguien de sistemas desactive las cuentas"—, el resultado es un mosaico de accesos parcialmente revocados, credenciales que sobreviven por omisión y puertas abiertas que nadie sabe que existen hasta que ocurre un incidente.
Este artículo propone un protocolo simple que cualquier empresa puede implementar, desde una pyme con cinco empleados hasta una organización con equipos de decenas de personas. No requiere herramientas sofisticadas: requiere disciplina y un checklist.
Cuando una persona deja la empresa, el foco suele estar en lo operativo: quién va a cubrir sus tareas, cómo se hace la transición de sus proyectos, qué documentación deja. La seguridad de la información suele ser una ocurrencia tardía, algo que "alguien se ocupa" pero que rara vez tiene un responsable designado y un procedimiento escrito.
Las consecuencias de no gestionar bien los accesos tras una salida son más frecuentes de lo que se cree. Un ex empleado que conserva acceso a la cuenta de correo corporativa puede leer comunicaciones internas durante semanas. Un ex colaborador con credenciales activas en el sistema de gestión puede modificar o eliminar información. Una cuenta compartida de un servicio en la nube que nunca se rotó puede ser usada por alguien que ya no debería tener acceso.
No hace falta que haya mala intención. A veces el problema es que la cuenta sigue activa, alguien la usa por costumbre y se mezcla información vieja con nueva. O que la cuenta es vulnerada por un tercero porque nadie la monitorea y la contraseña es débil. El riesgo no es solo el ex empleado: es que el acceso no gestionado se convierta en un vector de ataque para cualquiera.
En muchas empresas, el tiempo promedio entre la salida de una persona y la revocación completa de todos sus accesos supera los siete días. Durante esa semana, las credenciales están activas y nadie las está monitoreando. Si tu empresa no sabe exactamente cuánto tarda este proceso hoy, probablemente sea más de lo que imaginás.
Gestionar la salida de una persona en términos de seguridad no es complejo si se sigue un orden. Lo que falla no es la dificultad técnica: es la falta de un procedimiento estandarizado que se ejecute siempre, sin excepciones, sin depender de que alguien se acuerde.
El momento de preguntarse a qué sistemas tiene acceso una persona no es el día después de que se fue. Es antes: idealmente en el momento de la contratación, cuando se definen los accesos que necesita, y se actualiza cada vez que cambia de rol o de responsabilidades.
Si tu empresa no tiene un registro de qué accesos tiene cada persona —un simple documento alcanza—, el primer paso del protocolo es crearlo. No hace falta un sistema complejo: una planilla con columnas de persona, sistema, tipo de acceso y fecha de concesión es suficiente para empezar.
Los sistemas que suelen concentrar la mayor cantidad de accesos no revocados son:
Elegí a una persona de tu equipo —no la que se va, sino una actual— y pedile que enumere todos los sistemas, aplicaciones y servicios a los que tiene acceso. Compará esa lista con el registro que tiene la empresa. La diferencia entre ambas listas es tu verdadera exposición al riesgo.
El orden importa. No todos los accesos tienen el mismo potencial de daño si permanecen activos, y el tiempo siempre es limitado —especialmente en salidas conflictivas o repentinas—. Revocá primero lo que más daño puede hacer:
Revocar un acceso no es lo mismo que confirmar que la revocación funcionó. Después de ejecutar cada paso, verificá:
Después de revocar los accesos, intentá iniciar sesión con las credenciales de la persona en cada sistema —o pedile a alguien de tu equipo que lo haga—. Si podés entrar, la revocación no fue efectiva. Este control simple detecta configuraciones mal aplicadas, sesiones que sobrevivieron y accesos que se escaparon del radar.
Cada salida es una oportunidad para mejorar el protocolo. Después de ejecutar los pasos anteriores, documentá:
El protocolo descrito hasta acá es manual, y eso está bien para empezar. Pero a medida que la empresa crece, ejecutarlo manualmente cada vez que alguien se va se vuelve ineficiente y propenso a errores. La automatización no requiere un sistema complejo: hay cosas que se pueden resolver con lo que ya tenés.
Usar un gestor de identidad, aunque sea básico. Servicios como Google Workspace, Microsoft 365 o herramientas específicas de gestión de identidad permiten centralizar el alta y la baja de usuarios. Cuando una cuenta se desactiva en el directorio central, todos los servicios conectados deberían reflejar ese cambio automáticamente. Si tu empresa ya usa uno de estos servicios, asegurate de que todas las aplicaciones estén integradas. Si no, agregar las que faltan es más rápido y barato que seguir haciendo las bajas a mano.
Single Sign-On siempre que sea posible. Cuando los empleados acceden a las aplicaciones de la empresa usando su cuenta corporativa, revocar el acceso es un solo paso: desactivar la cuenta central. Cuando cada aplicación tiene su propio usuario y contraseña, revocar el acceso son quince pasos, y alguno casi seguro se va a olvidar.
Políticas de contraseñas y rotación automática. Las cuentas compartidas no deberían existir, pero si existen por razones operativas que no se pueden resolver en el corto plazo, al menos deberían tener rotación automática de contraseñas cada vez que alguien que las usaba deja la empresa.
Hay prácticas que son errores evidentes en retrospectiva pero que se repiten en empresas de todos los tamaños. Mencionarlas explícitamente ayuda a reconocerlas:
Que la persona que se va sea la encargada de desactivar sus propios accesos. Suena absurdo, pero ocurre. Confiar en que alguien que está saliendo de la empresa va a ejecutar su propia baja de sistemas es delegar la seguridad en quien ya no tiene incentivos para proteger los intereses de la organización.
Que el protocolo dependa de una sola persona. Si la única persona que sabe cómo revocar accesos está de vacaciones, el proceso se frena. El protocolo tiene que estar documentado y al menos dos personas deben saber ejecutarlo.
Que las cuentas de servicios —no de personas— se olviden sistemáticamente. Muchas credenciales no pertenecen a personas sino a aplicaciones: un script que usa una clave de API, una integración que se autentica con un token, un servicio que corre con credenciales que alguna persona configuró y ya no está. Cuando esa persona se va, el token sigue activo. Un inventario de credenciales de servicio, con responsables designados, es parte del protocolo de salida.
Que la salida sea amistosa y por eso se relajen los controles. La seguridad no depende del tono de la salida. Un protocolo bien diseñado se ejecuta igual para una renuncia en buenos términos que para un despido conflictivo. Si el protocolo es opcional en función de cómo se fue la persona, no es un protocolo: es una decisión discrecional.
Si tu empresa no tiene ningún procedimiento formal para gestionar accesos tras una salida, no intentes implementar todo de una vez. Empezá por lo mínimo viable:
Creá un registro de accesos por persona. Una planilla simple con columnas: nombre de la persona, sistema, tipo de acceso, fecha de concesión, responsable de revocación. Completala para todos los empleados actuales. Esto ya te da visibilidad sobre lo que hay que revocar cuando alguien se va.
Designá un responsable. Una persona —o un equipo, si la empresa es más grande— cuyo trabajo incluya explícitamente la gestión de altas y bajas de accesos. No puede ser una responsabilidad difusa que "todos saben que hay que hacer pero nadie tiene asignada".
Escribí el checklist de salida. Los cuatro pasos descritos en este artículo, adaptados a los sistemas que usa tu empresa, en un documento de una página que cualquier persona pueda seguir. Probá el checklist con la próxima salida y ajustalo según lo que funcione y lo que no.
Hacé una auditoría de accesos activos. Elegí un día del trimestre para revisar todos los accesos activos y detectar cuentas que deberían haber sido revocadas y no lo fueron. La primera vez que hagas este ejercicio probablemente encuentres accesos de personas que dejaron la empresa hace meses.
El artículo sobre qué es una brecha de seguridad explica cómo los accesos no gestionados se convierten en el punto de entrada para incidentes que podrían haberse prevenido. Si manejás datos de clientes, qué datos de tus clientes debes proteger detalla qué información es más sensible y por qué el acceso no controlado a esa información es un riesgo legal y de reputación. Para una mirada más amplia, riesgos técnicos que nadie revisa hasta que es tarde describe otros puntos débiles que las empresas suelen pasar por alto.
Gestionar la salida de una persona no es un acto de desconfianza: es una práctica de higiene de seguridad. Así como cerrás la puerta con llave cuando salís de la oficina —no porque desconfíes de tus vecinos, sino porque es lo que corresponde—, revocar accesos cuando alguien deja la empresa es simplemente lo que corresponde. Las empresas que lo hacen bien no son las que más invierten en seguridad: son las que tienen un protocolo y lo ejecutan sistemáticamente.
¿Quieres evaluar cómo aplicar esto a tu proyecto?
Cuéntanos tu caso →