Saltar al contenido
toevan
Iniciar sesiónReserve un piloto de auditoría
Abrir menúCerrar menú
Reserve un piloto de auditoría

Mapa de controles · Reglamento (UE) 2022/2554

DORA

Reserve un piloto de auditoríaVer un informe de muestra

2 de 6 controles de DORA que el código puede evidenciar, con v1.4.0, más 1 de apoyo

Evidencia de código para protección y prevención y para detección, reforzada por evidencia de gestión de cambios en v1.4.0.

  • Activo2
  • Próximamente en v1.4.00
  • De apoyo1
  • Planificado4
  • Su organización20
  1. 2 con evidencia de código hoyEvidencia parcial, comprobada en cada pull request.
  2. 1 con evidencia de apoyoToevan registra evidencia relacionada; la obligación sigue siendo organizativa.
  3. 20 quedan en su organizaciónEnumerados completos más abajo, para que nada quede implícito.

DORA se aplica a las entidades financieras de la UE desde el 17 de enero de 2025. Exige un marco de gestión del riesgo de TIC que pueda mostrar en funcionamiento, incluida una gestión de cambios documentada.

El blueprint de DORA aporta evidencia de código para el artículo 9 (protección y prevención) y el artículo 10 (detección) en cada pull request. Desde v1.4.0, la evidencia de gestión de cambios de cada cambio fusionado refuerza el artículo 9. La gobernanza, la notificación de incidentes, las pruebas de resiliencia y el riesgo de terceros quedan en su proceso.

En la hoja de ruta: el RTS sobre gestión del riesgo de TIC (Reglamento Delegado (UE) 2024/1774), con el artículo 17 de gestión de cambios de TIC a partir de evidencia de proceso y el artículo 16 a partir de evidencia de código. Aún falta añadir su edición al catálogo.

Toevan aporta evidencia para controles; nunca los certifica ni afirma que un marco esté cubierto. Si la evidencia es suficiente lo juzga su auditor.

Activo2

Evidencia de código hoy, sellada en cada pull request. Siempre parcial: el control también exige cosas fuera del código. Evidencia de código hoy: las reglas del blueprint DORA comprueban parte de esto en cada pull request.

  • Art.9

    Protección y prevención

    Cap. II Gestión del riesgo de TIC

    Reforzado en v1.4.0: evidencia de gestión de cambios por cada cambio fusionado.

  • Art.10

    Detección

    Cap. II Gestión del riesgo de TIC

De apoyo1

Toevan registra evidencia relacionada, hoy o en v1.4.0, pero la obligación es organizativa, así que nunca cuenta como cubierta.

  • Art.28

    Principios generales

    Cap. V Gestión del riesgo de terceros de TIC

    Evidencia de apoyo hoy: una regla registra evidencia relacionada con esta obligación. La obligación en sí es una política de la organización.

Planificado4

Se puede evidenciar desde el código o GitHub. La regla o el mapeo aún no están construidos.

  • Art.7

    Sistemas, protocolos y herramientas de TIC

    Cap. II Gestión del riesgo de TIC

  • Art.8

    Identificación

    Cap. II Gestión del riesgo de TIC

  • Art.12

    Políticas y procedimientos de copia de seguridad, procedimientos y métodos de restauración y recuperación

    Cap. II Gestión del riesgo de TIC

  • Art.25

    Pruebas de herramientas y sistemas de TIC

    Cap. IV Pruebas de resiliencia operativa digital

Su organización20

Política, personas, seguridad física, contratos, trámites regulatorios, operaciones o auditoría externa. Su organización aporta la evidencia.

Mostrar los 20 controles

Cap. II Gestión del riesgo de TIC

  • Art.5Gobernanza y organizaciónuna política de la organización
  • Art.6Marco de gestión del riesgo de TICuna política de la organización
  • Art.11Respuesta y recuperaciónun proceso operativo
  • Art.13Aprendizaje y evoluciónun proceso operativo
  • Art.14Comunicaciónun proceso operativo
  • Art.15Mayor armonización de herramientas, métodos, procesos y políticas de gestión del riesgo de TICun trámite regulatorio
  • Art.16Marco simplificado de gestión del riesgo de TICuna política de la organización

Cap. III Gestión, clasificación y notificación de incidentes relacionados con las TIC

  • Art.17Proceso de gestión de incidentes relacionados con las TICun proceso operativo
  • Art.18Clasificación de incidentes relacionados con las TIC y ciberamenazasun proceso operativo
  • Art.19Notificación de incidentes graves relacionados con las TIC y notificación voluntaria de ciberamenazas significativasun trámite regulatorio
  • Art.20Armonización del contenido y de las plantillas de notificaciónun trámite regulatorio
  • Art.21Centralización de la notificación de incidentes graves relacionados con las TICun trámite regulatorio
  • Art.22Retroalimentación de supervisiónun trámite regulatorio
  • Art.23Incidentes operativos o de seguridad relacionados con pagos que afectan a entidades de crédito, entidades de pago, proveedores de servicios de información sobre cuentas y entidades de dinero electrónicoun trámite regulatorio

Cap. IV Pruebas de resiliencia operativa digital

  • Art.24Requisitos generales para realizar pruebas de resiliencia operativa digitaluna política de la organización
  • Art.26Pruebas avanzadas de herramientas, sistemas y procesos de TIC basadas en TLPTuna evaluación externa
  • Art.27Requisitos para los probadores que realizan TLPTuna evaluación externa

Cap. V Gestión del riesgo de terceros de TIC

  • Art.29Evaluación preliminar del riesgo de concentración de TIC a nivel de entidaduna política de la organización
  • Art.30Disposiciones contractuales clavecontratos y proveedores

Cap. VI Acuerdos de intercambio de información

  • Art.45Acuerdos de intercambio de información sobre ciberamenazas e inteligenciaun trámite regulatorio

Cómo usarlo en una auditoría

  1. Tome la población de los registros de cambio (desde v1.4.0)

    Cada fusión en una rama protegida y cada push directo del periodo, capturados de GitHub en el momento, es un registro sellado que puede exportar para el muestreo. Puede repetir la población de la rama por defecto a partir del historial de git; las ramas de producción designadas están planificadas para v1.4.1.

  2. Lea la evidencia de código del periodo

    Cada pull request lleva resultados de código sellados frente a las reglas del blueprint, fijados al commit y a la versión del conjunto de reglas vigente.

  3. Pruebe una muestra

    Para cada registro muestreado, compruebe sus resultados y luego verifique su firma y su lugar en la cadena sin conexión.

    toevan audit verify --path evidence-clone --pub-key toevan.pub

Cómo se obtuvo cada dato

Cada dato de un registro y de un informe lleva una de seis etiquetas, para que su auditor sepa hasta qué punto puede fiarse.

Recalculado
Toevan lo calculó a partir del propio código o del historial de git.
Repítalo con las mismas entradas y obtenga el mismo resultado.
Informado + sellado
GitHub lo informó; Toevan lo capturó en el evento y lo firmó.
Fíese de ello tanto como se fía de GitHub. Cualquier cambio posterior es detectable.
Declarado + sellado
La organización lo declaró, como un cambio en lo que se comprueba; Toevan firmó la declaración y su historial.
Vea quién declaró qué, cuándo, y cada cambio posterior.
Registro de Toevan, sin sellar
Guardado en la base de datos de Toevan pero no sellado en el libro, como una exención hoy. Ninguna firma lo protege.
Trátelo como una declaración de Toevan y pida a la organización la aprobación que hay detrás.
Consumido
Tomado del registro firmado de otro sistema, como la procedencia de una compilación, y enlazado por commit o digest. Planificado.
Compruebe el registro original de forma independiente.
No capturado
No había una fuente fiable. Toevan no lo infiere.
Obténgalo de la organización por otros medios.

Véalo en un informe

El informe de muestra de evidencia de cambios muestra la evidencia tal como la recibe su auditor, con cada dato rotulado.

Abrir el informe de muestra

Ponga a prueba el mapeo en una auditoría real.

Traiga un repositorio y una auditoría próxima. Configuraremos el blueprint y guiaremos a su auditor por la verificación.

Reserve un piloto de auditoríaVer un informe de muestra