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
- 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: