Lieferanteninventar für NIS2 aufbauen, Schritt für Schritt

Die Sub-Schritte 6-1-1 bis 6-1-4 des Leitfadens beschreiben, was ins Inventar gehört: Pflichtfelder, Tier-Kriterien, Risikoprofil-Inhalte, Governance-Anforderungen. Was sie nicht beschreiben: wie Sie die Lieferanten finden, die im DSGVO-VVT fehlen, wie eine Klassifizierungssitzung in der Praxis läuft, welche Felder im Risikoprofil schwer zu befüllen sind und was eine formale Freigabe von einer Datei namens "Inventar_final_v3.xlsx" unterscheidet. Genau das zeigt dieser Artikel.

Ergebnis: vollständig klassifiziertes Lieferanteninventar v1.0 – Tier-1-Risikoprofile ausgefüllt, management-freigegeben, Inventar-Owner benannt, Update-System aktiv.

Schritt 1 – Die vollständige Lieferantenliste aufbauen

Der Leitfaden benennt das DSGVO-Verzeichnis von Verarbeitungstätigkeiten als Ausgangspunkt – zu Recht. Alle dort gelisteten Auftragsverarbeiter sind gleichzeitig NIS2-in-scope. Das Problem: Der VVT erfasst nur Lieferanten mit einer Auftragsverarbeiter-Rolle nach Art. 28 DSGVO. Drei Kategorien fehlen regelmäßig.

• SaaS-Anbieter ohne Auftragsverarbeiter-Rolle: Monitoring-Plattformen, Security-Scanner, CI/CD-Dienste – kein Art.-28-Verhältnis, aber potenziell direkter Systemzugang oder geschäftskritische Abhängigkeit.
• IaaS-Anbieter als Sub-Prozessoren: AWS, Azure oder GCP erscheinen im VVT oft nur als Unterauftragnehmer eines Auftragsverarbeiters, nicht als eigenständiger Eintrag. NIS2 bewertet die tatsächliche Abhängigkeit: Wenn Ihr regulierter Dienst auf AWS läuft, ist AWS Tier-1-Kandidat – unabhängig davon, wer im VVT als Vertragspartner steht.
• Software-Hersteller mit Auto-Update-Mechanismus: Kein DSGVO-Verhältnis, aber faktischer privilegierter Systemzugang. Der Update-Prozess mit Systemrechten ist ein eigenständiger Angriffspfad (→ A-31).

Um diese Lücken systematisch zu schließen, brauchen Sie drei Suchroutinen – zusätzlich zum VVT-Export.

Suchroutine 1 – Kostenstellen-Scan

Exportieren Sie alle IT-relevanten Buchungspositionen der letzten 12 Monate aus dem Buchhaltungssystem und alle Kreditkartenabrechnungen der IT-Kostenstellen. Gesucht: wiederkehrende Zahlungen an Software- und Cloud-Anbieter. Nicht der Händlername zählt (z. B. "AWS Marketplace"), sondern der dahinterliegende Dienst – eine Buchungsposition kann mehrere SaaS-Produkte enthalten.

Typische Funde: Monitoring-as-a-Service, Penetrationstesting-Plattformen, DevOps-Tools, abteilungsspezifische SaaS-Abos, die am IT-Einkaufsprozess vorbeigehen.

Suchroutine 2 – Firewall-Outbound / DNS-Log

Ein 30-Tage-Snapshot der ausgehenden Verbindungen zeigt, mit welchen externen Diensten Ihre Systeme regelmäßig kommunizieren. Keine PCAP-Analyse nötig: DNS-Querylog oder Firewall-Policy-Auswertung mit Unique-Destination-Liste reicht.

Was Sie suchen: wiederkehrende Verbindungen zu Domains, die kein bekannter VVT-Lieferant sind – insbesondere Update-Server (Muster: update.[vendor].com, cdn.[vendor].com), Telemetrie-Endpoints von installierter Software und API-Endpoints von SaaS-Integrationen. Der häufigste Fund: Software-Hersteller mit Auto-Update, der in keiner anderen Quellliste auftaucht.

Suchroutine 3 – Strukturierte Interviews

Der Kostenstellen-Scan findet, was bezahlt wird. Das Interview findet, was genutzt wird, ohne offiziell beschafft worden zu sein.

• IT und DevOps: "Welche externen Dienste nutzt ihr für Deployment, Monitoring, Testing, Backup?" Häufige Funde: GitHub-Actions-Runner auf externen Servern, externe Log-Aggregatoren, Cloud-Backup-Dienste.
• Fachabteilungen (HR, Finance, Marketing): "Welche Tools nutzt ihr, für die ihr kein IT-Ticket gestellt habt?" Häufige Funde: HR-Software mit Personalakten, Marketing-Automatisierungsplattformen mit CRM-Anbindung.
• Einkauf: "Welche Software-Lizenzen oder Service-Verträge laufen nicht über die IT-Kostenstelle?" Häufige Funde: Branchensoftware-Wartungsverträge, Outsourcing-Verträge mit implizitem Systemzugang.

Protokoll führen: zwei Sätze je Gespräch – Datum, Person, Kernaussagen. Das Interview ist Teil des Inventar-Aufbaus und damit auditierbar.

Output Schritt 1: vollständige Rohliste aller Lieferanten mit Datenquelle ("VVT", "Kostenstellen-Scan", "Firewall-Log", "Interview [Abteilung]"). Die Datenquelle ist kein Nice-to-have – sie dokumentiert, dass der Scope systematisch erhoben wurde.

Schritt 2 – Tier-Klassifizierung: wie die Entscheidung wirklich funktioniert

Die Tier-Kriterien sind klar: Tier 1 bei direktem privilegiertem Zugang oder hochschutzbedarftigen Daten, Tier 2 bei indirekten Abhängigkeiten, Tier 3 ohne Relevanz. Was der Leitfaden nicht beschreibt: wie eine Klassifizierungssitzung funktioniert, welche Fragen in welcher Reihenfolge weiterhelfen und wie man mit Grenzfällen und Uneinigkeit umgeht.

Wer in der Sitzung sein muss

• ISB: führt die Sitzung und trifft bei Uneinigkeit den formalen Entscheid.
• IT-Leiter: kennt Systemzugänge, Netzwerkarchitektur und technische Abhängigkeiten.
• Fachbereichsleitung (bei SaaS-Applikationen): weiß, welche Geschäftsdaten tatsächlich im System liegen. Ohne sie ist die Datenkritikalität von SaaS-Lösungen nicht verlässlich einzuschätzen – und damit Tier 1 vs. Tier 2 bei datenzugangsbezogenen Lieferanten nicht entscheidbar.

Die drei Entscheidungsfragen in der richtigen Reihenfolge

Für jeden Lieferanten – in dieser Reihenfolge:

1. Systemzugang – Art und Tiefe? (administrativ / lesend / API / physisch / kein direkter Zugang)
2. Datenzugang – betrifft Assets mit Schutzbedarf "hoch" oder "sehr hoch" gemäß der Schutzbedarfsanalyse aus Schritt 2-2?
3. Operationelle Abhängigkeit – was passiert bei einem vollständigen Ausfall dieses Lieferanten für 72 Stunden?

Die dritte Frage wird am häufigsten unterschätzt. Ein Cloud-IaaS-Anbieter ohne privilegierten Direktzugang ist trotzdem Tier 1, wenn Ihr regulierter Dienst ausschließlich dort betrieben wird und kein kurzfristiger Failover existiert. Zugriffsart allein ist kein ausreichendes Klassifizierungskriterium.

Die Begründungszeile – konkrete Beispiele

Jede Klassifizierungsentscheidung braucht eine Begründungszeile im Inventar. Ohne sie ist das Inventar nicht auditierbar – das Ergebnis steht, aber der Entscheidungsweg ist unklar.

Nicht auditierbar:

• "Tier 2 – kein kritischer Lieferant"
• "Tier 1 – wichtiger Cloud-Anbieter"

Auditierbar:

• Tier 2: "Zugang ausschließlich über Support-Ticket-System, kein Direktzugang zu Systemen, verarbeitete Daten Schutzbedarf normal gemäß SBA v2.1, Ausfall ohne Betriebsunterbrechung < 72h"
• Tier 1: "Produktionsdatenbank auf AWS RDS eu-central-1, kein Failover-Standort in < 72h verfügbar, Ausfall unterbricht Dienst X (Schutzbedarf hoch) unmittelbar"
• Tier 1: "SaaS-HR-System enthält Personalakten aller Mitarbeitenden (Schutzbedarf hoch), kein direkter Systemzugang, aber Datenzugang und operationelle Abhängigkeit für Payroll-Prozess"

Uneinigkeit dokumentieren – nicht verschweigen

Wenn ISB und IT-Leiter bei einem Lieferanten nicht einig sind: ISB trifft den formalen Entscheid, der Dissens wird mit einem Satz dokumentiert. Ein undokumentierter Schattenkonsens ist im BSI-Aufsichtsverfahren schlechter als ein dokumentierter Entscheid gegen eine Minderheitsmeinung.

Output Schritt 2: vollständig klassifizierte Lieferantenliste – jede Zeile mit Begründungszeile und Datum der Klassifizierungssitzung.

Schritt 3 – Tier-1-Risikoprofile: wo die Informationen herkommen

Das Risikoprofil ist kein vollständiges Assessment – das folgt in Schritt 6-2 (→ B-14). Es ist die strukturierte Bestandsaufnahme: Was ist über diesen Lieferanten bereits bekannt, bevor der Fragebogenprozess beginnt? Die drei Felder, an denen Inventare in der Praxis scheitern, sind Zertifizierungen, Vorfallshistorie und Sub-Prozessoren.

Sicherheitszertifizierungen: die Scope-Statement-Falle

"Hat ISO 27001" ist kein auditfähiger Eintrag. Die Prüfreihenfolge:

1. Zertifikatsdatenbank der Zertifizierungsstelle aufrufen – nicht das PDF des Lieferanten. DAkkS (dakks.de) führt alle akkreditierten deutschen Stellen, internationale Stellen über die IAF-Datenbank (iaf.nu). Aus der offiziellen Datenbank sehen Sie auch, ob ein Zertifikat zurückgezogen wurde.
2. Scope Statement lesen: Schließt der Geltungsbereich die Leistungen ein, die der Lieferant für Sie erbringt? Ein Zertifikat mit Scope "IT-Betrieb Rechenzentrum Standort A" deckt eine SaaS-Plattform aus Standort B nicht ab.
3. Ablaufdatum und letzten Surveillance-Audit-Nachweis notieren. ISO-27001-Zertifikate laufen drei Jahre, Surveillance-Audits finden jährlich statt. Ein Zertifikat ohne aktuellen Surveillance-Nachweis ist eine Momentaufnahme von vor bis zu zwei Jahren.

BSI C5 Typ II gilt gleichwertig zu ISO 27001 für IaaS/PaaS-Anbieter. SOC 2 Typ II – nicht Typ I, der ist eine Momentaufnahme – gilt gleichwertig für internationale SaaS-Anbieter, wenn nicht älter als 12 Monate.

Kein valides Zertifikat oder Scope-Mismatch: Eintrag "Kein valides Zertifikat für erbrachte Leistungen – offener Punkt für Schritt 6-2". Nicht leerlassen.

Bekannte Vorfälle: was "keine bekannten Vorfälle" bedeuten muss

Ein leeres Feld ist keine auditierbare Aussage – es ist unklar, ob die Frage überhaupt gestellt wurde. Drei Quellen systematisch durchsuchen:

• BSI-CERT-Warnungsarchiv: bsi.bund.de/cert – Suche nach Lieferantenname und Produktnamen.
• ENISA Threat Landscape Reports: für Vorfälle bei großen Anbietern mit EU-Relevanz.
• Status-Page des Lieferanten (Jahresarchiv): Für SaaS- und IaaS-Anbieter die direkteste Quelle. Die meisten Anbieter führen ein öffentliches Incident-Log mit Jahresarchiv.

Was im Inventar stehen muss: "Keine bekannten Vorfälle; geprüft: BSI-CERT-Warnungsarchiv, ENISA Threat Landscape 2022–2024, Status-Page [Lieferant] Jahresarchiv; Suche am [TT.MM.JJJJ]." Das ist ein auditfähiges Ergebnis. "Keine Vorfälle bekannt" ohne Quellenangabe ist es nicht.

Sub-Prozessoren: wenn man sie nicht kennt

Für Auftragsverarbeiter (VVT-Einträge): Art. 28 DSGVO verpflichtet den Auftragsverarbeiter zur Offenlegung seiner Unterauftragnehmer. Diese Pflicht nutzen – Anfrage stellen und die erhaltene Liste als Inventar-Anlage ablegen.

Für Nicht-Auftragsverarbeiter: "Sub-Prozessoren nicht bekannt; Offenlegungsanfrage für Schritt 6-2 geplant." Kein leeres Feld. Ein leeres Feld bedeutet, dass die Frage nicht gestellt wurde – das ist ein anderer Befund als "unbekannt, wird nachverfolgt".

SPOF-Einschätzung: eine Frage, binäre Antwort

Gibt es innerhalb von 72 Stunden einen funktionsfähigen Ersatz, wenn dieser Lieferant vollständig ausfällt? Ja / Nein / Unklar. Bei "Nein" oder "Unklar": SPOF-Markierung im Inventar setzen. Die Detailanalyse folgt in Schritt 6-2 und in A-33 – hier ist nur die Markierung relevant, nicht die vollständige Konzentrationsrisikobewertung.

Output Schritt 3: alle Tier-1-Risikoprofile ausgefüllt oder mit dokumentierten offenen Punkten für Schritt 6-2.

Schritt 4 – Freigabe und Governance: was konkret zählt

Der Leitfaden verlangt formale Freigabe durch Geschäftsleitung oder CISO, Versionierung, Inventar-Owner und Aktualisierungsprozess. Was er nicht beschreibt: was "formale Freigabe" konkret bedeutet – und was nicht ausreicht.

Die zwei Freigabemodi

• Option A – Unterschrift auf dem Deckblatt: Geschäftsführung oder CISO unterschreibt das Deckblatt des Inventars. Das Dokument trägt die Freigabe direkt – kein Suchen in E-Mail-Postfächern nötig.
• Option B – Protokollverweis: Das Deckblatt enthält Datum, Sitzungsbezeichnung, Tagesordnungspunkt und Beschlussergebnis der Sitzung, in der das Inventar freigegeben wurde. Das Sitzungsprotokoll liegt als Anlage vor. Beide Elemente müssen vorhanden sein.

Nicht ausreichend: E-Mail mit "sieht gut aus"; mündliche Genehmigung; Freigabe nur als Teil des Dateinamens. Das Deckblatt muss mindestens enthalten: Dokumententitel, Versionsnummer (v1.0), Erstellungsdatum, Inventar-Owner (Name + Funktion) und die Freigabe.

Inventar-Owner: was die Benennung bedeutet

Name und Funktion im Deckblatt – nicht "IT-Abteilung", nicht "ISB-Rolle". Der Owner stößt anlassbezogene Aktualisierungen an, verantwortet die jährliche Vollüberprüfung und rapportiert den Aktualisierungsstand. Wenn die Person nicht namentlich bekannt ist, ist der Prozess beim nächsten Auslöser nicht steuerbar.

Update-Auslöser operationalisieren

Die fünf anlassbezogenen Auslöser (→ A-31) bleiben toter Text, wenn sie nicht in ein laufendes System eingebunden sind. Drei Optionen:

• ITSM-Integration: Jeder neue Lieferantenvertrag als Change-Request; das Change-Formular enthält ein Pflichtfeld "Inventar-Update erforderlich". Bei Ja: automatischer Task an den Inventar-Owner. Robusteste Lösung, weil der Auslöser dort entsteht, wo die Arbeit anfällt.
• Kalender-Recurring: Jährliche Vollüberprüfung als Recurring-Appointment des Inventar-Owners – mit direktem Dokumentenlink. Ohne Link führt kein Kalendertermin zuverlässig zur richtigen Datei.
• Procurement-Gate: Einkauf informiert den Inventar-Owner per E-Mail-Vorlage bei jedem neuen Lieferantenvertrag. Fünf Pflichtfelder: Lieferantenname, Leistungsbeschreibung, Systemzugang (Ja/Nein), Laufzeit, Vertragsreferenz. Einfachste Lösung ohne ITSM.

Output Schritt 4: Inventar v1.0 mit Deckblatt, Freigabe dokumentiert, Inventar-Owner namentlich benannt, Update-System aktiv.

Was Sie jetzt haben

Nach diesen vier Schritten haben Sie:

1. Vollständige, klassifizierte Lieferantenliste (Tier 1/2/3) mit Begründungszeile und Quellenangabe je Eintrag
2. Tier-1-Risikoprofile mit dokumentiertem Zertifizierungsstatus (Scope geprüft), Vorfallshistorie (Quellen dokumentiert) und SPOF-Einschätzung
3. Management-freigegebenes Lieferanteninventar v1.0 mit Deckblatt, namentlich benanntem Inventar-Owner und aktivem Update-System
4. BSI-revisionssicheres Compliance-Artefakt für § 30 Abs. 2 Nr. 4 BSIG – vollständige Grundlage für Schritt 6-2 und 6-3

Weiter: B-14 (Lieferantenbewertung einrichten – Fragebogen und Risikoeinstufung für Ihre Tier-1-Lieferanten) · A-33 (Konzentrationsrisiko in der Lieferkette – SPOF-Markierungen aus diesem Inventar vertiefen)