Creación de un registro de auditoría compatible con DORA mediante webhooks de Didit (ES-1)

La Ley de Resiliencia Operativa Digital (DORA) plantea a las entidades financieras una pregunta engañosamente difícil: ¿puede probar lo que sucedió? Cuando un supervisor investiga un incidente, cuando un auditor examina sus controles o cuando un cliente disputa una decisión de incorporación, usted necesita un registro —completo, con marca de tiempo y a prueba de manipulaciones— de cada evento en sus sistemas de Tecnología de la Información y la Comunicación (TIC). La verificación de identidad es uno de esos sistemas, y genera exactamente los eventos que necesita capturar.

Esta publicación es la práctica: cómo convertir los webhooks de verificación y transacciones de Didit en un registro de auditoría compatible con DORA, qué almacenar y cómo hacer que resista el escrutinio. Incluye un ejemplo de webhook trabajado sobre el que puede construir hoy mismo.

Puntos clave

• DORA espera pruebas —un registro fiable de eventos TIC para la respuesta a incidentes, las pruebas de resiliencia y la revisión supervisora.
• Didit emite eventos de webhook en cada cambio de estado significativo: status.updated, data.updated, transaction.status.updated y business.status.updated.
• Cada evento es un hecho discreto y con marca de tiempo que se añade a un registro inmutable, el pilar de un registro de auditoría.
• Verifique la firma de cada webhook, almacene la carga útil sin procesar y nunca modifique un registro guardado; la regla es solo añadir.
• Los propios controles de Didit respaldan el registro: SOC 2 Tipo 1 (ATOM), ISO/IEC 27001:2022 (cert. n.º ES144068) e iBeta Nivel 1 PAD —garantía a nivel de proveedor para su registro de terceros TIC.
• El resultado satisface tanto el registro de lo que sucedió que DORA desea como la prueba de quién es esta persona que sustenta el control de acceso.

Lo que exige la norma

DORA se basa en cinco pilares: gestión de riesgos TIC, notificación de incidentes, pruebas de resiliencia operativa digital, intercambio de información y gestión de riesgos de terceros TIC. Un registro de auditoría es el tejido conectivo entre ellos. Específicamente, las entidades financieras deben:

• Detectar, registrar y notificar incidentes relacionados con las TIC —lo que presupone un registro lo suficientemente granular como para reconstruir lo sucedido.
• Probar la resiliencia, incluida la capacidad de rastrear transacciones y eventos a través del sistema.
• Gestionar el riesgo de terceros, incluidos los registros que provienen de un proveedor como un proveedor de verificación de identidad.
• Conservar los registros en un formulario que los supervisores puedan solicitar y en el que puedan confiar.

Los requisitos implícitos de un registro de auditoría utilizable se derivan de esto: los eventos deben ser completos (sin lagunas silenciosas), precisos (fieles a lo que ocurrió), ordenados cronológicamente (con marcas de tiempo fiables), atribuibles (vinculados a un sujeto y un actor) y a prueba de manipulaciones (se puede demostrar que un registro no se alteró después del hecho).

Por qué es importante

Cuando ocurre un incidente (un presunto robo de cuenta, una verificación disputada, una transacción marcada), la diferencia entre un evento contenido y un problema regulatorio suele ser la calidad de sus registros. Un registro completo le permite reconstruir la secuencia, demostrar que sus controles funcionaron según lo diseñado y demostrar a un supervisor que lo manejó correctamente. Un registro parcial lo deja adivinando y deja al supervisor poco convencido.

Los eventos de identidad son de alto valor aquí porque se encuentran en el límite del sistema: el momento en que una persona es verificada, verificada nuevamente o cambia su estado es exactamente el momento que más desea registrar. Capturar esos eventos a medida que ocurren, en lugar de reconstruirlos más tarde a partir de los registros de la aplicación, es lo que convierte "creemos que esto es lo que sucedió" en "aquí está lo que sucedió".

Cómo ayuda Didit

Didit emite un webhook para cada transición de estado en una sesión de verificación, transacción o negocio. No se sondea; se recibe un evento firmado en el momento en que algo cambia.

Evento	Se activa cuando	Valor de auditoría
status.updated	Una sesión de verificación cambia de estado (por ejemplo, a Approved, Declined, In Review)	Registra la decisión y su momento
data.updated	Los datos verificados de una sesión cambian	Registra lo que se capturó/cambió
transaction.status.updated	El estado de una transacción monitoreada cambia	Registra las decisiones de monitoreo y las resoluciones de los analistas
business.status.updated	El estado de una entidad comercial KYB cambia (ACTIVE/FLAGGED/BLOCKED)	Registra los resultados de la incorporación de negocios

Cada evento es un hecho autocontenido. Su trabajo es verificarlo, almacenarlo sin procesar y nunca cambiarlo. Juntos, esos eventos forman un libro mayor de solo añadir de todo lo que Didit hizo en su nombre, el registro de auditoría que DORA desea para la parte de verificación de identidad de su patrimonio TIC.

Y debido a que Didit mismo está certificado —SOC 2 Tipo 1 (ATOM, a partir del 09/04/2026), ISO/IEC 27001:2022 (Bureau Veritas, certificado n.º ES144068, válido hasta el 03/06/2027) e iBeta Nivel 1 PAD—, el proveedor detrás de esos eventos lleva su propia evidencia para su registro de terceros TIC de DORA.

Análisis profundo: convertir un webhook en un registro de auditoría

Aquí hay un webhook status.updated para una sesión de verificación que acaba de resolverse como 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 convertir eso en un registro de auditoría listo para DORA, haga cuatro cosas al recibirlo:

1. Verifique la firma. Recalcule el HMAC sobre el cuerpo de la solicitud sin procesar utilizando el secreto de firma de su punto final y compárelo con el encabezado signature antes de confiar en la carga útil. Rechace cualquier cosa que falle: un evento no verificado no tiene valor probatorio.
2. Almacene la carga útil sin procesar textualmente. Persista los bytes exactos que recibió, junto con su propia marca de tiempo de ingesta. No normalice ni reforme antes del almacenamiento; el evento sin procesar es la evidencia.
3. Añada, nunca actualice. Escriba en un almacén de solo añadir (o una tabla sin permisos de UPDATE/DELETE para el rol de la aplicación). Si un evento posterior reemplaza uno anterior, escriba una nueva fila que haga referencia al session_id antiguo, nunca sobrescriba.
4. Haga que sea a prueba de manipulaciones. Hash cada registro y encadene el hash en el siguiente (cada fila almacena el hash de la fila anterior), o escriba en un almacén de solo escritura. Ahora puede probar que el registro no fue alterado después del hecho.

El resultado es un libro mayor cronológico, atribuible y a prueba de manipulaciones: para cualquier session_id, puede reproducir cada cambio de estado, ver qué controles pasaron y mostrar exactamente cuándo se tomó la decisión, y probar que el registro no se ha tocado desde entonces. Ese es el estándar que busca un supervisor o un auditor, y es el mismo patrón que aplicaría a transaction.status.updated para las decisiones de monitoreo y a business.status.updated para los resultados de KYB.

Casos de uso

• Bancos y EMIs que construyen un registro de eventos TIC alineado con DORA que incluye decisiones de identidad.
• VASPs de criptomonedas que deben evidenciar las decisiones de incorporación y monitoreo de transacciones a los supervisores.
• Equipos de cumplimiento que se preparan para pruebas de resiliencia que rastrean eventos de principio a fin.
• Equipos de ingeniería que reemplazan el sondeo frágil con la ingesta de eventos firmados y de solo añadir.

Preguntas frecuentes

¿Qué eventos de webhook debo capturar para un registro de auditoría?

Como mínimo status.updated y data.updated para verificaciones; añada transaction.status.updated para el monitoreo de transacciones y business.status.updated para KYB. Capture cada evento: la integridad es el objetivo.

¿Necesito verificar las firmas de los webhooks?

Sí. Un webhook no verificado podría ser falsificado y no tiene peso probatorio. Recalcule la firma sobre el cuerpo sin procesar y rechace las discrepancias antes de registrar.

¿Por qué solo añadir? ¿No puedo simplemente actualizar un registro cuando cambia el estado?

DORA valora la evidencia de manipulación. Si sobrescribe registros, no puede probar que el historial no fue alterado. Añadir un nuevo evento para cada cambio preserva la secuencia completa y demostrable.

¿La captura de eventos de Didit satisface todo DORA?

No, DORA es amplio. Los eventos de Didit cubren la parte de verificación de identidad y monitoreo de su patrimonio TIC. Los combinará con los registros del resto de sus sistemas para un registro completo.

¿Didit tiene sus propias certificaciones para el registro de terceros de DORA?

Sí, SOC 2 Tipo 1 (ATOM), ISO/IEC 27001:2022 (cert. n.º ES144068, válido hasta el 03/06/2027) e iBeta Nivel 1 PAD, todos disponibles para respaldar su diligencia debida del proveedor.

¿Listo para empezar?

Vea las certificaciones de Didit en el centro de confianza, lea los detalles de integración de webhooks en la documentación y revise los precios transparentes en la página de precios. Cuando esté listo, empiece gratis: 500 verificaciones KYC gratuitas cada mes, con un flujo de verificación central desde $0.33.