ISMS-Daten sichern: Backup-Strategie für selbst gehostete Compliance-Systeme

Kein Backup, keine Zertifizierung

Wenn du dein ISMS self-hosted betreibst, hast du die volle Kontrolle über deine Daten. Das ist der zentrale Vorteil gegenüber einer SaaS-Lösung. Aber mit dieser Kontrolle kommt eine Verantwortung, die bei Cloud-Lösungen der Anbieter übernimmt: die Datensicherung.

Das klingt nach einer Selbstverständlichkeit, und doch passiert es regelmäßig: Ein Server fällt aus, eine Festplatte stirbt, ein Update geht schief, oder ein Ransomware-Angriff verschlüsselt das System. Und dann stellt sich heraus, dass das letzte Backup drei Monate alt ist, nie getestet wurde oder auf demselben Server lag.

Bei einem normalen Anwendungsserver ist das ärgerlich. Bei deinem ISMS-System ist es potenziell existenzbedrohend. Dein ISMS enthält das Risikoregister, den Maßnahmenstatus, Audit-Berichte, Incident-Dokumentationen und alle Nachweise, die du für deine Zertifizierung brauchst. Wenn diese Daten weg sind, fängst du nicht einfach von vorne an, du verlierst den dokumentierten Nachweis deiner gesamten Sicherheitsarbeit. Im schlimmsten Fall ist die ISO-27001-Zertifizierung gefährdet, weil du die geforderten Aufzeichnungen nicht mehr vorweisen kannst.

Dieser Artikel zeigt dir Schritt für Schritt, wie du eine solide Backup-Strategie für dein self-hosted ISMS aufbaust.

Was du sichern musst

Ein ISMS-System besteht typischerweise aus drei Komponenten, die alle gesichert werden müssen:

1. Die Datenbank

Die Datenbank ist das Herzstück deines ISMS. Hier liegen alle strukturierten Daten: Risiken, Maßnahmen, Controls, Audit-Einträge, Benutzerkonten, Berechtigungen und Konfigurationen. Bei den meisten Self-Hosted-Lösungen kommt PostgreSQL oder MySQL/MariaDB zum Einsatz.

Warum ein Dateisystem-Backup der Datenbank nicht reicht: Wenn du einfach das Datenverzeichnis von PostgreSQL oder MySQL kopierst, während die Datenbank läuft, bekommst du möglicherweise einen inkonsistenten Zustand. Offene Transaktionen, halb geschriebene Blöcke, fehlende WAL-Einträge (Write-Ahead Log). Ein solches Backup kann im Ernstfall unbrauchbar sein. Deshalb brauchst du ein logisches Backup über die Datenbanktools.

2. Das Dateisystem

Neben der Datenbank speichern ISMS-Systeme Dateien auf dem Filesystem:

• Uploads: Hochgeladene Dokumente wie Richtlinien-PDFs, Audit-Berichte, Schulungsnachweise, Zertifikate.
• Konfigurationsdateien: Anwendungskonfiguration, Datenbankverbindung, SMTP-Einstellungen, Lizenzschlüssel.
• Medien: Screenshots, Diagramme, Netzwerkpläne.

Diese Dateien müssen separat gesichert werden, da sie nicht in der Datenbank liegen.

3. Die Anwendungskonfiguration

Dazu gehören:

• Webserver-Konfiguration: Nginx oder Apache Virtual-Host-Konfiguration, SSL-Zertifikate.
• Umgebungsvariablen: .env-Dateien oder systemd-Konfigurationen mit Datenbankpasswörtern und API-Keys.
• Cronjobs: Automatisierte Aufgaben wie Backup-Skripte selbst, Report-Generierung oder Cache-Bereinigung.
• SSL-Zertifikate: Wenn du eigene Zertifikate verwendest (nicht Let's Encrypt, das sich selbst erneuert).

Datenbank-Backup mit pg_dump

Für PostgreSQL ist pg_dump das Standardwerkzeug für logische Backups. Es erzeugt eine SQL-Datei oder ein komprimiertes Archiv, das den vollständigen Datenbankinhalt enthält.

Grundlegendes Backup

pg_dump -h localhost -U isms_user -d isms_db -Fc -f /backup/isms_db_$(date +%Y%m%d_%H%M%S).dump

Parameter erklärt:

• -h localhost: Verbindung zum lokalen Datenbankserver.
• -U isms_user: Datenbankbenutzer mit Leserechten auf alle relevanten Tabellen.
• -d isms_db: Name der ISMS-Datenbank.
• -Fc: Custom-Format. Komprimiert, unterstützt selektiven Restore und paralleles Restore. Deutlich besser als -Fp (Plain SQL).
• -f /backup/...: Ausgabedatei mit Zeitstempel im Dateinamen.

Für MySQL/MariaDB

mysqldump -h localhost -u isms_user -p --single-transaction --routines --triggers isms_db | gzip > /backup/isms_db_$(date +%Y%m%d_%H%M%S).sql.gz

Wichtig: --single-transaction stellt sicher, dass das Backup konsistent ist, ohne die Datenbank zu sperren. Das funktioniert nur mit InnoDB-Tabellen (Standard bei MariaDB und modernem MySQL).

Dateisystem-Backup

Für die Dateien auf dem Filesystem eignet sich rsync oder tar:

tar czf /backup/isms_files_$(date +%Y%m%d_%H%M%S).tar.gz \
  /var/www/isms/uploads/ \
  /var/www/isms/.env \
  /var/www/isms/config/ \
  /etc/nginx/sites-available/isms.conf

Passe die Pfade an deine Installation an. Die konkreten Verzeichnisse hängen von der verwendeten ISMS-Software ab. Bei ISMS Lite sind die relevanten Pfade in der Installationsdokumentation aufgeführt.

Verschlüsselung der Backups mit AES-256

ISMS-Backups enthalten dein Risikoregister, Incident-Berichte und Audit-Ergebnisse. Ein unverschlüsseltes Backup auf einem Netzlaufwerk, einer externen Festplatte oder gar einem Cloud-Speicher ist ein Sicherheitsvorfall, der nur noch nicht entdeckt wurde.

Warum AES-256?

AES-256 (Advanced Encryption Standard mit 256-Bit-Schlüssel) ist der aktuelle Standard für symmetrische Verschlüsselung. Er wird vom BSI empfohlen, ist in allen relevanten Compliance-Frameworks anerkannt und gilt nach aktuellem Stand als quantencomputerresistent. Für Backup-Verschlüsselung gibt es keinen Grund, etwas anderes zu verwenden.

Verschlüsselung mit OpenSSL

openssl enc -aes-256-cbc -salt -pbkdf2 -iter 100000 \
  -in /backup/isms_db_20260315_020000.dump \
  -out /backup/isms_db_20260315_020000.dump.enc \
  -pass file:/etc/isms-backup/encryption.key

Parameter erklärt:

• -aes-256-cbc: AES-256 im CBC-Modus.
• -salt: Fügt einen zufälligen Salt hinzu, verhindert Rainbow-Table-Angriffe.
• -pbkdf2 -iter 100000: Key-Derivation mit 100.000 Iterationen, verlangsamt Brute-Force.
• -pass file:...: Liest das Passwort aus einer Datei statt aus der Kommandozeile (sicherer, weil es nicht in der Prozessliste erscheint).

Verschlüsselung mit GPG (Alternative)

GPG bietet den Vorteil asymmetrischer Verschlüsselung. Du verschlüsselst mit dem öffentlichen Schlüssel und brauchst nur den privaten Schlüssel zum Entschlüsseln:

gpg --encrypt --recipient backup@dein-unternehmen.de \
  --output /backup/isms_db_20260315_020000.dump.gpg \
  /backup/isms_db_20260315_020000.dump

Der Vorteil: Der private Schlüssel muss nicht auf dem Backup-Server liegen. Er kann separat aufbewahrt werden und wird nur für den Restore benötigt. Das reduziert das Risiko, dass ein Angreifer, der den Backup-Server kompromittiert, auch die Backups entschlüsseln kann.

Schlüsselmanagement

Das Passwort oder der Schlüssel für die Backup-Verschlüsselung ist der wichtigste Schlüssel in deinem gesamten Backup-Konzept. Wenn du ihn verlierst, sind alle verschlüsselten Backups wertlos. Wenn ein Angreifer ihn findet, kann er alle Backups lesen.

Empfohlene Aufbewahrung:

• Primär: Auf dem Backup-Server in einer Datei mit restriktiven Berechtigungen (chmod 600, nur root).
• Sekundär: In einem Passwort-Manager oder einem physischen Tresor, zugänglich für mindestens zwei autorisierte Personen.
• Nicht: Im Git-Repository, in einer E-Mail, auf einem Post-it oder in der .env-Datei der Anwendung.

Offsite-Kopie: Die zweite Verteidigungslinie

Das 3-2-1-Prinzip der Datensicherung besagt: 3 Kopien, auf 2 verschiedenen Medientypen, davon 1 offsite. Für ISMS-Backups ist die Offsite-Kopie besonders wichtig, weil ein Ransomware-Angriff, der deinen ISMS-Server trifft, wahrscheinlich auch lokale Backups verschlüsselt.

Option 1: Verschlüsseltes Backup auf einen zweiten Standort kopieren

rsync -avz --progress /backup/isms_db_20260315_020000.dump.enc \
  backup-user@offsite-server:/backup/isms/

Der Offsite-Server sollte:

• An einem anderen physischen Standort stehen (nicht im selben Gebäude).
• Eigene Zugangsdaten haben (nicht dieselben wie der Produktivserver).
• Keine eingehenden SSH-Verbindungen vom Produktivserver akzeptieren (nur der Backup-Server verbindet sich zum Offsite-Server, nicht umgekehrt).

Option 2: S3-kompatibler Objektspeicher

Viele Hosting-Provider bieten S3-kompatiblen Objektspeicher an, auch europäische Anbieter wie Hetzner, Contabo oder IONOS. Damit kannst du verschlüsselte Backups in die Cloud schieben, ohne die Datensouveränität aufzugeben, denn die Backups sind bereits clientseitig verschlüsselt:

aws s3 cp /backup/isms_db_20260315_020000.dump.enc \
  s3://isms-backup/2026/03/15/ \
  --endpoint-url https://s3.eu-central-1.example.com

Da das Backup vor dem Upload verschlüsselt wird, kann der Speicheranbieter die Daten nicht lesen. Du nutzt die Cloud nur als Speichermedium, nicht als Datenverarbeiter.

Option 3: Immutable Backups

Für maximalen Schutz gegen Ransomware eignen sich Immutable Backups. S3 Object Lock oder WORM-Speicher (Write Once Read Many) verhindern, dass einmal geschriebene Backups verändert oder gelöscht werden können, auch nicht von einem Angreifer mit Admin-Rechten.

Restore testen: Das Backup, das du nie getestet hast, existiert nicht

Diesen Satz wirst du in jedem Backup-Artikel lesen, und trotzdem ist "Restore nie getestet" der häufigste Backup-Fehler. Bei ISMS-Daten ist das besonders gefährlich, weil du den Datenverlust möglicherweise erst Monate später bemerkst, nämlich beim nächsten Audit oder Management Review.

Warum Restore-Tests scheitern

Die häufigsten Gründe, warum ein Restore nicht funktioniert:

• Fehlende Abhängigkeiten: Die Datenbank-Version auf dem Restore-System stimmt nicht mit der Backup-Version überein.
• Falsche Berechtigungen: Der Datenbank-User, dem die Tabellen gehören, existiert auf dem Restore-System nicht.
• Korrupte Backups: Das Backup wurde während des Schreibens unterbrochen oder das Speichermedium hat Fehler.
• Fehlende Verschlüsselungsschlüssel: Der Schlüssel zum Entschlüsseln ist nicht mehr verfügbar.
• Unvollständige Backups: Datenbank wurde gesichert, aber die Uploads fehlen, oder umgekehrt.

Restore-Prozedur für PostgreSQL

# 1. Backup entschlüsseln
openssl enc -d -aes-256-cbc -pbkdf2 -iter 100000 \
  -in /backup/isms_db_20260315_020000.dump.enc \
  -out /tmp/isms_restore.dump \
  -pass file:/etc/isms-backup/encryption.key

# 2. Datenbank erstellen (oder bestehende leeren)
createdb -h localhost -U postgres isms_restore_test

# 3. Backup einspielen
pg_restore -h localhost -U postgres -d isms_restore_test \
  --no-owner --role=isms_user /tmp/isms_restore.dump

# 4. Prüfen: Anzahl der Datensätze in kritischen Tabellen
psql -h localhost -U isms_user -d isms_restore_test \
  -c "SELECT 'risks' AS table_name, COUNT(*) FROM risks
      UNION ALL SELECT 'controls', COUNT(*) FROM controls
      UNION ALL SELECT 'incidents', COUNT(*) FROM incidents
      UNION ALL SELECT 'audits', COUNT(*) FROM audits;"

# 5. Aufräumen
dropdb -h localhost -U postgres isms_restore_test
rm /tmp/isms_restore.dump

Restore-Test-Plan

Empfehlung: Führe den Restore-Test quartalsweise durch. Dokumentiere das Ergebnis als Nachweis für interne Audits und Management Reviews. In ISMS Lite kannst du den Restore-Test als wiederkehrende Maßnahme mit Verantwortlichkeit und Frist anlegen, so dass er nicht vergessen wird.

Aufbewahrungsfristen für Audit-Daten

Nicht jedes Backup muss ewig aufbewahrt werden. Aber für ISMS-Daten gelten besondere Anforderungen, weil Auditoren historische Daten prüfen können.

ISO 27001 und Aufbewahrung

ISO 27001 fordert in Klausel 7.5 (Dokumentierte Information), dass Aufzeichnungen aufbewahrt werden, die den Nachweis der Konformität und der Wirksamkeit des ISMS ermöglichen. Eine konkrete Mindestdauer nennt der Standard nicht, aber in der Praxis gelten folgende Richtwerte:

NIS2 und Aufbewahrung

NIS2 definiert keine expliziten Aufbewahrungsfristen, aber die NIS2-Meldefristen und die Nachweispflichten legen nahe, dass Incident-Berichte und Risikobewertungen mindestens über den Zeitraum aufbewahrt werden sollten, in dem behördliche Nachfragen möglich sind. In der Praxis empfehlen wir mindestens 5 Jahre für alle sicherheitsrelevanten Aufzeichnungen.

Retention-Strategie für Backups

Nicht jedes Backup muss jahrelang aufbewahrt werden. Eine bewährte Strategie:

• Tägliche Backups: Aufbewahrung für 30 Tage.
• Wöchentliche Backups: Aufbewahrung für 12 Wochen (Sonntagsbackup wird aufbewahrt).
• Monatliche Backups: Aufbewahrung für 12 Monate (Backup vom 1. des Monats).
• Jährliche Backups: Aufbewahrung für 5 Jahre (Backup vom 1. Januar).

Dieses Schema stellt sicher, dass du kurzfristig auf tägliche Snapshots zugreifen kannst und langfristig historische Daten für Audits vorhanden sind, ohne den Speicherbedarf explodieren zu lassen.

Automatisierung per Cron

Manuelles Backup ist kein Backup. Es wird vergessen, aufgeschoben, falsch ausgeführt. Automatisierung ist keine Option, sondern Pflicht.

Komplettes Backup-Skript

#!/bin/bash
# ISMS Backup Script
# Sichert Datenbank und Dateisystem, verschlüsselt und überträgt offsite

set -euo pipefail

# Konfiguration
BACKUP_DIR="/backup/isms"
OFFSITE_HOST="backup@offsite.example.com"
OFFSITE_DIR="/backup/isms"
DB_NAME="isms_db"
DB_USER="isms_user"
ENCRYPTION_KEY="/etc/isms-backup/encryption.key"
ISMS_DIR="/var/www/isms"
TIMESTAMP=$(date +%Y%m%d_%H%M%S)
LOG_FILE="/var/log/isms-backup.log"
RETENTION_DAYS=30

# Logging
exec >> "$LOG_FILE" 2>&1
echo "=== Backup gestartet: $(date) ==="

# 1. Datenbank-Backup
echo "Starte Datenbank-Backup..."
pg_dump -h localhost -U "$DB_USER" -d "$DB_NAME" -Fc \
  -f "$BACKUP_DIR/db_${TIMESTAMP}.dump"
echo "Datenbank-Backup abgeschlossen."

# 2. Dateisystem-Backup
echo "Starte Dateisystem-Backup..."
tar czf "$BACKUP_DIR/files_${TIMESTAMP}.tar.gz" \
  "$ISMS_DIR/uploads/" \
  "$ISMS_DIR/.env" \
  "$ISMS_DIR/config/" \
  2>/dev/null || true
echo "Dateisystem-Backup abgeschlossen."

# 3. Zusammenfassen
echo "Erstelle Gesamtarchiv..."
tar cf "$BACKUP_DIR/isms_full_${TIMESTAMP}.tar" \
  -C "$BACKUP_DIR" \
  "db_${TIMESTAMP}.dump" \
  "files_${TIMESTAMP}.tar.gz"
echo "Gesamtarchiv erstellt."

# 4. Verschlüsseln
echo "Verschlüssele Backup..."
openssl enc -aes-256-cbc -salt -pbkdf2 -iter 100000 \
  -in "$BACKUP_DIR/isms_full_${TIMESTAMP}.tar" \
  -out "$BACKUP_DIR/isms_full_${TIMESTAMP}.tar.enc" \
  -pass file:"$ENCRYPTION_KEY"
echo "Verschlüsselung abgeschlossen."

# 5. Temporäre Dateien aufräumen
rm -f "$BACKUP_DIR/db_${TIMESTAMP}.dump"
rm -f "$BACKUP_DIR/files_${TIMESTAMP}.tar.gz"
rm -f "$BACKUP_DIR/isms_full_${TIMESTAMP}.tar"

# 6. Offsite-Transfer
echo "Übertrage Backup offsite..."
rsync -az "$BACKUP_DIR/isms_full_${TIMESTAMP}.tar.enc" \
  "$OFFSITE_HOST:$OFFSITE_DIR/"
echo "Offsite-Transfer abgeschlossen."

# 7. Alte Backups löschen (lokale Retention)
echo "Bereinige alte Backups..."
find "$BACKUP_DIR" -name "isms_full_*.tar.enc" -mtime +$RETENTION_DAYS -delete
echo "Bereinigung abgeschlossen."

# 8. Prüfsumme erstellen
sha256sum "$BACKUP_DIR/isms_full_${TIMESTAMP}.tar.enc" \
  >> "$BACKUP_DIR/checksums.sha256"

echo "=== Backup abgeschlossen: $(date) ==="
echo "Datei: isms_full_${TIMESTAMP}.tar.enc"
echo "Größe: $(du -h "$BACKUP_DIR/isms_full_${TIMESTAMP}.tar.enc" | cut -f1)"

Cronjob einrichten

# Tägliches Backup um 02:00 Uhr
echo "0 2 * * * root /opt/scripts/isms-backup.sh" > /etc/cron.d/isms-backup
chmod 644 /etc/cron.d/isms-backup

Monitoring des Backup-Jobs

Ein Backup-Skript, das still scheitert, ist schlimmer als kein Skript. Überwache den Backup-Job:

Option 1: E-Mail-Benachrichtigung bei Fehler

Füge am Ende des Skripts hinzu:

if [ $? -ne 0 ]; then
  echo "ISMS Backup fehlgeschlagen am $(date)" | \
    mail -s "ALERT: ISMS Backup Failed" admin@dein-unternehmen.de
fi

Option 2: Healthcheck-Ping

Nutze einen Dienst wie Healthchecks.io oder einen eigenen Endpoint:

# Am Ende des erfolgreichen Backups
curl -fsS -m 10 --retry 5 https://hc-ping.com/dein-uuid > /dev/null

Wenn der Ping ausbleibt, bekommst du eine Benachrichtigung.

Option 3: Logging und Monitoring-Integration

Schreibe Backup-Ergebnisse in dein zentrales Logging-System (syslog, Graylog, ELK) und erstelle einen Alert, wenn der tägliche Backup-Eintrag ausbleibt.

Checkliste: ISMS-Backup-Strategie

Häufige Fehler bei ISMS-Backups

Fehler 1: Backup und Produktivsystem auf demselben Server. Das ist kein Backup, das ist eine Kopie auf derselben Festplatte. Bei einem Hardwareausfall oder Ransomware-Angriff sind beide weg. Mindestens die Offsite-Kopie muss physisch getrennt sein.

Fehler 2: Unverschlüsselte Backups auf Cloud-Speicher. Du investierst in die Sicherheit deines ISMS, aber das Backup deines Risikoregisters liegt unverschlüsselt in einem S3-Bucket? Das ist ein Widerspruch, den spätestens der Auditor bemerkt.

Fehler 3: Restore nie getestet. Der mit Abstand häufigste Fehler. Jedes Quartal 30 Minuten für einen Restore-Test zu investieren kann dir Wochen an Wiederaufbauarbeit ersparen. Trage den Test als festen Termin ein, genau wie das interne Audit.

Fehler 4: Nur die Datenbank sichern, aber nicht die Dateien. Viele Backup-Skripte sichern nur die Datenbank. Aber wenn die Uploads (Richtlinien-PDFs, Audit-Berichte, Zertifikate) fehlen, ist der Restore unvollständig. Ein ISMS ohne die hochgeladenen Dokumente ist wie ein Aktenschrank ohne Akten.

Fehler 5: Verschlüsselungsschlüssel verlieren. Der Schlüssel liegt auf dem Backup-Server und nirgendwo sonst. Der Server stirbt. Die Backups existieren, aber niemand kann sie entschlüsseln. Bewahre den Schlüssel an mindestens zwei unabhängigen Orten auf, und stelle sicher, dass mindestens zwei Personen Zugang haben.

Sonderfall: Backup während der Zertifizierung

Wenn du dich auf eine ISO-27001-Zertifizierung vorbereitest oder dich im laufenden Zertifizierungszyklus befindest, gelten zusätzliche Empfehlungen:

Vor dem Audit: Erstelle ein vollständiges Backup und einen separaten Snapshot. Falls beim Audit etwas schiefgeht (unwahrscheinlich, aber möglich), hast du einen definierten Zustand.

Während des Zertifizierungszyklus: Stelle sicher, dass die Backup-Strategie selbst im ISMS dokumentiert ist. Der Auditor wird danach fragen. Die Datensicherungsrichtlinie sollte die ISMS-Daten explizit abdecken.

Nach Änderungen: Wenn du größere Änderungen am ISMS vornimmst (neue Risikobewertung, SoA-Update, Richtlinienänderung), erstelle ein zusätzliches Backup vor der Änderung. Falls etwas schiefgeht, kannst du auf den vorherigen Stand zurückkehren.

Die Backup-Strategie im Gesamtkontext

Deine ISMS-Backup-Strategie existiert nicht isoliert. Sie sollte Teil deiner allgemeinen Backup-Strategie sein und in den übergeordneten Disaster Recovery Plan eingebettet werden. Die RPO und RTO für dein ISMS-System sollten explizit definiert sein:

• RPO (Recovery Point Objective): Wie viele Stunden an ISMS-Daten kannst du maximal verlieren? Bei täglichen Backups um 02:00 Uhr verlierst du im schlimmsten Fall fast 24 Stunden. Ist das akzeptabel? Für die meisten Unternehmen ja, weil ISMS-Daten nicht im Minutentakt geändert werden.

• RTO (Recovery Time Objective): Wie schnell muss das ISMS nach einem Ausfall wieder verfügbar sein? Ein halber Tag? Ein Tag? In den meisten Fällen ist das ISMS nicht geschäftskritisch im Sinne von "Produktion steht still", aber bei einem aktiven Sicherheitsvorfall brauchst du Zugriff auf dein Incident-Response-Verfahren.

Tipp: Halte die wichtigsten Verfahren (Incident Response, Eskalationswege, Kontaktdaten) auch offline verfügbar, zum Beispiel als ausgedrucktes Notfallhandbuch. Dann ist ein kurzzeitiger ISMS-Ausfall kein Showstopper im Ernstfall.

Fazit

Ein self-hosted ISMS gibt dir die volle Kontrolle über deine sensibelsten Sicherheitsdaten. Diese Kontrolle verpflichtet dich aber auch, die Datensicherung selbst in die Hand zu nehmen. Datenbank-Backup, Dateisystem-Backup, Verschlüsselung, Offsite-Kopie, automatisierte Ausführung und regelmäßige Restore-Tests: Kein Schritt davon ist optional. Fang heute an, wenn du es nicht schon getan hast. Das erste Backup ist das wichtigste.

Weiterführende Artikel

• Die Kronjuwelen deines Unternehmens: Warum ISMS-Daten besonderen Schutz brauchen
• Datensicherung nach BSI: Das 3-2-1-1-0-Prinzip in der Praxis
• Backup-Strategie und Restore-Tests: Weil Backups allein nicht reichen
• Disaster Recovery Plan erstellen: Vom Notfall zurück zum Normalbetrieb
• Self-Hosted vs. Cloud: Datensouveränität bei Compliance-Software