Blog · 21 de maio de 2026

Construir um Registo de Auditoria DORA com Webhooks Didit (PT-PT)

O DORA exige que as empresas financeiras comprovem o que aconteceu, quando e a quem, nos seus sistemas TIC. Veja como construir um registo de auditoria à prova de adulteração a partir dos webhooks de verificação da Didit — com.

Por Didit21 de maio de 2026Atualizado 21/05/2026

O Digital Operational Resilience Act (DORA) coloca às entidades financeiras uma questão enganosamente difícil: conseguem provar o que aconteceu? Quando um supervisor investiga um incidente, quando um auditor avalia os seus controlos, ou quando um cliente contesta uma decisão de integração, necessita de um registo — completo, com carimbo de tempo e à prova de adulteração — de cada evento nos seus sistemas de Tecnologia de Informação e Comunicação (TIC). A verificação de identidade é um desses sistemas, e gera exatamente os eventos que precisa de capturar.

Este post é prático: como transformar os webhooks de verificação e transação da Didit num registo de auditoria pronto para DORA, o que armazenar e como garantir que resiste ao escrutínio. Inclui um exemplo de webhook prático que pode usar hoje mesmo.

Principais conclusões

O DORA exige provas — um registo fiável de eventos de TIC para resposta a incidentes, testes de resiliência e revisão supervisória.
A Didit emite eventos de webhook em cada mudança de estado significativa: status.updated, data.updated, transaction.status.updated e business.status.updated.
Cada evento é um facto discreto e com carimbo de tempo que anexa a um registo imutável — o pilar de um registo de auditoria.
Verifique a assinatura de cada webhook, armazene o payload bruto e nunca altere um registo — a regra é apenas anexar.
Os próprios controlos da Didit apoiam o registo: SOC 2 Tipo 1 (ATOM), ISO/IEC 27001:2022 (cert nº ES144068) e iBeta Nível 1 PAD — garantia ao nível do fornecedor para o seu registo de terceiros TIC.
O resultado satisfaz tanto o registo do que aconteceu que o DORA exige, como a prova de quem é este que sustenta o controlo de acesso.

O que a norma exige

O DORA assenta em cinco pilares: gestão de riscos de TIC, comunicação de incidentes, testes de resiliência operacional digital, partilha de informação e gestão de riscos de terceiros de TIC. Um registo de auditoria é o tecido conjuntivo que os liga. Especificamente, as entidades financeiras precisam de:

Detetar, registar e comunicar incidentes relacionados com as TIC — o que pressupõe um registo granular o suficiente para reconstruir o que aconteceu.
Testar a resiliência, incluindo a capacidade de rastrear transações e eventos através do sistema.
Gerir o risco de terceiros, incluindo os registos que advêm de um fornecedor como um fornecedor de verificação de identidade.
Reter registos num formato que os supervisores possam solicitar e em que possam confiar.

Os requisitos implícitos de um registo de auditoria utilizável decorrem disto: os eventos devem ser completos (sem lacunas silenciosas), precisos (fiéis ao que ocorreu), ordenados por tempo (com carimbos de tempo fiáveis), atribuíveis (ligados a um sujeito e a um ator) e à prova de adulteração (pode provar que um registo não foi alterado posteriormente).

Porquê é importante

Quando ocorre um incidente — uma suspeita de apropriação de conta, uma verificação contestada, uma transação sinalizada — a diferença entre um evento contido e um problema regulatório é muitas vezes a qualidade dos seus registos. Um registo completo permite-lhe reconstruir a sequência, provar que os seus controlos funcionaram conforme o esperado e demonstrar a um supervisor que lidou com a situação corretamente. Um registo incompleto deixa-o a adivinhar e o supervisor pouco convencido.

Os eventos de identidade são de alto valor aqui porque se situam na fronteira do sistema: o momento em que uma pessoa é verificada, re-verificada ou tem o seu estado alterado é exatamente o momento que mais deseja registado. Capturar esses eventos à medida que acontecem — em vez de os reconstruir posteriormente a partir de registos de aplicações — é o que transforma “achamos que isto foi o que aconteceu” em “aqui está o que aconteceu”.

Como a Didit ajuda

A Didit emite um webhook para cada transição de estado numa sessão de verificação, transação ou negócio. Não faz polling; recebe um evento assinado no momento em que algo muda.

Evento	Dispara quando	Valor de auditoria
`status.updated`	Uma sessão de verificação muda de estado (por exemplo, para `Approved`, `Declined`, `In Review`)	Regista a decisão e o seu momento
`data.updated`	Os dados verificados numa sessão mudam	Regista o que foi capturado/alterado
`transaction.status.updated`	O estado de uma transação monitorizada muda	Regista decisões de monitorização e resoluções de analistas
`business.status.updated`	O estado de uma entidade comercial KYB muda (`ACTIVE`/`FLAGGED`/`BLOCKED`)	Regista os resultados da integração de negócios

Cada evento é um facto autónomo. A sua tarefa é verificá-lo, armazená-lo como está e nunca alterá-lo. Juntos, esses eventos formam um livro-razão apenas de adição de tudo o que a Didit fez em seu nome — o registo de auditoria que o DORA exige para a parte de verificação de identidade dos seus sistemas de TIC.

E como a própria Didit é atestada — SOC 2 Tipo 1 (ATOM, a partir de 09/04/2026), ISO/IEC 27001:2022 (Bureau Veritas, cert nº ES144068, válido até 03/06/2027) e iBeta Nível 1 PAD — o fornecedor por trás desses eventos possui as suas próprias provas para o seu registo de terceiros DORA TIC.

Análise aprofundada: transformar um webhook num registo de auditoria

Aqui está um webhook status.updated para uma sessão de verificação que acabou de ser resolvida para Approved:

{
  "event": "status.updated",
  "session_id": "sess_7b21e0c4",
  "vendor_data": "user_4521",
  "status": "Approved",
  "previous_status": "In Review",
  "workflow_id": "wf_kyc_eu_substantial",
  "checks": {
    "id_verification": "passed",
    "passive_liveness": "passed",
    "face_match": "passed"
  },
  "created_at": "2026-05-21T10:32:04Z",
  "signature": "t=1747824724,v1=9f86d081884c7d659a..."
}

Para transformar isso num registo de auditoria pronto para DORA, faça quatro coisas ao recebê-lo:

Verifique a assinatura. Recalcule o HMAC sobre o corpo da requisição bruta usando o segredo de assinatura do seu endpoint e compare-o com o cabeçalho signature antes de confiar no payload. Rejeite qualquer coisa que falhe — um evento não verificado não tem valor probatório.
Armazene o payload bruto na íntegra. Persista os bytes exatos que recebeu, juntamente com o seu próprio carimbo de tempo de ingestão. Não normalize nem reformate antes do armazenamento; o evento bruto é a prova.
Anexe, nunca atualize. Escreva para um armazenamento apenas de adição (ou uma tabela sem permissões de UPDATE/DELETE para a função da aplicação). Se um evento posterior substituir um anterior, escreva uma nova linha referenciando o session_id antigo — nunca sobrescreva.
Torne-o à prova de adulteração. Faça um hash de cada registo e encadeie o hash no próximo (cada linha armazena o hash da linha anterior), ou escreva para um armazenamento de escrita única. Agora pode provar que o registo não foi alterado posteriormente.

O resultado é um livro-razão cronológico, atribuível e à prova de adulteração: para qualquer session_id pode reproduzir cada mudança de estado, ver quais verificações passaram e mostrar exatamente quando a decisão foi tomada — e provar que o registo não foi tocado desde então. Esse é o padrão que um supervisor ou auditor procura, e é o mesmo padrão que aplicaria a transaction.status.updated para decisões de monitorização e business.status.updated para resultados de KYB.

Casos de uso

Bancos e EMIs a construir um registo de eventos TIC alinhado com o DORA que inclui decisões de identidade.
VASPs de Cripto que devem comprovar decisões de integração e monitorização de transações aos supervisores.
Equipas de Conformidade a preparar-se para testes de resiliência que rastreiam eventos de ponta a ponta.
Equipas de Engenharia a substituir o polling frágil pela ingestão de eventos assinados e apenas de adição.

Perguntas frequentes

Que eventos de webhook devo capturar para um registo de auditoria?

No mínimo status.updated e data.updated para verificações; adicione transaction.status.updated para monitorização de transações e business.status.updated para KYB. Capture todos os eventos — a completude é o objetivo.

Preciso de verificar as assinaturas dos webhooks?

Sim. Um webhook não verificado pode ser falsificado e não tem peso probatório. Recalcule a assinatura sobre o corpo bruto e rejeite as discrepâncias antes de registar.

Porquê apenas anexar? Não posso simplesmente atualizar um registo quando o estado muda?

O DORA valoriza a prova de adulteração. Se sobrescrever registos, não pode provar que o histórico não foi alterado. Anexar um novo evento para cada alteração preserva a sequência completa e comprovável.

A captura dos eventos da Didit satisfaz todo o DORA?

Não — o DORA é abrangente. Os eventos da Didit cobrem a parte de verificação e monitorização de identidade dos seus sistemas de TIC. Irá combiná-los com registos dos seus outros sistemas para um registo completo.

A Didit tem as suas próprias certificações para o registo de terceiros DORA?

Sim — SOC 2 Tipo 1 (ATOM), ISO/IEC 27001:2022 (cert nº ES144068, válido até 03/06/2027) e iBeta Nível 1 PAD, todos disponíveis para apoiar a sua due diligence de fornecedor.

Pronto para começar?

Veja as certificações da Didit no hub de confiança, leia os detalhes de integração do webhook na documentação e reveja os preços transparentes na página de preços. Quando estiver pronto, comece gratuitamente — 500 verificações KYC gratuitas todos os meses, com um fluxo de verificação principal a partir de 0,33€.