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 para uma entidade regulada que inclua um componente comercial fica sob os três ao mesmo tempo. A boa notícia: um único pacote de provas pode cumprir os três, 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 playbook de incidentes de 24 horas e o texto sobre acessibilidade BFSG e EAA.

#O que é, em resumo, o conjunto de requisitos CRA, NIS2 e DORA?

• O CRA é regulação de produtos. A NIS2 é regulação de entidades. A DORA é regulação de entidades financeiras.
• O WordPress headless para entidades reguladas pode ficar sob os três.
• 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 2026, obrigações completas dos fabricantes a partir de 2027.
• NIS2 a partir do prazo de transposição de 2024-10-17; DORA de aplicação direta desde 2025-01-17.

#Como é que 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 é 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 é vendida ou licenciada a uma entidade financeira. O próprio WordPress, enquanto software livre de código aberto lançado por uma comunidade, não está no âmbito do CRA segundo o considerando 15 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. Tanto o artigo 21.º, n.º 2, alínea d), da NIS2 como o artigo 28.º, n.º 2, da DORA exigem que esta cadeia seja inventariada, classificada e controlada por contrato.

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: cibersegurança desde a conceção e por defeito, gestão de vulnerabilidades durante o período de suporte, atualizações de segurança, lista de materiais de software (SBOM), notificação de vulnerabilidades ativamente exploradas à ENISA no prazo de 24 horas após o conhecimento e notificação de incidentes graves no prazo de 24 horas após o conhecimento.

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

• Obrigações de notificação de vulnerabilidades e incidentes a partir de 2026.
• Obrigações completas dos fabricantes a partir de 2027 (36 meses após a entrada em vigor).
• Os requisitos de avaliação da conformidade para produtos com elementos digitais “importantes” e “críticos” têm percursos próprios.

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. O artigo 23.º fixa o alerta precoce em 24 horas, a notificação em 72 horas e o relatório final ao fim de um mês. O artigo 21.º, n.º 2, alínea d), traz os fornecedores para o âmbito através de obrigações contratuais.

O prazo de transposição terminou a 2024-10-17. 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. O artigo 28.º trata da gestão do risco de terceiros no domínio das TIC. Os artigos 16.º a 19.º cobrem o ciclo de vida da gestão de incidentes de TIC. 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.

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

Um projeto WordPress headless para uma entidade financeira que inclua um bundle de frontend comercial depara-se com as seguintes sobreposições:

Oito controlos sobrepostos. Um pacote de provas com oito pastas, cada uma com referências cruzadas aos três regulamentos, 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. Gerado com npm audit signatures mais um gerador CycloneDX. A SBOM é um entregável do artigo 13.º do CRA; na NIS2 e na DORA serve a gestão de vulnerabilidades.
• SBOM do backend WordPress. Inventário de plugins e temas com versão e licença. Plugin checker do WordPress.org mais 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. Os produtos com elementos digitais “importantes” e “críticos” precisam de uma avaliação da conformidade por terceiros nos termos do Anexo VII do CRA. 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.

TLPT ao abrigo do artigo 26.º da DORA. Os testes de intrusão baseados em ameaças para entidades financeiras significativas designadas 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 equipas de análise conjunta do artigo 31.º. O CRA tem autoridades de fiscalização do mercado do Anexo VIII. Três canais de supervisão diferentes continuam a exigir processos de comunicação separados.

#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 do CRA à medida que a ENISA os publica ao longo 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