Technische und organisatorische Maßnahmen (TOMs)

Stand: 31.10.2026

Diese Maßnahmen beschreiben das derzeit vorgesehene Sicherheitsniveau von WOFLO gemäß Art. 32 DSGVO. Sie werden entsprechend Risiko, technischer Entwicklung und Systemarchitektur fortlaufend überprüft und weiterentwickelt.

1. Zutritts- und physische Sicherheit

• Produktive Serverinfrastruktur in professionellen Rechenzentren.
• Hosting der zentralen Backend-, Datenbank- und KI-Systeme in Deutschland.
• Physischer Zutritt zu Rechenzentren wird durch den Hostinganbieter kontrolliert.
• Keine produktive Serverhardware in privaten Büroräumen.

2. Zugangskontrolle

• Beschränkung öffentlich erreichbarer Serverports auf erforderliche Dienste.
• Trennung zwischen administrativen und öffentlichen Hostnamen.
• Separater administrativer Anwendungsbereich mit rollenbasierten Berechtigungen.
• Individuelle Benutzerkonten für SaaS-Nutzer.
• Geheimnisse und API-Schlüssel werden nicht im Quellcode gespeichert.

3. Zugriffskontrolle und Mandantentrennung

• Mandantenbezogene Datenmodelle.
• Serverseitige Berechtigungsprüfungen.
• Zugriff auf Objekte und Bewerberdaten nur innerhalb des zugehörigen Mandantenkontexts.
• Administrative Funktionen getrennt vom normalen Kundenfrontend.
• Datenbankzugriffe erfolgen über die Backend-Anwendung bzw. administrativ kontrollierte Zugänge.

4. Verschlüsselung

Transport

• HTTPS/TLS für öffentlich erreichbare WOFLO-Dienste.
• Aktuelle TLS-Konfiguration über Cloudflare/Caddy.
• Interne Zugriffe werden auf die notwendigen Systeme beschränkt.

Dokumente

• Bewerbungsunterlagen, individualisierte erzeugte Vertragsdokumente, neue und migrierte Signaturdateien sowie Supportanhänge in den dafür vorgesehenen Dokumentenspeichern werden anwendungsseitig verschlüsselt gespeichert.
• Einsatz von AES-256-GCM mit authentifizierter Verschlüsselung.
• Separater Dokumentenverschlüsselungsschlüssel; keine Ableitung aus dem Django-Secret.
• Versioniertes Verschlüsselungsformat mit Key-ID.
• Keine dauerhafte Speicherung entschlüsselter Dokumentkopien auf dem Produktivdatenträger.
• Leere, nicht personalisierte Vertragsvorlagen und statische Assets verbleiben außerhalb des personenbezogenen Dokumentenspeichers. Für ältere Signatur-Daten-URLs besteht ein idempotenter, integritätsgeprüfter Migrationslauf mit Dry-Run.

5. Datensicherung und Wiederherstellung

• tägliche automatisierte Backups,
• clientseitige Verschlüsselung der Backup-Repositories mit Restic,
• separates Remote-Backup bei einer Hetzner Storage Box,
• lokales und entferntes Backup-Repository,
• Remote-Aufbewahrung grundsätzlich 30 tägliche Sicherungsstände,
• kürzere lokale Aufbewahrung,
• PostgreSQL-Logical-Dump,
• Sicherung der relevanten Media-Daten,
• regelmäßige Repository-Integritätsprüfungen,
• erfolgreich getesteter isolierter Restore-Prozess,
• Restore-Test ohne Zugriff auf Produktivdatenbank oder Produktiv-Media,
• getrennte externe Aufbewahrung kritischer Recovery-Secrets vorgesehen.

30 tägliche Sicherungsstände sind keine harte Aufbewahrungsgrenze von 30 Kalendertagen. Vor einer Wiederfreigabe nach Restore müssen neuere Löschungen, Kontoschließungen und Verarbeitungssperren anhand eines unabhängig verfügbaren geschützten Nachweises nachgeführt werden; die unabhängige Verfügbarkeit dieses organisatorischen Nachweises ist vor einer Wiederfreigabe betrieblich nachzuweisen.

6. Verfügbarkeits- und Belastbarkeitsschutz

• Docker-basierte Trennung von Diensten.
• Reverse Proxy über Caddy.
• Cloudflare- und Caddy-Komponenten für Bereitstellung, TLS und Proxy-Funktionen.
• Datenbank und Redis nicht direkt öffentlich exponiert.
• Nur erforderliche Hostports werden veröffentlicht.
• Wiederherstellungsprozess für Datenbank und Media ist dokumentiert und getestet.

7. Protokollierung und Nachvollziehbarkeit

• technische Server- und Anwendungslogs,
• Sicherheits- und Fehlerprotokollierung,
• Protokollierung ausgewählter relevanter Vertrags- und Prozessaktionen,
• bei signierten Vertragsdokumenten Integritätsnachweise über Hashwerte und Auditinformationen,
• Sicherheits- und Systemlogs mit dem Ziel einer Aufbewahrung von grundsätzlich bis zu 90 Tagen; anwendungsinterne Audit- und Nachweisprotokolle können zweckgebunden länger aufbewahrt werden.

8. Datenschutzfreundliche Verarbeitung

• Datenminimierung entsprechend den vorgesehenen Vermietungsprozessen.
• Keine automatische Wohnungsvergabe.
• Kein eigener WOFLO-Eignungsscore und keine automatische Auswahlentscheidung. Bereits in Nachweisen vorhandene Einkommens-/SCHUFA-Werte können dargestellt und durch den Vermieter verglichen oder sortiert werden.
• KI-Ausgaben dienen der Unterstützung und strukturierten Aufbereitung.
• Vermieter bleibt für die eigentliche Entscheidung verantwortlich.
• Nicht vermietungsrelevante E-Mails sollen vor einer weiteren Vermietungsverarbeitung ausgesondert werden.
• Minimierte neue Phase-A-Defaults ohne Nachweise; spätere erweiterte Selbstauskunft. Konfigurierbare Anforderungen mit Hinweisen auf Erforderlichkeit und Schwärzung.
• Personenbezogene Verarbeitungseinschränkung innerhalb des Mandanten vor KI-, Dokument-, Einreichungs- und Versandabläufen; gemeinsame Lifecycle-Sperren berücksichtigen laufende Arbeit.

9. Lokale KI- und OCR-Systeme

• KI-Modelle für Bewerberinhalte werden innerhalb der WOFLO-Serverinfrastruktur betrieben.
• OCR wird lokal ausgeführt.
• Bewerberinhalte werden für die KI-Auswertung nicht an externe generative KI-Anbieter übertragen.
• Auf interne Dienstnamen, Loopback und private Netzwerkziele begrenzte KI-URLs; keine Redirects oder Übertragung über Umgebungs-Proxys.
• OCR und Dokumentextraktion laufen intern; erforderliche Extraktionen, Prüfprompts und Ergebnisse werden im Backend zweckgebunden gespeichert und in die Löschprozesse einbezogen.
• KI- und OCR-Komponenten sind nicht öffentlich als eigenständige Endpunkte zugänglich.

10. Schutz von Authentifizierungs- und OAuth-Daten

• OAuth-Tokens werden nur für aktivierte Integrationen verwendet.
• Speicherung nur im erforderlichen Umfang.
• Tokens werden bei Reautorisierung ersetzt und nach bearbeiteter Trennung oder Kontobeendigung entfernt; nicht alle Integrationen verfügen derzeit über eine automatische Self-Service-Trennung.
• OAuth-Scopes werden auf die für die jeweilige Funktion erforderlichen Berechtigungen beschränkt.
• Secrets werden außerhalb des Git-Repositories verwaltet.

11. E-Mail-Sicherheit

• getrennte öffentliche Support- und Datenschutzadressen,
• technische Prüfung eingehender Webhooks,
• Support-Anhänge werden geschützt gespeichert,
• Support-/Datenschutzpostfach wird nicht dem Bewerber-LLM-/OCR-Workflow zugeführt.

12. Löschung

• unmittelbare Dokumentbereinigung nach Absage, Rückzug oder erfolgreichem Prozessabschluss, einschließlich zugeordneter Nachweise und individualisierter Vertrags-/Signaturdateien,
• übrige Bewerber-, Nachrichten-, Review-, Aktions- und KI-Arbeitsdaten grundsätzlich drei Kalendermonate nach dokumentiertem Abschlussereignis; keine tenantindividuelle Fristenkonfiguration,
• begründete, zweckgebundene und befristete Aufbewahrungsausnahmen; gesonderte Prüfung gemeinsam genutzter oder widersprüchlich zugeordneter Daten,
• Löschungen nach Datenbank-Commit über persistente, wiederholbare Dateilöschbelege ohne Dokumentinhalt; bereits abgelehnte oder zurückgezogene Bestandsbewerbungen werden von der Dokumentbereinigung erfasst,
• gesonderte Vertragsbeendigung unabhängig von offenen Rechnungen; Sperre neuer operativer Verarbeitung unter Lifecycle-Sperren bei weiter möglicher kontrollierter Prozessbeendigung und Abrechnung bereits entstandener Ansprüche,
• endgültige Kontoschließung erst nach Vertragsbeendigung, nur durch Owner/Unternehmensadministratoren mit ausdrücklicher Bestätigung, erneuter serverseitiger Prüfung von Prozessen und Abrechnung einschließlich lesender Stripe-Prüfung,
• Deaktivierung und gespeicherter, idempotenter Bereinigungsauftrag; Fehlerstatus und erneute Bearbeitung über Scheduler oder berechtigte Administration,
• Erhalt gesetzlich notwendiger Rechnungs-/Buchhaltungsnachweise und Stripe-Abgleichreferenzen für verspätete Webhooks; kein Löschen gemeinsam genutzter Benutzerkonten oder anderer Mandanten,
• Sicherungskopien werden über gesonderte rollierende Aufbewahrung entfernt.

Die tägliche Retention und die Wiederholung bestehender Kontobereinigungsaufträge sind Bestandteil der Scheduler-Konfiguration. Betrieb und Fehlerzustände sowie Infrastruktur-Logfristen sind zu überwachen. Der konkrete Dokument-/Aufbewahrungsumfang rechtlicher Ausnahmen ist organisatorisch zu prüfen.

13. Entwicklungs- und Änderungsmanagement

• Versionsverwaltung über Git.
• Tests vor Deployment.
• Datenbankmigrationen kontrolliert über Django-Migrationsmechanismen.
• Trennung von Test- und Produktionszugangsdaten.
• Sicherheitsrelevante Infrastrukturänderungen werden geprüft und dokumentiert.
• Keine Speicherung von Produktions-Secrets im Repository.

14. Vorfallmanagement

• technische Logs zur Analyse von Sicherheitsvorfällen,
• Möglichkeit zur Sperrung bzw. Rotation kompromittierter Zugangsdaten,
• definierte Backup-/Restore-Verfahren,
• Benachrichtigung betroffener Verantwortlicher bei Datenschutzverletzungen gemäß AVV,
• Wiederherstellungs- und Integritätsprüfung im Notfall.

15. Regelmäßige Überprüfung

WOFLO überprüft diese TOMs regelmäßig und insbesondere bei wesentlichen Änderungen der Architektur, des Risikoprofils oder der eingesetzten Dienstleister.