Guia de conformidade legal para agências WordPress em Espanha: RGPD, AEPD, LSSI e NIS2

#Guia de conformidade legal para agências WordPress em Espanha: RGPD, AEPD, LSSI e NIS2

O enquadramento legal dos sites empresariais e de comércio eletrónico em Espanha deixou de ser um conjunto de orientações teóricas e passou a ser um quadro operacional rigoroso. Em 2026, criar um site em Espanha com WordPress exige um conhecimento detalhado não só da tecnologia, mas também das leis nacionais e europeias que regulam a privacidade, o comércio eletrónico, a faturação e a cibersegurança.

Ignorar estas regras expõe as empresas a sanções da Agência Espanhola de Proteção de Dados (AEPD), da Secretaría de Estado de Digitalización e Inteligencia Artificial (a secretaria de Estado espanhola para a digitalização) e da Agência Tributária. Este artigo analisa os requisitos técnicos necessários para que uma instalação WordPress cumpra o quadro regulamentar em vigor em Espanha, com referências aos textos consolidados do BOE e aos guias da AEPD.

#Como cumprir o RGPD no WordPress segundo a AEPD

O RGPD (Regulamento (UE) 2016/679) é o pilar que rege o tratamento de dados pessoais na União Europeia. Em Espanha, a sua aplicação é supervisionada de forma muito ativa pela AEPD através da Ley Orgánica 3/2018 de Protección de Datos Personales y garantía de los derechos digitales (LOPDGDD).

#Como alojar Google Fonts localmente no WordPress

Um dos erros mais comuns em sites WordPress é o carregamento de recursos externos em tempo real. Quando um site faz um pedido a um servidor externo (como os servidores da Google para descarregar tipos de letra), o endereço IP do utilizador (considerado dado pessoal ao abrigo do RGPD) é transmitido a esse fornecedor terceiro e, com frequência, para fora do território da União Europeia.

Essa transmissão precisa de uma base jurídica e, se o servidor estiver fora do Espaço Económico Europeu, de garantias para a transferência internacional. Alojar os tipos de letra no próprio servidor elimina o pedido externo e, com ele, os dois problemas. A solução técnica no WordPress é simples: todos os tipos de letra são descarregados e servidos localmente a partir do servidor ou integrados no build estático (no caso de sites headless baseados em Astro).

Para alojar tipos de letra localmente num WordPress clássico:

1. Descarregue os ficheiros de tipos de letra (.woff2) a partir do Google Webfonts Helper ou de recursos semelhantes.
2. Carregue os ficheiros para a pasta do tema ou do tema filho (/assets/fonts/).
3. Defina as regras @font-face na folha de estilos CSS.
4. Desative os pedidos externos através de filtros no functions.php ou de ferramentas de otimização.

@font-face {
  font-family: 'Outfit';
  font-style: normal;
  font-weight: 400;
  font-display: swap;
  src: url('/assets/fonts/outfit-v11-latin-regular.woff2') format('woff2');
}

#Alojamento na UE conforme o RGPD

O RGPD exige que o responsável pelo tratamento garanta que os dados dos utilizadores são armazenados e tratados em infraestruturas que cumprem a regulamentação europeia. As transferências internacionais de dados para países sem decisão de adequação da Comissão Europeia exigem garantias adicionais (como a assinatura de Cláusulas Contratuais-Tipo, SCC).

Em 2026, a soberania de dados levou as agências a preferir alojamento fisicamente localizado na União Europeia. Usar plataformas que encaminham o tráfego através de proxies fora do território europeu sem acordos DPA (Data Processing Agreement) firmes representa um risco de conformidade significativo. Os fornecedores de CDN e alojamento com armazenamento exclusivo em centros de dados europeus são a opção padrão para projetos em produção.

#O que a LSSI exige a um site WordPress

A LSSI (Ley 34/2002) transpõe para o direito espanhol a Diretiva sobre o Comércio Eletrónico. Regula os serviços prestados através da internet quando constituem uma atividade económica para o prestador do serviço.

#O que deve conter a página Aviso Legal

Qualquer site que constitua uma atividade económica para o seu titular (venda direta, publicidade, afiliação ou angariação de leads) tem de dar acesso permanente, fácil, direto e gratuito à informação enumerada no artigo 10.1 da LSSI, normalmente reunida na página de Aviso Legal (o equivalente espanhol à página de informação legal):

• Nome ou denominação social, residência ou domicílio (ou um estabelecimento permanente em Espanha), endereço de email e qualquer outro dado que permita uma comunicação direta e efetiva.
• Dados de inscrição no Registro Mercantil (o registo comercial espanhol) ou no registo público em que o titular esteja inscrito.
• Se a atividade estiver sujeita a autorização administrativa prévia, os dados dessa autorização e do organismo que a supervisiona.
• Se for exercida uma profissão regulamentada, a ordem profissional e o número de inscrição, o título, o Estado em que foi emitido e as normas profissionais aplicáveis.
• Número de identificação fiscal.
• Se o site mostrar preços, informação clara e exata sobre se incluem impostos e, se for o caso, custos de envio.
• Os códigos de conduta a que o titular tenha aderido.

A lei não exige um número de telefone: basta o email mais qualquer outro canal de contacto direto. O artigo 38 gradua o incumprimento. Um incumprimento significativo das alíneas a) (identificação e contacto) e f) (preços) do artigo 10.1 é uma infração grave (artigo 38.3 b), e não informar sobre os restantes dados é uma infração leve (artigo 38.4 b). Segundo o artigo 39, as infrações graves são punidas com coima de 30.001 a 150.000 euros e as leves com coima até 30.000 euros. No WordPress, o lugar natural para estes dados é uma página com link a partir do rodapé de todos os modelos, incluindo o checkout do WooCommerce.

#Gestão de cookies e o banner de consentimento

O artigo 22.2 da LSSI só permite usar dispositivos de armazenamento e recuperação de dados no equipamento do utilizador se este tiver dado o seu consentimento depois de receber informação clara e completa sobre a sua utilização e finalidade. O Guia sobre a utilização de cookies da AEPD, atualizado em maio de 2024, concretiza como deve funcionar o banner (CMP, Consent Management Platform):

• Botões equivalentes: a opção de rejeitar tem de ser apresentada ao mesmo tempo, ao mesmo nível e com a mesma visibilidade que a de aceitar, sem remeter o utilizador para outra camada para rejeitar. Não é permitido destacar o botão de aceitação com cores chamativas e esconder a opção de rejeição num link de texto pouco legível.
• Categorias: o utilizador tem de poder aceitar ou rejeitar as cookies por finalidades (analíticas, publicitárias, de preferências). As cookies técnicas necessárias para prestar o serviço pedido (como manter os artigos no carrinho ou memorizar o idioma) estão isentas de consentimento.
• Consentimento ativo: o guia acolhe o critério do Comité Europeu para a Proteção de Dados segundo o qual continuar a navegar não é uma forma válida de dar consentimento, e acrescenta que a simples inatividade do utilizador também não o é. Os scripts de tracking têm de estar completamente inativos até o utilizador clicar em “Aceitar”.

#Que análise web pode funcionar sem consentimento segundo a AEPD

O guia geral da AEPD lembra que as cookies de análise não estão isentas do dever de consentimento. A exceção consta de outro guia, Uso de cookies para herramientas de medición de audiencia (janeiro de 2024), que só a admite se todas estas condições se cumprirem:

• A finalidade limita-se a medir a audiência do próprio site, em nome exclusivo do editor, e o resultado são dados estatísticos anónimos.
• Os dados não são cruzados com outros tratamentos nem transmitidos a terceiros, e não permitem seguir a pessoa entre diferentes sites ou aplicações.
• O tempo de vida das cookies limita-se a um período que permita comparar audiências (o guia dá como exemplo treze meses), sem ser prorrogado a cada visita, e os dados são conservados no máximo vinte e cinco meses.
• O utilizador é informado, por exemplo, na política de privacidade.
• Se a medição for prestada por um fornecedor externo, existe um contrato conforme o artigo 28 do RGPD que o proíbe de reutilizar os dados.

O guia enumera ainda as medições que considera estritamente necessárias: audiência por página, páginas de referência, tipo de dispositivo e navegador, tempos de carregamento, tempo na página, ações do utilizador e zona geográfica, sempre de forma agregada. Uma configuração que partilha os dados com plataformas publicitárias fica fora da isenção. Uma ferramenta autoalojada, configurada para não cruzar nem ceder dados, pode caber nela.

#Que coima aplica a AEPD por cookies sem consentimento

Usar cookies não isentas sem informar ou sem obter o consentimento nos termos do artigo 22.2 é uma infração leve segundo o artigo 38.4 g) da LSSI, punível com coima até 30.000 euros (artigo 39.1 c). Se houver reincidência e assim o declarar uma decisão definitiva proferida nos três anos anteriores, a infração passa a grave (artigo 38.3 i), com coima de 30.001 a 150.000 euros. A maioria das infrações da LSSI é sancionada pela Secretaría de Estado de Digitalización e Inteligencia Artificial, mas o artigo 43.1 atribui à AEPD as relativas a cookies, a comunicações comerciais por email e à revogação do consentimento.

Para fixar o montante, o artigo 40 tem em conta, entre outros critérios, a intencionalidade, o tempo durante o qual a infração foi cometida, os benefícios obtidos, o volume de faturação afetado e a adoção de medidas para mitigar ou reparar o dano. Corrigir o banner assim que a falha é detetada e documentar a correção é, portanto, um fator que a própria lei tem em conta.

#Como criar formulários conformes com o RGPD no WordPress

A angariação de leads através de formulários de contacto, subscrições de newsletter ou pedidos de orçamento é um ponto crítico sob a fiscalização da AEPD. Como o WordPress depende muito de plugins de formulários (como o Contact Form 7, o Gravity Forms ou o Formidable Forms), é necessária uma configuração cuidada para evitar falhas legais:

#Caixa de consentimento no formulário de contacto

Todos os formulários de contacto que recolham dados pessoais (como nome, email ou telefone) têm de incluir uma caixa de verificação não assinalada por defeito (checkbox), através da qual o utilizador aceita explicitamente a política de privacidade do site.

• Não são permitidas caixas pré-assinaladas.
• O envio do formulário tem de estar bloqueado até o utilizador assinalar ativamente a caixa.
• O texto junto à caixa tem de ter um link claro e acessível para a página de Política de Privacidade.

#O que deve conter a primeira camada de informação de privacidade

A AEPD exige que, imediatamente abaixo do botão de envio do formulário, seja apresentada uma “primeira camada” de informação simplificada sobre o tratamento dos dados. Esta informação tem de incluir de forma clara e direta:

• Responsável: nome do titular do site ou da empresa.
• Finalidade: para que são recolhidos os dados (por exemplo, responder a pedidos ou enviar propostas comerciais).
• Fundamento jurídico: a base legal do tratamento (normalmente o consentimento do titular dos dados).
• Destinatários: se os dados serão cedidos a terceiros (por exemplo, ferramentas de email marketing como o Brevo ou o Mailchimp).
• Direitos: como o utilizador pode exercer os direitos de acesso, retificação, apagamento e oposição (por exemplo, por email para uma caixa de correio dedicada).

#Como registar consentimentos de formulários no WordPress

Para cumprir o princípio da responsabilidade (accountability) do RGPD, a empresa tem de conseguir demonstrar que um utilizador concreto aceitou a política de privacidade numa data e hora específicas. No WordPress, isto consegue-se configurando o plugin de formulários para guardar na base de dados, em cada envio, o endereço IP (parcialmente anonimizado sempre que possível), a marca temporal (timestamp) e o estado da caixa de consentimento.

#Acessibilidade web obrigatória no WordPress com o EAA

A Diretiva (UE) 2019/882, conhecida como Ato Europeu de Acessibilidade (European Accessibility Act, EAA), foi transposta em Espanha através do título I da Ley 11/2023, de 8 de mayo. Exige que determinados produtos e serviços, entre eles os serviços de comércio eletrónico (incluindo os construídos com WooCommerce) e os serviços bancários, de transportes ou de comunicações eletrónicas, sejam acessíveis a pessoas com deficiência.

#Desde quando é obrigatória a acessibilidade de uma loja online em Espanha

Segundo a disposição final décima oitava da Ley 11/2023, o título I entrou em vigor a 28 de junho de 2025. Desde essa data, os serviços abrangidos têm de cumprir os requisitos de acessibilidade. O artigo 3.3 isenta as microempresas que prestem serviços, e a própria lei define microempresa como a que emprega menos de 10 pessoas e cujo volume de negócios anual ou balanço anual total não excede 2 milhões de euros. Uma agência que trabalha para várias lojas tem de verificar a isenção cliente a cliente, porque conta a dimensão do titular da loja, não a da agência.

#Critérios WCAG 2.2 de nível AA para WordPress

O critério prático para auditar um site é o nível AA das Diretrizes de Acessibilidade para o Conteúdo da Web (WCAG). O W3C explica na especificação das WCAG 2.2 que esta versão alarga as WCAG 2.1 com novos critérios, pelo que um site conforme com a 2.2 também é conforme com a 2.1, e recomenda adotar a 2.2 como objetivo, mesmo que as obrigações formais refiram versões anteriores. Isto obriga as agências a auditar e otimizar os modelos e blocos do WordPress segundo critérios rigorosos:

• Navegação por teclado: todo o site, incluindo menus suspensos e o checkout do WooCommerce, tem de ser navegável apenas com o teclado (tecla Tab). Os estados de foco (focus states) têm de ser claramente visíveis.
• Leitores de ecrã: as imagens têm de ter atributos alt descritivos e os elementos interativos (botões, links) têm de ter atributos aria-label descritivos quando o seu texto não é explícito.
• Contraste de cor: o texto tem de manter uma relação de contraste mínima de 4.5:1 face ao fundo (e 3:1 para texto grande).

#Porque é que os plugins de acessibilidade overlay não resolvem o EAA

Muitas agências tentam resolver a acessibilidade instalando plugins de sobreposição (overlays) que prometem tornar o site acessível automaticamente através de um botão flutuante. Um overlay altera a página no navegador depois de esta carregar, mas não muda os modelos, os blocos nem o HTML que o WordPress gera, que é onde os critérios WCAG são verificados. A acessibilidade tem de ser resolvida de forma nativa, em HTML semântico, e não com remendos de JavaScript.

#Como a NIS2 afeta uma agência WordPress em Espanha

A diretiva europeia NIS2, Diretiva (UE) 2022/2555, pretende elevar o nível comum de cibersegurança em toda a União Europeia. Alarga bastante o número de setores regulados e divide as empresas abrangidas em entidades essenciais e importantes. O seu artigo 41 fixava 17 de outubro de 2024 como data-limite para os Estados-Membros adotarem e publicarem as normas de transposição.

#Estado da transposição da NIS2 em Espanha

A 14 de outubro de 2026, a base de legislação consolidada do BOE não inclui nenhuma norma espanhola que transponha a NIS2. O quadro em vigor continua a ser o Real Decreto-ley 12/2018, sobre a segurança das redes e sistemas de informação, que transpôs a primeira diretiva NIS e é regulamentado pelo Real Decreto 43/2021. O seu artigo 19 impõe a obrigação de notificar incidentes aos operadores de serviços essenciais e aos prestadores de serviços digitais, que o fazem através do seu CSIRT de referência. O artigo 11 atribui ao INCIBE-CERT as entidades que não pertencem ao setor público definido na Ley 40/2015. Salvo se a própria agência for operador de serviços essenciais ou prestador de serviços digitais no sentido dessa norma, a obrigação de notificar não recai sobre ela. O que lhe chega, isso sim, são as exigências contratuais dos seus clientes regulados.

#Requisitos da NIS2 para agências WordPress na cadeia de abastecimento

Uma das novidades mais relevantes da NIS2 é o foco na cibersegurança da cadeia de abastecimento. O artigo 21.2 inclui entre as medidas mínimas de gestão de riscos a segurança da cadeia de abastecimento, com os aspetos de segurança da relação entre cada entidade e os seus fornecedores diretos (alínea d), e o uso de autenticação multifator quando adequado (alínea j). O artigo 21.3 pede ainda às entidades que avaliem as vulnerabilidades de cada fornecedor e a qualidade das suas práticas de cibersegurança, incluindo os seus procedimentos de desenvolvimento seguro.

Se a sua agência desenvolve, aloja ou faz a manutenção de um site WordPress para uma entidade regulada, é razoável esperar que o cliente passe estas medidas para o contrato:

• Controlo de acessos e MFA: autenticação de dois fatores em todas as contas de administrador do CMS e dos painéis de controlo do servidor.
• Runbook de incidentes: protocolo documentado para avisar o cliente sem demora, de modo a que este possa cumprir os seus próprios prazos. O artigo 23.4 da NIS2 exige à entidade regulada um alerta precoce em 24 horas a partir do momento em que tem conhecimento de um incidente significativo, uma notificação em 72 horas e um relatório final no máximo um mês após a notificação.
• Auditoria de dependências: análise regular dos plugins WordPress usados em produção para evitar ataques à cadeia de abastecimento (como a introdução de backdoors em atualizações de plugins populares).

#Como adaptar o WooCommerce ao VeriFactu

O Real Decreto 1007/2023 aprova o regulamento que define os requisitos dos sistemas informáticos de faturação, conhecido como regulamento VeriFactu. O seu artigo 8 exige que estes sistemas garantam a integridade, conservação, acessibilidade, legibilidade, rastreabilidade e inalterabilidade dos registos de faturação.

#Requisitos técnicos do VeriFactu para o WooCommerce

Nas lojas online baseadas em WooCommerce que vendem no mercado espanhol, a emissão de faturas tem de seguir o regulamento:

• Código QR: a fatura inclui um código QR cujos dados o destinatário pode enviar voluntariamente à Agência Tributária (artigo 17).
• Integridade do registo: os registos não podem ser alterados sem que o sistema o detete e avise. Qualquer correção ou anulação é feita através de pelo menos um registo de faturação adicional posterior, de forma a que os dados originais se conservem (artigo 8.2 a). Os registos estão encadeados para que a sua sequência possa ser seguida do primeiro ao último (artigo 8.2 b).
• Duas modalidades: o sistema pode enviar todos os registos à AEAT de forma automática e instantânea, e nesse caso é considerado “Sistema VERI*FACTU” e presume-se conforme por conceção (artigo 16). Se não os enviar, tem de assinar eletronicamente os registos (o artigo 16.3 só isenta dessa assinatura os sistemas VERI*FACTU).
• Declaração responsável: o produtor do software certifica que o seu sistema cumpre o regulamento através de uma declaração responsável visível em cada versão (artigo 13). O regulamento não prevê uma homologação do software pelas Finanças espanholas.

As agências de desenvolvimento WordPress devem evitar plugins genéricos que guardem registos editáveis e optar por integrar o WooCommerce, através de APIs, com ERPs ou software de faturação cujo produtor apresente essa declaração responsável.

#Prazos do VeriFactu para lojas WooCommerce

A disposição final quarta do Real Decreto 1007/2023, na redação dada pelo Real Decreto-ley 15/2025, de 2 de diciembre, fixa estes prazos:

• Contribuintes do Impuesto sobre Sociedades (o imposto espanhol sobre as sociedades): sistemas adaptados antes de 1 de janeiro de 2027.
• Restantes obrigados do artigo 3.1 (contribuintes do IRPF com atividades económicas, não residentes com estabelecimento permanente e entidades em regime de atribuição de rendimentos): sistemas operacionais antes de 1 de julho de 2027.
• Produtores e comercializadores de software: produtos adaptados num máximo de nove meses a partir da entrada em vigor da ordem ministerial de desenvolvimento.

O artigo 3.3 exclui os contribuintes que mantêm os livros de registo nos termos do artigo 62.6 do Regulamento do IVA, ou seja, através do Suministro Inmediato de Información (SII). Para os restantes, o sistema de faturação tem de estar adaptado nessas datas, e em muitas lojas pequenas é precisamente o WooCommerce que gera a fatura.

#Checklist de conformidade legal para WordPress em Espanha

Segue-se uma lista de verificação técnica dos elementos essenciais a configurar em qualquer instalação WordPress destinada ao mercado espanhol para garantir a conformidade total em 2026:

graph TD
    A[Conformidade regulamentar em Espanha] --> B[Privacidade & RGPD]
    A --> C[Obrigações formais & LSSI]
    A --> D[Segurança & NIS2]
    A --> E[Faturação & VeriFactu]

    B --> B1["Google Fonts alojadas localmente"]
    B --> B2["Servidores com DPA em território da UE"]
    B --> B3["Bloqueio prévio dos scripts de tracking"]

    C --> C1["Aviso Legal, Privacidade e Cookies visíveis"]
    C --> C2["Banner de cookies com botões equivalentes"]
    C --> C3["Consentimento explícito e informado"]

    D --> D1["Dois fatores (MFA) para administradores"]
    D --> D2["Registo de eventos e logs do sistema"]
    D --> D3["Auditoria automática dos plugins instalados"]

    E --> E1["Emissão de faturas não editáveis"]
    E --> E2["Software com declaração responsável VeriFactu"]
    E --> E3["IGIC nas Canárias e IPSI em Ceuta e Melilla"]

#Lista de verificação da configuração de WordPress e WooCommerce

• Tipos de letra locais: eliminar qualquer chamada a fonts.googleapis.com ou fonts.gstatic.com.
• Sem CDN externa: garantir que as imagens e os recursos estáticos são servidos a partir de domínios sob controlo da UE.
• Políticas atualizadas: links acessíveis no rodapé para a Política de Privacidade, o Aviso Legal e a Política de Cookies.
• Banner de cookies conforme: configurar a ferramenta escolhida (como o Cookiebot, o Complianz ou um desenvolvimento próprio leve em Cloudflare Workers) segundo o guia de cookies da AEPD, com o botão de rejeitar na primeira camada.
• Segurança no WordPress:
  • Limitar as tentativas de acesso falhadas (com plugins de segurança ou ao nível do proxy da Cloudflare).
  • Alterar o prefixo predefinido da base de dados do WordPress (wp_) durante a instalação.
  • Instalar um plugin de auditoria de atividade que registe as ações críticas dos administradores.
• WooCommerce:
  • Configurar as zonas de envio e o cálculo de impostos para as Canárias (IGIC), Ceuta e Melilla (IPSI).
  • Ativar campos específicos para o NIF/CIF no formulário de faturação do checkout.
  • Ligar o checkout a gateways de pagamento que apliquem a autenticação forte do cliente exigida pela PSD2 (3D Secure 2 nos pagamentos com cartão).

#Conclusão

A conformidade legal de um site empresarial ou loja online em Espanha já não é uma simples revisão de textos jurídicos que se resolve com modelos pré-definidos. Em 2026, a legalidade está intrinsecamente ligada ao design e à arquitetura técnica da plataforma.

As agências que adotam uma abordagem proativa de segurança desde a conceção e privacidade por defeito não só reduzem riscos legais significativos para os seus clientes, como ganham uma vantagem competitiva decisiva para conquistar os projetos de maior escala e valor no mercado ibérico.

#Como evitar sanções da AEPD no WordPress

A conformidade legal no ecossistema digital espanhol exige uma vigilância técnica proativa:

• Gestão de transferências internacionais de dados: depois das sucessivas decisões judiciais europeias sobre o fluxo transatlântico de informação, os administradores têm de garantir que os fornecedores de alojamento, análise e automação não transferem dados para jurisdições sem garantias adequadas sem o consentimento expresso do utilizador.
• Registo de atividades de tratamento (RAT) no WordPress: todas as empresas têm de documentar com rigor os formulários de contacto, as bases de dados de clientes do WooCommerce e os registos de acesso dos utilizadores registados. Integrar estas políticas diretamente na documentação técnica do projeto dá tranquilidade jurídica perante eventuais inspeções da Agência Espanhola de Proteção de Dados. O rigor jurídico protege o valor patrimonial do negócio.

#Cópias de segurança e formação em RGPD para equipas WordPress

Boas práticas de cibersegurança reduzem os riscos legais e operacionais na web:

• Atualizações controladas e cópias de segurança imutáveis: sistemas automáticos de backup em centros de dados localizados em território europeu permitem a recuperação imediata após incidentes de ransomware ou falhas de hardware.
• Formação da equipa editorial: formar os redatores na gestão adequada de imagens, direitos de autor e tratamento responsável de dados pessoais consolida uma cultura de conformidade regulamentar duradoura na empresa.