Artikel 28 Absatz 1 der Verordnung (EU) 2022/2554, DORA, macht den IKT-Risikomanagementrahmen des Kunden zu dem, wovon Ihr Dienst ein Bestandteil ist, und die Delegierte Verordnung (EU) 2024/1774 der Kommission vom 13. März 2024, veröffentlicht am 25. Juni 2024 und in Kraft seit dem 15. Juli 2024, legt diesen Rahmen in zweiundvierzig Artikeln fest: die Leitlinien, Verfahren, Protokolle und Werkzeuge aus Artikel 9 Absatz 2 DORA, die Erkennungsmechanismen aus Artikel 10, die Kontinuitäts- und Wiederherstellungspläne aus Artikel 11 und einen vereinfachten Rahmen für die kleinen Unternehmen aus Artikel 16. Das meiste davon ist die eigene Hausarbeit des Kunden. Neun Artikel nennen den IKT-Drittdienstleister, und jeder davon ist eine Frage, die der Rahmen des Kunden über Sie beantworten können muss, also eine Frage, die Ihnen gestellt wird. Dieser Artikel liest diese neun am 12. September 2026 aus dem Amtsblatt auf CELLAR, aus Sicht des Anbieters. Er ist keine Rechtsberatung.
Das Inventar will Ihre Support-Enddaten, Artikel 4
Artikel 4 verlangt eine Leitlinie für das Management von IKT-Assets, nach der das Unternehmen zu jedem IKT-Asset Aufzeichnungen führt: eine eindeutige Kennung, seinen physischen oder logischen Standort, seine Klassifizierung, seinen Eigentümer, die Geschäftsfunktionen, die es unterstützt, seine Kontinuitätsanforderungen einschließlich der Wiederherstellungszeit- und Wiederherstellungspunktziele, ob es externen Netzen ausgesetzt ist, seine Verbindungen und Abhängigkeiten zu anderen Assets und, Buchstabe b Ziffer ix von Absatz 2, soweit zutreffend, die Enddaten der regulären, erweiterten und individuellen Supportleistungen des IKT-Drittdienstleisters, nach denen das Asset nicht mehr unterstützt wird. Für einen Anbieter heißt das ein veröffentlichter Support-Lebenszyklus je Produktversion, mit Daten, denn das Inventar des Kunden hat dafür eine Spalte, und eine leere Spalte ist beim nächsten Audit des Kunden eine Feststellung.
Das Schwachstellenverfahren prüft Sie, und verfolgt Ihre Bibliotheken, Artikel 10
Artikel 10 verlangt Verfahren für das Schwachstellenmanagement, die unter anderem prüfen, ob IKT-Drittdienstleister Schwachstellen in den erbrachten Dienstleistungen behandeln und ob sie dem Unternehmen zumindest die kritischen Schwachstellen sowie Statistiken und Trends zeitnah melden; und die die Nutzung von Drittbibliotheken, einschließlich Open-Source-Bibliotheken, in Dienstleistungen, die kritische oder wichtige Funktionen unterstützen, und von Dienstleistungen, die ein Anbieter für das Unternehmen entwickelt oder angepasst hat, verfolgen. Die Verordnung fügt hinzu, dass das Unternehmen die Anbieter auffordert, die relevanten Schwachstellen zu untersuchen, die Ursachen zu bestimmen und Abhilfemaßnahmen umzusetzen, und dass es die Versionen und Aktualisierungen von Drittbibliotheken überwacht, wo angebracht in Zusammenarbeit mit dem Anbieter. Das Unternehmen selbst führt bei Assets, die kritische oder wichtige Funktionen unterstützen, mindestens wöchentlich automatisierte Schwachstellenscans durch, und sein Patch-Management setzt Fristen mit Eskalation.
Aus Sicht des Anbieters gelesen sind das drei Lieferungen: ein Verfahren zur Schwachstellenbehandlung, dessen Existenz der Kunde prüfen kann, ein regelmäßiger Schwachstellenbericht, der zumindest die kritischen mit Statistiken und Trends nennt, und eine Liste der Dritt- und Open-Source-Komponenten im Produkt mit ihren Versionen, also die Software-Stückliste, die der Cyber Resilience Act einem Hersteller aus eigenen Gründen abverlangt. Ein Anbieter, der sie bereits für den CRA erstellt, beantwortet Artikel 10 Absatz 2 Buchstabe d mit demselben Dokument.
Daten- und Systemsicherheit: Rollen zwischen Ihnen und dem Kunden, Maßnahmen an Ihrer Infrastruktur, Artikel 11
Artikel 11 verlangt ein Verfahren zur Daten- und Systemsicherheit, dessen Elemente für IKT-Assets oder Dienste, die ein IKT-Drittdienstleister betreibt, Buchstabe k, die Ermittlung und Umsetzung von Anforderungen zur Erhaltung der digitalen operationalen Resilienz im Einklang mit der Datenklassifizierung und der IKT-Risikobewertung umfassen. Dafür berücksichtigt das Unternehmen die Umsetzung der vom Anbieter empfohlenen Einstellungen an den Elementen, die es selbst betreibt, eine klare Zuweisung der Rollen und Verantwortlichkeiten für die Informationssicherheit zwischen dem Unternehmen und dem Anbieter, im Einklang mit der vollen Verantwortung des Unternehmens nach Artikel 28 Absatz 1 Buchstabe a DORA, die Kompetenzen, die es braucht, um den Dienst zu steuern und zu sichern, und technische und organisatorische Maßnahmen zur Minimierung der Risiken der Infrastruktur, die der Anbieter für seine Dienste nutzt, unter Berücksichtigung bewährter Verfahren und Normen. Buchstabe f Ziffer ii desselben Artikels, zu Endgeräten, verlangt Sicherheitsmechanismen, die von Mitarbeitenden oder IKT-Drittdienstleistern nicht unbefugt verändert, entfernt oder umgangen werden können.
Für einen SaaS-Anbieter ist die Rollenzuweisung das Dokument zur geteilten Verantwortung: welche Sicherheitseinstellungen der Kunde konfiguriert, welche der Anbieter betreibt und welche der Kunde nicht abschalten darf. Die Maßnahmen an Ihrer Infrastruktur sind die Maßnahmen, die der Geltungsbereich Ihres Zertifikats beschreibt, und der Rahmen des Kunden wird sie mit Verweis auf eine Norm abfragen.
Verschlüsselte Verbindungen über Netze Dritter, Artikel 13
Artikel 13 verlangt Maßnahmen zur Netzsicherheit, die die Verschlüsselung von Netzverbindungen über Unternehmensnetze, öffentliche Netze, Heimnetze, Netze Dritter und drahtlose Netze für die verwendeten Kommunikationsprotokolle einschließen, unter Berücksichtigung der Datenklassifizierung, und für die Netzdienste des Unternehmens die Dokumentation, ob sie von einem gruppeninternen oder von Drittdienstleistern erbracht werden. Die Antwort des Anbieters ist die Verschlüsselung bei der Übertragung für jede Verbindung zwischen dem Kunden und dem Produkt und zwischen dem Produkt und seinen Unterauftragnehmern, mit aufgeschriebenen Protokollversionen.
Quellcode von Anbietern wird vor der Produktion analysiert und getestet, Artikel 16
Artikel 16 verlangt eine Leitlinie für Beschaffung, Entwicklung und Wartung von IKT-Systemen und ein Verfahren zum Testen und Freigeben aller IKT-Systeme vor ihrer Nutzung und nach Wartung, angemessen zur Kritikalität der betroffenen Geschäftsprozesse und Assets. Das Verfahren enthält Maßnahmen zum Schutz der Integrität von Quellcode, der intern oder von einem Anbieter entwickelt und dem Unternehmen geliefert wird, und sieht vor, dass proprietäre Software und, soweit machbar, von Drittdienstleistern gelieferter oder aus Open-Source-Projekten stammender Quellcode vor dem Einsatz in der Produktionsumgebung analysiert und getestet wird. Für einen Anbieter, dessen Produkt der Kunde installiert, ist das das Recht des Kunden, Ihr Release vor dem Produktivgang zu testen und Integritätsmaßnahmen an dem zu sehen, was Sie liefern: signierte Releases, Prüfsummen, eine Build-Pipeline, die Sie beschreiben können. Für einen SaaS-Anbieter ist es das Interesse des Kunden an Ihren eigenen Release-Tests, denn der Einsatz in der Produktion geschieht auf Ihrer Seite.
Ein benanntes Konto für jede Ihrer Mitarbeitenden mit Zugang, Artikel 20
Artikel 20 verlangt Leitlinien für das Identitätsmanagement, nach denen jeder Mitarbeitenden des Unternehmens oder eines IKT-Drittdienstleisters, die auf die Informations- und IKT-Assets des Unternehmens zugreift, eine eindeutige Identität mit einem eindeutigen Benutzerkonto zugewiesen wird. Wo Ihr Support-Personal in die Umgebung des Kunden hineingreift, wird der Kunde ihm benannte Konten ausstellen und von Ihnen erwarten, dass Sie ihm sagen, wer kommt und wer geht; wo es nur in Ihre eigene Umgebung greift, wird der Fragebogen des Kunden verlangen, dass Sie dieselbe Regel bei sich zeigen.
Ihre Vorfallmeldungen sind eine der Erkennungsquellen des Kunden, Artikel 23
Artikel 23 verlangt einen Mechanismus zur schnellen Erkennung anomaler Aktivitäten, der unter anderen Quellen IKT-bezogene Vorfallmeldungen eines IKT-Drittdienstleisters, die in dessen eigenen Systemen und Netzen erkannt wurden und das Unternehmen beeinträchtigen können, sammelt, überwacht und auswertet. Die Alarmierung des Kunden ist darauf ausgelegt, Ihre Meldungen als Feed neben seinen eigenen Protokollen und Bedrohungsinformationen zu empfangen und sie so zu priorisieren, dass sie innerhalb seiner erwarteten Lösungszeit bearbeitet werden, während und außerhalb der Arbeitszeiten. Der Artikel zu schwerwiegenden Vorfällen erklärt, was dann passiert: Die Vier-Stunden-Frist beim Kunden beginnt mit seiner Einstufung, und Ihre Meldung ist das, was ihn einstufen lässt.
Kontinuitätstests schließen Ihren Dienst und Ihre Insolvenz ein, Artikel 25 und 26
Artikel 25 verlangt, dass die Tests der IKT-Geschäftsfortführungspläne des Unternehmens, soweit zutreffend, das Testen der von Drittdienstleistern erbrachten IKT-Dienste enthalten sowie Verfahren zur Überprüfung, ob das Personal des Unternehmens, seine Anbieter, seine Systeme und seine Dienste angemessen auf die Szenarien aus Artikel 26 reagieren können; für die Anbieterszenarien berücksichtigt das Unternehmen gebührend die Insolvenz oder das Versagen des Anbieters und politische Risiken im Land des Anbieters. Artikel 26 verlangt, dass die Reaktions- und Wiederherstellungspläne Szenarien berücksichtigen, in denen eine kritische oder wichtige Funktion sich verschlechtert oder ausfällt, mit der möglichen Auswirkung einer Insolvenz oder eines anderen Versagens eines Anbieters, sowie politische und soziale Instabilität im Land des Anbieters und dort, wo die Daten gespeichert und verarbeitet werden, und dass Kontinuitätsmaßnahmen zur Abfederung von Ausfällen der Anbieter von Diensten, die kritische oder wichtige Funktionen unterstützen, umgesetzt werden. Der Teil des Anbieters ist das Ausstiegs- und Übergangsverfahren aus der Klausel-Checkliste zu Artikel 30, 30(3)(f), und seine Bereitschaft, am Kontinuitätstest des Kunden teilzunehmen, die Buchstabe c von Artikel 30 Absatz 3 bereits in den Vertrag schreibt.
Was ein ISO-27001-System bereits beantwortet
Die Delegierte Verordnung nennt keine Norm, und das Folgende ist StandardOS' Lesart, wo ein Managementsystem nach ISO/IEC 27001:2022 die Antworten erzeugt, ohne Vermutung der Konformität. Artikel 4 Absatz 2 Buchstabe b Ziffer ix ist das Inventar der Werte, A.5.9, wenn das Inventar Support-Enddaten trägt. Artikel 10 ist die Maßnahme zum Schwachstellenmanagement, A.8.8, und die Berichtsvereinbarungen mit Lieferanten aus A.5.20; die Komponentenliste ist dieselbe Aufzeichnung, die der CRA verlangt. Artikel 11 Buchstabe k ist die Lieferantenvereinbarung, A.5.20, und die Konfigurationsmaßnahme, A.8.9; Buchstabe f Ziffer ii ist A.8.1 und A.8.7. Artikel 13 ist A.8.20 bis A.8.22 und die Kryptografiemaßnahme, A.8.24. Artikel 16 ist die sichere Entwicklung, A.8.25 bis A.8.29, mit dem Release-Test aus A.8.29 und der Änderungssteuerung aus A.8.32. Artikel 20 ist A.5.16, Identitätsmanagement, und A.5.18, Zugangsrechte. Artikel 23 ist die Planung des Vorfallmanagements aus A.5.24 und die Protokollierung und Überwachung aus A.8.15 und A.8.16, woher die Meldung kommt. Artikel 25 und 26 sind A.5.29 und A.5.30 und die Kontinuitätstests, die sie verlangen. Was die Norm Ihnen nicht gibt, sind das Inventar des Kunden, seine Klassifizierung Ihres Dienstes und seine Szenarien; das sind Fragen, die Sie mit Fakten beantworten, und das Datenblatt zum Register hält die zu Standorten und Unterauftragnehmern bereit.
Was zu tun ist, bevor die Fragen des Rahmens kommen
Veröffentlichen Sie einen Support-Lebenszyklus mit Daten je Version. Erstellen Sie eine Komponentenliste mit Versionen und einen regelmäßigen Schwachstellenbericht, und schreiben Sie den Berichtsrhythmus in den Vertrag. Schreiben Sie das Dokument zur geteilten Verantwortung, das die Rollen nach Artikel 11 Buchstabe k zuweist, einschließlich der Einstellungen, die der Kunde nicht abschalten darf. Dokumentieren Sie die Verschlüsselung bei der Übertragung mit Protokollversionen. Beschreiben Sie die Release-Pipeline und ihre Integritätsmaßnahmen. Wenden Sie benannte Konten auf Ihre eigenen Mitarbeitenden an und bieten Sie die Ein- und Austrittsmeldung für Konten in der Umgebung des Kunden an. Leiten Sie Ihre Vorfallmeldungen in einen Kanal, den der Kunde aufnehmen kann. Und proben Sie den Ausstieg mit dem Kunden, wenn er darum bittet, denn Artikel 25 sagt, dass er es tun wird. Der DORA-Hub hält die Daten der Verordnung und ihrer Rechtsakte bereit.