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

¿Qué es diagrama del proceso de solicitud de accesos (alta y cambio de rol)?

Un proceso de solicitud de accesos de empleados concede permisos porque ha ocurrido un evento laboral, no porque alguien los haya pedido. RR. HH. confirma que una persona se ha incorporado o ha cambiado de puesto, el perfil de acceso asociado a ese puesto define qué debe poder hacer, el responsable directo confirma que el rol es el correcto, el propietario del sistema aprueba lo que sea sensible y TI lo provisiona. La unidad de la solicitud es un puesto y no un sistema, y eso es justo lo que mantiene el resultado revisable un año después: «esta persona tiene el perfil de analista financiero» es una afirmación que alguien puede comprobar; «pidió acceso a la base de datos en 2023» no lo es.

Este no es el proceso general de solicitud de acceso, en el que alguien que ya ocupa su puesto necesita un sistema más y abre la petición por su cuenta. Ese flujo, junto con la recertificación periódica de permisos, se cubre en la plantilla de proceso de solicitud de acceso, y es mejor punto de partida si estás diseñando un formulario para el servicio de soporte. Tampoco es la incorporación de empleados, que cubre el contrato, la verificación de antecedentes, el equipo y el primer día, ni la salida de empleados, que se ocupa de las bajas. Esta plantilla cubre lo que esas tres dejan en medio: la primera concesión de accesos a quien se incorpora y la reconstrucción de los accesos cuando alguien cambia de puesto internamente.

El movimiento interno es donde fallan en silencio casi todos los procesos de accesos. Un cambio de rol es un alta y una baja a la vez y, en la práctica, solo se ejecuta la mitad del alta. Se añaden los permisos nuevos, nadie enumera los antiguos y, después de dos o tres movimientos, un empleado veterano acumula accesos de puestos que dejó hace años. El proceso nunca avisa de un problema, porque nada se ha roto: la acumulación aparece más tarde, en una revisión de accesos o como hallazgo de auditoría. Por eso el diagrama de abajo parte la rama del cambio de rol en dos flechas etiquetadas, «Añadir nuevos» y «Retirar antiguos», y devuelve ambas a la misma entrada del registro de accesos, para que la retirada sea tan visible como la concesión.

Qué cubre este diagrama de flujo

En esta plantilla

• Cinco carriles con responsable asignado (Empleado, Responsable directo, RR. HH., Propietario del sistema y TI) repartidos en cinco fases: evento de ciclo de vida, perfil de rol, aprobación, provisión y confirmación.
• Un disparador en el carril de RR. HH. en lugar de un formulario de petición: el responsable directo confirma el puesto y la fecha de inicio, RR. HH. registra el evento de alta o cambio, y desde ahí la decisión «¿Alta o cambio de rol?» marca el camino.
• Una rama de cambio de rol que sale de «Listar los accesos del rol anterior» por dos flechas etiquetadas: «Añadir nuevos» continúa hacia el perfil de acceso, mientras que «Retirar antiguos» va directamente a TI para quitar los permisos del puesto anterior.
• Una decisión «¿El perfil cubre el puesto?» cuya rama «No» lleva al empleado a solicitar acceso extra con justificación por escrito antes de volver a la aprobación del responsable directo.
• Una decisión «¿Incluye un sistema sensible?» que deriva solo esas solicitudes al propietario del sistema, cuya rama «Denegado» termina en «Solicitud de acceso denegada»; el acceso ordinario del perfil pasa directamente al control de funciones.
• Un control «¿Conflicto de segregación de funciones?» en el carril de TI antes de provisionar, con una rama que ajusta el alcance o añade un control y vuelve a evaluar; después, la provisión del perfil, una única actualización del registro de accesos que recoge tanto la concesión como la retirada, la confirmación de lo cambiado y una comprobación del propio empleado en su nuevo rol.

Cuándo usar esta plantilla

• Estás escribiendo la parte de accesos de un procedimiento de altas, cambios y bajas y necesitas ver el alta y el cambio de rol en una sola página, en vez de en dos listas separadas
• Los movimientos internos dejan a las personas con permisos de puestos anteriores y necesitas mostrar dónde encaja el paso de retirada y quién lo ejecuta
• Estás configurando la provisión automática a partir de RR. HH., en la que un registro del sistema de personal lanza un flujo en la herramienta de identidades o de tickets, y quieres cerrar el proceso antes de programar la automatización
• Un auditor, un cuestionario de seguridad de un cliente o un revisor de certificación ha preguntado cómo se conceden los accesos al contratar y cómo se ajustan al cambiar de puesto
• La responsabilidad está repartida entre RR. HH., responsables directos, propietarios de sistemas y TI, y hoy nadie es dueño del cambio de rol de principio a fin

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.