Contenido
1. Qué falla en la práctica y por qué DORA importa a su auditoría 2. Marco regulatorio: DORA frente a la NIA-ES 315 3. Evaluación del riesgo de TIC bajo la NIA-ES 315 4. Ejemplo práctico: auditoría de una gestora de fondos 5. Lista de verificación práctica 6. Errores frecuentes 7. Contenido relacionado
Qué falla en la práctica y por qué DORA importa a su auditoría
El fallo recurrente: el auditor financiero abre el encargo, ve que el cliente tiene un equipo DORA funcionando, un responsable de riesgo TIC nombrado y un informe anual del Art. 6 ya entregado al Banco de España, y concluye que los riesgos de TIC "están cubiertos". Pasa a tratar los sistemas de información como un entorno de control general y delega cualquier duda técnica al equipo de IT audit (cuando existe). El socio firma.
Luego viene la inspección del ICAC y pregunta cómo se evaluó, bajo la NIA-ES 315.25, el riesgo de incorrección material derivado de un incidente operativo de TIC clasificado como "mayor" por el propio cliente en agosto de 2024. Y los papeles están flojos.
Yo el primero he visto cerrar encargos con esta lógica. DORA introduce un cambio que muchos equipos no han interiorizado todavía: el cliente ya no dice "tenemos buenos sistemas". El cliente dice, por exigencia del Art. 8, que su sistema de pagos tiene una dependencia operativa crítica de un TPP concreto con un riesgo residual evaluado en X. Esa frase existe en un documento que su cliente tiene obligación legal de mantener. Si usted no la ha leído, tiene un problema de NIA-ES 500 (evidencia suficiente y adecuada), no de DORA.
Lo que la NIA-ES 315 revisada exige en la práctica: que los riesgos identificados por el cliente en el marco DORA se integren en su evaluación de riesgos, no que se ignoren por "ser de otra normativa". El ICAC no le va a sancionar por no evaluar el cumplimiento de DORA. Le va a sancionar por no usar evidencia disponible en el encargo.
Por qué importa para la auditoría financiera
No se trata de ciberseguridad en abstracto. Los sistemas de TIC procesan, registran y presentan la mayoría de las transacciones financieras de un cliente del sector financiero. Un fallo en los controles automatizados, una interrupción del TPP principal o un ciberataque puede traducirse en:
- Transacciones no registradas o registradas de forma incompleta - Pérdida de integridad en los datos financieros (afectación directa a existencia y exactitud) - Interrupciones que impiden el cierre contable del ejercicio - Pérdidas operativas materiales que requieren provisión bajo NIC 37 - Fallos en controles internos sobre la información financiera (con impacto en el enfoque de la auditoría)
La NIA-ES 315.13 exige identificar estos riesgos. La NIA-ES 330.8 exige diseñar procedimientos para responder a los riesgos identificados. Si la dirección del cliente ha documentado riesgos operativos TIC bajo DORA, esos riesgos son input directo para su evaluación.
Entidades sujetas a DORA en España
El Banco de España supervisa el cumplimiento para entidades de crédito (bancos, cajas de ahorros, cooperativas de crédito), entidades de pago, entidades de dinero electrónico, empresas de servicios de inversión, ESI no MiFID y entidades gestoras de fondos inscritas en su registro.
La CNMV supervisa gestoras de IIC, ECR, SGEIC, plataformas de negociación y proveedores de servicios de criptoactivos bajo MiCA. La DGSFP supervisa aseguradoras y reaseguradoras. Los tres se coordinan (en teoría) a través del marco establecido por la EBA, ESMA y EIOPA. En la práctica, el marco DORA está siendo aplicado con criterios ligeramente distintos según el supervisor, y eso tiene consecuencias para el auditor (volveremos a ello en la sección sobre TPP críticos).
Marco regulatorio: DORA frente a la NIA-ES 315
Lo que falla aquí: tratar DORA como "tema de cumplimiento del cliente"
No es un tema de cumplimiento del cliente. O sí lo es, pero no solo eso. DORA produce tres artefactos que son evidencia disponible para el auditor financiero:
1. El marco de gestión del riesgo de TIC (Art. 6) con su registro de activos de información 2. El registro de incidentes operativos clasificados (Art. 17-18) con su notificación a los supervisores 3. El registro de acuerdos contractuales con TPP (Art. 28) y la identificación de proveedores críticos (Art. 31)
Esa evidencia no sustituye sus procedimientos. Pero ignorarla cuando está encima de la mesa del cliente es difícil de defender ante el ICAC.
Los cinco pilares de DORA (lo que realmente le afecta)
DORA establece cinco pilares de resiliencia operativa digital. Para el auditor financiero, los relevantes son principalmente el 1 (gobernanza) y el 4 (riesgo de terceros):
1. Gestión del riesgo de TIC (Arts. 5-15): marco de gobernanza, políticas y procedimientos. Aquí aparece la evidencia sobre el entorno de control TIC que usted necesita bajo NIA-ES 315.A74. 2. Gestión de incidentes (Arts. 16-23): detección, respuesta y notificación. Los incidentes mayores se notifican a los supervisores. Son un indicador directo de posibles incorrecciones si el incidente afectó a sistemas de procesamiento contable. 3. Pruebas de resiliencia operativa digital (Arts. 24-27): pruebas de vulnerabilidad y TLPT para entidades significativas. 4. Gestión del riesgo de terceros proveedores (Arts. 28-43): supervisión de TPP críticos. Este pilar es donde está el 80% del problema para el auditor financiero. 5. Intercambio de información (Arts. 44-49): compartir información sobre amenazas.
El cumplimiento de DORA es responsabilidad de la dirección de la entidad financiera. Los supervisores financieros (Banco de España, CNMV, DGSFP) verifican el cumplimiento como parte de su función supervisora.
Su responsabilidad bajo NIA-ES 315
Como auditor financiero, su responsabilidad bajo NIA-ES 315 es distinta y más limitada. Debe obtener conocimiento de los controles internos relevantes para la auditoría, incluidos los controles sobre los sistemas de información (apartado 13); evaluar el diseño de los controles y determinar si se han implementado (apartado 20); identificar y evaluar los riesgos de incorrección material a nivel de aseveración (apartado 25).
No debe evaluar el cumplimiento de DORA. Debe evaluar si los riesgos de TIC (incluidos los que la propia dirección ha documentado bajo DORA) podrían causar incorrecciones materiales en los estados financieros.
Dónde se superponen (y dónde no)
Los controles de TIC que DORA requiere son relevantes para la auditoría financiera cuando procesan transacciones financieras significativas, mantienen registros contables críticos, respaldan controles internos sobre la información financiera o su fallo podría resultar en incorrecciones materiales.
En la práctica, eso significa que el trabajo DORA del cliente puede proporcionar evidencia útil sobre estos controles, pero no sustituye su evaluación bajo NIA-ES 315. Y aquí aparece la zona gris más incómoda del encargo: cuánta confianza depositar en el marco DORA del cliente. No hay respuesta única. Depende del diseño del marco, de la independencia de la función de riesgo TIC respecto de la línea de negocio, y de si el auditor interno ha probado los controles durante el ejercicio auditado.
Evaluación del riesgo de TIC bajo la NIA-ES 315
identificar sistemas de TIC relevantes para la auditoría
La NIA-ES 315.A74 explica que los controles sobre los sistemas de información son relevantes cuando procesan transacciones significativas o mantienen información financiera importante. Para clientes sujetos a DORA, identifique sistemas críticos de negocio (procesamiento de transacciones, gestión de riesgos y límites, contabilidad y reportes regulatorios, gestión de clientes y contratos) e infraestructura TIC subyacente (centros de datos y backup, redes, sistemas de autenticación y cifrado, monitorización y logging).
Punto : el registro de activos de información exigido por DORA Art. 8 ya contiene esta información. Pídalo. No lo reconstruya desde cero.
evaluar controles de TIC relevantes
Bajo NIA-ES 315.A77, debe evaluar controles generales de TIC (gestión del acceso y autenticación, gestión de cambios, operaciones de TIC, seguridad física y lógica) y controles de aplicación (validación de entrada, procesamiento completo y exacto, autorización adecuada, mantenimiento de integridad de datos).
En la práctica, eso significa que, si el cliente ha pasado auditoría interna sobre estos controles en el marco del Art. 6.5 de DORA, usted puede usar ese trabajo bajo NIA-ES 610, siempre que evalúe la competencia, objetividad y aplicación sistemática del enfoque del auditor interno. No es evidencia directa. Es punto de partida.
identificar riesgos de incorrección material
Los riesgos de TIC que pueden derivar en incorrecciones materiales se agrupan en tres familias: riesgos de procesamiento de transacciones (no autorizadas o fraudulentas, procesamiento incompleto o inexacto, duplicación u omisión, errores en cálculos automatizados); riesgos de integridad de datos (corrupción o pérdida, modificaciones no autorizadas, fallos en conciliación automatizada, errores en interfaces entre sistemas); riesgos de disponibilidad (interrupciones que impiden procesamiento o cierre contable, pérdida de capacidad de generar reportes, interrupciones prolongadas).
Cruce esa lista con el registro DORA de incidentes del cliente durante el ejercicio. Todo incidente clasificado como "mayor" bajo el Art. 18 que haya afectado a un sistema identificado como crítico es, por definición, un indicador de riesgo que usted debe evaluar.
obtener evidencia de auditoría
Lo que realmente ocurre en un encargo bien hecho: se revisa la documentación DORA existente (marco de gobernanza del riesgo de TIC, políticas y procedimientos, registros de incidentes y su resolución, resultados de pruebas de resiliencia), se realizan consultas específicas al responsable de TIC, al responsable de riesgos y al auditor interno, y se considera el uso de especialistas bajo NIA-ES 620 cuando los controles son técnicamente complejos.
Desde nuestra experiencia, el mayor error no es técnico. Es de scoping: equipos que piden la documentación DORA a los dos días antes de emisión del informe, cuando el responsable de TIC del cliente ya está en vacaciones y la única evidencia disponible es el resumen ejecutivo de tres páginas que aprobó el consejo. Los papeles, efectivamente, flojos.
Ejemplo práctico: auditoría de una gestora de fondos
Fondo Mediterráneo Gestión SGIIC S.A., gestora con sede en Valencia, administra 2.100 millones de euros en activos. La entidad está sujeta a DORA desde enero de 2025 y usa múltiples sistemas de TIC para procesar inversiones, valorar activos y generar reportes regulatorios a la CNMV.
Contexto del encargo
- Materialidad global: 420.000 € (0,2% de activos gestionados) - Materialidad de ejecución: 315.000 € - Año fiscal: cierre 31 de diciembre de 2024 - Emisión prevista del informe: 28 de febrero de 2025
identificación de sistemas críticos
Durante las consultas iniciales identificamos estos sistemas relevantes para la auditoría: sistema de gestión de carteras (PMS) que procesa todas las órdenes de compra/venta de valores; sistema de valoración que calcula diariamente el valor liquidativo de 47 fondos; sistema contable que registra todas las transacciones y genera estados financieros; sistema de gestión de riesgos que monitoriza límites de inversión y exposiciones.
Nota de documentación: obtenido listado completo de sistemas TIC del registro DORA Art. 8, validado con el responsable de sistemas y contrastado con el director general.
evaluación de controles de TIC
Controles generales evaluados:
- Gestión de acceso: revisión de matriz de accesos, procedimientos de alta/baja de usuarios - Gestión de cambios: documentación de cambios en sistemas durante 2024, aprobaciones requeridas - Backup y recuperación: política de backup diario, pruebas de recuperación trimestrales - Monitorización: sistemas de alerta automática, logs de actividad conservados 12 meses
Nota de documentación: controles generales operan con eficacia. No identificadas debilidades significativas.
Controles de aplicación evaluados:
- Validación de órdenes: el PMS requiere doble autorización para órdenes superiores a 500.000 € - Conciliación automatizada: reconciliación diaria entre PMS y contabilidad, excepciones investigadas - Cálculo del valor liquidativo: validación automática contra fuentes de precios, revisión manual diaria - Límites de inversión: alertas automáticas cuando se acerca a límites CNMV, bloqueo de órdenes excesivas
Nota de documentación: controles de aplicación diseñados apropiadamente. Probado funcionamiento para muestra de transacciones.
la complicación que no estaba en el plan
Aquí es donde el encargo se desvía del plan. Durante la revisión del registro DORA de proveedores (Art. 28) detectamos que el PMS está alojado en un TPP (un proveedor de servicios en la nube paneuropeo) que Fondo Mediterráneo había clasificado como "crítico" en su propio registro. Problema: ese mismo TPP prestaba servicio a otra gestora auditada por nuestra firma que lo había clasificado como "no crítico" porque su volumen de activos es menor y la dependencia operativa, según su análisis, era sustituible en 72 horas.
Dos clientes. Mismo proveedor. Dos clasificaciones. Y la NIA-ES 315 no resuelve la contradicción — DORA tampoco. El Art. 28 deja la clasificación al criterio de la entidad supervisada, sujeta a revisión del supervisor.
Debate interno: el socio A sostenía que debíamos mantener la clasificación del cliente (ambos criterios son defendibles, y nosotros no somos el regulador DORA). El socio B sostenía que, si una misma firma de auditoría ve el mismo proveedor tratado de dos formas distintas, tiene el deber profesional de escalar la inconsistencia, al menos como consulta interna. Los dos tienen razón. Terminamos documentando la divergencia en el memorándum de planificación y elevando consulta a calidad técnica. El file debe contar la historia, y esta historia incluye la divergencia.
Conclusión del paso: reclasificamos el riesgo de valoración como significativo por la dependencia operativa del TPP, no por DORA, sino porque la evidencia reunida bajo NIA-ES 315 así lo justificaba.
respuesta de auditoría
Procedimientos diseñados: pruebas de controles sobre 25 órdenes ejecutadas, verificación de autorización y procesamiento completo; recálculo independiente del valor liquidativo para 5 fondos en fecha de cierre; verificación de reconciliación entre PMS y contabilidad para diciembre 2024; procedimiento adicional sobre continuidad del TPP (revisión del plan de salida contractual y de la última prueba de conmutación).
Nota de documentación: procedimientos ejecutados sin excepciones significativas. Controles operan con eficacia durante el período auditado.
Conclusión del caso: los controles de TIC de Fondo Mediterráneo proporcionan seguridad razonable sobre la integridad de transacciones financieras. No identificamos debilidades materiales que requieran comunicación bajo NIA-ES 265. La divergencia de clasificación del TPP entre clientes de la firma queda documentada en papeles de trabajo y elevada a calidad técnica.
La observación de segundo orden
Aquí hay algo que no se lee en DORA. La clasificación de "TPP crítico" va a divergir sistemáticamente entre firmas auditadas y entre auditores. No porque unos cumplan y otros no, sino porque el Art. 28 deja el juicio en la entidad. Eso creará, en los próximos tres ejercicios, una cartera de inconsistencias que el ICAC y los supervisores (Banco de España, CNMV, DGSFP) tendrán que normalizar a posteriori — probablemente mediante criterios interpretativos o consultas. Mientras tanto, el auditor financiero está en el medio, con dos clientes, el mismo proveedor, y dos clasificaciones. Lo que para el cliente es una decisión de gestión, para el auditor es un riesgo documental.
Lista de verificación práctica
1. Identifique entidades sujetas a DORA: confirme si su cliente está dentro del alcance. Si aplica, pida copia del marco de gestión del riesgo de TIC requerido por DORA Art. 6 antes de cerrar la planificación.
2. Mapee sistemas críticos cruzando dos registros: el registro de activos de información del cliente (DORA Art. 8) y su propia evaluación de sistemas relevantes bajo NIA-ES 315.A77. Si hay sistemas en uno que no aparecen en el otro, pregunte por qué.
3. Evalúe controles generales y de aplicación: revise gestión de acceso, gestión de cambios, backup/recuperación, monitorización, validación de entrada, procesamiento, autorización e integridad de datos. Obtenga evidencia del diseño e implementación según NIA-ES 315.20.
4. Identifique riesgos de incorrección material cruzándolos con el registro de incidentes DORA: todo incidente clasificado como "mayor" durante el ejercicio auditado debe ser evaluado. No deje ninguno sin evaluar, aunque la dirección lo considere resuelto.
5. Diseñe respuesta de auditoría proporcional al riesgo: pruebas de controles y procedimientos sustantivos bajo NIA-ES 330.7. Para los TPP críticos, añada procedimientos específicos sobre continuidad y planes de salida contractual.
6. Documente las divergencias de criterio: si dos clientes tratan el mismo TPP de forma distinta, documente la divergencia y eleve consulta técnica. No hay respuesta estándar todavía.
Errores frecuentes
Contenido relacionado
- Evaluación del riesgo bajo NIA-ES 315: guía completa para identificar y evaluar riesgos de incorrección material, incluidos riesgos de TIC. - Calculadora de materialidad: herramienta para calcular materialidad global y de ejecución, útil para determinar si riesgos de TIC podrían derivar en incorrecciones materiales. - Controles internos sobre información financiera: marco para evaluar controles internos relevantes para la auditoría, incluidos controles de TIC bajo NIA-ES 315.