DORA Artikel 28 IKT-Drittparteirisiko: WordPress-Hosting- und WAF-Lieferanten-Audit

#DORA Artikel 28 IKT-Drittparteirisiko: WordPress-Hosting- und WAF-Lieferanten-Audit

Artikel 28 der Verordnung 2022/2554 ist der Teil von DORA, der entscheidet, ob ein Kunde aus dem Finanzsektor überhaupt einen Hosting-Vertrag oder ein WAF-Abonnement unterzeichnen darf. Er gilt für Kreditinstitute, Zahlungsinstitute, Versicherer, Wertpapierfirmen, Kryptowert-Dienstleister und rund fünfzehn weitere Kategorien aus Artikel 2. Seit 17. Januar 2025 gilt er unmittelbar, ohne nationale Umsetzung.

Dies ist ein vertiefender Beitrag im Pillar zu NIS2 und DORA auf WordPress mit Querverweisen auf den NIS2-Anhang-II-Nachweispfad und die CRA + NIS2 + DORA-Stack-Übersicht.

#TL;DR

• DORA Artikel 28 = allgemeine Grundsätze für das IKT-Drittparteirisikomanagement.
• Artikel 30 = die zwingenden Vertragsklauseln.
• Artikel 31 = das CTPP-Benennungsverfahren der Europäischen Aufsichtsbehörden.
• Ein WordPress-Mandat mit einer Bank oder einem Versicherer löst Registereintrag, Due Diligence, zwingende Klauseln und Ausstiegsstrategie aus.
• Hosting, CDN, WAF, Zahlungs-Plugin und E-Mail-Versand-Plugin landen alle im Register.

#Wer unter DORA fällt

Artikel 2 Absatz 1 von DORA zählt die Finanzeinrichtungen auf. Die häufigsten in WordPress-Mandaten:

• Kreditinstitute und ihre Gruppen.
• Zahlungsinstitute und E-Geld-Institute.
• Wertpapierfirmen, einschließlich Betreibern eines MTF oder OTF.
• Kryptowert-Dienstleister unter MiCA.
• Versicherungs- und Rückversicherungsunternehmen.
• Versicherungsvermittler oberhalb der Schwelle.
• Schwarmfinanzierungsdienstleister.
• Investmentfonds (OGAW-Verwalter, AIFM).

Hinzu kommen die kritischen IKT-Drittdienstleister (CTPP), die nach Artikel 31 von der Europäischen Bankenaufsichtsbehörde, ESMA und EIOPA gemeinsam benannt werden. Die erste Benennungsrunde lief 2025 und wird von Hyperscale-Cloud-Anbietern dominiert (die öffentliche Liste lebt im Portal der Europäischen Aufsichtsbehörden). Eine WordPress-Agentur wird kaum CTPP. Eine Managed-WordPress-Hosting-Plattform mit großem Finanzdienstleistungs-Portfolio möglicherweise schon.

#Was Artikel 28 tatsächlich fordert

Artikel 28 hat acht Absätze. Die für ein WordPress-Mandat operativen:

Artikel 28 Absatz 1. Die Finanzeinrichtung steuert das IKT-Drittparteirisiko als integralen Bestandteil ihres gesamten IKT-Risikomanagement-Rahmens. Der Rahmen, die Richtlinien und die Governance liegen bei der Einrichtung, nicht beim Lieferanten. Der Lieferant liefert Nachweise, die den Rahmen der Einrichtung stützen.

Artikel 28 Absatz 2. Solide, umfassende und gut dokumentierte Strategie für das IKT-Drittparteirisiko. Die Einrichtung führt die Dokumentation. Der Lieferant muss bereit sein, sie zu speisen.

Artikel 28 Absatz 3. Ein Register aller vertraglichen Vereinbarungen mit IKT-Drittdienstleistern, das jene zur Unterstützung kritischer oder wichtiger Funktionen von den übrigen unterscheidet. Das Register muss meldepflichtig an die Aufsicht sein. Für WordPress: Hosting, CDN, WAF, Zahlungs-Gateway, transaktionale E-Mail, KI-Anbieter, Monitoring-Werkzeug, Backup-Ziel.

Artikel 28 Absatz 4. Vorvertragliche Due Diligence. Identifikation und Bewertung aller relevanten Risiken. Konzentrationsrisikoanalyse beim Hinzufügen eines weiteren Vertrags mit demselben Anbieter oder einem Anbieter aus derselben Gruppe.

Artikel 28 Absatz 5. Bewertung von Interessenkonflikten. Das Leitungsorgan genehmigt die Richtlinie zum Einsatz von IKT-Diensten, die kritische oder wichtige Funktionen unterstützen.

Artikel 28 Absatz 7. Regelmäßige Neubewertung der vertraglichen Vereinbarung.

Artikel 28 Absatz 8. Ausstiegsstrategie für IKT-Dienste, die kritische oder wichtige Funktionen unterstützen. Dokumentiert, getestet, mit Übergangsplan.

#Zwingende Klauseln aus Artikel 30

Artikel 30 Absatz 2 listet die Mindestklauseln für jeden Vertrag. Artikel 30 Absatz 3 ergänzt Klauseln für Verträge, die kritische oder wichtige Funktionen unterstützen. Die Agenturvorlage, die ich mit Hosting- und WAF-Verträgen ausliefere, deckt sie alle ab:

Diese Matrix führe ich als einzelne Markdown-Datei im Mandatsordner. Jeder Vertrag wird vor Unterzeichnung dagegen geprüft.

#Das Lieferantenregister, gefüllt für WordPress

Ein WordPress-Mandat für eine Finanzeinrichtung berührt mehr IKT-Dritte, als der Einkauf üblicherweise erwartet. Das Register, das ich am ersten Tag eines Mandats aufstelle:

• Hosting-Anbieter. Der tatsächliche Rechenzentrumsbetreiber, die Verwaltungsoberfläche, das Support-Team. Kritisch oder wichtig, wenn die WordPress-Site Teil der Kundendienste ist.
• CDN-Anbieter. Cloudflare, Fastly, Akamai. Verarbeitet Verkehr, kann Request-Bodies sehen, terminiert TLS. Häufig kritisch oder wichtig.
• WAF-Anbieter. Manchmal identisch mit dem CDN, manchmal getrennt (Sucuri, Imperva). Inspiziert Nutzdaten. Kritisch oder wichtig.
• Zahlungs-Plugin. Stripe, Adyen, mollie, regionale Gateways. Der Plugin-Autor ist ein Lieferant; der Gateway-Betreiber ein anderer. Beide ins Register.
• Transaktionale E-Mail. SES, Postmark, SendGrid. Trägt Passwort-Resets, KYC-Benachrichtigungen, AML-Alerts. Häufig kritisch oder wichtig.
• Monitoring und APM. New Relic, Datadog, Sentry. Empfängt Stack Traces und teilweise Request-Payloads.
• Backup-Ziel. S3, Backblaze, Wasabi. Hält Datenbank und Uploads. Immer kritisch oder wichtig.
• KI-Anbieter. Wenn die WordPress-Site einen LLM für eine Kundenfunktion einsetzt (Chat, Zusammenfassung), ist der LLM-Anbieter im Anwendungsbereich.
• Plugin-Marktplatz. WordPress.org, Premium-Marktplätze. Update-Kanäle gehören nach Artikel 28 Absatz 2 Buchstabe d zur Lieferkette.

Pro Anbieter führt das Register: rechtlicher Name, Vertragsreferenz, Leistungsbeschreibung, Datenflüsse, Kritikalitätsklassifizierung, Verarbeitungsstandort, Datum der letzten Due Diligence, Verweis auf die Ausstiegsstrategie.

#Konzentrationsrisiko und der Konzern-Test

Artikel 28 Absatz 4 führt einen Test ein, der WordPress-Agenturen häufiger trifft als erwartet: keine Konzentration kritischer Funktionen bei Anbietern, die zur selben Eigentümerkette gehören. Eine Bank, die Cloudflare für CDN, Cloudflare Workers für Backend, Cloudflare R2 für Objektspeicher und Cloudflare Stream für Video nutzt, hat ein hohes Konzentrationsrisiko bei einem einzigen Anbieter. Das ist kein Cloudflare-spezifischer Befund; dasselbe gilt für AWS-, Azure- oder GCP-Stacks.

Bei WordPress zeigt sich das oft als: Hosting auf AWS, Backups auf S3, E-Mail über SES, Monitoring über CloudWatch. Vier AWS-Abhängigkeiten, ein Anbieter. Das Risikoregister muss das ausdrücklich anerkennen und entweder begründen oder Diversifizierung planen.

#Ausstiegsstrategien, die wirklich funktionieren

Artikel 28 Absatz 8 verlangt, dass die Ausstiegsstrategie dokumentiert und getestet wird. Für WordPress-Hosting und WAF umfasst eine echte Ausstiegsstrategie:

• Datenbank-Export im Standardformat. SQL-Dump kompatibel mit Stock-MySQL oder MariaDB, ohne proprietäre Erweiterungen.
• Dateisystem-Export einschließlich Uploads. Tar- oder Zip-Archiv, von außerhalb der Anbieterkonsole herunterladbar.
• DNS-Kontrolle. Domain-Registrar-Konto im Eigentum der Finanzeinrichtung, weder bei Agentur noch beim Hoster.
• Lizenz-Portabilität für Plugins und Themes. Lizenzen im Namen der Einrichtung, übertragbar an einen neuen Hoster.
• Getesteter Übergang. Eine Staging-Umgebung bei einem alternativen Hoster, die in einem dokumentierten Zeitfenster zur Produktion erhoben werden kann. Der Test ist protokolliert und datiert.
• Vertragliches Übergangsfenster. Der Hosting-Vertrag verpflichtet den Anbieter, während der Migration weiter zum gleichen Tarif zu liefern, mindestens für eine dokumentierte Dauer.

Die Preisgestaltung für Mandate, die das Ausstiegsstrategie-Paket beinhalten, ist individuell; das Ausstiegsdokument selbst nimmt Tage, nicht Stunden, und ist ein Liefergegenstand.

#Was das für das Einkaufsgespräch ändert

Eine WordPress-Agentur, die mit der bereits gefüllten Artikel-30-Klauselmatrix, der vorbereiteten Lieferantenregister-Vorlage und einer bewährten Ausstiegsstrategie kommt, passiert den Einkauf schneller. Die Finanzeinrichtung muss Artikel 28 nicht in einen Vertrag übersetzen; sie fügt die Liefergegenstände der Agentur in ihren eigenen IKT-Risikomanagement-Rahmen ein.

Das ist auch der Grund, warum ein regulierter Kunde Lieferanten-Shortlists nach Jurisdiktion filtert. Eine in der EU ansässige Agentur unter EU-Vertragsrecht entfernt eine Reibungsschicht; eine Agentur außerhalb der EU löst zusätzliche Due Diligence nach Artikel 28 Absatz 4 für jurisdiktionelles Risiko aus.

#Zuerst die Funktion klassifizieren, dann den Anbieter bewerten

Weder Markenname noch Vertragswert bestimmen die Kritikalität. Ausgangspunkt ist die Funktion, die das Vertragsverhältnis unterstützt, sowie die Auswirkung von Ausfall, Leistungsabfall oder Kompromittierung. Eine Informationsseite einer Bank kann für die Kommunikation relevant sein, ohne unmittelbar eine kritische Finanzdienstleistung zu tragen. Ein preisgünstiges Plugin für Anmeldung oder Zahlungsstatus kann dagegen eine erhebliche operative Wirkung haben.

Der Bewertungsvermerk benennt Geschäftsservice, Prozessverantwortung, betroffene Kunden, verarbeitete Daten, Wiederherstellungsziele, mögliche manuelle Ersatzverfahren und Abhängigkeiten von weiteren Anbietern. Zusätzlich hält er fest, wer die Einstufung als kritische oder wichtige Funktion genehmigt hat und wann sie erneut geprüft wird. Diese Einstufung steuert Tiefe der Due Diligence und zusätzliche Vertragsanforderungen. Der Lieferant kann sie nicht durch eine Selbstauskunft verbindlich festlegen.

#Nachweispaket für eine prüfbare Due Diligence

Der Einkauf sollte Nachweise zur konkret angebotenen Leistung verlangen, nicht nur eine allgemeine Sicherheitsbroschüre. Bei WordPress-Hosting, CDN, WAF oder Managed Service gehören regelmäßig dazu:

• Rechtsträger, Eigentümergruppe, Leistungsorte und benannte Unterauftragnehmer;
• Architektur- und Datenflussgrenzen einschließlich administrativer Zugänge und Supportpfade;
• Nachweise zu MFA, privilegierten Konten, Zugriffsprüfungen und Offboarding;
• Verfahren für Schwachstellen, Patches und Änderungen mit aktuellen Betriebsbelegen;
• Meldeweg für Vorfälle, Eskalationskontakte und Fähigkeit zur Beweissicherung;
• Ergebnisse von Wiederherstellungs- und Kontinuitätstests für die Vertragsleistung;
• unabhängige Prüfberichte mit Geltungsbereich, Ausschlüssen und Status offener Maßnahmen;
• vorgeschlagene Service Levels, Wiederherstellungsziele, Auditunterstützung und Übergangshilfe.

Ein Zertifikat kann die Prüfung stützen. Es beweist jedoch nicht automatisch, dass WordPress-Verwaltungsoberfläche, Supportteam und Backup-Ziel im zertifizierten Geltungsbereich liegen. Nachweisdatum, geprüfter Zeitraum, Prüfer und offene Fragen gehören in die Akte. Kann ein Anbieter sensible Unterlagen nicht vollständig herausgeben, werden kontrollierte Einsicht, unabhängiger Bericht oder eine konkrete vertragliche Zusicherung vereinbart. Der Punkt darf nicht stillschweigend als erfüllt gelten.

#Unterauftragnehmer unterhalb der ersten Vertragsbeziehung

Der direkte Vertragspartner betreibt selten den gesamten Stack. Eine Managed-WordPress-Agentur nutzt möglicherweise Cloud-Plattform, CDN, Ticketsystem, Monitoring und einen weiteren Supportdienstleister. Vertrag und Register müssen deshalb zwischen dem Vertragspartner und den Unternehmen unterscheiden, die tatsächlich Daten speichern, Systeme administrieren oder eine kritische beziehungsweise wichtige Funktion unterstützen.

Festgelegt wird, welche Änderungen der Unterauftragskette anzeigepflichtig sind, welche Angaben die Anzeige enthält, wie Widerspruch oder Kündigung funktionieren und was mit vorhandenen Daten geschieht. Der Einkauf prüft außerdem Konzentration auf der vierten Ebene: Zwei scheinbar unabhängige Anbieter können vom selben Hyperscaler, Identitätsdienst oder DNS-Betreiber abhängen. Eine nur bei Vertragsschluss erhobene Liste ist keine dauerhaft wirksame Kontrolle.

#Konzentration und Ausstieg gemeinsam testen

Zwei Logos in einem Architekturdiagramm bedeuten noch keine Diversifizierung. Nutzt der Ersatzhost dieselbe Cloud-Region, teilt das Backup denselben Identitätsdienst oder bleibt DNS unter Kontrolle des bisherigen Lieferanten, kann die Alternative zusammen mit dem Primärdienst ausfallen. Zu erfassen sind gemeinsame Eigentümerschaft, Infrastruktur, geografische Lage, Administrationszugänge und Spezialwissen.

Ein Ausstiegstest weist nach, dass berechtigte Personen aktuelle Daten und Konfigurationen erhalten, deren Integrität prüfen, den Dienst neu aufbauen, Verkehr umschalten, erforderliche Aufzeichnungen erhalten und alte Zugänge entziehen können. Die gemessene Dauer wird mit der genehmigten Geschäftstoleranz verglichen. Manuelle Schritte, Lizenzgrenzen, Formatprobleme und nicht reproduzierbare Funktionen werden protokolliert. Das Ergebnis kann ein akzeptiertes Restrisiko, eine Maßnahme oder ein Anbieterwechsel sein. Artikel 28 verlangt nicht automatisch, jede Abhängigkeit unabhängig von Kosten zu verdoppeln.

#Laufende Überprüfung und Abnahmekriterien

Frequenz und Tiefe der Neubewertung folgen Kritikalität und Veränderung. Auslöser sind unter anderem ein wesentlicher Vorfall, eine Übernahme, ein neuer Verarbeitungsort, ein bedeutender Wechsel bei Unterauftragnehmern, eine erhebliche Leistungsänderung oder wiederholte SLA-Abweichungen. Service Owner, Einkauf, Informationssicherheit, Recht und Datenschutz benötigen klare Rollen. Ein jährlich versandter Fragebogen ohne Bewertung der Antworten ist keine ausreichende Steuerung.

Vor Freigabe sollten ein benannter Kontrollverantwortlicher, ein vollständiges Nachweisprotokoll, vertraglich gelöste Lücken oder formell akzeptierte Ausnahmen, der Registereintrag, ein umsetzbarer Ausstiegsplan und der nächste Prüftermin vorliegen. Die Abnahme trennt belegte Tatsachen, reine Anbieteraussagen, nicht geprüfte Bereiche und Restrisiken. Ein Lieferantenaudit reduziert Unsicherheit, zertifiziert aber weder die DORA-Konformität der Finanzeinrichtung noch einen unterbrechungsfreien Betrieb.

Für eine belastbar abgrenzbare Prüfung senden Sie einen schriftlichen Brief mit Finanzfunktion, Anbieter und Leistung, Architektur, Datenklassen, bekannten Unterauftragnehmern, Wiederherstellungszielen, Vertragsstand und Beschaffungsfrist. Die NIS2- und DORA-Readiness-Prüfung kann daraus Lieferanteninventar, Nachweislücken, Vertragscheckliste, Konzentrationsanalyse und Retest-Plan für die WordPress-Fläche ableiten.

#Cluster-Lektüre

• Pillar: NIS2 und DORA auf WordPress: Konformitäts-Stack 2026
• NIS2 Anhang II für WordPress-Agenturen: Geltungsbereich, Fristen, Nachweispfad
• WordPress-Vorfallsreaktion unter NIS2: 24-Stunden-Frühwarnungs-Playbook
• Cyber Resilience Act + NIS2 + DORA: der 2026er Konformitäts-Stack für headless WordPress