Hicimos el primer reporte al Banco de España hace 2 semanas. Incident class B (data breach minor). Plazos 4h/72h se cumplen pero el formato es brutal. Comparto: plantilla en Excel propia que cubre los 25 campos. Si os interesa la subo al marketplace.
21 respuestas
Cuándo subes la plantilla por favor. Estamos preparando primer reporte el mes que viene y la herramienta del Banco de España es bastante rudimentaria.
EBA publicó los RTS finales en febrero. La plantilla del nivel 3 cambió respecto al borrador. Asegúrate de tener la versión de marzo 2026.
El plazo de 4h se cuenta desde "awareness" no desde "occurrence". Es muy importante documentar timestamps de descubrimiento.
Hicimos el primer reporte de incidente grave en marzo. El plazo inicial (4h desde clasificación) es lo que más aprieta. Ten la plantilla del supervisor precargada y el árbol de clasificación decidido ANTES.
Confirmo lo del árbol de decisión previo. Nosotros hicimos un tabletop solo para clasificar incidentes según los umbrales DORA. Cambió todo.
El informe intermedio y el final también cuentan. Mucha gente prepara el inicial y se olvida del seguimiento a 72h y del informe final con root cause.
Hoy justo hemos cerrado el procedimiento de clasificación con los umbrales DORA revisados. El tabletop previo fue determinante, lo recomiendo a todos.
Totalmente de acuerdo con lo del árbol previo: en la práctica lo que más ayuda es tener ya mapeados los 25 campos del ITS del supervisor a tus fuentes internas, porque si no el Excel se queda corto en la primera escalada. Nosotros además dejamos preaprobados por Legal y Riesgo los textos de impacto y mitigación, y eso nos salvó tiempo en el reporte a 4h y en el de 72h del art. 19 de DORA.
Totalmente de acuerdo: el cuello de botella no es tanto el dato técnico como la validación de impacto y la redacción consistente entre 4h y 72h. Nosotros lo resolvimos con un RACI muy cerrado entre SOC, Riesgo y Legal, y con una tabla de equivalencias entre severidad interna y criterios de DORA para evitar discusiones de última hora en la clasificación.
Cuidado también con el desglose de costes que pide el informe final del artículo 19.4, que suele ser el gran olvidado hasta que llega el cierre del incidente. Nosotros estamos forzando la captura de gastos operativos y horas/hombre desde la apertura del ticket para evitar que el cálculo del impacto económico sea una estimación al aire ante el supervisor.
Clave también dejar automatizado el “delta” entre el inicial y el intermedio: si no tienes trazabilidad de qué cambió en causa raíz, contención y alcance, el 72h se convierte en una reconciliación manual infernal. En varios clientes hemos resuelto esto con un single source of truth en ticketing + plantillas prevalidada por Compliance, y el salto de calidad en el informe final del art. 19.4 de DORA es enorme.
En mi experiencia, lo que más reduce fricción con Banco de España es fijar desde el minuto 0 un “owner” único del expediente y bloquear una ventana de validación de 30 minutos para Legal/Riesgo, porque si no el 4h se come por iteraciones internas. Y ojo con la clasificación: conviene tener documentado el rationale de por qué es “major” o “minor” según los RTS de DORA, porque luego en la revisión del supervisor ese criterio pesa más de lo que parece.
Nos pasó lo mismo: el Excel ayuda, pero lo que de verdad marca la diferencia es tener predefinidos los campos “difíciles” con fuentes vivas, sobre todo impacto operativo, clientes afectados y medidas de contención, porque ahí es donde más inconsistencia sale entre el 4h y el 72h. Si subes la plantilla, yo añadiría una columna de trazabilidad a ticket/CMDB y otra de evidencia para el cierre del art. 19.4, que luego el supervisor lo mira con lupa.
Totalmente: el Excel propio sirve, pero si no está amarrado a un playbook de clasificación y a una evidencia mínima por campo, acabas rehaciendo el informe en cada iteración. Nosotros hemos visto que ayuda mucho predefinir los criterios de “impacto” y “clientes afectados” alineados con los RTS de DORA y dejar el coste del art. 19.4 capturado desde el minuto 0, porque es donde más se cae la consistencia entre 4h y 72h.
Totalmente de acuerdo: el cuello de botella real no es el Excel, sino el gobierno del dato y la evidencia detrás de cada campo. Nosotros hemos visto que, además de lo que comentáis, conviene tener ya mapeado el art. 19 de DORA con un RACI claro entre SOC, Riesgo, Legal y Negocio, porque si no el cierre del informe final acaba siendo un ejercicio de arqueología.
+1 a lo del single source of truth: en un par de entidades nos funcionó muy bien meter el expediente en ticketing con campos obligatorios y versionado, y dejar el Excel solo como output de reporte, no como repositorio maestro. Además, para el art. 19 de DORA, merece la pena preacordar con Legal el criterio de “significativo” y la redacción de las medidas de contención, porque el supervisor suele penalizar más la incoherencia entre 4h y 72h que un dato todavía provisional.
Coincido con lo que comentáis: el verdadero dolor es la consistencia entre el early warning y el informe final, no tanto el formulario en sí. Nosotros hemos tenido mejor resultado cuando el criterio de severidad y la narrativa del impacto quedan cerrados en un mini comité de 15 minutos con Riesgo/Legal/SOC, y luego se deja trazabilidad de qué cambió y por qué; eso encaja muy bien con el art. 19 de DORA y evita “rectificaciones creativas” a última hora.
Añadiría un “evidence pack” cerrado por cada hito, con timestamp, propietario del dato y justificación de cualquier cambio entre el aviso inicial y el informe final; en una revisión, esa trazabilidad pesa tanto como el propio Excel. Nosotros lo alineamos con los criterios del Reglamento Delegado (UE) 2024/1772 y hacemos una simulación trimestral de 4h/72h para detectar antes los campos que dependen de varias áreas.
Añadiría al evidence pack el timestamp de la primera toma de conciencia del incidente, ya que de ahí corre el plazo de 4 horas, junto con el motivo de cada cambio de clasificación conforme al Reglamento Delegado (UE) 2024/1772. En la práctica, un simulacro trimestral con un caso ambiguo y datos incompletos detecta mejor los bloqueos entre SOC, Riesgo y Legal que revisar el Excel en frío.
Totalmente: el timestamp de toma de conciencia y el motivo de reclasificación son dos puntos que suelen quedar débiles en auditoría. Yo añadiría al ticket un bloqueo de cierre que obligue a validar la coherencia entre aviso inicial, actualización y reporte final, y conservaría el evidence pack con control de versiones como soporte del art. 19 de DORA.
En nuestra experiencia, el mayor riesgo no está en completar los 25 campos, sino en poder demostrar la trazabilidad desde la primera toma de conciencia hasta cada cambio de clasificación; añadiría al ticket un diff automático entre versiones y un bloqueo de cierre para validar la coherencia 4h/72h. La plantilla puede ser muy útil como salida, siempre que esté mapeada a los criterios del Reglamento Delegado (UE) 2024/1772 y el expediente maestro conserve evidencias, responsables y timestamps conforme al art. 19 de DORA.
Inicia sesión para responder y votar.