SoA de ISO 27001 para la preparación frente a NIS2 y DORA
Son las 08:30 de un lunes y Elena, la CISO de un proveedor SaaS fintech B2B en rápido crecimiento, abre una solicitud urgente del Consejo de Administración. La empresa acaba de obtener la certificación ISO/IEC 27001:2022, pero un importante potencial cliente bancario de la UE está planteando preguntas más exigentes que las del cuestionario de seguridad habitual.
No preguntan solo si la empresa cifra los datos, utiliza autenticación multifactor o dispone de un informe de pruebas de penetración. Quieren saber si la plataforma SaaS respalda sus obligaciones DORA, si el proveedor podría quedar dentro del alcance de NIS2 como servicio TIC o dependencia de infraestructura digital, y si la Declaración de Aplicabilidad de ISO 27001 puede justificar cada control incluido, cada control excluido y cada evidencia.
El Consejo de Administración formula la pregunta que cada CISO, responsable de cumplimiento y fundador de SaaS escucha cada vez con más frecuencia:
¿Puede nuestra SoA de ISO 27001 demostrar la preparación frente a NIS2 y DORA?
Elena sabe que la respuesta equivocada sería poner en marcha tres programas de cumplimiento separados: uno para ISO 27001, otro para NIS2 y otro para DORA. Eso generaría evidencias duplicadas, responsables de controles contradictorios y una carrera constante antes de cada evaluación de cliente. La mejor respuesta es utilizar el SGSI existente como sistema operativo del cumplimiento, con la Declaración de Aplicabilidad, o SoA, como documento maestro de trazabilidad.
La SoA no es solo una hoja de cálculo para la certificación ISO. En un entorno de ciberseguridad y resiliencia operativa de la UE, es el lugar donde una organización demuestra por qué existen los controles, por qué las exclusiones son defendibles, quién es responsable de cada control, qué evidencias respaldan la implantación y cómo el conjunto de controles aborda NIS2, DORA, GDPR, los contratos con clientes y el tratamiento interno de riesgos.
La Política de Seguridad de la Información empresarial de Clarysec Política de Seguridad de la Información establece:
El SGSI debe incluir límites de alcance definidos, una metodología de evaluación de riesgos, objetivos medibles y controles documentados justificados en la Declaración de Aplicabilidad (SoA).
Ese requisito, procedente de la cláusula 6.1.2 de la Política de Seguridad de la Información, es la base de un enfoque auditable. La SoA debe convertirse en el puente entre obligaciones, riesgos, controles, evidencias y decisiones de gestión.
Por qué NIS2 y DORA cambiaron lo que significa “aplicable”
Una SoA tradicional de ISO/IEC 27001:2022 suele empezar con una pregunta sencilla: “¿Qué controles del Anexo A son aplicables a nuestro plan de tratamiento de riesgos?”. Eso sigue siendo correcto, pero ya no es suficiente para proveedores SaaS, proveedores de servicios en la nube, proveedores de servicios gestionados, fintech, tecnología financiera y cadenas de suministro críticas.
NIS2 eleva la línea de base de la gestión de riesgos de ciberseguridad en entidades esenciales e importantes de la UE. Cubre sectores como infraestructura digital, proveedores de servicios de computación en la nube, proveedores de servicios de centros de datos, redes de distribución de contenidos, proveedores de servicios gestionados, proveedores de servicios gestionados de seguridad, banca e infraestructuras de los mercados financieros. Los Estados miembros deben identificar las entidades esenciales e importantes y los proveedores de servicios de registro de nombres de dominio, y muchos proveedores tecnológicos que antes trataban la regulación de ciberseguridad como un asunto del cliente ahora están directamente dentro del alcance o expuestos a requisitos contractuales trasladados en cascada.
NIS2 Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas en materia de análisis de riesgos, políticas de seguridad, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, adquisición y desarrollo seguros, evaluación de la eficacia de los controles, higiene cibernética, formación, criptografía, seguridad de RR. HH., control de acceso, gestión de activos y autenticación cuando proceda. NIS2 Article 23 añade expectativas de notificación escalonada de incidentes, incluidas alerta temprana, notificación, actualizaciones e informe final para incidentes significativos.
DORA, el Reglamento de Resiliencia Operativa Digital, se aplica desde el 17 de enero de 2025 y se centra en las entidades financieras y su ecosistema de riesgo TIC. Cubre la gestión del riesgo TIC, la notificación de incidentes relacionados con las TIC, la notificación de incidentes operativos o de seguridad relacionados con pagos para determinadas entidades, las pruebas de resiliencia operativa digital, el intercambio de información sobre ciberamenazas, la gestión del riesgo de terceros TIC, los acuerdos contractuales y la supervisión de proveedores terceros críticos de servicios TIC.
Para las entidades financieras que también sean entidades esenciales o importantes bajo NIS2, DORA actúa como el régimen sectorial específico para obligaciones equivalentes de gestión del riesgo TIC y notificación de incidentes. Pero para proveedores SaaS, proveedores de servicios en la nube, MSP y proveedores MDR que prestan servicio a clientes financieros, la realidad práctica es que las expectativas DORA llegan mediante contratación, contratos, derechos de auditoría, obligaciones de soporte en incidentes, planificación de salida, transparencia sobre subcontratistas y evidencias de resiliencia.
Eso cambia la conversación sobre la SoA. La pregunta ya no es: “¿El Anexo A contiene este control?”. La pregunta correcta es:
¿Podemos demostrar que la selección de controles está basada en riesgos, tiene en cuenta las obligaciones, es proporcionada, tiene responsables, está implantada, supervisada, evidenciada y aprobada?
ISO 27001 es el traductor universal para NIS2 y DORA
ISO/IEC 27001:2022 es valiosa porque es una norma de sistema de gestión, no una lista de verificación limitada. Exige que el SGSI se integre en los procesos de la organización y se escale a sus necesidades. Eso la convierte en un traductor universal eficaz para demandas de cumplimiento superpuestas.
Las cláusulas 4.1 a 4.4 exigen que la organización comprenda su contexto, identifique a las partes interesadas, determine los requisitos relevantes y defina el alcance del SGSI. Para un proveedor SaaS fintech como la empresa de Elena, esos requisitos de las partes interesadas pueden incluir clientes de la UE, clientes financieros afectados por DORA, exposición sectorial a NIS2, obligaciones como responsable y encargado del tratamiento bajo GDPR, dependencias externalizadas en la nube, interfaces con proveedores y expectativas del Consejo de Administración.
Las cláusulas 6.1.1 a 6.1.3 exigen planificar riesgos y oportunidades, un proceso repetible de evaluación de riesgos de seguridad de la información, un proceso de tratamiento de riesgos, la comparación con el Anexo A y una Declaración de Aplicabilidad que identifique los controles incluidos, el estado de implantación y las justificaciones de exclusión.
Aquí es donde la SoA se convierte en un registro de decisiones de control. Un control puede incluirse porque trata un riesgo, satisface un requisito legal, cumple un contrato de cliente, respalda un objetivo de negocio o representa una línea de base de higiene de seguridad. Un control solo puede excluirse después de que la organización lo haya evaluado conscientemente, lo haya considerado irrelevante para el alcance del SGSI, haya documentado la justificación y haya obtenido la aprobación adecuada.
La Política de gestión de riesgos empresarial de Clarysec Política de gestión de riesgos establece:
Una Declaración de Aplicabilidad (SoA) debe reflejar todas las decisiones de tratamiento y debe actualizarse siempre que se modifique la cobertura de los controles.
Este requisito, procedente de la cláusula 5.4 de la Política de gestión de riesgos, es crítico para la preparación frente a NIS2 y DORA. Un nuevo cliente regulado, una nueva dependencia en la nube, una nueva obligación de notificación de incidentes o un nuevo riesgo de concentración de proveedores pueden cambiar la aplicabilidad de los controles.
Empieza por el registro de cumplimiento, no por la lista de controles
Una SoA débil empieza por el Anexo A y pregunta: “¿Qué controles tenemos ya?”. Una SoA sólida empieza por la realidad operativa de la organización y pregunta: “¿Qué obligaciones, servicios, riesgos, datos, proveedores y clientes debe cubrir el SGSI?”.
ISO/IEC 27005:2022 respalda este enfoque al enfatizar los requisitos de las partes interesadas, los criterios de riesgo y la necesidad de considerar normas, reglas internas, leyes, regulaciones, contratos y controles existentes. También subraya que la no aplicabilidad o el incumplimiento deben explicarse y justificarse.
La Política de Cumplimiento Legal y Normativo para pymes de Clarysec Política de Cumplimiento Legal y Normativo para pymes recoge el mismo principio operativo:
El DG debe mantener un Registro de Cumplimiento sencillo y estructurado que enumere:
Ese requisito procede de la cláusula 5.1.1 de la Política de Cumplimiento Legal y Normativo para pymes. Para una organización más pequeña, el registro puede ser sencillo. Para una empresa, debe ser más detallado. La lógica es la misma: las obligaciones deben ser visibles antes de poder mapearse.
La Política de Cumplimiento Legal y Normativo empresarial de Clarysec Política de Cumplimiento Legal y Normativo es explícita:
Todas las obligaciones legales y reglamentarias deben mapearse a políticas, controles y responsables específicos dentro del Sistema de Gestión de la Seguridad de la Información (SGSI).
Esa es la cláusula 6.2.1 de la Política de Cumplimiento Legal y Normativo. Es la columna vertebral de gobernanza para utilizar una Declaración de Aplicabilidad de ISO 27001 en la preparación del cumplimiento frente a NIS2 y DORA.
| Campo del registro | Ejemplo de entrada | Por qué importa para la SoA |
|---|---|---|
| Fuente de la obligación | NIS2 Article 21 | Impulsa la inclusión de controles de análisis de riesgos, gestión de incidentes, continuidad, seguridad de proveedores, criptografía, control de acceso, gestión de activos y formación |
| Justificación de aplicabilidad | Proveedor SaaS que da soporte a clientes financieros y de sectores esenciales de la UE | Muestra por qué se considera NIS2, aunque el estatus legal final dependa de la designación por el Estado miembro |
| Responsable del control | Responsable de operaciones de seguridad | Respalda la rendición de cuentas y la titularidad de las evidencias |
| Control ISO/IEC 27001:2022 mapeado | Controles de gestión de incidentes A.5.24 a A.5.28 | Vincula la obligación legal con la selección de controles del Anexo A |
| Fuente de evidencias | Plan de respuesta a incidentes, muestras de tickets, revisión posterior al incidente, simulacro de notificación | Facilita el muestreo de auditoría |
| Decisión de la SoA | Aplicable | Crea trazabilidad entre obligación, riesgo, control y evidencia |
Construye criterios de riesgo que reflejen resiliencia, privacidad, proveedores y regulación
Muchas justificaciones de SoA fallan porque el modelo de calificación del riesgo es demasiado estrecho. Mide la probabilidad y el impacto técnicos, pero no captura la exposición regulatoria, la criticidad del servicio, el daño al cliente, la dependencia de proveedores, el impacto en la privacidad ni la interrupción operativa sistémica.
NIS2 no trata solo de confidencialidad. Se centra en prevenir y minimizar el impacto de los incidentes en los servicios y en sus destinatarios. DORA define funciones críticas o importantes en función de si una interrupción perjudicaría materialmente el rendimiento financiero, la continuidad del servicio o el cumplimiento normativo. GDPR añade responsabilidad proactiva, integridad, confidencialidad, preparación ante brechas de seguridad y daño a los interesados.
La Política de gestión de riesgos para pymes de Clarysec Política de gestión de riesgos para pymes ofrece un mínimo práctico:
Cada entrada de riesgo debe incluir: descripción, probabilidad, impacto, puntuación, propietario y plan de tratamiento.
Esta es la cláusula 5.1.2 de la Política de gestión de riesgos para pymes. Para la preparación frente a NIS2 y DORA, Clarysec amplía ese mínimo con campos como fuente de obligación, servicio afectado, categoría de datos, dependencia de proveedores, responsable de negocio, impacto regulatorio, riesgo residual, estado del tratamiento y fuente de evidencias.
| ID de riesgo | Escenario de riesgo | Factor de obligación | Controles de tratamiento | Justificación en la SoA |
|---|---|---|---|---|
| R-021 | Una indisponibilidad de la plataforma en la nube impide a los clientes acceder a paneles regulados de analítica antifraude | NIS2 Article 21, dependencia de cliente DORA, SLA contractual | A.5.29, A.5.30, A.8.13, A.8.15, A.8.16 | Aplicable porque la continuidad del servicio, las copias de seguridad, el registro de eventos, la supervisión y la preparación TIC reducen la interrupción operativa y respaldan las obligaciones de resiliencia de los clientes |
| R-034 | Un incidente de seguridad que afecta a datos personales de la UE no se detecta, escala ni notifica dentro de los plazos requeridos | responsabilidad proactiva bajo GDPR, NIS2 Article 23, obligaciones DORA de soporte en incidentes | A.5.24 a A.5.28, A.8.15, A.8.16 | Aplicable porque la gestión escalonada de incidentes, la recopilación de evidencias, el aprendizaje, el registro de eventos y la supervisión respaldan los flujos de trabajo de notificación regulatoria y a clientes |
| R-047 | Una debilidad de un subcontratista crítico afecta a la prestación segura del servicio a clientes financieros | seguridad de la cadena de suministro NIS2 Article 21, riesgo de terceros TIC bajo DORA | A.5.19 a A.5.23, A.5.31, A.5.36 | Aplicable porque el riesgo de proveedores, los requisitos contractuales, la gobernanza de la nube, las obligaciones de cumplimiento y el cumplimiento de políticas son necesarios para el aseguramiento de dependencias TIC |
Observa el lenguaje. Una justificación sólida no dice solo “implantado”. Explica por qué el control es aplicable en el contexto de negocio, regulatorio y de riesgo de la organización.
Mapea los dominios NIS2 y DORA a controles ISO 27001:2022
Una vez establecidos el registro de cumplimiento y los criterios de riesgo, el trabajo práctico consiste en mapear los dominios regulatorios a los controles del Anexo A. Este mapeo no demuestra el cumplimiento por sí solo, pero proporciona a auditores y clientes un índice claro para comprobar evidencias.
| Área de requisito regulatorio | Referencia NIS2 | Referencia DORA | Ejemplos de controles ISO/IEC 27001:2022 |
|---|---|---|---|
| Gobernanza y responsabilidad de la dirección | Article 20 | Article 5 | A.5.1, A.5.2, A.5.31, A.5.35, A.5.36 |
| Marco de gestión del riesgo | Article 21(1) | Article 6 | cláusulas ISO 27001 6.1.1 a 6.1.3, A.5.7, A.5.31, A.5.36 |
| Gestión y notificación de incidentes | Article 23 | Articles 17 to 19 | A.5.24, A.5.25, A.5.26, A.5.27, A.5.28, A.8.15, A.8.16 |
| Continuidad del negocio y resiliencia | Article 21(2)(c) | Articles 11 and 12 | A.5.29, A.5.30, A.8.13, A.8.14, A.8.15, A.8.16 |
| Cadena de suministro y riesgo de terceros | Article 21(2)(d), Article 21(3) | Articles 28 to 30 | A.5.19, A.5.20, A.5.21, A.5.22, A.5.23 |
| Adquisición y desarrollo seguros | Article 21(2)(e) | Article 9 | A.8.25, A.8.26, A.8.27, A.8.28, A.8.29, A.8.32 |
| Pruebas y eficacia del control | Article 21(2)(f) | Articles 24 to 27 | A.5.35, A.5.36, A.8.8, A.8.29, A.8.34 |
| Control de acceso y gestión de activos | Article 21(2)(i) | Article 9(4)(d) | A.5.9, A.5.15, A.5.16, A.5.17, A.5.18, A.8.2, A.8.3 |
| Criptografía y cifrado | Article 21(2)(h) | Article 9(4)(d) | A.8.24 |
Para Elena, este mapeo cambió la conversación con el Consejo de Administración. En lugar de presentar NIS2 y DORA como proyectos separados, pudo mostrar el solapamiento: gobernanza, gestión de riesgos, incidentes, continuidad, proveedores, pruebas, control de acceso y criptografía.
Los tres controles ISO de los que depende toda SoA para NIS2 y DORA
En Zenith Controls: The Cross-Compliance Guide Zenith Controls, Clarysec trata tres controles ISO/IEC 27002:2022 como centrales para una gobernanza de la SoA auditable frente a NIS2 y DORA. Son controles ISO enriquecidos con atributos de cumplimiento cruzado en la guía Zenith Controls.
| Control ISO/IEC 27002:2022 | Nombre del control | Atributos de Zenith Controls | Por qué importa para la gobernanza de la SoA |
|---|---|---|---|
| 5.31 | Requisitos legales, estatutarios, reglamentarios y contractuales | Preventivo, confidencialidad, integridad y disponibilidad (CID), identificar, legal y cumplimiento, gobernanza, ecosistema, protección | Establece la base de obligaciones que impulsa la inclusión de controles y la asignación de responsables |
| 5.35 | Revisión independiente de la seguridad de la información | Preventivo y correctivo, confidencialidad, integridad y disponibilidad (CID), identificar y proteger, aseguramiento de la seguridad de la información, gobernanza, ecosistema | Aporta aseguramiento de que las decisiones de la SoA y las evidencias de implantación pueden soportar una revisión independiente |
| 5.36 | Cumplimiento de políticas, reglas y normas de seguridad de la información | Preventivo, confidencialidad, integridad y disponibilidad (CID), identificar y proteger, legal y cumplimiento, aseguramiento de la seguridad de la información, gobernanza, ecosistema | Conecta la SoA con la conformidad operativa, el cumplimiento de políticas y la supervisión |
Estos controles no están aislados. Se conectan directamente con los controles de relaciones con proveedores A.5.19 a A.5.23, los controles de gestión de incidentes A.5.24 a A.5.28, los controles de continuidad A.5.29 y A.5.30, el control de privacidad A.5.34, la gestión de vulnerabilidades A.8.8, la gestión de configuraciones A.8.9, las copias de seguridad de información A.8.13, el registro de eventos A.8.15, las actividades de supervisión A.8.16, la criptografía A.8.24, los controles de desarrollo seguro A.8.25 a A.8.29 y la gestión de cambios A.8.32.
El valor de Zenith Controls es que ayuda a los equipos a evitar tratar la SoA como un artefacto de una sola norma. El control 5.31 respalda el mapeo legal y contractual. El control 5.35 respalda la auditoría interna, la revisión independiente y el aseguramiento de la dirección. El control 5.36 respalda el cumplimiento operativo de políticas, procedimientos, normas y requisitos de control.
Utiliza Zenith Blueprint para construir, probar y defender la SoA
En Zenith Blueprint: An Auditor’s 30-Step Roadmap Zenith Blueprint, Clarysec sitúa la construcción de la SoA en la fase de Gestión de riesgos, paso 13: Planificación del tratamiento de riesgos y Declaración de Aplicabilidad. El Blueprint indica a las organizaciones que utilicen la hoja de SoA de la plantilla “Risk Register and SoA Builder.xlsx”, decidan si cada uno de los 93 controles del Anexo A es aplicable y basen la decisión en el tratamiento de riesgos, los requisitos legales y contractuales, la relevancia para el alcance y el contexto de la organización.
El Blueprint establece:
La SoA es, en la práctica, un documento puente: vincula tu evaluación y tratamiento de riesgos con los controles reales que tienes.
Esa frase resume el modelo operativo. La SoA conecta obligaciones, riesgos, políticas, controles, evidencias y conclusiones de auditoría.
Zenith Blueprint también indica a los equipos que incluyan referencias cruzadas a regulaciones en las notas de la SoA cuando proceda. Si un control se implanta por GDPR, NIS2 o DORA, debe aparecer en el registro de riesgos o en las notas de la SoA. Más adelante, en el paso 24, el Blueprint indica a las organizaciones que actualicen la SoA después de la implantación y la verifiquen de forma cruzada con el plan de tratamiento de riesgos. En el paso 30, Preparación para la certificación, revisión final y simulacro de auditoría, el Blueprint dirige a los equipos a confirmar que cada control aplicable del Anexo A tiene evidencias como una política, procedimiento, informe, plan o registro de implantación.
Esa secuencia convierte la SoA en un instrumento vivo de cumplimiento:
- El paso 13 la construye a partir del tratamiento de riesgos y las obligaciones.
- El paso 24 la contrasta con la realidad de la implantación.
- El paso 30 la defiende mediante la revisión final de evidencias y el simulacro de auditoría.
Cómo redactar justificaciones de inclusión que los auditores puedan seguir
Un control debe incluirse cuando existe al menos un factor defendible: tratamiento de riesgos, requisito legal, requisito contractual, relevancia para el alcance, línea de base de higiene de seguridad, expectativa de aseguramiento de clientes u objetivo de resiliencia aprobado por la dirección.
Una fórmula útil es:
Aplicable porque [riesgo u obligación] afecta a [servicio, activo, datos o proceso], y este control proporciona [resultado preventivo, detectivo, correctivo o de resiliencia], evidenciado mediante [política, registro, prueba, informe o salida del sistema].
| Área de control | Justificación débil | Justificación auditable |
|---|---|---|
| Gestión de incidentes | Implantado | Aplicable porque NIS2 Article 23 y las expectativas de DORA sobre el ciclo de vida de incidentes exigen detección, clasificación, escalado, soporte a la notificación, comunicaciones, análisis de causa raíz, recopilación de evidencias y lecciones aprendidas para incidentes que afecten a clientes regulados |
| Seguridad de proveedores | Requerido | Aplicable porque el alojamiento en la nube, los proveedores de soporte y los servicios MDR afectan a la disponibilidad del servicio y a la confidencialidad de los datos, y NIS2 Article 21 junto con las expectativas de DORA sobre riesgo de terceros TIC exigen diligencia debida, salvaguardas contractuales, supervisión, revisión de subcontratistas y planificación de salida |
| Criptografía | En uso | Aplicable porque los datos de clientes, los secretos de autenticación, las copias de seguridad y los datos financieros regulados requieren salvaguardas de confidencialidad e integridad bajo NIS2, DORA, GDPR, contratos con clientes y tratamiento interno de riesgos |
| Revisión independiente | Sí | Aplicable porque la dirección, los clientes y los auditores requieren aseguramiento de que los controles del SGSI, las decisiones de la SoA, las evidencias y los mapeos regulatorios se revisan periódicamente de forma independiente |
Para un proveedor SaaS fintech, una fila de la SoA podría ser así:
| Campo de la SoA | Ejemplo de entrada |
|---|---|
| Control | A.5.19 Gestión de la seguridad de la información en las relaciones con proveedores |
| Aplicabilidad | Sí |
| Justificación | Aplicable porque el alojamiento en la nube, las herramientas de soporte y los servicios MDR afectan a la confidencialidad, la disponibilidad, la detección de incidentes y el aseguramiento de clientes regulados. Respalda las expectativas de NIS2 sobre cadena de suministro, las expectativas de DORA sobre riesgo de terceros TIC para clientes financieros, la responsabilidad proactiva de encargados del tratamiento bajo GDPR y los requisitos contractuales de auditoría. |
| Estado de implantación | Implantado y supervisado |
| Responsable | Responsable de gestión de proveedores |
| Evidencias | Registro de proveedores, lista de verificación de diligencia debida, cláusulas contractuales de seguridad, registros de revisión anual, informes SOC o de aseguramiento, revisión de subcontratistas, plan de salida para proveedores críticos |
| Riesgos vinculados | R-047, R-021, R-034 |
| Políticas vinculadas | Política de seguridad de terceros y proveedores, Política de Cumplimiento Legal y Normativo, Política de gestión de riesgos |
| Frecuencia de revisión | Anual, y ante cambio de proveedor, incidente grave, nuevo cliente regulado o ampliación del servicio |
Esto es auditable porque conecta el control con contexto, riesgo, obligación, implantación, responsabilidad y evidencias.
Cómo justificar exclusiones sin crear exposición de auditoría
Las exclusiones no son fallos. Las exclusiones mal justificadas sí lo son.
ISO/IEC 27001:2022 exige que la SoA justifique los controles excluidos del Anexo A. ISO/IEC 27005:2022 refuerza que la no aplicabilidad debe explicarse y justificarse. La Política de Seguridad de la Información empresarial de Clarysec establece:
La configuración de referencia puede adaptarse; sin embargo, las exclusiones deben documentarse con aprobación formal y justificación en la SoA.
Esta es la cláusula 7.2.2 de la Política de Seguridad de la Información.
La Política de Seguridad de la Información para pymes de Clarysec Política de Seguridad de la Información para pymes establece:
Cualquier desviación de esta política debe documentarse, explicando claramente por qué es necesaria la desviación, qué medidas de protección alternativas están implantadas y la fecha definida para la reevaluación.
Ese requisito procede de la cláusula 7.2.1 de la Política de Seguridad de la Información para pymes.
| Área de control | Justificación de exclusión | Salvaguardas requeridas |
|---|---|---|
| Controles de desarrollo seguro para código interno | No aplicable porque el alcance del SGSI cubre únicamente un servicio de reventa sin desarrollo interno de software, sin modificación de código y sin canalización de CI/CD | Aseguramiento de proveedores, aprobación de cambios, recepción de vulnerabilidades, comunicación con clientes y reevaluación anual |
| Supervisión de seguridad física para instalaciones propias | No aplicable porque la organización no tiene centro de datos, sala de servidores ni oficina propia dentro del alcance del SGSI, y toda la infraestructura de producción es operada por proveedores en la nube auditados | Diligencia debida del proveedor en la nube, controles contractuales, revisiones de acceso, revisión del modelo de responsabilidad compartida y evidencias de informes de aseguramiento del proveedor |
| Determinadas actividades de gestión de soportes en las instalaciones | No aplicable porque no se utilizan soportes extraíbles ni almacenamiento en las instalaciones dentro del servicio incluido en el alcance | Restricciones en endpoints, supervisión DLP cuando proceda, inventario de activos y validación periódica |
Para NIS2 y DORA, las exclusiones requieren especial cuidado. Una empresa SaaS rara vez debería excluir registro de eventos, supervisión, copias de seguridad, gestión de incidentes, control de acceso, seguridad de proveedores o gestión de vulnerabilidades. Incluso cuando un control no esté vinculado a un riesgo específico, puede seguir siendo necesario como línea de base de seguridad, aseguramiento de clientes, expectativa contractual u obligación legal.
La Política de gestión de riesgos para pymes de Clarysec también recuerda a los equipos cómo debe gestionarse el riesgo aceptado:
Aceptar: justificar por qué no se requiere ninguna acción adicional y registrar el riesgo residual.
Esa cláusula, 6.1.1 de la Política de gestión de riesgos para pymes, refleja exactamente el enfoque necesario para exclusiones y decisiones sobre riesgo residual.
Notificación de incidentes: demuestra el flujo de trabajo, no la existencia de la política
NIS2 Article 23 exige la notificación escalonada de incidentes significativos, incluida una alerta temprana dentro de las 24 horas desde que se tenga conocimiento, una notificación dentro de las 72 horas, actualizaciones cuando se soliciten y un informe final dentro del mes siguiente a la notificación de 72 horas. DORA exige que las entidades financieras detecten, gestionen, clasifiquen, escalen, comuniquen y notifiquen incidentes graves relacionados con las TIC, informen a los clientes afectados cuando sea necesario, realicen análisis de causa raíz y mejoren los controles.
Un proveedor SaaS puede no tener que notificar siempre directamente a una autoridad DORA, pero puede necesitar dar soporte a los plazos de notificación de sus clientes financieros. Eso hace que los controles de incidentes sean muy relevantes en la SoA.
Una SoA débil dice: “Existe una política de respuesta a incidentes”.
Una SoA sólida dice: “Aplicable porque la organización debe detectar, evaluar, clasificar, escalar, comunicar, preservar evidencias, respaldar plazos de notificación regulatoria, notificar a los clientes afectados cuando sea contractualmente requerido y aprender de incidentes que afecten a servicios, datos o clientes regulados”.
Las evidencias deben incluir:
- Plan de respuesta a incidentes y matriz de escalado.
- Criterios de clasificación de severidad.
- Flujo de trabajo de notificación a clientes.
- Árbol de decisión de notificación regulatoria cuando proceda.
- Tickets y cronologías de incidentes.
- Registros y alertas de supervisión.
- Registros de ejercicios de mesa.
- Revisión posterior al incidente y acciones correctivas.
- Procedimientos de preservación de evidencias.
La Política de Auditoría y Supervisión del Cumplimiento empresarial de Clarysec Política de Auditoría y Supervisión del Cumplimiento explica por qué esto importa:
Generar evidencias defendibles y una pista de auditoría en apoyo de requerimientos de autoridades reguladoras, procedimientos legales o solicitudes de aseguramiento de clientes.
Ese objetivo procede de la cláusula 3.4 de la Política de Auditoría y Supervisión del Cumplimiento.
Para organizaciones más pequeñas, la conservación de evidencias también debe ser explícita. La Política de Auditoría y Supervisión del Cumplimiento para pymes de Clarysec Política de Auditoría y Supervisión del Cumplimiento para pymes establece:
Las evidencias deben conservarse durante al menos dos años, o durante más tiempo cuando lo exijan la certificación o los acuerdos con clientes.
Esa es la cláusula 6.2.4 de la Política de Auditoría y Supervisión del Cumplimiento para pymes.
Una SoA, múltiples conversaciones de auditoría
La mejor SoA no duplica marcos. Crea una narrativa de controles trazable que distintos auditores pueden entender.
| Marco o perspectiva | Qué preguntará el auditor o evaluador | Cómo ayuda la SoA |
|---|---|---|
| ISO/IEC 27001:2022 | ¿Por qué se incluye o excluye este control del Anexo A, cuál es el estado de implantación y dónde están las evidencias? | Vincula las decisiones de control con riesgos, obligaciones, estado de implantación, responsables y evidencias |
| NIS2 | ¿Cómo funcionan en la práctica la gobernanza, el análisis de riesgos, la gestión de incidentes, la continuidad del negocio, la cadena de suministro, el cifrado, el control de acceso, la gestión de activos y la formación? | Mapea las expectativas de Article 21 y Article 23 a controles del Anexo A y registros operativos |
| DORA | ¿Cómo se evidencian el riesgo TIC, la gestión de incidentes, las pruebas de resiliencia, el riesgo de terceros, los contratos, los derechos de auditoría, los planes de salida y la supervisión de la dirección? | Muestra qué controles respaldan las obligaciones de entidades financieras o el aseguramiento de proveedores SaaS |
| GDPR | ¿Puede la organización demostrar integridad, confidencialidad, responsabilidad proactiva, preparación ante brechas de seguridad, apoyo al tratamiento lícito y controles de encargados del tratamiento? | Vincula las obligaciones de privacidad con controles de acceso, criptografía, registro de eventos, proveedores, incidentes, conservación y evidencias |
| NIST CSF 2.0 | ¿Cómo se respaldan los resultados de Govern, Identify, Protect, Detect, Respond y Recover mediante controles implantados? | Utiliza la misma base de evidencias para mostrar la cobertura funcional de ciberseguridad |
| COBIT 2019 y auditoría ISACA | ¿Están definidos los objetivos de gobernanza, la titularidad de controles, las actividades de aseguramiento, las métricas y la responsabilidad de la dirección? | Conecta las decisiones de la SoA con responsables, revisión del desempeño, revisión independiente y acciones correctivas |
Un auditor de ISO 27001 suele empezar por la lógica de las cláusulas: alcance, partes interesadas, evaluación de riesgos, tratamiento de riesgos, SoA, objetivos, auditoría interna, revisión por la dirección y mejora. Un revisor orientado a NIS2 se centra en proporcionalidad, responsabilidad de la dirección, formación, cadena de suministro, plazos de incidentes e impacto en el servicio. Un evaluador de cliente orientado a DORA se centra en riesgo TIC, funciones críticas o importantes, incidentes TIC graves, pruebas de resiliencia, cláusulas contractuales, derechos de auditoría, planes de salida, subcontratación y riesgo de concentración. Un revisor de privacidad se centra en la responsabilidad proactiva bajo GDPR y la preparación ante brechas de seguridad. Un auditor con enfoque COBIT 2019 o ISACA comprueba gobernanza, métricas, titularidad, aseguramiento y acciones correctivas.
Por eso la SoA no puede mantenerse solo por el equipo de seguridad. Necesita titularidad de las funciones legal, privacidad, compras, ingeniería, operaciones, Recursos Humanos y alta dirección.
Fallos comunes de la SoA en proyectos de preparación frente a NIS2 y DORA
Clarysec encuentra repetidamente los mismos problemas en proyectos de preparación:
- La SoA marca controles como aplicables, pero no se registra ningún riesgo, obligación o motivo de negocio.
- NIS2 y DORA se mencionan en políticas, pero no se mapean a controles, responsables ni evidencias.
- Los controles de proveedores se marcan como implantados, pero no existe registro de proveedores, clasificación de criticidad, revisión contractual ni plan de salida.
- Existen controles de incidentes, pero el proceso no soporta flujos de trabajo de notificación a 24 horas, 72 horas, clientes o informe final.
- La aprobación de la dirección se da por supuesta, pero no existe registro de aceptación del riesgo, aprobación de la SoA ni decisión sobre riesgo residual.
- Las exclusiones se copian de una plantilla y no se corresponden con el modelo operativo real en la nube, remoto, SaaS o fintech.
- Existen evidencias repartidas entre herramientas, pero ninguna pista de auditoría conecta las evidencias con la SoA.
- El tratamiento de datos personales bajo GDPR no está vinculado a controles de seguridad, respuesta ante brechas de seguridad, contratos con proveedores ni conservación.
- La auditoría interna revisa documentos, pero no comprueba si la SoA refleja la implantación real.
- La SoA se actualiza solo antes de la certificación, no después de nuevos clientes, proveedores, incidentes, hallazgos de auditoría o cambios regulatorios.
No son problemas de documentación. Son problemas de gobernanza.
Lista de verificación práctica para una SoA ISO 27001 auditable
Utiliza esta lista de verificación antes de una auditoría de certificación ISO 27001, una revisión de preparación NIS2, una evaluación de cliente DORA, una reunión del Consejo de Administración o un proceso de diligencia debida de inversores.
| Punto de control | Buena respuesta |
|---|---|
| Alcance | El alcance del SGSI refleja servicios, clientes, datos, proveedores, interfaces externalizadas y dependencias reguladas |
| Partes interesadas | Se identifican NIS2, clientes DORA, roles bajo GDPR, reguladores, clientes, proveedores y partes interesadas internas |
| Registro de cumplimiento | Las obligaciones legales, regulatorias, contractuales y de clientes se mapean a políticas, controles y responsables |
| Criterios de riesgo | Se incluyen impactos legales, operativos, de privacidad, de proveedores, de resiliencia, financieros y reputacionales |
| Registro de riesgos | Cada riesgo incluye descripción, probabilidad, impacto, puntuación, propietario, plan de tratamiento y riesgo residual |
| Inclusión en la SoA | Cada control aplicable tiene una justificación vinculada a riesgo, obligación, alcance, contrato o línea de base de seguridad |
| Exclusión en la SoA | Cada control excluido tiene una justificación específica, aprobada, basada en evidencias y con disparador de revisión |
| Evidencias | Cada control aplicable tiene evidencias de política, procedimiento, configuración, informe, prueba, ticket, registro, revisión o registro formal |
| Aprobación de la dirección | Los propietarios de riesgos aprueban los planes de tratamiento y los riesgos residuales, y la dirección revisa el desempeño del SGSI |
| Revisión independiente | La auditoría interna o revisión independiente comprueba la exactitud de la SoA, la calidad de las evidencias y la realidad de la implantación |
| Disparadores de actualización | Las actualizaciones de la SoA se realizan tras cambios de servicio, cambios de proveedor, incidentes, nuevos clientes, cambios regulatorios o hallazgos de auditoría |
Convierte la SoA en un puente de cumplimiento defendible
La presentación de Elena ante el Consejo de Administración tuvo éxito porque no presentó tres proyectos de cumplimiento desconectados. Presentó un único modelo operativo controlado y basado en evidencias, construido sobre ISO/IEC 27001:2022, con la SoA como puente entre regulación, riesgo, implantación de controles, evidencias y supervisión de la dirección.
NIS2 y DORA no hacen que ISO 27001 quede obsoleta. Hacen que una Declaración de Aplicabilidad de ISO 27001 bien construida sea más valiosa. La SoA puede convertirse en el lugar único donde tu organización explica por qué existen los controles, por qué las exclusiones son defendibles, cómo se conservan las evidencias, cómo se gobiernan los proveedores, cómo se escalan los incidentes y cómo sabe la dirección que el SGSI funciona.
Tu acción inmediata es sencilla:
- Abre tu SoA actual.
- Elige cinco controles marcados como aplicables y pregunta: “¿Qué riesgo, obligación o contrato justifica esto?”.
- Elige cinco exclusiones y pregunta: “¿Seguiría teniendo sentido para un auditor NIS2, DORA, GDPR o ISO/IEC 27001:2022?”.
- Comprueba si cada control aplicable tiene evidencias actuales.
- Confirma que la dirección ha aprobado los riesgos residuales y las decisiones de la SoA.
- Actualiza el registro de cumplimiento, el registro de riesgos y la SoA siempre que cambien servicios, proveedores, clientes, regulaciones o incidentes.
Clarysec ayuda a las organizaciones a hacerlo mediante Zenith Blueprint Zenith Blueprint, Zenith Controls Zenith Controls, conjuntos de políticas para empresas y pymes, herramientas de registro de riesgos, plantillas de SoA, preparación para auditorías y mapeo de cumplimiento cruzado para NIS2, DORA, GDPR, NIST CSF 2.0, COBIT 2019 y aseguramiento de clientes.
Si tu SoA no puede responder por qué, quién es responsable, qué evidencias lo demuestran y qué obligación respalda, aún no está preparada. Utiliza Clarysec para convertirla en un puente de cumplimiento auditable antes de que un regulador, auditor o cliente formule primero esas mismas preguntas.
Frequently Asked Questions
About the Author
Igor Petreski
Compliance Systems Architect, Clarysec LLC
Igor Petreski is a cybersecurity leader with over 30 years of experience in information technology and a dedicated decade specializing in global Governance, Risk, and Compliance (GRC).Core Credentials & Qualifications:• MSc in Cyber Security from Royal Holloway, University of London• PECB-Certified ISO/IEC 27001 Lead Auditor & Trainer• Certified Information Systems Auditor (CISA) from ISACA• Certified Information Security Manager (CISM) from ISACA • Certified Ethical Hacker from EC-Council
