GAP WP2.2 (Rendering Variante B) + WP4 (Feinschliff)

WP2.2 — Rendering-Doppelartikel (Variante B, Report §6):
- Variablen-Defaults ohne führenden Artikel: TOOL_TICKET „Ticketsystem",
  TOOL_NAME „ISMS-Tool", TOOL_IAM „Entra ID / Active Directory".
- Fließtext angepasst: „im/in {{VAR}}" rendert nun korrekt („im Ticketsystem");
  „über {{TOOL_TICKET}}" → „über das {{TOOL_TICKET}}"; TOOL_IAM (Adjektiv) mit
  korrekter Deklination ausgeschrieben („über das zentrale Verzeichnis (…)",
  „im zentralen Verzeichnis (…)"). Doppeldeutige Orte „bzw. ISMS-Tool" bereits in WP1 aufgelöst.
- Wert-Migration (Prisma-Migration, idempotent): strippt den führenden Artikel aus
  bestehenden, nicht angepassten Variablenwerten — auch für Bestandsmandanten/Deploy.

WP4 — Feinschliff:
- F16 (R06 2.1.4): „mobiles Arbeiten" konkret verortet (Regelung, hinterlegt im ISMS-Tool).
- F21 (VA-10): abgeschnittene RACI-Spaltentexte vervollständigt.
- F18: 13 SEHR-HOCH-Sätze in den -elev-Blöcken in {{#if FLAG_VERY_HIGH_PROTECTION}}
  ausgelagert → bei AL2 kein „Bei sehr hohem Schutzbedarf …" mehr.

Verifiziert: _verify.py Render 0 / Mapping sauber; Render-Gegenprobe mit echten
Defaults ohne „im das …"; AL2/AL3-Flag-Gegenprobe rückstandsfrei (SEHR-HOCH nur bei AL3);
Browser: R08 rendert „im Ticketsystem" und „über das zentrale Verzeichnis (Entra ID / Active Directory)".

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

seed/isms-vorlagenpaket-v2/richtlinien/R04_Incident-Notfall-und-Kontinuitaetsrichtlinie.md

@@ -70,7 +70,7 @@ Eine bekannte Definition meldepflichtiger Ereignisse und ein niedrigschwelliger
 
 {{#if FLAG_ELEVATED_PROTECTION}}
 <!-- IMPL 1.6.1-elev -->
-Bei sehr hohem Schutzbedarf werden Tests und Übungen der Ereignismeldung regelmäßig durchgeführt.
+{{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf werden Tests und Übungen der Ereignismeldung regelmäßig durchgeführt.{{/if}}
 {{/if}}
 
 ### 3.2 Behandlung von Sicherheitsereignissen (ISA 1.6.2)
@@ -127,7 +127,7 @@ Ereignisse werden ohne Verzögerung nach einem definierten Incident-Verfahren (s
 
 {{#if FLAG_ELEVATED_PROTECTION}}
 <!-- IMPL 1.6.2-elev -->
-Bei hohem Schutzbedarf sind maximale Reaktionszeiten je Schwere definiert, Eskalationen für nicht prioritätsgerecht bearbeitete Ereignisse geregelt, Meldepflichten und Kontakte bekannt, eine Kommunikationsstrategie sowie ein Verfahren für Lieferantenvorfälle etabliert. Bei sehr hohem Schutzbedarf wird die Ereignisbehandlung regelmäßig getestet.
+Bei hohem Schutzbedarf sind maximale Reaktionszeiten je Schwere definiert, Eskalationen für nicht prioritätsgerecht bearbeitete Ereignisse geregelt, Meldepflichten und Kontakte bekannt, eine Kommunikationsstrategie sowie ein Verfahren für Lieferantenvorfälle etabliert. {{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf wird die Ereignisbehandlung regelmäßig getestet.{{/if}}
 {{/if}}
 
 ### 3.3 Krisenmanagement (ISA 1.6.3)
@@ -196,7 +196,7 @@ Ein Krisenmanagement mit Plan, definiertem und genehmigtem Krisenstab, Rollen, A
 
 {{#if FLAG_ELEVATED_PROTECTION}}
 <!-- IMPL 1.6.3-elev -->
-Bei hohem Schutzbedarf sind relevante Krisenszenarien identifiziert, notwendige Ressourcen/Informationen und eine Kommunikationsstrategie sichergestellt, die Planung wird regelmäßig bewertet und stichprobenartig getestet (Tabletop). Bei sehr hohem Schutzbedarf werden regelmäßig Krisenübungen mit allen relevanten Personen inkl. Entscheidungsträgern durchgeführt.
+Bei hohem Schutzbedarf sind relevante Krisenszenarien identifiziert, notwendige Ressourcen/Informationen und eine Kommunikationsstrategie sichergestellt, die Planung wird regelmäßig bewertet und stichprobenartig getestet (Tabletop). {{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf werden regelmäßig Krisenübungen mit allen relevanten Personen inkl. Entscheidungsträgern durchgeführt.{{/if}}
 {{/if}}
 
 ### 3.4 Kontinuitätsplanung für IT-Dienste (ISA 5.2.8)
@@ -267,7 +267,7 @@ Kritische IT-Dienste sind mit Geschäftsauswirkung identifiziert; Anforderungen
 
 {{#if FLAG_ELEVATED_PROTECTION}}
 <!-- IMPL 5.2.8-elev -->
-Bei hohem Schutzbedarf sind RTO/RPO, SLAs mit Dienstleistern, Partnerkommunikation, regelmäßige Volltests sowie eine geschützte Backup-/Recovery-Strategie (immutable/isoliert) etabliert. Bei sehr hohem Schutzbedarf ist die Planung mit externen Dienstleistern abgestimmt, die Fortführung wesentlicher Funktionen sichergestellt und Tests inkl. Lessons Learned werden aufgezeichnet.
+Bei hohem Schutzbedarf sind RTO/RPO, SLAs mit Dienstleistern, Partnerkommunikation, regelmäßige Volltests sowie eine geschützte Backup-/Recovery-Strategie (immutable/isoliert) etabliert. {{#if FLAG_VERY_HIGH_PROTECTION}}Bei sehr hohem Schutzbedarf ist die Planung mit externen Dienstleistern abgestimmt, die Fortführung wesentlicher Funktionen sichergestellt und Tests inkl. Lessons Learned werden aufgezeichnet.{{/if}}
 {{/if}}
 
 ## 4. Verbindlichkeit