Avaliação de riscos de TI no WordPress: um método simples

Uma avaliação de riscos de TI para um site WordPress cabe numa página. Diz o que tem, o que pode realisticamente correr mal, qual seria a gravidade e quem corrige o quê, até quando. Pode ter um primeiro rascunho esta tarde, com o método em cinco passos descrito abaixo. O resultado é algo concreto para mostrar quando um questionário de cliente, uma seguradora ou uma autoridade de controlo perguntar como escolheu as suas medidas de segurança.

Porque é que a avaliação de riscos de TI vem primeiro no RGPD e na NIS2

O artigo 32.º, n.º 1, do RGPD exige medidas técnicas e organizativas adequadas ao risco, tendo em conta o estado da técnica e os custos. Não é possível demonstrar que uma medida é adequada sem antes dizer qual é o risco. O artigo 5.º, n.º 2, acrescenta que tem de poder comprovar o cumprimento, pelo que a avaliação tem de ficar por escrito. O nosso artigo sobre o artigo 32.º do RGPD no WordPress trata das próprias medidas.

Se a sua empresa estiver no âmbito da Diretiva NIS2, a lista de medidas mínimas do artigo 21.º, n.º 2, começa na alínea a): análise de riscos e políticas de segurança dos sistemas de informação. As obrigações vinculativas decorrem do direito nacional, por isso confirme a lei de transposição da NIS2 no seu país. Pode começar por verificar se a NIS2 se aplica à sua empresa.

Este método é um ponto de partida pragmático. Não é uma implementação da ISO 27001 nem uma auditoria externa formal.

Passo 1: Liste os seus ativos (sites, dados, contas, fornecedores)

Um ativo é tudo aquilo cuja perda ou utilização abusiva o prejudicaria. Numa pequena empresa típica, quatro grupos cobrem quase tudo. Comece pelos dados pessoais, porque é aí que o RGPD se aplica e onde o impacto é maior.

Seja específico. «Website» é demasiado vago. «shop.example.com, WooCommerce com cerca de 40 plugins, encomendas desde 2021» já é útil. Se, ao fazer a lista, encontrar uma cópia de teste esquecida ou a conta de administrador de um freelancer que já saiu, registe-o. Só essa descoberta justifica o exercício.

Passo 2: Identifique ameaças realistas para cada ativo

Não precisa de um catálogo de todos os ataques possíveis. Em sites WordPress, quatro grupos de ameaças cobrem a maioria dos incidentes reais:

• Plugins e temas vulneráveis ou abandonados. Alguém explora uma falha conhecida antes de atualizar, ou uma falha que nunca chega a ser corrigida.
• Credenciais roubadas ou partilhadas. Uma palavra-passe reutilizada, uma conta «admin» partilhada ou um acesso de agência que ninguém removeu.
• Falha do alojamento ou do servidor. Uma indisponibilidade, perda de dados no fornecedor de alojamento ou uma falha no próprio software do servidor. As vulnerabilidades PHP2Shell são um exemplo: estavam no runtime do PHP, pelo que um WordPress totalmente atualizado continuava exposto.
• Erro humano. Uma atualização que deixa o checkout inoperacional, uma página apagada ou um editor a quem foi atribuída a função de Administrador «só por um momento».

A ameaça dos plugins merece uma classificação honesta. O fornecedor Patchstack, no relatório State of WordPress Security in 2026, contabilizou 11 334 novas vulnerabilidades no ecossistema WordPress em 2025. Destas, 91 % estavam em plugins e 46 % não tinham correção disponibilizada pelo programador no momento da divulgação pública. Nas vulnerabilidades fortemente exploradas, o tempo mediano ponderado até à exploração em massa foi de 5 horas. São números de um fornecedor, mas explicam por que razão «plugin vulnerável» costuma ficar no topo de um registo WordPress.

Passo 3: Classifique probabilidade e impacto numa escala de 1 a 3

Use três níveis e defina-os em linguagem simples, para que duas pessoas que avaliem o mesmo risco cheguem à mesma resposta.

Probabilidade

1. Improvável num ano
2. Possível num ano
3. Esperada, ou já aconteceu consigo ou com um site semelhante

Impacto

1. Incómodo: a correção demora uma hora e nenhum dado é afetado
2. Indisponibilidade, ou uma quantidade limitada de dados não sensíveis afetada
3. Dados pessoais expostos, pagamentos afetados ou paragem do negócio

Multiplique os dois valores. Uma pontuação de 1–2 significa aceitar, 3–4 significa planear uma medida e 6–9 significa agir já. As pontuações 5, 7 e 8 não podem ocorrer nesta escala, o que mantém as faixas bem separadas.

Avalie o risco tal como está hoje. Um controlo que existe e funciona reduz a probabilidade. «Temos cópias de segurança» só conta se alguém já restaurou uma. Não acrescente decimais nem fatores de ponderação. A escala de 1 a 3 é grosseira de propósito, e a falsa precisão faz o registo parecer mais científico do que o conhecimento que o sustenta.

Passo 4: Escolha medidas, responsáveis e datas de revisão

Para cada risco com pontuação igual ou superior a 3, escolha uma ou duas medidas concretas. «Melhorar a segurança» não é uma medida. «Ativar a autenticação de dois fatores para os quatro administradores até 17 de novembro» é. Indique uma pessoa como responsável, não «o TI» ou «a agência», e fixe uma data.

Os artigos de aprofundamento tratam das medidas em si. Veja como lidar com plugins vulneráveis e cópias de segurança do WordPress que realmente se restauram. O seu registo de riscos só tem de documentar a decisão e apontar para as provas.

Mais duas coisas pertencem a cada linha. Primeiro, «aceitar» é uma decisão válida para pontuações baixas, desde que registe o motivo. Segundo, anote o risco residual, isto é, a pontuação que espera obter depois de a medida estar em vigor. Se uma medida não reduz a pontuação, provavelmente é a medida errada.

Exemplo prático: registo de riscos de uma pequena loja WooCommerce

O exemplo abaixo é de uma loja fictícia, com um site WooCommerce, uma cópia de teste, dois colaboradores, uma agência externa e alojamento partilhado. «P» é a probabilidade, «I» é o impacto e «Depois» é a pontuação residual esperada.

Leia-o de cima para baixo. Esta semana, a loja remove a conta da agência e pergunta ao fornecedor de alojamento pelo PHP. Ambas as ações são baratas e levam menos de uma hora. A limpeza de plugins segue-se na próxima semana, por ter a pontuação mais alta. A 2FA e o teste de restauro ficam agendados para dentro do mês.

As linhas do erro dos colaboradores e das mensagens dos formulários podem esperar por dezembro. As pontuações são mais baixas e, no caso dos erros de colaboradores, o trabalho sobre cópias de segurança da quarta linha já oferece uma alternativa. A indisponibilidade da newsletter é aceite, com motivo e data de revisão. Todas as linhas terminam em 3 ou menos. Isso não significa que nada possa acontecer. Significa um nível de risco documentado e fundamentado.

Manter a avaliação de riscos atualizada

Uma avaliação de riscos de TI que nunca volta a ser aberta passa a ser prova de que deixou de olhar. Reveja-a quando ocorrer um destes gatilhos:

• Depois de qualquer incidente ou quase-incidente, incluindo uma vaga de tentativas de início de sessão falhadas ou um plugin que teve de reverter
• Depois de alterações importantes, como um novo plugin que trata dados pessoais, um novo alojamento, uma nova agência ou o lançamento de uma loja
• Quando um fornecedor ou um cliente abrangido pela NIS2 envia um questionário de segurança
• A um intervalo fixo à sua escolha, por exemplo trimestral ou anual. É decisão sua, não uma regra legal

Atribua ao documento um número de versão e uma data, e guarde as versões antigas. Um histórico que mostra uma pontuação de 9 a descer para 3 depois de uma medida é uma boa prova de responsabilidade. O nosso guia sobre a documentação de auditorias de segurança mostra como o registo se articula com os restantes documentos.

O plugin de auditoria «Security Audit & Compliance» da secaudit.eu pode ajudar no Passo 2 e em cada revisão. Associa os resultados ao art. 32.º do RGPD e ao art. 21.º da NIS2 e exporta-os em relatório ou CSV, que pode comparar com o seu registo. As decisões do registo continuam a ser suas; o plugin fornece-lhe elementos atualizados para as tomar. → secaudit.eu

O seu próximo passo: copie a tabela de exemplo, substitua as linhas pelos seus próprios ativos e marque a data da primeira revisão antes de fechar o ficheiro.

FAQ

Preciso da ISO 27001 para isto?

Não. Este método é um arranque prático que pode executar com a sua própria equipa. A ISO 27001 é uma norma completa de sistemas de gestão, e adotá-la mais tarde é uma decisão de negócio à parte, muitas vezes motivada por grandes clientes.

Quanto tempo demora para um site?

Para um único site com uma configuração conhecida, um primeiro rascunho cabe numa sessão de trabalho. A maior parte do tempo vai para o Passo 1, a descoberta de contas e fornecedores. As revisões seguintes são muito mais rápidas, porque só atualiza o que mudou.

Uma agência faz isto uma vez ou para cada cliente?

Cada cliente é o responsável pelo tratamento do seu próprio site e é o titular da respetiva avaliação de riscos. A agência pode preparar um rascunho para o cliente aprovar. Deve também manter um registo separado para os seus próprios sistemas, como portáteis, cofre de palavras-passe e acessos ao alojamento dos clientes. O seu acordo de subcontratação de dados deve descrever quem faz o quê.

Este artigo é uma informação geral e não constitui aconselhamento jurídico.