Cyber Resilience Act + NIS2 + DORA: a conformidade em 2026 para WordPress headless

#Cyber Resilience Act + NIS2 + DORA: a conformidade em 2026 para WordPress headless

Entre 2024 e 2026, três atos da UE convergiram na mesma substância operacional. O Cyber Resilience Act (Regulamento (UE) 2024/2847) regula produtos com elementos digitais disponibilizados no mercado da UE. A Diretiva NIS2 (2022/2555) regula entidades que prestam serviços essenciais ou importantes. O Regulamento DORA (2022/2554) regula as entidades financeiras e os prestadores terceiros de serviços de TIC de que dependem. Um projeto WordPress headless que entrega um componente comercial a um cliente regulado fica sob o CRA do lado do produto e sob a NIS2 ou a DORA do lado da entidade. Para uma entidade financeira, a DORA substitui as regras da NIS2 sobre gestão do risco e notificação, em vez de se somar a elas. A boa notícia: um único pacote de provas pode cobrir tudo isto, se for organizado por controlo e não por ato.

Este artigo fecha o pilar sobre NIS2 e DORA em WordPress e liga o rasto de provas do Anexo II, a auditoria de fornecedores do artigo 28.º da DORA, o plano de incidentes de 24 horas e o texto sobre acessibilidade BFSG e EAA.

#Conjunto de requisitos CRA, NIS2 e DORA em resumo

• O CRA é regulação de produtos. A NIS2 é regulação de entidades. A DORA é regulação de entidades financeiras.
• Um projeto WordPress headless pode ficar sob o CRA pelos seus componentes comerciais e sob a NIS2 ou a DORA pelo cliente que o explora.
• Para as entidades financeiras, a DORA aplica-se em vez dos artigos 21.º e 23.º da NIS2 (artigo 4.º e considerando 28 da NIS2).
• Um pacote de provas organizado por controlo é melhor do que três rastos documentais separados.
• Obrigações de notificação do CRA a partir de 11 de setembro de 2026, aplicação plena a partir de 11 de dezembro de 2027.
• NIS2 a partir do prazo de transposição de 2024-10-17; DORA de aplicação direta desde 2025-01-17.

#Como o WordPress headless afeta a conformidade com CRA, NIS2 e DORA

Um projeto WordPress headless separa duas camadas. A camada de conteúdo usa o WordPress como editor e fonte de verdade, expondo o conteúdo através da REST API ou de GraphQL. A camada de apresentação usa uma framework de frontend (Next.js, Astro, Nuxt, SvelteKit) que consome esse conteúdo e o apresenta aos utilizadores.

Para a conformidade, esta separação altera a superfície de risco de três formas.

O frontend pode ser um produto. Uma aplicação Next.js com bibliotecas comerciais, implementada por uma agência, pode ser um “produto com elementos digitais” ao abrigo do CRA quando é fornecida no âmbito de uma atividade comercial. O próprio WordPress, enquanto software livre de código aberto lançado por uma comunidade e não monetizado pelos seus autores, não está no âmbito do CRA (considerandos 15 e 18 do Regulamento (UE) 2024/2847); os pacotes comerciais construídos sobre ele podem estar.

A cadeia de fornecimento é mais larga. Os projetos headless trazem dependências npm (muitas vezes centenas), funções edge de CDN, serviços de otimização de imagens, fornecedores de pesquisa e sistemas de comentários. O artigo 21.º, n.º 2, alínea d), da NIS2 pede às entidades abrangidas que protejam a relação com os fornecedores diretos, e o artigo 28.º, n.º 3, da DORA exige às entidades financeiras um registo de informações sobre todos os acordos contratuais de serviços de TIC. Ambos conduzem a um inventário desta cadeia com controlo contratual.

A superfície de incidentes está dividida. Uma vulnerabilidade pode estar no backend WordPress, no bundle do frontend, numa função edge ou numa API de terceiros. O relógio de 24 horas da NIS2 e os prazos de notificação da DORA aplicam-se à entidade, seja qual for o sítio onde está o erro. O runbook da agência tem de detetar e triar incidentes nas quatro camadas.

#O que exigem o CRA, a NIS2 e a DORA

#CRA (Regulamento (UE) 2024/2847)

Abrange produtos com elementos digitais disponibilizados no mercado da UE. O artigo 13.º define as obrigações do fabricante: uma avaliação documentada dos riscos de cibersegurança (artigo 13.º, n.os 2 e 3), os requisitos essenciais da parte I do Anexo I, como a configuração segura por defeito, o tratamento de vulnerabilidades durante o período de suporte segundo a parte II do Anexo I, as atualizações de segurança e uma lista de materiais de software (SBOM, parte II, ponto 1, do Anexo I). O artigo 14.º acrescenta a notificação: as vulnerabilidades ativamente exploradas e os incidentes graves são notificados em simultâneo à CSIRT designada como coordenadora e à ENISA, através da plataforma única de notificação do artigo 16.º, com um alerta precoce no prazo de 24 horas após o conhecimento.

Calendário de aplicação segundo o artigo 71.º:

• Obrigações de notificação do artigo 14.º a partir de 11 de setembro de 2026.
• Capítulo IV sobre organismos notificados (artigos 35.º a 51.º) a partir de 11 de junho de 2026.
• Tudo o resto, incluindo as obrigações completas dos fabricantes, a partir de 11 de dezembro de 2027.
• Os requisitos de avaliação da conformidade para produtos com elementos digitais “importantes” e “críticos” têm percursos próprios (artigo 32.º).

O software de código aberto desenvolvido e fornecido sem atividade comercial fica fora do âmbito do CRA. Os considerandos distinguem entre contribuição não comercial para código aberto e empacotamento comercial. O núcleo do WordPress é código aberto não comercial; uma oferta de WordPress gerido vendida como produto, com plugins premium agregados sob uma única licença, pode entrar no âmbito do CRA.

#NIS2 (Diretiva 2022/2555)

Abrange entidades (essenciais e importantes) enumeradas nos Anexos I e II. O artigo 21.º, n.º 2, enumera dez medidas de gestão do risco, alíneas a) a j) (em detalhe no artigo sobre o rasto de provas do Anexo II). O artigo 23.º, n.º 4, fixa o alerta precoce em 24 horas, a notificação em 72 horas e o relatório final ao fim de um mês (em detalhe no plano de resposta a incidentes em 24 horas). O artigo 21.º, n.º 2, alínea d), traz os fornecedores de forma indireta: a entidade tem de cobrir a segurança da cadeia de abastecimento, incluindo a relação com fornecedores diretos e prestadores de serviços, e o artigo 21.º, n.º 3, pede-lhe que tenha em conta as práticas de desenvolvimento seguro de cada fornecedor.

O prazo de transposição terminou a 2024-10-17 (artigo 41.º). Vários Estados-Membros atrasaram-se; verifique o estado nacional antes de qualquer auditoria final.

#DORA (Regulamento 2022/2554)

Abrange as entidades financeiras enumeradas no artigo 2.º e os prestadores terceiros críticos de serviços de TIC (CTPP) designados pelas Autoridades Europeias de Supervisão ao abrigo do artigo 31.º. Os artigos 28.º a 30.º tratam do risco de terceiros no domínio das TIC: os princípios gerais, o registo de informações e as estratégias de saída estão no artigo 28.º (em detalhe no artigo sobre a auditoria de fornecedores do artigo 28.º da DORA), e as cláusulas contratuais obrigatórias no artigo 30.º. Os artigos 17.º a 19.º cobrem o processo de gestão de incidentes relacionados com as TIC, a sua classificação e a notificação de incidentes graves. Os artigos 24.º a 27.º cobrem os testes de resiliência operacional digital, incluindo TLPT.

Aplica-se diretamente em toda a UE desde 2025-01-17 (artigo 64.º).

#Se a NIS2 continua a aplicar-se quando a DORA abrange uma entidade financeira

Não no que interessa aqui. O artigo 4.º, n.º 1, da NIS2 desliga as suas próprias disposições sobre gestão do risco, notificação e supervisão quando um ato jurídico setorial da União impõe requisitos de efeito pelo menos equivalente. O considerando 28 da NIS2 indica a DORA como esse ato para as entidades financeiras: as regras da DORA sobre gestão do risco de TIC, notificação de incidentes, testes de resiliência, partilha de informações e risco de terceiros aplicam-se em vez das da NIS2.

Para um projeto WordPress headless, isto divide os clientes em dois grupos:

• Um banco, uma seguradora, uma instituição de pagamento ou uma empresa de investimento trabalha sob a DORA. O pacote de provas remete para artigos da DORA, e as notificações de incidentes seguem para a autoridade financeira competente ao abrigo do artigo 19.º da DORA.
• Um hospital, uma empresa de energia, um organismo da administração pública ou outra entidade do Anexo I ou II trabalha sob a lei nacional que transpõe a NIS2. O pacote de provas remete para o artigo 21.º, n.º 2, e as notificações de incidentes seguem para a CSIRT ou a autoridade competente ao abrigo do artigo 23.º.

O CRA atravessa os dois grupos: se a agência entrega um produto comercial, as suas obrigações de fabricante aplicam-se seja qual for o regime do cliente. Por isso, a tabela de sobreposições mais abaixo tem uma coluna NIS2 e uma coluna DORA, mas um mesmo projeto só preenche uma delas.

#Quando a própria agência fica sob a NIS2

A NIS2 não chega só ao cliente. O Anexo I, ponto 9, inclui a “gestão de serviços TIC (entre empresas)”, que abrange os prestadores de serviços geridos e os prestadores de serviços de segurança geridos. O artigo 6.º, ponto 39, define o prestador de serviços geridos como a entidade que presta serviços relacionados com a instalação, gestão, operação ou manutenção de produtos, redes, infraestruturas ou aplicações de TIC, através de assistência ou administração ativa nas instalações do cliente ou à distância.

Uma agência que trata do alojamento, das atualizações e da monitorização das instalações WordPress dos seus clientes através de um contrato de manutenção encaixa nesta descrição. O teste de dimensão do artigo 2.º, n.º 1, decide se está abrangida: a diretiva aplica-se às entidades que são médias empresas segundo a Recomendação 2003/361/CE da Comissão ou que excedem esses limiares. Segundo o artigo 2.º dessa Recomendação, uma pequena empresa tem menos de 50 trabalhadores e volume de negócios ou balanço até 10 milhões de euros, pelo que uma agência com 50 ou mais trabalhadores e uma linha de alojamento gerido é o caso a verificar. Se estiver abrangida, precisa das suas próprias medidas do artigo 21.º e da sua própria via de notificação do artigo 23.º, separadas das dos clientes.

#Se um site em WordPress headless é um produto ao abrigo do CRA

Normalmente não, e o regulamento di-lo expressamente. O considerando 12 do CRA estabelece que os sítios web que não apoiam a funcionalidade de um produto com elementos digitais ficam fora do seu âmbito, e que os serviços de computação em nuvem como SaaS, PaaS e IaaS ficam antes abrangidos pela NIS2. Um site de marketing ou uma frente de banca online sobre WordPress headless é um sítio web explorado como serviço, não um produto colocado no mercado.

O CRA entra por três portas mais estreitas:

• Um produto comercial vendido a muitos clientes. Um tema premium, um plugin pago ou um kit inicial de frontend licenciado, fornecido no âmbito de uma atividade comercial, é um produto com elementos digitais (artigo 3.º, ponto 1).
• Uma app com backend próprio. O artigo 3.º, ponto 2, e o considerando 11 tratam como parte do produto o “tratamento de dados à distância” concebido pelo fabricante ou sob a sua responsabilidade, sem o qual o produto não consegue desempenhar uma das suas funções. Quando uma app móvel depende de um endpoint REST próprio do WordPress, esse endpoint entra no âmbito do CRA da app.
• Componentes de código aberto dentro de um produto comercial. O artigo 13.º, n.º 5, exige aos fabricantes diligência devida ao integrar componentes de terceiros, incluindo os livres e de código aberto, e o artigo 13.º, n.º 6, obriga-os a comunicar uma vulnerabilidade encontrada num componente a quem o mantém.

Nenhum dos tipos de produto dos Anexos III (produtos importantes) e IV (produtos críticos) é um CMS, um tema ou um frontend web. Um produto WordPress típico usa, por isso, o procedimento de controlo interno (módulo A do Anexo VIII), sem organismo notificado.

#Como se comparam os prazos de notificação do CRA, da NIS2 e da DORA

Cada ato tem o seu próprio relógio, que começa num momento diferente:

Os prazos da DORA vêm do Regulamento Delegado (UE) 2025/301 da Comissão, não da própria DORA. Uma consequência prática para uma stack headless: a agência de frontend que é também fabricante ao abrigo do CRA pode dever a sua própria notificação de 24 horas à ENISA sobre a mesma vulnerabilidade que o banco notifica ao seu supervisor. As duas notificações devem remeter uma para a outra, e o runbook deve indicar quem apresenta cada uma.

#Onde se sobrepõem o CRA, a NIS2 e a DORA

Um projeto WordPress headless que inclua um bundle de frontend comercial depara-se com as seguintes sobreposições. A coluna NIS2 aplica-se a clientes fora do setor financeiro, a coluna DORA a entidades financeiras:

Oito controlos sobrepostos. Um pacote de provas com oito pastas, cada uma com referências cruzadas ao CRA e ao regime do cliente, cumpre todos.

#Como estruturar um pacote de provas conjunto para CRA, NIS2 e DORA

Organizo o pacote por área de controlo, não por regulamento. Cada pasta de controlo contém:

1. Política. Aprovada pelo órgão de administração da entidade. Com referências cruzadas aos artigos relevantes do CRA / NIS2 / DORA.
2. Responsável pelo processo. Função identificada na entidade, mais o contacto identificado da agência.
3. Provas de implementação. Logs, relatórios de auditoria, resultados de análises, resultados de testes, cláusulas contratuais.
4. Tabela de mapeamento. Três colunas: artigo do CRA, artigo da NIS2, artigo da DORA. Onde a política se enquadra em cada um.
5. Registo de revisão. Revisão anual ou mais frequente, datada e assinada.
6. Histórico de auditorias. Auditorias externas, testes de intrusão, pedidos do regulador, tudo datado e etiquetado.

O pacote conjunto evita o desperdício mais comum na conformidade com vários atos: escrever o mesmo registo de riscos três vezes para três reguladores. Um registo, três referências de artigos nos metadados.

#Que provas exige um projeto headless para CRA, NIS2 e DORA

Um projeto headless acrescenta artefactos de que um projeto WordPress monolítico não precisa:

• SBOM do bundle do frontend. Um ficheiro CycloneDX ou SPDX que lista cada dependência npm com versão e licença. A CLI do npm gera-o com npm sbom --sbom-format cyclonedx (ou spdx); npm audit signatures é uma verificação à parte, que valida as assinaturas do registo. A SBOM é um entregável da parte II do Anexo I do CRA; na NIS2 e na DORA serve a gestão de vulnerabilidades e o inventário de ativos.
• SBOM do backend WordPress. Inventário de plugins e temas com versão e licença. O WP-CLI exporta-o com wp plugin list --fields=name,version,update_version,wporg_status,wporg_last_updated --format=json e wp theme list --format=json; a licença consta do cabeçalho de cada plugin, a que se juntam ficheiros internos de bloqueio de versões.
• Inventário de funções edge. Cloudflare Workers, Netlify Functions, Vercel Edge. Cada função é uma peça da cadeia de fornecimento e uma peça da superfície de incidentes.
• Documentação do contrato da API. Esquema OpenAPI ou GraphQL da API headless, com definições de segurança, limites de pedidos e autenticação.
• Provas do pipeline de implementação do frontend. Logs de CI/CD, resultados de análise de contentores, provas de deteção de segredos, revisão de dependências em cada PR.
• Monitorização entre camadas. Um único dashboard ou runbook que correlaciona eventos do backend WordPress, da aplicação de frontend, da camada edge e das APIs de terceiros.

Para uma entidade regulada, este conjunto de artefactos é obrigatório. Para uma entidade não regulada, é boa prática, mas a conversa sobre orçamento fica mais apertada.

#O que não cobre um pacote conjunto para CRA, NIS2 e DORA

Há três áreas que um único pacote não cobre.

Avaliação da conformidade ao abrigo do CRA. Segundo o artigo 32.º, os produtos importantes da classe I que não aplicam normas harmonizadas, todos os produtos importantes da classe II e os produtos críticos precisam do exame UE de tipo ou da garantia de qualidade total do Anexo VIII, com intervenção de um organismo notificado, ou de um sistema europeu de certificação da cibersegurança quando exista. A NIS2 e a DORA não têm uma base equivalente de certificação por terceiros (o TLPT da DORA é o mais próximo). Planeie a avaliação da conformidade como uma frente de trabalho separada quando o produto entra no Anexo III ou IV.

TLPT ao abrigo do artigo 26.º da DORA. Os testes de intrusão baseados em ameaças para entidades financeiras designadas realizam-se pelo menos de três em três anos sobre sistemas de produção em funcionamento, e as normas técnicas que os concretizam seguem o quadro TIBER-EU. A NIS2 e o CRA não exigem testes com esta profundidade.

Supervisão setorial. A NIS2 tem autoridades competentes setoriais. A DORA tem as autoridades financeiras competentes do artigo 46.º e, para cada prestador terceiro crítico de serviços de TIC, uma autoridade fiscalizadora principal auxiliada por uma equipa de avaliação conjunta (artigo 40.º). O CRA tem autoridades de fiscalização do mercado ao abrigo do artigo 52.º. Três canais de supervisão diferentes continuam a exigir processos de comunicação separados.

#Que coimas fixam o CRA, a NIS2 e a DORA

Os tetos diferem porque os atos regulam partes diferentes:

• CRA, artigo 64.º. Incumprimento dos requisitos essenciais do Anexo I ou dos artigos 13.º e 14.º: até 15 milhões de euros ou 2,5 % do volume de negócios anual a nível mundial, consoante o que for mais elevado. Outras obrigações dos operadores económicos: até 10 milhões de euros ou 2 %. Informações incorretas ou enganosas a organismos notificados ou autoridades de fiscalização do mercado: até 5 milhões de euros ou 1 %.
• NIS2, artigo 34.º. Infração ao artigo 21.º ou 23.º: um máximo de pelo menos 10 milhões de euros ou 2 % para as entidades essenciais, e de pelo menos 7 milhões de euros ou 1,4 % para as entidades importantes. Os Estados-Membros podem ir mais longe.
• DORA, artigo 50.º. Os montantes ficam a cargo dos Estados-Membros, que têm de dar às autoridades competentes poderes sancionatórios. Perante os prestadores terceiros críticos de serviços de TIC, o artigo 35.º permite à autoridade fiscalizadora principal impor uma sanção pecuniária compulsória diária de até 1 % do volume de negócios diário médio a nível mundial, durante no máximo seis meses.

Para a agência, a linha do CRA é a que cai no seu próprio balanço, porque a agência é o fabricante. As coimas da NIS2 e da DORA recaem sobre o cliente, e é por isso que os clientes as empurram pela cadeia abaixo através de cláusulas contratuais.

#O que exigem o CRA, a NIS2 e a DORA às agências WordPress

Uma agência WordPress que queira entregar projetos headless a entidades reguladas em 2026 tem de:

1. Construir uma vez o modelo do pacote de provas conjunto e reutilizá-lo em todos os projetos.
2. Gerar SBOM como parte do pipeline de implementação, e não à posteriori.
3. Manter o registo de fornecedores atualizado como documento vivo.
4. Manter a prontidão de resposta a incidentes nas duas camadas (WordPress e frontend).
5. Acompanhar os atos de execução e delegados que a Comissão adota ao abrigo do CRA, e conhecer a plataforma única de notificação da ENISA antes de o artigo 14.º se aplicar a 11 de setembro de 2026.

O preço é individual; é o âmbito da conformidade que define a duração do projeto, não uma avença mensal fixa.

#Guias relacionados sobre CRA, NIS2 e DORA

• Pilar: NIS2 e DORA em WordPress: o que um site tem de cumprir em 2026
• NIS2 anexo II para agências WordPress: âmbito, prazos e trilho de evidências
• DORA artigo 28, risco de terceiros TIC: auditoria do fornecedor de alojamento e WAF
• WordPress e NIS2: plano de resposta a incidentes em 24 horas
• BFSG e EAA: o prazo alemão de 2025 para lojas WordPress