Una recertificación de accesos es una pregunta simple que casi ninguna organización se hace con regularidad: ¿esta persona todavía necesita este acceso? Se le pregunta a alguien que sabe la respuesta (normalmente el jefe directo o el dueño de la aplicación), esa persona confirma o rechaza, y lo rechazado se quita.

Dicho así parece trivial. En la práctica es uno de los procesos que más cuesta sostener, y uno de los que más diferencia hace en el estado real de los accesos de una organización. En mi trabajo diario armo, corro y corrijo campañas de recertificación, así que acá va lo que funciona y lo que no.

Por qué hace falta

Los accesos se acumulan. Se dan por una urgencia, por un proyecto, por un reemplazo durante unas vacaciones, y casi nunca se quitan. Con los años, la gente termina con muchos más permisos de los que necesita para su trabajo actual. Eso tiene dos consecuencias: una cuenta comprometida vale mucho más para un atacante, y nadie puede explicar por qué ese acceso existe.

Por eso la revisión periódica de accesos aparece en prácticamente todos los marcos: el control 5.18 de ISO 27001:2022 la pide explícitamente, NIST CSF 2.0 la contempla dentro de la gestión de identidades y accesos, y es de las primeras cosas que mira cualquier auditor.

Los tipos de revisión

No todas las recertificaciones son iguales. Las más comunes:

  • Por responsable: cada jefe revisa los accesos de su equipo. Sirve para detectar acumulación de permisos de gente que cambió de rol.
  • Por aplicación o recurso: el dueño de una aplicación revisa quién tiene acceso a ella. Sirve para aplicaciones críticas o con datos sensibles.
  • De accesos privilegiados: administradores, cuentas de servicio, grupos sensibles. Conviene que sean más frecuentes que el resto.
  • Por evento: se dispara cuando alguien cambia de puesto, en vez de esperar a la campaña periódica.

En la mayoría de los casos se combinan: una revisión por responsable más espaciada, revisiones por aplicación para lo crítico y revisiones más frecuentes de lo privilegiado.

El problema: aprobar todo en bloque

El fracaso más común de una recertificación no es técnico. Es que el revisor recibe una lista de cientos de ítems con nombres como GRP_APP_FIN_RW_02, no tiene idea de qué significa cada uno, tiene una fecha límite y aprueba todo para sacárselo de encima.

El resultado es una campaña "exitosa" con cero rechazos que no sirvió para nada, salvo para generar una evidencia que un auditor atento va a cuestionar.

Si nadie rechaza nada, el problema no es que los accesos estén perfectos. Es que la revisión no se está haciendo.

Cómo implementarla para que funcione

1. Partir de una fuente de verdad

Antes de revisar accesos hay que saber quién es quién. Una recertificación necesita saber quién es el jefe de cada persona y quién es el dueño de cada aplicación. Si eso no está en RR.HH. o en el directorio de forma confiable, la campaña le va a llegar a la persona equivocada.

2. Traducir los permisos a lenguaje de negocio

Este es el paso que más impacto tiene y el que más se saltea. Cada permiso que entra en una revisión debería tener una descripción entendible: no GRP_APP_FIN_RW_02 sino "Modificación de asientos contables en el sistema de finanzas". Si el revisor entiende lo que está aprobando, decide.

3. Acotar el alcance

Mejor empezar revisando las aplicaciones críticas y los accesos privilegiados que intentar revisar todo de una. Una primera campaña chica, bien hecha, enseña mucho más que una gigante que nadie completa.

4. Mostrar contexto

Ayuda mucho indicarle al revisor qué accesos son poco comunes para el puesto de esa persona, cuáles no se usan hace meses o cuáles se dieron por fuera del proceso normal. Con ese contexto la decisión es mucho más fácil.

5. Cerrar el ciclo: remediar y dejar evidencia

Un rechazo tiene que terminar en un acceso quitado, con fecha y registro. Si la remoción depende de que alguien abra un ticket a mano y otro lo procese cuando pueda, una parte de los rechazos se pierde en el camino. Lo ideal es que la quita sea automática o, como mínimo, que se haga seguimiento hasta confirmarla.

6. Medir y ajustar

Después de cada campaña vale la pena mirar: cuánto tardó cada revisor, qué porcentaje rechazó, qué se quitó efectivamente. Esos datos dicen dónde hace falta mejorar descripciones, dónde hay revisores que necesitan acompañamiento y qué aplicaciones conviene revisar más seguido.

¿Hace falta una herramienta?

Una primera revisión se puede hacer con planillas: exportar accesos, mandarlos a los responsables, juntar respuestas y quitar lo rechazado. Sirve para arrancar y para entender el problema. Pero no escala: consolidar respuestas, perseguir a los que no contestan y demostrar que lo rechazado se quitó se vuelve inmanejable rápido.

Ahí es donde entra una solución de gobierno de identidades (IGA), que conecta las fuentes, arma las campañas, manda recordatorios, ejecuta las quitas y guarda la evidencia. Pero la herramienta no resuelve lo de fondo: si los permisos no tienen descripción y no se sabe quién es dueño de qué, la herramienta va a automatizar una revisión que nadie entiende.

Una revisión que significa algo

Lo valioso de una recertificación no es el reporte que queda al final, sino la decisión que toma alguien que sabe. Cuando el proceso está bien armado, cada ciclo deja los accesos un poco más limpios que el anterior, y en algún momento la revisión deja de ser una carga y pasa a ser rutina.