Beschaffungsteams stehen heute vor der Aufgabe, nicht nur Preis und Funktion, sondern auch die Sicherheit von Anbietern systematisch zu bewerten. Die Anbieter‑Sicherheitsbewertung ist ein zentraler Baustein der Risikosteuerung: Sie verbindet technische Prüfungen, Governance‑Entscheidungen und vertragliche Absicherungen. Dieser Beitrag liefert 10 konkrete Auditfragen, erklärt erwartbare Antworten, zeigt typische Risiken und gibt priorisierte Handlungsempfehlungen für IT‑Leitung, Compliance und Einkauf.
Warum eine strukturierte Anbieter‑Sicherheitsbewertung notwendig ist
Unternehmen kaufen zunehmend prozessnahe Softwarelösungen und nutzen Cloud‑Dienste. Ein Sicherheitsvorfall beim Anbieter trifft schnell Verfügbarkeit, Integrität und Vertraulichkeit der eigenen Daten. Eine strukturierte Bewertung reduziert das Risiko und schafft Entscheidungsgrundlagen für SLA, Haftung und technische Integrationen.
Wichtig: „Anbieter‑Sicherheitsbewertung“ meint hier das ganzheitliche Prüfverfahren — technische Security, organisatorische Maßnahmen, Compliance‑Status, Datenflüsse, Zugangskontrolle und Contingency‑Planung.
Wie dieser Leitfaden zu nutzen ist
Nutzen Sie die 10 Auditfragen als Checkliste in der RFP‑Phase, bei Vertragsverlängerungen und als Teil periodischer Third‑Party Reviews. Jede Frage enthält:
- konkrete Prüfbelege,
- Red‑Flags,
- Auswirkungsanalyse (Betrieb, Datenschutz, Compliance),
- empfohlene Gegenmaßnahmen und Priorität.
10 kritische Auditfragen für die Anbieter‑Sicherheitsbewertung
Die folgende Liste ist der Kern der Bewertung. Jede Frage ist unmittelbar operabel und lässt sich in ein Bewertungsformular oder ein RFP integrieren.
1) Wer hat Zugriff auf unsere Daten und wie wird der Zugriff gesteuert?
Was zu prüfen ist: Beschreibung der Identity‑ und Access‑Management(=IAM)-Prozesse, Rollen‑ und Rechtekonzept, Multi‑Factor‑Authentication (MFA) für administrative Zugänge, Prozeduren für Onboarding/Offboarding, Remote‑Zugriffskontrollen.
Erwartete Belege: IAM‑Diagramm, Beispiel‑User‑Provisioning‑Log, Proof of MFA‑Enforcement, Periodische Zugriffsreviews.
Red‑Flags: Shared Accounts ohne Nachverfolgbarkeit, fehlende MFA, kein Prozess für privilegierte Accounts.
Auswirkung: Unberechtigter Zugriff kann Datenverlust, Compliance‑Verstöße (z. B. DSGVO) und Betriebsunterbrechungen verursachen.
Maßnahme & Priorität: Verlangen Sie MFA für alle administrativen Zugänge und eine Verpflichtung zu regelmäßigen Zugriffsreviews. Priorität: Hoch.
2) Wie schützt der Anbieter Daten im Transit und ruhend?
Was zu prüfen ist: Verschlüsselungsstandards (TLS Version, Cipher Suites, HSM, Verschlüsselung von Backups), Key‑Management, Verschlüsselungsgrad für ruhende Daten (at‑rest) sowie End‑to‑End‑Szenarien für sensitive Datensätze.
Erwartete Belege: TLS/HTTPS‑Konfiguration, KMS‑Architekturdiagramm, Verschlüsselungspolicy, Nachweise für Key‑Rotation.
Red‑Flags: Klartext‑Speicherung sensibler Felder, proprietäres Key‑Management ohne Export/Recoverykonzept.
Auswirkung: Datenabfluss, Reputationsschaden, regulatorische Bußen.
Maßnahme & Priorität: Forderung nach Industriestandard (z. B. TLS 1.2+ mit aktuellen Ciphers), KMS mit Rollenbasiertem Zugriff, klare Backup‑Verschlüsselung. Priorität: Hoch.
3) Wie sieht das Patch‑ und Vulnerability‑Management aus?
Was zu prüfen ist: Update‑Prozesse für OS, Middleware und Anwendung, SLA‑Zeiten für kritische Patches, Schwachstellen‑Scanning‑Frequenz, Pentest‑Regelung (Intervall, Scope), Remediation‑Tracking.
Erwartete Belege: Patch‑Policy, Patch‑Zeitachse, Berichte aus Schwachstellenscans, Pentest‑Reports (ggf. redacted).
Red‑Flags: Kein Zeitplan für kritische Patches, fehlende Verantwortlichkeiten, Pentests nur auf Anfrage.
Auswirkung: Erhöhte Angriffsfläche; Zero‑Day‑Exploits können zur Kompromittierung führen.
Maßnahme & Priorität: Vereinbaren Sie verpflichtende Patch‑SLAs und definieren Sie Verantwortlichkeiten; fordern Sie regelmäßige, unabhängige Pentests. Priorität: Hoch.
4) Wie wird die Betriebsumgebung isoliert und segmentiert?
Was zu prüfen ist: Netzwerksegmentierung, Multi‑Tenant‑Isolation (bei SaaS), Mikrosegmentierung, Nutzung von Virtual Private Cloud (VPC), Passthrough‑Zugriffe zwischen Kundenumgebungen.
Erwartete Belege: Netzwerkdiagramme, Tenant‑Isolation‑Architektur, NSG/Firewall‑Regeln, Tests zur Isolation.
Red‑Flags: Single‑tenant‑Grenzen nicht klar, Shared‑Storage ohne ACLs, ungeprüfte Cross‑Tenant‑Ressourcen.
Auswirkung: Seitliche Bewegung möglich, Datenexfiltration zwischen Mandanten.
Maßnahme & Priorität: Setzen Sie Mindestanforderungen an Tenant‑Isolation und fordern Sie Nachweise durch Isolationstests. Priorität: Mittel bis Hoch (abhängig von Multi‑Tenant‑Risiko).
5) Welche Logging‑, Monitoring‑ und Incident‑Response‑Fähigkeiten existieren?
Was zu prüfen ist: Umfang und Retentionszeit von Audit‑Logs (Zugriffe, Änderungen), SIEM‑Integration, Alerting‑Regeln, Incident‑Response(IR)-Prozesse und Eskalationsstufen, Kommunikationspläne bei Sicherheitsvorfällen.
Erwartete Belege: Beispiel‑Logeinträge, SLA für Incident‑Benachrichtigung, IR‑Playbook (redacted), SOC‑Verfügbarkeit.
Red‑Flags: Kurzfristige Log‑Retention, fehlender Kunden‑Benachrichtigungsmechanismus, kein dokumentierter IR‑Prozess.
Auswirkung: Verzögerte Erkennung, höhere Schadensausbreitung, regulatorische Meldungspflichten nicht erfüllbar.
Maßnahme & Priorität: Verlangen Sie Mindestlog‑Retention und definierte Notification‑SLA bei Sicherheitsvorfällen. Priorität: Hoch.
6) Wie ist die Datenresidenz, Datenverarbeitung und Subprozessorenkette geregelt?
Was zu prüfen ist: Regionale Datenhaltung, Nutzung von Subprozessoren (Third Parties), Vertragsbedingungen zu Datenverarbeitung, Rechtsfolgen bei grenzüberschreitender Übermittlung, Datenlöschung/Exportprozesse.
Erwartete Belege: Subprozessoren‑Liste, Data Processing Agreement (DPA), Data Flow Diagramme.
Red‑Flags: Unklare Subprozessoren‑Kette, keine DPA, Datenhaltung in unsicheren Jurisdiktionen ohne entsprechende Schutzmaßnahmen.
Auswirkung: DSGVO‑Risiken, Anordnungspflichten bei Behörden, Verlust der Kontrolle über Daten.
Maßnahme & Priorität: Forderung nach transparenter Subprozessor‑Liste mit Änderungsbenachrichtigung, DPA und Standardvertragsklauseln. Priorität: Hoch (bei personenbezogenen Daten zwingend).
7) Wie belastbar ist die Business Continuity und das Backup/Restore‑Konzept?
Was zu prüfen ist: RTO/RPO‑Ziele, Backup‑Standorte, Testfrequenz für Restore, Disaster‑Recovery(=DR)-Plan, Independence der Backups (gegen Provider‑Fehler).
Erwartete Belege: Restore‑Testprotokolle, SLA‑Ziele für Verfügbarkeit, DR‑Playbook.
Red‑Flags: Keine regelmäßigen Restore‑Tests, Backups am gleichen logischen Standort wie Produktionsdaten.
Auswirkung: Längere Ausfallzeiten, Datenverlust, nicht erfüllte SLAs.
Maßnahme & Priorität: Verlangen Sie nachweisbare Restore‑Tests und trennen Sie Backup‑Standorte. Priorität: Mittel bis Hoch, abhängig von Business‑Kritikalität.
8) Welche Belege zur Secure‑Development‑Lifecycle(SDLC) und Code‑Qualität liefert der Anbieter?
Was zu prüfen ist: Verwendung von Sicherheits‑Gates im CI/CD, Code‑Scanning/Dependency‑Scanning, Testabdeckung, Release‑Prozesse, SAST/DAST‑Reports, Vulnerability‑Fix‑Policy.
Erwartete Belege: CI/CD‑Pipelinebeschreibung, Scan‑Reports, Policy zur Drittbibliotheksprüfung.
Red‑Flags: Kein automatisiertes Scanning, keine policygesteuerte Abhängigkeiten‑Prüfung.
Auswirkung: Eingeschleppte Schwachstellen durch Libraries, lange Remediation‑Zeiten.
Maßnahme & Priorität: Vereinbaren Sie SAST/DAST sowie Dependency‑Scanning als Vertragsbestandteil. Priorität: Mittel.
9) Wie sind Vertragsklauseln zu Haftung, Meldung und Audit geregelt?
Was zu prüfen ist: Rechte zu Audits, Haftungsbegrenzungen, Versicherungen (z. B. Cyber‑E&O), Benachrichtigungsfristen, SLAs, Aufwandsersatz für Incident‑Handling.
Erwartete Belege: Vertragsentwurf mit Auditklausel, Versicherungspolicen, SLA‑Matrix.
Red‑Flags: Absoluter Haftungsausschluss für Sicherheitsvorfälle, kein Auditrecht, intransparente SLA‑Messgrößen.
Auswirkung: Eingeschränkte Rechtsdurchsetzung, finanzielle Risiken, mangelnde Governance.
Maßnahme & Priorität: Aushandeln von Auditrechten, angemessenen Haftungsgrenzen und Pflicht zur Cyberversicherung. Priorität: Hoch (rechtlich entscheidend).
10) Welche Sichtbarkeit und Reporting erhalten wir im Betrieb?
Was zu prüfen ist: Dashboards, Health‑Reports, Security‑Metriken, SLAs und regelmäßige Review‑Meetings; Integration in eigenes Monitoring via APIs oder Log‑Forwarding.
Erwartete Belege: Beispiel‑Dashboard, API‑Specs für Monitoring, Reporting‑Rhythmus.
Red‑Flags: Keine Echtzeit‑Metriken, Reporting nur auf Anfrage.
Auswirkung: Eingeschränkte Kontrolle im Betrieb, schwierige SLA‑Verifikation.
Maßnahme & Priorität: Fordern Sie standardisierte Service‑Reports und API‑Zugriff zu Monitoringdaten. Priorität: Mittel.
Praktische Einordnung: Scorecard, Gewichtung und Priorisierung
Jede Frage sollte in eine Scorecard überführt werden. Empfohlenes Prinzip:
- Risikokategorie (Vertraulichkeit, Integrität, Verfügbarkeit, Compliance) zuordnen.
- Gewichten nach Geschäftsrelevanz (z. B. personenbezogene Daten höher gewichten).
- Schwellen definieren (z. B. „must have“, „nice to have“), die Vertragsverhandlung triggert.
Beispiel für ein einfacher Scoring‑Ansatz (gewichtet):
// Simple scoring example (pseudo-format for checklist ingestion)
{
"question_id": "q1",
"weight": 10,
"score": 8,
"rationale": "MFA vorhanden, aber keine regelmäßigen Zugriffsreviews"
}
Governance, Rollen und Verantwortlichkeiten
Die technische Bewertung ist nur ein Teil: Entscheidend ist, wer die Verantwortung trägt. Empfohlenes Rollenmodell:
- Beschaffungs‑Lead: Koordiniert RFP, Vertragsfragen und Scoring.
- IT‑Sicherheitsverantwortlicher: Prüft technische Nachweise, bewertet Red‑Flags.
- Compliance/Data Protection Officer: Bewertet DPA, Datenflüsse und rechtliche Risiken.
- Betriebsteam: Bewertet Integrationsaufwand, Monitoring und SLA‑Einhaltung.
Ein klarer Entscheidungsbaum (z. B. „Minor Findings → Remediation Plan; Major Findings → Ausschluss oder Contractual Mitigation“) reduziert Debatten in Gremien.
Vertragsausgestaltung und Auditklauseln — Formulierungsbeispiele
Gute Auditklauseln geben Transparenz und ermöglichen evidenzbasierte Kontrolle. Beispielklausel (Kurzform):
The Vendor shall provide, upon reasonable notice, audit evidence of security controls, including but not limited to: - annual penetration test report (redacted); - quarterly vulnerability scan summaries; - access logs for service accounts for the last 12 months; - evidence of backup restore tests at least annually. Notification: Vendor will notify Customer within 72 hours of any confirmed security incident affecting Customer data.
Hinweis: Klauseln sollten in Zusammenarbeit mit Recht und Datenschutz geprüft werden; Standardformulierungen (z. B. SCC/DPA) sind oft Ausgangspunkt.
Kontinuierliches Monitoring und Audit‑Rhythmus
Eine einmalige Prüfung reicht nicht. Empfohlene Cadence:
- Initiale Due Diligence: vor Vertragsabschluss.
- Follow‑Up Audit: jährlich bei kritischen Anbietern.
- Trigger‑Audits: nach größeren Architekturänderungen, Vorfällen oder bei Wechsel von Subprozessoren.
Technisch sinnvoll ist zudem die Einrichtung von automatisiertem Log‑Forwarding oder API‑Zugriff, damit das eigene SOC KPI‑basierte Überwachung betreiben kann.
Budget, Kosten und Aufwand
Die Tiefe der Prüfung sollte risikobasiert sein. Ein grober Orientierungsrahmen:
- Standard‑SaaS: Dokumenten‑ und Policy‑Review plus Schwachstellenscan (niedrige Kosten).
- Kritische Business‑Software: zusätzlich unabhängiger Pentest, Onsite‑Audit, rechtliche Klauselverhandlung (höhere Kosten).
- Langfristig: Investition in Audit‑Automatisierung (z. B. Fragebogenplattformen, Scoring‑Tools) amortisiert sich durch schnellere Entscheidungen.
Migrations‑ und Exit‑Szenarien: Vorbereitet sein
Vor dem ersten Commit sollten Exit‑Fälle geplant werden: Datenexportformate, Rückgabefristen, Übertragungstools und Post‑Termination‑Support. Schlüsselanforderungen:
- klare Exfiltration‑SLA und technische Exportschnittstelle,
- Nachweis der Datenlöschung bei Provider mit Auditmöglichkeit,
- Übergangsfristen für Support und Datenzugriff.
Praxisvorlage: Kurz‑Checkliste für RFP und Contract‑Review
RFP Security Checklist (short): - IAM: MFA, RBAC, onboarding/offboarding process - Encryption: TLS, at‑rest encryption, KMS details - Vulnerability Management: patch SLA, pentest cadence - Logging/Monitoring: retention, SIEM access, notification SLA - Subprocessors: list + notification procedure - BC/DR: RTO/RPO, restore tests - Contract: audit right, liability, cyber insurance
Approvvigionamento — Entscheidungshilfe, Checklisten und regulatorische Anforderungen
Für die Beschaffungs‑(ital.: Approvvigionamento)Praxis benötigen Einkaufsteams konkrete Entscheidungslogiken, nicht nur Checklisten. Die folgende, pragmatische Matrix hilft, Prüfaufwand zu steuern:
- Risikoklasse: Low / Medium / High — definiert anhand Datentypen (z. B. PII, Zahlungsdaten, Produktionssteuerung), Integrationsgrad und Business‑Kritikalität.
- Erforderliche Nachweise:
- Low: Self‑Assessment + TLS/Posture‑Check.
- Medium: plus ISO27001/SOC2‑Report und quarterly vuln scans.
- High: plus unabhängiger Pentest, Onsite/Remote Auditrechte, jährliche Restore‑Tests.
- Kontrakt‑Logik: Für Medium/High Anbieter Auditklausel und definierte Remediation‑Deadlines verpflichtend machen.
Beispiel: Wenn ein Anbieter High ist und personenbezogene Daten verarbeitet, muss die Beschaffung mindestens SOC2 Type II (oder ISO27001) und einen aktuellen Pentest vorweisen. Fehlen diese Nachweise, ist ein Risikotransfer via Versicherung oder zusätzliche vertragliche Garantien vorzusehen.
Triage‑ und Remediation‑Workflow (operativ)
Praktische Schritte, um Findings in den Betrieb zu überführen:
- Initiale Bewertung durch Security (Severity: Low/Medium/High/Critical).
- Erstellung eines Remediation‑Plans mit Verantwortlichkeit und Deadlines.
- Tracking in Ticketing‑System (z. B. JIRA/ServiceNow) mit SLA‑Feldern.
- Follow‑Up Review nach Fristablauf; bei Nichteinhaltung Eskalation an Legal/Procurement.
Ein exemplarischer JSON‑Block zur Übernahme in Automatisierungstools:
{
"finding_id": "F‑2026‑001",
"severity": "High",
"description": "Privilegierte Accounts ohne MFA",
"owner": "Vendor:security-team@example.com",
"customer_owner": "ITSecurityLead@example.com",
"due_date": "2026-09-30",
"status": "Open"
}
Kurzfristige SLAs und Eskalationszeiten (Praxisvorschlag)
Für Verhandlung und Monitoring empfiehlt sich ein Standardzeitplan:
- Critical Finding: Erstreaktion binnen 24 Stunden, Hotfix/Workaround binnen 72 Stunden.
- High: Remediation‑Plan binnen 7 Tage, Fix binnen 30 Tage.
- Medium/Low: Remediation binnen 90 Tage je nach Einfluss.
Vertraglich sollten Pflichtmeldungen an Kunden innerhalb 72 Stunden nach Bestätigung eines Incidents stehen. Das ermöglicht eigene regulatorische Meldeflüsse (z. B. DSGVO‑Meldungspflichten) rechtzeitig zu starten.
Operative Monitoring‑KPIs und Audit‑Reporting
Pragmatische Metriken, die Sie in die Scorecard aufnehmen sollten:
- MTTD (Mean Time To Detect) — Zielwerte abhängig vom Anbieter‑Risiko.
- MTTR (Mean Time To Recover) — verflochten mit RTO‑Zielen.
- Share kritischer Schwachstellen geschlossen in 30 Tagen.
- Compliance‑Berichts‑Pünktlichkeit (Anteil der Reports, die termingerecht geliefert wurden).
Beispiel‑API‑Abfrage, um Monitoring‑Metriken automatisiert abzuholen (vereinfachtes Beispiel):
curl -s -u api_key:x "https://vendor.example.com/api/monitoring/health" | jq '.metrics | {mttd, mttr, open_critical}'
Zusammenführung und Abschluss
Die Erweiterung der reinen Auditfragen um eine konkrete Approvvigionamento‑Logik macht die Sicherheitsbewertung verwertbar: Einkauf erhält klare Verhandlungshebel, Security handhabbare Remediation‑Fristen, Legal schutzfähige Klauseln und Betrieb transparente Metriken. Implementieren Sie die Scorecard automatisiert, dokumentieren Sie Entscheidungen und legen Sie Eskalationspfade formal fest — so reduzieren Sie Drittanbieterrisiken messbar und schaffen Audit‑gerechte Nachweise.
Weiterführende Schritte
Implementieren Sie die Checkliste in Ihr RFP‑Template, ergänzen Sie eine gewichtete Scorecard und legen Sie Audit‑Rhythmen fest. Bei Bedarf kann eine Initialprüfung durch einen unabhängigen Pentest oder ein Onsite‑Audit die Entscheidungsgrundlage stärken. Die Kombination aus technischen Nachweisen, vertraglichen Verpflichtungen und operationalisierten KPIs macht die Anbieter‑Sicherheitsbewertung zu einem wirksamen Instrument der Risiko‑Governance.
Für dieses Thema sind auch Drittanbieterrisiko und Saas-Sicherheit wichtig. Der Beitrag ordnet diese Aspekte verständlich ein und zeigt, worauf es im Alltag ankommt.