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:
| Klausel | Artikel-30-Absatz | Was im WordPress-Vertrag steht |
|---|---|---|
| Klare Leistungsbeschreibung | 30(2)(a) | Hosting-Stufe, WAF-Regelwerk, enthaltene Plugins, Reaktionszeiten |
| Standort der Daten | 30(2)(b) | EU/EWR-Rechenzentrum, EU-basierter Support, keine außereuropäischen Subunternehmer ohne Anzeige |
| Verfügbarkeits- und Sicherheitsanforderungen | 30(2)(c) | Verfügbarkeits-SLA, RPO, RTO, Verschlüsselung in Ruhe und im Transit |
| Schutz personenbezogener Daten | 30(2)(d) | AVV nach DSGVO Artikel 28, Verarbeitungsverzeichnis |
| Recht auf Zugang, Inspektion und Audit | 30(2)(e) | Vor-Ort- oder Remote-Audit-Recht, Frequenz, Frist |
| Service-Level-Beschreibungen | 30(2)(f) | SLA-Matrix, Gutschriftmechanismus bei Verstoß |
| Zusammenarbeit mit zuständigen Behörden | 30(2)(g) | Anbieter kooperiert auf Anfrage mit der Aufsicht |
| Kündigungsrechte | 30(2)(h) | Wesentlicher Vertragsverstoß, aufsichtsrechtlich erzwungene Kündigung, Kontrollwechsel |
| Teilnahme an Awareness und Schulung | 30(2)(i) | Jährliches Sicherheits-Briefing, benannter Kontakt |
| Unterauftragsvergabe | 30(3)(c) | Vorabgenehmigung für Unterauftrags-Vergaben kritischer Funktionen |
| Bedrohungsorientierte Penetrationstests | 30(3)(g) | Mitwirkung an TLPT nach Artikel 26 |
| Unterstützung der Ausstiegsstrategie | 30(3)(f) | Datenexportformat, Übergangshilfe, Parallelbetriebsphase |
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.
