Blog · 21 de maio de 2026

Construindo uma Trilha de Auditoria DORA-Ready com Webhooks Didit (PT-BR)

A DORA exige que empresas financeiras comprovem o que aconteceu, quando e com quem em seus sistemas de TIC. Veja como construir uma trilha de auditoria à prova de adulteração a partir dos webhooks de verificação da Didit — com.

Por Didit21 de maio de 2026Atualizado 21 de mai. de 2026

O Digital Operational Resilience Act (DORA) faz uma pergunta enganosamente difícil às entidades financeiras: você pode provar o que aconteceu? Quando um supervisor investiga um incidente, quando um auditor verifica seus controles, ou quando um cliente contesta uma decisão de onboarding, você precisa de um registro — completo, com carimbo de tempo e à prova de adulteração — de cada evento em seus sistemas de Tecnologia da Informação e Comunicação (TIC). A verificação de identidade é um desses sistemas, e gera exatamente os eventos que você precisa capturar.

Este post é o prático: como transformar os webhooks de verificação e transação da Didit em uma trilha de auditoria DORA-ready, o que armazenar e como fazer com que resista ao escrutínio. Inclui um exemplo de webhook trabalhado que você pode usar hoje.

Principais pontos

A DORA exige evidências — um registro confiável de eventos de TIC para resposta a incidentes, testes de resiliência e revisão supervisória.
A Didit emite eventos de webhook a cada mudança de estado significativa: status.updated, data.updated, transaction.status.updated e business.status.updated.
Cada evento é um fato discreto e com carimbo de tempo que você anexa a um log imutável — o bloco de construção de uma trilha de auditoria.
Verifique a assinatura de cada webhook, armazene o payload bruto e nunca altere um registro logado — somente anexar é a regra.
Os próprios controles da Didit apoiam a trilha: SOC 2 Tipo 1 (ATOM), ISO/IEC 27001:2022 (cert nº ES144068) e iBeta Nível 1 PAD — garantia de nível de fornecedor para seu registro de terceiros de TIC.
O resultado satisfaz tanto o registro de o que aconteceu que a DORA deseja quanto a prova de quem é este que sustenta o controle de acesso.

O que o padrão exige

A DORA é construída sobre cinco pilares: gestão de riscos de TIC, relatórios de incidentes, testes de resiliência operacional digital, compartilhamento de informações e gestão de riscos de terceiros de TIC. Uma trilha de auditoria é o tecido conectivo entre eles. Especificamente, as entidades financeiras precisam:

Detectar, registrar e relatar incidentes relacionados a TIC — o que pressupõe um registro 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.
Gerenciar o risco de terceiros, incluindo os registros que fluem de um provedor como um fornecedor de verificação de identidade.
Reter registros em um formato que os supervisores possam solicitar e confiar.

Os requisitos implícitos de uma trilha de auditoria utilizável decorrem disso: os eventos devem ser completos (sem lacunas silenciosas), precisos (fiéis ao que ocorreu), ordenados por tempo (com carimbos de tempo confiáveis), atribuíveis (vinculados a um sujeito e um ator) e à prova de adulteração (você pode mostrar que um registro não foi alterado após o fato).

Por que isso importa

Quando um incidente acontece — uma suspeita de tomada de conta, uma verificação contestada, uma transação sinalizada — a diferença entre um evento contido e um problema regulatório é frequentemente a qualidade de seus registros. Uma trilha completa permite reconstruir a sequência, provar que seus controles funcionaram conforme o planejado e demonstrar a um supervisor que você lidou com isso adequadamente. Uma trilha irregular deixa você adivinhando e o supervisor, não convencido.

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 seu status alterado é exatamente o momento que você mais deseja registrar. Capturar esses eventos à medida que acontecem — em vez de reconstruí-los mais tarde a partir de logs de aplicativos — é o que transforma “achamos que isso 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 em uma sessão de verificação, transação ou negócios. Você não faz polling; você recebe um evento assinado no momento em que algo muda.

Evento	Acionado quando	Valor de auditoria
`status.updated`	Uma sessão de verificação muda de status (ex: para `Aprovado`, `Recusado`, `Em Revisão`)	Registra a decisão e seu momento
`data.updated`	Dados verificados em uma sessão mudam	Registra o que foi capturado/alterado
`transaction.status.updated`	O status de uma transação monitorada muda	Registra decisões de monitoramento e resoluções de analistas
`business.status.updated`	O status de uma entidade comercial KYB muda (`ATIVO`/`SINALIZADO`/`BLOQUEADO`)	Registra os resultados do onboarding de negócios

Cada evento é um fato autocontido. Seu trabalho é verificá-lo, armazená-lo bruto e nunca alterá-lo. Juntos, esses eventos formam um livro-razão somente de acréscimo de tudo o que a Didit fez em seu nome — a trilha de auditoria que a DORA deseja para a fatia de verificação de identidade de seu patrimônio de TIC.

E porque 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 provedor por trás desses eventos carrega sua própria evidência para seu registro de terceiros de TIC DORA.

Aprofundando: transformando um webhook em um registro 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 em um registro de auditoria DORA-ready, 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 você recebeu, juntamente com seu próprio carimbo de data/hora de ingestão. Não normalize ou reformate antes do armazenamento; o evento bruto é a evidência.
Apenas anexe, nunca atualize. Escreva para um armazenamento somente de acréscimo (ou uma tabela sem permissões de UPDATE/DELETE para a função do aplicativo). 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 registro e encadeie o hash no próximo (cada linha armazena o hash da linha anterior), ou escreva em um armazenamento de escrita única. Agora você pode provar que o log não foi alterado após o fato.

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

Casos de uso

Bancos e EMIs construindo um log de eventos de TIC alinhado à DORA que inclui decisões de identidade.
VASPs de criptomoedas que devem evidenciar decisões de onboarding e monitoramento de transações para supervisores.
Equipes de conformidade preparando-se para testes de resiliência que rastreiam eventos de ponta a ponta.
Equipes de engenharia substituindo polling frágil por ingestão de eventos assinados e somente de acréscimo.

Perguntas frequentes

Quais eventos de webhook devo capturar para uma trilha de auditoria?

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

Preciso 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 inconsistências antes de registrar.

Por que somente acréscimo? Não posso simplesmente atualizar um registro quando o status muda?

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

A captura dos eventos da Didit satisfaz toda a DORA?

Não — a DORA é ampla. Os eventos da Didit cobrem a fatia de verificação e monitoramento de identidade de seu patrimônio de TIC. Você os combinará com logs do restante de seus sistemas para uma trilha completa.

A Didit possui suas próprias atestações para o registro de terceiros da 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 sua due diligence de fornecedores.

Pronto para começar?

Veja as atestações da Didit no hub de confiança, leia os detalhes de integração de webhook nos docs e revise 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 US$ 0,33.