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/055_wiki_cra.sql

@@ -0,0 +1,230 @@
+-- Migration 055: CRA (Cyber Resilience Act) Wiki-Kategorie und Artikel
+-- Neue Kategorie + 3 Artikel zum EU Cyber Resilience Act
+
+-- Kategorie: CRA
+INSERT INTO compliance_wiki_categories (id, name, description, icon, sort_order) VALUES
+('cra', 'Cyber Resilience Act (CRA)', 'EU-Verordnung fuer Cybersicherheit von Produkten mit digitalen Elementen', 'Shield', 75)
+ON CONFLICT (id) DO NOTHING;
+
+-- Artikel 1: CRA Grundlagen
+INSERT INTO compliance_wiki_articles (id, category_id, title, summary, content, legal_refs, tags, relevance, source_urls) VALUES
+('cra-grundlagen', 'cra',
+ 'Cyber Resilience Act — Ueberblick und Pflichten',
+ 'Der CRA (EU) 2024/2847 verpflichtet Hersteller von Produkten mit digitalen Elementen zu umfassenden Cybersicherheits-Massnahmen ueber den gesamten Produktlebenszyklus.',
+ '## Ueberblick
+
+Der **EU Cyber Resilience Act (CRA)**, Verordnung (EU) 2024/2847, ist am **10. Dezember 2024** in Kraft getreten. Er etabliert horizontale Cybersicherheitsanforderungen fuer alle **Produkte mit digitalen Elementen**, die in der EU in Verkehr gebracht werden.
+
+## Zeitplan
+
+| Datum | Meilenstein |
+|-------|------------|
+| 10.12.2024 | Inkrafttreten |
+| 11.06.2026 | Konformitaetsbewertungsstellen muessen benannt sein |
+| 11.09.2026 | Meldepflicht fuer Schwachstellen und Vorfaelle |
+| 11.12.2027 | Volle Anwendung — CE-Kennzeichnung erforderlich |
+
+## Was sind "Produkte mit digitalen Elementen"?
+
+Jedes Software- oder Hardware-Produkt, das:
+- Eine **Datenverbindung** (direkt oder indirekt) zu einem Geraet oder Netzwerk hat
+- **Software** enthaelt, die bestimmungsgemaeß genutzt wird
+
+**Beispiele:** IoT-Geraete, Firmware, eigenstaendige Software, Betriebssysteme, Router, Smart-Home-Geraete, industrielle Steuerungssysteme.
+
+## Kernpflichten fuer Hersteller
+
+### 1. Cybersecurity-Risikobewertung
+- Systematische Bewertung der Cybersecurity-Risiken des Produkts
+- Dokumentation der Risikoanalyse
+- Regelmaessige Aktualisierung
+
+### 2. Secure Development (SSDLC)
+- Sichere Entwicklungsprozesse etablieren
+- Code Reviews und Security Testing
+- Supply-Chain-Security pruefen
+
+### 3. Vulnerability Management
+- Aktives CVE-Monitoring
+- Coordinated Vulnerability Disclosure (CVD)
+- Patch-Bereitstellung waehrend des gesamten Support-Zeitraums
+
+### 4. Security Updates
+- Sichere Update-Mechanismen (signiert, integritaetsgeprueft)
+- Automatische oder einfache Update-Moeglichkeit fuer Nutzer
+- Mindest-Support-Zeitraum: 5 Jahre oder erwartete Produktlebensdauer
+
+### 5. Software Bill of Materials (SBOM)
+- Dokumentation aller Software-Komponenten
+- Top-Level-Abhaengigkeiten
+- Maschinenlesbares Format
+
+### 6. Incident Reporting
+- **24 Stunden:** Fruehwarnung an ENISA/nationale Behoerde
+- **72 Stunden:** Detaillierter Incident Report
+- Meldepflicht fuer aktiv ausgenutzte Schwachstellen
+
+## CE-Kennzeichnung
+
+Der CRA wird Teil der **CE-Konformitaet**. Ab Dezember 2027 duerfen Produkte ohne Cybersecurity-Konformitaet **nicht mehr in der EU verkauft werden**.
+
+## Sanktionen
+
+| Verstoss | Bussgeld |
+|----------|----------|
+| Wesentliche Anforderungen (Annex I) | Bis 15 Mio. EUR oder 2,5% des Jahresumsatzes |
+| Sonstige Pflichten | Bis 10 Mio. EUR oder 2% des Jahresumsatzes |
+| Falsche Informationen | Bis 5 Mio. EUR oder 1% des Jahresumsatzes |',
+ ARRAY['Art. 13 CRA', 'Art. 14 CRA', 'Annex I CRA', 'Annex II CRA', '(EU) 2024/2847'],
+ ARRAY['cra', 'cybersecurity', 'ce-kennzeichnung', 'iot', 'software', 'sbom', 'vulnerability', 'incident-reporting'],
+ 'critical',
+ ARRAY['https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng'])
+ON CONFLICT (id) DO NOTHING;
+
+-- Artikel 2: CRA Security Controls (Annex I)
+INSERT INTO compliance_wiki_articles (id, category_id, title, summary, content, legal_refs, tags, relevance, source_urls) VALUES
+('cra-security-controls', 'cra',
+ 'CRA Annex I — 35 Essential Cybersecurity Requirements',
+ 'Der CRA definiert in Annex I die wesentlichen Cybersicherheitsanforderungen. Daraus ergeben sich etwa 35 konkrete Security-Controls fuer den gesamten Produktlebenszyklus.',
+ '## Ueberblick
+
+Annex I des CRA enthaelt die **Essential Cybersecurity Requirements**. Sie lassen sich in 7 Themenbereiche mit insgesamt etwa 35 konkreten Controls aufteilen.
+
+## 1. Secure-by-Design / Architektur
+
+| # | Control | Beschreibung |
+|---|---------|-------------|
+| 1 | Secure-by-default | Produkte mit sicheren Standardeinstellungen ausliefern |
+| 2 | Minimale Angriffsflaeche | Nur notwendige Dienste und Schnittstellen aktivieren |
+| 3 | Sichere Systemarchitektur | Sicherheitskritische Komponenten isolieren und schuetzen |
+| 4 | Least-Privilege-Prinzip | Minimale Berechtigungen fuer Komponenten und Nutzer |
+| 5 | Trennung kritischer Funktionen | Isolation sicherheitskritischer Funktionen |
+| 6 | System-Haertung | Deaktivierung unnoetigerServices und Ports |
+| 7 | Manipulationsschutz | Schutz vor unautorisierter Software-Aenderung |
+| 8 | Integritaetspruefung | Signaturen und Integritaetschecks |
+| 9 | Zugriffsschutz | Zugriffskontrollen implementieren |
+
+## 2. Authentifizierung & Zugriffskontrolle
+
+| # | Control | Beschreibung |
+|---|---------|-------------|
+| 10 | Starke Authentifizierung | Sichere Authentifizierungsmechanismen |
+| 11 | Keine Default-Passwoerter | Keine universellen Standardpasswoerter |
+| 12 | Credential-Management | Sichere Verwaltung von Zugangsdaten |
+| 13 | Sitzungsmanagement | Sichere Session-Verwaltung |
+| 14 | Brute-Force-Schutz | Schutz vor Brute-Force-Angriffen |
+| 15 | Autorisierung | Rollenbasierte Zugriffskontrolle |
+
+## 3. Kryptografie & Datenschutz
+
+| # | Control | Beschreibung |
+|---|---------|-------------|
+| 16 | Datenverschluesselung | Verschluesselung sensibler Daten |
+| 17 | Speicher-Schutz | Schutz gespeicherter Daten (at-rest) |
+| 18 | Transport-Schutz | Schutz uebertragener Daten (in-transit) |
+| 19 | Schluesselmanagement | Sicheres kryptografisches Schluesselmanagement |
+| 20 | Schluesselschutz | Schutz kryptografischer Schluessel vor Zugriff |
+
+## 4. Software-Lifecycle-Security
+
+| # | Control | Beschreibung |
+|---|---------|-------------|
+| 21 | Secure Development Lifecycle | Strukturierter SSDLC-Prozess |
+| 22 | Code Reviews | Systematische Code-Ueberpruefungen |
+| 23 | Sichere Entwicklungspraktiken | Static Analysis, SAST, DAST |
+| 24 | Supply-Chain-Security | Pruefung von Drittanbieter-Komponenten |
+| 25 | Dependency-Monitoring | Ueberwachung von Abhaengigkeiten |
+| 26 | SBOM | Software Bill of Materials fuehren |
+
+## 5. Logging, Monitoring & Incident Detection
+
+| # | Control | Beschreibung |
+|---|---------|-------------|
+| 27 | Security-Logging | Protokollierung sicherheitsrelevanter Ereignisse |
+| 28 | Ereignis-Monitoring | Ueberwachung sicherheitsrelevanter Events |
+| 29 | Anomalie-Erkennung | Erkennung von Angriffen oder Anomalien |
+| 30 | Log-Integritaet | Schutz der Protokoll-Integritaet |
+
+## 6. Update- und Patch-Management
+
+| # | Control | Beschreibung |
+|---|---------|-------------|
+| 31 | Sichere Update-Mechanismen | Sichere Verfahren fuer Software-Updates |
+| 32 | Update-Authentizitaet | Signaturen fuer Updates |
+| 33 | Update-Integritaet | Integritaetspruefung bei Updates |
+| 34 | Lifecycle-Support | Security-Updates waehrend des gesamten Lebenszyklus |
+
+## 7. Vulnerability-Handling
+
+| # | Control | Beschreibung |
+|---|---------|-------------|
+| 35 | Vulnerability-Management | Strukturierter Prozess fuer Schwachstellen-Behandlung |
+
+Dazu gehoert:
+- Koordinierte Offenlegung (Coordinated Vulnerability Disclosure)
+- CVE-Monitoring
+- Patch-Bereitstellung innerhalb angemessener Frist
+
+## Automatisierungspotential
+
+Diese 35 Controls koennen automatisch zu folgenden Dokumenten fuehren:
+- **Cybersecurity Policy** (Grundsatzdokument)
+- **Secure Development Policy** (SSDLC)
+- **Vulnerability Management Policy** (CVD, Patching)
+- **Incident Response Policy** (24h/72h Meldung)
+- **SBOM-Dokumentation** (Komponentenliste)',
+ ARRAY['Annex I CRA', 'Art. 13 CRA', 'Art. 14 CRA', 'Art. 15 CRA'],
+ ARRAY['security-controls', 'annex-i', 'secure-by-design', 'authentifizierung', 'kryptografie', 'sbom', 'vulnerability', 'patching'],
+ 'critical',
+ ARRAY['https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng'])
+ON CONFLICT (id) DO NOTHING;
+
+-- Artikel 3: CRA + NIS2 + AI Act Zusammenspiel
+INSERT INTO compliance_wiki_articles (id, category_id, title, summary, content, legal_refs, tags, relevance, source_urls) VALUES
+('cra-regulierungsrahmen', 'cra',
+ 'CRA + NIS2 + AI Act — Das neue EU-Security-Framework',
+ 'CRA, NIS2-Richtlinie und AI Act bilden zusammen ein umfassendes EU-Sicherheitsframework fuer digitale Produkte, Infrastrukturen und KI-Systeme.',
+ '## Ueberblick
+
+Die EU hat mit drei zentralen Rechtsakten ein zusammenhaengendes Framework fuer Cybersicherheit und KI-Regulierung geschaffen. Fuer Softwarehersteller, die KI einsetzen, sind alle drei relevant.
+
+## Die drei Saeulen
+
+| Verordnung | Fokus | Zielgruppe | Anwendung ab |
+|-----------|-------|-----------|-------------|
+| **CRA** (2024/2847) | Produkt-Cybersecurity | Hersteller von Hardware/Software | 12/2027 |
+| **NIS2** (2022/2555) | Infrastruktur-Security | Betreiber wesentlicher Dienste | 10/2024 (national) |
+| **AI Act** (2024/1689) | KI-Regulierung | Anbieter/Betreiber von KI-Systemen | 08/2025 (stufenweise) |
+
+## Abgrenzung
+
+### CRA vs. NIS2
+- **CRA**: Regelt die **Sicherheit des Produkts** selbst (Design, Updates, Vulnerability Handling)
+- **NIS2**: Regelt die **Sicherheit der Organisation** (Risikomanagement, Incident Response, Supply Chain)
+- **Ueberschneidung**: Beide fordern Incident Reporting und Supply-Chain-Security
+
+### CRA vs. AI Act
+- **CRA**: Cybersecurity-Anforderungen an **alle** digitalen Produkte
+- **AI Act**: Zusaetzliche Anforderungen fuer Produkte, die **KI enthalten** (Transparenz, Erklaerbarkeit, Risikobewertung)
+- **Ueberschneidung**: Hochrisiko-KI-Systeme muessen sowohl CRA als auch AI Act erfuellen
+
+## Synergien nutzen
+
+Ein Unternehmen, das alle drei Verordnungen erfuellen muss, kann Synergien nutzen:
+
+| Thema | CRA | NIS2 | AI Act |
+|-------|-----|------|--------|
+| Risikobewertung | Produkt-Risiko | Org-Risiko | KI-Risiko |
+| Incident Reporting | 24h/72h | 24h/72h | Meldepflicht |
+| Supply Chain | SBOM | Lieferantenpruefung | Drittanbieter-KI |
+| Dokumentation | Tech. Doku | Policies | KI-Registrierung |
+| Audit/Konformitaet | CE-Kennzeichnung | Zertifizierung | Konformitaetsbewertung |
+
+## Empfehlung
+
+Bauen Sie ein **integriertes Compliance-Management-System** auf, das alle drei Verordnungen abdeckt. Gemeinsame Policies (Security, Incident Response, Risk Management) koennen fuer alle drei Regelwerke genutzt werden.',
+ ARRAY['(EU) 2024/2847', '(EU) 2022/2555', '(EU) 2024/1689', 'Art. 13 CRA', 'Art. 21 NIS2', 'Art. 9 AI Act'],
+ ARRAY['cra', 'nis2', 'ai-act', 'security-framework', 'compliance', 'synergien', 'ce-kennzeichnung'],
+ 'important',
+ ARRAY[]::text[])
+ON CONFLICT (id) DO NOTHING;

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;