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/verfahren/VA-01_Incident-Response-und-Meldeverfahren.md

@@ -33,7 +33,7 @@ Meldung eines Sicherheitsereignisses (Mitarbeitende, Technik/Monitoring, Externe
 
 ## 5. Ablauf
 
-1. Ereignis melden: Meldung über {{TOOL_TICKET}} bzw. E-Mail an {{ROLE_ISB}} erfassen.
+1. Ereignis melden: Meldung über das {{TOOL_TICKET}} bzw. E-Mail an {{ROLE_ISB}} erfassen.
 2. Triage & Klassifizierung: Relevanz, Schweregrad und Kategorie festlegen.
 3. Eindämmung: Sofortmaßnahmen zur Begrenzung des Schadens einleiten.
 4. Behebung & Wiederherstellung: Ursache beseitigen, Normalbetrieb herstellen.

seed/isms-vorlagenpaket-v2/verfahren/VA-03_Berechtigungsverfahren.md

@@ -29,13 +29,13 @@ Eintritt, Rollenwechsel oder Austritt einer Person; Berechtigungsantrag; fällig
 
 - Personalmeldung (HR)
 - Rollen-/Rechtekatalog (RBAC)
-- Bestehende Berechtigungen aus {{TOOL_IAM}}
+- Bestehende Berechtigungen aus dem zentralen Verzeichnis ({{TOOL_IAM}})
 
 ## 5. Ablauf
 
 1. Antrag erfassen: Zugang/Recht im {{TOOL_TICKET}} beantragen (Joiner/Mover).
 2. Fachliche Genehmigung: Erforderlichkeit nach Minimalprinzip prüfen und freigeben.
-3. Umsetzung: Rechte rollenbasiert in {{TOOL_IAM}} setzen.
+3. Umsetzung: Rechte rollenbasiert im zentralen Verzeichnis ({{TOOL_IAM}}) setzen.
 4. Leaver/Änderung: Bei Austritt/Wechsel Rechte unverzüglich entziehen/anpassen.
 5. Rezertifizierung ({{RECERT_FREQ}}, BL-IAM-05): Owner bestätigen/entziehen Rechte.
 6. Privilegierte Konten: gesondert prüfen und protokollieren (BL-IAM-06).
@@ -53,7 +53,7 @@ Eintritt, Rollenwechsel oder Austritt einer Person; Berechtigungsantrag; fällig
 
 ## 7. Ergebnis & Nachweis
 
-Dokumentierte Anträge/Genehmigungen im {{TOOL_TICKET}}; aktueller Berechtigungsstand in {{TOOL_IAM}}; Rezertifizierungsnachweis. Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
+Dokumentierte Anträge/Genehmigungen im {{TOOL_TICKET}}; aktueller Berechtigungsstand im zentralen Verzeichnis ({{TOOL_IAM}}); Rezertifizierungsnachweis. Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
 
 ## 8. Kennzahlen (KPI)
 

seed/isms-vorlagenpaket-v2/verfahren/VA-10_Lieferanten-Onboarding-und-Bewertung.md

@@ -43,8 +43,8 @@ Neuer Lieferant/Dienstleister mit Zugriff auf Informationen; Vertragsverlängeru
 
 | # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
 |---|---------|------------------|------------------|-----------------|----------------|
-| 1 | Bedarf & Risikoklasse bestimmen (Schutzb | Einkauf/Fachbereich | {{ROLE_ISB}} | - | - |
-| 2 | Sicherheitsbewertung (Selbstauskunft/Nac | {{ROLE_ISB}} | {{ROLE_ISB}} | Fachbereich | - |
+| 1 | Bedarf & Risikoklasse bestimmen (Schutzbedarf, Zugriff) | Einkauf/Fachbereich | {{ROLE_ISB}} | - | - |
+| 2 | Sicherheitsbewertung (Selbstauskunft/Nachweise/TISAX) | {{ROLE_ISB}} | {{ROLE_ISB}} | Fachbereich | - |
 | 3 | NDA & vertragliche Sicherheitsanforderun | Einkauf | {{ROLE_MANAGEMENT}} | {{ROLE_ISB}} | - |
 | 4 | Verantwortlichkeiten abgrenzen (Betrieb/ | {{ROLE_ISB}} | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | - |
 | 5 | Ins Lieferantenverzeichnis ({{TOOL_NAME}}) | {{ROLE_ISB}} | {{ROLE_ISB}} | - | - |

seed/isms-vorlagenpaket-v2/verfahren/VA-16_Sichere-Beschaffung-Entwicklung-und-Abnahme.md

@@ -35,7 +35,7 @@ Beschaffung, Neu-/Weiterentwicklung oder wesentliche Änderung eines IT-Dienstes
 
 1. Sicherheitsanforderungen spezifizieren (Security by Design) und den Schutzbedarf berücksichtigen.
 2. Beschaffung/Änderung anhand der Sicherheitskriterien durchführen.{{#if FLAG_EXTERNAL_IT}} Externe/Cloud-Dienste werden über {{LINK:VA-11}} bewertet und im {{LINK:REG-EXT-SERVICES}} geführt.{{/if}}
-3. Abnahmetests unter Sicherheitsaspekten vor der Produktivsetzung; Freigabe in {{TOOL_TICKET}} (Change-Kopplung {{LINK:VA-04}}).
+3. Abnahmetests unter Sicherheitsaspekten vor der Produktivsetzung; Freigabe im {{TOOL_TICKET}} (Change-Kopplung {{LINK:VA-04}}).
 4. Produktivdaten in Tests vermeiden bzw. anonymisieren; Testsysteme angemessen schützen.
 5. {{#if FLAG_DEV_INHOUSE}} Für die Eigenentwicklung gelten Secure-Coding-Vorgaben mit Code-Reviews und automatisierten Sicherheitstests (SAST/Dependency-Scan).{{/if}}
 6. {{#if FLAG_VERY_HIGH_PROTECTION}} Bei sehr hohem Schutzbedarf erfolgt vor Freigabe eine zusätzliche unabhängige Sicherheitsprüfung/Abnahme.{{/if}}
@@ -53,7 +53,7 @@ Beschaffung, Neu-/Weiterentwicklung oder wesentliche Änderung eines IT-Dienstes
 
 ## 7. Ergebnis & Nachweis
 
-Abnahmeprotokolle, Testberichte und Freigaben (in {{TOOL_TICKET}}). Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
+Abnahmeprotokolle, Testberichte und Freigaben (im {{TOOL_TICKET}}). Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
 
 ## 8. Kennzahlen (KPI)
 

seed/isms-vorlagenpaket-v2/verfahren/VA-17_Zutritts-und-Besuchermanagement.md

@@ -33,7 +33,7 @@ Eintritt/Austritt/Rollenwechsel, Besuch, Änderung des Zonenkonzepts, regelmäß
 
 ## 5. Ablauf
 
-1. Zutrittsrechte zu Sicherheitszonen werden über {{TOOL_TICKET}} beantragt, genehmigt und entzogen (Prinzip minimaler Rechte).
+1. Zutrittsrechte zu Sicherheitszonen werden über das {{TOOL_TICKET}} beantragt, genehmigt und entzogen (Prinzip minimaler Rechte).
 2. Besucher werden registriert, ausgewiesen und in schützenswerten Zonen begleitet.
 3. Betriebsmittel, Schlüssel und Ausweise werden ausgegeben, zurückgenommen und dokumentiert.
 4. Zutrittsberechtigungen werden regelmäßig überprüft ({{REVIEW_CYCLE}}) und bei Austritt/Wechsel unverzüglich angepasst.

seed/isms-vorlagenpaket-v2/verfahren/VA-19_Informationssicherheit-in-Projekten.md

@@ -35,7 +35,7 @@ Projektstart, wesentliche Projektänderung, Projektabschluss.
 
 1. Projekt zu Beginn anhand des **dokumentierten Kriterienkatalogs (BL-PROJ-01)** hinsichtlich Informationssicherheitsbedarf klassifizieren; Eintrag im **Projektregister ({{LINK:REG-PROJECTS}})**.
 2. In einer frühen Projektphase und bei Änderungen eine Risikobewertung durchführen (Kopplung Risikomanagement {{LINK:VA-09}}).
-3. Maßnahmen ableiten und als Aufgaben in {{TOOL_TICKET}} nachhalten.
+3. Maßnahmen ableiten und als Aufgaben im {{TOOL_TICKET}} nachhalten.
 4. {{#if FLAG_ELEVATED_PROTECTION}} Bei erhöhtem Schutzbedarf wird {{ROLE_ISB}} eingebunden; zusätzliche Prüfungen/Freigaben erfolgen vor kritischen Meilensteinen.{{/if}}
 5. Vor Projektabschluss die Umsetzung der Maßnahmen prüfen und im Projektregister dokumentieren.