La Declaración de Aplicabilidad en ISO 27001 no es papeleo: es donde tu SGSI demuestra si piensa o improvisa

Hay un documento en ISO 27001 que demasiadas empresas tratan como si fuera un trámite de certificación y no la pieza que delata si el sistema de gestión tiene cerebro o solo plantilla. Ese documento es la Declaración de Aplicabilidad, la famosa SoA. Cuando está bien hecha, explica por qué eliges unos controles y descartas otros, qué riesgos estás tratando y dónde está la evidencia. Cuando está mal, deja una estampa bastante conocida: matriz de riesgos genérica, anexo A copiado con frases vagas y auditor buscando pruebas mientras el equipo improvisa respuestas.

La ironía es que ISO 27001 no te pide que implantes controles “porque sí”. Te pide que pienses. La lógica está en las cláusulas 6 y 8 de ISO/IEC 27001:2022: primero evalúas riesgos, luego decides su tratamiento, después determinas qué controles necesitas, y finalmente documentas esa decisión en la SoA. No es una secuencia decorativa. Es el corazón del SGSI.

Para un CISO o un responsable de compliance en 2026, esto importa más que hace cinco años. No solo por certificarse. También porque la presión regulatoria europea ya no premia catálogos bonitos de controles; exige trazabilidad entre riesgo, decisión, control, incidente y prueba. DORA exige marcos de gestión de riesgos TIC y pruebas de resiliencia; NIS2 exige medidas técnicas, operativas y organizativas proporcionales; el GDPR obliga a demostrar responsabilidad proactiva y seguridad apropiada. En todos esos regímenes hay una pregunta de fondo: ¿puedes demostrar por qué hiciste lo que hiciste? La SoA, bien construida, ayuda a contestarla. Mal construida, te deja expuesto.

Lo que ISO 27001 pide de verdad, y lo que muchas organizaciones fingen que pide

ISO/IEC 27001:2022 no obliga a adoptar todos los controles del anexo A. Ese malentendido sigue vivo, sorprendentemente. La norma te exige definir y aplicar un proceso de evaluación de riesgos de seguridad de la información y un proceso de tratamiento de riesgos. Eso está en la cláusula 6.1.

El detalle importa:

La cláusula 6.1.2 exige definir y aplicar un proceso para la evaluación de riesgos que establezca criterios de aceptación del riesgo e identifique, analice y evalúe riesgos de seguridad de la información. La cláusula 6.1.3 exige definir y aplicar un proceso de tratamiento de riesgos, seleccionar opciones adecuadas, determinar los controles necesarios e “comparar” esos controles con los del anexo A para verificar que no se omite nada necesario. Y la cláusula 6.1.3 d) exige precisamente producir la Declaración de Aplicabilidad, que debe contener los controles necesarios, incluida la justificación de su inclusión, si son aplicados o no, y la justificación de las exclusiones.

A partir de ahí, la cláusula 8 convierte la teoría en operación. La 8.2 exige realizar las evaluaciones de riesgos a intervalos planificados o cuando se propongan cambios significativos. La 8.3 exige implementar el plan de tratamiento de riesgos y conservar información documentada de los resultados.

Dicho de forma menos diplomática: si tu organización tiene una evaluación de riesgos anual hecha en octubre para “pasar la auditoría” y doce meses de cambios tecnológicos no reflejados, el problema no es solo de orden documental. El problema es que el SGSI no está operando conforme a la cláusula 8. Y eso el auditor serio lo ve. El regulador serio también.

La SoA no empieza en el anexo A. Empieza en el negocio

Un error clásico consiste en abrir el anexo A, revisar los 93 controles de ISO/IEC 27001:2022 y marcar casillas. Eso produce una SoA, sí. Pero no necesariamente produce una decisión sensata. El punto de partida correcto no es el catálogo de controles, sino el contexto de la organización, el alcance del SGSI, los activos, los procesos críticos, las dependencias tecnológicas y los requisitos legales y contractuales.

Aquí la norma también es menos abstracta de lo que parece. Las cláusulas 4.1 y 4.2 obligan a entender el contexto interno y externo y las necesidades de las partes interesadas. La cláusula 4.3 obliga a determinar el alcance del SGSI. Si el alcance es difuso, la evaluación de riesgos sale defectuosa; si la evaluación es defectuosa, la SoA se convierte en ficción administrativa.

Ejemplo simple. Una fintech que procesa pagos, usa infraestructura cloud multirregión, externaliza el desarrollo a un tercero y depende de un proveedor de KYC no puede tratar el riesgo como si fuera una pyme industrial con ERP on-prem y 80 usuarios. Sus escenarios de riesgo no son los mismos: fallo de autenticación federada, indisponibilidad del proveedor de identidad, error de configuración en almacenamiento cloud, exposición de logs con datos personales, dependencia contractual de subprocesadores, fuga de secretos en pipelines CI/CD, degradación del servicio por API de terceros. Si eso no aparece en la evaluación, la SoA ya nace coja.

El anexo A sirve para comprobar cobertura y seleccionar controles. No para sustituir el juicio. ISO/IEC 27001:2022 reorganizó el anexo A en 4 bloques y 93 controles: organizativos, de personas, físicos y tecnológicos. Más cómodo. Más legible. Pero sigue sin hacer el trabajo por ti.

Qué hace una evaluación de riesgos útil y qué delata una evaluación de cartón

Una evaluación de riesgos útil no se limita a listar amenazas genéricas del tipo “malware”, “phishing” o “pérdida de datos”. Conecta cinco piezas: activo o proceso, amenaza, vulnerabilidad, impacto y probabilidad. Y añade una sexta que muchas matrices olvidan: el propietario del riesgo con capacidad real para decidir.

La prueba de fuego es operativa. Si tu evaluación concluye que el riesgo de exfiltración de datos desde un entorno SaaS es “medio”, ¿qué significa eso en términos prácticos? ¿Se ha valorado el volumen de datos personales? ¿Hay datos de categorías especiales del GDPR, artículo 9? ¿Existe cifrado gestionado por el proveedor o por el cliente? ¿Hay control de acceso condicional? ¿Se registran descargas masivas? ¿La revocación de cuentas externas tarda horas o días? Sin ese nivel de aterrizaje, el scoring se convierte en numerología corporativa.

Lo mismo con los impactos. Un impacto “alto” no dice gran cosa. Un impacto definido por umbrales sí: interrupción superior a cuatro horas de un proceso crítico, afectación a datos de más de 10.000 interesados, imposibilidad de restaurar backups dentro del RTO acordado, incumplimiento de una obligación de notificación de incidentes o exposición contractual frente a un cliente regulado. Si no puedes traducir el impacto a consecuencias observables, luego tampoco podrás defender por qué seleccionaste ciertos controles.

El regulador europeo lleva años empujando en esa dirección. NIS2, en su artículo 21, exige medidas de gestión de riesgos de ciberseguridad “adecuadas y proporcionadas” e incluye políticas de análisis de riesgos y seguridad de sistemas, gestión de incidentes, continuidad, seguridad de la cadena de suministro y autenticación multifactor, entre otras. DORA, en sus artículos 5 a 16, exige un marco de gestión de riesgos TIC con identificación, protección, detección, respuesta, recuperación y aprendizaje. No es casualidad que una evaluación de riesgos de verdad termine pareciéndose bastante a lo que esos textos esperan ver.

La Declaración de Aplicabilidad: qué debe contener y por qué suele fallar

La SoA, según la cláusula 6.1.3 d de ISO/IEC 27001:2022, debe incluir cuatro cosas concretas: los controles necesarios para implementar el tratamiento de riesgos; la justificación de su inclusión; si están implementados o no; y la justificación de la exclusión de los controles del anexo A que no se apliquen.

Eso parece sencillo hasta que uno revisa SoA reales. Los fallos más frecuentes son bastante repetitivos.

Primero, justificaciones vacías. “Se incluye para mitigar riesgos de seguridad” no es una justificación; es una obviedad. Una justificación útil cita el riesgo o escenario correspondiente. Por ejemplo: “Control A.8.15 logging se aplica para detectar accesos no autorizados y actividades anómalas en los entornos de pago, mitigando los riesgos R-14 y R-22 identificados en la evaluación de riesgos de 12 de mayo de 2026”. Eso ya es otra cosa.

Segundo, exclusiones absurdamente optimistas. Hay organizaciones que excluyen controles físicos porque “todo está en la nube”, como si nadie tuviera oficinas, portátiles, badges o salas con pantallas visibles. O excluyen controles de relación con proveedores porque “solo trabajamos con partners estratégicos”. Precisamente por eso. El auditor no te pide paranoia; te pide coherencia.

Tercero, falta de estado real. Poner “implementado” cuando el control existe solo en política, pero no en práctica, es una receta excelente para una no conformidad mayor si la evidencia no aparece. Un control puede estar implementado parcialmente. Puede estar en despliegue. Puede depender de un proyecto. Mentir al documento no hace que el control madure por arte de magia.

Cuarto, ausencia de vínculo con evidencias. La norma no exige que la SoA incluya todas las pruebas, pero operativamente conviene enlazar cada control con la evidencia primaria: política, procedimiento, configuración técnica, ticket de cambio, acta de revisión, informe de prueba, captura de consola, registro de formación, acta de comité, contrato con proveedor, informe de auditoría interna. Si no lo haces, cada auditoría empieza como una gymkana documental.

El cambio de 114 a 93 controles no simplificó tanto como algunos prometieron

Desde la actualización de ISO/IEC 27001:2022 y la alineación con ISO/IEC 27002:2022, el anexo A pasó de 114 controles a 93. Sobre el papel, menos controles deberían traducirse en menos complejidad. En la práctica, no exactamente.

Lo que cambió fue la estructura y la lógica de agrupación. Muchos controles se consolidaron; otros se reformularon; aparecieron enfoques más explícitos sobre inteligencia de amenazas, seguridad para uso de servicios cloud, preparación TIC para continuidad del negocio, monitorización de actividades, gestión de configuración, borrado de información, enmascaramiento de datos, prevención de fuga de datos, filtrado web, codificación segura o monitorización física. El listado resulta más cercano a la realidad técnica de 2026. También obliga a pensar mejor las interdependencias.

Por eso una SoA heredada de versiones anteriores y “adaptada” con un simple mapeo suele hacer agua. Funciona para pasar el expediente, no para gobernar el riesgo. El problema no es formal; es conceptual. Si migras el documento sin revisar los escenarios de riesgo, te quedas con controles nominalmente actualizados sobre amenazas evaluadas con una mentalidad vieja.

Un caso ilustrativo es el uso de cloud. Hoy ya no basta con afirmar que el proveedor “cumple ISO” y asunto resuelto. Los controles del anexo A relacionados con servicios cloud, configuración, monitorización, gestión de identidades, logging y continuidad exigen un aterrizaje mucho más fino. ¿Quién revisa privilegios? ¿Dónde residen los logs? ¿Qué retención aplica? ¿Se auditan los cambios de configuración? ¿Qué ocurre con las claves de cifrado? ¿Se prueban las restauraciones? ¿Hay restricciones por región? Si la SoA no baja a ese detalle, la organización parece gestionar cloud por delegación teológica.

Riesgo aceptado no significa riesgo pensado

Otra zona gris habitual es la aceptación del riesgo. ISO 27001 permite aceptar riesgos. Claro que sí. Lo que no permite es aceptarlos de forma automática, sin criterio ni responsable, para cuadrar presupuesto o calendario.

La cláusula 6.1.2 exige establecer criterios de aceptación del riesgo. Eso significa que la organización debe definir de antemano qué niveles o condiciones permiten aceptar un riesgo y quién puede aprobarlo. Si el umbral cambia según convenga al proyecto de turno, no hay criterio; hay oportunismo.

En organizaciones maduras, la aceptación del riesgo deja rastro: descripción del riesgo, controles existentes, evaluación residual, razón de la aceptación, horizonte temporal, aprobador con autoridad, condiciones de revisión y, a veces, acciones compensatorias. En organizaciones inmaduras, la aceptación se usa como cubo de basura semántico para todo lo que no da tiempo a corregir antes de la auditoría.

Si trabajas en servicios financieros o das servicio a entidades sujetas a DORA, esto merece un subrayado. DORA no prohíbe aceptar riesgos, pero el marco de gestión de riesgos TIC exige una gobernanza mucho más exigente y una responsabilidad clara del órgano de dirección. Un riesgo aceptado sin trazabilidad, sin apetito al riesgo formalizado y sin revisión periódica puede ser soportable para certificar ISO; para una entidad regulada, puede convertirse en un problema de gobernanza.

Donde ISO 27001 se cruza con GDPR, NIS2 y DORA de forma útil

Una certificación ISO 27001 no equivale a cumplir automáticamente con GDPR, NIS2 o DORA. Conviene repetirlo porque sigue habiendo departamentos comerciales que venden lo contrario con una alegría admirable. Pero una evaluación de riesgos y una SoA bien planteadas sí sirven como columna vertebral de cumplimiento cruzado.

Con GDPR, la conexión es bastante directa. El artículo 5.2 establece el principio de responsabilidad proactiva. El artículo 24 obliga al responsable a aplicar medidas técnicas y organizativas apropiadas. El artículo 32 exige garantizar un nivel de seguridad adecuado al riesgo, teniendo en cuenta el estado de la técnica, los costes, la naturaleza, el alcance, el contexto y los fines del tratamiento, así como los riesgos para los derechos y libertades de las personas físicas. Ese lenguaje encaja casi de forma natural con la lógica de ISO 27001. Si tu SoA vincula controles a riesgos sobre confidencialidad, integridad, disponibilidad y resiliencia, ya tienes una base robusta para demostrar por qué adoptaste MFA, cifrado, segregación, backups probados, logging o DLP.

Con NIS2 ocurre algo parecido, aunque el foco está en ciberseguridad y continuidad operativa de entidades esenciales e importantes. El artículo 21 enumera medidas mínimas que incluyen análisis de riesgos, gestión de incidentes, continuidad y recuperación, seguridad de la cadena de suministro, seguridad en adquisición, desarrollo y mantenimiento, evaluación de efectividad de medidas, higiene cibernética, criptografía y autenticación multifactor. Una SoA madura puede actuar como índice de evidencias para muchas de esas áreas. No sustituye el programa NIS2, pero ayuda a ordenar la casa.

Con DORA la relación es aún más estratégica para entidades financieras europeas. El reglamento exige, entre otras cosas, un marco interno sólido de gestión del riesgo TIC, clasificación y notificación de incidentes, pruebas de resiliencia, gestión del riesgo de terceros TIC y gobernanza por parte del órgano de dirección. ISO 27001 cubre parte del terreno, sobre todo en gestión y control, pero no llega sola a todo. Aquí el valor real de la SoA está en mostrar qué controles internos respaldan esas obligaciones y dónde siguen existiendo brechas, sobre todo en terceros críticos, testing avanzado y reporting regulatorio.

La idea útil no es “tenemos ISO, luego cumplimos”. La idea útil es otra: “si estructuramos bien riesgos, tratamiento, SoA y evidencias, reducimos trabajo duplicado y mejoramos defendibilidad frente a varias normas a la vez”. Eso sí es realista.

Cómo construir una SoA que sirva para gestionar, no solo para enseñar

La mejor SoA no es la más larga. Es la que permite responder preguntas incómodas sin buscar durante media hora en SharePoint.

Operativamente, una SoA útil suele incluir, como mínimo, estos campos: identificador del control del anexo A; nombre del control; aplicabilidad; justificación de inclusión o exclusión; riesgos vinculados; propietario del control; estado de implantación; referencia a política o procedimiento; referencia a evidencias; fecha de última revisión; observaciones sobre limitaciones o acciones abiertas. No todos esos campos son obligatorios por norma, pero casi todos son obligatorios para conservar la cordura.

La clave está en la granularidad. Si enlazas un control a veinte riesgos sin discriminar, la trazabilidad se vuelve tan opaca como una lista sin enlaces. Si enlazas cada control a los riesgos concretos que trata y a evidencias actualizadas, la SoA se transforma en un mapa de gobierno. El auditor la usa. El equipo de seguridad también. El responsable de protección de datos puede apoyarse en ella. Compras la necesita para revisar terceros. Continuidad la usa para probar dependencias. Ahí empieza a tener valor.

Hay otro matiz que suele marcar diferencias en auditoría: distinguir entre diseño del control y efectividad operativa. Una política aprobada acredita diseño. Un registro de revisiones trimestrales, resultados de escaneo, tickets resueltos, evidencias de restauración o informes de simulacros acreditan operación. Si en la SoA no separas mentalmente ambas capas, terminarás declarando como “implantado” un control que solo existe en PDF.

Ejemplos operativos: cómo se traduce un riesgo en control y evidencia

Veamos algunos escenarios que un CISO europeo reconoce al instante.

Escenario 1: fuga de datos desde colaboración cloud

Riesgo: usuarios comparten información sensible desde una suite de colaboración con enlaces públicos o permisos excesivos.

Tratamiento razonable: aplicar controles de clasificación de la información, control de acceso, prevención de fuga de datos, logging y revisión periódica de permisos. En el anexo A esto puede aterrizar, entre otros, en controles organizativos y tecnológicos relacionados con clasificación, gestión de acceso, monitorización de actividades y prevención de fugas.

Evidencia útil: política de clasificación aprobada; configuración de bloqueo de enlaces públicos; reglas DLP activas; informe mensual de comparticiones externas; revisión trimestral de grupos privilegiados; registro de incidentes relacionados; formación específica a usuarios de negocio.

Qué delata inmadurez: una SoA que dice “aplicable” pero la evidencia real es solo una política genérica descargada de una plantilla.

Escenario 2: dependencia crítica de proveedor SaaS para proceso regulado

Riesgo: indisponibilidad o fallo de seguridad del proveedor afecta a un proceso crítico y a obligaciones contractuales o regulatorias.

Tratamiento razonable: due diligence de proveedor, cláusulas contractuales, requisitos de notificación de incidentes, revisión de subprocesadores, pruebas de continuidad, exportabilidad de datos, logging y monitoreo de SLA.

Evidencia útil: evaluación de terceros; contrato con anexos de seguridad; resultados de revisión de SOC 2 o ISO del proveedor; actas de comité donde se aprueba el riesgo residual; prueba de restauración o plan alternativo; inventario de dependencias críticas.

Aquí la SoA gana mucho si conecta con DORA art. 28 y siguientes sobre gestión de terceros TIC cuando la entidad está dentro de su ámbito. Si no lo hace, la certificación puede quedar bien en la pared y corta frente al supervisor.

Escenario 3: desarrollo interno con riesgo de vulnerabilidades en software

Riesgo: introducción de vulnerabilidades por prácticas de codificación insegura, gestión deficiente de secretos o dependencias sin control.

Tratamiento razonable: requisitos de seguridad en el ciclo de desarrollo, segregación de entornos, análisis estático y de dependencias, gestión de secretos, revisión de código, hardening de pipelines, control de cambios y logging.

Evidencia útil: estándar de desarrollo seguro; resultados de SAST/DAST; inventario de dependencias; política de gestión de secretos; tickets de remediación con SLA; evidencia de revisiones de código; lista de excepciones aprobadas.

Conexión regulatoria extra: NIS2 art. 21 menciona expresamente la seguridad en la adquisición, desarrollo y mantenimiento de redes y sistemas, incluida la gestión de vulnerabilidades y divulgación coordinada cuando proceda. Una SoA bien hecha no solo ayuda en ISO. Te prepara para preguntas regulatorias bastante previsibles.

La auditoría de certificación no busca poesía. Busca coherencia verificable

Quien haya pasado por una auditoría seria sabe que el auditor competente suele seguir un hilo simple y devastador: enséñame el riesgo, enséñame el tratamiento, enséñame el control, enséñame la evidencia, enséñame la revisión. Si en cualquiera de esos pasos aparece una ruptura, la madurez aparente se desinfla rápido.

La no conformidad típica no surge porque falte una palabra en la SoA. Surge porque el documento promete más de lo que la operación sostiene. Algunos ejemplos muy habituales:

• La evaluación de riesgos no se actualizó tras una migración relevante a cloud, pese a que la cláusula 8.2 exige reevaluar ante cambios significativos.
• La SoA marca como aplicados controles de logging o revisión de accesos, pero no hay registros, retención definida ni evidencias de revisión.
• La justificación de exclusiones es incompatible con el alcance real del SGSI.
• El plan de tratamiento define acciones, pero no hay seguimiento, fechas ni responsables visibles.
• La organización conserva política y procedimiento, pero no evidencia de ejecución.

Un detalle que a menudo separa a las organizaciones maduras de las que viven en modo auditoría es la frecuencia de revisión. La norma habla de intervalos planificados y cambios significativos, no de una fecha ritual al año. Si este año has incorporado un nuevo ERP, un proveedor crítico, una funcionalidad de IA generativa con acceso a datos internos, una filial en otro país o una integración M&A, tu evaluación de riesgos y tu SoA deberían haber cambiado. Si no lo han hecho, el SGSI va por detrás del negocio. Mala señal.

Checklist de evidencias para auditoría

Esta es una de las pocas listas que sí merece existir, porque evita el caos de última hora y conecta directamente con las cláusulas 6 y 8. No sustituye el criterio, pero sí reduce errores tontos.

• Metodología de evaluación de riesgos vigente, con criterios de impacto, probabilidad y aceptación formalmente aprobados.
• Registro de riesgos dentro del alcance del SGSI, con fecha de revisión, propietario y evaluación residual.
• Plan de tratamiento de riesgos, con decisiones concretas: mitigar, transferir, evitar o aceptar, y con responsables y seguimiento.
• Declaración de Aplicabilidad actualizada, alineada con ISO/IEC 27001:2022 anexo A, con justificación de inclusión y exclusión.
• Evidencias de implantación por control: políticas, procedimientos, configuraciones, registros, actas, informes técnicos, contratos o tickets.
• Pruebas de operación: revisiones de acceso, escaneos, resultados de backups y restauraciones, simulacros, formación completada, incidencias gestionadas.
• Actas o decisiones del comité correspondiente cuando se acepten riesgos relevantes o se aprueben excepciones.
• Evidencia de reevaluación tras cambios significativos, tal como exige la cláusula 8.2.
• Resultados de auditorías internas y acciones correctivas relacionadas con controles del anexo A.
• Trazabilidad entre riesgos, controles y objetivos de seguridad cuando el SGSI los haya formalizado.

Si tu organización no puede reunir esto sin una operación de rescate documental, el problema no es la carpeta. Es la forma de gestionar.

Implicaciones para entidades financieras españolas y europeas

Para banca, seguros, EDE, EMI, gestoras, infraestructuras de mercado y proveedores TIC que dan servicio al sector financiero, la utilidad de una SoA robusta va más allá de ISO 27001. Sirve para ordenar evidencias que supervisores y clientes institucionales ya esperan ver por otras vías.

En 2026, una entidad financiera europea que use ISO 27001 como base de control debería revisar al menos cuatro frentes donde la SoA puede quedarse corta si se diseña solo para certificar.

El primero es terceros TIC. DORA pone el foco de forma muy explícita en la gestión contractual, la monitorización y la concentración de riesgo. Una SoA genérica sobre proveedores no basta si no distingue dependencias críticas, requisitos de salida, subcontratación en cadena e incident reporting. El artículo 28 de DORA y los siguientes no están para adornar questionnaires de procurement.

El segundo es resiliencia operativa probada. ISO 27001 exige tratamiento del riesgo y continuidad, pero DORA exige además pruebas de resiliencia digital con mayor sistemática y, en algunos casos, TLPT. Si la SoA declara controles de backup, recuperación y monitorización, la entidad tendrá que respaldarlos con pruebas frecuentes, resultados y remediación trazable. El papel aguanta bastante; un test fallido de restauración, no tanto.

El tercero es la conexión con privacidad. En banca y seguros, el dato personal y el dato financiero suelen viajar juntos. Si el SGSI no refleja riesgos sobre tratamiento de datos, transferencias, accesos privilegiados y retención, el responsable de protección de datos terminará creando un universo paralelo de controles. Mala idea. Duplicas esfuerzo y multiplicas inconsistencias.

El cuarto es la gobernanza. El Banco de España, la CNMV, la DGSFP y las autoridades europeas no buscan catálogos de control; buscan capacidad de dirección, supervisión y decisión. Una SoA útil permite explicar al comité de riesgos qué controles sostienen los procesos críticos, qué riesgos se han aceptado, qué terceros concentran exposición y dónde faltan evidencias. Si no sirve para esa conversación, sirve de poco.

Lo que un CISO debería revisar este año si no quiere una SoA de escaparate

La pregunta práctica no es si tienes SoA. La tienes. La pregunta es si refleja la realidad tecnológica y regulatoria de 2026.

Yo revisaría, como mínimo, cinco puntos. Uno: si la metodología de riesgos incorpora escenarios ligados a SaaS, identidades, APIs, pipelines, IA generativa, terceros y concentración cloud. Dos: si el registro de riesgos se actualiza cuando cambian sistemas, proveedores o procesos, no solo en la revisión anual. Tres: si cada control de la SoA tiene una justificación ligada a riesgos concretos y un propietario reconocible. Cuatro: si el estado “implementado” distingue entre diseño y operación. Cinco: si las evidencias se pueden localizar en minutos y no en una peregrinación por carpetas históricas.

Hay una razón por la que esto merece atención ahora. En 2026, los auditores están menos impresionados por documentos elegantes y más interesados en trazabilidad real. Y los clientes regulados también. Una fintech que vende a banca, un proveedor SaaS que procesa datos sensibles o un grupo industrial sujeto a NIS2 no compiten solo con producto o precio. Compiten también con la capacidad de demostrar control efectivo. La SoA, por aburrido que suene el nombre, juega en esa liga.

La conclusión incómoda: tu SGSI vale lo que valen sus decisiones documentadas

ISO 27001 tiene fama de normativa razonable precisamente porque no pretende adivinar tu negocio. Te obliga a decidir qué riesgos importan, cómo los tratas y qué controles necesitas. La Declaración de Aplicabilidad es el espejo de esas decisiones. Si el espejo devuelve una imagen nítida, tienes un SGSI gobernable. Si devuelve una colección de frases vacías, tienes un decorado de compliance.

La buena noticia es que arreglar una SoA no empieza por retocar el Excel. Empieza por revisar la calidad de la evaluación de riesgos, la claridad de los criterios de aceptación, la honestidad sobre el estado de los controles y la disciplina de conservar evidencia operativa. A partir de ahí, el documento deja de ser un artefacto de auditoría y se convierte en algo más útil: una explicación defendible de cómo protege tu organización lo que de verdad le puede doler.

Y ese, al final, es el verdadero examen. No si tu SGSI “tiene” todos los papeles. Sino si, cuando falle algo —porque algo fallará—, puedes demostrar que habías pensado el riesgo, elegido el control adecuado y revisado si funcionaba. Todo lo demás es caligrafía corporativa.