Software · DORA
Un software DORA debe acreditar que su entidad cumple el Reglamento sobre la resiliencia operativa digital: gestión del riesgo relacionado con las TIC bajo la responsabilidad del órgano de dirección, gestión y notificación de incidentes, pruebas de resiliencia y gestión de los terceros proveedores de servicios TIC, incluido el registro de información. Esta página muestra qué debe ofrecer un software para ello, en qué debe fijarse al elegirlo y cómo lo resuelve Sightadel.
Punto de partida
DORA se aplica desde enero de 2025 a las entidades financieras de toda la UE. El Reglamento se apoya en cinco pilares: gestión del riesgo relacionado con las TIC, gestión y notificación de incidentes relacionados con las TIC, pruebas de resiliencia operativa digital, gestión del riesgo de terceros proveedores de servicios TIC e intercambio voluntario de información sobre amenazas. Las normas técnicas de las autoridades europeas de supervisión regulan los detalles; en Alemania, la supervisión corresponde a la autoridad federal alemana de supervisión financiera (BaFin). No existe un certificado DORA.
Para un software, son determinantes sobre todo cuatro requisitos. El órgano de dirección aprueba el marco de gestión del riesgo TIC y asume la responsabilidad (arts. 5–6). Los incidentes se clasifican según criterios uniformes, los graves se notifican, y la notificación inicial, a más tardar 24 horas después de tener conocimiento (arts. 17–19). Un programa de pruebas basado en el riesgo se aplica a todos; determinadas entidades realizan además, al menos cada tres años, pruebas de penetración basadas en amenazas (arts. 24–27). Y el registro de información recoge todos los contratos con proveedores de servicios TIC (art. 28).
El registro suele ser la parte más laboriosa, porque los datos no figuran completos en ninguna carpeta de contratos. Un software DORA debería hacerlo surgir del mantenimiento continuo de los proveedores, no de una recopilación previa a la fecha de referencia. Las decisiones como el apetito de riesgo, la clasificación de las funciones críticas o importantes y las estrategias de salida siguen correspondiendo al órgano de dirección.
Por qué ahora
La BaFin solicita el registro de información una vez al año con una fecha de referencia. Quien solo lo actualiza poco antes vuelve a buscar desde cero cada año.
Se pregunta por el marco, su revisión anual, los resultados de las pruebas y la resolución de los hallazgos. Cuentan los justificantes con fecha, no las declaraciones de intenciones.
Antes de firmar el contrato son necesarias una evaluación de riesgos y la revisión del contenido del contrato según el art. 30. Después, el proveedor debe incluirse en el registro.
La primera fase se llevó a cabo como proyecto con hojas de cálculo y carpetas en unidades de red. Para el funcionamiento continuo eso rara vez basta.
Frameworks relevantes
Resumido con nuestras propias palabras, sin constituir asesoramiento jurídico. Prevalece el texto original en su versión vigente.
Para entidades financieras de la UE. En Sightadel, 50 requisitos con referencia al artículo y evidencia esperada. Cerrar las carencias existentes suele llevar de seis a doce meses. Para determinadas entidades más pequeñas existe un marco simplificado.
Ver el framework →La gestión del riesgo TIC, el control de accesos, las copias de seguridad y la gestión de incidentes se basan en los mismos fundamentos. El registro de información no tiene equivalente en ISO 27001.
Ver el framework →Para las entidades financieras, DORA tiene prioridad. Muchas medidas coinciden; los plazos de notificación difieren en el punto de partida: DORA se basa en la clasificación, NIS2 en el momento en que se tiene conocimiento.
Ver el framework →Un informe de atestación C5 de un proveedor cloud es una evidencia valiosa al evaluar a ese proveedor de servicios. No sustituye la evaluación de riesgos propia.
Ver el framework →Las medidas técnicas y los contratos de encargado del tratamiento recurren a los mismos datos de los proveedores de servicios. Un incidente puede activar varias obligaciones de notificación.
Ver el framework →Orden recomendado
Aclarar qué obligaciones se aplican, si procede el marco simplificado y qué funciones son críticas o importantes.
Recorrer de forma guiada los 50 requisitos y asignar las evidencias existentes del SGSI, la gestión de la continuidad y compras.
Registrar proveedores de servicios, contratos, funciones respaldadas y subcontratistas. Las listas existentes se incorporan mediante importación desde Excel.
Definir criterios de clasificación, responsabilidades y canales de notificación, y simularlos una vez.
Planes de acción con responsables y plazos. Las adaptaciones de contratos suelen ser lo que más tarda, porque la otra parte tiene que colaborar.
Ejecutar el programa de pruebas, revisar el marco cada año y mantener actualizado el registro. Después, estos pasos se repiten como ciclo.
Elección
Muchas herramientas cubren pilares aislados, por ejemplo solo el registro o solo la gestión de incidentes. Compruebe si el software mantiene unidas todas las obligaciones y se ajusta a su tamaño.
Cada requisito debería remitir al artículo del Reglamento e indicar la evidencia esperada. Así pueden asignarse directamente las preguntas de la auditoría interna.
Proveedores de servicios, contratos, funciones respaldadas y criticidad deberían mantenerse en un solo lugar. El registro no debe ser un proyecto aparte para la fecha de referencia.
Quien notifica también según NIS2 o el RGPD necesita una separación clara de los puntos de partida. DORA se basa en la clasificación como grave, NIS2 en el momento en que se tiene conocimiento.
Las pruebas deberían planificarse como citas recurrentes y los hallazgos seguirse con plazo y responsable. La prueba basada en amenazas en sí la realizan probadores especializados.
La aprobación del marco, los acuerdos y la formación de la dirección deberían archivarse con fecha. Son lo primero que se examina en cualquier revisión.
Una entidad pequeña tiene la misma obligación, pero no necesita el mismo aparato que un gran banco. Asegúrese de que el software pueda utilizarse sin una larga implantación.
Cómo ayuda Sightadel
50 requisitos con referencia al artículo y evidencia esperada, cada uno como pregunta con explicación. Las evidencias de ISO 27001 pueden reutilizarse directamente.
Más información →Proveedores de servicios con funciones respaldadas, criticidad, contratos y evidencias con fecha de validez. Las nuevas evaluaciones llegan como recordatorio. Así el registro de información crece a partir del mantenimiento continuo.
Más información →Actas de pruebas, pruebas de restauración y acuerdos con versión y fecha de validez. Cuando una evidencia caduca, aparece como tarea antes de que la encuentre la auditoría interna.
Más información →Los hallazgos de pruebas, revisiones y cláusulas contractuales que faltan se convierten en medidas con responsable y plazo. El registro de actividad muestra quién hizo qué y cuándo.
Más información →Sincronización periódica con sistemas como SAP, Microsoft Dynamics, Microsoft Azure o Jira. Los activos, las evidencias y las tareas proceden de los sistemas en los que se mantienen de todos modos.
Más información →Esfuerzo y duración
Los plazos son valores basados en la experiencia, no un compromiso. El ritmo lo marcan sobre todo el registro de información y las adaptaciones de contratos, no el software.
Qué licencia contrata · normalmente Professional
Una entidad típica gestiona DORA junto con ISO 27001 como base en la edición Professional. Con muchos proveedores de servicios TIC o varias sociedades, Enterprise es la opción adecuada. Si ISO 27001 está incluida, DORA cuesta de forma permanente menos.
Licencia por framework, duración mínima de un año, pago mensual o anual. Todos los precios, descuentos y una calculadora están en la página de precios. Los honorarios de un organismo de certificación o de auditoría se suman por separado.
Preguntas y respuestas
Más respuestas en las preguntas frecuentes o directamente a través de nuestro formulario de contacto.
El Reglamento no prescribe ningún software. Exige un marco documentado, un registro de información completo, una gestión de incidentes trazable y un programa de pruebas. Con pocos proveedores de servicios es posible con hojas de cálculo. Con muchos contratos, varios implicados y la presentación anual, compensa un sistema.
Para la primera presentación, muchas entidades utilizaron hojas de cálculo. Cada cambio de contrato, cada nuevo proveedor de servicios y cada prueba debe añadirse entonces a mano. Las listas existentes pueden importarse en Sightadel.
Sightadel se licencia por framework y edición, anualmente. Los importes actuales figuran en la página de precios. Si ya tiene licencia de ISO 27001, DORA cuesta de forma permanente menos. Puede probarlo gratis 14 días, sin datos de pago.
No. Sightadel le guía por los requisitos y deja constancia del estado. Al consultor lo elige en la red de socios de la aplicación o trae el suyo. Las revisiones de la auditoría interna, el auditor de cuentas y el supervisor no se ven afectadas. Sightadel no certifica y no recibe comisiones.
Aprueba el marco de gestión del riesgo TIC, fija el apetito de riesgo, acuerda la clasificación de las funciones críticas o importantes y aporta los recursos. Sightadel ofrece borradores y deja constancia de los acuerdos con fecha. Las decisiones las toma el propio órgano de dirección.
No. La TLPT la realizan probadores especializados. Sightadel registra la planificación, el resultado y la resolución de los hallazgos. Más información sobre los requisitos en la página sobre DORA.
Sightadel se desarrolla y se opera en Alemania.
14 días, acceso completo, sin datos de pago. Todo lo que cree se conserva en el plan de pago.
