Was DORA Artikel 30 von Verträgen mit IKT-Dienstleistern verlangt
Wer im Finanzsektor Software betreibt oder an Finanzunternehmen liefert, kennt das Muster seit dem 17. Januar 2025: Die Verordnung (EU) 2022/2554 (DORA) zwingt Banken, Versicherer, Zahlungsdienstleister und viele ihrer Zulieferer, die IKT-Lieferkette nicht mehr nur technisch, sondern vertraglich zu beherrschen. DORA Artikel 30 ist dabei die Norm, an der sich Einkauf, Recht, IT-Sicherheit und Produktteams am häufigsten reiben, denn sie legt fest, was in einem Vertrag über IKT-Dienstleistungen mindestens stehen muss.
Artikel 30 Absatz 2 gilt für alle vertraglichen Vereinbarungen über IKT-Dienstleistungen. Vereinfacht gesagt müssen Verträge die Funktionen und Dienste klar beschreiben, die Standorte nennen, an denen Daten verarbeitet und gespeichert werden, Regeln zum Schutz personenbezogener Daten enthalten, Zugang, Wiederherstellung und Rückgabe von Daten im Insolvenzfall sichern, Servicelevel beschreiben, Unterstützung bei IKT-Vorfällen regeln, die Zusammenarbeit mit Aufsichtsbehörden festschreiben sowie Kündigungsrechte und Ausstiegsstrategien definieren. Absatz 3 legt für Dienste, die kritische oder wichtige Funktionen unterstützen, noch einmal nach: umfassendere Servicelevel mit präzisen quantitativen und qualitativen Zielen, Berichtspflichten, Notfallpläne, Teilnahme an Tests und Prüfrechte.
Für einen ISV, der eine Signaturfunktion in seine Plattform einbaut, ergibt sich daraus eine unbequeme Doppelrolle. Gegenüber dem Finanzkunden ist er selbst IKT-Drittdienstleister. Gegenüber seinem Signaturanbieter ist er der Auftraggeber, der Lieferkettenfragen seiner Kunden weiterreichen muss. Ein Finanzunternehmen, das Ihre SaaS einsetzt, fragt irgendwann nicht mehr nur: „Ist die Signatur rechtsgültig?“, sondern: „Wo liegen die Daten, wer hat Zugriff, wie belegen Sie, dass der Vorgang so abgelaufen ist, wie vertraglich zugesagt?“
Genau an dieser Stelle trennt sich Vertragsprosa von prüffähigem Nachweis. Ein Vertrag kann zusagen, dass Standorte offengelegt werden. Ob die Verarbeitung tatsächlich dort stattfand, zeigt erst ein Protokoll, das Ereignisse unveränderlich festhält und von außen abfragbar ist. Dieser Unterschied zwischen Zusage und Beleg ist die eine harte Unterscheidung dieses Beitrags, und er bestimmt, wie Sie eine Signatur-API im DORA-Kontext bewerten sollten.
Wichtig vorab: DORA kennt keine Zertifizierung für Signatur-APIs. Es gibt kein Siegel, das Sie von einem Anbieter kaufen und dann „DORA-konform“ nennen dürfen. Was es gibt, ist die Pflicht der Finanzunternehmen, Drittparteirisiken zu steuern, ein Informationsregister zu führen und im Prüfungsfall Nachweise vorzulegen. Alles, was wir im Folgenden beschreiben, ist deshalb Evidence für diese Nachweise und keine Zertifizierung. Wer etwas anderes verspricht, liefert dem Kunden im Audit eine Behauptung, die sich nicht halten lässt.
Warum Papier, PDF-Ablage und Portal-Logins im Audit scheitern
Die meisten Signaturprozesse in Finanz- und Versicherungs-SaaS sind historisch gewachsen. Ein Vertrag wird erzeugt, an ein externes Portal übergeben, der Unterzeichner klickt sich dort durch, und am Ende landet ein PDF samt Zertifikatsseite in einem Ablageordner oder als Anhang im CRM. Für den Alltag funktioniert das. Für eine DORA-nahe Prüfung entstehen drei Lücken, die sich nicht mit mehr Disziplin schließen lassen, weil sie in der Architektur liegen.
Erstens fehlt die Verknüpfung zwischen Vertragsinhalt und Ablauf. Ein PDF zeigt, was unterschrieben wurde, aber nicht, wer wann welche Aufforderung erhalten hat, in welcher Reihenfolge Unterzeichner agierten, ob ein Vorgang abgebrochen und neu gestartet wurde oder welche Version eines Dokuments zu welchem Zeitpunkt gültig war. Prüfer fragen aber genau nach dem Ablauf, weil er zeigt, ob Kontrollen tatsächlich wirken.
Zweitens liegt der Beleg beim Anbieter, nicht bei Ihnen. Wenn Ereignisprotokolle nur im Portal des Signaturanbieters einsehbar sind, hängt Ihr Nachweis an dessen Login, dessen Retention und dessen Exportfunktion. Sobald ein Auditor eine lückenlose Kette über mehrere Monate verlangt, beginnt manuelles Screenshot-Sammeln. Das ist weder skalierbar noch revisionssicher, und es ist genau das, was Artikel 30 mit seinen Anforderungen an Zugang, Rückgabe und Zusammenarbeit mit Behörden zu vermeiden sucht.
Drittens bleibt die Jurisdiktion unsichtbar. Der Vertrag nennt vielleicht ein Rechenzentrum in der EU. Wem der Betreiber gehört und welches Recht auf ihn zugreifen kann, steht oft nicht im Auditpaket. Mit unserem Beitrag zu DSGVO und US Cloud Act bei E-Signatur-APIs haben wir diese Frage bereits aufgeschlüsselt. Für DORA kommt hinzu, dass Standort und Kontrolle als Vertragsbestandteil dokumentiert und belegt werden sollen.
Portal-Lösungen verschärfen das Problem, weil sie den Prozess aus Ihrem Produkt herausziehen. Der Nutzer verlässt Ihre Oberfläche, Ihre Ereignisse und die des Anbieters leben in getrennten Systemen, und die Korrelation passiert später per Hand. Wer die Hintergründe zum Bruch zwischen Host-System und Signaturstrecke vertiefen will, findet sie im Beitrag über White-label Signatur ohne Medienbruch. Im DORA-Kontext ist der Medienbruch nicht nur ein UX-Thema, sondern eine Beweislücke.
Ein kurzes Beispiel aus der Praxis: Ein ISV für Maklerverwaltung liefert Beratungsprotokolle an Versicherer. Im Prüfungsgespräch fragt der Kunde, ob nachvollziehbar ist, dass eine bestimmte Vollmacht erst nach der Identifikation des Unterzeichners signiert wurde und dass das Dokument zwischen Versand und Unterschrift nicht verändert wurde. Mit Portal und PDF-Ablage kann der ISV die Frage nur mit einem Verfahrenshinweis beantworten. Mit einem API-gestützten Ereignisprotokoll beantwortet er sie mit einem Export.
Hinzu kommt der Faktor Zeit. Prüfungen finden selten dann statt, wenn ein Team ohnehin Luft hat. Wer Nachweise erst im Anlassfall zusammensucht, bindet Entwicklung, Support und Rechtsabteilung gleichzeitig, und die Qualität der Antworten hängt davon ab, wer sich noch an einen Vorgang erinnert. Ein strukturierter Ereignisbestand verschiebt diese Arbeit in den Normalbetrieb: Sie definieren einmal, welche Daten anfallen, und jede spätere Anfrage ist eine Abfrage statt eines Projekts. Gerade für kleinere ISVs, die viele Finanzkunden mit begrenzten Ressourcen bedienen, ist dieser Unterschied oft die Grenze zwischen tragbarem und untragbarem Compliance-Aufwand.
Der API-Audit-Trail als Evidence Layer für die IKT-Lieferkette
Ein Evidence Layer ist keine Zertifizierung und kein Ersatz für Ihr Informationsregister. Er ist die technische Schicht, die dafür sorgt, dass jede relevante Aussage im Vertrag mit einem abrufbaren Datenpunkt unterlegt werden kann. Bei einer Signatur-API besteht diese Schicht aus drei Elementen: strukturierte Ereignisse pro Vorgang, eindeutige Kennungen, die Ereignisse mit Ihrem Fachobjekt verknüpfen, und ein Zugriff, der in Ihren eigenen Systemen landet, statt im Portal des Anbieters zu verbleiben.
Konkret heißt das: Jeder Signaturvorgang erzeugt Zustandswechsel wie angelegt, versendet, geöffnet, identifiziert, signiert, abgelehnt, abgelaufen oder widerrufen. Diese Wechsel übermittelt die API per Webhook an Ihr System, mit Zeitstempel und Vorgangskennung. Sie speichern sie in Ihrer eigenen Datenhaltung, gemeinsam mit Mandant, Dokumentversion und Prüfsumme. Wie Sie das sauber modellieren, ohne Ihr ERP mit Polling zu belasten, beschreiben wir im Beitrag zu Webhook State Management für E-Signatur-Events.
Aus Sicht von Artikel 30 entstehen dadurch belastbare Antworten auf typische Prüfungsfragen. Welche Dienste erbringt der Anbieter genau? Die API-Dokumentation und die dokumentierten Ereignistypen beschreiben die Funktionen maschinenlesbar. Wo werden Daten verarbeitet? Das Hosting ist vertraglich und technisch benannt, und Sie können es in Ihrem Informationsregister festhalten. Wie werden Vorfälle gemeldet? Fehler- und Statusereignisse sind Teil des Protokolls. Wie funktioniert der Ausstieg? Weil Ereignisse und Dokumente über die API exportierbar sind, hängt Ihre Beweisführung nicht an einem proprietären Portal.
Entscheidend ist die Trennung der Rollen. Die Signaturstufe richtet sich nach dem Anwendungsfall: SES für einfache Zustimmungen, AES, wenn Unterzeichner eindeutig zugeordnet und Änderungen erkennbar sein müssen, QES, wenn das Gesetz die qualifizierte Form verlangt. Sign2x ist kein qualifizierter Vertrauensdiensteanbieter. Für QES läuft die Qualifikation über einen Partner-QTSP wie Sign8. Der Evidence Layer dokumentiert in allen drei Fällen den Ablauf, er verändert aber nicht die rechtliche Qualität der Signatur. Eine Übersicht dazu bietet der Beitrag SES, AES und QES in SaaS.
Ein Punkt, den Teams oft unterschätzen: Der Trail ist nur so gut wie sein Schema. Wenn Ihr Ereignismodell nur „signiert“ und „nicht signiert“ kennt, liefert es kaum Evidence. Sinnvoll sind mindestens die Felder Vorgangs-ID, Ereignistyp, Zeitpunkt in UTC, handelnde Rolle, Dokument-Hash, Signaturstufe und das Ergebnis der Identifikation, soweit eine solche stattfand. Mit diesen Feldern können Sie im Prüfungsfall Fragen nach Reihenfolge, Zuständigkeit und Integrität beantworten, ohne personenbezogene Inhalte über das nötige Maß hinaus zu verteilen.
Das Video zeigt, wie sich die Signaturstrecke in eine bestehende Oberfläche einfügt und welche Ereignisse dabei entstehen. Für das Thema dieses Beitrags sind besonders die Zustandswechsel interessant: Sie sind der Rohstoff Ihres Audit-Trails.
Hosting und Jurisdiktion als Teil der Beweiskette
Wo ein Signaturdienst läuft und wem er gehört, ist bei DORA keine Fußnote. Artikel 30 verlangt die Nennung der Länder und Regionen, in denen Dienste erbracht und Daten verarbeitet werden. Für Finanzunternehmen kommt die Konzentrationsrisiko-Perspektive hinzu: Je stärker kritische Funktionen an einen einzelnen Anbieter oder eine einzelne Jurisdiktion gebunden sind, desto genauer wird hingesehen.
Sign2x läuft auf der Open Sovereign Cloud (OSC) von T-Systems. Für Ihre Beweiskette ist das aus zwei Gründen relevant. Erstens lässt sich der Standort konkret benennen und in Ihr Register eintragen. Zweitens unterliegt der Betrieb europäischem Recht und nicht der Reichweite von Gesetzen wie dem US Cloud Act. Warum bloße EU-Rechenzentren das Jurisdiktionsproblem nicht lösen, erklärt der kompakte Beitrag Cloud Act vs Datensouveränität, die technische Tiefe liefert der Artikel zur Open Sovereign Cloud für die E-Signatur-API.
Aus der Perspektive eines Auditors zählt, dass Sie die Aussage zum Hosting nicht nur als Marketingsatz, sondern als Vertragsbestandteil mit konkretem Betreiber vorlegen können. Ergänzend sollten Sie dokumentieren, welche Datenkategorien in der Signaturstrecke anfallen: Dokumentinhalte, Metadaten zu Unterzeichnern, Ereignisprotokolle, gegebenenfalls Ergebnisse einer Identifikation durch einen Partner. Je klarer diese Kategorien, desto einfacher lässt sich beschreiben, was wo liegt und wie lange es aufbewahrt wird.
Ebenso wichtig ist, was wir nicht behaupten. Hosting auf OSC macht Ihr Produkt nicht automatisch DORA-konform, und es ersetzt weder Ihre eigene Risikoanalyse noch das Informationsregister Ihres Kunden. Es beseitigt aber eine typische Schwachstelle im Auditgespräch, nämlich die offene Frage nach Eigentum und Zugriffsrecht. Wer die Bausteine im Zusammenhang sehen möchte, findet sie im Beitrag Cloud Act und Open Sovereign Cloud bei E-Signatur.
Für ISVs mit Mandantenmodell ergibt sich eine weitere Konsequenz. Wenn Sie White-label ausliefern, sollte der Standort für alle Mandanten identisch und dokumentiert sein, oder Sie müssen Abweichungen je Mandant sauber nachweisen können. Das spricht für ein einheitliches Hosting-Fundament und gegen individuelle Sonderwege, die im Audit niemand mehr überblickt. Mehr zur Mandantenfähigkeit lesen Sie im Beitrag Whitelabel-Anforderungen für ISVs.
Von der Vertragsklausel zum Datenpunkt: ein Mapping für Artikel 30
Der schnellste Weg, Artikel 30 greifbar zu machen, ist ein Mapping von Vertragsklauseln auf Datenpunkte. Nehmen Sie jede Anforderung und fragen Sie: Welche Zeile in welchem System würde ein Prüfer sehen, wenn er den Beleg verlangt? Wo die Antwort „keine“ lautet, haben Sie eine Lücke, die sich oft mit wenig Aufwand schließen lässt, weil die API die nötigen Ereignisse bereits liefert.
Die Leistungsbeschreibung lässt sich über die API-Spezifikation und die dokumentierten Ereignistypen belegen. Das ist robuster als eine Textbeschreibung im Vertrag, weil die Spezifikation versioniert ist und Änderungen nachvollziehbar werden. Die Standortangabe stützt sich auf das benannte Hosting und Ihre Dokumentation der Datenkategorien. Die Vorfallunterstützung zeigt sich in Status- und Fehlerereignissen sowie in dem Weg, auf dem Ihr Anbieter Störungen kommuniziert. Der Ausstieg wird durch einen getesteten Vollexport belegt, nicht durch den Satz „Daten werden auf Anfrage herausgegeben“.
Besonders lohnend ist das Mapping für die Servicelevel. Viele Verträge nennen Verfügbarkeitsziele, aber niemand misst sie aus Sicht des Kunden. Wenn Ihre Signaturstrecke über Webhooks und Statusabfragen läuft, können Sie eigene Messpunkte setzen: Zeit von der Anlage bis zum Versand, Zeit bis zur Bereitstellung des signierten Dokuments, Fehlerquote je Ereignistyp. Das sind Ihre Zahlen, aus Ihren Systemen, und sie taugen im Gespräch mit dem Finanzkunden mehr als eine Zusage ohne Messung. Wir nennen bewusst keine Durchsatzzahlen, denn sie hängen von Ihrer Last, Ihrem Dokumentprofil und Ihrer Integration ab und sollten in Ihrem Umfeld gemessen werden.
Das Informationsregister nach Artikel 28 profitiert ebenfalls. Es verlangt strukturierte Angaben zu IKT-Verträgen, Dienstleistern und unterstützten Funktionen. Wenn Sie als ISV Ihren Kunden ein sauberes Datenblatt zur Signaturstrecke liefern, das Funktion, Stufen, Standort, Rollenverteilung und Exportmöglichkeiten enthält, sparen Sie deren Einkauf Rückfragen und sich selbst Zeit in jedem Vertragszyklus. Ein solches Datenblatt ist kein Zertifikat, aber ein verlässlicher Rohstoff für fremde Register.
Schließlich lohnt der Blick auf Unterbeauftragung. Artikel 30 und die ergänzenden technischen Standards betonen die Kette: Wenn Ihr Signaturanbieter wiederum Partner einsetzt, etwa einen QTSP für QES oder einen Identifikationsdienst, gehört diese Kette in die Dokumentation. Beschreiben Sie, welche Rolle jeder Beteiligte hat und welche Daten an ihn fließen. Weil Sign2x eine API-Schicht ist und keine Qualifikation selbst ausstellt, ist diese Beschreibung bei uns ungewöhnlich klar: API und Orchestrierung hier, Qualifikation beim Partner. Die Hintergründe zu dieser Rollenteilung finden Sie im Beitrag GwG, Ident und QTSP bei E-Signatur.
Zum Abschluss dieses Mappings eine nüchterne Einschätzung: Kein Mapping ersetzt die Risikobewertung Ihres Kunden. Es verkürzt aber den Weg von der Frage zum Beleg erheblich. Teams, die diese Arbeit einmal gemacht haben, berichten üblicherweise, dass die größte Veränderung nicht im Audit selbst liegt, sondern im Alltag: Support, Vertrieb und Compliance greifen auf dieselben Ereignisdaten zu und diskutieren nicht mehr über Screenshots.
Checkliste für ISVs: Evidence vor dem Audit vorbereiten
Die folgende Checkliste ist kein Rechtsrat und ersetzt keine Prüfung durch Ihre Compliance-Abteilung. Sie hilft aber, die Technik so aufzustellen, dass Artikel-30-Fragen Ihrer Kunden in Stunden statt in Wochen beantwortbar sind.
- Funktionen beschreiben: Halten Sie fest, welche Signaturfunktionen Sie nutzen, welche Stufen (SES, AES, QES) Sie anbieten und wo ein Partner-QTSP beteiligt ist.
- Standorte benennen: Tragen Sie Hosting auf der Open Sovereign Cloud und gegebenenfalls Partnerstandorte in Ihre Lieferkettendokumentation ein.
- Ereignisse persistieren: Speichern Sie Webhook-Ereignisse in Ihrer eigenen Datenhaltung, mit Vorgangs-ID, UTC-Zeit, Rolle und Dokument-Hash.
- Export prüfen: Testen Sie, ob Sie Dokumente und Protokolle in einem dokumentierten Format vollständig exportieren können, auch als Ausstiegsszenario.
- Vorfälle abbilden: Definieren Sie, welche Fehler- und Statusereignisse Sie als meldepflichtig oder berichtsrelevant einstufen, und wie sie bei Ihnen auflaufen.
- Rollen trennen: Dokumentieren Sie, wer Signaturstufe, Identifikation und Qualifikation verantwortet. Sign2x liefert die API-Schicht, die Qualifikation für QES kommt vom Partner-QTSP.
- Tests einplanen: Nehmen Sie die Signaturstrecke in Ihre Resilienztests und Notfallübungen auf, sofern sie kritische oder wichtige Funktionen berührt.
Ein Wort zur Priorisierung: Beginnen Sie mit dem Ereignisschema. Alle anderen Punkte hängen davon ab, dass Sie überhaupt strukturierte Daten besitzen. Verträge und Registereinträge lassen sich nachziehen, Ereignisse aus der Vergangenheit nicht. Wer heute startet, sammelt ab heute Evidence. Planen Sie dafür kein Großprojekt ein: Ein Webhook-Endpunkt, ein Schema mit sieben bis acht Feldern und eine Tabelle in Ihrer Datenhaltung reichen für den Anfang völlig aus, und alles Weitere wächst mit den Fragen Ihrer Kunden.
Wenn Sie Ihre Ausgangslage strukturiert bewerten möchten, hilft der Sign2x Quiz bei der Einordnung von Anforderungen, und im Help Center finden Sie die Grundlagen zu Ereignissen und Statusmodellen. Anwendungsfälle aus regulierten Branchen bündeln wir unter Use Cases, weitere Fachbeiträge im Sign2x Blog. Für ein konkretes Gespräch über Ihre Lieferkettenfragen steht Ihnen der Developer Hub mit Sandbox und Dokumentation offen.
Wenn Sie wissen möchten, welche Nachweise Ihre Signaturstrecke heute schon liefert und wo Lücken bleiben, sprechen Sie mit uns. Wir sagen Ihnen auch, was wir nicht leisten.
Gespräch zu Ihrer DORA-Lieferkette anfragen
Weitere Perspektiven zum selben Thema: der Beitrag zu NIS-2 und dem Audit-Trail der Signatur zeigt, wie sich DORA und NIS-2 bei der Evidence ergänzen. Die Rolle des Partner-QTSP erläutert der Beitrag zu QTSP-Partnern für ISVs. Die rechtlichen Grundlagen der Signaturstufen finden Sie in der eIDAS-Verordnung, Hinweise zur Informationssicherheit beim BSI.
Häufige Fragen
Gibt es eine DORA-Zertifizierung für Signatur-APIs?
Nein. DORA sieht keine Zertifizierung für Signatur-APIs vor. Finanzunternehmen müssen Drittparteirisiken steuern und Nachweise führen. Ein API-Audit-Trail liefert Evidence für diese Nachweise, ist aber selbst kein Zertifikat.
Was verlangt DORA Artikel 30 bei IKT-Verträgen konkret?
Artikel 30 verlangt unter anderem klare Leistungsbeschreibungen, Angaben zu Verarbeitungsstandorten, Datenschutzregeln, Zugang und Rückgabe von Daten, Servicelevel, Unterstützung bei Vorfällen, Zusammenarbeit mit Behörden sowie Kündigungs- und Ausstiegsregeln. Für kritische oder wichtige Funktionen gelten zusätzliche Anforderungen.
Ist Sign2x ein qualifizierter Vertrauensdiensteanbieter?
Nein. Sign2x ist die API-Schicht. Für QES läuft die Qualifikation über einen Partner-QTSP, etwa Sign8. SES und AES sind je nach Anwendungsfall ebenfalls abbildbar.
Wo wird die Sign2x-Plattform gehostet?
Auf der Open Sovereign Cloud (OSC) von T-Systems. Der Standort lässt sich in der Lieferkettendokumentation und im Informationsregister benennen.
Welche Daten sollte ein Audit-Trail mindestens enthalten?
Vorgangs-ID, Ereignistyp, Zeitpunkt in UTC, handelnde Rolle, Dokument-Hash, Signaturstufe und das Ergebnis einer Identifikation, soweit eine stattfand. Speichern Sie diese Daten in Ihrer eigenen Datenhaltung.
