Entscheidungshilfe: IT-Dienstleister nach Risiko-, Compliance- und Sicherheitskriterien auswählen

Wer IT-Dienstleister auswählen muss, entscheidet nicht nur über Tagessätze und Verfügbarkeit, sondern über eine Erweiterung der eigenen Angriffsfläche, über regulatorische Nachweispflichten und über die Frage, wie schnell Sie im Störfall wieder handlungsfähig sind. In vielen Unternehmen werden Dienstleister faktisch zu Mitbetreibern: Sie administrieren Systeme, bewegen Daten, konfigurieren Sicherheitsmechanismen und beeinflussen Betriebsprozesse. Genau deshalb reicht „guter Eindruck im Pitch“ nicht aus.

Dieser Beitrag ist als Entscheidungshilfe für IT-Leitung, Informationssicherheit (ISMS), Datenschutz, Compliance und Geschäftsführung gedacht. Er zeigt ein praxistaugliches Vorgehen, um Anbieter risikobasiert zu bewerten: Welche Nachweise sind sinnvoll, welche Kontrollen sind unverzichtbar, wie setzen Sie Governance und Verantwortlichkeiten auf, und wie vermeiden Sie typische Fallen (Subdienstleister, Logzugriff, Exit, Beweisketten). Ziel ist eine Auswahlentscheidung, die später im Audit standhält und im Betrieb nicht zu Überraschungen führt.

1) Ausgangspunkt: Was bedeutet „Risiko“ bei IT-Dienstleistern konkret?

Im Lieferantenkontext ist Risiko nicht abstrakt, sondern sehr konkret: Es geht um die Kombination aus Eintrittswahrscheinlichkeit und Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit (CIA-Triade). Zusätzlich zählt die Nachweisbarkeit: Können Sie belegen, dass Kontrollen existieren und wirken?

Für die Bewertung hilft eine klare Trennung in vier Risikodomänen:

• Datenrisiko: Welche Daten verarbeitet der Dienstleister (personenbezogen, vertraulich, Geschäftsgeheimnisse)? Wo liegen sie, wie werden sie verschlüsselt, wer hat Zugriff?
• Zugriffs- und Betriebsrisiko: Erhält der Dienstleister Admin-Zugriff, Shell-Zugriff, VPN-Zugriff oder nur Ticket-basierten Zugriff? Gibt es Notfallzugänge? Werden Änderungen nach Change-Management durchgeführt?
• Lieferkettenrisiko: Subdienstleister (z. B. Cloud-Provider, Support-Ketten), Standortwechsel, Abhängigkeiten, proprietäre Tools, Exit-Hürden.
• Compliance- und Audit-Risiko: DSGVO, Branchenregeln, interne Policies, Aufbewahrung, Protokollierung, Nachweispflichten, Prüfrechte.

Eine belastbare Auswahlentscheidung setzt voraus, dass Sie zuerst den geplanten Einsatz des Dienstleisters präzise beschreiben: Systeme, Datenklassen, Privilegien, Betriebsfenster, RTO/RPO (Wiederanlaufzeit/Wiederanlaufpunkt) und organisatorische Schnittstellen. Ohne diese Eingrenzung wird jedes Assessment entweder zu weich („alles ist wichtig“) oder zu hart („alles verboten“).

2) Risikoklassifizierung vor dem Screening: Tiering statt Bauchgefühl

In der Praxis bewährt sich ein Tiering (Einstufung in Kritikalitätsstufen), das den Aufwand für Due Diligence und Vertragsklauseln steuert. Damit vermeiden Sie, dass Sie bei jedem kleinen Supportvertrag die komplette Audit-Maschinerie ausrollen – und gleichzeitig stellen Sie sicher, dass kritische Partner nicht durchrutschen.

Vorschlag für 4 Tiers (anpassbar)

• Tier 1 – Kritisch: Admin-/Root-Zugriffe, produktionsnahe Netzwerke, Verarbeitung sensibler Daten, Betrieb kritischer Prozesse, signifikante Ausfallauswirkungen.
• Tier 2 – Hoch: Zugriff auf wichtige Systeme oder große Datenmengen, aber mit Einschränkungen (z. B. nur über Jump-Host, streng getrennter Scope).
• Tier 3 – Mittel: begrenzter Zugriff, überwiegend Beratung/Projektarbeit, eingeschränkte Datenverarbeitung.
• Tier 4 – Niedrig: keine oder minimale Datenverarbeitung, kein Zugriff auf produktive Systeme (z. B. Schulung).

Ein Tiering sollte nicht allein an „Cloud vs. On-Prem“ hängen, sondern an Privilegien, Datenklassen und Betriebsverantwortung. Ein externer Admin im internen Netzwerk ist häufig riskanter als ein SaaS-Dienst mit sauberem Mandantenmodell und klaren Nachweisen.

3) Kernfrage im Auswahlprozess: Welches Betriebsmodell übernehmen Sie selbst – und was delegieren Sie wirklich?

Viele spätere Konflikte entstehen durch unscharfe Erwartungen: „Managed“ bedeutet nicht automatisch 24/7, nicht automatisch Patchen, nicht automatisch Backup-Restore-Tests. Darum muss das Betriebsmodell vor Vertragsabschluss in Betriebssprache beschrieben werden.

Praktische Abgrenzung: RACI und Betriebsartefakte

RACI ordnet Rollen zu: Responsible (ausführend), Accountable (verantwortlich), Consulted (einbezogen), Informed (zu informieren). Für Audits ist besonders wichtig, dass „Accountable“ eindeutig bleibt, auch wenn ein Dienstleister operativ handelt.

Artefakte, die Sie für kritische Dienstleister verbindlich einfordern sollten:

• Betriebshandbuch/Runbooks (Routine und Notfall)
• Change-Prozess inkl. Freigaberegeln und Rollback
• Monitoring- und Alarmierungswege (inkl. Bereitschaften)
• Backup- und Restore-Konzept (inkl. Testnachweisen)
• Patch- und Vulnerability-Management (Zyklen, Ausnahmen, Risikofreigaben)
• Incident-Handling inkl. Evidence (Beweissicherung) und Kommunikationsmatrix

4) Compliance und Nachweise: Welche Dokumente helfen wirklich?

Compliance wird oft mit „Papier“ verwechselt. Entscheidend ist, ob Nachweise prüfbar und scope-treffend sind. Ein ISO-27001-Zertifikat kann wertvoll sein – sagt aber ohne Scope-Prüfung wenig aus. Ein SOC-2-Report (Typ II) kann sehr hilfreich sein – aber nur, wenn die Controls zu Ihrem Risiko passen und die Ausnahmen (Exceptions) verstanden und adressiert werden.

Nachweise, die in der Praxis Substanz haben

• ISMS-Nachweise: ISO 27001 (Scope, Statement of Applicability), interne Policies, Risikobehandlung.
• SOC 2 Typ II: Zeitraum, geprüfte Trust Services Criteria, Findings/Exceptions, Subservice-Organisationen.
• Penetrationstest-/Vulnerability-Management-Nachweise: Frequenz, Scope, Umgang mit Findings (ohne dass Sie zwingend Detailberichte erhalten müssen).
• Datenschutzunterlagen: AVV (Auftragsverarbeitung), TOMs (technische und organisatorische Maßnahmen), Subprozessorenliste, Lösch- und Rückgabekonzept.
• BCM/DR: Business Continuity Management und Disaster Recovery, Testfrequenzen, Ergebnisse, Lessons Learned.

Wichtig: „Wir erfüllen DSGVO“ ist keine Aussage. Für DSGVO brauchen Sie konkrete Bausteine: AVV, Zweck, Kategorien betroffener Personen, Datenarten, Löschfristen, technische Maßnahmen, internationale Transfers (z. B. Standardvertragsklauseln) und ein belastbares Subdienstleister-Management.

5) Sicherheitskriterien für die Auswahl: Kontrollen, die im Betrieb zählen

Für die Auswahlentscheidung sollten Sie Sicherheitskriterien so formulieren, dass sie später operationalisierbar sind. Statt „hohe Sicherheit“ brauchen Sie prüfbare Anforderungen. Im Folgenden die Kontrollfamilien, die sich in Dienstleisterbeziehungen regelmäßig als entscheidend erweisen.

Identitäten und privilegierte Zugriffe (IAM/PAM)

IAM (Identity and Access Management) regelt Identitäten, Rollen und Berechtigungen. PAM (Privileged Access Management) steuert besonders mächtige Admin-Zugriffe, idealerweise zeitlich begrenzt und nachvollziehbar.

• Individuelle Benutzer statt Shared Accounts
• MFA (Multi-Faktor-Authentifizierung) verpflichtend
• Just-in-Time/Just-Enough-Access, wo möglich
• Zugriff über Jump-Hosts/Bastion, keine direkten Admin-Logins aus dem Internet
• Session Recording oder zumindest detaillierte Audit-Logs für privilegierte Aktionen

Prüffrage: Können Sie im Incident-Fall nachweisen, wer wann was gemacht hat, und können Sie Zugriffe innerhalb von Minuten entziehen?

Netzwerk- und Mandantentrennung

Gerade bei Managed Services ist die Segmentierung entscheidend: getrennte Netze für Management, Produktion, Backup, Logging; klare Firewall-Regeln; und ein dokumentiertes Regelwerk für Ausnahmen. Mandantentrennung ist bei SaaS-Anbietern zentral: logische Trennung (Tenant-Isolation), Verschlüsselung und Schutz vor Datenabfluss über Fehlkonfiguration.

Vulnerability- und Patch-Management

Für Auswahl und Vertrag zählt weniger der „Patch-Turnus“ als die Fähigkeit, Risiken zu steuern: Wie wird priorisiert (kritisch/hoch/mittel), wie werden Ausnahmen dokumentiert, wie erfolgt die Kompensation (z. B. WAF-Regeln, Isolation), und wie schnell können Hotfixes eingespielt werden?

Ein einfacher, aber wirkungsvoller Nachweis ist ein regelmäßiger Export aus dem Ticket-/Vulnerability-Prozess (anonymisiert), der zeigt: Eingang, Bewertung, Frist, Umsetzung, Review.

Logging, Monitoring, Forensikfähigkeit

Hier entscheidet sich Audit-Readiness: Ohne belastbare Logs (Zeitstempel, Integritätsschutz, Aufbewahrung) bleiben Vorfälle eine Meinungsfrage. Für Dienstleister ist besonders heikel, wenn Logs beim Dienstleister liegen, aber Sie als Kunde die Nachweispflicht tragen.

• Definierte Logquellen (Auth, Admin-Aktionen, Systemänderungen, API-Zugriffe)
• Zentrale Ablage mit Zugriffskonzept (Least Privilege)
• Aufbewahrungsfristen passend zu Regulierung und internen Policies
• Integrität (Manipulationsschutz) und Zeit-Synchronisation (NTP)

6) Datenschutz und Datenhoheit: AVV ist nur der Anfang

Datenschutz wird bei Dienstleisterauswahl häufig auf die AVV reduziert. Das ist riskant, weil die kritischen Fragen in der technischen Umsetzung liegen: Wo werden Daten verarbeitet, wie werden sie verschlüsselt, wie erfolgt Löschung, und wie wird Datenrückgabe im Exit umgesetzt?

Konkrete Anforderungen, die Sie dokumentieren sollten

• Datenlokation: Regionen/Rechenzentren, internationale Transfers, Rechtsgrundlagen.
• Verschlüsselung: in Transit (TLS) und at Rest; Schlüsselmanagement (KMS), Zugriff auf Schlüssel.
• Backups: enthalten sie personenbezogene Daten? Wie werden Backups gelöscht? Welche Retention gilt?
• Data Subject Requests: Unterstützung bei Auskunft/Löschung/Export, Fristen und Prozess.
• Rollenmodell: Wer ist Verantwortlicher, wer Auftragsverarbeiter, wer Subauftragsverarbeiter?

Wenn Sie strenge Anforderungen haben (z. B. Schlüssel in eigener Kontrolle, „Bring Your Own Key“), müssen diese Anforderungen vor der Auswahl in die Muss-Kriterien. Im Nachhinein sind solche Punkte häufig teuer oder technisch nicht machbar.

7) Subdienstleister und Lieferkette: Der blinde Fleck im Vendor-Management

Viele Risiken entstehen nicht beim ausgewählten Partner, sondern in der Kette: Cloud-Hosting, 24/7-NOC, externe Entwicklerteams, Support in anderen Jurisdiktionen. Subdienstleister sind nicht per se schlecht – aber sie müssen transparent, kontrollierbar und vertraglich abgedeckt sein.

Worauf Sie bestehen sollten

• Aktuelle Subdienstleisterliste mit Leistungsanteilen und Datenzugriffen
• Änderungsprozess: Vorabinformation und Widerspruchs-/Kündigungsrechte bei kritischen Änderungen
• „Flow-down“-Klauseln: Sicherheits- und Datenschutzanforderungen gelten in der Kette
• Rechte zur Einsicht in relevante Nachweise (z. B. SOC-Reports der Subservice-Organisation)

8) Vertrags- und SLA-Logik: Sicherheitsanforderungen müssen messbar werden

Verträge scheitern selten an einem fehlenden Paragraphen, sondern an nicht messbaren Erwartungen. SLAs (Service Level Agreements) beschreiben Serviceziele (z. B. Verfügbarkeit, Reaktionszeiten). OLAs (Operational Level Agreements) sind interne/operative Vereinbarungen zwischen Teams oder zwischen Dienstleister-Einheiten, die SLAs überhaupt erst erfüllbar machen.

Typische SLA-Bausteine, die Sie konkretisieren sollten

• Incident-Klassifizierung: P1/P2/P3-Definitionen anhand von Business-Impact
• Reaktions- und Wiederherstellungszeiten: nicht nur „Response“, sondern „Restore“
• Change-Fenster: Standard vs. Emergency Changes, Dokumentationspflicht
• Security SLAs: Fristen zur Behebung kritischer Schwachstellen, Patch-Zyklen, Ausnahmeregeln
• Reporting: monatliche Service-Reports mit definierten Kennzahlen und Abweichungsanalyse

Wichtig aus Audit-Sicht: Wenn Sie Sicherheitskontrollen vertraglich festschreiben, brauchen Sie auch eine Mess- und Nachweisroutine. Sonst entsteht eine Lücke zwischen Vertrag und Realität.

9) Audit-Perspektive: Was Prüfer typischerweise sehen wollen

Audits prüfen selten einzelne technische Details, sondern die Steuerbarkeit: Gibt es ein Verfahren, werden Entscheidungen dokumentiert, sind Verantwortlichkeiten klar, und sind Kontrollen wirksam. Für Dienstleisterbeziehungen laufen viele Prüfungen auf drei Fragen hinaus:

• Wurden Risiken vor Beauftragung bewertet? (Due Diligence, Tiering, Freigaben)
• Sind Kontrollen in Betrieb und Vertrag verankert? (SLA, Security-Anforderungen, Datenschutz, Subdienstleister)
• Können Sie die Wirksamkeit nachweisen? (Reports, Logs, Tests, Review-Protokolle)

Audit-fähig heißt nicht „dokumentenlastig“. Es heißt: Entscheide nachvollziehbar, dokumentiere knapp, speichere Evidenz zentral, und führe regelmäßige Reviews durch.

10) Praktische Checkliste: Due-Diligence-Fragen, die in der Auswahl wirklich helfen

Die folgende Liste ist als pragmatischer Kern gedacht. Sie ersetzt keine individuelle Risikoanalyse, aber sie deckt die typischen Entscheidungskriterien ab, die später im Betrieb und im Audit relevant werden.

A) Scope und Zugriff

• Welche Systeme/Umgebungen sind im Scope (Prod/Stage/Dev)?
• Welche Zugriffstypen (VPN, Jump-Host, API, Ticket-only) sind erforderlich?
• Wie werden privilegierte Zugriffe vergeben, protokolliert und entzogen?

B) Security Controls

• Welche Mindeststandards gelten (MFA, Passwortpolicy, Hardening, EDR/AV)?
• Wie läuft Patch-/Vulnerability-Management, inkl. Priorisierung und Ausnahmen?
• Wie wird Logging umgesetzt, wer hat Zugriff, welche Retention gilt?

C) Datenschutz und Datenmanagement

• AVV/TOMs: liegen aktuell vor und passen sie zum tatsächlichen Prozess?
• Datenlokation, Subdienstleister, internationale Transfers: sauber beschrieben?
• Löschung, Rückgabe und Backup-Retention: operativ umsetzbar?

D) Betrieb, Resilienz, Notfall

• Monitoring und On-Call: Zeiten, Eskalationswege, Kommunikationskanäle?
• Backup/Restore: werden Restores getestet und dokumentiert?
• BCM/DR: gibt es Tests, und was waren die letzten Ergebnisse?

E) Governance und Nachweise

• Welche Nachweise (ISO/SOC) liegen vor und welcher Scope ist abgedeckt?
• Wie werden Changes, Incidents und Reviews dokumentiert?
• Gibt es ein Prüfrecht, und wie wird es praktisch umgesetzt (z. B. Remote-Audit, Report-Einsicht)?

11) Scorecard-Ansatz: Entscheidung transparent machen (ohne Scheingenauigkeit)

Eine Scorecard hilft, mehrere Anbieter vergleichbar zu machen und Entscheidungen gegenüber Geschäftsführung, Revision oder Datenschutz zu begründen. Wichtig: Keine Scheingenauigkeit. Nutzen Sie wenige Kriterien, klare Gewichtung und dokumentieren Sie Abweichungen mit Kompensationsmaßnahmen.

Vorschlag für Gewichtung (Beispiel)

• 30% Sicherheit & Zugriffskontrollen
• 25% Betrieb & Resilienz (RTO/RPO, Runbooks, On-Call)
• 20% Compliance & Nachweise (ISO/SOC/AVV, Auditfähigkeit)
• 15% Lieferkette & Subdienstleister-Steuerung
• 10% Kommerzielle Faktoren (Kostenmodell, Transparenz, Flexibilität)

Bei Tier-1-Dienstleistern sollten Muss-Kriterien existieren, die nicht „weggewichtet“ werden dürfen (z. B. MFA, individuelle Accounts, AVV bei personenbezogenen Daten, Exit-Regelung, Logging). Wenn ein Muss-Kriterium nicht erfüllt ist, ist der Anbieter entweder raus oder es braucht eine formal genehmigte Risikofreigabe mit Kompensation.

12) Exit- und Notfallplanung: Auswahlkriterium, nicht Abschlussgedanke

Exit klingt nach Vertragsende, ist aber ein Sicherheits- und Betriebshebel: Was passiert bei Insolvenz, schwerem Incident, Streit, regulatorischem Stopp oder strategischem Wechsel? Ohne Exit-Plan steigt das Lock-in-Risiko, und im Notfall fehlt Zeit, Daten und Know-how sauber zu übergeben.

Elemente, die in Auswahl und Vertrag gehören

• Datenrückgabe: Formate, Vollständigkeit, Zeitfenster, Verantwortlichkeiten
• Löschbestätigung: inklusive Backups/Archivkopien (so weit technisch möglich, transparent beschrieben)
• Übergabe von Dokumentation: Runbooks, Architektur, Konfigurationen, Schlüssel-/Zertifikatsinventar
• Transition Support: definierte Stunden/Kontingente, priorisierte Aufgaben, Zugriff für Nachfolger
• Notfall-Exit: Sonderkündigung, Zugang zu Systemen/Logs, Freeze von Changes

Aus Betriebssicht ist besonders wichtig, dass Sie nicht nur „Daten“ zurückbekommen, sondern auch Betriebsfähigkeit: Konfigurationen, Zugriffsmodelle, Monitoring-Setups und Wiederherstellungswege.

13) Praktische Source-Blöcke: Vorlagen für Policies und Prüfkommandos

Die folgenden Beispiele sind bewusst generisch gehalten und müssen an Ihre Umgebung angepasst werden. Sie können sie als Startpunkt für interne Policies, Lieferantenanforderungen oder Audit-Checks verwenden.

Policy-Vorlage: Mindestanforderungen für Dienstleisterzugänge

POLICY: Drittanbieter-Zugriff auf IT-Systeme (Mindestanforderungen)

1. Identitäten
- Nur individuelle Benutzerkonten, keine geteilten Accounts.
- MFA verpflichtend für alle externen Zugänge.
- Rollenbasierte Berechtigungen (Least Privilege), zeitlich begrenzte Adminrechte (Just-in-Time).

2. Zugriffswege
- Adminzugriffe ausschließlich über definierte Jump-Hosts/Bastion oder PAM-Lösung.
- Kein direkter administrativer Zugriff aus dem Internet.
- Zugriff nur aus freigegebenen Netzen/Quellen (Allowlist), soweit praktikabel.

3. Protokollierung
- Authentifizierung, privilegierte Aktionen und Konfigurationsänderungen werden zentral geloggt.
- Logs sind gegen Manipulation geschützt und werden gemäß Retention-Vorgaben aufbewahrt.

4. Onboarding/Offboarding
- Freigabeprozess vor Einrichtung, inkl. Ticket und Owner.
- Deprovisionierung innerhalb definierter Frist nach Rollenwechsel/Projektende.

5. Ausnahmen
- Ausnahmen nur mit dokumentierter Risikobewertung, Ablaufdatum und Kompensationsmaßnahmen.

Prüfkommandos (Beispiele): Nachvollziehbarkeit von Adminzugriffen unter Linux

Für viele Umgebungen ist wichtig, ob privilegierte Aktionen nachvollziehbar sind. Die folgenden Checks helfen, typische Grundlagen zu prüfen (Auditd/Journal/Sudo). Sie sind keine vollständige Security-Prüfung, aber ein schneller Reality-Check im Onboarding oder Review.

# Prüfen, ob sudo-Aktionen geloggt werden (Beispielpfade je nach Distribution)
sudo grep -R "^Defaults" /etc/sudoers /etc/sudoers.d 2>/dev/null | head

# Letzte sudo-Ereignisse (wenn über journald erfasst)
sudo journalctl -u sudo --since "7 days ago" 2>/dev/null | tail -n 50

# Prüfen, ob auditd aktiv ist
sudo systemctl status auditd --no-pager

# Audit-Regeln anzeigen (falls auditd genutzt wird)
sudo auditctl -l 2>/dev/null | head -n 50

Wichtig für die Bewertung eines Dienstleisters ist weniger, dass ein bestimmtes Tool genutzt wird, sondern ob Ihr Ziel erreicht wird: unveränderbare, zentrale, auswertbare Audit-Spuren für relevante Aktionen.

14) Kosten und Aufwand realistisch einordnen: Sicherheit ist nicht gratis, Unsicherheit ist teurer

Risikobasierte Auswahl spart Geld, wenn sie verhindert, dass Sie an der falschen Stelle „billig“ einkaufen. Typische Kostenblöcke, die in Business Cases unterschätzt werden:

• Transaktionskosten: Onboarding, Due Diligence, Vertragsprüfung, Tool-Anbindungen
• Kontrollkosten: Reviews, Reports, Audits, Pen-Tests, Access-Recertification
• Incident-Kosten: Forensik, Stillstand, Kundenkommunikation, regulatorische Meldungen
• Lock-in-Kosten: Exit-Projekt, Datenmigration, Wissenstransfer

Ein pragmatischer Ansatz: Planen Sie Tier-1-Lieferanten wie interne kritische Systeme. Das bedeutet nicht „alles selbst machen“, sondern Steuerbarkeit herstellen: klare Rollen, klare Messpunkte, klare Evidenz.

15) Governance im Alltag: Wer entscheidet was – und wer trägt welche Verantwortung?

Vendor Governance funktioniert nur, wenn sie im Alltag gelebt wird. Dazu gehören feste Rituale und eindeutige Verantwortlichkeiten:

• Service Owner auf Kundenseite: fachlich/operativ zuständig, bewertet Reports, steuert Backlog
• Security/Compliance: definiert Muss-Kontrollen, prüft Abweichungen, genehmigt Ausnahmen
• Datenschutz: bewertet Datenflüsse, AVV/TOMs, Transfers, Löschkonzepte
• Provider Manager (oder Einkauf/Legal): Vertrags- und Eskalationsmanagement
• IT-Betrieb: integriert Monitoring, Logging, Backup, Changes, On-Call-Prozesse

Bewährt haben sich quartalsweise Service Reviews (SLA, Incidents, Changes, Security Findings) und ein jährliches Re-Assessment für Tier-1/2. Nicht als Formalie, sondern als Zeitpunkt für harte Fragen: Haben sich Scope, Subdienstleister, Datenklassen oder Zugriffsmuster verändert?

Fazit: IT-Dienstleister auswählen heißt steuerbare Risiken einkaufen

Eine gute Auswahlentscheidung entsteht aus einem einfachen Prinzip: Je größer der Zugriff und je kritischer die Daten oder Betriebsverantwortung, desto strenger müssen Nachweise, Kontrollen und Exit-Regeln sein. Wenn Sie Tiering, Scorecard und Muss-Kriterien sauber kombinieren, vermeiden Sie zwei Extreme: überzogene Anforderungen für unkritische Lieferanten und gefährliche Lücken bei kritischen Partnern.

Setzen Sie auf prüfbare Kriterien (IAM/PAM, Logging, Patch-Prozesse, Subdienstleister-Steuerung), verankern Sie diese vertraglich messbar (SLA/Security SLAs) und planen Sie Exit sowie Notfallübergaben von Anfang an. Damit wird Dienstleistermanagement weniger „Bauchgefühl“ und mehr eine auditfähige, betriebstaugliche Disziplin.

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