Security-Fragebogen für Dienstleister: Was wirklich geprüft werden sollte

Security-Fragebögen für Dienstleister scheitern oft an zwei Extremen. Entweder sind sie so allgemein, dass fast jede Antwort „ja“ lautet, oder sie enthalten hunderte Fragen ohne Bezug zur eingekauften Leistung. Beides erzeugt Dokumentation, aber wenig Risikoklarheit.

Ein guter Fragebogen beginnt mit Service, Daten, Zugriff und Geschäftsabhängigkeit. Er stellt wenige präzise Fragen, fordert passende Evidenz und ermöglicht eine nachvollziehbare Entscheidung. Die folgende Struktur kann modular verwendet werden: Basisteil für alle relevanten Dienstleister, vertiefende Module für Cloud, Software, privilegierten Zugriff, Kontinuität und kritische Lieferanten.

Vor dem Fragebogen: die interne Nutzung klären

Der Anbieter kann nur sinnvoll antworten, wenn Scope und Einsatz bekannt sind. Dokumentieren Sie Leistung, Nutzer, Datenarten, Integration, Zugriffsrechte, Standorte, Kritikalität und geplante Vertragsdauer. Viele Risiken entstehen durch die eigene Konfiguration und lassen sich nicht aus der allgemeinen Sicherheitslage des Anbieters ableiten.

Benennen Sie internen Service Owner und technische Ansprechpartner. Entscheiden Sie anhand eines Tiering-Modells, welche Module und Nachweise erforderlich sind. Ein Büroservice ohne Datenzugriff braucht keine Cloud-Forensikprüfung; ein privilegierter Managed Service Provider schon.

Antwortformat und Evidenz definieren

Verlangen Sie nicht nur Ja/Nein. Geeignete Felder sind Status, Scope, Verantwortlicher, Nachweis, Datum, bekannte Abweichung und geplante Maßnahme. Der Anbieter sollte „nicht anwendbar“ begründen und Dokumente auf den konkreten Service beziehen.

Akzeptierte Evidenz kann Zertifikat, Auditbericht, Richtlinie, Prozessauszug, technische Dokumentation, Screenshot, Demonstration oder Testprotokoll sein. Sensible Nachweise können in kontrollierter Einsicht geprüft werden. Das Ziel ist ausreichende Sicherheit, nicht das unkritische Sammeln vertraulicher Dokumente.

Modul A: Organisation und Governance

1. Wer trägt die Gesamtverantwortung für Informationssicherheit? Erwartet werden benannte Rolle, Berichtslinie und Vertretung. Warnsignal ist eine ausschließlich technische Zuständigkeit ohne Managementanbindung.
2. Welcher Geltungsbereich des Sicherheitsmanagements umfasst unseren Service? Prüfen Sie Standorte, Plattformen und Teams. Ein Zertifikat außerhalb des gelieferten Dienstes ist kein passender Nachweis.
3. Wie werden Sicherheitsrisiken regelmäßig identifiziert und behandelt? Verlangen Sie Methode, Frequenz, Eigentümer und Beispiel für Maßnahmenverfolgung.
4. Wie werden Richtlinien, Ausnahmen und Risikoakzeptanzen gesteuert? Ausnahmen benötigen Befristung und Genehmigung, nicht nur informelle Duldung.
5. Welche unabhängigen Prüfungen finden statt? Klären Sie Umfang, Frequenz, wesentliche Feststellungen und Umgang mit Abweichungen.

Modul B: Asset- und Konfigurationsmanagement

1. Wie werden Systeme und Komponenten des Services inventarisiert? Der Anbieter sollte Eigentümer, Version und Lebenszyklus kennen.
2. Welche sicheren Basiskonfigurationen gelten? Fragen Sie nach Standard, Abweichungsprozess und technischer Durchsetzung.
3. Wie werden Änderungen geplant, getestet, genehmigt und zurückgenommen? Besonders wichtig sind Notfalländerungen und Trennung von Entwicklung und Produktion.
4. Wie werden nicht mehr unterstützte Komponenten erkannt und ersetzt? Verlangen Sie Lifecycle- und Ausnahmeverfahren.
5. Wie werden Konfigurationsänderungen überwacht? Kritische administrative Änderungen sollten nachvollziehbar sein.

Modul C: Identität und Zugriff

1. Wie werden Nutzer angelegt, geändert und entfernt? Prüfen Sie Genehmigung, Owner und Frist nach Rollenwechsel oder Austritt.
2. Ist Mehrfaktorauthentisierung für privilegierte und externe Zugriffe verpflichtend? Erfragen Sie Faktoren, Ausnahmen und Abdeckung.
3. Wie werden privilegierte Rechte begrenzt und überwacht? Geeignete Nachweise sind PAM-Prozess, zeitliche Rechte und Sitzungsprotokollierung.
4. Werden gemeinsame Konten vermieden und technische Konten verwaltet? Geheimnisse benötigen Rotation, sichere Speicherung und Eigentümer.
5. Wie häufig werden Berechtigungen rezertifiziert? Frequenz richtet sich nach Risiko; Ergebnisse müssen zu Entzug führen.
6. Welche Notfallzugänge existieren? Break-Glass-Konten benötigen starke Kontrolle, Alarmierung und Test.

Modul D: Daten und Kryptografie

1. Welche Kundendaten werden verarbeitet, gespeichert oder übertragen? Antwort muss Datenfluss, Zweck und Standort abdecken.
2. Wie werden Daten klassifiziert und geschützt? Prüfen Sie Zuordnung technischer Kontrollen zur Schutzklasse.
3. Welche Verschlüsselung gilt bei Übertragung und Speicherung? Fragen Sie nach Scope, Protokollen, Ausnahmen und Schlüsselverantwortung.
4. Wie werden kryptografische Schlüssel erzeugt, gespeichert, rotiert und wiederhergestellt? Trennung von Daten- und Schlüsselzugriff ist relevant.
5. Wie werden Datenaufbewahrung und Löschung umgesetzt? Berücksichtigen Sie Backups, Logs und Unterauftragnehmer.
6. Wie werden Datenexport und Rückgabe beim Vertragsende ermöglicht? Format, Frist und Lesbarkeit gehören zur Exit-Fähigkeit.

Modul E: Schwachstellen- und Patchmanagement

1. Welche Quellen und Scans erkennen Schwachstellen? Abdeckung sollte Infrastruktur, Anwendung, Cloud und Komponenten berücksichtigen.
2. Wie werden Schwachstellen risikobasiert priorisiert? CVSS allein reicht nicht; Exposition, Ausnutzbarkeit und Servicekritikalität zählen.
3. Welche Behebungsziele gelten und wie werden Ausnahmen genehmigt? Verlangen Sie Fristen sowie kompensierende Kontrollen.
4. Wie werden aktiv ausgenutzte Schwachstellen behandelt? Notfallprozess und Kundenkommunikation müssen schnell greifen.
5. Wie wird die Wirksamkeit der Behebung bestätigt? Ticketabschluss ohne Retest ist schwach.
6. Wie werden Abhängigkeiten und Open-Source-Komponenten überwacht? Für Softwaredienste sind Komponenteninventar und Updateprozess relevant.

Modul F: Sichere Softwareentwicklung

1. Welche Secure-Development-Anforderungen gelten? Prüfen Sie Schulung, Standards und Verantwortung.
2. Wie werden Sicherheitsanforderungen und Bedrohungen im Design behandelt? Risikoabhängiges Threat Modeling ist ein möglicher Nachweis.
3. Welche Code-, Dependency- und Anwendungstests werden durchgeführt? Fragen Sie nach Abdeckung, Freigabe und Findings.
4. Wie sind Quellcode, Build-Pipeline und Signierschlüssel geschützt? Die Lieferkette muss gegen Manipulation abgesichert sein.
5. Wie werden Schwachstellen von Kunden oder Forschenden entgegengenommen? Verlangen Sie Disclosure-Prozess und Reaktionsweg.
6. Welche SBOM- oder Komponenteninformationen sind verfügbar? Umfang, Format und Aktualisierung sollten zum Produkt passen.

Modul G: Logging, Monitoring und Erkennung

1. Welche sicherheitsrelevanten Ereignisse werden protokolliert? Identität, Administration, Datenzugriff und Konfigurationsänderung sind zentrale Bereiche.
2. Wie lange bleiben Logs verfügbar? Aufbewahrung muss Erkennung, Untersuchung und Anforderungen unterstützen.
3. Wie werden Integrität und Zeitkonsistenz geschützt? Zentrale Sammlung und überwachte Datenlücken erhöhen Aussagekraft.
4. Welche Alarme werden rund um die Uhr bewertet? Erfragen Sie Triage, Eskalation und Reaktionszeit.
5. Welche Logs und Alarme erhält der Kunde? Ein Dienst ohne Kunden-Telemetrie kann Incident Response erheblich einschränken.
6. Wie werden Erkennungsregeln getestet? Übungen oder Simulationen liefern stärkere Evidenz als eine reine Regelanzahl.

Modul H: Incident Response

1. Wie werden Sicherheitsvorfälle klassifiziert und geführt? Rollen, Eskalation und 24/7-Erreichbarkeit sollten klar sein.
2. Wann und über welchen Kanal wird der Kunde informiert? Definieren Sie Trigger, Zeitfenster und Mindestinformationen.
3. Wie werden Beweise gesichert und mit Kunden geteilt? Forensische Fähigkeiten, Integrität und Datenschutz sind relevant.
4. Wie unterstützt der Anbieter Eindämmung und Recovery? Prüfen Sie konkrete Verantwortungsgrenzen.
5. Wie werden Behörden- und Kundenkommunikation abgestimmt? Vertrags- und Rechtsanforderungen dürfen nicht kollidieren.
6. Wie fließen Lessons Learned in Verbesserungen? Verlangen Sie Maßnahmenprozess und Nachverfolgung.

Modul I: Business Continuity und Disaster Recovery

1. Welche kritischen Funktionen und Abhängigkeiten umfasst die BIA? Der konkrete Kundendienst muss erfasst sein.
2. Welche RTO- und RPO-Werte gelten für unseren Service? Definition und Messpunkt müssen verständlich sein.
3. Wie sind Backup und Wiederherstellung geschützt? Trennung, Unveränderbarkeit, Zugriff und Test zählen.
4. Welche Ausfallszenarien wurden getestet? Ergebnisse sollten Hardware-, Cyber-, Standort- und Anbieterabhängigkeit abdecken.
5. Wie wird der Kunde während einer Störung informiert? Notfallkontakt und Update-Rhythmus sind notwendig.
6. Welche manuellen oder alternativen Leistungen existieren? Kapazität und zulässige Dauer müssen realistisch sein.

Modul J: Unterauftragnehmer

1. Welche Unterauftragnehmer unterstützen den Service? Leistung, Standort und Datenzugriff müssen transparent sein.
2. Wie werden Unterauftragnehmer vor Beauftragung geprüft? Anforderungen sollten risikobasiert weitergegeben werden.
3. Wie werden Änderungen angekündigt? Kunde benötigt angemessene Information und gegebenenfalls Widerspruchs- oder Kündigungsrechte.
4. Wie überwacht der Anbieter deren Leistung und Sicherheit? Ein Vertrag in der zweiten Ebene reicht nicht.
5. Welche Konzentrationsrisiken bestehen? Mehrere Unterauftragnehmer können dieselbe Cloud oder Region verwenden.

Modul K: Physische und personelle Sicherheit

1. Wie werden physische Zutritte zu relevanten Standorten kontrolliert? Umfang richtet sich nach Hosting und Daten.
2. Welche Prüfungen und Verpflichtungen gelten für Mitarbeitende? Rechtliche Zulässigkeit und Rollenrisiko sind zu berücksichtigen.
3. Wie werden Sicherheitsbewusstsein und rollenspezifische Kompetenz aufgebaut? Administratoren und Entwickler benötigen vertiefte Inhalte.
4. Wie werden Austritt und Rollenwechsel behandelt? Zugänge, Geräte und Geheimnisse müssen zeitnah angepasst werden.
5. Wie werden Remote-Arbeit und mobile Geräte geschützt? Gerätesicherheit, Datenzugriff und Umgebung sind relevant.

Modul L: Datenschutz und rechtliche Rahmenbedingungen

Datenschutzprüfung sollte durch zuständige Fachrollen erfolgen und nicht unkritisch in Security-Tiering aufgehen. Relevante Fragen betreffen Rollen, Rechtsgrundlage, Auftragsverarbeitung, Betroffenenrechte, internationale Transfers, Löschung und Datenschutzvorfälle.

Security liefert technische Kontrollen und Incident-Fähigkeit. Recht und Datenschutz bewerten Vertrags- und Gesetzesanforderungen. Gemeinsame Findings werden koordiniert, aber ihre fachliche Verantwortung bleibt erkennbar.

Vertiefung für privilegierten Fernzugriff

Fragen Sie nach Aktivierung, Genehmigung, MFA, Gerätevertrauen, Sitzungsaufzeichnung, zeitlicher Begrenzung und Notfallabschaltung. Der Anbieter sollte nur auf erforderliche Systeme und Zeiten zugreifen. Kundenseitiges Monitoring muss möglich sein.

Testen Sie Zugriff und Entzug. Prüfen Sie Konten externer Techniker und Unterauftragnehmer. Ein dauerhaft offener Tunnel ohne individuelle Identität ist ein wesentliches Warnsignal.

Vertiefung für Cloud- und SaaS-Dienste

Klärt Mandantentrennung, Regionen, Control-Plane-Logging, Kundenrollen, Export, Backup, Schlüsseloptionen und Shared Responsibility. Prüfen Sie, welche Funktionen nur in höheren Lizenzstufen verfügbar sind.

Eine allgemeine Cloud-Zertifizierung ersetzt nicht den konkreten Tenant und die eigene Konfiguration. Dokumentieren Sie Kundenpflichten und Abnahme vor Produktivstart.

Vertiefung für Softwareprodukte

Neben Secure Development sind Updatekanal, Signaturprüfung, Komponenten, Supportende und Vulnerability Disclosure relevant. Fragen Sie, wie schnell sicherheitskritische Updates bereitgestellt und Kunden informiert werden.

Bei On-Premises-Produkten muss klar sein, welche Logs, Hardening-Guides und sichere Standardkonfiguration verfügbar sind. Bei Agenten oder Treibern erhöht privilegierter Zugriff die Prüftiefe.

Bewertung: Nicht jede Abweichung ist gleich kritisch

Bewerten Sie Findings nach Servicekritikalität, Daten, Zugriff, Exposition, Ausnutzbarkeit und vorhandener Kompensation. Ein fehlender formaler Nachweis kann niedrig sein, wenn wirksame technische Evidenz besteht. Ein ungeschützter Administratorzugang bleibt hoch, auch wenn viele Richtlinien vorhanden sind.

Trennen Sie inhärentes Risiko, Kontrollreife und Rest-Risiko. Dokumentieren Sie Entscheidung, Maßnahme und Ablaufdatum. Ein Gesamtscore darf kritische K.-o.-Lücken nicht durch viele positive Antworten ausgleichen.

Red Flags für eine vertiefte Prüfung

• Antworten ohne Scope oder Bezug zum konkreten Service
• pauschales „vollständig konform“ ohne Evidenz
• Zertifikat deckt andere Gesellschaft oder Plattform ab
• keine individuelle Identität für privilegierte Zugriffe
• Incident-Meldung erst nach abgeschlossener Untersuchung
• unbekannte Unterauftragnehmer oder Datenstandorte
• Backups teilen dieselbe Administration wie Produktion
• kein getesteter Datenexport oder Exit
• kritische Findings ohne Eigentümer und Frist
• widersprüchliche Aussagen zwischen Fragebogen, Vertrag und Auditbericht

Eine Red Flag führt nicht automatisch zur Ablehnung. Sie löst Nachweis, kompensierende Kontrolle oder formale Risikoentscheidung aus.

Priorisieren Sie Hinweise nach Kritikalität des bezogenen Services und möglicher Auswirkung. Mehrere kleine Widersprüche können gemeinsam auf schwache Governance oder unzuverlässige Auskünfte hindeuten. Die vertiefte Prüfung muss deshalb sowohl den Einzelbefund als auch das Gesamtbild berücksichtigen.

Fragebogen im Lebenszyklus verwenden

Die Erstprüfung wird bei wesentlicher Änderung oder gemäß Tiering aktualisiert. Antworten und Nachweise besitzen Gültigkeitsdatum. Neue Unterauftragnehmer, Daten, Integrationen oder Vorfälle können eine sofortige Neubewertung auslösen.

Verknüpfen Sie Findings mit Vertrag, Onboarding und Monitoring. Der Fragebogen ist kein abgeschlossenes PDF, sondern ein Einstieg in die laufende Steuerung. Beim Exit liefert er Anforderungen für Datenrückgabe und Zugangsentzug.

Fazit: Gute Fragen sind servicebezogen und beweisbar

Ein wirksamer Dienstleisterfragebogen stellt nicht möglichst viele Fragen. Er reduziert konkrete Unsicherheiten über den eingekauften Service, fordert angemessene Evidenz und führt zu einer nachvollziehbaren Risikoentscheidung. Module und Tiering halten den Aufwand proportional.

BlackMount entwickelt im Drittparteienrisikomanagement passende Fragebögen, Nachweiskataloge und Bewertungsmodelle. Dabei werden Security, Kontinuität, Vertrag und technische Integration über den gesamten Anbieterlebenszyklus verbunden.

Verwendete Primärquellen

• NIST SP 800-161 Revision 1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations
• NIST CSF 2.0 Quick Start Guide: Cybersecurity Supply Chain Risk Management
• Richtlinie (EU) 2022/2555 – NIS2
• Verordnung (EU) 2022/2554 – DORA