DORA

aspectos central

> - DORA crea obligaciones para firmas que prestan servicios de certificación en la UE, no solo para bancos. Quien audita una entidad financiera regulada (banco, asegurador, gestor de activos, proveedor de pagos, prestamista no bancario) entra en alcance. > - El cambio operativo de NIA-ES 315: muchos riesgos de TI que antes eran "normales" son ahora riesgos de aseveración significativa en entidades financieras. > - La firma tiene también obligaciones propias bajo DORA. Auditar el cumplimiento DORA del cliente sin haber implementado DORA en la propia firma es lo que el ICAC empezó a marcar en 2025.

---

Cómo funciona

La Directiva sobre la Resiliencia Operacional Digital (DORA) es un marco regulatorio de la UE que establece requisitos de gestión de riesgos de TI para entidades financieras, incluidas las firmas que prestan servicios de certificación. Rige desde enero de 2025. Eso es lo que dice el manual. Lo que ocurre en la práctica es que la mayoría de los archivos pre-2025 trataban los riesgos de TI como riesgos de proceso, y muchos archivos post-2025 siguen haciéndolo por inercia.

DORA crea dos capas de obligación que conviven en el mismo encargo:

Capa 1: Obligaciones propias de la firma. La firma debe establecer políticas de gestión de riesgos de TI, resiliencia ante incidentes de ciberseguridad, pruebas de estrés de sistemas críticos, y planes de continuidad. La supervisión en la UE (a través de los reguladores nacionales de auditoría) ahora incluye evaluación de cumplimiento DORA. Esto no es un papel administrativo más — es contenido del MOI que el ICAC pide cuando viene.

Capa 2: Obligaciones de auditoría. Cuando se audita a una entidad financiera regulada por DORA, el auditor debe entender si la entidad ha implementado correctamente los controles de resiliencia digital exigidos. La NIA-ES 315 ya exigía identificar riesgos de error material; DORA expande qué se considera riesgo importante en entidades financieras. Un fallo de sistema que afecte a la capacidad de procesar transacciones es ahora un riesgo de aseveración directa.

Para las firmas, DORA introduce tres cambios en el tratamiento de riesgos de TI:

1. Clasificación elevada. Los riesgos de TI dejan de ser por defecto riesgos "normales" de proceso en entidades financieras. 2. Documentación de incidentes. Cualquier hallazgo de seguridad debe evaluarse contra el umbral de "incidente grave" bajo el artículo 2(h). Esto requiere documentación clara de severidad, alcance y tiempo de remediación. 3. Coordinación con supervisores. La firma debe entender quién es el supervisor relevante (regulador nacional de auditoría o, en bancos grandes, el BCE) para cumplir las obligaciones de notificación.

Por lo que conozco, lo que más cuesta a los equipos no es el cambio normativo en sí — es desconectar el reflejo de tratar los riesgos de TI como riesgos de control general y empezar a tratarlos como riesgos de aseveración con su propia evaluación bajo NIA-ES 315.25.

---

Ejemplo práctico: Talleres Mecánicos Europeos S.A.

Cliente: Talleres Mecánicos Europeos S.A., empresa prestamista no bancaria regulada por DORA (proveedor de servicios financieros bajo la UE), facturación 28,5 millones de euros, informa bajo NIIF, ubicada en Barcelona.

Situación: Durante la auditoría de 2024, el equipo identifica que el cliente tuvo un fallo no documentado en su sistema de autorización de préstamos durante tres días en octubre. El sistema falló, causando un retraso de 72 horas en el procesamiento de aprobaciones. El cliente remediaba el problema sin informar a su supervisor.

Paso 1: Clasificación bajo DORA El auditor evalúa si el incidente es "grave" conforme al artículo 2(h). Criterios: - ¿Afectó a servicios financieros críticos? Sí (las autorizaciones de préstamos son críticas). - ¿Duró más de 15 minutos? Sí (72 horas). - ¿Afectó a la integridad de registros? Potencialmente, si las aprobaciones no se registraron correctamente.

Nota de documentación: PT-210, "Evaluación de incidentes de ciberseguridad bajo DORA." Documenta: fecha del incidente (15 de octubre de 2024), sistemas afectados (módulo de autorización, SL-AUTH-2024), duración (72 horas), número de transacciones afectadas (347), remediación implementada, fecha de notificación al regulador.

Paso 2: Evaluación de riesgo de aseveración El hallazgo toca dos aseveraciones: integridad (¿se registraron todas las transacciones correctamente?) y exactitud (¿se aprobaron los montos correctos?). Bajo NIA-ES 315.25 es un riesgo de error material significativo porque afecta a la confiabilidad de los registros de ingresos y de cartera.

Nota de documentación: PT-320, "Riesgos de aseveración identificados." Riesgo = "Fallo de sistema de autorización causa subregistro o error de montos en ingresos por intereses"; estándar aplicable = NIA-ES 315.25 (riesgo importante); marco DORA aplicable = artículos 3-6.

Paso 3: La complicación — desacuerdo entre socios sobre la respuesta El socio A quiso aplicar procedimientos sustantivos de muestreo sobre los 347 préstamos del período del fallo y cerrar el asunto: "El error final será inmaterial y eso es lo que importa al usuario."

El socio B insistió en complementar con evaluación de cumplimiento DORA: "No es solo si las cuentas están bien. Es si la entidad tiene los controles que DORA exige. La ausencia de pruebas de resiliencia (artículo 18) y el retraso en la notificación al regulador son hallazgos en sí mismos, separados del error contable."

Ambos tienen razón en parte. El socio A protege la imagen fiel; el socio B protege la posición de la firma frente al ICAC. La decisión final fue ejecutar ambos enfoques: muestreo sustantivo Y evaluación de cumplimiento, con un párrafo de énfasis de cuestión propuesto si el cumplimiento DORA del cliente resultaba materialmente deficiente.

Nota de documentación: PT-325, "Discrepancia interna sobre alcance DORA. Posición A: enfoque sustantivo. Posición B: enfoque sustantivo + cumplimiento. Decisión final: ambos. Razón: la separación entre riesgo contable y riesgo regulatorio bajo DORA es la zona gris donde el ICAC mira primero."

Paso 4: Procedimientos de auditoría - Verificar la integridad de los 347 préstamos del período del fallo (reconciliación de términos aprobados vs. registrados). - Entrevistar a la dirección sobre políticas de backup y recuperación. - Revisar si la entidad realizó pruebas de resiliencia (artículo 18 DORA).

Nota de documentación: PT-330, "Procedimientos en respuesta al riesgo de fallo de sistema." Muestra de 50 transacciones verificadas; resultados: 3 discrepancias menores en montos de intereses; estimación del error = 2.400 euros.

Paso 5: Evaluación de obligaciones de notificación bajo DORA - ¿La entidad reportó al regulador? No, hasta que el equipo lo planteó en la reunión de hallazgos. - ¿Fue grave bajo DORA? Sí. - ¿Es responsabilidad del auditor reportar? No directamente; la responsabilidad es de la entidad. Pero el auditor debe comunicarlo a la dirección y, si la dirección no cumple, considerar si esto es incumplimiento regulatorio comunicable.

Nota de documentación: PT-340. Fecha de identificación del incidente por la dirección = 15 de octubre. Comunicación a la dirección por el equipo = 12 de enero de 2025. Confirmación de que la dirección notificó al regulador = 13 de enero (prueba en archivo).

Conclusión. El incidente fue grave bajo DORA, fue remediado por la dirección con retraso, y fue notificado al regulador después de la intervención del equipo. El error de 2.400 euros es inmaterial (0,008% de ingresos por intereses). El auditor incluye un párrafo en la carta de gestión recomendando monitoreo automatizado de disponibilidad de sistemas críticos. La opinión es sin salvedades. Pero — y esta es la parte que cambia con DORA — el archivo contiene ahora un riesgo de aseveración formalmente identificado, evaluado y respondido, donde antes habría una nota administrativa.

---

Qué confunden los auditores y revisores sobre DORA

- Confusión sobre alcance regulatorio: Muchos creen que DORA solo aplica a bancos grandes. Aplica a cualquier entidad financiera regulada en la UE: aseguradoras, gestores de activos, proveedores de pagos, prestamistas no bancarios. La firma debe conocer la clasificación regulatoria exacta del cliente para determinar qué requisitos DORA aplican.

- Falta de documentación de evaluación de "gravedad": Los equipos identifican incidentes pero no documentan explícitamente si cumplen el umbral del artículo 2(h). Sin esa evaluación documentada, la firma queda expuesta a crítica regulatoria si el incidente resulta serlo y nadie lo escaló.

- Confusión entre obligaciones de la entidad auditada vs. obligaciones de la firma: DORA crea obligaciones para ambos. Algunas firmas auditan cumplimiento DORA del cliente sin haber implementado DORA en su propia operación. Los reguladores nacionales ahora incluyen verificación de cumplimiento DORA en inspecciones de firmas. Es un brindis al sol auditar lo que tú mismo no cumples.

- Tratamiento residual de TI bajo NIA-ES 315: El reflejo es clasificar riesgos de TI como riesgos de control general, casi nunca como riesgos de aseveración. En entidades financieras post-DORA, esa distribución debería invertirse para sistemas críticos. Lo que cambia no es la NIA-ES 315 — cambia la calibración de qué se considera "importante" cuando la entidad opera bajo DORA.

El incentivo perverso aquí: ampliar el alcance bajo DORA implica más horas, más coordinación con el cliente, más papeleo. La presión de honorarios empuja a no abrir esa caja. Los archivos que pasan inspección son los que documentan deliberadamente por qué un riesgo de TI fue o no fue tratado como riesgo de aseveración significativa, no los que evitan el debate.

---

Comparación: DORA vs. requisitos previos de ciberseguridad

Antes de DORA: La seguridad de TI se abordaba a través de NIA-ES 315 (identificación de riesgos) y consideraciones ad hoc. No había un marco unificado para ciberseguridad de entidades financieras. El riesgo de ciberseguridad se documentaba como riesgo de negocio, sin obligación de notificación de incidentes graves a supervisores.

Con DORA (desde enero de 2025): La seguridad de TI es una obligación regulatoria explícita con requisitos detallados (gestión de riesgos, pruebas de resiliencia, notificación de incidentes, coordinación con supervisores). Un incidente que antes era una "observación sobre riesgos de TI" es ahora potencialmente un hallazgo de incumplimiento regulatorio, y un fallo que antes era un riesgo de control es ahora un riesgo de aseveración.

---

Términos relacionados

- ISA 315 (NIA-ES 315): Identificación y evaluación de riesgos: El estándar base que exige al auditor entender los riesgos importantes de la entidad, ahora expandido en contexto de entidades financieras reguladas por DORA. - Riesgo de aseveración significativa: Clasificación de riesgo elevado bajo NIA-ES 315; DORA ha elevado muchos riesgos de TI a esta categoría en entidades financieras. - Incidente de ciberseguridad: Evento que afecta a la confidencialidad, integridad o disponibilidad de sistemas o datos; bajo DORA, los incidentes graves deben reportarse. - Resiliencia operacional digital: Capacidad de una entidad de resistir, adaptarse y recuperarse de perturbaciones de TI; requisito central de DORA. - Pruebas de resiliencia (stress testing): Ejercicios de simulación requeridos por DORA para verificar que sistemas pueden funcionar bajo presión; los auditores deben verificar que se realizan. - Proveedor de servicios críticos: Bajo DORA, terceros cuya disponibilidad es crítica para la entidad (proveedores en la nube, procesadores de pagos); cambios en proveedores críticos deben notificarse a supervisores.

---

Herramienta de evaluación DORA

Si audita una entidad financiera regulada en la UE, use la lista de verificación de resiliencia operacional digital NIA-ES 315 para documentar sistemáticamente cómo verifica que la entidad cumple con requisitos DORA de gestión de riesgos, pruebas de resiliencia y planes de respuesta a incidentes.

---

Lecturas relacionadas

- Guía de auditoría de riesgos de tecnología en entidades financieras: Procedimientos específicos para entidades financieras bajo NIA-ES 315 y 330. - Identificación de riesgos importantes bajo NIA-ES 315: Cómo clasificar riesgos de TI como riesgos importantes cuando audita bajo estándares ISA. - Documentación de hallazgos de ciberseguridad en papeles de trabajo: Estructura de documentación para incidentes en contexto de auditoría.

---