Creació d'un Registre d'Auditoria Preparat per DORA amb Webhooks de Didit (CA)

La Llei de Resiliència Operativa Digital (DORA) planteja a les entitats financeres una pregunta enganyosament difícil: pots provar què va passar? Quan un supervisor investiga un incident, quan un auditor examina els teus controls, o quan un client qüestiona una decisió d'incorporació, necessites un registre —complet, amb segell de temps i a prova de manipulacions— de cada esdeveniment en els teus sistemes de Tecnologia de la Informació i la Comunicació (TIC). La verificació d'identitat és un d'aquests sistemes, i genera exactament els esdeveniments que necessites capturar.

Aquesta publicació és la pràctica: com convertir els webhooks de verificació i transacció de Didit en un registre d'auditoria preparat per DORA, què s'ha d'emmagatzemar i com fer que superi l'escrutini. Inclou un exemple de webhook detallat amb el qual pots començar a construir avui mateix.

Punts clau

• DORA espera proves — un registre fiable d'esdeveniments TIC per a la resposta a incidents, proves de resiliència i revisió supervisora.
• Didit emet esdeveniments de webhook en cada canvi d'estat significatiu: status.updated, data.updated, transaction.status.updated i business.status.updated.
• Cada esdeveniment és un fet discret i amb segell de temps que s'afegeix a un registre immutable — el pilar d'un registre d'auditoria.
• Verifica la signatura de cada webhook, emmagatzema la càrrega útil original i mai modifiquis un registre guardat — la regla és només afegir.
• Els controls de Didit avalen el registre: SOC 2 Tipus 1 (ATOM), ISO/IEC 27001:2022 (certificat núm. ES144068) i iBeta Nivell 1 PAD — garantia de proveïdor per al teu registre de tercers TIC.
• El resultat satisfà tant el registre de què va passar que DORA vol com la prova de qui és aquest que sustenta el control d'accés.

Què exigeix l'estàndard

DORA es basa en cinc pilars: gestió de riscos TIC, notificació d'incidents, proves de resiliència operativa digital, intercanvi d'informació i gestió de riscos de tercers TIC. Un registre d'auditoria és el teixit connectiu entre ells. Específicament, les entitats financeres han de:

• Detectar, registrar i informar d'incidents relacionats amb les TIC — la qual cosa pressuposa un registre prou granular per reconstruir el que va passar.
• Provar la resiliència, inclosa la capacitat de rastrejar transaccions i esdeveniments a través del sistema.
• Gestionar el risc de tercers, inclosos els registres que provenen d'un proveïdor com ara un proveïdor de verificació d'identitat.
• Conservar els registres en una forma que els supervisors puguin sol·licitar i confiar.

Els requisits implícits d'un registre d'auditoria utilitzable es deriven d'això: els esdeveniments han de ser complets (sense llacunes silencioses), precisos (fidels al que va ocórrer), ordenats per temps (amb segells de temps fiables), atribuïbles (vinculats a un subjecte i un actor) i a prova de manipulacions (pots demostrar que un registre no va ser alterat després del fet).

Per què és important

Quan ocorre un incident —una suposada presa de control de compte, una verificació disputada, una transacció marcada— la diferència entre un esdeveniment contingut i un problema regulatori sovint rau en la qualitat dels teus registres. Un registre complet et permet reconstruir la seqüència, provar que els teus controls van funcionar com estava previst i demostrar a un supervisor que ho vas gestionar correctament. Un registre incomplet et deixa amb dubtes i al supervisor sense convèncer.

Els esdeveniments d'identitat són de gran valor aquí perquè se situen a la frontera del sistema: el moment en què una persona és verificada, re-verificada o el seu estat canvia és exactament el moment que més vols registrar. Capturar aquests esdeveniments a mesura que succeeixen —en lloc de reconstruir-los més tard a partir dels registres d'aplicació— és el que converteix "creiem que això és el que va passar" en "aquí teniu el que va passar".

Com Didit ajuda

Didit emet un webhook per a cada transició d'estat en una sessió de verificació, transacció o negoci. No has de fer consultes; reps un esdeveniment signat en el moment en què alguna cosa canvia.

Esdeveniment	S'activa quan	Valor d'auditoria
status.updated	Una sessió de verificació canvia d'estat (p. ex., a Aprovat, Rebutjat, En Revisió)	Registra la decisió i el seu moment
data.updated	Canvien les dades verificades d'una sessió	Registra el que es va capturar/canviar
transaction.status.updated	Canvia l'estat d'una transacció monitoritzada	Registra les decisions de monitorització i les resolucions de l'analista
business.status.updated	Canvia l'estat d'una entitat de negoci KYB (ACTIU/MARCAT/BLOQUEJAT)	Registra els resultats d'incorporació de negocis

Cada esdeveniment és un fet autònom. La teva tasca és verificar-lo, emmagatzemar-lo tal qual i no modificar-lo mai. Junts, aquests esdeveniments formen un llibre de comptes només d'afegir de tot el que Didit va fer en nom teu — el registre d'auditoria que DORA vol per a la secció de verificació d'identitat del teu patrimoni TIC.

I com que Didit mateix està acreditat — SOC 2 Tipus 1 (ATOM, a partir del 09/04/2026), ISO/IEC 27001:2022 (Bureau Veritas, certificat núm. ES144068, vàlid fins al 03/06/2027) i iBeta Nivell 1 PAD — el proveïdor darrere d'aquests esdeveniments aporta les seves pròpies proves per al teu registre de tercers TIC de DORA.

Anàlisi en profunditat: convertint un webhook en un registre d'auditoria

Aquí teniu un webhook status.updated per a una sessió de verificació que acaba de resoldre's com a 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..."
}

Per convertir-lo en un registre d'auditoria preparat per DORA, fes quatre coses en rebre'l:

1. Verifica la signatura. Recalcula l'HMAC sobre el cos de la sol·licitud original utilitzant el secret de signatura del teu endpoint i compara-ho amb la capçalera signature abans de confiar en la càrrega útil. Rebutja qualsevol cosa que falli — un esdeveniment no verificat no té valor probatori.
2. Emmagatzema la càrrega útil original textualment. Persisteix els bytes exactes que vas rebre, juntament amb el teu propi segell de temps d'ingesta. No normalitzis ni reformateïs abans de l'emmagatzematge; l'esdeveniment original és la prova.
3. Afegeix, mai actualitzis. Escriu en un magatzem de només afegir (o una taula sense permisos UPDATE/DELETE per al rol de l'aplicació). Si un esdeveniment posterior reemplaça un d'anterior, escriu una nova fila referenciant l'antic session_id — mai sobrescriguis.
4. Fes-lo a prova de manipulacions. Hash cada registre i encadena el hash al següent (cada fila emmagatzema el hash de la fila anterior), o escriu en un magatzem d'escriptura única. Ara pots provar que el registre no va ser alterat després del fet.

El resultat és un llibre de comptes cronològic, atribuïble i a prova de manipulacions: per a qualsevol session_id pots reproduir cada canvi d'estat, veure quines comprovacions van passar i mostrar exactament quan es va prendre la decisió — i provar que el registre no s'ha tocat des de llavors. Aquest és l'estàndard que busca un supervisor o un auditor, i és el mateix patró que aplicaries a transaction.status.updated per a decisions de monitorització i business.status.updated per a resultats de KYB.

Casos d'ús

• Bancs i IMD que construeixen un registre d'esdeveniments TIC alineat amb DORA que inclou decisions d'identitat.
• VASPs de cripto que han de demostrar les decisions d'incorporació i monitorització de transaccions als supervisors.
• Equips de conformitat que es preparen per a proves de resiliència que rastregen esdeveniments de principi a fi.
• Equips d'enginyeria que reemplacen la consulta fràgil amb una ingesta d'esdeveniments signats i només d'afegir.

Preguntes freqüents

Quins esdeveniments de webhook hauria de capturar per a un registre d'auditoria?

Com a mínim status.updated i data.updated per a verificacions; afegeix transaction.status.updated per a la monitorització de transaccions i business.status.updated per a KYB. Captura cada esdeveniment — la completesa és l'objectiu.

He de verificar les signatures dels webhooks?

Sí. Un webhook no verificat podria ser suplantat i no té cap pes probatori. Recalcula la signatura sobre el cos original i rebutja les discrepàncies abans de registrar.

Per què només afegir? No puc simplement actualitzar un registre quan l'estat canvia?

DORA valora la prova de manipulació. Si sobrescrius registres, no pots provar que l'historial no va ser alterat. Afegir un nou esdeveniment per a cada canvi preserva la seqüència completa i provable.

La captura dels esdeveniments de Didit satisfà tot DORA?

No — DORA és àmplia. Els esdeveniments de Didit cobreixen la part de verificació d'identitat i monitorització del teu patrimoni TIC. Els combinaràs amb els registres de la resta dels teus sistemes per a un registre complet.

Didit té les seves pròpies acreditacions per al registre de tercers de DORA?

Sí — SOC 2 Tipus 1 (ATOM), ISO/IEC 27001:2022 (certificat núm. ES144068, vàlid fins al 03/06/2027) i iBeta Nivell 1 PAD, tots disponibles per donar suport a la teva diligència deguda amb proveïdors.

Llest per començar?

Consulta les acreditacions de Didit al centre de confiança, llegeix els detalls d'integració de webhooks a la documentació i revisa els preus transparents a la pàgina de preus. Quan estiguis llest, comença de franc — 500 verificacions KYC gratuïtes cada mes, amb un flux de verificació bàsic a partir de 0,33 dòlars.