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
| Bloco | Conteúdo |
|---|---|
| B_01.01–B_01.03 | Entidade que mantém o registo, perímetro de consolidação, sucursais |
| B_02.01–B_02.03 | Acordos contratuais: informação geral, informação específica, acordos intragrupo |
| B_03.01–B_03.03 | Entidades signatárias dos contratos, do lado do cliente e do prestador |
| B_04.01 | Entidades que utilizam efetivamente os serviços de TIC |
| B_05.01–B_05.02 | Prestadores terceiros de TIC e cadeias de subcontratação |
| B_06.01 | Identificação das funções da entidade |
| B_07.01 | Avaliação dos serviços que suportam funções críticas ou importantes |
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
| Campo | Bloco | Descrição | Exemplo |
|---|---|---|---|
| LEI da entidade | B_01 | Identificador da entidade que mantém o registo | 5493001… |
| Referência do acordo | B_02 | Número interno único do contrato | CTR-2025-014 |
| Tipo de acordo | B_02 | Autónomo, quadro ou subsequente | Acordo-quadro |
| Data de início / termo | B_02 | Vigência contratual | 01-03-2025 / 28-02-2028 |
| Prazo de pré-aviso | B_02 | Denúncia pela entidade e pelo prestador | 90 / 180 dias |
| Lei aplicável | B_02 | Direito que rege o contrato | Portugal |
| Custo anual | B_02 | Despesa do último exercício e moeda | 84 000 EUR |
| Tipo de serviço de TIC | B_02 | Categoria da taxonomia do anexo do regulamento | Serviços de computação em nuvem |
| Identificação do prestador | B_05 | LEI ou EUID, denominação legal e comercial | LEI + firma |
| País da sede do prestador | B_05 | Jurisdição da sede social | Irlanda |
| Empresa-mãe do prestador | B_05 | Entidade que encabeça o grupo | — |
| Subcontratação | B_05 | Grau na cadeia e identificação dos subcontratantes relevantes | Grau 1, grau 2 |
| Função apoiada | B_06 | Identificador, designação e linha de negócio | Processamento de pagamentos |
| Função crítica ou importante | B_06/B_07 | Sim/não, com fundamentação e data da avaliação | Sim, 15-01-2026 |
| Armazenamento de dados | B_07 | Se há armazenamento, país de repouso e país de gestão | Sim / Irlanda / Portugal |
| Sensibilidade dos dados | B_07 | Nível atribuído aos dados tratados | Elevada |
| Substituibilidade | B_07 | Facilidade de substituição do prestador | Complexidade elevada |
| Plano de saída | B_07 | Existência, reintegração possível, prestadores alternativos | Sim |
| Última auditoria | B_07 | Data da última auditoria ou avaliação de risco | 30-11-2025 |
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?
| Registo de informação DORA | Registo de tratamentos (art. 30.º RGPD) | |
|---|---|---|
| Objeto | Acordos de serviços de TIC | Atividades de tratamento de dados pessoais |
| Unidade | Contrato e prestador | Finalidade do tratamento |
| Formato | Modelos vinculativos das ESAs | Livre |
| Entrega | Anual ao supervisor financeiro | Só a pedido da CNPD |
| Âmbito | Todos os serviços de TIC, com ou sem dados pessoais | Só tratamentos de dados pessoais |
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.