NIS2 e DORA em WordPress: o que um site tem de cumprir em 2026
Dois atos da UE definem em 2026 o que é exigido do lado da cibersegurança a um site WordPress que conduz uma atividade regulada na União: a Diretiva NIS2 (2022/2555) e o Regulamento DORA (2022/2554). Não são intercambiáveis. A NIS2 é uma diretiva com âmbito setorial alargado, transposta para o direito nacional. A DORA é um regulamento setorial (finanças) com aplicação direta. Ambos se aplicam a WordPress se e somente se a entidade que opera o site estiver no âmbito.
O artigo liga-se ao pillar de serviços headless WordPress, onde a camada técnica e descrita, e ao pillar sobre WCAG, BFSG e EAA, porque a conformidade de acessibilidade e a de cibersegurança aterram cada vez mais no mesmo pedido de aquisição.
TL;DR
- Prazo de transposição da NIS2: 2024-10-17. DORA aplica-se desde 2025-01-17.
- NIS2: 18 setores, divididos entre entidades essenciais e importantes.
- DORA: setor financeiro mais fornecedores críticos de TIC.
- Exigências: gestão de risco documentada, comunicação de incidentes (24/72/30), auditorias.
- O WordPress em si não está no âmbito; está a entidade que opera o site, se for regulada.
Três coisas a saber desde já
Primeiro, a NIS2 e a DORA aplicam-se à entidade, não à tecnologia. O WordPress não é “compliant” nem “non-compliant” enquanto CMS. Compliant ou não é a entidade que opera o site. Se um hospital, um banco, um fornecedor de cloud ou um operador de e-commerce acima do limiar estiver no âmbito, o seu site WordPress entra no âmbito como parte da infraestrutura da entidade.
Segundo, a transposição nacional da NIS2 está atrasada em vários Estados-Membros. O prazo de 2024-10-17 expirou, mas vários países encontravam-se em diferentes fases do processo legislativo após essa data. O estado da transposição varia entre os Estados-Membros; verifique a base de dados jurídica nacional relevante antes da auditoria final. Para o estado português, consulte o Diário da República; para o estado polaco, o projeto de alteração à lei sobre o sistema nacional de cibersegurança está publicamente disponível e o seu estado atual deve ser verificado em ISAP antes de qualquer auditoria final. O estado em 2026-04 exige análise jurídica separada; este artigo não substitui aconselhamento jurídico.
Terceiro, a DORA aplica-se diretamente. O regulamento não exige transposição. Se uma entidade financeira ou um fornecedor crítico de TIC operar um site WordPress, as obrigações da DORA aplicam-se desde 2025-01-17 independentemente do estado legislativo nacional.
NIS2: âmbito subjetivo
A Diretiva NIS2 lista 18 setores. Os casos mais comuns em que o WordPress entra no âmbito:
Entidades essenciais (essential entities):
- Energia (eletricidade, gás, petróleo, calor, hidrogénio).
- Transportes (aéreo, ferroviário, aquático, rodoviário).
- Banca.
- Infraestruturas dos mercados financeiros.
- Saúde (hospitais, laboratórios de referência, fabricantes de medicamentos, dispositivos médicos).
- Água potável e águas residuais.
- Infraestrutura digital (fornecedores de DNS, registos de domínio, fornecedores de cloud computing, prestadores de serviços de centro de dados, redes de distribuição de conteúdos, prestadores de serviços de confiança, fornecedores de redes públicas de comunicações eletrónicas).
- Gestão de serviços TIC (B2B).
- Administração pública (condições definidas no art. 2).
- Espaço.
Entidades importantes (important entities):
- Serviços postais e de correio expresso.
- Gestão de resíduos.
- Fabrico, transformação e distribuição de químicos.
- Fabrico, transformação e distribuição de alimentos.
- Fabrico nos setores: médico, informático e eletrónico, de máquinas, automóvel.
- Prestadores de serviços digitais (mercados em linha, motores de pesquisa, plataformas sociais).
- Organismos de investigação.
Limiar de base: empresa médía (50+ trabalhadores ou volume de negócios anual ou balanço superior a 10 milhões EUR). Microempresas e pequenas empresas estão geralmente fora do âmbito, com exceções (por exemplo prestadores de serviços de confiança, registos de TLD, alguns fornecedores de DNS).
A entidade essencial tem obrigações mais estritas. A entidade importante tem os mesmos requisitos técnicos mas com supervisão menos intensiva.
DORA: âmbito subjetivo
A DORA aplica-se a cerca de 20 tipos de entidade financeira:
- Instituições de crédito.
- Instituições de pagamento.
- Instituições de moeda eletrónica.
- Empresas de investimento.
- Prestadores de serviços de criptoativos.
- Centrais de valores mobiliários.
- Contrapartes centrais.
- Plataformas de negociação (bolsas).
- Repositórios de transações.
- Empresas de seguros e resseguros.
- Mediadores de seguros e resseguros.
- Instituições de realização de planos de pensões profissionais.
- Agências de notação de risco.
- Auditores que auditam contas de entidades abrangidas pela DORA.
- Administradores de índices de referência críticos.
- Fundos de investimento (OICVM, AIFM).
- Prestadores de serviços de financiamento colaborativo.
- Repositórios de titularização.
Mais os fornecedores críticos de TIC terceiros (Critical ICT Third-Party Providers, CTPP) designados pela supervisão europeia. É o mecanismo pelo qual a DORA puxa parceiros de negócio para o seu âmbito, sem que estes se registem como entidade financeira.
Um WordPress operado por um banco, segurador ou fundo de investimento entra no âmbito da DORA como parte dos sistemas de TIC da entidade.
O que tem de ser feito em concreto: o núcleo comum
A NIS2 e a DORA partilham um núcleo convergente de exigências técnicas e organizacionais. Implementação em WordPress:
Gestão do risco cibernético. Registo de risco documentado, procedimento para avaliação e aceitação do risco, políticas de segurança aprovadas pelo órgão de gestão. São documentos, não apenas configuração do servidor.
Controlo de acesso e autenticação. Autenticação multifator (MFA) obrigatória para administradores WordPress. Palavras-passe fortes obrigatórias. Expiração de sessão obrigatória. Todas as contas de administrador devem ser nominais, não partilhadas.
Gestão de incidentes. Procedimento para deteção, classificação e comunicação de incidentes. Um incidente significativo na NIS2 é um com impacto significativo na prestação do serviço. Comunicação ao CSIRT ou autoridade competente em 24 horas após a deteção (alerta inicial), 72 horas com avaliação inicial, um mês com relatório final.
Segurança da cadeia de fornecimento. Um plugin WordPress, alojamento, CDN, fornecedor de email transacional, fornecedor de SMS, fornecedor de IA. Cada um faz parte da cadeia. É necessário um registo, avaliações de risco e cláusulas contratuais.
Continuidade do negócio e recuperação após desastre. Backup, plano de continuidade, recuperação após desastre, testados regularmente, não apenas executados.
Formação do pessoal. Exigida a nível do órgão de gestão e da organização em geral. Uma “apresentação interna” não basta; é necessário um plano de formação documentado.
Segurança dos processos de desenvolvimento e manutenção. Políticas de desenvolvimento de software, testes e gestão de vulnerabilidades. O core do WordPress é atualizado; os plugins também o devem ser, com um processo de testes em staging antes da produção.
Criptografia. Uma política de criptografia, incluindo TLS, cifragem de dados em repouso, assinaturas digitais. O WordPress não cifra a base de dados por defeito; a solução é cifragem ao nível do sistema de ficheiros ou da base de dados.
Específico da DORA: gestão de terceiros TIC
A DORA tem uma secção no capítulo V dedicada à gestão de terceiros TIC. Exige:
- Um registo de todos os contratos com fornecedores TIC.
- Classificação dos contratos (críticos, não críticos).
- Cláusulas contratuais obrigatórias em contratos com fornecedores de funções críticas.
- Procedimento de cessação com plano de migração.
- Testes de penetração orientados por ameaças (TLPT) pelo menos uma vez de 3 em 3 anos para entidades selecionadas.
Para o operador WordPress isto significa que o fornecedor de alojamento e os plugins críticos (security plugin, backup plugin, payment gateway plugin) entram no registo TIC.
Específico da NIS2: sanções e supervisão
A Diretiva NIS2 estabelece sanções administrativas que as transposições nacionais traduzem em montantes concretos. Os limites superiores na própria diretiva:
- Entidade essencial: até 10 milhões EUR ou 2 por cento do volume de negócios anual a nível mundial, consoante o que for mais elevado.
- Entidade importante: até 7 milhões EUR ou 1,4 por cento do volume de negócios anual a nível mundial, consoante o que for mais elevado.
As transposições nacionais podem introduzir limites próprios; a verificar na versão em vigor da lei na jurisdição relevante.
Sanções complementares: suspensão temporária da certificação, proibições temporárias do exercício de funções de direção para a pessoa responsável. Esta e a alteração mais marcante da NIS2: o órgão de gestão tem responsabilidade pessoal pela gestão do risco cibernético.
O artigo 20.º da NIS2 estabelece-o diretamente: os órgãos de gestão devem aprovar as medidas de gestão do risco cibernético, supervisionar a sua implementação e participar em formação relevante. Em Portugal, a transposição da NIS2 é operacionalizada através do diploma que substitui o Decreto-Lei n.º 65/2021 (que transpunha a NIS1), com o Centro Nacional de Cibersegurança (CNCS) como autoridade competente. Na prática, a responsabilidade pessoal não recai apenas no conselho de administração, mas também na camada executiva que supervisiona operacionalmente as áreas no âmbito: diretor de TI, CISO, responsável de compliance, encarregado de proteção de dados e diretor de operações. Para uma agência WordPress isto muda quem assina o entregável do lado do cliente: o registo de riscos, o runbook de incidentes e o inventário de fornecedores têm de ser aprovados por essa camada e entregues em formato probatório que aguente uma inspeção do CNCS.
Mapa prático de implementação em WordPress
Quatro categorias de trabalho, uma auditorIA:
Camada 1, infraestrutura. Alojamento conforme. Backup off-site. TLS 1.3. WAF. Monitorização 24/7 ou contrato com SOC. Política de atualização do core, themes, plugins.
Camada 2, aplicação. MFA para administradores. Palavras-passe fortes. Registo de todas as ações administrativas num fluxo separado. Anti-CSRF. Anti-XSS ao nível dos templates. Validação de input. Limite de tentativas de login.
Camada 3, organização. Políticas de segurança. Registo de risco. Plano de IR. Plano de BCDR. Registo de fornecedores TIC. Procedimento de comunicação de incidentes ao CSIRT/regulador. Formação.
Camada 4, documentação e auditoria. Documentação de processos. Registos de auditoria. Auditoria externa ou interna periódica. Retenção com atenção aos requisitos do RGPD.
O WordPress como CMS cobre cerca de 30 por cento dos requisitos técnicos “out of the box”, após hardening e plugins cerca de 60 por cento. Os restantes 40 por cento são organização, documentação e procedimentos.
Triagem de âmbito: da entidade até à rota WordPress
Uma avaliação útil começa pela entidade e pelo serviço regulado, não por uma lista genérica de plugins. Registe a sociedade que presta o serviço, setor, dimensão, mercados, autoridade competente e fundamento usado para incluir ou excluir a operação. Quando a NIS2 estiver em causa, confirme a transposição nacional vigente e não trate o texto da diretiva como se fosse a única regra operacional. Para DORA, confirme o tipo de entidade financeira, as funções críticas ou importantes e os contratos TIC que suportam essas funções.
Depois faça o caminho inverso até WordPress. Que rotas participam na prestação do serviço? Que dados entram num formulário? Para onde seguem? Quem aloja, monitoriza, envia email, gere DNS, fornece CDN, autenticação, pagamentos e suporte? Inclua cron jobs, API, contas administrativas, ambientes de staging, cópias de segurança e ferramentas de deploy. Uma página institucional pode ter baixa criticidade, enquanto um formulário de incidente, uma área reservada ou uma integração de pagamento pode fazer parte de um processo essencial.
O resultado deve ser uma matriz de âmbito com serviço, ativo, dependência, proprietário, criticidade e justificação. Esta matriz não decide sozinha a aplicabilidade jurídica. Serve para tornar explícitas as premissas e impedir que uma auditoria técnica prometa mais do que examinou.
Mapear controlos a evidências verificáveis
“Temos MFA” é uma afirmação; uma configuração exportada, a lista de funções abrangidas, o procedimento de recuperação e um teste datado formam evidência. Para cada controlo, ligue requisito, risco, implementação, proprietário, frequência de teste e prova. Evite capturas de ecrã soltas sem data ou contexto, porque envelhecem depressa e são difíceis de rever.
No âmbito WordPress, o dossier pode incluir inventário de versões e componentes, política de atualização, aprovação de alterações, resultados de análise de vulnerabilidades, configuração de acessos privilegiados, registos de administração enviados para armazenamento separado, testes de restauro, diagrama de fluxos de dados e registo de exceções. A retenção de logs deve ser proporcional, documentada e alinhada com privacidade; recolher tudo indefinidamente não é sinónimo de melhor controlo.
Cada constatação precisa de passos de reprodução, impacto, ativo afetado, prioridade, responsável e critério de fecho. Quando vários sítios usam o mesmo pipeline ou plugin, trate a origem comum. O objetivo é produzir um trilho que outra pessoa consiga rever, e não um PDF que se torna obsoleto no dia da entrega.
Incidentes: preparar decisões antes do relógio começar
Os prazos formais tornam inútil um plano que só existe na cabeça do fornecedor. Defina quem recebe alertas, quem pode declarar um incidente, quem avalia significância, quem preserva evidências e quem comunica com a autoridade, clientes e direção. O operador técnico pode fornecer factos, mas a classificação regulatória e a notificação pertencem à entidade e aos responsáveis que ela designou.
O runbook WordPress deve abranger, pelo menos, conta administrativa comprometida, exploração de plugin, alteração não autorizada, fuga de dados por formulário, indisponibilidade prolongada, corrupção de base de dados e comprometimento de fornecedor. Para cada cenário indique sinais, ações imediatas, canais fora de banda, preservação de logs, decisão de isolamento, recuperação e critérios para voltar à produção.
Faça exercícios de mesa e testes técnicos separados. O exercício valida contactos, escalonamento e decisões; o teste de restauro prova que uma cópia pode realmente recuperar o serviço. Registe tempos, falhas e ações corretivas. Não espere por um incidente real para descobrir que as credenciais de emergência estão no mesmo sistema indisponível.
Fornecedores e plugins como controlos contratuais
O registo de fornecedores deve distinguir empresa contratada, serviço efetivo, subcontratantes conhecidos, localização, dados tratados, dependência operacional, termos de saída e evidências disponíveis. Um plugin gratuito também cria dependência técnica, mesmo quando não existe um contrato negociado. Nesse caso, documente o modelo de suporte, política de divulgação de vulnerabilidades, capacidade de substituição e risco aceite.
Para funções críticas ou importantes, avalie direitos de auditoria e acesso, notificação de incidentes, continuidade, segurança de subcontratação, portabilidade e assistência na saída. Nem todas as cláusulas se aplicam da mesma forma a todos os fornecedores. A equipa jurídica deve adaptar o contrato; a equipa WordPress fornece o inventário e explica a dependência técnica.
Teste a saída antes de precisar dela. Uma cópia de segurança alojada exclusivamente na conta do fornecedor não constitui um plano de migração independente. Documente como recuperar código, media, base de dados, DNS, segredos, configurações e histórico operacional, e quem tem autoridade para executar cada passo.
Aceitação, limitações e governação contínua
Defina critérios de aceitação por risco. Uma correção fecha quando foi aplicada no ambiente certo, testada, aprovada pelo proprietário e ligada a evidência. Para controlos contínuos, indique também frequência e gatilhos de repetição: nova versão principal, alteração de fornecedor, incidente, mudança de arquitetura ou prazo periódico.
A revisão final deve apresentar controlos implementados, lacunas abertas, riscos aceites, dependências e limitações da amostra. Um teste de segurança não prova conformidade integral; uma auditoria WordPress não avalia toda a organização; e nenhum relatório garante ausência futura de incidentes. Esta linguagem não enfraquece o trabalho. Torna a decisão defensável e ajuda a direção a perceber o que continua por fazer.
Depois da primeira entrega, mantenha inventário, patches, acessos, fornecedores, exercícios e evidências dentro do processo normal de mudança. A direção deve receber informação suficientemente curta para decidir e suficientemente concreta para questionar atrasos, exceções e risco residual.
Preparar um briefing escrito para a avaliação
Envie os países e entidades envolvidos, setor, serviço regulado, arquitetura, URLs, fornecedores críticos, integrações, ambientes, auditorias anteriores e prazo. Inclua incidentes conhecidos e alterações planeadas. Não envie segredos ou dados pessoais no primeiro contacto; basta indicar que tipo de evidência existe e como poderá ser disponibilizada de forma segura.
A nossa auditoria de conformidade UE para WordPress inclui uma frente NIS2/DORA para triagem, mapeamento de evidências, fornecedores e runbooks. A proposta delimita WordPress e integrações observadas, não oferece certificação jurídica genérica nem garantia contra incidentes. Um briefing escrito permite separar rapidamente decisões legais, correções técnicas e responsabilidades operacionais.
Para a frente
Consequências práticas para a escolha da equipa que opera WordPress: uma agência que opera o site para uma entidade abrangida pela NIS2 ou pela DORA entra ela própria na cadeia de fornecimento. O nosso modelo de entrega headless deixa explícitos jurisdição da UE e compliance como standard, porque é um filtro de aquisição em 2026.
Onde este artigo se encaixa
O artigo liga-se ao pillar de serviços headless WordPress (camada técnica), ao pillar sobre WCAG/BFSG/EAA (compliance de acessibilidade no mesmo scoreboard de aquisição), ao artigo sobre nearshore Polónia (jurisdição UE como valor para o comprador ocidental) e à auditoria prática de acessibilidade para a parte operacional.
