Referenzen und Zertifikate von SaaS-Anbietern prüfen: öffentliche Quellen

Was sich an Referenzen und Zertifikaten überhaupt öffentlich prüfen lässt

Ein ISO-27001-Siegel auf der Marketingseite, Kundenlogos und die Angabe «zertifiziert» sind Selbstdeklarationen. Prüfbar werden sie erst über eine vom Anbieter unabhängige Stelle: das Verzeichnis der ausstellenden Zertifizierungsstelle, einen öffentlichen Schlüssel zur Signaturprüfung oder die Vergabemeldung der auftraggebenden Stelle. Geprüft wird also nicht durch Nachfragen beim Anbieter, sondern durch Nachprüfen seiner Angaben bei Dritten.

Vier Belegkategorien sind öffentlich zugänglich, und jede belegt etwas anderes. Ein Registereintrag bei der Zertifizierungsstelle belegt Existenz, Inhaber, Geltungsbereich und Geltungsdauer eines Zertifikats – nicht, dass dieser Geltungsbereich die konkret bezogene SaaS-Leistung abdeckt. Eine Signatur belegt, dass ein Dokument unverändert vom Inhaber eines bestimmten Schlüssels stammt – nicht, dass der Inhalt korrekt ist. Ein öffentlicher Schlüssel unter einer festen Adresse auf der Domain des Anbieters belegt, wer zur Ausstellung berechtigt ist, und macht die Prüfung von der Mitwirkung des Anbieters unabhängig. Eine Vergabemeldung belegt, wer wann einen öffentlichen Auftrag erhalten hat – nicht, wie das Projekt verlaufen ist.

Für die Beschaffung heisst das: pro Beleg festlegen, was verlangt und wo selbst nachgeprüft wird. Vom Anbieter Zertifikatsnummer und ausstellende Stelle verlangen statt einer PDF-Kopie; Speicherort des öffentlichen Schlüssels samt Fingerabdruck verlangen statt eines Berichts als Mailanhang; zu Referenzprojekten Vergabestelle und Vergabedatum verlangen, damit die Meldung selbst gesucht werden kann. Vertraglich zu regeln ist die Nachführung: Zertifikate sind ohne Lücke zu erneuern, neue Berichtsversionen signiert nachzuliefern.

Vergleich der vier öffentlich prüfbaren Belegkategorien

Zertifikate im Register der Zertifizierungsstelle gegenprüfen

Ein ISO-27001-Zertifikat stellt nicht die geprüfte Organisation aus: Eine akkreditierte Zertifizierungsstelle führt ein externes Audit durch und prüft, ob das Informationssicherheits-Managementsystem (ISMS) die Normanforderungen erfüllt. Aussteller und Inhaber der Urkunde sind zwei verschiedene Parteien; die ausstellende Stelle führt ein eigenes Zertifikatsverzeichnis. Dort wird gegengeprüft, nicht auf der Anbieterseite.

Aus der Urkunde sind sechs Angaben zu übernehmen: Rechtsbezeichnung des zertifizierten Unternehmens statt Produkt- oder Markenbezeichnung, Zertifikatsnummer, Norm samt Ausgabejahr (etwa ISO/IEC 27001:2022), ausstellende Zertifizierungsstelle, Geltungsdauer und wortwörtlicher Geltungsbereich. Der Geltungsbereich entscheidet über den Nutzen: Er nennt Standorte, Geschäftseinheiten und Tätigkeiten, die auditiert wurden. Konzernzertifikate decken selten jede Tochtergesellschaft und jeden Dienst ab; ein Zertifikat für Entwicklung und Betrieb bedeutet nicht automatisch, dass das für Sie relevante Rechenzentrum oder die eingesetzten Unterauftragnehmer enthalten sind.

Neben dem Geltungsbereich ist der Auditzyklus zu prüfen. Zertifikate haben eine Geltungsdauer und werden während dieser durch wiederkehrende Überwachungsaudits begleitet; vor Ablauf steht ein Erneuerungsaudit. Fragen Sie nach Datum und Art des letzten Audits und vergleichen Sie dies mit der Geltungsdauer. Läuft ein Zertifikat in wenigen Monaten ab und fehlt der Nachweis der Erneuerung, ist die Aussage «zertifiziert» nur so lange belastbar wie das Papier.

Datenschutz-Zertifizierungen nach Schweizer Recht einordnen

Seit dem 1. September 2023 gelten das revidierte Datenschutzgesetz (DSG) sowie die neuen Ausführungsbestimmungen in der Datenschutzverordnung (DSV) und der Verordnung über Datenschutzzertifizierungen (VDSZ); Übergangsfristen sind keine vorgesehen. Das revidierte DSG schützt Persönlichkeit und Grundrechte natürlicher Personen mit Aufenthalt in der Schweiz, deren Daten Private oder der Staat bearbeiten; Daten juristischer Personen sind nicht mehr geschützt. Für die SaaS-Beschaffung bedeutet das: Eine Datenschutzzertifizierung betrifft Personendaten natürlicher Personen – Firmendaten, die derselbe Dienst ebenfalls verarbeitet, fallen nicht darunter.

Die VDSZ bildet den Rahmen für Datenschutzzertifizierungen nach dem DSG. Prüfbar sind wie bei jedem Zertifikat die ausstellende Stelle, deren Zulassung für den betreffenden Bereich, der in der Urkunde umschriebene Gegenstand – welche Bearbeitungen und welche Teile der Organisation geprüft wurden – sowie die Geltungsdauer. Verlangen Sie Urkunde und Bezeichnung der zertifizierenden Stelle und bestehen Sie darauf, den Eintrag selbst einsehen zu können.

Eine Zertifizierung des Anbieters ersetzt nicht die Prüfung der eigenen Verantwortung. Wer als Verantwortlicher Personendaten an einen SaaS-Anbieter auslagert, bleibt gegenüber den betroffenen Personen für die Bearbeitung verantwortlich; zertifiziert sind die Prozesse des Anbieters, nicht der Einsatz des Dienstes durch Sie. Zur Beschaffung gehören deshalb zusätzlich eigene Abklärungen: welche Personendaten in welchem Umfang in den Dienst gelangen, welche Auftragsbearbeitung vereinbart wird, wo die Daten bearbeitet und gespeichert werden und wie sie bei Vertragsende zurückgeholt und gelöscht werden.

Relevante gesetzliche Grundlagen für Datenschutz-Zertifizierungen in der Schweiz

Signierte Berichte und öffentliche Schlüssel selbst verifizieren

Sicherheitsberichte, Penetrationstest-Berichte und Auditunterlagen sollten als signierte Dateien verlangt werden, nicht als gewöhnlicher PDF-Anhang. In der Schweiz werben Anbieter von Sicherheitstests mit PGP-signierten Reports. Die Signatur erlaubt eine Gegenprobe ohne Rückfrage beim Absender: Stimmt sie, ist die Datei seit der Ausstellung unverändert und stammt vom Inhaber des zugehörigen privaten Schlüssels.

Das Prüfmuster, das Transpareo für den Digitalen Produktpass beschreibt, lässt sich direkt übertragen: Der Aussteller veröffentlicht seine Kennung beziehungsweise seinen öffentlichen Schlüssel auf seiner eigenen Domain unter einer festen Adresse (nach dem W3C-Standard DID:web), die Prüfung läuft im Browser des Betrachters und kontaktiert keinen Server des Anbieters, und die Anzeige-App ist quelloffen, sodass der Prüfcode gelesen werden kann. Der private Schlüssel bleibt beim Aussteller; ein zweiter Aussteller ergänzt höchstens eine Gegensignatur. Für die Beschaffung heisst das: Verlangen Sie die Adresse der Schlüsselablage und prüfen Sie eine gelieferte Datei selbst nach.

Bewusst keine klassische Zertifikatskette: Zertifikatsketten verfallen über Jahre, während eine Adresse auf der eigenen Domain robust bleibt. Wer Nachweise aufbewahrt, die auch nach langer Zeit noch überprüfbar sein sollen, setzt deshalb auf dauerhaft erreichbare Schlüsseladressen und nicht auf eine Kette, deren Wurzel in der Zwischenzeit abgelaufen sein kann. Liegt die Signatur nicht als Block über dem Dokument, sondern über jeder einzelnen Angabe, bleiben auch später ergänzte Felder nachweisbar, ohne dass neu signiert werden muss.

Vertraglich zu regeln sind der Veröffentlichungsort von öffentlichem Schlüssel und Fingerabdruck, die Pflicht zur signierten Lieferung jedes Berichts und – weil eine Signatur nur so lange prüfbar bleibt, wie der Schlüssel auffindbar ist – die Aufbewahrung von Schlüssel und Bericht im eigenen Archiv.

Referenzen aus öffentlichen Vergabedaten rekonstruieren

Referenzen lassen sich über öffentliche Vergabeinformationen nachvollziehen, weil Zuschläge und Rahmenverträge gemeldet werden. Der methodische Ansatz nutzt drei Zeithorizonte gleichzeitig: die Vergangenheit (wer ist der Platzhirsch?), die Gegenwart (welche Ausschreibungen passen heute?) und die Zukunft (welche Rahmenverträge laufen demnächst aus?). Für die Anbieterprüfung heisst das: Vergabemeldungen mit dem Namen des Anbieters suchen und Auftraggeber, Gegenstand, Datum und Laufzeit erfassen, statt sich auf die Referenzliste in der Präsentation zu verlassen.

Für das Timing lohnt der Blick auf die Vertragswerke: Ein Überblick über öffentliche IT-Aufträge im DACH-Raum nennt für Deutschland EVB-IT-Rahmenverträge, für Österreich AVB-IT und für die Schweiz die Informatik-AGB mit ihren Vierjahreszyklen; er empfiehlt, diese Laufzeiten als Timing-Instrument zu nutzen. Wer weiss, wann ein Rahmenvertrag ausläuft, weiss auch, wann ein Anbieter wieder im Wettbewerb steht und wann Referenzen und Konditionen neu verglichen werden können.

Ein wiederkehrender Incumbent ist die aussagekräftigste Referenz und das deutlichste Warnsignal zugleich. Ein Anbieter, der seit Jahren beim Auftraggeber sitzt, kennt die Infrastruktur und hat sein System bereits integriert; wer neu anbietet, startet bei null. Aus der Reihenfolge der Zuschläge und den Laufzeiten der Rahmenverträge lässt sich deshalb ablesen, wo Abhängigkeiten bestehen, wie lange ein Auftraggeber bereits gebunden ist und wann sich der Markt für eine Neuvergabe öffnet.

Laufzeiten von Rahmenverträgen im DACH-Raum – Timing-Instrument für SaaS-Beschaffung

Anschluss- und Interoperabilitätsnachweise im Bundesumfeld prüfen

eIAM ist das zentrale Zugriffs- und Berechtigungssystem des Bundes; AGOV ist ein inhärenter Bestandteil von eIAM und nimmt eine besondere Stellung ein, während sich CH-LOGIN im Phase-out befindet. Öffentlich einsehbar ist das Merkblatt für Beschaffungen «Anschluss von Applikationen an eIAM» (Version 1.7 vom 9. Oktober 2024) als Grundlage für Anschlussfragen. Es behandelt den Anschluss von Applikationen an eIAM und ist in der zum Beschaffungszeitpunkt aktuellen Fassung zu lesen.

Nach diesem Merkblatt gilt für Webapplikationen und native Mobile-Apps eine eIAM-Bezugspflicht. Der Anschluss kann direkt oder indirekt erfolgen, wobei mehrere indirekte Anschlussvarianten bestehen; das Merkblatt unterscheidet zudem Fälle, in denen die Dienste des EJPD zu nutzen sind, von solchen, in denen der Service eIAM zum Einsatz kommt. Bevor Sie eine Interoperabilitätszusage akzeptieren, lassen Sie sich die gewählte Anschlussvariante und den vorgesehenen Weg schriftlich bezeichnen und prüfen die Bezugspflicht gegen das Merkblatt.

Prüfbar ist das ohne Mitwirkung des Anbieters: Das Merkblatt liegt öffentlich vor, ebenso die Angaben zu eIAM, AGOV und den Identitätsprovidern, aus denen eIAM elektronische Identitäten bezieht. Die Fragen an den Anbieter richten sich damit auf Belegbares – welche Anschlussvariante, gestützt auf welche Version des Merkblatts, mit welcher Stelle abgestimmt – und nicht auf allgemeine Zusicherungen der Interoperabilität.

Warnsignale und die Grenzen der öffentlichen Prüfung

Warnsignale ergeben sich direkt aus öffentlichen Quellen: ein Siegel ohne auffindbaren Registereintrag; ein Zertifikat, dessen Geltungsbereich die betriebene Leistung, den Standort oder die Unterauftragnehmer nicht umfasst; ein abgelaufenes Zertifikat ohne Nachweis der Erneuerung; genannte Referenzkunden ohne Vergabemeldung und ohne Datum; ein Sicherheitsbericht als PDF ohne Signatur.

Die daraus folgenden Fragen gehen direkt an den Anbieter: Zertifikatsnummer, ausstellende Stelle, wortwörtlicher Geltungsbereich, Geltungsdauer, Datum und Art des letzten Audits; Adresse und Fingerabdruck des öffentlichen Schlüssels sowie die Zusage, jeden Bericht signiert zu liefern; Vergabestelle, Auftragsgegenstand und Datum für jede genannte Referenz; die gewählte eIAM-Anschlussvariante samt Version des Merkblatts. Wer keine dieser Angaben erhält, hat damit bereits eine Antwort.

Die Grenzen der öffentlichen Prüfung sind ebenso klar: Nachvollziehbar ist nur, was eine dritte Stelle publiziert. Interne Auditfeststellungen, die Liste der Unterauftragnehmer, die Incident-Historie und der aktuelle Zustand einer produktiven Instanz lassen sich so nicht überprüfen; dafür braucht es vertraglich gesicherte Auskünfte und Prüfrechte. Ein Zertifikat belegt ein funktionierendes Managementsystem, nicht die Sicherheit einer bestimmten Konfiguration im Betrieb.

Prüfpunkte für Referenzen und Zertifikate aus öffentlichen Quellen

Vorteile und Grenzen der öffentlichen Prüfung von SaaS-Anbietern