1. Vertraulichkeit (Art. 32 Abs. 1 lit. b DSGVO)
1.1 Zutrittskontrolle — physischer Zugang
Rechenzentren der Subprozessoren
Die Primär-Datenbank (Supabase/PostgreSQL) wird in einem AWS-Rechenzentrum in Frankfurt (eu-central-1) betrieben. AWS-Rechenzentren sind ISO/IEC 27001, SOC 2 Type II und PCI-DSS-zertifiziert. Der physische Zutritt erfolgt mehrfaktor-authentifiziert mit Biometrie und Schleusensystem; jeder Zutritt ist protokolliert.
Büroräume des Auftragnehmers
Büroräume sind mit Schließzylinder gesichert; nur autorisierte Mitarbeiter erhalten Schlüssel. Auf lokalen Entwicklergeräten werden keine produktiven personenbezogenen Daten gespeichert.
1.2 Zugangskontrolle — System-Ebene
Authentifizierung
Passwörter werden als bcrypt-Hashes mit individuellem Salt und hohem Work-Factor (Cost 12+) gespeichert. Zwei-Faktor-Authentifizierung per TOTP ist für alle Nutzer jederzeit aktivierbar.
Administrativer Zugriff
Administrative Zugriffe auf produktive Systeme erfolgen ausschließlich über SSH-Key-Authentifizierung mit Hardware-Token (YubiKey) und IP-Allow-Listing. Privilegierte Aktionen erfordern eine Re-Authentifizierung.
Passwort-Richtlinien
Mindestlänge 12 Zeichen, Zwang zu Komplexität bei Administrator-Accounts, Rate-Limiting und Account-Lock-Out nach fünf fehlgeschlagenen Anmeldeversuchen, automatische Sitzungsbeendigung nach Inaktivität.
1.3 Zugriffskontrolle — Datensatz-Ebene
Row Level Security (RLS)
Jede Datenbanktabelle mit Nutzer-Bezug ist durch Row-Level-Security-Policies geschützt. Mandantenübergreifende Zugriffe sind architektonisch ausgeschlossen — selbst bei fehlerhaftem Anwendungscode bleibt der Isolationsmechanismus auf Datenbankebene wirksam.
Rollen-basiertes Berechtigungskonzept
Interne Rollen: User · Steuerberater-Lesezugriff · Administrator · Super-Administrator. Super-Administrator-Aktionen werden vollständig auditiert (who, what, when, from-IP).
Least-Privilege-Prinzip
Jeder Service-Account hat nur die minimal erforderlichen Rechte. Service-Role-Keys sind strikt vom Anon-Key getrennt und werden nur serverseitig in geschützten Umgebungsvariablen verwendet.
1.4 Trennungsgebot
Mandantentrennung
Logische Trennung durch user_id-/company_id-Spalten in Kombination mit Row-Level-Security. Produktiv-, Staging- und Test-Umgebungen sind vollständig physisch getrennt (separate Supabase-Instanzen, separate AWS-Accounts bei Subprozessoren).
2. Integrität (Art. 32 Abs. 1 lit. b DSGVO)
2.1 Weitergabekontrolle
Transportverschlüsselung
Sämtliche Datenübertragungen erfolgen über TLS 1.2+ (überwiegend TLS 1.3). HSTS ist erzwungen (HSTS-Preload), HTTP-Verbindungen werden automatisch auf HTTPS umgeleitet.
Verschlüsselung ruhender Daten
Datenbank: AES-256 (AWS RDS-seitig). Beleg- und Export-Dateien: AES-256-verschlüsselter S3-Bucket in Frankfurt. Backups sind ebenfalls verschlüsselt.
Field-Level-Verschlüsselung sensibler PII (App-Layer, AES-256-GCM)
Zusätzlich zur at-rest-Verschlüsselung der gesamten DB werden sensible Felder (vat_id, tax_number, iban, bic,counterparty_iban) auf Anwendungsebene mit AES-256-GCM (versioniertes Schlüssel- Schema v1:) verschlüsselt, bevor sie in die Datenbank geschrieben werden. Der Schlüssel ENCRYPTION_KEY_V1 liegt ausschließlich in der Vercel-Laufzeitumgebung und ist getrennt von der DB. Auch ein vollständiger Datenbank-Dump enthält damit keine plaintext-Steuernummern oder -IBAN. Stand 24.04.2026: Dual-Write-Phase aktiv (encrypted wird bei jedem Write parallel geschrieben), Backfill alter Datensätze und anschließendes DROP der plaintext-Spalten ist als geplante Folge-Migration dokumentiert.
Pseudonymisierung
Ausgewählte Datenfelder sind zusätzlich spaltenweise pseudonymisiert (pgcrypto-Extension); bei Kontolöschung erfolgt PII-Anonymisierung in allen relevanten Tabellen vor der steuerrechtlichen Langzeit-Aufbewahrung.
E-Mail-Sicherheit
Rechnungs- und Transaktions-E-Mails werden mit SPF, DKIM und DMARC ausgeliefert. Resend als E-Mail-Provider signiert alle Webhook-Callbacks.
2.2 Eingabekontrolle
Audit-Log
Sicherheitsrelevante Aktionen (Login, Passwort-Änderung, 2FA-Änderung, Superadmin-Aktionen, Account-Löschung, Datenexport) werden mit Zeitstempel, Akteur und IP in einem unveränderlichen Audit-Log protokolliert.
Datenbank-Änderungen
Alle DDL-Änderungen erfolgen ausschließlich über versionierte Migrationsdateien im Git-Repository. Manuelle Änderungen in der Produktivdatenbank sind prozessual untersagt und technisch durch fehlende Admin-Rechte im Dashboard blockiert.
3. Verfügbarkeit und Belastbarkeit (Art. 32 Abs. 1 lit. b und c DSGVO)
3.1 Verfügbarkeit
Redundanz und Hochverfügbarkeit
Datenbank wird auf Primär- und Standby-Knoten gespiegelt; Failover erfolgt automatisiert. Anwendungsserver laufen auf Vercel mit Edge-Deployment (Multi-Region) und automatischer Skalierung.
Datensicherung / Backups
Tägliche automatisierte Voll-Backups der Datenbank, 30 Tage Aufbewahrung; Point-in-Time-Recovery-Funktion für die letzten 7 Tage mit Granularität von 2 Minuten. Wiederherstellbarkeit wird quartalsweise getestet.
Monitoring
24/7-Monitoring der Kerndienste (Health-Endpoint /api/health) mit automatischen Incident-Alerts an das Engineering-Team. Sentry überwacht Error-Rates und Performance-Metriken in Echtzeit.
3.2 Belastbarkeit
Rate-Limiting
Alle Authentifizierungs- und datenschreibenden Endpunkte sind rate-limitiert (Upstash-Redis, Sliding-Window-Algorithmus).
DDoS-Schutz
Vercel Edge-Netzwerk und Cloudflare Turnstile (bei Registrierung) filtern auffällige Request-Muster.
Lasttests
Quartalsweise Lasttests bis 5000 virtuelle Nutzer mit k6 auf einem Staging-Cluster; Breakpoint-Tests identifizieren frühzeitig Engpässe vor Produktiv-Rollout.
3.3 Wiederherstellbarkeit (Disaster Recovery)
RTO / RPO
Recovery Time Objective: 4 Stunden für Wiederherstellung des Dienstes nach Totalausfall. Recovery Point Objective: 5 Minuten (maximaler Datenverlust bei Totalausfall dank Point-in-Time-Recovery).
Notfall-Runbook
Dokumentierte Incident-Response-Prozesse für die häufigsten Ausfallszenarien (DB-Ausfall, Region-Ausfall, Subprozessor-Störung, Kompromittierung).
4. Verfahren zur regelmäßigen Überprüfung (Art. 32 Abs. 1 lit. d DSGVO)
4.1 Interne Kontrollen
Code-Review
Jede Code-Änderung durchläuft vor Merge eine Peer-Review. Sicherheitsrelevante Änderungen (Authentifizierung, Autorisierung, Kryptographie) erfordern zusätzlich ein Vier-Augen-Prinzip.
Automatisierte Tests
Kontinuierliche Integrationspipeline mit über 1000 automatisierten Tests (Unit, Integration, End-to-End via Playwright); Deployments werden nur bei grüner Pipeline durchgeführt.
Dependency-Scanning
Täglicher Abgleich mit Sicherheitsdatenbanken (npm audit, OSV, Snyk) für alle Dependencies; kritische CVEs werden binnen 7 Tagen gepatcht.
4.2 Externe Prüfungen
Penetration-Tests
Beauftragung eines unabhängigen Pentest-Anbieters einmal jährlich. Befunde werden nach Schweregrad priorisiert abgearbeitet.
Subprozessoren-Review
Quartalsweise Prüfung aller Subprozessoren: Gültigkeit des AVV, aktueller Zertifizierungsstatus (ISO 27001, SOC 2), dokumentierte Vorfälle und deren Behandlung.
4.3 Schulung
Datenschutz-Schulungen
Alle Mitarbeiter mit Zugriff auf personenbezogene Daten werden bei Aufnahme sowie mindestens jährlich auf Datenschutz und Informationssicherheit geschult; die Teilnahme ist dokumentiert.
Verpflichtung auf Vertraulichkeit
Alle Mitarbeiter werden gemäß Art. 29 / Art. 32 Abs. 4 DSGVO schriftlich zur Verschwiegenheit verpflichtet.
5. Meldepflichten bei Datenschutzverletzungen
Datenschutzverletzungen werden intern unverzüglich nach Bekanntwerden dokumentiert und bewertet. Bei voraussichtlichem Risiko für Rechte und Freiheiten betroffener Personen erfolgt die Meldung an die zuständige Aufsichtsbehörde (BayLDA) binnen 72 Stunden (Art. 33 DSGVO). Betroffene werden unverzüglich per E-Mail informiert, wenn voraussichtlich ein hohes Risiko besteht (Art. 34 DSGVO).
Gegenüber Auftraggebern (Kunden als Verantwortliche) erfolgt die Meldung sogar binnen 24 Stunden nach Bekanntwerden (siehe §6.6 AVV).
6. Dokumentation und Aktualisierung
Dieses TOM-Dokument wird fortlaufend an den Stand der Technik und an neue Erkenntnisse aus Pentests und Audits angepasst. Wesentliche Änderungen werden an die betroffenen Auftraggeber mindestens 30 Tage vor Inkrafttreten per E-Mail kommuniziert. Die jeweils aktuelle Fassung ist unter buchbalance.de/tom abrufbar.
Version 2.1 · Stand 24. April 2026 · Anlage 1 zum AVV · Verantwortlich: Torben Gosch, Geschäftsführer BuchBalance GmbH.