La transición a ISO 27001:2022 llega a muchos CISO como un ejercicio de reetiquetado documental: mapear los controles antiguos a los nuevos, actualizar la Declaración de Aplicabilidad (SoA) y esperar a la auditoría de recertificación. El problema es que buena parte de los controles reorganizados —y casi todos los nuevos— describen capacidades técnicas que solo se pueden dar por implantadas si se comprueba que funcionan. Tener una política de gestión de configuración no significa que los sistemas estén bastionados, y un control documentado de prevención de fuga de datos no impide una exfiltración si nadie lo ha probado. Este artículo explica cómo cambia la estructura del Anexo A y qué controles conviene someter a validación técnica antes de sentarse frente al auditor.
Controles del Anexo A de ISO 27001:2022: qué cambia en la estructura
La revisión de 2022 reduce el catálogo de 114 controles (repartidos en 14 dominios en la edición de 2013) a 93 controles agrupados en solo cuatro categorías. No es una reducción real de alcance: 24 controles antiguos se fusionaron, 58 se mantienen prácticamente intactos y se incorporaron 11 controles nuevos. El cambio de fondo es organizativo y busca alinear el estándar con marcos como ISO 27002:2022, que ahora acompaña cada control con atributos (tipo de control, propiedades de seguridad, conceptos de ciberseguridad, capacidades operativas y dominios de seguridad).
Las cuatro categorías del nuevo Anexo A
- Controles organizativos (A.5, 37 controles): políticas, roles, gestión de proveedores, inteligencia de amenazas y uso de servicios en la nube.
- Controles de personas (A.6, 8 controles): concienciación, responsabilidades, teletrabajo y acuerdos de confidencialidad.
- Controles físicos (A.7, 14 controles): perímetro, mantenimiento de equipos y monitorización física.
- Controles tecnológicos (A.8, 34 controles): aquí se concentra el grueso de lo que un equipo ofensivo puede y debe verificar: gestión de accesos, criptografía, seguridad de red, desarrollo seguro y monitorización.
Los 11 controles nuevos
La mayoría de las novedades caen del lado técnico y son precisamente las que más difíciles resultan de evidenciar solo con documentación: inteligencia de amenazas (5.7), seguridad en el uso de servicios en la nube (5.23), preparación TIC para la continuidad de negocio (5.30), monitorización de seguridad física (7.4), gestión de configuración (8.9), eliminación de información (8.10), enmascaramiento de datos (8.11), prevención de fuga de datos (8.12), actividades de monitorización (8.16), filtrado web (8.23) y desarrollo seguro (8.28).
Qué controles tecnológicos conviene validar técnicamente
Un auditor de certificación revisa que exista el control y que se aplique de forma coherente. Pero el valor real para el CISO no es aprobar la auditoría, sino saber que el control resiste. Estos son los grupos del Anexo A donde una validación ofensiva marca la diferencia entre "documentado" y "eficaz".
Gestión de accesos e identidad (A.8.2, A.8.3, A.8.5)
Los controles de derechos de acceso privilegiado, restricción de acceso a la información y autenticación segura son candidatos naturales a pruebas técnicas. Un pentest verifica la escalada de privilegios, la existencia de cuentas huérfanas, MFA mal configurado o mecanismos de recuperación de contraseña débiles. Alineado con MITRE ATT&CK, se puede demostrar de forma reproducible si un atacante interno o un usuario comprometido logra saltar los límites definidos en la SoA.
Gestión de configuración y bastionado (A.8.9)
Este control nuevo exige definir, documentar e implantar configuraciones seguras. La validación técnica contra líneas base tipo CIS Benchmarks es lo que convierte una política en evidencia: servicios expuestos innecesariamente, cifrados obsoletos, permisos por defecto y hardening incompleto de servidores, contenedores y dispositivos de red.
Seguridad en redes y servicios en la nube (A.8.20, A.8.21, A.5.23)
Con la adopción masiva de infraestructura cloud, el control 5.23 y los de seguridad de red concentran mucho riesgo real: buckets mal configurados, grupos de seguridad demasiado permisivos, roles IAM con exceso de privilegios o segmentación de red inexistente. La revisión de configuración cloud complementa el pentest de perímetro y es difícilmente verificable sin acceso técnico a la plataforma.
Desarrollo seguro y aplicaciones (A.8.25, A.8.26, A.8.28)
El control 8.28 de codificación segura, junto con los requisitos de seguridad de aplicaciones, encaja directamente con una evaluación siguiendo OWASP (ASVS, Testing Guide). Inyecciones, control de acceso roto, deserialización insegura o exposición de datos sensibles son hallazgos que ninguna revisión documental detecta, pero que comprometen todo el SGSI.
Prevención de fuga de datos y monitorización (A.8.12, A.8.16, A.8.15)
Los controles de DLP, actividades de monitorización y registro (logging) se validan mejor mediante ejercicios que simulan exfiltración y comprueban si la detección responde. Un equipo ofensivo trabajando bajo un enfoque tipo Purple Team mide si los eventos generados durante un ataque llegan realmente al SIEM y disparan alertas, o si el control existe solo sobre el papel.
Del papel a la evidencia: cómo encaja en la auditoría
El error habitual es tratar la certificación y la validación técnica como procesos separados. En la práctica, un pentest bien orientado genera evidencia directa para la SoA: demuestra la eficacia de los controles del dominio A.8, aporta trazabilidad para el ciclo de mejora continua (cláusula 10) y alimenta la valoración de riesgos (cláusula 6.1) con datos reales en lugar de estimaciones. Cuando el auditor pregunta cómo se comprueba la eficacia de un control técnico, un informe de pentest firmado por auditores OSCP es la respuesta más sólida posible.
En CISEC abordamos este puente entre el requisito normativo y la comprobación técnica dentro de la auditoría ISO 27001, combinando la revisión del SGSI con pruebas ofensivas sobre los controles del Anexo A que lo requieren. Con metodología PTES y OWASP, y validación continua a través de nuestra plataforma ORDAL, el objetivo no es solo pasar la certificación, sino que los controles declarados aguanten un ataque real entre auditorías.
Preguntas frecuentes
¿Es obligatorio un pentest para certificarse en ISO 27001:2022?
La norma no exige explícitamente un pentest, pero sí demanda evaluar la eficacia de los controles (cláusula 9) y gestionar el riesgo técnico. Para los controles del dominio A.8, una prueba de intrusión es la forma más defendible de aportar esa evidencia ante el auditor.
¿Cuántos de los 93 controles se pueden validar técnicamente?
Los 34 controles tecnológicos (A.8) son el núcleo verificable, y varios organizativos y físicos —como 5.7, 5.23 o 7.4— también admiten comprobación práctica. En total, alrededor de un tercio del Anexo A se beneficia directamente de una evaluación ofensiva.
¿Cuándo conviene hacer la validación técnica respecto a la auditoría?
Lo idóneo es realizarla varias semanas antes de la auditoría de certificación o recertificación, con margen para remediar los hallazgos y documentar las acciones correctivas. Un modelo de pentesting continuo evita, además, que los controles se degraden entre ciclos anuales.