Un empleado deja la empresa. ¿Cuál es el control relevante de GRC que hay que verificar?
Respuesta breve
El riesgo de una baja es el acceso que persiste, así que el control a verificar es el desaprovisionamiento puntual de cada vía de acceso —cuentas de directorio, SSO, VPN, credenciales privilegiadas y de servicio, y SaaS de terceros— conciliado con el proceso de alta/cambio/baja (JML). Suponer que RR. HH. lo gestiona todo sin verificar deja brechas sin propietario. Mantener la cuenta activa 'por si vuelve' es un riesgo permanente y no supervisado. Desactivar solo el correo ignora los muchos otros sistemas que la persona aún podría alcanzar. La clave es verificar que el acceso se elimina real y completamente, no confiar en que así fue.
Cuando alguien se va, el riesgo no es la salida, sino el acceso que persiste tras ella. Un exempleado (o un atacante que encuentra la cuenta abandonada) con credenciales activas al correo, la VPN, las consolas de nube o un sistema privilegiado es un vector de brecha de manual. El control de GRC consiste en verificar que todo ese acceso se elimina con prontitud, y verificarlo contra un proceso definido en lugar de suponer que ocurrió.
Qué cubre realmente "todo el acceso"
El desaprovisionamiento no es un único interruptor. Un proceso de baja completo revoca las cuentas de directorio (Active Directory / Entra ID), las sesiones SSO y los inicios de sesión federados, las credenciales de VPN y acceso remoto, las cuentas privilegiadas y de servicio/admin y, sobre todo, las aplicaciones SaaS de terceros —muchas aprovisionadas fuera de la TI central y que sobreviven a una desactivación de SSO—. Todo esto debe conciliarse con el proceso de alta/cambio/baja (JML), para que un flujo definido y auditable especifique qué se elimina, en qué plazo y quién lo confirmó.
Por qué fallan las respuestas incorrectas
"RR. HH. se encarga de todo" es la suposición que crea cuentas huérfanas: RR. HH. es dueño del evento laboral, pero la eliminación técnica de accesos necesita un propietario y verificación —confiar sin comprobar deja brechas—. Mantener la cuenta activa "por si vuelve" es un riesgo permanente y no supervisado; una credencial válida y dormida es exactamente lo que buscan los atacantes. Desactivar solo el correo atiende el sistema más visible e ignora la VPN, la nube, el SaaS y los accesos privilegiados que la persona aún puede usar —un arreglo parcial que parece hecho pero no lo está—.
El criterio que se evalúa
El entrevistador quiere oírte razonar en términos del ciclo de vida completo de la identidad, verte verificar en lugar de suponer, y comprender la larga cola de cuentas SaaS y shadow que escapan al SSO. Una buena respuesta menciona la conciliación con el proceso JML, la gestión de credenciales compartidas y de servicio (rotarlas, no solo desactivarlas) y la capacidad de evidenciar un desaprovisionamiento puntual ante un auditor —cerrando el círculo entre el evento de RR. HH. y la eliminación real y confirmada de cada vía de acceso—.
Posibles preguntas de seguimiento
- ¿Cómo detectas las cuentas SaaS o de 'shadow IT' que no están detrás del SSO?
- ¿Cuál es la forma correcta de gestionar las cuentas compartidas o de servicio que usaba la persona que se va?
- ¿Cómo evidenciarías un desaprovisionamiento puntual ante un auditor?