Welche Sicherheitsnachweise sollte man von IT-Dienstleistern verlangen?
Dieser Text wurde mit künstlicher Intelligenz (KI) erstellt.
Das Wichtigste in Kürze
Verlangen Sie Nachweise risikobasiert und dienstbezogen. Mehr Dokumente bedeuten nicht automatisch bessere Evidenz.
Prüfen Sie bei jedem Nachweis Geltungsbereich, Organisation, Dienst, Zeitraum, Ausnahmen und ausstellende beziehungsweise prüfende Stelle.
ISO/IEC 27001, SOC-Berichte und BSI C5 beantworten unterschiedliche Fragen und sind nicht ohne Kontext austauschbar.
Technische Tests, Richtlinien, Vorfallprozesse und BCM-Evidenz ergänzen formale Nachweise, wenn sie zum Risiko passen.
Schützen Sie vertrauliche Berichte und dokumentieren Sie, welche offenen Punkte oder Kundenkontrollen verbleiben.
Nachweise müssen zur Entscheidung passen
Sicherheitsnachweise helfen, Aussagen eines IT-Dienstleisters zu prüfen. Sie unterscheiden sich jedoch deutlich in Gegenstand, Tiefe und Aktualität. Ein Zertifikat bewertet ein Managementsystem in einem definierten Scope. Ein Prüfbericht kann Kontrolldesign und Wirksamkeit für einen Zeitraum untersuchen. Eine Pentest-Zusammenfassung betrachtet einen technischen Prüfbereich.
Es gibt keinen universellen Pflichtkatalog für jede Dienstleistung. Die Auswahl folgt Leistung, Kritikalität, Datenzugriff und möglicher Auswirkung. Dieser Artikel hilft bei Anforderung und Auswertung der Nachweise. Er ersetzt keine rechtliche oder datenschutzrechtliche Prüfung.
Nachweise aus Risiko und Leistung ableiten
Beginnen Sie mit dem konkreten Dienst. Welche Daten verarbeitet der Anbieter? Erhält er administrative Rechte? Entwickelt er Software, betreibt er Infrastruktur oder stellt er einen standardisierten Cloud-Dienst bereit? Welche Geschäftsprozesse wären bei einem Ausfall betroffen? Diese Fragen bestimmen, welche Aussage belegt werden muss.
Ordnen Sie jede Anforderung einem Risiko zu. Für privilegierten Support sind Zugriffsfreigabe, starke Authentisierung, Protokollierung und Entzug von Rechten relevant. Bei Softwareentwicklung interessieren Entwicklungsprozess, Abhängigkeitsmanagement und Behandlung von Schwachstellen. Für einen Cloud-Dienst können Mandantentrennung, Verschlüsselung, Verfügbarkeit und Steuerung von Unterauftragnehmern im Vordergrund stehen.
NIST SP 1326 beschreibt Due Diligence als Recherche verfügbarer, relevanter Informationen über Lieferanten oder Produkte, damit Entscheidungen auf einer ausreichenden Grundlage getroffen werden können. Der Leitfaden ist auf IKT-Lieferanten zugeschnitten und nennt unter anderem Resilienz, grundlegende Cyberpraktiken und Lieferkettenebenen. Er liefert keinen universellen deutschen Nachweiskatalog, unterstützt aber den risikobasierten Aufbau.
Definieren Sie vor der Anfrage, welches Dokument, welche Zusammenfassung oder welche Bestätigung akzeptiert wird. Manche Berichte dürfen nur unter Vertraulichkeitsvereinbarung eingesehen werden. In anderen Fällen kann eine angemessen detaillierte Managementzusammenfassung genügen. Wird ein Nachweis nicht bereitgestellt, sollte der Anbieter alternative Evidenz erklären können.
ISO/IEC 27001: Zertifikat und Scope prüfen
ISO/IEC 27001:2022 definiert Anforderungen an ein Informationssicherheits-Managementsystem. Eine Zertifizierung zeigt, dass das ISMS im angegebenen Geltungsbereich gegen die Norm geprüft wurde. Sie bestätigt nicht automatisch jede technische Einzelkontrolle und nicht jede Leistung des Unternehmens.
Prüfen Sie den Namen der zertifizierten Organisation, Standorte, Tätigkeiten, Gültigkeitszeitraum und Zertifizierungsstelle. Entscheidend ist die Scope-Beschreibung: Erfasst sie den Dienst, die Betriebsumgebung und die Gesellschaft, mit der Sie den Vertrag schließen? Ein sehr allgemeiner Scope verlangt Rückfragen. Ein Zertifikat für die Konzernzentrale kann einen getrennt betriebenen Dienst einer Tochtergesellschaft ausschließen.
Fragen Sie bei kritischen Leistungen nach der Statement of Applicability oder einer geeigneten Zusammenfassung, soweit der Anbieter sie freigeben kann. Dieses Dokument zeigt, welche Kontrollen im ISMS ausgewählt oder ausgeschlossen wurden und wie Ausschlüsse begründet sind. Die konkrete Aussage muss mit dem Scope und dem bezogenen Dienst verbunden werden.
Beachten Sie auch Aktualität und Änderungen. Ein gültiges Zertifikat kann aus einer Prüfung stammen, die vor einer größeren Akquisition oder Produktumstellung stattfand. Klären Sie wesentliche Änderungen und offene Feststellungen in einem Lieferantengespräch. Die Zertifizierung bleibt wichtige Evidenz, aber keine automatische Freigabe.
SOC-Berichte und BSI C5 im passenden Kontext nutzen
SOC-Berichte stammen aus dem US-amerikanischen Prüfungsrahmen der AICPA. SOC 1 adressiert Kontrollen, die für die interne Finanzberichterstattung der Nutzerorganisation relevant sind. SOC 2 betrachtet Kontrollen einer Serviceorganisation in Bezug auf Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit oder Datenschutz. Für eine allgemeine Sicherheitsprüfung ist daher nicht jeder SOC-Bericht gleich geeignet.
Prüfen Sie bei SOC 2 die Systembeschreibung, einbezogenen Trust Services Criteria, Zeitraum, Prüfungsergebnis, Ausnahmen und Complementary User Entity Controls. Diese Kundenkontrollen muss die nutzende Organisation selbst umsetzen, damit die betrachteten Kontrollziele erreicht werden. Ein Bericht mit gutem Ergebnis kann seine Aussage verlieren, wenn der Kunde die vorausgesetzte sichere Konfiguration nicht umsetzt.
Der Cloud Computing Compliance Criteria Catalogue C5 des BSI ist auf die Informationssicherheit von Cloud-Diensten ausgerichtet. Das BSI stellt klar, dass eine C5-Testierung durch externe Prüfer erfolgt und keine Zertifizierung des BSI ist. Prüfen Sie deshalb Bericht, Prüfgegenstand und Nutzungshinweise. Ein C5-Bericht ist vor allem dann relevant, wenn der bezogene Cloud-Dienst im Scope liegt.
C5 unterscheidet Typ-1- und Typ-2-Berichterstattung. Laut BSI bewertet Typ 1 die Beschreibung sowie Ausgestaltung und Implementierung der Kontrollen zu einem Zeitpunkt. Typ 2 umfasst zusätzlich Prüfhandlungen zur Wirksamkeit über einen Zeitraum. Das BSI sieht Typ 2 für eine angemessene Aussagekraft als erforderlich an; besondere Konstellationen können dennoch eine Typ-1-Berichterstattung erklären.
Umsetzung einer konkreten organisatorischen Kontrolle
Verantwortung, Stichprobe, Aktualität, Bezug zur Leistung
Technische und operative Nachweise ergänzen
Ein Penetrationstest untersucht einen vereinbarten technischen Scope mit menschlicher Expertise. Fordern Sie nicht zwingend den vollständigen Rohbericht. Eine Zusammenfassung kann Datum, Methodik, getestete Systeme, ausgeschlossene Bereiche, Befunde nach Schwere, offene Risiken und Status der Nachprüfung enthalten. Ein Test ohne klaren Scope oder Retest sagt wenig über den aktuellen Zustand des bezogenen Dienstes.
Für Schwachstellenmanagement sind Prozessbeschreibung, Zuständigkeit, Quellen, Priorisierungslogik und Nachweise geschlossener Befunde relevant. Konkrete interne Scanergebnisse können hochsensibel sein. Vereinbaren Sie deshalb eine Form, die ausreichende Evidenz liefert und keine unnötige Angriffsfläche durch Dokumentenverteilung schafft. Eine externe IT-Risikoanalyse kann ergänzend aktuelle erreichbare Systeme und sichtbare Merkmale prüfen.
Beim Incident Management sind Meldeweg, Erreichbarkeit, Klassifizierung, Untersuchung, Kundeninformation und Nachbereitung prüfbar. Geeignete Nachweise können eine Prozessbeschreibung, ein Übungsprotokoll oder eine anonymisierte Fallzusammenfassung sein. Verlangen Sie keine echten personenbezogenen oder kundenbezogenen Vorfalldaten, wenn diese für Ihre Entscheidung nicht erforderlich sind.
Für Business Continuity und Wiederanlauf zählen definierte Verantwortlichkeiten, Abhängigkeiten, Wiederanlaufziele und Tests. Eine Richtlinie belegt die Vorgabe; ein aktuelles Testprotokoll zeigt, ob ein Szenario geübt und ausgewertet wurde. Prüfen Sie, ob das getestete Szenario den bezogenen Dienst und wesentliche Unterauftragnehmer einschließt.
Aktualität, Ausnahmen und Vertraulichkeit bewerten
Jeder Nachweis braucht einen Datenstand. Legen Sie je Risikoklasse fest, wie alt Dokumente sein dürfen und welche Ereignisse eine neue Prüfung auslösen. Wesentliche Produktänderungen, ein Sicherheitsvorfall, ein Wechsel kritischer Unterauftragnehmer oder eine neue Betriebsregion können einen formal gültigen Nachweis ergänzungsbedürftig machen.
Lesen Sie Ausnahmen und Einschränkungen. Ein Prüfbericht kann Kontrollen mit Feststellungen enthalten, einen kurzen Prüfzeitraum abdecken oder Teile der Leistung ausschließen. Fragen Sie nach Managementreaktion, Behandlungsstatus und kompensierenden Maßnahmen. Eine Feststellung ist kein automatischer Ablehnungsgrund; ihre Bedeutung hängt von Risiko und Behandlung ab.
Behandeln Sie sensible Berichte nach einem Need-to-know-Prinzip. Nutzen Sie geschützte Übertragung, rollenbasierten Zugriff, eine definierte Aufbewahrung und geregelte Löschung. Speichern Sie in der Lieferantenakte nach Möglichkeit Bewertung und Verweis, ohne unnötige Kopien zu erzeugen. Vertragliche Vertraulichkeitsregeln sind zu beachten.
Datenschutz bleibt ein eigener Prüfbereich. Wenn ein Dienstleister personenbezogene Daten im Auftrag verarbeitet, sind Rollen, Vertrag und Anforderungen nach anwendbarem Datenschutzrecht gesondert zu prüfen. Ein ISO-Zertifikat, SOC-Bericht oder C5-Testat ersetzt diese Prüfung nicht. Ebenso beweist eine Datenschutzvereinbarung nicht die Wirksamkeit aller Sicherheitskontrollen.
Aus Nachweisen eine dokumentierte Entscheidung ableiten
Erstellen Sie keine reine Dokumenten-Checkliste. Führen Sie je Risiko die Aussage des Dienstleisters, den passenden Nachweis, dessen Grenzen und offene Fragen zusammen. Bewerten Sie Evidenz nach Relevanz, Herkunft, Aktualität und Prüftiefe. Mehrere schwache Dokumente ergeben nicht automatisch eine starke Aussage.
Der Dienstleister sollte Abweichungen erklären und alternative Evidenz anbieten können. Ein kleiner Anbieter besitzt möglicherweise keinen SOC- oder C5-Bericht, kann aber gezielte Prozess- und Testnachweise liefern. Die Entscheidung richtet sich nach Risiko und nicht nach Unternehmensgröße oder Bekanntheit. Für kritische Leistungen kann das Fehlen unabhängiger Evidenz dennoch zusätzliche Prüfung erfordern.
Dokumentieren Sie akzeptierte Nachweise, Datenstand, Feststellungen, Maßnahmen, Fristen und Restrisiko. Verknüpfen Sie Ablaufdaten mit Wiedervorlagen. Bei laufenden Leistungen können externe Signale eine frühere Prüfung auslösen. Das Security Rating liefert hierfür eine zusätzliche Außensicht, ersetzt aber keine Nachweisbewertung.
LocateRisk unterstützt die technische Perspektive auf identifizierte beziehungsweise erreichbare Systeme und deren Veränderungen. Für die organisatorische Evidenz bleiben Dokumente, Interviews und interne Prüfung erforderlich. Hinweise zur Einbindung in das Lieferantenportfolio finden Sie beim Vendor Risk Management.
Das hängt von Leistung und Risiko ab. Mögliche Nachweise sind ISO/IEC-27001-Zertifikate, SOC- oder C5-Berichte, Pentest-Zusammenfassungen, Richtlinien, Prozessnachweise sowie Evidenz zu Vorfallmanagement und Wiederanlauf. Jeder Nachweis muss den bezogenen Dienst in einem geeigneten Scope abdecken.
Prüfen Sie zertifizierte Organisation, Standorte, Tätigkeiten, Gültigkeit und Zertifizierungsstelle. Der Geltungsbereich muss den bezogenen Dienst und die relevante Betriebsumgebung erfassen.
Nein. Das BSI stellt klar, dass C5-Testierungen von externen Prüfern durchgeführt werden und keine BSI-Zertifizierung sind. Entscheidend sind der konkrete Bericht, sein Prüfgegenstand und die Feststellungen.
Nicht zwingend. Je nach Risiko kann eine geschützte, ausreichend detaillierte Zusammenfassung mit Scope, Datum, Methodik, Befunden, offenen Risiken und Retest-Status genügen. Vertraulichkeit und Entscheidungsbedarf müssen austariert werden.
Nein. Datenschutzrollen, vertragliche Anforderungen und die konkrete Verarbeitung personenbezogener Daten sind gesondert zu prüfen. Sicherheitsnachweise können technische und organisatorische Aspekte belegen, ersetzen aber keine rechtliche Einordnung.
We use cookies to optimize our website and our service.
Functional
Immer aktiv
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistics
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.
Deutsch 
English 
Français