Lieferantenaudit Checkliste: Leitfaden für DORA, NIS2 und ISO 27001
Warum Lieferantenaudits jetzt kritisch sind
Schritt 1: Öffnen Sie Ihr Register der kritischen IKT-Drittanbieter. Wenn Sie keines haben, ist das Ihr dringendstes Compliance-Problem.
DORA und NIS2 haben das Thema Drittanbieter-Risikomanagement aus dem Hintergrund auf die Agenda der Geschäftsführung katapultiert. Die Realität ist ernüchternd: Die meisten Cyberangriffe und Betriebsunterbrechungen kommen nicht von innen – sie kommen über die Lieferkette. SolarWinds, Kaseya, MOVEit: Die Liste der Lieferketten-Angriffe mit Milliardenschäden wächst jährlich.
Für Finanzunternehmen unter DORA ist das Lieferantenaudit keine Kann-Anforderung. Artikel 28–30 DORA schreiben vor, dass kritische IKT-Drittanbieter vertraglich zur Auditduldung verpflichtet und regelmäßig geprüft werden müssen.
Dieser Leitfaden gibt Ihnen die komplette Checkliste plus Durchführungsanleitung.
Was ist ein Lieferantenaudit?
Ein Lieferantenaudit (Second-Party-Audit) ist eine strukturierte Prüfung, bei der ein Unternehmen die Sicherheitspraktiken, Prozesse und Konformität eines Lieferanten oder Dienstleisters bewertet.
Unterschied zum internen Audit: Beim Lieferantenaudit prüft der Kunde seinen Anbieter – nicht die eigene Organisation.
Abgrenzung zur Lieferantenzertifizierung: Ein Zertifikat (z.B. ISO 27001) ist ein Signal – kein Ersatz für ein eigenes Audit. Zertifikate bestätigen Konformität zum Zertifizierungszeitpunkt; ein eigenes Audit bewertet die aktuelle Situation.
Rechtliche Grundlagen
DORA (Art. 28–30)
DORA ist das spezifischste Regelwerk für IKT-Drittanbieter im Finanzsektor:
- Art. 28(2): Finanzunternehmen müssen IKT-Risiken durch Dritte systematisch identifizieren und bewerten
- Art. 28(4): Für kritische IKT-Dienstleister sind vertragliche Vereinbarungen mit spezifischen Klauseln erforderlich
- Art. 30(2)(f): Verträge müssen Audit-Rechte des Finanzunternehmens einschließen
- Art. 28(5): Jährliche Überprüfung aller IKT-Drittanbieter im Register
Definition „kritischer IKT-Drittanbieter": Entschieden durch die Aufsichtsbehörde (EBA, ESMA, EIOPA, BaFin) – betrifft Cloud-Anbieter, Rechenzentrumsbetreiber, Datenverwaltungsdienste, die eine systemische Rolle spielen.
NIS2 (Art. 21)
NIS2 verlangt die Implementierung von Sicherheitsmaßnahmen, die explizit Sicherheit in der Lieferkette einschließen. Für wesentliche und wichtige Einrichtungen bedeutet das:
- Risikobasierte Bewertung aller relevanten Lieferanten
- Sicherheitsanforderungen in Verträgen
- Regelmäßige Überprüfung
ISO 27001:2022 (Anhang A.5.19–A.5.22)
- A.5.19: Informationssicherheit in Lieferantenbeziehungen – Policy und Anforderungskatalog
- A.5.20: Sicherheitsanforderungen in Lieferantenvereinbarungen
- A.5.21: IKT-Lieferkettensicherheit
- A.5.22: Überwachung, Überprüfung und Änderungsmanagement von Lieferantendienstleistungen
Schritt 1: Lieferanten klassifizieren
Nicht alle Lieferanten erfordern gleich intensive Audits. Klassifizieren Sie zuerst:
Klassifizierungsmatrix
| Kategorie | Beschreibung | Audit-Intensität |
|---|---|---|
| Kritisch | Direkter Zugang zu sensiblen Daten oder kritischen Systemen; Ausfall würde Betrieb gefährden | Jährliches Vollaudit (Vor-Ort oder remote) |
| Wesentlich | Verarbeitet unternehmensrelevante Daten; Ausfall würde Betrieb beeinträchtigen | Jährlicher Fragebogen + 2-jährliches Vollaudi |
| Standard | Standardlieferant ohne privilegierten Datenzugang | Fragebogen bei Qualifizierung, Überprüfung alle 3 Jahre |
| Nicht kritisch | Keine Datenverarbeitung, kein Systemzugang | Nur vertragliche Grundanforderungen |
DORA-spezifisch: Für DORA-regulierte Unternehmen müssen Sie alle IKT-Drittanbieter in einem Register führen, das mindestens Kategorisierung, Vertragsvolumen und Kritikalität enthält.
Schritt 2: Vorbereitende Unterlagen anfordern
Mindestens 4 Wochen vor dem Audit folgende Dokumente anfordern:
Zertifikate und Testate
- ISO 27001-Zertifikat (aktuell, mit Zertifizierungsbereich)
- SOC 2 Type II-Bericht (maximal 12 Monate alt)
- TISAX-Assessment (sofern Automotive-relevant)
- Sonstige relevante Zertifizierungen (ISO 9001, ISO 22301)
Sicherheitsdokumentation
- Informationssicherheitspolitik
- Datenschutzerklärung und Verarbeitungsverzeichnis
- Dokumentation der Verschlüsselungsstandards
- Patch-Management-Richtlinie
- Business-Continuity-Plan (BCP)
- Ergebnisse des letzten BCP-Tests
- Recovery-Time-Objective (RTO) und Recovery-Point-Objective (RPO) für kritische Services
Vorfallsmanagement
- Incident-Response-Plan
- Nachweis: Keine ungeklärten Major-Incidents in den letzten 12 Monaten
Schritt 3: Lieferantenaudit-Checkliste
Block A: Governance und Sicherheitsorganisation
| Nr. | Prüffrage | Nachweis erforderlich | Bewertung |
|---|---|---|---|
| A.1 | Ist ein CISO oder verantwortliche Person für Informationssicherheit benannt? | Organigramm / Jobbeschreibung | □ Ja □ Nein |
| A.2 | Gibt es eine dokumentierte und freigegebene Informationssicherheitspolitik? | Policy-Dokument mit Datum | □ Ja □ Nein |
| A.3 | Wann wurde die IS-Politik zuletzt durch das Management überprüft? | Überprüfungsnachweis | □ < 12 Mo. □ > 12 Mo. |
| A.4 | Existiert ein Sicherheitsgremium oder -ausschuss? Wie oft trifft es sich? | Protokolle | □ Ja □ Nein |
| A.5 | Werden Mitarbeitende regelmäßig in Informationssicherheit geschult? | Schulungsplan, Teilnahmeliste | □ Ja □ Nein |
Block B: Zugangssteuerung
| Nr. | Prüffrage | Nachweis erforderlich | Bewertung |
|---|---|---|---|
| B.1 | Gilt das Least-Privilege-Prinzip für alle Systeme? | IAM-Konzept, Rollenmatrix | □ Ja □ Teilweise □ Nein |
| B.2 | Ist MFA für alle privilegierten Zugriffe und Remote-Zugänge aktiviert? | Screenshot IAM-Konfiguration | □ Ja □ Teilweise □ Nein |
| B.3 | Findet ein regelmäßiges User-Access-Review statt? | Access-Review-Protokoll (< 12 Mo.) | □ Ja □ Nein |
| B.4 | Werden Zugriffsrechte bei Ausscheiden sofort entzogen? | Offboarding-Prozess | □ Ja □ Nein |
| B.5 | Gibt es klare Regeln für den Umgang mit Drittanbieter-Zugriffen auf eigene Systeme? | Vendor-Access-Policy | □ Ja □ Nein |
Block C: Datenschutz und Datensicherheit
| Nr. | Prüffrage | Nachweis erforderlich | Bewertung |
|---|---|---|---|
| C.1 | Werden Daten in Ruhe verschlüsselt (AES-256 oder gleichwertig)? | Technische Dokumentation | □ Ja □ Nein |
| C.2 | Werden Daten in der Übertragung verschlüsselt (TLS 1.2+)? | Protokoll-Konfiguration | □ Ja □ Nein |
| C.3 | Ist ein Datenschutzbeauftragter (DSB) benannt? | DSB-Kontaktinformationen | □ Ja □ Nein |
| C.4 | Gibt es ein Verzeichnis der Verarbeitungstätigkeiten? | VVT-Auszug für relevante Services | □ Ja □ Nein |
| C.5 | Wo werden die Daten gespeichert? (Rechenzentrumsstandort) | Hosting-Dokumentation | □ EU □ USA □ Sonstiges |
| C.6 | Bei Drittland-Transfer: Welcher SCCs/Transfermechanismus? | SCC-Vereinbarung | □ SCC □ Adequacy □ Sonstiges |
Block D: Vorfallsmanagement und Meldepflichten
| Nr. | Prüffrage | Nachweis erforderlich | Bewertung |
|---|---|---|---|
| D.1 | Gibt es einen dokumentierten Incident-Response-Plan? | IR-Plan-Dokument | □ Ja □ Nein |
| D.2 | Wie werden Kunden über Sicherheitsvorfälle informiert? Innerhalb welcher Frist? | SLA / Vertragsklausel | □ < 24h □ < 72h □ Unbekannt |
| D.3 | Wie lautet die Kontaktadresse für Sicherheitsvorfälle? | Notfallkontakt | □ Vorhanden □ Fehlt |
| D.4 | Gab es in den letzten 12 Monaten wesentliche Sicherheitsvorfälle? Wie wurden diese behandelt? | Incident-Protokoll oder Erklärung | □ Keine □ Protokoll vorhanden |
| D.5 | Ist der Lieferant bereit, DORA-konforme Incident-Meldungen bereitzustellen? | Vertragsklausel / schriftliche Bestätigung | □ Ja □ Nein |
Block E: Business Continuity und Resilience
| Nr. | Prüffrage | Nachweis erforderlich | Bewertung |
|---|---|---|---|
| E.1 | Gibt es einen Business-Continuity-Plan für kritische Services? | BCP-Dokument | □ Ja □ Nein |
| E.2 | Wurden BCP/Disaster-Recovery-Tests durchgeführt? Wann war der letzte? | Testprotokoll (< 12 Mo.) | □ Ja □ Nein |
| E.3 | Welche RTO/RPO-Garantien gelten für die genutzten Services? | SLA-Dokument | □ Definiert □ Undefiniert |
| E.4 | Gibt es redundante Infrastruktur (mehrere Rechenzentren, Geo-Redundanz)? | Infrastruktur-Dokumentation | □ Ja □ Nein |
| E.5 | Werden Sub-Lieferanten auf gleiche Sicherheitsanforderungen verpflichtet? | Sub-Lieferantenrichtlinie | □ Ja □ Nein |
Block F: Vulnerability Management und Patches
| Nr. | Prüffrage | Nachweis erforderlich | Bewertung |
|---|---|---|---|
| F.1 | Gibt es einen dokumentierten Patch-Management-Prozess? | Patch-Policy | □ Ja □ Nein |
| F.2 | Innerhalb welcher Frist werden kritische Sicherheitslücken gepatcht? | SLA in der Patch-Policy | □ < 24h (krit.) □ > 24h □ Unbekannt |
| F.3 | Werden regelmäßige Vulnerability-Scans durchgeführt? | Scan-Berichte | □ Ja □ Nein |
| F.4 | Werden Penetrationstests extern durchgeführt? Wie häufig? | Pentest-Berichte (< 12 Mo.) | □ Jährlich □ Unregelmäßig □ Nein |
Schritt 4: Bewertung und Scoring
Scoring-Modell
Bewerten Sie jeden Block auf einer Skala von 0–10:
- 8–10: Konform, keine Maßnahmen erforderlich
- 5–7: Teilkonform, Verbesserungsmaßnahmen vereinbaren
- 0–4: Kritische Lücke, sofortige Maßnahmen oder Eskalation
Gesamtbewertung:
- Alle Blöcke ≥ 8: Lieferant qualifiziert
- Ein Block 5–7: Bedingte Qualifizierung mit Maßnahmenplan
- Ein Block < 5 oder D.4 = Sicherheitsvorfall ohne Protokoll: Nicht qualifiziert / Eskalation
Red Flags – sofortiger Eskalationsbedarf
- ISO 27001-Zertifikat abgelaufen oder nicht vorhanden (für kritische Lieferanten)
- Kein Incident-Response-Plan
- Datenhaltung in Drittländern ohne SCCs
- Sicherheitsvorfälle in den letzten 12 Monaten ohne dokumentierte Aufarbeitung
- Patch-Zeiten für kritische Vulnerabilities > 30 Tage
- Ablehnung von Audit-Zugang
Schritt 5: Auditbericht und Maßnahmen
Der Lieferantenaudit-Bericht dokumentiert:
- Auditdatum, Lieferant, Auditteam, Kontaktperson
- Geprüfter Service-Scope
- Ergebnisse je Block (Score + Kommentar)
- Identifizierte Lücken mit Klassifizierung
- Vereinbarte Maßnahmen mit Frist und Verantwortlichem
- Gesamtbewertung und Empfehlung (Qualifiziert / Bedingt / Abgelehnt)
- Nächster Review-Termin
Lieferantenaudit in der Praxis: Was Unternehmen falsch machen
Fehler 1: Zertifikat als Ersatz für Audit
Ein ISO-27001-Zertifikat ist ein Ausgangspunkt, kein Abschluss. Fragen Sie immer: „Können Sie mir das konkret zeigen?"
Fehler 2: Kein Audit-Recht im Vertrag
Ohne vertragliches Audit-Recht kann der Lieferant ablehnen. Unter DORA ist das für kritische IKT-Anbieter eine Pflichtklausel.
Fehler 3: Audit ohne Follow-up
Gefundene Lücken ohne Maßnahmenplan und Follow-up-Termin sind wertlos.
Fehler 4: Nur Dokumente prüfen
Dokumentation und Realität klaffen oft auseinander. Stellen Sie Fragen, die Praxis zeigen: „Wann war Ihr letzter Restore-Test? Können Sie das Protokoll zeigen?"
Lieferantenaudit-Software: Wann lohnt sich Automatisierung?
Ab 10–15 Lieferanten wird manuelle Verwaltung zum Engpass. Matproof bietet:
- Lieferantenregister mit Kritikalitätsklassifizierung
- Standardisierte Auditfragebögen (DORA, NIS2, ISO 27001)
- Automatische Erinnerungen für fällige Reviews
- Maßnahmenverfolgung mit Lieferanten-Benachrichtigung
- Konsolidiertes Lieferantenrisiko-Dashboard
Mehr über Matproof Lieferantenmanagement →
Weiterführende Artikel: