Guía de evidencias de auditoría de control de acceso para ISO 27001
Son las 09:10 del día de auditoría. María, Directora de Seguridad de la Información (CISO) de una fintech y plataforma en la nube en rápido crecimiento, tiene abierta su política de control de acceso. El responsable de TI está exportando la configuración de acceso condicional del proveedor de identidad. Recursos Humanos busca el ticket de baja de un analista financiero que dejó la organización hace seis semanas. El auditor interno levanta la vista y formula la pregunta que todos sabían que llegaría:
“Muéstreme cómo se solicita, aprueba, aplica, revisa y elimina el acceso de un usuario con privilegios sobre datos personales.”
Esa única frase puede revelar si un programa de control de acceso está preparado para una auditoría o solo está preparado sobre el papel.
El equipo de María contaba con un Sistema de Gestión de la Seguridad de la Información (SGSI) maduro, un ciclo anual de recertificación ISO/IEC 27001:2022, autenticación multifactor implantada, controles de acceso basados en roles en los sistemas esenciales y hojas de cálculo de revisiones trimestrales de acceso. Pero esta auditoría era distinta. La lista de solicitudes del auditor incluía preparación frente a requisitos regulatorios emergentes. Para la organización de María, eso significaba NIS2, DORA y GDPR, todos examinados bajo la misma perspectiva operativa: identidad, acceso, autenticación, privilegios y evidencias.
El problema al que se enfrentan muchos CISO no es que el control de acceso no exista. El problema es que las evidencias existen de forma fragmentada. Las aprobaciones de incorporación están en Jira o ServiceNow. La configuración de MFA está en Microsoft Entra ID, Okta u otro proveedor de identidad. Los permisos de AWS, Azure y Google Cloud residen en consolas separadas. Las acciones privilegiadas pueden quedar registradas en una herramienta PAM, o no registrarse en absoluto. El estado laboral está en BambooHR, Workday u hojas de cálculo. Las revisiones de acceso pueden aprobarse por correo electrónico.
Cuando un auditor relaciona IAM, MFA, PAM, eventos de altas, modificaciones y bajas, datos personales, administración en la nube y expectativas regulatorias, las evidencias fragmentadas se descomponen rápidamente.
Las auditorías de control de acceso ISO/IEC 27001:2022 no son solo revisiones técnicas de configuración. Son pruebas del sistema de gestión. Examinan si los riesgos de identidad y acceso se entienden, tratan, implantan, supervisan y mejoran. Cuando NIS2, DORA y GDPR también son relevantes, las mismas evidencias deben demostrar una gobernanza de accesos basada en riesgos, autenticación robusta, aprobaciones trazables, revocación oportuna, restricción de privilegios, protección de datos personales y rendición de cuentas demostrable por parte de la dirección.
La respuesta práctica no es un archivador más grande. Es un único modelo de evidencias de control de acceso que comienza con el alcance y el riesgo del SGSI, fluye a través de la política y el diseño de controles, aterriza en las herramientas de IAM y PAM, y se mapea con claridad frente a ISO/IEC 27001:2022, NIS2, DORA, GDPR, NIST y COBIT.
Por qué el control de acceso es el eje regulatorio
El control de acceso se ha convertido en un asunto del Consejo de Administración y de interés para los reguladores porque el compromiso de identidades es hoy una vía habitual hacia la interrupción operativa, las brechas de seguridad de los datos, el fraude y la exposición de la cadena de suministro.
Bajo NIS2, Articles 2 y 3, leídos junto con los anexos I y II, incorporan al ámbito de aplicación a muchas entidades medianas y grandes de los sectores enumerados como entidades esenciales o importantes. Esto incluye proveedores de infraestructura digital y de gestión de servicios TIC, como proveedores de servicios de computación en la nube, proveedores de servicios de centros de datos, proveedores de servicios gestionados y proveedores de servicios gestionados de seguridad. Los Estados miembros debían transponer NIS2 antes de octubre de 2024 y aplicar medidas nacionales desde octubre de 2024, con listas de entidades previstas para abril de 2025. Article 20 atribuye a los órganos de dirección la responsabilidad de aprobar las medidas de gestión de riesgos de ciberseguridad y supervisar su implantación. Article 21 exige medidas técnicas, operativas y organizativas, incluidas políticas de control de acceso, gestión de activos, higiene cibernética, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro y MFA o autenticación continua cuando proceda.
DORA añade una capa sectorial de resiliencia operativa para entidades financieras y proveedores terceros pertinentes de servicios TIC. Articles 1, 2 y 64 establecen DORA como un marco uniforme aplicable desde el 17 de enero de 2025. Articles 5 y 6 exigen gobernanza y un marco documentado de gestión del riesgo TIC. Article 9 aborda la protección y la prevención, incluidas políticas, procedimientos, protocolos y herramientas de seguridad TIC. Articles 24 a 30 añaden pruebas de resiliencia operativa digital y gestión del riesgo de terceros TIC. Para las entidades financieras, las evidencias de control de acceso se convierten en evidencias de resiliencia, no solo en evidencias de administración de TI.
GDPR aporta la perspectiva de los datos personales. Articles 2 y 3 definen una aplicabilidad amplia para el tratamiento en la UE y el alcance del mercado de la UE. Article 5 exige integridad, confidencialidad y responsabilidad proactiva demostrable. Article 25 exige protección de datos desde el diseño y por defecto. Article 32 exige medidas técnicas y organizativas apropiadas. En la práctica, esto implica acceso controlado, autenticación segura, registro de eventos, revisión y eliminación oportuna para los sistemas que tratan datos personales.
ISO/IEC 27001:2022 proporciona a las organizaciones el motor del sistema de gestión para unificar estas obligaciones. Las cláusulas 4.1 a 4.3 exigen que la organización comprenda el contexto, las partes interesadas, los requisitos legales y contractuales, las interfaces, las dependencias y el alcance del SGSI. Las cláusulas 6.1.1 a 6.1.3 exigen evaluación de riesgos de seguridad de la información, tratamiento, comparación con el Anexo A, una Declaración de Aplicabilidad y aprobación de los planes de tratamiento y del riesgo residual. La cláusula 8.1 exige control operacional, información documentada que demuestre que los procesos se ejecutaron según lo planificado, control de cambios y control de los procesos suministrados externamente.
Por tanto, la pregunta de auditoría no es “¿Tienen MFA?”. Es “¿Pueden demostrar, para las identidades y sistemas dentro del alcance, que el riesgo de acceso se gobierna, trata, implanta, supervisa y mejora?”.
Construir la columna vertebral de evidencias desde el alcance del SGSI hasta las pruebas de IAM
Clarysec inicia la preparación de la auditoría de control de acceso haciendo que las evidencias sean trazables desde el contexto de la organización. ISO/IEC 27001:2022 espera que el SGSI esté integrado en los procesos de la organización y dimensionado según sus necesidades. Un proveedor SaaS de 30 personas y un banco multinacional no tendrán la misma arquitectura de acceso, pero ambos necesitan una cadena de evidencias coherente.
| Capa de evidencias | Qué demuestra | Sistemas fuente habituales | Valor de cumplimiento cruzado |
|---|---|---|---|
| Alcance del SGSI y requisitos de las partes interesadas | Qué sistemas, datos, regulaciones y dependencias de terceros están dentro del alcance | Alcance del SGSI, registro de cumplimiento, inventario de datos, registro de proveedores | Respaldan ISO/IEC 27001:2022 cláusulas 4.2 y 4.3, delimitación del alcance NIS2, mapeo de dependencias TIC de DORA, responsabilidad proactiva de GDPR |
| Evaluación de riesgos de acceso | Por qué se necesitan IAM, MFA, PAM y revisiones en función del riesgo | Registro de riesgos, escenarios de amenaza, plan de tratamiento | Respalda ISO/IEC 27001:2022 cláusula 6.1, ISO/IEC 27005:2022, marco de riesgo TIC de DORA, medidas de riesgo de NIS2 |
| Políticas y normas | Qué exige la organización | Política de control de acceso, política de privilegios, política de incorporación y cese | Convierte las expectativas regulatorias en reglas internas exigibles |
| Configuración de IAM y PAM | Si los controles están implantados técnicamente | IdP, sistema de información de recursos humanos, ITSM, PAM, IAM en la nube, consolas de administración SaaS | Demuestra mínimo privilegio, MFA, RBAC, flujos de aprobación y controles de sesión privilegiada |
| Registros de revisión y supervisión | Si el acceso sigue siendo adecuado a lo largo del tiempo | Campañas de revisión de accesos, SIEM, registros de PAM, atestaciones de responsables | Demuestra operación continua de controles, supervisión DORA, higiene cibernética NIS2, minimización GDPR |
| Registros de baja y excepciones | Si el acceso se elimina y las excepciones se controlan | Lista de bajas de Recursos Humanos, registros de desactivación, registro de excepciones | Demuestra revocación oportuna, aceptación del riesgo residual y prevención de brechas de seguridad |
ISO/IEC 27005:2022 resulta útil porque recomienda consolidar requisitos legales, regulatorios, contractuales, sectoriales e internos en un contexto de riesgo común. Las cláusulas 6.4 y 6.5 destacan criterios de riesgo que consideran objetivos de la organización, leyes, relaciones con proveedores y restricciones. Las cláusulas 7.1 y 7.2 permiten escenarios basados en eventos y en activos. Para el control de acceso, esto implica evaluar escenarios estratégicos como “un administrador SaaS privilegiado exporta datos de clientes de la UE” junto con escenarios de activos como “una clave IAM huérfana de AWS asociada a almacenamiento de producción”.
En Zenith Blueprint: hoja de ruta de 30 pasos para auditores de Clarysec, esta columna vertebral de evidencias se construye durante la fase Controles en acción. El paso 19 se centra en controles tecnológicos para la gestión de endpoints y accesos, mientras que el paso 22 formaliza el ciclo de vida organizativo de los accesos.
Zenith Blueprint indica a los equipos que verifiquen que el aprovisionamiento y el desaprovisionamiento están estructurados, integrados con Recursos Humanos siempre que sea posible, respaldados por flujos de solicitud de acceso y revisados trimestralmente. También instruye a las organizaciones para documentar los tipos de identidad, aplicar controles para identidades individuales, compartidas y de servicio, aplicar políticas robustas de contraseñas y MFA, eliminar cuentas inactivas y mantener bóvedas seguras o documentación para credenciales de servicio.
Así es exactamente como los auditores prueban el control de acceso: una identidad, un sistema, una aprobación, un privilegio, una revisión y una revocación cada vez.
Qué recopilar para evidencias de control de acceso listas para auditoría
Su paquete de evidencias de control de acceso debe permitir que un auditor seleccione cualquier usuario y trace el ciclo de vida: solicitud, aprobación, asignación, autenticación, elevación de privilegios, supervisión, revisión y revocación.
Un paquete de evidencias sólido incluye:
- Política de control de acceso y política de cuentas de usuario
- Procedimiento de altas, modificaciones y bajas
- Matriz de roles o matriz de control de acceso
- Lista de aplicaciones, plataformas y repositorios de datos dentro del alcance
- Configuración de MFA del proveedor de identidad
- Políticas de acceso condicional y lista de excepciones
- Inventario de cuentas privilegiadas
- Evidencias de flujos de trabajo de PAM, incluidas aprobaciones y registros de sesión
- Resultado reciente de la campaña de revisión de accesos
- Muestras de atestaciones de responsables y acciones de remediación
- Informe de bajas de Recursos Humanos cotejado con registros de desactivación
- Inventario de cuentas de servicio, propietarios, registros de rotación y evidencias de bóveda
- Procedimiento de cuentas de emergencia y registro de prueba
- Evidencias de incidentes o alertas relacionadas con inicios de sesión fallidos, elevación de privilegios o cuentas inactivas
- Entradas de la Declaración de Aplicabilidad para controles del Anexo A relacionados con el acceso
Las políticas de Clarysec hacen explícita esta expectativa. En la Política de control de acceso para pymes, el requisito es sencillo y orientado a auditoría:
“Debe mantenerse un registro seguro de todo aprovisionamiento, modificación y eliminación de accesos.”
De la sección “Requisitos de implementación de la política”, cláusula 6.1.1.
La misma política para pymes también vincula RBAC y MFA directamente con las responsabilidades de los roles:
“Implanta controles de acceso basados en roles (RBAC) y aplica autenticación robusta (por ejemplo, autenticación multifactor (MFA)).”
De la sección “Funciones y responsabilidades”, cláusula 4.2.3.
Para organizaciones de mayor tamaño, la Política de incorporación y cese empresarial exige que el sistema IAM registre la creación de cuentas, las asignaciones de roles y permisos, y los eventos de desactivación, admita plantillas de control de acceso basado en roles e integre los sistemas de Recursos Humanos para desencadenantes de altas, modificaciones y bajas. Esa cláusula ayuda a contar la historia de auditoría en un único lugar: incorporación estandarizada, ciclo de vida de identidad activado por Recursos Humanos y eventos IAM trazables.
Mapear IAM, MFA, PAM y revisiones con los controles de ISO/IEC 27001:2022
Zenith Controls: la guía de cumplimiento cruzado de Clarysec trata el control de acceso como una familia de controles conectada, no como un elemento aislado de una lista de verificación. Para ISO/IEC 27001:2022, los controles más relevantes incluyen:
- Control 5.15, control de acceso
- Control 5.16, gestión de identidades
- Control 5.17, información de autenticación
- Control 5.18, derechos de acceso
- Control 8.2, derechos de acceso privilegiado
- Control 8.3, restricción de acceso a la información
- Control 8.5, autenticación segura
- Control 8.15, registro de eventos
- Control 8.16, actividades de supervisión
Para la información de autenticación, Zenith Controls mapea el control 5.17 como un control preventivo que respalda la confidencialidad, integridad y disponibilidad, con la capacidad operativa de gestión de identidades y accesos. Se vincula directamente con la gestión de identidades, la autenticación segura, las funciones y responsabilidades, el uso aceptable y el cumplimiento de las políticas. La seguridad de las credenciales incluye el ciclo de vida de los autenticadores, emisión segura, almacenamiento, restablecimiento, revocación, tokens de MFA, claves privadas y credenciales de servicio.
Para los derechos de acceso, Zenith Controls mapea el control 5.18 con la concesión, revisión, modificación y revocación formales. Se vincula con el control de acceso, la gestión de identidades, la segregación de funciones, los derechos de acceso privilegiado y la supervisión del cumplimiento. Este es el control que convierte el mínimo privilegio en evidencias.
Para los derechos de acceso privilegiado, Zenith Controls mapea el control 8.2 con el riesgo específico de las cuentas elevadas, incluidos administradores de dominio, usuarios root, administradores de tenants en la nube, superusuarios de bases de datos y controladores de CI/CD. La guía conecta el acceso privilegiado con la gestión de identidades, los derechos de acceso, la restricción de acceso a la información, la autenticación segura, el trabajo remoto, el registro de eventos y la supervisión.
| Tema de auditoría | Evidencias de acceso ISO/IEC 27001:2022 | Mapeo NIS2 | Mapeo DORA | Mapeo GDPR |
|---|---|---|---|---|
| Ciclo de vida IAM | Flujo de altas, modificaciones y bajas, solicitudes de acceso, aprobaciones, plantillas de roles, registros de desactivación | Medidas de gestión de riesgos de Article 21, políticas de control de acceso y gestión de activos | Articles 5, 6 y 9: gobernanza, marco de riesgo TIC, seguridad lógica y control de acceso | Articles 5, 25 y 32: responsabilidad proactiva, minimización y seguridad |
| MFA | Política del IdP, capturas de pantalla de acceso condicional, estadísticas de enrolamiento en MFA, aprobaciones de excepciones | Article 21(2)(j): MFA o autenticación continua cuando proceda | Acceso seguro a sistemas TIC críticos y controles de riesgo TIC | Medidas técnicas apropiadas frente al acceso no autorizado |
| PAM | Inventario de cuentas privilegiadas, aprobaciones, elevación JIT, registros de sesión, rotación de secretos en bóveda | Article 21(2)(i): control de acceso basado en riesgos y gestión de activos | Protección de sistemas TIC, resiliencia operativa y supervisión | Restricción y auditoría del acceso elevado a datos personales |
| Revisiones de acceso | Registros de revisión trimestrales o semestrales, atestaciones de responsables, tickets de remediación | Higiene cibernética, políticas de control de acceso y gestión de activos | Supervisión continua, acceso basado en roles y revocación | Protección de datos por defecto y responsabilidad proactiva demostrable |
| Baja | Lista de bajas de Recursos Humanos, evidencias de bloqueo o eliminación de cuentas, revocación de tokens | Eliminación oportuna de accesos innecesarios | Control del acceso TIC durante todo el ciclo de vida | Prevención del acceso no autorizado a datos personales |
Un único informe de revisión de accesos bien diseñado puede respaldar ISO/IEC 27001:2022, NIS2, DORA y GDPR si incluye alcance, propietario del sistema, revisor, lista de cuentas, justificación del rol, indicador de privilegio, decisiones, eliminaciones, excepciones y fecha de finalización.
Las evidencias de MFA son más que una captura de pantalla
Un error habitual en auditoría es presentar una captura de pantalla que indica “MFA habilitado”. Los auditores necesitan más que eso. Necesitan saber dónde se aplica MFA, quién está excluido, cómo se aprueban las excepciones, si las cuentas privilegiadas están cubiertas y si la configuración técnica coincide con la política.
Desde Zenith Blueprint, fase Controles en acción, paso 19, los auditores preguntarán cómo se aplican las políticas de contraseñas y MFA, qué sistemas están protegidos, a quién aplica MFA y si las aplicaciones críticas pueden probarse con una cuenta de muestra. Las evidencias pueden incluir configuración del IdP, políticas de acceso condicional, estadísticas de enrolamiento en MFA y procedimientos de restablecimiento de contraseñas.
Para entornos empresariales, la Política de gestión de cuentas de usuario y privilegios de Clarysec establece:
“Cuando sea técnicamente viable, la autenticación multifactor (MFA) es obligatoria para: 6.3.2.1 Cuentas administrativas y cuentas de nivel root 6.3.2.2 Acceso remoto (VPN, plataformas en la nube) 6.3.2.3 Acceso a datos sensibles o regulados”
De la sección “Requisitos de implementación de la política”, cláusula 6.3.2.
Esto crea un puente directo de auditoría. Si MFA es obligatoria para cuentas administrativas, acceso remoto y datos regulados, el paquete de evidencias debe incluir listas de cuentas administrativas y de nivel root, configuración de acceso remoto, políticas de acceso condicional de plataformas en la nube, listas de aplicaciones con datos sensibles, informes de enrolamiento en MFA, aprobaciones de excepciones, controles compensatorios y evidencias recientes de revisión de alertas por inicios de sesión fallidos o intentos de elusión de MFA.
Para NIST SP 800-53 Rev. 5, esto se alinea con IA-2 Identificación y autenticación, IA-5 Gestión de autenticadores, AC-17 Acceso remoto y AU-2 Registro de eventos. Para COBIT 2019, respalda DSS05.04 Gestionar la identidad de usuarios y el acceso lógico, así como las prácticas relacionadas de monitorización de seguridad.
Las normas ISO de apoyo amplían la perspectiva. ISO/IEC 27018:2020 extiende las expectativas de autenticación para la nube pública que maneja datos personales. ISO/IEC 24760-1:2019 respalda la vinculación de autenticadores y la gestión del ciclo de vida. ISO/IEC 29115:2013 introduce niveles de aseguramiento de autenticación, útiles para decidir dónde son necesarios tokens hardware o MFA resistente al phishing. ISO/IEC 27033-1:2015 respalda una autenticación de red robusta para acceso remoto o entre redes.
Las evidencias de PAM son la vía más rápida hacia un hallazgo mayor o una auditoría limpia
El acceso privilegiado es donde los auditores se vuelven escépticos, porque las cuentas privilegiadas pueden eludir controles, extraer datos, crear persistencia y alterar registros. En Zenith Blueprint, paso 19, se establece:
“En cualquier sistema de información, el acceso privilegiado es poder , y ese poder conlleva riesgo.”
La guía se centra en quién tiene acceso privilegiado, qué permite, cómo se gestiona y cómo se supervisa a lo largo del tiempo. Recomienda un inventario actualizado, mínimo privilegio, RBAC, elevación temporal o justo a tiempo, flujos de trabajo de aprobación, cuentas de usuario nominales, evitar credenciales compartidas, registro de cuentas de emergencia, sistemas PAM, rotación de credenciales, uso de bóvedas, grabación de sesiones, elevación temporal, supervisión y revisión periódica.
La Política de control de acceso empresarial de Clarysec lo convierte en un requisito de control:
“El acceso administrativo debe controlarse estrictamente mediante: 5.4.1.1 Cuentas privilegiadas separadas 5.4.1.2 Supervisión y grabación de sesiones 5.4.1.3 Autenticación multifactor 5.4.1.4 Elevación temporal o activada por flujo de trabajo”
De la sección “Requisitos de gobernanza”, cláusula 5.4.1.
Esta cita es casi un guion de prueba de auditoría. Si la política exige cuentas administrativas separadas, muestre la lista de cuentas privilegiadas y demuestre que cada una se asigna a una persona nominal. Si exige supervisión de sesiones, muestre sesiones grabadas o registros de PAM. Si exige MFA, muestre su aplicación en todas las rutas de acceso privilegiado. Si exige elevación limitada en el tiempo, muestre marcas temporales de caducidad y tickets de aprobación.
La versión para pymes es igual de directa. La Política de gestión de cuentas de usuario y privilegios para pymes establece:
“Los privilegios elevados o administrativos requieren aprobación adicional del Director General o del Responsable de TI y deben documentarse, estar limitados en el tiempo y estar sujetos a revisión periódica.”
De la sección “Requisitos de implementación de la política”, cláusula 6.2.2.
Para organizaciones más pequeñas, esta suele ser la diferencia entre “confiamos en nuestro administrador” y “controlamos el riesgo privilegiado”. El auditor no exige herramientas empresariales en todas las pymes, pero sí exige evidencias proporcionadas al riesgo. Un ticket, una aprobación, una asignación temporal a un grupo, la aplicación de MFA y un registro de revisión pueden ser suficientes cuando el alcance es limitado y el riesgo menor.
Las revisiones de acceso demuestran que el mínimo privilegio está funcionando
Las revisiones de acceso muestran si los permisos se acumulan silenciosamente. También muestran si los responsables comprenden el acceso que realmente tienen sus equipos.
La Política de gestión de cuentas de usuario y privilegios empresarial exige:
“Seguridad de TI, en colaboración con los responsables de departamento, debe realizar revisiones trimestrales de todas las cuentas de usuario y sus privilegios asociados.”
De la sección “Requisitos de implementación de la política”, cláusula 6.5.1.
Para pymes, la Política de gestión de cuentas de usuario y privilegios para pymes establece una cadencia proporcionada:
“Debe realizarse una revisión de todas las cuentas de usuario y privilegios cada seis meses.”
De la sección “Requisitos de implementación de la política”, cláusula 6.4.1.
Una revisión de accesos creíble incluye nombre del sistema, alcance, nombre del revisor, fecha de exportación, fecha de revisión, propietario de la identidad, departamento, superior jerárquico, estado laboral, rol o derecho, indicador de privilegio, indicador de sensibilidad de los datos, decisión, ticket de remediación, fecha de cierre, propietario de la excepción y fecha de caducidad de la excepción.
Para Zenith Controls, los derechos de acceso 5.18 son el punto en el que esto se convierte en evidencia de cumplimiento cruzado. La guía mapea los derechos de acceso con GDPR Article 25 porque el acceso debe estar limitado desde el diseño y por defecto. Los mapea con NIS2 Article 21(2)(i) porque las políticas de control de acceso y la gestión de activos requieren asignación basada en riesgos, eliminación oportuna de accesos innecesarios y revocación formal. Los mapea con DORA porque los sistemas TIC financieros necesitan acceso basado en roles, supervisión y procesos de revocación.
Los auditores orientados a NIST suelen probarlo mediante AC-2 Gestión de cuentas, AC-5 Separación de funciones y AC-6 Mínimo privilegio. Los auditores de COBIT 2019 revisan DSS05.04 Gestionar la identidad de usuarios y el acceso lógico y DSS06.03 Gestionar roles, responsabilidades, privilegios de acceso y niveles de autoridad. Los auditores de ISACA ITAF se centran en si las evidencias son suficientes, fiables y completas.
La baja y la revocación de tokens son fáciles de muestrear
Las bajas son uno de los puntos más sencillos para demostrar si el ciclo de vida funciona. Los auditores suelen seleccionar a un empleado cesado recientemente y solicitar el registro de baja de Recursos Humanos, el ticket, el registro de deshabilitación de la cuenta, evidencias de desactivación en SaaS, eliminación de VPN, revocación de MFA, eliminación de tokens de API y devolución de activos.
En la Política de incorporación y cese para pymes, Clarysec establece:
“Las cuentas dadas de baja deben bloquearse o eliminarse, y los tokens de acceso asociados deben revocarse, incluido el acceso remoto (VPN), las vinculaciones de aplicaciones MFA y los tokens de API.”
De la sección “Requisitos de implementación de la política”, cláusula 6.3.3.
Esto importa porque el acceso moderno no es solo un nombre de usuario y una contraseña. El acceso puede persistir mediante tokens de actualización, claves de API, claves SSH, concesiones OAuth, cuentas de servicio, derechos de administración local, sesiones móviles y portales de terceros. Un registro de Recursos Humanos desactivado sin revocación de tokens es una evidencia incompleta.
Zenith Blueprint, fase Controles en acción, paso 16, indica a las organizaciones que estén preparadas con una lista de verificación de cese documentada, evidencias de una baja reciente, un registro de deshabilitación de cuentas de usuario de AD o MDM, un formulario firmado de devolución de activos y documentación de baja que incluya obligaciones de confidencialidad.
El auditor de María solicitó el caso de un desarrollador sénior saliente que tenía acceso privilegiado a bases de datos de producción. Su equipo presentó la Política de incorporación y cese para pymes, la lista de verificación de cese construida a partir de Zenith Blueprint paso 16, el ticket ITSM activado por Recursos Humanos, el registro de deshabilitación del directorio, la revocación del certificado VPN, la eliminación de la organización GitHub, la eliminación de la clave IAM de AWS y el ticket de verificación cerrado firmado por el Responsable de TI. Las evidencias eran completas, oportunas y estaban directamente vinculadas a la política.
Ejecute un sprint de evidencias de tres muestras antes de que lo haga el auditor
Un ejercicio práctico de preparación consiste en elegir tres muestras antes de la auditoría:
- Un nuevo empleado incorporado en los últimos 90 días
- Un usuario privilegiado con acceso de administrador a la nube, base de datos, producción o IAM
- Un empleado dado de baja o con cambio de rol en los últimos 90 días
| Muestra | Evidencias que recopilar | Condición de aprobación | Hallazgo común |
|---|---|---|---|
| Nuevo empleado | Registro de alta de Recursos Humanos, solicitud de acceso, aprobación, asignación de roles, enrolamiento en MFA, primer inicio de sesión | Acceso concedido solo tras la aprobación y alineado con el rol | Acceso concedido antes de la aprobación o rol demasiado amplio |
| Usuario privilegiado | Justificación de negocio, cuenta administrativa separada, prueba de MFA, aprobación PAM, registro de sesión, revisión trimestral | El privilegio es nominal, está justificado, limitado en el tiempo cuando sea posible, supervisado y revisado | Cuenta administrativa compartida, ausencia de MFA, sin evidencia de sesión |
| Baja o cambio | Evento de Recursos Humanos, ticket de terminación o cambio de rol, registros de desactivación, eliminación de VPN, revocación de MFA o token de API, cierre de revisión | Acceso eliminado de forma rápida y completa | Cuenta SaaS aún activa, token de API no revocado, pertenencia antigua a grupo mantenida |
A continuación, conecte cada muestra con los registros del SGSI: escenario de riesgo, decisión de tratamiento, selección de controles en la Declaración de Aplicabilidad, cláusula de la política, configuración técnica, registro de revisión y acción correctiva si existe alguna brecha.
Esto convierte la preparación de auditoría de una recopilación de documentos en una verificación de controles.
Prepararse para distintas perspectivas de auditoría
Distintos perfiles de auditoría llevan a preguntas distintas, aunque las evidencias sean las mismas.
| Perspectiva del auditor | Foco principal | Evidencias esperadas |
|---|---|---|
| Auditor ISO/IEC 27001:2022 | Proceso del SGSI, tratamiento de riesgos y operación de controles | Evaluación de riesgos, SoA, políticas aprobadas, solicitudes de acceso, registros de revisión, registros de desactivación |
| Práctica de auditoría ISO/IEC 19011:2018 | Muestreo, corroboración y coherencia | Configuración de contraseñas, umbrales de bloqueo, marcas temporales de aprobación, registros de ejecución, entrevistas |
| Auditor de SGSI ISO/IEC 27007:2020 | Ejecución y eficacia de la auditoría del SGSI | Definiciones de roles comparadas con permisos reales, pistas de aprobación privilegiada, registros de revocación |
| Evaluador centrado en NIST | Implantación técnica y pruebas de controles | Evidencias AC-2, AC-5, AC-6, AC-17, IA-2, IA-5 y AU-2 de herramientas IAM, PAM y SIEM |
| Auditor COBIT 2019 o ISACA | Gobernanza, propiedad y fiabilidad de las evidencias | Evidencias de proceso DSS05.04 y DSS06.03, métricas, excepciones, seguimiento de remediación |
| Revisor DORA | Riesgo TIC, resiliencia y criticidad | Listas de acceso a sistemas críticos, supervisión de privilegios, controles de administradores terceros, enlaces con pruebas de resiliencia |
| Revisor NIS2 | Responsabilidad de la dirección y medidas de riesgo | Supervisión del Consejo de Administración, medidas de control de acceso de Article 21, cobertura de MFA, preparación para incidentes |
| Revisor GDPR | Confidencialidad y responsabilidad proactiva sobre datos personales | Restricciones de acceso a datos personales, evidencias de privacidad por defecto de Article 25, medidas de seguridad de Article 32 |
Preparar evidencias que satisfagan todas estas perspectivas demuestra un programa de cumplimiento maduro y reduce el trabajo duplicado.
Hallazgos comunes y acciones preventivas
Los hallazgos de control de acceso son previsibles. Las acciones preventivas también.
| Hallazgo | Por qué importa | Prevención |
|---|---|---|
| Existen revisiones de acceso, pero se excluyen las cuentas privilegiadas | Los derechos de administración generan el riesgo de mayor impacto | Incluir indicador de privilegio, registros de PAM y grupos de administración en cada revisión |
| MFA está habilitada para empleados, pero no para mesas de servicio, contratistas o administradores de nube | Los atacantes apuntan a las excepciones | Mantener informe de cobertura MFA y registro de excepciones con fechas de caducidad |
| El proceso de altas está documentado, pero los cambios no se gestionan | La acumulación de privilegios se incrementa tras los cambios de rol | Activar una revisión de acceso en cada cambio de departamento o rol |
| Existen cuentas administrativas compartidas sin controles compensatorios | La responsabilidad proactiva es débil | Sustituirlas por cuentas administrativas nominales o aplicar retirada desde bóveda y registro de sesiones |
| Las bajas se deshabilitan en el directorio, pero siguen activas en plataformas SaaS | El acceso persiste fuera del IdP principal | Mantener un inventario de aplicaciones y una lista de verificación de baja para cada sistema |
| Las contraseñas de cuentas de servicio son desconocidas o nunca se rotan | Las identidades no humanas se convierten en puertas traseras ocultas | Asignar propietarios, almacenar secretos en bóveda, rotar credenciales y revisar registros de uso |
| La política exige revisión trimestral, pero las evidencias muestran revisión anual | La política y la práctica divergen | Ajustar la cadencia en función del riesgo o aplicar el requisito documentado |
| Las aprobaciones de acceso están en correo electrónico sin regla de conservación | La pista de auditoría es frágil | Usar flujos ITSM y conservación alineada con la política |
La Política de control de acceso empresarial añade un requisito de conservación que evita uno de los fallos de evidencia más comunes:
“Las decisiones de aprobación deben registrarse y conservarse con fines de auditoría durante un mínimo de 2 años.”
De la sección “Requisitos de gobernanza”, cláusula 5.3.2.
Si las aprobaciones desaparecen tras la limpieza del correo electrónico, el control puede haber operado, pero la auditoría no puede basarse en él. La conservación forma parte del diseño del control.
La responsabilidad proactiva de la dirección necesita métricas de acceso
NIS2 Article 20 y DORA Articles 5 y 6 convierten el control de acceso en una preocupación de la dirección porque el compromiso de identidades puede derivar en interrupción operativa, notificación regulatoria, brecha de seguridad de los datos y daño al cliente. ISO/IEC 27001:2022 cláusulas 5.1 a 5.3 también exigen que la Alta Dirección alinee el SGSI con la estrategia de negocio, proporcione recursos, comunique la importancia, asigne responsabilidades y promueva la mejora continua.
Entre las métricas útiles de control de acceso se incluyen:
- Porcentaje de sistemas críticos cubiertos por SSO
- Porcentaje de cuentas privilegiadas con MFA
- Número de cuentas privilegiadas permanentes frente a cuentas JIT
- Tasa de finalización de revisiones de acceso
- Número de permisos excesivos revocados
- Cumplimiento del SLA de desactivación de bajas
- Número de cuentas inactivas
- Cobertura de propietarios de cuentas de servicio
- Cobertura de grabación de sesiones PAM
- Número y antigüedad de excepciones MFA
Estas métricas ayudan a la dirección a aprobar el tratamiento de riesgos y demostrar supervisión. También hacen que las auditorías sean más creíbles porque la organización puede demostrar que el control de acceso se supervisa como un riesgo vivo, no como algo que se redescubre antes de cada auditoría.
Convertir evidencias dispersas en confianza de auditoría
Si las evidencias de control de acceso ISO/IEC 27001:2022 están dispersas entre Recursos Humanos, ITSM, IAM, PAM, consolas en la nube y hojas de cálculo, el siguiente paso no es reescribir otra política. El siguiente paso es una arquitectura de evidencias.
Comience con esta secuencia:
- Defina los sistemas, identidades y datos dentro del alcance.
- Mapee NIS2, DORA, GDPR y los requisitos contractuales en el contexto del SGSI.
- Use escenarios de riesgo al estilo ISO/IEC 27005:2022 para priorizar IAM, MFA, PAM y revisiones de acceso.
- Actualice la Declaración de Aplicabilidad y el Plan de Tratamiento de Riesgos.
- Alinee las cláusulas de la política con los flujos de trabajo reales de IAM y PAM.
- Ejecute el sprint de evidencias de tres muestras.
- Corrija las brechas antes de que las encuentre el auditor.
- Mantenga un paquete de evidencias reutilizable para certificación, diligencia debida de clientes y revisiones regulatorias.
Clarysec puede ayudarle a implantarlo mediante Zenith Blueprint: hoja de ruta de 30 pasos para auditores, mapear requisitos de forma cruzada con Zenith Controls: la guía de cumplimiento cruzado y operacionalizar los requisitos con el conjunto adecuado de políticas de Clarysec, incluidas la Política de control de acceso, la Política de gestión de cuentas de usuario y privilegios y la Política de incorporación y cese.
La preparación para auditorías de control de acceso no consiste en demostrar que se compró una herramienta IAM. Consiste en demostrar que los procesos de identidad, autenticación, privilegios y revisión reducen riesgos reales para la organización y satisfacen las normas y regulaciones relevantes para su organización.
Descargue los kits de herramientas de Clarysec, ejecute el sprint de evidencias de tres muestras y convierta sus evidencias de control de acceso, hoy dispersas, en un expediente de auditoría claro, repetible y defendible.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
