DORA Informationsregister für WordPress-Lieferanten: Pflichtfelder
Artikel 28(3) der Verordnung 2022/2554 verpflichtet jedes Finanzunternehmen, ein Informationsregister zu vertraglichen Vereinbarungen mit IKT-Drittparteidienstleistern zu führen und zu aktualisieren. Die Durchführungsverordnung (EU) 2024/2956 setzt die Feldstruktur: fünfzehn Tabellen mit benannten Spalten. Eine WordPress-Agentur, die eine Bank, einen Versicherer, ein Wertpapierdienstleistungsunternehmen oder ein Zahlungsinstitut beliefert, landet in diesem Register und muss die Daten rechtzeitig in der richtigen Form liefern.
Dies ist ein vertiefender Artikel innerhalb der NIS2 und DORA WordPress Säule, mit Querverweis zur DORA Artikel 28 Drittparteienrisiko-Erklärung.
TL;DR
- Fünfzehn Tabellen, gesetzt durch Durchführungsverordnung 2024/2956.
- Vereinbarungen über kritische oder wichtige Funktionen haben Zusatzspalten (Substituierbarkeit, Konzentrationsrisiko, Exit-Plan).
- Subkontraktorenketten transparent bis zur für das Finanzunternehmen relevanten Ebene.
- Die Agentur reicht das Register nicht ein; die Agentur speist es.
- Die meisten Agenturen verfehlen vier der fünfzehn Tabellen bei Erstabgabe.
Was das Finanzunternehmen einreicht
Gemäß Artikel 28(3) muss jedes Finanzunternehmen das Register mindestens jährlich an seine zuständige Behörde und die europäische Aufsichtsbehörde über das gemeinsame Reporting-Framework melden. Die Durchführungsverordnung 2024 definiert das Schema. Die fünfzehn Tabellen sind:
- Unternehmensinformationen.
- Niederlassungsinformationen.
- Tochtergesellschaftsinformationen.
- IKT-Dienstleistungen.
- Funktionsidentifikation.
- Vertragliche Vereinbarungen.
- Funktionen der vertraglichen Vereinbarung.
- IKT-Dienstleistungen der vertraglichen Vereinbarung.
- Risiko der vertraglichen Vereinbarung.
- Subkontraktoren.
- Kündigungsbestimmungen.
- Standorte.
- Verantwortliche Personen oder Stellen.
- Vereinbarungen für kritische oder wichtige Funktionen.
- Konzentrationsvereinbarungen (gruppenweit).
Eine WordPress-Agentur erscheint typisch in Tabellen 4, 6, 8, 9, 10, 11, 12, 14. Tabellen 1-3, 5, 7, 13 gehören dem Finanzunternehmen. Tabelle 15 ist selten und nur, wenn die Agentur eine Muttergesellschaft hat oder häufig in der Gruppe liefert.
Was die WordPress-Agentur liefern muss
Pro IKT-Dienstleistung (Tabelle 4) und pro vertraglicher Vereinbarung (Tabelle 6) liefert die Agentur die Spalten, die das Finanzunternehmen ins Register überträgt. Die nicht-erschöpfende Praxisliste:
- Dienstleistungsbeschreibung: WordPress-Hosting, Plugin-Entwicklung, Headless-Frontend, Support, Sicherheitsaudits - pro Posten, nicht ein Sammelposten.
- Lieferantenname und LEI: der Legal Entity Identifier der Agentur. Eine kleine WordPress-Agentur ohne LEI muss vor Vertragsabschluss einen erwerben.
- Eintragungsland und Hauptsitz.
- Gruppenzugehörigkeit: Mutter, Tochter, Schwesterfirmen.
- Erbrachte Dienstleistungen: welche Produkte berührt werden, mit Kritikalitätsflagge.
- Verarbeitete Daten: Kundendaten, Transaktionsdaten, Mitarbeiterdaten, keine.
- Datenstandorte: Land und Rechenzentrumsanbieter pro Speicherebene (Produktion, Backup, Log-Archiv).
- Subprocessor: jeder Lieferant, den die Agentur zur Erbringung nutzt (Cloudflare, Sentry, Deployment-Plattform, Monitoring, KI-APIs).
- Subprocessor-Jurisdiktionen: Land und anwendbares Recht pro Subprocessor.
Tabelle 11 (Kündigungsbestimmungen) verlangt von der Agentur:
- Kündigungsfrist für das Finanzunternehmen.
- Kündigungsfrist für die Agentur.
- Auslöser für vorzeitige Kündigung durch das Finanzunternehmen.
- Exit-Plan: wie das Finanzunternehmen Daten und Betrieb zurückbekommt.
Tabelle 14 (kritische oder wichtige Funktion) verlangt zusätzliche Evidenz, wenn die WordPress-Dienstleistung eine kritische oder wichtige Funktion stützt. Substituierbarkeitsbewertung, Konzentrationsrisiko, Exit-Plan mit realistischen Zeiten, regelmäßiger Testkalender.
Was die meisten WordPress-Agenturen verfehlen
Fünf wiederkehrende Lücken aus Lieferanten-Reviews 2025-2026:
LEI nicht beschafft. Eine WordPress-Agentur ohne Legal Entity Identifier verzögert Vertrag und Register. LEIs kosten ungefähr eine Domain-Verlängerung pro Jahr. Es gibt keinen Grund, ohne LEI zu arbeiten, wenn man regulierte Finanzkunden bedient.
Subprocessor-Liste unvollständig. Cloudflare ist gelistet; Sentry ist gelistet; der KI-Anbieter für redaktionelle Tools, der E-Mail-Relay-Anbieter, die Deployment-Plattform und der Off-Site-Backup-Speicher werden vergessen. Das Register fällt durch das Review und die Agentur läuft erneut durch Beschaffung.
Exit-Plan ist ein Absatz. “Wir übergeben Daten auf Anfrage” ist kein Exit-Plan. Das Finanzunternehmen braucht Übergabetage geschätzt, Datenformate, Source-Code-Repository-Übergabe, Runbook-Übergabe, Abhängigkeitsliste und Konten-Stilllegungsverfahren. Mindestens drei Seiten, idealerweise versioniert.
Fehlender Backup-Testnachweis. Artikel 11 DORA verlangt regelmäßige Tests operativer Resilienz einschließlich Restore. Die Agentur ohne Quartalsrestore-Log fällt im Lieferanten-Review beim ersten Audit.
Keine Bewertung als kritische Funktion. Die Agentur behauptet “wir sind nicht kritisch”, weil die WordPress-Site “nur Marketing” ist. Die Konformitäts-Abteilung des Finanzunternehmens widerspricht, weil ein Marken-Ausfall Kundenvertrauen schadet. Klärt das früh im Vertrag, nicht während des Audits.
Wie man sich auf die erste Aufnahme vorbereitet
Eine praktische Checkliste für eine WordPress-Agentur vor dem ersten Register:
- LEI besorgen, falls fehlend.
- Subprocessor inventarisieren, mit Land und anwendbarem Recht pro Anbieter.
- Versionierten Exit-Plan schreiben: Daten, Code, Runbook, Konten.
- Datenstandorte pro Speicherebene und pro Subprocessor dokumentieren.
- Vollständigen Restore aus Off-Site-Backup testen; Zeitstempel, Dauer und Ergebnis loggen.
- Erbrachte Dienstleistungen auf Funktionen des Finanzunternehmens mappen; kritisch oder wichtig flaggen.
- Substituierbarkeits-Statement entwerfen: welche Konkurrenten ersetzen euren Dienst, in wie vielen Wochen.
- Quartals-Review-Kadenz starten: jedes Quartal Daten auffrischen, abzeichnen, ablegen.
Vor dem ersten Vertrag erledigt zahlt sich diese Vorbereitung mehrfach aus. Während des ersten Audits erledigt verdoppelt sie die Beauftragungskosten.
Feldinventar mit stabilen Kennungen aufbauen
Der Register-Feed ist ein kontrollierter Datenbestand, kein Fragebogen aus dem Gedächtnis. Legen Sie je Rechtsträger, Vereinbarung, IKT-Dienstleistung, unterstützter Funktion, Standort und relevanter Unterauftragsbeziehung einen Datensatz an. Jedes Objekt erhält eine stabile interne Kennung. Namen und Verträge ändern sich; die Kennung verbindet Versionen ohne unsicheren Namensvergleich.
Zu jedem Feld gehören Definition, Format, erlaubte Werte, Pflichtstatus im verwendeten Template, Quellsystem, Eigentümer und Nachweis. “Nicht anwendbar”, “unbekannt” und leer sind unterschiedliche Zustände. Datumswerte, Länderkennungen und rechtliche Namen müssen dem geforderten Format folgen. LEI oder andere Identifikatoren dürfen nicht erfunden werden. Das Finanzunternehmen bestätigt, welcher Identifikatortyp und welche Validierung im aktuellen Meldetemplate verlangt werden.
Quellsysteme und Datenherkunft
Die Informationen stammen aus mehreren Bereichen. Beschaffung hält Vertrag und Nachträge. Recht verantwortet Kündigungs-, Prüf-, Unterauftrags- und Exit-Klauseln. Finance führt den Lieferantenstamm. Security und Architektur ordnen Dienste den Systemen und Funktionen zu. Datenschutz kennt Datenkategorien und Verarbeitungsorte. Die Agentur liefert Unternehmensidentität, Leistungsumfang, Subunternehmer, Betriebsorte und Exit-Unterlagen.
Für jedes Ausgabefeld wird die Herkunft festgehalten: Quelldokument oder System, Quellfeld, Abrufdatum, Transformationsregel und Prüfer. Stammt das Startdatum aus einem Nachtrag statt dem Rahmenvertrag, muss das sichtbar sein. Werden mehrere Plugin-Abonnements zu einem Dienst gebündelt, wird die Freigabe dokumentiert. So werden Korrekturen reproduzierbar und Tabellenwerte bleiben belegbar.
Quellbelege liegen geschützt beim Datensatz: unterschriebene Vertragsversion, Lieferantenerklärung, Architekturdiagramm, genehmigte Standortliste und Änderungsmitteilung. Der Zugriff ist beschränkt, weil das Paket Sicherheitsarchitektur, Kontakte und Vertragsbedingungen enthalten kann.
Eigentum und Änderungsrhythmus
Das Finanzunternehmen bleibt für sein Register verantwortlich. Ein Registereigentümer steuert Schema und Abgabekalender. Vertragseigentümer prüfen Vereinbarungen und Funktionen. Security validiert Dienst- und Abhängigkeitszuordnung. Beschaffung verfolgt Lieferantenantworten. Die WordPress-Agentur benennt einen Dateneigentümer und eine Vertretung für strukturierte Rückfragen und Freigaben.
Prüfungen sind periodisch und ereignisgesteuert. Auslöser sind neue Verträge oder Nachträge, Einführung oder Abschaltung eines Dienstes, Änderung von Firmenname oder Subunternehmer, neue Hostingregion, Übernahme, überarbeiteter Exit-Plan und neue Kritikalitätsbewertung. Die verbindliche Kadenz ergibt sich aus DORA, Durchführungsstandards, Verfahren des Finanzunternehmens und Vorgaben der Aufsicht. Eine vierteljährliche Lieferantenprüfung kann eine interne Kontrolle sein, ist hier aber keine universelle gesetzliche Frist.
Validierung vor dem Export
Strukturprüfungen kontrollieren Pflichtfelder, eindeutige Kennungen, gültige Datumswerte und Codes, auflösbare Referenzen und verwaiste Dienst- oder Subunternehmerzeilen. Danach folgt die semantische Prüfung: Vertragsdaten stimmen mit dem unterzeichneten Dokument überein, Enddaten liegen nicht vor dem Start, Standorte passen zur Architektur, Subunternehmer unterstützen einen benannten Dienst und Beziehungen zu kritischen Funktionen sind vom Finanzunternehmen freigegeben.
Wesentliche Änderungen erhalten ein Vier-Augen-Review. Abgewiesene Datensätze gehen mit Fehlercode und Erklärung zurück, statt unbemerkt korrigiert zu werden. Validierungsergebnis, Prüfer, Zeitpunkt und Datenversion bleiben erhalten. Vor Abgabe werden Zeilenzahlen und wichtige Summen mit dem letzten akzeptierten Export abgeglichen; Zu- und Abgänge sowie Kennungswechsel werden erklärt.
Export- und Nachweispaket
Exportiert wird ein eingefrorener Freigabestand, keine weiter bearbeitete Live-Tabelle. Er erhält Datenversion, Erstellungszeit, Schemaversion und Prüfsumme. Aufbewahrt werden maschinenlesbare Datei, lesbarer Kontrollbericht, Validierung, Freigaben und Beweisindex. Wo eine Testumgebung existiert, wird der Import geprobt. Zeichencodierung, Trennzeichen und Datumsformate können fachlich korrekte Daten technisch ungültig machen.
Die Übergabe der Agentur benennt Rechtsträger, Vereinbarungen, Leistungen, Orte und Subunternehmer, Stichtag, Änderungen, bekannte Lücken und Kontakt. Sie behauptet nicht, dass dieser Ausschnitt das Gesamtregister vollständig macht. Gruppenkonsolidierung, Funktionsklassifizierung und Behördenabgabe bleiben beim Finanzunternehmen.
Praktischer Qualitätsprozess für Lieferantenantworten
Eine Lieferantenabfrage braucht eine eindeutige Referenz auf Vertrag und Dienst. Schicken Sie keine freie Liste mit Fragen, wenn das Zielsystem strukturierte Werte erwartet. Stellen Sie eine versionierte Vorlage, Felddefinitionen, Beispiele, erlaubte Codes und einen sicheren Rückgabekanal bereit. Der Lieferant bestätigt den Stichtag und kennzeichnet Angaben, die noch von einem Unterauftragnehmer abhängen. Rückfragen werden am Datensatz geführt, nicht in voneinander getrennten E-Mail-Verläufen.
Bei einer Änderung wird nicht der gesamte historische Stand überschrieben. Speichern Sie vorherigen Wert, neuen Wert, Wirksamkeitsdatum, Änderungsgrund, Quelle und Freigabe. Ein neuer Hostingstandort kann etwa angekündigt, vertraglich genehmigt und technisch aktiviert werden. Diese drei Daten müssen nicht identisch sein. Die Historie ermöglicht später zu erklären, welcher Stand zu einem bestimmten Meldetermin galt.
Auch Dubletten brauchen eine Regel. Derselbe Konzern kann Vertragspartner, Plattformanbieter und Unterauftragnehmer über verschiedene Gesellschaften sein. Rechtliche Einheiten werden getrennt geführt und über Konzernbeziehungen verbunden. Handelsname, Produktname und Rechtsträger sind keine austauschbaren Felder. Ähnlich gilt: ein Pluginname beschreibt ein Produkt, nicht automatisch den Vertragspartner oder den Ort, an dem Daten verarbeitet werden.
Vor der Freigabe liest ein fachlicher Eigentümer den Datensatz als Geschichte: Welche Funktion wird durch welchen Vertrag, Dienst und Lieferanten an welchem Ort unterstützt, und wie wäre ein Ausstieg möglich? Wenn diese Kette nicht verständlich ist, sind formal ausgefüllte Felder noch nicht ausreichend. Offene Werte werden mit Eigentümer und Zieltermin in eine Qualitätsliste übernommen, statt durch Annahmen ersetzt zu werden.
Ein kleines Kontrollprotokoll macht den Prozess prüfbar. Es nennt Eingang der Lieferantenantwort, automatische Prüfungen, fachliche Rückfragen, Freigabe und Aufnahme in den Export. Kennzahlen wie offene Pflichtfelder, überfällige Antworten, Datensätze ohne Quelle und Änderungen nach dem Stichtag helfen dem Registereigentümer, die Arbeitslast zu steuern. Sie sind interne Qualitätsindikatoren, keine regulatorischen Konformitätswerte.
Testdaten und produktive Registerdaten bleiben getrennt. Beispiele dürfen keine echten Ansprechpartner, Vertragswerte oder Sicherheitsdetails enthalten. Wird eine Vorlage geändert, muss ein Migrationstest zeigen, wie bestehende Datensätze in das neue Schema überführt werden. Abweichungen werden nicht durch manuelle Nacharbeit kurz vor der Abgabe verborgen, sondern als wiederholbare Transformationsregel dokumentiert und geprüft.
Grenzen und schriftliches Briefing
QA-Szenario: Wechsel der Hostingregion
Angenommen, eine verwaltete WordPress-Instanz wechselt innerhalb Europas die Hostingregion, der rechtliche Hostinganbieter bleibt aber gleich. Die Änderung ist nicht erledigt, indem ein Länderfeld überschrieben wird. Der Dateneigentümer ermittelt betroffene Vereinbarungen, Dienste, unterstützte Funktionen, Produktions-, Backup- und Logstandorte sowie Unterauftragsbeziehungen. Der Vertragseigentümer prüft Genehmigungspflichten. Security bestätigt den technischen Wirksamkeitszeitpunkt, Datenschutz eine mögliche Änderung des Verarbeitungsverzeichnisses.
Der Änderungssatz enthält alten und neuen Wert, Ankündigungs-, Genehmigungs- und Wirksamkeitsdatum, Quelldokumente und Datensatzkennungen. Die Validierung prüft Ländercode, Verbindung zwischen Standort und Dienst sowie die getrennte Behandlung von Produktion, Backup und Protokollarchiv. Bleibt die alte Region während einer Migration aktiv, können beide Standorte mit Gültigkeitszeitraum erforderlich sein. Ein sofortiges Überschreiben würde die tatsächliche Lage falsch darstellen.
Der Prüfer gleicht Lieferantenerklärung, Architekturbeleg und Vertrag ab. Ein Widerspruch wird als Datenqualitätsbefund mit Eigentümer geführt, nicht durch Auswahl des bequemsten Werts gelöst. Die Abnahme verlangt freigegebene Quellen, bestandene Schemavalidierung, konsistente Referenzen, eine erklärte Änderung gegenüber dem letzten Export und bestätigte Information der nachgelagerten Eigentümer.
Lieferantennachfrage und Abnahme
Rückfragen erhalten klare Zustände: angefordert, eingegangen, in Prüfung, Klärung nötig, akzeptiert und abgelaufen. Jede Anfrage nennt Datensatz, betroffene Felder, erwartetes Format, sicheren Rückkanal und Termin. Eine Klärung bezeichnet den konkreten Konflikt, etwa ein Land des Unterauftragnehmers, das nicht zum Standortbeleg passt. Eine pauschale Bitte, “alles noch einmal zu prüfen”, erzeugt keine bessere Datenqualität.
Die Abnahme erfolgt feldbezogen. Unternehmensidentität kann freigegeben sein, während ein Standort offen bleibt. Der Registereigentümer entscheidet, ob ein unvollständiger Datensatz in den internen Arbeitsstand darf und welche Lücke den Export blockiert. Vertrags- oder Betriebsdaten werden nicht aus einer Marketingwebsite abgeleitet. Kann ein Lieferant ein wesentliches Feld nicht belegen, geht die Eskalation an den Vertragseigentümer.
Vor der Schlussfreigabe prüft eine zweite Person Aktualität der Quellen, Wirksamkeitsdaten, Verknüpfung von Vertrag, Dienst und Funktion, Abdeckung der Unterauftragnehmer und Behandlung unbekannter Werte. Der Abnahmevermerk enthält Datenversion, Prüfer, Ausnahmen und nächsten Aktualisierungsauslöser. Diese interne Freigabe schafft einen Nachweispfad, ist aber keine Freigabe durch die Aufsicht.
Ein akzeptierter Datensatz kann später veralten. Deshalb erhält jede wesentliche Quelle ein Prüfdatum oder einen Ereignisauslöser. Vertragsangaben werden bei Nachtrag oder Verlängerung geprüft, Standorte bei Infrastrukturänderungen, Unterauftragnehmer bei Lieferantenmitteilungen und Ansprechpartner bei organisatorischen Wechseln. Meldet ein Lieferant keine Änderung, ersetzt das nicht die geplante Bestätigung. Umgekehrt sollte eine unveränderte Antwort als neue Bestätigung mit Datum erhalten bleiben, statt den historischen Datensatz still zu überschreiben.
Kann eine Frage bis zum Export nicht geklärt werden, dokumentiert der Registereigentümer Auswirkung, Eskalation und Entscheidung. Ein unbekannter Wert wird nicht zu “nicht anwendbar” umgedeutet. So bleibt sichtbar, ob die Lücke fachlich zulässig ist, eine Nachlieferung braucht oder den Datensatz von der Freigabe ausschließt.
Dieser Leitfaden ist eine praktische Daten-Governance-Hilfe, kein Ersatz für Durchführungsverordnung (EU) 2024/2956, aktuelle Aufsichtsvorgaben oder Rechtsberatung. Templates, Taxonomien und Validierungsregeln können sich ändern. Die Klassifizierung eines Dienstes hängt vom Kontext ab; gelieferte Daten garantieren keine erfolgreiche regulatorische Prüfung.
Für die Strukturierung eines WordPress-Lieferantenfeeds senden Sie ein schriftliches Briefing über den NIS2- und DORA-Readiness-Service. Nennen Sie Perspektive, Jurisdiktionen, Rechtsträger, Verträge und Dienste, aktuelles Registerformat, Quellsysteme, Subunternehmerkette, Termin und bekannte Validierungsfehler. Verträge, Zugangsdaten und sensible Architektur gehören nicht in die erste Nachricht. Das erste Ergebnis sollte Feldlandkarte, Eigentumsmodell, Datenqualitätsliste und Nachweisplan sein.
