Revisiones de accesos de usuarios que los auditores aceptan (con plantilla)

Una revisión de accesos de usuarios es una comprobación periódica de que cada cuenta de un sistema sigue perteneciendo a alguien que la necesita, con el nivel de privilegio que necesita. Es una de las evidencias de auditoría que más se solicitan — y una de las que más se rechazan, porque los equipos entregan una exportación de la lista de usuarios cuando el auditor pidió un registro de decisiones.

Esta distinción importa más que cualquier otro detalle de este artículo: una exportación muestra un estado; una revisión muestra criterio. Una hoja de cálculo con todo el mundo que tenía acceso en marzo solo demuestra que sabes consultar tus propios sistemas. Lo que el auditor está probando es si una persona concreta miró cada una de esas cuentas y decidió algo sobre ella.

Qué piden realmente los marcos

Las revisiones de accesos están en la intersección de dos requisitos de marcos distintos, y por eso aparecen en casi todas las auditorías:

• SOC 2 Common Criteria CC6 cubre el acceso lógico: cómo se registra, autoriza, modifica y elimina el acceso. Las revisiones son la forma de demostrar que la autorización sigue siendo correcta con el paso del tiempo, y no solo en el momento del alta. Consulta los Common Criteria explicados.
• ISO 27001 Anexo A.5.18 (derechos de acceso) cubre la concesión, la revisión y la retirada de los derechos de acceso. A.8.2 (derechos de acceso privilegiado) sube el listón específicamente para las cuentas administrativas, y A.5.15–A.5.17 cubren las prácticas de control de acceso, identidad y autenticación que las rodean. La guía completa del Anexo A explica cómo encajan entre sí.

Ninguno de los dos marcos prescribe una frecuencia. Lo que ambos esperan es que definas una, la justifiques frente al riesgo y luego la cumplas de verdad.

Paso 1: Define la población — es lo primero que se pone a prueba

Antes de mirar una sola decisión, el auditor comprobará si tu lista estaba completa. Este es el paso que los equipos se saltan, y es el paso que invalida todo lo que viene después: si la población es incorrecta, todas las decisiones tomadas sobre ella son imposibles de verificar.

Estar completa significa dos cosas. Primero, que revisaste todas las cuentas del sistema, no solo las que recordabas — incluidas las cuentas de servicio, las de contratistas, las compartidas y las de personas que ya se fueron. Segundo, que puedes mostrar de dónde salió la lista: una exportación generada por el sistema, con origen y marca de tiempo visibles, no una hoja de cálculo mantenida a mano.

Forma práctica de conseguirlo: exporta la lista de usuarios directamente desde cada sistema dentro del alcance, anota la fecha de la exportación y quién la hizo, y concilia el total con tu plantilla de RRHH y con tu inventario de activos y sistemas. Cualquier cuenta que aparezca en el sistema pero no en RRHH es o bien una cuenta de servicio que tienes que documentar, o un hallazgo que tienes que corregir.

Paso 2: Elige la frecuencia por riesgo, no por costumbre

La frecuencia debe seguir el radio de impacto del acceso. Un patrón defendible para un equipo pequeño:

• Acceso privilegiado y administrativo — trimestral. Infraestructura de producción, roles root y de administrador en la nube, administración de bases de datos, cualquier cosa que pueda conceder más acceso.
• Acceso estándar a sistemas con datos de clientes — semestral o anual, según lo sensibles que sean los datos y cuánto se mueva tu plantilla.
• Por eventos, además del calendario — una revisión disparada por un cambio de rol, una reorganización de equipo o una baja, en lugar de esperar al siguiente ciclo programado.

Escribe la frecuencia en tu política de control de acceso y luego cúmplela. Un auditor que compare una política que promete revisiones trimestrales con la evidencia de dos revisiones en un año levantará un hallazgo — y el hallazgo es por el compromiso incumplido, no por la frecuencia en sí. Una política que cumples de verdad es mejor que una ambiciosa que no cumples.

Paso 3: Asegúrate de que quien revisa no se está revisando a sí mismo

La independencia es el segundo motivo de rechazo más común. La persona que revisa una cuenta no debería ser la que la tiene, y a ser posible tampoco la que concede los accesos.

Para la mayoría de las empresas pequeñas el modelo viable es que el responsable del sistema o el manager del titular de la cuenta haga la revisión, y que otra persona — un fundador, el responsable de seguridad, quien lleve el SGSI — dé el visto bueno a la revisión en conjunto. Eso te deja dos nombres en el registro, que es exactamente lo que el auditor busca.

El caso incómodo es la startup de dos personas donde el CTO es dueño de todos los sistemas y tiene todas las credenciales de administrador. La respuesta honesta no es fingir lo contrario: haz que el otro fundador revise el acceso del CTO, documenta que la segregación está limitada por el tamaño del equipo y deja constancia de los controles compensatorios (registro de logs, alertas ante cambios de privilegios). Los auditores aceptan limitaciones documentadas y razonadas mucho antes que una separación ficticia.

Paso 4: Registra una decisión por cada cuenta

Esta es la parte que convierte una exportación en una revisión. Cada fila de la población necesita un resultado explícito — y «ninguna acción» es un resultado, siempre que lo haya elegido una persona.

Las dos últimas columnas son las que los equipos dejan vacías, y son las que los auditores revisan con más dureza.

Paso 5: Cierra el círculo — aprobado no es eliminado

Una revisión que identifica doce cuentas para revocar y no revoca ninguna es peor que no haber hecho la revisión: documenta que sabías que había un problema y no lo arreglaste. Los auditores toman muestras de las revocaciones de tu revisión y van a mirar en el sistema real para confirmar que la cuenta ya no está.

Así que el paquete de evidencia de cada ciclo necesita tres artefactos, no uno:

1. La exportación de la población, con su origen y su fecha.
2. El registro de revisión completado, con las decisiones por cuenta, los nombres de los revisores y las fechas.
3. La prueba de la remediación — tickets, registros de cambios o una exportación posterior que muestre que las cuentas revocadas ya no están.

Ese tercer artefacto es lo que convierte una revisión de afirmación en evidencia. Para ver cómo encaja en el panorama general de la evidencia, mira qué quieren realmente los auditores como evidencia.

Las revisiones detectan lo que se le escapó al offboarding

Ayuda tener claro qué trabajo hace la revisión. El offboarding es tu control preventivo: cuando alguien se va, su acceso se va con él, el mismo día. La revisión de accesos es el control detectivo que pilla los casos en los que el offboarding no se activó: el contratista cuyo encargo terminó sin hacer ruido, la herramienta SaaS que no estaba en la lista de offboarding, la cuenta de servicio creada para una migración que acabó hace un año.

Si tus revisiones de accesos sacan a la luz de forma sistemática a empleados que ya se fueron, el hallazgo no va realmente sobre la revisión. Va sobre el proceso de offboarding, y ahí es donde toca arreglarlo.

Los antipatrones

• Entregar la exportación como si fuera la revisión. Estado, no criterio. Es el rechazo más común que existe.
• Revisar solo los sistemas que son fáciles de exportar. Los auditores preguntan por los sistemas dentro del alcance, incluidos los incómodos.
• Aprobar en bloque todas las filas de un clic. Una revisión en la que se mantiene el 100 % de las cuentas en una empresa que crece invita al escrutinio — y si nunca cambia nada, quien revisa no está revisando.
• Olvidar las cuentas de servicio y las compartidas. Son las que más privilegios acumulan y menos propietario tienen.
• No dejar rastro de la remediación. La decisión sin el seguimiento es un hallazgo sin cerrar.

La conclusión

Las revisiones de accesos no son difíciles, pero son exigentes: una población completa salida de una exportación del sistema, alguien que revise sin tener ese acceso, una decisión explícita en cada cuenta y la prueba de que las revocaciones se hicieron de verdad. Haz eso cuatro veces al año con tus cuentas privilegiadas y la petición de evidencia deja de ser una carrera contrarreloj.

Siguiente: la checklist de monitorización durante todo el año para ver dónde encajan las revisiones en el calendario general, la recopilación de evidencias para SOC 2 para el resto de la lista de peticiones, o mira cómo la recolección automática de evidencias mantiene juntas la población y la prueba.