-- Migration 071: IT-Security Policy Templates
-- 14 professional policy templates based on ISO 27001 / BSI IT-Grundschutz
-- Types: information_security_policy, access_control_policy, password_policy,
--        encryption_policy, logging_policy, backup_policy, incident_response_policy,
--        change_management_policy, patch_management_policy, asset_management_policy,
--        cloud_security_policy, devsecops_policy, secrets_management_policy,
--        vulnerability_management_policy

-- Template 1: Informationssicherheitsrichtlinie
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
) SELECT
    gen_random_uuid(),
    '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
    'information_security_policy',
    'Informationssicherheitsrichtlinie (ISO 27001)',
    'Uebergeordnete Informationssicherheitsrichtlinie nach ISO/IEC 27001:2022 und BSI IT-Grundschutz. Definiert Governance, Risikoansatz, Klassifizierung, Rollen und Pruefzyklus.',
    $template$# Informationssicherheitsrichtlinie

## Dokumentenkontrolle

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{DOCUMENT_VERSION}} |
| Datum | {{VERSION_DATE}} |
| Autor | {{ISB_NAME}} |
| Freigabe | {{GF_NAME}} |
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |

### Aenderungshistorie

| Version | Datum | Autor | Aenderung |
|---------|-------|-------|-----------|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |

---

## 1. Zweck und Geltungsbereich

Diese Richtlinie definiert den uebergeordneten Rahmen fuer die Informationssicherheit bei {{COMPANY_NAME}}. Sie gilt fuer:

- Alle Mitarbeiterinnen und Mitarbeiter, einschliesslich Fuehrungskraefte
- Externe Dienstleister und Auftragnehmer mit Zugang zu Unternehmensinformationen
- Alle IT-Systeme, Netzwerke, Anwendungen und Datenbestaende
- Cloud-Dienste, mobile Endgeraete und Remote-Arbeitsplaetze

Die Richtlinie orientiert sich an ISO/IEC 27001:2022, BSI IT-Grundschutz (Kompendium Edition 2023) und den Anforderungen der DSGVO Art. 32.

---

## 2. Sicherheitsziele und Grundsaetze

{{COMPANY_NAME}} verfolgt die folgenden Sicherheitsziele:

| Schutzziel | Beschreibung |
|------------|-------------|
| Vertraulichkeit | Informationen sind nur Berechtigten zugaenglich |
| Integritaet | Daten sind vollstaendig und unverfaelscht |
| Verfuegbarkeit | Systeme und Daten stehen bei Bedarf zur Verfuegung |
| Authentizitaet | Identitaet von Nutzern und Systemen ist verifiziert |
| Nichtabstreitbarkeit | Aktionen koennen eindeutig zugeordnet werden |

Grundsaetze:

- Risikobasierter Ansatz: Massnahmen orientieren sich am Schutzbedarf
- Need-to-Know-Prinzip: Zugriff nur bei dienstlicher Notwendigkeit
- Defense-in-Depth: Mehrschichtige Sicherheitsarchitektur
- Kontinuierliche Verbesserung: PDCA-Zyklus fuer das ISMS

---

## 3. Informationsklassifizierung

| Klasse | Beschreibung | Beispiele |
|--------|-------------|-----------|
| Oeffentlich | Frei zugaenglich | Pressemitteilungen, Marketing |
| Intern | Nur fuer Mitarbeiter | Organigramme, interne News |
| Vertraulich | Eingeschraenkter Personenkreis | Vertraege, Finanzdaten |
| Streng vertraulich | Nur namentlich Berechtigte | Geschaeftsgeheimnisse, Kryptoschluessel |

Jeder Informationswert muss klassifiziert und einem Verantwortlichen (Asset Owner) zugeordnet werden.

---

## 4. Organisation und Rollen

| Rolle | Verantwortung |
|-------|---------------|
| Geschaeftsfuehrung ({{GF_NAME}}) | Gesamtverantwortung, Ressourcenbereitstellung, Freigabe |
| ISB ({{ISB_NAME}}) | Steuerung des ISMS, Risikobehandlung, Berichterstattung |
| IT-Leitung | Umsetzung technischer Massnahmen |
| Fachabteilungen | Klassifizierung ihrer Daten, Einhaltung der Richtlinien |
| Alle Mitarbeiter | Einhaltung der Sicherheitsrichtlinien, Meldung von Vorfaellen |

Der ISB berichtet mindestens quartalsweise an die Geschaeftsfuehrung.

---

## 5. Risikoansatz

Die Risikobewertung erfolgt nach ISO 27005 und umfasst:

1. **Identifikation**: Erfassung aller Informationswerte und Bedrohungen
2. **Analyse**: Bewertung der Eintrittswahrscheinlichkeit und Schadenshoehe
3. **Bewertung**: Priorisierung anhand der Risikomatrix (Schutzbedarf: normal/hoch/sehr hoch)
4. **Behandlung**: Risikominderung, -transfer, -akzeptanz oder -vermeidung

Akzeptierte Restrisiken werden von der Geschaeftsfuehrung schriftlich genehmigt.

---

## 6. Schulung und Sensibilisierung

- Alle neuen Mitarbeiter erhalten eine Sicherheitseinweisung innerhalb der ersten Arbeitswoche
- Jaehrliche Awareness-Schulungen fuer alle Mitarbeiter sind verpflichtend
- Gezielte Trainings fuer IT-Personal und Entwickler nach Bedarf
- Phishing-Simulationen mindestens zweimal jaehrlich

---

## 7. Revision

Jaehrliche Pruefung durch den ISB. Ausserplanmaessige Pruefung bei wesentlichen Aenderungen der Bedrohungslage, nach Sicherheitsvorfaellen oder bei organisatorischen Veraenderungen.

Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
$template$,
    '["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
    'de', 'DE',
    'mit', 'MIT License', 'BreakPilot Compliance',
    false, true, '1.0.0', 'published',
    NOW(), NOW()
WHERE NOT EXISTS (
    SELECT 1 FROM compliance_legal_templates
    WHERE document_type = 'information_security_policy'
      AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
);

-- Template 2: Zugriffskontrollrichtlinie
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
) SELECT
    gen_random_uuid(),
    '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
    'access_control_policy',
    'Zugriffskontrollrichtlinie',
    'Richtlinie zur Zugriffskontrolle nach ISO 27001 Annex A.9 und BSI IT-Grundschutz. Regelt RBAC, Least Privilege, Onboarding/Offboarding, MFA und Rezertifizierung.',
    $template$# Zugriffskontrollrichtlinie

## Dokumentenkontrolle

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{DOCUMENT_VERSION}} |
| Datum | {{VERSION_DATE}} |
| Autor | {{ISB_NAME}} |
| Freigabe | {{GF_NAME}} |
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |

### Aenderungshistorie

| Version | Datum | Autor | Aenderung |
|---------|-------|-------|-----------|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |

---

## 1. Zweck und Geltungsbereich

Diese Richtlinie regelt die Vergabe, Verwaltung und den Entzug von Zugriffsrechten auf IT-Systeme und Daten bei {{COMPANY_NAME}}. Sie gilt fuer alle Mitarbeiter, externen Dienstleister und technischen Konten.

Normative Grundlagen: ISO/IEC 27001:2022 Annex A.9, BSI IT-Grundschutz ORP.4, DSGVO Art. 32 Abs. 1b.

---

## 2. Grundsaetze

- **Least Privilege**: Jeder Benutzer erhaelt ausschliesslich die Rechte, die zur Ausfuehrung seiner Aufgaben erforderlich sind
- **Need-to-Know**: Zugriff auf Informationen nur bei dienstlicher Notwendigkeit
- **Rollbasierte Zugriffskontrolle (RBAC)**: Berechtigungen werden ueber Rollen vergeben, nicht individuell
- **Funktionstrennung (Segregation of Duties)**: Kritische Prozesse erfordern die Mitwirkung mehrerer Personen

---

## 3. Onboarding und Offboarding

### 3.1 Onboarding

| Schritt | Verantwortlich | Frist |
|---------|---------------|-------|
| Rollenantrag durch Fachvorgesetzten | Fachbereich | Vor Arbeitsbeginn |
| Freigabe durch IT-Sicherheit | ISB / IT | Innerhalb 1 Arbeitstag |
| Einrichtung der Konten | IT-Administration | Vor Arbeitsbeginn |
| Sicherheitseinweisung | ISB | Erster Arbeitstag |

### 3.2 Offboarding

- Deaktivierung aller Konten am letzten Arbeitstag (Frist: 0 Tage)
- Entzug physischer Zugangsmedien (Ausweise, Token)
- Ueberpruefung auf persoenliche Daten auf Unternehmensgeraeten
- Dokumentation im Offboarding-Protokoll

---

## 4. Multi-Faktor-Authentifizierung (MFA)

MFA ist verpflichtend fuer:

- Alle Remote-Zugriffe (VPN, Cloud-Konsolen)
- Administrative Konten und privilegierte Zugaenge
- Zugriff auf vertrauliche oder streng vertrauliche Daten
- Single Sign-On (SSO) Portale

Akzeptierte Faktoren: TOTP-Apps, Hardware-Token (FIDO2/U2F). SMS-basierte OTP sind nicht zulaessig.

---

## 5. Rezertifizierung

| Berechtigungstyp | Pruefzyklus | Verantwortlich |
|------------------|-------------|----------------|
| Standard-Benutzer | Halbjaehrlich | Fachvorgesetzter |
| Privilegierte Konten | Quartalsweise | ISB + IT-Leitung |
| Service-Accounts | Halbjaehrlich | IT-Administration |
| Externe Zugaenge | Quartalsweise | Projektleitung + ISB |

Nicht bestaetigte Rechte werden nach Fristablauf automatisch entzogen.

---

## 6. Protokollierung und Monitoring

- Alle Anmeldevorgaenge (erfolgreich und fehlgeschlagen) werden protokolliert
- Fehlgeschlagene Anmeldeversuche: Kontosperrung nach 5 Versuchen
- Privilegierte Zugriffe werden im SIEM korreliert und ueberwacht
- Zugriffsprotokolle werden mindestens 12 Monate aufbewahrt

---

## 7. Revision

Jaehrliche Pruefung durch den ISB. Ausserplanmaessige Pruefung bei Sicherheitsvorfaellen oder organisatorischen Aenderungen.

Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
$template$,
    '["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
    'de', 'DE',
    'mit', 'MIT License', 'BreakPilot Compliance',
    false, true, '1.0.0', 'published',
    NOW(), NOW()
WHERE NOT EXISTS (
    SELECT 1 FROM compliance_legal_templates
    WHERE document_type = 'access_control_policy'
      AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
);

-- Template 3: Passwortrichtlinie
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
) SELECT
    gen_random_uuid(),
    '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
    'password_policy',
    'Passwortrichtlinie',
    'Richtlinie zur Passwortsicherheit nach BSI IT-Grundschutz ORP.4 und NIST SP 800-63B. Regelt Komplexitaet, Rotation, MFA, Passwort-Manager und Service-Accounts.',
    $template$# Passwortrichtlinie

## Dokumentenkontrolle

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{DOCUMENT_VERSION}} |
| Datum | {{VERSION_DATE}} |
| Autor | {{ISB_NAME}} |
| Freigabe | {{GF_NAME}} |
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |

### Aenderungshistorie

| Version | Datum | Autor | Aenderung |
|---------|-------|-------|-----------|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |

---

## 1. Zweck und Geltungsbereich

Diese Richtlinie definiert die Anforderungen an die Erstellung, Verwaltung und den Schutz von Passwoertern bei {{COMPANY_NAME}}. Sie gilt fuer alle Benutzerkonten, Service-Accounts und technischen Zugaenge.

Normative Grundlagen: BSI IT-Grundschutz ORP.4, NIST SP 800-63B, ISO 27001 Annex A.9.

---

## 2. Passwortanforderungen

### 2.1 Benutzerpasswoerter

| Kriterium | Anforderung |
|-----------|-------------|
| Mindestlaenge | 12 Zeichen |
| Komplexitaet | Gross-/Kleinbuchstaben, Ziffern, Sonderzeichen |
| Maximalalter | 365 Tage (bei MFA), 90 Tage (ohne MFA) |
| Passworthistorie | Letzte 12 Passwoerter duerfen nicht wiederverwendet werden |
| Sperrung | Nach 5 fehlgeschlagenen Versuchen fuer 15 Minuten |

### 2.2 Administratorpasswoerter

| Kriterium | Anforderung |
|-----------|-------------|
| Mindestlaenge | 16 Zeichen |
| Maximalalter | 90 Tage |
| MFA | Verpflichtend (FIDO2 oder TOTP) |
| Speicherung | Ausschliesslich im freigegebenen Passwort-Manager |

### 2.3 Service-Accounts

- Mindestlaenge 24 Zeichen, automatisch generiert
- Rotation alle 90 Tage oder bei Personalwechsel
- Speicherung ausschliesslich in Secrets-Management-Systemen (z.B. HashiCorp Vault)
- Keine interaktive Anmeldung zulaessig

---

## 3. Passwort-Manager

{{COMPANY_NAME}} stellt einen zentral verwalteten Passwort-Manager bereit. Dessen Nutzung ist fuer alle dienstlichen Passwoerter verpflichtend.

Verboten sind:
- Speicherung von Passwoertern in Klartext (Dateien, E-Mails, Tickets)
- Speicherung im Browser ohne Master-Passwort
- Weitergabe von Passwoertern per E-Mail, Chat oder Telefon

---

## 4. Multi-Faktor-Authentifizierung

MFA ist verpflichtend fuer alle Konten. Akzeptierte Verfahren:

| Verfahren | Sicherheitsstufe | Zulaessig |
|-----------|-----------------|-----------|
| FIDO2 / U2F Hardware-Token | Hoch | Ja (empfohlen) |
| TOTP-App (Authenticator) | Mittel | Ja |
| Push-Benachrichtigung | Mittel | Ja |
| SMS-OTP | Niedrig | Nein |

---

## 5. Verbotene Praktiken

- Verwendung desselben Passworts fuer dienstliche und private Konten
- Weitergabe von Passwoertern an Dritte, auch innerhalb des Teams
- Hardcodierung von Passwoertern in Quellcode oder Konfigurationsdateien
- Nutzung von Standardpasswoertern oder trivialen Mustern (z.B. „Firma2024!")

---

## 6. Revision

Jaehrliche Pruefung durch den ISB. Anpassung bei neuen Bedrohungslagen oder technologischen Aenderungen.

Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
$template$,
    '["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
    'de', 'DE',
    'mit', 'MIT License', 'BreakPilot Compliance',
    false, true, '1.0.0', 'published',
    NOW(), NOW()
WHERE NOT EXISTS (
    SELECT 1 FROM compliance_legal_templates
    WHERE document_type = 'password_policy'
      AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
);

-- Template 4: Verschluesselungsrichtlinie
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
) SELECT
    gen_random_uuid(),
    '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
    'encryption_policy',
    'Verschluesselungsrichtlinie',
    'Richtlinie zur Verschluesselung nach ISO 27001 Annex A.10 und BSI TR-02102. Regelt Verschluesselung at-rest und in-transit, Schluesselmanagement, TLS-Versionen und zulaessige Algorithmen.',
    $template$# Verschluesselungsrichtlinie

## Dokumentenkontrolle

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{DOCUMENT_VERSION}} |
| Datum | {{VERSION_DATE}} |
| Autor | {{ISB_NAME}} |
| Freigabe | {{GF_NAME}} |
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |

### Aenderungshistorie

| Version | Datum | Autor | Aenderung |
|---------|-------|-------|-----------|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |

---

## 1. Zweck und Geltungsbereich

Diese Richtlinie definiert verbindliche Anforderungen an den Einsatz kryptographischer Verfahren bei {{COMPANY_NAME}}. Sie gilt fuer alle Systeme, die personenbezogene Daten, Geschaeftsgeheimnisse oder vertrauliche Informationen verarbeiten, speichern oder uebertragen.

Normative Grundlagen: ISO/IEC 27001:2022 Annex A.10, BSI TR-02102 (Kryptographische Verfahren), DSGVO Art. 32.

---

## 2. Verschluesselung in Transit

### 2.1 TLS-Anforderungen

| Parameter | Anforderung |
|-----------|-------------|
| Mindestversion | TLS 1.2 (TLS 1.3 bevorzugt) |
| Cipher Suites | Nur AEAD-basierte Suites (AES-GCM, ChaCha20-Poly1305) |
| Zertifikate | Oeffentlich signiert (Let's Encrypt oder kommerzielle CA) |
| HSTS | Aktiviert mit min-age >= 31536000 |
| Certificate Pinning | Fuer mobile Apps und kritische APIs empfohlen |

### 2.2 Weitere Protokolle

- E-Mail: TLS-Verschluesselung (STARTTLS) verpflichtend; S/MIME oder PGP fuer vertrauliche Inhalte
- VPN: IPSec oder WireGuard; kein PPTP oder L2TP ohne IPSec
- SSH: Version 2, Ed25519-Schluessel bevorzugt, RSA >= 4096 Bit

---

## 3. Verschluesselung at Rest

| Bereich | Methode | Mindeststandard |
|---------|---------|-----------------|
| Datenbanken | Transparent Data Encryption (TDE) oder Spalten-Verschluesselung | AES-256 |
| Dateisysteme | LUKS/dm-crypt (Linux), FileVault (macOS), BitLocker (Windows) | AES-256 |
| Backups | Verschluesselung vor Uebertragung an Offsite-Speicher | AES-256-GCM |
| Object Storage | Server-Side Encryption (SSE) mit kundenverwalteten Schluesseln | AES-256 |

---

## 4. Schluesselmanagement

- Schluessel werden ausschliesslich in einem zertifizierten Key-Management-System (KMS) oder Hardware-Security-Module (HSM) gespeichert
- Rotation: Symmetrische Schluessel mindestens jaehrlich; asymmetrische Schluessel alle 2 Jahre
- Schluessellaenge: RSA >= 4096 Bit, ECC >= 256 Bit (P-256 oder Ed25519), AES >= 256 Bit
- Getrennte Schluessel fuer Entwicklung, Test und Produktion
- Notfallzugriff: Dokumentiertes Key-Recovery-Verfahren mit Vier-Augen-Prinzip

---

## 5. Verbotene Verfahren

- SSL 2.0/3.0, TLS 1.0/1.1
- DES, 3DES, RC4, MD5, SHA-1 (fuer kryptographische Zwecke)
- Selbstentwickelte kryptographische Algorithmen
- Hardcodierte Schluessel in Quellcode oder Konfigurationsdateien

---

## 6. Revision

Jaehrliche Pruefung durch den ISB. Sofortige Pruefung bei Bekanntwerden neuer Schwachstellen in eingesetzten Algorithmen.

Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
$template$,
    '["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
    'de', 'DE',
    'mit', 'MIT License', 'BreakPilot Compliance',
    false, true, '1.0.0', 'published',
    NOW(), NOW()
WHERE NOT EXISTS (
    SELECT 1 FROM compliance_legal_templates
    WHERE document_type = 'encryption_policy'
      AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
);

-- Template 5: Protokollierungsrichtlinie
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
) SELECT
    gen_random_uuid(),
    '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
    'logging_policy',
    'Protokollierungsrichtlinie',
    'Richtlinie zur Protokollierung und Ueberwachung nach ISO 27001 Annex A.12.4 und BSI IT-Grundschutz OPS.1.1.5. Regelt Protokollierungspflichten, Aufbewahrung, SIEM-Anbindung und Integritaetsschutz.',
    $template$# Protokollierungsrichtlinie

## Dokumentenkontrolle

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{DOCUMENT_VERSION}} |
| Datum | {{VERSION_DATE}} |
| Autor | {{ISB_NAME}} |
| Freigabe | {{GF_NAME}} |
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |

### Aenderungshistorie

| Version | Datum | Autor | Aenderung |
|---------|-------|-------|-----------|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |

---

## 1. Zweck und Geltungsbereich

Diese Richtlinie definiert die Anforderungen an die Protokollierung sicherheitsrelevanter Ereignisse bei {{COMPANY_NAME}}. Ziel ist die Erkennung von Sicherheitsvorfaellen, die Unterstuetzung forensischer Analysen und die Erfuellung regulatorischer Nachweispflichten.

Geltungsbereich: Alle IT-Systeme, Netzwerkkomponenten, Anwendungen, Datenbanken und Cloud-Dienste.

Normative Grundlagen: ISO/IEC 27001:2022 Annex A.8.15/A.8.16, BSI IT-Grundschutz OPS.1.1.5, DSGVO Art. 5 Abs. 2.

---

## 2. Protokollierungspflichtige Ereignisse

| Kategorie | Ereignisse |
|-----------|-----------|
| Authentifizierung | Anmeldung (Erfolg/Fehlschlag), Abmeldung, MFA-Nutzung |
| Autorisierung | Zugriffsverweigerung, Rechteaenderungen, Rollenverlaengerung |
| Datenzugriff | Zugriff auf vertrauliche Daten, Massenexporte, API-Aufrufe |
| Systemereignisse | Start/Stopp von Diensten, Konfigurationsaenderungen |
| Netzwerk | Firewall-Regeln (deny), VPN-Verbindungen, DNS-Anomalien |
| Sicherheit | Malware-Erkennung, IDS/IPS-Alarme, Schwachstellen-Scans |

### 2.1 Mindestinhalt eines Logeintrags

Jeder Logeintrag muss enthalten: Zeitstempel (UTC, ISO 8601), Quellsystem, Benutzerkennung (falls zutreffend), Ereignistyp, Ergebnis (Erfolg/Fehlschlag), Quell-IP und Zielressource.

---

## 3. Aufbewahrungsfristen

| Logtyp | Aufbewahrungsfrist |
|--------|--------------------|
| Sicherheitslogs | 12 Monate (Minimum) |
| Zugriffslogs | 6 Monate |
| Anwendungslogs | 3 Monate |
| Debug-Logs | 30 Tage |
| Compliance-Audit-Logs | 36 Monate |

Nach Ablauf der Frist werden Logs sicher geloescht (DSGVO Art. 5 Abs. 1e).

---

## 4. SIEM und zentrale Logsammlung

- Alle Systeme leiten Logs an das zentrale SIEM-System weiter
- Korrelationsregeln fuer typische Angriffsszenarien (Brute-Force, Lateral Movement, Privilege Escalation)
- Alerting: Kritische Ereignisse loesen innerhalb von 15 Minuten eine Benachrichtigung aus
- Dashboards fuer SOC und ISB mit taeglicher Ueberpruefung

---

## 5. Zugriffskontrolle und Integritaet

- Zugriff auf Logdaten nur fuer ISB, SOC-Analysten und berechtigte Administratoren
- Schreibschutz: Logs duerfen nachtraeglich nicht veraendert oder geloescht werden
- Integritaetssicherung durch kryptographische Hashwerte oder Write-Once-Speicher
- Trennung der Log-Infrastruktur von produktiven Systemen

---

## 6. Datenschutz bei der Protokollierung

- Personenbezogene Daten in Logs werden auf das Notwendige beschraenkt (Datenminimierung)
- IP-Adressen und Benutzerkennungen gelten als personenbezogene Daten (DSGVO)
- Zugriff auf Logs mit personenbezogenen Daten nur mit dienstlicher Begruendung
- Betriebsrat ist ueber Umfang der Protokollierung informiert (BetrVG §87 Abs. 1 Nr. 6)

---

## 7. Revision

Jaehrliche Pruefung durch den ISB. Anpassung bei Einfuehrung neuer Systeme oder Aenderung regulatorischer Anforderungen.

Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
$template$,
    '["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
    'de', 'DE',
    'mit', 'MIT License', 'BreakPilot Compliance',
    false, true, '1.0.0', 'published',
    NOW(), NOW()
WHERE NOT EXISTS (
    SELECT 1 FROM compliance_legal_templates
    WHERE document_type = 'logging_policy'
      AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
);

-- Template 6: Datensicherungsrichtlinie
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
) SELECT
    gen_random_uuid(),
    '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
    'backup_policy',
    'Datensicherungsrichtlinie',
    'Richtlinie zur Datensicherung nach ISO 27001 Annex A.12.3 und BSI IT-Grundschutz CON.3. Regelt 3-2-1-Regel, RPO/RTO, Wiederherstellungstests, Offsite-Sicherung und Backup-Verschluesselung.',
    $template$# Datensicherungsrichtlinie

## Dokumentenkontrolle

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{DOCUMENT_VERSION}} |
| Datum | {{VERSION_DATE}} |
| Autor | {{ISB_NAME}} |
| Freigabe | {{GF_NAME}} |
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |

### Aenderungshistorie

| Version | Datum | Autor | Aenderung |
|---------|-------|-------|-----------|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |

---

## 1. Zweck und Geltungsbereich

Diese Richtlinie definiert die Anforderungen an die Datensicherung bei {{COMPANY_NAME}}. Ziel ist der Schutz vor Datenverlust durch technische Stoerungen, menschliche Fehler, Cyberangriffe oder Naturereignisse.

Geltungsbereich: Alle produktiven Systeme, Datenbanken, Konfigurationen und geschaeftskritischen Daten.

Normative Grundlagen: ISO/IEC 27001:2022 Annex A.8.13, BSI IT-Grundschutz CON.3.

---

## 2. Backup-Strategie (3-2-1-Regel)

{{COMPANY_NAME}} wendet die 3-2-1-Regel an:

- **3** Kopien jeder kritischen Datei (1 Produktiv + 2 Backups)
- **2** verschiedene Speichermedien (z.B. SSD + Object Storage)
- **1** Kopie an einem geografisch getrennten Standort (Offsite)

---

## 3. Backup-Klassifizierung und Zyklen

| Datenklasse | Backup-Typ | Frequenz | Aufbewahrung |
|-------------|-----------|----------|-------------|
| Geschaeftskritisch (Tier 1) | Vollbackup + inkrementell | Taeglich + stuendliche Snapshots | 90 Tage |
| Wichtig (Tier 2) | Vollbackup + inkrementell | Taeglich | 30 Tage |
| Standard (Tier 3) | Vollbackup | Woechentlich | 14 Tage |
| Konfigurationen | Vollbackup | Bei jeder Aenderung | 12 Monate |

---

## 4. RPO und RTO

| Datenklasse | RPO (max. Datenverlust) | RTO (max. Ausfallzeit) |
|-------------|------------------------|------------------------|
| Tier 1 | 1 Stunde | 4 Stunden |
| Tier 2 | 24 Stunden | 8 Stunden |
| Tier 3 | 7 Tage | 24 Stunden |

---

## 5. Verschluesselung und Integritaet

- Alle Backups werden vor der Uebertragung verschluesselt (AES-256-GCM)
- Verschluesselungsschluessel werden getrennt von den Backups aufbewahrt
- Integritaetspruefung durch SHA-256-Hashwerte bei jedem Backup-Lauf
- Automatische Alertierung bei fehlgeschlagenen Backups oder Integritaetsverletzungen

---

## 6. Wiederherstellungstests

| Testtyp | Frequenz | Verantwortlich |
|---------|----------|----------------|
| Einzelne Dateien/Tabellen | Monatlich | IT-Administration |
| Vollstaendiges System | Quartalsweise | IT-Leitung + ISB |
| Disaster-Recovery-Uebung | Jaehrlich | Geschaeftsfuehrung + IT |

Testergebnisse werden dokumentiert und Abweichungen von RPO/RTO als Risiken behandelt.

---

## 7. Verantwortlichkeiten

| Rolle | Aufgabe |
|-------|---------|
| IT-Administration | Durchfuehrung und Ueberwachung der Backups |
| ISB ({{ISB_NAME}}) | Pruefung der Backup-Strategie, Risikobewertung |
| Fachabteilungen | Klassifizierung ihrer Daten (Tier 1-3) |
| Geschaeftsfuehrung | Freigabe der RPO/RTO-Ziele |

---

## 8. Revision

Jaehrliche Pruefung durch den ISB. Sofortige Anpassung nach Wiederherstellungstests mit Abweichungen oder nach Sicherheitsvorfaellen.

Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
$template$,
    '["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
    'de', 'DE',
    'mit', 'MIT License', 'BreakPilot Compliance',
    false, true, '1.0.0', 'published',
    NOW(), NOW()
WHERE NOT EXISTS (
    SELECT 1 FROM compliance_legal_templates
    WHERE document_type = 'backup_policy'
      AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
);

-- Template 7: Incident-Response-Richtlinie
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
) SELECT
    gen_random_uuid(),
    '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
    'incident_response_policy',
    'Incident-Response-Richtlinie',
    'Richtlinie zur Behandlung von Sicherheitsvorfaellen nach ISO 27001 Annex A.16 und BSI IT-Grundschutz DER.2.1. Regelt Erkennung, Triage, Eskalation, Kommunikation, Post-Mortem und DSGVO Art. 33/34 Meldepflichten.',
    $template$# Incident-Response-Richtlinie

## Dokumentenkontrolle

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{DOCUMENT_VERSION}} |
| Datum | {{VERSION_DATE}} |
| Autor | {{ISB_NAME}} |
| Freigabe | {{GF_NAME}} |
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |

### Aenderungshistorie

| Version | Datum | Autor | Aenderung |
|---------|-------|-------|-----------|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |

---

## 1. Zweck und Geltungsbereich

Diese Richtlinie definiert den strukturierten Umgang mit Sicherheitsvorfaellen bei {{COMPANY_NAME}}. Sie stellt sicher, dass Vorfaelle schnell erkannt, eingedaemmt, behoben und nachbereitet werden.

Geltungsbereich: Alle IT-Systeme, Daten und Prozesse. Alle Mitarbeiter sind zur Meldung von Verdachtsfaellen verpflichtet.

Normative Grundlagen: ISO/IEC 27001:2022 Annex A.5.24-A.5.28, BSI IT-Grundschutz DER.2.1, DSGVO Art. 33/34.

---

## 2. Incident-Klassifizierung

| Schweregrad | Beschreibung | Reaktionszeit |
|-------------|-------------|---------------|
| Kritisch (P1) | Datenverlust, Ransomware, Datenschutzverletzung mit hohem Risiko | Sofort (< 1 Stunde) |
| Hoch (P2) | Kompromittiertes System, erfolgreicher Angriff ohne Datenabfluss | < 4 Stunden |
| Mittel (P3) | Verdaechtiges Verhalten, Malware-Fund auf Einzelsystem | < 8 Stunden |
| Niedrig (P4) | Fehlkonfiguration, Policy-Verstoss ohne Schaden | < 24 Stunden |

---

## 3. Incident-Response-Phasen

### 3.1 Erkennung und Meldung

- Automatische Erkennung durch SIEM, IDS/IPS, EDR
- Manuelle Meldung durch Mitarbeiter an: security@{{COMPANY_NAME}}.de oder ISB direkt
- Jeder Verdachtsfall wird erfasst — auch bei Fehlalarm

### 3.2 Triage und Bewertung

- ISB bewertet Schweregrad innerhalb von 30 Minuten nach Meldung
- Feststellung: Welche Systeme und Daten sind betroffen?
- Bei personenbezogenen Daten: Sofortige Einbindung des DSB

### 3.3 Eindaemmung

- Kurzfristig: Isolation betroffener Systeme, Sperrung kompromittierter Konten
- Mittelfristig: Sicherung forensischer Beweise, temporaere Workarounds

### 3.4 Behebung und Wiederherstellung

- Beseitigung der Ursache (Patching, Konfigurationsaenderung, Neuinstallation)
- Wiederherstellung aus verifizierten Backups
- Validierung der Systeme vor Produktivnahme

### 3.5 Post-Mortem

- Innerhalb von 5 Arbeitstagen nach Abschluss
- Root-Cause-Analyse, Lessons Learned, Massnahmenplan
- Dokumentation im Incident-Management-System

---

## 4. Meldepflichten (DSGVO)

### Art. 33 — Meldung an die Aufsichtsbehoerde

Bei Verletzung des Schutzes personenbezogener Daten: Meldung innerhalb von **72 Stunden** nach Bekanntwerden, es sei denn, die Verletzung fuehrt voraussichtlich nicht zu einem Risiko.

### Art. 34 — Benachrichtigung der Betroffenen

Bei **hohem Risiko** fuer die Rechte und Freiheiten: Unverzuegliche Benachrichtigung der betroffenen Personen in klarer, einfacher Sprache.

---

## 5. Eskalationsmatrix

| Schweregrad | Benachrichtigung |
|-------------|-----------------|
| P1 (Kritisch) | ISB + Geschaeftsfuehrung + DSB + Rechtsabteilung + externe Forensik |
| P2 (Hoch) | ISB + IT-Leitung + DSB |
| P3 (Mittel) | ISB + IT-Administration |
| P4 (Niedrig) | IT-Administration |

---

## 6. Revision

Jaehrliche Pruefung durch den ISB. Aktualisierung nach jedem P1/P2-Vorfall. Jaehrliche Incident-Response-Uebung (Tabletop oder Simulation).

Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
$template$,
    '["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
    'de', 'DE',
    'mit', 'MIT License', 'BreakPilot Compliance',
    false, true, '1.0.0', 'published',
    NOW(), NOW()
WHERE NOT EXISTS (
    SELECT 1 FROM compliance_legal_templates
    WHERE document_type = 'incident_response_policy'
      AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
);

-- Template 8: Change-Management-Richtlinie
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
) SELECT
    gen_random_uuid(),
    '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
    'change_management_policy',
    'Change-Management-Richtlinie',
    'Richtlinie zum Change Management nach ISO 27001 Annex A.12.1.2 und ITIL v4. Regelt Change Advisory Board, Genehmigungs-Workflow, Risikobewertung, Rollback-Verfahren und Dokumentation.',
    $template$# Change-Management-Richtlinie

## Dokumentenkontrolle

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{DOCUMENT_VERSION}} |
| Datum | {{VERSION_DATE}} |
| Autor | {{ISB_NAME}} |
| Freigabe | {{GF_NAME}} |
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |

### Aenderungshistorie

| Version | Datum | Autor | Aenderung |
|---------|-------|-------|-----------|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |

---

## 1. Zweck und Geltungsbereich

Diese Richtlinie stellt sicher, dass alle Aenderungen an IT-Systemen, Anwendungen und Infrastruktur bei {{COMPANY_NAME}} kontrolliert, bewertet und dokumentiert durchgefuehrt werden. Ziel ist die Minimierung von Stoerungen und Sicherheitsrisiken durch ungeplante oder ungetestete Aenderungen.

Geltungsbereich: Produktivsysteme, Netzwerkinfrastruktur, Datenbanken, Cloud-Konfigurationen und sicherheitsrelevante Software.

Normative Grundlagen: ISO/IEC 27001:2022 Annex A.8.32, ITIL v4 Change Enablement, BSI IT-Grundschutz OPS.1.1.3.

---

## 2. Change-Klassifizierung

| Kategorie | Beschreibung | Genehmigung |
|-----------|-------------|-------------|
| Standard-Change | Vordefinierter, risikoarmer Change (z.B. Patch, User-Anlage) | Vorab genehmigt |
| Normaler Change | Geplante Aenderung mit Risikobewertung | CAB-Genehmigung |
| Emergency Change | Dringend zur Behebung eines Vorfalls oder kritischer Schwachstelle | ISB + IT-Leitung (nachtraegliches CAB-Review) |

---

## 3. Change Advisory Board (CAB)

Das CAB besteht aus:

- ISB ({{ISB_NAME}}) — Vorsitz
- IT-Leitung
- Betroffene Fachabteilung(en)
- Bei Bedarf: DSB, Entwicklungsleitung, externe Berater

Das CAB tritt woechentlich zusammen. Emergency Changes werden ausserplanmaessig per Umlaufverfahren genehmigt.

---

## 4. Change-Prozess

| Phase | Aktivitaet | Verantwortlich |
|-------|-----------|----------------|
| 1. Antrag | Change-Request im Ticketsystem erstellen | Antragsteller |
| 2. Bewertung | Risikobewertung, Impact-Analyse, Ressourcenplanung | CAB |
| 3. Genehmigung | Freigabe oder Ablehnung mit Begruendung | CAB / ISB |
| 4. Implementierung | Durchfuehrung im geplanten Wartungsfenster | IT-Team |
| 5. Validierung | Funktions- und Sicherheitstests nach Implementierung | QA / IT-Team |
| 6. Abschluss | Dokumentation, Lessons Learned, Ticket schliessen | Antragsteller + IT |

---

## 5. Risikobewertung fuer Changes

Jeder normale Change wird nach folgenden Kriterien bewertet:

| Kriterium | Niedrig | Mittel | Hoch |
|-----------|---------|--------|------|
| Betroffene Nutzer | < 10 | 10-100 | > 100 |
| Ausfallrisiko | Kein Ausfall | Kurzzeitig | Laengerer Ausfall moeglich |
| Sicherheitsrelevanz | Keine | Indirekt | Direkt sicherheitsrelevant |
| Reversibilitaet | Sofort rueckgaengig | Mit Aufwand | Nicht rueckgaengig |

---

## 6. Rollback-Verfahren

- Fuer jeden Change muss ein Rollback-Plan dokumentiert sein
- Rollback-Kriterien: Definition klarer Metriken fuer Abbruch
- Backup vor Implementierung: Snapshot oder Datensicherung verpflichtend
- Maximale Rollback-Zeit: Muss innerhalb des Wartungsfensters liegen

---

## 7. Revision

Jaehrliche Pruefung durch den ISB. Nachbereitung bei jedem gescheiterten Change.

Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
$template$,
    '["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
    'de', 'DE',
    'mit', 'MIT License', 'BreakPilot Compliance',
    false, true, '1.0.0', 'published',
    NOW(), NOW()
WHERE NOT EXISTS (
    SELECT 1 FROM compliance_legal_templates
    WHERE document_type = 'change_management_policy'
      AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
);

-- Template 9: Patch-Management-Richtlinie
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
) SELECT
    gen_random_uuid(),
    '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
    'patch_management_policy',
    'Patch-Management-Richtlinie',
    'Richtlinie zum Patch-Management nach ISO 27001 Annex A.12.6 und BSI IT-Grundschutz OPS.1.1.3. Regelt Scan-Zyklen, Kritikalitaetsklassifizierung, SLAs pro Schweregrad und Ausnahmebehandlung.',
    $template$# Patch-Management-Richtlinie

## Dokumentenkontrolle

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{DOCUMENT_VERSION}} |
| Datum | {{VERSION_DATE}} |
| Autor | {{ISB_NAME}} |
| Freigabe | {{GF_NAME}} |
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |

### Aenderungshistorie

| Version | Datum | Autor | Aenderung |
|---------|-------|-------|-----------|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |

---

## 1. Zweck und Geltungsbereich

Diese Richtlinie stellt sicher, dass Sicherheitsupdates und Patches zeitnah und kontrolliert auf allen Systemen von {{COMPANY_NAME}} eingespielt werden. Ziel ist die Reduzierung der Angriffsflaeche durch bekannte Schwachstellen.

Geltungsbereich: Betriebssysteme, Anwendungen, Firmware, Container-Images und Bibliotheken auf allen Produktiv-, Test- und Entwicklungssystemen.

Normative Grundlagen: ISO/IEC 27001:2022 Annex A.8.8, BSI IT-Grundschutz OPS.1.1.3, NIST SP 800-40.

---

## 2. Scan-Zyklus

| Systemkategorie | Scan-Frequenz | Tool |
|----------------|---------------|------|
| Server (Produktion) | Woechentlich | Vulnerability Scanner |
| Endgeraete | 14-taegig | Endpoint-Management |
| Container-Images | Bei jedem Build + woechentlich | Container-Security-Scanner |
| Netzwerkkomponenten | Monatlich | Netzwerk-Scanner |
| Drittanbieter-Software | Woechentlich | Dependency-Scanner (SCA) |

---

## 3. Kritikalitaetsklassifizierung und SLAs

Die Klassifizierung erfolgt nach CVSS v3.1:

| CVSS-Score | Schweregrad | Patch-SLA | Testanforderung |
|-----------|-------------|-----------|----------------|
| 9.0 - 10.0 | Kritisch | 72 Stunden | Smoke-Test ausreichend |
| 7.0 - 8.9 | Hoch | 7 Tage | Standardtest |
| 4.0 - 6.9 | Mittel | 30 Tage | Standardtest |
| 0.1 - 3.9 | Niedrig | 90 Tage | Im naechsten Release-Zyklus |

Bei aktiver Ausnutzung (Known Exploited Vulnerability): Patch-SLA wird auf **24 Stunden** verkuerzt, unabhaengig vom CVSS-Score.

---

## 4. Patch-Prozess

1. **Identifikation**: Automatischer Scan erkennt fehlende Patches
2. **Bewertung**: ISB klassifiziert Kritikalitaet und bewertet Risiko
3. **Test**: Patch wird in Testumgebung validiert (ausser bei kritischen Emergency-Patches)
4. **Genehmigung**: Freigabe durch IT-Leitung (Standard) oder ISB (Emergency)
5. **Deployment**: Rollout in definiertem Wartungsfenster oder via Auto-Update-Policy
6. **Verifizierung**: Erneuter Scan bestaetigt erfolgreiche Installation

---

## 5. Ausnahmen und Kompensationsmassnahmen

Falls ein Patch nicht innerhalb des SLA eingespielt werden kann:

- Schriftliche Begruendung durch den Systemverantwortlichen
- Genehmigung durch ISB ({{ISB_NAME}})
- Dokumentation von Kompensationsmassnahmen (z.B. Network Segmentation, WAF-Regel, IPS-Signatur)
- Maximale Ausnahmedauer: 90 Tage, danach erneute Bewertung
- Tracking aller Ausnahmen im Risikomanagement-System

---

## 6. Automatisierung

- Betriebssystem-Patches: Automatisches Deployment nach Freigabe (WSUS, apt-unattended-upgrades, o.Ae.)
- Container: Base-Image-Updates triggern automatischen Rebuild in CI/CD-Pipeline
- Dependency-Updates: Automatische Pull Requests durch Dependency-Bot

---

## 7. Revision

Jaehrliche Pruefung durch den ISB. Anpassung der SLAs bei veraenderter Bedrohungslage.

Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
$template$,
    '["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
    'de', 'DE',
    'mit', 'MIT License', 'BreakPilot Compliance',
    false, true, '1.0.0', 'published',
    NOW(), NOW()
WHERE NOT EXISTS (
    SELECT 1 FROM compliance_legal_templates
    WHERE document_type = 'patch_management_policy'
      AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
);

-- Template 10: Asset-Management-Richtlinie
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
) SELECT
    gen_random_uuid(),
    '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
    'asset_management_policy',
    'Asset-Management-Richtlinie',
    'Richtlinie zum IT-Asset-Management nach ISO 27001 Annex A.8 und BSI IT-Grundschutz. Regelt CMDB, Lebenszyklus, Eigentuemer, Klassifizierung und sichere Entsorgung.',
    $template$# Asset-Management-Richtlinie

## Dokumentenkontrolle

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{DOCUMENT_VERSION}} |
| Datum | {{VERSION_DATE}} |
| Autor | {{ISB_NAME}} |
| Freigabe | {{GF_NAME}} |
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |

### Aenderungshistorie

| Version | Datum | Autor | Aenderung |
|---------|-------|-------|-----------|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |

---

## 1. Zweck und Geltungsbereich

Diese Richtlinie definiert die Anforderungen an die Erfassung, Verwaltung und sichere Entsorgung aller IT-Assets bei {{COMPANY_NAME}}. Ziel ist die vollstaendige Transparenz ueber alle Informationswerte als Grundlage fuer Risikomanagement und Sicherheitsmassnahmen.

Geltungsbereich: Hardware, Software, Cloud-Dienste, Datenbestaende und Netzwerkkomponenten.

Normative Grundlagen: ISO/IEC 27001:2022 Annex A.5.9-A.5.13, BSI IT-Grundschutz ORP.1.

---

## 2. Configuration Management Database (CMDB)

Alle IT-Assets werden in der zentralen CMDB erfasst. Pflichtfelder:

| Feld | Beschreibung |
|------|-------------|
| Asset-ID | Eindeutige Kennzeichnung |
| Asset-Typ | Hardware / Software / Cloud / Daten |
| Eigentuemer (Owner) | Verantwortliche Person oder Abteilung |
| Standort | Physisch oder Cloud-Region |
| Klassifizierung | Schutzbedarf (normal/hoch/sehr hoch) |
| Status | Aktiv / Wartung / Ausgemustert |
| Beschaffungsdatum | Datum der Inbetriebnahme |
| End-of-Life | Geplantes oder herstellerseitiges EOL |

Die CMDB wird bei jeder Aenderung aktualisiert. Quartalsweise Inventur durch IT-Administration.

---

## 3. Lebenszyklus-Management

| Phase | Aktivitaet | Verantwortlich |
|-------|-----------|----------------|
| Beschaffung | Bedarfspruefung, Sicherheitsbewertung, Lizenzpruefung | Fachbereich + IT |
| Inbetriebnahme | CMDB-Eintrag, Haertung, Erstinstallation | IT-Administration |
| Betrieb | Patch-Management, Monitoring, regelmaessige Pruefung | IT-Administration |
| Wartung | Updates, Hardware-Refresh, Lizenzverlaengerung | IT-Administration |
| Ausmusterung | Datenlöschung, Deregistrierung, Entsorgung | IT + ISB |

---

## 4. Klassifizierung und Schutzbedarf

| Schutzbedarf | Kriterien | Beispiele |
|-------------|-----------|-----------|
| Normal | Ausfall < 24h tolerierbar, keine pers. Daten | Drucker, interne Wiki |
| Hoch | Ausfall geschaeftskritisch, personenbezogene Daten | ERP, Datenbanken, E-Mail |
| Sehr hoch | Existenzbedrohend bei Kompromittierung | Finanzsysteme, HSM, Backup-Server |

Die Klassifizierung bestimmt die erforderlichen Sicherheitsmassnahmen (TOM).

---

## 5. Sichere Entsorgung

| Medientyp | Methode | Standard |
|-----------|---------|----------|
| Festplatten (HDD) | Physische Zerstoerung oder 3-faches Ueberschreiben | DIN 66399, Sicherheitsstufe H-4 |
| SSDs | Secure Erase (herstellerspezifisch) + physische Zerstoerung | DIN 66399, Sicherheitsstufe H-5 |
| Papier | Schredder Sicherheitsstufe P-4 (vertraulich) oder P-6 (streng vertraulich) | DIN 66399 |
| Cloud-Ressourcen | Kryptographische Schluesselvernichtung + Deregistrierung | CSA Guidance |

Entsorgung wird im Entsorgungsprotokoll dokumentiert (Datum, Methode, Verantwortlicher).

---

## 6. Revision

Jaehrliche Pruefung durch den ISB. Quartalsweise CMDB-Inventur.

Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
$template$,
    '["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
    'de', 'DE',
    'mit', 'MIT License', 'BreakPilot Compliance',
    false, true, '1.0.0', 'published',
    NOW(), NOW()
WHERE NOT EXISTS (
    SELECT 1 FROM compliance_legal_templates
    WHERE document_type = 'asset_management_policy'
      AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
);

-- Template 11: Cloud-Security-Richtlinie
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
) SELECT
    gen_random_uuid(),
    '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
    'cloud_security_policy',
    'Cloud-Security-Richtlinie',
    'Richtlinie zur Cloud-Sicherheit nach ISO 27017, BSI C5 und DSGVO. Regelt Shared Responsibility, Anbieterbewertung, Datenresidenz, Verschluesselung und Exit-Strategie.',
    $template$# Cloud-Security-Richtlinie

## Dokumentenkontrolle

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{DOCUMENT_VERSION}} |
| Datum | {{VERSION_DATE}} |
| Autor | {{ISB_NAME}} |
| Freigabe | {{GF_NAME}} |
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |

### Aenderungshistorie

| Version | Datum | Autor | Aenderung |
|---------|-------|-------|-----------|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |

---

## 1. Zweck und Geltungsbereich

Diese Richtlinie definiert die Sicherheitsanforderungen fuer die Nutzung von Cloud-Diensten bei {{COMPANY_NAME}}. Sie stellt sicher, dass Cloud-Services den gleichen Sicherheitsstandards unterliegen wie On-Premises-Systeme.

Geltungsbereich: Alle IaaS-, PaaS- und SaaS-Dienste, die von {{COMPANY_NAME}} genutzt oder betrieben werden.

Normative Grundlagen: ISO/IEC 27017:2015, ISO/IEC 27018:2019, BSI C5:2020, DSGVO Art. 28/32.

---

## 2. Shared-Responsibility-Modell

| Verantwortung | IaaS | PaaS | SaaS |
|--------------|------|------|------|
| Physische Sicherheit | Anbieter | Anbieter | Anbieter |
| Netzwerk-Infrastruktur | Anbieter | Anbieter | Anbieter |
| Betriebssystem | {{COMPANY_NAME}} | Anbieter | Anbieter |
| Anwendung | {{COMPANY_NAME}} | {{COMPANY_NAME}} | Anbieter |
| Datenklassifizierung | {{COMPANY_NAME}} | {{COMPANY_NAME}} | {{COMPANY_NAME}} |
| Zugriffskontrolle | {{COMPANY_NAME}} | {{COMPANY_NAME}} | {{COMPANY_NAME}} |
| Datensicherung | {{COMPANY_NAME}} | Geteilt | Geteilt |

---

## 3. Anbieterbewertung

Vor Nutzung eines Cloud-Dienstes ist eine Sicherheitsbewertung durch den ISB erforderlich:

| Kriterium | Anforderung |
|-----------|-------------|
| Zertifizierungen | ISO 27001, BSI C5 oder SOC 2 Type II |
| Datenstandort | EU/EWR (bei personenbezogenen Daten verpflichtend) |
| Auftragsverarbeitung | AVV nach Art. 28 DSGVO |
| Verschluesselung | At-rest + in-transit, kundenverwaltete Schluessel bei vertraulichen Daten |
| SLA | Verfuegbarkeit >= 99.9%, definierte Reaktionszeiten |
| Audit-Rechte | Nachweisrecht fuer {{COMPANY_NAME}} oder durch Dritte |

Cloud-Dienste ohne positive Bewertung duerfen nicht genutzt werden (Shadow-IT-Verbot).

---

## 4. Datenresidenz und Datenschutz

- Personenbezogene Daten: Speicherung und Verarbeitung ausschliesslich in EU/EWR
- Drittland-Transfer nur mit Angemessenheitsbeschluss oder Standardvertragsklauseln (SCC) + TIA
- Vertrauliche und streng vertrauliche Daten: Verschluesselung mit kundenverwalteten Schluesseln (BYOK/HYOK)
- Datentrennung: Mandantenfahige Isolation sichergestellt (logisch oder physisch)

---

## 5. Cloud-Sicherheitsmassnahmen

- **Identity & Access Management**: Zentrales IAM, SSO, MFA fuer alle Cloud-Konsolen
- **Network Security**: VPC/VNet-Segmentierung, Private Endpoints fuer Datenbankzugriffe
- **Monitoring**: Cloud-native Logging + Weiterleitung an zentrales SIEM
- **Infrastructure as Code**: Alle Cloud-Ressourcen werden per IaC verwaltet (Terraform, Pulumi)
- **Drift Detection**: Automatische Erkennung von Konfigurationsabweichungen

---

## 6. Exit-Strategie

{{COMPANY_NAME}} haelt fuer jeden Cloud-Dienst eine Exit-Strategie vor:

- Dokumentiertes Verfahren zur Datenmigration (Export-Formate, APIs)
- Maximale Kuendigungsfrist und Datenherausgabefrist vertraglich vereinbart
- Jaehrlicher Test der Datenportabilitaet fuer kritische Dienste
- Rueckfalloptionen: Alternativer Anbieter oder On-Premises-Betrieb

---

## 7. Revision

Jaehrliche Pruefung durch den ISB. Neubewertung bei Anbieterwechsel oder wesentlichen Vertragsaenderungen.

Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
$template$,
    '["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
    'de', 'DE',
    'mit', 'MIT License', 'BreakPilot Compliance',
    false, true, '1.0.0', 'published',
    NOW(), NOW()
WHERE NOT EXISTS (
    SELECT 1 FROM compliance_legal_templates
    WHERE document_type = 'cloud_security_policy'
      AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
);

-- Template 12: DevSecOps-Richtlinie
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
) SELECT
    gen_random_uuid(),
    '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
    'devsecops_policy',
    'DevSecOps-Richtlinie',
    'Richtlinie zur sicheren Softwareentwicklung nach ISO 27001 Annex A.14, OWASP und BSI IT-Grundschutz. Regelt SAST/DAST, Dependency Scanning, Container Security und CI/CD-Sicherheitsgates.',
    $template$# DevSecOps-Richtlinie

## Dokumentenkontrolle

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{DOCUMENT_VERSION}} |
| Datum | {{VERSION_DATE}} |
| Autor | {{ISB_NAME}} |
| Freigabe | {{GF_NAME}} |
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |

### Aenderungshistorie

| Version | Datum | Autor | Aenderung |
|---------|-------|-------|-----------|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |

---

## 1. Zweck und Geltungsbereich

Diese Richtlinie integriert Sicherheitsmassnahmen in den gesamten Software-Entwicklungslebenszyklus (SDLC) bei {{COMPANY_NAME}}. Ziel ist die fruehzeitige Erkennung und Behebung von Sicherheitsschwachstellen nach dem Shift-Left-Prinzip.

Geltungsbereich: Alle intern entwickelten Anwendungen, Bibliotheken, Container-Images und CI/CD-Pipelines.

Normative Grundlagen: ISO/IEC 27001:2022 Annex A.8.25-A.8.31, OWASP SAMM, BSI IT-Grundschutz CON.8.

---

## 2. Sichere Entwicklungsprinzipien

- **Secure by Design**: Sicherheitsanforderungen werden in der Entwurfsphase definiert
- **Secure by Default**: Standardkonfigurationen sind restriktiv (kein offener Zugriff, keine Default-Passwoerter)
- **Defense in Depth**: Mehrschichtige Absicherung auf Anwendungsebene
- **Least Privilege**: Anwendungen laufen mit minimalen Rechten
- **Input Validation**: Alle Eingaben werden serverseitig validiert und bereinigt

---

## 3. CI/CD-Sicherheitsgates

Jede Pipeline muss folgende Gates enthalten:

| Gate | Tool-Kategorie | Blockierend bei |
|------|---------------|----------------|
| SAST (Static Analysis) | SonarQube, Semgrep, o.Ae. | High/Critical Findings |
| SCA (Dependency Scan) | Trivy, Snyk, Dependabot | Known Exploited Vulnerabilities |
| Secret Detection | GitLeaks, TruffleHog | Jeder Fund |
| Container Scan | Trivy, Grype | Critical CVEs |
| DAST (Dynamic Analysis) | OWASP ZAP (Staging) | High Findings |
| License Check | FOSSA, license-checker | GPL/AGPL-Abhaengigkeiten |

Pipeline-Builds mit blockierenden Findings werden automatisch abgelehnt.

---

## 4. Code-Review und Merge-Anforderungen

| Kriterium | Anforderung |
|-----------|-------------|
| Review | Mindestens 1 Reviewer (2 bei sicherheitskritischen Aenderungen) |
| Branching | Feature-Branches, kein direkter Push auf main/production |
| Signierung | Commits muessen signiert sein (GPG oder SSH) |
| Tests | Alle Unit- und Integrationstests muessen bestehen |
| Coverage | Mindestens 80% Code-Coverage fuer neue Module |

---

## 5. Container-Sicherheit

- Base-Images: Nur freigegebene, gehaertete Base-Images verwenden
- Non-Root: Container laufen als non-root User
- Read-Only Filesystem: Wo moeglich, schreibgeschuetztes Root-Filesystem
- Image Signing: Alle Produktiv-Images werden signiert (Cosign/Notary)
- Kein SSH in Containern, keine Package-Manager in Produktiv-Images

---

## 6. Secrets in der Entwicklung

- Keine Secrets in Quellcode, Konfigurationsdateien oder Container-Images
- Secrets werden ausschliesslich ueber Secrets-Management-Systeme bereitgestellt
- Lokale Entwicklung: `.env`-Dateien in `.gitignore`, niemals committet
- Pre-Commit-Hooks pruefen auf versehentlich eingecheckte Secrets

---

## 7. Sicherheitsschulungen fuer Entwickler

- Jaehrliche sichere Entwicklungsschulung (OWASP Top 10, Secure Coding)
- Onboarding: Sicherheitseinweisung fuer neue Entwickler in der ersten Woche
- Threat Modelling: Fuer neue Features und Architekturentscheidungen

---

## 8. Revision

Jaehrliche Pruefung durch den ISB. Anpassung bei neuen Angriffsszenarien oder Tool-Aenderungen.

Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
$template$,
    '["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
    'de', 'DE',
    'mit', 'MIT License', 'BreakPilot Compliance',
    false, true, '1.0.0', 'published',
    NOW(), NOW()
WHERE NOT EXISTS (
    SELECT 1 FROM compliance_legal_templates
    WHERE document_type = 'devsecops_policy'
      AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
);

-- Template 13: Secrets-Management-Richtlinie
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
) SELECT
    gen_random_uuid(),
    '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
    'secrets_management_policy',
    'Secrets-Management-Richtlinie',
    'Richtlinie zum Secrets-Management nach ISO 27001 und BSI IT-Grundschutz. Regelt Vault-Nutzung, Rotation, Verbot hardcodierter Secrets, Audit-Protokollierung und Notfallzugriff.',
    $template$# Secrets-Management-Richtlinie

## Dokumentenkontrolle

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{DOCUMENT_VERSION}} |
| Datum | {{VERSION_DATE}} |
| Autor | {{ISB_NAME}} |
| Freigabe | {{GF_NAME}} |
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |

### Aenderungshistorie

| Version | Datum | Autor | Aenderung |
|---------|-------|-------|-----------|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |

---

## 1. Zweck und Geltungsbereich

Diese Richtlinie definiert den sicheren Umgang mit Secrets (Passwoerter, API-Schluessel, Zertifikate, Tokens, kryptographische Schluessel) bei {{COMPANY_NAME}}. Sie stellt sicher, dass Secrets zu keinem Zeitpunkt im Klartext offengelegt, in Code eingebettet oder unkontrolliert weitergegeben werden.

Geltungsbereich: Alle Systeme, Anwendungen, CI/CD-Pipelines und Mitarbeiter von {{COMPANY_NAME}}.

Normative Grundlagen: ISO/IEC 27001:2022 Annex A.5.33, BSI IT-Grundschutz ORP.4, NIST SP 800-57.

---

## 2. Secrets-Management-System

{{COMPANY_NAME}} betreibt ein zentrales Secrets-Management-System (z.B. HashiCorp Vault) als einzige autorisierte Quelle fuer Secrets.

| Anforderung | Umsetzung |
|-------------|-----------|
| Zentrale Speicherung | Alle Secrets im Vault, nicht in Dateien oder Datenbanken |
| Zugriffskontrolle | Policy-basiert, Least Privilege, MFA fuer Admin-Zugriff |
| Verschluesselung | At-rest (AES-256) und in-transit (TLS 1.2+) |
| Audit-Log | Jeder Zugriff wird protokolliert (wer, wann, welches Secret) |
| Hochverfuegbarkeit | Cluster-Betrieb mit automatischem Failover |

---

## 3. Rotation

| Secret-Typ | Rotationsintervall | Methode |
|-----------|-------------------|---------|
| Datenbank-Passwoerter | 90 Tage | Automatisch via Vault Dynamic Secrets |
| API-Schluessel | 180 Tage | Automatisch oder manuell mit Uebergangsphase |
| TLS-Zertifikate | 90 Tage (ACME/Let's Encrypt) | Automatisch |
| Service-Account-Tokens | 90 Tage | Automatisch via Token-Renewal |
| SSH-Schluessel | Einmalig (Signed SSH) | Vault SSH Secrets Engine |

Sofortige Rotation bei: Verdacht auf Kompromittierung, Mitarbeiteraustritt, Sicherheitsvorfall.

---

## 4. Verbotene Praktiken

Folgende Praktiken sind strengstens untersagt:

- Hardcodierte Secrets in Quellcode, Dockerfiles oder Konfigurationsdateien
- Secrets in Umgebungsvariablen auf Produktivsystemen (ausser via Vault Agent Injection)
- Versand von Secrets per E-Mail, Chat, Ticket oder unverschluesselten Kanaelen
- Speicherung in persoenlichen Notizen, Wikis oder Shared Drives
- Wiederverwendung von Secrets ueber Umgebungen hinweg (Dev/Staging/Prod)
- Nutzung von Secrets ohne Ablaufdatum

---

## 5. CI/CD-Integration

- Pipelines beziehen Secrets ausschliesslich zur Laufzeit aus dem Vault
- Keine Secrets in Pipeline-Konfigurationen (Jenkinsfile, .gitlab-ci.yml, GitHub Actions)
- Pre-Commit-Hooks (GitLeaks, TruffleHog) verhindern versehentliches Einchecken
- Build-Artefakte werden auf eingebettete Secrets gescannt

---

## 6. Notfallzugriff (Break Glass)

Fuer den Fall, dass der regulaere Vault-Zugriff nicht verfuegbar ist:

- Versiegelte Notfallzugaenge werden physisch sicher aufbewahrt (Tresor, Vier-Augen-Prinzip)
- Nutzung wird automatisch protokolliert und loest sofortige Benachrichtigung an ISB aus
- Nach Nutzung: Sofortige Rotation aller betroffenen Secrets
- Quartalsweise Pruefung der Notfallzugaenge auf Funktionsfaehigkeit

---

## 7. Revision

Jaehrliche Pruefung durch den ISB. Sofortige Pruefung nach jedem Incident mit Secret-Kompromittierung.

Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
$template$,
    '["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
    'de', 'DE',
    'mit', 'MIT License', 'BreakPilot Compliance',
    false, true, '1.0.0', 'published',
    NOW(), NOW()
WHERE NOT EXISTS (
    SELECT 1 FROM compliance_legal_templates
    WHERE document_type = 'secrets_management_policy'
      AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
);

-- Template 14: Schwachstellenmanagement-Richtlinie
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
) SELECT
    gen_random_uuid(),
    '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e',
    'vulnerability_management_policy',
    'Schwachstellenmanagement-Richtlinie',
    'Richtlinie zum Schwachstellenmanagement nach ISO 27001 Annex A.12.6 und BSI IT-Grundschutz. Regelt Scanning-Zeitplaene, CVSS-Klassifizierung, Behebungs-SLAs, Ausnahmen und Disclosure-Verfahren.',
    $template$# Schwachstellenmanagement-Richtlinie

## Dokumentenkontrolle

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{DOCUMENT_VERSION}} |
| Datum | {{VERSION_DATE}} |
| Autor | {{ISB_NAME}} |
| Freigabe | {{GF_NAME}} |
| Naechste Pruefung | {{NEXT_REVIEW_DATE}} |

### Aenderungshistorie

| Version | Datum | Autor | Aenderung |
|---------|-------|-------|-----------|
| {{DOCUMENT_VERSION}} | {{VERSION_DATE}} | {{ISB_NAME}} | Erstfassung |

---

## 1. Zweck und Geltungsbereich

Diese Richtlinie definiert den strukturierten Umgang mit technischen Schwachstellen bei {{COMPANY_NAME}}. Ziel ist die systematische Identifikation, Bewertung und Behebung von Schwachstellen, um die Angriffsflaeche zu minimieren.

Geltungsbereich: Alle IT-Systeme, Anwendungen, Container, Cloud-Ressourcen und Netzwerkkomponenten.

Normative Grundlagen: ISO/IEC 27001:2022 Annex A.8.8, BSI IT-Grundschutz OPS.1.1.3, NIST SP 800-40, CIS Controls v8.

---

## 2. Scanning-Zeitplan

| Scan-Typ | Frequenz | Ziel |
|----------|----------|------|
| Netzwerk-Schwachstellenscan | Woechentlich | Alle erreichbaren IP-Adressen und Ports |
| Webanwendungsscan (DAST) | 14-taegig | Alle externen Webanwendungen und APIs |
| Container-Image-Scan | Bei jedem Build + woechentlich | Alle Container-Images in Registry |
| Dependency-Scan (SCA) | Taeglich (automatisch) | Alle Softwareprojekte |
| Konfigurationsaudit | Monatlich | Cloud-Accounts, Server, Netzwerkgeraete |
| Penetrationstest | Jaehrlich (extern) | Gesamte externe Angriffsflaeche |

---

## 3. CVSS-Klassifizierung und Behebungs-SLAs

Schwachstellen werden nach CVSS v3.1 klassifiziert:

| CVSS-Score | Schweregrad | Behebungs-SLA | Eskalation bei Ueberschreitung |
|-----------|-------------|--------------|-------------------------------|
| 9.0 - 10.0 | Kritisch | 72 Stunden | Geschaeftsfuehrung + ISB |
| 7.0 - 8.9 | Hoch | 7 Tage | IT-Leitung + ISB |
| 4.0 - 6.9 | Mittel | 30 Tage | ISB |
| 0.1 - 3.9 | Niedrig | 90 Tage | Regulaerer Patch-Zyklus |

**Verschaerfung**: Bei aktiver Ausnutzung (KEV-Katalog) oder oeffentlichem Exploit-Code wird der SLA unabhaengig vom CVSS auf **24 Stunden** verkuerzt.

---

## 4. Bewertungsprozess

1. **Identifikation**: Automatischer Scan oder externe Meldung (Advisory, Bug Bounty)
2. **Triage**: ISB bewertet CVSS-Score, Exploitability und Kontext (erreichbar? exponiert?)
3. **Priorisierung**: Kontextuelle Risikobewertung unter Beruecksichtigung von Asset-Kritikalitaet
4. **Zuweisung**: Ticket im Vulnerability-Tracker mit Verantwortlichem und SLA-Deadline
5. **Behebung**: Patch, Konfigurationsaenderung oder Kompensationsmassnahme
6. **Verifizierung**: Erneuter Scan bestaetigt Schliessung der Schwachstelle
7. **Abschluss**: Dokumentation im Vulnerability-Tracker

---

## 5. Ausnahmen und Risikoakzeptanz

Falls eine Schwachstelle nicht innerhalb des SLA behoben werden kann:

- Schriftlicher Antrag durch den Systemverantwortlichen mit Begruendung
- Dokumentation von Kompensationsmassnahmen (z.B. WAF-Regel, Network Segmentation, Monitoring)
- Genehmigung durch ISB ({{ISB_NAME}}); ab CVSS >= 9.0 zusaetzlich Geschaeftsfuehrung
- Maximale Ausnahmedauer: 90 Tage, danach Neubewertung
- Alle Ausnahmen werden im Risikomanagement-System nachverfolgt

---

## 6. Responsible Disclosure

{{COMPANY_NAME}} betreibt einen Responsible-Disclosure-Prozess:

- Sicherheitsforscher koennen Schwachstellen an security@{{COMPANY_NAME}}.de melden
- Bestaetigung des Eingangs innerhalb von 2 Arbeitstagen
- Gemeinsame Abstimmung eines Zeitplans fuer die Behebung (max. 90 Tage)
- Keine rechtlichen Schritte gegen gutglaeubige Sicherheitsforscher
- Oeffentliche Anerkennung (Hall of Fame) nach Zustimmung des Meldenden

---

## 7. Metriken und Reporting

Der ISB berichtet quartalsweise an die Geschaeftsfuehrung:

| Metrik | Beschreibung |
|--------|-------------|
| MTTR (Mean Time to Remediate) | Durchschnittliche Behebungszeit pro Schweregrad |
| Offene Schwachstellen | Anzahl offener Findings nach Schweregrad und Alter |
| SLA-Einhaltung | Prozentsatz innerhalb des SLA behobener Schwachstellen |
| Scan-Abdeckung | Anteil der gescannten Assets an Gesamtinventar |
| Risikoakzeptanzen | Anzahl und Alter aktiver Ausnahmen |

---

## 8. Revision

Jaehrliche Pruefung durch den ISB. Sofortige Anpassung nach groesseren Sicherheitsvorfaellen oder bei veraenderter Bedrohungslage.

Naechste Pruefung: {{NEXT_REVIEW_DATE}}.
$template$,
    '["COMPANY_NAME","ISB_NAME","GF_NAME","DOCUMENT_VERSION","VERSION_DATE","NEXT_REVIEW_DATE"]'::jsonb,
    'de', 'DE',
    'mit', 'MIT License', 'BreakPilot Compliance',
    false, true, '1.0.0', 'published',
    NOW(), NOW()
WHERE NOT EXISTS (
    SELECT 1 FROM compliance_legal_templates
    WHERE document_type = 'vulnerability_management_policy'
      AND tenant_id = '9282a473-5c95-4b3a-bf78-0ecc0ec71d3e'
);
