La Declaración de Aplicabilidad en ISO 27001 no es un anexo aburrido: es donde se decide si tu SGSI funciona o finge

Hay documentos que casi nadie quiere leer y que, aun así, deciden si una certificación ISO 27001 aguanta una auditoría o se desmorona en la segunda entrevista. La Declaración de Aplicabilidad, la famosa SoA, pertenece a esa categoría. Parece un inventario administrativo. No lo es. Es el lugar donde una organización deja por escrito qué controles del anexo A aplica, cuáles no, y por qué. Dicho sin maquillaje: ahí se ve si el SGSI responde a riesgos reales o si solo colecciona políticas bonitas en PDF.

La clave está en que ISO/IEC 27001 no pide controles por fe. Pide un proceso. La lógica arranca en la cláusula 6, que obliga a definir acciones para abordar riesgos y oportunidades, fijar objetivos y, sobre todo, ejecutar una evaluación y tratamiento del riesgo de seguridad de la información. Sigue en la cláusula 8, donde ese proceso debe operarse, mantenerse y conservar evidencia documentada. El anexo A entra después, no antes. Quien empieza por “vamos a marcar controles” suele terminar con una SoA incoherente, exclusiones mal defendidas y un auditor haciendo preguntas incómodas que, francamente, eran evitables.

Para CISOs y responsables de cumplimiento en Europa, este punto importa más en 2026 que hace tres años. No porque ISO 27001 haya cambiado cada trimestre, sino porque el entorno regulatorio ya no tolera SGSI teatrales. DORA exige a entidades financieras y proveedores TIC críticos una gestión del riesgo de las TIC integral y documentable; véanse, entre otros, los artículos 6 a 16 sobre marco de gestión de riesgos TIC y el artículo 28 sobre terceros TIC. NIS2, en su artículo 21, obliga a medidas técnicas, operativas y organizativas “adecuadas y proporcionadas”, incluyendo análisis de riesgos y seguridad de la cadena de suministro. GDPR no se queda atrás: el artículo 24 exige responsabilidad proactiva, el 25 privacidad desde el diseño y por defecto, el 32 seguridad del tratamiento, y los artículos 33 y 34 marcan la respuesta a brechas. La consecuencia práctica es bastante simple: si tu metodología de riesgos en ISO 27001 no conecta con esas obligaciones, el sello puede quedar bien en la web, pero sirve de poco cuando llega el supervisor o el incidente.

Este artículo no resume la norma. Eso ya lo hace cualquiera. Lo que sigue es el punto delicado: cómo se construye una evaluación de riesgos que resista auditoría, cómo se redacta una SoA que no parezca copiada de una plantilla y qué evidencias demuestran que el SGSI existe fuera de PowerPoint.

El error de base: tratar la gestión de riesgos como una ceremonia anual

La cláusula 6.1 de ISO/IEC 27001 es menos glamourosa que hablar de zero trust, pero bastante más útil. La organización debe planificar acciones para abordar riesgos y oportunidades, definir y aplicar un proceso de evaluación del riesgo de seguridad de la información, y establecer criterios de aceptación del riesgo. También debe aplicar un proceso de tratamiento del riesgo y producir una Declaración de Aplicabilidad que incluya los controles necesarios, su justificación de inclusión o exclusión y el estado de implementación.

Lo que muchas empresas hacen en la práctica es otra cosa: una workshop anual de dos horas, un Excel con “probabilidad por impacto”, tres colores y una lista de riesgos genéricos del tipo “phishing”, “caída del sistema” y “fuga de datos”. Luego alguien asigna niveles alto/medio/bajo, se vinculan controles de forma vaga y se archiva hasta el año siguiente. Eso puede servir para entretener un comité. No para certificar un SGSI maduro.

La norma, además, no impone una metodología concreta. Y aquí empieza la tentación. Como no prescribe un modelo único, cada organización rellena el hueco como puede: ISO 31000, OCTAVE, FAIR, matrices propias o combinaciones bastante imaginativas. Tener libertad metodológica está muy bien; usarla para fabricar arbitrariedad, no. Si dos riesgos con impacto comparable reciben tratamiento distinto porque un responsable “lo ve así”, tu criterio no está definido. Y si no está definido, el auditor lo detectará.

La pregunta útil no es si la metodología tiene cinco niveles o tres. La pregunta es si produce decisiones repetibles. Dos analistas distintos, con la misma información, deberían llegar a una conclusión razonablemente similar. Si no, no tienes un proceso: tienes una discusión eterna disfrazada de gobernanza.

En 2026, además, esa debilidad ya no es solo un problema de certificación. También afecta a la defensa regulatoria. Bajo DORA, por ejemplo, la entidad debe poder demostrar cómo identifica, clasifica y protege activos TIC críticos, cómo detecta anomalías, cómo responde y cómo aprende del incidente. Si la matriz de riesgos no conecta con activos, procesos críticos, dependencias de terceros y escenarios de interrupción, luego no hay manera limpia de justificar prioridades de inversión, umbrales de reporte ni decisiones de continuidad.

Qué exige de verdad la cláusula 6: criterios, consistencia y trazabilidad

La parte más subestimada de ISO 27001 no es el catálogo de controles. Son los criterios. La cláusula 6.1.2 obliga a definir criterios de riesgo, garantizar que las evaluaciones produzcan resultados consistentes, e identificar, analizar y evaluar los riesgos. Parece obvio. No lo es. La mayoría de incoherencias en auditoría nacen aquí.

Un criterio de riesgo serio debería responder, como mínimo, a seis preguntas operativas.

1. ¿Qué universo de activos y procesos entra en el análisis?

Si el alcance del SGSI cubre desarrollo, soporte, sistemas corporativos y tratamiento de datos de clientes, el inventario no puede limitarse a “servidores” y “aplicaciones”. Debe incluir información, procesos de negocio, dependencias humanas, proveedores relevantes, repositorios de código, sistemas de identidad, copias de seguridad y, muy importante, interfaces con terceros. En una fintech, por ejemplo, dejar fuera al proveedor de KYC o al procesador de pagos es una forma elegante de autoengañarse.

Esto conecta con GDPR art. 30 sobre registros de actividades de tratamiento y con DORA art. 8 y 9 sobre identificación y clasificación de funciones, activos y dependencias TIC. Si tus taxonomías no hablan entre sí, acabarás manteniendo tres inventarios distintos que se contradicen con admirable disciplina.

2. ¿Cómo se define impacto?

“Alto/medio/bajo” no basta. Impacto sobre qué. Confidencialidad, integridad y disponibilidad, sí, pero también impacto regulatorio, contractual, financiero, operativo y reputacional. No hace falta inventar modelos actuariales imposibles. Hace falta fijar umbrales entendibles.

Ejemplo operativo: para disponibilidad, “alto” puede significar interrupción superior a cuatro horas en un servicio clasificado como crítico; para integridad, modificación no autorizada en registros contables o transacciones; para confidencialidad, exposición de datos personales de categoría especial en el sentido del GDPR art. 9 o credenciales privilegiadas. Cuando estos criterios no existen, todo parece “alto” después de un incidente y “medio” cuando toca presupuestar controles. Curioso cómo funciona la percepción del riesgo cuando hay que firmar una orden de compra.

3. ¿Cómo se estima probabilidad o verosimilitud?

Muchas organizaciones asignan probabilidad sin mirar casi nada: ni historial de incidentes, ni exposición técnica, ni inteligencia de amenazas, ni madurez del control existente. En cambio, un proceso defendible combina al menos cuatro factores: atractivo del activo, exposición, capacidad del atacante o causa desencadenante, y eficacia del control actual.

Si una aplicación expuesta a Internet procesa datos de pago, depende de bibliotecas de terceros y tiene ciclo de parcheo de 45 días, su verosimilitud no puede equipararse a la de una wiki interna aislada con MFA, segmentación y parcheo semanal. Parece una obviedad, sí. Pues conviene escribirla. Lo que no se documenta, en ISO 27001 no existe a efectos de auditoría.

4. ¿Cuál es el umbral de aceptación del riesgo?

La cláusula 6.1.2 pide criterios para aceptar riesgos. Aquí abundan los documentos que dicen “la dirección decide”. Magnífico. ¿Con qué umbral? ¿Qué riesgos no puede aceptar un responsable de área y deben escalarse al comité? ¿Se aceptan riesgos altos con plan compensatorio? ¿Durante cuánto tiempo? Sin esa disciplina, la aceptación del riesgo se convierte en una amnistía administrativa.

Un esquema razonable suele distinguir entre: riesgo aceptable por control owner, riesgo que requiere validación del CISO, y riesgo que exige aprobación formal de dirección o comité. Si además hay impacto sobre protección de datos, debería intervenir DPO o función de privacidad cuando proceda, sobre todo si el escenario puede activar evaluación de impacto del GDPR art. 35.

5. ¿Qué opciones de tratamiento existen y cuándo se elige cada una?

ISO 27001 permite evitar, mitigar, compartir o aceptar riesgos. Lo básico. Lo útil es definir las condiciones de uso. Compartir mediante seguro ciber, por ejemplo, no elimina el riesgo operativo ni sustituye controles. Transferir a un proveedor cloud tampoco te descarga de responsabilidad; el GDPR art. 28 sobre encargados del tratamiento y DORA art. 28 sobre terceros TIC dejan esto bastante claro, cada uno en su terreno.

La organización debería poder explicar por qué eligió cifrado, segregación de funciones, MFA, hardening, formación, logging o cláusulas contractuales, y no otra medida. Si la respuesta es “porque está en el anexo A”, la lógica va al revés.

6. ¿Cómo se garantiza la consistencia del proceso?

La consistencia no nace de una política larga. Nace de guías, escalas definidas, ejemplos calibrados y revisiones de calidad. Los equipos que mejor ejecutan ISO 27001 suelen mantener un playbook interno con ejemplos de calificación, factores mínimos por tipología de activo, y criterios de escalado. No es literatura. Es ingeniería de decisiones.

La cláusula 8 es donde se separa la teoría del trabajo real

La cláusula 8 de ISO/IEC 27001 obliga a implementar y controlar los procesos necesarios para cumplir los requisitos del SGSI y llevar a cabo las acciones identificadas en la cláusula 6. También exige conservar evidencia documentada de que los procesos se han ejecutado según lo previsto. Esta parte suele sufrir un problema crónico: las organizaciones documentan muy bien lo que planean y bastante peor lo que realmente hacen.

Un auditor no se impresiona con una metodología impecable si no puede seguir el rastro hasta la operación diaria. Quiere ver, por ejemplo, que un riesgo identificado sobre cuentas privilegiadas desembocó en una decisión de tratamiento; que esa decisión se tradujo en implantación de PAM o, como mínimo, MFA reforzada, proceso JML y revisiones periódicas; y que hay registros que prueban su funcionamiento. Política, procedimiento, ticket de implementación, evidencia de configuración, revisión de accesos, incidencia detectada, corrección aplicada. Esa cadena es oro.

Lo mismo con vulnerabilidades. Si el riesgo registrado dice “exposición a explotación de software no parcheado en sistemas críticos”, la evidencia no puede ser una política genérica de gestión de parches de 2024. Necesitas inventario de activos, clasificación de criticidad, SLA de remediación, reportes de escaneo, excepciones aprobadas, ventanas de mantenimiento y prueba de cierre. NIS2 art. 21 menciona expresamente gestión de vulnerabilidades y políticas de higiene cibernética. No hace falta que ISO 27001 repita el discurso para que el auditor espere algo tangible.

La evidencia tampoco puede vivir en un silo documental separado de las herramientas reales. Si el SGSI dice que monitorizas eventos de seguridad, debería existir correlación entre la política, la arquitectura del SIEM, los casos de uso activos, la retención de logs y la revisión periódica. Si afirmas que haces revisiones de terceros, deberían aparecer due diligences, cláusulas contractuales, resultados de cuestionarios, findings y seguimiento. Si declaras cifrado de portátiles, el MDM o EDR debería poder demostrar el porcentaje de cumplimiento. En resumen: lo que la SoA marca como “implementado” tiene que poder enseñarse sin improvisar una búsqueda frenética en SharePoint cinco minutos antes de la auditoría.

La Declaración de Aplicabilidad: el documento más maltratado del SGSI

ISO/IEC 27001 exige, como resultado del tratamiento del riesgo, una Declaración de Aplicabilidad que contenga los controles necesarios, la justificación de inclusión, la justificación de exclusión de controles del anexo A y el estado de implementación. Esa definición, aparentemente administrativa, encierra varias trampas.

La primera: la SoA no es un checklist de auditor. Es una decisión de diseño del sistema de control. La segunda: excluir un control no es pecado, pero hay que saber defenderlo. La tercera: la SoA no puede ser estática si cambia el riesgo, el negocio o la arquitectura.

Con la edición actual de ISO/IEC 27001, el anexo A contiene 93 controles organizados en cuatro bloques: organizativos, de personas, físicos y tecnológicos. Ese rediseño heredado de ISO/IEC 27002:2022 obligó a muchas entidades a mapear controles antiguos a nuevos y, de paso, dejó al descubierto SoA hechas con cierta pereza. Si tu documento todavía arrastra nomenclaturas antiguas sin un mapeo claro o descripciones vagas del tipo “aplica parcialmente”, estás invitando a que el auditor pregunte “parcialmente cómo, exactamente”.

Una SoA útil, no solo certificable, debería incluir al menos: identificador y nombre del control, aplicabilidad, justificación de inclusión o exclusión, referencia al riesgo o riesgos que cubre, propietario del control, estado de implementación, evidencia primaria, controles relacionados y observaciones sobre excepciones o limitaciones. Sí, es más trabajo. También evita horas de discusión durante la auditoría.

Veamos dónde fallan más a menudo.

Exclusiones mal argumentadas

Decir que un control “no aplica por la naturaleza del negocio” sirve de poco si no explicas esa naturaleza. Si excluyes controles físicos porque operas en cloud, el argumento es débil: sigues teniendo oficinas, puestos, dispositivos, medios removibles, visitantes o trabajo híbrido. Si excluyes controles sobre desarrollo seguro porque “no desarrollamos software”, cuidado: quizá no desarrolles producto propio, pero sí scripts, automatizaciones, integraciones o infraestructura como código. Hoy casi todas las empresas “no tecnológicas” desarrollan algo, aunque sea a escondidas y con GitHub privado.

La exclusión aceptable es concreta y verificable. Por ejemplo: un control sobre medios de almacenamiento puede no aplicar en una arquitectura completamente virtualizada con política corporativa que prohíbe soportes extraíbles, enforcement técnico por endpoint management y excepción cero registrada en 12 meses. Ahí hay argumento, no literatura.

Inclusiones sin rastro al riesgo

Otro clásico: incluir casi todos los controles del anexo A “por prudencia”, pero sin enlazar a riesgos, obligaciones legales o decisiones de negocio. Eso convierte la SoA en una lista ceremonial. Si un control aparece como aplicable, deberías poder responder al menos a una de estas preguntas: ¿qué riesgo reduce?, ¿qué requisito legal, contractual o del cliente cubre?, ¿qué decisión arquitectónica lo hace necesario?

Este punto es particularmente sensible en organizaciones sujetas a múltiples marcos. Si aplicas controles de logging, integridad y retención por exigencias internas, perfecto. Pero si además esos controles sirven para soportar detección y reporte de incidentes bajo DORA, NIS2 o GDPR art. 33, conviene reflejarlo. No para presumir de compliance integrado, sino para evitar duplicidades y contradicciones.

Estados de implementación irreales

“Implementado” no significa “existe una herramienta comprada”. Tampoco “hay un proyecto en marcha”. Si la organización está desplegando DLP en 40% de endpoints, el estado no es implementado completo. Si MFA cubre usuarios de negocio pero no cuentas de servicio ni accesos privilegiados, dilo. La sinceridad controlada duele menos que una no conformidad mayor.

Una práctica madura es usar estados claros: no implementado, en diseño, parcialmente implementado, implementado, implementado con excepciones, retirado. Lo relevante no es la taxonomía; es que esté definida y se use de forma consistente.

Cómo conectar riesgos, SoA y obligaciones regulatorias sin convertir el SGSI en un monstruo burocrático

El gran reto para un CISO europeo no es cumplir ISO 27001 en abstracto. Es evitar cuatro sistemas paralelos: uno para la certificación, otro para DORA o NIS2, otro para privacidad y otro para auditoría interna. Ese enfoque multiplica documentos y reduce control real. La alternativa inteligente es usar la gestión de riesgos del SGSI como columna vertebral y mapear desde ahí los requisitos regulatorios.

Tomemos tres ejemplos habituales.

Acceso privilegiado

Riesgo: uso indebido o compromiso de cuentas privilegiadas en sistemas críticos. Tratamiento: MFA resistente al phishing donde sea viable, PAM o controles equivalentes, segregación de funciones, revisión trimestral de privilegios, logs reforzados, vault de credenciales y proceso de altas/bajas/cambios. SoA: controles de control de acceso, autenticación, gestión de identidades, registro y monitorización. Cruce regulatorio: GDPR art. 32 por seguridad apropiada, NIS2 art. 21 por control de acceso y gestión de incidentes, DORA arts. 6-15 por protección y detección en el marco de riesgo TIC.

Si este diseño está bien hecho, no necesitas tres narrativas distintas. Necesitas una sola arquitectura de control, varias referencias normativas y evidencias comunes.

Terceros TIC y cadena de suministro

Riesgo: dependencia crítica de proveedor SaaS o cloud sin due diligence, cláusulas de seguridad insuficientes o capacidad limitada de supervisión. Tratamiento: evaluación previa, clasificación por criticidad, requisitos contractuales, derecho de auditoría o evidencia equivalente, revisión de certificaciones, continuidad, salida ordenada, seguimiento de subencargados si hay datos personales, y revisión periódica. SoA: relaciones con proveedores, seguridad en servicios de terceros, continuidad, requisitos legales y contractuales. Cruce regulatorio: DORA art. 28 y siguientes sobre terceros TIC, NIS2 art. 21.2(d) sobre seguridad de la cadena de suministro, GDPR art. 28 sobre encargados y art. 32 por medidas de seguridad.

Aquí aparece una ironía frecuente: muchas organizaciones evalúan a sus proveedores con más detalle para la certificación que para una renovación contractual real. Luego se sorprenden cuando el incidente viene por un tercero del que solo conservan una hoja Excel y un certificado SOC 2 caducado.

Detección y respuesta a incidentes

Riesgo: incapacidad de detectar y contener accesos no autorizados o disrupciones antes de que escalen. Tratamiento: centralización de logs, casos de uso prioritarios, playbooks, clasificación de incidentes, retención, cadena de custodia, simulacros y post-mortems. SoA: logging, monitorización, gestión de incidentes, continuidad, copias de seguridad. Cruce regulatorio: GDPR arts. 33 y 34 para brechas de datos personales, NIS2 art. 23 sobre notificación de incidentes significativos, DORA arts. 17 a 23 sobre gestión, clasificación y notificación de incidentes TIC.

Cuando el SGSI está bien integrado, la discusión deja de ser “qué pide cada norma” y pasa a ser “qué evidencia común sostiene varias obligaciones”. Eso ahorra tiempo, sí, pero sobre todo mejora coherencia. Y la coherencia, a efectos de supervisión, vale más que un repositorio infinito de políticas desconectadas.

Qué evidencias convencen en certificación y cuáles huelen a cartón piedra

ISO 27001 no certifica intención. Certifica un sistema en funcionamiento. Eso obliga a pensar la evidencia como un flujo, no como un archivo. Los auditores suelen buscar cuatro cosas: decisión, implementación, operación y revisión. Si una de las cuatro falla, el control se tambalea.

La evidencia sólida suele combinar documentación marco y rastro operativo. Por ejemplo:

• Metodología de evaluación de riesgos aprobada, con criterios, escalas, umbrales y responsables.
• Registro de riesgos vigente, con fechas, propietarios, tratamiento, estado y aceptación formal cuando proceda.
• Actas o minutas de comité donde se revisan riesgos altos, excepciones y avances.
• SoA actualizada, versionada y alineada con el alcance real del SGSI.
• Procedimientos operativos vinculados a controles concretos del anexo A.
• Pruebas de funcionamiento: extractos de SIEM, revisiones de acceso, resultados de escaneos, tickets de remediación, pruebas de backup y restauración, ejercicios de respuesta a incidentes, revisiones de proveedores.
• Auditoría interna y revisión por la dirección, que en ISO 27001 no son adornos sino piezas obligatorias del ciclo de mejora.

La evidencia débil suele tener otra pinta: políticas sin revisar desde hace dos años, documentos aprobados sin dueño claro, capturas de pantalla sin contexto, informes exportados una vez para el auditor y jamás usados por operación, o matrices de riesgos donde la mitad de los riesgos siguen “abiertos” desde 2025 sin explicación. Eso no siempre genera una no conformidad mayor, pero sí erosiona confianza. Y la confianza del auditor, una vez perdida, cuesta recuperarla.

Checklist de evidencias para auditoría

Esta es una de las pocas listas que sí merece existir, porque el tema es auditable y documental por definición. Si tu organización prepara o mantiene la certificación, estas evidencias deberían estar localizadas, actualizadas y vinculadas a un responsable concreto.

Implicaciones para entidades financieras españolas

Para banca, seguros, EDE, EFC, gestoras y buena parte del ecosistema fintech en España, ISO 27001 sigue siendo una referencia útil en 2026, pero ya no puede vivir separada del resto del marco regulatorio. DORA es aplicable desde el 17 de enero de 2025 y, a estas alturas, la discusión ya no es si conviene prepararse, sino cómo demostrar madurez operativa ante supervisores y auditores sin duplicar trabajo.

Aquí la SoA puede jugar un papel sorprendentemente práctico. No sustituye los requerimientos de DORA, claro. Tampoco el marco EBA sobre outsourcing o las obligaciones específicas de Banco de España, CNMV o DGSFP cuando correspondan. Pero sí puede convertirse en un mapa verificable de controles que soporte la narrativa supervisora: control de accesos, continuidad, clasificación de activos, logging, respuesta a incidentes, gestión de proveedores TIC y resiliencia operacional.

Una entidad financiera española debería hacerse tres preguntas bastante directas.

La primera: ¿mi registro de riesgos de ISO 27001 enlaza con servicios importantes o críticos en el sentido de DORA, o solo con activos técnicos? Si no enlaza, será difícil justificar prioridades de resiliencia.

La segunda: ¿mi SoA distingue controles diseñados para riesgos internos de los que también cubren obligaciones de terceros TIC, reporte de incidentes o continuidad? Si no lo hace, acabarás generando documentación paralela para supervisión.

La tercera: ¿tengo evidencias de pruebas, revisiones y excepciones que aguanten una inspección más allá de la auditoría de certificación? Porque el listón supervisor no siempre coincide con el del auditor de ISO, y en finanzas suele ser menos indulgente con las ambigüedades.

Hay otro punto delicado. Muchas entidades pequeñas o medianas asumen que tener ISO 27001 les coloca en buena posición para DORA. Les ayuda, sin duda. Pero no basta. DORA entra más a fondo en gobernanza TIC, reporte, pruebas de resiliencia y supervisión de terceros. Traducido: una SoA impecable no compensa una mala gestión de dependencias cloud o una clasificación deficiente de incidentes. Aun así, usar la disciplina de ISO 27001 como base documental y operativa sigue siendo, probablemente, la opción más sensata.

Qué suele preguntar un auditor cuando huele incoherencia

Los auditores experimentados no necesitan una gran revelación para detectar un SGSI débil. Les bastan tres o cuatro preguntas bien colocadas.

“Muéstrame un riesgo alto abierto y enséñame qué controles del anexo A lo tratan.”

“Has excluido este control. ¿Qué evidencia demuestra que no aplica al alcance actual?”

“Dices que el control está implementado. ¿Quién es el propietario, con qué frecuencia se revisa y dónde está la última evidencia?”

“¿Qué ha cambiado en la SoA desde la última revisión y por qué?”

Si estas preguntas obligan a reunir a media organización para improvisar una respuesta, el problema no es el auditor. El problema es que el SGSI no está gobernando nada de verdad.

También conviene recordar que la mejora continua, en ISO 27001, no es una coletilla moral. Las no conformidades y acciones correctivas deben gestionarse; las auditorías internas deben aportar hallazgos; la revisión por la dirección debe tomar decisiones sobre cambios, recursos y oportunidades de mejora. Un SGSI que no aprende de incidentes, excepciones o desviaciones termina certificando costumbre, no resiliencia.

Mi lectura: la SoA es un documento de negocio, no de compliance

Aquí está el punto que demasiadas organizaciones siguen pasando por alto. La Declaración de Aplicabilidad no pertenece solo al equipo de compliance, ni debería redactarse en un rincón por el consultor de turno. Es un documento de negocio porque traduce riesgo a control y control a decisión operativa. Afecta a presupuesto, arquitectura, contratación, recursos humanos, compras, continuidad y respuesta a incidentes.

Por eso una buena SoA no se parece a un formulario. Se parece a un mapa de decisiones: qué proteges, de qué, con qué, con qué límite, y con qué evidencia. Si está bien construida, ayuda a priorizar inversiones. Si está mal hecha, anestesia a la dirección con una falsa sensación de orden.

Mi recomendación para 2026 es bastante poco romántica y muy práctica. Revisa la metodología de riesgos antes que la SoA. Alinea criterios con impacto operativo, legal y de terceros. Obliga a que cada control aplicable tenga dueño y evidencia primaria. Limpia exclusiones cómodas pero mal defendidas. Conecta el registro de riesgos con incidentes reales, findings de auditoría, vulnerabilidades críticas y cambios de arquitectura. Y, sobre todo, deja de tratar la certificación como el evento central. El certificado es una foto. La gestión del riesgo es la película. Y nadie quiere descubrir en medio del incidente que solo había decorado.

La paradoja de ISO 27001 es esta: cuanto más madura es una organización, menos teatral resulta su documentación. Menos adjetivos. Más decisiones. Menos promesas. Más trazabilidad. La SoA, bien llevada, resume exactamente eso. No es el anexo aburrido. Es el corazón del SGSI.