Registo de Informação DORA para fornecedores WordPress: campos obrigatórios

#Registo de Informação DORA para fornecedores WordPress: campos obrigatórios

O artigo 28.º, n.º 3, do Regulamento 2022/2554 obriga cada entidade financeira a manter e atualizar um Registo de Informação sobre os acordos com fornecedores terceiros de serviços de TIC. O Regulamento de Execução (UE) 2024/2956 fixa a estrutura dos campos: quinze tabelas com colunas nomeadas. Uma agência WordPress que presta serviços a um banco, a uma seguradora, a uma empresa de investimento ou a uma instituição de pagamento entra neste registo e tem de fornecer os dados a tempo e no formato certo.

Este é um artigo de apoio dentro do pilar sobre NIS2 e DORA em WordPress, com remissão para a explicação do artigo 28.º do DORA sobre o risco de terceiros.

#Resumo

• Quinze tabelas fixadas pelo Regulamento de Execução 2024/2956.
• Os acordos sobre funções críticas ou importantes têm colunas adicionais (substituibilidade, risco de concentração, plano de saída).
• Cadeias de subcontratantes transparentes até ao nível relevante para a entidade financeira.
• A agência não submete o registo; a agência alimenta-o.
• A maioria das agências omite quatro das quinze tabelas na primeira submissão.

#Quais são as 15 tabelas do Registo de Informação DORA

Nos termos do artigo 28.º, n.º 3, cada entidade financeira tem de reportar o registo pelo menos uma vez por ano à sua autoridade de supervisão e à autoridade europeia de supervisão, através de um quadro de reporte comum. O regulamento de execução de 2024 define o esquema. As quinze tabelas:

1. Informação sobre a entidade.
2. Informação sobre a sucursal.
3. Informação sobre a filial.
4. Serviços de TIC.
5. Identificação das funções.
6. Acordos.
7. Funções do acordo.
8. Serviços de TIC do acordo.
9. Risco do acordo.
10. Subcontratação (subcontratantes).
11. Disposições relativas à rescisão.
12. Localizações.
13. Pessoas ou órgãos responsáveis.
14. Acordos relativos a funções críticas ou importantes.
15. Acordos com concentração (terceiros dentro do grupo).

Destas quinze, uma agência WordPress surge normalmente nas tabelas 4, 6, 8, 9, 10, 11, 12 e 14. As tabelas 1-3, 5, 7 e 13 pertencem à entidade financeira. A tabela 15 surge raramente e apenas quando a agência tem uma empresa-mãe ou é um fornecedor frequente no grupo da entidade.

#Que dados o fornecedor WordPress entrega ao abrigo do DORA

Por serviço de TIC (tabela 4) e por acordo (tabela 6), a agência fornece as colunas que a entidade financeira transcreve para o registo. Uma lista prática, não exaustiva:

• Descrição do serviço: alojamento WordPress, desenvolvimento de plugins, front-end headless, suporte, auditorias de segurança, discriminados por rubrica e não num único saco comum.
• Nome do fornecedor e LEI: o Legal Entity Identifier da agência. Uma pequena agência WordPress sem LEI tem de o obter antes de assinar o acordo.
• País de registo e sede.
• Pertença a grupo: empresa-mãe, filiais, empresas irmãs.
• Serviços prestados: que produtos são afetados, com indicação de criticidade.
• Dados tratados: dados de clientes, dados de transações, dados de colaboradores, nenhuns.
• Localizações dos dados: país e fornecedor de centro de dados por camada de armazenamento (produção, cópia de segurança, arquivo de registos).
• Subcontratantes: todos os fornecedores que a agência usa para prestar o serviço (Cloudflare, Sentry, plataforma de implementação, monitorização, APIs de IA).
• Jurisdições dos subcontratantes: país e lei aplicável por subcontratante.

A tabela 11 (disposições relativas à rescisão) exige que a agência divulgue:

• O prazo de pré-aviso para a entidade financeira.
• O prazo de pré-aviso para a agência.
• Os factos que permitem a rescisão antecipada pela entidade financeira.
• O plano de saída: como a entidade financeira recupera os dados e as operações.

A tabela 14 (acordos relativos a funções críticas ou importantes) exige provas adicionais se o serviço WordPress apoiar uma função crítica ou importante. Avaliação da substituibilidade, risco de concentração, plano de saída com prazos realistas, calendário regular de testes.

#O que falta mais vezes às agências WordPress no registo DORA

Cinco lacunas recorrentes das avaliações de fornecedores de 2025-2026:

Falta de LEI. Uma agência WordPress sem Legal Entity Identifier atrasa o acordo e o registo. Um LEI custa mais ou menos o mesmo que a renovação anual de um domínio. Não há justificação para não ter LEI quando se serve o setor financeiro regulado.

Lista de subcontratantes incompleta. A Cloudflare está lá, a Sentry está lá; o fornecedor de IA das ferramentas editoriais, o fornecedor de reencaminhamento de email, a plataforma de implementação e o destino das cópias de segurança externas ficam esquecidos. O registo não passa a revisão e a agência volta a passar pelo processo de compras.

Plano de saída num só parágrafo. “Entregamos os dados a pedido” não é um plano de saída. A entidade financeira precisa do número estimado de dias para a transição, do formato de entrega dos dados, da entrega do repositório de código, da entrega do runbook, da lista de dependências e do procedimento de encerramento das contas. No mínimo três páginas, de preferência um documento versionado.

Falta de prova de teste das cópias de segurança. O artigo 11.º do DORA exige testes regulares da resiliência operacional, incluindo a reposição. Uma agência sem registo trimestral de reposições chumba na revisão logo na primeira auditoria.

Falta de avaliação de função crítica. A agência afirma “não somos críticos” porque o site WordPress é “só marketing”. A equipa de compliance da entidade financeira discorda, porque uma falha da marca prejudica a confiança dos clientes. Resolva isto cedo no acordo, não durante a auditoria.

#Como preparar o primeiro registo

Uma lista de verificação prática para uma agência WordPress que entra no seu primeiro registo:

1. Obter o LEI, se faltar.
2. Inventariar os subcontratantes, com país e lei aplicável por fornecedor.
3. Escrever um plano de saída versionado: dados, código, runbook, contas.
4. Documentar as localizações dos dados por camada de armazenamento e por subcontratante.
5. Testar uma reposição completa a partir da cópia de segurança externa; registar a data e hora, a duração e o resultado.
6. Mapear os serviços prestados para as funções da entidade financeira; assinalar as críticas ou importantes.
7. Redigir uma declaração de substituibilidade: que concorrentes podem substituir o vosso serviço e em quantas semanas.
8. Instituir um ritmo de revisão trimestral: atualização dos dados, assinatura e arquivo em cada trimestre.

Feita antes do primeiro acordo, esta preparação compensa várias vezes. Feita durante a primeira auditoria, duplica o custo do trabalho.

#Como criar um inventário dos campos do registo DORA

A alimentação do registo deve ser um conjunto de dados controlado, não um questionário preenchido de memória. Cria-se um registo separado para a entidade jurídica, o acordo, o serviço de TIC, a função apoiada, a localização e cada relação de subcontratação relevante. Cada objeto recebe um identificador interno estável. Os nomes e os acordos mudam; o identificador liga as versões sem ser preciso adivinhar se duas entradas descrevem o mesmo fornecedor.

Para cada campo, registe a definição, o formato, os valores admitidos, se é obrigatório no modelo utilizado, o sistema de origem, o responsável e a prova. “Não aplicável”, “desconhecido” e um campo vazio são estados diferentes. As datas, os códigos de país e as denominações jurídicas têm de seguir o formato exigido. Nunca se pode inventar um LEI ou outro identificador. A entidade financeira deve confirmar o tipo de identificador e as regras de validação exigidas no modelo em vigor e pela autoridade competente.

#De onde vêm os dados do registo DORA

Os dados vêm de várias áreas. As compras guardam o acordo e as adendas. A equipa jurídica é responsável pelas cláusulas de rescisão, auditoria, subcontratação e saída. As finanças mantêm a ficha do fornecedor. A segurança e a arquitetura ligam os serviços aos sistemas e às funções. A privacidade descreve as categorias de dados e os locais de tratamento. A agência fornece a sua identidade jurídica, o âmbito do serviço, os subcontratantes, os locais operacionais e os materiais de saída.

Cada campo da exportação precisa de informação sobre a sua origem: documento ou sistema, campo de origem, data de extração, regra de transformação e revisor. Se a data de início vem de uma adenda e não do acordo-quadro, a entrada deve explicá-lo. Se várias subscrições de plugins formam um único serviço, é preciso conservar a aprovação desse agrupamento. Assim, as correções são reprodutíveis e um valor numa folha de cálculo não se torna um facto sem fonte.

As provas de origem ficam protegidas junto do registo: versão assinada do acordo, declaração do fornecedor, diagrama de arquitetura, lista de localizações aprovada e notificação de alteração. O acesso deve ser restrito, porque o pacote pode revelar a arquitetura de segurança, contactos e condições comerciais.

#Quem é responsável pelo registo DORA e quando o atualizar

A entidade financeira continua responsável pelo seu registo. O responsável pelo registo controla o esquema e o calendário. Os responsáveis pelos acordos verificam os acordos e as funções. A segurança verifica o mapeamento de serviços e dependências. As compras acompanham as respostas dos fornecedores. A agência WordPress designa um responsável pelos dados e um substituto para as questões e a aprovação da alimentação.

A revisão é periódica e desencadeada por eventos. Entre eles estão um novo acordo ou adenda, o arranque ou a retirada de um serviço, a alteração da denominação jurídica, um novo subcontratante, a mudança da região de alojamento, uma aquisição, a revisão do plano de saída e uma nova avaliação de função crítica. O ritmo vinculativo resulta do DORA, das normas técnicas de execução, dos procedimentos da entidade e das instruções da autoridade. Uma atualização trimestral pode ser um controlo interno, mas não é aqui apresentada como um prazo legal universal.

#Como validar os dados do registo DORA antes da exportação

Os controlos estruturais verificam os campos obrigatórios, a unicidade dos identificadores, as datas e os códigos, as referências e os registos órfãos de serviços ou subcontratantes. Os controlos semânticos comparam as datas com o acordo assinado, a ordem entre início e fim, as localizações com a arquitetura, o subcontratante com um serviço concreto e as relações de função crítica com a decisão da entidade financeira.

As alterações relevantes passam pelo princípio dos quatro olhos. Um registo rejeitado é devolvido com um código de erro e uma explicação, em vez de ser corrigido em silêncio. Conservam-se o resultado, a pessoa, a hora e a versão do conjunto de dados. Antes do envio, compara-se o número de registos e os totais principais com a última exportação aceite, explicando adições, eliminações e identificadores alterados.

#O que deve conter a exportação do registo DORA e o pacote de provas

A exportação é gerada a partir de uma versão congelada, não de uma folha de cálculo ainda em edição. Recebe a versão dos dados, a hora de criação, a versão do esquema e uma soma de verificação. Conservam-se o ficheiro legível por máquina, um relatório de controlo legível, os resultados da validação, as aprovações e um índice das fontes. Se existir um ambiente de testes, convém ensaiar a importação. A codificação, os separadores e o formato das datas podem rejeitar dados corretos quanto ao conteúdo.

A entrega da agência abrange a entidade, os acordos, os serviços, as localizações, os subcontratantes, a data de referência, as alterações, as lacunas conhecidas e o contacto. Não se deve afirmar que este recorte garante a integralidade de todo o registo. A consolidação ao nível do grupo, a classificação das funções e a submissão continuam a cargo da entidade financeira.

#Como verificar as respostas do fornecedor ao registo DORA

O pedido ao fornecedor deve indicar um acordo e um serviço concretos. Em vez de uma lista livre de perguntas, vale a pena enviar um modelo versionado, definições dos campos, exemplos, códigos admitidos e um canal de resposta seguro. O fornecedor confirma a data de referência e assinala os dados que dependem das respostas dos subcontratantes. As questões são acompanhadas junto do registo, e não em várias trocas de email independentes.

Uma alteração não deve apagar o histórico. Guarde o valor anterior, o novo valor, a data de efeito, o motivo, a fonte e a aprovação. Uma nova região de alojamento pode ter datas próprias de anúncio, de consentimento contratual e de arranque técnico. O histórico permite determinar que estado vigorava na data de um relatório concreto.

É também necessária uma regra para duplicados. Um mesmo grupo pode surgir como contraparte, plataforma e subcontratante através de empresas diferentes. As entidades jurídicas mantêm-se em separado e ligam-se por uma relação de grupo. A denominação comercial, o produto e a parte no acordo não são o mesmo campo. O nome de um plugin não indica automaticamente o fornecedor jurídico nem a localização dos dados.

Antes da aprovação, o responsável lê o registo como uma dependência completa: que função é apoiada por que acordo, serviço, empresa e localização, e como decorre a saída. Se isto não puder ser explicado, os campos formalmente preenchidos ainda precisam de trabalho. As lacunas vão para uma lista de qualidade com responsável e prazo, em vez de serem substituídas por pressupostos.

#Limitações deste guia sobre o registo DORA

#Como atualizar o registo DORA após mudar de região de alojamento

Suponha que uma instalação WordPress gerida é transferida entre regiões europeias do mesmo fornecedor de alojamento enquanto entidade jurídica. A alteração não consiste em sobrescrever um único campo de país. O responsável pelos dados identifica os acordos, os serviços, as funções apoiadas, as localizações de produção, cópias e registos e as relações de subcontratação. O responsável pelo acordo verifica se é exigido consentimento. A segurança confirma a data do arranque técnico e a privacidade avalia a alteração da informação sobre o tratamento.

O pacote de alteração contém o valor anterior e o novo, a data do anúncio, o consentimento, a data de efeito, as fontes e os identificadores dos registos. A validação verifica o código de país, a relação entre localização e serviço e o tratamento separado da produção, das cópias de segurança e do arquivo. Se a região anterior estiver a funcionar durante a migração, ambos os locais podem precisar de um período de validade. Sobrescrever de imediato apagaria a informação sobre o estado real.

O revisor compara a declaração do fornecedor, a prova de arquitetura e o acordo. Uma divergência torna-se uma tarefa de qualidade de dados com responsável, e não um motivo para escolher o valor mais conveniente. A aprovação exige fontes aprovadas, validação correta do esquema, relações coerentes, uma diferença explicada face à exportação anterior e a transmissão da alteração aos restantes responsáveis.

#Como pedir esclarecimentos ao fornecedor e aceitar os seus dados

O tratamento das respostas deve ter estados explícitos: enviado, recebido, em verificação, esclarecimento necessário, aceite e expirado. O pedido indica o registo, os campos, o formato, o canal seguro e o prazo. Um pedido de esclarecimento descreve uma contradição concreta, por exemplo o país de um subcontratante que não coincide com o anexo de localizações. Um genérico “verifiquem tudo outra vez” não melhora a qualidade.

A aceitação faz-se ao nível do campo. A identidade jurídica pode ser aprovada enquanto a localização continua em aberto. O responsável pelo registo define se um registo incompleto pode entrar no conjunto de trabalho e o que bloqueia a exportação. Os dados contratuais ou operacionais não devem ser adivinhados a partir de um site de marketing. A falta de uma prova relevante é escalada para o responsável pelo acordo.

Antes da aprovação final, uma segunda pessoa verifica a atualidade das fontes, as datas de efeito, a ligação entre acordo, serviço e função, a cobertura dos subcontratantes e a marcação dos valores desconhecidos. O registo de aprovação inclui a versão dos dados, o revisor, as exceções e o próximo facto que desencadeia a atualização. Trata-se de um rasto de controlo interno, não de uma aprovação pela autoridade de supervisão.

#O que mudar no registo DORA quando muda o responsável pelo serviço

Depois de uma reorganização, a responsabilidade pelo site pode passar do marketing para a equipa de canais digitais sem mudança de fornecedor nem de acordo. Mesmo assim, o registo tem de atualizar a pessoa ou unidade responsável e verificar se o mapeamento de funções mudou. O responsável anterior aprova a transferência das exceções em aberto e o novo confirma os contactos, o ritmo de revisão e o poder de decisão.

A verificação abrange um endereço de contacto que funcione, um substituto, a coerência com o diretório organizacional e a transferência do acesso às provas. Não basta escrever um nome novo se ninguém assumiu a obrigação de atualizar. O cenário mostra que a qualidade do registo depende também das mudanças organizacionais, e não apenas das técnicas e contratuais.

Também um registo aceite envelhece. Cada fonte relevante deve ter uma data de próxima verificação ou um facto desencadeador. O acordo é reavaliado após uma adenda ou renovação, a localização após uma alteração de infraestrutura, o subcontratante após uma comunicação do fornecedor e o contacto após uma reorganização. A ausência de alterações comunicadas não substitui uma confirmação planeada. Também a resposta “sem alterações” deve ser registada com data e aprovador, em vez de deixar silenciosamente o registo antigo.

Se um campo não puder ser esclarecido antes da exportação, o responsável descreve o impacto, a escalada e a decisão. Um valor desconhecido não pode ser transformado em “não aplicável” só para passar a validação. Deve ficar claro se a lacuna é aceitável, se exige preenchimento ou se bloqueia a aceitação do registo.

Este material é um mapa de gestão de dados e não substitui o Regulamento de Execução (UE) 2024/2956, as instruções de supervisão em vigor nem aconselhamento jurídico. As versões dos modelos, as taxonomias e as validações podem mudar. A classificação depende do contexto e a entrega dos dados não garante a aceitação do registo.

Se precisar de organizar a alimentação a partir de um fornecedor WordPress, envie um briefing escrito através do serviço de preparação para NIS2 e DORA. Indique a perspetiva, as jurisdições, as entidades, os acordos e serviços, o formato do registo, os sistemas de origem, a cadeia de subcontratantes, o prazo e os erros de validação conhecidos. Na primeira mensagem não envie acordos, dados de acesso nem arquitetura sensível. O primeiro resultado deve ser um mapa de campos, um modelo de responsabilidades, uma lista de qualidade de dados e um plano de provas.

#Uma agência WordPress precisa de código LEI para o DORA?

O DORA exige das instituições financeiras total transparência sobre toda a cadeia de fornecimento de TIC:

• Obrigação de ter um código LEI (Legal Entity Identifier): Uma agência que fornece software ou suporte técnico ao setor bancário e fintech tem de ter um código LEI ativo, renovado anualmente. Sem este identificador, a entidade financeira não consegue reportar corretamente o acordo às autoridades europeias de supervisão (EBA, ESMA, EIOPA).
• Identificação da cadeia de subcontratação (tabela 10): A instituição tem de saber não só quem gere o WordPress, mas também em que infraestrutura física funcionam os servidores (por exemplo AWS, Google Cloud, OVHcloud), quem fornece a proteção anti-DDoS (Cloudflare) e que bibliotecas SaaS externas participam no tratamento dos pedidos (Sentry, Postmark, Datadog).

#O que deve incluir o plano de saída do fornecedor de TIC no DORA

As tabelas 11 e 14 impõem requisitos rigorosos para o fim da colaboração:

• Garantia de migração de dados e código sem interrupções: O acordo tem de especificar em que formato a agência entrega a base de dados MySQL, os repositórios Git e a documentação de implementação em caso de rescisão do contrato (por exemplo, no prazo de 30 dias após a denúncia).
• Testes regulares do plano de saída: As entidades financeiras realizam simulações de mudança de fornecedor de TIC para verificar se a saída da agência atual não perturba processos de negócio críticos nem provoca perda de dados de clientes.

#Que direito de auditoria deve prever o acordo com o fornecedor de TIC

O artigo 30.º do Regulamento DORA exige de forma incondicional cláusulas de auditoria nos acordos com fornecedores de TIC:

• Acesso sem entraves dos auditores à infraestrutura: O acordo tem de garantir tanto às equipas de controlo interno do banco como aos inspetores da autoridade nacional de supervisão financeira e da Autoridade Bancária Europeia (EBA) acesso total aos registos, à documentação técnica e aos ambientes de alojamento do WordPress.
• Colaboração em testes de penetração avançados (TLPT): A agência está obrigada a participar ativamente em testes de resiliência baseados em cenários de ameaça (Threat-Led Penetration Testing), demonstrando estar preparada para se defender contra ataques avançados.
• Resumo: Uma entrega exemplar de dados ao Registo de Informação é prova de maturidade operacional, que constrói confiança duradoura junto das instituições financeiras e abre a porta a contratos empresariais plurianuais.

Manter o registo com rigor e cuidar continuamente da conformidade com a regulamentação europeia é a melhor proteção contra o risco de sanções financeiras e de perda de reputação no mercado financeiro. O profissionalismo em engenharia de segurança é a chave para um sucesso empresarial duradouro.

A confiança constrói-se com factos.

#Ligações relacionadas

• Pilar NIS2 e DORA em WordPress
• NIS2 vs DORA: sobreposição de âmbito para agências WordPress em 2026
• Auditoria de conformidade EU para WordPress