NIS2 vs DORA: sobreposição de âmbito para agências WordPress em 2026

#NIS2 vs DORA: sobreposição de âmbito para agências WordPress em 2026

A Diretiva 2022/2555 (NIS2) e o Regulamento 2022/2554 (DORA) cobrem terreno semelhante, mas com mecânicas diferentes. A NIS2 é uma diretiva que cada Estado-Membro transpõe para o direito nacional. A DORA é um regulamento de aplicação direta. A NIS2 abrange um conjunto amplo de setores essenciais e importantes. A DORA é específica do setor financeiro. Onde se sobrepõem (a maior parte da gestão de risco, gestão de incidentes, cadeia de fornecimento), um percurso de evidência bem construído pode satisfazer ambas. Onde a DORA vai mais além (Registo de Informação, testes de penetração baseados em ameaças), a agência WordPress precisa de acrescentar as diferenças.

Este é um artigo de apoio dentro do pilar sobre NIS2 e DORA no WordPress, com referências cruzadas ao percurso de evidência do Anexo II, ao guia do artigo 28 da DORA, ao guia de campos do Registo de Informação e à linha temporal de notificação 24/72/30.

#Resumo

• A DORA é lex specialis para entidades financeiras; a NIS2 aplica-se nos restantes casos.
• Sobreposição: gestão de risco, gestão de incidentes, continuidade de negócio, cadeia de fornecimento, comunicação.
• Só DORA: esquema do Registo de Informação, TLPT para entidades críticas, cláusulas prescritivas para terceiros.
• Só NIS2: âmbito setorial mais amplo (energia, transportes, saúde, administração pública), variantes de transposição nacional.
• Regra prática: se algum cliente estiver sob a DORA, construa o percurso de evidência ao nível DORA e reduza para a NIS2.

#Como a própria NIS2 nomeia a DORA

O artigo 1(2) da NIS2 diz: onde atos legislativos setoriais da União exijam que entidades essenciais ou importantes geram riscos de cibersegurança ou notifiquem incidentes significativos, aplicam-se essas disposições setoriais. A DORA é um desses atos. Assim, uma entidade financeira no âmbito da DORA não cumpre em duplicado: cumpre a DORA, e as disposições equivalentes da NIS2 consideram-se cumpridas.

Aquilo que a DORA não aborda explicitamente (por exemplo, parte da responsabilidade do órgão de administração segundo a NIS2, formação, cooperação setorial entre CSIRT), continua a estar coberto pela base da NIS2.

Para uma agência WordPress isto significa: se o cliente é um banco, uma empresa de investimento, uma instituição de pagamento, uma seguradora, um gestor de ativos, um TPP ao abrigo da PSD2, domina a DORA. Construa sobre a DORA. Se o cliente é um hospital, um registo TLD, um distribuidor de energia, um operador postal, domina a NIS2. Construa sobre a NIS2.

#Árvore de decisão: NIS2, DORA, ou ambas?

A regra acima (“DORA para finanças, NIS2 para tudo o resto”) mantém-se nos casos óbvios. Falha nos casos que realmente ocupam uma tarde de definição de âmbito: uma fintech abaixo do limiar de entidade significativa, um grupo hospitalar com uma subsidiária de pagamentos, ou uma agência que nunca assinou nada com a palavra “NIS2” mas descobre uma cláusula de cadeia de fornecimento enterrada num anexo. O fluxograma abaixo é o percurso que utilizamos numa chamada de integração com um novo cliente, antes de começar qualquer revisão de contrato.

flowchart TD
    A["O cliente é uma entidade financeira nos termos do artigo 2 da DORA?"] -->|"Sim"| B["É um banco, empresa de investimento, instituição de pagamento, seguradora, gestor de ativos, ou TPP da PSD2?"]
    A -->|"Não"| C["O cliente está num setor do Anexo I ou II da NIS2: energia, transportes, saúde, água, infraestrutura digital, administração pública, serviços postais, resíduos, ou fabrico?"]
    B -->|"Sim"| D["DORA primária: construir Registo de Informação, preparação para TLPT, análise de risco de concentração"]
    B -->|"Não - abaixo do limiar ou isento"| C
    C -->|"Sim"| E["NIS2 primária: construir registo de risco do artigo 21, percurso de evidência do Anexo II, delta de transposição nacional"]
    C -->|"Não"| F["A agência é contratada por uma entidade que, por sua vez, está no âmbito, ou seja, é a agência um fornecedor TIC de terceiros?"]
    F -->|"Sim - cliente é âmbito DORA"| G["Incorporação pela cadeia de fornecimento nos termos do artigo 28 da DORA: cláusulas contratuais do cliente transferem obrigações de nível DORA"]
    F -->|"Sim - cliente é âmbito NIS2"| H["Incorporação pela cadeia de fornecimento nos termos do artigo 21(2)(d) da NIS2: cláusulas contratuais do cliente transferem obrigações de nível NIS2"]
    F -->|"Não"| I["Nenhum dos regimes se aplica direta ou indiretamente: monitorizar o crescimento do cliente e a reclassificação setorial anualmente"]
    D --> J["O grupo tem subsidiárias não financeiras que também utilizam a agência?"]
    E --> J
    J -->|"Sim"| K["Holding de regime misto: manter a evidência de nível DORA como teto e mapear as subsidiárias individualmente"]
    J -->|"Não"| L["Um percurso de evidência de um só nível é suficiente"]

Há duas ramificações onde as agências mais erram a resposta. Primeiro, a ramificação “Não - abaixo do limiar ou isento” que sai de B: um cliente pode ser uma entidade financeira nos termos do artigo 2 da DORA e ainda assim não ser um banco ou uma seguradora no sentido comum - os prestadores de serviços de financiamento colaborativo e algumas instituições de pagamento caem aqui, e não deixam de ser entidades DORA só por serem pequenas. Segundo, a ramificação F: uma agência sem qualquer cliente regulado no papel pode ainda ser arrastada para obrigações da DORA se um dos seus subcontratos de alojamento ou manutenção estiver por baixo da cadeia de fornecimento de uma entidade regulada, vários níveis mais abaixo.

#Matriz de aplicabilidade

Seis arquétipos de cliente que uma agência provavelmente vai encontrar, mapeados face ao regime primário, à forma como a obrigação chega à agência, e ao nível de percurso de evidência com que essa chamada de definição de âmbito deveria terminar.

O padrão que mais surpreende novas chamadas de definição de âmbito: a partir do momento em que uma relação com um cliente em qualquer parte da carteira de uma agência é âmbito DORA, é operacionalmente mais económico construir cada percurso de evidência ao nível DORA e reduzir para clientes só-NIS2 do que manter dois sistemas de documentação em paralelo.

#Dois casos de definição de âmbito anonimizados

Os detalhes seguintes estão compostos e despidos de dados identificativos; nenhum nome de cliente aparece nesta secção.

Caso A: cooperativa de crédito regional. Uma cooperativa de crédito com cerca de 40 agências numa única região subcontratou o seu site institucional e uma intranet interna para os colaboradores, ambos baseados em WordPress, a uma agência externa. A cooperativa é uma entidade financeira nos termos do artigo 2 da DORA sem qualquer ressalva - a estrutura “cooperativa” não altera isso. A chamada de definição de âmbito confirmou que a agência tinha de constar no Registo de Informação da cooperativa como fornecedor de serviços TIC de terceiros, concretamente nas tabelas B.02.01 (acordos contratuais) e B.05.01 (funções suportadas), apesar de a dimensão da cooperativa a manter abaixo do limiar de testes de penetração avançados baseados em ameaças. A agência teve ainda de responder à questão de risco de concentração do artigo 29 - “quem mais poderia assumir o alojamento e a manutenção em oito semanas” - porque a responsável de compliance da cooperativa precisava dessa resposta por escrito independentemente do estatuto TLPT. A estrutura de pastas do percurso de evidência resultante refletia a disposição 05_dora_register/ descrita mais adiante neste artigo, preenchida desde o primeiro dia do contrato em vez de recuperada apenas antes de uma auditoria.

Caso B: grupo hospitalar municipal. Um grupo de hospitais municipais que gere um portal de informação para pacientes partilhado e uma intranet para os colaboradores, ambos baseados em WordPress, contratou a mesma abordagem de percurso de evidência, mas caiu no lado oposto da árvore. Os hospitais estão no Anexo I da NIS2 (setor da saúde) e o grupo não tinha qualquer estatuto de entidade financeira em nenhuma parte da sua estrutura, pelo que a DORA nunca entrou em jogo. Não foi construído qualquer esquema de Registo de Informação - teria sido esforço desperdiçado, uma vez que o formato RoI de quinze tabelas é um requisito específico da DORA sem equivalente na NIS2. Em vez disso, a agência construiu um registo de fornecedores mais simples, mais um questionário de due diligence e uma cláusula de SLA de notificação de incidentes ligada à transposição nacional da NIS2 do hospital (que fixou os seus próprios prazos de notificação e autoridade competente, distintos do ritmo de 24h/72h/1 mês utilizado noutras partes deste pilar). A lição prática ao comparar os dois casos: o cliente em âmbito DORA custou aproximadamente o dobro do esforço de documentação inicial em comparação com o cliente em âmbito NIS2, quase inteiramente devido ao esquema do Registo de Informação, e essa diferença de custo é o melhor preditor de que nível de percurso de evidência orçamentar para um novo contrato.

#O que se sobrepõe

Cinco grandes áreas de sobreposição onde um único artefacto serve ambos os regimes:

Gestão de risco. O artigo 21 da NIS2 enumera dez medidas; os artigos 5 a 15 da DORA cobrem o mesmo terreno conceptual com mais detalhe. Um registo de risco que nomeie ativos, ameaças, probabilidade, impacto e tratamento satisfaz ambos. O nível de detalhe difere: a DORA espera mais granularidade para funções críticas ou importantes; a NIS2 espera proporcionalidade.

Gestão de incidentes. Os artigos 22-23 da NIS2 e os artigos 17-23 da DORA exigem ambos classificação, resposta, recuperação, pós-morte e comunicação. Os prazos de notificação diferem ligeiramente (NIS2: alerta antecipado 24h, notificação 72h, relatório final 1 mês; DORA: semelhante, com modelos setoriais). O manual interno de resposta a incidentes pode ser partilhado.

Continuidade de negócio. O artigo 21(2)(c) da NIS2 e o artigo 11 da DORA exigem ambos cópia de segurança, restauro testado, fora do local, com RPO e RTO documentados. Um plano de continuidade e recuperação com um registo anual de simulações de restauro satisfaz ambos.

Controlos da cadeia de fornecimento. O artigo 21(2)(d) da NIS2 e o artigo 28 da DORA exigem ambos registo de fornecedores, due diligence, cláusulas contratuais, plano de saída. O Registo de Informação da DORA é um esquema mais rigoroso; construir para a DORA dá conformidade da cadeia de fornecimento da NIS2 de forma gratuita.

Comunicação. Ambas exigem comunicação à autoridade competente. A NIS2 designa o CSIRT nacional e a autoridade competente; a DORA comunica ao regulador financeiro (nacional mais as autoridades europeias de supervisão). A preparação interna da evidência é a mesma; o destinatário é diferente.

#O que a DORA acrescenta

Três diferenças onde a DORA vai mais além da NIS2 e a agência WordPress tem de acrescentar evidência específica:

Esquema do Registo de Informação. O Regulamento de Execução 2024/2956 da Comissão especifica quinze tabelas com colunas nomeadas. Detalhado no guia de campos do Registo de Informação. A NIS2 não tem equivalente; a agência sob obrigações apenas-NIS2 não precisa deste esquema.

Testes de penetração baseados em ameaças. O artigo 26 da DORA exige TLPT avançado para entidades financeiras classificadas como significativas. A agência que opera infraestrutura crítica para uma entidade deste tipo pode estar no âmbito como sistema testado. A NIS2 menciona a gestão de vulnerabilidades de forma ampla, mas não o TLPT.

Risco de concentração e substituibilidade. O artigo 29 da DORA exige uma análise explícita de concentração: quantas funções críticas este terceiro suporta, e com que facilidade pode ser substituído. A agência tem de conseguir responder “quem mais poderia fazer este trabalho em oito semanas se desaparecêssemos”. A NIS2 não tem uma exigência prescritiva comparável.

#O que a NIS2 acrescenta

Duas diferenças onde a NIS2 vai mais além do que a DORA em contextos não financeiros:

Amplitude setorial. Hospitais, ISP, operadores de telecomunicações, serviços postais, produção alimentar, administração pública, organizações de investigação estão na NIS2. A maioria não está na DORA. A agência que trabalha nestes setores de clientes mantém um percurso conforme à NIS2 por setor.

Variantes de transposição nacional. Como a NIS2 é uma diretiva, cada Estado-Membro implementa os detalhes com um toque local. A implementação alemã (KRITIS-DachG / NIS2UmsuCG) difere da polaca (KSC), que por sua vez difere da norueguesa. A agência que opera de forma transfronteiriça mantém um pequeno documento de diferenças por jurisdição.

#Um percurso de evidência, ambos os regimes

Uma disposição prática do percurso de evidência que cobre ambos:

• 00_governance/ - registo de risco, aprovação do órgão de administração, ritmo de revisão.
• 01_gestao_risco/ - mapeamento do artigo 21 / artigo 5, controlos, ficheiros de evidência.
• 02_resposta_incidentes/ - manual, simulações de mesa, análises pós-incidente, modelos 24/72/30.
• 03_continuidade_negocio/ - política de cópias de segurança, registos de testes de restauro, plano de continuidade.
• 04_cadeia_fornecimento/ - registo de fornecedores, lista de subcontratados, ficheiros de due diligence.
• 05_dora_register/ - entradas do Registo de Informação (15 tabelas) para clientes DORA.
• 06_comunicacao/ - relatórios anteriores, registo de destinatários, registo de prazos.
• 07_jurisdicoes/ - diferenças de transposição da NIS2 por Estado-Membro.
• 08_tlpt/ - para entidades DORA significativas, relatórios de TLPT e correção.

Construa-o uma vez, itere trimestralmente, e a próxima revisão de fornecedores demora horas, não semanas.

#Referências cruzadas

• NIS2 Anexo II para agências WordPress: percurso de evidência
• DORA artigo 28: risco de terceiros TIC para WordPress
• Registo de Informação da DORA para fornecedores WordPress: campos obrigatórios
• Linha temporal de notificação de incidentes NIS2 24h/72h/1M
• Pilar sobre NIS2 e DORA no WordPress
• Auditoria de conformidade da UE para WordPress