Los 93 controles del anexo A de ISO 27001:2022: cómo priorizar la implementación sin convertirla en un monumento al Excel

El error más caro con ISO 27001:2022 no es dejar controles fuera. Es meterlos todos sin pensar. Hay organizaciones que tratan los 93 controles del anexo A como una lista de la compra obligatoria, y luego descubren dos cosas: que la norma no funciona así y que su Declaración de Aplicabilidad se ha convertido en un cementerio de decisiones mal explicadas.

ISO/IEC 27001:2022 exige seleccionar controles en función del riesgo, justificar inclusiones y exclusiones y documentarlo en la Declaración de Aplicabilidad. Ese documento no es burocracia ornamental. Es la pieza que conecta la evaluación de riesgos con las medidas reales del sistema de gestión de seguridad de la información. Si falla ahí, todo lo demás empieza a oler a proyecto de compliance hecho para auditor y no para resistir incidentes.

La edición 2022 reorganiza los controles del anexo A en cuatro bloques: organizacionales, de personas, físicos y tecnológicos. Son 93 controles, frente a los 114 de la edición 2013. Menos no significa más fácil. Significa más condensado, más abstracto en algunos puntos y, por tanto, más exigente en criterio. El trabajo serio ya no consiste en “mapear 114 numeritos”, sino en decidir qué combinación de controles reduce riesgo material en tu entorno, con dependencia real de terceros, nubes híbridas, desarrollo continuo y un regulador europeo que, por si alguien se había relajado, no distingue mucho entre un fallo técnico y una mala gobernanza.

Para un CISO o un responsable de cumplimiento en Europa, la pregunta útil no es “¿cuáles son los 93 controles?”. La pregunta útil es otra: ¿qué controles debo priorizar primero para reducir riesgo, sobrevivir a auditoría y no entrar en colisión con DORA, NIS2, GDPR o las obligaciones contractuales de clientes exigentes? Ahí está el quid.

Primero, una precisión que evita meses de trabajo inútil

ISO 27001:2022 no obliga a implantar automáticamente los 93 controles del anexo A. Lo que obliga, en la cláusula 6.1.3, es a determinar tratamientos de riesgo, comparar tus controles con los del anexo A para verificar que no omites lo necesario y elaborar una Declaración de Aplicabilidad que contenga, como mínimo, los controles necesarios, la justificación de inclusión, el estado de implementación y la justificación de exclusión de los no aplicables.

Ese matiz cambia el proyecto entero. Si partes de la idea “hay que implantarlo todo”, acabarás con tres patologías muy comunes:

• controles nominalmente implantados pero sin evidencia operativa;
• políticas infladas que nadie usa;
• un SoA bonito en PDF y débil ante preguntas concretas del auditor o del cliente.

La edición 2022 también importa por la estructura. Los cuatro temas del anexo A son:

• 37 controles organizacionales;
• 8 controles de personas;
• 14 controles físicos;
• 34 controles tecnológicos.

Eso ha llevado a algunas empresas a priorizar por “familia” o por facilidad. Error. La estructura sirve para ordenar; no para decidir. Priorizar por cantidad de controles o por afinidad del equipo es una mala idea. Si tu principal exposición está en terceros críticos, identidades privilegiadas, desarrollo inseguro o fuga de datos personales, empezar por embellecer el perímetro físico porque “es una familia cerradita y fácil de evidenciar” tiene el mismo valor que ordenar los cubiertos mientras arde la cocina.

La lógica correcta: priorizar por riesgo, dependencia y evidencia

Si tuviera que reducir una implantación sensata a una fórmula simple, sería esta: prioriza los controles que reduzcan escenarios de pérdida plausibles, que respondan a obligaciones regulatorias ya exigibles y que puedas demostrar con evidencia trazable. No por madurez teórica. No por moda. No por el entusiasmo del proveedor de turno.

Hay tres ejes que funcionan bien para decidir.

1. Riesgo de impacto alto y probabilidad no trivial

Tu evaluación de riesgos debe aterrizar en escenarios reconocibles: compromiso de cuentas privilegiadas, ransomware, exfiltración de datos personales, indisponibilidad prolongada de servicios críticos, error humano en despliegues, dependencia excesiva de un proveedor cloud, sabotaje interno, pérdida de portátiles sin cifrar, exposición accidental de repositorios o APIs.

Si el escenario ya te quita el sueño porque ha pasado en tu sector, no debería esperar al “wave 3” del programa ISO. Un control que mitiga un riesgo severo y frecuente merece prioridad aunque sea incómodo de implantar.

2. Dependencias externas y obligaciones cruzadas

En 2026, pocas organizaciones europeas operan sin nubes públicas, SaaS críticos, MSPs o cadenas de desarrollo distribuidas. Eso hace que controles sobre proveedores, seguridad en el ciclo de vida, monitorización, gestión de configuraciones e identidades tengan más peso del que tenían hace una década. No solo por sentido común. También por presión normativa.

DORA, por ejemplo, aprieta de lleno en la gestión del riesgo de terceros TIC. Los artículos 28 a 30 obligan a las entidades financieras a gobernar, clasificar, supervisar y documentar dependencias externas de forma mucho más seria que el viejo “tenemos un contrato y un SLA”. NIS2, en su artículo 21, exige medidas técnicas, operativas y organizativas, incluyendo gestión de incidentes, continuidad, seguridad de la cadena de suministro y políticas para evaluar la eficacia de las medidas. GDPR no se queda atrás: el artículo 32 exige medidas apropiadas al riesgo; el 33 impone notificación de violaciones de seguridad a la autoridad de control en 72 horas; el 28 convierte la gestión de encargados en una obligación dura, no en un anexo simpático de procurement.

Si tu implantación ISO ignora estos puntos y se centra antes en controles más fáciles de “papelizar”, quizá certificas. Pero no estás priorizando bien.

3. Evidencia operativa disponible o construible

Un control sin evidencia es una opinión con logo corporativo. La prioridad real también depende de si puedes demostrar que el control existe, funciona y se revisa. Logs de MFA, actas de revisión de accesos, tickets de gestión de cambios, escaneos de vulnerabilidades, resultados de EDR, inventarios, cláusulas contractuales, registros de formación, pruebas de restauración, actas de simulacros, métricas de parches. Eso vale. Una política genérica subida a SharePoint, bastante menos.

Por eso conviene priorizar también controles cuya implementación pueda apalancarse en procesos ya vivos. Si tu ITSM funciona, los controles ligados a cambios, activos, incidencias y proveedores pueden acelerarse. Si tu IAM está roto, no tiene sentido fingir madurez documental mientras las cuentas privilegiadas siguen compartidas.

Qué bloques del anexo A suelen merecer prioridad real en 2026

No existe una secuencia universal. Sí existe un patrón bastante repetible en organizaciones europeas medianas y grandes: ciertos controles tienen un rendimiento de reducción de riesgo muy superior al resto al comienzo del programa. Hablo de rendimiento, no de glamour.

Organizacionales: donde se decide si ISO 27001 es un sistema o una decoración

Los controles organizacionales del anexo A suelen parecer menos vistosos que los tecnológicos. Luego llega un incidente serio y todo el mundo descubre que la falla no fue solo técnica: no había clasificación de activos, no estaba claro quién aprobaba riesgos, no existía proceso de gestión de cambios decente, los proveedores se contrataron sin due diligence, los roles eran difusos y la respuesta a incidentes vivía en un PDF de 2019.

Entre los controles organizacionales que más a menudo merecen prioridad alta están los relativos a políticas de seguridad, roles y responsabilidades, segregación de funciones, gestión de proyectos, inventario y uso aceptable de activos, clasificación y etiquetado de la información, transferencia de información, control de accesos desde la gobernanza, relaciones con proveedores, preparación TIC para continuidad del negocio, respuesta a incidentes, recopilación de evidencias, gestión de configuraciones, gestión de cambios, capacidad, prevención de fuga de datos, copias de seguridad, redundancia y cumplimiento de requisitos legales, estatutarios, regulatorios y contractuales.

Traducido a castellano útil: si no sabes qué activos importan, quién decide sobre ellos, qué terceros los tocan y cómo se recuperan tras un incidente, da igual cuánto dinero metas en tooling.

Hay un control especialmente infravalorado en muchas implantaciones: la gestión de cambios. No luce en presentaciones, pero evita una parte obscena de los incidentes autoinfligidos. Un despliegue mal autorizado, una regla de firewall abierta “temporalmente”, un bucket público, una dependencia vulnerable introducida sin revisión, un hardening deshecho por prisa comercial. Si tienes un proceso de cambios con evaluación de seguridad, evidencia y rollback, reduces riesgo real. Si no, la mitad del discurso sobre “resiliencia” es teatro.

Personas: el bloque pequeño que suele tener un impacto desproporcionado

Solo 8 controles. Y aun así, muchas empresas llegan tarde a ellos porque parecen “recursos humanos con pátina ISO”. Mala lectura. Los controles de personas cubren el ciclo laboral completo: antes de la contratación, durante el empleo y en la salida o cambio de puesto, junto con concienciación, responsabilidades disciplinarias y reporte de eventos.

¿Por qué priorizarlos? Porque una parte enorme del riesgo operativo sigue pasando por personas con acceso legítimo. No hace falta entrar en folklore sobre “el empleado es el eslabón más débil”; esa frase ya hizo suficiente daño. Lo que sí conviene asumir es que altas, bajas y cambios mal gestionados siguen abriendo puertas absurdas: cuentas activas semanas después de una salida, accesos incompatibles acumulados, privilegios temporales convertidos en permanentes, contratistas sin revocación limpia y formación anual tratada como trámite.

Aquí hay conexión directa con GDPR. El principio de integridad y confidencialidad del artículo 5.1.f y la seguridad del tratamiento del artículo 32 no se sostienen si la organización carece de disciplina en accesos y formación. Y en entornos cubiertos por NIS2 o DORA, la responsabilidad de la dirección sobre medidas adecuadas ya no es precisamente filosófica.

Si debes elegir, prioriza cuatro cosas: controles previos a la incorporación cuando haya acceso sensible, cláusulas y responsabilidades claras, formación basada en riesgos concretos del puesto y un proceso de offboarding medible en horas, no en “cuando nos pase la lista RR.HH.”. Un auditor serio preguntará por evidencias. Un atacante también, aunque de forma menos educada.

Físicos: menos glamurosos, pero no opcionales

Los 14 controles físicos suelen infravalorarse en organizaciones muy cloud o muy SaaS. “Si todo está en la nube, esto nos afecta poco”. Esa frase envejece mal. Sigue habiendo oficinas, portátiles, salas de reuniones, teletrabajo, impresoras con memoria, destrucción de soportes, dispositivos móviles, visitas de terceros, racks locales, equipos de red, entornos de desarrollo y material sensible circulando fuera del CPD perfecto que solo existe en la presentación comercial.

La prioridad aquí depende mucho del modelo operativo. Una fintech nativa cloud con oficina ligera tendrá menos superficie física crítica que una aseguradora con sedes, archivo, centros de atención y equipamiento distribuido. Aun así, controles sobre entrada física, áreas seguras, protección frente a amenazas físicas y ambientales, seguridad del puesto de trabajo, clear desk/clear screen, ubicación y protección de equipos y retirada segura de activos suelen ser relevantes antes de lo que algunos creen.

Hay un punto especialmente práctico: el teletrabajo ha disuelto la frontera física del control. El portátil corporativo en casa del empleado, la llamada confidencial desde un coworking, el monitor a la vista en un tren. Si tu SoA trata la seguridad física como un bloque heredado “de oficina clásica”, va por detrás del riesgo real.

Tecnológicos: el bloque más visible y también el más fácil de sobredimensionar

Los 34 controles tecnológicos son los que más titulares internos generan. MFA, EDR, cifrado, DLP, logging, filtrado web, gestión de vulnerabilidades, hardening, seguridad de redes, borrado seguro, enmascaramiento, prevención de fuga, monitorización. Aquí es donde abundan las compras impulsivas.

La prioridad, otra vez, no la marca el catálogo del fabricante. La marcan tus escenarios de riesgo y tus obligaciones. En 2026, hay un conjunto de controles tecnológicos que rara vez debería quedar al final:

• gestión de identidades y autenticación fuerte, especialmente para privilegios y acceso remoto;
• gestión de vulnerabilidades técnicas y parcheo basado en criticidad;
• registro y monitorización de eventos, con capacidad real de detección;
• copias de seguridad seguras, offline o inmutables cuando aplique, y pruebas de restauración;
• seguridad de red y segmentación proporcional;
• configuración segura y hardening;
• cifrado y gestión de claves cuando haya datos sensibles;
• seguridad en el desarrollo y pruebas de seguridad en cambios.

La ironía habitual es esta: muchas organizaciones compran tecnología avanzada de detección antes de resolver inventario, privilegios o logs básicos. Es como instalar una alarma premium en una casa donde nadie sabe cuántas puertas hay ni quién tiene copia de las llaves.

La Declaración de Aplicabilidad: el documento donde se nota quién ha pensado y quién ha copiado

La SoA es el corazón argumental de ISO 27001:2022. No debería redactarse al final para satisfacer al auditor. Debería construirse en paralelo a la evaluación de riesgos y al plan de tratamiento. Si se hace bien, responde cuatro preguntas con precisión:

• qué control del anexo A aplica;
• por qué aplica o por qué no aplica;
• cómo se implementa;
• qué evidencia demuestra su estado.

La tentación de copiar justificaciones genéricas es enorme. Y se nota enseguida. “No aplica porque la organización no realiza desarrollo”. ¿Seguro? ¿Ni scripts de automatización, ni IaC, ni low-code, ni parametrizaciones críticas de SaaS, ni integraciones API? En 2026, muchas empresas dicen que no desarrollan porque no tienen un gran equipo de software, pero modifican procesos críticos con herramientas que cambian su superficie de riesgo. Excluir controles de desarrollo sin revisar esa realidad es pedir problemas.

Otro clásico: “no aplica por externalización”. Tampoco funciona así. Externalizar una actividad no externaliza la responsabilidad de gobernarla. Si un SaaS procesa datos personales, hay que conectar la decisión con el artículo 28 GDPR y, si eres entidad financiera, con los requerimientos de terceros TIC de DORA. Si un MSP gestiona infraestructura, la exclusión de controles internos puede ser parcial, pero la necesidad de supervisión, requisitos contractuales, monitorización y salida ordenada no desaparece por arte de magia.

Una SoA útil para auditoría y para negocio suele incluir, aunque la norma no imponga un formato único, columnas o campos sobre: identificador del control, aplicabilidad, justificación, propietario, documento/procedimiento asociado, herramientas o mecanismos implementados, evidencia principal, estado de madurez y riesgos o excepciones abiertas. Si no vinculas cada control con un dueño y una evidencia, el documento se degrada rápido a inventario narrativo.

Cómo priorizar sin caer en la trampa del “quick win” vacío

Los “quick wins” gustan porque permiten enseñar movimiento. El problema es que algunos solo mueven PowerPoint. Una priorización seria combina resultados tempranos con cimientos duraderos.

Propongo un enfoque de cinco capas, más honesto que empezar por familias del anexo A.

Capa 1: gobierno mínimo viable

Antes de desplegar controles dispersos, define propietarios, alcance, criterios de riesgo, activos críticos, requisitos legales y ritmo de seguimiento. Sin eso, todo se descoordina. Aquí entran la política marco, el inventario de activos de información, la asignación de responsabilidades y el proceso de tratamiento de riesgos.

Esto conecta con la cláusula 4 sobre contexto, la 5 sobre liderazgo, la 6 sobre planificación y la 8 sobre operación del SGSI. El anexo A no flota solo; se apoya en el sistema de gestión. Muchas implantaciones fracasan porque intentan “hacer el anexo A” sin construir primero la máquina que decide y revisa.

Capa 2: identidades, accesos y privilegios

Si hoy tu organización tiene MFA parcial, revisiones de acceso irregulares o cuentas privilegiadas mal custodiadas, ese debería ser un frente prioritario. No porque lo diga una moda de mercado, sino porque el compromiso de identidad sigue siendo una de las rutas más eficaces para ataques reales y para incidentes internos.

Desde el punto de vista normativo, aquí confluyen ISO 27001 con GDPR art. 32, NIS2 art. 21 y, para entidades financieras, con la lógica de resiliencia y control continuo que DORA exige. El auditor de ISO buscará procedimiento y evidencia. El regulador sectorial, si llega el incidente, querrá saber si las medidas eran apropiadas al riesgo y si estaban operativas.

Capa 3: visibilidad y capacidad de respuesta

Sin logs, monitorización y respuesta a incidentes, no hay capacidad de demostrar control. Tampoco de contener daños. La prioridad debe ponerse en fuentes de log críticas, casos de uso de detección, escalado, forénsica básica y pruebas de respuesta. No hace falta montar un SOC de película para empezar, pero sí establecer qué eventos importan, cuánto tiempo se retienen y quién actúa.

GDPR art. 33 introduce aquí una presión práctica: si sufres una violación de seguridad de datos personales, el reloj de 72 horas no se detiene porque tu logging sea caótico. La obligación de notificación a la autoridad de control empieza cuando tienes conocimiento de la violación. Sin capacidad razonable de detección y análisis, la ventana se te come.

Capa 4: resiliencia operacional

Copias de seguridad, restauración probada, redundancia donde proceda, continuidad y gestión de crisis. Estas piezas suelen venderse como “BCP/DR de toda la vida”, pero en 2026 la conversación ya no es esa. La pregunta es si puedes mantener o recuperar servicios críticos dentro de tolerancias definidas y con dependencias externas mapeadas.

En organizaciones sujetas a DORA, la conversación se vuelve aún más concreta por las exigencias de marco de gestión del riesgo TIC, respuesta y recuperación, continuidad y pruebas. ISO no sustituye a DORA, pero una priorización inteligente de controles del anexo A sí puede ayudarte a construir evidencias reutilizables. No idénticas. Reutilizables, que es bastante mejor que empezar de cero tres veces.

Capa 5: terceros, desarrollo y cambio

Este bloque suele entrar tarde y debería subir posiciones. La superficie de riesgo moderna se mueve por proveedores, pipelines, integraciones y cambios frecuentes. Si compras SaaS, externalizas operaciones o desarrollas software, los controles de due diligence, cláusulas de seguridad, monitorización del proveedor, gestión de vulnerabilidades, revisiones de código, segregación de entornos y control de cambios merecen un tratamiento prioritario.

La razón es sencilla: muchos incidentes graves ya no nacen solo de un endpoint comprometido, sino de una combinación de mala configuración, dependencia opaca y falta de supervisión contractual. Y eso, por cierto, es exactamente el tipo de fallo que luego queda fatal en el comité de auditoría porque nadie puede decir quién era dueño del riesgo.

No todos los 93 controles pesan igual: una matriz práctica para decidir

Si tu organización está arrancando o reordenando su SGSI, conviene clasificar los controles del anexo A con cuatro variables: criticidad del activo afectado, cobertura regulatoria cruzada, dependencia de terceros y esfuerzo de evidencia. No hace falta convertirlo en una tesis doctoral. Sí conviene evitar decisiones intuitivas sin rastro documental.

La tabla no sustituye al análisis. Lo ordena. Si al aplicar esta lógica un control queda sistemáticamente abajo, pregunta por qué. A veces la respuesta será correcta. Otras veces descubrirás un sesgo muy humano: se ha relegado porque nadie quiere hacerse cargo.

Errores de priorización que siguen apareciendo en auditoría

Después de años viendo programas ISO, hay errores que regresan con una puntualidad casi entrañable.

Confundir certificación con cobertura real de riesgo

Se implantan controles “auditables” pero no necesariamente los que más reducen exposición. Resultado: buena foto de cumplimiento, mala postura operativa. La norma permite adaptar; no premia engañarse.

Excluir controles con justificaciones endebles

“No aplica porque lo lleva el proveedor”, “no aplica porque no tenemos CPD”, “no aplica porque somos una empresa pequeña”. Ninguna de esas frases basta por sí sola. El análisis debe bajar a proceso, activo y escenario de riesgo.

Convertir la SoA en un documento estático

Si cambian arquitectura, proveedores, procesos de desarrollo, uso de IA generativa interna o superficie regulatoria, la SoA debe cambiar. Dejarla congelada tras la certificación es una manera elegante de crear incoherencias futuras.

Priorizar controles tecnológicos sin base de inventario

No puedes proteger lo que no localizas. Sin inventario razonable de activos, datos, repositorios, interfaces y terceros, la priorización técnica será parcial y a veces directamente ficticia.

Subestimar la evidencia

Un control puede existir de facto y aun así fracasar en auditoría o en due diligence de cliente si no hay prueba suficiente. Esto vale para backups, revisiones de acceso, formación, cambios y respuesta a incidentes. “Lo hacemos, pero no queda registro” suele significar “no puedes demostrarlo cuando importa”.

Cómo encaja ISO 27001:2022 con DORA, NIS2 y GDPR sin vender humo de “armonización total”

Conviene decirlo claro: ISO 27001 no te da cumplimiento automático de DORA, NIS2 ni GDPR. Quien venda eso está simplificando demasiado o vendiendo otra cosa. Lo que sí ofrece es una arquitectura de gestión útil para estructurar controles, responsabilidades y evidencias de forma reutilizable.

Con DORA, la relación más obvia está en gobernanza del riesgo TIC, incidentes, continuidad, pruebas y terceros. Pero DORA va más allá en exigencias sectoriales y supervisión de terceros críticos. El anexo A te ayuda a construir base documental y operativa; no resuelve por sí solo la granularidad financiera ni los RTS/ITS aplicables.

Con NIS2, el encaje es fuerte en medidas de gestión del riesgo, cadena de suministro, gestión de incidentes, continuidad, seguridad del desarrollo y formación. El artículo 21 de NIS2 es particularmente útil como punto de contraste: si tu priorización ISO deja flojas esas áreas, probablemente también deja huecos frente a NIS2.

Con GDPR, la intersección es constante: control de accesos, cifrado, resiliencia, pruebas, gestión de proveedores, minimización operativa y respuesta a incidentes. Pero GDPR introduce principios y derechos que ISO no cubre de forma exhaustiva, como bases jurídicas, transparencia, minimización estricta o DPIAs bajo el artículo 35. Un SGSI sólido ayuda. No sustituye a una función de privacidad madura.

La forma inteligente de trabajar en 2026 no es intentar que una norma “cubra” mágicamente a las demás. Es construir un modelo de control donde una misma evidencia sirva para varios frentes cuando tenga sentido: una revisión trimestral de accesos puede apoyar ISO, GDPR y exigencias contractuales; una prueba de restauración puede alimentar ISO, DORA y auditorías de clientes; un registro de terceros críticos puede alinearse con procurement, legal, DORA y NIS2. Reutilizar evidencia es eficiencia. Reutilizar argumentarios falsos es otra cosa.

Checklist de evidencias para auditoría

Si estás priorizando implantación, prioriza también la capacidad de demostrarla. Esta es la parte que demasiados equipos intentan arreglar la semana antes de la auditoría, con resultados previsiblemente cómicos.

• Inventario de activos y propietarios: registro actualizado, criterio de criticidad, activos de información y no solo hardware.
• Evaluación de riesgos: metodología, criterios, resultados, aprobaciones, seguimiento de tratamientos.
• Declaración de Aplicabilidad: versión vigente, justificaciones específicas, estado de implementación, exclusiones razonadas.
• Control de accesos: matriz de roles, altas/bajas/cambios, revisiones periódicas, MFA, cuentas privilegiadas.
• Gestión de cambios: tickets, aprobaciones, evaluación de impacto, evidencias de prueba y rollback.
• Gestión de vulnerabilidades: escaneos, criticidad, plazos internos de remediación, excepciones aprobadas.
• Backups y restauración: políticas, inventario de copias, resultados de pruebas, incidencias detectadas.
• Incidentes: procedimiento, registros, cronología, decisiones, lecciones aprendidas, notificaciones si aplican.
• Proveedores: due diligence, clasificación, contratos, cláusulas de seguridad, seguimiento periódico.
• Formación: plan anual, registros de asistencia, contenido por perfiles, campañas específicas.
• Cumplimiento legal y regulatorio: matriz de requisitos aplicables, revisiones, responsables y evidencias asociadas.

Si varias de estas evidencias no existen o son difíciles de localizar, ya tienes una señal bastante clara de dónde debe ir la prioridad. No a la política nueva. A la disciplina operativa.

Implicaciones para entidades financieras españolas

Para banca, pagos, seguros, EAF, gestoras y buena parte del ecosistema fintech en España, ISO 27001:2022 sigue siendo una certificación valiosa, pero en 2026 ya no basta con exhibirla como atajo reputacional. El listón regulatorio europeo ha subido y el supervisor pregunta con más detalle.

La combinación práctica es esta: si tu entidad está bajo DORA, la priorización del anexo A debería reforzar, no distraer, el marco de riesgo TIC, la respuesta y recuperación, la gestión de terceros y la trazabilidad de pruebas. El Banco de España, la CNMV o la DGSFP no van a considerar que una SoA genérica compense una gobernanza pobre sobre proveedores críticos o una capacidad de recuperación no probada.

Además, las entidades españolas suelen enfrentarse a una presión adicional de clientes corporativos y grupos internacionales que piden evidencias concretas, no solo certificados. Quieren saber tiempos de revocación de accesos, frecuencia de pruebas de restauración, retención de logs, arquitectura de segregación, localización de datos y controles sobre subencargados. Ahí la utilidad de una implantación bien priorizada se vuelve muy tangible: reduce fricción comercial y evita responder cuestionarios de seguridad con fe y buena voluntad.

Hay otra implicación menos obvia. En grupos financieros, el problema rara vez está en la entidad principal. Está en filiales, proveedores y procesos heredados donde el SGSI corporativo llega deshilachado. El anexo A, bien usado, sirve para imponer una gramática común de control. Mal usado, produce una ilusión de homogeneidad que se rompe en cuanto preguntas por evidencia local.

La pregunta final no es cuántos controles tienes, sino cuáles sostienes de verdad

Los 93 controles del anexo A de ISO 27001:2022 no son un examen tipo test. Son un catálogo para tomar decisiones defendibles. Eso exige criterio, y el criterio se demuestra enlazando riesgo, obligación, implementación y evidencia.

Si tu organización está priorizando ahora, empieza por donde duele de verdad: gobierno útil, activos, identidades, monitorización, resiliencia, terceros y cambios. Después amplía. Lo contrario también se puede hacer, claro. Hay empresas que dedican meses a redactar políticas impecables mientras siguen sin probar restauraciones o sin revisar privilegios. Luego llega una auditoría seria, un cliente grande o un incidente. Y la realidad, como suele pasar, tiene la mala costumbre de leer los anexos con más atención que los comités.

La mejor SoA no es la que marca más casillas. Es la que explica por qué cada control está —o no está— y lo respalda con una operación que aguanta preguntas incómodas. Si la tuya todavía no aguanta esas preguntas, ya sabes cuál es la prioridad. No necesitas otro Excel. Necesitas mejores decisiones.