DORA: o registo de fornecedores TIC é um mapa de dependências, não uma folha de contactos

Uma obrigação contínua, com um modelo relacional

O artigo 28.º, n.º 3, do DORA determina que as entidades financeiras mantenham e atualizem, ao nível individual, subconsolidado e consolidado, um registo de informação sobre todos os acordos contratuais relativos à utilização de serviços TIC prestados por terceiros.

O Regulamento de Execução (UE) 2024/2956 define os modelos normalizados. As tabelas representam entidades, ramos, contratos, prestadores, cadeia de fornecimento, serviços, funções, avaliações e estratégias de saída. A informação repete-se apenas onde o modelo exige e liga-se por chaves.

As Autoridades Europeias de Supervisão usam o registo para supervisão e para apoiar a designação dos prestadores terceiros críticos. Por isso, o ficheiro é simultaneamente inventário operacional, evidência de governação e objeto de reporte.

Escolher o grão certo antes de preencher campos

Fornecedor, contrato e serviço não são sinónimos. Um prestador pode ter vários contratos; um contrato pode cobrir vários serviços; um serviço pode suportar múltiplas funções; e um contrato pode depender de vários subcontratantes. Colocar tudo numa linha cria repetições, omissões e relações impossíveis de validar.

O prestador que assina o acordo com a entidade financeira ocupa o nível 1 da cadeia. Os subcontratantes relevantes surgem em níveis superiores a 1 e devem ser ligados ao serviço e ao contrato apropriados. A classificação não é uma opinião sobre importância: representa posição na cadeia.

Identificadores e vazios: onde a qualidade falha primeiro

O regulamento de execução privilegia identificadores formais. Para pessoas coletivas, o modelo prevê LEI ou EUID nos contextos definidos; outros tipos de prestador seguem as opções do próprio anexo. Uma entidade não deve inventar um identificador diferente em cada sistema ou alterar o tipo para contornar uma lacuna.

A resposta final da EBA à Q&A 2024_7285 esclarece que campos que compõem uma chave primária não podem ficar vazios. Quando apropriado, deve usar-se a indicação prevista de não aplicável; noutros campos, a ausência pode ser tecnicamente aceite, mas continua a ser um problema de qualidade de dados.

Isto cria dois gates distintos: validade estrutural, que impede carregar um ficheiro incoerente, e qualidade material, que impede aceitar uma submissão incapaz de explicar risco, dependências ou cobertura.

Construir uma arquitetura de dados, não uma campanha anual

O registo degrada-se quando é montado apenas antes da entrega. Contratos mudam no jurídico, serviços mudam na tecnologia, faturas revelam fornecedores que compras não classificou, e subcontratantes surgem em anexos ou portais externos.

Defina uma fonte de autoridade por atributo e uma regra de reconciliação. Compras não deve decidir criticidade operacional; a CMDB não deve inventar termos contratuais; risco não deve manter sozinho a identidade jurídica. O produto final pode ser gerado a partir de várias fontes, mas cada campo precisa de dono e linhagem.

• Bloquear contratos TIC sem identificadores, serviço, dono e cláusula de subcontratação estruturáveis.
• Reconciliar prestadores com contas a pagar para encontrar contratos ou serviços fora do inventário.
• Ligar funções críticas ou importantes à análise de impacto e aos serviços que as suportam.
• Versionar taxonomia, regras, transformações e exceções usadas em cada submissão.
• Testar saída e substituição onde concentração, dados ou dependências tornam a migração material.