Die nachfolgenden technischen und organisatorischen Maßnahmen (TOM) beschreiben das Schutzniveau, das Auditspiegel zur Sicherstellung der Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit der verarbeiteten personenbezogenen Daten gemäß Art. 32 DSGVO vorhält. Sie beschreiben den tatsächlich umgesetzten Stand; geplante Maßnahmen sind in Abschnitt 6 gesondert und als solche gekennzeichnet aufgeführt.
1. Vertraulichkeit
1.1 Zutrittskontrolle
Die Infrastruktur wird ausschließlich in Rechenzentren der Hetzner Online GmbH in Falkenstein (FSN1) und Nürnberg (NBG1) betrieben. Hetzner verfügt für diese Rechenzentren über eine Zertifizierung nach ISO/IEC 27001. Physischer Zutritt ist auf befugtes Hetzner-Personal beschränkt; Zutrittskontrolle und Videoüberwachung verantwortet Hetzner im Rahmen seines Auftragsverarbeitungsvertrags. Eigene Räumlichkeiten mit Kundendaten betreibt der Auftragnehmer nicht.
1.2 Zugangskontrolle
- Anmeldung an Auditspiegel-Konten mit Passwort (mindestens 12 Zeichen, Abgleich mit bekannten Datenpannen) und verpflichtender Zwei-Faktor-Anmeldung (TOTP). Konten ohne eingerichtete Zwei-Faktor-Anmeldung erhalten keinen Zugriff auf Anwendungsdaten.
- TOTP-Geheimnisse werden mit pgcrypto auf Spaltenebene verschlüsselt, Wiederherstellungscodes nur als Argon2id-Hash gespeichert.
- Sitzungen laufen spätestens 7 Tage nach der letzten Nutzung ab; Sitzungs-Cookies sind
HttpOnly,SecureundSameSite=Lax. - Administrativer Zugang zu den Servern ausschließlich per SSH mit persönlichem Schlüssel; die Hetzner-Firewall lässt eingehend nur SSH (eingeschränkt), HTTP (Weiterleitung) und HTTPS zu.
- Betriebsoberflächen (Monitoring, Fehlerprotokolle) sind zusätzlich durch eine vorgeschaltete Anmeldung geschützt.
1.3 Zugriffskontrolle
- Auf Datenbankebene erzwingt PostgreSQL Row Level Security (
FORCE ROW LEVEL SECURITY) die Trennung nach Organisation. Jede Anwendungs-Transaktion setzt den Organisations-Kontext; ohne ihn sind keine Kundendaten lesbar. - Die Anwendung arbeitet mit einer Datenbankrolle ohne Recht zur Umgehung von RLS. Schemaänderungen erfolgen über eine getrennte Rolle.
- Protokoll- und Nachweistabellen sind für die Anwendung nur anfügbar (kein Ändern oder Löschen); Löschungen nach Ablauf der Fristen laufen über eng begrenzte Datenbankfunktionen.
- Plattform-Administrationsseiten sind auf namentlich festgelegte Konten beschränkt; jeder Aufruf wird protokolliert.
1.4 Trennungskontrolle
Auditspiegel ist als mandantenfähiges System nach dem Shared-Schema-Modell aufgebaut. Die Trennung erfolgt über eine Organisations-Spalte in jeder mandantenbezogenen Tabelle und wird durch RLS-Richtlinien durchgesetzt. Produktions- und Testsysteme sind getrennt; Tests arbeiten mit synthetischen Daten.
1.5 Datenminimierung und Pseudonymisierung
- Aus dem Microsoft-365-Tenant werden ausschließlich Konfigurations- und Verzeichnisdaten gelesen, keine Inhalte aus Postfächern, Dateien, Chats oder Kalendern.
- Vollständige Antworten der Microsoft-Graph-Schnittstelle werden nur flüchtig (höchstens 2 Stunden, im Arbeitsspeicher-Cache) gehalten. Dauerhaft gespeichert wird je Befund nur ein auf 2 KB begrenzter Nachweis-Auszug, in dem einzelne Konten höchstens als Stichprobe (bis zu 5 Einträge) erscheinen.
- IP-Adressen werden in Sicherheits- und Nachweisprotokollen nur als Hash gespeichert, der mit einem geheimen, täglich wechselnden Schlüssel gebildet wird (Pseudonymisierung). Der Schlüssel wird aus dem Master-Schlüssel abgeleitet, der nicht in der Datenbank liegt; ohne ihn lässt sich der Hash nicht durch Durchprobieren aller Adressen zurückrechnen.
- Die vollständige IP-Adresse wird nur an der aktiven Sitzung gespeichert, damit Sie Ihre angemeldeten Geräte erkennen können. Abgelaufene Sitzungen werden täglich gelöscht; bei Sitzungen, die länger als 30 Tage aktiv sind, wird die IP-Adresse gekürzt (IPv4 auf die ersten drei Blöcke, IPv6 auf die ersten 48 Bit).
- Das Zugriffsprotokoll des vorgeschalteten Webservers erfasst nur fehlgeschlagene Anfragen und speichert dabei keine IP-Adresse.
2. Integrität
2.1 Weitergabekontrolle
- Alle Verbindungen von außen erfolgen ausschließlich verschlüsselt (TLS 1.2 oder höher, HTTP Strict Transport Security; unverschlüsselte Aufrufe werden auf HTTPS umgeleitet).
- Verbindungen zu Microsoft Graph, zum Mailserver (STARTTLS verpflichtend) und zu Stripe erfolgen ausschließlich über TLS.
- Berichte (PDF) liegen in privaten Speicherbereichen; Downloads erfolgen nur über zeitlich begrenzte, signierte Links.
2.2 Eingabekontrolle
Sicherheitsrelevante Aktionen (Anmeldung, Einrichtung und Entfernung der Zwei-Faktor-Anmeldung, Erteilung und Widerruf der Microsoft-Administratorzustimmung, Start eines Audits, Annahme einer AVV-Version, Abruf eines Berichts, Konto-Löschung, Aufrufe der Administrationsseiten) werden in einer nur anfügbaren Protokolltabelle mit Zeitstempel und pseudonymisierter IP-Adresse festgehalten und nach 2 Jahren gelöscht.
3. Verfügbarkeit und Belastbarkeit
3.1 Datensicherung
Die produktive Datenbank wird täglich gesichert (physische und logische Sicherung) und mit restic verschlüsselt auf eine vom Server getrennte Hetzner Storage Box in Deutschland übertragen. Es werden die letzten 30 Tagesstände vorgehalten. Das Sicherungspasswort wird beim Aufsetzen des Servers eingebracht und nicht im Quellcode oder Image abgelegt.
3.2 Wiederherstellungstests
Die Wiederherstellung wird vor Aufnahme des Produktivbetriebs und danach regelmäßig (Zielrhythmus: monatlich, mindestens vierteljährlich) auf einer Wegwerf-Datenbank geprüft (Integritätsprüfung der Sicherung, Wiederherstellung und Abgleich der Tabellen); das Ergebnis wird festgehalten.
3.3 Überwachung
System- und Anwendungsmetriken sowie strukturierte Protokolle werden mit selbst betriebenen Komponenten (Prometheus, Alertmanager, Loki, Grafana) auf den eigenen Servern in Deutschland erfasst. Protokolle werden in der zentralen Protokollablage nach 14 Tagen gelöscht; die lokalen Protokolldateien der Container sind in der Größe begrenzt (3 × 10 MB je Dienst) und werden laufend überschrieben. Alarme (z. B. Dienstausfall, ausbleibende Sicherung, ablaufendes Zertifikat, Speicherplatz) gehen per E-Mail an den Betreiber.
3.4 Wiederherstellbarkeit nach Störungen
Für den Ausfall des Servers, der Datenbank und des Sicherungsspeichers bestehen dokumentierte Wiederherstellungsabläufe (Betriebshandbuch). Vor jeder Aktualisierung wird zusätzlich ein Datenbankabzug erstellt.
4. Löschung
- Rohantworten der Graph-Schnittstelle: nach höchstens 2 Stunden.
- Protokoll der Graph-Aufrufe (ohne Inhalte) und Scan-Ablaufprotokolle: nach 90 Tagen.
- Sicherheits- und Nachweisprotokoll: nach 2 Jahren, spätestens mit der Löschung des Kontos; Einwilligungsprotokoll früherer Cookie-Auswahlen (seit 24.10.2026 ohne neue Einträge, kein Cookie-Banner mehr): nach 3 Jahren.
- Sitzungen: nach Ablauf (täglich), IP-Adresse länger aktiver Sitzungen nach 30 Tagen gekürzt.
- Server-Protokolle: nach 14 Tagen; Datensicherungen: nach 30 Tagen.
- Konto-Löschung: nach einer Widerrufsfrist von 30 Tagen. Gelöscht werden das Konto mit Sitzungen und Zwei-Faktor-Daten, die verbundenen Tenants, alle Prüfergebnisse einschließlich der Konto-Stichproben, die gespeicherten Berichte und Auskunftsdateien, die Zugangsschlüssel einer Buchhaltungs-Verbindung und die Protokolle der Organisation; ein laufendes Abo wird beendet. Das läuft als täglicher, wiederaufnehmbarer Löschlauf unter der Mandantentrennung.
- Nach Vertragsende: Löschung wie bei der Konto-Löschung spätestens 12 Monate nach Vertragsende, 30 Tage vorher per E-Mail angekündigt (AVV §11 Abs. 3).
- Konten ohne Buchung (nie ein Einmal-Audit oder Abo): Löschung wie bei der Konto-Löschung, wenn sich 12 Monate lang niemand angemeldet hat (ohne Anmeldung ab der Registrierung), 30 Tage vorher per E-Mail angekündigt; eine Anmeldung bis dahin bricht die Löschung ab (AVV §11 Abs. 3a). Grundlage ist der bei jeder abgeschlossenen Anmeldung gespeicherte Zeitpunkt der letzten Anmeldung.
- Aufbewahrt bleiben nach der Löschung nur Firmenname, USt-IdNr und Stripe-Kundennummer zur Zuordnung der Rechnungen (10 Jahre, § 147 AO, § 14b UStG) sowie der Nachweis der Annahme von AGB und AVV ohne Namen und IP-Hash (3 Jahre ab Ende des Löschjahres).
5. Verfahren zur regelmäßigen Überprüfung, Bewertung und Evaluierung
5.1 Überprüfung der Maßnahmen
Diese TOM werden mindestens jährlich sowie bei wesentlichen Änderungen der Verarbeitung überprüft und angepasst. Automatisierte Prüfungen im Entwicklungsprozess sichern unter anderem die Mandantentrennung (RLS), die Datensparsamkeits-Grenze (keine Speicherung von Graph-Rohantworten) und die Abhängigkeits-Aktualität ab.
5.2 Auftragskontrolle (Unterauftragsverarbeiter)
Vor der Aufnahme eines Unterauftragsverarbeiters werden geprüft:
- ein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO,
- geeignete technische und organisatorische Maßnahmen,
- der Ort der Verarbeitung und, bei Übermittlungen in Drittländer, geeignete Garantien nach Art. 44 ff. DSGVO.
Änderungen der Liste werden mindestens 30 Tage vor Wirksamwerden angekündigt. Die aktuelle Liste ist unter /legal/subprocessors abrufbar.
5.3 Organisatorisches
Der Auftragnehmer ist ein Einzelunternehmen; die Verarbeitung führt der Inhaber selbst durch. Werden weitere Personen eingesetzt, werden sie vorher schriftlich auf Vertraulichkeit verpflichtet und erhalten Zugriff nur, soweit für ihre Aufgabe erforderlich.
6. Geplante Maßnahmen
Die folgenden Maßnahmen sind vorgesehen, aber noch nicht umgesetzt. Sie werden hier aufgeführt, damit der tatsächliche Stand nicht überzeichnet wird:
- externer Penetrationstest der Anwendung; eine Zusammenfassung stellen wir Kunden nach Vorliegen auf Anfrage zur Verfügung,
- zentrale Fehlererfassung mit GlitchTip (selbst betrieben),
- Überführung des Hauptschlüssels der Spaltenverschlüsselung in HashiCorp Vault.