El riesgo de seguridad que nadie ve: accesos activos de quien ya no trabaja contigo

Un cliente bancario en Colombia enviaba tickets manuales para inactivar a empleados que ya no trabajaban con ellos — entre 10% y 15% de su volumen mensual de tickets, urgentes por naturaleza porque cada retraso significaba un exempleado con acceso activo a la plataforma. Automatizar la detección del correo de baja y disparar la desactivación vía API, sin intervención manual, eliminó ese riesgo y ese volumen de tickets — y el mismo patrón se reutilizó después para automatizar el alta de nuevos empleados.

El acceso que sigue abierto después del último día

El acceso de un exempleado, activo un día más de lo necesario, no es un detalle administrativo — es una de las observaciones más comunes en auditorías SOC 2 e ISO 27001, y una de las más fáciles de prevenir si el proceso no depende de que alguien recuerde mandar el ticket a tiempo.

¿Qué tan común es este riesgo, en realidad?

Estudios de gobernanza de identidad de 2026 ubican a las cuentas huérfanas entre las tres principales preocupaciones de seguridad SaaS para el 89% de los CISO encuestados, al mismo nivel que la escalación de privilegios y el shadow IT. Y en un análisis reciente del sector, 27% de las brechas en la nube involucraron el mal uso de credenciales inactivas — muchas de ellas, cuentas de personas que ya no debían tener acceso.

¿Cómo se diseñó la automatización?

Nos reunimos con el cliente para entender su proceso de baja y el formato exacto de sus correos de notificación. A partir de ahí diseñamos un flujo automatizado: cuando llegaba un correo de un remitente aprobado con ciertas palabras clave, un agente disparaba una llamada API que actualizaba el estatus del usuario directamente en la plataforma, sin manejo manual. Después aplicamos el mismo patrón para automatizar la configuración inicial de nuevos empleados.

¿Qué cambia cuando la automatización reemplaza al ticket?

Eliminamos por completo el manejo manual de esos tickets, reduciendo entre 10% y 15% el volumen mensual de esa cuenta y quitando el riesgo de desactivación tardía. También liberamos a Nivel 1 para enfocarse en casos de mayor valor. Lo que haría distinto hoy: exigir desde el inicio el mismo formato de correo, para que Nivel 1 nunca reciba estos casos por la vía manual — que la automatización sea la única ruta, no un atajo que corre en paralelo con el proceso manual de respaldo.

La lección que me llevo

El costo promedio de una brecha de datos ronda los $4.45 millones de dólares según IBM (2024) — y una parte de ese riesgo vive en algo tan simple como un acceso que debió cerrarse el mismo día que alguien dejó de trabajar contigo. Automatizar ese cierre no es una mejora de eficiencia; es control de acceso básico.

Fuentes de datos: estudios de gobernanza de identidad 2026 (cuentas huérfanas entre las tres principales preocupaciones de seguridad SaaS para el 89% de los CISO encuestados); análisis del sector sobre brechas en la nube (27% involucraron mal uso de credenciales inactivas); IBM Cost of a Data Breach Report 2024 ($4.45 millones USD promedio global).

Preguntas frecuentes

¿Cómo se automatiza la revocación de accesos sin depender de tickets manuales? Diseñando un flujo que detecte el evento de baja (por ejemplo, un correo de un remitente aprobado con ciertas palabras clave) y dispare automáticamente una llamada API que actualice el estatus del usuario en la plataforma, sin intervención humana.

¿Qué es una cuenta huérfana? Una cuenta de usuario que sigue activa y con acceso a sistemas después de que la persona dejó la organización o cambió de rol. Es una observación frecuente en auditorías SOC 2 e ISO 27001 y un vector común en brechas de datos.