NIS2 anexo II para agências WordPress: âmbito, prazos e trilho de evidências
O artigo 21.º da Diretiva 2022/2555 é a disposição operacional que define como decorre uma auditoria. O anexo I e o anexo II definem quem tem de passar por ela. Este texto faz corresponder as dez medidas do artigo 21.º, n.º 2, a controlos concretos numa agência WordPress e aos ficheiros de evidência que espero quando um cliente regulado lança uma avaliação de fornecedores.
É um artigo de apoio ao pilar sobre NIS2 e DORA em WordPress, com ligação ao playbook de resposta a incidentes nas primeiras 24 horas.
TL;DR
- O artigo 21.º, n.º 2, enumera dez medidas de gestão de risco. Nenhuma é opcional.
- Anexo I = entidades essenciais. Anexo II = entidades importantes. As mesmas medidas, supervisão diferente.
- O auditor procura quatro artefactos por medida: política, responsável, registo de implementação, ritmo de revisão.
- As coimas do artigo 34.º aplicam-se à entidade, não ao fornecedor WordPress, mas as cláusulas da cadeia de abastecimento empurram as obrigações para baixo.
- Em cada contrato regulado mantenho uma pasta por cada alínea do artigo 21.º.
Que entidades estão abrangidas pelos anexos I e II da NIS2
O anexo I enumera as entidades essenciais: energia, transportes, banca, infraestruturas do mercado financeiro, saúde, água potável e águas residuais, infraestruturas digitais, gestão de serviços TIC (B2B), administração pública, espaço. O anexo II enumera as entidades importantes: serviços postais e de estafeta, gestão de resíduos, produtos químicos, alimentos, fabrico de dispositivos médicos, computadores e eletrónica, máquinas e veículos a motor, prestadores de serviços digitais, organizações de investigação.
Os dois anexos aplicam-se a entidades médias e maiores (50 ou mais trabalhadores, ou volume de negócios anual superior a 10 milhões de EUR, ou balanço total superior a 10 milhões de EUR). As microempresas e pequenas empresas ficam fora do âmbito direto, com as exceções do artigo 2.º, n.º 2: prestadores de serviços de confiança, registos de TLD, alguns prestadores de DNS, administração pública, fornecedores de redes públicas de comunicações eletrónicas.
Filtro prático para uma agência WordPress: hospital, banco, fábrica química, operador de centro de dados, registo de TLD, gestor de OICVM. Se o cliente for um destes, a delimitação do âmbito começa. Se o cliente for um hotel, uma startup SaaS ou um retalhista regional, a delimitação termina normalmente com “fora do âmbito, as boas práticas de segurança continuam a aplicar-se”.
Medidas do artigo 21.º da NIS2 numa agência WordPress
O texto da diretiva lê-se como dez alíneas, de a) a j). Cada alínea passa a ser uma pasta no meu repositório de projeto.
a) Políticas de análise dos riscos e de segurança dos sistemas de informação. Um registo de riscos assinado, com ativos, ameaças, probabilidade, impacto e tratamento. Para WordPress: servidor de produção, servidor de staging, conjunto de plugins, APIs externas (pagamentos, e-mail, analítica, IA), contas de administração, base de dados de conteúdos. Ameaças: RCE num plugin, credential stuffing, ransomware nas cópias de segurança, violação do RGPD através de uma exportação. Tratamento: calendário de atualizações, MFA, cópia de segurança cifrada fora do local, conjunto de regras WAF.
b) Tratamento de incidentes. Deteção, classificação, resposta, recuperação, balanço. Evidência: runbook de resposta a incidentes com responsáveis nomeados, ferramenta de monitorização que dispara alertas (Wordfence, Sucuri, IDS do alojamento, alertas da Cloudflare), canal de Slack ou PagerDuty, modelo de post-mortem.
c) Continuidade das atividades, como a gestão de cópias de segurança e a recuperação de desastres, e gestão de crises. Cópia de segurança com armazenamento fora do local, RPO e RTO definidos, reposição testada. Plano de comunicação de crise com uma pessoa para os meios de comunicação e outra para o regulador. Exercício anual de reposição com relatório.
d) Segurança da cadeia de abastecimento, incluindo aspetos de segurança relativos às relações entre cada entidade e os seus fornecedores ou prestadores de serviços diretos. É aqui que a agência WordPress aterra. A entidade regulada mantém um registo de fornecedores, classifica-os por criticidade, faz due diligence e inclui cláusulas de segurança nos contratos. O artigo 28.º do DORA aplica a mesma lógica, de forma mais rigorosa no setor financeiro.
e) Segurança na aquisição, desenvolvimento e manutenção de redes e sistemas de informação, incluindo o tratamento e a divulgação de vulnerabilidades. Um ciclo de desenvolvimento seguro documentado. Para WordPress: revisão de código dos plugins e temas próprios, análise de dependências (Snyk, Dependabot, Plugin Checker no WordPress.org), um endereço de e-mail para reportar vulnerabilidades, uma política de gestão de patches.
f) Políticas e procedimentos para avaliar a eficácia das medidas de gestão dos riscos de cibersegurança. Auditoria interna, externa ou teste de intrusão. Evidência: descrição do âmbito, relatório do teste, registo de ações corretivas, ata do reteste.
g) Práticas básicas de ciber-higiene e formação. Formação anual para todos os colaboradores, formação por função para administradores. Evidência: registo de formação com nomes, datas e conteúdos.
h) Políticas e procedimentos relativos à utilização de criptografia e, se for caso disso, de cifragem. TLS 1.3 na periferia, cifragem das cópias de segurança, cifragem em repouso das cópias da base de dados. Política de algoritmos de hash (sem MD5 nem SHA-1). Inventário de chaves criptográficas.
i) Segurança dos recursos humanos, políticas de controlo de acessos e gestão de ativos. Processo de entrada, mudança e saída de pessoas. Contas de administração nominais, sem credenciais partilhadas. Inventário de ativos que abrange todas as instalações WordPress, ambientes de staging, acessos a repositórios e acessos a consolas de alojamento. Revisão trimestral de permissões.
j) Utilização de autenticação multifator ou de soluções de autenticação contínua, comunicações de voz, vídeo e texto seguras e sistemas seguros de comunicação de emergência. MFA em cada login de administração WordPress, cada consola de alojamento, cada consola de CDN, cada repositório de código, cada caixa de e-mail. Sem exceções para “contas internas de confiança”.
Que evidências exige um auditor NIS2 para cada medida
Para cada uma das dez alíneas, espero quatro artefactos quando o auditor aparece:
| Artefacto | Aspeto | Significado |
|---|---|---|
| Documento de política | Aprovado pela administração, datado, com controlo de versões | O artigo 20.º exige aprovação e supervisão do órgão de administração |
| Responsável pelo processo | Função nomeada (CISO, diretor de engenharia, diretor da agência) | O auditor não aceita “a equipa” como responsável |
| Registo de implementação | Logs, capturas de ecrã, números de tickets, relatórios de análise, cláusulas contratuais | Demonstra que a política funciona de facto |
| Ritmo de revisão | Revisão anual ou trimestral, entrada no calendário, ata | Uma política na gaveta sem revisão é uma constatação de auditoria |
Mantenho esta tabela de quatro colunas para cada alínea do artigo 21.º, n.º 2. Dez alíneas, quarenta artefactos. É este o aspeto do dossiê de auditoria em 2026.
Prazos de notificação de incidentes do artigo 23.º da NIS2
O anexo II descreve o funcionamento normal. Quando ocorre um incidente, aplica-se o artigo 23.º:
- 24 horas após tomar conhecimento: alerta precoce ao CSIRT ou à autoridade competente.
- 72 horas após tomar conhecimento: notificação com avaliação inicial e indicadores de comprometimento.
- 1 mês após tomar conhecimento: relatório final com a causa principal e as ações corretivas tomadas.
- Relatório intercalar sempre que o regulador o solicite.
O playbook detalhado para as primeiras 24 horas está no artigo WordPress, resposta a incidentes ao abrigo da NIS2.
Coimas da NIS2 e responsabilidade da administração
O artigo 34.º fixa limites que as transposições nacionais não podem reduzir:
- Entidades essenciais: pelo menos 10 milhões de EUR ou 2 % do volume de negócios anual mundial total, consoante o valor mais elevado.
- Entidades importantes: pelo menos 7 milhões de EUR ou 1,4 % do volume de negócios anual mundial total, consoante o valor mais elevado.
O artigo 20.º, n.º 1, atribui a responsabilidade aos órgãos de administração, incluindo o dever de supervisionar a aplicação. O artigo 20.º, n.º 2, exige que os membros do órgão frequentem formação. As transposições nacionais podem acrescentar sanções pessoais contra a pessoa responsável; o estado da lei polaca sobre o sistema nacional de cibersegurança deve ser verificado no ISAP antes da auditoria.
Como delimitar os serviços da agência numa avaliação NIS2
O pacote da agência começa pela descrição da fronteira. Indique as partes do contrato, o serviço do cliente, os sites de produção, os repositórios, os ambientes, as integrações e os fornecedores efetivamente geridos pela agência. A responsabilidade pelo código WordPress, alojamento, DNS, CDN, identidade, pagamentos e acesso editorial descreve-se em separado. A presença de uma ferramenta na arquitetura não torna automaticamente a agência responsável pelo controlo.
No mesmo documento registam-se exclusões e pressupostos. Se o cliente mantém o seu próprio fornecedor de identidade ou gere a base de dados, isso tem de ficar escrito. Se a agência implementa código mas não aprova alterações em produção, essa divisão também tem de estar visível. O cliente regulado responde pela qualificação NIS2 e pelo direito nacional; a agência fornece evidências sobre o seu próprio serviço.
Matriz RACI NIS2 para cliente, agência e alojamento
Uma matriz ao estilo RACI cobre a aprovação de alterações, implementações de emergência, triagem de vulnerabilidades, acesso privilegiado, execução de cópias de segurança, autorização de reposição, escalamento de incidentes, revisão de logs e saída do fornecedor. Cada linha indica o papel do cliente, o papel da agência, quem aprova, onde está a evidência e o canal de escalamento.
Os controlos partilhados exigem precisão. O alojamento pode fazer a cópia, a agência supervisionar a execução e o cliente definir o objetivo de reposição. Uma entrada como “a responsabilidade é do alojamento” esconde as obrigações de controlo e decisão das outras partes. A matriz é atualizada sempre que mudam o âmbito, a arquitetura ou as pessoas.
Evidências NIS2 para alterações, vulnerabilidades e acessos
Para uma alteração, guarda-se o pedido, a avaliação de risco, a revisão por uma segunda pessoa, o teste, a aprovação, o registo da implementação e o resultado do rollback. Uma alteração de emergência tem um caminho mais curto, mas não um caminho sem documentação: regista-se a autoridade de quem decide, o motivo e o prazo da revisão posterior. Uma release deve ligar o ticket, o commit e a hora em produção.
Para uma vulnerabilidade, regista-se a origem do alerta, o ativo e a versão, a justificação da prioridade, a exposição, a decisão, o prazo e o reteste. Uma exportação do scanner, por si só, não diz se o problema afetava a produção nem se uma exceção foi aceite. Quando um plugin não tem patch suportado, são necessários controlos compensatórios e uma decisão de substituição.
Para um acesso, regista-se a identidade nominal, a função, a justificação, quem aprovou, o MFA, a data de atribuição e a última revisão. A remoção do acesso de quem sai ou de uma conta de suporte expirada também tem de deixar rasto. Palavras-passe e códigos de recuperação não pertencem ao dossiê de evidências.
Como testar a reposição de cópias de segurança como evidência NIS2
Um estado verde na tarefa de cópia de segurança confirma que o ficheiro foi criado, não que é recuperável. A evidência descreve o âmbito, o ritmo, a cifragem, a localização, a retenção, o alerta de falha e as pessoas autorizadas a repor. Depois, faz-se a reposição num ambiente isolado, registando o início, o fim, a verificação de integridade, o teste da aplicação e os desvios ao RPO e ao RTO.
É preciso ter em conta as dependências fora da base de dados: ficheiros multimédia, configuração, segredos, DNS, regras na periferia, tarefas agendadas e definições de implementação. Repor só a base de dados pode dar um site que abre, mas não envia mensagens nem aceita pagamentos. A ata de receção especifica que serviço foi recuperado, o que foi simulado e o que ficou excluído.
Com que frequência rever e aceitar evidências NIS2
Cada evidência tem um responsável e um gatilho de atualização. Os acessos podem ser revistos trimestralmente, os exercícios de reposição e de incidentes anualmente ou após uma alteração relevante, e as vulnerabilidades e patches de forma contínua. Uma alteração de contrato, arquitetura, fornecedor ou de um plugin crítico desencadeia uma revisão dirigida.
Um artefacto está aceite quando está atualizado, tem responsável, está ligado a um controlo dentro do âmbito, está guardado no sítio certo e foi verificado pela função responsável. As lacunas registam-se à parte, com risco, responsável e prazo. Não se pode criar um registo histórico em falta como se já existisse antes.
O pacote mostra controlos selecionados do fornecedor num período definido. Não é um certificado NIS2, nem um parecer jurídico, nem prova de conformidade total do cliente. Também não garante a ausência de incidentes. As limitações devem constar da página de rosto.
Orçamento de um pacote de fornecedor NIS2 para WordPress
Para pedir orçamento, envie as partes do contrato, a descrição do serviço, a arquitetura, os ambientes, as integrações críticas, o questionário de fornecedor, a data da auditoria e a lista de evidências disponíveis. Não envie segredos na primeira mensagem. O nosso trabalho de preparação para NIS2 e DORA pode cobrir o pacote de fornecedor WordPress, a matriz de responsabilidades, as lacunas de evidência e a receção. Não substitui a avaliação jurídica do cliente.
O que inclui o pacote de segurança do fornecedor para clientes regulados
Uma agência WordPress que queira manter clientes regulados em 2026 entrega dois artefactos em cada contrato:
- Uma autodeclaração face ao artigo 21.º, n.º 2, alínea d), que descreve as medidas de segurança aplicadas na própria agência.
- Um documento de referência que o cliente inclui no seu próprio dossiê do artigo 21.º, mostrando como o contrato WordPress corresponde a cada uma das dez medidas.
Junto os dois num “pacote de segurança do fornecedor” e anexo-o à proposta. Isso elimina uma ronda com o departamento de compras e mostra que compreendemos o contexto regulatório. O orçamento de contratos de compliance engineering é individual; é o âmbito do dossiê que determina as horas, não uma tabela de preços.
