Für hopps ist eine DSGVO-Strategie kein einzelnes Ticket, sondern ein Programm mit vier parallel laufenden Strängen: Dateninventar, rechtlich-organisatorische Absicherung, technische Maßnahmen und Betriebsprozesse. Aus der Codebasis sieht man schon, dass ihr personenbezogene und teils sensible Finanzdaten verarbeitet: Mitglieder mit Name/E-Mail in Member.java, Organisationsstammdaten inkl. Adresse, E-Mail, Telefon und Steuernummer in Organization.java, Belege mit Dateiinhalt, Metadaten, Rechnungs- und Gegenparteidaten in Document.java sowie Transaktionen mit Absender-/Empfängerdaten in Transaction.java. Dazu kommen externe Verarbeitungen über Azure Document AI und OpenAI-Schlüssel laut README.md und AzureAiService.java. Das macht DSGVO hier zu einem echten Produkt- und Betriebs-Thema, nicht nur zu einer Website-Aufgabe.
Empfohlene Umsetzungsstrategie
Phase 1: Governance und Scope festziehen
Definiert sofort, ob ihr gerade die SaaS-Variante, Self-Hosted oder beides abdecken wollt. Für SaaS seid ihr Verantwortlicher für Vereins- und Mitgliedsdaten; für Self-Hosted verschiebt sich ein Teil der Pflichten auf den Betreiber, aber Produkt, Doku und Default-Konfigurationen bleiben relevant. Ergebnis dieser Phase: Verantwortlichkeiten, benannter Projekt-Owner, Einbindung externer Rechtsberatung, Verzeichnis der Verarbeitungstätigkeiten, Liste aller Auftragsverarbeiter, Entscheidung ob ein DSB nötig ist, und ein verbindlicher Risikokatalog.
Phase 2: Dateninventar und Datenflüsse dokumentieren
Erstellt eine vollständige Datenlandkarte aus Produkt und Infrastruktur. Für hopps muss sie mindestens folgende Flüsse abdecken: Login und Benutzerverwaltung über Keycloak in auth.service.ts, Dateiupload und S3/MinIO-Speicherung über DocumentResource.java und DocumentFileService.java, OCR/Extraktion über ScanDocumentResource.java, sowie mobile Token-Speicherung in SecureStore in AuthContext.tsx. Ergebnis: Datenarten, Zweck, Rechtsgrundlage, Empfänger, Speicherort, Speicherfrist, Löschregel, internationaler Transfer.
Phase 3: Kritische Rechts- und Architekturentscheidungen
Hier müsst ihr die größten DSGVO-Hebel entscheiden:
Dürfen Belegdaten an Azure Document AI und OpenAI übertragen werden?
In welcher Region werden diese Dienste betrieben?
Braucht ihr EU-Regionen, SCCs, Transfer Impact Assessment und AV-Verträge?
Wird KI-Verarbeitung standardmäßig aktiviert oder optional pro Organisation?
Welche Daten sind gesetzlich aufzubewahren und welche nicht?
Ohne diese Entscheidungen wird jede technische Umsetzung später wieder umgebaut.
Phase 4: Product Compliance Backlog priorisieren
Daraus wird ein umsetzbares Delivery-Programm mit Epics:
Datenschutzhinweise und Transparenz im Produkt
Rechte der Betroffenen: Auskunft, Berichtigung, Löschung, Export
Lösch- und Aufbewahrungskonzept
Einwilligungs-/Konfigurationslogik für optionale KI-Verarbeitung
Zugriffsschutz, Mandantentrennung, Rollenmodell
Logging, Incident Response, Breach-Management
Vendor- und Vertragsmanagement
TOMs, Backup, Verschlüsselung, Geheimnis- und Berechtigungskonzept
Was für hopps konkret in den Backlog muss
Euer größter Pflichtblock ist Datenminimierung und Speicherbegrenzung. Aktuell werden Dateien, Analyseergebnisse, Gegenparteidaten und Transaktionen dauerhaft persistiert; Upload und Löschung sind da, aber eine nachweisbare Aufbewahrungs- und Löschstrategie sehe ich in der Codebasis nicht. DELETE /documents/{id} löscht Datei und Datenobjekt in DocumentResource.java, aber es fehlt die übergreifende Policy: wann löschen, wann sperren statt löschen, wie mit steuerrechtlicher Aufbewahrung umgehen, wie Backups behandeln, wie Löschjobs und Nachweise geführt werden.
Der zweite große Block ist Drittland- und Auftragsverarbeitung. Durch Azure Document AI und OpenAI-bezogene Konfigurationen habt ihr sehr wahrscheinlich externe Auftragsverarbeiter im Kernprozess. Dafür braucht ihr vor Go-Live AVV/DPA, Rechtsgrundlagen, technische Bewertung, Transferprüfung und transparente Nutzerinformation. Projektseitig sollte daraus ein eigenes Workstream mit Legal, Infra und Product entstehen.
Der dritte Block ist Betroffenenrechte operabel machen. Für SaaS braucht ihr einen standardisierten Prozess für Auskunft, Berichtigung, Löschung, Einschränkung und Datenexport. Produktseitig heißt das: Admin-UI oder interne Ops-Runbooks, die Mitglieds-, Organisations-, Dokument- und Transaktionsdaten organisationsbezogen exportieren und löschen können. Aktuell ist funktionale Löschung teilweise vorhanden, aber kein kompletter DSAR-Prozess erkennbar.
Der vierte Block ist Security by Default. Positiv: mobile Tokens liegen in SecureStore, und die Helm-Werte enthalten solide Container-Sicherheitsdefaults in values.yaml. Kritisch: In der lokalen Compose-Konfiguration finden sich klar unsichere Defaults wie deaktiviertes OIDC bzw. permit in docker-compose.yaml. Das ist für Dev okay, muss aber sauber von produktionsfähigen Defaults, Dokumentation und Compliance-Aussagen getrennt werden.
Empfohlene Projektstruktur für die Umsetzung
Stream A: Legal & Governance
Verantwortlich für VVT, AVV/DPA, TOMs, Datenschutzerklärung, Vertragswerk, Rollenklärung SaaS vs Self-Hosted.
Stream B: Product & UX
Verantwortlich für Transparenz, Einwilligungslogik falls nötig, Export-/Löschfunktionen, Admin-Flows, KI-Einstellungen pro Organisation.
Stream C: Engineering & Security
Verantwortlich für Löschjobs, Auditierbarkeit, Backup-Konzept, Verschlüsselung, Secrets, Berechtigungen, Logging-Härtung, Data Mapping.
Stream D: Operations & Support
Verantwortlich für Incident-Prozess, DSAR-SLA, Support-Handbuch, Breach-Runbook, Vendor-Review, Release-Gates.
Pragmatischer Rollout in 90 Tagen
0-30 Tage
Scope festlegen, Dateninventar abschließen, Vendor-Liste fertigstellen, kritische Rechtsfragen entscheiden, Risikoregister anlegen, DSGVO-Epics schneiden.
30-60 Tage
Datenschutzhinweise, Lösch-/Aufbewahrungskonzept, DSAR-Prozess, AVV/TOMs, KI-Konfiguration, technische Gaps priorisieren und umsetzen.
60-90 Tage
Export-/Löschfähigkeit produktiv machen, Security-Hardening abschließen, Incident/Breach-Runbook testen, Go-Live-Checkliste und Freigabe.
Definition of Done für eine belastbare DSGVO-Strategie
Alle Verarbeitungstätigkeiten und Systeme sind dokumentiert.
Für jeden externen Dienst existiert eine rechtliche und technische Freigabe.
Für jede Datenkategorie gibt es Rechtsgrundlage, Frist und Löschregel.
Betroffenenrechte sind nicht nur beschrieben, sondern operativ ausführbar.
Sicherheitsmaßnahmen und Zuständigkeiten sind getestet.
SaaS und Self-Hosted sind datenschutzrechtlich sauber getrennt beschrieben.
Wenn du willst, mache ich daraus im nächsten Schritt direkt einen konkreten DSGVO-Umsetzungsplan für hopps mit Epics, Arbeitspaketen, Verantwortlichen, Reihenfolge und einer Go-Live-Checkliste.
Für hopps ist eine DSGVO-Strategie kein einzelnes Ticket, sondern ein Programm mit vier parallel laufenden Strängen: Dateninventar, rechtlich-organisatorische Absicherung, technische Maßnahmen und Betriebsprozesse. Aus der Codebasis sieht man schon, dass ihr personenbezogene und teils sensible Finanzdaten verarbeitet: Mitglieder mit Name/E-Mail in Member.java, Organisationsstammdaten inkl. Adresse, E-Mail, Telefon und Steuernummer in Organization.java, Belege mit Dateiinhalt, Metadaten, Rechnungs- und Gegenparteidaten in Document.java sowie Transaktionen mit Absender-/Empfängerdaten in Transaction.java. Dazu kommen externe Verarbeitungen über Azure Document AI und OpenAI-Schlüssel laut README.md und AzureAiService.java. Das macht DSGVO hier zu einem echten Produkt- und Betriebs-Thema, nicht nur zu einer Website-Aufgabe.
Empfohlene Umsetzungsstrategie
Phase 1: Governance und Scope festziehen
Definiert sofort, ob ihr gerade die SaaS-Variante, Self-Hosted oder beides abdecken wollt. Für SaaS seid ihr Verantwortlicher für Vereins- und Mitgliedsdaten; für Self-Hosted verschiebt sich ein Teil der Pflichten auf den Betreiber, aber Produkt, Doku und Default-Konfigurationen bleiben relevant. Ergebnis dieser Phase: Verantwortlichkeiten, benannter Projekt-Owner, Einbindung externer Rechtsberatung, Verzeichnis der Verarbeitungstätigkeiten, Liste aller Auftragsverarbeiter, Entscheidung ob ein DSB nötig ist, und ein verbindlicher Risikokatalog.
Phase 2: Dateninventar und Datenflüsse dokumentieren
Erstellt eine vollständige Datenlandkarte aus Produkt und Infrastruktur. Für hopps muss sie mindestens folgende Flüsse abdecken: Login und Benutzerverwaltung über Keycloak in auth.service.ts, Dateiupload und S3/MinIO-Speicherung über DocumentResource.java und DocumentFileService.java, OCR/Extraktion über ScanDocumentResource.java, sowie mobile Token-Speicherung in SecureStore in AuthContext.tsx. Ergebnis: Datenarten, Zweck, Rechtsgrundlage, Empfänger, Speicherort, Speicherfrist, Löschregel, internationaler Transfer.
Phase 3: Kritische Rechts- und Architekturentscheidungen
Hier müsst ihr die größten DSGVO-Hebel entscheiden:
Dürfen Belegdaten an Azure Document AI und OpenAI übertragen werden?
In welcher Region werden diese Dienste betrieben?
Braucht ihr EU-Regionen, SCCs, Transfer Impact Assessment und AV-Verträge?
Wird KI-Verarbeitung standardmäßig aktiviert oder optional pro Organisation?
Welche Daten sind gesetzlich aufzubewahren und welche nicht?
Ohne diese Entscheidungen wird jede technische Umsetzung später wieder umgebaut.
Phase 4: Product Compliance Backlog priorisieren
Daraus wird ein umsetzbares Delivery-Programm mit Epics:
Datenschutzhinweise und Transparenz im Produkt
Rechte der Betroffenen: Auskunft, Berichtigung, Löschung, Export
Lösch- und Aufbewahrungskonzept
Einwilligungs-/Konfigurationslogik für optionale KI-Verarbeitung
Zugriffsschutz, Mandantentrennung, Rollenmodell
Logging, Incident Response, Breach-Management
Vendor- und Vertragsmanagement
TOMs, Backup, Verschlüsselung, Geheimnis- und Berechtigungskonzept
Was für hopps konkret in den Backlog muss
Euer größter Pflichtblock ist Datenminimierung und Speicherbegrenzung. Aktuell werden Dateien, Analyseergebnisse, Gegenparteidaten und Transaktionen dauerhaft persistiert; Upload und Löschung sind da, aber eine nachweisbare Aufbewahrungs- und Löschstrategie sehe ich in der Codebasis nicht. DELETE /documents/{id} löscht Datei und Datenobjekt in DocumentResource.java, aber es fehlt die übergreifende Policy: wann löschen, wann sperren statt löschen, wie mit steuerrechtlicher Aufbewahrung umgehen, wie Backups behandeln, wie Löschjobs und Nachweise geführt werden.
Der zweite große Block ist Drittland- und Auftragsverarbeitung. Durch Azure Document AI und OpenAI-bezogene Konfigurationen habt ihr sehr wahrscheinlich externe Auftragsverarbeiter im Kernprozess. Dafür braucht ihr vor Go-Live AVV/DPA, Rechtsgrundlagen, technische Bewertung, Transferprüfung und transparente Nutzerinformation. Projektseitig sollte daraus ein eigenes Workstream mit Legal, Infra und Product entstehen.
Der dritte Block ist Betroffenenrechte operabel machen. Für SaaS braucht ihr einen standardisierten Prozess für Auskunft, Berichtigung, Löschung, Einschränkung und Datenexport. Produktseitig heißt das: Admin-UI oder interne Ops-Runbooks, die Mitglieds-, Organisations-, Dokument- und Transaktionsdaten organisationsbezogen exportieren und löschen können. Aktuell ist funktionale Löschung teilweise vorhanden, aber kein kompletter DSAR-Prozess erkennbar.
Der vierte Block ist Security by Default. Positiv: mobile Tokens liegen in SecureStore, und die Helm-Werte enthalten solide Container-Sicherheitsdefaults in values.yaml. Kritisch: In der lokalen Compose-Konfiguration finden sich klar unsichere Defaults wie deaktiviertes OIDC bzw. permit in docker-compose.yaml. Das ist für Dev okay, muss aber sauber von produktionsfähigen Defaults, Dokumentation und Compliance-Aussagen getrennt werden.
Empfohlene Projektstruktur für die Umsetzung
Stream A: Legal & Governance
Verantwortlich für VVT, AVV/DPA, TOMs, Datenschutzerklärung, Vertragswerk, Rollenklärung SaaS vs Self-Hosted.
Stream B: Product & UX
Verantwortlich für Transparenz, Einwilligungslogik falls nötig, Export-/Löschfunktionen, Admin-Flows, KI-Einstellungen pro Organisation.
Stream C: Engineering & Security
Verantwortlich für Löschjobs, Auditierbarkeit, Backup-Konzept, Verschlüsselung, Secrets, Berechtigungen, Logging-Härtung, Data Mapping.
Stream D: Operations & Support
Verantwortlich für Incident-Prozess, DSAR-SLA, Support-Handbuch, Breach-Runbook, Vendor-Review, Release-Gates.
Pragmatischer Rollout in 90 Tagen
0-30 Tage
Scope festlegen, Dateninventar abschließen, Vendor-Liste fertigstellen, kritische Rechtsfragen entscheiden, Risikoregister anlegen, DSGVO-Epics schneiden.
30-60 Tage
Datenschutzhinweise, Lösch-/Aufbewahrungskonzept, DSAR-Prozess, AVV/TOMs, KI-Konfiguration, technische Gaps priorisieren und umsetzen.
60-90 Tage
Export-/Löschfähigkeit produktiv machen, Security-Hardening abschließen, Incident/Breach-Runbook testen, Go-Live-Checkliste und Freigabe.
Definition of Done für eine belastbare DSGVO-Strategie
Alle Verarbeitungstätigkeiten und Systeme sind dokumentiert.
Für jeden externen Dienst existiert eine rechtliche und technische Freigabe.
Für jede Datenkategorie gibt es Rechtsgrundlage, Frist und Löschregel.
Betroffenenrechte sind nicht nur beschrieben, sondern operativ ausführbar.
Sicherheitsmaßnahmen und Zuständigkeiten sind getestet.
SaaS und Self-Hosted sind datenschutzrechtlich sauber getrennt beschrieben.
Wenn du willst, mache ich daraus im nächsten Schritt direkt einen konkreten DSGVO-Umsetzungsplan für hopps mit Epics, Arbeitspaketen, Verantwortlichen, Reihenfolge und einer Go-Live-Checkliste.