Anlage 2 – Technische und organisatorische Maßnahmen (TOM) nach Art. 32 DSGVO

Stand: 01/2026

1. Einleitung / System- und Datenstandort

Der Auftragnehmer betreibt die SaaS-Anwendung „Vertriebskraftwerk“ in der EU-Region europe-west3 (Frankfurt). Wesentliche Komponenten:

- Firestore-Datenbank (europe-west3)

- Cloud Functions (europe-west3)

- Cloud Storage (EU/europe-west3)

- Cloud Run API (europe-west3)

- Firebase Hosting (EU)

Subdienstleister der Cloud-Infrastruktur ist die Google Cloud Platform. Ein theoretischer Administratorzugriff durch den Cloud-Anbieter (z. B. zur Wartung) kann konzernbedingt nicht vollständig ausgeschlossen werden. Der Zugriff ist über das Data Processing Addendum (DPA) geregelt; Standardvertragsklauseln (SCC) sind implementiert.

2. Vertraulichkeit (Confidentiality)

2.1 Zutrittskontrolle (physisch)

- Physische Sicherheit der Rechenzentren wird durch den Rechenzentrumsbetreiber gewährleistet.

- Zutritt zu internen Arbeitsbereichen des Auftragnehmers erfolgt organisatorisch kontrolliert (Schließ-/Zutrittskonzept).

2.2 Zugangskontrolle (Authentifizierung)

- Nutzer-Authentifizierung über Firebase Authentication.

- Passwörter werden nicht im Klartext gespeichert, sondern via scrypt (memory-hard hashing) gehasht.

- Unterstützung von 2FA (wo aktiviert/konfiguriert).

- Schutzmechanismen gegen Brute-Force-Angriffe durch Firebase Auth sowie zusätzliche Schutzmaßnahmen auf API-Ebene (Rate Limiting, siehe Ziffer 6).

2.3 Zugriffskontrolle (Autorisierung / Berechtigungen)

- Rollen- und Rechtekonzept (RBAC) mit Rollen wie Admin, Team Admin, User, CRM Agent.

- Mandantenisolierung durch:

 - hierarchische Datenpfade (z. B. teams/{teamId}/locations/{locationId}/(weitere Unterpfade))

 - Custom Claims im Firebase Auth Token

 - Firestore Security Rules, die team_id und location_id prüfen

- Zugriff auf Betriebs-Logs ausschließlich für berechtigte Administratoren (IAM-Rolle roles/logging.viewer).

2.4 Trennungskontrolle

- Mandantenbezogene logische Trennung durch Datenmodell (Teams/Locations/Forms/Answers) und Firestore Security Rules.

- Trennung von Entwicklungs-/Testprozessen durch lokale Entwicklung mit Firebase Emulator und kontrollierte Deployment-Prozesse (siehe Ziffer 5).

3. Integrität (Integrity)

3.1 Übertragungskontrolle

- Datenübertragung über TLS 1.2+ (Firebase Hosting Standard).

- Cipher Suites nach Google Cloud Standard (u. a. ECDHE, bevorzugt AES-GCM).

- E-Mail-Transport via TLS-verschlüsseltem SMTP (secure: true).

3.2 Schutz vor Manipulation / Injection

- Parametrisierte Firestore Queries.

- Input-Validierung in Cloud Functions.

- Strukturierte Error Responses; keine Stack-Traces in Production.

3.3 Eingabekontrolle / Nachvollziehbarkeit

- Protokollierung sicherheits- und betriebsrelevanter Ereignisse (siehe Ziffer 4).

- Löschvorgänge werden mit Timestamp und betroffenen Dokumenten in Cloud Functions Logs dokumentiert.

4. Protokollierung, Monitoring und Detektion

4.1 Logging (Art und Umfang)

Erhobene Logs umfassen insbesondere:

- Authentication Events (Firebase Auth)

- Cloud Functions Ausführungen

- API-Aufrufe (inkl. Rate Limiting / Zugriffsmuster)

- Stripe Webhook Events

- Fehler und Exceptions

4.2 Speicherdauer, Speicherort, Zugriff

- Log-Speicherdauer: 30 Tage (Cloud Logging Standard).

- Speicherort: europe-west3.

- Zugriff: nur Administratoren mit IAM-Rolle roles/logging.viewer.

4.3 Monitoring / Alerting

- Technische Trigger für Sicherheits-/Betriebsvorfälle: Cloud Monitoring Alerts, ungewöhnliche Login-Aktivitäten, Fehlerrate-Spikes (siehe Ziffer 7).

5. Verfügbarkeit, Wiederherstellbarkeit und Resilienz (Availability)

5.1 Backup-Strategie

- Firestore Point-in-Time Recovery (PITR): kontinuierlich, Aufbewahrung 7 Tage, europe-west3.

- Geplante Sicherungen: wöchentlich (Sonntag), Aufbewahrung 70 Tage, europe-west3.

5.2 Wiederherstellungsziele (RPO/RTO)

- RPO: < 1 Minute (kontinuierliche PITR-Replikation)

- RTO: < 4 Stunden (Restore über Firebase Console)

- Restore-Tests: jährlicher Test mit Testdaten empfohlen; Wiederherstellung über Firebase Console oder Google Cloud Console möglich.

5.3 Release-, Deployment- und Rollback-Prozess

- Lokale Entwicklung mit Firebase Emulator.

- Code Review vor Merge; Branch Protection / Review Required in GitHub.

- Dependency Checks (z. B. npm audit, flutter pub outdated).

- Externer Penetrationstest (jährlich).

- Rollback:

 - Firebase Hosting: Instant Rollback über Konsole

 - Cloud Functions: vorherige Version reaktivierbar

- Dokumentation: Git Commit History, CHANGELOG.md.

6. API- und Schnittstellensicherheit

6.1 Rate Limiting

- Throttling: Mindestabstand 10 Sekunden.

- Daily Limit: konfigurierbar pro API-Key.

- Response Headers: X-RateLimit-Limit, X-RateLimit-Remaining, Retry-After.

6.2 CORS-Konfiguration (zugelassene Domains)

- app.vertriebskraftwerk.de

- forms.vertriebskraftwerk.de

- vertriebskraftwerk.web.app

- forms-vertriebskraftwerk.web.app

- localhost nur für Entwicklung.

6.3 Weitere Schutzmaßnahmen

- Brute-Force-Schutz: Firebase Auth built-in Protection plus Rate Limiting auf API-Ebene.

- Fehlerbehandlung: strukturierte Error Responses; keine Stack-Traces in Production.

7. Incident Response / Datenschutzvorfälle (Art. 33/34 DSGVO)

7.1 Verantwortlichkeiten

- Technische Leitung: Niklas (Entwicklung)

- Datenschutz: INSECCO (externer Datenschutzpartner)

- Geschäftsführung: Toni Rost

7.2 Eskalationskette

1) Technische Erkennung/Meldung -> Technische Leitung

2) Bewertung der Schwere -> Abstimmung mit INSECCO

3) Eindämmungsmaßnahmen -> Technische Leitung

4) Benachrichtigung Geschäftsführung -> bei relevanten Vorfällen

5) Behördenmeldung (72h) -> in Abstimmung mit INSECCO

7.3 Technische Trigger

- Cloud Monitoring Alerts (Firebase)

- Ungewöhnliche Login-Aktivitäten

- Fehlerrate-Spikes

8. Lösch- und Aufbewahrungskonzept (Datenminimierung / Speicherbegrenzung)

8.1 Standard-Löschkonzept (Formularantworten inkl. Anhänge)

- Beginn der Löschfrist: Datum der Formularübermittlung (created_at Timestamp).

- Auslöser: Cloud Scheduler (Pub/Sub), täglich 00:00 Uhr Europe/Berlin.

- Ablauf:

 1) Query aller Answers mit created_at älter als 2 Jahre

 2) Batch-Löschung in Firestore

 3) Löschung zugehöriger Dateien in Cloud Storage

 4) Logging des Löschvorgangs (Cloud Functions Logs)

- Kaskadenlöschung: Team -> Locations -> Forms -> Answers -> Attachments.

- Backup-Handling: PITR kann gelöschte Daten bis max. 7 Tage enthalten; danach endgültige Entfernung.

8.2 Optionale verkürzte Aufbewahrung für Gehalts-/Einkommensnachweise (empfohlen)

Gehalts-/Einkommensdaten sind keine besonderen Kategorien (Art. 9 DSGVO), jedoch vertrauliche Finanzdaten. Der Auftragnehmer empfiehlt, solche Nachweise vorrangig strukturiert zu erfassen (Felder) und Dokumentuploads nur soweit erforderlich zu nutzen. Sofern der Auftraggeber einen gesonderten, verkürzten Löschprozess für Einkommensnachweise wünscht (z. B. Löschung nach Abschluss der Beratung oder nach kurzer Frist), kann dies als zusätzliche Weisung/Anforderung vereinbart und technisch über separate Löschroutinen umgesetzt werden.

9. Verschlüsselung & Key Management

9.1 Verschlüsselung während der Übertragung

- TLS 1.2+ für Web/App-Verbindungen (Firebase Hosting Standard).

- TLS 1.2+ für SMTP (secure: true).

9.2 Verschlüsselung im Ruhezustand (at rest)

- Firestore/Cloud Storage: AES-256 at rest (Google-managed keys).

- Schlüsselverwaltung: Google Cloud KMS (managed).

9.3 Geheimnisse / Schlüssel / API Keys

- API-Key-Hashing: SHA-256 (nur Hash wird in der Datenbank gespeichert).

- Secrets (z. B. SMTP Host/Port) werden über Firebase Functions Secrets verwaltet.

10. E-Mail-Verarbeitung

- Transport: Nodemailer mit TLS (secure: true).

- Anbieter: Strato AG.

- Host/Port: über Firebase Functions Secrets konfiguriert.

- Zwischenspeicherung: E-Mails werden in Firestore (emails Collection) gequeued und nach erfolgreichem Versand gelöscht.

- Zustellprotokolle: Cloud Functions Logs enthalten Versandstatus.

11. Datei-Export / PDF-Verarbeitung

- PDFs werden im Speicher generiert (Uint8List), kein Zwischenspeichern auf Dateisystem.

- Signed URLs werden für temporären Zugriff auf Dateien verwendet; Gültigkeit wird über Firebase-Konfiguration gesteuert.

- Zugriffsschutz: Firebase Auth erforderlich; Berechtigungsprüfung auf Team/Location-Basis.

- Verschlüsselung: AES-256 at rest (Cloud Storage Standard).

12. KI-Modul – technische und organisatorische Schutzmaßnahmen (optional, nur bei Aktivierung)

12.1 Grundsatz

KI-Funktionen sind optional und werden nur auf Weisung/Aktivierung durch den Mandanten genutzt. Es gelten die allgemeinen TOM (Zugriffskontrolle, Protokollierung, Verschlüsselung, Mandantentrennung).

12.2 Pseudonymisierung/Referenz-ID statt Klartext-Identifikatoren

- Vor einer Übermittlung an den KI-Anbieter werden direkte Identifikatoren natürlicher Personen (insb. Name, Vorname, Anschrift sowie spezifische weitere Kontaktdaten) nicht im Klartext übertragen.

- Diese Identifikatoren werden durch eine kryptografische Referenz-ID ersetzt.

- Die Zuordnung Referenz-ID ↔ Person wird ausschließlich innerhalb der Systeme des Auftragnehmers geführt und ist gegen unbefugten Zugriff geschützt (Rollen-/Rechtekonzept, Zugriff nur nach Need-to-know).

- Der KI-Anbieter erhält keine Zuordnungsinformationen.

12.3 Minimierung und Verbote

- Standardprozess: keine besonderen Kategorien (Art. 9 DSGVO) in KI-Eingaben.

- Mandanten werden organisatorisch verpflichtet, keine Art.-9-Daten über Formulare/KI zu erheben; Ausnahmen nur nach gesonderter Vereinbarung inkl. DSFA.

12.4 Human-in-the-loop

- KI-Ergebnisse dienen der Assistenz; fachliche Bewertung/Entscheidung erfolgt durch einen menschlichen Entscheider (Human-in-the-loop).

- Es erfolgt keine ausschließlich automatisierte Entscheidung mit Rechtswirkung.

13. Penetrationstests / Schwachstellenmanagement

- Externer Penetrationstest: fernao information security GmbH, Datum 26.07.2024, Hack-Score 5.75 (mittel).

- Findings werden nach Schwere priorisiert und mit Maßnahmenplan bearbeitet.

14. Art. 9 DSGVO – Standardmäßig ausgeschlossen

Die Verarbeitung besonderer Kategorien personenbezogener Daten nach Art. 9 DSGVO ist im Standardumfang der Plattform ausgeschlossen. Der Auftraggeber ist verpflichtet, solche Daten nicht über Formulare/Uploads zu erheben oder verarbeiten zu lassen. Abweichungen sind nur nach gesonderter schriftlicher Vereinbarung, DSFA (Art. 35 DSGVO) und zusätzlichen Schutzmaßnahmen zulässig.