Stand: Juni 2026

Dieses Dokument beschreibt die technischen und organisatorischen Massnahmen (TOMs) der domulex software GmbH zur Sicherstellung der Vertraulichkeit, Integritaet, Verfuegbarkeit und Belastbarkeit der Verarbeitungssysteme im Rahmen der Plattform domulex.ai (inkl. domFINANZ, domBOOKS, domINVESTOR, domCOMPLY, domCRM, domENERGY). Die TOMs werden regelmaessig geprueft und bei Bedarf fortgeschrieben. Die jeweils gueltige Fassung ist auf /toms abrufbar.

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.
Fuer Such- und Abgleichfunktionen auf sensiblen Stammdaten werden HMAC-SHA256-Pseudonyme pro Mandant und Zweck eingesetzt. Dadurch muessen E-Mail-Adressen, Namen oder vergleichbare Identifikatoren nicht breit im Klartext durchsucht werden.

1.6 Zero-Cleartext-Architektur fuer sensible Stammdaten

(1) Der Auftragnehmer verarbeitet sensible Stammdaten nach dem Zero-Cleartext-Prinzip. Danach duerfen definierte sensible Feldwerte in zentralen Stammdatenbestaenden nicht dauerhaft als allgemein lesbarer Klartextbestand vorgehalten werden, soweit die technische Umsetzung der jeweiligen Datenkategorie den feldbezogenen Schutz vorsieht.

(2) Der feldbezogene Schutz umfasst insbesondere Kontakt-, Adress-, Identifikations- und Bankdaten in Nutzer-, Kunden-, Objekt-, Einheiten-, Mitarbeiter- und Sollstellungsdaten. Der Auftragnehmer speichert diese Feldwerte verschluesselt und fuehrt Such- und Abgleichfunktionen, soweit technisch vorgesehen, ueber zweck- und mandantenbezogene Pseudonyme aus.

(3) Die Verschluesselung geschuetzter Feldwerte erfolgt serverseitig mit AES-GCM. Die hierfuer eingesetzten Schluessel werden in einem serverseitigen Secret-Management-System vorgehalten und weder im Client noch in der Datenbank im Klartext gespeichert.

(4) Der Zugriff auf geschuetzte Feldwerte erfolgt ausschliesslich ueber freigegebene Backend-Funktionen mit Mandantenpruefung und gezielter Feldfreigabe. Ein pauschaler clientseitiger Abruf ganzer sensibler Stammdatenbestaende im Klartext ist fuer die geschuetzten Lesepfade nicht vorgesehen.

(5) Fuer Altbestaende und Datenmigrationen stellt der Auftragnehmer eine Klartext-Inventur, Shadow-Migration und kontrollierte Entfernung abgeloester Klarfelder bereit. Die Inventur dient der Statuspruefung und gibt keine geschuetzten Feldinhalte, sondern nur technische Metadaten und Zaehler zurueck.

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).
Zusaetzliche feldbezogene Verschluesselung sensibler Stammdaten nach dem Zero-Cleartext-Prinzip. Klartextwerte werden nur gezielt und fluechtig ueber gepruefte Backend-Funktionen entschluesselt, soweit dies fuer die jeweilige Funktion erforderlich ist.

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).
Sicherheitsrelevante Datenmigrationen fuer geschuetzte Felder sind ueber Admin-Funktionen mit Inventur, Dry-Run, Shadow-Migration und kontrolliertem Cleanup nachvollziehbar.

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.
Regelmaessige Klartext-Inventur fuer definierte sensible Datenbestaende (z. B. Nutzer-, Kontakt-, Objekt-, Einheiten-, Mitarbeiter- und Sollstellungsdaten) zur Ueberpruefung des Zero-Cleartext-Schutzes.
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 Standardvertragsklauseln.
Externe Sicherheits-Audits durch Drittparteien werden mit zunehmender Kundenbasis durchgefuehrt.

Kontakt fuer Fragen

domulex software GmbH
Datenschutzbeauftragter
E-Mail: datenschutz@domulex.ai

Technisch-organisatorische Massnahmen (TOMs)