Art. 21(3) der NIS-2-Richtlinie richtet die Sicherheits-Due-Diligence eines regulierten Käufers gegenüber seinen Lieferanten auf deren «Cybersicherheitspraxis», die ENISA hat die Liste veröffentlicht, die Spitäler verlangen sollen, und das nackte Badge auf einer Trust-Seite beantwortet nichts davon: eine Position dazu, was eine Seite behaupten darf und was neben jeder Behauptung stehen muss.
Art. 21(3) der NIS-2-Richtlinie richtet die Sicherheits-Due-Diligence eines regulierten Käufers gegenüber seinen Lieferanten auf deren «Cybersicherheitspraxis», die ENISA hat die Liste veröffentlicht, die Spitäler verlangen sollen, und das nackte Badge auf einer Trust-Seite beantwortet nichts davon: eine Position dazu, was eine Seite behaupten darf und was neben jeder Behauptung stehen muss.
Öffnen Sie die Trust-Seite eines Anbieters, und das Erste, was Ihnen meist begegnet, ist ein Badge: ein Framework-Name, ein Logo, manchmal ein Häkchen. Es ist das am wenigsten informative Element der Seite, weil es für drei verschiedene Aussagen stehen kann. Eine akkreditierte Stelle kann das Unternehmen auditiert und ein Zertifikat ausgestellt haben, das Unternehmen kann sich selbst an der Norm gemessen haben, oder das Badge kann eine Logodatei sein und sonst nichts, und alle drei werden identisch dargestellt. Der Leser auf der anderen Seite hat jetzt eine Liste: Am 22. Juli 2026 hat die ENISA ihre Beschaffungsleitlinien für die Cybersicherheit von Spitälern und Gesundheitsdienstleistern veröffentlicht, die festhalten, was ein Spital von einem Anbieter verlangen soll. Haben Sie Ihre eigene Trust-Seite schon so gelesen, wie dieses Spital sie lesen wird?
Ein Hinweis zur deutschen Fassung dieses Beitrags: Zitate aus der NIS-2-Richtlinie folgen der amtlichen deutschen Fassung auf EUR-Lex. ENISA und NIST veröffentlichen nur auf Englisch; ihre Zitate stehen hier im Original, jeweils mit einer sinngemässen deutschen Wiedergabe. Die Zitate von www.devguard.ch/trust stammen aus der deutschen Sprachfassung dieser Seite.
Die NIS-2-Richtlinie bindet die wesentlichen und wichtigen Einrichtungen, die sie erfasst, und Artikel 21 ist ihre Mindestliste der Risikomanagementmassnahmen. Buchstabe d von Art. 21(2) setzt «Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zwischen den einzelnen Einrichtungen und ihren unmittelbaren Anbietern oder Diensteanbietern» auf diese Liste, und Art. 21(3) sagt, was die Einrichtung abwägt, wenn sie entscheidet, welche dieser Massnahmen geeignet sind:
«Die Mitgliedstaaten stellen sicher, dass die Einrichtungen bei der Erwägung geeigneter Maßnahmen nach Absatz 2 Buchstabe d des vorliegenden Artikels die spezifischen Schwachstellen der einzelnen unmittelbaren Anbieter und Diensteanbieter sowie die Gesamtqualität der Produkte und der Cybersicherheitspraxis ihrer Anbieter und Diensteanbieter, einschließlich der Sicherheit ihrer Entwicklungsprozesse, berücksichtigen.»
Der Satz nennt die spezifischen Schwachstellen des Anbieters, die Gesamtqualität seiner Produkte und seine Cybersicherheitspraxis, bis hin zur Sicherheit seiner Entwicklungsprozesse. Die Wörter «Zertifikat», «Zertifizierung» und «zertifiziert» kommen in Artikel 21 nirgends vor. Worüber sich der Käufer nach 21(3) ein Bild machen soll, ist, wie der Anbieter arbeitet.
Die Pflicht liegt beim Käufer: Der Abschnitt zum Geltungsbereich der ENISA-Leitlinien hält fest, dass die NIS-2-Richtlinie «does not directly impose requirements on information and communications technology (ICT) suppliers» (sinngemäss: Anbietern von Informations- und Kommunikationstechnologie (IKT) nicht unmittelbar Anforderungen auferlegt), sie erreicht Sie also als Due Diligence Ihrer regulierten Kunden. Diese Due Diligence beginnt mit dem, was Sie zu veröffentlichen beschlossen haben: Der Fragebogen ist die eingehende Hälfte der Kette; die Trust-Seite ist das, was der Käufer liest, bevor er einen verschickt. Das Verb der Richtlinie lautet «berücksichtigen», nicht «verifizieren»; was eine Seite diesem Leser schuldet, ist deshalb meine Position, und ich vertrete sie als solche.
Der ENISA-Leitfaden für Spitäler macht diese Lesart konkret. Sein Abschnitt zum Geltungsbereich (1.2, S. 5–6) sagt, die Empfehlungen «specify the required security documentation and evidence suppliers must provide for their network and information systems and services» (sinngemäss: legen die erforderliche Sicherheitsdokumentation und die Nachweise fest, die Anbieter für ihre Netz- und Informationssysteme und Dienste vorlegen müssen), und sein rechtlicher Hinweis nennt das Dokument die «views and interpretations» (sinngemäss: Auffassungen und Interpretationen) der ENISA; sein «must» ist also Orientierungshilfe für das Spital.
PLAN-02 (S. 16) verlangt «verifying adherence to mandated standards, certifications and regulations such as ISO 27001, the EHDS Regulation and the MDR/IVDR» (sinngemäss: die Einhaltung vorgeschriebener Normen, Zertifizierungen und Vorschriften wie ISO 27001, der EHDS-Verordnung und der MDR/IVDR zu prüfen). SOURCE-01 (S. 21), die Massnahme zur Anbieterauswahl, beginnt so:
«When feasible, healthcare providers must prioritise the selection of ICT product and service suppliers who demonstrate certified compliance with relevant security standards and regulations, including MDR/IVDR requirements and the EHDS Regulation.»
Sinngemäss: Wo machbar, müssen Gesundheitsdienstleister bei der Auswahl von Anbietern von IKT-Produkten und -Diensten solche bevorzugen, die eine zertifizierte Einhaltung einschlägiger Sicherheitsnormen und Vorschriften nachweisen, einschliesslich der MDR/IVDR-Anforderungen und der EHDS-Verordnung.
Die Checklistenzeile für klinische Informationssysteme verlangt vom Spital zu prüfen, dass die Anbieterauswahl «includes evaluation of their product certifications and security audit reports» (sinngemäss: die Bewertung von deren Produktzertifizierungen und Sicherheits-Auditberichten einschliesst) (SOURCE-01.03). Jeder Punkt auf dieser Liste ist ein Dokument. Ein Badge ist keines.
Auf keiner seiner 69 Seiten stellt der Leitfaden eine Zertifizierung der eigenen Erklärung eines Anbieters gegenüber; er nennt immer nur die externe Art, «certified or independently assessed» (sinngemäss: zertifiziert oder unabhängig bewertet). Die Unterscheidung unten stützt sich deshalb auf die Formulierung «Cybersicherheitspraxis» in Art. 21(3) und darauf, was ein Due-Diligence-Leser mit jeder Behauptung anfangen kann. NIST definiert diesen Auftrag. SP 1326, sein Quick-Start-Guide vom Juli 2026, definiert Due Diligence (S. 4) als «the investigative process of researching and verifying all available, pertinent information about a given supplier or product so that informed decisions can be made on new acquisitions or existing systems» (sinngemäss: den Untersuchungsprozess, alle verfügbaren, relevanten Informationen über einen bestimmten Anbieter oder ein bestimmtes Produkt zu recherchieren und zu verifizieren, damit fundierte Entscheidungen über Neubeschaffungen oder bestehende Systeme getroffen werden können), und ordnet die Schreibtischrecherche in öffentlich verfügbaren Informationen, im Gegensatz zur Nachfrage beim Anbieter, der grundlegenden Due Diligence zu. Ihre Trust-Seite ist diese Information, und zum Auftrag gehört, sie zu verifizieren.
Hier ist die Sortierung, die ich auf jede Behauptung einer Trust-Seite anwenden würde. Drei Arten von Aussagen tragen dasselbe Badge; nur die erste lässt sich von aussen prüfen.
Jetzt stellen Sie den Leser aus Art. 21(3), dessen Auftrag laut NIST «researching and verifying» ist, vor jede der drei. Eine Selbstbewertung, die ihr Control-Set nennt, beantwortet die Frage nach der Praxis direkt: Das ist die Norm, so weit sind wir, dann wurde gemessen. Eine Zertifizierung mit ihrem Dokument daneben beantwortet eine stärkere Frage und lässt sich verifizieren. Das nackte Badge beantwortet keine von beiden, weil der Leser nicht erkennen kann, welche der drei es ist, und es abwerten muss. Ich glaube, genau das haben Anbieter verkehrt herum: Eine beschriftete Selbstbewertung sieht schwächer aus als ein Badge und ist für die Person, die die Due Diligence macht, mehr wert, weil man damit arbeiten kann.
Also hier die Regel, an der ich eine Trust-Seite messe, und sie braucht keine bestimmte Software: Eine Trust-Seite darf nur behaupten, was sie neben der Behauptung zeigen kann. Eine Zertifizierung nennt ihre Stelle und ihr Datum und trägt oder verlinkt das Zertifikat. Ein selbst bewerteter Status sagt, woran und wann gemessen wurde. Eine Behauptung, hinter der nichts steht, wird nicht aufgestellt. Die Seite, die dabei herauskommt, ist kürzer, und alles, was auf ihr übrig bleibt, übersteht einen Leser, der nachprüfen darf.
Wir haben eine Implementierung dieser Regel gebaut. Das Register selbst war Thema des Juli-Beitrags: ab Werk ausgeschaltet, drei Arten von Elementen (Framework, Subprocessor, Zertifikat), Zurückziehen löscht, ein rotierbares Handle, Ihre eigene Website rendert die Daten.
Ein veröffentlichtes Framework erscheint in einem von drei Modi: als Status-Badge, der aus der Control-Abdeckung berechnet wird, als genauer Prozentsatz oder als Zusicherung «Zertifiziert»; in den ersten beiden Modi wird alles unter 50 % Abdeckung nie veröffentlicht. Ein Zertifikat ist eine Datei mit Ausstellungs- und Ablaufdatum; abgelaufene fallen von selbst heraus, und Downloads sind ab Werk ausgeschaltet.
Jetzt der Preis: Das Produkt kann eine Zertifizierung nicht verifizieren. Im Modus «Zertifiziert» tippt die veröffentlichende Person eine Zertifizierungsstelle und ein Datum ein, beides optional, und kann ein Zertifikat verlinken, das auf demselben Trust Center veröffentlicht ist; ein Link auf irgendetwas anderes wird abgewiesen. Nichts prüft die Stelle oder das Datum, und die Zusicherung lässt sich ohne alle drei speichern. Das ist schwächer als mein Prinzip: Das Produkt weist einen ins Leere zeigenden Link ab und sonst nichts, eine falsche «Zertifiziert»-Behauptung hat also die veröffentlichende Person zu verantworten. Die Untergrenze verbirgt, statt zu verifizieren; ein Käufer kann ein nie veröffentlichtes Framework nicht von einem unterscheiden, das unter 50 % gefallen ist. Es gibt keinen zugangsbeschränkten Dokumentenfluss: «Auf Anfrage verfügbar» ist eine Beschriftung ohne Anfragemechanismus dahinter. Die öffentlichen Daten enthalten keine Kontaktdaten und kein Branding. Eine gehostete Seite gibt es nach wie vor nicht: devguard liefert die Daten aus, und Sie rendern sie auf Ihrer eigenen Website.
www.devguard.ch/trust wird aus demselben öffentlichen Endpunkt gerendert, den jeder Kunde bekommt, und zeigt, was die Regel kostet. Der Frameworks-Abschnitt sagt, die Abdeckung werde «gegen unser eigenes Control-Set in devguard gemessen, nicht durch ein externes Audit». Der Zeitstempel bei den Subprocessors ist mit «Zuletzt aktualisiert» beschriftet, mit Absicht: Er sagt, wann die Daten erzeugt wurden, und das ist eine andere Behauptung als die, dass jemand sie geprüft hätte. Der Zertifikate-Abschnitt rendert nichts, denn, wie es die FAQ formuliert: «Wir halten noch keine formelle Zertifizierung». Die Seite zeigt weniger, als eine Logo-Wand zeigen würde.
Die Regel braucht Ihre Seite, von der anderen Seite gelesen. Nehmen Sie jede Behauptung darauf und sortieren Sie sie: ein zertifizierter Fakt mit Stelle, Datum und Dokument daneben; ein selbst bewerteter Status, der nennt, woran und wann gemessen wurde; oder Dekoration. Was durch die Sortierung fällt, hat dem Käufer nie etwas gesagt, womit er arbeiten konnte, und dieser Käufer muss Ihre Praxis nach Art. 21(3) ohnehin berücksichtigen. Fangen Sie beim grössten Badge an.
Die Zusicherungsregeln oben beschreiben, wie sich devguards Trust Center heute verhält.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.
Starten Sie kostenlos, bringen Sie Ihre Frameworks mit, und die Nachweise bleiben an der Arbeit, während sie ausgeliefert wird — ohne Setup-Reibung, ohne Feuerwehrübung in der Audit-Woche.