Quién revisa y qué se revisa

Una campaña de certificación (también se le dice revisión de accesos o recertificación) pone delante de una persona, el revisor, una lista de accesos y le pide una decisión por cada uno: mantener o retirar. Lo importante no es la lista, es quién decide. Un revisor sirve si conoce para qué necesita el acceso quien lo tiene: normalmente su jefe directo, que sabe qué hace cada persona de su equipo, o el dueño de la aplicación, que sabe qué permisos tiene sentido dar.

Quien administra la aplicación sabe cómo se configura, no para qué lo usa cada persona. Y además es quien suele ejecutar los cambios: si decide y ejecuta, nadie más ha mirado.

La frecuencia de una campaña no se improvisa: la fija la política según cuánto daño podría hacer un acceso mal dado. A más criticidad, menos tiempo puede pasar sin revisar. La tabla politica_revision da los días y la tabla aplicaciones trae la fecha de la última certificación de cada una.

Para saber si una aplicación está vencida basta restar: días entre la última certificación y la fecha de la revisión (2026-10-01), comparados con el plazo que su criticidad permite. Hay una sola aplicación de criticidad alta que ya lo pasó.

Un hallazgo sin número se discute; con número se prioriza. Para la aplicación que acabas de encontrar, cuenta los días calendario entre su última certificación y el 2026-10-01 y resta el plazo de la política. El resultado es el retraso.

La tabla campanas dice, para cada campaña programada, qué aplicación cubre y quién será el revisor. Compara esa columna con lo que acabas de leer sobre quién debe decidir. Una de las campañas pone como revisor a quien administra la aplicación.

El alcance de una campaña es una lista de elementos: cada uno es un permiso concreto de una cuenta concreta. Al revisor se le pide una decisión por elemento, no una firma para todo el conjunto, y que esa decisión quede con su fecha y su nombre. Es lo que después se enseña como evidencia.