DORA: registo de informação (modelo e guia)

O registo de informação exigido pelo artigo 28.º, n.º 3, da DORA é o inventário estruturado de todos os acordos contratuais relativos à utilização de serviços de TIC prestados por terceiros. Segue modelos normalizados fixados pelo Regulamento de Execução (UE) 2024/2956, é mantido ao nível da entidade e em base consolidada, e entrega-se ao supervisor — Banco de Portugal, CMVM ou ASF — num formato legível por máquina, pelo menos uma vez por ano.

Este guia dá-lhe a estrutura dos modelos das Autoridades Europeias de Supervisão, os campos a preencher e a razão por que o registo de atividades de tratamento do RGPD não serve como substituto.

Principais conclusões

• Base legal: art. 28.º, n.º 3, do Regulamento (UE) 2022/2554; formato fixado pelo Regulamento de Execução (UE) 2024/2956.
• O registo divide-se em blocos de modelos B_01 a B_07, ligados entre si por identificadores.
• Cada acordo tem de indicar se o serviço suporta uma função crítica ou importante — é este campo que determina a profundidade das restantes obrigações.
• A cadeia de subcontratação entra no registo, não apenas o fornecedor direto.
• Alimenta a designação europeia de prestadores críticos: é um reporte de supervisão, não documentação interna.

O que exige o artigo 28.º, n.º 3?

A norma obriga cada entidade financeira a manter e atualizar um registo sobre todos os acordos contratuais de utilização de serviços de TIC prestados por terceiros — ao nível da entidade e, quando aplicável, em base subconsolidada e consolidada — distinguindo os acordos que suportam funções críticas ou importantes dos restantes.

Sobre ele assentam três deveres: comunicar anualmente ao supervisor o número de novos acordos, as categorias de prestadores, os tipos de acordo e os serviços abrangidos; disponibilizar o registo, ou secções dele, sempre que a autoridade o solicite; e informar atempadamente qualquer acordo previsto relativo a funções críticas. Um registo desatualizado incumpre os três em simultâneo.

Que modelos usar? A estrutura do Regulamento (UE) 2024/2956

Os blocos não são folhas independentes: ligam-se por chaves — referência do acordo, código LEI do prestador, identificador da função. É por isso que a construção em folhas separadas falha quase sempre na validação: basta um identificador inconsistente para o ficheiro ser rejeitado.

Campo a campo: o que preencher

Dois campos merecem atenção desproporcionada. Função crítica ou importante: marcar «sim» aciona os requisitos contratuais reforçados do artigo 30.º, n.º 3, as exigências de auditoria e acesso, o plano de saída e a avaliação de concentração; marcar «não» sem fundamentação documentada é o achado mais comum numa inspeção. E a localização dos dados: o registo distingue o país onde os dados repousam do país a partir do qual são geridos, e tem de ser coerente com o que já declarou sobre transferências internacionais de dados.

Como se entrega o registo ao supervisor?

A entidade entrega o registo à sua autoridade competente — Banco de Portugal, CMVM ou ASF, consoante o setor — que o transmite às Autoridades Europeias de Supervisão (EBA, ESMA e EIOPA). A recolha é anual, reportada a uma data de referência fixada pelo supervisor, e o ficheiro tem de respeitar a estrutura e as validações do modelo europeu.

O destino do ficheiro explica o rigor exigido: é a partir dos registos agregados que as ESAs identificam concentrações e designam prestadores de TIC como críticos, sujeitando-os a supervisão europeia direta. Um registo com códigos LEI errados ou funções mal classificadas não é um problema meramente formal.

Em que difere do registo de atividades de tratamento do RGPD?

A confusão custa tempo em ambos os sentidos. Um prestador de manutenção de servidores sem acesso a dados pessoais entra no registo DORA e não no do RGPD; uma agência de marketing que trate dados de clientes sem prestar serviço de TIC entra no do RGPD e não no da DORA. Os prestadores que constam de ambos — o alojamento em nuvem é o caso típico — obrigam a documentação distinta: o contrato de subcontratação do artigo 28.º do RGPD não contém as cláusulas mínimas do artigo 30.º da DORA. O mesmo vale para as entidades do grupo abrangidas pela transposição da NIS2 em Portugal, que mantêm inventários próprios.

Erros frequentes

• Registar apenas o fornecedor direto. A cadeia de subcontratação relevante para funções críticas tem de constar do registo.
• Confundir signatário com utilizador. Quem assina o contrato (B_03) e quem usa efetivamente o serviço (B_04) são campos distintos e, em grupos, raramente coincidem.
• Deixar a criticidade por decidir. Sem avaliação datada e fundamentada, o campo B_07 não é preenchível de forma defensável.
• Ignorar contratos intragrupo. Os serviços de TIC prestados por outra entidade do grupo entram no registo (B_02.03).
• Construir o registo uma vez. É um reporte periódico, não um projeto: cada novo contrato ou aditamento altera o ficheiro.

Manter o registo vivo

O trabalho pesado não é a primeira versão — é manter a coerência entre contratos, funções e classificações ao longo do ano, com renovações, aditamentos e mudanças de subcontratantes. É o padrão que já conhece dos registos de proteção de dados, agravado por existir aqui um formato vinculativo e validação automática do lado do supervisor.

Isto separa quem gere o registo num ficheiro de quem o gere num sistema. Uma plataforma que mantenha fornecedores, contratos, funções e avaliações de criticidade ligados entre si e exporte no formato europeu — o que faz um software DORA orientado para o setor financeiro em Portugal — elimina a reconciliação manual anual. Para quem já usa software de conformidade RGPD, estender a base de fornecedores existente sai mais barato do que uma suite DORA autónoma; os intervalos de preço estão no nosso guia de custos.

Perguntas frequentes

Com que frequência se entrega o registo de informação?

Pelo menos uma vez por ano, à autoridade competente, reportado à data de referência que esta fixar. Além disso, o supervisor pode solicitar o registo, ou secções dele, a qualquer momento.

O registo abrange contratos com empresas do mesmo grupo?

Sim. Os acordos intragrupo de serviços de TIC têm modelo próprio (B_02.03) e contam para efeitos de criticidade e de concentração.

Uma folha de cálculo é suficiente?

Para começar a recolher informação, sim. Para entregar, não: o ficheiro tem de respeitar a estrutura, os identificadores e as validações dos modelos do Regulamento (UE) 2024/2956.

Um registo incompleto pode ser sancionado?

O incumprimento do artigo 28.º está sujeito aos poderes de supervisão e ao regime sancionatório nacional. Na prática, um registo incompleto sinaliza deficiências de governação e tende a alargar o âmbito da inspeção — ver o guia DORA completo quanto à responsabilidade do órgão de administração.

Conclusão

O registo de informação é a peça mais trabalhosa da DORA e a primeira que o supervisor pede. Construa-o pelos contratos, não pelos sistemas; documente a criticidade de cada função antes de preencher os campos que dela dependem; inclua a cadeia de subcontratação e os acordos intragrupo; e mantenha os identificadores coerentes entre blocos, porque é aí que a validação falha. Quem trata o registo como reporte periódico, e não como projeto concluído, chega à recolha anual sem trabalho extraordinário.