DORA artigo 28, risco de terceiros TIC: auditoria do fornecedor de alojamento e WAF para WordPress
O artigo 28 do Regulamento 2022/2554 é a parte do DORA que decide se um cliente do setor financeiro pode sequer assinar um contrato de alojamento ou uma subscrição de WAF. Aplica-se a instituições de crédito, instituições de pagamento, seguradoras, empresas de investimento, prestadores de serviços de criptoativos e cerca de quinze outras categorias do artigo 2. Desde 17 de janeiro de 2025 aplica-se diretamente, sem transposição.
Este é um artigo de apoio ao pilar sobre NIS2 e DORA em WordPress, com remissões para o percurso de evidências do Anexo II da NIS2 e para a visão geral da pilha CRA + NIS2 + DORA.
TL;DR
- DORA artigo 28 = princípios gerais da gestão do risco de terceiros TIC.
- Artigo 30 = cláusulas contratuais obrigatórias.
- Artigo 31 = regime de designação dos CTPP, conduzido pelas Autoridades Europeias de Supervisão.
- Um mandato WordPress para um banco ou seguradora desencadeia a inscrição no registo, a due diligence, as cláusulas e o plano de saída.
- No registo entram o alojamento, a CDN, o WAF, o plugin de pagamentos e o plugin de envio de e-mails.
A quem se aplica o DORA no setor financeiro
O artigo 2.º, n.º 1, enumera as entidades financeiras. As mais frequentes nos mandatos WordPress:
- Instituições de crédito e os respetivos grupos.
- Instituições de pagamento e instituições de moeda eletrónica.
- Empresas de investimento, incluindo as que operam MTF ou OTF.
- Prestadores de serviços de criptoativos ao abrigo do MiCA.
- Empresas de seguros e de resseguros.
- Mediadores de seguros acima do limiar de dimensão.
- Prestadores de serviços de financiamento colaborativo.
- Fundos de investimento (gestoras de OICVM, GFIA).
A estes somam-se os terceiros prestadores críticos de serviços TIC (CTPP), designados ao abrigo do artigo 31 em conjunto pela EBA, pela ESMA e pela EIOPA. A primeira ronda de designações decorreu em 2025 e é dominada por hyperscalers (a lista pública está no portal das Autoridades Europeias de Supervisão). Uma agência WordPress dificilmente se tornará CTPP. Uma plataforma de alojamento WordPress gerido com uma grande carteira de clientes financeiros pode tornar-se.
Requisitos do artigo 28 do DORA, número a número
O artigo 28 tem oito números. Os operacionais para um mandato WordPress:
Artigo 28.º, n.º 1. A entidade financeira gere o risco de terceiros TIC como parte integrante de todo o quadro de gestão do risco TIC. O quadro, as políticas e a supervisão ficam do lado da entidade, não do fornecedor. O fornecedor entrega as evidências que suportam esse quadro.
Artigo 28.º, n.º 2. Uma estratégia sólida, abrangente e bem documentada para o risco de terceiros TIC. A entidade mantém a documentação. O fornecedor tem de estar pronto para a alimentar.
Artigo 28.º, n.º 3. Um registo de todos os contratos com terceiros prestadores de serviços TIC, assinalando os que suportam funções críticas ou importantes. O registo tem de poder ser reportado ao regulador. Para WordPress: alojamento, CDN, WAF, gateway de pagamento, e-mail transacional, fornecedor de IA, ferramenta de monitorização e destino das cópias de segurança.
Artigo 28.º, n.º 4. Due diligence pré-contratual. Identificação e avaliação de todos os riscos relevantes. Análise do risco de concentração quando se acrescenta mais um contrato com o mesmo fornecedor ou com um fornecedor do mesmo grupo.
Artigo 28.º, n.º 5. Avaliação de conflitos de interesses. O órgão de administração aprova a política de utilização de serviços TIC que suportam funções críticas ou importantes.
Artigo 28.º, n.º 7. Reavaliação periódica do contrato.
Artigo 28.º, n.º 8. Estratégia de saída para os serviços TIC que suportam funções críticas ou importantes. Documentada, testada e com plano de transição.
Cláusulas contratuais do artigo 30 do DORA no contrato de alojamento
O artigo 30.º, n.º 2, enumera as cláusulas mínimas de qualquer contrato. O artigo 30.º, n.º 3, acrescenta cláusulas para os contratos que suportam funções críticas ou importantes. O modelo de agência que entrego com os contratos de alojamento e WAF cobre-as todas:
| Cláusula | N.º do art. 30 | O que consta do contrato WordPress |
|---|---|---|
| Descrição clara do serviço | 30(2)(a) | Nível de alojamento, conjunto de regras WAF, plugins incluídos no preço, tempos de resposta |
| Localização dos dados | 30(2)(b) | Centro de dados na UE/EEE, suporte a partir da UE, sem subcontratantes fora da UE sem notificação |
| Requisitos de disponibilidade e segurança | 30(2)(c) | SLA de disponibilidade, RPO, RTO, cifragem em repouso e em trânsito |
| Proteção de dados pessoais | 30(2)(d) | Contrato de subcontratação nos termos do artigo 28 do RGPD, registo das atividades de tratamento |
| Direito de acesso, inspeção e auditoria | 30(2)(e) | Auditoria presencial ou remota, periodicidade, prazos |
| Descrições dos níveis de serviço | 30(2)(f) | Matriz de SLA, mecanismo de descontos por incumprimento |
| Cooperação com as autoridades de supervisão | 30(2)(g) | O fornecedor coopera com o regulador quando solicitado |
| Direitos de rescisão | 30(2)(h) | Incumprimento grave, rescisão imposta pelo regulador, mudança de controlo |
| Participação em ações de sensibilização e formação | 30(2)(i) | Briefing anual de segurança, pessoa de contacto nomeada |
| Subcontratação | 30(3)(c) | Consentimento prévio para a subcontratação de funções críticas |
| Testes de penetração baseados em ameaças | 30(3)(g) | Cooperação nos TLPT do artigo 26 |
| Apoio à estratégia de saída | 30(3)(f) | Formato de exportação de dados, apoio na transição, período de funcionamento em paralelo |
Mantenho esta matriz como um único ficheiro Markdown na pasta do mandato. Cada contrato é verificado em relação a ela antes da assinatura.
Registo de informação DORA para fornecedores WordPress
Um mandato WordPress para uma entidade financeira envolve mais terceiros TIC do que o departamento de compras costuma prever. O registo que monto no primeiro dia do mandato:
- Fornecedor de alojamento. O operador efetivo do centro de dados, o painel de gestão, a equipa de suporte. Crítico ou importante se o WordPress fizer parte da prestação de serviços aos clientes.
- Fornecedor de CDN. Cloudflare, Fastly, Akamai. Processa o tráfego, vê o conteúdo dos pedidos, termina o TLS. Muitas vezes crítico ou importante.
- Fornecedor de WAF. Por vezes o mesmo da CDN, por vezes separado (Sucuri, Imperva). Inspeciona payloads. Crítico ou importante.
- Plugin de pagamentos. Stripe, Adyen, mollie, gateways locais. O autor do plugin é um fornecedor; o operador do gateway é outro. Ambos entram no registo.
- E-mail transacional. SES, Postmark, SendGrid. Transporta reposições de palavra-passe, notificações KYC, alertas AML. Muitas vezes crítico ou importante.
- Monitorização e APM. New Relic, Datadog, Sentry. Recebe stack traces e fragmentos de payloads.
- Destino das cópias de segurança. S3, Backblaze, Wasabi. Guarda a base de dados e os carregamentos. Sempre crítico ou importante.
- Fornecedor de IA. Se o WordPress usar um LLM em funções de contacto com o cliente (chat, resumos), o fornecedor do LLM está no âmbito.
- Marketplace de plugins. WordPress.org, marketplaces premium. Os canais de atualização fazem parte da cadeia de abastecimento nos termos do art. 28.º, n.º 2, alínea d).
O registo guarda, para cada fornecedor: denominação legal, referência do contrato, descrição do serviço, fluxos de dados, classificação de criticidade, local de tratamento, data da última due diligence e remissão para a estratégia de saída.
Como avaliar o risco de concentração DORA com um único fornecedor de cloud?
O artigo 28.º, n.º 4, introduz um teste que apanha as agências WordPress mais vezes do que se pensa: não concentrar funções críticas em fornecedores do mesmo grupo de capital. Um banco que usa Cloudflare para CDN, Cloudflare Workers para backend, Cloudflare R2 para armazenamento de objetos e Cloudflare Stream para vídeo tem um risco de concentração elevado num único fornecedor. Não é uma conclusão específica da Cloudflare; funciona da mesma forma para pilhas AWS, Azure ou GCP.
Em WordPress, isto costuma ter este aspeto: alojamento na AWS, cópias de segurança no S3, e-mail via SES, monitorização via CloudWatch. Quatro dependências AWS, um só fornecedor. O registo de riscos tem de o reconhecer de forma explícita e justificá-lo ou planear a diversificação.
Estratégia de saída DORA para alojamento e WAF WordPress
O artigo 28.º, n.º 8, exige que a estratégia de saída seja documentada e testada. Para alojamento e WAF WordPress, uma estratégia de saída real inclui:
- Exportação da base de dados em formato normalizado. Dump SQL compatível com MySQL ou MariaDB de origem, sem extensões proprietárias.
- Exportação do sistema de ficheiros com os carregamentos. Arquivo tar ou zip, descarregável fora do painel do fornecedor.
- Controlo do DNS. A conta no registo de domínios pertence à entidade financeira, não à agência nem ao fornecedor de alojamento.
- Portabilidade das licenças de plugins e temas. Licenças em nome da entidade, transferíveis para o novo fornecedor de alojamento.
- Transição testada. Um ambiente de staging num fornecedor de alojamento alternativo que pode passar a produção num tempo documentado. O teste fica registado e datado.
- Janela de transição contratual. O contrato de alojamento obriga o fornecedor a manter os serviços durante a migração, ao mesmo preço, pelo menos durante um período documentado.
O orçamento dos mandatos que incluem o pacote de estratégia de saída é individual; o próprio documento de saída leva dias, não horas, e é um resultado do mandato.
Como o DORA muda a contratação de uma agência WordPress
Uma agência WordPress que chega com a matriz das cláusulas do artigo 30 preenchida, um modelo de registo de fornecedores pronto e uma estratégia de saída testada passa mais depressa pelo processo de compras. A entidade financeira não tem de traduzir o artigo 28 num contrato; incorpora os materiais preparados pela agência no seu próprio quadro de gestão do risco TIC.
É também por isso que um cliente regulado filtra a lista curta de fornecedores por jurisdição. Uma agência da UE sujeita ao direito da União elimina uma camada de atrito; uma agência de fora da UE obriga a uma due diligence adicional ao abrigo do artigo 28.º, n.º 4, sobre o risco jurisdicional.
Como classificar uma função crítica ou importante no DORA
A criticidade não é decidida pela marca nem pelo valor do contrato. O ponto de partida é a função suportada pelo serviço e o efeito da sua indisponibilidade, degradação ou comprometimento. O site informativo de um banco pode ser importante para a comunicação sem suportar diretamente um serviço financeiro crítico. Um plugin barato que trata a autenticação ou o estado dos pagamentos pode ter um impacto operacional muito maior do que o custo da licença sugere.
A ficha de classificação deve indicar o serviço de negócio, o responsável pelo processo, os clientes afetados, os dados, os objetivos de recuperação, os contornos manuais possíveis e as dependências de outros fornecedores. Regista também quem aprovou a qualificação como função crítica ou importante e a data da próxima revisão. Esta decisão define a profundidade da due diligence e as condições adicionais do artigo 30. Não é um rótulo que o fornecedor possa atribuir a si próprio.
Lista de evidências para a due diligence do fornecedor TIC
O departamento de compras deve receber evidências relativas ao serviço concreto, não uma pasta genérica de segurança. Para alojamento, CDN, WAF ou manutenção WordPress, o pacote inclui normalmente:
- entidade jurídica, grupo proprietário, locais de prestação do serviço e subcontratantes;
- limites da arquitetura e dos fluxos de dados, incluindo o acesso administrativo e os canais de suporte;
- evidências de MFA, revisões de acessos privilegiados e revogação de acessos;
- processos de vulnerabilidades, correções e alterações, com exemplos recentes do seu funcionamento;
- circuito de notificação de incidentes, contactos de escalonamento e preservação de evidências;
- resultados dos testes de recuperação e de continuidade relativos ao serviço contratado;
- relatórios independentes, o seu âmbito, exclusões e estado das ações corretivas;
- SLA proposto, objetivos de recuperação, apoio à auditoria e assistência no fim do contrato.
Um certificado apoia a avaliação, mas não prova automaticamente que abrange o painel de gestão do WordPress, a equipa de suporte e o destino das cópias de segurança. No registo de evidências, anote a data, o período abrangido pela análise, quem avaliou e as questões em aberto. Se o material for confidencial, pode acordar-se uma consulta controlada, um relatório independente ou uma cláusula específica. Uma lacuna não deve ser marcada como cumprida só porque o fornecedor se recusou a entregar o documento.
Subcontratação no DORA nos fornecedores WordPress
A contraparte direta raramente gere toda a pilha. Uma agência de WordPress gerido pode usar cloud, CDN, um sistema de tickets, monitorização e suporte externo. O contrato e o registo têm de distinguir a parte contratual das entidades que efetivamente armazenam dados, administram o sistema ou suportam uma função crítica ou importante.
É preciso definir que alterações na subcontratação exigem notificação, o que a comunicação contém, como funcionam a oposição ou a rescisão e o que acontece aos dados existentes. A avaliação abrange também a concentração no quarto nível. Dois fornecedores aparentemente independentes podem depender do mesmo hyperscaler, do mesmo operador de DNS ou do mesmo fornecedor de identidade. Uma lista recolhida na assinatura e nunca atualizada não é um controlo eficaz.
Como testar a saída de um fornecedor TIC
Dois logótipos num diagrama não garantem diversificação. Se o alojamento de reserva usa a mesma região de cloud, a conta de cópias de segurança o mesmo sistema de identidade e o DNS continua sob o controlo do fornecedor de saída, a alternativa pode falhar juntamente com o serviço principal. Mapeie a propriedade partilhada, a infraestrutura, a geografia, as credenciais administrativas e o conhecimento especializado.
O teste de saída deve confirmar que uma equipa autorizada consegue obter os dados e a configuração atuais, verificar a integridade, restaurar o serviço, redirecionar o tráfego, preservar os registos exigidos e revogar o acesso antigo. Meça o tempo e compare-o com a tolerância de negócio aceite. Registe os passos manuais, as limitações de licenciamento, os problemas de formato e as funções que não foi possível restaurar. O resultado pode ser um risco residual aceite, um plano de melhoria ou a mudança de origem do serviço. O artigo 28 não impõe automaticamente a duplicação de cada dependência independentemente do custo.
Revisão periódica do fornecedor TIC e critérios de aceitação
A frequência da reavaliação depende da criticidade e das alterações. Uma nova revisão deve ser desencadeada por um incidente grave, uma aquisição, um novo local de tratamento, uma alteração relevante de subcontratante, uma reformulação do serviço ou incumprimentos repetidos do SLA. O responsável pelo serviço, as compras, a segurança, o departamento jurídico e a proteção de dados precisam de papéis atribuídos. Enviar um questionário anual sem avaliar as respostas não constitui supervisão eficaz.
Antes da aceitação devem existir: um responsável pelo controlo, um registo de evidências completo, lacunas contratuais resolvidas ou exceções formalmente aceites, a inscrição no registo, um plano de saída exequível e a data da próxima revisão. A aceitação separa os factos confirmados, as declarações do fornecedor, os elementos fora do âmbito e o risco residual. A auditoria do fornecedor reduz a incerteza, mas não certifica a conformidade da entidade financeira com o DORA nem garante a continuidade do serviço.
Para definir o âmbito de um orçamento, envie um briefing escrito com a função financeira, o fornecedor e o serviço, a arquitetura, as classes de dados, os subcontratantes conhecidos, os objetivos de recuperação, o estado do contrato e o prazo de compras. Uma auditoria de prontidão NIS2 e DORA pode então organizar o registo de fornecedores, as lacunas de evidências, a checklist do contrato, a análise de concentração e o plano de novo teste para a superfície WordPress.
