Evaluación de riesgos ISO 27001 preparada para auditoría para NIS2 y DORA
El café sobre el escritorio de Sarah estaba frío.
Como CISO de una fintech en rápido crecimiento, estaba acostumbrada a trabajar bajo presión. La empresa acababa de cerrar un acuerdo con un socio bancario importante, y el cuestionario de diligencia debida en su pantalla debería haber sido una formalidad. Las primeras preguntas eran conocidas: aportar la Declaración de Aplicabilidad de ISO/IEC 27001:2022, compartir el registro de riesgos más reciente y explicar la metodología de evaluación de riesgos.
Entonces el cuestionario cambió de tono.
Demuestre cómo su programa de gestión de riesgos aborda DORA. Explique su preparación para la Directiva NIS2, incluida la responsabilidad de la dirección y las medidas de gestión de riesgos de la cadena de suministro. Aporte evidencias de que los proveedores críticos de TIC se evalúan, se supervisan y están cubiertos por planes de respuesta a incidentes y continuidad del negocio.
El lunes por la mañana, el mismo asunto estaba en la agenda del comité de riesgos del consejo de administración. Auditoría de certificación ISO 27001 en ocho semanas. Presión de DORA por parte de clientes del sector financiero. Preguntas de clasificación NIS2 para una línea de servicios alojados en la nube que se estaba expandiendo en la UE. Compras afirmaba que existían revisiones de proveedores, pero las evidencias estaban repartidas entre correos electrónicos, carpetas contractuales y una hoja de cálculo de proveedores. Legal indicaba que el mapeo regulatorio seguía en curso. Ingeniería decía que el registro de riesgos estaba prácticamente terminado.
El consejo de administración formuló la única pregunta que importaba:
¿Podemos demostrar que nuestra evaluación de riesgos y nuestro plan de tratamiento de riesgos son suficientes?
Ese es el verdadero problema para empresas SaaS, fintech, de servicios gestionados, de nube y de plataformas digitales. No si existe un registro de riesgos. No si los controles del Anexo A se han copiado en una hoja de cálculo. La cuestión es si la organización puede demostrar, bajo presión de auditoría y de clientes, que su proceso de evaluación de riesgos ISO 27001 es repetible, basado en riesgos, aprobado por los propietarios del riesgo, vinculado a acciones de tratamiento, mapeado a obligaciones legales y operativo en la práctica.
Bien ejecutados, una evaluación de riesgos ISO 27001 y un plan de tratamiento de riesgos pueden respaldar la certificación ISO/IEC 27001:2022, las medidas de gestión de riesgos de ciberseguridad de NIS2 Article 21, los requisitos de gestión del riesgo de las TIC de DORA, la responsabilidad proactiva de GDPR, el aseguramiento de proveedores, la preparación ante incidentes y los informes al consejo de administración.
Mal ejecutados, se convierten en una hoja de cálculo que los auditores desmontarán en treinta minutos.
Esta guía muestra cómo Clarysec construye evidencias de evaluación y tratamiento de riesgos ISO 27001 preparadas para auditoría utilizando Zenith Blueprint: hoja de ruta de 30 pasos para auditoría, las políticas de Clarysec y Zenith Controls: guía de cumplimiento transversal.
Por qué la evaluación de riesgos ISO 27001 es ahora un eje de cumplimiento
El panorama regulatorio de la UE converge en torno a un principio sencillo: el riesgo de ciberseguridad debe gobernarse, documentarse, probarse y asignarse a responsables.
ISO/IEC 27001:2022 ya funciona de esta forma. Las cláusulas 4.1 a 4.4 exigen que la organización comprenda su contexto, las partes interesadas, el alcance del SGSI y las interacciones de los procesos antes de evaluar el riesgo. Las cláusulas 6.1.2 y 6.1.3 exigen un proceso definido de evaluación y tratamiento de riesgos de seguridad de la información. Las cláusulas 8.2 y 8.3 exigen que la organización realice evaluaciones de riesgos e implemente el plan de tratamiento conservando información documentada.
NIS2 y DORA hacen que esta misma lógica basada en riesgos sea más urgente.
NIS2 Article 20 exige que los órganos de dirección de entidades esenciales e importantes aprueben las medidas de gestión de riesgos de ciberseguridad, supervisen su implementación y reciban formación en ciberseguridad. Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas para gestionar los riesgos que afectan a las redes y sistemas de información. Esas medidas incluyen análisis de riesgos, gestión de incidentes, continuidad del negocio, seguridad de la cadena de suministro, desarrollo seguro, gestión de vulnerabilidades, evaluación de la eficacia, higiene cibernética, criptografía, seguridad de los recursos humanos, control de acceso, gestión de activos y autenticación multifactor o comunicaciones seguras cuando proceda.
DORA ejerce una presión similar sobre las entidades financieras. Articles 5 y 6 exigen que el órgano de dirección defina, apruebe, supervise y siga siendo responsable de los mecanismos de gestión del riesgo de las TIC. DORA espera un marco documentado de gestión del riesgo de las TIC integrado en la gestión global de riesgos, respaldado por políticas, procedimientos, protocolos, herramientas, auditoría interna, remediación, continuidad, pruebas, gestión de incidentes y gobernanza de terceros de TIC.
La conclusión es práctica e inevitable: el registro de riesgos ya no es una hoja de trabajo del equipo técnico. Es evidencia de gobierno.
La política empresarial Política de gestión de riesgos de Clarysec hace explícita esta expectativa:
Debe mantenerse un proceso formal de gestión de riesgos conforme a ISO/IEC 27005 e ISO 31000, que cubra la identificación, análisis, evaluación, tratamiento, supervisión y comunicación del riesgo.
De la Política empresarial de gestión de riesgos, sección “Requisitos de gobernanza”, cláusula de política 5.1.
La misma política define el resultado preparado para auditoría:
Mantener un Registro de Riesgos y un Plan de Tratamiento de Riesgos centralizados y sujetos a control de versiones, que reflejen el estado actual del riesgo, la cobertura del control y el progreso de la mitigación.
De la Política empresarial de gestión de riesgos, sección “Objetivos”, cláusula de política 3.3.
Esa frase, “estado actual del riesgo, cobertura del control y progreso de la mitigación”, marca la diferencia entre un archivo estático de cumplimiento y un programa de riesgos defendible.
Empiece por el alcance, las obligaciones y los criterios de riesgo
Muchas evaluaciones de riesgos ISO 27001 débiles comienzan con una lista de verificación de controles. Ese enfoque invierte el orden correcto.
ISO 27001 exige que la organización determine el contexto, los requisitos de las partes interesadas, el alcance del SGSI, las responsabilidades de liderazgo y la planificación del riesgo antes de seleccionar controles. ISO/IEC 27005:2022 refuerza esto al recomendar que las organizaciones identifiquen los requisitos básicos de las partes interesadas antes de evaluar el riesgo. Esos requisitos pueden proceder de normas ISO, regulaciones sectoriales, leyes nacionales, contratos con clientes, políticas internas, actividades de tratamiento anteriores y obligaciones de proveedores.
Para una empresa SaaS o fintech orientada a la UE, el proceso de riesgos debe comenzar con un inventario de cumplimiento y obligaciones.
| Fuente del requisito | Por qué afecta a la evaluación de riesgos ISO 27001 | Artefacto de evidencia |
|---|---|---|
| ISO/IEC 27001:2022 cláusulas 4, 5, 6, 8, 9 y 10 | Define contexto, liderazgo, evaluación de riesgos, tratamiento de riesgos, control operacional, evaluación del desempeño y mejora | Alcance del SGSI, metodología de riesgos, registro de riesgos, plan de tratamiento, SoA, registros de revisión por la dirección |
| NIS2 Articles 20, 21 y 23 | Añade responsabilidad de la dirección, medidas de ciberseguridad frente a todo tipo de amenazas y expectativas de notificación de incidentes | Aprobación del consejo de administración, mapeo de Article 21, procedimiento de notificación de incidentes, evidencias de continuidad |
| DORA Articles 5, 6, 11, 12, 17, 18, 19, 24, 28 y 30 | Exige gobierno del riesgo de las TIC, continuidad, copia de seguridad y restauración, ciclo de vida de incidentes, pruebas y controles de riesgo de terceros de TIC | Marco de riesgo de las TIC, pruebas del plan de continuidad de negocio, registro de incidentes, registros de pruebas de resiliencia, registro de proveedores de TIC |
| GDPR Articles 3, 4, 5, 6, 9, 10, 25, 32, 33 y 34 | Exige responsabilidad proactiva, tratamiento lícito, protección de datos desde el diseño, seguridad adecuada y evaluación de brechas de seguridad | Inventario de datos, mapeo de bases jurídicas, entradas de riesgo de privacidad, enlaces a EIPD, registros de evaluación de brechas de seguridad |
| Contratos con proveedores y clientes | Convierte compromisos comerciales en criterios de riesgo, controles, evidencias y plazos | Registro contractual, registros de diligencia debida, derechos de auditoría, SLA, cláusulas de salida |
Para pymes, la Política de cumplimiento legal y normativo para pymes de Clarysec establece el punto de partida:
El Director General debe mantener un Registro de Cumplimiento simple y estructurado que enumere:
De la Política de cumplimiento legal y normativo para pymes, sección “Requisitos de gobernanza”, cláusula de política 5.1.1.
Ese registro sencillo es un puente entre el cumplimiento y la gestión de riesgos. Si indica que GDPR aplica porque se tratan datos personales de la UE, que NIS2 puede aplicar porque la organización presta servicios digitales o gestionados, o que DORA es relevante por clientes del sector financiero, esas obligaciones deben influir en los criterios de riesgo y en las prioridades de tratamiento.
El Zenith Blueprint es directo sobre este punto en la fase de gestión de riesgos, paso 10, “Establecimiento de criterios de riesgo y matriz de impacto”:
Considere también los requisitos legales/regulatorios en sus criterios de aceptación. Algunos riesgos pueden ser inaceptables independientemente de la probabilidad debido a la legislación.
De Zenith Blueprint, fase de gestión de riesgos, paso 10.
También ofrece una regla práctica para talleres:
“Todo riesgo que pueda dar lugar al incumplimiento de leyes aplicables (GDPR, etc.) no es aceptable y debe mitigarse.”
De Zenith Blueprint, fase de gestión de riesgos, paso 10.
Para la fintech de Sarah, esto cambia el modelo de puntuación. Una vulnerabilidad en una API de proveedor puede tener baja probabilidad, pero si su explotación pudiera desencadenar un incidente grave relacionado con las TIC bajo DORA, un incidente significativo bajo NIS2, una evaluación de brecha de seguridad bajo GDPR, un incumplimiento de SLA de cliente o una escalada al consejo de administración, el impacto es alto o crítico. La exposición de cumplimiento pasa a formar parte de la lógica de riesgo, no de una hoja de cálculo separada.
Construya un registro de riesgos que los auditores puedan probar
Los auditores no solo preguntan cuáles son sus principales riesgos. Comprueban si el método está definido, es repetible, es trazable y se sigue.
Preguntarán:
- ¿Cómo identificaron estos riesgos?
- ¿Qué activos, servicios, proveedores, tipos de datos y procesos estaban dentro del alcance?
- ¿Qué criterios se utilizaron para la probabilidad y el impacto?
- ¿Quién es propietario de cada riesgo?
- ¿Qué controles existentes reducen el riesgo?
- ¿Por qué se seleccionó esa decisión de tratamiento?
- ¿Dónde está la evidencia de que el tratamiento se ejecutó?
- ¿Quién aprobó el riesgo residual?
- ¿Cuándo se reevaluará el riesgo?
La Política de gestión de riesgos para pymes de Clarysec recoge la entrada mínima de riesgo preparada para auditoría:
Cada entrada de riesgo debe incluir: descripción, probabilidad, impacto, puntuación, propietario y plan de tratamiento.
De la Política de gestión de riesgos para pymes, sección “Requisitos de gobernanza”, cláusula de política 5.1.2.
Para programas empresariales, la fase de gestión de riesgos del Zenith Blueprint, paso 11, “Construcción y documentación del Registro de Riesgos”, amplía la estructura. Recomienda columnas como identificador del riesgo, activo, amenaza, vulnerabilidad, descripción del riesgo, probabilidad, impacto, nivel de riesgo, controles actuales, propietario del riesgo, decisión de tratamiento, plan de tratamiento o controles, y estado.
Una entrada de riesgo sólida tiene este aspecto:
| Campo | Ejemplo de entrada |
|---|---|
| Identificador del riesgo | R-042 |
| Activo o proceso | Tratamiento de datos de clientes mediante API de pago de tercero y base de datos de producción |
| Amenaza | Explotación de una vulnerabilidad crítica en la API del proveedor o en el servicio de base de datos en la nube de soporte |
| Vulnerabilidad | Visibilidad limitada sobre la gestión de vulnerabilidades del proveedor, pruebas de restauración incompletas y ausencia de un procedimiento de actuación probado para brechas de seguridad del proveedor |
| Descripción del riesgo | Un compromiso de un proveedor o servicio en la nube podría exponer datos financieros, interrumpir el servicio, activar notificaciones regulatorias e incumplir contratos con clientes |
| Controles actuales | SSO, acceso basado en roles, contrato con proveedor, registro de eventos en producción, copias de seguridad diarias, revisión trimestral de accesos |
| Probabilidad | Media |
| Impacto | Crítico |
| Nivel de riesgo | Crítico |
| Propietario del riesgo | CTO y responsable de ingeniería de plataforma |
| Decisión de tratamiento | Mitigar |
| Mapeo regulatorio | Controles del Anexo A de ISO 27001 sobre proveedores, nube, incidentes, registro de eventos, acceso, continuidad, copia de seguridad y cumplimiento legal; NIS2 Articles 20, 21 y 23; DORA Articles 5, 6, 11, 12, 17, 18, 19, 24, 28 y 30; GDPR Articles 32, 33 y 34 |
| Evidencias | Diligencia debida de proveedores, solicitud de derechos de auditoría, informe de prueba de restauración, regla de supervisión SIEM, ejercicio de simulación de incidentes, SoA actualizada, actas de revisión por la dirección |
Esto es materialmente distinto de “riesgo de terceros, alto, mitigar”. La versión preparada para auditoría vincula activo, amenaza, vulnerabilidad, consecuencia, controles actuales, propietario, regulación, evidencias y gobierno.
Convierta el tratamiento de riesgos en un plan de evidencias
Un plan de tratamiento de riesgos debe responder a cuatro preguntas operativas:
- ¿Qué haremos?
- ¿Quién es responsable?
- ¿Cuándo estará hecho?
- ¿Cómo demostraremos que redujo el riesgo?
ISO/IEC 27001:2022 cláusula 6.1.3 exige que la organización seleccione opciones de tratamiento, determine los controles necesarios, los compare con el Anexo A para evitar omisiones, elabore una Declaración de Aplicabilidad, formule un plan de tratamiento y obtenga la aprobación de los propietarios del riesgo para el plan y los riesgos residuales. La cláusula 8.3 exige después implementar el plan de tratamiento y conservar información documentada sobre los resultados.
La política empresarial Política de gestión de riesgos lo aterriza en la práctica:
El Responsable de Riesgos debe asegurar que los tratamientos sean realistas, tengan plazos definidos y estén mapeados a controles del Anexo A de ISO/IEC 27001.
De la Política empresarial de gestión de riesgos, sección “Requisitos de implementación de la política”, cláusula de política 6.4.2.
La política para pymes también aclara que la aceptación no es un atajo:
Aceptar: Justificar por qué no se requiere ninguna acción adicional y registrar el riesgo residual.
De la Política de gestión de riesgos para pymes, sección “Requisitos de implementación de la política”, cláusula de política 6.1.1.
La aceptación debe justificarse frente a los criterios, aprobarse por el propietario adecuado y supervisarse. Bajo NIS2 y DORA, un riesgo residual no aprobado puede convertirse en un fallo de gobierno.
Un plan de tratamiento completo debe contener estos campos:
| Campo de tratamiento | Propósito de auditoría |
|---|---|
| Identificador del riesgo | Vincula el tratamiento con el riesgo evaluado |
| Opción de tratamiento | Muestra la justificación: mitigar, evitar, transferir o aceptar |
| Controles seleccionados | Conecta el riesgo con el Anexo A, políticas y salvaguardas técnicas |
| Factor regulatorio | Muestra la relevancia de NIS2, DORA, GDPR, contrato o cliente |
| Propietario de la acción | Demuestra responsabilidad proactiva |
| Fecha límite | Hace que el tratamiento tenga un plazo definido |
| Evidencia de implementación | Muestra que la acción se completó |
| Medida de eficacia | Muestra si se redujo la probabilidad o el impacto |
| Riesgo residual | Muestra la exposición restante |
| Aprobación del propietario del riesgo | Demuestra aceptación y gobierno |
Para el R-042 de Sarah, el plan de tratamiento se convierte en una lista de acciones de cumplimiento transversal.
| Identificador del riesgo | Acción de tratamiento | Referencia del Anexo A de ISO/IEC 27001:2022 | Relevancia NIS2 | Relevancia DORA | Propietario | Evidencia |
|---|---|---|---|---|---|---|
| R-042 | Ejercer los derechos de auditoría del proveedor y solicitar evidencias de gestión de vulnerabilidades | 5.19, 5.20, 5.21, 5.22, 5.31 | Article 21(2)(d) seguridad de la cadena de suministro | Articles 28 y 30 riesgo de terceros de TIC y contratos | CTO y Responsable de compras | Solicitud de auditoría, respuesta del proveedor, revisión contractual |
| R-042 | Implementar supervisión reforzada de actividad anómala de API y actividad privilegiada | 8.15, 8.16, 5.16, 5.17, 5.18 | Article 21(2)(i) control de acceso y gestión de activos | Articles 6 y 17 riesgo de las TIC y gestión de incidentes | Responsable del SOC | Regla SIEM, prueba de alerta, revisión de accesos |
| R-042 | Probar la restauración de copias de seguridad y definir RTO y RPO a nivel de servicio | 5.30, 8.13, 8.14 | Article 21(2)(c) continuidad del negocio y copia de seguridad | Articles 11 y 12 respuesta, recuperación, copia de seguridad y restauración | Responsable de ingeniería de plataforma | Informe de restauración, aprobación de RTO y RPO |
| R-042 | Ejecutar un ejercicio de simulación sobre brecha de seguridad de proveedor | 5.24, 5.26, 5.27, 5.29 | Articles 21(2)(b) y 23 gestión y notificación de incidentes | Articles 17, 18, 19 y 24 gestión, clasificación, notificación y pruebas de incidentes | CISO | Registro del ejercicio de simulación, lecciones aprendidas, herramienta de seguimiento de remediación |
| R-042 | Actualizar la SoA y la aprobación del riesgo residual | 5.4, 5.31, 5.35 | Article 20 responsabilidad de la dirección | Articles 5 y 6 gobierno y marco de riesgo de las TIC | CISO y Propietario del Riesgo | SoA actualizada, registro de aprobación, actas de revisión por la dirección |
Este plan es potente porque crea una línea directa desde un escenario de riesgo hasta controles ISO 27001, obligaciones NIS2, artículos DORA, propietarios y evidencias.
Haga que la Declaración de Aplicabilidad trabaje más
La Declaración de Aplicabilidad suele tratarse como un artefacto de certificación. Debería ser más que eso.
ISO/IEC 27001:2022 cláusula 6.1.3 exige que la SoA incluya los controles necesarios, la justificación de inclusión, el estado de implementación y la justificación de exclusiones. La guía ISO/IEC 27005:2022 refuerza la necesidad de comparar los controles seleccionados con el Anexo A de ISO/IEC 27001 para evitar omisiones.
En un programa preparado para auditoría, la SoA se convierte en el puente entre el tratamiento de riesgos y las evidencias de cumplimiento transversal. Si un plan de tratamiento exige MFA, registro de eventos, supervisión de proveedores, restauración de copias de seguridad, desarrollo seguro, escalado de incidentes o planificación de salida de la nube, la SoA debe mostrar que los controles pertinentes del Anexo A están incluidos, justificados, implementados o planificados, y evidenciados.
Esto también ayuda a evitar un fallo de auditoría común: el registro de riesgos dice una cosa, el plan de tratamiento dice otra y la SoA guarda silencio. Cuando esos artefactos no coinciden, los auditores pierden confianza rápidamente.
Mapeo del tratamiento de riesgos ISO 27001 a NIS2, DORA y GDPR
ISO 27001 no sustituye a NIS2, DORA ni GDPR. Proporciona un mecanismo estructurado para generar evidencias para ellos.
La clave es incorporar el mapeo al proceso de riesgos en lugar de añadirlo después.
| Evidencia de tratamiento de riesgos ISO 27001 | Relevancia NIS2 | Relevancia DORA | Relevancia GDPR |
|---|---|---|---|
| Criterios de riesgo con puntuación de impacto regulatorio | Respalda las medidas proporcionadas de gestión de riesgos de ciberseguridad de Article 21 | Respalda la proporcionalidad, el gobierno y el marco de riesgo de las TIC de Articles 4, 5 y 6 | Respalda la responsabilidad proactiva y la seguridad adecuada |
| Registro de riesgos con propietarios e impacto CID | Respalda la supervisión de la dirección de Article 20 y el análisis de riesgos de Article 21 | Respalda la gestión documentada del riesgo de las TIC y la propiedad del riesgo | Respalda la demostración de conocimiento del riesgo sobre datos personales |
| Plan de tratamiento mapeado al Anexo A | Respalda las medidas de Article 21 en áreas de incidentes, continuidad, proveedores, acceso, vulnerabilidades y desarrollo seguro | Respalda controles de TIC, gestión de incidentes, continuidad, pruebas y resiliencia de terceros | Respalda medidas técnicas y organizativas bajo Article 32 |
| Entradas de riesgo de proveedores y controles contractuales | Respalda la seguridad de la cadena de suministro de Article 21(2)(d) | Respalda los requisitos de riesgo de terceros de TIC y contractuales de Articles 28 y 30 | Respalda salvaguardas de encargados del tratamiento y transferencias cuando aplique |
| Escenarios de incidentes y procedimientos de notificación | Respalda el flujo de notificación de incidentes significativos de Article 23 | Respalda la gestión, clasificación y notificación de incidentes de Articles 17, 18 y 19 | Respalda la evaluación de notificación de brechas de seguridad de Articles 33 y 34 |
| Tratamientos de continuidad, copia de seguridad y recuperación | Respalda continuidad, copia de seguridad, recuperación ante desastres y gestión de crisis de Article 21(2)(c) | Respalda respuesta, recuperación, copia de seguridad y restauración de Articles 11 y 12 | Respalda disponibilidad y resiliencia cuando intervienen datos personales |
| Revisiones de eficacia de controles | Respalda la evaluación de la eficacia de Article 21(2)(f) | Respalda las expectativas de pruebas y remediación de Article 24 | Respalda la responsabilidad proactiva continua |
Este mapeo es especialmente importante cuando las regulaciones se solapan. DORA es el régimen sectorial específico de resiliencia de TIC para muchas entidades financieras, mientras que NIS2 puede seguir siendo directamente relevante para determinados proveedores, coordinación o entidades fuera del alcance de DORA. Una fintech puede necesitar DORA como marco principal de resiliencia de TIC, mientras que un proveedor de servicios gestionados que dé soporte a esa fintech puede afrontar obligaciones NIS2 directamente.
El registro de riesgos debe poder mostrar ambos lados de esa dependencia.
Use Zenith Controls como brújula de cumplimiento transversal
Clarysec utiliza Zenith Controls como guía de cumplimiento transversal para prevenir el fallo común en el que controles ISO, artículos regulatorios y preguntas de auditoría viven en universos separados. No crea un marco de control separado. Mapea las áreas de control de ISO/IEC 27001:2022 e ISO/IEC 27002:2022 a otras normas, expectativas de auditoría y perspectivas de cumplimiento.
Para la evaluación y el tratamiento de riesgos ISO 27001, estas referencias son especialmente importantes:
| Referencia del Anexo A de ISO/IEC 27001:2022 utilizada en Zenith Controls | Por qué importa para la evaluación y el tratamiento de riesgos | Atributos capturados en Zenith Controls |
|---|---|---|
| 5.4 Responsabilidades de la dirección | Conecta la propiedad del tratamiento de riesgos con el gobierno, la claridad de roles y la responsabilidad proactiva | Control preventivo, respalda confidencialidad, integridad y disponibilidad, mapea a Identificar, Gobernanza, Gobernanza y Ecosistema |
| 5.31 Requisitos legales, estatutarios, regulatorios y contractuales | Conecta el registro de cumplimiento con los criterios de riesgo, las decisiones de tratamiento y la inclusión en la SoA | Control preventivo, respalda confidencialidad, integridad y disponibilidad, mapea a Identificar, Legal y Cumplimiento, Gobernanza, Ecosistema y Protección |
| 5.35 Revisión independiente de la seguridad de la información | Conecta auditoría interna, auditoría externa y aseguramiento por la dirección con la eficacia del tratamiento | Control preventivo y correctivo, respalda confidencialidad, integridad y disponibilidad, mapea a Identificar y Proteger, Aseguramiento de la seguridad de la información, Gobernanza y Ecosistema |
La lección de cumplimiento transversal es sencilla. Si las obligaciones legales no están en el método de evaluación de riesgos, la puntuación está incompleta. Si la puntuación está incompleta, las prioridades de tratamiento pueden ser incorrectas. Si las prioridades son incorrectas, la SoA y los informes al consejo de administración dejan de ser fiables.
El Zenith Blueprint plantea el mismo punto en la fase de gestión de riesgos, paso 14, “Políticas de tratamiento de riesgos y referencias regulatorias cruzadas”. Recomienda a las organizaciones crear una tabla de mapeo que enumere los requisitos regulatorios clave de seguridad y los controles o políticas correspondientes en el SGSI. Esto no es obligatorio para la certificación ISO 27001, pero resulta muy útil para demostrar que la seguridad se gestiona en su contexto legal y contractual.
Qué preguntarán distintos auditores
Un auditor de certificación, un revisor orientado a NIS2, un cliente orientado a DORA, un revisor de GDPR, un evaluador NIST o un profesional COBIT pueden examinar las mismas evidencias, pero formular preguntas diferentes.
| Enfoque del auditor | Pregunta típica de auditoría | Evidencias que espera |
|---|---|---|
| Auditor ISO 27001 | ¿El método de evaluación de riesgos está definido, es repetible, se aplica y está vinculado al tratamiento y a la SoA? | Metodología de riesgos, criterios, registro, SoA, plan de tratamiento, aprobaciones residuales |
| Revisor orientado a NIS2 | ¿Las medidas de ciberseguridad cubren las áreas de Article 21 y la responsabilidad de la dirección? | Aprobaciones del consejo de administración, mapeo de Article 21, procedimiento de actuación ante incidentes, evidencias de continuidad, evidencias de riesgo de proveedores |
| Revisor orientado a DORA | ¿La gestión del riesgo de las TIC está documentada, gobernada, probada y extendida a terceros de TIC? | Marco de riesgo de las TIC, proceso de clasificación de incidentes, pruebas del plan de continuidad de negocio, pruebas de resiliencia, registro de proveedores de TIC |
| Revisor de GDPR | ¿Puede la organización demostrar seguridad adecuada y responsabilidad proactiva sobre los riesgos relativos a datos personales? | Inventario de datos, mapeo de bases jurídicas, procedimiento de evaluación de brechas de seguridad, evidencias de tratamiento de riesgos de privacidad |
| Evaluador orientado a NIST | ¿Los riesgos se identifican, se protegen, se detectan, se responden y se recuperan mediante controles medibles? | Escenarios de riesgo, inventario de activos, implementación de controles, supervisión, registros de respuesta y recuperación |
| Auditor COBIT o ISACA | ¿El gobierno del riesgo está alineado con objetivos empresariales, roles, desempeño, aseguramiento e informes de gestión? | Actas de gobierno, RACI, KRI, hallazgos de auditoría interna, seguimiento de remediación, paneles de gestión |
Por eso importa la arquitectura de evidencias. La misma entrada de riesgo debe ser trazable desde el objetivo de negocio hasta el activo, amenaza, vulnerabilidad, control, propietario, factor regulatorio, acción de tratamiento, resultado de prueba y decisión de la dirección.
Las políticas de Clarysec están diseñadas para respaldar esa arquitectura. La política empresarial Política de gestión de riesgos indica en la sección “Normas y marcos de referencia”:
Article 5: exige un marco documentado de gestión del riesgo de las TIC, cubierto íntegramente por la estructura de esta política, incluidos el mapeo de la SoA y los KRI.
Esto convierte la política de un documento estático en evidencia de auditoría que muestra que el gobierno del riesgo de las TIC se ha diseñado deliberadamente teniendo DORA en cuenta.
Hallazgos comunes que rompen los programas de riesgos
Cuando Clarysec revisa evidencias de evaluación y tratamiento de riesgos ISO 27001, aparecen repetidamente los mismos hallazgos.
Primero, los criterios de riesgo ignoran el impacto legal, regulatorio, contractual, de proveedores y de privacidad. Esto provoca puntuaciones débiles. Una brecha de seguridad de datos personales o un fallo de proveedor crítico puede calificarse como medio porque la probabilidad es baja, aunque el impacto sobre GDPR, NIS2, DORA o clientes debería hacerlo alto o crítico.
Segundo, los propietarios del riesgo son genéricos. “TI” no es un propietario del riesgo. Un propietario del riesgo debe ser un rol o persona responsable de las decisiones de tratamiento, presupuesto, plazos y riesgo residual.
Tercero, los planes de tratamiento no tienen plazos definidos. “Mejorar la supervisión” no es un plan. “Desplegar alertas de sesiones privilegiadas en el SIEM para cuentas de administración de producción antes del 30 de junio, bajo responsabilidad del Responsable del SOC, probado mediante inicio de sesión administrativo simulado y con evidencias de alerta adjuntas” sí es un plan.
Cuarto, la SoA está desconectada del tratamiento. Si el plan de tratamiento exige supervisión de proveedores, pruebas de copia de seguridad, escalado de incidentes, MFA o registro de eventos, la SoA debe reflejar los controles pertinentes y el estado de implementación.
Quinto, el riesgo residual no está aprobado. ISO 27001 exige la aprobación por el propietario del riesgo del plan de tratamiento y de los riesgos residuales. NIS2 y DORA lo hacen aún más importante porque la responsabilidad de la dirección es explícita.
Sexto, el riesgo de proveedores se trata como administración de compras. Bajo NIS2 Article 21(2)(d) y DORA Articles 28 y 30, el riesgo de proveedores y de terceros de TIC debe formar parte de la gestión de riesgos, no ser un cuestionario anual almacenado de forma aislada.
Séptimo, no hay evidencias de eficacia. ISO 27001 cláusula 6.1.1 exige evaluar la eficacia de las acciones planificadas. NIS2 incluye la evaluación de la eficacia en Article 21(2)(f). DORA espera pruebas y remediación. Un control que existe pero nunca se prueba es una evidencia débil.
La Política de gestión de riesgos para pymes establece la expectativa con claridad:
El Director General y el Coordinador de Riesgos deben asegurar que las actividades de gestión de riesgos estén preparadas para auditoría. El Registro de Riesgos y las acciones relacionadas están sujetos a auditoría interna y externa.
De la Política de gestión de riesgos para pymes, sección “Aplicación y cumplimiento”, cláusula de política 8.2.1.
Informes al consejo de administración sin saturar a la alta dirección
NIS2, DORA e ISO 27001 apuntan todos hacia la responsabilidad de la dirección, pero los consejos no necesitan cada fila de riesgo. Necesitan informes útiles para la toma de decisiones.
Un buen paquete de riesgos para el consejo de administración debe mostrar:
- Riesgos altos y críticos por dominio
- Acciones de tratamiento vencidas
- Riesgos regulatorios que impliquen NIS2, DORA, GDPR o contratos
- Riesgos de proveedores que afecten a servicios críticos o importantes
- Tendencias de incidentes y cuasi incidentes
- Riesgos residuales pendientes de aceptación
- Resultados de pruebas de eficacia de controles
- Cambios materiales en alcance, proveedores, tecnología o legislación
- Hallazgos de auditoría interna y acciones correctivas
Clarysec suele recomendar revisiones operativas de riesgos mensuales y revisiones por la dirección trimestrales. Las revisiones mensuales se centran en la ejecución del tratamiento. Las revisiones trimestrales se centran en aceptación, financiación, priorización, exposición regulatoria y decisiones estratégicas de riesgo.
Este ritmo también respalda la mejora continua. Las evaluaciones de riesgos deben actualizarse cuando se produzcan incidentes, surjan vulnerabilidades, se introduzcan nuevos activos, cambie la tecnología, cambien los proveedores, cambien las leyes, cambien las obligaciones con clientes o cambie el apetito de riesgo.
La ruta de implementación de Clarysec
Un programa de riesgos unificado evita hojas de cálculo desconectadas para ISO, NIS2, DORA, GDPR y aseguramiento de clientes. La ruta práctica es:
- Confirmar el alcance del SGSI, servicios, activos, proveedores, jurisdicciones y obligaciones con clientes.
- Construir o actualizar el registro de cumplimiento utilizando la Política de cumplimiento legal y normativo para pymes cuando proceda.
- Definir la metodología de riesgos, criterios de aceptación, escalas de probabilidad, escalas de impacto y reglas de impacto regulatorio.
- Construir el registro de riesgos utilizando la fase de gestión de riesgos de Zenith Blueprint y el enfoque de Clarysec para el generador del Registro de Riesgos y la SoA.
- Identificar riesgos basados en activos y en escenarios, incluidos escenarios de proveedores, nube, privacidad, continuidad, incidentes, vulnerabilidades, desarrollo seguro y acceso.
- Puntuar los riesgos utilizando criterios que incluyan impacto legal, regulatorio, contractual, operativo, de privacidad, de proveedores y financiero.
- Seleccionar opciones de tratamiento: mitigar, evitar, transferir o aceptar.
- Mapear los controles necesarios al Anexo A de ISO/IEC 27001:2022 y a la guía ISO/IEC 27002:2022.
- Crear o actualizar la Declaración de Aplicabilidad.
- Mapear los tratamientos a NIS2 Article 21, a la gestión del riesgo de las TIC y expectativas de terceros de DORA, a la responsabilidad proactiva de GDPR y a las obligaciones contractuales de clientes.
- Recopilar evidencias, validar la eficacia de los controles y obtener la aprobación del riesgo residual.
- Preparar un paquete de auditoría organizado por riesgo, control, regulación y artefacto de evidencia.
- Incorporar los resultados a la revisión por la dirección, auditoría interna, acción correctiva y mejora continua.
Esto no es documentación por sí misma. Es el sistema operativo de un gobierno cibernético defendible.
Construya un paquete de tratamiento de riesgos preparado para auditoría
La historia de Sarah termina bien porque dejó de tratar ISO 27001, NIS2 y DORA como proyectos de cumplimiento separados. Utilizó la evaluación de riesgos ISO 27001 como motor central, incorporó obligaciones regulatorias en los criterios de riesgo, mapeó acciones de tratamiento al Anexo A y a requisitos de la UE, y recopiló evidencias que clientes, auditores y el consejo de administración podían entender.
Su organización puede hacer lo mismo.
Use Zenith Blueprint: hoja de ruta de 30 pasos para auditoría para definir criterios de riesgo, construir el registro de riesgos, crear el plan de tratamiento de riesgos y establecer referencias cruzadas con requisitos regulatorios.
Use Zenith Controls: guía de cumplimiento transversal para conectar las áreas de control del Anexo A de ISO/IEC 27001:2022 con perspectivas de gobernanza, cumplimiento legal, aseguramiento y auditoría.
Use la Política de gestión de riesgos, la Política de gestión de riesgos para pymes y la Política de cumplimiento legal y normativo para pymes de Clarysec para estandarizar propiedad, registros, decisiones de tratamiento y evidencias preparadas para auditoría.
El siguiente paso práctico más rápido es tomar sus diez riesgos principales y contrastarlos con cinco preguntas:
- ¿El impacto regulatorio es visible?
- ¿El plan de tratamiento tiene plazos definidos y propietario?
- ¿Cada tratamiento está mapeado al Anexo A y a la SoA?
- ¿La relevancia de NIS2, DORA, GDPR o de clientes está documentada cuando aplica?
- ¿Existe evidencia de que el control funciona?
Si la respuesta es no, Clarysec puede ayudarle a convertir su registro de riesgos en un programa de tratamiento de riesgos defendible y de cumplimiento transversal en el que auditores, reguladores, clientes y consejos de administración puedan confiar.
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
