DSGVO-konformes ISMS-Hosting: Anforderungen an die Datenhaltung deiner Compliance-Daten

Dein ISMS-Tool fällt unter die DSGVO

Wenn du ein ISMS aufbaust, denkst du an Risiken, Controls und Audits. An die DSGVO denkst du dabei vielleicht im Kontext der Verarbeitung von Kundendaten oder Mitarbeiterdaten. Aber es gibt eine Stelle, an der Datenschutz und Informationssicherheit direkt aufeinandertreffen: dein ISMS-Tool selbst.

Ein ISMS-Tool verarbeitet personenbezogene Daten. Nicht massenhaft, aber systematisch und über die gesamte Nutzungsdauer hinweg. Sobald du personenbezogene Daten verarbeitest, gelten die Regeln der DSGVO. Und bei einem ISMS-Tool, das in der Cloud läuft, wird es besonders interessant, weil sich zusätzliche Anforderungen an die Auftragsverarbeitung, den Drittlandtransfer und die technischen Schutzmaßnahmen ergeben.

Welche personenbezogenen Daten enthält ein ISMS?

Ein Blick in ein typisches ISMS-Tool zeigt schnell, dass personenbezogene Daten an vielen Stellen verarbeitet werden:

Das sind keine abstrakten Kategorien. Das sind reale Daten realer Mitarbeiter. Der Name des ISB, der eine Risikobewertung erstellt hat. Die E-Mail-Adresse der Abteilungsleiterin, die als Risikoeigentümerin eingetragen ist. Der Zeitstempel, wann der IT-Administrator die letzte Maßnahme als erledigt markiert hat.

Art. 32 DSGVO: Technische und organisatorische Maßnahmen

Art. 32 DSGVO verlangt, dass du "unter Berücksichtigung des Stands der Technik, der Implementierungskosten und der Art, des Umfangs, der Umstände und der Zwecke der Verarbeitung sowie der unterschiedlichen Eintrittswahrscheinlichkeit und Schwere des Risikos für die Rechte und Freiheiten natürlicher Personen" geeignete technische und organisatorische Maßnahmen triffst.

Für ein ISMS-Tool bedeutet das konkret:

Verschlüsselung (Art. 32 Abs. 1 lit. a)

Verschlüsselung in Transit. Jede Verbindung zum ISMS-Tool muss per TLS verschlüsselt sein. Das gilt sowohl für den Zugriff über den Browser als auch für API-Verbindungen. Bei einem Self-Hosted-Setup konfigurierst du das über den Reverse Proxy mit einem gültigen Zertifikat. Bei Cloud-Lösungen ist das in der Regel Standard, aber prüfe, ob auch interne Verbindungen zwischen den Diensten des Anbieters verschlüsselt sind.

Verschlüsselung at Rest. Die Daten auf der Festplatte sollten verschlüsselt sein. Bei Self-Hosted reicht LUKS (Linux) oder BitLocker (Windows) auf dem Server. Bei Cloud-Lösungen frage nach, ob die Datenbank verschlüsselt ist und wer die Schlüssel verwaltet. Wenn der Cloud-Anbieter die Schlüssel kontrolliert, hat er technisch die Möglichkeit, die Daten zu entschlüsseln.

Zugangs- und Zugriffskontrolle (Art. 32 Abs. 1 lit. b)

• MFA für alle Benutzerkonten
• Rollenbasiertes Berechtigungskonzept (ISB sieht alles, Abteilungsleiter nur eigene Risiken)
• Automatische Sitzungstimeouts
• Protokollierung aller Zugriffe und Änderungen
• User-Lifecycle-Management: Zugänge deaktivieren, wenn Mitarbeiter das Unternehmen verlassen

Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b)

• Regelmäßige, getestete Backups
• Dokumentiertes Restore-Verfahren
• Monitoring der Systemverfügbarkeit

Regelmäßige Überprüfung (Art. 32 Abs. 1 lit. d)

Art. 32 fordert ein "Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen". Für ein ISMS-Tool bedeutet das: Die TOMs müssen nicht nur existieren, sie müssen regelmäßig geprüft werden. Sind die Passwortrichtlinien noch aktuell? Funktioniert MFA? Wurde das letzte Backup-Restore getestet?

Art. 28 DSGVO: Auftragsverarbeitung

Hier wird es für Cloud-basierte ISMS-Tools relevant. Wenn du ein ISMS-Tool als SaaS nutzt, verarbeitet der Anbieter personenbezogene Daten in deinem Auftrag. Das ist eine Auftragsverarbeitung im Sinne von Art. 28 DSGVO, und du brauchst eine Auftragsverarbeitungsvereinbarung (AVV).

Was die AVV enthalten muss

Art. 28 Abs. 3 DSGVO listet die Pflichtinhalte einer AVV auf:

• Gegenstand und Dauer der Verarbeitung
• Art und Zweck der Verarbeitung
• Art der personenbezogenen Daten und Kategorien betroffener Personen
• Pflichten und Rechte des Verantwortlichen
• Weisungsgebundenheit des Auftragsverarbeiters
• Vertraulichkeitsverpflichtung der Mitarbeiter des Auftragsverarbeiters
• TOMs des Auftragsverarbeiters (Art. 32)
• Bedingungen für die Hinzuziehung weiterer Auftragsverarbeiter (Subprocessors)
• Unterstützung bei Betroffenenrechten (Auskunft, Löschung, Berichtigung)
• Unterstützung bei DSFA und Meldepflichten
• Löschung oder Rückgabe der Daten nach Beendigung
• Nachweismöglichkeiten und Inspektionen (Auditrecht)

AVV-Prüfung in der Praxis

Die meisten SaaS-Anbieter liefern eine Standard-AVV mit, die du beim Vertragsabschluss akzeptierst. Das Problem: Diese Standard-AVVs sind häufig zugunsten des Anbieters formuliert und enthalten Lücken, die du erkennen musst.

Typische Schwachstellen in Standard-AVVs:

Eingeschränktes Auditrecht. Die AVV gewährt dir das Recht auf "Inspektionen", definiert aber, dass der Anbieter stattdessen auch einen SOC-2-Bericht oder ein ISO-27001-Zertifikat vorlegen kann. Das ist nicht dasselbe wie ein eigenes Auditrecht, und die Lieferantenbewertung wird dadurch erschwert.

Pauschale Genehmigung für Subprocessors. Die AVV erlaubt dem Anbieter, Subprocessors hinzuzufügen, und du wirst lediglich informiert. Du hast ein Einspruchsrecht, aber wenn du einsprichst, kann der Anbieter den Vertrag kündigen. Faktisch hast du also keine echte Wahlmöglichkeit.

Unklare Löschfristen. Die AVV verspricht die Löschung der Daten nach Vertragsende, definiert aber keinen konkreten Zeitraum und keine Nachweispflicht. "Innerhalb angemessener Frist" kann alles zwischen einer Woche und einem Jahr bedeuten.

Fehlende TOM-Dokumentation. Die AVV verweist auf die TOMs des Anbieters, aber die TOMs sind entweder nicht angehängt oder bestehen aus generischen Beschreibungen ohne konkrete technische Details.

Wenn du eine AVV prüfst, achte auf diese Punkte. Eine schlechte AVV ist schlimmer als keine, weil sie eine falsche Sicherheit vermittelt.

On-Prem eliminiert die Auftragsverarbeitung

Hier liegt der grundlegende Vorteil von On-Premise-Hosting: Wenn du das ISMS-Tool auf deiner eigenen Infrastruktur betreibst, gibt es keinen Auftragsverarbeiter. Du verarbeitest die Daten selbst, auf deinen eigenen Servern, unter deiner eigenen Kontrolle. Es gibt keine AVV, keine Subprocessor-Kette und keine Abhängigkeit von den Datenschutzpraktiken eines Dritten. In ISMS Lite bleiben alle personenbezogenen Daten auf deinem Server, und du bist sowohl Verantwortlicher als auch Betreiber der Infrastruktur.

Das bedeutet nicht, dass du keine TOMs brauchst. Die brauchst du für deine eigene Infrastruktur genauso. Aber du kontrollierst sie selbst und musst nicht darauf vertrauen, dass ein Dritter sie einhält.

Art. 44ff DSGVO: Drittlandtransfer

Die Artikel 44 bis 49 der DSGVO regeln die Übermittlung personenbezogener Daten an Drittländer, also Länder außerhalb des Europäischen Wirtschaftsraums (EWR). Für ISMS-Tools ist das relevant, wenn der Cloud-Anbieter oder dessen Subprocessors Daten in Drittländern verarbeiten oder darauf zugreifen.

Das US-Problem

Die meisten großen Cloud-Infrastrukturen (AWS, Azure, GCP) gehören US-Unternehmen. Selbst wenn die Daten in einem EU-Rechenzentrum liegen, unterliegen US-Unternehmen dem CLOUD Act (Clarifying Lawful Overseas Use of Data Act). Der CLOUD Act ermöglicht es US-Behörden, von US-Unternehmen die Herausgabe von Daten zu verlangen, auch wenn diese Daten physisch in der EU gespeichert sind.

Das EU-US Data Privacy Framework (DPF), das seit 2023 als Angemessenheitsbeschluss nach Art. 45 DSGVO gilt, bietet eine rechtliche Grundlage für den Datentransfer an zertifizierte US-Unternehmen. Aber die Stabilität dieses Frameworks ist unsicher. Der Europäische Gerichtshof hat bereits zwei Vorgängerregelungen (Safe Harbor und Privacy Shield) für ungültig erklärt. Ob das DPF dauerhaft Bestand haben wird, ist eine offene Frage.

Für ein ISMS-Tool, das die sensibelsten Sicherheitsinformationen deines Unternehmens enthält, ist das ein relevantes Risiko. Nicht ein theoretisches Risiko der Art "ein US-Geheimdienst könnte sich für unsere Risikobewertung interessieren", sondern ein praktisches Compliance-Risiko: Wenn das DPF kippt, brauchst du innerhalb kurzer Frist eine alternative Rechtsgrundlage für den internationalen Datentransfer oder musst die Daten zurückholen.

Standardvertragsklauseln (SCCs) als Absicherung

Unabhängig vom DPF setzen viele Unternehmen auf Standardvertragsklauseln (Standard Contractual Clauses, SCCs) als zusätzliche Absicherung. SCCs sind vertragliche Vereinbarungen, die sicherstellen sollen, dass der Empfänger im Drittland ein angemessenes Datenschutzniveau bietet.

Aber SCCs allein reichen nach der Schrems-II-Entscheidung des EuGH nicht aus. Du musst zusätzlich ein Transfer Impact Assessment (TIA) durchführen, also eine Bewertung, ob das Recht des Drittlands den vertraglich zugesicherten Schutz in der Praxis aushebeln kann. Bei den USA und dem CLOUD Act ist die Antwort: Ja, potenziell schon.

On-Prem eliminiert den Drittlandtransfer

Wenn du dein ISMS-Tool auf eigener Infrastruktur in der EU betreibst, gibt es keinen Drittlandtransfer. Keine SCCs, kein TIA, keine Abhängigkeit von Angemessenheitsbeschlüssen, die der EuGH in fünf Jahren für ungültig erklären könnte. Die Daten liegen in der EU, werden in der EU verarbeitet, und unterliegen ausschließlich EU-Recht.

DSFA für ISMS-Tools: Pflicht oder Kür?

Die Datenschutz-Folgenabschätzung (DSFA) nach Art. 35 DSGVO ist Pflicht, wenn eine Verarbeitung "voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge" hat. Die Aufsichtsbehörden haben Positivlisten veröffentlicht, die bestimmte Verarbeitungsarten benennen, für die eine DSFA durchzuführen ist.

Wann eine DSFA für das ISMS-Tool nötig sein kann

Ein ISMS-Tool fällt nicht automatisch unter die Pflicht zur DSFA. Die verarbeiteten Daten sind überwiegend berufliche Kontaktdaten (Name, Rolle, E-Mail) in einem begrenzten Kontext. Es gibt kein Profiling, keine automatisierte Entscheidungsfindung und keine systematische Überwachung.

Allerdings gibt es Grenzfälle:

Umfangreiche Audit-Trail-Daten. Wenn das ISMS-Tool jede Aktion jedes Nutzers minutengenau protokolliert, entsteht ein detailliertes Verhaltensprofil. Wer hat wann was bearbeitet, wie lange war die Person eingeloggt, welche Dokumente hat sie angesehen. Das geht über einfache Zugriffsprotokolle hinaus und kann als systematische Überwachung interpretiert werden.

Sensible Zusatzdaten in Vorfallberichten. Wenn Incident-Berichte Details über das Fehlverhalten einzelner Mitarbeiter enthalten ("Mitarbeiter X hat auf den Phishing-Link geklickt"), werden die Daten deutlich sensibler als reine Kontaktdaten.

Große Organisationen. Wenn das ISMS-Tool Daten von mehreren tausend Mitarbeitern über Jahre hinweg speichert, steigt der Umfang der Verarbeitung.

Empfehlung: DSFA als Absicherung

Auch wenn eine DSFA nicht immer formale Pflicht ist, empfiehlt sich eine Kurzanalyse, die dokumentiert, warum die Verarbeitung kein hohes Risiko darstellt, oder, falls doch Risiken identifiziert werden, welche Maßnahmen ergriffen wurden. Das kostet einen halben Tag Aufwand und liefert dir eine saubere Dokumentation, falls die Aufsichtsbehörde nachfragt.

Das Verarbeitungsverzeichnis für dein ISMS-Tool

Jedes Unternehmen muss nach Art. 30 DSGVO ein Verarbeitungsverzeichnis (Verzeichnis der Verarbeitungstätigkeiten, VVA) führen. Dein ISMS-Tool ist eine Verarbeitungstätigkeit, die dort aufgeführt werden muss.

VVA-Eintrag bei Cloud-Hosting

Bezeichnung: Informationssicherheits-Managementsystem (ISMS)
Verantwortlicher: [Firmenname], vertreten durch [GF]
Zweck: Verwaltung des ISMS, Risikobewertung, Maßnahmentracking,
       Audit-Management, Schulungsnachweis, Vorfallmanagement
Rechtsgrundlage: Art. 6 Abs. 1 lit. c (rechtliche Verpflichtung),
                 Art. 6 Abs. 1 lit. f (berechtigtes Interesse)
Kategorien betroffener Personen: Mitarbeiter, externe Auditoren,
                                  Dienstleister
Kategorien personenbezogener Daten: Name, E-Mail, Rolle, Abteilung,
                                     Schulungsteilnahmen,
                                     Zugriffsprotokolle
Empfänger: [SaaS-Anbieter als Auftragsverarbeiter],
           [Subprocessors des Anbieters laut AVV]
Drittlandtransfer: [Ja/Nein, Details zu SCCs, TIA, DPF]
Löschfristen: Benutzerdaten 3 Monate nach Ausscheiden,
              Audit-Daten 6 Jahre, Vorfallberichte 3 Jahre
TOMs: Siehe AVV mit [Anbieter], eigene Zugangskontrolle per MFA,
      Rollenkonzept

VVA-Eintrag bei On-Prem-Hosting

Bezeichnung: Informationssicherheits-Managementsystem (ISMS)
Verantwortlicher: [Firmenname], vertreten durch [GF]
Zweck: Verwaltung des ISMS, Risikobewertung, Maßnahmentracking,
       Audit-Management, Schulungsnachweis, Vorfallmanagement
Rechtsgrundlage: Art. 6 Abs. 1 lit. c (rechtliche Verpflichtung),
                 Art. 6 Abs. 1 lit. f (berechtigtes Interesse)
Kategorien betroffener Personen: Mitarbeiter, externe Auditoren,
                                  Dienstleister
Kategorien personenbezogener Daten: Name, E-Mail, Rolle, Abteilung,
                                     Schulungsteilnahmen,
                                     Zugriffsprotokolle
Empfänger: Keine (interne Verarbeitung auf eigener Infrastruktur)
Drittlandtransfer: Nein
Löschfristen: Benutzerdaten 3 Monate nach Ausscheiden,
              Audit-Daten 6 Jahre, Vorfallberichte 3 Jahre
TOMs: Serverseitige Verschlüsselung (LUKS), TLS 1.3,
      MFA für alle Benutzer, rollenbasierte Zugriffskontrolle,
      tägliches Backup mit Restore-Test

Der Unterschied fällt sofort auf. Bei On-Prem gibt es keine Empfänger, keinen Drittlandtransfer und keine Verweise auf externe AVVs. Der Eintrag ist kürzer, klarer und einfacher zu pflegen.

Checkliste: DSGVO-Konformität deines ISMS-Tools

Grundlagen

• Ist das ISMS-Tool als Verarbeitungstätigkeit im VVA eingetragen?
• Ist die Rechtsgrundlage für die Verarbeitung dokumentiert?
• Sind die Löschfristen für die verschiedenen Datenarten definiert?
• Gibt es ein Löschkonzept, das die Umsetzung der Löschfristen sicherstellt?

Technische Maßnahmen (Art. 32)

• Ist die Verbindung zum ISMS-Tool per TLS verschlüsselt?
• Sind die Daten at rest verschlüsselt?
• Ist MFA für alle Benutzer aktiviert?
• Gibt es ein rollenbasiertes Berechtigungskonzept?
• Werden Zugriffe und Änderungen protokolliert?
• Gibt es regelmäßige, getestete Backups?

Bei Cloud-Hosting zusätzlich

• Liegt eine AVV mit dem Anbieter vor?
• Wurde die AVV inhaltlich geprüft (nicht nur abgenickt)?
• Ist die Subprocessor-Liste dokumentiert und bewertet?
• Gibt es einen Prozess für Subprocessor-Änderungen?
• Ist der Drittlandtransfer geprüft und dokumentiert (DPF, SCCs, TIA)?
• Gibt es ein Auditrecht gegenüber dem Anbieter?
• Ist eine Exit-Strategie mit Datenrückgabe und -löschung vereinbart?

Betroffenenrechte

• Kann das Unternehmen Auskunftsanfragen nach Art. 15 bezüglich der ISMS-Daten beantworten?
• Können personenbezogene Daten im ISMS-Tool berichtigt und gelöscht werden?
• Ist das Löschkonzept für ISMS-Daten dokumentiert?

Häufige Fehler bei der DSGVO-Konformität des ISMS

Fehler 1: Das ISMS-Tool nicht als Verarbeitungstätigkeit behandeln. Das ISMS-Tool fällt oft durch das Raster, weil es als internes Werkzeug und nicht als Datenverarbeitung wahrgenommen wird. Aber sobald dort personenbezogene Daten stehen, und das tun sie ab dem ersten Benutzer-Account, ist es eine Verarbeitungstätigkeit, die ins VVA gehört.

Fehler 2: Die AVV des Cloud-Anbieters nicht prüfen. Viele Unternehmen akzeptieren die Standard-AVV beim Vertragsabschluss, ohne sie inhaltlich zu prüfen. Das ist riskant, denn eine Standard-AVV, die wesentliche Pflichtinhalte vermissen lässt, schützt dich im Ernstfall nicht. Der Datenschutzbeauftragte sollte die AVV vor der Unterschrift prüfen.

Fehler 3: Drittlandtransfer ignorieren. "Die Server stehen in Frankfurt" ist keine ausreichende Analyse. Wenn der SaaS-Anbieter ein US-Unternehmen ist oder US-Subprocessors einsetzt, musst du den Drittlandtransfer bewerten, auch wenn die Daten physisch in der EU liegen.

Fehler 4: Löschfristen nicht definieren. ISMS-Daten haben unterschiedliche Aufbewahrungsanforderungen. Schulungsnachweise müssen für die Dauer der Beschäftigung plus eine angemessene Frist aufbewahrt werden. Audit-Berichte typischerweise sechs Jahre. Vorfallberichte drei bis fünf Jahre. Benutzerdaten müssen gelöscht werden, wenn der Mitarbeiter das Unternehmen verlässt und kein Aufbewahrungsgrund mehr besteht. Ohne definierte Fristen sammelst du Daten auf Vorrat, und das ist ein DSGVO-Verstoß.

Fehler 5: Die TOMs des ISMS-Tools aus der TOM-Dokumentation ausklammern. Die TOMs nach Art. 32 gelten für alle Verarbeitungstätigkeiten, also auch für das ISMS-Tool. Wenn du die TOMs für deine Haupt-Geschäftsprozesse dokumentierst, vergiss nicht, auch die TOMs für die Werkzeuge zu dokumentieren, mit denen du dein ISMS betreibst.

Der pragmatische Weg: On-Prem als DSGVO-Vereinfacher

Dieser Artikel hat gezeigt, dass die DSGVO-Anforderungen an ein ISMS-Tool nicht trivial sind. Auftragsverarbeitung, Drittlandtransfer, Subprocessor-Management, AVV-Prüfung, TIA, die Liste der zu erledigenden Aufgaben ist lang. Jeder einzelne Punkt ist lösbar, aber in der Summe entsteht ein erheblicher Dokumentations- und Prüfaufwand.

On-Premise-Hosting streicht die Hälfte dieser Liste. Keine Auftragsverarbeitung, keine AVV, kein Drittlandtransfer, kein TIA, keine Subprocessor-Bewertung. Was bleibt, sind die Grundanforderungen, die du sowieso erfüllen musst: TOMs, Berechtigungskonzept, Backup-Strategie, Löschkonzept und der VVA-Eintrag.

Das ist kein Argument gegen Cloud-Lösungen im Allgemeinen. Für viele Anwendungen ist die Cloud der richtige Weg. Aber für ein ISMS-Tool, das die sensibelsten Informationen deines Unternehmens enthält und dessen Datenhaltung sowohl von DSGVO-Aufsichtsbehörden als auch von ISO-27001-Auditoren unter die Lupe genommen wird, bietet On-Prem den klarsten und kürzesten Weg zur Konformität.

ISMS Lite setzt genau auf dieses Modell: eine Self-Hosted-Lösung, die auf deiner eigenen Infrastruktur läuft. Du installierst sie auf deinem Server, die Daten bleiben bei dir, und die DSGVO-Dokumentation wird so kurz wie möglich. Kein Drittlandtransfer, keine Subprocessor-Listen, keine AVV-Verhandlungen. Stattdessen volle Kontrolle und ein VVA-Eintrag, der auf eine halbe Seite passt.

Weiterführende Artikel

• Self-Hosted vs. Cloud: Datensouveränität bei Compliance-Software
• Auftragsverarbeitung: AVV prüfen und Dienstleister bewerten
• Technische und organisatorische Maßnahmen (TOMs) dokumentieren
• Verarbeitungsverzeichnis (VVA) nach Art. 30 DSGVO erstellen
• Internationaler Datentransfer: Standardvertragsklauseln und Angemessenheitsbeschlüsse