Die Mail kommt aus dem Einkauf und ist drei Zeilen lang: Für die weitere Zusammenarbeit brauche man einen Nachweis über die IT-Sicherheit des Unternehmens. Kein Fragebogen im Anhang, keine Norm, kein Formular, keine Frist. Nur die Erwartung, dass etwas geschickt wird. NIS2 ist da, die Überprüfung der Lieferkette steht auf immer mehr Listen, und damit kommen diese Anfragen jetzt in Serie. Bleibt die Frage, was man zurückschickt und wie man sich auf die nächste Anfrage vorbereitet.
Das Wichtigste in Kürze
- Warum die Anfrage kommt: Der Kunde muss unter NIS2, DORA, ISO 27001 oder TISAX® dokumentieren, dass er seine Lieferanten bewertet. Diese Anforderung gibt er weiter.
- Was als Nachweis zählt: ein Zertifikat, eine Selbstauskunft oder eine technische Prüfung von außen. Der ausgefüllte Fragebogen allein reicht immer seltener.
- Womit zu rechnen ist: Manche Kunden prüfen von sich aus, ohne zu fragen. Was von außen sichtbar ist, kann jeder abfragen.
- Offene Punkte: muss niemand verstecken. Ein bewusst akzeptiertes Restrisiko mit Begründung, kompensierender Maßnahme und Termin ist im Audit ein gültiges Ergebnis.
Warum dein Kunde ausgerechnet jetzt fragt
Seit 6. Dezember 2025 gilt die deutsche NIS2-Umsetzung, in Österreich tritt das NISG 2026 am 1. Oktober 2026 in Kraft. Rund 4.000 österreichische Unternehmen fallen direkt darunter. Sie alle müssen die Sicherheit ihrer Lieferkette bewerten und diese Bewertung dokumentieren. Delegieren geht nicht, raten auch nicht. Also fragen sie ihre Lieferanten. Dasselbe passiert bei DORA in der Finanzbranche, bei jeder ISO-27001-Zertifizierung mit ihrer Lieferantenbewertung und bei TISAX® in der Automobilzulieferung.
Dass die Anfrage oft so unspezifisch klingt, hat einen einfachen Grund: Im Einkauf steht auf der Liste „Nachweis Cybersicherheit einholen“, nicht „Bericht über die extern erreichbare Angriffsfläche“. Wer als Erster etwas Brauchbares schickt, setzt in dieser Lieferkette oft den Standard.
Was zählt als Nachweis der IT-Sicherheit?
Drei Arten werden akzeptiert: ein Zertifikat, eine Selbstauskunft und eine technische Prüfung von außen. Sie belegen Unterschiedliches. Welcher Nachweis verlangt wird, hängt vor allem davon ab, wie kritisch der Kunde die Lieferbeziehung einstuft.
Reicht ein ISO-27001-Zertifikat?
Meistens ja, es ist der stärkste der drei Nachweise. Das Zertifikat belegt ein funktionierendes ISMS inklusive technischer Pflichten: Schwachstellenmanagement nach Annex A 8.8, Härtung, Sicherheitstests, je nach Risikobewertung auch Penetrationstests. Die Königsdisziplin also.
Nur wird das so schnell niemand von einem Lieferanten verlangen, denn eine Zertifizierung ist ein Prozess, der sich über Monate zieht. Gefordert wird sie dort, wo sie vertraglich vereinbart ist, etwa bei Dienstleistern mit Zugriff auf Kundensysteme oder in der Automobilzulieferung. Wenn der Kunde in vier Wochen etwas braucht, hilft ein Zertifizierungsprojekt ohnehin nicht weiter. Vorgeschrieben ist eine Zertifizierung für Lieferanten auch nicht: NIS2 verlangt vom Kunden, dass er bewertet, nicht dass sein Lieferant zertifiziert ist.
Reicht eine Selbstauskunft?
Oft schon, aber immer seltener. Der ausgefüllte Fragebogen deckt vor allem organisatorische Themen ab: Zuständigkeiten, Backup-Konzept, Notfallpläne, Schulungen, Meldewege. Das ist nicht wertlos, bleibt aber eine Aussage über das eigene Unternehmen, vom eigenen Unternehmen.
Üblich ist inzwischen die Kombination aus Fragebogen und technischem Nachweis. Bei kritischen Lieferanten, also dort, wo ein Ausfall oder ein Datenabfluss beim Kunden direkt durchschlägt, geht die Anforderung teilweise bis zum Penetrationstest mit Bericht.
Was zeigt eine technische Prüfung von außen?
Sie beantwortet die Frage, die der Auditor stellt: Was sieht ein Angreifer heute, wenn er die Domain in ein Tool eingibt? Geprüft werden die extern erreichbaren Systeme, bei CheckFix zum Beispiel in fünf Kategorien:
- Mail-Sicherheit, also SPF, DKIM und DMARC der Domain
- TLS/SSL-Verschlüsselung der erreichbaren Dienste
- bekannte Schwachstellen (CVEs) auf den eingesetzten Versionen
- Security-Header der Webdienste
- offene Ports und aus dem Internet erreichbare Dienste
Seriöse Prüfungen arbeiten dabei nicht willkürlich, sondern nach dokumentierten Methodiken: NIST SP 800-115 für die Vorgehensweise, der SSL Server Rating Guide von Qualys SSL Labs für TLS, das Rating der Mozilla HTTP Observatory für Security-Header, die BSI-Richtlinie TR-03182 für E-Mail-Authentifizierung, CVSS für Schwachstellen. Wo es keine Norm gibt, kommt die Erfahrung aus der Pentest-Praxis dazu. Das ist der Grund, warum so ein Bericht im Audit standhält: Die Bewertung ist nachvollziehbar und wiederholbar.
Eine solche Analyse ist nicht-invasiv. Es wird nichts ausgenutzt und in nichts eingedrungen. Sie ersetzt deshalb keinen Penetrationstest.
Darf der Kunde einfach selbst nachschauen?
Ja, und manche tun genau das. Sie lassen die Prüfung selbst laufen und legen anschließend das Ergebnis vor.
Wer abfragt, was ein Server öffentlich beantwortet, dringt nirgends ein. Ein abgelaufenes Zertifikat, ein fehlender DMARC-Eintrag, eine erreichbare Datenbank: Das ist die Außenansicht, die jeder sehen kann, auch der, der es nicht gut meint. Aktives Ausnutzen von Schwachstellen ist etwas anderes und braucht eine schriftliche Freigabe.
Genau diese Außenansicht ist der Punkt. Die häufigsten Einfallstore sind keine ausgefeilten Zero-Days, sondern erreichbare Dienste mit bekannten Lücken, schwache Verschlüsselung und Zugänge, an die sich niemand mehr erinnert. Angreifer suchen automatisiert nach diesen Mustern und nehmen, was schnell geht. Deshalb akzeptieren Auditoren und Einkaufsabteilungen eine externe technische Prüfung als Nachweis, meistens zusätzlich zum organisatorischen Fragebogen.
Frag zurück, bevor du irgendwas schickst
Zwei Rückfragen sparen viel Arbeit:
- Wofür wird der Nachweis gebraucht, und welche Vorgabe steht dahinter?
- In welcher Form und bis wann?
Kommt eine konkrete Antwort, ist klar, was zu liefern ist. Kommt keine, ist auch das eine Information: Dann ist die Anfrage eine Formalie, und ein sauberer externer Sicherheitsbericht erfüllt sie.
Vom Check zum Bericht
Der Ablauf unterscheidet sich je nach Tool. Viele Lösungen wollen erst eingerichtet werden: Ziele hinterlegen, Scanprofile wählen, teilweise Zugänge oder Agenten bereitstellen. Bei CheckFix genügt die dienstliche E-Mail-Adresse, den Rest ermittelt das System selbst, also Subdomains, IP-Adressen, erreichbare Dienste und Zertifikate. Daraus entsteht ein Gesamtrating von A bis F und eine Note je Kategorie. Die Gesamtnote entspricht der schlechtesten Kategorie, eine kritische Lücke lässt sich also nicht durch gute Ergebnisse anderswo ausgleichen.
Interessanter als die Note ist, was danach kommt. Ein Bericht, der nur sagt „Security-Header fehlen“, hilft der IT nicht weiter. Sinnvoll ist ein Ergebnis, das vier Dinge mitliefert:
- eine priorisierte Aufgabenliste mit betroffenen Hosts, IPs und Ports statt einer reinen Befundliste
- eine Dringlichkeit, die sich an der Ausnutzbarkeit orientiert und nicht nur an einem abstrakten Risikowert
- die Möglichkeit, nach der Behebung erneut zu prüfen
- einen Report, der einem Audit standhält, auch wenn nicht gleich alle Lücken geschlossen werden konnten
Der eigentlich starke Nachweis ist nämlich der Re-Check. Der zeigt keinen Zustand, sondern eine Entwicklung: Am 3. März waren zwölf Punkte offen, am 14. April sind es zwei. Das ist die Dokumentation, die der Auditor beim Kunden sehen will, und sie ist mehr wert als ein einzelner guter Score.
Der Security-Check mit A-bis-F-Rating ist bei CheckFix kostenlos, die vollständige ToDo-CheckList inklusive Bericht und Re-Check gibt es ab 490 Euro im Jahr. Typische Funde lassen sich in wenigen Stunden abarbeiten: ein Zertifikat auf dem falschen Hostnamen, DMARC auf none statt auf einer wirksamen Policy, eine fehlende Weiterleitung von HTTP auf HTTPS, ein Remote-Zugang aus einem alten Projekt, den seit Jahren niemand mehr abgedreht hat.
Ein Plan schlägt Panik.
Was tun mit Lücken, die offen bleiben müssen?
Dokumentieren statt verschweigen. Nicht jeder Punkt lässt sich schließen, und das ist nicht automatisch ein Problem.
Der Hoster betreibt einen Server, auf dem bekannte Schwachstellen noch nicht gepatcht sind. Dort lässt sich nicht selbst eingreifen, nur nachfordern und im Zweifel den Anbieter wechseln. Oder ein Port muss offen bleiben, weil ein Kunde darüber Daten abholt. Dann bleibt er offen, aber die Bedingungen drumherum müssen sauber sein: verschlüsselter Transport statt FTP im Klartext, eine IP-Whitelist statt „von überall erreichbar“, ein eigener Zugang pro Partner, Protokollierung. Dasselbe gilt für die alte Maschinensteuerung, die nur TLS 1.0 spricht. Wenn sie bleiben muss, gehört sie in ein eigenes Segment und nicht direkt ans Internet.
Was dich disqualifiziert, ist nicht die offene Lücke. Es ist, sie zu verschweigen.
Zu jedem offenen Punkt gehört deshalb eine kurze Stellungnahme: Warum bleibt er offen, welche kompensierende Maßnahme gibt es, bis wann kommt eine Lösung, wer ist zuständig, und wann wird die Entscheidung erneut geprüft. Bei CheckFix entsteht dieses Dokument direkt aus dem Dashboard, mit Management Response und Maßnahmenplan zu jedem offenen Befund. Das steht jedem CheckFix-Kunden zur Verfügung, nicht nur Lieferanten, die über den Risk Manager eines Auftraggebers eingeladen wurden.
Wo die Scandaten landen
Eine Frage, die öfter gestellt wird: Wohin gehen eigentlich die Daten aus so einer Prüfung? Das Ergebnis ist eine Liste der erreichbaren Systeme samt Schwachstellen, und viele wollen diese Liste nicht bei einem Anbieter außerhalb der EU wissen.
CheckFix läuft auf europäischer Infrastruktur, gehostet bei Hetzner. Der Scan arbeitet regelbasiert nach den oben genannten Methodiken, es kommt keine KI zum Einsatz, außer ein KI-Pentest wird ausdrücklich beauftragt. Scandaten gehen an keinen externen KI-Dienst. Bei einem Kunden, der selbst NIS2-pflichtig ist, kommt diese Frage früher oder später auf.
Was der Bericht nicht abdeckt
Eine externe Analyse zeigt die Außenansicht. Sie sagt nichts über das interne Netz, die Backups, die Notfallpläne oder die Prozessdokumentation. Ein ISMS ersetzt sie nicht, einen Penetrationstest auch nicht.
Und ihre Aussagekraft ist asymmetrisch: Ein schlechtes Ergebnis ist ein verlässliches Warnsignal, ein gutes Ergebnis ist notwendig, aber nicht hinreichend. Wer etwas anderes verkauft, verkauft zu viel. Deshalb verlangen die meisten Kunden beides, den technischen Nachweis und den organisatorischen Fragebogen.
Fazit: Die Anfrage ist besser als ihr Ruf
Eine Sicherheitsanfrage aus dem Einkauf fühlt sich an wie zusätzliche Arbeit ohne Gegenwert. Sie ist aber der einzige Moment, in dem ein Kunde Cybersicherheit von sich aus zum Thema macht. Wer da mit einem Bericht und einem Maßnahmenplan antwortet, statt mit einem hastig ausgefüllten Fragebogen, ist in der Wahrnehmung des Einkaufs kein Risiko mehr, sondern ein Lieferant, mit dem man planen kann.
Und der nächste Kunde, der fragt, bekommt dieselben Unterlagen in fünf Minuten.
Wie bekomme ich einen Sicherheitsnachweis für meinen Kunden?
Am schnellsten über eine automatisierte externe Sicherheitsanalyse: Prüfung starten, die gefundenen Punkte mit der IT beheben, erneut prüfen lassen und dem Kunden den Bericht schicken. Je nach Befundlage dauert das wenige Tage bis wenige Wochen.
Der Bericht deckt den technischen Teil des Lieferkettennachweises ab, den der Kunde für NIS2, DORA, ISO 27001 oder TISAX® braucht. Organisatorische Anforderungen wie ISMS, Backup-Konzept und Notfallpläne werden gesondert nachgewiesen, meist über einen Fragebogen.
Punkte, die offen bleiben müssen, gehören mit Management Response und Maßnahmenplan dokumentiert, samt Begründung, kompensierender Maßnahme und Termin.
Den Einstieg macht der kostenlose Security-Check von CheckFix