breakpilot-compliance/backend-compliance/scripts/seed_policy_templates.py

#!/usr/bin/env python3
"""Seed ~29 policy templates into the compliance legal_templates table via API."""

import json
import sys
import requests

API = "https://api-dev.breakpilot.ai/api/compliance/legal-templates"
HEADERS = {
    "Content-Type": "application/json",
    "X-Tenant-Id": "9282a473-5c95-4b3a-bf78-0ecc0ec71d3e",
    "X-User-Id": "admin",
}

BASE = {
    "language": "de",
    "jurisdiction": "DE",
    "license_id": "mit",
    "license_name": "MIT License",
    "source_name": "BreakPilot Compliance",
    "attribution_required": False,
    "is_complete_document": True,
    "version": "1.0.0",
    "status": "published",
}


TEMPLATES = [
# ── 1. Information Security Policy ──────────────────────────────────
{
    "document_type": "information_security_policy",
    "title": "Informationssicherheits-Richtlinie",
    "description": "Grundlegende Prinzipien der Informationssicherheit. Definiert Schutzziele, Verantwortlichkeiten und Rahmenbedingungen.",
    "placeholders": ["{{COMPANY_NAME}}", "{{SECURITY_OFFICER}}", "{{VERSION}}", "{{DATE}}", "{{SCOPE_DESCRIPTION}}", "{{GF_NAME}}"],
    "content": """# Informationssicherheits-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |
| Verantwortlich | {{SECURITY_OFFICER}} |
| Freigabe | {{GF_NAME}} |

## 1. Zweck

Diese Richtlinie definiert die grundlegenden Prinzipien der Informationssicherheit bei {{COMPANY_NAME}}.

## 2. Geltungsbereich

{{SCOPE_DESCRIPTION}}

Diese Policy gilt fuer alle Mitarbeiter, Systeme, Anwendungen und Datenverarbeitungsprozesse.

## 3. Begriffe

- **Vertraulichkeit**: Schutz vor unbefugtem Zugriff
- **Integritaet**: Schutz vor unbefugter Aenderung
- **Verfuegbarkeit**: Sicherstellung der Nutzbarkeit

## 4. Richtlinie

{{COMPANY_NAME}} verpflichtet sich zur Sicherstellung von Vertraulichkeit, Integritaet und Verfuegbarkeit aller Informationswerte. Die Informationssicherheit ist integraler Bestandteil aller Geschaeftsprozesse.

## 5. Rollen und Verantwortlichkeiten

| Rolle | Verantwortung |
|-------|---------------|
| Geschaeftsfuehrung | Gesamtverantwortung, Budget, strategische Ausrichtung |
| {{SECURITY_OFFICER}} | Operative Steuerung, Konzepte, Audits, Berichtswesen |
| Fuehrungskraefte | Umsetzung in ihrem Verantwortungsbereich |
| Alle Mitarbeiter | Einhaltung der Richtlinien, Meldung von Vorfaellen |

## 6. Umsetzung

- Technische und organisatorische Massnahmen (TOMs)
- Zugriffskontrollen nach Least-Privilege-Prinzip
- Verschluesselung sensibler Daten
- Regelmaessige Sicherheitsschulungen
- Kontinuierliches Monitoring

## 7. Ueberwachung und Durchsetzung

Die Einhaltung wird durch regelmaessige Audits und Reviews ueberprueft. Verstoesse werden dokumentiert und koennen arbeitsrechtliche Konsequenzen haben.

## 8. Ausnahmen

Ausnahmen muessen schriftlich beim {{SECURITY_OFFICER}} beantragt und von der Geschaeftsfuehrung genehmigt werden. Jede Ausnahme wird mit Risikobewertung dokumentiert.

## 9. Pruefzyklus

Diese Richtlinie wird mindestens jaehrlich oder bei wesentlichen Aenderungen ueberprueft.
""",
},

# ── 2. Access Control Policy ────────────────────────────────────────
{
    "document_type": "access_control_policy",
    "title": "Zugriffskontrollen-Richtlinie",
    "description": "Anforderungen an Zugriffskontrollen auf Systeme und Daten. Least Privilege, RBAC, Reviews.",
    "placeholders": ["{{COMPANY_NAME}}", "{{SECURITY_OFFICER}}", "{{VERSION}}", "{{DATE}}", "{{MFA_REQUIRED}}", "{{ACCESS_REVIEW_FREQUENCY}}"],
    "content": """# Zugriffskontrollen-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Definition von Anforderungen an Zugriffskontrollen auf Systeme und Daten.

## 2. Geltungsbereich

Alle IT-Systeme, Anwendungen und Netzwerke von {{COMPANY_NAME}}.

## 3. Richtlinie

Zugriffe werden nach dem Prinzip der minimalen Rechtevergabe (Least Privilege) gewaehrt. Jeder Zugriff muss geschaeftlich begruendet sein.

## 4. Authentifizierung

- Alle Benutzer muessen eindeutig authentifiziert werden
- Multi-Faktor-Authentifizierung: {{MFA_REQUIRED}}
- Passwortanforderungen gemaess Passwort-Richtlinie

## 5. Autorisierung

- Rollenbasierte Zugriffskontrolle (RBAC)
- Zugriffsrechte werden vom Fachverantwortlichen beantragt
- Genehmigung durch Vorgesetzten und IT-Sicherheit

## 6. Zugriffspruefungen

Zugriffsrechte werden {{ACCESS_REVIEW_FREQUENCY}} ueberprueft. Nicht mehr benoetigte Rechte werden umgehend entzogen.

## 7. Ueberwachung

Zugriffe werden protokolliert und auf Anomalien ueberwacht.

## 8. Ausnahmen

Ausnahmen muessen dokumentiert und genehmigt werden.

## 9. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 3. Password Policy ─────────────────────────────────────────────
{
    "document_type": "password_policy",
    "title": "Passwort-Richtlinie",
    "description": "Anforderungen an sichere Passwoerter, Speicherung, Reset-Verfahren und Monitoring.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{MIN_PASSWORD_LENGTH}}", "{{PASSWORD_EXPIRY_DAYS}}", "{{MAX_LOGIN_ATTEMPTS}}"],
    "content": """# Passwort-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Definition von Anforderungen an sichere Passwoerter.

## 2. Anforderungen

Passwoerter muessen:
- Mindestens {{MIN_PASSWORD_LENGTH}} Zeichen lang sein
- Gross- und Kleinbuchstaben enthalten
- Mindestens ein Sonderzeichen enthalten
- Nicht in gaengigen Woerterlisten vorkommen

## 3. Speicherung

Passwoerter duerfen nur in gehashter Form gespeichert werden (bcrypt, Argon2 oder gleichwertig).

## 4. Gueltigkeitsdauer

Passwoerter laufen nach {{PASSWORD_EXPIRY_DAYS}} Tagen ab. Die letzten 12 Passwoerter duerfen nicht wiederverwendet werden.

## 5. Reset-Verfahren

Passwort-Resets erfolgen ueber sichere, identitaetsverifizierte Verfahren.

## 6. Ueberwachung

- Fehlgeschlagene Loginversuche werden protokolliert
- Nach {{MAX_LOGIN_ATTEMPTS}} Fehlversuchen wird das Konto temporaer gesperrt

## 7. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 4. Encryption Policy ───────────────────────────────────────────
{
    "document_type": "encryption_policy",
    "title": "Verschluesselungs-Richtlinie",
    "description": "Sicherstellung der Verschluesselung sensibler Daten in Transit und at Rest.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{KEY_ROTATION_MONTHS}}"],
    "content": """# Verschluesselungs-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Sicherstellung der Verschluesselung sensibler Daten bei {{COMPANY_NAME}}.

## 2. Geltungsbereich

Alle Datenuebertragungen und Datenspeicher.

## 3. Richtlinie

### In Transit
- TLS 1.2+ fuer alle externen Verbindungen
- TLS 1.3 bevorzugt
- Keine selbstsignierten Zertifikate in Produktion

### At Rest
- AES-256 fuer gespeicherte Daten
- Datenbank-Verschluesselung fuer personenbezogene Daten

### Verbotene Algorithmen
MD5, SHA-1, DES, 3DES, RC4

## 4. Schluesselverwaltung

- Schluessel werden in einem dedizierten Key Management System verwaltet
- Rotation alle {{KEY_ROTATION_MONTHS}} Monate
- Schluessel und Daten werden getrennt gespeichert

## 5. Ueberwachung

Kryptographische Implementierungen werden regelmaessig ueberprueft.

## 6. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 5. Logging Policy ──────────────────────────────────────────────
{
    "document_type": "logging_policy",
    "title": "Logging-Richtlinie",
    "description": "Anforderungen an Logging und Monitoring. Aufbewahrung, Schutz und Analyse von Protokolldaten.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{LOG_RETENTION_PERIOD}}", "{{SIEM_SYSTEM}}"],
    "content": """# Logging-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Definition von Anforderungen an Logging und Monitoring bei {{COMPANY_NAME}}.

## 2. Geltungsbereich

Alle IT-Systeme und Anwendungen.

## 3. Richtlinie

Folgende Ereignisse muessen protokolliert werden:
- Authentisierungsversuche (erfolgreich und fehlgeschlagen)
- Systemkonfigurationsaenderungen
- Zugriffe auf sensible Daten
- Sicherheitsereignisse und Alarme
- Administrative Aktionen

## 4. Aufbewahrung

Logs werden mindestens {{LOG_RETENTION_PERIOD}} aufbewahrt.

## 5. Schutz

- Logs sind gegen Manipulation zu schuetzen (Write-Once, zentrale Sammlung)
- Zugriff auf Logs ist auf autorisiertes Personal beschraenkt
- Zentrales SIEM: {{SIEM_SYSTEM}}

## 6. Analyse

Logs werden regelmaessig auf Anomalien und Sicherheitsvorfaelle analysiert.

## 7. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 6. Backup Policy ──────────────────────────────────────────────
{
    "document_type": "backup_policy",
    "title": "Backup-Richtlinie",
    "description": "Sicherstellung der Wiederherstellbarkeit von Daten. Backup-Frequenz, Speicherung, Tests.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{BACKUP_FREQUENCY}}", "{{BACKUP_RETENTION_DAYS}}", "{{RTO_HOURS}}", "{{RPO_HOURS}}"],
    "content": """# Backup-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Sicherstellung der Wiederherstellbarkeit von Daten bei {{COMPANY_NAME}}.

## 2. Geltungsbereich

Alle geschaeftskritischen Systeme und Daten.

## 3. Backup-Frequenz

Backups erfolgen mindestens {{BACKUP_FREQUENCY}}.

| Datenklasse | Frequenz | Aufbewahrung |
|-------------|----------|--------------|
| Kritisch | Taeglich | {{BACKUP_RETENTION_DAYS}} Tage |
| Standard | Woechentlich | 30 Tage |
| Archiv | Monatlich | 365 Tage |

## 4. Wiederherstellungsziele

- RTO (Recovery Time Objective): {{RTO_HOURS}} Stunden
- RPO (Recovery Point Objective): {{RPO_HOURS}} Stunden

## 5. Speicherung

Backups werden verschluesselt und georedundant gespeichert.

## 6. Tests

Backup-Wiederherstellungen werden quartalsweise getestet und dokumentiert.

## 7. Ueberwachung

Backup-Prozesse werden automatisiert ueberwacht. Fehler werden sofort eskaliert.

## 8. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 7. Incident Response Policy ────────────────────────────────────
{
    "document_type": "incident_response_policy",
    "title": "Incident-Response-Richtlinie",
    "description": "Massnahmen bei Sicherheitsvorfaellen. Meldewege, Eskalation, Dokumentation.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{INCIDENT_REPORT_CHANNEL}}", "{{SECURITY_OFFICER}}", "{{DPO_NAME}}", "{{NOTIFICATION_DEADLINE_HOURS}}"],
    "content": """# Incident-Response-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Definition von Massnahmen bei Sicherheitsvorfaellen bei {{COMPANY_NAME}}.

## 2. Vorfallsdefinition

Ein Sicherheitsvorfall ist jede tatsaechliche oder vermutete Verletzung der Informationssicherheit, einschliesslich Datenschutzverletzungen gemaess Art. 33 DSGVO.

## 3. Meldung

- Meldung ueber: {{INCIDENT_REPORT_CHANNEL}}
- Erste Meldung innerhalb von 1 Stunde nach Entdeckung
- Meldung an Aufsichtsbehoerde innerhalb {{NOTIFICATION_DEADLINE_HOURS}} Stunden (bei Datenschutzvorfaellen)

## 4. Response-Prozess

1. **Erkennung** — Vorfall identifizieren und klassifizieren
2. **Analyse** — Ausmass und Ursache bestimmen
3. **Eindaemmung** — Schaden begrenzen
4. **Beseitigung** — Ursache beheben
5. **Wiederherstellung** — Normalbetrieb herstellen
6. **Nachbereitung** — Lessons Learned dokumentieren

## 5. Eskalation

| Schwere | Eskalation an |
|---------|---------------|
| Kritisch | Geschaeftsfuehrung + {{SECURITY_OFFICER}} + {{DPO_NAME}} sofort |
| Hoch | {{SECURITY_OFFICER}} innerhalb 1h |
| Mittel | IT-Leitung innerhalb 4h |

## 6. Dokumentation

Alle Vorfaelle werden lueckenlos dokumentiert und archiviert.

## 7. Pruefzyklus

Jaehrliche Ueberpruefung. Zusaetzlich nach jedem schweren Vorfall.
""",
},

# ── 8. Change Management Policy ────────────────────────────────────
{
    "document_type": "change_management_policy",
    "title": "Change-Management-Richtlinie",
    "description": "Kontrolle von Aenderungen an IT-Systemen. Genehmigung, Tests, Dokumentation.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{CAB_MEMBERS}}"],
    "content": """# Change-Management-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Kontrolle von Aenderungen an IT-Systemen bei {{COMPANY_NAME}}.

## 2. Geltungsbereich

Alle Produktionssysteme, Netzwerke und sicherheitsrelevante Konfigurationen.

## 3. Change-Prozess

Aenderungen muessen:
- Dokumentiert (Change Request)
- Risikobewertung durchgefuehrt
- Genehmigt (Change Advisory Board)
- In Testumgebung validiert
- Mit Rollback-Plan versehen sein

## 4. Change Advisory Board

Mitglieder: {{CAB_MEMBERS}}

## 5. Notfallaenderungen

Notfallaenderungen muessen nachtraeglich innerhalb von 48h dokumentiert und genehmigt werden.

## 6. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 9. Patch Management Policy ─────────────────────────────────────
{
    "document_type": "patch_management_policy",
    "title": "Patch-Management-Richtlinie",
    "description": "Sicherstellung zeitnaher Sicherheitsupdates. Fristen, Priorisierung, Monitoring.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{CRITICAL_PATCH_HOURS}}", "{{HIGH_PATCH_DAYS}}", "{{STANDARD_PATCH_DAYS}}"],
    "content": """# Patch-Management-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Sicherstellung zeitnaher Sicherheitsupdates bei {{COMPANY_NAME}}.

## 2. Geltungsbereich

Alle Systeme, Anwendungen und Bibliotheken.

## 3. Patch-Fristen

| Schweregrad | Frist |
|-------------|-------|
| Kritisch (CVSS >= 9.0) | {{CRITICAL_PATCH_HOURS}} Stunden |
| Hoch (CVSS 7.0-8.9) | {{HIGH_PATCH_DAYS}} Tage |
| Mittel/Niedrig | {{STANDARD_PATCH_DAYS}} Tage |

## 4. Ueberwachung

Patchstatus wird automatisiert ueberwacht und monatlich reportet.

## 5. Ausnahmen

Ausnahmen muessen mit Risikobewertung dokumentiert und genehmigt werden.

## 6. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 10. Asset Management Policy ────────────────────────────────────
{
    "document_type": "asset_management_policy",
    "title": "Asset-Management-Richtlinie",
    "description": "Verwaltung aller IT-Assets. Inventarisierung, Klassifizierung, Entsorgung.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{ASSET_REVIEW_FREQUENCY}}"],
    "content": """# Asset-Management-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Verwaltung aller IT-Assets bei {{COMPANY_NAME}}.

## 2. Asset-Inventar

Alle Hardware, Software, Cloud-Dienste und Datenbestaende muessen inventarisiert sein.

## 3. Eigentuemer

Jedes Asset hat einen verantwortlichen Eigentuemer, der fuer Schutz und Pflege zustaendig ist.

## 4. Klassifizierung

| Stufe | Beschreibung | Schutzbedarf |
|-------|-------------|--------------|
| Kritisch | Geschaeftskritische Systeme | Sehr hoch |
| Wichtig | Unterstuetzende Systeme | Hoch |
| Standard | Bueroausstattung | Normal |

## 5. Ueberprufung

Asset-Inventar wird {{ASSET_REVIEW_FREQUENCY}} ueberprueft.

## 6. Entsorgung

Assets werden nach NIST 800-88 oder gleichwertig sicher entsorgt. Datentraeger werden zertifiziert vernichtet.

## 7. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 11. Cloud Security Policy ──────────────────────────────────────
{
    "document_type": "cloud_security_policy",
    "title": "Cloud-Sicherheits-Richtlinie",
    "description": "Sicherheitsanforderungen fuer Cloud-Nutzung. Zugelassene Anbieter, Konfiguration, Monitoring.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{CLOUD_PROVIDERS}}", "{{DATA_RESIDENCY}}"],
    "content": """# Cloud-Sicherheits-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Definition von Sicherheitsanforderungen fuer Cloud-Nutzung bei {{COMPANY_NAME}}.

## 2. Zugelassene Anbieter

{{CLOUD_PROVIDERS}}

Neue Cloud-Dienste muessen vor Nutzung durch IT-Sicherheit freigegeben werden.

## 3. Sicherheitsanforderungen

- Verschluesselung aller Daten (at rest und in transit)
- Zugriffskontrollen mit MFA
- Logging und Monitoring aller Aktivitaeten
- Datenresidenz: {{DATA_RESIDENCY}}

## 4. Konfigurationsmanagement

Cloud-Konfigurationen werden per Infrastructure-as-Code verwaltet und regelmaessig auf Fehlkonfigurationen geprueft.

## 5. Ueberwachung

Cloud-Security-Posture wird kontinuierlich ueberwacht.

## 6. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 12. DevSecOps Policy ───────────────────────────────────────────
{
    "document_type": "devsecops_policy",
    "title": "DevSecOps-Richtlinie",
    "description": "Integration von Sicherheitsmassnahmen in Entwicklungsprozesse. SDLC, Code Review, Security Testing.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}"],
    "content": """# DevSecOps-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Integration von Sicherheitsmassnahmen in alle Phasen des Softwareentwicklungsprozesses bei {{COMPANY_NAME}}.

## 2. Secure Development Lifecycle

- Threat Modeling in der Planungsphase
- Sichere Coding-Standards (OWASP Top 10)
- Dependency-Scanning in der CI/CD-Pipeline

## 3. Code Review

Alle Codeaenderungen werden durch mindestens eine weitere Person geprueft. Sicherheitsrelevante Aenderungen erfordern Review durch Security-Team.

## 4. Security Testing

- SAST (Static Application Security Testing) in der CI-Pipeline
- DAST (Dynamic Application Security Testing) vor Releases
- Regelmaessige Penetrationstests

## 5. Secrets im Code

Secrets duerfen nicht im Quellcode gespeichert werden. Pre-Commit-Hooks pruefen auf versehentlich eingecheckte Secrets.

## 6. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 13. Secrets Management Policy ──────────────────────────────────
{
    "document_type": "secrets_management_policy",
    "title": "Secrets-Management-Richtlinie",
    "description": "Schutz von API Keys, Zugangsdaten und Zertifikaten. Speicherung, Rotation, Zugriffskontrolle.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{VAULT_SYSTEM}}", "{{SECRET_ROTATION_DAYS}}"],
    "content": """# Secrets-Management-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Schutz von API Keys, Zugangsdaten und Zertifikaten bei {{COMPANY_NAME}}.

## 2. Speicherung

Secrets duerfen ausschliesslich in {{VAULT_SYSTEM}} gespeichert werden. Klartext-Speicherung in Code, Konfigurationsdateien oder Dokumenten ist verboten.

## 3. Zugriffskontrolle

Zugriff auf Secrets ist auf die minimal notwendigen Personen und Systeme beschraenkt.

## 4. Rotation

Secrets werden alle {{SECRET_ROTATION_DAYS}} Tage rotiert. Bei Verdacht auf Kompromittierung sofort.

## 5. Audit

Alle Zugriffe auf Secrets werden protokolliert und ueberwacht.

## 6. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 14. Vulnerability Management Policy ────────────────────────────
{
    "document_type": "vulnerability_management_policy",
    "title": "Schwachstellenmanagement-Richtlinie",
    "description": "Erkennung, Priorisierung und Behebung von Schwachstellen.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{SCAN_FREQUENCY}}", "{{CRITICAL_FIX_HOURS}}"],
    "content": """# Schwachstellenmanagement-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Erkennung und Behandlung von Schwachstellen bei {{COMPANY_NAME}}.

## 2. Scanning

Schwachstellenscans werden {{SCAN_FREQUENCY}} durchgefuehrt. Scope: alle exponierten Systeme und Anwendungen.

## 3. Priorisierung

Schwachstellen werden nach CVSS-Score priorisiert:

| CVSS | Prioritaet | Frist |
|------|-----------|-------|
| 9.0+ | Kritisch | {{CRITICAL_FIX_HOURS}} Stunden |
| 7.0-8.9 | Hoch | 7 Tage |
| 4.0-6.9 | Mittel | 30 Tage |
| < 4.0 | Niedrig | 90 Tage |

## 4. Behebung

Behebung innerhalb der definierten Fristen. Abweichungen muessen mit Risikobewertung genehmigt werden.

## 5. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 15. Data Protection Policy ─────────────────────────────────────
{
    "document_type": "data_protection_policy",
    "title": "Datenschutz-Richtlinie",
    "description": "Grundsaetze des Datenschutzes gemaess DSGVO. Rechtsgrundlagen, Betroffenenrechte, TOMs.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{DPO_NAME}}", "{{DPO_EMAIL}}", "{{SUPERVISORY_AUTHORITY}}"],
    "content": """# Datenschutz-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |
| DSB | {{DPO_NAME}} ({{DPO_EMAIL}}) |

## 1. Zweck

Sicherstellung der Einhaltung der DSGVO und des BDSG bei {{COMPANY_NAME}}.

## 2. Geltungsbereich

Alle Verarbeitungen personenbezogener Daten.

## 3. Grundsaetze

- Rechtmaessigkeit, Verarbeitung nach Treu und Glauben, Transparenz
- Zweckbindung
- Datenminimierung
- Richtigkeit
- Speicherbegrenzung
- Integritaet und Vertraulichkeit

## 4. Rechtsgrundlagen

Jede Verarbeitung erfordert eine Rechtsgrundlage gemaess Art. 6 DSGVO.

## 5. Betroffenenrechte

Auskunft (Art. 15), Berichtigung (Art. 16), Loeschung (Art. 17), Einschraenkung (Art. 18), Datenportabilitaet (Art. 20), Widerspruch (Art. 21).

## 6. Datenschutzbeauftragter

{{DPO_NAME}} — Kontakt: {{DPO_EMAIL}}

## 7. Aufsichtsbehoerde

{{SUPERVISORY_AUTHORITY}}

## 8. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 16. Data Classification Policy ─────────────────────────────────
{
    "document_type": "data_classification_policy",
    "title": "Datenklassifizierungs-Richtlinie",
    "description": "Klassifizierung von Daten nach Schutzbedarf. Stufen, Kennzeichnung, Handhabung.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}"],
    "content": """# Datenklassifizierungs-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Einheitliche Klassifizierung von Daten nach Schutzbedarf bei {{COMPANY_NAME}}.

## 2. Klassifizierungsstufen

| Stufe | Kennzeichnung | Beispiele | Schutzmassnahmen |
|-------|--------------|-----------|-----------------|
| Oeffentlich | OEFFENTLICH | Marketing-Material | Keine besonderen |
| Intern | INTERN | Interne Memos | Zugriffskontrolle |
| Vertraulich | VERTRAULICH | Personaldaten, Vertraege | Verschluesselung + Zugriffskontrolle |
| Streng vertraulich | STRENG VERTRAULICH | Geschaeftsgeheimnisse | Verschluesselung + Need-to-Know |

## 3. Verantwortlichkeit

Der Dateneigentuemer ist fuer die korrekte Klassifizierung verantwortlich.

## 4. Kennzeichnung

Alle Dokumente und Datenspeicher muessen entsprechend gekennzeichnet werden.

## 5. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 17. Data Retention Policy ──────────────────────────────────────
{
    "document_type": "data_retention_policy",
    "title": "Datenaufbewahrungs-Richtlinie",
    "description": "Aufbewahrungsfristen und Loeschprozesse fuer verschiedene Datenkategorien.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{DPO_NAME}}"],
    "content": """# Datenaufbewahrungs-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Definition von Aufbewahrungsfristen und Loeschprozessen bei {{COMPANY_NAME}}.

## 2. Grundsatz

Daten werden nur so lange aufbewahrt, wie es fuer den Verarbeitungszweck erforderlich oder gesetzlich vorgeschrieben ist (Art. 5 Abs. 1 lit. e DSGVO).

## 3. Aufbewahrungsfristen

| Datenkategorie | Frist | Rechtsgrundlage |
|----------------|-------|-----------------|
| Buchungsbelege | 10 Jahre | HGB §257, AO §147 |
| Handelsbriefe | 6 Jahre | HGB §257 |
| Bewerbungsunterlagen | 6 Monate | AGG §15 |
| Vertragsdaten | Vertragsende + 3 Jahre | BGB §195 |
| Protokolldaten | 90 Tage | Berechtigtes Interesse |

## 4. Loeschprozess

Daten werden nach Ablauf der Frist automatisiert oder manuell geloescht. Die Loeschung wird dokumentiert.

## 5. Verantwortlich

{{DPO_NAME}} ueberwacht die Einhaltung der Fristen.

## 6. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 18. Data Transfer Policy ───────────────────────────────────────
{
    "document_type": "data_transfer_policy",
    "title": "Datentransfer-Richtlinie",
    "description": "Regelungen fuer Datenuebermittlung, insbesondere in Drittlaender. Garantien, Vertraege.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{DPO_NAME}}"],
    "content": """# Datentransfer-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Regelungen fuer die Uebermittlung personenbezogener Daten bei {{COMPANY_NAME}}.

## 2. Drittlandtransfers

Datenuebermittlung in Laender ausserhalb des EWR nur mit:
- Angemessenheitsbeschluss der EU-Kommission
- Standardvertragsklauseln (SCCs)
- Binding Corporate Rules

## 3. Auftragsverarbeitung

Datenuebermittlung an Auftragsverarbeiter nur mit AVV gemaess Art. 28 DSGVO.

## 4. Technische Sicherung

Alle Datentransfers muessen verschluesselt erfolgen (TLS 1.2+).

## 5. Dokumentation

Jeder regelmaessige Datentransfer wird im Verzeichnis der Verarbeitungstaetigkeiten dokumentiert.

## 6. Pruefzyklus

Jaehrliche Ueberpruefung durch {{DPO_NAME}}.
""",
},

# ── 19. Privacy Incident Policy ────────────────────────────────────
{
    "document_type": "privacy_incident_policy",
    "title": "Datenschutzvorfall-Richtlinie",
    "description": "Meldepflichten bei Datenschutzverletzungen gemaess Art. 33/34 DSGVO.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{DPO_NAME}}", "{{DPO_EMAIL}}", "{{SUPERVISORY_AUTHORITY}}"],
    "content": """# Datenschutzvorfall-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Regelung der Meldepflichten bei Datenschutzverletzungen gemaess Art. 33/34 DSGVO.

## 2. Definition

Eine Datenschutzverletzung ist eine Verletzung der Sicherheit, die zur Vernichtung, zum Verlust, zur Veraenderung oder zur unbefugten Offenlegung personenbezogener Daten fuehrt.

## 3. Interne Meldung

Jeder Mitarbeiter meldet vermutete Datenschutzvorfaelle unverzueglich an {{DPO_NAME}} ({{DPO_EMAIL}}).

## 4. Behoerdenmeldung (Art. 33)

Meldung an {{SUPERVISORY_AUTHORITY}} innerhalb von 72 Stunden, sofern ein Risiko fuer Betroffene besteht.

## 5. Betroffeneninformation (Art. 34)

Bei hohem Risiko werden Betroffene unverzueglich informiert.

## 6. Dokumentation

Jeder Vorfall wird im Datenschutzvorfall-Register dokumentiert — unabhaengig davon, ob eine Meldepflicht besteht.

## 7. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 20. Employee Security Policy ───────────────────────────────────
{
    "document_type": "employee_security_policy",
    "title": "Mitarbeiter-Sicherheitsrichtlinie",
    "description": "Sicherheitspflichten fuer Mitarbeiter. Vertraulichkeit, Clean Desk, Meldepflichten.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{SECURITY_OFFICER}}"],
    "content": """# Mitarbeiter-Sicherheitsrichtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Definition der Sicherheitspflichten fuer alle Mitarbeiter von {{COMPANY_NAME}}.

## 2. Vertraulichkeit

Geschaeftliche Informationen duerfen nicht an Unbefugte weitergegeben werden. Die Vertraulichkeitsverpflichtung gilt ueber das Arbeitsverhaeltnis hinaus.

## 3. Clean Desk / Clear Screen

- Arbeitsplatz bei Verlassen aufraeumen
- Bildschirmsperre nach 5 Minuten Inaktivitaet
- Vertrauliche Dokumente im Schredder oder verschlossenen Behaelter entsorgen

## 4. Geraetesicherheit

- Dienstgeraete verschluesseln
- Keine privaten USB-Speicher an Dienstgeraeten
- Geraeteverlust sofort an {{SECURITY_OFFICER}} melden

## 5. Meldepflicht

Sicherheitsvorfaelle, verdaechtiges Verhalten und Phishing-Versuche sind unverzueglich zu melden.

## 6. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 21. Security Awareness Policy ──────────────────────────────────
{
    "document_type": "security_awareness_policy",
    "title": "Security-Awareness-Richtlinie",
    "description": "Schulungs- und Sensibilisierungsprogramm fuer Informationssicherheit.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{TRAINING_FREQUENCY}}", "{{PHISHING_SIM_FREQUENCY}}"],
    "content": """# Security-Awareness-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Sicherstellung eines angemessenen Sicherheitsbewusstseins bei allen Mitarbeitern von {{COMPANY_NAME}}.

## 2. Schulungsprogramm

- Onboarding-Sicherheitsschulung fuer neue Mitarbeiter (Pflicht)
- Auffrischungsschulung: {{TRAINING_FREQUENCY}}
- Rollenspezifische Vertiefungen fuer IT, Entwicklung und Fuehrungskraefte

## 3. Phishing-Simulationen

Simulierte Phishing-Kampagnen: {{PHISHING_SIM_FREQUENCY}}. Ergebnisse werden anonymisiert ausgewertet.

## 4. Themen

- Passwortsicherheit und MFA
- Phishing und Social Engineering
- Datenschutz und DSGVO
- Sichere Nutzung von Cloud-Diensten
- Meldung von Sicherheitsvorfaellen

## 5. Erfolgsmessung

| KPI | Zielwert |
|-----|---------|
| Schulungsquote | 100% |
| Phishing-Klickrate | < 5% |

## 6. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 22. Remote Work Policy ─────────────────────────────────────────
{
    "document_type": "remote_work_policy",
    "title": "Remote-Work-Richtlinie",
    "description": "Sicherheitsanforderungen fuer mobiles Arbeiten und Homeoffice.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{VPN_REQUIRED}}"],
    "content": """# Remote-Work-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Sicherheitsanforderungen fuer mobiles Arbeiten und Homeoffice bei {{COMPANY_NAME}}.

## 2. Netzwerksicherheit

- VPN-Pflicht: {{VPN_REQUIRED}}
- Kein Zugriff auf Unternehmensdaten ueber oeffentliche WLANs ohne VPN
- Privates Netzwerk mit WPA3-Verschluesselung empfohlen

## 3. Geraetesicherheit

- Nur genehmigte Dienstgeraete verwenden
- Festplattenverschluesselung aktiv
- Automatische Bildschirmsperre

## 4. Physische Sicherheit

- Bildschirm nicht einsehbar positionieren
- Vertrauliche Telefonate nicht in oeffentlichen Bereichen
- Geraete nicht unbeaufsichtigt lassen

## 5. Datenschutz

- Keine Ausdrucke vertraulicher Dokumente im Homeoffice
- Familienmitglieder haben keinen Zugang zu Arbeitsgeraeten

## 6. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 23. Offboarding Policy ─────────────────────────────────────────
{
    "document_type": "offboarding_policy",
    "title": "Offboarding-Richtlinie",
    "description": "Sicherheitsrelevante Massnahmen beim Ausscheiden von Mitarbeitern.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{ACCESS_REVOKE_HOURS}}"],
    "content": """# Offboarding-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Sicherheitsrelevante Massnahmen beim Ausscheiden von Mitarbeitern bei {{COMPANY_NAME}}.

## 2. Zugriffsentzug

Alle Zugriffsrechte werden innerhalb von {{ACCESS_REVOKE_HOURS}} Stunden nach dem letzten Arbeitstag entzogen:
- Active Directory / SSO-Konten deaktivieren
- VPN-Zugang sperren
- Cloud-Dienste (E-Mail, SaaS) deaktivieren
- Physische Zutrittsrechte entziehen

## 3. Geraeterueckgabe

- Laptop, Smartphone, Tokens, Schluessel
- Datentraeger sicher loeschen oder einziehen

## 4. Wissentransfer

- Dokumentation offener Aufgaben
- Uebergabe an Nachfolger oder Vorgesetzten

## 5. Vertraulichkeit

Erinnerung an fortbestehende Vertraulichkeitspflichten.

## 6. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 24. Vendor Risk Management Policy ──────────────────────────────
{
    "document_type": "vendor_risk_management_policy",
    "title": "Lieferanten-Risikomanagement-Richtlinie",
    "description": "Bewertung und Steuerung von Risiken durch Drittanbieter und Lieferanten.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{VENDOR_REVIEW_FREQUENCY}}"],
    "content": """# Lieferanten-Risikomanagement-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Bewertung und Steuerung von Risiken durch Drittanbieter bei {{COMPANY_NAME}}.

## 2. Risikobewertung

Vor Beauftragung eines Lieferanten:
- Sicherheitsfragebogen
- Pruefung von Zertifizierungen (ISO 27001, SOC 2)
- Datenschutz-Folgenabschaetzung bei Datenverarbeitung

## 3. Vertragliche Anforderungen

- AVV gemaess Art. 28 DSGVO (bei Auftragsverarbeitung)
- SLA mit Sicherheitsanforderungen
- Recht auf Audits
- Benachrichtigungspflicht bei Sicherheitsvorfaellen

## 4. Laufende Ueberwachung

Lieferantenbewertung: {{VENDOR_REVIEW_FREQUENCY}}

## 5. Beendigung

Sichere Datenrueckgabe oder -loeschung bei Vertragsende.

## 6. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 25. Third Party Security Policy ────────────────────────────────
{
    "document_type": "third_party_security_policy",
    "title": "Drittanbieter-Sicherheitsrichtlinie",
    "description": "Sicherheitsanforderungen an Drittanbieter mit Zugang zu Systemen oder Daten.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{SECURITY_OFFICER}}"],
    "content": """# Drittanbieter-Sicherheitsrichtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Sicherheitsanforderungen an Drittanbieter mit Zugang zu Systemen oder Daten von {{COMPANY_NAME}}.

## 2. Zugangskontrollen

- Drittanbieter erhalten nur minimale, zeitlich begrenzte Zugriffsrechte
- Dedizierte Accounts (keine geteilten Zugangsdaten)
- MFA erforderlich
- VPN-Pflicht fuer Remote-Zugriffe

## 3. Ueberwachung

Alle Drittanbieter-Aktivitaeten werden protokolliert und ueberwacht.

## 4. Sicherheitsanforderungen

Drittanbieter muessen nachweisen:
- Informationssicherheits-Richtlinie vorhanden
- Mitarbeiterschulungen durchgefuehrt
- Datenschutzkonformitaet

## 5. Vorfallmeldung

Drittanbieter muessen Sicherheitsvorfaelle innerhalb von 24h an {{SECURITY_OFFICER}} melden.

## 6. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 26. Supplier Security Policy ───────────────────────────────────
{
    "document_type": "supplier_security_policy",
    "title": "Lieferanten-Sicherheitsrichtlinie",
    "description": "Mindest-Sicherheitsanforderungen in der Lieferkette gemaess NIS2.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}"],
    "content": """# Lieferanten-Sicherheitsrichtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Definition von Mindest-Sicherheitsanforderungen in der Lieferkette von {{COMPANY_NAME}} gemaess NIS2 Art. 21.

## 2. Lieferantenkategorien

| Kategorie | Risiko | Prueftiefe |
|-----------|--------|-----------|
| Kritisch (Zugang zu Kernsystemen) | Hoch | Vollstaendiges Assessment |
| Standard (SaaS-Tools) | Mittel | Fragebogen + Zertifikat |
| Gering (Buromaterial) | Niedrig | Keine IT-Pruefung |

## 3. Mindestanforderungen

- Verschluesselung fuer Datenaustausch
- Patch-Management-Prozess
- Incident-Response-Faehigkeit
- Vertraulichkeitsvereinbarungen

## 4. Supply-Chain-Risiken

Software-Lieferkette: SBOM (Software Bill of Materials) bei kritischen Lieferanten einfordern.

## 5. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 27. Business Continuity Policy ─────────────────────────────────
{
    "document_type": "business_continuity_policy",
    "title": "Business-Continuity-Richtlinie",
    "description": "Sicherstellung der Geschaeftskontinuitaet. BIA, Notfallplaene, Tests.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{BCM_RESPONSIBLE}}", "{{BIA_REVIEW_FREQUENCY}}"],
    "content": """# Business-Continuity-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |
| BCM-Verantwortlich | {{BCM_RESPONSIBLE}} |

## 1. Zweck

Sicherstellung der Geschaeftskontinuitaet bei {{COMPANY_NAME}} in Krisensituationen.

## 2. Business Impact Analyse (BIA)

Kritische Geschaeftsprozesse werden identifiziert und priorisiert. BIA-Review: {{BIA_REVIEW_FREQUENCY}}.

## 3. Notfallplaene

Fuer jeden kritischen Prozess existiert ein dokumentierter Notfallplan mit:
- Ausloesekriterien
- Verantwortlichkeiten
- Wiederherstellungsschritte
- Kommunikationsplan

## 4. Tests

Notfalluebungen werden jaehrlich durchgefuehrt. Ergebnisse werden dokumentiert und Plaene entsprechend angepasst.

## 5. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 28. Disaster Recovery Policy ───────────────────────────────────
{
    "document_type": "disaster_recovery_policy",
    "title": "Disaster-Recovery-Richtlinie",
    "description": "Wiederherstellung von IT-Systemen nach Katastrophen. RTO, RPO, Failover.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{RTO_HOURS}}", "{{RPO_HOURS}}", "{{DR_SITE}}"],
    "content": """# Disaster-Recovery-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Wiederherstellung von IT-Systemen nach Katastrophen bei {{COMPANY_NAME}}.

## 2. Wiederherstellungsziele

| Klasse | RTO | RPO |
|--------|-----|-----|
| Kritisch | {{RTO_HOURS}}h | {{RPO_HOURS}}h |
| Wichtig | 24h | 8h |
| Standard | 72h | 24h |

## 3. DR-Standort

{{DR_SITE}}

## 4. Failover-Verfahren

- Automatisches Failover fuer kritische Systeme
- Dokumentierte manuelle Failover-Prozeduren
- Regelmaessige Failover-Tests

## 5. Kommunikation

Eskalationsmatrix und Kommunikationsplan fuer den Katastrophenfall.

## 6. Tests

DR-Tests werden halbjaehrlich durchgefuehrt.

## 7. Pruefzyklus

Jaehrliche Ueberpruefung.
""",
},

# ── 29. Crisis Management Policy ───────────────────────────────────
{
    "document_type": "crisis_management_policy",
    "title": "Krisenmanagement-Richtlinie",
    "description": "Fuehrung und Kommunikation in Krisensituationen. Krisenstab, Eskalation, Kommunikation.",
    "placeholders": ["{{COMPANY_NAME}}", "{{VERSION}}", "{{DATE}}", "{{CRISIS_TEAM}}", "{{CRISIS_HOTLINE}}"],
    "content": """# Krisenmanagement-Richtlinie

| Feld | Wert |
|------|------|
| Unternehmen | {{COMPANY_NAME}} |
| Version | {{VERSION}} |
| Datum | {{DATE}} |

## 1. Zweck

Regelung der Fuehrung und Kommunikation in Krisensituationen bei {{COMPANY_NAME}}.

## 2. Krisendefinition

Eine Krise ist ein Ereignis, das den Geschaeftsbetrieb, die Reputation oder die Sicherheit wesentlich gefaehrdet und ueber die Handlungsmoeglichkeiten des Normalbetriebs hinausgeht.

## 3. Krisenstab

Mitglieder: {{CRISIS_TEAM}}

Erreichbar ueber: {{CRISIS_HOTLINE}}

## 4. Eskalationsstufen

| Stufe | Beschreibung | Aktivierung |
|-------|-------------|-------------|
| 1 — Alarmierung | Potentielle Krise erkannt | IT-Leitung informiert |
| 2 — Mobilisierung | Krise bestaetigt | Krisenstab einberufen |
| 3 — Vollbetrieb | Schwere Krise | Geschaeftsfuehrung leitet |

## 5. Kommunikation

- Interne Kommunikation: Nur ueber offizielle Kanaele
- Externe Kommunikation: Ausschliesslich durch autorisierte Sprecher
- Social Media: Abstimmung mit Kommunikationsabteilung

## 6. Nachbereitung

Nach jeder Krise: Lessons-Learned-Workshop innerhalb von 14 Tagen.

## 7. Pruefzyklus

Jaehrliche Ueberpruefung. Zusaetzlich nach jeder Krise.
""",
},
]


def main():
    ok, fail = 0, 0
    for t in TEMPLATES:
        payload = {**BASE, **t}
        try:
            resp = requests.post(API, json=payload, headers=HEADERS, timeout=15)
            if resp.status_code == 201:
                print(f"  OK: {t['document_type']} — {t['title']}")
                ok += 1
            else:
                print(f"  FAIL ({resp.status_code}): {t['document_type']} — {resp.text[:150]}")
                fail += 1
        except Exception as e:
            print(f"  ERROR: {t['document_type']} — {e}")
            fail += 1
    print(f"\nDone: {ok} OK, {fail} failed (of {len(TEMPLATES)} total)")


if __name__ == "__main__":
    main()