Trust-Center-Anforderungen unter NIS2 und DORA
Keine der beiden Regulierungen erwähnt „Trust Center“ namentlich. Beide schaffen Anforderungen, die nur eine strukturierte externe Nachweisschicht erfüllen kann.
NIS2 und DORA sind interne Governance-Regulierungen. Sie schreiben vor, welche Sicherheitsmaßnahmen umzusetzen sind, welche Vorfälle zu melden und welche Nachweise zu führen sind. Sie schreiben nicht vor, wie Sie Ihre Compliance-Haltung nach außen kommunizieren.
Aber in der Praxis passiert Folgendes: Ihre Kunden — insbesondere die selbst regulierten — brauchen strukturierte, kontinuierliche Sichtbarkeit in Ihre Sicherheitslage. Nicht aus Neugier, sondern weil ihre eigenen NIS2- und DORA-Pflichten sie zur Überwachung ihrer Lieferkette verpflichten. Ihr Trust Center ist der Ort, an dem diese Überwachung stattfindet.
Die regulatorische Logik
NIS2 und DORA existieren nicht isoliert. Sie erzeugen eine Kaskade von Pflichten, die Lieferketten hinunterfließt.
Eine wesentliche Einrichtung unter NIS2 muss Lieferkettensicherheit gewährleisten (Artikel 21(2)(d)). Dafür müssen sie ihre Lieferanten bewerten und überwachen. Deren Lieferanten sind nicht direkt durch NIS2 reguliert (es sei denn, sie sind selbst wesentliche oder wichtige Einrichtungen), aber sie stehen vor einer kommerziellen Pflicht: Wenn Sie Ihre Sicherheitslage Ihren regulierten Kunden nicht nachweisen können, verlieren Sie den Vertrag.
Die gleiche Logik gilt unter DORA. Finanzunternehmen müssen IKT-Drittparteien-Risiken managen (Artikel 28-30). Ihre IKT-Dienstleister müssen Nachweise über Sicherheitsmaßnahmen, Incident-Management-Fähigkeiten und Business-Continuity-Planung liefern — nicht einmalig, sondern kontinuierlich.
Das erzeugt eine marktweite Nachfrage nach strukturierter, verifizierbarer, kontinuierlich aktualisierter externer Sicherheitskommunikation. Genau das leistet ein Trust Center. Die Regulierung schafft den Bedarf; das Trust Center ist die operative Antwort.
NIS2-Anforderungen, die Trust-Center-Bedarf erzeugen
Lieferkettensicherheit — Artikel 21(2)(d)
Was die Regulierung sagt: Wesentliche und wichtige Einrichtungen müssen „die Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern oder Diensteanbietern" adressieren.
Was das für Lieferanten bedeutet: Ihre regulierten Kunden müssen gegenüber ihrer nationalen zuständigen Behörde nachweisen, dass sie ihre Lieferkette überwachen. Sie brauchen Evidenz, dass ihre Lieferanten angemessene Sicherheitsmaßnahmen unterhalten.
Was das von Ihrem Trust Center erfordert:
- Strukturierte Darstellung Ihrer Sicherheitslage, kontinuierlich aktualisiert — kein statisches PDF
- Frameworks und Zertifizierungen mit Scope, Gültigkeit und Auditdaten
- Subprozessor-Liste mit Datenverarbeitungsstandorten und Rollen — sichtbar, nicht hinter einem Vertriebsgespräch versteckt
- Vendor-Assurance-Profile, die Ihre Kunden in ihrer eigenen NIS2-Dokumentation referenzieren können
Wenn Ihr Trust Center ein Dokumenten-Repository ist, das einmal im Quartal aktualisiert wird, erfüllt es die Erwartung an kontinuierliche Überwachung nicht. Wenn es Echtzeit-Compliance-Status mit automatisch aktualisierter Evidenz bietet, schon.
Vorfallmeldung — Artikel 23
Was die Regulierung sagt: Wesentliche und wichtige Einrichtungen müssen einreichen:
- Frühwarnung an ihr CSIRT innerhalb von 24 Stunden nach Kenntnisnahme eines erheblichen Sicherheitsvorfalls
- Vorfallmeldung innerhalb von 72 Stunden mit erster Bewertung
- Abschlussbericht innerhalb eines Monats mit Ursachenanalyse
Was das für Lieferanten bedeutet: Die Meldepflicht liegt bei der Einrichtung, nicht bei ihrem Lieferanten. Aber wenn der Vorfall bei einem Lieferanten entsteht oder ihn betrifft, beginnt die Meldefrist der Einrichtung mit Kenntnisnahme. Verzögerte Kenntnisnahme bedeutet verzögerte Meldung bedeutet regulatorisches Risiko.
Was das von Ihrem Trust Center erfordert:
- Vorfallkommunikationsfähigkeit — strukturierte Statusupdates, die betroffene Kunden über das Trust Center erhalten, nicht per einzelner E-Mail
- Schweregrad-Klassifizierung sichtbar für relevante Stakeholder
- Zeitdokumentation, die Ihre Kunden in ihren eigenen Vorfallberichten an ihr CSIRT referenzieren können
- Post-Incident-Evidenz (Ursachenanalyse, Abhilfemaßnahmen) über denselben Kanal verfügbar
Das bedeutet nicht, jeden Sicherheitsvorfall öffentlich zu publizieren. Es bedeutet, eine geschützte Kommunikationsschicht innerhalb Ihres Trust Centers zu haben, die die richtigen Stakeholder mit strukturierten Informationen innerhalb der richtigen Fristen erreicht.
Aufsichtsbefugnisse — Artikel 32-33
Was die Regulierung sagt: Nationale zuständige Behörden können Prüfungen durchführen, Nachweise anfordern und von Einrichtungen verlangen, Compliance-Maßnahmen nachzuweisen — jederzeit, nicht nur während geplanter Auditzyklen.
Was das für Lieferanten bedeutet: Wenn die zuständige Behörde Ihres Kunden (in Deutschland: das BSI) Lieferkettensicherheitsnachweise verlangt, wird sich Ihr Kunde an Sie wenden. Er braucht Ihre Compliance-Evidenz schnell — nicht „wir bereiten etwas für das Audit vor."
Was das von Ihrem Trust Center erfordert:
- Evidenz, die aktuell ist (heutiger Stand, nicht letztes Quartal)
- Evidenz, die strukturiert ist (organisiert nach Framework, Maßnahme und Kontrolle — kein Ordner mit PDFs)
- Evidenz, die abrufbar ist (Ihr Kunde kann holen, was er braucht — innerhalb von Stunden, nicht Wochen)
DORA-Anforderungen, die Trust-Center-Bedarf erzeugen
IKT-Drittparteien-Risikomanagement — Artikel 28-30
Was die Regulierung sagt: Finanzunternehmen müssen Risiken aus IKT-Drittparteien-Dienstleistern identifizieren, klassifizieren und managen. Dies umfasst ein Register aller IKT-Drittparteien-Vereinbarungen, Due Diligence vor Vertragsschluss und kontinuierliche Compliance-Überwachung.
Was das für Lieferanten bedeutet: Wenn Sie an Finanzinstitute in der EU verkaufen, müssen Ihre Kunden Sie in ihrem IKT-Drittparteien-Register klassifizieren und Ihre Sicherheitslage überwachen. Sie brauchen strukturierte Daten über Ihre Sicherheitsmaßnahmen, Business-Continuity-Fähigkeiten und Subunternehmer-Ketten.
Was das von Ihrem Trust Center erfordert:
- Sicherheitsdokumentation strukturiert nach den Kategorien, die DORA von Finanzunternehmen zu bewerten verlangt: Verfügbarkeit, Authentizität, Integrität, Vertraulichkeit (Artikel 5)
- Business-Continuity- und Disaster-Recovery-Dokumentation — nicht nur, dass ein Plan existiert, sondern Nachweis von Tests
- Subunternehmer-Ketten-Sichtbarkeit — DORA verlangt von Finanzunternehmen, die gesamte IKT-Lieferkette zu verstehen, nicht nur die direkte Beziehung
- Vertragliche Compliance-Evidenz — DORA Artikel 30 spezifiziert, was IKT-Dienstleistungsverträge enthalten müssen; Ihr Trust Center kann nachweisen, dass Sie diese Bestimmungen erfüllen
Vorfallmeldung — Artikel 19
Was die Regulierung sagt: Finanzunternehmen müssen schwerwiegende IKT-bezogene Vorfälle an ihre zuständige Behörde melden, mit Klassifizierung basierend auf Auswirkungskriterien einschließlich Datenverlusten, Dienstverfügbarkeit und Anzahl betroffener Kunden.
Was das für Lieferanten bedeutet: Wenn ein Vorfall bei Ihnen ein Finanzunternehmen-Kunde betrifft, muss dieser ihn anhand der DORA-Auswirkungskriterien klassifizieren. Er braucht Ihre Vorfalldaten strukturiert, nicht vergraben in einem E-Mail-Thread.
Was das von Ihrem Trust Center erfordert:
- Vorfallkommunikation, die Daten liefert, die Finanzunternehmen für ihre eigene DORA-Klassifizierung brauchen: Umfang der Auswirkung, betroffene Datenkategorien, Dienstverfügbarkeitsstatus, Behebungszeitplan
- Strukturiertes Format, das sich an DORA-Meldevorlagen orientiert und den Klassifizierungsaufwand Ihres Kunden reduziert
Aufsicht kritischer IKT-Drittdienstleister — Artikel 31-37
Was die Regulierung sagt: Die Europäischen Aufsichtsbehörden (ESAs) können IKT-Drittdienstleister als „kritisch" einstufen und sie direkter Aufsicht unterwerfen, einschließlich Vor-Ort-Prüfungen und Evidenzanfragen.
Was das für Lieferanten bedeutet: Wenn Sie als kritischer IKT-Drittdienstleister eingestuft werden, können Aufsichtsbehörden Ihre Sicherheitslage direkt prüfen. Selbst wenn Sie nicht als kritisch eingestuft werden, müssen Ihre Finanzunternehmen-Kunden nachweisen, dass sie Sie ersetzen könnten — was detailliertes Verständnis Ihrer Service-Architektur erfordert.
Was das von Ihrem Trust Center erfordert:
- Ausreichende technische Dokumentation, damit Regulierer Ihre Sicherheitslage bewerten können, ohne einen separaten Auditprozess zu erfordern
- Service-Architektur-Informationen, die Finanzunternehmen bei der Bewertung von Konzentrationsrisiken und Exit-Strategien helfen
- Nachweise über Compliance-Maßnahmen, die direkt gegenüber Aufsichtsbehörden präsentiert werden können
Was ein NIS2/DORA-fähiges Trust Center leisten muss
Basierend auf diesen regulatorischen Anforderungen braucht ein Trust Center, das NIS2- und DORA-betroffene Kunden bedient, fünf Fähigkeiten jenseits traditionellen Dokumentenaustauschs:
1. Kontinuierlicher Compliance-Status
Statische Dokumentation, die vierteljährlich aktualisiert wird, erfüllt Erwartungen an kontinuierliche Überwachung nicht. Das Trust Center sollte Ihren aktuellen Compliance-Stand widerspiegeln — Zertifizierungen mit Gültigkeitsdaten, Kontrollstatus der sich aktualisiert, wenn Ihr ISMS sich aktualisiert, Evidenz die zeitgestempelt und versioniert ist.
2. Strukturierte Vendor-Assurance-Profile
Ihre Kunden müssen Sie in ihre Lieferkettensicherheitsdokumentation (NIS2) oder ihr IKT-Drittparteien-Register (DORA) aufnehmen. Machen Sie es einfach: Stellen Sie strukturierte Daten über Ihre Sicherheitsmaßnahmen, Zertifizierungen, Datenverarbeitungsstandorte und Subunternehmer-Beziehungen in einem Format bereit, das sie direkt referenzieren können.
3. Vorfallkommunikationskanal
E-Mail-Threads skalieren nicht. Wenn ein Vorfall mehrere Kunden betrifft, brauchen Sie einen strukturierten Kommunikationskanal innerhalb des Trust Centers, der Schweregrad-Klassifizierung, Zeitdokumentation, Auswirkungsumfang und Behebungsstatus liefert — sichtbar für betroffene Stakeholder, angemessen geschützt.
4. Evidenz-Abruf auf Anfrage
Wenn der Regulierer Ihres Kunden Lieferketten-Evidenz anfordert, sollte Ihr Kunde kein Support-Ticket einreichen und warten müssen. Das Trust Center sollte Compliance-Evidenz direkt abrufbar machen — strukturiert nach Framework und Kontrolle, aktuell und verifizierbar.
5. Abgestufte Zugriffskontrollen
Nicht alles gehört auf eine öffentliche Seite. Pentest-Zusammenfassungen könnten NDA-geschützt sein. Vorfallkommunikation könnte auf betroffene Kunden beschränkt sein. Framework-Zertifizierungen könnten öffentlich sein. Ein Trust Center für regulierte Branchen braucht granulare Zugriffssteuerung — öffentlich, eingeschränkt, NDA-geschützt, kundenspezifisch — ohne die Basisinformationen unzugänglich zu machen.
Was das für die Plattformwahl bedeutet
Wenn zu Ihren Kunden wesentliche oder wichtige Einrichtungen unter NIS2 oder Finanzunternehmen unter DORA gehören, hat das Trust Center, das Sie wählen, regulatorische Implikationen — nicht nur für Sie, sondern für die Compliance-Haltung Ihrer Kunden.
Bewerten Sie die Plattform gegen diese regulatorischen Anforderungen, nicht nur gegen Feature-Listen. Ein Trust Center mit schöner Analytics und KI-Fragebogenautomatisierung, aber ohne Vorfallkommunikationsfähigkeit, ohne Vendor-Assurance-Profile und ohne Evidenz-Abruf — dieses Trust Center bedient den Markt nicht, den NIS2 und DORA schaffen.
Berücksichtigen Sie Datensouveränität im regulatorischen Kontext. Ihr Trust Center enthält Compliance-Evidenz, auf die Ihre Kunden für ihre eigenen regulatorischen Pflichten angewiesen sind. Wenn diese Evidenz auf Infrastruktur gespeichert ist, die dem US CLOUD Act unterliegt, erben Ihre Kunden dieses Souveränitätsrisiko in ihrer Lieferkettenbewertung.
Fragen Sie, ob die Plattform EU-Frameworks als primär oder sekundär behandelt. Wenn NIS2 und DORA im Produkterlebnis Nachgedanken sind — verfügbar, aber nicht prominent — werden Ihre regulierten Kunden das bemerken. Sie bewerten Ihre Compliance-Reife, und Ihr Trust Center ist der Nachweis.
Quellen
- Richtlinie (EU) 2022/2555 (NIS2-Richtlinie) — Lieferkettensicherheit (Art. 21(2)(d)), Vorfallmeldung (Art. 23), Aufsichtsbefugnisse (Art. 32-33).
- Verordnung (EU) 2022/2554 (DORA) — IKT-Drittparteien-Risikomanagement (Art. 28-30), Vorfallmeldung (Art. 19), Aufsicht kritischer Anbieter (Art. 31-37).
- NIS2-Umsetzungsgesetz (NIS2UmsuCG) — Deutsche Umsetzung mit Festlegung der BSI-Aufsichtsbefugnisse.
Weiterführende Inhalte
- Warum europäische Unternehmen ein europäisches Trust Center brauchen
- Beste Trust-Center-Plattformen für europäische Unternehmen (2026)
- NIS2 Compliance-Lücken: Was Ihr ISMS nicht abdeckt
- NIS2 Compliance-Checkliste: ISMS vs. NIS2
- Incident Response Plan vs. Incident Management System
- NIS2 Nachweispflicht: Audit Readiness
- DORA-Verordnung: Was sie für Trust Center bedeutet