Lars
04663e090a
- compliance-implementation.md: expand P-13 section with all extensions (0.8.88-0.8.94: audit log, email notifications, club-admin rights, workflow bar, archive split, badge, CI fix); update test summary to 159 passed; add operativ check items 9-13 for P-13 extensions; bump app version header to 0.8.94 - compliance-package-register.md: expand P-13 Letzter Stand with full extension list through 0.8.94; update Fortschritt version - compliance-roadmap.md: update app version to 0.8.94; P-13 row in Schnellreferenz marked done (was showing as "next recommended"); Etappe B P-13 hint updated with full feature summary - HANDOVER.md: update app version header to 0.8.94; §5b P-13 section rewritten with complete feature list including all 0.8.88-0.8.94 additions; §6 next session updated Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
24 KiB
Compliance-Roadmap – Shinkan Jinkendo
Typ: Lebendes Steuerungsdokument
Erstellt: 2026-05-10
App-Version: 0.8.94
Zuletzt aktualisiert: 2026-05-11
1. Zweck und Geltung
Dieses Dokument steuert die aktuelle Priorisierung, Release-Readiness und nächste Freigabeschritte für das Compliance-Programm. Es ersetzt keines der folgenden Dokumente, sondern ergänzt sie:
| Dokument | Rolle |
|---|---|
docs/compliance-audit.md |
Historischer Initialbefund (unveränderlich als Quelle) |
docs/compliance-package-register.md |
Kanonische Quelle für Paket-IDs und aktuellen Paketstatus |
docs/compliance-implementation.md |
Chronologischer Umsetzungsnachweis |
docs/compliance-roadmap.md |
Aktuelle Prioritäten, Release-Gates, nächste Freigaben |
Bindungsregeln:
- Paket-IDs → immer aus dem Paketregister
- Historische Findings und Severity-Einstufungen → immer aus dem Initial-Audit
- Aktuelle Reihenfolge und Freigabeempfehlungen → dieses Dokument
Diese Roadmap ist nach jedem Re-Audit zu aktualisieren. Abweichungen von der bisherigen Priorität werden mit Datum und Begründung dokumentiert (→ §4, §10).
2. Aktueller Stand (2026-05-11)
App-Version: 0.8.94
Teilweise umgesetzte Pakete
| ID | Titel | Version | Offen |
|---|---|---|---|
| P-01 | Rechtstexte | 0.8.74 | Juristische Inhalte — Betreiber + Rechtsanwalt |
| P-06 | Upload-Einwilligungsdialog + P-06+ Volljournal + Korrektur | 0.8.83 | KRIT-04: Juristische Validierung (§22 KUG, §8 DSGVO, Widerrufsrecht, Texte p06-v1-conservative) |
Vollständig geschlossene Pakete
| ID | Titel | Version |
|---|---|---|
| P-03 | Papierkorb-Retention-Job aktivieren | 0.8.66 |
| P-03b | Nacharbeit: Retention-Zeiten 30+30 Tage | 0.8.67 |
| P-04 | Copyright-Pflicht für Archiv-Promotion vereinheitlichen | 0.8.66 |
| P-05 | Passwort-Mindestlänge angleichen (alle Endpoints) | 0.8.66–0.8.67 |
| P-05b | Nacharbeit: reset-password Mindestlänge | 0.8.67 |
| P-07 | ALLOW_PUBLIC_MEDIA_STATIC dokumentieren + Release-Test | 0.8.66 |
| P-12 | sessionStorage bei Logout bereinigen | 0.8.68 |
| P-23 | LoginPage: minLength angleichen + Versionsstring entfernen | 0.8.66 |
| P-24 | CORS einschränken (Methoden + Header) | 0.8.66 |
| P-01b | Nacharbeit: Mobile/PWA-Erreichbarkeit Rechtstexte via /settings/legal |
0.8.70 |
| P-01c | Nacharbeit: Admin-konfigurierbare Rechtstexte (DB 047, Superadmin-UI, API) | 0.8.71 |
| P-01c+ | Erweiterung: Als-Entwurf-kopieren (copy-as-draft) |
0.8.72 |
| P-01c++ | Erweiterung: Echter PDF-Download (jsPDF) + Abschnitts-Sortierung/-Einfügen | 0.8.74 |
| P-13 | Content-Melde-Backend + Erweiterungen (Audit-Log, E-Mail, Club-Admin, Workflow) | 0.8.87–0.8.94 |
Vollständig abgeschlossen: 10 Hauptpakete + 4 Nacharbeiten + 2 Erweiterungen = 16 Umsetzungseinheiten (P-13 inkl. umfangreicher Nachfixe 0.8.88–0.8.94)
Teilweise umgesetzt (technisch): P-01, P-06
Offene Pakete (13)
P-02, P-08, P-09, P-10, P-14, P-15, P-16, P-17, P-18, P-19, P-20, P-21, P-22
Gesamtstatus
⛔ Nicht öffentlich freigabefähig
Begründung: Die App kann im aktuellen Zustand nicht für allgemeine öffentliche Registrierung beworben oder aktiv vermarktet werden. Folgende zwingende Voraussetzungen fehlen noch:
- P-01: Kein Impressum, keine Datenschutzerklärung, keine AGB. Eine öffentlich erreichbare App ohne Impressum ist eine Ordnungswidrigkeit nach § 5 DDG.
- P-06: Keine Einwilligungserklärung beim Medienupload. Personenbilder können ohne jede Rechteabklärung hochgeladen werden.
- P-02: Nutzer können ihr Konto nicht selbst löschen (DSGVO Art. 17). Der Prozess ist noch nicht einmal fachlich spezifiziert.
P-13: Keine Möglichkeit, rechtswidrige Inhalte zu melden.✅ Implementiert (v0.8.87). Content-Melde-Backend umgesetzt: POST/api/content-reports, Admin-Inbox-Integration, P-11 Legal-Hold-Anbindung.P-11: Kein Legal-Hold-Status.✅ Implementiert (v0.8.84).
Was geöffnet bleiben kann (mit Dokumentation): Vereinsinterne Nutzung durch bekannte Trainer-Gruppen ist mit dem aktuellen Stand vertretbar, solange keine öffentliche Vermarktung stattfindet und kein official-Content aktiviert wird.
3. Aktuelle Blocker vor öffentlichem Betrieb
Die folgenden Pakete sind vor der Freigabe für allgemeine öffentliche Registrierung zwingend zu adressieren. Die Reihenfolge entspricht der in §5 definierten Umsetzungsreihenfolge.
Blocker 1 — P-01: Rechtstexte
Finding: KRIT-01 (Ordnungswidrigkeit, § 5 DDG)
Technischer Stand: ⚠️ Vollständige technische Infrastruktur vorhanden (Version 0.8.74):
- Routen
/impressum,/datenschutz,/nutzungsbedingungen,/medienrichtlinieöffentlich ohne Auth erreichbar (P-01, 0.8.69) - Mobile/PWA-Erreichbarkeit via
/settings/legal(P-01b, 0.8.70) - Admin-konfigurierbare Rechtstexte: DB-Versionierung, Publish/Archive-Workflow, Superadmin-UI
/admin/legal-documents(P-01c, 0.8.71) - Als-Entwurf-kopieren: Bestehendes Dokument als Basis für neue Version übernehmen (0.8.72)
- Echter PDF-Download via jsPDF (direkter Dateidownload, kein Druckdialog), Abschnitte sortieren (▲/▼) und an beliebiger Stelle einfügen (0.8.74)
Warum noch offen: Impressum, Datenschutzerklärung und AGB ohne juristisch geprüfte Inhalte genügen der gesetzlichen Pflicht nicht. Die Superadmin-UI bietet alle Werkzeuge zum Einpflegen, Versionieren und Veröffentlichen von Texten — sobald Inhalte vorliegen, verschwindet der Platzhalter-Banner automatisch.
Nächster Schritt: Rechtsanwalt beauftragen → Inhalte über /admin/legal-documents einpflegen → Veröffentlichen → Platzhaltermarkierung verschwindet automatisch.
Blocker 2 — P-06: Upload-Einwilligungsdialog
Finding: KRIT-04 (§22 KUG, §8 DSGVO)
Warum zwingend: Jeder hochgeladene Bildinhalt mit erkennbaren Personen ist ohne dokumentierte Einwilligung rechtlich problematisch. Das Risiko besteht nicht erst bei öffentlichen Inhalten — es beginnt beim Upload.
Technischer Stand: ⚠️ Vollständig technisch umgesetzt (v0.8.83):
- P-06a–P-06d (v0.8.75): Deklarations-Log, Backend-Enforcement,
RightsDeclarationDialog.jsx, 3 neue Admin-Endpoints, Altbestand-Indikator, 25 Backend-Tests - P-06+ Volljournal + Korrektur (v0.8.83): Vollständiger Audit-Log (
media_asset_audit_log) für alle Asset-Änderungen; Journal-Endpoint (events[]chronologisch); Korrektur-Endpoint für nachträgliche Deklarations-Korrekturen; Zugriff Superadmin + Uploader + Vereins-Admin
Warum noch KRIT-04 offen: Juristische Validierung der Einwilligungsformulierungen (§7.7), KUG-Anforderungen im Vereinskontext (§7.2), Minderjährigenschutz (§7.4) und Altbestand-Behandlung (§7.8) steht aus. Texte sind Arbeitsfassungen (p06-v1-conservative) ohne anwaltliche Freigabe.
Nächster Schritt: Rechtsanwalt für juristische Prüfung der Feldtexte (T1–T10 in docs/p06-upload-rights-spec.md §10.3) und der offenen KUG/DSGVO-Fragen beauftragen. Nach Klärung: Textfreigabe eintragen → KRIT-04 kann geschlossen werden.
Blocker 3 — P-11: Legal-Hold Lifecycle-Status ✅ Implementiert (v0.8.84–0.8.86)
Finding: MITT-02
Abgeschlossen: 2026-05-11. Migration 051, media_legal_hold.py, Retention-Schutz, Superadmin-API + Frontend (0.8.84); UI-Bugfixes (0.8.85); vollständige Auslieferungssperre (download_exercise_media_file HTTP 451), Frontend-Placeholder in allen Übungskomponenten, Medienliste nur noch für Superadmin mit Legal-Hold-Einträgen (0.8.86). Details: docs/compliance-package-register.md §P-11.
Blocker 3 (neu) — P-13: Content-Melde-Backend (Minimalversion) ✅ Implementiert (v0.8.87)
Finding: KRIT-03
Abgeschlossen: 2026-05-11. Migration 052 (content_reports); POST /api/content-reports (optionale Auth, official-Medien ohne Login meldbar); GET /api/me/inbox/content-reports (Plattform-Admin); PATCH /api/content-reports/{id}; POST /api/content-reports/{id}/legal-hold (Superadmin, P-11-Integration, reason_code-Mapping). Inbox-Erweiterung InboxPage.jsx mit zweitem Abschnitt „Inhaltsmeldungen". Keine separate Moderations-Queue — bestehende Admin-Inbox erweitert. 15 Backend-Unit-Tests. Details: docs/compliance-package-register.md §P-13.
Blocker 5 — P-02: DSGVO-Self-Service (fachliche Spezifikation zuerst)
Finding: KRIT-02, KRIT-05
Warum zuerst spezifizieren, dann umsetzen: P-02 berührt Kontolöschung, Medienarchiv, Vereinsinhalte, Backups und Fristen. Eine voreilige Implementierung riskiert unvollständige oder juristisch falsche Umsetzung. → Erst spezifizieren (→ §5 Etappe C), dann freigeben.
Juristisch zu klären: Anonymisierung vs. Löschung bei Vereinsinhalten; Backup-Retention-Policy.
Blocker 6 — P-08: HSTS-Betriebsnachweis (Betreiber-Aufgabe)
Finding: HOCH-02, SEC-01
Status: Außerhalb des Repo-Scopes. HSTS muss am externen Reverse-Proxy (Fritz!Box → Synology → Nginx) konfiguriert sein.
Anforderung: Vor öffentlichem Betrieb: manueller Nachweis (z. B. curl -I https://shinkan.jinkendo.de zeigt Strict-Transport-Security-Header).
Nicht im Code zu lösen — aber als Release-Gate dokumentiert (→ §7).
4. Abweichungen gegenüber der ursprünglichen Audit-Reihenfolge
P-13 wird vorgezogen (Etappe 3 → Etappe B)
Das Initial-Audit (docs/compliance-audit.md §17) ordnete P-13–P-16 (DSA-Meldeverfahren) in Etappe 3 ein, nach den Sicherheits- und Datenschutzpaketen von Etappe 2. Die Begründung war: juristische Klärung des DSA-Anwendungsbereichs zuerst.
Aktuelle Einschätzung (2026-05-10): Diese Reihenfolge bleibt für den vollen DSA-Stack (P-14–P-16) richtig. Für den Kern von P-13 — die technische Möglichkeit, eine Inhaltsmeldung abzugeben und zu bearbeiten — ist eine Vorziehung geboten, weil:
- Die App erlaubt bereits jetzt Upload und Anzeige von Nutzerinhalten mit
official-Sichtbarkeit - Das Risiko ungemeldeter Rechtsverletzungen ist kein langfristiges, sondern ein unmittelbares
- Die juristische DSA-Bewertung (ab welcher Nutzerzahl, welche Pflichten) bleibt offen — sie entscheidet über den Umfang, nicht über das Ob einer Grundfähigkeit
- Eine minimale Melde-Queue kostet weniger als P-14–P-16 zusammen und schafft handlungsfähige Grundstruktur
Keine ID-Änderung: P-13 bleibt P-13. Die Neuprioritisierung ist eine Planungsentscheidung, keine inhaltliche Änderung des Pakets.
P-22 (HTML-Sanitizer) bleibt in Etappe D
Das Initial-Audit platzierte P-22 in Etappe 2. Die aktuelle Einschätzung: CSP script-src 'self' reduziert das XSS-Risiko für eingeloggte Nutzer erheblich. Das Risiko ist real, aber kein harter Blocker vor öffentlichem Betrieb im Vergleich zu P-01, P-06, P-11, P-13. P-22 bleibt auf der Roadmap, wird aber nicht als Release-Gate behandelt.
5. Aktuell empfohlene Umsetzungsreihenfolge
✅ Etappe A – Abgeschlossen (2026-05-10, Version 0.8.68)
| Paket | Titel | Aufwand | Status |
|---|---|---|---|
| P-12 | sessionStorage bei Logout bereinigen | ~15 min | ✅ umgesetzt |
Abschluss: P-12 wurde am 2026-05-10 in Version 0.8.68 umgesetzt. logout() in AuthContext.jsx löscht alle sj_coach_*-Schlüssel via Präfix-Iteration. Playwright-Test verifiziert. MITT-05 geschlossen.
Etappe B – Technische Grundlagen für öffentlichen Betrieb
Reihenfolge innerhalb der Etappe ist flexibel; P-01 und P-06 haben keine gegenseitige Abhängigkeit.
| Paket | Titel | Aufwand | Abhängigkeit | Freigabe-Formulierung |
|---|---|---|---|---|
| P-01 | Rechtstexte technisch anlegen (Platzhalter-Seiten, Routen) | 2–4 h Technik | Inhalt durch Rechtsanwalt separat | „Freigabe zur Umsetzung P-01: Rechtstexte" |
| P-06 | Upload-Einwilligungsdialog | 2–4 Tage | — | „Freigabe zur Umsetzung P-06: Upload-Einwilligungsdialog" |
| — | ✅ implementiert (v0.8.84) | — | ||
| — | ✅ implementiert (v0.8.87) | — |
Hinweis P-01: Die technische Anlage (leere Seiten, Routen /impressum, /datenschutz, /nutzungsbedingungen) ist von der juristischen Ausarbeitung des Inhalts zu trennen. Beide Teilschritte können unabhängig voneinander freigegeben und durchgeführt werden.
Hinweis P-13: ✅ Vollständig implementiert (v0.8.87–0.8.94). Kernumsetzung: POST /api/content-reports, GET /api/me/inbox/content-reports, PATCH /api/content-reports/{id}, POST /api/content-reports/{id}/legal-hold. Erweiterungen: Audit-Log (Migration 053), E-Mail-Benachrichtigungen, Club-Admin-Rechte (Vereinsmedien), Workflow-Bar + Archiv-Trennung, Badge auf Medienkarten, CI-Fix (15 Tests grün). Keine separate Moderations-Queue — bestehende Admin-Inbox erweitert. P-14 (Moderations-UI), P-15 (Uploader-Benachrichtigung), P-16 (Beschwerdeverfahren) folgen in Etappe D.
Etappe C – DSGVO-Self-Service sauber spezifizieren (vor Umsetzungsfreigabe)
P-02 erhält eine eigene Spezifikationsphase, bevor eine Umsetzungsfreigabe erteilt wird. Zu klärende Punkte:
| Frage | Entscheidungsträger |
|---|---|
| Löschung vs. Anonymisierung bei Vereinsinhalten | Betreiber + Rechtsanwalt |
| Verhalten bei Medien, die anderen Vereinen zugeordnet sind | Betreiber + Technik |
| Umgang mit Backups (Retention vs. Löschung auf Antrag) | Betreiber + Rechtsanwalt |
| Fristen: Bearbeitungszeit für Löschanträge | Rechtsanwalt |
| Audit-Log für Löschanträge (wer, wann, was) | Technik |
| Datenexport-Format und Umfang | Technik + Betreiber |
Erst wenn diese Fragen beantwortet und als Spec dokumentiert sind, wird P-02 in Etappe C freigegeben.
Etappe D – Ausbau und langfristige Optimierungen
| Paket | Titel | Aufwand | Priorität |
|---|---|---|---|
| P-09 | Admin-Audit-Log | 3–5 Tage | Hoch |
| P-10 | Mindestalter-Abfrage | 1–2 Tage | Mittel |
| P-14 | Moderations-UI (Frontend) | 3–5 Tage | Mittel (nach P-13) |
| P-15 | Uploader-Benachrichtigung bei Sperrung | 1–2 Tage | Mittel (nach P-13) |
| P-16 | Beschwerdeverfahren | 2–4 Tage | Niedrig (nach P-15) |
| P-08 | HSTS-Dokumentation / Betriebsnachweis | Betreiber | Hoch (Release-Gate) |
| P-22 | HTML-Sanitizer für Rich-Text-Felder | 1–2 Tage | Mittel |
| P-20 | VVT erstellen | Betreiber | Hoch |
| P-21 | AV-Verträge abschließen | Betreiber | Hoch |
| P-02 | Self-Service-Kontolöschung + Datenexport | 5–8 Tage | Hoch (nach Spezifikation Etappe C) |
| P-17 | MFA für Superadmins (TOTP) | 5–8 Tage | Mittel |
| P-18 | HttpOnly-Cookie als Auth-Alternative | 3–5 Tage | Niedrig |
| P-19 | Anti-Virus-Scan (ClamAV) | 3–5 Tage | Niedrig |
6. Nächste empfohlene Freigabe
P-01 + P-01b + P-01c technisch vollständig umgesetzt (Version 0.8.74). Rechtstexte über Login, Desktop-Sidebar und Einstellungen → Rechtliches (Mobile/PWA) erreichbar. Superadmin kann über /admin/legal-documents versionierte Rechtstexte anlegen, bearbeiten (inkl. Abschnitts-Sortierung und Einfügen an beliebiger Stelle), als Entwurf kopieren, veröffentlichen und als PDF herunterladen — sobald Inhalte eingepflegt sind, verschwindet der Platzhalter-Banner automatisch. Juristische Inhalte bleiben offen (Betreiber + Rechtsanwalt).
Die nächste technische Freigabe sollte Etappe B umfassen — beginnend mit P-06:
P-06 Spezifikation vorhanden (docs/p06-upload-rights-spec.md, 2026-05-10). Die Umsetzung setzt die Entscheidung über 12 juristische Klärungspunkte voraus (§22 KUG im Vereinskontext, §8 DSGVO Minderjährigenschutz, Widerrufsrecht, Speicherfristen für Einwilligungen). Erst nach dieser Klärung:
„Freigabe zur Umsetzung P-06: Upload-Einwilligungsdialog"
oder als Paket (nach Klärung P-06):
„Freigabe zur Umsetzung Etappe B: P-06, P-11, P-13"
Parallel dazu Betreiber-Aufgabe:
Rechtsanwalt für die Ausarbeitung der Inhalte von P-01 beauftragen — Inhalte über /admin/legal-documents einpflegen und veröffentlichen. Dies ist eine Betreiber-Aufgabe, keine weitere technische Freigabe.
Nach P-01 vollständig (Inhalte eingepflegt): Gate 1 rückt näher — verbleibende Blocker: P-06, P-02 (Spez.), P-11, P-13, P-08 (Betreiber).
7. Release-Gates
Gate 1 — Öffentliche allgemeine Registrierung freischalten
Folgende Bedingungen müssen alle erfüllt sein:
| Bedingung | Paket | Typ |
|---|---|---|
| Impressum und Datenschutzerklärung mit juristisch geprüftem Inhalt | P-01 | ⚠️ Routen vorhanden — Inhalte durch Rechtsanwalt erforderlich |
| Upload-Einwilligungsdialog aktiv | P-06 | Code |
| DSGVO-Löschprozess spezifiziert (Spec akzeptiert, auch wenn nicht vollständig implementiert) | P-02 | Spezifikation |
| Legal-Hold-Status vorhanden | P-11 | ✅ Bereits erfüllt (Version 0.8.84–0.8.86) |
| Content-Melde-Backend (Minimalversion) aktiv | P-13 | Code |
| HSTS am externen Reverse-Proxy nachgewiesen | P-08 | Betreiber |
| Papierkorb-Retention-Job läuft (Monitoring aktiv) | P-03 | Bereits erfüllt |
ALLOW_PUBLIC_MEDIA_STATIC nicht in Prod-Env gesetzt |
P-07 | Bereits erfüllt |
| sessionStorage bei Logout bereinigt | P-12 | ✅ Bereits erfüllt (Version 0.8.68) |
Darf bei Gate 1 offen bleiben (mit Dokumentation):
- P-02 vollständige Implementierung (Spezifikation genügt als Zwischenstand, wenn aktiver Prozess für Löschanfragen per E-Mail dokumentiert ist)
- P-09 Admin-Audit-Log
- P-10 Mindestalter-Abfrage
- P-14–P-16 Moderationsausbau
- P-17 MFA, P-18 HttpOnly-Cookie, P-19 Anti-Virus-Scan
- P-20 VVT (in Erstellung), P-21 AV-Verträge (in Klärung)
Gate 2 — Aktivierung öffentlicher Official-Medien (visibility = official)
Bevor Inhalte mit official-Sichtbarkeit (plattformweit sichtbar, ohne Login) aktiv eingesetzt werden:
| Bedingung | Paket | Typ |
|---|---|---|
| Gate 1 vollständig erfüllt | — | Voraussetzung |
| Upload-Einwilligungsdialog für Personenbilder aktiv | P-06 | Code |
| Legal-Hold-Status aktiv (Sofortsperrung möglich) | P-11 | ✅ Bereits erfüllt (Version 0.8.84–0.8.86) |
| Content-Melde-Backend aktiv | P-13 | Code |
| Copyright-Pflicht bei Promotion aktiv und getestet | P-04 | Bereits erfüllt |
| Moderationsprozess organisatorisch dokumentiert (wer, wie schnell, Eskalationspfad) | — | Betreiber |
Gate 3 — Aktivierung öffentlicher Inhalte im Vereinsbereich (visibility = club)
Bedingungen für Vereinsinhalte sind weniger streng als für official, da der Personenkreis begrenzt ist:
| Bedingung | Status |
|---|---|
| Copyright-Pflicht bei Promotion aktiv | ✅ bereits erfüllt (P-04) |
| Papierkorb-Retention-Job aktiv | ✅ bereits erfüllt (P-03) |
| Upload-Einwilligungsdialog vorhanden | muss mit P-06 kommen |
| Mitgliedschaftsbasierte Zugriffskontrolle funktioniert | ✅ (TenantContext, library_content_visibility_sql) |
8. Juristisch zu prüfende Punkte
Alle folgenden Punkte erfordern Einschätzung durch einen Rechtsanwalt oder Datenschutzbeauftragten. Keine der nachfolgenden Einschätzungen ist rechtlich verbindlich.
| Thema | Frage | Priorität |
|---|---|---|
| Rechtstexte | Vollständige Angaben Impressum, Datenschutzerklärung, AGB, Medienrichtlinie. Inhalte können nicht technisch generiert werden. | Sofort |
| DSA-Anwendungsbereich | Ab welcher Nutzerzahl und unter welchen Voraussetzungen gilt der DSA für diese Plattform? Welche Pflichten für sehr kleine Plattformen? | Vor öffentlichem Betrieb |
| Einwilligungsmodell Personenbilder | §22 KUG: Welche Einwilligungen sind für Bilder erkennbarer Personen im Vereinskontext erforderlich? Reicht eine pauschale Upload-Erklärung? | Vor öffentlichem Betrieb |
| Minderjährigenschutz | §8 DSGVO: Ab welchem Alter ist keine elterliche Einwilligung nötig? Wie ist mit Bildern Minderjähriger umzugehen? | Vor öffentlichem Betrieb |
| DSGVO-Löschprozess | Anonymisierung vs. Löschung bei Vereinsinhalten; Umgang mit Backups; Fristen für Löschanträge (Art. 17) | Vor Implementierung P-02 |
| Datenübertragbarkeit | Welcher Exportumfang ist für Art. 20 DSGVO ausreichend? Welches Format? | Vor Implementierung P-02 |
| AV-Verträge | Welche Dienstleister benötigen einen AVV (SMTP-Anbieter, MediaWiki, OpenRouter)? | Vor öffentlichem Betrieb |
| Backup-Retention | Wie muss die Backup-Retention-Policy aussehen, damit DSGVO-Löschanfragen auch Backups erfassen? | Vor öffentlichem Betrieb |
| MediaWiki-Lizenz | Welche Lizenzanforderungen gelten für Übungsinhalte von karatetrainer.net? | Klärenswert |
9. Betreiber-Aufgaben
Diese Punkte liegen außerhalb des Code-Scopes und erfordern organisatorische Maßnahmen durch den Betreiber:
| Aufgabe | Bezug | Dringlichkeit |
|---|---|---|
| Rechtsanwalt beauftragen (Rechtstexte, DSA, KUG) | P-01, P-06 | Sofort |
| VVT erstellen (DSGVO Art. 30) | P-20 | Vor öffentlichem Betrieb |
| AV-Verträge klären (SMTP, MediaWiki, OpenRouter) | P-21 | Vor öffentlichem Betrieb |
| HSTS am Reverse-Proxy (Fritz!Box/Synology) konfigurieren und nachweisen | P-08 | Vor öffentlichem Betrieb |
| Backup-Konzept dokumentieren und Restore-Test durchführen | — | Dringend empfohlen |
| Moderationsprozess organisatorisch festlegen: Wer moderiert? Wie schnell? Eskalationspfad? | P-13–P-16 | Vor Aktivierung öffentlicher Inhalte |
| Notfallkontakt für Datenpannen benennen (DSGVO Art. 33) | — | Vor öffentlichem Betrieb |
Papierkorb-Retention-Job überwachen (docker logs shinkan-retention-cron) |
P-03 | Laufend |
10. Aktualisierungsregel
| Anlass | Maßnahme |
|---|---|
| Nach jedem Re-Audit | §2 (Aktueller Stand) und §5 (Reihenfolge) aktualisieren |
| Nach jeder Freigabe | Paketregister (docs/compliance-package-register.md) aktualisieren; §2 dieser Roadmap anpassen |
| Prioritätsänderung gegenüber bisheriger Roadmap | Datum und Begründung in §4 dokumentieren |
| Neue Paket-IDs | Immer im Initial-Audit + Paketregister vergeben; nie nur in dieser Roadmap |
| Paketstatus | Nie direkt in dieser Roadmap pflegen — immer aus Paketregister übernehmen |
Diese Roadmap enthält keine eigenständigen Statusangaben. §2 wird durch Abfrage des Paketregisters befüllt und bei Aktualisierungen synchronisiert.
Anhang: Schnellreferenz Freigabe-Formulierungen
| Freigabe | Formulierung | Status |
|---|---|---|
| ✅ historisch abgeschlossen (Version 0.8.68) | ||
| ✅ historisch abgeschlossen (Version 0.8.69) | ||
| ✅ historisch abgeschlossen (Version 0.8.70) | ||
| ✅ historisch abgeschlossen (Version 0.8.71); Erweiterungen copy-as-draft (0.8.72) + jsPDF/Sortierung (0.8.74) | ||
| P-06 | „Freigabe zur Umsetzung P-06 auf Basis konservativer Erstannahmen" | ✅ erteilt + vollständig umgesetzt (2026-05-11, v0.8.75–0.8.83) — technisch umgesetzt unter p06-v1-conservative inkl. P-06+ Volljournal + Korrektur; KRIT-04 bleibt bis juristische Validierung |
| P-11 | „Freigabe zur Umsetzung P-11: Legal-Hold Lifecycle-Status" | ✅ vollständig umgesetzt (2026-05-11, v0.8.84–0.8.86) — Migration 051, Retention-Schutz, Superadmin-API + Frontend (0.8.84); UI-Bugfixes (0.8.85); Auslieferungssperre + Frontend-Placeholder + Superadmin-only Medienliste (0.8.86); 15 Backend-Tests |
| ✅ vollständig umgesetzt (2026-05-11, v0.8.87–0.8.94) — Kernumsetzung + Audit-Log, E-Mail-Benachrichtigungen, Club-Admin-Rechte, Workflow-Management, Badge, CI-Fix; 15 Backend-Tests | ||
| P-02 Spezifikation | „Freigabe zur Spezifikation P-02: DSGVO-Self-Service-Prozess" | offen |
Erstellt: 2026-05-10 | Quellen: docs/compliance-audit.md, docs/compliance-package-register.md, docs/compliance-implementation.md | Kein Rechtsanwalt; alle rechtlichen Einschätzungen sind juristisch zu prüfen.