DORA, NIS2 e status pages: transformar a comunicação de incidente em prova de conformidade UE

⚡TL;DR

• A conformidade DORA assenta no Artigo 19, que impõe uma notificação inicial 4 horas após a classificação de um incidente grave (24 horas no máximo após a deteção), um relatório intermédio a 72 horas e um relatório final a 1 mês, números oficiais confirmados pelos RTS/ITS JC 2024-33 publicados pelas ESA a 17 de julho de 2024.
• A conformidade NIS2 apoia-se no Artigo 23, que impõe um alerta precoce a 24 horas, uma notificação a 72 horas e um relatório final a 1 mês, aplicável a 18 setores essenciais e importantes na Europa.
• Uma status page pública com selo temporal, arquivada e exportável em JSON satisfaz as três propriedades de uma prova oponível: selo temporal RFC 3339 UTC, audit trail imutável, acessibilidade pública verificável.
• A ACPR assinala no seu balanço a 8 meses do DORA (janeiro de 2026) que os prazos de 4 horas são «ainda raramente respeitados». 2026 marca o fim da tolerância e o início da aplicação ativa.
• O risco terceiro TIC (DORA Artigo 28) impõe uma revisão contratual do prestador de status page: jurisdição, localização dos dados, exit strategy, direito de auditoria.

A 15 de janeiro de 2026, a ACPR publicou o seu balanço dos oito primeiros meses de aplicação do DORA concluindo que os prazos de notificação de quatro horas são «ainda raramente respeitados» pelas entidades financeiras francesas. Em Frankfurt e no Luxemburgo, a BaFin e a CSSF observam uma constatação equivalente. Do lado da NIS2, 22 dos 27 Estados-Membros transpuseram a diretiva a 1 de abril de 2026: a Alemanha colocou em vigor o NIS2UmsuCG a 6 de dezembro de 2025, a Itália aplica o decreto legislativo 138/2024 desde 16 de outubro de 2024, a França aguarda a promulgação da Lei Resiliência adotada a 26 de fevereiro de 2025.

Neste panorama, uma questão operacional regressa em cada auditoria: como apresentar a prova de que uma notificação de incidente foi efetivamente emitida dentro dos prazos? Os e-mails internos perdem-se, os tickets ServiceNow encerram, as capturas de ecrã contestam-se. Resta um artefacto público, com selo temporal, acessível a qualquer hora a partir do exterior: a status page. Ora, para a maioria dos SaaS B2B europeus, esta página continua a ser uma ferramenta de comunicação de marketing, não um entregável de auditoria. A viragem regulamentar que se jogou entre 2024 e 2026 altera radicalmente este estatuto.

Este artigo dirige-se aos diretores técnicos, responsáveis pela segurança da informação, responsáveis SRE e encarregados da proteção de dados que devem pilotar a conformidade DORA e a conformidade NIS2 de um SaaS B2B europeu. Articula-se em três tempos: uma componente pedagógica sobre as regulamentações, uma componente operacional sobre a anatomia de uma status page conforme, depois uma componente checklist para preparar um controlo. Sairá com um mapeamento unificado dos prazos, um modelo de exportação JSON alinhado com os modelos RTS/ITS DORA, uma metodologia em sete etapas e uma checklist de vinte e cinco pontos.

A constatação inicial é simples: a status page pública reúne, sem sobrecusto técnico, as três propriedades de uma peça probatória. É necessário, ainda, que seja concebida com esse espírito. As secções seguintes mostram como transformar uma ferramenta operacional num entregável de auditoria, apoiando-se nos textos oficiais (EUR-Lex, RTS/ITS das ESA, ANSSI, ACPR, BaFin, CSSF, Banca d'Italia) e nos relatos de experiência públicos mais recentes.

Porque é que a status page entra no perímetro de auditoria UE em 2026

A status page pública foi durante muito tempo percecionada como uma montra. Servia para tranquilizar os clientes durante um incidente, para evitar uma saturação do suporte, para sinalizar uma janela de manutenção. Em 2026, muda de função. Os reguladores europeus, com a ACPR à cabeça, consideram agora que uma comunicação pública de incidente com selo temporal faz parte integrante do dossiê de conformidade TIC, sem a nomear formalmente «prova» nos textos, mas convocando-a sistematicamente nos controlos documentais.

O deslize regulamentar: da página de cortesia ao artefacto de auditoria

Três elementos explicam esta viragem. Primeiro, o fim do período de transição do DORA. O Regulamento UE 2022/2554 entrou em aplicação a 17 de janeiro de 2025. Os oito primeiros meses serviram de período de observação, durante o qual os supervisores não aplicaram sanções massivas. A partir do primeiro trimestre de 2026, a ACPR, a BaFin, o Banco Central do Luxemburgo e a Banca d'Italia confirmaram ter passado ao modo de aplicação ativa. Em segundo lugar, a transposição da NIS2 generaliza-se. A 1 de abril de 2026, 22 Estados-Membros em 27 adotaram um texto nacional, o que cobre a maioria dos operadores económicos europeus. Por fim, a ENISA publicou em outubro de 2025 o seu Threat Landscape que documenta uma intensificação dos incidentes TIC, o que empurra os reguladores a endurecer a sua exigência de transparência.

Três forças convergentes: regulação financeira, segurança de rede e cadeia de fornecimento

O DORA aplica-se às entidades financeiras e aos seus prestadores de serviços TIC críticos. A NIS2 cobre 18 setores (energia, saúde, transportes, digital, alimentação, infraestruturas públicas, etc.). Para um editor SaaS B2B europeu, coexistem dois cenários. Primeiro cenário: o editor é ele próprio operador essencial ou importante na aceção da NIS2 (por exemplo, um alojador cloud, um prestador de serviço gerido, um editor de assinatura eletrónica qualificada). Está então diretamente sujeito à NIS2. Segundo cenário: o editor presta serviço a um banco, a uma seguradora, a uma fintech sujeita ao DORA. Torna-se então um prestador TIC na aceção do DORA Artigo 28, e o seu cliente deve contratualizar obrigações de resiliência, auditabilidade e reporte. Em ambos os casos, a status page sai do campo do marketing para entrar no campo contratual e regulamentar.

A cadeia de fornecimento também entra em jogo. O NIS2 Artigo 21 parágrafo 2 impõe uma gestão explícita dos riscos ligados aos prestadores e à cadeia de fornecimento. Uma falha não comunicada de um subcontratado pode ser imputada ao operador principal. A status page serve então de mecanismo contratual de notificação entre elos da cadeia.

O que dizem os supervisores na prática

As posições públicas convergem. A ACPR, através do seu portal OneGate e da sua FAQ DORA, insiste na rastreabilidade das notificações. A BaFin alemã, no seu artigo oficial sobre o reporte DORA, exige a coerência entre a comunicação pública e o relatório regulamentar. A CSSF luxemburguesa publicou as circulares 25/892 e 25/893 em maio de 2025, que detalham a classificação e o reporte. A ANSSI, em França, opera o portal MonEspaceNIS2 que centraliza as notificações NIS2 para os operadores essenciais e importantes. A mensagem é uniforme: é precisa uma marca pública com selo temporal, e essa marca não é opcional. É um complemento estrutural ao relatório regulamentar confidencial.

Para as equipas operacionais, isto impõe repensar a conceção da status page como entregável de auditoria desde a fase de arquitetura, e não como canal de comunicação reativo. É exatamente o que permite a ferramenta status page CaptainDNS, concebida para produzir um artefacto oponível de forma nativa.

A reter: em 2026, a sua status page pode ser convocada como peça probatória pelo seu regulador. Concebê-la como tal desde o início evita uma reformulação dispendiosa no momento da auditoria.

DORA Artigo 19 dissecado: 4 h, 72 h, 1 mês

O Regulamento DORA, formalmente o Regulamento (UE) 2022/2554, aplica-se às entidades financeiras europeias e aos seus prestadores TIC críticos. O seu capítulo III, e mais especificamente o Artigo 19, enquadra a notificação dos incidentes TIC graves. Para um editor SaaS B2B que presta serviço a um banco ou a uma seguradora, compreender este artigo não é um exercício jurídico: é o que dita a orquestração operacional de um incidente.

Âmbito de aplicação: entidades financeiras e prestadores TIC críticos

O Artigo 2 do DORA enumera 20 categorias de entidades financeiras: instituições de crédito, instituições de pagamento, prestadores de serviços de informação sobre contas, prestadores de serviços de financiamento colaborativo, empresas de investimento, plataformas de negociação, depositários centrais, contrapartes centrais, gestores de organismos de investimento coletivo, empresas de seguros e resseguros, mediadores de seguros, instituições de previdência profissional, agências de notação, administradores de índices de referência, prestadores de serviços de criptoativos, registos de titularização, fundos, etc. Todas estas entidades estão diretamente sujeitas ao DORA.

O capítulo V (Artigos 28 a 44) estende por contrato as obrigações DORA aos prestadores TIC. Se um prestador suporta uma função crítica ou importante (CIFA, Critical or Important Function Arrangement), as cláusulas contratuais são obrigatórias. Se um prestador ultrapassar os limiares definidos pelas ESA (European Supervisory Authorities: EBA, EIOPA, ESMA), pode ser designado «prestador terceiro crítico» (CTPP, Critical Third-Party Provider) e ficar sob supervisão direta.

O tríptico temporal: 4 h, 72 h, 1 mês

O Artigo 19 impõe três prazos para notificar um incidente TIC classificado como grave:

• Notificação inicial: 4 horas após a classificação do incidente como grave, com um limite máximo de 24 horas após a deteção.
• Relatório intermédio: 72 horas após a deteção.
• Relatório final: 1 mês após a deteção.

O detalhe dos prazos e dos campos obrigatórios consta do documento final das normas técnicas JC 2024-33 publicado a 17 de julho de 2024 pelas três autoridades europeias EBA, EIOPA e ESMA. Trata-se de Regulatory Technical Standards (RTS) e Implementing Technical Standards (ITS) que precisam o conteúdo esperado de cada relatório. A notificação inicial deve conter nove campos: identidade da entidade, selo temporal da deteção, selo temporal da classificação, descrição preliminar, critérios de classificação ativados (Artigos 17 e 18 DORA), impacto estimado, medidas imediatas tomadas, próximos passos previstos, contacto dedicado.

A classificação apoia-se nos critérios do Artigo 18 do DORA: materialidade do impacto (número de clientes afetados, duração, geografia, perda de dados, criticidade do serviço interrompido, gravidade económica). O prazo de 4 horas inicia-se no momento em que a entidade conclui formalmente que o incidente é «grave», não na deteção. Esta nuance muda tudo na prática: é necessário documentar a cadeia de decisão (quem classificou, com que critérios, a que hora UTC), sob pena de o regulador requalificar o prazo e concluir por um incumprimento.

A quem notificar na prática consoante a sua jurisdição

As entidades notificam a sua autoridade nacional competente:

• França: ACPR através do portal OneGate (formato JSON, sem assinatura eletrónica exigida). Em caso de indisponibilidade do OneGate (meia-noite-4 h, domingos), envio por correio eletrónico para 2760-INCIDENTS-DORA-UT@acpr.banque-france.fr.
• Alemanha: BaFin através do portal MVP (Meldungs- und Veröffentlichungsplattform), em formato XBRL.
• Luxemburgo: CSSF através do portal eDesk (Circular 25/893), acompanhado de uma matriz de classificação padronizada.
• Itália: Banca d'Italia através do seu portal dedicado aos incidentes DORA, em formato CSV ou XML.

Para os CTPP designados, a supervisão é conjunta entre ESA e regulador nacional, com uma equipa Joint Examination Team (JET) que pode auditar no local. Um editor SaaS B2B que presta serviço a vários bancos europeus pode ter de notificar várias autoridades em paralelo para um mesmo incidente, daí o interesse crítico de um formato pivot tipo JSON explorado a partir da sua status page, o que se cruza com a lógica do monitoring DNS resiliente documentado anteriormente.

Sanções Artigos 50 a 58

O DORA prevê sanções administrativas pesadas. Para as entidades financeiras: até 2 % do volume de negócios anual mundial ou 10 milhões de euros (o mais elevado), com coima individual que pode atingir 1 milhão de euros para os responsáveis. Para os CTPP: até 1 % do volume de negócios diário médio mundial, durante seis meses no máximo. Para além das coimas, as sanções são publicadas (Artigo 54), o que acrescenta um custo reputacional significativo. O balanço da ACPR de janeiro de 2026 precisa que a fase de aplicação ativa arrancou no primeiro trimestre de 2026, mas sem ainda citar nenhum caso público sancionado, sinal de que os reguladores preparam os seus processos em silêncio.

A reter: 4 horas após a classificação, deve dispor de 9 campos obrigatórios prontos a transmitir. Se a sua status page já exporta estes campos, ganhou o essencial da corrida.

NIS2 Artigo 23 e a cascata 24 h, 72 h, 1 mês

A Diretiva NIS2, formalmente a Diretiva (UE) 2022/2555, completa o Regulamento DORA cobrindo todos os setores essenciais e importantes fora do financeiro puro. O seu Artigo 23 fixa uma cascata de notificação distinta, mais ampla no seu perímetro, e com um ponto de partida diferente. Para um SaaS B2B europeu, a Diretiva NIS2 aplica-se frequentemente em paralelo com o DORA, e orquestrar os dois é o desafio operacional principal de 2026.

Perímetro alargado: dezoito setores e cadeia de fornecimento

Os anexos I e II da NIS2 enumeram 18 setores. O anexo I distingue os setores altamente críticos (energia, transportes, banca, infraestrutura do mercado financeiro, saúde, água potável, águas residuais, infraestrutura digital, gestão dos serviços informáticos B2B, administração pública, espaço), o anexo II os outros setores críticos (serviços postais e de correio, gestão de resíduos, fabricação, produção e distribuição de produtos químicos, produção e transformação de géneros alimentícios, prestadores de serviços digitais, investigação). A dimensão da entidade (≥ 50 trabalhadores e volume de negócios ≥ 10 milhões de euros para o estatuto «importante», limiares mais elevados para «essencial») determina se está abrangida pela NIS2.

O NIS2 Artigo 21 parágrafo 2 alínea d) impõe a gestão da segurança da cadeia de fornecimento, incluindo os aspetos de segurança relativos às relações diretas entre prestadores e fornecedores. Uma status page mal explorada por um prestador pode acarretar a responsabilidade do operador essencial ou importante cliente.

Alerta precoce 24 h, notificação 72 h, relatório final 1 mês

O Artigo 23 organiza a notificação em três tempos:

• Alerta precoce nas 24 horas seguintes ao conhecimento de um incidente significativo.
• Notificação de incidente nas 72 horas seguintes ao conhecimento, incluindo uma avaliação inicial, indicadores de compromisso e uma descrição da gravidade.
• Relatório final no mês seguinte à notificação, com análise causal detalhada.

O ponto de partida crítico: «conhecimento» (awareness), não «deteção» técnica nem «classificação» formal. Assim que uma equipa interna toma consciência de um incidente significativo, o contador arranca. Um incidente é «significativo» se causou ou for suscetível de causar uma perturbação grave dos serviços, perdas financeiras importantes, ou se afetou ou for suscetível de afetar terceiros causando danos materiais ou imateriais consideráveis.

Transposições nacionais na primavera de 2026

O ponto da situação a 1 de abril de 2026:

• França: Lei Resiliência adotada pela Assembleia Nacional a 26 de fevereiro de 2025, promulgação esperada no primeiro semestre de 2026. A ANSSI opera o portal MonEspaceNIS2 e coordena o CERT-FR como CSIRT nacional. Período de adequação: 3 anos após a promulgação. Para acompanhar a evolução do historial das observações, ver a rastreabilidade DNS publicada pela CaptainDNS em novembro de 2025.
• Alemanha: NIS2UmsuCG promulgado a 5 de dezembro de 2025, em vigor a 6 de dezembro de 2025. O BSI publicou os detalhes operacionais: cerca de 30 000 entidades abrangidas, registo obrigatório em 3 meses, sanções de nível «board accountability».
• Itália: decreto legislativo 138/2024 publicado a 4 de setembro de 2024, em vigor a 16 de outubro de 2024. A ACN (Agenzia per la Cybersicurezza Nazionale) opera o portal de notificação, completado pelo DPCM 221 de 9 de dezembro de 2024.
• Portugal, Luxemburgo, Países Baixos, Bélgica, Espanha, Polónia, países nórdicos, países bálticos: transposição efetiva ou iminente (processo parlamentar em curso). Em Portugal, o CNCS (Centro Nacional de Cibersegurança) assume o papel de CSIRT nacional para as notificações NIS2.
• Cinco Estados em atraso a 1 de abril de 2026: risco de processos por infração ao abrigo do Artigo 258 TFUE.

Diferença entre a diretiva e o regulamento de proteção de dados

A NIS2 e o RGPD sobrepõem-se parcialmente. Um incidente pode ser simultaneamente um «incidente significativo» NIS2 e uma «violação de dados pessoais» RGPD. As notificações são então paralelas: CSIRT nacional para a NIS2, autoridade de proteção de dados (CNPD em Portugal, CNIL em França) para o RGPD. O prazo do RGPD Artigo 33 é de 72 horas «após dele ter tido conhecimento». A NIS2 acrescenta um alerta precoce a 24 horas, o que cria uma obrigação suplementar. Para um editor que opera um serviço de armazenamento SaaS que sofre uma intrusão envolvendo dados pessoais, três canais de reporte podem ser desencadeados (NIS2 + RGPD + DORA se o cliente for financeiro), daí a importância de uma fonte única com selo temporal, que é precisamente a status page pública.

A reter: ao abrigo da NIS2, o contador de 24 h arranca a partir do conhecimento interno, não após a classificação formal. Prepare as suas equipas para publicar uma mensagem pública nas 4 primeiras horas para não ter de fazer tudo na 23.ª hora.

Cartografia unificada das três regulamentações europeias

A complexidade operacional nasce do cruzamento entre as três regulamentações. Para um editor que presta serviço simultaneamente a entidades financeiras e a operadores essenciais NIS2, um mesmo incidente pode desencadear três canais de notificação, com prazos e destinatários diferentes. A status page desempenha então o papel de denominador comum com selo temporal.

Tabela cruzada dos prazos

Regulamentação	Facto gerador	Prazo inicial	Intermédio	Final	Autoridade destinatária	Sanção máxima
DORA Artigo 19	Incidente TIC classificado como grave (Art. 17-18)	4 h após classificação (24 h máx. após deteção)	72 h após deteção	1 mês após deteção	ACPR (FR) / BaFin (DE) / CSSF (LU) / Banca d'Italia (IT) / Banco de Portugal (PT)	2 % VN mundial ou 10 M€ (entidade) / 1 % VN diário médio 6 meses (CTPP)
NIS2 Artigo 23	Incidente significativo	24 h alerta precoce	72 h notificação	1 mês relatório final	CSIRT nacional (CERT-FR / BSI / ACN / CNCS / etc.)	10 M€ ou 2 % VN mundial (essencial) / 7 M€ ou 1,4 % VN mundial (importante)
RGPD Artigo 33	Violação de dados pessoais	72 h após o conhecimento	n/d	(conforme investigação CNPD/CNIL)	CNPD (PT), CNIL (FR) ou equivalente nacional	20 M€ ou 4 % VN mundial

Facto gerador: quem arranca quando

Três pontos de partida distintos coabitam. O DORA parte da classificação como incidente grave (formal, documentada, datada). A NIS2 parte do conhecimento interno de um incidente significativo. O RGPD parte da tomada de conhecimento de uma violação. O prazo operacional mais curto é de 4 horas (DORA), mas inicia-se tarde (após classificação). O mais precoce é o alerta precoce NIS2 a 24 h, que pode iniciar-se várias horas antes da classificação DORA.

Para as equipas ops, isto significa que um único incidente pode estar simultaneamente em avanço NIS2 e em atraso DORA, daí a necessidade de um registo comum e de um mecanismo de classificação rápida. Do lado da supervisão, a ferramenta monitor de uptime HTTP multirregional fornece o selo temporal técnico objetivo no qual se apoia a classificação.

A quem notificar: o mapeamento completo por jurisdição

Para os SaaS B2B que operam em vários países europeus, eis a matriz de destinatários:

• França: ACPR (DORA), CERT-FR via MonEspaceNIS2 (NIS2), CNIL (RGPD).
• Alemanha: BaFin (DORA), BSI (NIS2), BfDI ou autoridade do Land (RGPD).
• Itália: Banca d'Italia (DORA, via portal dedicado), ACN (NIS2), Garante (RGPD).
• Luxemburgo: CSSF (DORA via eDesk), GovCERT-LU (NIS2), CNPD-LU (RGPD).
• Espanha: Banco de España e CNMV (DORA), INCIBE-CERT (NIS2), AEPD (RGPD).
• Países Baixos: DNB e AFM (DORA), NCSC-NL (NIS2), AP (RGPD).
• Portugal: Banco de Portugal, CMVM e ASF (DORA), CNCS via CSIRT nacional (NIS2), CNPD (RGPD).

A ideia de um ponto de entrada único europeu progride: o pacote Digital Omnibus apresentado pela Bird & Bird prevê uma harmonização a 18 meses pós-adoção. Em 2026, esta harmonização não é ainda efetiva: é preciso, portanto, pilotar manualmente as notificações múltiplas, e a status page continua a ser o único entregável coerente para todas as jurisdições.

---

Crie uma status page conforme com DORA e NIS2 hoje mesmo

---

A reter: quando 3 regulamentações se aplicam, a janela mais curta vence, frequentemente 4 h DORA. A status page pública com selo temporal serve as três em paralelo.

A status page como peça probatória: porque é que os auditores a pedem

Uma peça probatória no sentido jurídico combina três propriedades: selo temporal fiável, imutabilidade, acessibilidade pública verificável. Nenhum outro artefacto técnico de um SaaS B2B preenche os três critérios em simultâneo. Os logs internos não estão acessíveis publicamente. Os PDF post-mortem podem ser editados a posteriori. Os e-mails a clientes não têm selo temporal criptográfico. A status page pública preenche as três condições, desde que tenha sido concebida com esse espírito.

Três propriedades probatórias: selo temporal assinado, arquivo imutável, audiência pública

O selo temporal deve seguir o RFC 3339 no formato UTC. É o padrão reconhecido pelo conjunto das jurisdições europeias para as operações eletrónicas (eIDAS, eIDAS 2). O selo em hora local (CET, CEST, BST) é inaceitável porque é ambíguo nas mudanças de hora. O selo qualificado na aceção do RFC 3161, assinado por um Trust Service Provider qualificado, é ainda mais sólido juridicamente, mas continua a ser opcional na prática enquanto o selo UTC for coerente e verificável.

A imutabilidade assenta no audit trail: cada atualização de incidente deve ser versionada, nunca sobrescrita. Se corrigir uma mensagem às 14 h 17 UTC após uma publicação às 14 h 02 UTC, as duas versões devem permanecer acessíveis, com a menção «editado às 14 h 17». Esta disciplina editorial assemelha-se à prática dos meios de comunicação em linha sobre as correções factuais.

A acessibilidade pública é o que distingue a status page de um log interno. A página deve ser consultável sem autenticação, a partir de qualquer ponto da Internet. Isto impõe uma infraestrutura de alojamento distinta da aplicação principal: se a sua aplicação cair, a sua status page deve manter-se de pé. É uma exigência de arquitetura que se reforça com DNSSEC ativo no domínio status e HTTPS estrito.

Caso Cloudflare R2 de 21 de março de 2025: modelo de referência

A Cloudflare documentou publicamente um incidente no seu serviço R2 a 21 de março de 2025. A empresa publicou um post-mortem detalhado três dias após o incidente. O desenrolar é exemplar: anúncio na status page às 14 h 04 UTC (pouco depois do início da degradação), atualizações a cada 15 a 30 minutos, identificação da causa-raiz (problema de configuração do storage), resolução anunciada às 15 h 11 UTC, post-mortem completo a 24 de março com linha temporal detalhada, root cause, próximos passos corretivos. A status page serve aqui de pivot temporal: regista os compromissos operacionais com selo temporal, e o post-mortem posterior refere-se a ela explicitamente.

Para um editor SaaS B2B europeu, este modelo é diretamente transponível. Não exige ferramentas exóticas: exige uma disciplina editorial e um formato de exportação estruturado.

Quando o prestador de status page cai ele próprio em avaria

A OneUptime documentou um caso revelador: entre 2 e 23 de fevereiro de 2026, o módulo system metrics da Atlassian Statuspage permaneceu indisponível durante 21 dias consecutivos. A análise publicada pela OneUptime a 25 de fevereiro de 2026 sublinha o paradoxo: um prestador de status page que não consegue manter o SLA dos seus próprios componentes não pode servir de artefacto de auditoria para os seus clientes. O risco concentrado num único prestador torna-se uma vulnerabilidade contratual direta.

Balanço ACPR a oito meses: a tensão regulamentar face à realidade operacional

O balanço da ACPR de 15 de janeiro de 2026 assinala que os prazos de 4 horas são «ainda raramente respeitados». Esta constatação não é um cheque em branco: acompanha o anúncio da passagem ao modo de aplicação ativa. A mensagem implícita: o ano de 2026 marca a transição entre a tolerância e a sanção. Para as entidades que ainda não dispõem de uma status page conforme, o risco de sanção é concreto. No plano dos princípios de segurança TLS e cadeia de confiança, o rigor do selo temporal e da assinatura alinha-se com as mesmas exigências criptográficas.

A reter: apenas uma status page pública com selo temporal combina as três propriedades de uma prova oponível. Concebê-la como tal é hoje um investimento de retorno regulamentar muito elevado.

Anatomia de uma status page DORA-ready: dez atributos obrigatórios

Uma status page concebida como entregável de auditoria deve preencher dez requisitos técnicos. A lista abaixo sintetiza as expectativas cruzadas dos supervisores europeus (ACPR, BaFin, CSSF, Banca d'Italia, ACN) e as boas práticas operacionais dos editores mais maduros.

Atributo 1, identificação clara dos componentes e serviços. A granularidade deve descer ao nível produto/região. Uma etiqueta «API» é insuficiente; é preciso «API REST v3, região EU-West», «API REST v3, região US-East», «SFTP B2B», «Webhooks». Isto permite declarar um incidente parcial sem desencadear um pânico injustificado sobre o conjunto do serviço.

Atributo 2, selo temporal RFC 3339 UTC em todo o lado. Nenhuma data em hora local. Nenhuma data sem fuso horário. A conversão para hora local faz-se do lado do navegador. A coerência UTC garante a oponibilidade jurídica.

Atributo 3, gravidade codificada e estável. Quatro níveis no mínimo: operational, degraded performance, partial outage, major outage. As etiquetas devem ser estáveis ao longo do tempo (sem renomeação por marketing). O código numérico subjacente (por exemplo 0/1/2/3) deve transitar no fluxo JSON para permitir a automatização.

Atributo 4, ligação explícita para o incidente em curso e identificador estável. Cada incidente deve ter um identificador único, persistente após a resolução, acessível por URL canónico. Os reguladores pedem frequentemente: «Forneça-nos o URL exato da comunicação pública do incidente XYZ.»

Atributo 5, audit trail visível. Cada atualização deve ser versionada, datada e identificar o autor (pelo menos pelo papel ou identificador). As edições posteriores devem permanecer visíveis com a menção «editado a …».

Atributo 6, exportação estruturada JSON, RSS, Atom, ICS. O JSON serve para a extração automatizada para os relatórios reguladores. RSS e Atom servem a subscrição cliente (e o sourcing por ferramentas como StatusGator ou IsDown). ICS serve a manutenção planeada para as equipas clientes.

Atributo 7, independência de infraestrutura. A status page deve estar alojada fora do perímetro aplicacional supervisionado. Se a sua aplicação está em AWS Frankfurt, a sua status page não deve estar. Esta independência não é negociável: é o que distingue um entregável útil em caso de avaria grave de um placebo.

Atributo 8, versionamento das atualizações. Consequência direta do atributo 5: um sistema de armazenamento imutável tipo Write-Once-Read-Many (WORM) ou registo assinado garante que nenhuma reescrita retroativa é tecnicamente possível.

Atributo 9, notificações cross-canal. E-mail, webhook, RSS e SMS opcional. Os reguladores pedem frequentemente para serem subscritores durante os controlos: recusar um canal de subscrição não é equacionável.

Atributo 10, conservação de longa duração. O arquivo dos snapshots (JSON e HTML) deve cobrir no mínimo 6 anos para alinhar o DORA Artigos 5 a 14 (ICT risk framework, registo de incidentes) e as transposições nacionais NIS2. A França impõe 6 anos na Lei Resiliência adotada. As transposições italiana e alemã retêm um mínimo de 5 anos.

---

Aside: risco terceiro TIC e cláusulas contratuais DORA Artigos 28 e 30

O capítulo V do DORA enquadra as relações entre entidades financeiras e prestadores TIC. O Artigo 28 impõe a manutenção de um registo dos acordos contratuais TIC, a classificação das funções críticas ou importantes (CIFA), e a concentração do risco terceiro. O Artigo 30 enumera as cláusulas contratuais mínimas: descrição clara do serviço, níveis de serviço mensuráveis, localização dos dados, segurança da informação, acessibilidade e restituição dos dados, direito de auditoria, exit strategy.

Para um editor ou um cliente SaaS B2B europeu, estes dois artigos ditam um questionamento objetivo no momento de escolher um prestador de status page:

• Localização dos dados. O alojamento dos dados da status page (incidentes, comentários, metadados) está contratualmente garantido na Europa? Os subcontratados (CDN, backups, monitoring interno) estão todos localizados na Europa?
• Jurisdição do prestador. Um prestador cuja casa-mãe está nos Estados Unidos ativa o risco CLOUD Act (Clarifying Lawful Overseas Use of Data Act, 2018), que permite às autoridades americanas exigir dados armazenados por uma empresa sob jurisdição americana, independentemente do país de armazenamento físico. Isto não desqualifica automaticamente os prestadores em causa (Atlassian Statuspage, por exemplo), mas impõe SCC (Standard Contractual Clauses) RGPD reforçadas e um DPA explícito.
• Certificações. SOC 2 Type II e ISO 27001 são úteis mas não suficientes para o DORA, que exige uma auditabilidade específica ao setor financeiro. Peça explicitamente um Statement of Applicability incluindo a cláusula DORA Artigo 28.
• Registo dos subcontratados. Um prestador conforme com o DORA deve poder fornecer a lista atualizada dos seus subprocessadores com a sua localização e o seu papel. Recusa = sinal de alerta.
• Exit strategy testada. A capacidade de recuperar a totalidade do seu historial de status page em formato aberto (JSON, CSV) em menos de 72 horas deve ser contratualizada e testada anualmente. Uma exportação improvisada em caso de urgência não resiste a um auditor.

Os prestadores US (Atlassian Statuspage, StatusGator, alguns BetterStack consoante a jurisdição do contrato) coabitam com alternativas europeias (Instatus EU, CaptainDNS, OpenStatus em modo self-hosted). A escolha não se faz sobre as features ou o pricing, faz-se sobre o alinhamento com o DORA Artigos 28 e 30. Para o detalhe das cláusulas contratuais, consulte a síntese da Bird & Bird sobre as cláusulas contratuais DORA. Sobre a mesma lógica de alojamento europeu contratualizado, ver também o guia MTA-STS completo.

---

A reter: 10 atributos técnicos mais 1 questão jurídica de jurisdição formam a checklist de anatomia. Qualquer falha num atributo é um risco de auditoria, não um detalhe de produto.

Modelo de incident report: do JSON da status page ao relatório DORA

O objetivo de uma status page DORA-ready não é apenas comunicar publicamente. É também alimentar diretamente o relatório regulamentar confidencial, sem reintrodução manual de dados. O pivot entre os dois é um ficheiro JSON estruturado, derivado da status page e transposto para os modelos RTS/ITS JC 2024-33.

Correspondência campo a campo entre a exportação da status page e o modelo do regulador

O relatório inicial DORA exige nove campos mínimo. A tabela abaixo mostra a correspondência com uma exportação JSON status page:

• entity_id (status page) → campo «LEI» ou identificador nacional do relatório DORA.
• incident.uuid (status page) → campo «Reference number» do relatório.
• 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, duração, geografia, dados) → bloco «Estimated impact».
• incident.immediate_actions (tabela de medidas) → campo «Immediate measures taken».
• incident.contact (e-mail + telefone do contacto DORA) → campo «Reporting contact».

Exemplo JSON para um incidente DDoS classificado 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 extração e de transmissão

A industrialização do fluxo assenta em três blocos. Uma tarefa cron lê a status page a cada 5 minutos, serializa os incidentes em formato JSON, assina o ficheiro com uma assinatura destacada (PGP ou cosign). Uma segunda tarefa, desencadeada por um webhook aquando da classificação, prepara a versão regulador mapeando os campos sobre os XSD oficiais (XBRL para a BaFin, XML para a Banca d'Italia, JSON para a ACPR OneGate). Um terceiro bloco gere a transmissão através das API ou portais dedicados (OneGate API, eDesk CSSF, MVP BaFin), com retry em caso de indisponibilidade do portal.

Sobre a securização do transporte de e-mail das notificações complementares, o rigor das políticas MTA-STS alojadas inscreve-se na mesma lógica de prova criptográfica explorável em auditoria.

A reter: se a sua status page exporta este JSON, preenche o relatório DORA em 4 horas sem reintrodução. É a diferença entre cumprir o prazo e falhá-lo.

Metodologia prática em sete etapas (HowTo)

Para passar do conceito ao operacional, eis uma metodologia em sete etapas, aplicável em 90 dias para um SaaS B2B europeu que dispõe de uma equipa SRE de base.

Metodologia de adequação da status page ao DORA e NIS2

Sete etapas para tornar a sua status page oponível perante uma auditoria ACPR, BaFin, ACN ou CSSF em 90 dias.

1. Etapa 1: inventário dos serviços e classificação de criticidade

   Elaborar a lista exaustiva dos serviços expostos e associar a cada um uma criticidade na aceção do DORA (CIFA / não-CIFA) ou da NIS2 (essencial / importante / fora do âmbito). Documentar o critério escolhido e o método de classificação. Este inventário é o alicerce de todos os compromissos posteriores. Sem um inventário rigoroso, é impossível justificar ao regulador porque é que um subserviço não aparece na status page.

2. Etapa 2: escolha do prestador de status page segundo o DORA Artigos 28 e 30

   Avaliar cada candidato em cinco critérios objetivos: jurisdição do prestador, localização dos dados, subcontratados documentados, exit strategy contratualizada, audit trail técnico. Um prestador sem resposta escrita sobre estes cinco pontos deve ser afastado, independentemente das suas funcionalidades. A revisão contratual deve ser validada pela direção jurídica antes da assinatura.

3. Etapa 3: arquitetura multirregional e independência DNS

   Alojar a status page numa infraestrutura estritamente distinta do perímetro aplicacional. DNS separado (subdomínio status. dedicado, autoridade distinta), alojamento geograficamente separado. Ativar DNSSEC, HSTS e CAA no domínio status. A independência põe-se à prova: cortar artificialmente a aplicação principal em teste e verificar que a status page continua consultável. Sem teste, a independência não passa de uma declaração.

4. Etapa 4: templates de incidente para quatro níveis de gravidade

   Preparar quatro modelos de anúncio público: operational maintenance, degraded performance, partial outage, major outage. Cada modelo inclui os campos obrigatórios (timestamps UTC, gravidade, componentes afetados, medidas imediatas, ETA estimada). Os modelos devem ser validados pelo DPO, pela direção jurídica e pela direção de comunicação. Sem pré-validação, cada incidente exige uma revisão urgente que custa tempo precioso.

5. Etapa 5: pipeline de arquivo com selo temporal e selado

   Implementar um snapshot com selo temporal a cada 5 minutos (JSON + HTML) depositado num armazenamento imutável (S3 Object Lock em modo compliance, ou registo assinado local tipo sigstore). Conservação mínima 6 anos. A assinatura destacada do snapshot deve ser depositada separadamente para permitir a verificação de integridade por um terceiro.

6. Etapa 6: teste trimestral sob a forma de tabletop exercise

   Organizar a cada três meses um exercício tabletop simulando um incidente grave. O objetivo: validar que o prazo entre deteção e publicação pública se mantém inferior a 15 minutos, e que a classificação DORA é documentada em menos de 4 horas. O teste deve envolver SRE, comms, jurídico, DPO e um membro do COMEX. Um relatório escrito do tabletop faz parte das provas auditáveis.

7. Etapa 7: revisão anual alinhada com auditoria ACPR, BaFin, ACN, CSSF

   Organizar anualmente uma revisão formal (board level) que passe em revista os incidentes graves do ano, verifique a conformidade das notificações, valide as evoluções da status page e arbitre os investimentos do ano seguinte. Esta revisão é exigida pelo DORA Artigo 17 (governance e organização do ICT risk management). Sem registo escrito desta revisão, o auditor pode concluir por uma falha de governance, o que agrava qualquer sanção.

O encadeamento das etapas 1 a 4 prepara a infraestrutura; as etapas 5 e 6 trancam a prova e a resiliência; a etapa 7 institucionaliza a abordagem. Para as equipas que nunca pilotaram uma simulação, o investimento inicial parece elevado. É na realidade irrisório face ao risco de sanção. Sobre o rigor dos controlos HTTPS e HSTS associados ao domínio status, ver o guia HSTS preload.

A reter: sem drill trimestral de 4 horas, descobrirá em produção que o seu processo de notificação não aguenta. O drill custa meio dia. Uma notificação falhada custa 10 milhões de euros.

Perguntas frequentes

FAQ

O nosso SaaS é abrangido pelo DORA se prestarmos um serviço a um banco?

Sim, indiretamente. Os Artigos 28 e 30 do DORA impõem às entidades financeiras repercutir contratualmente as obrigações sobre os seus prestadores TIC, em particular os que suportam uma CIFA (Critical or Important Function Arrangement). Ficará, portanto, sujeito a cláusulas contratuais obrigatórias: localização dos dados, direitos de auditoria, exit strategy, níveis de serviço mensuráveis. Se for designado CTPP (Critical Third-Party Provider) pelas ESA, fica sob supervisão direta. A status page torna-se então um entregável contratual quantificado e oponível.

Qual é o prazo exato de uma notificação DORA inicial?

Quatro horas após a classificação do incidente como grave, com um limite máximo de 24 horas após a deteção. A classificação apoia-se no DORA Artigo 18 e nos critérios de materialidade (impacto clientes, duração, geografia, perda de dados, criticidade do serviço). O prazo arranca no momento do veredicto «incidente grave», não na deteção. O documento JC 2024-33 publicado em julho de 2024 pelas ESA enumera os nove campos obrigatórios do relatório inicial: identidade da entidade, selo temporal deteção, selo temporal classificação, descrição preliminar, critérios de classificação, impacto estimado, medidas imediatas, próximos passos, contacto dedicado.

Qual é a diferença operacional entre o DORA e a NIS2 para a nossa status page?

O DORA prevalece sobre o setor financeiro (bancos, seguradoras, fundos, prestadores de serviços de pagamento) e arranca o seu cronómetro 4 horas após a classificação. A NIS2 cobre 18 setores essenciais e importantes (energia, saúde, digital, transporte, alimentação, etc.) e arranca 24 horas após o conhecimento interno do incidente. Ambos convergem para 72 horas de notificação intermédia e 1 mês para o relatório final. Se estiver nos dois perímetros (raro mas possível), o DORA prevalece em razão do prazo mais curto. A status page serve as duas regulamentações com o mesmo artefacto com selo temporal, desde que o formato JSON exportado cubra os campos dos dois modelos.

A status page pode realmente servir de peça probatória em auditoria?

Uma página pública com selo temporal, arquivada e exportável em JSON, RSS ou Atom preenche as três propriedades de uma prova oponível: selo temporal RFC 3339 UTC, imutabilidade via audit trail visível, acessibilidade pública verificável. Nenhum PDF post-mortem nem log interno combina estes três critérios. Vários reguladores europeus (ACPR, BaFin) consideram agora a comunicação pública de incidente como parte integrante do dossiê de auditoria TIC, sem a nomear formalmente «prova», mas é regularmente convocada nos controlos documentais. A título comparativo, um selo temporal qualificado RFC 3161 por um Trust Service Provider traz um nível jurídico suplementar.

A nossa status page Atlassian Statuspage US é compatível com o DORA Artigo 28?

A questão não é de incompatibilidade absoluta, mas de gestão do risco terceiro TIC e de jurisdição. Um prestador de status page sob jurisdição americana ativa o CLOUD Act e exige SCC (Standard Contractual Clauses) e um DPA RGPD reforçados. Para se manter conforme com o DORA Artigos 28 a 30, exija ao prestador: localização europeia dos dados e dos logs, cláusulas de auditoria, exit strategy testada anualmente, certificações ISO 27001 e SOC 2 Type II, registo atualizado dos subcontratados. Se o seu serviço suporta uma CIFA, estas cláusulas são obrigatórias, não opcionais. Caso contrário, o seu cliente financeiro terá de arbitrar entre manutenção do contrato e risco regulamentar.

Quais são os 5 pilares do DORA?

O DORA assenta em cinco pilares estruturantes. Primeiro pilar: ICT risk management (Artigos 5 a 15), que impõe um quadro de governance e de gestão dos riscos TIC. Segundo pilar: ICT-related incident management, classification and reporting (Artigos 17 a 23), que inclui o Artigo 19 sobre o reporte. Terceiro pilar: digital operational resilience testing (Artigos 24 a 27), do qual fazem parte os TLPT (Threat-Led Penetration Testing) para as entidades significativas. Quarto pilar: management of ICT third-party risk (Artigos 28 a 44), que dita os contratos com os prestadores TIC, incluindo o prestador de status page. Quinto pilar: information sharing arrangements (Artigo 45). O pilar 2 impõe a status page como artefacto, o pilar 4 dita as suas condições contratuais.

Quem notificar em Portugal para um incidente DORA?

Em Portugal, a notificação DORA é dirigida à autoridade financeira competente segundo o setor: o Banco de Portugal para as instituições de crédito, instituições de pagamento e instituições de moeda eletrónica; a CMVM (Comissão do Mercado de Valores Mobiliários) para as empresas de investimento e gestoras de ativos; a ASF (Autoridade de Supervisão de Seguros e Fundos de Pensões) para as seguradoras, resseguradoras e fundos de pensões. Para um incidente NIS2, o CSIRT nacional designado é o CNCS (Centro Nacional de Cibersegurança) através do CERT.PT. Para um incidente RGPD envolvendo dados pessoais, a CNPD (Comissão Nacional de Proteção de Dados). Um mesmo incidente pode desencadear duas ou três vias paralelas, daí o interesse operacional crítico de um formato pivot tipo JSON status page explorado uma única vez e transposto para cada modelo regulador.

Durante quanto tempo devemos arquivar as nossas status pages?

Nenhum prazo está fixado explicitamente pelo DORA Artigo 19, mas a coerência com os Artigos 5 a 14 (ICT risk framework, registo de incidentes, audit trail) sugere um mínimo de 5 a 6 anos. O RGPD impõe poder demonstrar a sua conformidade na aceção do Artigo 5 parágrafo 2, sem prazo fixado. Os reguladores nacionais (ACPR, BaFin, Banco de Portugal) pedem tipicamente 5 anos de arquivos auditáveis. A Lei Resiliência francesa adotada em fevereiro de 2025 prevê 6 anos para a NIS2. Recomendação prudente: arquivar todos os snapshots status page (JSON e HTML) em armazenamento imutável tipo WORM ou registo assinado, durante 6 anos no mínimo, com procedimento documentado de restituição em 72 horas.

É preciso uma status page diferente por mercado UE (FR, DE, IT, PT)?

Não, uma única status page multilingue basta, desde que o conteúdo seja idêntico em substância de uma língua para outra. Os reguladores nacionais aceitam um entregável unificado desde que esteja acessível na língua da jurisdição em causa. Atenção, em contrapartida, aos fusos horários: utilize UTC como fonte única de verdade e mostre a conversão local do lado do navegador (client-side). Se o seu serviço opera ao abrigo de várias autoridades (ACPR + BaFin + CSSF + Banco de Portugal), mantenha um identificador de incidente estável e global, traduzido por mapeamento linguístico, nunca por historial separado. Uma duplicação de historial acarreta incoerências temporais muito expostas em auditoria.

O que acontece se falharmos um prazo de 4 h DORA?

Sanções administrativas até 2 % do volume de negócios anual mundial ou 10 milhões de euros (o mais elevado) para a entidade, e até 1 milhão de euros de coima individual para os responsáveis identificados. Para os CTPP: até 1 % do volume de negócios diário médio mundial, durante seis meses. Para além das coimas, consequências reputacionais via a publicação das sanções (Artigo 54). A ACPR, no seu balanço a 8 meses de janeiro de 2026, regista que estes prazos de 4 horas são «ainda raramente respeitados». 2026 marca o fim da tolerância e o início da aplicação ativa. Conservar uma marca pública exaustiva (status page com selo temporal) é hoje o melhor seguro contra uma requalificação desfavorável.

Checklist final: vinte e cinco pontos a validar antes da auditoria

Esta checklist sintetiza as exigências DORA, NIS2 e RGPD aplicáveis à status page de um SaaS B2B europeu. Está estruturada em três blocos: documental (7 pontos), técnico (10 pontos), organizacional (8 pontos). Validar 25 pontos sobre 25 não garante a ausência de sanção, mas coloca a entidade numa situação defensiva sólida face a um controlo da ACPR, BaFin, ACN, CSSF, Banca d'Italia ou Banco de Portugal.

Bloco documental (sete pontos)

1. Política de classificação dos incidentes escrita e assinada pela direção (matriz gravidade para reporte DORA e NIS2).
2. Procedimento de notificação DORA 4 horas documentado, validado pela direção jurídica, atualizado anualmente.
3. Procedimento de notificação NIS2 24 horas documentado, alinhado com o portal nacional (MonEspaceNIS2, BSI, ACN, CNCS).
4. DPA RGPD assinado com o prestador de status page, incluindo a lista dos subcontratados.
5. Registo dos prestadores TIC atualizado, conforme com o DORA Artigo 28 parágrafo 3.
6. Exit strategy do prestador de status page testada anualmente e documentada.
7. Plano de comunicação de crise validado pelo COMEX (papéis, mensagens-tipo, canais).

Bloco técnico (dez pontos)

1. Status page alojada fora da infraestrutura aplicacional, com prova de independência testada.
2. Selo temporal RFC 3339 UTC em todo o lado, sem exceção (interface, API, exportações).
3. Gravidade codificada em 4 níveis mínimo (operational, degraded, partial outage, major outage).
4. Exportação estruturada disponível em JSON, RSS e Atom, completada por ICS para a manutenção.
5. Audit trail visível em cada atualização, identificando o autor (papel mínimo).
6. Versionamento das atualizações de incidente, nunca sobrescrita retroativa.
7. Monitoring multirregional ativo em pelo menos 4 zonas (UE, US, APAC, UK).
8. Notificações cross-canal operacionais: e-mail, webhook, RSS, SMS opcional.
9. Arquivo imutável WORM ou registo assinado durante 6 anos no mínimo.
10. Segurança do domínio status: DNSSEC ativo, HTTPS estrito, HSTS, CAA, teste HSTS validado.

Bloco organizacional (oito pontos)

1. Papel «DORA Incident Notifier» designado por escrito, com backup (equivalente CSSF eDesk role).
2. Piquete 24/7 no canal status page, com rotação documentada e calendário anual.
3. Drill 4 horas trimestral sob a forma de tabletop exercise, seguido de um post-mortem do drill.
4. Mapeamento documentado das autoridades nacionais por jurisdição (ACPR / BaFin / ACN / CSSF / Banca d'Italia / Banco de Portugal + CSIRT NIS2 + CNIL/CNPD e equivalentes RGPD).
5. KPI «delay-to-publish» seguido em contínuo, com objetivo inferior a 15 minutos.
6. Comunicações cliente pré-redigidas por cenário, validadas pelo DPO e direção jurídica.
7. Formação anual das equipas SRE e comunicação sobre as obrigações DORA e NIS2.
8. Revisão anual COMEX e conselho de administração sobre os incidentes graves (DORA Artigo 17).

Para integrar esta checklist diretamente no seu backlog de auditoria, duas exportações operacionais estão disponíveis: descarregar a checklist em formato CSV (para importação Excel ou Google Sheets) ou em formato JSON (para ingestão num GRC, Jira ou Notion). Cada linha contém a categoria, o número, o ponto, a prioridade e o elemento probatório exigido para a defesa documental.

Baixe a checklist de implementação

Assistentes podem reutilizar a checklist através dos exports JSON ou CSV abaixo.

• Descarregar a checklist DORA/NIS2 (CSV)
• Descarregar a checklist DORA/NIS2 (JSON)

Glossário

• CIFA: Critical or Important Function Arrangement, função crítica ou importante na aceção do DORA Artigo 28.
• CTPP: Critical Third-Party Provider, prestador terceiro crítico designado pelas ESA e sujeito a supervisão direta.
• DORA: Digital Operational Resilience Act, Regulamento UE 2022/2554, em aplicação desde 17 de janeiro de 2025.
• NIS2: Network and Information Security Directive 2, Diretiva UE 2022/2555, a transpor para os direitos nacionais.
• ESA: European Supervisory Authorities, que reúne a EBA (bancos), a EIOPA (seguros) e a ESMA (mercados financeiros).
• CSIRT: Computer Security Incident Response Team, equipa nacional designada por cada Estado-Membro para a NIS2 (CERT-FR, BSI, ACN, CNCS, etc.).
• RTS / ITS: Regulatory Technical Standards e Implementing Technical Standards, publicados pelas ESA para precisar o DORA.
• WORM: Write Once Read Many, modo de armazenamento imutável que garante a ausência de reescrita.

Conclusão

O ano de 2026 consagra a viragem entre a fase de transição e a aplicação ativa das duas regulamentações europeias estruturantes para a resiliência operacional digital. Para um SaaS B2B europeu, a conformidade DORA e a conformidade NIS2 deixam de ser uma matéria documental: a status page pública passa a ser um entregável de auditoria, oponível perante um supervisor nacional, e não uma simples ferramenta de comunicação de marketing. Três prioridades emergem: alojar a status page numa infraestrutura independente, exportar um formato JSON pivot alinhado com o JC 2024-33, organizar um drill trimestral de 4 horas para validar a cadeia completa. Os editores que anteciparem esta transformação entre 2026 e 2027 transformarão uma obrigação regulamentar em vantagem comercial: um cliente financeiro ou um operador essencial preferirá sempre um prestador cuja status page possa servir diretamente o seu próprio relatório regulador, em vez de um prestador onde cada incidente exige uma reconstrução manual da prova. Para começar a industrializar esta abordagem, o alojamento de uma status page conforme constitui o ponto de entrada mais rápido.