El Anexo A de ISO 27001 en una empresa cloud-native: qué controles ya están hechos

La primera reacción ante ISO 27001:2022 en una empresa de veinte personas que corre sobre AWS es que los 93 controles del Anexo A describen otro tipo de organización: una con sala de servidores, lector de tarjetas y un registro documentado de visitas.

En parte es así. Pero una empresa cloud-native suele satisfacer más Anexo A del que cree, y el hueco se concentra en unos pocos sitios. Saber cuáles es la diferencia entre una certificación de tres meses y una de nueve.

Lo que el cloud ya te da, con evidencia

La revisión de 2022 reorganizó los antiguos 114 controles en cuatro temas: organizativos, de personas, físicos y tecnológicos. El tema físico es donde el cloud hace casi todo el trabajo.

Los controles 7.1 a 7.14 —perímetro físico, controles de entrada, seguridad de oficinas, ubicación de equipos, seguridad del cableado, eliminación segura— aplican al centro de datos. Si tu producción corre íntegramente en un hiperescalar, los heredas, y la evidencia es la certificación del propio proveedor. Descarga el certificado ISO 27001 y el informe SOC 2 de Artifact, del Service Trust Portal o del equivalente, deja registrado qué controles consideras heredados, y pon la vigencia de esos documentos en un calendario de revisión.

Sé preciso con la frontera, porque los auditores lo son. Heredas el centro de datos. No heredas tu oficina, ni tus portátiles, ni la destrucción del equipo del desarrollador que tenía una copia de la base de datos de producción en 2023. Los controles 7.7 (puesto despejado), 7.9 (equipos fuera de las instalaciones) y 7.10 (soportes de almacenamiento) siguen siendo tuyos.

Varios controles tecnológicos son también configuración que ya tienes: 8.13 copias de seguridad, 8.14 redundancia, 8.20 seguridad de redes, 8.21 seguridad de servicios de red, 8.22 segregación. La evidencia es código Terraform y una prueba de restauración, que además es mejor artefacto que un documento de política.

Los controles que sí requieren trabajo

En nuestra experiencia el hueco se concentra en una docena de sitios:

5.7 Inteligencia de amenazas es nueva en 2022 y pilla a mucha gente. No exige un producto de suscripción. Una rutina documentada —quién lee qué avisos de fabricantes y boletines de CCN-CERT o CISA, cómo uno relevante se convierte en un ticket, con unos meses de ejemplos— la satisface.

5.15, 5.16, 5.18 Control de acceso, identidad y derechos de acceso. Los controles son corrientes; lo que duele es la evidencia. Necesitas registros de altas, cambios y bajas y revisiones periódicas de acceso con un artefacto que muestre quién revisó qué y qué cambió. Una organización con un grafo de quién llega a qué lo tiene más fácil aquí que una con una hoja de cálculo.

5.23 Seguridad de la información para servicios en la nube es el control que nombra explícitamente tu situación: cómo se seleccionan los servicios cloud, cuál es el reparto de responsabilidad por servicio, y qué pasa a la salida. Casi ninguna empresa ha escrito nunca la parte de la salida.

5.30 Preparación TIC para la continuidad de negocio. Una restauración efectivamente realizada y cronometrada, con el resultado registrado. No una política de copias: una prueba.

8.8 Gestión de vulnerabilidades técnicas y 8.28 Codificación segura son donde el utillaje de escaneo se encuentra con la evidencia. Tener el escáner no es el control; el control es el proceso de triaje, los plazos por severidad y la prueba de que se cumplen.

8.16 Actividades de monitorización. Logs recogidos, retenidos y con alertas que alguien atiende. Es el control que más veces revela que las alertas van a un canal que nadie lee.

8.32 Gestión de cambios y 8.31 Separación de entornos. Normalmente ya se cumplen vía pull requests y cuentas separadas, pero nadie ha escrito que la aprobación de la pull request es el registro de control de cambios. Dilo explícitamente; ahorra una discusión.

La parte que no es Anexo A en absoluto

Las cláusulas 4 a 10 de la norma —el sistema de gestión en sí— son las que de verdad hacen fracasar auditorías. El Anexo A es un catálogo de controles del que seleccionas; las cláusulas son obligatorias.

Eso significa: alcance definido, una metodología de análisis de riesgos y un registro de riesgos real, una Declaración de Aplicabilidad, objetivos de seguridad con mediciones, auditoría interna y revisión por la dirección con acta. La auditoría interna y la revisión por la dirección son las dos que más se echan en falta, y ninguna se puede fabricar a posteriori: la entidad certificadora buscará registros fechados.

Una secuencia realista

Primero el alcance, estrecho y defendible. Después el análisis de riesgos, porque la Declaración de Aplicabilidad tiene que derivarse de él y no escribirse primero y justificarse después. Después cerrar la docena de huecos de control. Después operar el sistema tres meses para que haya evidencia de su funcionamiento: revisiones de acceso hechas, incidentes registrados, cambios aprobados. Después auditoría interna, después revisión por la dirección, después Fase 1.

Los tres meses de operación son el paso que la gente intenta saltarse y no puede. Un auditor mira una política escrita la semana pasada y ve que se escribió la semana pasada.

Las organizaciones a las que esto les resulta fácil son las que tratan el control como algo que hace la plataforma y la evidencia como algo que la plataforma emite. Si generas evidencia a mano, la generarás una vez, para la auditoría, y luego pararás, que es exactamente lo que la auditoría de seguimiento del año siguiente está diseñada para encontrar.