DORA-konformen Audit-Trail mit Didit-Webhooks erstellen (DE)

Der Digital Operational Resilience Act (DORA) stellt Finanzunternehmen vor eine trügerisch schwierige Frage: Können Sie beweisen, was passiert ist? Wenn ein Aufseher einen Vorfall untersucht, ein Prüfer Ihre Kontrollen überprüft oder ein Kunde eine Onboarding-Entscheidung anficht, benötigen Sie eine vollständige, zeitgestempelte und manipulationssichere Aufzeichnung jedes Ereignisses in Ihren Informations- und Kommunikationstechnologie (IKT)-Systemen. Die Identitätsprüfung ist eines dieser Systeme, und sie erzeugt genau die Ereignisse, die Sie erfassen müssen.

Dieser Beitrag ist der praktische Teil: wie man Didits Verifizierungs- und Transaktions-Webhooks in einen DORA-konformen Audit-Trail verwandelt, was man speichern und wie man es auf Herz und Nieren prüfen kann. Er enthält ein ausgearbeitetes Webhook-Beispiel, das Sie noch heute nutzen können.

Wichtigste Erkenntnisse

• DORA erwartet Nachweise – eine zuverlässige Aufzeichnung von IKT-Ereignissen für die Reaktion auf Vorfälle, Resilienztests und aufsichtsrechtliche Überprüfungen.
• Didit sendet Webhook-Ereignisse bei jeder relevanten Statusänderung: status.updated, data.updated, transaction.status.updated und business.status.updated.
• Jedes Ereignis ist ein diskretes, zeitgestempeltes Faktum, das Sie an ein unveränderliches Protokoll anhängen – den Baustein eines Audit-Trails.
• Überprüfen Sie die Signatur jedes Webhooks, speichern Sie die Rohdaten und ändern Sie niemals einen protokollierten Datensatz – nur Anhängen ist die Regel.
• Didits eigene Kontrollen sichern den Trail ab: SOC 2 Typ 1 (ATOM), ISO/IEC 27001:2022 (Zertifikat Nr. ES144068) und iBeta Level 1 PAD – Anbieter-Level-Sicherheit für Ihr IKT-Drittanbieterregister.
• Das Ergebnis erfüllt sowohl die von DORA gewünschte Was-ist-passiert-Aufzeichnung als auch den Wer-ist-das-Nachweis, der die Zugriffssteuerung untermauert.

Was der Standard erfordert

DORA basiert auf fünf Säulen: IKT-Risikomanagement, Meldung von Vorfällen, Tests der digitalen operationellen Resilienz, Informationsaustausch und IKT-Drittparteien-Risikomanagement. Ein Audit-Trail ist das verbindende Element zwischen ihnen. Insbesondere müssen Finanzunternehmen:

• IKT-bezogene Vorfälle erkennen, protokollieren und melden – was eine Aufzeichnung voraussetzt, die detailliert genug ist, um das Geschehene zu rekonstruieren.
• Resilienz testen, einschließlich der Fähigkeit, Transaktionen und Ereignisse durch das System zu verfolgen.
• Drittparteienrisiken managen, einschließlich der Aufzeichnungen, die von einem Anbieter wie einem Identitätsprüfungsanbieter stammen.
• Aufzeichnungen aufbewahren in einer Form, die von Aufsichtsbehörden angefordert und herangezogen werden kann.

Die impliziten Anforderungen an einen nutzbaren Audit-Trail ergeben sich daraus: Ereignisse müssen vollständig (keine stillen Lücken), genau (getreu dem Geschehenen), zeitlich geordnet (mit zuverlässigen Zeitstempeln), zurechenbar (einem Subjekt und einem Akteur zugeordnet) und manipulationssicher sein (Sie können beweisen, dass ein Datensatz nachträglich nicht geändert wurde).

Warum es wichtig ist

Wenn ein Vorfall eintritt – eine vermutete Kontoübernahme, eine bestrittene Verifizierung, eine markierte Transaktion – ist der Unterschied zwischen einem eingedämmten Ereignis und einem regulatorischen Problem oft die Qualität Ihrer Aufzeichnungen. Ein vollständiger Trail ermöglicht es Ihnen, die Abfolge zu rekonstruieren, zu beweisen, dass Ihre Kontrollen wie vorgesehen funktioniert haben, und einem Aufseher zu zeigen, dass Sie den Vorfall ordnungsgemäß behandelt haben. Ein lückenhafter Trail lässt Sie raten und den Aufseher unüberzeugt.

Identitätsereignisse sind hier von hohem Wert, da sie an der Grenze des Systems liegen: Der Moment, in dem eine Person verifiziert, erneut verifiziert wird oder ihr Status sich ändert, ist genau der Moment, den Sie am meisten aufzeichnen möchten. Das Erfassen dieser Ereignisse, sobald sie geschehen – anstatt sie später aus Anwendungslogs zu rekonstruieren – verwandelt „Wir glauben, dass dies passiert ist“ in „Hier ist, was passiert ist.“

Wie Didit hilft

Didit sendet einen Webhook für jeden Statusübergang in einer Verifizierungs-, Transaktions- oder Geschäftssitzung. Sie fragen nicht ab; Sie erhalten ein signiertes Ereignis, sobald sich etwas ändert.

Ereignis	Löst aus, wenn	Audit-Wert
status.updated	Eine Verifizierungssitzung den Status ändert (z.B. zu Approved, Declined, In Review)	Zeichnet die Entscheidung und ihren Zeitpunkt auf
data.updated	Verifizierte Daten einer Sitzung sich ändern	Zeichnet auf, was erfasst/geändert wurde
transaction.status.updated	Der Status einer überwachten Transaktion sich ändert	Zeichnet Überwachungsentscheidungen und Analystenauflösungen auf
business.status.updated	Der Status einer KYB-Geschäftseinheit sich ändert (ACTIVE/FLAGGED/BLOCKED)	Zeichnet Ergebnisse des Geschäfts-Onboardings auf

Jedes Ereignis ist ein eigenständiges Faktum. Ihre Aufgabe ist es, es zu überprüfen, als Rohdaten zu speichern und niemals zu ändern. Zusammen bilden diese Ereignisse ein nur-anhängendes Hauptbuch von allem, was Didit in Ihrem Namen getan hat – den Audit-Trail, den DORA für den Identitätsverifizierungs-Teil Ihrer IKT-Infrastruktur verlangt.

Und da Didit selbst zertifiziert ist – SOC 2 Typ 1 (ATOM, Stand 09.04.2026), ISO/IEC 27001:2022 (Bureau Veritas, Zertifikat Nr. ES144068, gültig bis 03.06.2027) und iBeta Level 1 PAD – liefert der Anbieter hinter diesen Ereignissen eigene Nachweise für Ihr DORA IKT-Drittanbieterregister.

Deep Dive: Einen Webhook in einen Audit-Datensatz verwandeln

Hier ist ein status.updated Webhook für eine Verifizierungssitzung, die gerade als Approved abgeschlossen wurde:

{
  "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..."
}

Um dies in einen DORA-konformen Audit-Datensatz zu verwandeln, tun Sie bei Erhalt vier Dinge:

1. Überprüfen Sie die Signatur. Berechnen Sie den HMAC über den rohen Anforderungs-Body neu, indem Sie das Signaturgeheimnis Ihres Endpunkts verwenden, und vergleichen Sie ihn mit dem signature-Header, bevor Sie der Payload vertrauen. Lehnen Sie alles ab, was fehlschlägt – ein unbestätigtes Ereignis hat keinen Beweiswert.
2. Speichern Sie die Rohdaten wortgetreu. Speichern Sie die exakten Bytes, die Sie erhalten haben, zusammen mit Ihrem eigenen Erfassungszeitstempel. Normalisieren oder umformen Sie nicht vor der Speicherung; das rohe Ereignis ist der Beweis.
3. Anhängen, niemals aktualisieren. Schreiben Sie in einen nur-anhängenden Speicher (oder eine Tabelle ohne UPDATE/DELETE-Berechtigungen für die App-Rolle). Wenn ein späteres Ereignis ein früheres ersetzt, schreiben Sie eine neue Zeile, die auf die alte session_id verweist – überschreiben Sie niemals.
4. Machen Sie es manipulationssicher. Hashen Sie jeden Datensatz und verketten Sie den Hash mit dem nächsten (jede Zeile speichert den Hash der vorherigen Zeile) oder schreiben Sie in einen einmalig beschreibbaren Speicher. Jetzt können Sie beweisen, dass das Protokoll nachträglich nicht geändert wurde.

Das Ergebnis ist ein chronologisches, zurechenbares, manipulationssicheres Hauptbuch: Für jede session_id können Sie jede Statusänderung wiedergeben, sehen, welche Prüfungen bestanden wurden, und genau zeigen, wann die Entscheidung getroffen wurde – und beweisen, dass der Datensatz seitdem nicht verändert wurde. Das ist der Standard, den ein Aufseher oder Prüfer sucht, und es ist das gleiche Muster, das Sie auf transaction.status.updated für Überwachungsentscheidungen und business.status.updated für KYB-Ergebnisse anwenden würden.

Anwendungsfälle

• Banken und E-Geld-Institute, die ein DORA-konformes IKT-Ereignisprotokoll erstellen, das Identitätsentscheidungen enthält.
• Krypto-VASP, die Aufsichtsbehörden Onboarding- und Transaktionsüberwachungsentscheidungen nachweisen müssen.
• Compliance-Teams, die sich auf Resilienztests vorbereiten, die Ereignisse Ende-zu-Ende verfolgen.
• Engineering-Teams, die anfälliges Polling durch signiertes, nur-anhängendes Ereignis-Ingestion ersetzen.

Häufig gestellte Fragen

Welche Webhook-Ereignisse sollte ich für einen Audit-Trail erfassen?

Mindestens status.updated und data.updated für Verifizierungen; fügen Sie transaction.status.updated für die Transaktionsüberwachung und business.status.updated für KYB hinzu. Erfassen Sie jedes Ereignis – Vollständigkeit ist der Punkt.

Muss ich Webhook-Signaturen überprüfen?

Ja. Ein unbestätigter Webhook könnte gefälscht sein und hat keinen Beweiswert. Berechnen Sie die Signatur über den rohen Body neu und lehnen Sie Abweichungen vor der Protokollierung ab.

Warum nur anhängen? Kann ich einen Datensatz nicht einfach aktualisieren, wenn sich der Status ändert?

DORA legt Wert auf Manipulationssicherheit. Wenn Sie Datensätze überschreiben, können Sie nicht beweisen, dass die Historie nicht geändert wurde. Das Anhängen eines neuen Ereignisses für jede Änderung bewahrt die vollständige, nachweisbare Sequenz.

Deckt das Erfassen von Didits Ereignissen alle Anforderungen von DORA ab?

Nein – DORA ist umfassend. Didits Ereignisse decken den Bereich der Identitätsprüfung und Überwachung Ihrer IKT-Infrastruktur ab. Sie werden diese mit Protokollen aus dem Rest Ihrer Systeme für einen vollständigen Trail kombinieren.

Hat Didit eigene Zertifizierungen für das DORA-Drittanbieterregister?

Ja – SOC 2 Typ 1 (ATOM), ISO/IEC 27001:2022 (Zertifikat Nr. ES144068, gültig bis 03.06.2027) und iBeta Level 1 PAD, alle verfügbar zur Unterstützung Ihrer Anbieter-Due-Diligence.

Bereit zum Start?

Sehen Sie Didits Zertifizierungen im Trust Hub, lesen Sie die Details zur Webhook-Integration in der Dokumentation und überprüfen Sie die transparenten Preise auf der Preisseite. Wenn Sie bereit sind, starten Sie kostenlos – 500 kostenlose KYC-Prüfungen jeden Monat, mit einem Kern-Verifizierungsablauf ab 0,33 $.