Diagrama del proceso de solicitud de accesos (alta y cambio de rol)

Cómo funciona

1. Apunta el disparador a vuestro registro real de RR. HH.

   Sustituye «Registrar el evento de alta o cambio» por el registro que de verdad lanza el proceso: un alta en el sistema de personal o un cambio de puesto con fecha de efecto. Anota quién lo introduce y con cuánta antelación tiene que existir respecto a la fecha efectiva, porque ese margen es lo que decide si el acceso está listo el primer día en el puesto.

2. Escribe los perfiles de rol antes de publicar el diagrama

   «Consultar el perfil de acceso del rol» solo funciona si los perfiles existen. Empieza por los puestos que más contratáis y a los que más gente se mueve, enumera los permisos que necesita cada uno y asigna a cada perfil un propietario con nombre y una fecha de revisión. Los perfiles sin dueño acaban convertidos en la suma de todo lo que alguien ha pedido alguna vez, que es justo lo contrario de solicitar un puesto en lugar de un sistema.

3. Define qué cuenta como sistema sensible

   La rama «¿Incluye un sistema sensible?» necesita criterios escritos al lado. Los casos habituales son nóminas y sistemas financieros, datos personales o de salud, entornos de producción y cualquier permiso con derechos de administrador. Ajusta el listón para que la rama se active en una minoría de solicitudes: si salta con todo, la aprobación del propietario se convierte en un trámite y frena los casos ordinarios.

4. Convierte la retirada en una tarea con responsable y fecha

   La flecha «Retirar antiguos» es el paso que la mayoría de las organizaciones no tiene. Decide quién elabora la lista de accesos del puesto anterior —normalmente el responsable saliente o una exportación de la herramienta de identidades—, quién ejecuta la retirada y en qué plazo respecto a la fecha del cambio. Si alguien necesita conservar accesos antiguos para cerrar un traspaso, concédelos como prórroga con fecha en lugar de dejar el permiso abierto.

5. Acuerda las reglas de segregación de funciones y quién acepta un conflicto

   Enumera las combinaciones que una misma persona no puede tener, por ejemplo dar de alta a un proveedor y aprobar sus pagos, o escribir código y publicarlo en producción. Sin esa lista, el control es decorativo. Después nombra a quién puede aceptar un conflicto inevitable y qué control compensatorio tiene que registrar junto al permiso, porque en un equipo pequeño el conflicto es a veces la única salida viable.

6. Publícalo y pruébalo con los siguientes cambios de rol

   Comparte el diagrama con RR. HH., los responsables que aparecen en él, los propietarios de sistemas y TI para que todos trabajen sobre la misma versión. Tras los próximos movimientos internos, recorre un caso real sobre el diagrama y comprueba si la mitad de la retirada se ejecutó de verdad. Mantener el mapa bajo control de versiones y con aprobaciones registradas es lo que hace que el proceso que la gente sigue y el que le enseñas a un revisor sean el mismo.

Preguntas frecuentes

¿Qué es el proceso de solicitud de accesos de empleados?

Es el camino que recorre un acceso cuando lo activa un evento laboral y no una petición puntual. RR. HH. registra que alguien se ha incorporado o ha cambiado de puesto, el perfil de acceso de ese puesto define los permisos, el responsable directo confirma que el rol es correcto, el propietario del sistema aprueba lo sensible, se ejecuta un control de segregación de funciones y TI provisiona y deja constancia. En un cambio de rol, además, se retiran los permisos del puesto anterior. Lo que lo distingue es el disparador: el proceso arranca en un registro de RR. HH., así que el acceso sigue al puesto y no a la bandeja de entrada.

¿Por qué quien cambia de puesto acaba con permisos de más?

Porque el cambio se gestiona como una suma. El responsable que recibe a la persona pide lo que necesita ahora, y en esa conversación nadie nombra los accesos que ya no le hacen falta. El responsable anterior ha pasado página, los propietarios de sistemas solo ven la petición nueva y los permisos antiguos no se revocan nunca. Repite eso dos o tres veces y un empleado veterano acumula accesos de varios puestos, lo que se suele llamar acumulación de privilegios. La solución es de procedimiento, no técnica: convierte la retirada en un paso con responsable y fecha, como hace la rama «Retirar antiguos» de esta plantilla, y registra las dos mitades contra el mismo movimiento.

¿Quién debe ser dueño de los accesos de altas y cambios, RR. HH. o TI?

RR. HH. es dueño del disparador y TI de la ejecución, y el proceso se rompe cuando se le pide a uno de los dos que haga ambas cosas. RR. HH. es la única función que sabe con fiabilidad que alguien se ha incorporado o ha cambiado de puesto, y su registro lleva la fecha de efecto de la que depende todo el calendario. TI tiene los derechos administrativos y es la única función capaz de provisionar o retirar. El criterio intermedio corresponde al responsable directo, que confirma el rol, y al propietario del sistema, que responde de su sistema. Mantener esas cuatro figuras en carriles distintos es también lo que impide que alguien solicite y se conceda a sí mismo un acceso.

¿Qué esperan las normas de control de accesos cuando alguien cambia de puesto?

El Anexo A de la ISO/IEC 27001:2022 incluye controles de control de accesos (A.5.15), gestión de identidades (A.5.16) y derechos de acceso (A.5.18); este último cubre la provisión, revisión, modificación y retirada de derechos y trata el cambio de puesto como un momento en el que hay que ajustarlos. El Anexo A cubre también las responsabilidades que subsisten cuando la relación laboral cambia o termina (A.6.5). Los criterios comunes de SOC 2 sobre acceso lógico mantienen la misma postura: el acceso se autoriza antes de emitir credenciales y se modifica o retira cuando cambia el rol. Ninguna norma fija un intervalo de revisión ni una herramienta concreta, y ninguna acepta un diagrama como evidencia: lo que se prueba son las aprobaciones, los registros de provisión y el registro de accesos que el proceso genera.