feat: CRA wiki, cybersecurity policy template, Phase H RAG ingestion

- Wiki: add CRA category with 3 articles (Grundlagen, 35 Security Controls,
  CRA+NIS2+AI Act Framework)
- Document Generator: add CRA-konforme Cybersecurity Policy template with
  21 sections covering governance, SSDLC, vulnerability management,
  incident response (24h/72h), SBOM, patch management
- RAG: ingest Phase H — 17 EU regulations + 2 NIST frameworks now in Qdrant
  (CRA, AI Act, NIS2, DSGVO, DMA, GPSR, Batterieverordnung, etc.)
- Phase H script: add scripts/ingest-phase-h.sh for reproducible ingestion
- rag-sources.md: update status to ingestiert, add CRA entry

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

backend-compliance/migrations/056_cra_cybersecurity_policy.sql

@@ -0,0 +1,515 @@
+-- Migration 056: CRA Cybersecurity Policy Template
+-- Unternehmensrichtlinie Cybersecurity basierend auf EU Cyber Resilience Act, ISO 27001 Best Practices
+
+INSERT INTO compliance_legal_templates (
+    id, tenant_id, document_type, title, description, content,
+    placeholders, language, jurisdiction,
+    license_id, license_name, source_name,
+    attribution_required, is_complete_document, version, status,
+    created_at, updated_at
+) VALUES (
+    gen_random_uuid(),
+    '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
+    'cybersecurity_policy',
+    'Unternehmensrichtlinie Cybersecurity (CRA-konform)',
+    'Umfassende Cybersecurity-Richtlinie basierend auf dem EU Cyber Resilience Act (EU) 2024/2847, ISO 27001 und Secure-Development-Standards. Deckt Governance, Risikomanagement, Secure Development, Vulnerability Management, Incident Response und Compliance ab.',
+    $template$# Unternehmensrichtlinie Cybersecurity
+
+**{{COMPANY_NAME}}**
+
+*(Cybersecurity Policy — CRA-konform)*
+
+| Feld | Inhalt |
+|------|--------|
+| Dokumenttyp | Unternehmensrichtlinie |
+| Version | {{DOCUMENT_VERSION}} |
+| Datum | {{VERSION_DATE}} |
+| Naechste Ueberpruefung | {{NEXT_REVIEW_DATE}} |
+| Verantwortlich | {{ISB_NAME}} (CISO/ISB) |
+| Freigabe | {{GF_NAME}} (Geschaeftsfuehrung) |
+| Vertraulichkeit | Intern |
+
+---
+
+## 1. Zweck der Richtlinie
+
+Diese Cybersecurity-Richtlinie legt die organisatorischen und technischen Massnahmen fest, mit denen {{COMPANY_NAME}}:
+
+- Informationssysteme schuetzt
+- Cyberrisiken systematisch reduziert
+- Gesetzliche Anforderungen erfuellt (insb. EU Cyber Resilience Act, NIS2, DSGVO)
+- Sicherheitsvorfaelle erkennt, behandelt und meldet
+
+Die Richtlinie gilt fuer alle:
+
+- Mitarbeiterinnen und Mitarbeiter von {{COMPANY_NAME}}
+- Externe Dienstleister und Auftragnehmer
+- IT-Systeme, Software und Cloud-Services
+- Produkte mit digitalen Elementen im Sinne des CRA
+
+---
+
+## 2. Geltungsbereich
+
+Diese Richtlinie gilt fuer:
+
+- Unternehmens-IT und Netzwerkinfrastruktur
+- Interne Softwareentwicklung
+- Cloud-Infrastruktur und SaaS-Dienste
+- Datenverarbeitungssysteme
+- Produkte mit digitalen Elementen (Software, IoT, Firmware)
+- Lieferanten und Dienstleister mit Zugang zu Systemen von {{COMPANY_NAME}}
+
+Betroffene Assets:
+
+- Server und Netzwerkkomponenten
+- Endgeraete (Laptops, Mobilgeraete)
+- Software und Firmware
+- Datenbanken und APIs
+- Kryptografische Schluessel und Zertifikate
+
+---
+
+## 3. Sicherheitsziele
+
+Die Cybersecurity-Strategie von {{COMPANY_NAME}} verfolgt folgende Ziele:
+
+### Vertraulichkeit
+Schutz sensibler Daten vor unbefugtem Zugriff. Klassifizierung von Daten nach Schutzbedarf.
+
+### Integritaet
+Sicherstellung, dass Daten und Systeme nicht unautorisiert veraendert werden. Einsatz von Integritaetspruefungen und Signaturen.
+
+### Verfuegbarkeit
+Systeme und Dienste muessen gemaess den vereinbarten SLAs verfuegbar sein. Redundanz und Wiederherstellungsfaehigkeit sicherstellen.
+
+### Nachvollziehbarkeit
+Sicherheitsrelevante Ereignisse muessen lueckenlos dokumentiert und fuer Audits nachvollziehbar sein.
+
+---
+
+## 4. Governance und Verantwortlichkeiten
+
+### 4.1 Geschaeftsfuehrung
+
+{{GF_NAME}} ist verantwortlich fuer:
+
+- Festlegung der Sicherheitsstrategie
+- Bereitstellung angemessener Ressourcen
+- Ueberwachung der Compliance-Einhaltung
+- Jaehrliche Freigabe dieser Richtlinie
+
+### 4.2 Chief Information Security Officer (CISO/ISB)
+
+{{ISB_NAME}} ist verantwortlich fuer:
+
+- Umsetzung der Sicherheitsstrategie
+- Risikomanagement und Risikoberichterstattung
+- Security-Monitoring und Threat Intelligence
+- Koordination des Incident-Response-Teams
+- Kontaktperson fuer Behoerden bei Sicherheitsvorfaellen
+
+### 4.3 Datenschutzbeauftragter
+
+{{DPO_NAME}} ({{DPO_EMAIL}}) wird bei sicherheitsrelevanten Vorfaellen einbezogen, die personenbezogene Daten betreffen.
+
+### 4.4 IT-Abteilung
+
+Verantwortlich fuer:
+
+- Sichere Infrastruktur und Systemhaertung
+- Patch-Management und Update-Bereitstellung
+- Netzwerksegmentierung und Firewall-Management
+- Monitoring und Log-Management
+
+### 4.5 Entwicklerteams
+
+Verantwortlich fuer:
+
+- Secure Coding und Code Reviews
+- Dependency Management und SBOM-Pflege
+- Security Testing (SAST, DAST, SCA)
+- Vulnerability Remediation
+
+### 4.6 Alle Mitarbeiter
+
+Alle Mitarbeiter von {{COMPANY_NAME}} muessen:
+
+- Sicherheitsrichtlinien einhalten
+- Sicherheitsvorfaelle unverzueglich melden
+- An jaehrlichen Security-Schulungen teilnehmen
+- Phishing-Versuche und verdaechtige Aktivitaeten melden
+
+---
+
+## 5. Risikomanagement
+
+{{COMPANY_NAME}} fuehrt regelmaessig eine Cyber-Risikoanalyse durch.
+
+### Prozess
+
+1. **Identifikation** kritischer Assets und Daten
+2. **Bedrohungsanalyse** (Threat Modeling, STRIDE)
+3. **Schwachstellenanalyse** (CVE-Monitoring, Vulnerability Scanning)
+4. **Risikobewertung** (Eintrittswahrscheinlichkeit x Auswirkung)
+5. **Risikobehandlung** (Vermeiden, Reduzieren, Uebertragen, Akzeptieren)
+
+### Frequenz
+
+Risikobewertungen erfolgen:
+
+- Mindestens jaehrlich
+- Bei wesentlichen Systemanderungen
+- Bei neuen Produkten oder Dienstleistungen
+- Nach Sicherheitsvorfaellen
+
+### Dokumentation
+
+Alle Risikoanalysen werden dokumentiert und fuer mindestens 3 Jahre aufbewahrt. Die Ergebnisse werden der Geschaeftsfuehrung in Form eines Risikoberichts vorgelegt.
+
+---
+
+## 6. Secure System Architecture
+
+Systeme von {{COMPANY_NAME}} muessen nach folgenden Prinzipien entwickelt und betrieben werden:
+
+### Security by Design
+Sicherheitsanforderungen werden bereits in der Architekturphase beruecksichtigt. Jedes neue System durchlaeuft ein Security Architecture Review.
+
+### Security by Default
+Systeme werden mit sicheren Grundeinstellungen ausgeliefert. Keine Dienste oder Ports sind standardmaessig aktiviert, die nicht benoetigt werden.
+
+### Least Privilege
+Benutzer und Systeme erhalten nur die minimal notwendigen Berechtigungen. Privilegierte Zugriffe werden gesondert protokolliert.
+
+### Segmentierung
+Kritische Systeme werden durch Netzwerksegmentierung isoliert. Produktiv-, Entwicklungs- und Testumgebungen sind strikt getrennt.
+
+### Haertung
+Alle Systeme werden gemaess anerkannter Haertungsrichtlinien (CIS Benchmarks, BSI IT-Grundschutz) konfiguriert.
+
+---
+
+## 7. Zugriffskontrollen
+
+### Anforderungen
+
+- Eindeutige, personalisierte Benutzerkonten
+- Starke Passwortrichtlinie (mind. 12 Zeichen, Komplexitaet)
+- Multi-Faktor-Authentifizierung (MFA) fuer alle administrativen Zugriffe und externe Zugaenge
+- Rollenbasierte Zugriffskontrolle (RBAC) mit regelmaessiger Rezertifizierung
+- Automatische Sperrung nach 5 fehlgeschlagenen Login-Versuchen
+
+### Verboten
+
+- Gemeinsam genutzte Accounts (Shared Accounts)
+- Universal-Default-Passwoerter
+- Unverschluesselte Speicherung von Zugangsdaten
+- Weitergabe von Zugangsdaten per E-Mail
+
+### Privileged Access Management
+
+Administratorzugriffe muessen:
+
+- Gesondert beantragt und genehmigt werden
+- Zeitlich begrenzt sein (Just-in-Time Access)
+- Vollstaendig protokolliert werden
+
+---
+
+## 8. Kryptografie
+
+{{COMPANY_NAME}} verwendet ausschliesslich moderne, anerkannte kryptografische Verfahren.
+
+### Verschluesselung erforderlich fuer
+
+- Gespeicherte sensible Daten (at rest) — AES-256
+- Datenuebertraung (in transit) — TLS 1.2+, vorzugsweise TLS 1.3
+- Backups — vollstaendig verschluesselt
+- Konfigurationsdaten und Secrets — Vault oder vergleichbar
+
+### Schluesselmanagement
+
+- Schluessel muessen sicher gespeichert werden (HSM oder Vault)
+- Regelmaessige Rotation (mind. jaehrlich, bei Kompromittierung sofort)
+- Zugriff nur fuer autorisierte Personen
+- Dokumentation der Schluessel-Lebenszyklen
+
+### Verbotene Verfahren
+
+- MD5 und SHA-1 fuer kryptografische Zwecke
+- DES und 3DES
+- SSL und TLS < 1.2
+
+---
+
+## 9. Secure Software Development Lifecycle (SSDLC)
+
+Alle Softwareprodukte von {{COMPANY_NAME}} muessen einen sicheren Entwicklungsprozess durchlaufen. Dies entspricht den Anforderungen des CRA Annex I.
+
+### Entwicklungsprozess
+
+1. **Security Requirements** — Sicherheitsanforderungen in User Stories und Epics
+2. **Threat Modeling** — Bedrohungsanalyse in der Designphase
+3. **Secure Coding** — Einhaltung von Secure-Coding-Standards
+4. **Code Review** — Peer Review mit Security-Fokus
+5. **Security Testing** — Automatisierte und manuelle Tests
+6. **Release-Freigabe** — Security Sign-off vor Deployment
+
+### Pflichtmassnahmen
+
+- **Static Application Security Testing (SAST)** — in der CI/CD-Pipeline
+- **Software Composition Analysis (SCA)** — Dependency Scanning
+- **Dynamic Application Security Testing (DAST)** — vor jedem Major Release
+- **Secrets Detection** — Automatische Pruefung auf eingebettete Zugangsdaten
+- **Penetration Testing** — mindestens jaehrlich durch externe Tester
+
+---
+
+## 10. Software-Supply-Chain-Security
+
+{{COMPANY_NAME}} kontrolliert externe Softwarekomponenten systematisch.
+
+### Software Bill of Materials (SBOM)
+
+Fuer alle Produkte wird ein SBOM gefuehrt, das mindestens folgende Informationen enthaelt:
+
+- Name und Version aller Software-Komponenten
+- Lizenzinformationen
+- Bekannte Schwachstellen (CVE)
+
+Das SBOM wird bei jedem Release aktualisiert und in maschinenlesbarem Format (CycloneDX oder SPDX) bereitgestellt.
+
+### Open-Source-Kontrolle
+
+- Lizenzpruefung vor Aufnahme neuer Abhaengigkeiten
+- Monitoring auf bekannte Schwachstellen (CVE)
+- Regelmaessige Updates von Abhaengigkeiten
+
+---
+
+## 11. Logging und Monitoring
+
+### Logging umfasst
+
+- Erfolgreiche und fehlgeschlagene Login-Versuche
+- Administrative Systemanderungen
+- Zugriffe auf sensible Daten
+- Sicherheitsrelevante Konfigurationsanderungen
+- API-Zugriffe und Fehler
+
+### Anforderungen an Logs
+
+- Manipulationssicher (append-only, signiert oder WORM)
+- Zentral gesammelt (SIEM oder vergleichbar)
+- Aufbewahrung mindestens 12 Monate
+- Zugriff nur fuer autorisiertes Security-Personal
+
+### Monitoring
+
+- Echtzeit-Ueberwachung sicherheitsrelevanter Ereignisse
+- Automatische Alarmierung bei Anomalien
+- Korrelation von Events aus verschiedenen Quellen
+
+---
+
+## 12. Vulnerability Management
+
+{{COMPANY_NAME}} betreibt ein strukturiertes Schwachstellenmanagement.
+
+### Prozess
+
+1. **Identifikation** — Automatische Scans, Bug Bounty, CVE-Monitoring
+2. **Bewertung** — Risikobewertung nach CVSS
+3. **Priorisierung** — Kritische Schwachstellen zuerst
+4. **Behebung** — Patch-Entwicklung und Deployment
+5. **Verifizierung** — Bestaetigung der Behebung
+6. **Kommunikation** — Information betroffener Kunden und Behoerden
+
+### Coordinated Vulnerability Disclosure (CVD)
+
+{{COMPANY_NAME}} veroeffentlicht eine CVD-Policy. Sicherheitsforscher koennen Schwachstellen an {{SECURITY_EMAIL}} melden. Meldungen werden innerhalb von 5 Werktagen bestaetigt.
+
+---
+
+## 13. Patch- und Update-Management
+
+Alle Systeme muessen regelmaessig aktualisiert werden.
+
+### Patchzyklen
+
+| Risikostufe | Reaktionszeit |
+|-------------|---------------|
+| Kritisch (CVSS >= 9.0) | 24-72 Stunden |
+| Hoch (CVSS 7.0-8.9) | 7 Tage |
+| Mittel (CVSS 4.0-6.9) | 30 Tage |
+| Niedrig (CVSS < 4.0) | Naechster regulaerer Update-Zyklus |
+
+### Anforderungen an Updates
+
+- Alle Updates muessen **digital signiert** sein
+- Integritaetspruefung vor Installation
+- Rollback-Moeglichkeit bei fehlerhaften Updates
+- Automatische Update-Benachrichtigung fuer Kunden
+- **Mindest-Support-Zeitraum: 5 Jahre** (gemaess CRA)
+
+---
+
+## 14. Incident Response
+
+{{COMPANY_NAME}} betreibt einen dokumentierten Incident-Response-Prozess.
+
+### Schritte
+
+1. **Detection** — Erkennung durch Monitoring, Meldung oder externe Information
+2. **Classification** — Einstufung nach Schweregrad (P1-P4)
+3. **Containment** — Sofortige Eindaemmung des Vorfalls
+4. **Investigation** — Forensische Analyse und Ursachenermittlung
+5. **Recovery** — Wiederherstellung des Normalbetriebs
+6. **Reporting** — Dokumentation und Meldung an Behoerden
+7. **Lessons Learned** — Nachbereitung und Verbesserung
+
+### Meldepflichten (CRA-konform)
+
+| Meldung | Frist | Empfaenger |
+|---------|-------|-----------|
+| **Fruehwarnung** | 24 Stunden | ENISA / nationale Behoerde |
+| **Detaillierter Bericht** | 72 Stunden | ENISA / nationale Behoerde |
+| **Abschlussbericht** | 1 Monat | ENISA / nationale Behoerde |
+
+Bei personenbezogenen Daten gelten zusaetzlich die Fristen nach Art. 33/34 DSGVO (72 Stunden an Aufsichtsbehoerde).
+
+### Kontakte
+
+| Rolle | Person | Kontakt |
+|-------|--------|---------|
+| CISO/ISB | {{ISB_NAME}} | {{ISB_EMAIL}} |
+| DSB | {{DPO_NAME}} | {{DPO_EMAIL}} |
+| GF | {{GF_NAME}} | {{GF_EMAIL}} |
+
+---
+
+## 15. Security Testing
+
+Folgende Tests werden regelmaessig durchgefuehrt:
+
+| Test | Frequenz | Durchfuehrung |
+|------|----------|--------------|
+| Vulnerability Scans | Woechentlich | Automatisiert (CI/CD) |
+| SAST/SCA | Bei jedem Commit | Automatisiert (CI/CD) |
+| DAST | Vor Major Releases | Automatisiert + manuell |
+| Penetration Tests | Jaehrlich | Externer Dienstleister |
+| Red-Team-Tests | Alle 2 Jahre | Externer Dienstleister |
+| Social Engineering | Jaehrlich | Externer Dienstleister |
+
+---
+
+## 16. Backup und Wiederherstellung
+
+### Anforderungen
+
+- **Taegliche Backups** aller kritischen Systeme und Daten
+- **Off-Site-Backups** an geografisch getrenntem Standort
+- **Verschluesselung** aller Backup-Daten
+- **Wiederherstellungstests** mindestens vierteljaehrlich
+
+### Recovery-Ziele
+
+| Metrik | Ziel |
+|--------|------|
+| Recovery Time Objective (RTO) | {{RTO_HOURS}} Stunden |
+| Recovery Point Objective (RPO) | {{RPO_HOURS}} Stunden |
+
+---
+
+## 17. Lieferanten- und Drittanbieter-Management
+
+Lieferanten mit Zugang zu Systemen oder Daten von {{COMPANY_NAME}} muessen Sicherheitsanforderungen erfuellen.
+
+### Anforderungen
+
+- Sicherheitspruefung vor Vertragsabschluss (Security Assessment)
+- Sicherheitsanforderungen im Vertrag (Auftragsverarbeitung, SLA)
+- Regelmaessige Audits und Compliance-Nachweise
+- Incident-Notification-Pflicht innerhalb von 24 Stunden
+- Nachweis ueber eigenes Vulnerability Management
+
+---
+
+## 18. Schulungen und Awareness
+
+Alle Mitarbeiter von {{COMPANY_NAME}} erhalten:
+
+- **Jaehrliche Security-Awareness-Trainings**
+- **Phishing-Simulationen** (mind. 2x jaehrlich)
+- **Rollenspezifische Schulungen** (Entwickler: Secure Coding, IT: Incident Response)
+- **Onboarding-Schulung** fuer neue Mitarbeiter
+
+Teilnahme ist verpflichtend. Die Teilnahme wird dokumentiert.
+
+---
+
+## 19. Dokumentation und Compliance
+
+{{COMPANY_NAME}} dokumentiert:
+
+- Risikoanalysen und Risikobehandlungsplaene
+- Sicherheitskontrollen und deren Wirksamkeit
+- Sicherheitsvorfaelle und deren Behandlung
+- Software-Updates und Patches
+- SBOM fuer alle Produkte
+- Audit-Ergebnisse
+
+Die Dokumentation muss jederzeit fuer Audits und behoerdliche Anfragen verfuegbar sein.
+
+### Regulatorische Compliance
+
+Diese Richtlinie dient der Einhaltung folgender Vorschriften:
+
+- **EU Cyber Resilience Act** (EU) 2024/2847
+- **NIS2-Richtlinie** (EU) 2022/2555
+- **DSGVO** (EU) 2016/679 — technische und organisatorische Massnahmen
+- **ISO/IEC 27001** — Best Practices fuer Informationssicherheit
+
+---
+
+## 20. Durchsetzung
+
+Verstoesse gegen diese Richtlinie koennen je nach Schwere folgende Konsequenzen haben:
+
+- Disziplinarmassnahmen
+- Vertragsstrafen (bei externen Dienstleistern)
+- Rechtliche Konsequenzen (bei vorsaetzlichen Verstoessen)
+
+---
+
+## 21. Ueberpruefung und Aktualisierung
+
+Diese Cybersecurity-Richtlinie wird ueberprueft:
+
+- **Jaehrlich** durch {{ISB_NAME}} (CISO/ISB)
+- Bei **regulatorischen Aenderungen** (neue EU-Verordnungen, nationale Gesetze)
+- Nach **groesseren Sicherheitsvorfaellen**
+- Bei **wesentlichen Aenderungen** der IT-Infrastruktur oder Produktlandschaft
+
+Die naechste planmaessige Ueberpruefung ist am **{{NEXT_REVIEW_DATE}}**.
+
+---
+
+## Freigabe
+
+| | Name | Datum | Unterschrift |
+|--|------|-------|-------------|
+| Erstellt von | {{ISB_NAME}} (CISO/ISB) | {{VERSION_DATE}} | _________________ |
+| Freigegeben von | {{GF_NAME}} (Geschaeftsfuehrung) | {{VERSION_DATE}} | _________________ |
+
+---
+
+*Dieses Dokument ist Eigentum von {{COMPANY_NAME}} und unterliegt der Vertraulichkeitsstufe "Intern".*
+$template$,
+    CAST('["COMPANY_NAME","COMPANY_ADDRESS","COMPANY_CITY","GF_NAME","GF_EMAIL","ISB_NAME","ISB_EMAIL","DPO_NAME","DPO_EMAIL","SECURITY_EMAIL","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE","RTO_HOURS","RPO_HOURS"]' AS jsonb),
+    'de', 'DE',
+    'mit', 'MIT License', 'BreakPilot Compliance',
+    false, true, '1.0.0', 'published',
+    NOW(), NOW()
+) ON CONFLICT DO NOTHING;