Cumplimiento DORA y NIS2: la status page como prueba documental para SaaS B2B en la UE

⚡TL;DR

• DORA Artículo 19 impone una notificación inicial 4 horas después de la clasificación de un incidente grave (24 horas máximo después de la detección), un informe intermedio a las 72 horas y un informe final al mes, cifras oficiales confirmadas por los RTS/ITS JC 2024-33 publicados por las ESA el 17 de julio de 2024.
• NIS2 Artículo 23 impone una alerta temprana a 24 horas, una notificación a 72 horas y un informe final a 1 mes, aplicable a 18 sectores esenciales e importantes en Europa.
• Una status page pública con marca temporal, archivada y exportable en JSON, satisface las tres propiedades de una prueba oponible: marca temporal RFC 3339 UTC, audit trail inmutable, accesibilidad pública verificable.
• La ACPR señala en su balance de 8 meses de DORA (enero de 2026) que los plazos de 4 horas son "todavía raramente respetados". 2026 marca el fin de la tolerancia y el comienzo de la aplicación activa.
• El riesgo de terceros ICT (DORA Artículo 28) impone una revisión contractual del proveedor de status page: jurisdicción, localización de los datos, estrategia de salida, derecho de auditoría.

El 15 de enero de 2026, la ACPR publicó su balance de los ocho primeros meses de aplicación de DORA concluyendo que los plazos de notificación de incidente de cuatro horas son "todavía raramente respetados" por las entidades financieras francesas. En Fráncfort y Luxemburgo, BaFin y CSSF observan una constatación equivalente. Por el lado del cumplimiento NIS2, 22 de los 27 Estados miembros transpusieron la Directiva NIS2 al 1 de abril de 2026: Alemania puso en vigor el NIS2UmsuCG el 6 de diciembre de 2025, Italia aplica el decreto legislativo 138/2024 desde el 16 de octubre de 2024, Francia espera la promulgación de la Ley de Resiliencia adoptada el 26 de febrero de 2025.

En este panorama, una pregunta operativa surge en cada auditoría: ¿cómo aportar la prueba de que una notificación de incidente fue efectivamente emitida dentro de los plazos? Los correos internos se pierden, los tickets ServiceNow se cierran, las capturas de pantalla son impugnables. Queda un artefacto público, con marca temporal, accesible a cualquier hora desde el exterior: la status page (página de estado pública). Pero, para la mayoría de los SaaS B2B europeos, esta página sigue siendo una herramienta de comunicación de marketing, no un entregable de auditoría. El vuelco regulatorio que se produjo entre 2024 y 2026 cambia radicalmente este estatus, e instala el cumplimiento DORA y el cumplimiento NIS2 en el corazón de la gestión de incidentes.

Este artículo se dirige a los directores técnicos, responsables de seguridad de la información, responsables SRE y delegados de protección de datos que deben pilotar el cumplimiento DORA y el cumplimiento NIS2 de un SaaS B2B europeo. Se articula en tres tiempos: un apartado pedagógico sobre las regulaciones, un apartado operativo sobre la anatomía de una status page conforme, y un apartado de lista de verificación para preparar un control. Saldrá con un mapa unificado de los plazos, un modelo de exportación JSON alineado con las plantillas RTS/ITS DORA, un marco en siete pasos y una lista de verificación de veinticinco puntos.

La constatación de partida es simple: la status page pública reúne, sin sobrecoste técnico, las tres propiedades de una prueba documental. Solo falta que esté concebida con ese espíritu. Las secciones siguientes muestran cómo transformar una herramienta operativa en un entregable de auditoría, apoyándose en los textos oficiales (EUR-Lex, RTS/ITS de las ESA, ANSSI, ACPR, BaFin, CSSF, Banca d'Italia) y en las experiencias públicas más recientes.

Por qué la status page entra en el perímetro de auditoría UE en 2026

La status page pública fue percibida durante mucho tiempo como un escaparate. Servía para tranquilizar a los clientes durante un incidente, para evitar una saturación del soporte, para señalar una ventana de mantenimiento. En 2026, cambia de función. Los reguladores europeos, con la ACPR a la cabeza, consideran ahora que una comunicación pública de incidentes con marca temporal forma parte integrante del expediente de cumplimiento ICT, sin nombrarla formalmente "prueba" en los textos, pero invocándola sistemáticamente durante los controles documentales.

El deslizamiento regulatorio de la página de cortesía al artefacto de auditoría

Tres elementos explican este vuelco. Primero, el fin del período transitorio del Reglamento DORA. El Reglamento (UE) 2022/2554 entró en aplicación el 17 de enero de 2025. Los ocho primeros meses sirvieron de período de observación, durante el cual los supervisores no aplicaron sanciones masivas. A partir del primer trimestre de 2026, la ACPR, la BaFin, el Banco Central de Luxemburgo y la Banca d'Italia han confirmado haber pasado al modo de aplicación activa. Después, la transposición de NIS2 se generaliza. Al 1 de abril de 2026, 22 Estados miembros sobre 27 han adoptado un texto nacional, lo que cubre la mayoría de los operadores económicos europeos. Por último, la ENISA publicó en octubre de 2025 su Threat Landscape que documenta una intensificación de los incidentes ICT, lo que empuja a los reguladores a endurecer su exigencia de transparencia.

Tres fuerzas convergentes de regulación financiera, seguridad de redes y cadena de suministro

DORA se aplica a las entidades financieras y a sus prestadores ICT críticos. NIS2 cubre 18 sectores (energía, salud, transporte, digital, alimentación, infraestructuras públicas, etc.). Para un editor SaaS B2B europeo coexisten dos escenarios. Primer escenario: el editor es él mismo operador esencial o importante en el sentido de NIS2 (por ejemplo, un hospedador en la nube, un proveedor de servicio gestionado, un editor de firma electrónica cualificada). Está entonces sujeto directamente a NIS2. Segundo escenario: el editor presta servicio a un banco, una aseguradora, una fintech sujeta a DORA. Se convierte entonces en proveedor ICT en el sentido del Artículo 28 de DORA, y su cliente debe contractualizar obligaciones de resiliencia, auditabilidad y reporte. En ambos casos, la status page sale del ámbito de marketing para entrar en el ámbito contractual y regulatorio.

La cadena de suministro también entra en juego. El Artículo 21 apartado 2 de NIS2 impone una gestión explícita de los riesgos vinculados a los proveedores y a la cadena de suministro. Un fallo no comunicado de un subcontratista puede ser imputado al operador principal. La status page sirve entonces de mecanismo contractual de notificación entre eslabones de la cadena.

Lo que dicen los supervisores en la práctica

Las posiciones públicas convergen. La ACPR, a través de su portal OneGate y su FAQ DORA, insiste en la trazabilidad de las notificaciones. La BaFin alemana, en su artículo oficial sobre el reporte DORA, exige la coherencia entre la comunicación pública y el informe regulatorio. La CSSF luxemburguesa ha publicado las circulares 25/892 y 25/893 en mayo de 2025, que detallan la clasificación y el reporte. La ANSSI, en Francia, opera el portal MonEspaceNIS2 que centraliza las notificaciones NIS2 para los operadores esenciales e importantes. El mensaje es uniforme: hace falta una huella pública con marca temporal, y esa huella no es opcional. Es un complemento estructural al informe regulatorio confidencial.

Para los equipos operativos, esto impone replantear la concepción de la status page como entregable de auditoría desde la fase de arquitectura, y no como canal de comunicación reactivo. Es exactamente lo que permite la herramienta status page CaptainDNS, concebida para producir un artefacto oponible de forma nativa.

Para recordar: en 2026, su status page puede ser invocada como prueba documental por su regulador. Concebirla así desde el principio evita una remodelación costosa en el momento de la auditoría.

Cumplimiento DORA: el artículo 19 desglosado en 4 h, 72 h, 1 mes

El Reglamento (UE) 2022/2554, conocido como Reglamento DORA, se aplica a las entidades financieras europeas y a sus prestadores ICT críticos. Su capítulo III, y más específicamente el Artículo 19, regula la notificación de incidente ICT grave y constituye el corazón operativo del cumplimiento DORA. Para un editor SaaS B2B que presta servicio a un banco o a una aseguradora, comprender este artículo no es una cuestión jurídica: es lo que dicta la orquestación operativa de un incidente y su marco de cumplimiento.

Ámbito de aplicación: entidades financieras y proveedores ICT críticos

El Artículo 2 de DORA enumera 20 categorías de entidades financieras: entidades de crédito, entidades de pago, prestadores de servicios de información sobre cuentas, prestadores de servicios de financiación participativa, empresas de servicios de inversión, centros de negociación, depositarios centrales, entidades de contrapartida central, gestores de organismos de inversión colectiva, empresas de seguros y reaseguros, mediadores de seguros, fondos de pensiones de empleo, agencias de calificación, administradores de índices de referencia, prestadores de servicios sobre criptoactivos, registros de titulización, fondos, etc. Todas estas entidades están directamente sujetas a DORA.

El capítulo V (Artículos 28 a 44) extiende por contrato las obligaciones DORA a los proveedores ICT. Si un proveedor sustenta una función crítica o importante (CIFA, Critical or Important Function Arrangement), las cláusulas contractuales son obligatorias. Si un proveedor supera los umbrales definidos por las ESA (European Supervisory Authorities: EBA, EIOPA, ESMA), puede ser designado "prestador tercero crítico" (CTPP, Critical Third-Party Provider) y caer bajo supervisión directa.

El tríptico temporal de 4 h, 72 h, 1 mes

El Artículo 19 impone tres plazos para notificar un incidente ICT clasificado como grave:

• Notificación inicial: 4 horas después de la clasificación del incidente como grave, con un límite máximo de 24 horas después de la detección.
• Informe intermedio: 72 horas después de la detección.
• Informe final: 1 mes después de la detección.

El detalle de los plazos y de los campos obligatorios figura en el documento final de los estándares técnicos JC 2024-33 publicado el 17 de julio de 2024 por las tres autoridades europeas EBA, EIOPA y ESMA. Se trata de Regulatory Technical Standards (RTS) e Implementing Technical Standards (ITS) que precisan el contenido esperado de cada informe. La notificación inicial debe contener nueve campos: identidad de la entidad, marca temporal de la detección, marca temporal de la clasificación, descripción preliminar, criterios de clasificación activados (Artículos 17 y 18 DORA), impacto estimado, medidas inmediatas adoptadas, próximos pasos previstos, contacto dedicado.

La clasificación se apoya en los criterios del Artículo 18 DORA: materialidad del impacto (número de clientes afectados, duración, geografía, pérdida de datos, criticidad del servicio interrumpido, gravedad económica). El plazo de 4 horas arranca en el momento en que la entidad concluye formalmente que el incidente es "grave", no en la detección. Este matiz lo cambia todo en la práctica: hay que documentar la cadena de decisión (quién clasificó, sobre qué criterios, a qué hora UTC), so pena de que el regulador pueda recalificar el plazo y concluir un incumplimiento.

A quién notificar en la práctica según su jurisdicción

Las entidades notifican a su autoridad nacional competente:

• Francia: ACPR a través del portal OneGate (formato JSON, sin firma electrónica requerida). En caso de indisponibilidad de OneGate (medianoche-4 h, domingos), envío por correo electrónico a 2760-INCIDENTS-DORA-UT@acpr.banque-france.fr.
• Alemania: BaFin a través del portal MVP (Meldungs- und Veröffentlichungsplattform), en formato XBRL.
• Luxemburgo: CSSF a través del portal eDesk (Circular 25/893), acompañado de una matriz de clasificación estandarizada.
• Italia: Banca d'Italia a través de su portal dedicado a los incidentes DORA, en formato CSV o XML.

Para los CTPP designados, la supervisión es conjunta entre ESA y regulador nacional, con un Joint Examination Team (JET) que puede auditar in situ. Un editor SaaS B2B que presta servicio a varios bancos europeos puede tener que notificar a varias autoridades en paralelo por un mismo incidente, de ahí el interés crítico de un formato pivote tipo JSON explotado desde su status page, lo que enlaza con la lógica del monitoreo DNS resiliente documentado anteriormente.

Sanciones Artículos 50 a 58

DORA prevé sanciones administrativas elevadas. Para las entidades financieras: hasta el 2 % del volumen de negocios anual mundial o 10 millones de euros (el más elevado), con multa individual que puede alcanzar 1 millón de euros para los responsables. Para los CTPP: hasta el 1 % del volumen de negocios diario medio mundial, durante seis meses como máximo. Más allá de las multas, las sanciones se publican (Artículo 54), lo que añade un coste reputacional significativo. El balance ACPR de enero de 2026 precisa que la fase de aplicación activa arrancó en el primer trimestre de 2026, pero sin citar todavía un caso público sancionado, señal de que los reguladores preparan sus expedientes en silencio.

Para recordar: 4 horas después de la clasificación, debe disponer de 9 campos obligatorios listos para transmitir. Si su status page ya exporta estos campos, ha ganado lo esencial de la carrera.

Cumplimiento NIS2: el artículo 23 y la cascada de 24 h, 72 h, 1 mes

La Directiva (UE) 2022/2555, conocida como Directiva NIS2, completa el Reglamento DORA cubriendo todos los sectores esenciales e importantes fuera del financiero puro. Su Artículo 23 fija una cascada de notificación distinta, más amplia en su perímetro, y con un punto de partida diferente. Para un SaaS B2B europeo, el cumplimiento NIS2 se aplica a menudo en paralelo del cumplimiento DORA, y orquestar ambos es el reto operativo principal de 2026.

Perímetro ampliado de dieciocho sectores y cadena de suministro

Los anexos I y II de NIS2 enumeran 18 sectores. El anexo I distingue los sectores altamente críticos (energía, transporte, banca, infraestructura del mercado financiero, salud, agua potable, aguas residuales, infraestructura digital, gestión de servicios informáticos B2B, administración pública, espacio), el anexo II los demás sectores críticos (servicios postales y de mensajería, gestión de residuos, fabricación, producción y distribución de productos químicos, producción y transformación de alimentos, prestadores de servicios digitales, investigación). El tamaño de la entidad (≥ 50 empleados y volumen de negocios ≥ 10 millones de euros para el estatus de "importante", umbrales más altos para "esencial") determina si está sujeta a NIS2.

El Artículo 21 apartado 2 letra d de NIS2 impone la gestión de la seguridad de la cadena de suministro, incluidos los aspectos de seguridad relativos a las relaciones directas entre proveedores y prestadores. Una status page mal explotada por un proveedor puede acarrear la responsabilidad del operador esencial o importante cliente.

Alerta temprana de 24 h, notificación de 72 h, informe final de 1 mes

El Artículo 23 organiza la notificación en tres tiempos:

• Alerta temprana en las 24 horas siguientes al conocimiento de un incidente significativo.
• Notificación de incidente en las 72 horas siguientes al conocimiento, incluyendo una evaluación inicial, indicadores de compromiso y una descripción de la gravedad.
• Informe final en el mes siguiente a la notificación, con análisis causal detallado.

El punto de partida crítico: "conocimiento" (awareness), no "detección" técnica ni "clasificación" formal. En cuanto un equipo interno tiene conocimiento de un incidente significativo, el contador arranca. Un incidente es "significativo" si ha causado o es susceptible de causar una perturbación grave de los servicios, pérdidas financieras importantes, o si ha afectado o es susceptible de afectar a terceros causando daños materiales o inmateriales considerables.

Transposiciones nacionales de la directiva NIS2 en la primavera de 2026

El estado de la cuestión al 1 de abril de 2026:

• Francia: Ley de Resiliencia adoptada por la Asamblea Nacional el 26 de febrero de 2025, promulgación esperada en el primer semestre de 2026. La ANSSI opera el portal MonEspaceNIS2 y coordina el CERT-FR como CSIRT nacional. Período de adecuación: 3 años después de la promulgación. Para seguir la evolución de la historización de las observaciones, véase la trazabilidad DNS publicada por CaptainDNS en noviembre de 2025.
• Alemania: NIS2UmsuCG promulgado el 5 de diciembre de 2025, en vigor el 6 de diciembre de 2025. El BSI ha publicado los detalles operativos: unas 30 000 entidades afectadas, registro obligatorio en 3 meses, sanciones de nivel "board accountability".
• Italia: decreto legislativo 138/2024 publicado el 4 de septiembre de 2024, en vigor el 16 de octubre de 2024. La ACN (Agenzia per la Cybersicurezza Nazionale) opera el portal de notificación, completado por el DPCM 221 del 9 de diciembre de 2024.
• Luxemburgo, Países Bajos, Bélgica, España, Portugal, Polonia, países nórdicos, países bálticos: transposición efectiva o inminente (procedimiento parlamentario en curso).
• Cinco Estados con retraso al 1 de abril de 2026: riesgo de procedimientos de infracción del Artículo 258 TFUE.

Diferencia entre la directiva y el reglamento de protección de datos

NIS2 y RGPD se solapan parcialmente. Un incidente puede ser a la vez un "incidente significativo" NIS2 y una "violación de datos personales" RGPD. Las notificaciones son entonces paralelas: CSIRT nacional para NIS2, autoridad de protección de datos (AEPD en España, CNIL en Francia) para RGPD. El plazo del Artículo 33 del RGPD es de 72 horas "después de haber tenido conocimiento". NIS2 añade una alerta temprana a 24 horas, lo que crea una obligación suplementaria. Para un editor que opera un servicio de almacenamiento SaaS que sufre una intrusión que implica datos personales, tres canales de reporte pueden activarse (NIS2 + RGPD + DORA si el cliente es financiero), de ahí la importancia de una fuente única con marca temporal, que es precisamente la status page pública.

Para recordar: bajo NIS2, el contador de 24 h arranca desde el conocimiento interno, no después de la clasificación formal. Prepare a sus equipos para publicar un mensaje público en las 4 primeras horas para no tener que hacerlo todo en la 23ª hora.

Cartografía unificada de las tres regulaciones europeas

La complejidad operativa nace del cruce entre las tres regulaciones. Para un editor que presta servicio simultáneamente a entidades financieras y operadores esenciales NIS2, un mismo incidente puede desencadenar tres canales de notificación, con plazos y destinatarios diferentes. La status page juega entonces el papel de denominador común con marca temporal.

Tabla cruzada de plazos

Regulación	Hecho generador	Plazo inicial	Intermedio	Final	Autoridad destinataria	Sanción máxima
DORA Artículo 19	Incidente ICT clasificado como grave (Art. 17-18)	4 h tras clasificación (24 h máx. tras detección)	72 h tras detección	1 mes tras detección	ACPR (FR) / BaFin (DE) / CSSF (LU) / Banca d'Italia (IT)	2 % volumen de negocios mundial o 10 M€ (entidad) / 1 % volumen de negocios diario medio 6 meses (CTPP)
NIS2 Artículo 23	Incidente significativo	24 h alerta temprana	72 h notificación	1 mes informe final	CSIRT nacional (CERT-FR / BSI / ACN / etc.)	10 M€ o 2 % volumen de negocios mundial (esencial) / 7 M€ o 1,4 % volumen de negocios mundial (importante)
RGPD Artículo 33	Violación de datos personales	72 h tras conocimiento	n/a	(según investigación)	AEPD (ES), CNIL (FR) o equivalente nacional	20 M€ o 4 % volumen de negocios mundial

Hecho generador y quién arranca cuándo

Tres puntos de partida distintos cohabitan. DORA parte de la clasificación como incidente grave (formal, documentada, fechada). NIS2 parte del conocimiento interno de un incidente significativo. RGPD parte de la toma de conocimiento de una violación. El plazo operativo más corto es de 4 horas (DORA), pero arranca tarde (después de la clasificación). El más precoz es la alerta temprana NIS2 a 24 h, que puede arrancar varias horas antes de la clasificación DORA.

Para los equipos ops, esto significa que un solo incidente puede estar a la vez en avance NIS2 y en retraso DORA, de ahí la necesidad de un registro común y de un mecanismo de clasificación rápida. Por el lado de la supervisión, la herramienta monitor de uptime HTTP multirregional proporciona la marca temporal técnica objetiva sobre la que se apoya la clasificación.

A quién notificar con el mapeo completo por jurisdicción

Para los SaaS B2B que operan en varios países europeos, esta es la matriz de destinatarios:

• Francia: ACPR (DORA), CERT-FR a través de MonEspaceNIS2 (NIS2), CNIL (RGPD).
• Alemania: BaFin (DORA), BSI (NIS2), BfDI o autoridad de Land (RGPD).
• Italia: Banca d'Italia (DORA, vía portal dedicado), ACN (NIS2), Garante (RGPD).
• Luxemburgo: CSSF (DORA vía eDesk), GovCERT-LU (NIS2), CNPD (RGPD).
• España: Banco de España y CNMV (DORA), INCIBE-CERT (NIS2), AEPD (RGPD).
• Países Bajos: DNB y AFM (DORA), NCSC-NL (NIS2), AP (RGPD).

La idea de un punto de entrada único europeo progresa: el paquete Digital Omnibus presentado por Bird & Bird prevé una armonización a 18 meses post-adopción. En 2026, esta armonización no es todavía efectiva: por tanto, hay que pilotar manualmente las notificaciones múltiples, y la status page sigue siendo el único entregable coherente para todas las jurisdicciones.

---

Cree una status page conforme a DORA y NIS2 desde hoy

---

Para recordar: cuando 3 regulaciones se aplican, la ventana más corta gana, a menudo 4 h DORA. La status page pública con marca temporal sirve a las tres en paralelo.

La status page como prueba documental y por qué los auditores la piden

Una prueba documental en sentido jurídico combina tres propiedades: marca temporal fiable, inmutabilidad, accesibilidad pública verificable. Ningún otro artefacto técnico de un SaaS B2B cumple las tres casillas a la vez. Los logs internos no son accesibles públicamente. Los PDF post-mortem pueden ser editados después. Los correos a clientes no están sellados criptográficamente. La status page pública cumple las tres condiciones, siempre que haya sido concebida con ese espíritu.

Tres propiedades probatorias de marca temporal firmada, archivo inmutable y audiencia pública

La marca temporal debe seguir el RFC 3339 en formato UTC. Es el estándar reconocido por el conjunto de las jurisdicciones europeas para las operaciones electrónicas (eIDAS, eIDAS 2). El sellado en hora local (CET, CEST, BST) es inaceptable porque resulta ambiguo en torno a los cambios de hora. El sellado cualificado en el sentido del RFC 3161, firmado por un Trust Service Provider cualificado, es aún más sólido jurídicamente, pero sigue siendo opcional en la práctica mientras la marca temporal UTC sea coherente y verificable.

La inmutabilidad reposa sobre el audit trail: cada actualización de incidente debe ser versionada, nunca sobrescrita. Si corrige un mensaje a las 14:17 UTC tras una publicación a las 14:02 UTC, las dos versiones deben permanecer accesibles, con la mención "editado a las 14:17". Esta disciplina editorial se parece a la práctica de los medios en línea sobre las correcciones factuales.

La accesibilidad pública es lo que distingue la status page de un log interno. La página debe ser consultable sin autenticación, desde cualquier punto de Internet. Esto impone una infraestructura de alojamiento distinta de la aplicación principal: si su aplicación cae, su status page debe permanecer en pie. Es una exigencia de arquitectura que se refuerza con DNSSEC activo en el dominio status y HTTPS estricto.

El caso Cloudflare R2 del 21 de marzo de 2025 como modelo de referencia

Cloudflare ha documentado públicamente un incidente en su servicio R2 el 21 de marzo de 2025. La empresa publicó un post-mortem detallado tres días después del incidente. El desarrollo es ejemplar: anuncio en la status page a las 14:04 UTC (poco después del inicio de la degradación), actualizaciones cada 15 a 30 minutos, identificación de la causa raíz (problema de configuración de almacenamiento), resolución anunciada a las 15:11 UTC, post-mortem completo el 24 de marzo con línea de tiempo detallada, causa raíz, próximos pasos correctores. La status page sirve aquí de pivote temporal: sella los compromisos operativos, y el post-mortem posterior se refiere explícitamente a ella.

Para un editor SaaS B2B europeo, este modelo es directamente trasladable. No exige herramientas exóticas: exige una disciplina editorial y un formato de exportación estructurado.

Cuando el proveedor de status page cae a su vez

OneUptime ha documentado un caso revelador: entre el 2 y el 23 de febrero de 2026, el módulo system metrics de Atlassian Statuspage permaneció no disponible durante 21 días consecutivos. El análisis publicado por OneUptime el 25 de febrero de 2026 subraya la paradoja: un proveedor de status page que no consigue mantener el SLA de sus propios componentes no puede servir de artefacto de auditoría para sus clientes. El riesgo concentrado en un único proveedor se convierte en una vulnerabilidad contractual directa.

Balance ACPR a ocho meses con la tensión regulatoria frente a la realidad operativa

El balance ACPR del 15 de enero de 2026 señala que los plazos de 4 horas son "todavía raramente respetados". Esta constatación no es un cheque en blanco: acompaña al anuncio del paso al modo de aplicación activa. El mensaje implícito: el año 2026 marca la transición entre la tolerancia y la sanción. Para las entidades que aún no disponen de una status page conforme, el riesgo de sanción es concreto. En el plano de los principios de seguridad TLS y cadena de confianza, el rigor de la marca temporal y de la firma se alinea con las mismas exigencias criptográficas.

Para recordar: solo una status page pública con marca temporal combina las tres propiedades de una prueba oponible. Concebirla así hoy es una inversión de muy alto retorno regulatorio.

Anatomía de una status page DORA-ready con diez atributos obligatorios

Una status page concebida como entregable de auditoría debe marcar diez casillas técnicas. La lista siguiente sintetiza las expectativas cruzadas de los supervisores europeos (ACPR, BaFin, CSSF, Banca d'Italia, ACN, AEPD, INCIBE) y las buenas prácticas operativas en materia de gestión de incidentes desarrolladas por los editores más maduros.

Atributo 1, identificación clara de los componentes y servicios. La granularidad debe descender al nivel producto/región. Una etiqueta "API" es insuficiente; hace falta "API REST v3, región EU-West", "API REST v3, región US-East", "SFTP B2B", "Webhooks". Esto permite declarar un incidente parcial sin desencadenar un pánico injustificado en el conjunto del servicio.

Atributo 2, marca temporal RFC 3339 UTC en todas partes. Ninguna fecha en hora local. Ninguna fecha sin huso horario. La conversión a hora local se hace del lado del navegador. La coherencia UTC garantiza la oponibilidad jurídica.

Atributo 3, severidad codificada y estable. Cuatro niveles como mínimo: operational, degraded performance, partial outage, major outage. Las etiquetas deben ser estables en el tiempo (sin renombrado por marketing). El código numérico subyacente (por ejemplo 0/1/2/3) debe transitar en el flujo JSON para permitir la automatización.

Atributo 4, enlace explícito al incidente en curso e identificador estable. Cada incidente debe tener un identificador único, persistente tras la resolución, accesible por URL canónica. Los reguladores piden a menudo: "Denos la URL exacta de la comunicación pública del incidente XYZ."

Atributo 5, audit trail visible. Cada actualización debe estar versionada, fechada e identificar al autor (al menos por rol o identificador). Las ediciones posteriores deben permanecer visibles con la mención "editado el…".

Atributo 6, exportación estructurada en JSON, RSS, Atom, ICS. JSON sirve para la extracción automatizada hacia los informes reguladores. RSS y Atom sirven para la suscripción cliente (y para el sourcing por herramientas como StatusGator o IsDown). ICS sirve para el mantenimiento planificado para los equipos clientes.

Atributo 7, independencia de infraestructura. La status page debe estar alojada fuera del perímetro aplicativo supervisado. Si su aplicación está en AWS Frankfurt, su status page no debe estarlo. Esta independencia no es negociable: es lo que distingue un entregable útil en caso de avería mayor de un placebo.

Atributo 8, versionado de las actualizaciones. Consecuencia directa del atributo 5: un sistema de almacenamiento inmutable tipo Write-Once-Read-Many (WORM) o un registro firmado garantiza que ninguna reescritura retroactiva es técnicamente posible.

Atributo 9, notificaciones multicanal. Email, webhook, RSS y SMS opcional. Los reguladores piden a menudo estar suscritos durante los controles: rechazar un canal de suscripción no es planteable.

Atributo 10, conservación de larga duración. El archivado de los snapshots (JSON y HTML) debe cubrir como mínimo 6 años para alinear DORA Artículos 5 a 14 (ICT risk framework, registro de incidentes) y las trasposiciones nacionales NIS2. Francia impone 6 años en la Ley de Resiliencia adoptada. Las trasposiciones italiana y alemana retienen un mínimo de 5 años.

---

Apunte sobre el riesgo de terceros ICT y las cláusulas contractuales DORA Artículos 28 y 30

El capítulo V de DORA regula las relaciones entre entidades financieras y proveedores ICT. El Artículo 28 impone llevar un registro de los acuerdos contractuales ICT, la clasificación de las funciones críticas o importantes (CIFA), y la concentración del riesgo de terceros. El Artículo 30 enumera las cláusulas contractuales mínimas: descripción clara del servicio, niveles de servicio medibles, localización de los datos, seguridad de la información, accesibilidad y restitución de los datos, derecho de auditoría, estrategia de salida.

Para un editor o un cliente SaaS B2B europeo, estos dos artículos dictan un cuestionamiento objetivo en el momento de elegir un proveedor de status page:

• Localización de los datos. ¿Está el alojamiento de los datos de la status page (incidentes, comentarios, metadatos) garantizado contractualmente en Europa? ¿Están los subcontratistas (CDN, backups, monitoreo interno) todos localizados en Europa?
• Jurisdicción del proveedor. Un proveedor cuya casa matriz está en los Estados Unidos activa el riesgo CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018), que permite a las autoridades estadounidenses exigir datos almacenados por una empresa bajo jurisdicción estadounidense, independientemente del país de almacenamiento físico. Esto no descalifica automáticamente a los proveedores afectados (Atlassian Statuspage, por ejemplo), pero impone SCC (Standard Contractual Clauses) RGPD reforzadas y un DPA explícito.
• Certificaciones. SOC 2 Type II e ISO 27001 son útiles pero no suficientes para DORA, que exige una auditabilidad específica del sector financiero. Pida explícitamente un Statement of Applicability que incluya la cláusula DORA Artículo 28.
• Registro de los subcontratistas. Un proveedor conforme a DORA debe poder proporcionar la lista actualizada de sus subprocesadores con su localización y su rol. Rechazo = señal de alerta.
• Estrategia de salida probada. La capacidad de recuperar la totalidad de su historial de status page en formato abierto (JSON, CSV) en menos de 72 horas debe estar contractualizada y probada anualmente. Una exportación improvisada en caso de urgencia no aguanta ante un auditor.

Los proveedores US (Atlassian Statuspage, StatusGator, algunos BetterStack según la jurisdicción del contrato) cohabitan con alternativas europeas (Instatus EU, CaptainDNS, OpenStatus en modo self-hosted). La elección no se hace sobre las features o el pricing, se hace sobre la alineación con DORA Artículos 28 y 30. Para el detalle de las cláusulas contractuales, consulte la síntesis de Bird & Bird sobre las cláusulas contractuales DORA. Sobre la misma lógica de alojamiento europeo contractualizado, véase también la guía MTA-STS completa.

---

Para recordar: 10 atributos técnicos más 1 cuestión jurídica de jurisdicción forman la lista anatomía. Cualquier fallo en un atributo es un riesgo de auditoría, no un detalle de producto.

Modelo de incident report del JSON status page al informe DORA

El objetivo de una status page DORA-ready no es solo comunicar públicamente. Es también alimentar directamente el informe regulatorio confidencial, sin entrada manual repetida. El pivote entre los dos es un fichero JSON estructurado, derivado de la status page y transpuesto sobre las plantillas RTS/ITS JC 2024-33.

Correspondencia campo a campo entre la exportación status page y la plantilla regulador

El informe inicial DORA exige nueve campos mínimo. La tabla siguiente muestra la correspondencia con una exportación JSON status page:

• entity_id (status page) -> campo "LEI" o identificador nacional del informe DORA.
• incident.uuid (status page) -> campo "Reference number" del informe.
• incident.detected_at (timestamp RFC 3339 UTC) -> campo "Date and time of detection".
• incident.classified_at -> campo "Date and time of classification".
• incident.preliminary_description -> campo "Description of the incident".
• incident.classification_criteria (lista codificada Art. 18) -> campo "Classification criteria activated".
• incident.impact_estimate (clientes, duración, geografía, datos) -> bloque "Estimated impact".
• incident.immediate_actions (tabla de medidas) -> campo "Immediate measures taken".
• incident.contact (email + teléfono del contacto DORA) -> campo "Reporting contact".

Ejemplo JSON para un incidente DDoS clasificado como grave

{
  "entity": {
    "lei": "5493000F4ZO33MV32P92",
    "name": "captaindns.com",
    "ncas": ["ACPR-FR", "BaFin-DE"]
  },
  "incident": {
    "uuid": "INC-2026-05-15-001",
    "url_public": "https://status.captaindns.com/incidents/INC-2026-05-15-001",
    "detected_at": "2026-05-15T14:02:11Z",
    "classified_at": "2026-05-15T14:48:32Z",
    "classification_criteria": [
      "geographical_spread:multi_region",
      "data_loss:none",
      "duration_estimate:over_2h",
      "clients_affected:over_10000"
    ],
    "severity": "major_outage",
    "preliminary_description": "Volumetric DDoS attack (1.2 Tbps) on EU-West API ingress, mitigation engaged at T+8min, traffic partially restored T+15min, full mitigation T+47min.",
    "impact_estimate": {
      "clients_affected_estimate": 12400,
      "geography": ["EU-West", "EU-North"],
      "data_loss": false,
      "downstream_dependencies": ["bank-X", "insurer-Y"]
    },
    "immediate_actions": [
      "Activation BGP blackhole upstream",
      "Failover to APAC fallback (read-only mode)",
      "Public status page update T+11min"
    ],
    "next_steps": [
      "Continuous monitoring 24h",
      "Forensic capture preserved",
      "Intermediate report scheduled T+72h"
    ],
    "contact": {
      "name": "DORA Incident Notifier (role dedicated)",
      "email": "dora-incidents@captaindns.com",
      "phone": "+33 1 00 00 00 00"
    },
    "timestamps_audit_trail": [
      {"at": "2026-05-15T14:08:00Z", "action": "public_announce", "version": 1},
      {"at": "2026-05-15T14:23:00Z", "action": "update_severity", "version": 2},
      {"at": "2026-05-15T14:55:00Z", "action": "resolution_announced", "version": 3}
    ]
  }
}

Workflow de extracción y transmisión

La industrialización del flujo se apoya en tres ladrillos. Una tarea cron lee la status page cada 5 minutos, serializa los incidentes en formato JSON, firma el fichero con una firma destacada (PGP o cosign). Una segunda tarea, desencadenada por un webhook al clasificar, prepara la versión regulador mapeando los campos sobre los XSD oficiales (XBRL para BaFin, XML para Banca d'Italia, JSON para ACPR OneGate). Un tercer ladrillo gestiona la transmisión a través de las API o portales dedicados (OneGate API, eDesk CSSF, MVP BaFin), con reintentos en caso de indisponibilidad del portal.

Sobre la securización del transporte email de las notificaciones complementarias, el rigor de las políticas MTA-STS alojadas se inscribe en la misma lógica de prueba criptográfica explotable en auditoría.

Para recordar: si su status page exporta este JSON, rellena el informe DORA en 4 horas sin reescritura. Es la diferencia entre cumplir el plazo y fallarlo.

Marco práctico en siete pasos (HowTo)

Para pasar del concepto a lo operativo, aquí un marco en siete pasos, aplicable en 90 días para un SaaS B2B europeo que dispone de un equipo SRE de base.

Marco de adecuación status page DORA y NIS2

Siete pasos para hacer su status page oponible ante una auditoría ACPR, BaFin, ACN o CSSF en 90 días.

1. Paso 1: inventario de los servicios y clasificación de criticidad

   Elaborar la lista exhaustiva de los servicios expuestos y asociar a cada uno una criticidad en el sentido de DORA (CIFA / no-CIFA) o NIS2 (esencial / importante / fuera de alcance). Documentar el criterio retenido y el método de clasificación. Este inventario es el cimiento de todos los compromisos posteriores. Sin un inventario limpio, es imposible justificar ante el regulador por qué un subservicio no aparece en la status page.

2. Paso 2: elección del proveedor de status page según DORA Artículos 28 y 30

   Evaluar a cada candidato sobre cinco criterios objetivos: jurisdicción del proveedor, localización de los datos, subcontratistas documentados, estrategia de salida contractualizada, audit trail técnico. Un proveedor sin respuesta escrita sobre estos cinco puntos debe ser descartado, independientemente de sus funcionalidades. La revisión contractual debe ser validada por la dirección jurídica antes de la firma.

3. Paso 3: arquitectura multirregional e independencia DNS

   Alojar la status page sobre una infraestructura estrictamente distinta del perímetro aplicativo. DNS separado (subdominio status. dedicado, autoridad distinta), alojamiento geográficamente separado. Activar DNSSEC, HSTS y CAA sobre el dominio status. La independencia se pone a prueba: cortar artificialmente la aplicación principal en pruebas y verificar que la status page sigue siendo consultable. Sin prueba, la independencia no es más que una declaración.

4. Paso 4: plantillas de incidente para cuatro niveles de gravedad

   Preparar cuatro modelos de anuncio público: operational maintenance, degraded performance, partial outage, major outage. Cada modelo incluye los campos obligatorios (timestamps UTC, severidad, componentes afectados, medidas inmediatas, ETA estimada). Los modelos deben ser validados por el DPO, la dirección jurídica y la dirección de comunicación. Sin prevalidación, cada incidente exige una revisión urgente que cuesta tiempo precioso.

5. Paso 5: pipeline de archivado sellado con marca temporal

   Poner en marcha un snapshot con marca temporal cada 5 minutos (JSON + HTML) depositado en un almacenamiento inmutable (S3 Object Lock en modo compliance, o registro firmado local tipo sigstore). Conservación mínimo 6 años. La firma destacada del snapshot debe ser depositada por separado para permitir la verificación de integridad por un tercero.

6. Paso 6: prueba trimestral en forma de tabletop exercise

   Organizar cada tres meses un ejercicio tabletop simulando un incidente grave. El objetivo: validar que el plazo entre detección y publicación pública permanece por debajo de 15 minutos, y que la clasificación DORA se documenta en menos de 4 horas. La prueba debe implicar SRE, comms, jurídico, DPO y un miembro del COMEX. Un acta escrita del tabletop forma parte de las pruebas auditables.

7. Paso 7: revisión anual alineada con auditoría ACPR, BaFin, ACN, CSSF

   Organizar anualmente una revisión formal (board level) que repase los incidentes graves del año, verifique la conformidad de las notificaciones, valide las evoluciones de la status page y arbitre las inversiones del año siguiente. Esta revisión es exigida por DORA Artículo 17 (gobernanza y organización del ICT risk management). Sin huella escrita de esta revisión, el auditor puede concluir un defecto de gobernanza, lo que agrava cualquier sanción.

El encadenamiento de los pasos 1 a 4 prepara la infraestructura; los pasos 5 y 6 bloquean la prueba y la resiliencia; el paso 7 institucionaliza el enfoque. Para los equipos que nunca han dirigido una simulación, la inversión inicial parece elevada. Es en realidad ínfima frente al riesgo de sanción. Sobre el rigor de los controles HTTPS y HSTS asociados al dominio status, véase la guía HSTS preload.

Para recordar: sin drill trimestral de 4 horas, descubrirá en producción que su proceso de notificación no aguanta. El drill cuesta medio día. Una notificación fallida cuesta 10 millones de euros.

Preguntas frecuentes

FAQ

¿Está nuestro SaaS afectado por DORA si prestamos un servicio a un banco?

Sí, indirectamente. Los Artículos 28 y 30 de DORA imponen a las entidades financieras repercutir contractualmente las obligaciones sobre sus proveedores ICT, particularmente los que sustentan una CIFA (Critical or Important Function Arrangement). Estará por tanto sujeto a cláusulas contractuales obligatorias: localización de los datos, derechos de auditoría, estrategia de salida, niveles de servicio medibles. Si es designado CTPP (Critical Third-Party Provider) por las ESA, cae bajo supervisión directa. La status page se convierte entonces en un entregable contractual cuantificado y oponible.

¿Cuál es el plazo exacto de una notificación DORA inicial?

Cuatro horas después de la clasificación del incidente como grave, con un límite máximo de 24 horas tras la detección. La clasificación se apoya en el Artículo 18 de DORA y los criterios de materialidad (impacto clientes, duración, geografía, pérdida de datos, criticidad del servicio). El plazo arranca en el momento del veredicto "incidente grave", no en la detección. El documento JC 2024-33 publicado en julio de 2024 por las ESA enumera los nueve campos obligatorios del informe inicial: identidad de la entidad, marca temporal detección, marca temporal clasificación, descripción preliminar, criterios de clasificación, impacto estimado, medidas inmediatas, próximos pasos, contacto dedicado.

¿Cuál es la diferencia operativa entre DORA y NIS2 para nuestra status page?

DORA prima sobre el sector financiero (bancos, aseguradoras, fondos, proveedores de servicios de pago) y arranca su cronómetro 4 horas después de la clasificación. NIS2 cubre 18 sectores esenciales e importantes (energía, salud, digital, transporte, alimentación, etc.) y arranca 24 horas después del conocimiento interno del incidente. Las dos convergen en 72 horas de notificación intermedia y 1 mes para el informe final. Si está en ambos perímetros (raro pero posible), DORA prima debido al plazo más corto. La status page sirve a las dos regulaciones con el mismo artefacto con marca temporal, siempre que el formato JSON exportado cubra los campos de las dos plantillas.

¿Puede la status page servir realmente de prueba documental en auditoría?

Una página pública con marca temporal, archivada y exportable en JSON, RSS o Atom cumple las tres propiedades de una prueba oponible: marca temporal RFC 3339 UTC, inmutabilidad vía audit trail visible, accesibilidad pública verificable. Ningún PDF post-mortem ni log interno combina estos tres criterios. Varios reguladores europeos (ACPR, BaFin) consideran ahora la comunicación pública de incidentes como parte integrante del expediente de auditoría ICT, sin nombrarla formalmente "prueba", pero es invocada regularmente durante los controles documentales. A título comparativo, una marca temporal cualificada RFC 3161 por un Trust Service Provider aporta un nivel jurídico suplementario.

¿Es nuestra status page Atlassian Statuspage US compatible con DORA Artículo 28?

La cuestión no es de incompatibilidad absoluta, sino de gestión del riesgo de terceros ICT y de jurisdicción. Un proveedor de status page bajo jurisdicción estadounidense activa el CLOUD Act y necesita SCC (Standard Contractual Clauses) y un DPA RGPD reforzados. Para mantenerse conforme a DORA Artículos 28 a 30, exija al proveedor: localización europea de los datos y de los logs, cláusulas de auditoría, estrategia de salida probada anualmente, certificaciones ISO 27001 y SOC 2 Type II, registro al día de los subcontratistas. Si su servicio sustenta una CIFA, estas cláusulas son obligatorias, no opcionales. En su defecto, su cliente financiero tendrá que arbitrar entre mantenimiento del contrato y riesgo regulatorio.

¿Cuáles son los 5 pilares de DORA?

DORA reposa sobre cinco pilares estructurantes. Primer pilar: ICT risk management (Artículos 5 a 15), que impone un marco de gobernanza y de gestión de los riesgos ICT. Segundo pilar: ICT-related incident management, classification and reporting (Artículos 17 a 23), la gestión de incidentes ICT, su clasificación y su reporte, que incluye el Artículo 19 sobre la notificación. Tercer pilar: digital operational resilience testing (Artículos 24 a 27), del que TLPT (Threat-Led Penetration Testing) para las entidades significativas. Cuarto pilar: management of ICT third-party risk (Artículos 28 a 44), que dicta los contratos con los proveedores ICT, incluido el proveedor de status page. Quinto pilar: information sharing arrangements (Artículo 45). El pilar 2 impone la status page como artefacto, el pilar 4 dicta sus condiciones contractuales.

¿A quién notificar en Francia un incidente DORA?

La ACPR a través del portal OneGate, en formato JSON, sin firma electrónica requerida. Para los períodos de indisponibilidad de OneGate (medianoche-4 h, domingos y festivos), el envío se hace por correo electrónico a 2760-INCIDENTS-DORA-UT@acpr.banque-france.fr. Para un incidente NIS2, el CSIRT nacional designado (CERT-FR a través de MonEspaceNIS2 una vez promulgada la Ley de Resiliencia). Para un incidente RGPD que implique datos personales, la CNIL. Un mismo incidente puede desencadenar dos o tres vías paralelas, de ahí el interés operativo crítico de un formato pivote tipo JSON status page explotado una sola vez y transpuesto hacia cada plantilla regulador.

¿Cuánto tiempo debemos archivar nuestras status pages?

Ningún plazo está fijado explícitamente por DORA Artículo 19, pero la coherencia con los Artículos 5 a 14 (ICT risk framework, registro de incidentes, audit trail) sugiere un mínimo de 5 a 6 años. El RGPD exige poder demostrar su conformidad en el sentido del Artículo 5 apartado 2, sin plazo fijado. Los reguladores nacionales (ACPR, BaFin) piden típicamente 5 años de archivos auditables. La Ley de Resiliencia francesa adoptada en febrero de 2025 prevé 6 años para NIS2. Recomendación prudente: archivar todos los snapshots status page (JSON y HTML) en almacenamiento inmutable tipo WORM o registro firmado, durante 6 años mínimo, con procedimiento documentado de restitución bajo 72 horas.

¿Hace falta una status page diferente por mercado UE (FR, DE, IT)?

No, una sola status page multilingüe basta, siempre que el contenido sea idéntico en sustancia de una lengua a otra. Los reguladores nacionales aceptan un entregable unificado siempre que sea accesible en la lengua de la jurisdicción concernida. Atención en cambio a los husos horarios: utilice UTC como fuente única de verdad y muestre la conversión local del lado del navegador (client-side). Si su servicio opera bajo varias autoridades (ACPR + BaFin + CSSF), mantenga un identificador de incidente estable y global, traducido por mapeo lingüístico, jamás por historial separado. Una duplicación de historial conlleva incoherencias temporales muy expuestas en auditoría.

¿Qué pasa si fallamos un plazo de 4 h DORA?

Sanciones administrativas hasta el 2 % del volumen de negocios anual mundial o 10 millones de euros (el más elevado) para la entidad, y hasta 1 millón de euros de multa individual para los responsables identificados. Para los CTPP: hasta el 1 % del volumen de negocios diario medio mundial, durante seis meses. Más allá de las multas, consecuencias reputacionales vía la publicación de las sanciones (Artículo 54). La ACPR, en su balance de 8 meses de enero de 2026, señala que estos plazos de 4 horas son "todavía raramente respetados". 2026 marca el fin de la tolerancia y el comienzo de la aplicación activa. Conservar una huella pública exhaustiva (status page con marca temporal) es hoy el mejor seguro contra una recalificación desfavorable.

Lista de verificación final de veinticinco puntos a validar antes de la auditoría

Esta lista sintetiza las exigencias DORA, NIS2 y RGPD aplicables a la status page de un SaaS B2B europeo. Está estructurada en tres bloques: documental (7 puntos), técnico (10 puntos), organizativo (8 puntos). Marcar 25 puntos sobre 25 no garantiza la ausencia de sanción, pero coloca a la entidad en una situación defensiva sólida frente a un control ACPR, BaFin, ACN, CSSF o Banca d'Italia.

Bloque documental (siete puntos)

1. Política de clasificación de los incidentes escrita y firmada por la dirección (matriz severidad hacia reporte DORA y NIS2).
2. Procedimiento de notificación DORA 4 horas documentado, validado por la dirección jurídica, actualizado anualmente.
3. Procedimiento de notificación NIS2 24 horas documentado, alineado con el portal nacional (MonEspaceNIS2, BSI, ACN).
4. DPA RGPD firmado con el proveedor de status page, incluyendo la lista de los subcontratistas.
5. Registro de los proveedores ICT al día, conforme a DORA Artículo 28 apartado 3.
6. Estrategia de salida del proveedor de status page probada anualmente y documentada.
7. Plan de comunicación de crisis validado por el COMEX (roles, mensajes-tipo, canales).

Bloque técnico (diez puntos)

1. Status page alojada fuera de la infraestructura aplicativa, con prueba de independencia probada.
2. Marca temporal RFC 3339 UTC en todas partes, sin excepción (interfaz, API, exportaciones).
3. Severidad codificada en 4 niveles mínimo (operational, degraded, partial outage, major outage).
4. Exportación estructurada disponible en JSON, RSS y Atom, completada por ICS para el mantenimiento.
5. Audit trail visible en cada actualización, identificando al autor (rol mínimo).
6. Versionado de las actualizaciones incidentes, jamás de sobrescritura retroactiva.
7. Monitoreo multirregional en marcha sobre al menos 4 zonas (UE, US, APAC, UK).
8. Notificaciones multicanal operativas: email, webhook, RSS, SMS opcional.
9. Archivado inmutable WORM o registro firmado sobre al menos 6 años.
10. Seguridad del dominio status: DNSSEC activo, HTTPS estricto, HSTS, CAA, test HSTS validado.

Bloque organizativo (ocho puntos)

1. Rol "DORA Incident Notifier" designado por escrito, con backup (equivalente CSSF eDesk role).
2. Guardia 24/7 sobre el canal status page, con rotación documentada y calendario anual.
3. Drill 4 horas trimestral en forma de tabletop exercise, seguido de un post-mortem del drill.
4. Mapeo documentado de las autoridades nacionales por jurisdicción (ACPR / BaFin / ACN / CSSF / Banca d'Italia + CSIRT NIS2 + CNIL/AEPD y equivalentes RGPD).
5. KPI "delay-to-publish" seguido en continuo, con objetivo inferior a 15 minutos.
6. Comunicaciones clientes pre-redactadas por escenario, validadas por DPO y dirección jurídica.
7. Formación anual de los equipos SRE y comunicación sobre las obligaciones DORA y NIS2.
8. Revisión anual COMEX y consejo de administración sobre los incidentes graves (DORA Artículo 17).

Para integrar esta lista directamente en su backlog de auditoría, dos exportaciones operativas están disponibles: descargar la lista en formato CSV (para importación Excel o Google Sheets) o en formato JSON (para ingestión en un GRC, Jira o Notion). Cada línea contiene la categoría, el número, el punto, la prioridad y la prueba documental requerida para la defensa documental.

Descarga la checklist de despliegue

Los asistentes pueden reutilizar la checklist con los exports JSON o CSV de abajo.

• Descargar la lista DORA/NIS2 (CSV)
• Descargar la lista DORA/NIS2 (JSON)

Glosario

• CIFA: Critical or Important Function Arrangement, función crítica o importante en el sentido de DORA Artículo 28.
• CTPP: Critical Third-Party Provider, proveedor tercero crítico designado por las ESA y sujeto a supervisión directa.
• DORA: Digital Operational Resilience Act, Reglamento (UE) 2022/2554, en aplicación desde el 17 de enero de 2025.
• NIS2: Network and Information Security Directive 2, Directiva (UE) 2022/2555, pendiente de transposición a los derechos nacionales.
• ESA: European Supervisory Authorities, que agrupa a la EBA (bancos), la EIOPA (seguros) y la ESMA (mercados financieros).
• CSIRT: Computer Security Incident Response Team, equipo nacional designado por cada Estado miembro para NIS2 (CERT-FR, BSI, ACN, etc.).
• RTS / ITS: Regulatory Technical Standards e Implementing Technical Standards, publicados por las ESA para precisar DORA.
• WORM: Write Once Read Many, modo de almacenamiento inmutable que garantiza la ausencia de reescritura.

Conclusión

El año 2026 ratifica el vuelco entre la fase de transición y la aplicación activa del Reglamento DORA y de la Directiva NIS2, las dos regulaciones europeas estructurantes para la resiliencia operativa digital. Para un SaaS B2B europeo, el cumplimiento DORA y el cumplimiento NIS2 transforman la status page pública en un entregable de auditoría oponible ante un supervisor nacional, y ya no en una simple herramienta de comunicación de marketing. Tres prioridades emergen: alojar la status page sobre una infraestructura independiente, exportar un formato JSON pivote alineado con JC 2024-33, organizar un drill trimestral de 4 horas para validar la cadena completa. Los editores que anticipen esta transformación entre 2026 y 2027 transformarán una obligación regulatoria en ventaja comercial: un cliente financiero o un operador esencial preferirá siempre un proveedor cuya status page pueda servir directamente a su propio informe regulador, antes que un proveedor donde cada incidente exige una reconstrucción manual de la prueba. Para empezar a industrializar este enfoque, el hospedaje de una status page conforme constituye el punto de entrada más rápido.