Evidencias de auditoría de ISO 27001 para NIS2 y DORA
Son las 08:17 de un martes y el director de seguridad de la información (CISO) de una empresa fintech SaaS en rápido crecimiento tiene tres mensajes pendientes.
El primero es de un cliente bancario importante: «Envíen su último informe de auditoría interna, las actas de revisión por la dirección, el estado de las acciones correctivas, el procedimiento de notificación de incidentes, el registro de proveedores y evidencias de supervisión por parte del consejo de administración».
El segundo es del director financiero (CFO): «¿Estamos dentro del alcance de NIS2 o DORA, y qué evidencias tenemos ya?».
El tercero es del director general (CEO): «¿Podemos decir que estamos preparados para auditorías?».
La respuesta incómoda en muchas organizaciones no es que no se esté haciendo nada. Es peor. El trabajo de seguridad se realiza en todas partes, pero las evidencias no están en ninguna. Hay controles, pero no existe pista de auditoría. Hay tickets, pero no una vinculación clara con los riesgos. Hay actualizaciones a la dirección, pero no resultados formales de revisión por la dirección. Hay conversaciones con proveedores, pero no existe un registro de proveedores defendible, ni revisión contractual, ni estrategia de salida.
Esa brecha es precisamente donde la auditoría interna y la revisión por la dirección de ISO/IEC 27001:2022 dejan de ser meras actividades de certificación. Se convierten en el ritmo operativo para NIS2, DORA, GDPR, aseguramiento de clientes, ciberseguros y rendición de cuentas del órgano de dirección.
Los equipos SaaS, de nube, MSP, MSSP y fintech rara vez fallan por falta de actividad de seguridad. Fallan porque la actividad está dispersa entre Slack, Jira, hojas de cálculo, portales de proveedores, tickets del SOC, expedientes de compras y presentaciones al consejo. Un regulador, auditor externo o cliente empresarial no quiere una explicación heroica. Quiere evidencias objetivas.
La solución práctica no consiste en ejecutar programas de auditoría separados para cada marco. Consiste en utilizar el SGSI de ISO 27001 como motor central de evidencias y etiquetar esas evidencias para NIS2, DORA, GDPR y requisitos contractuales. Bien ejecutado, un ciclo de auditoría interna y un ciclo de revisión por la dirección pueden responder a muchas preguntas de cumplimiento.
De la fatiga de marcos a un modelo unificado de evidencias del SGSI
Muchos CISO se enfrentan a una versión del problema de María. María dirige la seguridad de una empresa B2B SaaS con clientes del sector financiero. Su equipo superó una auditoría de certificación ISO/IEC 27001:2022 hace seis meses. El SGSI está madurando, las políticas se aplican y los responsables de controles comprenden sus responsabilidades. Entonces el CEO le reenvía dos artículos, uno sobre la Directiva NIS2 y otro sobre DORA, con una pregunta breve: «¿Estamos cubiertos?».
La respuesta depende del alcance, los servicios, los clientes y las entidades jurídicas. Pero la respuesta operativa es clara: si María trata NIS2 y DORA como proyectos de cumplimiento separados, generará trabajo duplicado, evidencias incoherentes y una fatiga de auditoría creciente. Si los trata como requisitos de partes interesadas dentro del SGSI, puede usar ISO 27001 para incorporarlos, probarlos y demostrar preparación.
ISO/IEC 27001:2022 está diseñado para ello. La cláusula 4 exige que la organización comprenda su contexto y los requisitos de las partes interesadas, incluidas las obligaciones legales, regulatorias, contractuales y derivadas de dependencias. La cláusula 5 exige liderazgo e integración en los procesos de la organización. La cláusula 6 exige evaluación de riesgos y tratamiento de riesgos. La cláusula 9 exige evaluación del desempeño mediante monitorización, auditoría interna y revisión por la dirección. La cláusula 10 exige mejora y acción correctiva.
NIS2 y DORA encajan de forma natural en esa estructura.
NIS2 exige que las entidades esenciales e importantes implanten medidas técnicas, operativas y organizativas adecuadas y proporcionadas de gestión de riesgos de ciberseguridad. También atribuye responsabilidad a los órganos de dirección para aprobar esas medidas, supervisar su implantación y poder responder por los incumplimientos. Sus medidas mínimas cubren análisis de riesgos, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, desarrollo seguro, gestión de vulnerabilidades, evaluación de la eficacia, formación, criptografía, seguridad de recursos humanos, control de acceso, gestión de activos y, cuando proceda, autenticación multifactor o autenticación continua.
DORA es aplicable desde el 17 de enero de 2025 y crea un régimen sectorial de resiliencia operativa digital para entidades financieras. Exige responsabilidad del órgano de dirección sobre la gestión del riesgo de las TIC, un marco de gestión del riesgo de las TIC documentado, una estrategia de resiliencia operativa digital, planes de continuidad y recuperación de las TIC, pruebas de resiliencia, gobernanza de incidentes relacionados con las TIC y gestión del riesgo de terceros proveedores de servicios TIC. Para proveedores SaaS y de nube que prestan servicios a entidades financieras, DORA puede aparecer a través de obligaciones contractuales, auditorías de clientes y expectativas de gestión del riesgo de terceros proveedores de servicios TIC, incluso cuando el proveedor no sea en sí mismo una entidad financiera.
GDPR añade la capa de responsabilidad proactiva. Cuando se tratan datos personales dentro del alcance de GDPR, las organizaciones deben poder demostrar el cumplimiento de los principios de protección de datos y de las medidas técnicas y organizativas adecuadas.
ISO 27001 no es un certificado mágico de cumplimiento para estas obligaciones. Es el sistema de gestión que permite organizarlas, evidenciarlas y mejorarlas.
La cuestión del alcance: qué está demostrando y para quién
Antes de construir un paquete de evidencias preparado para auditorías, la dirección debe responder a una pregunta básica: ¿qué obligaciones están dentro del alcance?
Para negocios SaaS y de nube, el alcance de NIS2 puede ser más amplio de lo previsto. NIS2 se aplica a entidades públicas o privadas de sectores enumerados que cumplen umbrales de tamaño, y a determinadas entidades de alto impacto con independencia de su tamaño. Los sectores pertinentes pueden incluir infraestructura digital, proveedores de servicios de computación en la nube, proveedores de centros de datos, redes de distribución de contenidos, proveedores de servicios de confianza, proveedores públicos de comunicaciones electrónicas y proveedores B2B de gestión de servicios TIC, como proveedores de servicios gestionados y proveedores de servicios de seguridad gestionados. Los proveedores SaaS deben prestar especial atención a cómo se prestan los servicios, qué sectores soportan y si habilitan administración bajo demanda y acceso remoto amplio a recursos informáticos compartidos y escalables.
Para proveedores fintech y de servicios al sector financiero, DORA debe analizarse por separado. DORA cubre directamente una amplia gama de entidades financieras, incluidas entidades de crédito, entidades de pago, proveedores de servicios de información sobre cuentas, entidades de dinero electrónico, empresas de servicios de inversión, proveedores de servicios de criptoactivos, centros de negociación, gestores de fondos, empresas de seguros y reaseguros y proveedores de servicios de financiación participativa. Los proveedores terceros de servicios TIC también forman parte del ecosistema DORA porque las entidades financieras deben gestionar sus dependencias TIC, mantener registros de acuerdos contractuales e incluir disposiciones contractuales específicas para servicios TIC que soporten funciones críticas o importantes.
NIS2 y DORA también interactúan. Cuando un acto jurídico sectorial de la UE impone requisitos equivalentes de gestión de riesgos de ciberseguridad o notificación de incidentes, las disposiciones correspondientes de NIS2 pueden no aplicarse a esas entidades en esas materias. DORA es el régimen sectorial de resiliencia operativa para entidades financieras. Eso no convierte a NIS2 en irrelevante para todos los proveedores de su entorno. Significa que el modelo de evidencias debe distinguir si la organización es una entidad financiera directamente sujeta a DORA, un proveedor tercero de servicios TIC que da soporte a entidades financieras, un proveedor SaaS dentro del alcance de NIS2 o un grupo con múltiples entidades jurídicas y líneas de servicio.
Este análisis de alcance pertenece al contexto del SGSI y al registro de partes interesadas. Sin él, el plan de auditoría probará cuestiones equivocadas.
Una pista de auditoría, muchas preguntas de cumplimiento
Un error habitual es crear paquetes de evidencias separados para ISO 27001, NIS2, DORA, GDPR, ciberseguros y auditorías de clientes. Ese enfoque genera duplicidades y respuestas contradictorias. Un enfoque mejor es un único modelo de evidencias con múltiples perspectivas.
En el centro está el SGSI. A su alrededor se sitúan cinco familias de evidencias.
| Familia de evidencias | Qué demuestra | Registros típicos |
|---|---|---|
| Evidencias de gobernanza | La dirección aprobó, dotó de recursos y revisó el SGSI | Política de seguridad de la información, roles, plan de auditoría, actas de revisión por la dirección, informes al consejo |
| Evidencias de riesgo | Los riesgos se identificaron, evaluaron, asignaron y trataron | Criterios de riesgo, registro de riesgos, plan de tratamiento de riesgos, Declaración de aplicabilidad, aprobaciones de riesgo residual |
| Evidencias de control | Los controles operan según su diseño | Revisiones de acceso, pruebas de restauración, alertas de monitorización, informes de vulnerabilidades, diligencia debida de proveedores, registros de desarrollo seguro |
| Evidencias de aseguramiento | Comprobaciones independientes o internas detectaron deficiencias y verificaron la conformidad | Plan de auditoría interna, lista de verificación de auditoría, informe de auditoría, registro de no conformidades, registro CAPA |
| Evidencias de mejora | Los hallazgos derivaron en corrección, análisis de causa raíz y mejora continua | Planes de acciones correctivas, lecciones aprendidas, decisiones de la dirección, políticas actualizadas, registros de repetición de pruebas |
Esta estructura se alinea con Zenith Blueprint: hoja de ruta de 30 pasos para auditores Zenith Blueprint. En la fase de auditoría, revisión y mejora, el paso 25 se centra en el programa de auditoría interna, el paso 26 en la ejecución de la auditoría, el paso 28 en la revisión por la dirección y el paso 29 en la mejora continua.
La orientación del paso 25 de Blueprint es deliberadamente práctica:
«Desarrolle un calendario que describa cuándo se realizarán las auditorías y qué cubrirán».
«Utilice la plantilla de plan de auditoría interna si se proporciona; puede ser un documento sencillo o una hoja de cálculo que enumere fechas de auditoría, alcance y auditores asignados».
De Zenith Blueprint, fase de auditoría, revisión y mejora, paso 25: programa de auditoría interna Zenith Blueprint
Ese plan de auditoría sencillo se vuelve potente cuando está basado en riesgos y etiquetado frente a obligaciones NIS2, DORA y GDPR.
Controles ISO 27001 que sustentan la preparación para auditorías
Para la preparación para auditorías, tres controles de ISO/IEC 27002:2022 son especialmente importantes cuando se interpretan a través de Zenith Controls: guía de cumplimiento cruzado Zenith Controls:
- 5.4 Responsabilidades de la dirección
- 5.35 Revisión independiente de la seguridad de la información
- 5.36 Cumplimiento de políticas, normas y estándares de seguridad de la información
No son «controles Zenith» separados. Son controles de ISO/IEC 27002:2022 que Zenith Controls ayuda a mapear, auditar e interpretar entre marcos.
El control 5.4 pregunta si las responsabilidades de seguridad de la información están asignadas y comprendidas. El control 5.35 pregunta si la seguridad de la información se revisa de forma independiente. El control 5.36 pregunta si la organización cumple sus políticas, normas y estándares.
Zenith Controls clasifica el control 5.35 con un enfoque orientado al aseguramiento:
El control 5.35 de ISO/IEC 27002:2022, «Revisión independiente de la seguridad de la información», se trata en Zenith Controls como «Preventivo, Correctivo», y respalda la confidencialidad, integridad y disponibilidad mediante los conceptos de ciberseguridad «Identificar» y «Proteger», con capacidad operativa en «Aseguramiento de la seguridad de la información». Zenith Controls
Esto importa porque la auditoría interna es preventiva y correctiva a la vez. Previene puntos ciegos al probar el SGSI antes del escrutinio externo y corrige debilidades mediante acciones documentadas.
La matriz de correspondencia más amplia parte de los requisitos de NIS2 y DORA y, después, identifica las evidencias de ISO 27001 que pueden demostrarlos.
| Tema regulatorio | Evidencias de ISO/IEC 27001:2022 e ISO/IEC 27002:2022 | Foco práctico de auditoría |
|---|---|---|
| Responsabilidad proactiva de la dirección | Cláusulas 5, 9.3 y controles 5.2, 5.4, 5.35, 5.36 | Aprobaciones de la dirección, actas de revisión, asignación de roles, decisiones CAPA |
| Análisis de riesgos y políticas de seguridad | Cláusulas 4, 6.1, 6.2 y controles 5.1, 5.7, 5.9, 5.31 | Criterios de riesgo, registro de riesgos, aprobaciones de políticas, requisitos legales y contractuales |
| Gestión de incidentes | Controles 5.24, 5.25, 5.26, 5.27, 5.28 | Clasificación, escalado, registros de respuesta, lecciones aprendidas, preservación de evidencias |
| Continuidad de negocio y recuperación | Controles 5.29, 5.30, 8.13 | Planes de continuidad, preparación TIC, pruebas de restauración de copias de seguridad, métricas de recuperación |
| Riesgo de proveedores y nube | Controles 5.19, 5.20, 5.21, 5.22, 5.23 | Diligencia debida de proveedores, contratos, monitorización, planes de salida de la nube, riesgo de concentración |
| Desarrollo seguro y vulnerabilidades | Controles 8.8, 8.25, 8.26, 8.27, 8.28, 8.29 | SLA de vulnerabilidades, registros de SDLC seguro, aprobaciones de cambios, pruebas de seguridad |
| Acceso, recursos humanos y formación | Controles 5.15, 5.16, 5.17, 5.18, 6.1, 6.2, 6.3, 6.5, 6.6, 6.7 | Revisiones de acceso, muestras de altas, cambios y bajas, registros de concienciación, controles de trabajo remoto |
| Registro, monitorización y criptografía | Controles 8.15, 8.16, 8.17, 8.24 | Conservación de registros, revisión de alertas, sincronización horaria, estándares de cifrado |
| Privacidad y cumplimiento legal | Controles 5.31, 5.34, 5.36 | Registro legal, controles de privacidad, evidencias de encargados del tratamiento, revisiones de cumplimiento |
El mapeo de controles solo es útil cuando las evidencias son sólidas. Si el registro es débil, ninguna matriz de correspondencia lo salvará. Si el registro está completo, las mismas evidencias pueden responder a preguntas de estilo ISO, NIS2, DORA, GDPR, NIST Cybersecurity Framework 2.0 y COBIT 2019.
Evidencias de políticas que Clarysec espera que las organizaciones conserven
Las políticas de Clarysec convierten la teoría del SGSI en expectativas de evidencias.
Para pymes, Política de auditoría y supervisión del cumplimiento-sme Política de auditoría y supervisión del cumplimiento-sme exige aprobación de la dirección y disciplina de auditoría:
«El director general (DG) debe aprobar un plan de auditoría anual».
De Política de auditoría y supervisión del cumplimiento-sme, requisitos de gobernanza, cláusula 5.1.1 Política de auditoría y supervisión del cumplimiento-sme
También establece una cadencia mínima:
«Las auditorías internas o revisiones de cumplimiento deben realizarse al menos anualmente».
De Política de auditoría y supervisión del cumplimiento-sme, requisitos de gobernanza, cláusula 5.2.1
Y conecta los hallazgos con la corrección y la revisión por la dirección:
«El DG debe aprobar un plan de acciones correctivas y hacer seguimiento de su implantación».
De Política de auditoría y supervisión del cumplimiento-sme, requisitos de gobernanza, cláusula 5.4.2
«Los hallazgos de auditoría y las actualizaciones de estado deben incluirse en el proceso de revisión por la dirección del SGSI».
De Política de auditoría y supervisión del cumplimiento-sme, requisitos de gobernanza, cláusula 5.4.3
La conservación de evidencias también es explícita:
«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».
De Política de auditoría y supervisión del cumplimiento-sme, requisitos de implantación de la política, cláusula 6.2.4
Para organizaciones más grandes, Política de auditoría y supervisión del cumplimiento Política de auditoría y supervisión del cumplimiento, también referenciada en algunos materiales de Clarysec como P33 Política de auditoría y supervisión del cumplimiento, amplía la estructura:
«Se elaborará y aprobará anualmente un plan de auditoría basado en riesgos, teniendo en cuenta:»
De Política de auditoría y supervisión del cumplimiento, requisitos de gobernanza, cláusula 5.2 Política de auditoría y supervisión del cumplimiento
«La organización mantendrá un registro de auditorías que contenga:»
De Política de auditoría y supervisión del cumplimiento, requisitos de gobernanza, cláusula 5.4
«Las auditorías internas seguirán un procedimiento documentado que incluya:»
De Política de auditoría y supervisión del cumplimiento, requisitos de implantación de la política, cláusula 6.1.1
«Todos los hallazgos darán lugar a una CAPA documentada que incluya:»
De Política de auditoría y supervisión del cumplimiento, requisitos de implantación de la política, cláusula 6.2.1
La revisión por la dirección se apoya en la Política de seguridad de la información Política de seguridad de la información, también referenciada en algunos materiales de Clarysec como P01 Política de seguridad de la información:
«Las actividades de revisión por la dirección (según la cláusula 9.3 de ISO/IEC 27001) se realizarán al menos anualmente e incluirán:»
De Política de seguridad de la información, requisitos de gobernanza, cláusula 5.3 Política de seguridad de la información
Estos requisitos crean la cadena de evidencias que esperan los auditores: plan aprobado, procedimiento definido, registro de auditorías, hallazgos, CAPA, conservación y revisión por la dirección.
Construcción del paquete de evidencias preparado para auditorías
Un paquete de evidencias preparado para auditorías no es una carpeta enorme creada dos días antes de la auditoría. Es una estructura viva mantenida durante todo el año.
| Elemento de evidencia | Propósito en ISO 27001 | Relevancia para NIS2 y DORA |
|---|---|---|
| Alcance del SGSI y registro de partes interesadas | Demuestra que se identifican requisitos legales, contractuales y derivados de dependencias | Respalda el alcance de la entidad en NIS2, el análisis del rol en DORA y la responsabilidad proactiva en GDPR |
| Criterios de riesgo y registro de riesgos | Demuestra una evaluación de riesgos y una asignación de responsabilidades coherentes | Respalda las medidas de gestión de riesgos de NIS2 y el marco de riesgo TIC de DORA |
| Declaración de aplicabilidad | Demuestra controles seleccionados, justificación y estado de implantación | Crea una línea base de controles consolidada para cumplimiento cruzado |
| Plan anual de auditoría interna | Demuestra aseguramiento planificado | Respalda la supervisión de la dirección y la planificación de auditoría TIC de DORA |
| Lista de verificación de auditoría interna | Demuestra criterios de auditoría y método de muestreo | Demuestra cómo se probaron los requisitos de NIS2, DORA y GDPR |
| Informe de auditoría y registro de hallazgos | Muestra evidencias objetivas y no conformidades | Respalda la evaluación de eficacia y el aseguramiento regulatorio |
| Registro CAPA | Muestra causa raíz, responsable, fecha límite y cierre | Respalda medidas correctivas en NIS2 y remediación en DORA |
| Paquete de revisión por la dirección | Demuestra la revisión por la dirección del desempeño, incidentes, riesgos y recursos | Respalda la rendición de cuentas del órgano de dirección en NIS2 y DORA |
| Registro de proveedores y evidencias contractuales | Demuestra el control del riesgo de terceros | Respalda la seguridad de la cadena de suministro en NIS2 y la gestión del riesgo de terceros proveedores de servicios TIC en DORA |
| Registros de notificación de incidentes y lecciones aprendidas | Demuestra respuesta y mejora | Respalda la notificación escalonada de NIS2 y la gobernanza de incidentes de DORA |
El paquete de evidencias debe mapearse a las cláusulas de ISO/IEC 27001:2022 y a los controles del Anexo A, pero etiquetarse por relevancia regulatoria. Un registro de auditoría de proveedor, por ejemplo, puede respaldar controles de proveedores del Anexo A, seguridad de la cadena de suministro de NIS2 y gestión del riesgo de terceros proveedores de servicios TIC de DORA. Un registro de ejercicio de simulación de incidentes puede respaldar la gestión de incidentes de ISO 27001, la preparación para la notificación escalonada de NIS2 y la gobernanza de incidentes graves relacionados con TIC de DORA.
Cómo realizar la auditoría interna integrada
El paso 26 de Zenith Blueprint enfatiza las evidencias objetivas:
«Realice la auditoría recopilando evidencias objetivas para cada elemento de su lista de verificación».
«Entreviste al personal pertinente».
«Revise la documentación».
«Observe las prácticas».
«Muestree y realice comprobaciones aleatorias».
De Zenith Blueprint, fase de auditoría, revisión y mejora, paso 26: ejecución de auditoría Zenith Blueprint
Eso es exactamente lo que exige la preparación para NIS2 y DORA. Reguladores y clientes no aceptarán «creemos que esto funciona». Preguntarán cómo lo sabe.
Una auditoría bien ejecutada prueba cuatro dimensiones de evidencia.
| Dimensión de evidencia | Prueba de auditoría de ejemplo | Buena evidencia |
|---|---|---|
| Diseño | ¿La política o el proceso define el requisito? | Política aprobada, procedimiento, estándar, flujo de trabajo |
| Implantación | ¿Se ha desplegado el proceso? | Tickets, configuraciones, registros de formación, registros de proveedores |
| Eficacia operativa | ¿Funcionó a lo largo del tiempo? | Muestras de varios meses, alertas, revisiones de registros, resultados de pruebas |
| Escalado de gobernanza | ¿La dirección vio los resultados y actuó sobre ellos? | Aprobación CAPA, actas de revisión por la dirección, decisión presupuestaria |
Considere un evento simulado de ransomware en un servidor de preproducción. El auditor comprueba si el proceso de respuesta a incidentes puede cumplir los requisitos de ISO 27001, las expectativas de notificación escalonada de NIS2 y las obligaciones frente a clientes en DORA.
| Evidencia recopilada | Relevancia para ISO 27001 | Relevancia para NIS2 | Relevancia para DORA |
|---|---|---|---|
| Registro de incidentes con clasificación inicial y marca temporal | Control 5.26 respuesta a incidentes de seguridad de la información | Establece el momento de conocimiento para los plazos de notificación | Respalda la identificación y el registro de incidentes relacionados con TIC |
| Escalado al CSIRT y a asesores jurídicos | Control 5.25 evaluación y decisión sobre eventos de seguridad de la información | Respalda la toma de decisiones para la notificación de incidentes significativos | Respalda los procedimientos de comunicación interna y escalado |
| Borrador de plantilla de notificación de alerta temprana | Control 5.24 planificación y preparación de la gestión de incidentes | Respalda la capacidad de cumplir la expectativa de alerta temprana en 24 horas | Puede respaldar la preparación de comunicaciones contractuales |
| Registro de decisión de restauración de copia de seguridad | Controles 5.29, 5.30 y 8.13 | Respalda evidencias de continuidad de negocio y recuperación ante desastres | Respalda expectativas de respuesta, recuperación y restauración de copias de seguridad |
| Registro de comunicación con clientes | Controles 5.20 y 5.22 acuerdos con proveedores y monitorización de los servicios de proveedores | Puede respaldar comunicaciones contractuales y de cadena de suministro | Respalda obligaciones de riesgo de terceros frente a clientes financieros |
NIS2 tiene una estructura de notificación escalonada para incidentes significativos, incluida una alerta temprana dentro de las 24 horas desde el conocimiento, una notificación de incidente dentro de las 72 horas y un informe final dentro de un mes desde la notificación del incidente. DORA tiene su propio marco de clasificación y notificación de incidentes relacionados con TIC para entidades financieras. La auditoría interna debe verificar que los procedimientos de actuación capturan la hora de conocimiento, los criterios de severidad, los servicios afectados, los indicadores de compromiso, las acciones de mitigación, la causa raíz, las obligaciones de notificación a clientes y los datos del informe final.
Convertir un hallazgo de auditoría en evidencia para NIS2 y DORA
Un hallazgo realista sobre proveedores muestra cómo deben fluir las evidencias.
Durante la auditoría interna, el auditor toma muestras de cinco proveedores críticos. Un proveedor de registros en la nube soporta la monitorización antifraude y la generación de alertas de seguridad de la plataforma fintech. El proveedor figura en el inventario, pero no existe un plan de salida documentado, no hay evidencia de revisión anual de seguridad y no se ha confirmado que el contrato incluya asistencia en incidentes o derechos de auditoría.
El auditor registra una no conformidad frente a los requisitos de seguridad de proveedores y salida de la nube. Una respuesta débil diría «falta revisión de proveedor». Una respuesta sólida crea una cadena de evidencias de cumplimiento cruzado:
- Registre el hallazgo en el informe de auditoría, incluido el tamaño de la muestra, el nombre del proveedor, la referencia contractual y las evidencias faltantes.
- Añada una entrada CAPA con causa raíz, por ejemplo: «la lista de verificación de incorporación de proveedores no incluía clasificación de criticidad ni activador de plan de salida».
- Asigne el responsable del proveedor y el propietario del riesgo.
- Actualice el registro de proveedores para marcar el servicio como soporte de una función crítica o importante.
- Realice una evaluación de riesgos que cubra interrupción del servicio, acceso a datos, riesgo de concentración, dependencia de notificación de incidentes y brechas contractuales.
- Actualice el plan de tratamiento de riesgos y la Declaración de aplicabilidad cuando proceda.
- Obtenga una adenda contractual actualizada o una aceptación del riesgo documentada.
- Cree o pruebe un plan de salida.
- Vuelva a auditar las evidencias del proveedor tras la remediación.
- Informe del hallazgo, el riesgo y las necesidades de recursos en la revisión por la dirección.
Esta única cadena respalda múltiples obligaciones. NIS2 espera seguridad de la cadena de suministro y consideración de las vulnerabilidades de proveedores, prácticas de ciberseguridad y procedimientos de desarrollo seguro. DORA exige que las entidades financieras gestionen el riesgo de terceros proveedores de servicios TIC, mantengan registros de acuerdos contractuales, evalúen a los proveedores antes de contratar, incluyan derechos de auditoría e inspección cuando proceda, mantengan derechos de terminación y documenten estrategias de salida para servicios TIC que soporten funciones críticas o importantes. GDPR también puede ser relevante si el proveedor trata datos personales.
El registro de auditoría ya no es solo evidencia de cumplimiento. Es evidencia de resiliencia.
Revisión por la dirección: donde la evidencia se convierte en responsabilidad proactiva
La auditoría interna encuentra la realidad. La revisión por la dirección decide qué hacer con ella.
El paso 28 de Zenith Blueprint describe el paquete de entradas para la revisión por la dirección:
«ISO 27001 especifica varias entradas obligatorias para la revisión por la dirección. Prepare un informe breve o una presentación que cubra estos puntos».
Blueprint enumera el estado de acciones previas, cambios en cuestiones externas e internas, desempeño y eficacia del SGSI, incidentes o no conformidades, oportunidades de mejora y necesidades de recursos.
De Zenith Blueprint, fase de auditoría, revisión y mejora, paso 28: revisión por la dirección Zenith Blueprint
Para NIS2 y DORA, la revisión por la dirección es donde se hace visible la rendición de cuentas a nivel del órgano de dirección. La revisión no debe limitarse a decir «se habló de seguridad». Debe mostrar que la dirección revisó:
- Cambios en requisitos NIS2, DORA, GDPR, de clientes y contractuales.
- Cambios de alcance, incluidos nuevos países, productos, clientes regulados o dependencias TIC.
- Resultados de auditoría interna, incluidas no conformidades mayores y menores.
- Estado de CAPA y acciones vencidas.
- Objetivos y métricas de seguridad.
- Tendencias de incidentes, cuasi incidentes y lecciones aprendidas.
- Riesgos de concentración de proveedores y nube.
- Resultados de pruebas de continuidad de negocio y copias de seguridad.
- Desempeño de vulnerabilidades y aplicación de parches.
- Necesidades de recursos, incluidas personas, herramientas, formación y presupuesto.
- Riesgos residuales que requieren aceptación formal.
- Decisiones de mejora y responsables asignados.
Aquí es donde María puede convertir un informe técnico en aseguramiento estratégico. En lugar de decir «encontramos una brecha en el proceso de incidentes», puede decir: «La auditoría identificó una no conformidad menor en nuestros criterios de decisión para la notificación de incidentes NIS2. La CAPA actualiza el procedimiento, añade una matriz de decisión y exige un ejercicio de simulación en 30 días. Necesitamos aprobación de la dirección para la revisión jurídica y el tiempo de formación».
Ese es el tipo de registro que respalda la gobernanza, la supervisión y la toma de decisiones defendible.
Acción correctiva: la diferencia entre un hallazgo y la madurez
Una auditoría interna sin acción correctiva es solo un diagnóstico.
El paso 29 de Zenith Blueprint indica a las organizaciones que utilicen un registro CAPA:
«Complételo con cada problema: descripción del problema, causa raíz, acción correctiva, responsable asignado, fecha objetivo de finalización, estado».
De Zenith Blueprint, fase de auditoría, revisión y mejora, paso 29: mejora continua Zenith Blueprint
También establece una distinción importante:
«En términos de auditoría: la corrección soluciona el síntoma; la acción correctiva soluciona la causa. Ambas son importantes».
De Zenith Blueprint, fase de auditoría, revisión y mejora, paso 29: mejora continua
Si faltan evidencias de restauración de copias de seguridad, la corrección puede ser ejecutar y documentar una prueba de restauración esta semana. La acción correctiva consiste en modificar el procedimiento de copias de seguridad para que las pruebas de restauración se programen trimestralmente, generen tickets automáticamente, sean revisadas por el propietario del servicio y se incluyan en las métricas de revisión por la dirección.
Los auditores buscan esa madurez. Un auditor de ISO 27001 prueba la conformidad con el SGSI y los controles seleccionados. Un revisor de NIS2 pregunta si las medidas de gestión de riesgos son eficaces y están supervisadas. Un revisor de DORA busca integración del marco de riesgo TIC, pruebas de resiliencia, gestión de dependencias de terceros y remediación. Un evaluador de NIST Cybersecurity Framework 2.0 puede preguntar si los resultados de gobernanza, identificar, proteger, detectar, responder y recuperar están operando. Un auditor de COBIT 2019 puede centrarse en objetivos de gobernanza, asignación de responsabilidades, indicadores de rendimiento y aseguramiento.
El mismo registro CAPA puede satisfacer estas perspectivas si incluye causa raíz, responsable, impacto en el riesgo, acción correctiva, fecha límite, evidencia de implantación, revisión de eficacia y visibilidad para la dirección.
Las múltiples perspectivas del auditor
Distintos auditores leen la misma evidencia de forma diferente. Zenith Controls ayuda a anticipar esas preguntas al actuar como guía de cumplimiento cruzado para controles ISO/IEC 27002:2022 y marcos relacionados.
| Perspectiva de auditoría | Qué preguntará probablemente el auditor | Evidencia que responde bien |
|---|---|---|
| Auditor de ISO 27001 | ¿El SGSI está planificado, implantado, evaluado y mejorado de acuerdo con los requisitos de ISO/IEC 27001:2022? | Alcance, evaluación de riesgos, Declaración de aplicabilidad, plan de auditoría interna, informe de auditoría, resultados de revisión por la dirección, CAPA |
| Revisor de NIS2 | ¿La dirección aprobó y supervisó medidas de gestión de riesgos adecuadas, y puede la entidad demostrar eficacia y acción correctiva? | Actas del consejo o de revisión por la dirección, plan de tratamiento de riesgos, procedimientos de actuación ante incidentes, revisiones de proveedores, registros de formación, métricas de eficacia |
| Revisor de DORA | ¿La gestión del riesgo TIC está integrada en la gobernanza, la estrategia de resiliencia, las pruebas, el riesgo de terceros y la remediación? | Marco de riesgo TIC, plan de auditoría, evidencias de pruebas de resiliencia, registro de terceros, mapeo de funciones críticas, registros de remediación |
| Revisor de GDPR | ¿Puede la organización demostrar responsabilidad proactiva en el tratamiento y la seguridad de los datos personales? | Inventario de datos, registros de bases jurídicas, acuerdos con encargados del tratamiento, registros de brechas de seguridad, controles de acceso, evidencias de conservación, medidas de seguridad |
| Evaluador de NIST CSF 2.0 | ¿Los resultados de gobernanza, riesgo, protección, detección, respuesta y recuperación operan eficazmente? | Evidencias de control mapeadas a resultados, registros, monitorización, registros de incidentes, pruebas de recuperación, acciones de mejora |
| Auditor de COBIT 2019 | ¿Están definidos y supervisados los objetivos de gobernanza, la asignación de responsabilidades, la gestión del desempeño y las actividades de aseguramiento? | RACI, políticas, KPI, registro de auditorías, gestión de problemas, informes a la dirección, registros de decisiones |
El control 5.36 es un buen ejemplo. El auditor de ISO 27001 puede centrarse en si se realizan revisiones de cumplimiento y si alimentan acciones correctivas. El revisor de NIS2 puede preguntar si esas revisiones prueban medidas legales de ciberseguridad, no solo reglas internas. El revisor de DORA puede centrarse en si las revisiones de cumplimiento incluyen proveedores TIC críticos y aplicación contractual.
Por eso las evidencias deben diseñarse desde el principio para múltiples lectores.
Un ciclo intensivo práctico de preparación para auditorías en 30 días
Si el CEO pregunta si la organización puede estar preparada para auditorías en 30 días, la respuesta honesta es: puede construir una línea base de evidencias creíble si la dirección apoya el ciclo intensivo y el alcance es realista.
| Días | Actividad | Resultado |
|---|---|---|
| 1 a 3 | Confirmar el alcance del SGSI, los servicios regulados, las partes interesadas y las obligaciones | Declaración de alcance, nota de aplicabilidad de NIS2, DORA y GDPR |
| 4 a 7 | Actualizar criterios de riesgo, registro de riesgos y propietarios de riesgos clave | Registro de riesgos actualizado y prioridades de tratamiento |
| 8 a 10 | Elaborar un plan de auditoría interna basado en riesgos | Plan de auditoría aprobado y lista de verificación de auditoría |
| 11 a 17 | Ejecutar entrevistas de auditoría, muestreo y revisión de evidencias | Registro de evidencias, hallazgos, observaciones positivas |
| 18 a 20 | Validar hallazgos con responsables y clasificar la severidad | Informe de auditoría y registro de no conformidades |
| 21 a 24 | Crear registro CAPA con causas raíz, responsables y fechas límite | Plan de acciones correctivas aprobado |
| 25 a 27 | Preparar el paquete de revisión por la dirección | Presentación o informe de revisión con métricas, riesgos, incidentes y recursos |
| 28 a 30 | Celebrar la revisión por la dirección y registrar decisiones | Actas, registro de acciones, aceptaciones de riesgo, decisiones sobre recursos |
Este ciclo intensivo no sustituye la madurez a largo plazo. Crea una línea base operativa defendible. El verdadero valor aparece cuando la organización repite el ciclo trimestral o semestralmente, no solo una vez al año.
Fallos habituales de evidencias que Clarysec encuentra
Las mismas debilidades aparecen en auditorías SaaS, de nube y fintech:
- El plan de auditoría existe, pero no está basado en riesgos.
- La lista de verificación de auditoría prueba cláusulas ISO, pero ignora NIS2, DORA, GDPR y obligaciones de clientes.
- Existen actas de revisión por la dirección, pero no muestran decisiones, asignación de recursos ni aceptación del riesgo.
- Los registros CAPA enumeran acciones, pero no causa raíz.
- Los hallazgos se cierran sin verificación de eficacia.
- Se realizan revisiones de proveedores, pero los proveedores críticos no se distinguen de los proveedores de bajo riesgo.
- Existen procedimientos de actuación ante incidentes, pero nadie puede demostrar que el flujo de notificación de 24 o 72 horas funcionaría.
- Los trabajos de copia de seguridad están en verde, pero las pruebas de restauración no están evidenciadas.
- Las revisiones de acceso se exportan, pero las excepciones no se siguen hasta su cierre.
- Se recopilan registros, pero nadie puede demostrar monitorización, escalado o respuesta.
- Las evidencias se almacenan en carpetas personales en lugar de en un repositorio controlado.
- Los requisitos de conservación no están claros o son incoherentes con los contratos de clientes.
Estos fallos se pueden corregir. Requieren una arquitectura estructurada de evidencias del SGSI, no una búsqueda documental de última hora.
Cómo se ve un buen resultado para el consejo de administración
Cuando el CISO vuelve al CEO y al CFO, la respuesta más sólida no es «hemos superado una lista de verificación de auditoría». Es:
«Tenemos un plan de auditoría aprobado. Realizamos una auditoría interna basada en riesgos. Identificamos hallazgos con evidencias objetivas. Aprobamos CAPA con responsables y fechas límite. Elevamos riesgos materiales, incidentes, dependencias de proveedores y necesidades de recursos a la revisión por la dirección. Mapeamos evidencias frente a ISO/IEC 27001:2022, NIS2, DORA y GDPR. Podemos mostrar la pista de auditoría».
Esa respuesta cambia la conversación. Da al CEO confianza ante los clientes. Da al CFO claridad sobre la exposición regulatoria. Da al consejo de administración un registro de supervisión defendible. Da al CISO una hoja de ruta priorizada en lugar de una pila de solicitudes desconectadas.
Lo más importante es que mueve a la organización del teatro del cumplimiento a la resiliencia operativa.
Próximos pasos con Clarysec
Su próxima auditoría no debería ser una carrera de última hora. Debería ser una prueba visible de que su SGSI funciona, la dirección está implicada y la organización está preparada para ISO 27001, NIS2, DORA, GDPR y el aseguramiento de clientes.
Clarysec puede ayudarle a:
- Construir un plan de auditoría interna basado en riesgos utilizando Zenith Blueprint: hoja de ruta de 30 pasos para auditores Zenith Blueprint.
- Mapear evidencias de auditoría mediante Zenith Controls: guía de cumplimiento cruzado Zenith Controls.
- Implantar gobernanza de auditoría para pymes o empresas mediante Política de auditoría y supervisión del cumplimiento-sme Política de auditoría y supervisión del cumplimiento-sme o Política de auditoría y supervisión del cumplimiento Política de auditoría y supervisión del cumplimiento.
- Preparar paquetes de revisión por la dirección alineados con la Política de seguridad de la información Política de seguridad de la información y las expectativas de la cláusula 9.3 de ISO/IEC 27001:2022.
- Convertir hallazgos en registros CAPA, decisiones de la dirección y mejora medible.
Descargue los kits de herramientas de Clarysec, reserve una evaluación de preparación o solicite una demostración para convertir su próxima auditoría interna en evidencias listas para el consejo de administración para ISO 27001, NIS2, DORA y más allá.
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
