使用Didit Webhook构建符合DORA要求的审计追踪

《数字运营韧性法案》(DORA) 向金融机构提出了一个看似简单实则棘手的问题：您能否证明发生了什么？当监管机构调查事件、审计师抽查您的控制措施或客户对入职决定提出异议时，您需要一份完整、带时间戳且防篡改的记录，记录下您的信息和通信技术 (ICT) 系统中的每一个事件。身份验证就是这些系统之一，它恰好会生成您需要捕获的事件。

本文是实践篇：如何将Didit的验证和交易Webhook转化为符合DORA要求的审计追踪，存储什么，以及如何使其经受住审查。它包含一个您可以立即开始构建的Webhook示例。

关键要点

• DORA期望有证据 — 用于事件响应、韧性测试和监管审查的ICT事件可靠记录。
• Didit在每个有意义的状态变更时发出Webhook事件：status.updated、data.updated、transaction.status.updated 和 business.status.updated。
• 每个事件都是一个独立的、带时间戳的事实，您将其附加到不可变日志中 — 这是审计追踪的构建块。
• 验证每个Webhook的签名，存储原始负载，并且永不修改已记录的记录 — 仅追加是规则。
• Didit自己的控制措施支持审计追踪：SOC 2 Type 1 (ATOM)、ISO/IEC 27001:2022 (证书编号 ES144068) 和 iBeta Level 1 PAD — 为您的ICT第三方注册提供供应商级别的保证。
• 结果既满足DORA要求的发生了什么的记录，也满足支撑访问控制的这是谁的证明。

标准要求

DORA建立在五个支柱之上：ICT风险管理、事件报告、数字运营韧性测试、信息共享和ICT第三方风险管理。审计追踪是连接它们的纽带。具体而言，金融机构需要做到：

• 检测、记录和报告ICT相关事件 — 这预设了足够细粒度的记录，以便重建事件。
• 测试韧性，包括通过系统追踪交易和事件的能力。
• 管理第三方风险，包括来自身份验证供应商等提供商的记录。
• 保留记录，以便监管机构可以请求并依赖。

可用审计追踪的隐含要求由此而来：事件必须完整（无静默空白）、准确（忠实于发生的事情）、按时间顺序排列（具有可靠的时间戳）、可归因（与主体和行为者相关联）和防篡改（您可以证明记录事后未被更改）。

为什么它很重要

当发生事件时——可疑的账户盗用、有争议的验证、被标记的交易——受控事件与监管问题之间的区别，通常在于您记录的质量。完整的追踪允许您重建序列，证明您的控制措施按预期发挥作用，并向监管机构证明您处理得当。零散的追踪会让您猜测，并让监管机构不相信。

身份事件在此处具有高价值，因为它们位于系统的边界：一个人被验证、重新验证或其状态改变的时刻，正是您最希望被记录的时刻。捕获这些事件的发生——而不是稍后从应用程序日志中重建——将“我们认为发生了什么”变成了“这就是发生了什么”。

Didit如何提供帮助

Didit针对验证、交易或业务会话中的每次状态转换都会发出一个Webhook。您无需轮询；一旦发生变化，您就会收到一个已签名的事件。

事件	触发时机	审计价值
status.updated	验证会话状态变更（例如变更为Approved、Declined、In Review）	记录决策及其时间
data.updated	会话上的已验证数据发生变化	记录捕获/更改的内容
transaction.status.updated	受监控交易的状态变更	记录监控决策和分析师解决方案
business.status.updated	KYB业务实体的状态变更（ACTIVE/FLAGGED/BLOCKED）	记录业务入职结果

每个事件都是一个自包含的事实。您的任务是验证它，按原样存储它，并且永不更改它。这些事件共同构成了Didit代表您所做的一切的仅追加账本——DORA希望为您的ICT资产中的身份验证部分提供审计追踪。

而且由于Didit本身已通过认证——SOC 2 Type 1 (ATOM，截至2026年4月9日)、ISO/IEC 27001:2022 (必维国际检验集团，证书编号ES144068，有效期至2027年6月3日) 和 iBeta Level 1 PAD——这些事件背后的提供商为您的DORA ICT第三方注册提供了自己的证据。

深入探讨：将Webhook转换为审计记录

这是一个status.updated Webhook，用于一个刚刚解析为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..."
}

要将其转换为符合DORA要求的审计记录，请在接收时执行四项操作：

1. 验证签名。使用您的端点签名密钥对原始请求正文重新计算HMAC，并将其与signature头进行比较，然后再信任负载。拒绝任何失败的事件——未经验证的事件没有证据价值。
2. 按原样存储原始负载。持久化您收到的确切字节，以及您自己的摄入时间戳。在存储之前不要进行规范化或重塑；原始事件就是证据。
3. 追加，永不更新。写入一个仅追加存储（或一个没有应用程序角色UPDATE/DELETE权限的表）。如果后面的事件取代了前面的事件，则写入一个引用旧session_id的新行——永不覆盖。
4. 使其防篡改。对每条记录进行哈希处理，并将哈希链接到下一条记录中（每行存储前一行的哈希），或写入一次性写入存储。现在您可以证明日志事后未被更改。

结果是一个按时间顺序、可归因、防篡改的账本：对于任何session_id，您都可以重播所有状态更改，查看通过了哪些检查，并准确显示决策是在何时做出的——并证明记录此后未被触动。这是监管机构或审计师正在寻找的标准，它与您将应用于transaction.status.updated（用于监控决策）和business.status.updated（用于KYB结果）的模式相同。

用例

• 银行和电子货币机构 (EMI) 正在构建包含身份决策的符合DORA的ICT事件日志。
• 加密资产服务提供商 (VASP) 必须向监管机构证明入职和交易监控决策。
• 合规团队 正在准备韧性测试，以端到端地追踪事件。
• 工程团队 正在用签名、仅追加的事件摄取取代脆弱的轮询。

常见问题

我应该捕获哪些Webhook事件用于审计追踪？

至少是验证的status.updated和data.updated；为交易监控添加transaction.status.updated，为KYB添加business.status.updated。捕获所有事件——完整性是关键。

我需要验证Webhook签名吗？

是的。未经验证的Webhook可能会被欺骗，并且没有证据 weight。在记录之前，请对原始正文重新计算签名并拒绝不匹配项。

为什么是仅追加？我不能在状态更改时只更新记录吗？

DORA重视防篡改。如果您覆盖记录，您就无法证明历史未被更改。为每次更改追加新事件可以保留完整、可证明的序列。

捕获Didit的事件是否能满足DORA的所有要求？

不能——DORA范围很广。Didit的事件涵盖了您的ICT资产的身份验证和监控部分。您需要将它们与您其余系统的日志结合起来，以获得完整的追踪。

Didit是否拥有DORA第三方注册的自有认证？

是的——SOC 2 Type 1 (ATOM)、ISO/IEC 27001:2022 (证书编号ES144068，有效期至2027年6月3日) 和 iBeta Level 1 PAD，所有这些都可用于支持您的供应商尽职调查。

准备好开始了吗？

请访问 信任中心 查看 Didit 的认证，在 文档 中阅读 Webhook 集成详情，并在 定价页面 查看透明定价。准备好后，免费开始 — 每月 500 次免费 KYC 检查，核心验证流程低至 0.33 美元。