- Der Auditor prüft nicht nur dein ISMS, sondern auch die Werkzeuge, mit denen du es betreibst. Wo dein Risikoregister liegt, ist eine berechtigte Audit-Frage.
- Cloud-basierte ISMS-Tools erzeugen Subprocessor-Ketten, die du vollständig dokumentieren und bewerten musst. Jeder Subauftragnehmer ist ein potenzielles Risiko.
- Die Auditierbarkeit von SaaS-Lösungen ist eingeschränkt: Du kannst keine eigenen Penetrationstests durchführen, keine Server-Logs einsehen und keine physische Inspektion vornehmen.
- Self-Hosted-Lösungen vereinfachen die Audit-Dokumentation erheblich, weil du die vollständige Kontrolle über Infrastruktur, Zugänge und Datenflüsse hast.
- Bereite dich auf Audit-Fragen zur Datenhaltung vor, indem du Standort, Zugriffsrechte, Backup-Strategie und Subprocessor-Liste deines ISMS-Tools dokumentierst.
Die Frage, die jeder Auditor stellt
Es passiert meistens am zweiten Tag des Zertifizierungsaudits. Der Auditor hat sich durch die Informationssicherheitsrichtlinie gearbeitet, die Risikobewertung geprüft und die Controls im Statement of Applicability durchgesprochen. Dann stellt er eine Frage, die harmlos klingt: "Wo liegt eigentlich Ihr Risikoregister?"
Die Frage zielt nicht auf das Format ab. Ob du dein Risikoregister in Excel, einem spezialisierten Tool oder einer selbstgebauten Anwendung führst, ist dem Auditor erst einmal egal. Was ihn interessiert, ist der physische und rechtliche Speicherort. Liegt das Risikoregister auf einem Server in eurem Serverraum? Auf einem deutschen Cloud-Server? Bei einem US-Anbieter? In einer SaaS-Lösung, deren Infrastruktur über drei Kontinente verteilt ist?
Die Antwort auf diese Frage hat direkte Auswirkungen auf mehrere Controls der ISO 27001. Und die Art, wie du antwortest, verrät dem Auditor mehr über den Reifegrad deines ISMS als jede Richtlinie es könnte.
Warum der Speicherort deines ISMS-Tools relevant ist
Ein ISMS-Tool ist kein gewöhnliches Stück Software. Es enthält eine konzentrierte Sammlung der sensibelsten Informationen deines Unternehmens:
Risikoregister. Eine vollständige Aufstellung aller identifizierten Risiken, ihrer Bewertung und der geplanten Behandlung. Für einen Angreifer ist das eine Einkaufsliste: Welche Schwachstellen kennt das Unternehmen selbst, und welche davon sind noch nicht behandelt?
Audit-Feststellungen. Dokumentierte Abweichungen, Schwachstellen und offene Maßnahmen. Wer Zugriff auf diese Daten hat, weiß genau, wo die Verteidigung dünn ist.
Vorfallberichte. Detaillierte Beschreibungen vergangener Sicherheitsvorfälle, deren Ursachen und der ergriffenen Maßnahmen. In Kombination mit dem Risikoregister ergibt sich ein vollständiges Bild der Sicherheitslage.
Maßnahmenstatus. Welche Controls sind umgesetzt, welche sind geplant, welche haben Defizite? Diese Information ist Gold wert für jeden, der gezielt nach Angriffsvektoren sucht.
Personenbezogene Daten. Namen von Risikoeigentümern, Verantwortlichen für Maßnahmen, Teilnehmern an Schulungen und Audits. Damit fallen ISMS-Daten auch unter die DSGVO.
Der Auditor weiß das. Deshalb behandelt er dein ISMS-Tool nicht als neutrale Software, sondern als einen kritischen Informationswert, der den gleichen Schutzanforderungen unterliegt wie jedes andere Asset mit hohem Schutzbedarf.
Was der Auditor konkret prüft
Die Frage nach dem Speicherort ist nur der Anfang. Ein erfahrener Auditor arbeitet sich systematisch durch mehrere Ebenen:
A.5.23 Cloud-Dienste
Wenn dein ISMS-Tool eine Cloud-Lösung ist, greift Control A.5.23 der ISO 27001:2022. Dieses Control fordert, dass du Prozesse für die Beschaffung, Nutzung, Verwaltung und den Ausstieg aus Cloud-Diensten etablierst. Der Auditor will sehen, dass du den Cloud-Dienst bewusst ausgewählt hast und die damit verbundenen Risiken kennst.
Typische Audit-Fragen:
- Haben Sie eine Risikobewertung für die Nutzung dieses Cloud-Dienstes durchgeführt?
- Welche Datenklassifizierung haben die im Cloud-Dienst gespeicherten Informationen?
- Gibt es eine Exit-Strategie, falls der Anbieter den Dienst einstellt oder die Bedingungen ändert?
- Wie stellen Sie sicher, dass die Verschlüsselung der Daten Ihren Anforderungen entspricht?
A.5.21 Informationssicherheit in der Lieferkette
Jeder Cloud-Anbieter ist ein Glied in deiner Lieferkette. Control A.5.21 fordert, dass du die Risiken in der Lieferkette identifizierst und behandelst. Das bedeutet: Du musst wissen, wer dein ISMS-Tool hostet, wer die Infrastruktur betreibt und welche weiteren Dienstleister involviert sind.
A.8.10 Löschung von Informationen
Wenn du den ISMS-Anbieter wechselst oder das Tool absetzt, musst du sicherstellen, dass deine Daten vollständig gelöscht werden. Bei einer Self-Hosted-Lösung formatierst du die Festplatte. Bei einer SaaS-Lösung vertraust du darauf, dass der Anbieter die Daten aus allen Backups und Replikaten entfernt. Der Auditor will wissen, wie du das verifizierst.
A.5.31 Gesetzliche und regulatorische Anforderungen
Wo deine Daten liegen, bestimmt, welches Recht gilt. Daten in der EU unterliegen der DSGVO. Daten bei einem US-Unternehmen können dem CLOUD Act unterliegen, auch wenn sie physisch in Europa gespeichert sind. Der Auditor prüft, ob du diese rechtlichen Implikationen bewertet und in deiner Risikobewertung berücksichtigt hast.
Das Problem der Subprocessor-Ketten
Hier wird es bei Cloud-basierten ISMS-Tools kompliziert. Kein SaaS-Anbieter betreibt seine Lösung vollständig in Eigenregie. Hinter der Benutzeroberfläche verbirgt sich eine Kette von Unterauftragsverarbeitern (Subprocessors), die jeweils eigene Zugänge, eigene Jurisdiktionen und eigene Sicherheitsniveaus mitbringen.
Ein typisches Szenario für ein Cloud-ISMS-Tool:
| Ebene | Anbieter | Jurisdiktion | Zugriff auf Daten |
|---|---|---|---|
| SaaS-Anbieter | ISMS Tool GmbH | Deutschland | Voll (Klartext) |
| Cloud-Infrastruktur | AWS / Azure / GCP | USA (Mutterkonzern) | Technisch möglich (Infrastruktur-Admin) |
| CDN / DDoS-Schutz | Cloudflare | USA | Traffic-Ebene, potenziell Metadaten |
| E-Mail-Service | SendGrid / Mailgun | USA | E-Mail-Inhalte (Benachrichtigungen) |
| Monitoring | Datadog / New Relic | USA | Logs, Metadaten, potenziell Nutzungsdaten |
| Backup-Storage | Separater Cloud-Provider | Variabel | Vollständige Datenkopie |
| Support-Tool | Zendesk / Intercom | USA | Support-Tickets mit ISMS-Kontext |
Das sind sieben Unternehmen mit potenziellem Zugriff auf Teile deiner ISMS-Daten. Jedes dieser Unternehmen hat eigene Subprocessors. Die Kette kann sich auf 20 bis 30 Unternehmen ausdehnen, bevor du am Ende ankommst.
Der Auditor wird fragen: "Können Sie mir die vollständige Subprocessor-Liste Ihres ISMS-Tools zeigen?" Wenn du diese Frage nicht beantworten kannst, ist das eine Feststellung. Wenn du sie beantworten kannst, aber keine Risikobewertung für die kritischen Subprocessors durchgeführt hast, ist das ebenfalls eine Feststellung.
Die Benachrichtigungsfalle
Die meisten SaaS-Anbieter behalten sich das Recht vor, Subprocessors zu ändern, und informieren ihre Kunden per E-Mail oder über eine Webseite. Du bist vertraglich verpflichtet, diese Änderungen zu überwachen und zu bewerten. In der Praxis geht diese E-Mail im Posteingang unter, und die Risikobewertung wird nie aktualisiert. Der Auditor findet dann eine Subprocessor-Liste vom Vertragsabschluss vor zwei Jahren und eine aktuelle Liste, die drei neue Einträge enthält, für die keine Bewertung existiert.
Auditierbarkeit: SaaS vs. On-Prem
Ein fundamentaler Unterschied zwischen Cloud- und Self-Hosted-Lösungen zeigt sich bei der Frage der Auditierbarkeit. Als Nutzer einer SaaS-Lösung bist du in deinen Prüfmöglichkeiten erheblich eingeschränkt.
Was du bei SaaS nicht kannst
Keine eigenen Penetrationstests. Die allermeisten SaaS-Anbieter verbieten Penetrationstests gegen ihre Infrastruktur. Du kannst einen Pentest-Bericht des Anbieters anfordern, aber du kannst nicht selbst oder durch einen von dir beauftragten Dienstleister testen. Du bist auf die Aussagen des Anbieters angewiesen.
Keine Server-Logs. Du siehst die Anwendungslogs, die der SaaS-Anbieter dir zur Verfügung stellt. Die darunterliegenden Server-Logs, Betriebssystem-Events, Netzwerk-Logs und Infrastruktur-Events bleiben dir verborgen. Wenn es einen Sicherheitsvorfall gibt, bist du auf die Forensik des Anbieters angewiesen.
Keine physische Inspektion. Du kannst nicht in das Rechenzentrum fahren und prüfen, ob die physische Sicherheit deinen Anforderungen entspricht. Du verlässt dich auf Zertifikate und Audit-Berichte des Rechenzentrumsbetreibers.
Keine unabhängige Backup-Verifizierung. Du kannst nicht prüfen, ob die Backups deiner Daten tatsächlich funktionieren, ob sie verschlüsselt sind und ob sie an dem Ort liegen, den der Anbieter angibt. Du vertraust auf die Angaben in der Dokumentation.
Kein Zugriff auf die Konfiguration. Du kannst die Datenbank-Konfiguration, die Webserver-Einstellungen, die Firewall-Regeln und die Verschlüsselungsparameter nicht einsehen. Die gesamte Infrastruktur-Ebene ist eine Blackbox.
Was du bei Self-Hosted kannst
Bei einer Self-Hosted-Lösung drehst du das Verhältnis um. Du hast vollständigen Zugriff auf:
- Server-Logs auf allen Ebenen (Anwendung, Betriebssystem, Netzwerk)
- Datenbank-Inhalte und -Konfiguration
- Backup-Dateien und deren Verifizierung
- Netzwerk-Konfiguration und Firewall-Regeln
- Verschlüsselungskonfiguration und Zertifikatsmanagement
- Physischen Standort der Hardware
Das bedeutet nicht, dass Self-Hosted automatisch sicherer ist. Es bedeutet, dass du die Sicherheit selbst verantworten und gegenüber dem Auditor nachweisen kannst, statt auf die Aussagen Dritter angewiesen zu sein.
Praxisbeispiel: Zwei Unternehmen im Audit
Zwei mittelständische Unternehmen mit jeweils circa 120 Mitarbeitern stehen im Zertifizierungsaudit. Beide haben ein funktionierendes ISMS aufgebaut. Beide haben dieselbe Auditorin. Aber die Datenhaltung ihrer ISMS-Tools unterscheidet sich grundlegend.
Unternehmen A: Cloud-basiertes ISMS-Tool
Die Auditorin fragt: "Wo liegt Ihr Risikoregister?"
Der ISB antwortet: "Wir nutzen ein Cloud-basiertes ISMS-Tool. Die Daten liegen bei einem deutschen SaaS-Anbieter."
Die Auditorin hakt nach: "Wo genau hostet der Anbieter die Daten?"
"Bei AWS in Frankfurt."
"Hat AWS als US-Unternehmen potenziell Zugriff auf die Daten unter dem CLOUD Act?"
"Das müsste ich prüfen."
"Haben Sie eine Auftragsverarbeitungsvereinbarung mit dem SaaS-Anbieter?"
"Ja, die ist beim Vertragsabschluss unterschrieben worden."
"Haben Sie die Subprocessor-Liste geprüft und die Risiken bewertet?"
Stille.
"Haben Sie eine Exit-Strategie dokumentiert für den Fall, dass der Anbieter den Dienst einstellt?"
"Wir könnten die Daten als CSV exportieren."
"Haben Sie das getestet? Sind alle Daten exportierbar, einschließlich Dateianhänge, Versionierungen und Beziehungen zwischen Datensätzen?"
Weitere Stille.
Die Auditorin notiert drei Beobachtungen: unvollständige Risikobewertung des Cloud-Dienstes, fehlende Subprocessor-Bewertung und nicht getestete Exit-Strategie. Keine davon ist eine Major Nonconformity, aber in der Summe zeigen sie, dass die Datenhaltung des ISMS-Tools nicht mit derselben Sorgfalt behandelt wurde wie die übrigen ISMS-Prozesse.
Unternehmen B: Self-Hosted ISMS-Tool
Dieselbe Frage: "Wo liegt Ihr Risikoregister?"
Die ISB antwortet: "Auf unserem eigenen Server im Serverraum am Standort Karlsruhe. Das ISMS-Tool läuft als Docker-Container auf einem dedizierten Server, der ausschließlich für das ISMS genutzt wird."
"Wer hat Zugriff auf den Server?"
"Drei Personen aus der IT-Abteilung, plus ich als ISB für die Anwendungsebene. Die Zugänge sind per SSH-Key und MFA abgesichert. Hier ist die Zugriffsmatrix."
"Wie sieht die Backup-Strategie aus?"
"Tägliches Datenbank-Backup, verschlüsselt, auf einen separaten Server am zweiten Standort. Monatlicher Restore-Test, der letzte war vor drei Wochen erfolgreich. Hier ist das Protokoll."
"Welche Subprocessors sind involviert?"
"Keine. Die gesamte Infrastruktur steht bei uns. Die Software-Updates laden wir vom Hersteller herunter und spielen sie nach Prüfung in einer Staging-Umgebung ein."
Die Auditorin notiert: vollständige Kontrolle über die Datenhaltung, dokumentierte Zugriffskontrolle, getestete Backup-Strategie. Keine Feststellungen in diesem Bereich.
Der Unterschied ist nicht, dass Unternehmen A schlechte Arbeit geleistet hat. Der Unterschied ist, dass Unternehmen B die Fragen sofort und vollständig beantworten konnte, weil es die Kontrolle über die gesamte Kette hat. In ISMS Lite läuft genau dieses Modell: Das Tool steht auf deiner eigenen Infrastruktur, und du kannst dem Auditor jeden Layer selbst zeigen, vom Server bis zur Anwendung.
Checkliste: Audit-Vorbereitung Datenhaltung
Unabhängig davon, ob du ein Cloud- oder Self-Hosted-ISMS-Tool nutzt, solltest du diese Fragen vor dem Audit beantworten können:
Standort und Jurisdiktion
- In welchem Land und Rechenzentrum liegen die ISMS-Daten?
- Welcher Rechtsordnung unterliegen die Daten (DSGVO, CLOUD Act, andere)?
- Gibt es eine Risikobewertung für den Standort und die Jurisdiktion?
- Sind die TOMs des Rechenzentrums dokumentiert und bewertet?
Zugriffskontrolle
- Wer hat Zugriff auf die ISMS-Daten (intern und extern)?
- Sind die Zugänge nach dem Least-Privilege-Prinzip vergeben?
- Gibt es ein Berechtigungskonzept für das ISMS-Tool?
- Werden Zugriffe protokolliert und regelmäßig überprüft?
Subprocessor-Management (bei Cloud-Lösungen)
- Liegt eine aktuelle Subprocessor-Liste vor?
- Wurde für jeden kritischen Subprocessor eine Risikobewertung durchgeführt?
- Gibt es einen Prozess zur Überwachung von Subprocessor-Änderungen?
- Sind die AVVs der Subprocessors geprüft und dokumentiert?
Backup und Wiederherstellung
- Wie oft werden Backups erstellt und wo werden sie gespeichert?
- Sind die Backups verschlüsselt?
- Wurde ein Restore-Test durchgeführt und protokolliert?
- Wie lang sind RPO und RTO für das ISMS-Tool?
Exit-Strategie
- Können alle Daten vollständig exportiert werden?
- Wurde der Export getestet und dokumentiert?
- Gibt es einen Migrationsplan für den Anbieterwechsel?
- Ist die Löschung der Daten beim bisherigen Anbieter vertraglich geregelt?
Verschlüsselung
- Sind die Daten at rest verschlüsselt?
- Sind die Daten in transit verschlüsselt?
- Wer verwaltet die Verschlüsselungsschlüssel?
- Gibt es ein dokumentiertes Schlüsselmanagement?
Häufige Fehler bei der Audit-Vorbereitung
Fehler 1: Das ISMS-Tool aus der Risikobewertung ausklammern. Viele Unternehmen bewerten die Risiken für ihre Geschäftsanwendungen sorgfältig, vergessen aber, dass das ISMS-Tool selbst ein Informationswert mit hohem Schutzbedarf ist. Es gehört ins Asset-Management und in die Risikobewertung.
Fehler 2: Zertifikate des Anbieters als ausreichend betrachten. Dass dein SaaS-Anbieter ISO-27001-zertifiziert ist, entbindet dich nicht von der Pflicht, deine eigene Risikobewertung durchzuführen. Das Zertifikat des Anbieters ist ein Datenpunkt, kein Freifahrtschein. Der Auditor wird prüfen, ob du den Geltungsbereich der Zertifizierung des Anbieters kennst und ob er die für dich relevanten Bereiche abdeckt.
Fehler 3: Die Exit-Strategie als theoretisch abtun. "Wir wechseln ja nicht den Anbieter" ist keine akzeptable Antwort. ISO 27001 fordert die Planung für den Fall, dass ein Dienst nicht mehr verfügbar ist. Das schließt den Fall ein, dass der SaaS-Anbieter den Dienst einstellt, die Preise verdreifacht oder die Vertragsbedingungen in einer Weise ändert, die für dich nicht mehr akzeptabel ist. In deiner Business Impact Analyse sollte das ISMS-Tool als geschäftskritischer Prozess berücksichtigt sein.
Fehler 4: Subprocessor-Änderungen ignorieren. SaaS-Anbieter ändern ihre Subprocessor-Listen regelmäßig. Wenn du die Änderungsbenachrichtigungen nicht aktiv verfolgst und bewertest, häuft sich ein Compliance-Rückstand an, den der Auditor aufdecken wird.
Fehler 5: Backup-Verantwortung beim Anbieter vermuten. Bei SaaS-Lösungen ist häufig unklar, welche Backup-Garantien tatsächlich bestehen. "Wir machen Backups" reicht nicht. Du brauchst konkrete Angaben zu Frequenz, Aufbewahrungsdauer, Verschlüsselung und Restore-Fähigkeit. Und du musst prüfen, ob ein Restore wirklich funktioniert.
Was der Auditor am Ende sehen will
Der Auditor will im Kern eine Sache sehen: dass du dein ISMS-Tool mit derselben Sorgfalt behandelst wie jedes andere kritische System. Das bedeutet:
Eine dokumentierte Schutzbedarfsfeststellung für die ISMS-Daten. In der Regel wird der Schutzbedarf für Vertraulichkeit und Integrität als hoch eingestuft, weil die Daten die gesamte Sicherheitslage des Unternehmens offenlegen.
Eine Risikobewertung, die den Speicherort, die Zugriffskontrolle, die Subprocessor-Kette und die Verfügbarkeit des Tools berücksichtigt. Nicht als Einmalübung beim Vertragsabschluss, sondern als regelmäßig aktualisierte Bewertung.
Nachweise, dass die identifizierten Risiken behandelt werden. Wenn du weißt, dass dein SaaS-Anbieter Subprocessors in den USA nutzt, dann musst du auch dokumentieren, wie du das Risiko des Drittlandtransfers behandelst: Akzeptanz mit Begründung, Standardvertragsklauseln, zusätzliche technische Maßnahmen oder ein Wechsel zu einem Anbieter ohne US-Subprocessors.
Einen getesteten Plan für den Fall, dass das Tool nicht mehr verfügbar ist. Das kann ein Restore aus dem Backup auf eigener Infrastruktur sein, ein Export in ein alternatives Format oder ein dokumentierter Migrationspfad zu einem anderen Tool.
Der Kontrollverlust-Faktor
Die Audit-Thematik zeigt ein grundsätzliches Muster: Je mehr Kontrolle du über die Datenhaltung deines ISMS-Tools abgibst, desto mehr Dokumentations- und Nachweisaufwand entsteht. Nicht weil Cloud-Lösungen per se unsicher sind, sondern weil du für jeden Aspekt, den du nicht selbst kontrollierst, auf die Aussagen und Nachweise Dritter angewiesen bist.
Bei einer Self-Hosted-Lösung dokumentierst du, was du selbst siehst und konfigurierst. Bei einer Cloud-Lösung dokumentierst du, was der Anbieter dir sagt. Der Auditor weiß den Unterschied zu schätzen.
Das heißt nicht, dass Cloud-Lösungen im Audit automatisch durchfallen. Es heißt, dass du bei Cloud-Lösungen mehr Arbeit in die Dokumentation und Risikobewertung investieren musst, um das gleiche Ergebnis zu erzielen. Bei einem internen Audit solltest du die Datenhaltung des ISMS-Tools als eigenen Prüfpunkt aufnehmen, bevor der externe Auditor danach fragt.
Für Unternehmen, die den Aufwand minimieren und dem Auditor klare, selbst verifizierbare Antworten geben wollen, ist die Self-Hosted-Variante der kürzeste Weg. Du zeigst auf deinen Server, öffnest die Konfiguration und sagst: "Hier liegen die Daten, so sind sie geschützt, und hier ist der Nachweis." Kein Verweis auf Drittberichte, keine Subprocessor-Listen, keine Vertrauensketten.
ISMS Lite verfolgt genau diesen Ansatz: eine Self-Hosted-Lösung, die auf deiner eigenen Infrastruktur läuft und dir die vollständige Kontrolle über deine ISMS-Daten gibt. Das vereinfacht nicht nur das Audit, sondern auch den täglichen Betrieb, weil du nicht ständig prüfen musst, ob sich in der Lieferkette deines Tool-Anbieters etwas geändert hat.