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

Evidencia de código para protección y prevención, y evidencia de proceso de despliegues y releases para el artículo 9.

Reserve un piloto de auditoríaVer un informe de muestra
DORA · Reglamento (UE) 2022/25546 artículos en el alcance · según el mapeo de v1.4.1
  • Código 1
  • Proceso Art.9
  • Planificado 5

Evidencia de código

1artículos comprobados en cada pull request

Activo (proceso)

Art.9de despliegues y releases

Planificado

5se puede evidenciar desde el código o GitHub; aún no construido

Artículos de nivel organizativo

Políticas, personas, proveedores, seguridad física y similares, enumerados más abajo.Toevan aporta evidencia de apoyo para 1 de ellos.Gestionados por los procesos de su organización

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) en cada pull request; la detección del artículo 10 está planificada. El artículo 9 tiene además evidencia de proceso de despliegues y releases: un despliegue correcto de un commit en producción, una revisión de despliegue aprobada con la separación de funciones calculada, y la etiqueta de un release y el commit que nombra. 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.

Evidencia de código1

Sellada en cada pull request. Siempre parcial: el control también exige cosas fuera del código. Las reglas del blueprint DORA comprueban parte de cada uno en cada pull request.

  • Art.9Protección y prevenciónCap. II Gestión del riesgo de TICEvidencia de proceso de despliegues y releases: un despliegue correcto de un commit en producción, según la marca de GitHub o la designación de la organización. Una revisión de despliegue aprobada, con la separación de funciones calculada. La etiqueta de un release y el commit que nombra.

De apoyo1

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

  • Art.28Principios generalesCap. V Gestión del riesgo de terceros de TICEvidencia de apoyo: una regla registra evidencia relacionada con esta obligación. La obligación en sí es una política de la organización.

Planificado5

Se puede evidenciar desde el código o GitHub. Todavía ninguna regla los comprueba; cada uno está planificado y ninguno cuenta hoy como evidencia.

  • Art.7Sistemas, protocolos y herramientas de TICCap. II Gestión del riesgo de TIC
  • Art.8IdentificaciónCap. II Gestión del riesgo de TIC
  • Art.10DetecciónCap. II Gestión del riesgo de TIC
  • Art.12Políticas y procedimientos de copia de seguridad, procedimientos y métodos de restauración y recuperaciónCap. II Gestión del riesgo de TIC
  • Art.25Pruebas de herramientas y sistemas de TICCap. IV Pruebas de resiliencia operativa digital

Artículos de nivel organizativo

Los controles de nivel organizativo (políticas, personas, proveedores, seguridad física y similares) siguen en manos del propio proceso de su organización; Toevan no se ocupa de ellos.

Mostrar la lista

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

    Cada pull request fusionado en la rama por defecto y cada push a una rama protegida que ningún pull request fusionado explique, en el 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.

  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 verifíquelo sin conexión con la clave publicada, con openssl y la shell: obtenga la evidencia, confirme la clave, compruebe el registro. Para repetir toda la cadena, Toevan facilita el comando toevan a petición; aún no es público.

    Los tres pasos, con los comandos exactos

Cómo se obtuvo cada hecho6 etiquetas
Recalculado
Toevan lo calculó a partir del propio código o del historial de git.
Informado + sellado
GitHub lo informó; Toevan lo capturó en el evento y lo firmó.
Declarado + sellado
La organización lo declaró, como un cambio en lo que se comprueba; Toevan firmó la declaración y su historial.
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.
Consumido
Tomado de los registros de despliegue y de release de GitHub y enlazado por commit o digest.
No capturado
No había una fuente fiable. Toevan no lo infiere.
El informe de muestra de evidencia de cambios muestra la evidencia tal como la recibe su auditor, con cada hecho etiquetado.Abrir el informe de muestra

Pruebe el mapeo en una auditoría real.

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

Reserve un piloto de auditoríaVer un informe de muestra
  • Un repositorio, un marco
  • Evidencia desde el primer pull request
  • Verificable sin una cuenta de Toevan