Basis: Certvia dev@a48c5fb als Fundament für Craftvia

Unveränderter Stand von certvia/dev (a48c5fb) plus Craftvia-Spezifikation
und Brandbook unter docs/craftvia/. ISMS-Module werden im Folgecommit entfernt.

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

docs/wizard-uebergabe/02_Fachcontent_C1-C9/C0_README-Fachcontent-Uebersicht.md

@@ -0,0 +1,35 @@
+# Fachcontent-Zulieferung C1–C9 — Übersicht
+
+Fachliche Zulieferung (SME/Berater) für den Onboarding-Wizard, gemäß `BeraterAnweisungFachcontent.md` und `WizardEntwicklerBacklog.md`. Alle Pakete sind ID-konsistent zum bestehenden Vorlagenpaket `isms-vorlagenpaket-v2` (`mapping.json`, `variables.schema.json`, Baseline `BL-*`). Prüfziele: Informationssicherheit (Paketbasis), Prototypenschutz (8.x) und Datenschutz (9.x) als Erweiterung.
+
+## Lieferpakete
+
+| WP | Datei | Schaltet frei (Backlog) | Inhalt |
+|---|---|---|---|
+| **C1** | `C1_Scoping-AL-Pruefziel.md` | A2 | AL2/AL3-Kennzeichnung + Prüfziel + Scope-Bedingung je Anforderung — **412 Anforderungen** (316 IS + 72 Proto + 24 DS) |
+| **C2** | `C2_Fragenkatalog-Wirkung.md` | B2, B3 | Fragenkatalog (A–F) + Antwort→Wirkung (Variable/Flag/Control/Risiko/Aufgabe), gekoppelt an `variables.schema.json` |
+| **C3** | `C3_Vorlagen-Annotation.md` | B4 | Annotationskonvention (REQ/IMPL-Anker, `{{#if FLAG}}`, Baseline-Variablen), Ist-Bestätigung (`_verify.py → OK`), Erweiterung P01/D01 |
+| **C4** | `C4_Risikokatalog.md` | A6 | Standard-/VDA-Risiko-Katalog (**39 Risiken, 11 Kategorien**) mit Controls, Assets, Standardmaßnahmen, Default-5×5-Einschätzung |
+| **C5** | `C5_Reifegradlogik.md` | A7 | Generische Beleg→Reifegrad-Regel + control-spezifische Tabelle (alle 45 IS-Controls + Proto/DS-Gruppen), Zielreifegrad, Offene-Punkt-Kriterium |
+| **C6** | `C6_Umsetzungshinweise.md` | B5, A7 | Umsetzungshinweise je Teilanforderung (**~397 Blöcke über 79 Controls**): org/tech, Nachweise, Vorlage, Ressourcen, AL-Filter |
+| **C7** | `C7_Rollen-Funktionstrennung.md` | A4 | Soll-Rollenmodell, Funktionstrennungs-Regeln (FT-01…06), ISB-Bestellungs-Vorlage im Paket-Stil |
+| **C8** | `C8_Priorisierung-Gap.md` | A8 | Prioritätsregeln (Hoch/Mittel/Niedrig), Dedup-Kriterien, Quick-Win-Definition |
+| **C9** | `C9_Auswertung-Export.md` | B7 | Reifegrad-Interpretationstexte, nächste Schritte, VDA-ISA-Export-Layout (bestätigt/unbestätigt) |
+
+## Konsistenz-Anker
+
+- **Anforderungs-IDs** = `mapping.json`-IDs (z. B. `4.1.2-H1`); Proto/DS neu im gleichen Schema (`8.1.1-M1`, `9.1.1-M1`).
+- **Flags/Variablen** = `variables.schema.json` (Single Source of Truth). Neue Flags (`FLAG_PROTOTYPE_PROTECTION`, `FLAG_ISB_EXTERNAL/INTERNAL`) sind in C3/C7 vermerkt und dort zuerst zu ergänzen.
+- **Technische Werte** = Baseline `BL-*` (C6 referenziert, nie hart kodiert).
+- **Vorlagenpaket** unverändert; `python3 seed/isms-vorlagenpaket-v2/_verify.py` → **OK**.
+
+## Offene Punkte / Abhängigkeiten für die Umsetzung
+
+1. **Proto/DS-Vorlagen** (`P01`, `D01`) und zugehörige `mapping.json`-Einträge sind noch anzulegen (C3 Abschnitt 3) — die Anforderungsdekomposition + Hinweise (C1/C5/C6) liegen bereits vor.
+2. **Neue `FLAG_*`** vor Nutzung in `variables.schema.json` ergänzen, damit `_verify.py` sie kennt.
+3. **Baseline-IDs in C6**: Agenten haben teils sprechende `BL-*`-Codes ergänzt, die über den dokumentierten Satz (BL-IAM/CRY/OPS/NET/EP/PHY/HR/SUP/DEL/GOV/PROJ) hinausgehen — vor Verdrahtung gegen `Technische-Sicherheits-Baseline.md` normalisieren.
+4. **ISB-Freigabe** der neuen/angepassten Fachtexte ist der abschließende fachliche Schritt (steht im Backlog offen auf `dev`).
+
+## Reihenfolge (kritischer Pfad)
+
+C2 → C1/C3 (schalten B2/B3 und A2/B4 frei) → C4/C5/C6 (A6/A7/B5) → C7/C8/C9. Entspricht der Meilenstein-Sequenz M0–M6 des Backlogs.

docs/wizard-uebergabe/02_Fachcontent_C1-C9/C1_Scoping-AL-Pruefziel.md

@@ -0,0 +1,444 @@
+# C1 — Scoping-Grundlage: AL2/AL3-Kennzeichnung + Prüfziel-Zuordnung je Anforderung
+
+> **Schaltet frei:** A2 (Scoping / Admin-AL / Scope-Filter). **Grundlage:** `mapping.json` (Informationssicherheit, 316 Anforderungen) + Prototypenschutz/Datenschutz-Dekomposition (Erweiterung).
+
+## Methodik (Zuordnungslogik)
+
+Der Assessment-Level (AL) wird **zentral im Adminportal** gesetzt (Backlog A2) und ist read-only im Scoping. Die Zuordnung folgt der VDA-ISA-/TISAX-Systematik:
+
+- **MUSS / SOLL** → Bestandteil von **AL2 und AL3** (Grundabsicherung; SOLL über `FLAG_INCLUDE_SHOULD` für Ziel-Reifegrad 3).
+- **HOCH** (Zusatz hoher Schutzbedarf) → relevant bei **hohem Schutzbedarf** (typisch AL3), Flag `FLAG_HIGH_PROTECTION`.
+- **SEHR HOCH** (Zusatz sehr hoher Schutzbedarf) → relevant bei **sehr hohem Schutzbedarf** (AL3), Flag `FLAG_VERY_HIGH_PROTECTION`.
+- **Prüfziel** steuert, ob ein ganzes Kapitel überhaupt im Scope ist (Informationssicherheit / Prototypenschutz / Datenschutz).
+- **Scope-Bedingung** = das Feature-Flag bzw. die Bedingung aus `mapping.json` (`condition`); ist keine gesetzt, gilt „immer im Scope" (sobald das Prüfziel aktiv ist).
+
+Der Scope-Filter (A2) blendet je nach AL + Flags + Prüfziel die nicht relevanten Anforderungen aus. Spalte „Scope-Bedingung" ist maschinenlesbar an die `FLAG_*` aus `variables.schema.json` gekoppelt.
+
+## Prüfziel Informationssicherheit (316 Anforderungen)
+
+| Control | Anforderungs-ID | Typ | AL2 | AL3 | Prüfziel | Scope-Bedingung (Flag) |
+|---|---|---|:--:|:--:|---|---|
+| 1.1.1 | 1.1.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.1.1 | 1.1.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.1.1 | 1.1.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.1.1 | 1.1.1-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.1.1 | 1.1.1-M5 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.1.1 | 1.1.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.1.1 | 1.1.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.1.1 | 1.1.1-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.1.1 | 1.1.1-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.2.1 | 1.2.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.2.1 | 1.2.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.2.1 | 1.2.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.2.1 | 1.2.1-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.2.1 | 1.2.1-M5 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.2.1 | 1.2.1-M6 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.2.2 | 1.2.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.2.2 | 1.2.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.2.2 | 1.2.2-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.2.2 | 1.2.2-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.2.2 | 1.2.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.2.2 | 1.2.2-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.2.2 | 1.2.2-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 1.2.3 | 1.2.3-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.2.3 | 1.2.3-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.2.3 | 1.2.3-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.2.3 | 1.2.3-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.2.3 | 1.2.3-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 1.3.1 | 1.3.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.3.1 | 1.3.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.3.1 | 1.3.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.3.2 | 1.3.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.3.2 | 1.3.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.3.2 | 1.3.2-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.3.2 | 1.3.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.3.3 | 1.3.3-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.3.3 | 1.3.3-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.3.3 | 1.3.3-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.3.3 | 1.3.3-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.3.3 | 1.3.3-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.3.3 | 1.3.3-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.3.4 | 1.3.4-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.3.4 | 1.3.4-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.3.4 | 1.3.4-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.3.4 | 1.3.4-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.3.4 | 1.3.4-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.3.4 | 1.3.4-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.3.4 | 1.3.4-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.3.4 | 1.3.4-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 1.4.1 | 1.4.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.4.1 | 1.4.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.4.1 | 1.4.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.4.1 | 1.4.1-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.4.1 | 1.4.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.4.1 | 1.4.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.4.1 | 1.4.1-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.4.1 | 1.4.1-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.5.1 | 1.5.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.5.1 | 1.5.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.5.1 | 1.5.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.5.1 | 1.5.1-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.5.1 | 1.5.1-M5 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.5.1 | 1.5.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.5.2 | 1.5.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.5.2 | 1.5.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.5.2 | 1.5.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.6.1 | 1.6.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.6.1 | 1.6.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.6.1 | 1.6.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.6.1 | 1.6.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.6.1 | 1.6.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.6.1 | 1.6.1-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.6.1 | 1.6.1-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.6.1 | 1.6.1-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.6.1 | 1.6.1-S6 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.6.1 | 1.6.1-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 1.6.2 | 1.6.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.6.2 | 1.6.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.6.2 | 1.6.2-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.6.2 | 1.6.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.6.2 | 1.6.2-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.6.2 | 1.6.2-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.6.2 | 1.6.2-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 1.6.2 | 1.6.2-H2 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 1.6.2 | 1.6.2-H3 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 1.6.2 | 1.6.2-H4 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 1.6.2 | 1.6.2-H5 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 1.6.2 | 1.6.2-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 1.6.3 | 1.6.3-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.6.3 | 1.6.3-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.6.3 | 1.6.3-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 1.6.3 | 1.6.3-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.6.3 | 1.6.3-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.6.3 | 1.6.3-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.6.3 | 1.6.3-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.6.3 | 1.6.3-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.6.3 | 1.6.3-S6 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 1.6.3 | 1.6.3-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 1.6.3 | 1.6.3-H2 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 1.6.3 | 1.6.3-H3 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 1.6.3 | 1.6.3-H4 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 1.6.3 | 1.6.3-H5 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 1.6.3 | 1.6.3-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 2.1.1 | 2.1.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 2.1.1 | 2.1.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 2.1.1 | 2.1.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 2.1.1 | 2.1.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 2.1.1 | 2.1.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 2.1.2 | 2.1.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 2.1.2 | 2.1.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 2.1.2 | 2.1.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 2.1.2 | 2.1.2-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 2.1.2 | 2.1.2-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 2.1.3 | 2.1.3-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 2.1.3 | 2.1.3-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 2.1.3 | 2.1.3-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 2.1.3 | 2.1.3-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 2.1.3 | 2.1.3-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 2.1.3 | 2.1.3-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 2.1.3 | 2.1.3-S6 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 2.1.4 | 2.1.4-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 2.1.4 | 2.1.4-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 2.1.4 | 2.1.4-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 2.1.4 | 2.1.4-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 3.1.1 | 3.1.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 3.1.1 | 3.1.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 3.1.1 | 3.1.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 3.1.1 | 3.1.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 3.1.1 | 3.1.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 3.1.1 | 3.1.1-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 3.1.1 | 3.1.1-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 3.1.1 | 3.1.1-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 3.1.1 | 3.1.1-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 3.1.4 | 3.1.4-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 3.1.4 | 3.1.4-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 3.1.4 | 3.1.4-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 4.1.1 | 4.1.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 4.1.1 | 4.1.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.1.1 | 4.1.1-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 4.1.2 | 4.1.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 4.1.2 | 4.1.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 4.1.2 | 4.1.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.1.2 | 4.1.2-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.1.2 | 4.1.2-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.1.2 | 4.1.2-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 4.1.2 | 4.1.2-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 4.1.3 | 4.1.3-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 4.1.3 | 4.1.3-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 4.1.3 | 4.1.3-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 4.1.3 | 4.1.3-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 4.1.3 | 4.1.3-M5 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 4.1.3 | 4.1.3-M6 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 4.1.3 | 4.1.3-M7 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 4.1.3 | 4.1.3-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.1.3 | 4.1.3-S10 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.1.3 | 4.1.3-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.1.3 | 4.1.3-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.1.3 | 4.1.3-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.1.3 | 4.1.3-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.1.3 | 4.1.3-S6 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.1.3 | 4.1.3-S7 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.1.3 | 4.1.3-S8 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.1.3 | 4.1.3-S9 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.2.1 | 4.2.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 4.2.1 | 4.2.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 4.2.1 | 4.2.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.2.1 | 4.2.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.2.1 | 4.2.1-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.2.1 | 4.2.1-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.2.1 | 4.2.1-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 4.2.1 | 4.2.1-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 4.2.1 | 4.2.1-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 4.2.1 | 4.2.1-V2 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 5.1.1 | 5.1.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.1.1 | 5.1.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.1.1 | 5.1.1-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 5.1.2 | 5.1.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.1.2 | 5.1.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.1.2 | 5.1.2-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.1.2 | 5.1.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.1.2 | 5.1.2-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.1.2 | 5.1.2-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.1.2 | 5.1.2-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 5.1.2 | 5.1.2-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 5.2.1 | 5.2.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.1 | 5.2.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.1 | 5.2.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.1 | 5.2.1-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.1 | 5.2.1-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.1 | 5.2.1-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 5.2.2 | 5.2.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.2 | 5.2.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.2 | 5.2.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.3 | 5.2.3-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.3 | 5.2.3-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.3 | 5.2.3-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.3 | 5.2.3-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.3 | 5.2.3-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.3 | 5.2.3-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.3 | 5.2.3-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.3 | 5.2.3-S6 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.3 | 5.2.3-S7 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.3 | 5.2.3-S8 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.4 | 5.2.4-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.4 | 5.2.4-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.4 | 5.2.4-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.4 | 5.2.4-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.4 | 5.2.4-M5 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.4 | 5.2.4-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.4 | 5.2.4-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.4 | 5.2.4-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.4 | 5.2.4-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 5.2.4 | 5.2.4-H2 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 5.2.4 | 5.2.4-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 5.2.5 | 5.2.5-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.5 | 5.2.5-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.5 | 5.2.5-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.5 | 5.2.5-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.5 | 5.2.5-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.5 | 5.2.5-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.6 | 5.2.6-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.6 | 5.2.6-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.6 | 5.2.6-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.6 | 5.2.6-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.6 | 5.2.6-M5 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.6 | 5.2.6-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.6 | 5.2.6-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.6 | 5.2.6-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.6 | 5.2.6-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 5.2.6 | 5.2.6-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 5.2.7 | 5.2.7-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.7 | 5.2.7-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.7 | 5.2.7-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.7 | 5.2.7-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.7 | 5.2.7-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 5.2.8 | 5.2.8-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.8 | 5.2.8-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.8 | 5.2.8-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.8 | 5.2.8-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.8 | 5.2.8-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.8 | 5.2.8-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 5.2.8 | 5.2.8-H2 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 5.2.8 | 5.2.8-H3 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 5.2.8 | 5.2.8-H4 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 5.2.8 | 5.2.8-H5 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 5.2.8 | 5.2.8-H6 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 5.2.8 | 5.2.8-H7 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 5.2.8 | 5.2.8-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 5.2.8 | 5.2.8-V2 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 5.2.8 | 5.2.8-V3 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 5.2.9 | 5.2.9-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.9 | 5.2.9-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.2.9 | 5.2.9-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.2.9 | 5.2.9-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 5.2.9 | 5.2.9-H2 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 5.2.9 | 5.2.9-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 5.2.9 | 5.2.9-V2 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 5.2.9 | 5.2.9-V3 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 5.3.1 | 5.3.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.3.1 | 5.3.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.3.1 | 5.3.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.3.1 | 5.3.1-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.3.1 | 5.3.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.3.1 | 5.3.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.3.1 | 5.3.1-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.3.1 | 5.3.1-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.3.1 | 5.3.1-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.3.1 | 5.3.1-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 5.3.2 | 5.3.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.3.2 | 5.3.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.3.2 | 5.3.2-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.3.2 | 5.3.2-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.3.2 | 5.3.2-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 5.3.3 | 5.3.3-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.3.4 | 5.3.4-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.3.4 | 5.3.4-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 5.3.4-KI | 5.3.4-KI-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.3.4-KI | 5.3.4-KI-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.3.4-KI | 5.3.4-KI-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 5.3.4-KI | 5.3.4-KI-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 6.1.1 | 6.1.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 6.1.1 | 6.1.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 6.1.1 | 6.1.1-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 6.1.1 | 6.1.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 6.1.1 | 6.1.1-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 6.1.1 | 6.1.1-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 6.1.1 | 6.1.1-H2 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 6.1.1 | 6.1.1-H3 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 6.1.1 | 6.1.1-V1 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 6.1.1 | 6.1.1-V2 | SEHR HOCH | – | Ja | Informationssicherheit | `FLAG_VERY_HIGH_PROTECTION` |
+| 6.1.2 | 6.1.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 6.1.2 | 6.1.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 6.1.2 | 6.1.2-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 6.1.2 | 6.1.2-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 6.1.2 | 6.1.2-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 6.1.2 | 6.1.2-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 6.1.2 | 6.1.2-S3 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 6.1.2 | 6.1.2-S4 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 6.1.2 | 6.1.2-S5 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 6.1.3 | 6.1.3-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 6.1.3 | 6.1.3-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 6.1.3 | 6.1.3-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 6.1.3 | 6.1.3-M4 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 6.1.3 | 6.1.3-M5 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 6.1.3 | 6.1.3-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 6.1.3 | 6.1.3-S2 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 6.1.3 | 6.1.3-H1 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 6.1.3 | 6.1.3-H2 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 6.1.3 | 6.1.3-H3 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 6.1.3 | 6.1.3-H4 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 6.1.3 | 6.1.3-H5 | HOCH | – | Ja | Informationssicherheit | `FLAG_HIGH_PROTECTION` |
+| 7.1.1 | 7.1.1-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 7.1.1 | 7.1.1-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 7.1.1 | 7.1.1-S1 | SOLL | Ja | Ja | Informationssicherheit | `FLAG_INCLUDE_SHOULD` |
+| 7.1.2 | 7.1.2-M1 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 7.1.2 | 7.1.2-M2 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+| 7.1.2 | 7.1.2-M3 | MUSS | Ja | Ja | Informationssicherheit | immer im Scope |
+
+## Prüfziel Prototypenschutz (72 Anforderungen) — Erweiterung
+
+| Control | Anforderungs-ID | Typ | AL2 | AL3 | Prüfziel | Scope-Bedingung (Flag) |
+|---|---|---|:--:|:--:|---|---|
+| 8.1.1 | 8.1.1-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.1.1 | 8.1.1-S1 | SOLL | Ja | Ja | Prototypenschutz | `FLAG_INCLUDE_SHOULD` |
+| 8.1.2 | 8.1.2-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.1.2 | 8.1.2-S1 | SOLL | Ja | Ja | Prototypenschutz | `FLAG_INCLUDE_SHOULD` |
+| 8.1.3 | 8.1.3-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.1.3 | 8.1.3-S1 | SOLL | Ja | Ja | Prototypenschutz | `FLAG_INCLUDE_SHOULD` |
+| 8.1.3 | 8.1.3-S2 | SOLL | Ja | Ja | Prototypenschutz | `FLAG_INCLUDE_SHOULD` |
+| 8.1.4 | 8.1.4-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.1.4 | 8.1.4-S1 | SOLL | Ja | Ja | Prototypenschutz | `FLAG_INCLUDE_SHOULD` |
+| 8.1.4 | 8.1.4-S2 | SOLL | Ja | Ja | Prototypenschutz | `FLAG_INCLUDE_SHOULD` |
+| 8.1.4 | 8.1.4-H1 | HOCH | – | Ja | Prototypenschutz | `FLAG_HIGH_PROTECTION` |
+| 8.1.5 | 8.1.5-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.1.5 | 8.1.5-H1 | HOCH | – | Ja | Prototypenschutz | `FLAG_HIGH_PROTECTION` |
+| 8.1.6 | 8.1.6-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.1.6 | 8.1.6-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.1.6 | 8.1.6-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.1.7 | 8.1.7-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.1.7 | 8.1.7-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.1.7 | 8.1.7-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.1.7 | 8.1.7-M4 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.1.8 | 8.1.8-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.1.8 | 8.1.8-H1 | HOCH | – | Ja | Prototypenschutz | `FLAG_HIGH_PROTECTION` |
+| 8.2.1 | 8.2.1-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.1 | 8.2.1-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.1 | 8.2.1-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.1 | 8.2.1-M4 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.2 | 8.2.2-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.2 | 8.2.2-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.2 | 8.2.2-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.2 | 8.2.2-M4 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.2 | 8.2.2-M5 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.2 | 8.2.2-M6 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.3 | 8.2.3-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.3 | 8.2.3-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.3 | 8.2.3-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.3 | 8.2.3-M4 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.3 | 8.2.3-M5 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.3 | 8.2.3-M6 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.3 | 8.2.3-M7 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.4 | 8.2.4-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.4 | 8.2.4-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.4 | 8.2.4-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.5 | 8.2.5-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.5 | 8.2.5-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.5 | 8.2.5-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.6 | 8.2.6-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.6 | 8.2.6-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.6 | 8.2.6-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.6 | 8.2.6-M4 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.6 | 8.2.6-M5 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.7 | 8.2.7-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.2.7 | 8.2.7-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.3.1 | 8.3.1-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.3.1 | 8.3.1-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.3.1 | 8.3.1-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.3.1 | 8.3.1-M4 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.3.2 | 8.3.2-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.4.1 | 8.4.1-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.4.1 | 8.4.1-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.4.1 | 8.4.1-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.4.2 | 8.4.2-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.4.2 | 8.4.2-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.4.3 | 8.4.3-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.4.3 | 8.4.3-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.4.3 | 8.4.3-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.5.1 | 8.5.1-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.5.1 | 8.5.1-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.5.1 | 8.5.1-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.5.2 | 8.5.2-M1 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.5.2 | 8.5.2-M2 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.5.2 | 8.5.2-M3 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+| 8.5.2 | 8.5.2-M4 | MUSS | Ja | Ja | Prototypenschutz | Prüfziel Prototypenschutz aktiv |
+
+> Hinweis Scope Prototypenschutz: Prüfziel bezieht sich in der aktuellen Konfiguration auf **Prototypenteile/-komponenten**; Controls 8.4.x (Test-/Erprobung) und 8.5.x (Ausstellungen/Film) sind per Scope-Regel `n.a.` und werden ausgeblendet.
+
+## Prüfziel Datenschutz (24 Anforderungen) — Erweiterung
+
+| Control | Anforderungs-ID | Typ | AL2 | AL3 | Prüfziel | Scope-Bedingung (Flag) |
+|---|---|---|:--:|:--:|---|---|
+| 9.1.1 | 9.1.1-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.2.1 | 9.2.1-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.2.1 | 9.2.1-M2 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.2.1 | 9.2.1-M3 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.2.1 | 9.2.1-M4 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.2.1 | 9.2.1-M5 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.2.1 | 9.2.1-M6 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.3.1 | 9.3.1-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.4.1 | 9.4.1-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.4.1 | 9.4.1-M2 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.5.1 | 9.5.1-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.5.2 | 9.5.2-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.5.2 | 9.5.2-M2 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.5.3 | 9.5.3-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.5.3 | 9.5.3-M2 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.5.3 | 9.5.3-M3 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.6.1 | 9.6.1-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.6.2 | 9.6.2-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.6.2 | 9.6.2-M2 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.6.2 | 9.6.2-M3 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.7.1 | 9.7.1-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.7.2 | 9.7.2-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.8.1 | 9.8.1-M1 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |
+| 9.8.1 | 9.8.1-M2 | MUSS | Ja | Ja | Datenschutz | Prüfziel Datenschutz aktiv (`FLAG_PERSONAL_DATA`) |

docs/wizard-uebergabe/02_Fachcontent_C1-C9/C2_Fragenkatalog-Wirkung.md

@@ -0,0 +1,110 @@
+# C2 — Fragenkatalog + Antwort→Wirkung-Mapping
+
+> **Schaltet frei:** B2 (Regel-/Mapping-Engine) und B3 (Fragebogen, Schritt 2). **Kritischer Pfad.**
+> **Grundlage:** `variables.schema.json` (Single Source of Truth der Wizard-Variablen und `FLAG_*`), `mapping.json` (`condition`-Flags je Anforderung), `Technische-Sicherheits-Baseline.md` (`BL-*`-Parameter).
+
+## 1. Prinzip
+
+Jede Frage erzeugt eine **Wirkung** auf genau vier Kanäle (DSL-Vertrag aus dem Backlog, Foundation #3):
+
+1. **Variable/Platzhalter** — füllt einen `{{NAME}}`-Wert (z. B. `ORG_NAME`, `MFA_SCOPE`).
+2. **Feature-Flag** — setzt ein `FLAG_*` true/false, das `{{#if FLAG_X}}`-Blöcke in Vorlagen und die Control-Relevanz steuert.
+3. **Control/Risiko-Bezug** — schaltet Controls in den Scope und schlägt Katalog-Risiken (C4) vor.
+4. **Aufgabe** — erzeugt bei bestimmten Antworten einen Aufgabenvorschlag (Aufgaben-Modul).
+
+Antworttypen: `text`, `single-select`, `multi-select`, `boolean`, `number/duration`. Baseline-Parameter (Abschnitt E) sind **vorbelegte Defaults** aus der Baseline; die Frage dient nur der Bestätigung/Anpassung, nicht der Ersteingabe.
+
+Anzeige-Bedingungen referenzieren zuvor gesetzte Flags (bedingter Fragebogen).
+
+---
+
+## 2. Abschnitt A — Organisation & Geltungsbereich
+
+| Frage-ID | Frage | Antworttyp | Anzeige-Bedingung | Wirkung |
+|---|---|---|---|---|
+| Q-ORG-01 | Vollständiger Name der Organisation? | text | immer | Variable `ORG_NAME` |
+| Q-ORG-02 | Kurzname/Abkürzung? | text | immer | Variable `ORG_SHORT` |
+| Q-ORG-03 | Geltungsbereich – Kurzlabel? | text | immer | Variable `ISMS_SCOPE` |
+| Q-ORG-04 | Geltungsbereich – Beschreibung (Standorte, Bereiche, Systeme, Ausschlüsse)? | text (lang) | immer | Variable `ISMS_SCOPE_DESCRIPTION`; speist Scope-Objekt (Schritt 1) |
+| Q-ORG-05 | Verarbeitet die Organisation personenbezogene Daten? | boolean | immer | Flag `FLAG_PERSONAL_DATA`; schaltet Prüfziel Datenschutz (9.x) + Controls 7.1.2 · Risiken R-DSGVO-* |
+| Q-ORG-06 | Werden Prototypen/schutzbedürftige Entwicklungsobjekte verarbeitet? | boolean | immer | schaltet Prüfziel Prototypenschutz (8.x); bei „nein" 8.x ausgeblendet |
+
+## 3. Abschnitt B — Rollen (→ Schritt 3, Paket C7)
+
+| Frage-ID | Frage | Antworttyp | Anzeige-Bedingung | Wirkung |
+|---|---|---|---|---|
+| Q-ROLE-01 | Oberste Leitung (Name/Funktion)? | text | immer | Variable `ROLE_MANAGEMENT` |
+| Q-ROLE-02 | Informationssicherheitsbeauftragte(r)/CISO? intern/extern? | text + single-select | immer | Variable `ROLE_ISB`; Funktionstrennungsprüfung (C7); bei fehlend → Aufgabe „ISB bestellen" |
+| Q-ROLE-03 | IT-Leitung / IT-Verantwortung (intern/extern)? | text | immer | Variable `ROLE_IT_LEAD`; Input Funktionstrennung ISB≠IT (C7) |
+| Q-ROLE-04 | Personalleitung? | text | immer | Variable `ROLE_HR_LEAD` |
+| Q-ROLE-05 | Datenschutzbeauftragte(r)? | text | `FLAG_PERSONAL_DATA` | Variable `ROLE_DPO` |
+
+## 4. Abschnitt C — Governance & Betriebsrahmen
+
+| Frage-ID | Frage | Antworttyp | Anzeige-Bedingung | Wirkung |
+|---|---|---|---|---|
+| Q-GOV-01 | Name des eingesetzten ISMS-Tools? | text | immer | Variable `TOOL_NAME` |
+| Q-GOV-02 | Ticket-/Workflow-System (Dokumentationsort)? | text | immer | Variable `TOOL_TICKET` (BL-IAM-07, BL-OPS-02/09) |
+| Q-GOV-03 | Verzeichnis-/IAM-System? | text | immer | Variable `TOOL_IAM` (BL-IAM-06/07) |
+| Q-GOV-04 | Revisions-/Prüfzyklus? | single-select (jährlich/…) | immer | Variable `REVIEW_CYCLE` (BL-HR-01, BL-GOV-01) |
+| Q-GOV-05 | Ziel-Reifegrad – SOLL-Anforderungen einbeziehen? | boolean (Default ja) | immer | Flag `FLAG_INCLUDE_SHOULD`; blendet alle `[SOLL]`-Blöcke ein/aus |
+
+## 5. Abschnitt D — Feature-Fragen (steuern `FLAG_*`, Klauseln, Controls, Risiken)
+
+Diese Fragen sind der Kern der Regel-Engine: jede Antwort blendet Vorlagenklauseln ein/aus, schaltet Controls in den Scope und schlägt Risiken vor.
+
+| Frage-ID | Frage | Antworttyp | Anzeige-Bedingung | Wirkung (Flag · Klausel/Control · Risiko/Aufgabe) |
+|---|---|---|---|---|
+| Q-FEAT-01 | Schutzbedarf im Scope – höchste Stufe? (normal / hoch / sehr hoch) | single-select | immer | `FLAG_HIGH_PROTECTION` (hoch|sehr hoch), `FLAG_VERY_HIGH_PROTECTION` (sehr hoch), abgeleitet `FLAG_ELEVATED_PROTECTION`; blendet `[HOCH]`/`[SEHR HOCH]`-Anforderungen + `-elev`-Umsetzungstexte ein |
+| Q-FEAT-02 | Werden Cloud-Dienste genutzt? | boolean | immer | `FLAG_CLOUD_USED`; R12-Klauseln + Controls 5.3.2/5.3.4/6.1.3; Risiken R-CLOUD-* |
+| Q-FEAT-03 | Werden KI-/GenAI-Dienste genutzt? | boolean | immer | `FLAG_AI_USED`; R12-KI-Klauseln + Control 5.3.4-KI · VA-11; Risiko R-AI-* |
+| Q-FEAT-04 | Produktions-/OT-Umgebung vorhanden? | boolean | immer | `FLAG_OT_USED`; BL-NET-01 OT-Segmentierung; Risiken R-OT-* |
+| Q-FEAT-05 | Eigene Software-Entwicklung? | boolean | immer | `FLAG_DEV_INHOUSE`; R11-Klauseln + Controls 5.3.1 · VA-16; Risiko R-DEV-* |
+| Q-FEAT-06 | Mobiles Arbeiten / Homeoffice zugelassen? | boolean | immer | `FLAG_MOBILE_WORK`; R06-Klauseln + Control 2.1.4 |
+| Q-FEAT-07 | Mobile Endgeräte / Datenträger im Einsatz? | boolean | immer | `FLAG_MOBILE_DEVICES`; R06/BL-EP-*; Control 3.1.4; Risiko R-PHY-mobile |
+| Q-FEAT-08 | Eigene PKI / Zertifikatsverwaltung? | boolean | immer | `FLAG_CRYPTO_PKI`; BL-CRY-05 PKI-Klausel; Control 5.1.1 |
+| Q-FEAT-09 | Externe IT-Dienstleister genutzt? | boolean | immer | `FLAG_EXTERNAL_IT`; R13-Klauseln + Controls 6.1.1/6.1.3 · VA-10; Risiko R-SUP-*; bei „ja" → Aufgabe „Dienstleister-Selbstauskunft einholen" |
+| Q-FEAT-10 | Zugriff auf Kundensysteme (z. B. OEM)? | boolean | immer | `FLAG_CUSTOMER_SYSTEMS`; Klauseln „Konten in Kundensystemen" in R08/R13 (Controls 4.1.3/4.2.1/6.1.x) |
+
+## 6. Abschnitt E — Technische Baseline (Defaults bestätigen/anpassen)
+
+Vorbelegt aus `Technische-Sicherheits-Baseline.md`. Je Frage wird der Default angezeigt; Änderung schreibt die zugehörige Variable. Anzeige gruppiert; nur relevante bei gesetztem Flag.
+
+| Frage-ID | Frage (Parameter) | Variable / Baseline-ID | Anzeige-Bedingung |
+|---|---|---|---|
+| Q-BL-01 | Passwort-Mindestlänge / Komplexität / Rotation | `PW_MIN_LENGTH`,`PW_COMPLEXITY`,`PW_ROTATION` (BL-IAM-01) | immer |
+| Q-BL-02 | MFA-Geltungsbereich | `MFA_SCOPE` (BL-IAM-02) | immer |
+| Q-BL-03 | Sitzungs-Timeout | `SESSION_TIMEOUT` (BL-IAM-03) | immer |
+| Q-BL-04 | Kontosperrung | `ACCOUNT_LOCKOUT` (BL-IAM-04) | immer |
+| Q-BL-05 | Rezertifizierungs-Frequenz | `RECERT_FREQ` (BL-IAM-05) | immer |
+| Q-BL-06 | Mindest-TLS / zulässige Algorithmen | `TLS_MIN`,`CRYPTO_ALGO` (BL-CRY-01/02) | immer |
+| Q-BL-07 | Patch-SLAs (kritisch/hoch/standard) | `PATCH_SLA_CRIT/HIGH/STD` (BL-OPS-01) | immer |
+| Q-BL-08 | Schwachstellenscan-Frequenz | `VULN_SCAN_FREQ` (BL-OPS-02) | immer |
+| Q-BL-09 | Malware-Update-Frequenz | `MALWARE_UPDATE` (BL-OPS-03) | immer |
+| Q-BL-10 | Log-Aufbewahrung | `LOG_RETENTION` (BL-OPS-04) | immer |
+| Q-BL-11 | Backup-Schema / Aufbewahrung / Testfrequenz | `BACKUP_SCHEME/RETENTION/TEST_FREQ` (BL-OPS-05/06) | immer |
+| Q-BL-12 | Penetrationstest-Frequenz | `PENTEST_FREQ` (BL-OPS-08) | `FLAG_ELEVATED_PROTECTION` |
+| Q-BL-13 | Eingesetzte Lösungen: MFA/Malware/Backup/SIEM/MDM/VPN | `TECH_MFA/MALWARE/BACKUP/SIEM/MDM/VPN` | jeweils bei zugehörigem Flag |
+| Q-BL-14 | Krypto-Standardvorgabe | `TECH_CRYPTO` (BL-CRY-02) | immer |
+
+## 7. Abschnitt F — Dokument-Metadaten
+
+| Frage-ID | Frage | Variable |
+|---|---|---|
+| Q-DOC-01 | Dokument-Version (Default 1.0) | `DOC_VERSION` |
+| Q-DOC-02 | Dokument-Datum | `DOC_DATE` |
+| Q-DOC-03 | Dokument-Status (Entwurf/In Freigabe/Freigegeben) | `DOC_STATUS` |
+
+---
+
+## 8. Aufgaben-Trigger aus Antworten (Auszug)
+
+| Auslösende Antwort | Aufgabe (Typ) |
+|---|---|
+| Q-ROLE-02 „ISB nicht benannt" | `organizational` – ISB bestellen (verknüpft Control 1.2.2) |
+| Q-ROLE-02/03 ISB = IT-Verantwortung | `organizational` – Funktionstrennung herstellen/kompensieren (C7) |
+| Q-FEAT-09 „externe IT-Dienstleister = ja" | `evidence_provide` – Selbstauskunft/TISAX-Nachweis einholen (Control 6.1.1) |
+| Q-FEAT-02/03 Cloud/KI = ja, ohne Freigabeverfahren | `document_create` – Cloud-/KI-Freigabeverfahren aktivieren (VA-11) |
+| Q-BL-11 „kein Wiederherstellungstest" | `technical` – Restore-Test etablieren (BL-OPS-06, Control 5.2.9) |
+
+> Hinweis: Die vollständige Antwort→Wirkung-Matrix wird maschinenlesbar als Regelobjekte (B2-DSL) hinterlegt; diese Tabelle ist die fachliche Spezifikation dafür. Neue `FLAG_*` bitte zuerst in `variables.schema.json` ergänzen (Single Source of Truth), dann Frage + Wirkung hier.

docs/wizard-uebergabe/02_Fachcontent_C1-C9/C3_Vorlagen-Annotation.md

@@ -0,0 +1,49 @@
+# C3 — Regelfähige Vorlagen-Auszeichnung (Annotationskonvention + Verify + Erweiterung)
+
+> **Schaltet frei:** B4 (Richtlinien – Import + Upload + Control-Mapping). **Grundlage:** `isms-vorlagenpaket-v2/` (34 Vorlagen, `mapping.json`, `variables.schema.json`, `_verify.py`).
+
+## 1. Ist-Zustand (Informationssicherheit) — vollständig annotiert
+
+Das Vorlagenpaket ist für die **Informationssicherheit** bereits regelfähig ausgezeichnet und konsistent:
+
+- **34 Vorlagen** – Leitlinie `L00`, Richtlinien `R01–R14`, Verfahren `VA-01 … VA-19`, plus `Technische-Sicherheits-Baseline.md`, `Nachweisregister_zentral.md`, `ISA-Mapping-Matrix.md`.
+- **316 Anforderungen** in `mapping.json` (312 ISA + 4 kundenspezifisch KI), je mit stabiler ID, `type`, `level`, `policy`, `condition`-Flag, `req_anchor`/`impl_anchor`, `verfahren`.
+- **`python3 _verify.py` → OK** (Render ohne offene Platzhalter für `FLAG_INCLUDE_SHOULD` an/aus, keine verwaisten Anker, keine Handlebars-Reste). **Dieser Lauf ist die Abnahmebedingung jeder Änderung.**
+
+Für Informationssicherheit ist C3 damit als „bestätigt/konsistent" zu betrachten; die SME-Aufgabe ist Pflege + die Erweiterung um Prototypenschutz/Datenschutz (Abschnitt 3).
+
+## 2. Annotationskonvention (verbindlich für alle Vorlagen)
+
+| Konstrukt | Bedeutung | Beispiel |
+|---|---|---|
+| `{{VARIABLE}}` | Variable aus `variables.schema.json` | `{{ORG_NAME}}`, `{{MFA_SCOPE}}` |
+| `{{#if FLAG_X}} … {{/if}}` | Bedingter Block (Feature-Flag/Reifegrad/Schutzbedarf) | `{{#if FLAG_HIGH_PROTECTION}} … {{/if}}` |
+| `[MUSS]`/`[SOLL]`/`[HOCH]`/`[SEHR HOCH]` | Sichtbare Kennzeichnung der Anforderungsstufe | `- **[SOLL]** …` |
+| `<!-- REQ <id> -->` | Hidden-Anker vor einer Einzelanforderung | `<!-- REQ 4.1.2-H1 -->` |
+| `<!-- IMPL <control> -->` | Hidden-Anker vor dem Umsetzungstext (Control-gebündelt) | `<!-- IMPL 4.1.2 -->` |
+| `<!-- IMPL <control>-elev -->` | Umsetzungsvariante für erhöhten Schutzbedarf | `<!-- IMPL 4.1.2-elev -->` |
+| `{{LINK:ZIEL}}` | Laufzeit-Link (Dokument/Nachweisregister) | `{{LINK:R08#4.1.2}}` |
+| Verfahrensanker `<!-- FULFILLS <ids> | POLICY <Rxx> -->` | VA erfüllt Anforderungen | in `VA-*` |
+
+**Regeln für eine regelfähige Auszeichnung**
+
+1. Jede Einzelanforderung erhält genau einen `<!-- REQ <id> -->`-Anker, dessen ID exakt der `mapping.json`-`id` entspricht.
+2. `[SOLL]` immer in `{{#if FLAG_INCLUDE_SHOULD}}`, `[HOCH]` in `{{#if FLAG_HIGH_PROTECTION}}`, `[SEHR HOCH]` in `{{#if FLAG_VERY_HIGH_PROTECTION}}`. Der `condition`-Wert in `mapping.json` und der `{{#if}}` im Dokument müssen übereinstimmen.
+3. Feature-abhängige Klauseln (Cloud/KI/OT/Dev/Mobil/PKI/Extern/Kundensysteme) in den passenden `{{#if FLAG_*}}`-Block.
+4. Konkrete Zahlenwerte nie hart schreiben, sondern über Baseline-Variable (`{{PW_MIN_LENGTH}}` …) referenzieren.
+5. `<!-- … -->`-Anker im Dokument belassen (im Lesemodus unsichtbar); nur der PDF-/Druckexport entfernt sie.
+6. Nach jeder Änderung `python3 _verify.py` → **OK**.
+
+## 3. Erweiterung: Prototypenschutz (P01) + Datenschutz (D01)
+
+Das Paket ist „VDA ISA 2027 (Information Security)". Für die Prüfziele **Prototypenschutz (8.x)** und **Datenschutz (9.x)** sind Vorlagen + `mapping.json`-Einträge neu anzulegen — nach identischer Konvention. Vorschlag:
+
+- **Neue Vorlage `P01_Prototypenschutz.md`** (Richtlinie Prototypenschutz) + Verfahren `VA-20_Prototypen-Zutritt-und-Transport`. Deckt 8.1.x (physische Sicherheit/Perimeter/Zonen/Zutritt/Einbruch/Besucher/Mandantentrennung), 8.2.x (Geheimhaltung/Unterauftragnehmer/Schulung/Klassifizierung/Bildaufzeichnung), 8.3.x (Transport/Lagerung). 8.4.x/8.5.x nur bei erweitertem Prüfziel.
+- **Neue Vorlage `D01_Datenschutz.md`** (Richtlinie Datenschutz) — kann `R14 Compliance & Datenschutz` erweitern/aufteilen; Verfahren `VA-18 Datenschutz-und-Compliance-Pflege` ist vorhanden. Deckt 9.1.x–9.8.x.
+- Je neuer Anforderung ein `mapping.json`-Eintrag im gleichen Schema (`id`,`policy`=P01/D01,`control`,`level`,`type`,`is_isa`=true,`req_anchor`,`impl_anchor`,`condition`,`requirement`,`verfahren`). Anforderungs-IDs siehe C1/C6-Dekomposition (`8.1.1-M1` …, `9.1.1-M1` …).
+- Neue `FLAG_*` bei Bedarf zuerst in `variables.schema.json` (z. B. `FLAG_PROTOTYPE_PROTECTION`), damit `_verify.py` sie kennt; Prototypenschutz-Klauseln in `{{#if FLAG_PROTOTYPE_PROTECTION}}`.
+- `_verify.py` um die neuen Verzeichnisse/Anker erweitern, dann → **OK**.
+
+## 4. Control-Zuordnung beim manuellen Upload (B4b)
+
+Für hochgeladene **eigene** Richtlinien (kein Template): Pflichtfeld „belegt Controls" (Multi-Select aus dem Control-Katalog). Optional je Control die abgedeckten Anforderungs-IDs. Diese Zuordnung fließt wie ein `<!-- REQ -->`-Anker in die Nachweislage (Schritt 7) — ohne Tailoring, aber mit voller Reifegrad-/Gap-Wirkung. Ein späterer Gap-Check (Dokumentinhalt ↔ Anforderungstext) ist als Option vorgesehen (offener Entscheidungspunkt).

docs/wizard-uebergabe/02_Fachcontent_C1-C9/C4_Risikokatalog.md

@@ -0,0 +1,169 @@
+# C4 — Standard-Risikokatalog (VDA ISA / TISAX)
+
+**Paket:** C4 — Kuratierter Risiko-Katalog für den Onboarding-Wizard
+**Modul:** Risikomanagement
+**Referenzen:** R03 Risikomanagement · VA-09 Risikomanagement-Verfahren · VDA ISA (IS 1.x–7.x, Prototypenschutz 8.x, Datenschutz 9.x) · Baseline-Parameter BL-*
+
+---
+
+## 1. Nutzung im Wizard-Schritt „Risikomanagement"
+
+Dieser Katalog wird dem Kunden im Onboarding-Wizard als kuratierte Vorauswahl typischer Informationssicherheits- und TISAX-Risiken angeboten. Der Ablauf:
+
+1. **Auswahl** — Der Kunde markiert die für seinen Scope zutreffenden Risiken. Nicht zutreffende Risiken (z. B. Prototypenschutz ohne physische Musterteile, Entwicklung ohne eigene Softwareentwicklung) werden abgewählt oder als „nicht anwendbar" begründet.
+2. **Ergänzung** — Der Kunde ergänzt eigene, organisationsspezifische Risiken.
+3. **Bewertung** — Jedes ausgewählte Risiko wird nach der 5×5-Matrix bewertet (Eintrittswahrscheinlichkeit × Schadenshöhe). Die im Katalog hinterlegte **Default-Einschätzung** ist ein Startwert und vom Kunden anzupassen.
+4. **Maßnahmenableitung** — Aus dem bewerteten Risiko werden Maßnahmen abgeleitet (Standardmaßnahmen sind vorbelegt). Maßnahmen erzeugen im System **Aufgaben** mit Verantwortlichen und Fristen.
+5. **Restrisiko** — Nach Maßnahmenumsetzung erfolgt eine erneute Bewertung (Netto-/Restrisiko). Restrisiken oberhalb der Akzeptanzschwelle erfordern eine dokumentierte Risikoakzeptanz durch die Leitung (siehe VA-09).
+
+### Bewertungslogik (5×5)
+
+| Achse | Stufen | Kurzdefinition |
+|-------|--------|----------------|
+| **Eintrittswahrscheinlichkeit (E)** | 1 sehr gering · 2 gering · 3 mittel · 4 hoch · 5 sehr hoch | Erwartete Häufigkeit im Betrachtungszeitraum (i. d. R. 12 Monate) |
+| **Schadenshöhe (S)** | 1 vernachlässigbar · 2 gering · 3 spürbar · 4 hoch · 5 existenzbedrohend | Auswirkung auf Vertraulichkeit/Integrität/Verfügbarkeit, Vertrag, Reputation, Recht |
+
+**Risikowert = E × S** (1–25). Klassifizierung gemäß VA-09:
+
+- **1–4 gering** (grün) — beobachten, ggf. akzeptieren
+- **5–9 mittel** (gelb) — Maßnahmen empfohlen
+- **10–15 hoch** (orange) — Maßnahmen verbindlich, Termin gesetzt
+- **16–25 sehr hoch** (rot) — Sofortmaßnahmen, Eskalation an Leitung
+
+Die Default-Einschätzung je Risiko ist als **E/S** angegeben (z. B. „E3/S4"). Sie geht von einem typischen KMU-Zuliefererbetrieb ohne bereits umgesetzte Maßnahmen aus (Brutto-/Ausgangsrisiko).
+
+### ID-Schema
+
+`R-<KATEGORIE>-<lfd. Nr.>` — Kategorien: ORG (Organisation/Governance), HR (Personal), PHY (Physisch), IAM (Identitäts-/Zugriffsmanagement), CRY (Kryptografie), OPS (Betrieb/IT), NET (Netzwerk), SUP (Lieferanten/Cloud), DEV (Entwicklung), PROTO (Prototypenschutz), DSGVO (Datenschutz).
+
+---
+
+## 2. Organisation / Governance
+
+| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) |
+|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------|
+| R-ORG-01 | Fehlende/veraltete IS-Leitlinie & Verantwortlichkeiten | Es existiert keine von der Leitung verabschiedete Informationssicherheitsleitlinie oder Rollen (ISB/CISO) sind nicht benannt, sodass Steuerung und Verbindlichkeit fehlen. | 1.1.1, 1.2.1, 1.3.1 | Richtlinien, Organisation | IS-Leitlinie nach R03 erstellen/aktualisieren, ISB benennen, jährliches Management-Review etablieren | E3/S4 — ohne Governance keine wirksame Steuerung; Schaden trifft gesamtes ISMS |
+| R-ORG-02 | Kein funktionierendes Risikomanagement | Risiken werden nicht systematisch erfasst, bewertet oder behandelt; TISAX-Anforderung an Risikoprozess ist nicht erfüllt. | 1.4.1 | Prozesse, Dokumentation | Risikomanagement-Verfahren VA-09 einführen, Risiko-Register führen, Reviews terminieren | E3/S4 — Kernanforderung TISAX; Assessment-Abweichung wahrscheinlich |
+| R-ORG-03 | Fehlendes Asset- und Informationsklassifizierungsschema | Werte (Informationen, Systeme) sind nicht inventarisiert oder klassifiziert, sodass Schutzbedarf und Maßnahmen nicht zielgerichtet zugeordnet werden können. | 1.3.2, 1.3.3, 5.2.x | Informationswerte, Inventar | Asset-Inventar aufbauen, Klassifizierungsschema (intern/vertraulich/streng vertraulich) einführen und kennzeichnen | E3/S3 — Grundlage vieler Controls; ohne Klassifizierung Fehlschutz |
+| R-ORG-04 | Unzureichende IS-Vorgabendokumentation / veraltete Verfahren | Verfahrensanweisungen und Richtlinien sind nicht vorhanden, veraltet oder werden nicht gelebt, was zu inkonsistentem Handeln führt. | 1.2.x, 1.5.1 | Dokumentation | Dokumentenlenkung nach R03 etablieren, Review-Zyklus (jährlich), Freigabe- und Versionskontrolle | E3/S3 — Nachweisführung im Assessment gefährdet |
+| R-ORG-05 | Fehlendes Vorfalls- / Incident-Management | Sicherheitsvorfälle werden nicht erkannt, gemeldet, dokumentiert oder ausgewertet, wodurch Schäden eskalieren und Lernen ausbleibt. | 1.6.1 | Prozesse | Incident-Response-Prozess einführen, Meldewege und Eskalation definieren, Vorfallregister führen | E3/S4 — verzögerte Reaktion vergrößert Schaden erheblich |
+| R-ORG-06 | Fehlendes Business Continuity / Notfallmanagement | Für Ausfälle kritischer Prozesse/IT existieren keine Notfall- und Wiederanlaufpläne, sodass Betriebsunterbrechungen unkontrolliert verlaufen. | 1.6.x, 7.x | Prozesse, IT-Systeme | BCM-Konzept und Wiederanlaufpläne erstellen, Notfallübungen jährlich, Bezug zu BL-OPS-05 (Backup) | E2/S4 — selten, aber hoher Schaden bei Eintritt |
+
+---
+
+## 3. Personal
+
+| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) |
+|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------|
+| R-HR-01 | Mangelndes Sicherheitsbewusstsein der Mitarbeitenden | Beschäftigte sind nicht regelmäßig geschult und fallen auf Phishing/Social Engineering herein oder handeln fahrlässig. | 2.1.2, 2.1.3 | Personal, Informationen | Awareness-Programm und jährliche Schulungen einführen, Phishing-Simulationen, Schulungsnachweise dokumentieren | E4/S3 — Mensch häufigster Angriffsvektor |
+| R-HR-02 | Fehlende Vertraulichkeits-/Geheimhaltungsvereinbarungen | Mit Mitarbeitenden, Zeitarbeit oder Externen sind keine NDAs abgeschlossen, sodass der Schutz vertraulicher Informationen rechtlich nicht abgesichert ist. | 2.1.1 | Verträge, Personal | NDA/Verpflichtung auf Vertraulichkeit in Onboarding-Prozess verankern, Bestand nachpflegen | E3/S3 — häufige Lücke bei Externen/Zeitarbeit |
+| R-HR-03 | Unsicheres On-/Offboarding (Berechtigungen bei Austritt) | Bei Eintritt, Wechsel oder Austritt werden Zugänge und Assets nicht zeitnah vergeben/entzogen, sodass verwaiste Konten und Datenmitnahme entstehen. | 2.1.x, 3.1.1 | Konten, Endgeräte | On-/Offboarding-Checkliste mit HR/IT, Fristen für Kontoentzug und Asset-Rückgabe, regelmäßiger Abgleich | E3/S3 — verwaiste Konten sind typischer Auditfund |
+| R-HR-04 | Innentäter / Datenmitnahme durch Mitarbeitende | Berechtigte Personen entwenden oder missbrauchen vorsätzlich Informationen (z. B. Konstruktionsdaten) zum eigenen Vorteil oder für Wettbewerber. | 2.1.x, 5.2.x, 3.1.x | Informationen, geistiges Eigentum | Need-to-know umsetzen, Protokollierung sensibler Zugriffe, DLP-Ansätze, arbeitsrechtliche Regelungen | E2/S4 — selten, aber sehr hoher Schaden für IP |
+
+---
+
+## 4. Physische Sicherheit
+
+| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) |
+|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------|
+| R-PHY-01 | Unberechtigter Zutritt zu Betriebs-/Sicherheitsbereichen | Fehlende Zutrittskontrolle ermöglicht Unbefugten Zugang zu Büros, Serverräumen oder Fertigung, mit Diebstahl- und Manipulationsrisiko. | 4.1.1, 4.1.2 | Gebäude, IT-Systeme | Zonenkonzept, Zutrittskontrollsystem/Schließplan, Besucherregelung mit Begleitung und Protokoll | E3/S3 — Grundschutzanforderung, oft lückenhaft |
+| R-PHY-02 | Unzureichender Schutz von Server-/Technikräumen | Serverräume sind nicht ausreichend gegen Zutritt, Brand, Wasser, Strom-/Klimaausfall geschützt, was zu Ausfall oder Datenverlust führt. | 4.1.x, 7.x | IT-Infrastruktur | Technikraum absichern (Zutritt, USV, Klima, Brand-/Wasserschutz), Umgebungsüberwachung | E2/S4 — geringe Häufigkeit, hoher Ausfallschaden |
+| R-PHY-03 | Diebstahl/Verlust von Datenträgern und Dokumenten | Papierunterlagen, USB-Medien oder Datenträger mit vertraulichen Informationen gehen verloren oder werden entwendet. | 4.1.x, 5.2.x | Datenträger, Dokumente | Clean-Desk-Policy, verschließbare Schränke, sichere Entsorgung (Schredder/zertifiziert), Medienverschlüsselung | E3/S3 — alltägliches Restrisiko |
+
+---
+
+## 5. Identitäts- und Zugriffsmanagement (IAM)
+
+| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) |
+|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------|
+| R-IAM-01 | Fehlberechtigungen / überzogene Zugriffsrechte | Zugriffsrechte folgen nicht dem Need-to-know- und Least-Privilege-Prinzip; Sammelrechte und Rechteakkumulation entstehen. | 3.1.1, 3.1.2, 3.1.3 | Konten, Anwendungen, Daten | Rollen-/Rechtekonzept (RBAC), regelmäßige Rezertifizierung der Berechtigungen, Trennung von Funktionen | E4/S3 — häufigster Auditfund im IAM |
+| R-IAM-02 | Schwache Authentisierung / fehlende MFA | Zugänge (insb. remote, Admin, Cloud) sind nur durch schwache Passwörter geschützt, wodurch Kontoübernahmen leicht möglich sind. | 3.1.4, 3.1.5 | Konten, Zugänge | Passwortrichtlinie (BL-IAM-*), MFA für Remote-/Admin-/Cloud-Zugänge verpflichtend, SSO | E4/S4 — Credential-Angriffe sehr häufig und wirksam |
+| R-IAM-03 | Ungesicherte / geteilte privilegierte Konten | Administrative und Sammelkonten werden geteilt genutzt und nicht überwacht, sodass Handlungen nicht zurechenbar sind. | 3.1.x | Admin-Konten | Privileged-Access-Management, personalisierte Admin-Konten, Protokollierung, getrennte Admin-Arbeitsplätze | E3/S4 — Missbrauch privilegierter Rechte hochwirksam |
+
+---
+
+## 6. Kryptografie
+
+| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) |
+|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------|
+| R-CRY-01 | Fehlende Verschlüsselung mobiler Geräte / Datenträger | Notebooks, Smartphones und Wechselmedien sind nicht verschlüsselt, sodass bei Verlust/Diebstahl Daten unmittelbar lesbar sind. | 5.1.1, 5.1.2 | Endgeräte, Datenträger | Full-Disk-Encryption (BitLocker/FileVault) verpflichtend, MDM-erzwungene Verschlüsselung, Medienrichtlinie | E3/S4 — Verlustfall führt sonst direkt zu Datenabfluss |
+| R-CRY-02 | Unsichere Datenübertragung (fehlende Transportverschlüsselung) | Vertrauliche Daten werden unverschlüsselt (E-Mail, FTP, HTTP) übertragen und können abgefangen werden. | 5.1.1 | Kommunikation, Daten | TLS erzwingen, sichere Austauschwege/Portale, E-Mail-Verschlüsselung für vertrauliche Inhalte | E3/S3 — Abfangrisiko bei Zulieferaustausch |
+| R-CRY-03 | Unzureichendes Schlüssel-/Zertifikatsmanagement | Kryptografische Schlüssel und Zertifikate werden nicht sicher verwaltet oder laufen unbemerkt ab, was zu Ausfällen oder Kompromittierung führt. | 5.1.x | Schlüssel, Zertifikate | Krypto-Richtlinie, zentrale Schlüssel-/Zertifikatsverwaltung, Ablaufüberwachung, sichere Aufbewahrung | E2/S3 — schleichender, aber wirkungsvoller Ausfall |
+
+---
+
+## 7. Betrieb / IT
+
+| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) |
+|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------|
+| R-OPS-01 | Fehlendes/mangelhaftes Patch- und Schwachstellenmanagement | Betriebssysteme und Anwendungen werden nicht zeitnah aktualisiert, sodass bekannte Schwachstellen ausnutzbar bleiben. | 5.2.4, 5.2.5 | IT-Systeme, Software | Patchmanagement-Prozess mit Fristen nach Kritikalität, Schwachstellenscans, Vulnerability-Tracking | E4/S4 — meistgenutztes Einfallstor, hohe Angriffsfläche |
+| R-OPS-02 | Schadsoftware / Ransomware-Befall | Malware gelangt über E-Mail, Wechselmedien oder Web ins Netz und verschlüsselt oder exfiltriert Daten. | 5.2.3 | IT-Systeme, Daten | Endpoint-Protection/EDR flächendeckend, E-Mail-/Web-Filter, Makro-Restriktionen, Awareness (R-HR-01) | E4/S5 — hohe Häufigkeit, potenziell existenzbedrohend |
+| R-OPS-03 | Backup-/Wiederanlauf-Versagen | Datensicherungen fehlen, sind unvollständig, nicht getestet oder mitverschlüsselbar, sodass eine Wiederherstellung im Ernstfall scheitert. | 7.x | Daten, IT-Systeme | Backup-Konzept nach BL-OPS-05 (3-2-1, Offline-/Immutable-Kopie), regelmäßige Restore-Tests, RTO/RPO definieren | E3/S5 — im Ransomware-Fall entscheidend für Überleben |
+| R-OPS-04 | Fehlende Protokollierung und Überwachung (Logging/Monitoring) | Sicherheitsrelevante Ereignisse werden nicht protokolliert oder ausgewertet, sodass Angriffe unentdeckt bleiben. | 5.2.6 | IT-Systeme, Logs | Zentrales Logging, Log-Auswertung/SIEM-Ansatz, Aufbewahrungsfristen, Alarmierung bei Auffälligkeiten | E3/S3 — verlängert Entdeckungszeit erheblich |
+| R-OPS-05 | Schatten-IT / nicht genehmigte Software & Dienste | Mitarbeitende nutzen nicht freigegebene Cloud-Dienste oder Software, wodurch Daten unkontrolliert abfließen und Schwachstellen entstehen. | 5.2.x, 6.1.x | Anwendungen, Daten | Freigabeprozess für Software/Dienste, Anwendungsinventar, technische Restriktionen, Awareness | E3/S3 — verbreitet, schwer sichtbar |
+| R-OPS-06 | Fehlkonfiguration / fehlendes Change-Management | Systeme werden ohne kontrollierte Änderungsprozesse betrieben, sodass Fehlkonfigurationen Sicherheitslücken und Ausfälle verursachen. | 5.2.1, 5.2.2 | IT-Systeme, Konfiguration | Härtungs-/Konfigurationsvorgaben (Baselines), Change-Management-Prozess, Test vor Produktivsetzung | E3/S3 — Fehlkonfiguration häufige Ausfall-/Angriffsursache |
+| R-OPS-07 | Verlust/Diebstahl mobiler Endgeräte | Notebooks, Smartphones oder Tablets gehen unterwegs verloren oder werden gestohlen und ermöglichen Zugriff auf Daten und Systeme. | 5.2.x, 5.1.1 | Endgeräte, Daten | MDM mit Remote-Wipe, Geräteverschlüsselung (R-CRY-01), Bildschirmsperre, Verlustmeldeprozess | E3/S3 — mobiles Arbeiten erhöht Häufigkeit |
+| R-OPS-08 | Fehlende sichere Entsorgung / Wiederverwendung von IT | Ausgemusterte Geräte und Datenträger werden ohne sichere Löschung entsorgt oder weitergegeben, sodass Restdaten abfließen. | 5.2.x, 4.1.x | Datenträger, Endgeräte | Prozess zur sicheren Löschung/Vernichtung, zertifizierte Entsorgung, Nachweisführung | E2/S3 — selten, aber unbemerkter Datenabfluss |
+
+---
+
+## 8. Netzwerk
+
+| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) |
+|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------|
+| R-NET-01 | Unsichere Netzsegmentierung / flaches Netz | Fehlende Trennung zwischen Office-, Produktions-/OT- und Gastnetzen ermöglicht laterale Ausbreitung von Angriffen. | 5.2.x | Netzwerk, IT-Systeme | Netzsegmentierung (VLAN/Zonen), Firewall-Regelwerk, Trennung OT/IT und Gast-WLAN | E3/S4 — begünstigt großflächige Kompromittierung |
+| R-NET-02 | Unsicherer Remote-/VPN-Zugang | Fernzugriffe sind nicht ausreichend abgesichert (kein MFA, offene Ports, veraltete VPN-Gateways) und werden angegriffen. | 5.2.x, 3.1.4 | Zugänge, Netzwerk | Gehärtetes VPN mit MFA, Zugriff nach Least-Privilege, Patching der Gateways, Zugriffprotokollierung | E3/S4 — Remote-Zugänge sind bevorzugtes Angriffsziel |
+| R-NET-03 | Unzureichender Perimeter-/Firewall-Schutz | Fehlende oder falsch konfigurierte Firewalls und exponierte Dienste erlauben direkte Angriffe aus dem Internet. | 5.2.x | Netzwerk, IT-Systeme | Firewall mit restriktivem Regelwerk, regelmäßige Regel-Reviews, Minimierung exponierter Dienste, externe Scans | E3/S4 — exponierte Dienste werden automatisiert angegriffen |
+
+---
+
+## 9. Lieferanten / Cloud
+
+| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) |
+|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------|
+| R-SUP-01 | Lieferanten/Dienstleister ohne IS-Nachweis | Externe Partner mit Zugriff auf Informationen/Systeme verfügen über kein nachgewiesenes IS-Niveau (z. B. TISAX/ISO 27001), was Risiken in die Lieferkette trägt. | 6.1.1, 6.1.2 | Verträge, Lieferanten | Lieferantenbewertung, IS-Anforderungen und Nachweise vertraglich fordern, TISAX-Label bei sensiblen Daten | E3/S4 — Kettenrisiko, TISAX-relevant für Weitergabe |
+| R-SUP-02 | Unzureichende vertragliche IS-Regelungen mit Dienstleistern | Verträge enthalten keine Vorgaben zu Vertraulichkeit, Rückgabe/Löschung, Audit- und Meldepflichten. | 6.1.x | Verträge | Standard-IS-Vertragsklauseln/Anlage, Regelungen zu Löschung, Subunternehmern, Meldung von Vorfällen | E3/S3 — Nachweislücke bei Audit |
+| R-SUP-03 | Abhängigkeit von Cloud-Diensten / Datenabfluss in die Cloud | Vertrauliche Daten liegen bei Cloud-Anbietern ohne ausreichende Kontrolle über Standort, Zugriff und Ausfallabsicherung. | 6.1.x, 9.x | Cloud-Dienste, Daten | Cloud-Nutzungsrichtlinie, Anbieterprüfung (Zertifikate, Standort), Verschlüsselung, AVV bei Personenbezug | E3/S4 — Kontrollverlust und Lock-in |
+| R-SUP-04 | Kompromittierung über die Software-Lieferkette | Manipulierte Updates, Bibliotheken oder Fernwartungszugänge von Dienstleistern führen zu Kompromittierungen. | 6.1.x, 5.2.x | Software, Zugänge | Bezugsquellen prüfen, Signaturen verifizieren, Fernwartungszugänge kontrollieren und protokollieren | E2/S4 — selten, aber weitreichende Wirkung |
+
+---
+
+## 10. Entwicklung
+
+| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) |
+|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------|
+| R-DEV-01 | Abfluss von Entwicklungs-/Konstruktionsdaten | Vertrauliche Entwicklungsdaten (CAD, Spezifikationen, Quellcode) gelangen unkontrolliert nach außen (Cloud, Mail, private Geräte). | 5.2.x, 8.x, 6.1.x | Entwicklungsdaten, IP | Klassifizierung und Zugriffsbeschränkung (Need-to-know), sichere Austauschwege, DLP, Repository-Absicherung | E3/S5 — Kernwert des Zulieferers, hoher IP-Schaden |
+| R-DEV-02 | Unsichere Software-Entwicklung (fehlender Secure SDLC) | Sicherheitsanforderungen werden in Entwicklung und Tests nicht berücksichtigt, sodass verwundbare Produkte/Software entstehen. | 5.2.x | Quellcode, Anwendungen | Secure-Coding-Vorgaben, Code-Reviews/SAST, Sicherheitstests, Trennung Entwicklungs-/Produktivumgebung | E3/S3 — je nach Entwicklungsanteil relevant |
+| R-DEV-03 | Testdaten mit Echt-/Produktivdaten | In Entwicklungs- und Testumgebungen werden ungeschützte Produktiv- oder Personendaten verwendet und exponiert. | 5.2.x, 9.x | Testdaten, Personendaten | Anonymisierung/Pseudonymisierung von Testdaten, Zugriffsbeschränkung Testumgebung, Löschkonzept | E3/S3 — verbreitete Praxis, auch datenschutzrelevant |
+
+---
+
+## 11. Prototypenschutz
+
+| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) |
+|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------|
+| R-PROTO-01 | Unberechtigter Zutritt zu Prototypen-/Musterbereichen | Unbefugte erlangen Zugang zu Bereichen mit Prototypen, Musterteilen oder Vorserien und können diese einsehen, fotografieren oder entwenden. | 8.1.x, 8.2.x | Prototypen, Räumlichkeiten | Sicherheitszonen mit Zutrittskontrolle, Begleitpflicht, Kamera-/Fotografierverbot, Besucherregelung | E3/S4 — TISAX-Prototypenschutz Kernrisiko |
+| R-PROTO-02 | Unzureichender Schutz bei Erprobung/Transport von Prototypen | Bei Fahrzeugerprobung, Foto/Film oder Transport werden Prototypen unzureichend getarnt/gesichert und Dritten zugänglich. | 8.3.x, 8.4.x | Prototypen, Fahrzeuge | Tarnung/Abdeckung, gesicherte Transporte, Regelungen für Erprobung und Foto/Film, Geheimhaltungszonen | E2/S4 — seltener, aber öffentlichkeitswirksamer Schaden |
+| R-PROTO-03 | Informationsabfluss zu geschützten Produkten/Projekten | Informationen zu geheimhaltungsbedürftigen Fahrzeugprojekten (Bilder, Daten, Termine) gelangen an Unbefugte oder in soziale Medien. | 8.1.x, 8.2.x | Projektinformationen | Verschärfte Klassifizierung/Kennzeichnung, Need-to-know, Schulung Prototypenschutz, Mobilgeräte-Restriktionen | E3/S4 — Reputations- und Vertragsschaden beim OEM |
+
+---
+
+## 12. Datenschutz
+
+| Risiko-ID | Titel | Beschreibung | Betroffene Controls (VDA ISA) | Asset-Typen | Standardmaßnahme(n) | Default (E/S) |
+|-----------|-------|--------------|-------------------------------|-------------|---------------------|---------------|
+| R-DSGVO-01 | Datenschutzverstoß / meldepflichtige Datenpanne | Personenbezogene Daten werden unrechtmäßig offengelegt, verloren oder verarbeitet, was zu Meldepflicht (Art. 33/34), Bußgeld und Reputationsschaden führt. | 9.x | Personendaten | Datenschutz-Managementprozess, Datenpannen-Meldeprozess (72 h), technische/organisatorische Maßnahmen (TOM) | E3/S4 — hohe Bußgeld- und Meldepflichtrelevanz |
+| R-DSGVO-02 | Fehlende Auftragsverarbeitungsverträge (AVV) | Für Dienstleister, die personenbezogene Daten verarbeiten, fehlen AVV nach Art. 28 DSGVO, sodass Verarbeitung unrechtmäßig ist. | 9.x, 6.1.x | Verträge, Personendaten | AVV-Prozess etablieren, Bestand prüfen und nachholen, Dienstleister mit Personenbezug erfassen | E3/S3 — häufige Lücke, aufsichtsrelevant |
+| R-DSGVO-03 | Fehlendes Verarbeitungsverzeichnis / keine Rechtsgrundlagen | Verarbeitungstätigkeiten sind nicht dokumentiert (Art. 30) oder ohne Rechtsgrundlage, sodass Nachweispflichten verletzt werden. | 9.x | Dokumentation, Personendaten | Verzeichnis von Verarbeitungstätigkeiten führen, Rechtsgrundlagen prüfen, Löschkonzept/Fristen definieren | E3/S3 — Rechenschaftspflicht, Auditfund |
+| R-DSGVO-04 | Unzulässige Übermittlung in Drittländer | Personenbezogene Daten werden ohne geeignete Garantien in Drittländer (z. B. über Cloud-Dienste) übermittelt. | 9.x, 6.1.x | Personendaten, Cloud-Dienste | Datenflüsse prüfen, Standardvertragsklauseln/Transfer-Impact-Assessment, EU-Verarbeitung bevorzugen | E2/S4 — komplex, hohe aufsichtsrechtliche Relevanz |
+
+---
+
+## 13. Hinweise zur Pflege des Katalogs
+
+- Der Katalog ist eine **Startvorlage**; jede Organisation passt Auswahl, Beschreibung, Controls-Zuordnung und Bewertung an ihren Scope an.
+- Controls-Angaben referenzieren die **Struktur** der VDA ISA (Kapitel 1–9). Die genauen Unter-Control-Nummern sind bei Nutzung gegen die aktuell gültige VDA-ISA-Version zu verifizieren.
+- Standardmaßnahmen verweisen, wo möglich, auf vorhandene Vorlagen/Verfahren (R03, VA-09) und Baseline-Parameter (z. B. **BL-OPS-05** Backup). Weitere BL-* sind bei Umsetzung zu ergänzen.
+- Jede aus einem Risiko abgeleitete Maßnahme sollte eine **Aufgabe** mit Verantwortlichem, Termin und Statusverfolgung erzeugen (VA-09).
+
+_Ende Paket C4 — Standard-Risikokatalog._

docs/wizard-uebergabe/02_Fachcontent_C1-C9/C5_Reifegradlogik.md

@@ -0,0 +1,199 @@
+# Paket C5 — Reifegrad-Logik je Control (Onboarding-Wizard, Schritt 7 „Control-Assessment")
+
+**Zweck:** Regelbasierte, nachvollziehbare Herleitung eines **Reifegrad-Vorschlags (0–3)** je Control aus den im Wizard vorhandenen Belegen (verknüpfte Dokumente, Risiken, Assets) und deren Validierungsstatus. Der Vorschlag ist **nicht bindend** — die Bestätigung/Überschreibung durch den Bearbeiter ist Pflicht (Vier-Augen-Logik über die Rolle des ISB/Assessors).
+
+**Grundlage:** VDA-ISA-Reifegradmodell 0–3
+- **0 — unvollständig:** Anforderung nicht oder nur zufällig erfüllt, keine belastbaren Belege.
+- **1 — durchgeführt/informell:** Ergebnis wird erreicht, aber ohne festgelegte, dokumentierte Vorgehensweise.
+- **2 — gesteuert/dokumentiert:** Vorgehen ist definiert, dokumentiert (Richtlinie **und** Verfahren) und mit Nachweisen belegt.
+- **3 — etabliert/integriert:** Vorgehen ist in die Organisation integriert und seine **Wirksamkeit wird über die Zeit nachgewiesen** (wiederkehrende Reviews/Protokolle/Tests).
+
+---
+
+## 1. Belegtypen und Validierungsstatus (Datenmodell-Bezug)
+
+Der Wizard kennt je Control folgende verknüpfbare Belegklassen:
+
+| Belegklasse | Herkunft im Fachcontent | Beispiel |
+|---|---|---|
+| **Zuständige Richtlinie (P)** | Feld `policy` (L00, R01–R14) | Leitlinie, Richtlinie |
+| **Zugehöriges Verfahren (V)** | Feld `verfahren` (VA-01 … VA-19) | Verfahrensanweisung / Prozess |
+| **Operativer Nachweis (N)** | control-spezifisch (Protokoll, Report, Register, Ticket, Testnachweis) | Review-Protokoll, Auditbericht |
+| **Asset-Verknüpfung (A)** | Asset-Inventar | zugeordnete Informationswerte/Systeme |
+| **Risiko-Verknüpfung (R)** | Risikoregister | zugeordnete Risiken + Risk Owner |
+
+**Validierungsstatus je Beleg:** `fehlt` → `verknüpft (unvalidiert)` → `validiert` (durch Bearbeiter bestätigt, vorhanden, aktuell). Ein Beleg zählt für Reifegrad-Sprünge nach ≥2 nur, wenn er **`validiert`** ist.
+
+**Aktualitätsregel (für N):** Ein operativer Nachweis gilt als „aktuell", wenn er innerhalb des für das Control definierten Review-Zyklus liegt (Standard: ≤ 12 Monate; anlassbezogene Verfahren: letzter relevanter Vorfall/Change abgedeckt). Veraltete Nachweise zählen wie `verknüpft (unvalidiert)`.
+
+---
+
+## 2. Allgemeine Regeltabelle „Belegkonstellation → Reifegrad-Vorschlag" (generisch, für alle Controls)
+
+| # | Belegkonstellation | Vorschlag | Begründung |
+|---|---|---|---|
+| R0 | Keine Belege verknüpft **oder** nur unvalidierte Fragmente ohne zuständige Richtlinie | **0** | Kein belastbarer Nachweis einer geregelten Vorgehensweise. |
+| R1a | Zuständige Richtlinie (P) verknüpft, aber **nicht validiert** | **1** | Regelungsabsicht erkennbar, aber nicht bestätigt/gelebt (informell). |
+| R1b | Richtlinie (P) validiert, **aber** ein für das Control **gefordertes Verfahren (V) fehlt** oder ist unvalidiert | **1** | Richtlinie allein steuert die operative Umsetzung noch nicht. |
+| R1c | Nur operativer Nachweis (N) vorhanden, **ohne** validierte Richtlinie | **1** | Tätigkeit wird durchgeführt, aber nicht dokumentiert gesteuert. |
+| R2 | Richtlinie (P) **validiert** **UND** alle geforderten Verfahren (V) **validiert** **UND** (falls einschlägig) Asset-/Risiko-Verknüpfung vorhanden | **2** | Vorgehen ist dokumentiert und gesteuert, Nachweise liegen strukturell vor. |
+| R3 | Zusätzlich zu R2: mindestens **ein operativer Wirksamkeitsnachweis (N) validiert und aktuell** (Review-/Audit-/Test-/Schulungs-/Rezertifizierungsprotokoll) | **3** | Wirksamkeit wird über die Zeit belegt, Vorgehen ist integriert. |
+
+**Sonderfälle:**
+- Controls **ohne** zugeordnetes Verfahren im Fachcontent (`verfahren` = leer): Die operative Steuerung ist in der Richtlinie selbst verankert. Für Grad 2 tritt an die Stelle von (V) eine **validierte, dokumentierte Umsetzungsregelung/Konfiguration (N-basisch)**; Grad 3 erfordert weiterhin einen **wiederkehrenden Wirksamkeitsnachweis**.
+- Controls, die nur `SOLL` enthalten (z. B. 5.3.3): MUSS-Ebene ist definitionsgemäß erfüllt; Bewertung startet effektiv bei 1 und folgt ansonsten der Tabelle.
+- **Nachweis widerspricht Richtlinie / offene Findings im Nachweis:** Vorschlag wird um einen Grad gedeckelt (max. 1) und ein offener Punkt erzeugt.
+
+---
+
+## 3. Zielreifegrad-Regel
+
+| Assessment-Scope (Kundenkonfiguration) | Standard-Zielreifegrad |
+|---|---|
+| **AL 3** / normaler Schutzbedarf (MUSS + SOLL im Scope) | **3** |
+| **AL 2** / reiner **MUSS-Scope** | **2** |
+| Control mit HOCH/SEHR-HOCH-Anforderungen im Scope (hoher/sehr hoher Schutzbedarf) | **3** (Grad 3 wird zur Pflicht, keine Absenkung) |
+
+- Der Zielreifegrad wird **einmal je Assessment** aus dem Scope (AL2/AL3, Schutzbedarf-Flags `FLAG_INCLUDE_SHOULD`, `FLAG_HIGH_PROTECTION`, `FLAG_VERY_HIGH_PROTECTION`) abgeleitet und je Control angezeigt.
+- In der Control-Tabelle (Abschnitt 5) ist der **Standard-Zielreifegrad = 3** ausgewiesen; er sinkt automatisch auf **2**, sobald der Kunde im Onboarding einen reinen MUSS-/AL2-Scope wählt.
+
+---
+
+## 4. „Offener-Punkt"-Kriterium (Gap/Aufgabe entsteht, wenn …)
+
+Ein **offener Punkt (Gap → Aufgabe)** wird automatisch erzeugt, wenn **eine** der folgenden Bedingungen zutrifft:
+
+1. **Vorschlag < Zielreifegrad** (Reifegradlücke). → Aufgabe: „Belege/Umsetzung bis Zielgrad X anheben".
+2. **Pflichtbeleg fehlt:** zuständige Richtlinie (P) oder ein gefordertes Verfahren (V) ist `fehlt`/unvalidiert. → Aufgabe: Dokument erstellen/verknüpfen/validieren.
+3. **Operativer Nachweis fehlt oder ist veraltet**, obwohl Zielgrad 3. → Aufgabe: Review/Audit/Test durchführen und dokumentieren.
+4. **Asset-/Risiko-Verknüpfung fehlt** bei Controls, die auf Inventar/Risikoregister aufsetzen (z. B. 1.3.x, 1.4.1, 5.2.8). → Aufgabe: Verknüpfung herstellen.
+5. **Nachweis mit Findings/Widerspruch** (Deckelung nach Abschnitt 2). → Aufgabe: Abweichung beheben.
+6. **Bearbeiter überschreibt Vorschlag nach unten** oder markiert „nicht bestätigt". → Aufgabe mit Begründungspflicht.
+
+Jeder offene Punkt trägt: Control-ID, fehlende Belegklasse, Ist-Grad, Zielgrad, empfohlene Maßnahme, Verantwortlichen (Default: ISB).
+
+---
+
+## 5. Control-spezifische Tabelle — IS-Controls (alle 45)
+
+**Legende Richtlinien (`policy`):** L00 = Informationssicherheits-Leitlinie · R01 = ISMS-Organisation/Rollen · R02 = Umgang mit Informationswerten (Asset-Mgmt) · R03 = Risikomanagement & Wirksamkeitsprüfung · R04 = Incident-/Notfall-/Kontinuitätsmanagement · R05 = Personalsicherheit · R06 = Mobiles Arbeiten/Mobile Geräte · R07 = Physische Sicherheit/Zonenkonzept · R08 = Zugriffssteuerung (IAM) · R09 = Kryptografie/Kommunikationssicherheit · R10 = IT-Betriebssicherheit · R11 = Systementwicklung/Beschaffung · R12 = Cloud/externe IT-Dienste & KI · R13 = Lieferantenmanagement · R14 = Compliance/Recht & Datenschutz.
+
+**Legende Verfahren (`verfahren`, abgeleitete Bezeichnungen):** VA-01 Ereignisbehandlung · VA-02 Notfall-/Kontinuitätsmgmt · VA-03 Benutzer-/Berechtigungsverwaltung · VA-04 Change-Management · VA-05 Backup & Wiederherstellung · VA-06 Schwachstellen-/Patch-/Audit-Mgmt · VA-07 Kryptografie/sichere Übertragung · VA-08 Asset-Inventarisierung & Klassifizierung · VA-09 Risikomanagement · VA-10 Lieferantensteuerung · VA-11 Cloud-/KI-Freigabe · VA-12 Schulung & Sensibilisierung · VA-13 Protokollierung/Monitoring · VA-14 Personalprozess · VA-15 Interne Audits/Compliance-Prüfung · VA-17 Zutrittsmanagement · VA-16 Sichere Entwicklung/Beschaffung · VA-18 Rechts-/Datenschutzkataster · VA-19 Projektklassifizierung.
+
+Format: **Reifegrad-2-Bedingung** = Vorgehen dokumentiert & gesteuert · **Reifegrad-3-Bedingung** = zusätzlich validierter, aktueller Wirksamkeitsnachweis.
+
+| Control | Erwartete Belege (Richtlinie / Verfahren / operativer Nachweis) | Reifegrad-2-Bedingung | Reifegrad-3-Bedingung | Ziel |
+|---|---|---|---|---|
+| **1.1.1** IS-Leitlinie | L00 / — / Managementfreigabe + Veröffentlichungsnachweis (Intranet), Änderungskommunikation | L00 validiert, Freigabe u. Bereitstellung dokumentiert | Wiederkehrender Leitlinien-Review (≤12 M.) + Nachweis Änderungskommunikation | 3 |
+| **1.2.1** ISMS/Geltungsbereich | R01 / — / Anwendbarkeitserklärung (SoA)/ISA-Katalog, Management-Review-Protokoll | R01 validiert, Scope + SoA dokumentiert | Regelmäßige Managementbewertung mit Wirksamkeitsaussage | 3 |
+| **1.2.2** Rollen & Verantwortlichkeiten | R01 / — / Rollen-/Verantwortungsmatrix, ISB-Ernennung, Qualifikationsnachweis | R01 validiert, Rollen zugewiesen u. dokumentiert | Periodische Überprüfung der Rollenbesetzung/Qualifikation | 3 |
+| **1.2.3** Projektklassifizierung | R01 / VA-19 / ausgefüllte Projektklassifizierung + Projekt-Risikobewertung | R01 + VA-19 validiert | Nachweis wiederholter Klassifizierung/Neubewertung über Projekte | 3 |
+| **1.3.1** Identifizierung Informationswerte | R02 / VA-08 / aktuelles Asset-/Informationswert-Inventar (**A**) | R02 + VA-08 validiert, Inventar (A) verknüpft | Nachweis regelmäßiger Inventarpflege/-abgleich | 3 |
+| **1.3.2** Klassifizierung Informationswerte | R02 / VA-08 / Klassifizierungsschema + klassifizierte Assets (**A**) | R02 + VA-08 validiert, Schema angewandt | Regelmäßige Überprüfung/Neubewertung der Klassifizierung | 3 |
+| **1.3.3** Externe IT-Dienste | R02 / — / Freigabe-/Bestandsliste externer Dienste, Freigabeverfahren | R02 validiert + dokumentierte Freigabeliste u. -regelung | Regelmäßige Prüfung, dass nur freigegebene Dienste genutzt werden | 3 |
+| **1.3.4** Software-Freigabe | R02 / — / Softwarefreigabeliste/Whitelist, Versions-/Patchstand | R02 validiert + dokumentierte Freigabeliste | Regelmäßige Überprüfung der Softwarefreigaben | 3 |
+| **1.4.1** Risikomanagement | R03 / VA-09 / Risikoregister mit Risk Ownern (**R**), Maßnahmenplan | R03 + VA-09 validiert, Risikoregister (R) verknüpft | Regelmäßige/anlassbezogene Neubewertung + Maßnahmen-Tracking | 3 |
+| **1.5.1** Compliance-/Richtlinienprüfung | R03 / VA-15 / Prüfplan + Prüfaufzeichnungen/Ergebnisse | R03 + VA-15 validiert, Prüfplan vorhanden | Durchgeführte Prüfungen dokumentiert + Korrekturmaßnahmen verfolgt | 3 |
+| **1.5.2** Unabhängige Überprüfung | R03 / VA-15 / Bericht unabhängiger/kompetenter Stelle, Managementbericht | R03 + VA-15 validiert | Durchgeführte unabhängige Prüfung + Maßnahmenverfolgung nachgewiesen | 3 |
+| **1.6.1** Meldung Sicherheitsereignisse | R04 / VA-01 / dokumentierte Meldewege/-kanäle, Meldeformular/Ticketsystem | R04 + VA-01 validiert, Meldewege bekannt | Nachweis genutzter Meldewege (Tickets) + ggf. Test der Meldung | 3 |
+| **1.6.2** Behandlung Sicherheitsereignisse | R04 / VA-01 / Incident-Log/Tickethistorie mit Lessons Learned | R04 + VA-01 validiert | Bearbeitete Vorfälle + Lessons-Learned-Rückfluss nachgewiesen | 3 |
+| **1.6.3** Krisen-/Notfallmanagement | R04 / VA-02 / Krisen-/Notfallplan, Krisenstab, Übungs-/Testprotokoll | R04 + VA-02 validiert, Plan u. Rollen dokumentiert | Durchgeführte Krisenübung/Test + Aktualisierung der Planung | 3 |
+| **2.1.1** Personalprüfung (Eignung/Identität) | R05 / VA-14 / Einstellungsprozess, dokumentierte Identitätsprüfung | R05 + VA-14 validiert | Nachweis gelebter Prüfung über Einstellungen (Stichprobe) | 3 |
+| **2.1.2** Verpflichtungen (NDA/Richtlinien) | R05 / VA-14 / unterzeichnete Vertraulichkeits-/Richtlinienverpflichtungen | R05 + VA-14 validiert, Verpflichtungen vorhanden | Nachweis flächendeckender, aktueller Verpflichtungen | 3 |
+| **2.1.3** Schulung & Sensibilisierung | R05 / VA-12 / Schulungskonzept + Teilnahmenachweise | R05 + VA-12 validiert, Konzept genehmigt | Regelmäßig durchgeführte Schulungen + Teilnahmedokumentation | 3 |
+| **2.1.4** Mobiles Arbeiten | R06 / — / kommunizierte Regelung, Sensibilisierungsnachweis | R06 validiert + dokumentierte Anforderungen | Nachweis Sensibilisierung + Überprüfung der Umsetzung | 3 |
+| **3.1.1** Sicherheitszonenkonzept | R07 / VA-17 / Zonenkonzept + Umsetzungsnachweis, Zutritts-/Besucherverfahren | R07 + VA-17 validiert, Zonenkonzept umgesetzt | Regelmäßige Überprüfung von Zonen/Zutritt/Besuchermgmt | 3 |
+| **3.1.4** Mobile Geräte/Datenträger | R06 / — / Regelung + Geräteregistrierung/MDM-Nachweis | R06 validiert + dokumentierte Anforderungen/Registrierung | Nachweis Umsetzung (MDM/Verschlüsselung) + Überprüfung | 3 |
+| **4.1.1** Identifikationsmittel (Lebenszyklus) | R08 / VA-03 / Ausgabe-/Rückgabe-/Sperrprozess, Nachweis kontrollierte Erstellung | R08 + VA-03 validiert | Nachweis gelebter Sperr-/Rückgabeprozesse (z. B. Verlustfall) | 3 |
+| **4.1.2** Benutzerauthentifizierung | R08 / — / Authentifizierungskonzept, techn. Umsetzung (Passwortpolicy/MFA) | R08 validiert + dokumentiertes Auth-Konzept | Nachweis wirksamer Umsetzung (MFA-/Policy-Report) + Review | 3 |
+| **4.1.3** Verwaltung Benutzerkonten | R08 / VA-03 / Kontenverwaltungsprozess, Konten-Rezertifizierung | R08 + VA-03 validiert | Regelmäßige Konten-Überprüfung/Rezertifizierung nachgewiesen | 3 |
+| **4.2.1** Verwaltung Zugriffsrechte | R08 / VA-03 / Berechtigungskonzept, Rechte-Review/Rezertifizierung | R08 + VA-03 validiert | Regelmäßige Rechte-Rezertifizierung nachgewiesen | 3 |
+| **5.1.1** Kryptografie | R09 / VA-07 / Kryptokonzept, Nachweis eingesetzter Verfahren | R09 + VA-07 validiert, Konzept umgesetzt | Regelmäßige Überprüfung der Krypto-Verfahren/Stand der Technik | 3 |
+| **5.1.2** Netzdienste/sichere Übertragung | R09 / VA-07 / Netzdienst-Inventar, Verschlüsselungsnachweis | R09 + VA-07 validiert, Dienste dokumentiert | Nachweis wirksamer (Transport-)Verschlüsselung + Überprüfung | 3 |
+| **5.2.1** Change-Management | R10 / VA-04 / Change-Prozess, Change-Tickets/CAB-Protokolle | R10 + VA-04 validiert | Nachweis gelebter Changes inkl. IS-Bewertung + Verifikation | 3 |
+| **5.2.2** Trennung Entw./Test/Prod | R10 / — / Risikobewertung + Segmentierungsnachweis | R10 validiert + dokumentierte Segmentierung | Überprüfung der Trennung/Segmentierung im Betrieb | 3 |
+| **5.2.3** Schutz vor Schadsoftware | R10 / — / AV-Konzept, AV-Konsole/Status-Report | R10 validiert + dokumentierte Schutzmaßnahmen | Aktueller AV-Statusreport + regelmäßige Überprüfung | 3 |
+| **5.2.4** Protokollierung/Logging | R10 / VA-13 / Logging-Konzept, Log-Review-Nachweis | R10 + VA-13 validiert | Nachweis regelmäßiger Log-Auswertung/Eskalation | 3 |
+| **5.2.5** Umgang mit Schwachstellen | R10 / VA-04, VA-06 / Schwachstellen-/Patchprozess, Scan-/Patchreports | R10 + VA-04 + VA-06 validiert | Aktuelle Scan-/Patchreports + Risikobehandlung nachgewiesen | 3 |
+| **5.2.6** Prüfung von IT-Systemen (Audit) | R10 / VA-06 / Prüfanforderungen, Audit-/Pentestberichte | R10 + VA-06 validiert | Durchgeführte System-/Dienstprüfungen + Maßnahmen nachgewiesen | 3 |
+| **5.2.7** Netzwerkmanagement | R10 / — / Netzkonzept/Segmentierung, Umsetzungsnachweis | R10 validiert + dokumentiertes Netzkonzept | Überprüfung von Netzmgmt/Segmentierung im Betrieb | 3 |
+| **5.2.8** Kontinuität IT-Dienste (BCM) | R04 / VA-02 / kritische Dienste identifiziert (**A**), Kontinuitätsplan, Testprotokoll | R04 + VA-02 validiert, kritische Dienste (A) erfasst | Durchgeführter Kontinuitäts-/Wiederherstellungstest nachgewiesen | 3 |
+| **5.2.9** Backup & Wiederherstellung | R10 / VA-05 / Backup-/Restore-Konzept, Restore-Testprotokoll | R10 + VA-05 validiert, Konzepte vorhanden | Durchgeführter Restore-Test (regelmäßig) nachgewiesen | 3 |
+| **5.3.1** Sichere Systementwicklung/Beschaffung | R11 / VA-16 / IS-Anforderungen, Abnahme-/Testnachweise | R11 + VA-16 validiert | Nachweis durchgeführter Abnahmetests/Security-Tests | 3 |
+| **5.3.2** Sicherheit Netzdienste | R11 / VA-16 / SLA/Absicherungsverfahren, Überwachungsnachweis | R11 + VA-16 validiert | Nachweis Überwachung/Qualitätssicherung der Netzdienste | 3 |
+| **5.3.3** Beendigung IT-Dienste (nur SOLL) | R11 / — / vertraglich geregelter Beendigungsprozess, Nachweis Rückgabe/Löschung | R11 validiert + dokumentierter Beendigungsprozess | Nachweis gelebter Beendigung (Datenrückgabe/-löschung) | 3 |
+| **5.3.4** Mandantentrennung (Cloud) | R12 / VA-11 / Trennungskonzept des Anbieters, Nachweis | R12 + VA-11 validiert | Regelmäßige Überprüfung/Anpassung des Trennungskonzepts | 3 |
+| **5.3.4-KI** KI-/GenAI-Nutzung | R12 / VA-11 / KI-Nutzungsregelung + Freigabeliste, vertragl. Trainings-Ausschluss | R12 + VA-11 validiert, Freigabeliste + Datenklassen | Human-in-the-Loop-/Dokumentationsnachweis + Überprüfung | 3 |
+| **6.1.1** Lieferantenmanagement | R13 / VA-10 / Lieferantenbewertung, Verträge + Nachweise/Zertifikate | R13 + VA-10 validiert, Bewertung + Verträge | Regelmäßige Überprüfung Nachweise/Vertragserfüllung (Monitoring) | 3 |
+| **6.1.2** Vertraulichkeitsvereinbarungen | R13 / VA-10 / NDA-Vorlagen + abgeschlossene NDAs, Gültigkeitsüberwachung | R13 + VA-10 validiert, Vorlagen + NDAs | Regelmäßige Überprüfung/Verlängerung + gelebte NDA-Nutzung | 3 |
+| **6.1.3** Geteilte Verantwortlichkeiten (Shared Resp.) | R13 / VA-10 / Verantwortungsmatrix, Nachweis Erfüllung durch Dienstleister | R13 + VA-10 validiert, Matrix dokumentiert | Nachweis, dass Dienstleister Verantwortung erfüllen (Prüfung) | 3 |
+| **7.1.1** Rechtliche/vertragliche Vorgaben | R14 / VA-18 / Rechts-/Compliance-Kataster, Aktualisierungsnachweis | R14 + VA-18 validiert, Kataster vorhanden | Regelmäßige Aktualisierung des Katasters + Umsetzungsnachweis | 3 |
+| **7.1.2** Datenschutz-relevante IS-Anforderungen | R14 / VA-18 / dokumentierte DS-Anforderungen, Umsetzungsnachweis im ISMS | R14 + VA-18 validiert, Anforderungen bestimmt | Nachweis Umsetzung/Überprüfung im ISMS-Kontext | 3 (MUSS-only¹) |
+
+¹ 7.1.2 enthält nur MUSS-Anforderungen: In reinem AL2-/MUSS-Scope Zielreifegrad **2**; ansonsten 3.
+
+---
+
+## 6. Proto (8.x) und Datenschutz (9.x) — kompakte Gruppenlogik
+
+Für Prototypenschutz und Datenschutz sind im Fachcontent **keine Verfahren (VA)** hinterlegt; die Anforderungen sind überwiegend **MUSS** und stark auftraggeber-/rechtsgetrieben. Die Reifegradlogik wird daher vereinfacht: Für Grad 2 tritt an die Stelle des Verfahrens die **dokumentierte, umgesetzte Regelung** (Konzept/Prozess/Vereinbarung); Grad 3 erfordert einen **wiederkehrenden Wirksamkeits-/Umsetzungsnachweis**.
+
+**Generische Regel Proto/DS:**
+- **0** — keine Regelung/kein Konzept belegt.
+- **1** — Konzept/Vereinbarung vorhanden, aber unvalidiert oder nur informell umgesetzt.
+- **2** — Konzept/Prozess/Vereinbarung **validiert und umgesetzt** (physische Maßnahme, Vertrag, dokumentierter Prozess).
+- **3** — zusätzlich **validierter, aktueller Nachweis der gelebten Umsetzung** (Auditbericht, Alarmverfolgung, Schulungsnachweis, Besucherprotokoll, DSFA-Register, VVT-Pflege, Auftragskontrollen).
+
+**Zielreifegrad Proto/DS:** überwiegend **2** (reine MUSS-Anforderungen); für Gruppen mit SOLL/HOCH-Anteil bzw. hohem Schutzbedarf **3**.
+
+### 6.1 Prototypenschutz (8.x)
+
+| Gruppe | Controls | Erwartete Belege (Richtlinie/Regelung / operativer Nachweis) | Grad-2-Bedingung | Grad-3-Bedingung | Ziel |
+|---|---|---|---|---|---|
+| **8.1 Physische Sicherheit** | 8.1.1–8.1.8 | Sicherheitskonzept Prototypenschutz (Außenhaut, Zutritt, Einblickschutz, EMA/Alarmverfolgung, Besuchermgmt, Mandantentrennung) / Umsetzungs- u. Alarmverfolgungsnachweise, Besucherprotokolle | Sicherheitskonzept validiert + Schutzmaßnahmen umgesetzt | Wiederkehrende Überprüfung der phys. Maßnahmen + Alarmverfolgung/Besuchermgmt nachgewiesen | 2–3² |
+| **8.2 Organisation/Vertrag/Personal** | 8.2.1–8.2.7 | NDAs (Firma + Personen), Zutrittsvergabeprozess, Schulungskonzept Prototypen, Bild-/Geräteregelungen / unterzeichnete NDAs, Schulungsnachweise, Zutrittslogs | Vereinbarungen/Prozesse validiert u. dokumentiert | Nachweis gelebter Umsetzung (Schulungen, Zutritts-Reviews, Nachweise Unterauftragnehmer) | 2 |
+| **8.3 Transport/Lagerung** | 8.3.1–8.3.2 | Prozess Einholung Auftraggebervorgaben, freigegebene Logistiker / Nachweis Einhaltung/Meldeprozess | Prozesse validiert u. implementiert | Nachweis gelebter Transport-/Lagerkontrollen u. Ereignismeldung | 2 |
+| **8.4 Tarnung/Erprobung** | 8.4.1–8.4.3 | Tarnungs-/Erprobungsregeln, Meldeprozess Beschädigungen / Nachweis Bekanntgabe u. Einhaltung | Regeln/Prozesse validiert u. bekannt | Nachweis gelebter Einhaltung + Meldungen bei Vorfällen | 2 |
+| **8.5 Ausstellungen/Foto-Film** | 8.5.1–8.5.2 | Prozess Auftraggebervorgaben, freigegebene Sicherheitskonzepte / Freigabenachweise, Verhaltensregeln | Prozesse + freigegebene Konzepte validiert | Nachweis gelebter Umsetzung je Veranstaltung/Shooting | 2 |
+
+² 8.1.4/8.1.5/8.1.8 mit HOCH-Anteil (schutzbedürftige Fahrzeuge): Zielreifegrad 3.
+
+### 6.2 Datenschutz (9.x)
+
+| Gruppe | Controls | Erwartete Belege (Richtlinie/Regelung / operativer Nachweis) | Grad-2-Bedingung | Grad-3-Bedingung | Ziel |
+|---|---|---|---|---|---|
+| **9.1 Richtlinie DS** | 9.1.1 | DS-Richtlinie (freigegeben) / Aktualisierungs-/Freigabenachweis | DS-Richtlinie validiert u. freigegeben | Regelmäßige Aktualisierung/Review nachgewiesen | 2 |
+| **9.2 Verantwortlichkeiten DS** | 9.2.1 | DSB-Bestellung/DS-Funktion, Kontaktveröffentlichung, Ressourcen / Kontroll- u. Berichtsdokumentation | Bestellung/Funktion + Eingliederung validiert | Nachweis ausgeübter Kontrollpflichten + Managementbericht | 2 |
+| **9.3 Verarbeitungsverzeichnis** | 9.3.1 | VVT (Art. 30), Prozessbeschreibung/Zuständigkeiten / VVT-Pflegenachweis | VVT + Prozess validiert | Regelmäßige VVT-Pflege/Aktualität nachgewiesen | 2 |
+| **9.4 DSFA** | 9.4.1 | Kriterien/Liste DSFA-pflichtiger Verarbeitungen, DSFA-Verfahren / durchgeführte DSFA | DSFA-Verfahren + Zuständigkeiten validiert | Durchgeführte DSFA + Maßnahmen nachgewiesen | 2 |
+| **9.5 Datenübermittlung/AV** | 9.5.1–9.5.3 | AV-Verträge (Art. 28), Transferinstrumente, Drittland-Garantien / Nachweis Verträge/Prüfungen | Prozesse + Verträge validiert | Nachweis Überprüfung Einhaltung + Drittland-Erfassung (TIA) | 2 |
+| **9.6 Betroffenenrechte/Vorfälle** | 9.6.1–9.6.2 | Verfahren Betroffenenanfragen, DS-Vorfall-/Notfallplan, Schulung / Bearbeitungs-/Meldenachweise | Verfahren validiert u. dokumentiert | Nachweis fristgerechter Bearbeitung + Meldeprozesse gelebt | 2 |
+| **9.7 Personal DS** | 9.7.1–9.7.2 | Vertraulichkeitsverpflichtungen, DS-Schulungskonzept / Verpflichtungs- u. Schulungsnachweise | Verpflichtung + Schulungskonzept validiert | Regelmäßige DS-Schulungen + Verpflichtungen nachgewiesen | 2 |
+| **9.8 Weisungen AV** | 9.8.1 | Verfahren Weisungsumgang, Datentrennung nach Auftrag / Dokumentation Weisungen | Verfahren + Maßnahmen validiert | Nachweis dokumentierter/umgesetzter Weisungen + Trennung | 2 |
+
+---
+
+## 7. Umsetzungshinweis Wizard (Pseudologik)
+
+```
+ziel = ableiteZiel(scope)                     // AL3 -> 3, AL2/MUSS -> 2, HOCH/V-HOCH -> 3
+p = statusRichtlinie(control.policy)
+v = min(statusAllerVerfahren(control.verfahren))   // leer -> „n/a" (durch N-basisch ersetzt)
+n = statusOperativerNachweis(control)              // inkl. Aktualitätsprüfung
+a = statusAssetVerknuepfung(control)               // nur falls einschlägig
+r = statusRisikoVerknuepfung(control)              // nur falls einschlägig
+
+if p != validiert:                      vorschlag = (p == verknuepft) ? 1 : 0
+elif verfahrenGefordert && v != validiert: vorschlag = 1
+elif einschlaegigA && a != verknuepft:  vorschlag = 1
+else:                                   vorschlag = 2
+if vorschlag == 2 && n == validiert_aktuell: vorschlag = 3
+if nachweisMitFindings:                 vorschlag = min(vorschlag, 1)
+
+if vorschlag < ziel || pflichtbelegFehlt || (ziel==3 && n!=validiert_aktuell):
+    erzeugeOffenenPunkt(control, ist=vorschlag, ziel, fehlendeBelege)
+
+// Pflicht: Bearbeiter bestätigt oder überschreibt vorschlag (mit Begründung)
+```
+
+**Kernprinzip:** Der Wizard schlägt vor, der Bearbeiter entscheidet. Jeder Vorschlag ist über die verknüpften, validierten Belege vollständig nachvollziehbar; jede Lücke zwischen Vorschlag und Zielreifegrad wird automatisch in einen offenen Punkt (Aufgabe) überführt.

docs/wizard-uebergabe/02_Fachcontent_C1-C9/C7_Rollen-Funktionstrennung.md

@@ -0,0 +1,61 @@
+# C7 — ISMS-Soll-Rollenmodell + Funktionstrennung (+ Bestellungs-Vorlage)
+
+> **Schaltet frei:** A4 (ISMS-Rollen & Funktionstrennung, Schritt 3). **Grundlage:** `variables.schema.json` (`ROLE_*`), Richtlinie `R01_ISMS-Organisation-und-Rollen`.
+
+## 1. Soll-Rollenmodell
+
+| Rolle | Variable | Kernverantwortung | Besetzung |
+|---|---|---|---|
+| Oberste Leitung | `ROLE_MANAGEMENT` | Gesamtverantwortung ISMS, Ressourcen, Freigabe von Leitlinie/Richtlinien, Managementbewertung | intern (GF) |
+| Informationssicherheitsbeauftragte(r) | `ROLE_ISB` | Aufbau/Pflege/Weiterentwicklung ISMS, Beratung der Leitung, Risikomanagement, Audits, Meldeweg; berichtet direkt an die Leitung | intern **oder** extern |
+| IT-Leitung / IT-Verantwortung | `ROLE_IT_LEAD` | Betrieb, technische Umsetzung der Maßnahmen | intern oder extern (Dienstleister) |
+| Personalleitung | `ROLE_HR_LEAD` | Personalsicherheit, On-/Offboarding, Awareness | intern |
+| Datenschutzbeauftragte(r) | `ROLE_DPO` | Datenschutz-Compliance (bei Verarbeitung personenbezogener Daten) | intern oder extern |
+
+Bezug: Controls 1.2.1/1.2.2 (Organisation der IS), 2.1.x (Personal), 7.1.2 (Datenschutz). Rollen-Variablen befüllen Platzhalter in allen Vorlagen (Verantwortlich/Freigabe).
+
+## 2. Funktionstrennungs-Regeln (Prüfung im Wizard)
+
+| Regel-ID | Bedingung | Ergebnis | Begründung |
+|---|---|---|---|
+| FT-01 | `ROLE_ISB` = `ROLE_IT_LEAD` (dieselbe Person, beide intern) | **Konflikt** → Hinweis + Aufgabe | ISB muss die IT unabhängig überwachen können; Selbstkontrolle unzulässig |
+| FT-02 | `ROLE_ISB` intern **und** direkt der IT-Leitung unterstellt | **Konflikt (schwach)** → Hinweis | Weisungsunabhängigkeit/Berichtsweg an Leitung gefährdet |
+| FT-03 | `ROLE_ISB` = `ROLE_MANAGEMENT` | **Konflikt** → Hinweis + Aufgabe | Leitung kann eigene ISMS-Verantwortung nicht selbst überwachen |
+| FT-04 | `ROLE_ISB` nicht benannt | **Lücke** → Aufgabe „ISB bestellen" (Control 1.2.2) | ISB ist Muss-Anforderung |
+| FT-05 | `ROLE_DPO` fehlt trotz `FLAG_PERSONAL_DATA` | **Lücke** → Aufgabe „DSB benennen/prüfen" | Datenschutz-Organisation erforderlich |
+| FT-06 | Antragsteller = Genehmiger von Zugriffsrechten (aus IAM-Daten) | **Konflikt** → Hinweis | Vier-Augen bei Berechtigungsvergabe (Control 4.2.1) |
+
+**Kompensierende Kontrollen** (wenn Trennung z. B. bei Kleinorganisation nicht möglich): externer ISB (GEFIM-Modell), Vier-Augen mit der Leitung, dokumentierte Ausnahmegenehmigung + verstärkte Protokollierung. Der Wizard bietet bei Konflikt „Trennung herstellen" **oder** „kompensierende Kontrolle dokumentieren" (→ Aufgabe bzw. Nachweis).
+
+## 3. Bestellungs-/Ernennungs-Vorlage (Paket-Stil)
+
+Neue Vorlage `VA-00_ISB-Bestellung.md` bzw. Textbaustein in `R01`, mit Platzhaltern und Ankern:
+
+```markdown
+# Bestellung Informationssicherheitsbeauftragte(r)
+
+| Feld | Wert |
+|------|------|
+| Organisation | {{ORG_NAME}} |
+| Bestellte Person / Funktion | {{ROLE_ISB}} |
+| Bestellt durch | {{ROLE_MANAGEMENT}} |
+| Besetzung | {{#if FLAG_ISB_EXTERNAL}}extern (Dienstleistervertrag){{/if}}{{#if FLAG_ISB_INTERNAL}}intern{{/if}} |
+| Version / Datum / Status | {{DOC_VERSION}} / {{DOC_DATE}} / {{DOC_STATUS}} |
+
+<!-- REQ 1.2.2-M1 -->
+Die Organisation {{ORG_NAME}} bestellt {{ROLE_ISB}} mit Wirkung zum {{DOC_DATE}} zum/zur Informationssicherheitsbeauftragten.
+
+## Aufgaben und Befugnisse
+- Aufbau, Pflege und Weiterentwicklung des ISMS gemäß VDA ISA.
+- Beratung der Leitung; jährliche Überprüfung von Richtlinien und Wirksamkeit.
+- Koordination von Risikomanagement, Schulungen, Audits, Maßnahmen.
+- Melde-/Eskalationsrecht direkt an {{ROLE_MANAGEMENT}}; Zugang zu relevanten Informationen/Systemen.
+
+## Freigabe
+| Rolle | Name | Datum, Unterschrift |
+|-------|------|---------------------|
+| Leitung | {{ROLE_MANAGEMENT}} | |
+| ISB | {{ROLE_ISB}} | |
+```
+
+Neue Flags bei Bedarf in `variables.schema.json`: `FLAG_ISB_EXTERNAL` / `FLAG_ISB_INTERNAL` (aus Q-ROLE-02). Nach Anlage `_verify.py` → **OK**.

docs/wizard-uebergabe/02_Fachcontent_C1-C9/C8_Priorisierung-Gap.md

@@ -0,0 +1,37 @@
+# C8 — Priorisierungslogik Gap + Quick-Wins
+
+> **Schaltet frei:** A8 (Gap-Konsolidierung, Schritt 8). **Grundlage:** Ergebnisse aus Schritt 6 (Risiko) und 7 (Control-Assessment), Aufgaben-Modul.
+
+## 1. Prioritätsregeln (deterministisch)
+
+Priorität eines offenen Punkts = höchste zutreffende Regel:
+
+| Priorität | Bedingung |
+|---|---|
+| **Hoch** | Offene **MUSS**-Anforderung (Reifegrad < 2) · **oder** offene AL3-Zusatzanforderung (`HOCH`/`SEHR HOCH`) bei entsprechendem Schutzbedarf · **oder** Behandlungsmaßnahme zu einem Risiko oberhalb der Akzeptanzlinie · **oder** fehlende Muss-Rolle/Funktionstrennungs-Konflikt (C7 FT-01/03/04) |
+| **Mittel** | Offene **SOLL**-Anforderung · Reifegrad = 2 aber unter Zielreifegrad 3 · Nachweis vorhanden aber nicht validiert · Dokument im Entwurf/nur als Vorlage |
+| **Niedrig** | Redaktioneller/formaler Punkt · Optimierung ohne Reifegrad-Wirkung · Nachweis nur zu aktualisieren |
+
+Zusatzgewichtung (Sortierung innerhalb gleicher Priorität): (1) Anzahl betroffener Controls, (2) Risikohöhe des verknüpften Risikos, (3) Aufwand aufsteigend (Quick-Wins zuerst).
+
+## 2. Deduplizierung
+
+Offene Punkte aus Schritt 6 und 7 werden zusammengeführt. Dedup-Schlüssel = (Control + Teilanforderungs-ID) bzw. (verknüpfte Maßnahme/Aufgabe). Regeln:
+
+- Gleiche Teilanforderung aus mehreren Quellen → **ein** Punkt, höchste Priorität gewinnt, Quellen werden verknüpft.
+- Ein offener Punkt, für den bereits eine Aufgabe existiert → keine neue Aufgabe, bestehende verknüpfen.
+- Risiko-Maßnahme und Control-Gap, die dieselbe Maßnahme adressieren (z. B. „Patchmanagement einführen" für Risiko R-OPS-03 und Controls 5.2.3/5.2.5) → zusammenführen, alle Bezüge an die eine Aufgabe hängen.
+
+## 3. Quick-Wins
+
+Ein offener Punkt ist **Quick-Win**, wenn: geringer Aufwand (organisatorisch/redaktionell, kein Tool-/Budgetbedarf) **und** Reifegrad-Wirkung ≥ +1 auf mindestens ein Control **und** keine Abhängigkeit von anderer offener Maßnahme. Typische Quick-Wins: Freigabe/Validierung eines bereits erstellten Dokuments, Befüllen einer vorhandenen Vorlage (Konten-Review, Rezertifizierung), Rollen-/Funktionstrennungs-Dokumentation, Redaktionslücken schließen. Der Wizard hebt Quick-Wins im Maßnahmenplan gesondert hervor (Reihenfolge-Empfehlung „erst Quick-Wins, dann Hoch-Aufwand").
+
+## 4. Beispiel-Priorisierung
+
+| Offener Punkt | Regel | Priorität | Quick-Win? |
+|---|---|---|---|
+| Kein Patchmanagement (Controls 5.2.3/5.2.5, Risiko R-OPS-03) | MUSS < 2 + Risiko | Hoch | nein (Tool) |
+| Restore-Test nicht durchgeführt (5.2.9, BL-OPS-06) | MUSS-Nachweis fehlt | Hoch | ja (organisatorisch) |
+| ISB = IT-Verantwortung (FT-01) | Funktionstrennungs-Konflikt | Hoch | teils (extern/kompensieren) |
+| SOLL Berechtigungs-Review nur als Vorlage (4.2.1) | SOLL, nicht validiert | Mittel | ja |
+| Zonenbezeichnung inkonsistent (3.1.1) | redaktionell | Niedrig | ja |

docs/wizard-uebergabe/02_Fachcontent_C1-C9/C9_Auswertung-Export.md

@@ -0,0 +1,49 @@
+# C9 — Auswertungs-/Interpretationstexte + Export-Layout
+
+> **Schaltet frei:** B7 (Assessment-Readiness & Export, Schritt 9). **Grundlage:** validierte Control-Bewertungen (Schritt 7), Gap-/Maßnahmenliste (Schritt 8), Validierungsstatus (A3).
+
+## 1. Reifegrad-Dashboard — Interpretationstexte
+
+Aggregation je Kapitel und gesamt (Durchschnitt der Control-Reifegrade, „unbestätigt" zählt nicht als erfüllt). Textbänder nach Gesamtreifegrad:
+
+| Reifegrad (Ø) | Band | Interpretationstext |
+|---|---|---|
+| < 1,5 | Aufbau | „Das ISMS befindet sich im Aufbau. Wesentliche Richtlinien/Verfahren sind noch zu erstellen oder freizugeben. Fokus: Muss-Anforderungen und Grundstruktur." |
+| 1,5 – < 2,5 | Etabliert im Aufbau | „Grundlegende Prozesse sind vorhanden und teils dokumentiert. Für Assessment-Reife fehlen v. a. Nachweise der gelebten Anwendung und Validierungen." |
+| 2,5 – < 3,0 | Assessment-nah | „Das ISMS ist überwiegend etabliert. Wenige offene Punkte und Nachweise trennen von der Assessment-Reife (AL-Ziel). Fokus: Hoch-Punkte schließen, Wirksamkeitsnachweise ergänzen." |
+| = 3,0 | Assessment-reif | „Die bewerteten Controls erfüllen den Zielreifegrad. Empfehlung: Stichprobenvalidierung und Aktualität der Nachweise vor dem Assessment sicherstellen." |
+
+Zusätzliche Kennzahlen: Anteil bestätigter (validierter) Controls, Anzahl offener Punkte je Priorität, Abdeckung je Prüfziel, „höchstes erreichbares Ergebnis" = Zielreifegrad.
+
+## 2. Empfohlene nächste Schritte (dynamisch)
+
+Regelbasiert eingeblendet:
+
+- Offene **Hoch**-Punkte vorhanden → „Vor dem Assessment zwingend: die N Hoch-Punkte im Maßnahmenplan abarbeiten (siehe Aufgaben)."
+- Unvalidierte Objekte vorhanden → „X Objekte warten auf Validierung durch ISB/Berater — bis dahin als ‚unbestätigt' gewertet."
+- Prüfziel Prototypenschutz aktiv & 8.x < Ziel → „Prototypenspezifische Nachweise ergänzen (physische Schutzmaßnahmen, Zutritt, Transport)."
+- Nachweis-Upload-Iteration noch offen → „Operative Nachweise (Screenshots/Protokolle) in der Folgeiteration hochladen."
+
+## 3. VDA-ISA-Katalog-Export — Layout
+
+**Struktur (je Prüfziel ein Tabellenblatt/Abschnitt, Reihenfolge Informationssicherheit → Prototypenschutz → Datenschutz):**
+
+| Feld | Inhalt | Quelle |
+|---|---|---|
+| Control-ID | z. B. 4.1.2 | Katalog |
+| Kontrollfrage / Ziel | aus Katalog | Katalog |
+| Reifegrad | 0–3 (bestätigt) bzw. „na" | Schritt 7 |
+| Status | bestätigt / unbestätigt | A3-Validierung |
+| Umsetzungsbeschreibung | je Teilanforderung: **Anforderung (fett)** + Umsetzung (normal), Reihenfolge MUSS→SOLL→HOCH→SEHR HOCH | Schritt 7 + Vorlagen-IMPL |
+| Belege | verknüpfte Dokumente/Verfahren/Risiken/Assets | Schritt 4–7 |
+| Offene Punkte | je Control aus Gap-Liste | Schritt 8 |
+
+**Darstellungsregeln:** Anforderungstext im Originalwortlaut, **fett**; Umsetzung normal darunter mit Quellenangabe (Dokument, Version/Stand, Kapitel) — konsistent zur bisherigen Ausarbeitung. „Unbestätigt" sichtbar markieren (z. B. Kennzeichnung/Farbe). Ergänzungshinweise/offene Punkte **nicht** im Katalog, sondern in der separaten Maßnahmen-/Schwachstellenliste.
+
+**Exportformate:** XLSX (VDA-ISA-Katalogsicht + Ergebnisblatt mit Reifegrad-Kennzahlen), zusätzlich DOCX/PDF für Management-Zusammenfassung. Der Export koppelt an den bestehenden DOCX/PDF-Export der App.
+
+## 4. Zusatzartefakte im Export
+
+- **Maßnahmenplan** (aus C8): priorisierte offene Punkte + verknüpfte Aufgaben, Quick-Wins hervorgehoben.
+- **Nachweisregister** (aus `Nachweisregister_zentral.md`): je Anforderung der zugeordnete Nachweis/Status.
+- **Management-Zusammenfassung**: Stärken, Reifegrad-Überblick, Hoch-Punkte, empfohlene Schritte vor dem Assessment.