Controles técnicos ISO 27001 en AWS, GCP y Azure (Guía técnica 2026)

Si estás implementando ISO 27001 en una infraestructura cloud, la pregunta que no te responde bien el Anexo A es la más importante: qué configuración concreta de AWS / GCP / Azure satisface cada control.

La norma habla de "gestión técnica de vulnerabilidades", "configuración segura" y "monitorización". Tu auditor va a pedirte evidencia. Y entre ambos queda un abismo que nadie rellena: ¿qué servicio AWS exacto cubre A.8.8? ¿Qué log de GCP demuestra A.8.16? ¿Cómo se evidencia A.8.9 en Azure sin un Excel manual?

Esta guía mapea los controles técnicos de ISO 27001:2022 (Anexo A.8 principalmente) a configuraciones concretas en las tres clouds mayoritarias. Está pensada para el ingeniero o CTO que va a ejecutar la implementación — no para el consultor que va a redactar la declaración de aplicabilidad.

Si buscas el coste de certificarse, no este artículo: hay una guía aparte sobre precios de certificación ISO 27001 en España. Este post asume que ya has decidido y ahora toca implementar.

---

Qué es ISO 27001 (y por qué no es solo papeleo)

ISO 27001 es el estándar internacional para sistemas de gestión de seguridad de la información (SGSI). Define un marco para identificar riesgos, implementar controles de seguridad y mantener una mejora continua. La versión actual es ISO/IEC 27001:2022, que reorganizó los controles del Anexo A en cuatro categorías: organizativos, de personas, físicos y tecnológicos.

Lo que la mayoría de guías no te dicen es que ISO 27001 no prescribe herramientas ni tecnologías específicas. Te dice qué debes proteger, no cómo. Eso significa que la implementación depende completamente de tu stack tecnológico. Un control que en un data center tradicional requiere configurar firewalls físicos, en la nube se resuelve con Security Groups y NACLs.

Para una startup o PYME con infraestructura en la nube, esto es una ventaja enorme: muchos controles técnicos se cubren con funcionalidades nativas de AWS o GCP que ya tienes disponibles, herramientas open source que puedes integrar en tu CI/CD, y en algunos casos, soluciones comerciales que unifican la monitorización.

El problema real no es entender la norma. Es saber cuáles de los 34 controles tecnológicos ya cubres con lo que tienes y cuáles necesitan trabajo adicional.

---

Los controles de configuración cloud (A.8.1, A.8.5, A.8.9, A.8.10, A.8.15, A.8.20, A.8.24)

Este grupo de controles se centra en cómo configuras y mantienes tu infraestructura cloud. La buena noticia: la mayoría se pueden verificar con herramientas nativas de tu proveedor o con CSPM y controles ISO 27001 automatizados (Cloud Security Posture Management).

A.8.1 — Dispositivos endpoint del usuario

El control pide que los dispositivos que acceden a información de la organización estén protegidos. En cloud, esto se traduce a: ¿tus instancias EC2, VMs de GCP y contenedores tienen configuraciones de seguridad básicas? ¿Están parcheados? ¿Tienen agentes de monitorización?

Cómo implementarlo:

• AWS nativo: AWS Systems Manager Patch Manager para parches automáticos, Security Hub para verificar configuraciones baseline, Inspector para vulnerabilidades en instancias
• GCP nativo: OS Config para gestión de parches, Security Command Center para detectar configuraciones inseguras
• Open source: Prowler (auditoría AWS/GCP contra CIS Benchmarks), Lunar (auditoría de seguridad Linux)
• Comercial (CSPM): Cualquier herramienta CSPM verifica que las instancias cumplan la baseline: grupos de seguridad, cifrado de discos, puertos de gestión cerrados

A.8.5 — Autenticación segura

Esto cubre MFA, políticas de contraseñas y gestión de credenciales. Es probablemente el control con mayor impacto inmediato y más fácil de implementar.

Cómo implementarlo:

• AWS nativo: IAM Access Analyzer para detectar permisos excesivos, AWS Config rules (iam-user-mfa-enabled, access-keys-rotated) para verificar MFA y rotación de keys
• GCP nativo: Cloud Identity con verificación en dos pasos obligatoria, IAM Recommender para permisos least-privilege
• Open source: Prowler (checks específicos de IAM), ScoutSuite (auditoría multi-cloud), aws-iam-authenticator para Kubernetes
• Quick win: Revisa ahora mismo aws iam generate-credential-report — te muestra qué usuarios tienen MFA activado y cuándo se usaron sus access keys por última vez

A.8.9 — Gestión de configuración

Uno de los controles más relevantes para cloud. Exige que las configuraciones de hardware, software y redes se establezcan, documenten y mantengan. Traducción directa: ¿tus Security Groups están configurados según una baseline? ¿Tu CloudTrail está activado? ¿Tus buckets tienen la política de acceso correcta?

Cómo implementarlo:

• AWS nativo: AWS Config con Conformance Packs (incluye packs predefinidos para CIS y PCI DSS), CloudFormation Guard para validar templates antes del despliegue
• GCP nativo: Organization Policy Service para restricciones a nivel organización, Config Connector para GitOps
• Open source: Prowler y ScoutSuite para auditorías periódicas, Open Policy Agent (OPA) para políticas como código, Terraform Sentinel o tflint para validar IaC antes de aplicar
• Infraestructura como código: Si usas Terraform o Pulumi, las configuraciones ya están documentadas en tu repo. Añade checkov o tfsec en el CI para validar que cada cambio cumple la baseline

A.8.10 — Borrado de información

Los datos deben eliminarse de forma segura cuando ya no son necesarios. En cloud: ¿tus snapshots antiguos se eliminan? ¿Los buckets temporales se limpian? ¿Las bases de datos de desarrollo contienen datos reales de producción?

Cómo implementarlo:

• AWS nativo: S3 Lifecycle Rules para borrar objetos automáticamente, Data Lifecycle Manager para snapshots EBS, RDS automated backups con retención configurada
• GCP nativo: Object Lifecycle Management en Cloud Storage, scheduled snapshots con políticas de retención
• Open source: cloud-custodian (reglas declarativas para limpiar recursos huérfanos, snapshots viejos, volúmenes sin usar)
• Manual necesario: Decidir qué datos son "no necesarios" es una decisión de negocio. Las herramientas automatizan la ejecución, no la decisión

A.8.15 — Registro de actividades (logging)

Exige que las actividades de los usuarios, excepciones, fallos y eventos de seguridad se registren y protejan. En AWS esto es CloudTrail + CloudWatch. En GCP es Cloud Audit Logs.

Cómo implementarlo:

• AWS nativo: CloudTrail en todas las regiones (multi-region trail), logs a S3 con MFA Delete habilitado, CloudWatch Alarms para eventos críticos (root login, IAM changes)
• GCP nativo: Cloud Audit Logs habilitados para todos los servicios (Admin Activity logs son automáticos, Data Access logs requieren activación manual)
• Open source: ElasticSearch + Kibana (ELK) o Grafana Loki para centralizar logs, Falco para detección de anomalías en runtime de contenedores
• Verificación rápida: Ejecuta aws cloudtrail describe-trails y comprueba que IsMultiRegionTrail es true y LogFileValidationEnabled es true

A.8.20 — Seguridad en redes

Los controles de red deben proteger la información en sistemas y aplicaciones. En cloud: VPCs, subnets, NACLs, Security Groups, reglas de firewall.

Cómo implementarlo:

• AWS nativo: VPC Flow Logs para visibilidad de tráfico, Security Groups (stateful) + NACLs (stateless), AWS Network Firewall para inspección profunda
• GCP nativo: VPC Flow Logs, Firewall Rules con logging, Hierarchical Firewall Policies a nivel organización
• Open source: Prowler checks de Security Groups abiertos, nmap para verificar qué puertos son realmente accesibles, cartography (LinkedIn) para mapear relaciones entre recursos cloud
• Desde fuera: Herramientas ASM (Attack Surface Management) verifican qué puertos y servicios son accesibles desde internet. Esto complementa la vista interna: a veces un Security Group parece correcto pero una regla de Load Balancer expone el servicio igualmente

A.8.24 — Uso de criptografía

La información debe protegerse con cifrado según su clasificación. En cloud: cifrado en reposo para discos, bases de datos y backups. Cifrado en tránsito para todas las comunicaciones.

Cómo implementarlo:

• AWS nativo: KMS para gestión de claves, cifrado por defecto en S3 (SSE-S3 o SSE-KMS), EBS encryption, RDS encryption. Usa AWS Config rule encrypted-volumes y rds-storage-encrypted
• GCP nativo: Cloud KMS, Customer-Managed Encryption Keys (CMEK), cifrado por defecto en Cloud Storage y discos persistentes
• Open source: testssl.sh para verificar configuración TLS de tus endpoints, Mozilla SSL Configuration Generator para generar configs seguras de nginx/Apache
• Verificación rápida en tránsito: curl -I https://tudominio.com y revisa la versión TLS. Si ves TLS 1.0 o 1.1, tienes un problema. Mozilla Observatory (observatory.mozilla.org) te da un análisis gratuito

---

Los controles de desarrollo seguro (A.8.25, A.8.28)

Estos controles se cubren principalmente con tu pipeline CI/CD, no con herramientas de infraestructura. Si ya tienes un pipeline de CI/CD moderno, probablemente estés más cerca de lo que crees.

A.8.25 — Ciclo de vida del desarrollo seguro

El desarrollo de software debe seguir reglas de seguridad. Esto incluye revisión de código, pruebas de seguridad, gestión de dependencias y separación de entornos.

Cómo implementarlo con tu CI/CD:

• SAST (análisis estático): Semgrep (open source, reglas para OWASP Top 10), SonarQube Community Edition (gratis, soporta 30+ lenguajes), CodeQL (gratis para repos públicos en GitHub)
• Dependency scanning: Dependabot (nativo en GitHub), Renovate (open source), npm audit / pip-audit / bundle-audit en tu pipeline
• Secrets en código: GitLeaks o TruffleHog en pre-commit hooks para evitar que se comitan credentials, API keys o tokens
• Container scanning: Trivy (open source, escanea imágenes Docker, IaC, y dependencias), Grype + Syft de Anchore
• Separación de entornos: Cuentas AWS separadas para dev/staging/prod (AWS Organizations), proyectos separados en GCP
• DAST (análisis dinámico): OWASP ZAP (open source) integrado en CI para escanear la app en staging antes de promover a producción. Nuclei (ProjectDiscovery) para templates de vulnerabilidades conocidas
• Pentesting periódico: Un pentest manual anual o tras cambios significativos valida lo que las herramientas automatizadas no pueden: lógica de negocio, flujos de autorización complejos, cadenas de explotación

Ejemplo de pipeline mínimo para A.8.25:

1. Pre-commit: GitLeaks (secrets), Semgrep (SAST rápido)
2. CI build: npm audit / dependency check, Trivy (containers), SonarQube (SAST completo)
3. CI deploy to staging: OWASP ZAP baseline scan (DAST)
4. Manual gate: revisión de código por peer antes de merge a main
5. Post-deploy: escaneo de superficie expuesta para verificar que no se ha abierto nada nuevo

A.8.28 — Codificación segura

El código debe escribirse siguiendo principios de seguridad. Esto cubre OWASP Top 10, validación de input, gestión de sesiones, protección contra inyección.

Cómo implementarlo:

• Linting de seguridad: ESLint con eslint-plugin-security (Node.js), bandit (Python), gosec (Go), brakeman (Ruby on Rails)
• Frameworks seguros por defecto: React escapa XSS por defecto, Django tiene protección CSRF automática, Spring Security maneja autenticación. Usa los mecanismos del framework en lugar de implementar seguridad propia
• Headers de seguridad: Configura CSP, HSTS, X-Frame-Options en tu reverse proxy. helmet (Node.js), django-csp (Django), o directamente en nginx/Cloudflare
• Validación de input: zod o joi (Node.js), marshmallow (Python), Bean Validation (Java) — valida en el servidor siempre, no solo en el cliente
• DAST automático: OWASP ZAP o Nuclei detectan XSS reflejado, inyección SQL básica, cabeceras faltantes, cookies sin flags de seguridad
• Lo que requiere revisión manual: Inyección SQL en segundo orden, vulnerabilidades de deserialización, fallos de lógica de autorización (IDOR), condiciones de carrera. Esto requiere un pentester con experiencia o revisión manual de código enfocada

---

Los controles de visibilidad exterior (A.8.2, A.8.8, A.8.12, A.8.16, A.8.21)

Hay un subconjunto de controles que requieren saber qué ves desde fuera de tu red. No lo que configuras internamente, sino lo que un atacante puede descubrir sobre tu organización. Aquí es donde las herramientas internas tienen un punto ciego.

A.8.2 — Derechos de acceso privilegiado

Debe restringirse y controlarse el uso de acceso privilegiado.

Cómo implementarlo:

• AWS/GCP nativo: IAM Access Analyzer (AWS), IAM Recommender (GCP), políticas de least privilege, roles temporales con AWS STS o Workload Identity (GCP)
• Open source: Prowler para detectar usuarios con permisos excesivos, iamlive para generar políticas IAM mínimas a partir de uso real
• Vista exterior: Verifica que no tienes paneles de administración expuestos a internet: consolas de Jenkins, dashboards de Grafana, phpMyAdmin, interfaces de base de datos accesibles sin VPN. Un escaneo nmap de tus IPs públicas o una herramienta ASM automatizada detecta esto
• Quick win: Busca en Shodan o Censys tu dominio — muestra lo que cualquier atacante ya puede ver

A.8.8 — Gestión de vulnerabilidades técnicas

Este control exige que se obtenga información sobre vulnerabilidades técnicas, se evalúe la exposición y se tomen medidas.

Cómo implementarlo:

• Escaneo de infraestructura: AWS Inspector (nativo), Trivy para imágenes de contenedores, OpenVAS (open source, escaneo de red)
• Escaneo de aplicaciones web: OWASP ZAP, Nikto (open source), Nuclei con templates de CVEs
• Escaneo de dependencias: npm audit, pip-audit, Dependabot, Renovate — muchas vulnerabilidades críticas vienen por dependencias desactualizadas, no por tu código
• Escaneo externo: Herramientas ASM detectan servicios expuestos con CVEs conocidos. También puedes usar nmap con scripts NSE de detección de versiones
• Pentesting manual: Para cadenas de explotación complejas, vulnerabilidades lógicas, escalada de privilegios post-explotación. Un pentest externo anual es el complemento necesario
• Proceso de parcheo: El control no solo pide detectar vulnerabilidades, sino actuar. Define SLAs: críticas en 24-48h, altas en 1 semana, medias en 1 mes

A.8.12 — Prevención de fuga de datos

Deben aplicarse medidas para prevenir la divulgación no autorizada de información.

Cómo implementarlo:

• AWS nativo: S3 Block Public Access a nivel cuenta, Macie para detectar datos sensibles en S3, GuardDuty para detección de exfiltración
• GCP nativo: Organization Policy para bloquear acceso público en Cloud Storage, DLP API para detectar PII en datos almacenados
• Open source: s3scanner para encontrar buckets públicos, GitLeaks en CI para evitar que secrets lleguen al repo
• Vista exterior: Verifica desde fuera que no tienes buckets S3 o GCS públicos, repositorios de código accesibles, directorios abiertos con documentación interna, archivos de backup expuestos. Esto se puede hacer con herramientas ASM o manualmente con búsquedas en Google (site:s3.amazonaws.com tuempresa)

A.8.16 — Actividades de seguimiento (monitoring)

Las redes, sistemas y aplicaciones deben monitorizarse para detectar comportamientos anómalos.

Cómo implementarlo:

• AWS nativo: GuardDuty (detección de amenazas), CloudWatch Alarms, Security Hub para centralizar hallazgos
• GCP nativo: Security Command Center, Cloud Monitoring, Event Threat Detection
• Open source: Falco para runtime security en Kubernetes, Wazuh (SIEM open source), ElastAlert para alertas sobre logs
• Monitorización externa: ¿Apareció un nuevo subdominio? ¿Se abrió un puerto nuevo? ¿Cambió la configuración DNS? Herramientas ASM o simplemente un cron job con subfinder + nmap + diff detectan cambios en tu perímetro

A.8.21 — Seguridad de servicios de red

Los servicios de red deben identificarse y protegerse.

Cómo implementarlo:

• Inventario interno: AWS Config para listar todos los recursos con IP pública, GCP Asset Inventory
• Inventario externo: subfinder + httpx (ProjectDiscovery, open source) para descubrir todos tus subdominios y servicios accesibles, masscan para escaneo rápido de puertos
• Herramientas ASM: Mapean todos los servicios accesibles desde internet de forma continua: web servers, APIs, servicios SMTP, bases de datos, paneles de admin. Si un servicio de red existe y no lo sabías, no puedes protegerlo
• Quick win: Ejecuta subfinder -d tudominio.com | httpx -title -status-code -tech-detect y revisa si hay algo que no debería estar ahí

---

Los controles que requieren trabajo manual

Seamos honestos: no todo se automatiza. Algunos controles del Anexo A requieren decisiones humanas, procesos organizativos o criterio de negocio.

A.8.3 — Restricción de acceso a la información. Decidir quién accede a qué datos requiere entender el contexto de negocio. Puedes automatizar la revisión de permisos IAM con Access Analyzer o Prowler, pero la decisión de si un desarrollador debería tener acceso a la base de datos de producción es una decisión de negocio.

A.8.4 — Acceso al código fuente. Controlar quién puede leer y modificar el código fuente. Puedes auditar los permisos de GitHub/GitLab con github-audit o las APIs de administración, pero definir la política de acceso requiere criterio humano. Consejo práctico: usa CODEOWNERS para requerir review de los owners y branch protection rules para evitar push directo a main.

A.8.11 — Enmascaramiento de datos. Cuando los datos de producción se usan en entornos de desarrollo o pruebas, deben enmascararse. Herramientas como Faker (generación de datos sintéticos), AWS DMS con transformaciones, o scripts custom con reglas de anonimización. La parte manual: decidir qué campos son sensibles y qué nivel de enmascaramiento necesitan.

A.8.26 — Requisitos de seguridad de aplicaciones. Definir los requisitos de seguridad para cada aplicación antes de construirla. Esto es trabajo de arquitectura y diseño: threat modeling, clasificación de datos, definición de requisitos de autenticación y autorización. Herramientas como OWASP Threat Dragon (open source) ayudan a estructurar el proceso, pero el trabajo intelectual es humano.

---

Mapa completo: qué herramienta cubre qué control

Esta tabla resume los controles tecnológicos más relevantes para infraestructura cloud y qué tipo de herramienta los cubre:

Lo que esto muestra: Muchos controles se cubren con herramientas que probablemente ya tienes o puedes añadir gratis. Las herramientas nativas de AWS/GCP cubren lo básico. Open source y CI/CD cubren el desarrollo seguro. Las herramientas CSPM/ASM comerciales aportan valor cuando necesitas unificar la visibilidad, automatizar el compliance continuo, y generar evidencias para auditoría. Y el pentesting manual cubre lo que ninguna herramienta automatizada puede: lógica de negocio y cadenas de explotación complejas.

---

Cómo preparar una auditoría ISO 27001 con evidencias automatizadas

El mayor dolor de las auditorías ISO 27001 no es implementar los controles. Es demostrar que los tienes implementados. El auditor quiere evidencia: capturas, informes, registros de que los controles funcionan de forma continua, no solo el día de la auditoría.

Antes (enfoque manual): Dos semanas antes de la auditoría, el equipo de seguridad revisa manualmente cada recurso cloud, hace capturas de pantalla de las configuraciones, las pega en un documento Word con el control correspondiente, y reza para que nadie haya cambiado nada desde entonces.

Ahora (enfoque automatizado): Exportas informes que muestran el estado actual de cada control: qué recursos cumplen, cuáles no, desde cuándo, y qué acción correctiva se tomó. Estos informes pueden venir de:

• AWS Security Hub / GCP Security Command Center: Centraliza hallazgos de múltiples servicios con scoring de compliance
• Prowler: Genera informes contra CIS Benchmarks y mapea automáticamente a controles ISO 27001
• Tu CI/CD: Los logs de Semgrep, Trivy y ZAP en cada build son evidencia de A.8.25 y A.8.28
• Herramientas CSPM comerciales: Aportan dashboards de compliance con mapeo directo a controles ISO 27001, historial de cumplimiento, y exportación de evidencias en formato auditor-friendly

Para los controles que requieren pentesting, presentas el informe de la última prueba de penetración con los hallazgos, clasificación de riesgo y estado de remediación.

El resultado: en lugar de preparar auditorías reactivamente, mantienes un estado de compliance continuo que puedes demostrar en cualquier momento.

---

ISO 27001 en España: contexto regulatorio

Si tu empresa opera en España, ISO 27001 no existe en el vacío. Se solapa con otros marcos regulatorios que probablemente ya te aplican:

NIS2 (Directiva europea, transpuesta en España). NIS2 exige medidas técnicas y organizativas para gestionar riesgos de ciberseguridad. Muchas de estas medidas se mapean directamente a controles de ISO 27001. Si implementas ISO 27001, cubres una parte significativa de los requisitos de NIS2.

ENS (Esquema Nacional de Seguridad). Obligatorio para empresas que trabajan con la administración pública española. Tiene su propio catálogo de medidas de seguridad, pero hay un solapamiento sustancial con ISO 27001 en los controles técnicos.

GDPR / LOPDGDD — Artículo 32. ISO 27001 no es GDPR, pero implementar un SGSI robusto cubre muchos de los requisitos técnicos del Artículo 32 del GDPR (seguridad del tratamiento): cifrado, gestión de accesos, monitorización, pruebas periódicas.

DORA (para sector financiero/seguros). Si tu empresa está en el sector financiero o de seguros, DORA añade requisitos específicos de resiliencia digital que también se benefician de los controles técnicos de ISO 27001.

La ventaja de automatizar los controles técnicos es que la evidencia sirve para múltiples marcos. Un informe que demuestra cifrado en reposo cubre A.8.24 de ISO 27001, el artículo 32 de GDPR, y requisitos equivalentes en NIS2 y ENS.

---

Por dónde empezar

Si estás considerando ISO 27001 y tu infraestructura está en la nube, la secuencia práctica es:

1. Haz un inventario real de lo que tienes expuesto. Antes de implementar controles, necesitas saber qué tienes. Ejecuta subfinder -d tudominio.com | httpx para ver qué hay expuesto, o usa un escaneo ASM para automatizarlo. También revisa tus cuentas cloud con Prowler o ScoutSuite.

2. Evalúa el estado de tus configuraciones cloud. Ejecuta Prowler contra tus cuentas AWS (prowler aws --compliance iso27001_2022) o revisa Security Hub / Security Command Center. La mayoría de empresas se sorprenden al ver que ya cumplen un 40-60% simplemente por usar las configuraciones por defecto.

3. Añade seguridad a tu CI/CD. GitLeaks en pre-commit, Semgrep y dependency scanning en CI, OWASP ZAP en staging. Esto cubre A.8.25 y A.8.28 con mínimo esfuerzo. La mayoría de estas herramientas son gratuitas y se integran en 30 minutos.

4. Prioriza los gaps por riesgo real. No intentes arreglar todo a la vez. Los hallazgos críticos son los que tienen impacto alto y probabilidad de explotación alta: puertos de gestión abiertos, falta de MFA en cuentas privilegiadas, datos sin cifrar, dependencias con CVEs críticos.

5. Automatiza la monitorización continua. ISO 27001 no es un checklist que cumples una vez. Exige mejora continua. AWS Config rules, GuardDuty, y alertas en tu pipeline de CI detectan desviaciones en cuanto ocurren.

6. Valida con pentesting periódico. Los controles de configuración se verifican con automatización. Los controles de aplicación se verifican con pruebas activas. Un pentest anual (o después de cambios significativos) es el complemento necesario.

---

Cómo encaja Vulnerabbit aquí

La plataforma automatiza la evidencia continua de los controles técnicos: vulnerabilidades (A.8.8, A.8.25, A.8.29), configuración cloud (A.8.9), monitorización y atacantes externos (A.5.7, A.8.16). Es la capa que un auditor valora más en 2026 — evidencia continua, no un pentest del mes pasado.

El acompañamiento. Además del SaaS, aceptamos un número limitado de implantaciones puntuales al año cuando el encaje es bueno. Si necesitas apoyo en la ejecución — no sólo la herramienta — escríbenos.

Empieza por lo más rápido: lanza un análisis gratuito de tu superficie. En minutos te damos el primer mapa de controles técnicos con evidencia exportable.