shinkan-jinkendo/docs/compliance-roadmap.md

Compliance-Roadmap – Shinkan Jinkendo

Typ: Lebendes Steuerungsdokument
Erstellt: 2026-05-10
App-Version: 0.8.68
Zuletzt aktualisiert: 2026-05-10

---

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-10)

App-Version: 0.8.67

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

Abgeschlossene Pakete: 7 Hauptpakete + 2 Nacharbeiten = 9 Umsetzungseinheiten

Offene Pakete (17)

P-01, P-02, P-06, P-08, P-09, P-10, P-11, P-13, 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:

1. P-01: Kein Impressum, keine Datenschutzerklärung, keine AGB. Eine öffentlich erreichbare App ohne Impressum ist eine Ordnungswidrigkeit nach TMG §5.
2. P-06: Keine Einwilligungserklärung beim Medienupload. Personenbilder können ohne jede Rechteabklärung hochgeladen werden.
3. P-02: Nutzer können ihr Konto nicht selbst löschen (DSGVO Art. 17). Der Prozess ist noch nicht einmal fachlich spezifiziert.
4. P-13: Keine Möglichkeit, rechtswidrige Inhalte zu melden. Bei einer UGC-Plattform mit öffentlichen Inhalten ist dies ein erhebliches Restrisiko, unabhängig davon, ob der DSA formal anwendbar ist.
5. P-11: Kein Legal-Hold-Status. Bei erkannten Rechtsverletzungen dauert es bis zu 30 Tage, bis Inhalte vollständig ausgeblendet sind.

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, TMG §5)
Warum zwingend: Eine öffentlich erreichbare App ohne Impressum ist seit dem ersten Tag der öffentlichen Zugänglichkeit bußgeldbewehrt. Auch eine Beta-/Invite-Only-Phase ohne Impressum trägt dieses Risiko, sobald die URL öffentlich bekannt ist.
Abhängigkeit: Technische Seiten können sofort angelegt werden (Platzhalter). Inhalt erfordert Rechtsanwalt.

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.
Abhängigkeit: Keine; kann als Frontend-Dialog mit Backend-Flag implementiert werden.

Blocker 3 — P-11: Legal-Hold Lifecycle-Status

Finding: MITT-02
Warum jetzt statt Etappe 2: Der aktuelle Papierkorb-Mechanismus reicht für reaktive Maßnahmen bei Rechtsverletzungen nicht aus. Zwischen Meldung und vollständiger Unsichtbarkeit liegen bis zu 30 Tage (Stufe 1). Für eine Plattform mit öffentlichen Inhalten ist das nicht akzeptabel.
Abhängigkeit: Sinnvoll mit P-13 zusammen umzusetzen (Moderationssystem braucht direkten Sperr-Status).

Blocker 4 — P-13: Content-Melde-Backend (Minimalversion)

Finding: KRIT-03
Warum vorgezogen (Abweichung vom Initial-Audit): → Siehe §4
Minimalumfang: Meldung einreichen + Moderations-Queue für Admin. Nicht der volle P-14–P-16-Stack.
Abhängigkeit: P-11 (Legal-Hold) für direkte Reaktion auf Meldungen empfohlen.

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 – Sofortmaßnahme (ca. 15 Minuten)

Paket	Titel	Aufwand	Freigabe-Formulierung
P-12	sessionStorage bei Logout bereinigen	~15 min	„Freigabe zur Umsetzung P-12: sessionStorage bei Logout bereinigen"

Begründung: Minimaler Aufwand, bereits vollständig dokumentiert mit Fix-Code in docs/compliance-implementation.md §P-12. Schließt MITT-05. Keine Abhängigkeiten. Sollte nicht weiter offen bleiben.

---

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"
P-11	Legal-Hold Lifecycle-Status	2–3 Tage	sinnvoll vor P-13	„Freigabe zur Umsetzung P-11: Legal-Hold Lifecycle-Status"
P-13	Content-Melde-Backend (Minimalversion)	3–5 Tage	P-11 empfohlen	„Freigabe zur Umsetzung P-13: Content-Melde-Backend"

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 Minimalumfang: Im Rahmen von Etappe B umfasst P-13 ausschließlich:

• POST /api/reports — Meldung einreichen
• GET /api/admin/reports — Moderations-Queue
• PATCH /api/admin/reports/{id} — Status setzen

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

Empfehlung: Kein Großpaket.

Die nächste Freigabe sollte P-12 allein umfassen:

„Freigabe zur Umsetzung P-12: sessionStorage bei Logout bereinigen"

Begründung:

• Aufwand: ca. 15 Minuten
• Risiko: null (isolierte Änderung in AuthContext.jsx)
• Fix ist vollständig dokumentiert in docs/compliance-implementation.md §P-12
• Schließt MITT-05 ohne Regressionsgefahr
• Erfordert keinen Re-Audit — kann direkt committet werden

Alternativ: P-12 + P-01 (technische Platzhalterseiten)

Wenn Rechtstexte-Seiten rein technisch angelegt werden sollen (leere Routen, Hinweis „Inhalt folgt"), kann P-01 (technischer Teil) gleichzeitig freigegeben werden:

„Freigabe zur Umsetzung P-01: Rechtstexte technisch anlegen (Platzhalter-Seiten und Routen)"

Inhaltliche Ausarbeitung der Rechtstexte bleibt davon getrennt und erfordert einen Rechtsanwalt.

Nach dieser Freigabe: Mini-Re-Audit, dann Freigabe für Etappe B als Paket.

---

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	Code + Rechtsanwalt
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	Code
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	Code (nach Freigabe)

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	Code
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

Empfohlene nächste Freigabe	Formulierung
P-12 allein	„Freigabe zur Umsetzung P-12: sessionStorage bei Logout bereinigen"
P-12 + P-01 technisch	„Freigabe zur Umsetzung P-12 und P-01: sessionStorage bereinigen und Rechtstexte-Routen technisch anlegen (Platzhalter)"
Etappe B komplett	„Freigabe zur Umsetzung Etappe B: P-01, P-06, P-11, P-13"
P-02 Spezifikation	„Freigabe zur Spezifikation P-02: DSGVO-Self-Service-Prozess"

---

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.