ISO 27001 para equipos técnicos: qué controles puedes automatizar y cuáles no

Guía honesta para CTOs e ingenieros: qué controles del Anexo A de ISO 27001 se pueden automatizar de verdad, cuáles siguen siendo trabajo humano, y cómo preparar evidencia continua para tu auditor.

K
Kevin Reyes
11 min de lectura

Eres CTO, Head of Engineering o responsable de seguridad. Tu empresa ha decidido certificarse en ISO 27001. Tienes un consultor que te está ayudando con el SGSI, pero llega el momento de la verdad: qué vas a tener que hacer tú y qué puedes delegar a herramientas.

La mayoría del contenido que encuentras online es o demasiado abstracto ("implementa una cultura de seguridad") o demasiado vendedor ("automatiza el 100% de tu ISO 27001"). Ninguna de las dos es útil cuando tienes un auditor interno contratado para dentro de 6 semanas.

En los últimos 12 meses hemos acompañado implantaciones reales y hemos visto docenas más por el lado de plataforma. La realidad es incómodamente simple:

Puedes automatizar de verdad aproximadamente el 70–75% de los controles del Anexo A.8 (técnicos). El resto — análisis de riesgos, SoA, políticas, formación, auditoría interna — sigue siendo trabajo humano. Sin excepciones, sin "IA que te lo hace todo".

Esta guía te da el mapa exacto: qué controles son automatizables, con qué tipo de herramienta, y cuáles tendrás que resolver a mano o con consultor. Cero humo.

Cómo está organizada ISO 27001:2022 y por qué importa para ti

ISO 27001:2022 tiene 93 controles en el Anexo A, organizados en 4 familias:

FamiliaQué cubreNº controles% automatizable
A.5 — OrganizacionalesPolíticas, roles, gestión de proveedores3710–15%
A.6 — PersonasContratación, formación, salida80–5%
A.7 — FísicosOficinas, almacenamiento físico140%
A.8 — TecnológicosSistemas, redes, software, datos3465–75%

Para ti, como técnico, el juego real está en A.8. Es donde se concentran los controles que una plataforma bien configurada puede evidenciar de forma continua. Y es también donde los auditores esperan ver madurez en 2026 — el mercado ha subido el listón respecto a 2017.

La trampa en la que cae casi todo el mundo

Antes de entrar al detalle: hay un error conceptual que vemos repetido en cada implantación, y te va a costar tiempo si no lo resuelves ahora.

ISO 27001 no se certifica en tu herramienta. Se certifica en tu SGSI (Sistema de Gestión de la Seguridad de la Información). Es decir: el auditor no audita que tengas Vulnerabbit, Vanta o cualquier otra cosa. Audita que hayas identificado tus riesgos, definido controles, y los estés ejecutando de forma demostrable.

La herramienta es evidencia. No es cumplimiento. La diferencia parece sutil y no lo es: un SGSI mal diseñado con una plataforma top = no conformidad. Un SGSI sólido con evidencia manual bien llevada = certificación pasada.

Por eso esta guía se llama "qué se puede automatizar" y no "cómo certificarte en 3 clics". El primero es cierto. El segundo es marketing.

Los controles técnicos del Anexo A.8 que SÍ puedes automatizar

Te los ordeno de mayor a menor viabilidad de automatización real — no por número de control.

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

Lo que pide la norma: identificar vulnerabilidades técnicas de forma oportuna, evaluar exposición y tomar medidas apropiadas.

Automatizable: ✅ 100%. Un escáner DAST (aplicaciones web) + SCA (dependencias) + SAST (código) genera hallazgos y evidencia continua. El auditor quiere ver: política de remediación por severidad + evidencia de escaneos periódicos + registro de hallazgos cerrados.

Lo que NO es automatizable: la decisión de priorización. "Tenemos 340 hallazgos medium, ¿cuáles se arreglan antes?" es una pregunta de negocio, no de herramienta.

Evidencia exportable útil:

  • Calendario de escaneos automáticos (idealmente semanal o por deploy)
  • Informe de hallazgos con CVSS + fecha de apertura/cierre
  • SLA de remediación documentado y evidencia de cumplimiento

A.8.9 — Gestión de la configuración

Lo que pide la norma: establecer, documentar e implementar configuraciones seguras.

Automatizable: ✅ 100% en cloud. Un CSPM (Cloud Security Posture Management) evalúa configuraciones AWS/GCP/Azure contra CIS Benchmarks, NIST 800-53 o marcos equivalentes. Produce evidencia continua, alertas en drift, y reporte de cobertura.

Lo que NO es automatizable: en infraestructura on-premise legacy, sigue siendo Ansible/Chef + checklist humano. No hay CSPM para un datacenter físico en 2026.

A.8.16 — Actividades de monitorización

Lo que pide la norma: monitorizar redes, sistemas y aplicaciones para detectar comportamiento anómalo.

Automatizable: ✅ 80%. SIEM + ASM (Attack Surface Management) cubre la parte externa. Logs centralizados cubren la parte interna. El auditor quiere ver: qué se monitoriza + quién recibe alertas + evidencia de casos abiertos.

Lo que NO es automatizable: la respuesta humana ante alertas. Automatizar la detección no te exime de tener un proceso de escalado y un equipo preparado para ejecutar.

A.5.7 — Inteligencia de amenazas

Lo que pide la norma: recopilar y analizar información sobre amenazas para generar inteligencia accionable.

Automatizable: ✅ 70%. Feeds de threat intel integrados en tu ASM/EDR + alertas sobre menciones de tu dominio en leaks. Herramientas tipo HaveIBeenPwned a nivel de dominio, feeds de OSINT integrados en plataforma.

Lo que NO es automatizable: la interpretación. "¿Este IOC aplica a nuestra empresa?" requiere contexto humano.

A.8.25 / A.8.26 / A.8.29 — Ciclo seguro de desarrollo

Lo que pide la norma: gestión segura del código, configuración de seguridad de aplicaciones, pruebas de seguridad.

Automatizable: ✅ 85%. SAST en el CI, SCA en pre-merge, DAST en staging, secret scanning. Evidencia exportable por cada pull request.

Lo que NO es automatizable: la revisión de arquitectura. Las decisiones de diseño seguro siguen siendo trabajo de humanos con criterio.

A.8.24 — Uso de criptografía

Lo que pide la norma: política de criptografía bien implementada.

Automatizable: ✅ 60%. CSPM verifica cifrado en reposo (S3, RDS, disks). Scanner TLS verifica cifrado en tránsito. Pero la política — qué algoritmos, qué rotación de claves, qué longitudes — es documento humano.

A.8.20 / A.8.21 / A.8.22 — Redes

Lo que pide la norma: seguridad de redes, servicios de red, segregación.

Automatizable: ✅ 70%. CSPM cubre configuración cloud (VPCs, security groups, NACLs). Scanner externo detecta puertos expuestos. Inventario de activos con clasificación queda en el medio — semi-automatizable con ASM.

A.8.12 — Prevención de fuga de datos

Lo que pide la norma: detectar y prevenir exfiltración.

Automatizable: ⚠️ 40%. DLP es complejo y propenso a falsos positivos. CSPM detecta buckets públicos (parte de lo importante). Herramientas específicas como Nightfall hacen el resto. No esperes una solución de un solo vendor.

A.8.23 — Filtrado web

Lo que pide la norma: restringir acceso a webs peligrosas.

Automatizable: ✅ 90%. SWG (Zscaler, Netskope) o simplemente DNS filtering a nivel red. Evidencia en logs.

A.8.15 — Registro de eventos

Lo que pide la norma: centralizar y proteger logs.

Automatizable: ✅ 95%. Cloud-native logging (CloudWatch, Stackdriver, Azure Monitor) + centralización. La parte que más se olvida: retención. La norma no pide un tiempo concreto, pero 1 año mínimo es la expectativa de auditor en 2026.

Tabla resumen: automatización por control

ControlNombreAutomatizaciónHerramienta típica
A.8.8Vulnerabilidades técnicas100%DAST + SCA + SAST
A.8.9Configuración100% (cloud)CSPM
A.8.15Registro de eventos95%Log aggregation + retention
A.8.23Filtrado web90%SWG / DNS filtering
A.8.25/26/29SDLC seguro85%CI/CD security gates
A.8.16Monitorización80%SIEM + ASM
A.5.7Inteligencia amenazas70%Threat feeds integrados
A.8.20/21/22Redes70%CSPM + escáner externo
A.8.24Criptografía60%TLS scanner + KMS inventory
A.8.12DLP40%DLP dedicado + CSPM

Los controles que NO son automatizables (y quién los hace)

Aquí está la parte honesta que muchos vendors no te dicen.

A.5 — Políticas y gobernanza (37 controles, 85% humano)

Política de seguridad, organización, roles y responsabilidades, relaciones con proveedores, gestión de incidentes, gestión de continuidad. Esto es redacción, revisión y firma. Tu consultor o tu CISO lo hace. Tu plataforma no.

Lo que la plataforma puede hacer: darte evidencia de que aplicas la política (ej: si la política dice "escaneo mensual", te enseña los escaneos). Pero la política la escribe un humano.

A.6 — Personas (8 controles, 100% humano)

Background checks, acuerdos de confidencialidad, formación en seguridad, gestión de salida. Todo trabajo de RRHH + seguridad. Automatizable a nivel logístico (tracker de formaciones completadas en un LMS) pero la decisión y la ejecución son humanas.

A.7 — Físicos (14 controles, 100% humano)

Zonas seguras, control de acceso físico, almacenamiento de activos. Tarjetas de acceso, cámaras, inventario físico. Nada automatizable desde una plataforma de seguridad cloud.

A.8 — lo que SÍ es humano dentro del técnico

Incluso en A.8, hay partes que no son automatizables:

  • A.8.1 — Gestión de activos: el inventario puede discoverarse (ASM ayuda), pero la clasificación ("¿este activo es crítico?") es decisión humana.
  • A.8.2 — Privilegios: IAM gestionado técnicamente, pero el principio de mínimo privilegio lo decide un humano con contexto.
  • A.8.3 — Gestión de acceso a información: controles técnicos sí, justificación de negocio de cada acceso no.
  • A.8.30 — Outsourcing de desarrollo: contractual, no técnico.

Los 4 bloques que sigues necesitando hacer a mano (o con consultor)

Independientemente de las herramientas que tengas, estos 4 entregables son humanos de principio a fin. Y son los que más retrasan las certificaciones cuando se subestiman.

1. Análisis de riesgos

Identificación de activos, amenazas, vulnerabilidades y valoración de probabilidad × impacto. Requiere conocimiento del negocio — no hay herramienta en el mercado que te dé un análisis de riesgos de tu empresa con un clic. Tiempo realista: 2–4 semanas con consultor, 4–8 sin él.

2. Declaración de Aplicabilidad (SoA)

Tabla con los 93 controles y decisión explícita de aplicabilidad + justificación. Derivada del análisis de riesgos. Tiempo: 1 semana con consultor.

3. Políticas y procedimientos

Mínimo requerido: política general de seguridad, política de clasificación de información, política de acceso, procedimiento de gestión de incidentes, procedimiento de gestión de cambios. Plantillas existen, pero adaptarlas a tu empresa es trabajo humano. Tiempo: 2–3 semanas.

4. Auditoría interna

Requisito obligatorio antes de la externa. La ejecuta un auditor cualificado distinto al implementador. No puedes ejecutarla tú si eres el responsable de la implementación. Coste típico en España: 2.000–4.000€.

Checklist para tu próxima reunión con el consultor

Para salir con deberes claros, lleva esta tabla rellena:

┌─────────────────────────────────────────┐
│ ¿TENGO YA?                              │
├─────────────────────────────────────────┤
│ ☐ DAST/SAST/SCA en CI/CD                │
│ ☐ CSPM activo en todas las clouds       │
│ ☐ Logging centralizado con >1 año ret.  │
│ ☐ ASM descubriendo superficie externa   │
│ ☐ Política de remediación por severidad │
│ ☐ SIEM o equivalente                    │
│ ☐ Inventario de activos actualizado     │
├─────────────────────────────────────────┤
│ ¿HE HECHO YA?                           │
├─────────────────────────────────────────┤
│ ☐ Análisis de riesgos formal            │
│ ☐ Declaración de Aplicabilidad          │
│ ☐ 5 políticas mínimas redactadas        │
│ ☐ Formación de empleados anual          │
│ ☐ Auditoría interna (contratada)        │
│ ☐ Plan de tratamiento de riesgos        │
└─────────────────────────────────────────┘

Si marcas todas las del primer bloque, tu capa técnica está cubierta. Si marcas todas las del segundo, estás listo para auditoría externa. Si solo tienes marcadas las del primero, ese es exactamente el trabajo que te queda — y es más del que la mayoría estima al empezar.

Expectativa realista de cronograma

Para una PYME/scaleup española partiendo de cero:

Semana 1-2:   Contratar consultor + diagnóstico inicial
Semana 3-6:   Análisis de riesgos + SoA
Semana 5-10:  Redacción de políticas (paralelo)
Semana 7-14:  Implementación de controles técnicos (si no están)
Semana 12-16: Formación + evidencia operativa
Semana 16:    Auditoría interna
Semana 18-20: Corrección de no conformidades
Semana 20-24: Auditoría externa (Fase 1 + Fase 2)
Semana 24-28: Remediación y emisión del certificado

Total: 6–7 meses para una primera certificación. Menos si ya tenías parte del stack técnico y políticas preexistentes. Si alguien te promete "certificación en 60 días desde cero", desconfía.


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.


¿Qué leer después?

Comprueba si tu dominio es vulnerable

Nuestro escáner gratuito analiza SSL, cabeceras de seguridad, DNS y configuración de email en menos de 5 minutos. Sin instalar nada.

Lanzar Auditoría Gratuita
Kevin Reyes

Escrito por

Kevin Reyes

Fundador & CEO de Vulnerabbit

Ingeniero DevSecOps con más de 7 años de experiencia en cloud security, CI/CD y automatización de infraestructura. Fundó Vulnerabbit con la misión de hacer la ciberseguridad sencilla, proactiva y accesible para startups y pymes.

LinkedIn
Escanea tu dominio gratis