Registro de Auditoría DORA con Webhooks de Didit

La Ley de Resiliencia Operativa Digital (DORA) plantea a las entidades financieras una pregunta engañosamente difícil: ¿pueden probar lo que ocurrió? 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 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 transacción de Didit en un registro de auditoría listo para DORA, qué almacenar y cómo hacer que resista el escrutinio. Incluye un ejemplo de webhook trabajado sobre el que puede construir hoy.

Conclusiones clave

• DORA espera pruebas — un registro fiable de los eventos de 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 componente básico de un registro de auditoría.
• Verifique la firma de cada webhook, almacene la carga útil sin procesar y nunca modifique un registro. 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 de TIC.
• El resultado satisface tanto el registro de qué ocurrió que DORA desea como la prueba de quién es que sustenta el control de acceso.

Lo que exige la norma

DORA se basa en cinco pilares: gestión de riesgos de TIC, notificación de incidentes, pruebas de resiliencia operativa digital, intercambio de información y gestión de riesgos de terceros de 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 ocurrido.
• 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.
• Retener registros en un formato 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 ocurrido), 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 fue alterado después del hecho).

Por qué es importante

Cuando ocurre un incidente —una sospecha de toma de control de cuenta, una verificación disputada, una transacción marcada— la diferencia entre un evento contenido y un problema regulatorio es a menudo la calidad de sus registros. Un rastro completo le permite reconstruir la secuencia, probar que sus controles funcionaron según lo diseñado y demostrar a un supervisor que lo manejó correctamente. Un rastro incompleto lo deja adivinando y al supervisor sin convencer.

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, re-verificada o su estado cambia 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 un «creemos que esto es lo que sucedió» en un «esto es 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. Usted no consulta; recibe un evento firmado en el momento en que algo cambia.

Evento	Se dispara cuando	Valor de auditoría
status.updated	El estado de una sesión de verificación cambia (p. ej., a Aprobado, Rechazado, En revisión)	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 del analista
business.status.updated	El estado de una entidad comercial KYB cambia (ACTIVO/MARCADO/BLOQUEADO)	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 anexar de todo lo que Didit hizo en su nombre, el rastro de auditoría que DORA desea para la parte de verificación de identidad de su patrimonio de TIC.

Y debido a que Didit 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 tiene sus propias pruebas para su registro de terceros de TIC de DORA.

Inmersión profunda: 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 usando el secreto de firma de su endpoint 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 reformatee antes del almacenamiento; el evento sin procesar es la evidencia.
3. Solo anexar, nunca actualizar. Escriba en un almacén de solo anexar (o una tabla sin permisos de UPDATE/DELETE para el rol de la aplicación). Si un evento posterior anula uno anterior, escriba una nueva fila haciendo referencia al session_id anterior; nunca sobrescriba.
4. Hágalo 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 una sola 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é comprobaciones pasaron y mostrar exactamente cuándo se tomó la decisión, y probar que el registro no ha sido modificado 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 de 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 extremo a extremo.
• Equipos de ingeniería que reemplazan el polling 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 completitud es el objetivo.

¿Necesito verificar las firmas de los webhooks?

Sí. Un webhook no verificado podría ser falsificado y no tiene valor 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 los 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 los eventos de Didit satisface todas las exigencias de DORA?

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

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

Sí, SOC 2 Tipo 1 (ATOM), ISO/IEC 27001:2022 (certificado nº ES144068, válido hasta el 03-06-2027) e iBeta Nivel 1 PAD, todos disponibles para respaldar su debida diligencia 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, comience gratis — 500 verificaciones KYC gratuitas cada mes, con un flujo de verificación principal desde $0.33.