Apetito de riesgo TIC en DORA: guía para la aprobación del consejo de administración en 2026

Son las 08:15 de un martes, y el CISO de una empresa mediana de tecnología de pagos espera ante la sala del consejo de administración con tres documentos abiertos en una tableta.

El primero es el registro de riesgos TIC. Tiene 137 filas, calificaciones codificadas por colores y varios riesgos altos vinculados a concentración en la nube, acceso privilegiado, recuperación frente a ransomware, exposición de datos de clientes y respuesta a incidentes de proveedores. El segundo es el registro de preparación para DORA. Indica que la empresa dispone de políticas, procedimientos de gestión de incidentes, registros de terceros y planes de pruebas de resiliencia. El tercero es el paquete de documentación para el consejo de administración en una reunión regulatoria.

La presidenta tiene una pregunta, y no es técnica:

“¿Qué nivel de riesgo TIC hemos acordado realmente aceptar?”

La sala queda en silencio porque la empresa tiene evaluaciones de riesgos, pero no un apetito de riesgo TIC aprobado por el consejo de administración. Tiene calificaciones de impacto, pero no umbrales de tolerancia medibles. Tiene reuniones de escalado, pero ningún desencadenante formal que indique cuándo un riesgo cibernético pasa a requerir una decisión del órgano de administración. Ha aceptado riesgos residuales, pero algunos se justifican como “decisiones de negocio” sin un vínculo claro con los criterios de riesgo, la proporcionalidad de GDPR Article 32, las expectativas de tolerancia de DORA o la responsabilidad de la dirección en NIS2.

Esa brecha es cada vez más visible en 2026. DORA es aplicable desde el 17 de enero de 2025 y exige que las entidades financieras mantengan un marco de gobernanza y control del riesgo TIC, incluida la responsabilidad del órgano de administración sobre el marco de gestión del riesgo TIC, la estrategia de resiliencia operativa digital y la tolerancia al riesgo TIC. NIS2 impulsa a los órganos de administración a aprobar medidas de gestión de riesgos de ciberseguridad y a supervisar su implantación. GDPR Article 32 exige medidas técnicas y organizativas de seguridad adecuadas basadas en el riesgo. ISO/IEC 27001:2022 proporciona la mecánica del sistema de gestión: contexto, partes interesadas, criterios de riesgo, planes de tratamiento, información documentada y revisión por la dirección.

El puente que falta es una declaración de apetito y tolerancia al riesgo TIC que el consejo de administración pueda entender, aprobar, cuestionar y utilizar.

Esta guía explica cómo construir ese puente utilizando Zenith Blueprint: hoja de ruta de 30 pasos para auditores de Clarysec, la Política de gestión de riesgos de Clarysec, la Política de gestión de riesgos para pymes de Clarysec y Zenith Controls: guía de cumplimiento cruzado.

Por qué los registros de riesgos no son apetito de riesgo

Muchas organizaciones confunden un registro de riesgos con gobernanza del riesgo. Un registro de riesgos indica qué riesgos existen, cómo se califican, quién es su propietario y qué tratamiento está previsto. No responde automáticamente a las preguntas de nivel consejo de administración que DORA, NIS2, GDPR e ISO/IEC 27001:2022 esperan que aborden los directivos.

Una declaración madura de apetito de riesgo TIC responde a preguntas como:

• ¿Qué riesgos TIC son inaceptables con independencia del coste?
• ¿Qué tiempo de indisponibilidad operativa puede tolerar la organización para una función crítica o importante?
• ¿Qué nivel de pérdida de datos o compromiso de la integridad de los datos queda fuera del apetito?
• ¿Qué riesgo de concentración en terceros requiere la atención del consejo de administración?
• ¿Quién puede aceptar riesgo TIC residual, y a qué nivel?
• ¿Cuándo debe escalarse un riesgo a la alta dirección o al órgano de administración?
• ¿Cómo se integran los requisitos legales, regulatorios y contractuales en los criterios de riesgo?

En DORA, esto no es un refinamiento opcional de gobernanza. Article 5 exige que el órgano de administración defina, apruebe, supervise y sea responsable del marco de gestión del riesgo TIC, incluida la estrategia de resiliencia operativa digital y la tolerancia al riesgo TIC. Article 6 exige un marco documentado de gestión del riesgo TIC, revisión anual para entidades que no sean microempresas, auditoría interna, remediación de hallazgos críticos de auditoría y una estrategia de resiliencia operativa digital con objetivos TIC, tolerancia al riesgo, tolerancia al impacto, arquitectura, pruebas y estrategia de comunicación de incidentes.

NIS2 añade un modelo paralelo de responsabilidad de dirección. Article 20 exige que los órganos de administración de las entidades esenciales e importantes aprueben las medidas de gestión de riesgos de ciberseguridad, supervisen su implantación y reciban formación. Article 21 exige medidas técnicas, operativas y organizativas adecuadas y proporcionadas basadas en un enfoque multirriesgo, incluidos análisis de riesgos, gestión de incidentes, continuidad de negocio, seguridad de la cadena de suministro, desarrollo seguro, eficacia de los controles, formación, criptografía, seguridad de los recursos humanos, control de acceso, gestión de activos y autenticación multifactor cuando proceda.

Para las entidades financieras, DORA se trata como un acto jurídico sectorial específico de la Unión cuando se solapan obligaciones de NIS2. En la práctica, DORA desplaza por lo general los requisitos solapados de gestión de riesgos y notificación de incidentes de NIS2 para las entidades financieras dentro de su ámbito, mientras que NIS2 sigue siendo importante para la coordinación y para proveedores fuera de las obligaciones directas de DORA aplicables a entidades financieras. Para proveedores SaaS, de nube, de servicios gestionados y de seguridad gestionada, NIS2 puede aplicarse directamente cuando se cumplen las condiciones de alcance.

Por eso, el apetito de riesgo TIC aprobado por el consejo de administración ya no es un artefacto de riesgo financiero. Es un control de gobernanza de la seguridad.

Usar ISO/IEC 27001:2022 como sistema operativo

DORA y NIS2 indican a los directivos qué debe gobernarse. ISO/IEC 27001:2022 proporciona a las organizaciones un sistema operativo práctico para gobernarlo.

Las cláusulas 4.1 a 4.4 de ISO/IEC 27001:2022 exigen que la organización defina el contexto, las partes interesadas, los requisitos, el alcance del SGSI y los procesos del SGSI. Esto importa porque DORA, NIS2, GDPR, los contratos, las expectativas supervisoras, los clientes, los proveedores de servicios en la nube y los acuerdos de externalización se convierten en requisitos que influyen en los criterios de riesgo.

Las cláusulas 5.1 a 5.3 exigen compromiso de liderazgo, alineación de políticas, recursos, responsabilidades y reporte del desempeño del SGSI a la alta dirección. Las cláusulas 6.1.1 a 6.1.3 exigen planificación basada en riesgos, un proceso documentado de evaluación de riesgos, criterios de aceptación del riesgo, criterios de evaluación coherentes, propietarios del riesgo, comparación frente a los criterios de riesgo, planificación del tratamiento, una Declaración de Aplicabilidad y aprobación del riesgo residual.

Esta es la base de la tolerancia al riesgo TIC de DORA.

En la fase de gestión de riesgos, el paso 10 de Zenith Blueprint indica a las organizaciones que definan los criterios de riesgo antes de calificar los riesgos:

“Los criterios de riesgo son las reglas y referencias que su organización utiliza para evaluar la importancia de cada riesgo. Establecer estos criterios desde el principio garantiza que todos hablen el mismo lenguaje de riesgos.”

El mismo paso advierte que el impacto regulatorio debe integrarse en las definiciones de riesgo:

“Cualquier riesgo que pueda conducir al incumplimiento de las leyes aplicables (GDPR, etc.) no es aceptable y debe mitigarse.”

Zenith Blueprint también ofrece orientación práctica para escalar el impacto:

“Al definir el impacto, conviene relacionar los niveles con la escala específica de su organización. Por ejemplo, ‘Impacto financiero mayor = pérdida > 100.000 USD’ (ajústelo a su contexto). Considere también el impacto regulatorio: por ejemplo, una brecha de datos personales podría ser automáticamente ‘Mayor’ o ‘Severa’ debido a las sanciones de GDPR y a los requisitos de notificación, aunque la pérdida financiera directa no esté clara. Del mismo modo, si está dentro del alcance de NIS2 (servicios esenciales), un incidente que provoque una interrupción del servicio podría ser al menos ‘Mayor’ por sus implicaciones legales. Incluya estas consideraciones en sus definiciones.”

Esa orientación evita un fallo habitual: calificar un riesgo cibernético como moderado porque la pérdida financiera inmediata parece reducida, ignorando el impacto legal, de resiliencia operativa, sobre los interesados o sobre los clientes.

Un modelo apto para el consejo de administración debe separar cuatro capas:

Esta estructura hace que el apetito de riesgo sea auditable, porque cada declaración puede trazarse a criterios de riesgo, controles, evidencias y decisiones.

Una declaración de apetito de riesgo TIC de DORA apta para el consejo de administración

Una declaración sólida de apetito de riesgo TIC debe ser lo bastante breve para que el consejo de administración la apruebe, lo bastante específica para que la dirección la aplique y lo bastante medible para que los auditores la prueben. Debe evitar la jerga, pero no puede ser vaga.

Una declaración práctica de alto nivel podría decir:

“Nuestra entidad tiene bajo apetito por riesgos TIC que puedan causar perjuicio material a los clientes, interrupción de funciones críticas o importantes, divulgación o alteración no autorizada de datos regulados, incumplimiento de obligaciones legales o pérdida de resiliencia en servicios TIC críticos prestados por terceros.”

Esa declaración necesita después umbrales de tolerancia medibles y desencadenantes de escalado.

Esta tabla cambia la conversación. El consejo de administración ya no aprueba un eslogan. Aprueba límites operativos para disponibilidad, confidencialidad, integridad, proveedores, vulnerabilidades, recuperación y cumplimiento.

La Política de gestión de riesgos de Clarysec respalda este modelo de gobernanza. La política empresarial establece:

“Aprueba el Marco de gestión del riesgo y define el apetito de riesgo aceptable y los umbrales de tolerancia.”

La cláusula 6.2.1 explicita el requisito de medición:

“Los riesgos se evaluarán en función de la probabilidad y el impacto usando una matriz de riesgos estándar con escalas de calificación claramente definidas.”

La cláusula 6.3.4 crea la regla de aceptación que los auditores esperarán:

“Los riesgos aceptados sin tratamiento se justificarán por escrito, se vincularán al apetito de riesgo de la organización y se aprobarán en el nivel adecuado.”

Para pymes, la Política de gestión de riesgos para pymes mantiene el mismo principio de gobernanza en un formato más ligero:

“Asegurar la participación de la dirección en la aprobación de la tolerancia al riesgo y de los principales planes de tratamiento del riesgo.”

También exige el escalado de riesgos altos:

“Los riesgos altos deben escalarse al Director General para decisión.”

Esto es proporcionalidad en la práctica. DORA Article 4 exige que los requisitos se apliquen de forma proporcionada al tamaño, el perfil de riesgo y la naturaleza, escala y complejidad de los servicios. ISO/IEC 27001:2022 habilita el mismo principio mediante alcance, contexto, criterios de riesgo y decisiones de tratamiento. El estándar de gobernanza no es que todas las organizaciones necesiten la misma estructura de comités. El estándar de gobernanza es que el apetito de riesgo, la tolerancia, el escalado y la aceptación estén definidos, aprobados, evidenciados y utilizados.

GDPR Article 32 cambia la conversación sobre riesgos

GDPR Article 32 suele tratarse como una cláusula técnica de seguridad. En términos de gobernanza, también es una cláusula de apetito de riesgo.

Article 32 exige que los responsables del tratamiento y encargados del tratamiento apliquen medidas técnicas y organizativas apropiadas para garantizar un nivel de seguridad adecuado al riesgo. Ese enfoque basado en riesgos considera el estado de la técnica, los costes de aplicación, la naturaleza, el alcance, el contexto y los fines del tratamiento, y los riesgos para los derechos y libertades de las personas físicas.

Esto afecta al apetito de riesgo TIC de tres formas.

Primero, el impacto sobre datos personales no puede reducirse a pérdida financiera. La exposición de una base de datos pequeña puede tener un coste directo limitado, pero consecuencias graves para la confidencialidad, la identidad, el fraude, la discriminación o el impacto sobre derechos. Si se tratan categorías especiales de datos personales, como datos de salud, biométricos o genéticos, el apetito debe ser materialmente menor.

Segundo, los roles de tratamiento deben conectarse con la propiedad del riesgo. GDPR distingue entre responsables del tratamiento y encargados del tratamiento. DORA distingue entre entidades financieras y proveedores terceros de servicios TIC. NIS2 distingue entre entidades esenciales e importantes. ISO/IEC 27001:2022 exige propietarios del riesgo. Una declaración de apetito madura debe identificar quién es propietario de las decisiones de riesgo que implican datos personales, tratamiento externalizado, servicios críticos y dependencias transfronterizas.

Tercero, la proporcionalidad de Article 32 debe ser visible en la selección de controles. Cifrado, seudonimización, control de acceso, copia de seguridad, registro de eventos, supervisión, respuesta a incidentes y resiliencia no son tareas técnicas aisladas. Son medidas de tratamiento seleccionadas porque un riesgo superó el apetito o la tolerancia.

La Política de gestión de riesgos de Clarysec lo conecta explícitamente:

“Article 32: exige un enfoque basado en riesgos para las medidas de seguridad, cumplido mediante evaluaciones de riesgos basadas en impacto y selección de controles.”

Ese es el vínculo operativo que buscan los auditores: requisito de Article 32, evaluación de riesgos, calificación del riesgo, plan de tratamiento de riesgos, selección de controles, riesgo residual y aprobación.

Cómo Zenith Controls respalda evidencias de cumplimiento cruzado

Una declaración de apetito aprobada por el consejo de administración adquiere valor cuando se mapea a controles. Zenith Controls actúa como la guía de cumplimiento cruzado de Clarysec, ayudando a los equipos a reutilizar evidencias en ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF y aseguramiento al estilo COBIT.

Tres áreas de control de ISO/IEC 27002:2022 son especialmente importantes:

Esto no es un ejercicio documental de mapeo. Cambia la forma en que se toman decisiones.

Si un propietario de negocio solicita aceptar un retraso en el despliegue de MFA para administradores, Zenith Controls ayuda al CISO a mostrar por qué no es solo una cuestión de control de acceso. Afecta a la gobernanza de políticas, la responsabilidad de la dirección, los requisitos legales y regulatorios, la seguridad del tratamiento en GDPR, la gestión del riesgo TIC de DORA, las medidas de ciberseguridad de NIS2, el impacto de incidentes y las evidencias de auditoría.

Si un equipo de producto quiere lanzarse en un nuevo mercado de la UE usando un nuevo servicio en la nube, el control 5.31 de ISO/IEC 27002:2022 incorpora la revisión de requisitos legales y regulatorios al alcance del SGSI. La cláusula 4.2 de ISO/IEC 27001:2022 exige identificar los requisitos de las partes interesadas, incluidas obligaciones legales, regulatorias y contractuales. La cláusula 8.1 exige planificación y control operacional, incluido el control de procesos, productos o servicios suministrados externamente que sean relevantes para el SGSI.

El objetivo es un único lenguaje de riesgos, no dialectos de cumplimiento separados.

Flujo de aprobación: quién decide qué

Un CISO puede proponer el apetito de riesgo TIC, pero el consejo de administración u órgano de administración debe asumir su titularidad. Esa titularidad necesita un flujo de trabajo.

Esto también se alinea con NIST CSF 2.0. La función GOVERN, especialmente GV.RM, espera objetivos acordados de gestión de riesgos, declaraciones de apetito de riesgo y tolerancia, actividades de riesgo integradas en la gestión de riesgos empresariales, opciones definidas de respuesta al riesgo, líneas de comunicación y métodos estandarizados para calcular, documentar, categorizar y priorizar riesgos de ciberseguridad. GV.RR espera responsabilidad de liderazgo, roles, autoridades y recursos alineados con la estrategia de riesgo. GV.PO espera que las políticas se establezcan, comuniquen, apliquen, revisen y actualicen.

Los profesionales de aseguramiento al estilo COBIT 2019 e ISACA preguntarán si el apetito de riesgo está integrado en la gobernanza empresarial de la información y la tecnología, no simplemente adjunto como anexo a una política de ciberseguridad.

Construir un paquete de apetito de riesgo TIC en una sola sesión de trabajo

Un taller práctico de apetito de riesgo TIC puede llevar a una organización desde registros dispersos hasta un paquete auditable para el consejo de administración.

Paso 1: recopilar las entradas correctas

Prepare el registro de riesgos TIC actual, el análisis de impacto en el negocio, los objetivos de recuperación, la lista de funciones críticas o importantes, el inventario de activos TIC, el inventario de servicios TIC, el registro de dependencias de proveedores y servicios en la nube, los criterios de clasificación de incidentes, el inventario de tratamientos de GDPR, las DPIA cuando proceda, el registro de obligaciones legales, las políticas, la Declaración de Aplicabilidad y la declaración existente de apetito de riesgo empresarial.

Esto se alinea con las cláusulas 4, 6 y 8 de ISO/IEC 27001:2022, y con los métodos de perfiles de NIST CSF que comienzan por prioridades de negocio, prioridades de riesgo, requisitos, salvaguardas y roles.

Paso 2: definir escalas de impacto que incluyan regulación

Usando el paso 10 de Zenith Blueprint, defina probabilidad e impacto en lenguaje de negocio. Incluya pérdida financiera, interrupción operativa, impacto en clientes, daño reputacional, impacto legal y regulatorio, daño a los interesados e impacto en funciones críticas.

Por ejemplo, un impacto “Mayor” podría incluir una indisponibilidad prolongada de un servicio crítico, una brecha de datos personales confirmada que requiera notificación, el incumplimiento de una obligación de notificación de incidentes de DORA o el fallo de un proveedor que afecte a una función crítica o importante.

Paso 3: redactar el apetito por dominio

No cree un único apetito cibernético genérico. Defina dominios como disponibilidad de servicios críticos, confidencialidad de datos personales, integridad de los datos, acceso privilegiado, dependencia de terceros TIC, concentración en la nube, exposición a vulnerabilidades, preparación para la notificación de incidentes, copia de seguridad y recuperación, y riesgo de cambios en desarrollo seguro.

Para cada dominio, redacte una declaración de apetito, uno o varios umbrales de tolerancia y desencadenantes de escalado.

Paso 4: conectar el tratamiento con la Declaración de Aplicabilidad

El paso 13 de Zenith Blueprint indica a las organizaciones que elijan opciones de tratamiento del riesgo: mitigar, evitar, transferir o aceptar. También subraya la aprobación por la dirección:

“Las decisiones de tratamiento del riesgo y la SoA deben ser revisadas y aprobadas por la Alta dirección.”

Para DORA y NIS2, esto evidencia que el órgano de administración o el liderazgo delegado revisó riesgos clave, tratamientos y exposición residual aceptada. Para GDPR, respalda la responsabilidad proactiva al mostrar por qué las medidas seleccionadas eran adecuadas al riesgo.

Paso 5: registrar la aceptación con caducidad y condiciones

Todo riesgo residual medio o alto aceptado debe incluir:

• ID del riesgo y propietario
• Justificación de negocio
• Referencia a la declaración de apetito
• Umbral de tolerancia afectado
• Análisis legal y regulatorio
• Controles compensatorios
• Fecha de caducidad o revisión
• Aprobador
• Ubicación de las evidencias
• Desencadenante para reabrir la decisión

La Política de gestión de riesgos para pymes establece:

“Cualquier decisión de aceptar o diferir el tratamiento de un riesgo alto o medio debe documentarse en el Registro de Riesgos. Esta documentación debe incluir:”

En entornos empresariales, esto se convierte en un flujo de aprobación y un paquete para el comité de riesgos. En organizaciones más pequeñas, puede ser una pestaña estructurada del registro de riesgos con aprobación formal de la dirección. El objetivo no es la burocracia. El objetivo es la defensa jurídica.

Tolerancia a incidentes: donde el apetito se encuentra con el reloj

El apetito de riesgo se vuelve real durante los incidentes.

DORA Article 17 exige que las entidades financieras establezcan un proceso de gestión de incidentes relacionados con TIC para detectar, gestionar y notificar incidentes, registrar todos los incidentes y ciberamenazas significativas, identificar causas raíz, usar indicadores de alerta temprana, clasificar incidentes por prioridad, severidad y criticidad del servicio, asignar roles, comunicar a las partes interesadas, escalar al menos los incidentes graves relacionados con TIC a la alta dirección y al órgano de administración, y restaurar operaciones seguras en plazo oportuno.

DORA Article 18 clasifica los incidentes usando factores como clientes afectados, duración, indisponibilidad, extensión geográfica, pérdidas de datos que afecten a disponibilidad, autenticidad, integridad o confidencialidad, criticidad de los servicios afectados e impacto económico. Article 19 exige que los incidentes graves relacionados con TIC se notifiquen a la autoridad competente, informando a los clientes cuando sus intereses financieros se vean afectados.

NIS2 Article 23 tiene una notificación por fases para incidentes significativos, incluida alerta temprana sin demora indebida y, cuando proceda, en un plazo de 24 horas; notificación del incidente sin demora indebida y, cuando proceda, en un plazo de 72 horas; actualizaciones intermedias cuando se soliciten; y un informe final no más tarde de un mes después de la notificación del incidente. Los incidentes significativos incluyen los que causan interrupción operativa grave, pérdida financiera o daño material o inmaterial a terceros.

La declaración de apetito debe definir umbrales de escalado antes de que ocurra el incidente.

Los controles del Anexo A sobre planificación de incidentes, evaluación de eventos de seguridad de la información, respuesta a incidentes, aprendizaje de incidentes, recopilación de evidencias, mantenimiento de la seguridad de la información durante interrupciones y preparación TIC para la continuidad de negocio respaldan todos estos umbrales. Los resultados de NIST CSF en IDENTIFY, PROTECT, DETECT, RESPOND y RECOVER respaldan el mismo modelo operativo, incluidas copias de seguridad, supervisión, declaración de incidentes, escalado, análisis de causa raíz, comunicación con partes interesadas y verificación de recuperación.

La tolerancia de proveedores y nube que los consejos de administración suelen omitir

DORA convierte el riesgo de terceros TIC en una obligación central de cumplimiento. Article 28 exige que las entidades financieras gestionen el riesgo de terceros TIC como parte del marco de gestión del riesgo TIC, manteniendo al mismo tiempo la plena responsabilidad sobre el cumplimiento. Exige estrategia de riesgo de terceros TIC, registros de acuerdos contractuales de servicios TIC, distinción de servicios que soportan funciones críticas o importantes, reporte anual, notificación de acuerdos previstos, evaluaciones precontractuales, diligencia debida, derechos de auditoría e inspección, derechos de terminación y estrategias de salida documentadas.

Article 29 añade análisis de riesgo de concentración, incluida la no sustituibilidad, múltiples dependencias del mismo proveedor o de proveedores conectados, riesgos de subcontratación, subcontratistas de terceros países, cumplimiento de protección de datos, exigibilidad y cadenas complejas de subcontratación. Article 30 exige derechos y obligaciones contractuales por escrito, descripciones de servicios, ubicaciones, protecciones de seguridad, acceso y devolución de datos, niveles de servicio, asistencia en incidentes, cooperación con autoridades, derechos de terminación, planes de contingencia probados, supervisión y acuerdos de salida.

Una declaración de tolerancia de proveedores aprobada por el consejo de administración podría decir:

“Tenemos bajo apetito por que funciones críticas o importantes dependan de un proveedor tercero de servicios TIC cuando carecemos de derechos contractuales de auditoría, acuerdos de salida probados, obligaciones de notificación de incidentes, objetivos de nivel de servicio, derechos de devolución de datos o visibilidad sobre subcontratación material.”

Esa frase proporciona a compras una regla práctica. Si el contrato no cumple el umbral, el riesgo no puede ser aceptado discretamente por el equipo de proyecto.

Cómo probarán los auditores su apetito de riesgo TIC

Una declaración sólida de apetito se diseña pensando en auditoría.

El paso 28 de Zenith Blueprint, en la fase de auditoría, revisión y mejora, refuerza la capa de revisión por la dirección. Indica a las organizaciones que recopilen entradas como cambios en cuestiones externas e internas, desempeño del SGSI, resultados de auditoría, supervisión y medición, incidentes, no conformidades, oportunidades de mejora y necesidades de recursos. También señala que la revisión por la dirección debe generar decisiones y acciones, no solo presentaciones.

Al menos anualmente, y siempre que haya cambios materiales, la dirección debe revisar si los umbrales de tolerancia siguen alineados con el modelo de negocio, si los incidentes superaron el apetito, si los riesgos aceptados permanecen dentro de los límites aprobados, si nuevos requisitos de DORA, NIS2, GDPR o contractuales cambiaron la configuración de referencia, si los proveedores se mantienen dentro de las tolerancias de concentración y si los KRI están provocando escalados oportunos.

Si la respuesta es no, debe cambiar la declaración de apetito o deben cambiar los controles.

Patrones habituales de fallo en trabajos de preparación para 2026

En proyectos DORA, NIS2, GDPR e ISO/IEC 27001:2022, aparecen repetidamente las mismas debilidades:

• Apetito sin umbrales, donde el consejo de administración aprueba una declaración pero nadie puede decir cuándo se ha vulnerado.
• Umbrales sin autoridad, donde existen niveles de severidad pero los propietarios del riesgo pueden aceptar excepciones sin aprobación superior.
• Riesgo legal fuera del modelo de calificación, donde GDPR, DORA, NIS2 y contratos se enumeran por separado pero no se integran en los criterios de impacto.
• Tolerancia de proveedores ausente del paquete del consejo de administración, aunque compras o TI conocen las dependencias TIC críticas.
• Revisión por la dirección como teatro, donde se presentan diapositivas pero no se documentan decisiones, acciones, necesidades de recursos ni aceptaciones de riesgo.
• Fragmentación de evidencias de auditoría, donde políticas, registros, KRI, informes de incidentes, revisiones de proveedores y actas del consejo de administración existen en lugares distintos sin referencias cruzadas.

El enfoque de Clarysec está diseñado para eliminar estas brechas. Zenith Blueprint proporciona la ruta de implantación por fases. La Política de gestión de riesgos y la Política de gestión de riesgos para pymes proporcionan cláusulas de gobernanza escaladas para entornos empresariales y pymes. Zenith Controls mapea la columna vertebral de controles en políticas de seguridad de la información, responsabilidad de la dirección y requisitos legales o regulatorios, haciendo que las evidencias sean reutilizables en ISO/IEC 27001:2022, DORA, NIS2, GDPR, NIST CSF y aseguramiento al estilo COBIT.

Convertir la intención del consejo de administración en gobernanza auditable del riesgo TIC

Si su organización tiene un registro de riesgos pero no puede mostrar un apetito de riesgo TIC aprobado por el consejo de administración, umbrales de tolerancia medibles, desencadenantes de escalado y reglas formales de aceptación, la brecha no es cosmética. Afecta a la gobernanza de DORA, la responsabilidad de la dirección en NIS2, la defensa jurídica de GDPR Article 32 y la preparación para auditorías de ISO/IEC 27001:2022.

Un siguiente paso práctico es ejecutar un taller focalizado de apetito de riesgo TIC usando el toolkit de Clarysec:

1. Use el paso 10 de Zenith Blueprint para definir criterios de riesgo y escalas de impacto.
2. Use el paso 13 de Zenith Blueprint para vincular opciones de tratamiento, riesgo residual y aprobación de la Declaración de Aplicabilidad.
3. Use el paso 14 de Zenith Blueprint para establecer referencias cruzadas con obligaciones de GDPR, NIS2 y DORA.
4. Use el paso 28 de Zenith Blueprint para incorporar apetito, KRI, riesgos aceptados y decisiones sobre recursos a la revisión por la dirección.
5. Aplique la Política de gestión de riesgos o la Política de gestión de riesgos para pymes para formalizar reglas de aprobación y aceptación.
6. Use Zenith Controls para mapear controles de gobernanza a evidencias de auditoría y expectativas de cumplimiento cruzado.

Clarysec puede ayudarle a convertir artefactos de riesgo dispersos en un modelo de apetito de riesgo TIC aprobado por el consejo de administración y listo para reguladores, que sus equipos puedan usar cuando la próxima indisponibilidad de la nube, fallo de proveedor, divulgación de vulnerabilidad o incidente de datos personales ponga a prueba la tolerancia real de la organización.