Lieferketten-Resilienz: Prüfkriterien für Drittanbieter-Verträge vor Vertragsverlängerung

Eine Vertragsverlängerung mit einem IT-Dienstleister, SaaS-Anbieter oder Cloud-Provider wirkt oft wie Routine. Operativ ist sie das Gegenteil: Sie ist einer der wenigen Zeitpunkte, an denen Sie Konditionen, Nachweise und Kontrollrechte ohne eskalierenden Streit nachschärfen können. Genau hier entscheidet sich, ob Lieferketten-Resilienz im Alltag trägt oder nur auf dem Papier existiert. Denn im Incident, bei einem Zulieferer-Ausfall oder bei regulatorischer Prüfung zählt nicht, was „üblich“ ist, sondern was vertraglich vereinbart, technisch umsetzbar und als Nachweis verfügbar ist.

Dieser Beitrag bündelt Prüfkriterien, die sich in Audits und in der Betriebspraxis bewähren: von Abhängigkeiten und Subunternehmern über SLAs/SLOs (Service Level Agreement/Objective: zugesicherte bzw. angestrebte Servicewerte) bis zu Exit-Strategie, Business Continuity (BCP: Notfallplanung) und Disaster Recovery (DR: Wiederanlauf nach Totalausfall). Schwerpunkt ist Umsetzbarkeit: Welche Fragen Sie stellen, welche Artefakte Sie anfordern und wie Sie Ergebnisse priorisieren, damit eine Verlängerung nicht zum Risiko-Update wird.

Warum Vertragsverlängerungen der beste Hebel für Lieferketten-Resilienz sind

Im laufenden Vertrag ist das Machtgleichgewicht oft ungünstig: Änderungen kosten Zeit, der Anbieter argumentiert mit Standardisierung, und interne Teams scheuen Reibung. Bei der Verlängerung sind hingegen drei Dinge anders:

• Neu-Verhandlung ist erwartbar: Preisanpassungen, Laufzeiten, Leistungsumfang – damit ist ein „Change Window“ legitim.
• Risikolage hat sich verändert: Neue Bedrohungen (z. B. Ransomware), neue Abhängigkeiten (Subprozessoren), neue Regulatorik (z. B. DORA/NIS2) sind ein sachlicher Anlass.
• Auditfähigkeit wird entscheidbar: Sie können Nachweisformate, Reporting, Eskalationsrechte und Prüfzugänge fixieren.

Praktisch bedeutet das: Verlängerungen sollten nicht nur von Einkauf und Fachbereich getrieben sein. Sie sind ein Governance-Ereignis mit klaren Rollen: IT-Betrieb (für technische SLOs, Schnittstellen, Wiederanlauf), Informationssicherheit (Kontrollen, Nachweise), Datenschutz (AVV/Subprozessoren), Compliance/Risikomanagement (Wesentlichkeit, Dokumentation) und Legal (Haftung, Rechte, Beweislast).

Vorarbeit: Kritikalität, Abhängigkeiten und „Wesentlichkeit“ sauber bestimmen

Bevor Sie Kriterien abarbeiten, brauchen Sie eine belastbare Einordnung. Sonst diskutieren Sie Details (z. B. Penetrationstest-Frequenz), obwohl der Dienst im Ernstfall nicht einmal ersetzt werden kann.

1) Kritikalitätsklassifizierung: Was fällt wirklich aus?

Bewerten Sie, welche Geschäftsprozesse an dem Drittanbieter hängen und was die maximale tolerierbare Unterbrechung ist. In der Sprache der Notfallplanung sind das RTO (Recovery Time Objective: maximal tolerierte Wiederherstellungszeit) und RPO (Recovery Point Objective: maximal tolerierter Datenverlust in Zeit). Wenn der Dienst zwar „wichtig“ ist, aber manuell überbrückbar, sind andere Vertragsklauseln relevant als bei einem Dienst, der Zahlungsverkehr, Produktion oder Logistik direkt stoppt.

2) Abhängigkeitslandkarte: Wer hängt an wem?

Lieferketten-Resilienz scheitert selten am Hauptanbieter, sondern an der Kette dahinter: Identity Provider, Payment-Gateway, SMS/Email-Versand, CDN, Managed DNS, Ticketing, Monitoring. Fordern Sie eine Service-Abhängigkeitsübersicht an und spiegeln Sie sie mit Ihrer Architektur- und CMDB-Sicht (Configuration Management Database: Inventar von Systemen/Beziehungen). Ziel ist eine Liste „Single Points of Failure“ inklusive Subunternehmern (Subprozessoren), Regionen, und organisatorischer Zuständigkeiten.

3) Regulatorische Einordnung: DORA/NIS2/branchenspezifische Vorgaben

Auch ohne die juristischen Details auszubreiten: Für viele Unternehmen wird die Lieferkette zum Prüfgegenstand. DORA (für den Finanzsektor und indirekt für viele Zulieferer) verlangt u. a. robuste Drittparteiensteuerung und Nachweise. NIS2 zielt auf Sicherheitsmaßnahmen und Lieferkettensicherheit in vielen Sektoren. Ergebnis: Sie brauchen dokumentierte, wiederholbare Prüfungen – und Sie müssen zeigen können, wie Sie Findings behandeln.

Prüfkriterien für Drittanbieter-Verträge vor Vertragsverlängerung (Kerncheckliste)

Die folgenden Prüffelder sind so aufgebaut, dass Sie sie in Vertragsanhänge, Risiko-Reviews und Audit-Ordner übersetzen können. Nicht jedes Feld ist für jeden Anbieter gleich tief zu prüfen. Die Tiefe leitet sich aus Kritikalität und Datenrisiko ab.

A) Leistungsbeschreibung: Was genau wird geliefert – und was nicht?

Viele Resilienz-Probleme sind Auslegungsfragen. Klären Sie, ob die Leistungsbeschreibung technische Details enthält, die später beweisbar sind.

• Scope und Grenzen: Welche Umgebungen (Prod/Stage), welche Mandanten, welche Regionen?
• Änderungsfenster: Wartungsfenster, Vorlaufzeiten, Kommunikationskanäle, „Emergency Changes“.
• Shared Responsibility: Wer ist wofür zuständig (z. B. Patching, IAM, Backup, Logging)? Dieses Modell muss zu Ihrer Betriebsrealität passen.
• Abkündigungen: Mindest-Fristen für API- oder Feature-Deprecation und Migrationsunterstützung.

Konsequenz für Entscheider: Wenn das „Was“ unscharf ist, ist jedes SLA nur begrenzt wertvoll. Unschärfe erzeugt Streit im Incident und erhöht interne Betriebskosten (mehr Abstimmungen, mehr Workarounds).

B) SLA/SLO und Support: Messen, Durchsetzen, Eskalieren

Ein SLA, das nicht gemessen werden kann, ist ein Beruhigungsdokument. Prüfen Sie:

• Definitionen: Was zählt als „Verfügbarkeit“? Welche Messpunkte (Client, Provider, synthetisches Monitoring)?
• SLOs pro Kernfunktion: Nicht nur „Service up“, sondern z. B. API-Latenz, Batch-Laufzeiten, Queue-Backlog (Warteschlangenrückstand).
• Supportmodell: 24/7 ja/nein, Reaktionszeiten, Entstörung vs. „Best Effort“, dedizierte Ansprechpartner.
• Eskalationspfad: Technische Eskalation (on-call), Management-Eskalation, definierte Kommunikationskanäle im Major Incident.
• Service Credits und Sonderkündigungsrecht: Credits allein kompensieren selten Betriebsschäden; wichtiger ist ein verankertes Recht, bei wiederholter Nichterfüllung zu kündigen oder umzusteuern.

Audit-Perspektive: Legen Sie fest, welche Reports regelmäßig geliefert werden (Monatsreport, Major-Incident-Review, RCA). RCA (Root Cause Analysis: Ursachenanalyse) sollte konkrete Korrekturmaßnahmen und Termine enthalten, nicht nur Erklärungen.

C) Business Continuity und Disaster Recovery: Nachweise statt Versprechen

Für Lieferketten-Resilienz ist entscheidend, ob der Anbieter seine eigene Betriebsfortführung beherrscht und wie Ihre Abhängigkeit davon gestaltet ist.

• BCP/DR-Ansatz: Gibt es dokumentierte Pläne? Welche Szenarien sind abgedeckt (Region-Ausfall, Ransomware, Insider, Lieferantenausfall)?
• RTO/RPO-Fähigkeit: Welche Zielwerte gelten für den Dienst? Passen sie zu Ihren Anforderungen?
• Übungen und Tests: Werden Wiederanlauf-Tests durchgeführt? Wie oft? Können Sie Summary-Ergebnisse erhalten?
• Backup- und Restore-Logik: Welche Daten werden gesichert, wie lange, wo liegen Backups (Region/Provider)? Gibt es Immutable- oder WORM-Mechanismen (Write Once Read Many: gegen nachträgliche Veränderung)?
• Notbetriebsmodus: Gibt es degradierte Betriebsarten (Read-only, eingeschränkte Funktion), die Sie einplanen können?

Entscheidungsrelevant: Ein Anbieter kann formal ein DR-Konzept haben, aber die Abhängigkeiten (z. B. Identity, Schlüsselmanagement, DNS) verhindern den Wiederanlauf. Deshalb gehört zur Prüfung mindestens eine Architektur-Sicht „Was muss funktionieren, damit der Dienst wiederkommt?“

D) Sicherheitskontrollen und Nachweise: Was wird belegt, wie aktuell, wie verwertbar?

Viele Unternehmen verlangen ISO 27001 (ISMS-Zertifizierung) oder SOC 2 (Kontrollbericht) – beides kann sinnvoll sein, ersetzt aber keine Kontextprüfung. Prüfen Sie daher neben dem „Badge“ die Details:

• Geltungsbereich (Scope): Deckt der Nachweis genau den Service ab, den Sie nutzen, inklusive Betriebsstandorte und Subunternehmer?
• Aktualität: Berichtszeitraum, Zeitpunkt der Prüfung, bekannte Ausnahmen/„Management Responses“.
• Vulnerability- und Patch-Management: Prozess, SLAs für kritische Patches, Umgang mit Zero-Days.
• Penetrationstests und Schwachstellen-Scans: Frequenz, unabhängige Durchführung, Nachweis von Remediation (Abstellung).
• Security Logging: Welche Logs existieren, wie lange, Zugriff für Sie (z. B. Export in Ihr SIEM: Security Information and Event Management)?
• Identity & Access Management: MFA (Multi-Faktor-Authentifizierung), Rollenmodell, JML-Prozess (Joiner/Mover/Leaver), Break-Glass-Accounts (Notfallzugang).
• Verschlüsselung und Key Management: Verschlüsselung in Transit/at Rest, Schlüsselverwaltung (KMS/HSM), Schlüsselrotation.

Wichtig: Definieren Sie „Minimum Evidence“ für Verlängerung. Beispiel: Ohne Scope-klaren SOC2/ISO-Nachweis plus Subunternehmerliste plus Incident-Prozess gibt es nur eine Kurzverlängerung oder eine Verlängerung mit Auflagen.

E) Subunternehmer/Subprozessoren: Transparenz, Wechselrechte, Kettenpflichten

Lieferketten-Resilienz heißt: Die Kontrolle endet nicht beim Vertragspartner. Subprozessoren (Datenschutz) und Unterauftragnehmer (Betrieb) müssen sichtbar und steuerbar sein.

• Aktuelle Liste: Namen, Rolle, Standort/Region, Zweck, Datenarten.
• Change Notification: Vorlauf bei Änderungen, Widerspruchs- oder Sonderkündigungsrechte, insbesondere bei kritischen Subprozessoren.
• Flow-down-Klauseln: Verpflichtung, dass Sicherheits- und BCP-Anforderungen an Subunternehmer weitergereicht werden (vertragliche Kette).
• Concentration Risk: Häufen sich Subunternehmer bei einem Hyperscaler, einer Region oder einem Identitätsdienst? Dann ist Diversifizierung oder Exit-Plan wichtiger.

Audit-Perspektive: Subunternehmerwechsel ohne geregelte Vorlaufzeit ist ein typischer Finding-Treiber, weil sich Risiko und Datenflüsse ändern, ohne dass Ihr Unternehmen angemessen reagieren kann.

F) Daten, Datenschutz und Datenzugriff: Minimierung, Portabilität, Souveränität

Bei Vertragsverlängerung sollten Sie Datenflüsse nüchtern prüfen: Welche Daten liegen wo, wer kann sie sehen, wie kommen Sie im Notfall daran?

• Datenklassifizierung: Personenbezogene Daten, Geschäftsgeheimnisse, Betriebsdaten, Protokolle. Passen Schutzmaßnahmen und Aufbewahrung?
• AVV/DPA: Auftragsverarbeitung (DSGVO) inklusive TOMs (Technische und organisatorische Maßnahmen), Meldefristen, Subprozessoren.
• Datenresidenz: Region/Standortbindung und Konsequenzen bei Failover.
• Zugriffsrechte: Provider-Admin-Zugriffe, Support-Zugriff, Protokollierung und Genehmigungen (z. B. „Support nur nach Ticketfreigabe“).
• Portabilität: Exportformate, Frequenz, Vollständigkeit (inkl. Metadaten), Test eines Exports.
• Datenlöschung: Löschfristen nach Vertragsende, Nachweis der Löschung, Backups (wann sind auch Backup-Kopien gelöscht?).

Konsequenz für Betrieb: Wenn Exporte nur manuell oder in proprietären Formaten möglich sind, wird Ihr Exit teuer und langsam. Das ist ein Resilienzproblem, nicht nur ein Komfortthema.

G) Incident Response & Kommunikation: Zeit, Inhalt, Schnittstellen

Im Ernstfall zählt die Geschwindigkeit der Information und die Qualität der Inhalte. Prüfen Sie:

• Definition „Security Incident“: Was muss gemeldet werden (auch Verdacht/Beinahe-Vorfälle)?
• Meldewege: 24/7-Kontakt, dedizierte Channels, PGP/verschlüsselte Kommunikation wenn nötig.
• Fristen: Erstmeldung, Updates, Abschlussbericht. Für manche Kontexte sind sehr kurze Fristen sinnvoll, aber nur, wenn der Anbieter sie leisten kann.
• Forensik und Beweissicherung: Welche Logs/Daten werden gesichert, wie lange, wie wird Integrität garantiert?
• Koordination: Teilnahme an War Rooms, Bereitstellung technischer Ansprechpartner, gemeinsame Postmortems.

Besonders wichtig ist eine Regelung, wie Sie eigene Nachweispflichten erfüllen (z. B. interne Meldungen, Behördenmeldungen) und welche Informationen Sie vom Anbieter rechtzeitig bekommen.

H) Exit-Strategie und „Operational Switch“: Wegkommen können, ohne Betrieb zu verlieren

Exit ist der Test, ob Sie wirklich Steuerung haben. Eine Exit-Strategie ist mehr als „Wir können kündigen“. Sie muss technisch und organisatorisch funktionieren.

• Exit-Klauseln: Kündigungsrechte bei Sicherheits- oder Resilienz-Verstößen, „Exit Assistance“ (Unterstützung beim Wechsel), Preisdeckel für Unterstützungsleistungen.
• Datenexport + Dokumentation: Zeitplan, Formate, Vollständigkeit, Übergabe von Konfigurationen, Abhängigkeiten.
• Übergangsphase: Parallelbetrieb, Read-only-Phase, definierte Ansprechpartner, Zugriff auf historische Daten.
• Technischer Switch: Wie werden DNS, Zertifikate, Identitäten, Webhooks/APIs umgestellt? Welche Vorlaufzeiten gibt es?

Praxisempfehlung: Verlangen Sie mindestens einmal pro Jahr einen „Exit-Dry-Run light“: einen realen Export-Test und einen dokumentierten Ablaufplan. Das ist günstiger als ein Exit im Krisenmodus.

I) Audit- und Kontrollrechte: Prüfen können, ohne den Betrieb zu gefährden

Viele Anbieter begrenzen Auditrechte aus Sicherheits- und Standardisierungsgründen. Sie brauchen einen praxistauglichen Kompromiss, der Ihre Nachweispflichten erfüllt.

• Welche Nachweise akzeptiert werden: SOC2/ISO-Berichte, Prüfberichte unabhängiger Dritter, Security Whitepapers, regelmäßige Kontroll-Reports.
• Right to Audit vs. Right to Evidence: Häufig ist ein „Evidence“-Anspruch realistischer als Vor-Ort-Audits. Wichtig ist, dass Evidence ausreichend ist und termingebunden geliefert wird.
• Auditfenster und Prozess: Vorlauf, Umfang, Geheimhaltung, Schutz von Mandantendaten.
• Abweichungsmanagement: Umgang mit Findings, Remediation-Pläne, Nachprüfung.

Auditfest wird es, wenn Sie definieren, welche Artefakte Sie jährlich bekommen und wie Sie sie intern ablegen (inkl. Verantwortlicher, Gültigkeit, Review-Datum).

J) Finanzen, Haftung und Versicherbarkeit: Risiko nicht „wegverhandeln“, aber begrenzen

Resilienz ist auch eine Kostenfrage: Wer trägt Schäden, wer trägt Mehrarbeit, und wie kalkulierbar ist das?

• Haftungsobergrenzen: Passen Caps zur Kritikalität? Bei kritischen Services sind zu niedrige Caps ein Signal, dass Sie Exit/Redundanz stärker priorisieren müssen.
• Indirekte Schäden: Anbieter schließen Folgeschäden oft aus; dann ist Ihr technisches Risikodesign (Redundanz, Notbetrieb) umso wichtiger.
• Preislogik bei Skalierung/Krisen: Kosten bei Notfallkapazitäten, Datenexport, Zusatzsupport im Incident.
• Cyber-/Betriebsunterbrechungsbezug: Prüfen Sie, ob Vertragsbedingungen Ihre eigene Versicherbarkeit beeinflussen (z. B. Nachweis von Backups/BCP).

Priorisierung: Welche Kriterien sind „Dealbreaker“, welche sind Auflagen?

Ohne Priorisierung enden Reviews in endlosen Listen. Bewährt hat sich eine Einteilung in drei Klassen, die Sie vor dem Review festlegen:

• Dealbreaker (keine Verlängerung ohne Lösung): fehlende Subunternehmertransparenz, keine belastbaren Incident-Meldewege, keine Möglichkeit zum Datenexport, fehlende grundlegende Sicherheitsnachweise für kritische Dienste.
• Auflagen (verlängern, aber mit Frist und Nachweis): unklare SLA-Messung, unzureichende DR-Testnachweise, fehlende SIEM-Integration, unklare Löschprozesse.
• Verbesserungen (Backlog): Optimierungen an Reportformaten, zusätzliche Metriken, Prozessfeinschliff.

Diese Einteilung muss an Kritikalität gekoppelt sein. Ein HR-SaaS hat andere Dealbreaker als ein IAM-System (Identity and Access Management), das Ihre gesamte Zugriffssteuerung trägt.

Governance-Setup: Rollen, RACI und Entscheidungsvorlage für die Verlängerung

Damit Lieferketten-Resilienz nicht am Koordinationsaufwand scheitert, brauchen Sie ein klares Setup. RACI (Responsible/Accountable/Consulted/Informed) ist dafür ein pragmatisches Raster.

Minimal-RACI für kritische Drittanbieter

• Accountable (A): Service Owner im Unternehmen (oft IT-Leitung oder Prozessverantwortliche), der die Risikoentscheidung trägt.
• Responsible (R): Vendor Manager/Einkauf für Verhandlungsführung; IT-Betrieb für technische Anforderungen; Security/Compliance für Kontrollen.
• Consulted (C): Datenschutz, Legal, Enterprise Architecture, ggf. BCM-Verantwortliche.
• Informed (I): Geschäftsführung/Board-Risiko-Gremium bei wesentlichen Services.

Ergebnisdokument: Eine einseitige Entscheidungsvorlage (Renew / Renew with Conditions / Short Extension / Replace) mit Risiko-Heatmap, Kostenfolge (z. B. zusätzliche Kontrollen, Redundanz) und Umsetzungsplan.

Audit- und Nachweislogik: So wird die Prüfung wiederholbar

Für „Continuità operativa“ zählt Wiederholbarkeit. Ein Auditor will sehen, dass Sie nicht nur einmal geprüft haben, sondern dass die Steuerung dauerhaft funktioniert.

Nachweispaket pro Anbieter (Ordnerstruktur als Vorlage)

/third-party-risk/<anbieter>/<jahr>/
  01_vertrag_und_anhaenge/
  02_scope_und_architektur/
  03_sla_slo_reports/
  04_security_nachweise/
  05_subunternehmer/
  06_incident_und_rca/
  07_bcp_dr/
  08_datenschutz/
  09_exit_und_portabilitaet/
  10_findings_und_remediation/

Praktisch: Legen Sie je Ordner eine „README“-Notiz ab (kurzer Text), wer reviewed hat, wann das nächste Review fällig ist und welche offenen Punkte existieren. Das reduziert Personensilo-Risiko.

Kontrollkalender: Wiederkehrende Prüfungen ohne Aktionismus

Statt „jährlich alles“ lohnt ein Takt nach Risiko:

• Quartalsweise: SLA/SLO-Reports, Major-Incident-Auswertung, Subunternehmer-Änderungen.
• Halbjährlich: Zugriffskontrollen/Break-Glass-Review, Datenexport-Test (light), Patch-/Vuln-KPIs.
• Jährlich: SOC/ISO-Update, DR/BCP-Übungsnachweis, Exit-Plan-Review.

Damit wird die Vertragsverlängerung später weniger stressig: Sie haben den Verlauf dokumentiert und verhandeln auf Basis von Fakten.

Technische „Copy-&-Use“-Bausteine: Anforderungen und Policies als Textbaustein

Für viele Anbieter ist es hilfreich, nicht nur Fragen zu stellen, sondern Mindestanforderungen als wiederverwendbare Klausel-/Policy-Bausteine zu liefern. Die folgenden Blöcke sind bewusst textlich gehalten, damit sie in Ausschreibungen, Vertragsanhänge oder interne Policies kopiert werden können.

Mindestanforderung: Incident-Meldung und RCA

Der Anbieter meldet Sicherheits- und Verfügbarkeitsvorfälle, die den vereinbarten Service beeinflussen oder beeinflussen können, unverzüglich über einen 24/7-Kontaktweg.
Erstmeldung enthält mindestens: Zeitpunkt, betroffene Komponenten, vermutete Ursache, aktuelle Kundenwirkung, empfohlene Sofortmaßnahmen.
Der Anbieter liefert innerhalb eines vereinbarten Zeitfensters einen Abschlussbericht (RCA) mit: Ursachenanalyse, getroffenen Gegenmaßnahmen, offenen Maßnahmen inkl. Termin und Verantwortlichkeit, sowie Maßnahmen zur Vermeidung von Wiederholungen.

Mindestanforderung: Subunternehmer-Transparenz und Änderungsmanagement

Der Anbieter führt eine aktuelle Liste aller Unterauftragnehmer/Subprozessoren, die an der Leistungserbringung oder Datenverarbeitung beteiligt sind, inkl. Zweck, Standort/Region und betroffenen Datenarten.
Änderungen an dieser Liste werden mit Vorlauf angekündigt. Bei kritischen Änderungen erhält der Kunde ein Widerspruchs- oder Sonderkündigungsrecht.
Der Anbieter stellt sicher, dass wesentliche Sicherheits- und Resilienzanforderungen vertraglich an Unterauftragnehmer weitergegeben werden (Flow-down).

Mindestanforderung: Datenportabilität und Exit-Unterstützung

Der Anbieter ermöglicht während der Vertragslaufzeit und bei Vertragsende einen vollständigen Export aller kundenspezifischen Daten inkl. Metadaten in einem dokumentierten, gängigen Format.
Der Exportprozess ist innerhalb definierter Fristen durchführbar und wird auf Wunsch in einer Testdurchführung verifiziert.
Der Anbieter unterstützt den Übergang zu einem Nachfolgesystem (Exit Assistance) zu vorab definierten Konditionen.

Kosten- und Umsetzbarkeitsblick: Was ist realistisch – und was verursacht verdeckte Betriebskosten?

Resilienz-Anforderungen scheitern häufig nicht an der Idee, sondern am Aufwand. Drei typische Kostentreiber sollten Sie vor einer Verlängerung offen ansprechen:

• Messbarkeit und Monitoring: Wenn SLA-Messung nur über den Anbieter möglich ist, sind Streit und Blindflug vorprogrammiert. Planen Sie synthetisches Monitoring oder Log-/Metrik-Exports ein.
• Redundanz vs. Exit: Manche Risiken lösen Sie günstiger mit Exit-Fähigkeit (Portabilität, Alternativen, Datenexport) als mit teurer Doppelbetreibung.
• Interne Prozesslast: Unklare Kommunikationswege, manuelle Exportschritte, fehlende Reports binden Betriebskapazität. Das gehört in die TCO-Sicht (Total Cost of Ownership), nicht nur in den Security-Ordner.

Eine klare Regel hilft: Wenn ein Anbieter eine Anforderung nicht erfüllen kann, muss er entweder (a) eine alternative Kontrolle anbieten (kompensierende Maßnahme) oder (b) Sie müssen das Risiko bewusst akzeptieren und technisch/organisatorisch abfedern. „Wird schon passen“ ist keine Option, wenn die Abhängigkeit wesentlich ist.

Schlussfazit: Verlängerung als Resilienz-Review, nicht als Einkaufstermin

Lieferketten-Resilienz entsteht nicht durch ein einzelnes Dokument, sondern durch eine Kette aus klaren Verträgen, messbaren Servicezielen, belastbaren Sicherheitsnachweisen, beherrschbaren Subunternehmern und einer realistischen Exit-Fähigkeit. Die Vertragsverlängerung ist der Moment, an dem Sie diese Kette stärken können – mit minimaler Reibung und maximaler Wirkung.

Wenn Sie vor der Verlängerung Kritikalität und Abhängigkeiten sauber bestimmen, Prüfbereiche priorisieren (Dealbreaker/Auflagen/Backlog) und eine auditfähige Nachweislogik etablieren, wird aus Vendor Management ein operatives Steuerungsinstrument. Das senkt nicht nur Risiken, sondern reduziert auch ungeplante Betriebskosten im Incident und im Wechsel-Szenario.

Für dieses Thema sind auch Drittanbieter-Risikomanagement und Vendor Risk Management wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.