Technisch-organisatorische Massnahmen (TOMs)

Stand: Mai 2026

1. Vertraulichkeit

1.1 Zutrittskontrolle

• Hosting auf Google Cloud Platform, Hauptregion europe-west3 (Frankfurt am Main).
• Die Rechenzentren sind nach ISO/IEC 27001, ISO/IEC 27017 und ISO/IEC 27018 zertifiziert (Zertifizierung der Google Cloud Platform).
• Buero-Arbeitsplaetze des Auftragnehmers sind durch Schliesssystem und Alarmanlage geschuetzt; Zugang nur fuer berechtigte Personen.
• Besucher werden begleitet und protokolliert.

1.2 Zugangskontrolle (Systemzugang)

• Authentifizierung ueber Firebase Authentication mit Passwort-Mindestlaenge, Komplexitaetsanforderungen und automatischer Sperre nach Fehlversuchen.
• Zwei-Faktor-Authentifizierung verfuegbar; fuer Administrator-Konten verpflichtend.
• App Check (reCAPTCHA v3) reduziert automatisierte Angriffe.
• Sitzungs-Tokens mit kurzer Lebensdauer; Refresh-Token-Rotation.
• SSH-Zugriffe nur ueber Schluesselauthentifizierung; keine Passwort-Logins.

1.3 Zugriffskontrolle (Datenzugang)

• Rollenbasiertes Berechtigungskonzept (Eigentuemer / Mitarbeiter / externer Datenschutzbeauftragter / Plattform-Admin) mit Custom Claims im Token.
• Strikte Mandantentrennung ueber Firestore-Sicherheitsregeln (User-UID als Tenant-Schluessel) sowie ueber Backend-Pruefungen.
• Append-only-Audit-Log fuer Compliance-relevante Aktionen (audit_log, comply_versions) mit Schreibschutz fuer Clients (Write-Once / WORM).
• Vier-Augen-Prinzip in domCOMPLY: Entwurf -> Pruefung -> Freigabe.
• Need-to-Know-Prinzip fuer Mitarbeiter des Auftragnehmers.

1.4 Trennungsgebot

• Logische Trennung pro Mandant (User-UID).
• Kein Cross-Mandanten-Lesezugriff durch Firestore-Rules technisch ausgeschlossen.
• Trennung von Produktiv- und Entwicklungsumgebung.
• Externe Datenschutzbeauftragte erhalten Lesezugriff nur auf die Daten der Mandanten, die sie eigens beauftragt haben.

1.5 Pseudonymisierung & Datensparsamkeit

• Audit-Log: Lokal-Teil von E-Mail-Adressen wird maskiert.
• IP-Adressen, soweit gespeichert, gekuerzt verarbeitet.
• Eingaben in KI-Module werden nicht zu Trainingszwecken weiterverwendet.

2. Integritaet

2.1 Weitergabekontrolle

• TLS 1.2/1.3 fuer alle Daten-Uebertragungen.
• Verschluesselung ruhender Daten in Firestore und Cloud Storage durch GCP (AES-256, Google-managed Keys).
• Anwendungsseitige Verschluesselung besonders sensibler Felder (insbesondere SMTP-Passwoerter externer E-Mail-Konten der Kunden) mittels Fernet (AES-128 CBC + HMAC). Der Schluessel wird ausschliesslich im Cloud-Run-Environment des Auftragnehmers vorgehalten und nicht in Firestore gespeichert; Klartext-Anmeldedaten existieren nur fluechtig zur Laufzeit der Verbindung zum E-Mail-Hoster.
• Keine Datenuebertragung in Drittlaender ohne Standardvertragsklauseln und Risikoanalyse (TIA).
• Versand sensibler Dokumente nur ueber gesicherte Kanaele (HTTPS-Download aus Plattform, signierte URLs).
• Anwendungsseitige Verschluesselung sensibler Felder (insbesondere SMTP-Passwoerter externer E-Mail-Konten der Kunden) mittels Fernet (AES-128 CBC + HMAC); Schluessel wird im Cloud-Run-Environment des Auftragnehmers vorgehalten und nicht in Firestore gespeichert. Klartext- Anmeldedaten existieren ausschliesslich fluechtig zur Laufzeit der Verbindung zum E-Mail-Hoster.

2.2 Eingabekontrolle

• Protokollierung sicherheitsrelevanter Aktionen (Anmeldung, Aenderung, Loeschung, Freigabe) mit Zeitstempel und Akteur-ID.
• Schreibgeschuetztes Audit-Log via Firestore-Rules.
• Versionierung freigegebener Compliance-Eintraege (Snapshot pro Approval).

3. Verfuegbarkeit und Belastbarkeit

3.1 Verfuegbarkeitskontrolle

• Mehrfachredundante Speicherung in Firestore (Multi-Zonen).
• Cloud Functions skalieren automatisch; DDoS-Basisschutz von Google Cloud.
• Hosting-Plattform mit 99,95 % SLA.
• Regelmaessige Datenexporte / Backup-Snapshots.
• Wiederherstellungstests werden im Rahmen des Betriebshandbuchs durchgefuehrt.

3.2 Rasche Wiederherstellbarkeit

• Infrastructure-as-Code (Firebase-Konfiguration, Functions-Quellcode in Git).
• Wiederherstellungsziel (RTO): 24 Stunden.
• Wiederherstellungspunkt (RPO): 24 Stunden.

4. Verfahren zur regelmaessigen Pruefung, Bewertung und Evaluierung

• Jaehrliche Pruefung dieser TOMs durch den internen oder externen Datenschutzbeauftragten.
• Anlassbezogene Pruefung bei Aenderungen von Diensten oder Risiken.
• Schwachstellen-Reviews und Abhaengigkeits-Updates regelmaessig.
• Externe Sicherheits-Audits (Pentest, Code-Review) werden eingefuehrt, sobald die Plattform den entsprechenden Reifegrad erreicht hat.
• Mitarbeiter-Schulung zu Datenschutz und Informationssicherheit jaehrlich, Onboarding-Modul fuer Neueinstellungen.

5. Auftragskontrolle

• Verarbeitung ausschliesslich gemaess Hauptvertrag und Weisung des Kunden.
• Auswahl von Unterauftragnehmern nach DSGVO-konformen Kriterien; Auflistung im AVV unter § 7.
• Vertraege gemaess Art. 28 DSGVO mit allen Unterauftragnehmern, soweit nicht im Standard-DPA von Google bereits abgedeckt.
• Externe Datenschutzbeauftragte des Kunden sind keine Unterauftragnehmer (Art. 38 DSGVO unabhaengig).

6. Datenschutz-Vorfaelle

• Reaktionsplan fuer Datenschutz-Vorfaelle mit interner Eskalationsmatrix.
• Meldung an den Auftraggeber unverzueglich, spaetestens innerhalb von 24 Stunden.
• Vorlage fuer Aufsichts- und Betroffenenmeldung im Modul domCOMPLY hinterlegt.

7. Bekannte Beschraenkungen

• Die ISO/IEC 27001-Zertifizierung des Auftragnehmers selbst ist nicht vorhanden; die Beratungsstruktur folgt jedoch dem Standard.
• Fuer Firebase Authentication koennen Auth-Metadaten gemaess Google-DPA in weiteren Google-Regionen verarbeitet werden; Schutz durch Standard­vertrags­klauseln.
• Externe Sicherheits-Audits durch Drittparteien werden mit zunehmender Kundenbasis durchgefuehrt.