Technische und organisatorische Maßnahmen

Verschlüsselung im Transport

TLS 1.3 wird für die gesamte Kommunikation zwischen Endgerät und Anwendung erzwungen (HSTS mit max-age = 2 Jahre, includeSubDomains, preload). Veraltete TLS-Versionen (≤ 1.1) sind durch den Hosting-Anbieter deaktiviert.

Verschlüsselung im Ruhezustand

Personenbezogene Daten werden auf allen Speicherschichten mit AES-256 verschlüsselt: Postgres-Datenbank (verwaltet durch den EU-Datenbankanbieter), Hetzner Object Storage (Primary, Rechenzentrum Deutschland), Cloudflare R2 (EU-Mirror) sowie alle Snapshot-Backups.

Revisionssichere Belege

Hochgeladene Belege werden im S3 Object Lock Compliance Mode mit einer Aufbewahrungsfrist von 7 Jahren gespeichert. Bytes können während dieser Frist weder vom Verantwortlichen noch vom Hosting-Anbieter verändert oder gelöscht werden — die gesetzliche Aufbewahrungspflicht nach § 132 BAO wird damit technisch erzwungen.

Passwort-Hashing

Passwörter werden mit bcrypt (adaptiver Cost-Parameter) gehasht und niemals im Klartext gespeichert oder protokolliert. Der Hash-Algorithmus wird durch das Authentifizierungsmodul (Better-auth) verwaltet.

Pseudonymisierung

Interne Verweise auf personenbezogene Datensätze erfolgen über zufällige, nicht-iterierbare IDs (UUID/ULID). Application-Logs enthalten ausschließlich diese IDs, keine Klarnamen oder E-Mail-Adressen. Fehler-Reports werden serverseitig gefiltert; personenbezogene Felder werden nicht an externe Dienste übermittelt.

Zugriffskontrolle

Der Zugriff auf die Anwendung erfolgt ausschließlich nach erfolgreicher Authentifizierung (E-Mail + Passwort, optional zweiter Faktor). Sitzungen werden in HttpOnly- und Secure-Cookies mit SameSite-Schutz verwaltet. Eine Mehr-Faktor-Authentifizierung (TOTP) steht jedem Benutzer zur Verfügung und wird empfohlen.

Rollenbasiertes Berechtigungsmodell

Innerhalb eines Mandanten existieren die Rollen Inhaber (Owner) und Mitglied (Staff) mit Schreibrechten sowie die Rolle Konsulent (Kanzlei-Admin, Kanzlei-Mitglied) mit reinem Lesezugriff. Schreibversuche durch Konsulenten werden serverseitig blockiert (siehe `src/lib/security/api-guards.ts`).

Mandantentrennung

Sämtliche fachlichen Datensätze sind mit einer Mandanten-ID (account_id) verknüpft. Datenbank-Abfragen filtern verpflichtend auf diese ID; zusätzlich wird bei nachgelagerten Joins eine serverseitige Tenancy-Assertion ausgeführt, die mandantenübergreifende Zugriffe mit HTTP 403 ablehnt.

Solo-Operator-Modell

Es gibt derzeit keine weiteren Mitarbeitenden. Der Verantwortliche <<FOUNDER_NAME>> ist allein zugriffsberechtigt auf Produktivsysteme, Datenbankschnittstellen und Verwaltungskonsolen der Sub-Verarbeiter. Bei einer Personaleinstellung werden vor Erteilung von Produktivzugriffen schriftliche Vertraulichkeitserklärungen (Art 28 Abs 3 lit b DSGVO analog) sowie ein dokumentiertes Berechtigungskonzept eingeführt.

Vertraulichkeit der Sub-Verarbeiter

Alle Sub-Verarbeiter sind vertraglich gemäß Art 28 Abs 3 lit b DSGVO zur Vertraulichkeit verpflichtet (Standard-AVV bzw. Data Processing Addendum des jeweiligen Anbieters). Die vollständige Liste samt Drittland-Sicherungen ist unter https://<<DOMAIN>>/legal/datenschutz/subprocessors einsehbar.

Audit-Log

Sicherheitsrelevante Zustandsänderungen (Anmeldungen, Rollenänderungen, Belegfreigaben, Export-Erzeugungen, Konsulentenwechsel) werden in einem applikationsinternen Audit-Log mit Zeitstempel, Akteur-ID und Request-ID protokolliert (`src/lib/observability/`, Domain-Modul `audit/`).

Unveränderbarkeit von Belegen

Hochgeladene Belege werden im Object Lock Compliance Mode bytewise unveränderlich gespeichert. Eine nachträgliche Manipulation ist technisch ausgeschlossen; Korrekturen erfolgen ausschließlich durch Storno und erneuten Upload — das Original bleibt erhalten.

Eingabevalidierung

Sämtliche eingehende Daten (Formulare, API-Requests, Hintergrundjobs) werden serverseitig mit typisierten Schemata (Zod) validiert. Clientseitige Validierung dient ausschließlich der Benutzerführung und wird niemals als alleinige Sicherung verwendet.

Sicherheits-Header

Eine strikte Content Security Policy, X-Content-Type-Options, X-Frame-Options DENY, Referrer-Policy strict-origin-when-cross-origin sowie eine restriktive Permissions-Policy werden für jede Antwort gesendet (siehe `src/lib/security/headers.ts`).

Geografische Redundanz

Beleg-Inhalte werden primär im Hetzner Object Storage in Deutschland gespeichert und kontinuierlich in einen Cloudflare-R2-Mirror in der EU repliziert. Beide Standorte liegen innerhalb des EWR; ein Drittland-Transfer findet bei der Speicherung nicht statt.

Datenbank-Backups

Die Postgres-Datenbank wird vom EU-Datenbankanbieter mit täglichen Snapshots und Point-in-Time Recovery (PITR) gesichert. Die Aufbewahrungsfrist und das Recovery-Time-Objective des Anbieters werden vertraglich zugesichert.

Hintergrundjobs

Lang laufende Verarbeitungen (Belegerkennung, Exporterzeugung, E-Mail-Versand) laufen über Trigger.dev v3 mit persistenter Warteschlange, automatischen Wiederholungen mit Backoff und Idempotenz. Ein Ausfall einzelner Worker führt nicht zu Datenverlust.

Hosting-Plattform

Die Anwendung läuft auf Vercel mit Rechenzentrum-Auswahl Frankfurt (fra1). Plattformseitig stehen DDoS-Schutz und eine Web Application Firewall zur Verfügung; Skalierung erfolgt automatisch.

Wiederherstellungsverfahren

Im Schadensfall werden Datenbank-Inhalte aus dem letzten Snapshot bzw. per Point-in-Time Recovery wiederhergestellt; Beleg-Inhalte werden bei Ausfall des Primärspeichers aus dem EU-Mirror gelesen. Die Anwendungskonfiguration ist vollständig im Quellcode versioniert und kann jederzeit neu deployt werden.

Wiederherstellungsziel

Angestrebt wird eine Wiederherstellung des Lesezugriffs auf Belege innerhalb von 4 Stunden und die volle Wiederherstellung des Schreibzugriffs innerhalb von 24 Stunden nach Feststellung eines Totalausfalls. Diese Werte sind Zielwerte ohne vertragliche Service-Level-Zusage.

Testfrequenz

Das Wiederherstellungsverfahren wird mindestens einmal jährlich sowie nach wesentlichen Architekturänderungen in einer isolierten Umgebung getestet. Ergebnis und Datum werden intern dokumentiert.

Quartalsweise Selbstüberprüfung

Die in diesem Dokument beschriebenen Maßnahmen werden vom Verantwortlichen mindestens einmal pro Quartal überprüft. Festgestellte Abweichungen werden zeitnah behoben; wesentliche Änderungen führen zu einer aktualisierten Version dieses Dokuments mit angepasstem Stand-Datum.

Sicherheits-Updates

Abhängigkeiten der Anwendung werden automatisiert auf bekannte Schwachstellen geprüft (Dependabot / Renovate). Kritische Sicherheits-Patches (CVSS ≥ 7,0) werden innerhalb von 7 Tagen nach Verfügbarkeit eingespielt; Patches der Schwere „kritisch” (CVSS ≥ 9,0) so rasch wie möglich, in der Regel innerhalb von 48 Stunden.

Penetrationstests

Penetrationstests werden bei wesentlichen Architekturänderungen sowie bei Bedarf durchgeführt. Ein turnusmäßiger externer Pentest ist nicht vertraglich zugesichert; Ergebnisse interner Reviews werden im Repository unter `SECURITY_AUDIT.md` versioniert dokumentiert.

Allgemeine Genehmigung weiterer Sub-Verarbeiter

Der Verantwortliche setzt Sub-Verarbeiter mit allgemeiner schriftlicher Genehmigung gemäß Art 28 Abs 2 Satz 2 DSGVO ein. Beabsichtigte Änderungen (Hinzufügung oder Austausch) werden Kunden mindestens 30 Tage im Voraus per E-Mail und durch Aktualisierung der Sub-Verarbeiter-Liste angekündigt. Innerhalb dieser Frist kann der Kunde der Änderung widersprechen.

Sub-Verarbeiter-Liste

Die vollständige, jeweils aktuelle Liste der eingesetzten Sub-Verarbeiter mit Sitz, Zweck und Rechtsgrundlage einer etwaigen Drittland-Übermittlung ist unter https://<<DOMAIN>>/legal/datenschutz/subprocessors einsehbar.

Drittland-Übermittlung

Sofern Sub-Verarbeiter mit Sitz in den USA eingesetzt werden, beruht die Übermittlung primär auf der Zertifizierung nach dem EU-US Data Privacy Framework (Adäquanzbeschluss der Kommission vom 10.07.2023). Ergänzend werden Standardvertragsklauseln (Modul 2 oder 3, Durchführungsbeschluss (EU) 2021/914) abgeschlossen und ein dokumentiertes Transfer Impact Assessment (TIA) gemäß Schrems-II-Rechtsprechung durchgeführt.

Eingabekontrolle

Sicherheitsrelevante Eingaben und Änderungen werden im Audit-Log mit Akteur, Zeitstempel und Request-ID protokolliert (siehe Abschnitt 3). Eingabevalidierung erfolgt serverseitig mit Zod-Schemata.

Weitergabekontrolle

Transportverschlüsselung mit TLS 1.3 (siehe Abschnitt 1); Drittlandübermittlung ausschließlich auf Grundlage von DPF, SCC und TIA (siehe Abschnitt 7); keine Datenverkäufe und keine Werbe-Tracker (siehe Cookie-Information).

Auftragskontrolle

Schriftlicher Auftragsverarbeitungsvertrag mit jedem Sub-Verarbeiter; allgemeine Genehmigung mit 30-Tage-Widerspruchsfrist (siehe Abschnitt 7); öffentliches Sub-Verarbeiter-Verzeichnis.

Trennungskontrolle

Mandantenbezogene Trennung über account_id-Filter in der Datenbank und serverseitige Tenancy-Assertions (siehe Abschnitt 2); strikte Trennung zwischen Produktiv-, Staging- und Entwicklungsumgebung; keine Verarbeitung von Produktivdaten in Entwicklungsumgebungen.

Erkennung

Sicherheitsvorfälle werden über den serverseitigen Fehler-Reporter (`src/lib/observability/error-reporter.ts`), Anomalie-Meldungen der Hosting- und Datenbankanbieter sowie Hinweise von Benutzern oder Dritten erkannt. Auffälligkeiten im Audit-Log werden bei der quartalsweisen Überprüfung kontrolliert.

Interne Eskalation

Bei Bekanntwerden einer Verletzung des Schutzes personenbezogener Daten wird unverzüglich eine schriftliche Erstbewertung erstellt (betroffene Daten, vermutete Ursache, ergriffene Sofortmaßnahmen).

Meldung an den Verantwortlichen (bei Auftragsverarbeitung)

Soweit <<FOUNDER_NAME>> für Beleg-Inhalte als Auftragsverarbeiter tätig ist (vgl. Datenschutzerklärung, Abschnitt „Rollen”), wird der jeweils betroffene Verantwortliche (Mandant) gemäß Art 33 Abs 2 DSGVO unverzüglich, spätestens jedoch innerhalb von 24 Stunden ab Kenntnisnahme, schriftlich benachrichtigt. Diese 24-Stunden-Frist ist bewusst strenger gewählt als die 72-Stunden-Frist des Verantwortlichen gegenüber der Aufsichtsbehörde, um diesem ausreichend Reaktionszeit zu lassen.

Meldung an die Datenschutzbehörde

Soweit <<FOUNDER_NAME>> selbst Verantwortlicher ist (Konto-, Profil- und Abrechnungsdaten), erfolgt die Meldung an die österreichische Datenschutzbehörde gemäß Art 33 Abs 1 DSGVO binnen 72 Stunden ab Kenntnisnahme, sofern die Verletzung voraussichtlich zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt.

Benachrichtigung Betroffener

Bei voraussichtlich hohem Risiko für die Rechte und Freiheiten natürlicher Personen werden die Betroffenen gemäß Art 34 DSGVO unverzüglich benachrichtigt.

Datenminimierung

Im Registrierungs- und Onboarding-Prozess werden ausschließlich die für den Betrieb erforderlichen Daten erhoben (E-Mail, Passwort, Firmenname; UID-Nummer optional für die Rechnungserstellung). Keine Erhebung von Profilbildern, Geburtsdaten, Geschlecht oder vergleichbaren Merkmalen.

Sichere Voreinstellungen

Sitzungs-Cookies sind standardmäßig HttpOnly, Secure und SameSite=Lax gesetzt. Die Mehr-Faktor-Authentifizierung steht jedem Benutzer ohne Aufpreis zur Verfügung. Sub-Verarbeiter für KI-Verarbeitung (Mistral, Anthropic) werden ausschließlich in Tarifen verwendet, in denen die übermittelten Inhalte nicht für das Modell-Training genutzt werden („no-training”).

Kein Tracking ohne Notwendigkeit

Auf der Marketing-Website werden keine Analyse-, Marketing- oder Werbedienste eingebunden. Im angemeldeten Bereich werden ausschließlich technisch notwendige bzw. funktionale Cookies gesetzt (siehe Cookie-Information).