aspectos central
DORA crea obligaciones directas para firmas de auditoría que prestan servicios de certificación en UE, no solo para bancos y aseguradoras.
La auditoría debe documentar cómo verifica la resiliencia operacional digital del cliente (requisito ISA 315); DORA cambia el contexto de lo que es "riesgo de tecnología" en la auditoría.
Las firmas deben informar de incidentes graves de ciberseguridad a sus supervisores; esto afecta a cómo se documentan los hallazgos relacionados con seguridad en los papeles de trabajo.
---
Cómo funciona
DORA (Directiva 2024/2561) entró en vigor el 16 de diciembre de 2024. Aunque el texto es técnicamente una directiva de la UE sobre resiliencia operacional digital de entidades financieras, su aplicación a firmas de auditoría crea obligaciones tanto sustantivas como de auditoría.
Para las firmas de auditoría, DORA establece dos capas de obligación:
Capa 1: Obligaciones propias de la firma. Las firmas deben establecer políticas de gestión de riesgos de TI, resilencia ante incidentes de ciberseguridad, pruebas de estrés de sistemas críticos, y planes de continuidad. Esto no es una sugerencia; es un requisito regulatorio. La supervisión en la UE (a través de los reguladores nacionales de auditoría) ahora incluye evaluación de cumplimiento de DORA.
Capa 2: Obligaciones de auditoría. Cuando se audita a una entidad financiera regulada por DORA (un banco, asegurador, gestor de activos o proveedor de servicios de pago), el auditor debe entender si la entidad ha implementado correctamente los controles de resiliencia digital exigidos por DORA. La NIA-ES 315 (o ISA 315 en su forma base) requiere que el auditor identifique y evalúe los riesgos de error material; DORA ha expandido qué se considera un riesgo importante en entidades financieras. Un incidente de ciberseguridad o fallo de sistema que afecte a la capacidad de la entidad de procesar transacciones es ahora un riesgo de aseveración directa bajo DORA.
Las firmas de auditoría también tienen obligaciones de reporte. Si se identifica un incidente de ciberseguridad grave durante la auditoría (o si la entidad informa a la firma durante el trabajo), la firma debe comunicarlo a su supervisor nacional de auditoría dentro de 72 horas en casos de severidad alta. Esto ha creado una nueva responsabilidad de documentación en los papeles de trabajo.
Desde el punto de vista práctico, DORA introduce tres cambios en cómo los auditores tratan los riesgos de TI:
---
- Clasificación elevada. Los riesgos de TI ya no son siempre un riesgo "normal" de proceso. Para entidades financieras, muchos riesgos de TI son ahora riesgos de aseveración significativa porque pueden afectar directamente a la confiabilidad de los registros contables o la capacidad de la entidad de operar.
- Documentación de incidentes. Cualquier hallazgo de seguridad debe evaluarse contra el umbral de "incidente grave" bajo DORA. Esto requiere documentación clara de severidad, alcance y tiempo de remediación.
- Coordinación con supervisores. Las firmas deben entender quién es el supervisor relevante (el regulador de auditoría nacional o, en el caso de bancos grandes, el BCE) para cumplir correctamente con las obligaciones de reporte.
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 de 28,5 millones de euros, informes bajo NIIF, ubicada en Barcelona.
Situación: Durante la auditoría de 2024, el equipo auditor 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ó, lo que causó un retraso de 72 horas en el procesamiento de aprobaciones. El cliente remediaba el problema sin informar a su supervisor regulatorio.
Paso 1: Clasificación bajo DORA. El auditor evalúa si el incidente es "grave" conforme al artículo 2(h) de DORA. 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 sí, si las aprobaciones no se registraron correctamente.
Nota de documentación: PT-210, "Evaluación de incidentes de ciberseguridad bajo DORA." Se 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, y fecha de notificación al regulador.
Paso 2: Evaluación de riesgo de aseveración. El auditor determina que este hallazgo toca dos aseveraciones: integridad (¿se registraron todas las transacciones correctamente?) y exactitud (¿se aprobaron los montos correctos?). Bajo NIA-ES 315.25, esto es un riesgo de error material significativo porque afecta directamente a la confiabilidad de los registros de ingresos y de cartera de préstamos.
Nota de documentación: PT-320, "Riesgos de aseveración identificados." Se documenta: 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 (gestión de riesgos operacionales, pruebas de resiliencia).
Paso 3: Procedimientos de auditoría. El auditor diseña procedimientos para:
Nota de documentación: PT-330, "Procedimientos de auditoría en respuesta al riesgo de fallo de sistema." Se documenta: muestra de 50 transacciones verificadas elemento por elemento; resultados: 3 discrepancias menores en montos de intereses (errores de acumulación, no de aprobación); estimación del error = €2.400.
Paso 4: Evaluación de necesidad de reporte bajo DORA. El auditor evalúa si el incidente debe reportarse al supervisor nacional dentro de 72 horas. Criterios bajo DORA artículo 21:
Nota de documentación: PT-340, "Evaluación de obligaciones de reporte bajo DORA." Se documenta: fecha de identificación del incidente por la dirección = 15 de octubre (ya más de 72 días antes de la auditoría); criterios DORA evaluados; comunicación a la dirección realizada (acta de reunión, 12 de enero de 2025); confirmación de que la dirección notificó al regulador el 13 de enero (prueba en archivo).
Conclusión. El incidente fue grave bajo DORA, fue correctamente remediado por la dirección después de un retraso, y fue finalmente reportado al regulador. El error de €2.400 es inmaterial para los estados financieros (0,008% de ingresos por intereses de 28,5M). El auditor incluye un párrafo en la carta de gestión recomendando aplicación de monitoreo automatizado de disponibilidad de sistemas críticos (control preventivo no presente en DORA artículo 6). La opinión es sin salvedades porque no hay incidencia en las aseveraciones materiales; sin embargo, DORA ha convertido lo que hace cinco años hubiera sido una observación administrativa en un riesgo de aseveración formalmente identificado.
---
- Verificar la integridad de los 347 préstamos que pasaron por el sistema durante el fallo (reconciliación de términos aprobados vs. registrados).
- Entrevistar a la dirección sobre políticas de backup y recuperación de sistemas (NIA-ES 315 exige entendimiento de cómo la entidad gestiona riesgos de TI).
- Revisar si la entidad había realizado "pruebas de resiliencia" (stress testing) como exige DORA artículo 18; si no, esto es un hallazgo de cumplimiento.
- ¿La entidad ya reportó al regulador? No.
- ¿Fue grave bajo DORA? Sí (más de 15 minutos, servicios críticos afectados).
- ¿Es responsabilidad del auditor reportar? No directamente; la responsabilidad es de la entidad. Pero el auditor tiene obligación de comunicarlo a la dirección y, si la dirección no cumple con el reporte, considerar si esto es un acto de incumplimiento regulatorio que debe comunicarse.
Qué confunden los auditores y revisores sobre DORA
---
- Confusión sobre alcance regulatorio: Muchos auditores creen que DORA solo aplica a bancos grandes. En realidad, aplica a cualquier entidad financiera regulada en la UE, incluidas empresas de seguros, gestores de activos, proveedores de servicios de pago, y prestamistas no bancarios. La firma de auditoría debe conocer la clasificación regulatoria exacta de su cliente para determinar qué requisitos de DORA aplican.
- Falta de documentación de evaluación de "gravedad": Los auditores a menudo identifican incidentes de ciberseguridad pero no documentan explícitamente si cumplen el umbral de DORA de "incidente grave" (artículo 2(h)). El reporte a supervisores está condicionado a esta clasificación. Sin documentación clara de por qué sí o no es "grave," la firma está expuesta a crítica regulatoria posterior.
- Confusión entre obligaciones de la entidad auditada vs. obligaciones de la firma auditora: DORA crea obligaciones tanto para la entidad financiera auditada como para la propia firma de auditoría. Algunas firmas auditan cumplimiento DORA de sus clientes pero no han implementado DORA en su propia operación de auditoría (gestión de riesgos de TI, planes de continuidad). Los reguladores nacionales ahora incluyen verificación de cumplimiento de DORA en inspecciones de firmas.
Comparación: DORA vs. requisitos previos de ciberseguridad
Antes de DORA: Los auditores abordaban la seguridad de TI principalmente a través de NIA-ES 315 (identificación de riesgos) y consideraciones ad hoc. No había un marco regulatorio unificado para ciberseguridad de entidades financieras. El riesgo de ciberseguridad se documentaba como un riesgo de negocio, pero no existía obligación de reporte de incidentes graves a supervisores.
Con DORA (a partir de enero de 2025): La seguridad de TI es ahora una obligación regulatoria explícita con requisitos detallados (gestión de riesgos, pruebas de resiliencia, reporte de incidentes, coordinación con supervisores). Esto cambia cómo el auditor evalúa y documenta hallazgos relacionados con TI. Un incidente que antes era una "observación sobre riesgos de TI" es ahora potencialmente un hallazgo de incumplimiento regulatorio.
---
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 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 de ciberseguridad en contexto de auditoría.