Lars
75d6a40817
All checks were successful
Deploy Development / deploy (push) Successful in 35s
Test Suite / pytest-backend (push) Successful in 32s
Test Suite / lint-backend (push) Successful in 0s
Test Suite / build-frontend (push) Successful in 7s
Test Suite / playwright-tests (push) Successful in 32s
- compliance-implementation.md: P-01-Abschnitt hinzugefügt (technisch teilweise umgesetzt), Testergebnisse, Version 0.8.69 - compliance-package-register.md: P-01 ❌ open → ⚠️ partially implemented; Fortschrittsblock aktualisiert; App-Version 0.8.69 - compliance-roadmap.md: P-01 in teilweise umgesetzte Pakete; Blocker 1 aktualisiert; §6 nächste Freigabe auf P-06 / Etappe B; Anhang Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
351 lines
19 KiB
Markdown
351 lines
19 KiB
Markdown
# Compliance-Roadmap – Shinkan Jinkendo
|
||
|
||
**Typ:** Lebendes Steuerungsdokument
|
||
**Erstellt:** 2026-05-10
|
||
**App-Version:** 0.8.69
|
||
**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.69
|
||
|
||
### Teilweise umgesetzte Pakete
|
||
|
||
| ID | Titel | Version | Offen |
|
||
|----|-------|---------|-------|
|
||
| P-01 | Rechtstexte | 0.8.69 | Juristische Inhalte — Betreiber + Rechtsanwalt |
|
||
|
||
### 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 |
|
||
|
||
**Vollständig abgeschlossen:** 7 Hauptpakete + 2 Nacharbeiten = 9 Umsetzungseinheiten
|
||
**Teilweise umgesetzt (technisch):** P-01
|
||
|
||
### Offene Pakete (16)
|
||
|
||
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 § 5 DDG.
|
||
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, § 5 DDG)
|
||
**Technischer Stand:** ⚠️ Routen und Platzhalterseiten vorhanden (Version 0.8.69). Juristische Inhalte fehlen noch.
|
||
**Warum noch offen:** Impressum, Datenschutzerklärung und AGB ohne geprüfte Inhalte genügen der gesetzlichen Pflicht nicht. Die Platzhalterseiten machen die Lücke sichtbar, schließen sie aber nicht.
|
||
**Nächster Schritt:** Rechtsanwalt beauftragt werden → Inhalte durch Betreiber ergänzen → Platzhaltermarkierung entfernen.
|
||
|
||
### 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 – 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" |
|
||
| 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
|
||
|
||
**P-01 technisch umgesetzt (Version 0.8.69).** Juristische Inhalte bleiben offen.
|
||
|
||
Die nächste technische Freigabe sollte **Etappe B** umfassen — beginnend mit dem kleinsten Paket:
|
||
|
||
> „Freigabe zur Umsetzung P-06: Upload-Einwilligungsdialog"
|
||
|
||
oder als Paket:
|
||
|
||
> „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 — 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 | 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 | ✅ 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 | 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
|
||
|
||
| Freigabe | Formulierung | Status |
|
||
|----------|-------------|--------|
|
||
| ~~P-12 allein~~ | ~~„Freigabe zur Umsetzung P-12: sessionStorage bei Logout bereinigen"~~ | ✅ historisch abgeschlossen (Version 0.8.68) |
|
||
| ~~P-01 technisch~~ | ~~„Freigabe zur Umsetzung P-01: Rechtstexte technisch anlegen"~~ | ✅ historisch abgeschlossen (Version 0.8.69) |
|
||
| **P-06 (empfohlen)** | **„Freigabe zur Umsetzung P-06: Upload-Einwilligungsdialog"** | ⬅ nächste empfohlene Freigabe |
|
||
| Etappe B komplett | „Freigabe zur Umsetzung Etappe B: P-06, P-11, P-13" | offen |
|
||
| 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.*
|