Artigo 32.º do RGPD e WordPress: o que é «segurança adequada»

O artigo 32.º do RGPD não menciona nenhum plugin, nenhuma configuração de servidor nem um comprimento mínimo de palavra-passe. Exige uma segurança adequada ao risco — e, na maioria dos sites WordPress, isso traduz-se numa lista curta e concreta: HTTPS em todo o site, software atualizado, contas pessoais com autenticação de dois fatores, cópias de segurança que já foram efetivamente restauradas e verificações regulares. Quem faz isto e o consegue demonstrar já cobre a maior parte do que o artigo 32.º espera de um site WordPress típico.

Este guia traduz as alíneas a) a d) do artigo 32.º, n.º 1, em medidas para WordPress, ponto por ponto. Aborda também os dois deveres que as rodeiam: documentar as medidas (responsabilidade) e garantir que o fornecedor de alojamento e a agência fazem a sua parte.

Segurança WordPress e RGPD: o que diz o artigo 32.º

O artigo 32.º do RGPD obriga tanto o responsável pelo tratamento (a empresa) como qualquer subcontratante (por exemplo, o fornecedor de alojamento) a aplicar medidas técnicas e organizativas adequadas. O que é adequado depende das técnicas mais avançadas, dos custos de aplicação, da natureza, do âmbito, do contexto e das finalidades do tratamento, bem como do risco para as pessoas cujos dados são tratados.

O artigo enumera depois quatro elementos que essas medidas incluem, «consoante o que for adequado»:

• a) a pseudonimização e a cifragem dos dados pessoais;
• b) a capacidade de assegurar a confidencialidade, integridade, disponibilidade e resiliência permanentes dos sistemas e dos serviços;
• c) a capacidade de restabelecer atempadamente a disponibilidade e o acesso aos dados pessoais após um incidente;
• d) um processo para testar, apreciar e avaliar regularmente se as medidas funcionam.

Por trás disto está o artigo 5.º, n.º 1, alínea f): os dados pessoais têm de ser tratados com uma segurança adequada. E um site WordPress típico trata mais dados pessoais do que o dono imagina: contas de utilizador, comentários com nome, endereço de e-mail e endereço IP, mensagens de formulários de contacto, inscrições em newsletters, encomendas WooCommerce e registos do servidor.

Uma abordagem baseada no risco: técnicas mais avançadas e custos

O artigo 32.º assenta deliberadamente no risco. O site de uma empresa com um único formulário de contacto, uma loja com milhares de contas de clientes e uma área de membros que guarda informação de saúde não exigem o mesmo esforço, mas cada um precisa de um nível à medida do que pode correr mal. O artigo 32.º, n.º 2, indica os riscos a ponderar: destruição, perda e alteração acidentais ou ilícitas, e divulgação ou acesso não autorizados a dados pessoais.

A expressão «técnicas mais avançadas» deve ler-se como «consolidado e amplamente disponível», e não como «o produto mais caro do mercado». HTTPS, versões de software suportadas e login com dois fatores para administradores fazem hoje parte desse patamar, e custam pouco. Os custos podem justificar que um pequeno blogue funcione sem uma firewall de aplicações web de nível empresarial. Raramente justificam saltar o básico.

Alíneas a) a d) do artigo 32.º, n.º 1, como medidas WordPress

A tabela associa cada alínea a medidas típicas no WordPress e às provas que vale a pena guardar.

a) Cifragem e pseudonimização

O site inteiro deve ser servido apenas por HTTPS, incluindo /wp-admin/ e todos os formulários, com HSTS acrescentado logo que isso funcione de forma fiável. As palavras-passe não são cifradas, mas sim convertidas em hash, que é a abordagem correta para elas: desde o WordPress 6.8, as palavras-passe dos utilizadores usam bcrypt.

De todas as cópias dos dados pessoais, as cópias de segurança são as mais esquecidas. Devem ser cifradas e guardadas longe do servidor web. A verdadeira pseudonimização é rara num site WordPress típico, mas há medidas próximas que reduzem o risco: encurtar os endereços IP nas estatísticas e nos registos e não manter mensagens de formulários na base de dados mais tempo do que o necessário. Dados que já não estão guardados não podem ser divulgados.

b) Confidencialidade, integridade, disponibilidade e resiliência

As atualizações vêm primeiro. A Patchstack, empresa de segurança, contabilizou 11 334 novas vulnerabilidades no ecossistema WordPress em 2025, 91 % delas em plugins. Nas mais exploradas, a mediana ponderada até à exploração em massa foi de cinco horas (relatório da Patchstack). Ative as atualizações automáticas onde fizer sentido (o núcleo oferece-as para plugins e temas desde o WordPress 5.5) e apague os plugins que não estão em uso. O nosso guia sobre plugins vulneráveis explica como auditá-los.

O controlo de acessos é o segundo pilar: uma conta pessoal por pessoa, a função mais baixa que sirva (Editor, Autor ou Colaborador em vez de Administrador) e autenticação de dois fatores para todos os administradores — o núcleo do WordPress não a inclui. Para proteger a integridade, remova os editores de ficheiros do painel no wp-config.php:

define( 'DISALLOW_FILE_EDIT', true );

De tempos a tempos, compare os ficheiros do núcleo com os checksums oficiais (wp core verify-checksums no WP-CLI). Para a disponibilidade e a resiliência, escolha um alojamento com recursos e monitorização adequados. Nenhum plugin consegue absorver um grande ataque DDoS; essa é a função de uma CDN ou de uma firewall na periferia da rede (edge). O guia oficial de hardening do WordPress enumera mais definições do lado do servidor.

c) Restabelecer a disponibilidade após um incidente

Uma cópia de segurança só conta se puder ser restaurada. Faça cópias dos ficheiros e da base de dados, mantenha pelo menos uma fora do servidor e fora do alcance da conta de administrador do WordPress e teste um restauro completo num ambiente de testes (staging). Registe quanto tempo demorou: a exigência de agir «de forma atempada» defende-se muito melhor com um tempo de restauro medido do que com uma esperança.

d) Testar, apreciar e avaliar regularmente

O RGPD não fixa uma periodicidade, por isso cada empresa deve definir a sua e cumpri-la. Um ponto de partida razoável para uma pequena empresa: uma análise automática por semana, uma revisão das contas de utilizador e dos plugins por trimestre, um teste de restauro duas vezes por ano e uma revisão extra depois de cada incidente ou alteração importante. Registe o que foi encontrado e corrigido, com datas.

O plugin Security Audit & Compliance da secaudit.eu pode cobrir parte destes testes: procura malware, ficheiros do núcleo alterados, plugins desatualizados e palavras-passe fracas, associa os resultados ao art. 32.º do RGPD e mostra um resumo de conformidade no ecrã; os relatórios assinados (PDF, CSV) estão incluídos no secaudit.eu Pro. Uma análise apoia a documentação; por si só, não torna um site conforme.

Responsabilidade: documentar o que se faz (art. 5.º, n.º 2)

Nos termos do artigo 5.º, n.º 2, o responsável pelo tratamento tem de conseguir comprovar o cumprimento. Na prática, isso significa um documento de segurança curto e vivo, e não um dossiê que ninguém lê. Deve abranger:

• Um inventário: alojamento, versão do WordPress, plugins, temas, serviços externos
• Quem tem acesso, com que função, e quem aprova novas contas
• As medidas para as alíneas a) a d), com a nota de risco que as fundamenta
• Um registo de atualizações e as datas das análises, das revisões de acessos e dos testes de restauro
• O procedimento para incidentes, incluindo a notificação de violações em 72 horas
• Os contratos celebrados com os subcontratantes

Reveja o documento uma vez por ano e sempre que o site mudar de forma significativa. A nossa checklist de segurança WordPress é um bom ponto de partida para o inventário.

Alojamento e agências: subcontratantes nos termos do art. 28.º

O fornecedor de alojamento guarda a base de dados e as cópias de segurança. Uma agência ou um freelancer com acesso de administrador consegue ler todos os registos de clientes. Ambos atuam normalmente como subcontratantes, e é então necessário um contrato com cada um nos termos do artigo 28.º. O mesmo artigo determina que só podem ser usados subcontratantes que apresentem garantias suficientes de execução de medidas técnicas e organizativas adequadas, e o contrato tem de os obrigar a adotar as medidas exigidas pelo artigo 32.º.

Faça perguntas concretas em vez de confiar num modelo. Onde são guardadas as cópias de segurança, e durante quanto tempo? A autenticação de dois fatores é obrigatória no painel de alojamento e nas contas da agência? Com que rapidez avisam de um incidente de segurança? Quando termina o contrato com uma agência, remova as contas dela e altere as credenciais partilhadas no mesmo dia.

As infrações aos artigos 25.º a 39.º, incluindo o artigo 32.º, podem ser punidas com coimas até 10 milhões de euros ou 2 % do volume de negócios anual a nível mundial, consoante o montante mais elevado (art. 83.º, n.º 4, alínea a)). Ainda assim, o momento mais provável em que a documentação vai fazer falta é depois de um incidente, quando uma autoridade (em Portugal, a CNPD) perguntar que medidas estavam em vigor.

Perguntas frequentes

O artigo 32.º exige um plugin de segurança específico?

Não. Exige medidas adequadas, não produtos. Um plugin pode ajudar em algumas delas, como o login com dois fatores ou as análises, mas as atualizações, as cópias de segurança, as revisões de acessos e os contratos fazem igualmente parte.

O artigo 32.º aplica-se a um site pequeno sem contas de utilizador?

Sim, a partir do momento em que o site trata dados pessoais, por exemplo mensagens de formulários de contacto, comentários ou registos do servidor com endereços IP. As medidas acompanham o risco.

O HTTPS basta para a alínea a)?

Não. O HTTPS protege os dados em trânsito. As cópias de segurança, as exportações e a base de dados no servidor precisam de proteção própria.

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