GAP WP1: Neue VAs 14–19 integriert + Register + Baseline + Eltern-Wiring

ISB-Volltexte der sechs neuen Verfahrensanweisungen eingepflegt (VA-14..VA-19)
und die im GAP-Report identifizierten Inhalts-GAPs geschlossen.

- 6 neue VAs unter verfahren/ (VA-14 Personalsicherheit, VA-15 Interne Audits,
  VA-16 Sichere Beschaffung/Entwicklung, VA-17 Zutritts-/Besuchermanagement,
  VA-18 Datenschutz-Pflege, VA-19 Informationssicherheit in Projekten) mit
  FULFILLS-Headern; mapping.json: verfahren[] + Reverse-Links (anforderungen[].verfahren).
- 4 referenzierte Register als Dokumente (import-managed.ts): REG-PROJECTS,
  REG-SENS-ROLES, REG-AUDIT-PLAN, REG-EXT-SERVICES (Pflichtspalten dokumentiert;
  editierbares Datenmodell = offenes WP3.0).
- Baseline: BL-GOV-01 (Audit-/Prüfzyklus) und BL-PROJ-01 (Projekt-Kriterien).
- Eltern-Richtlinien verdrahtet (IMPL-Ersatztexte aus Report §8): R01 1.2.3 (A-N1,
  löst „bzw. ISMS-Tool" auf), R05 2.1.1 (A-G-B1) + 2.1.2 (N2→VA-14), R03 1.5.1
  (A-F12→VA-15), R11 5.3.1 (A-F13→VA-16), R07 3.1.1 (N3→VA-17), R14 7.1.2 (A-N8→VA-18).

Verifiziert: _verify.py Render 0 / Mapping sauber (nur vorbestehendes IMPL 3.1.3);
Re-Import in Demo → 10 neue Dokumente, Coverage-Gaps geschlossen (1.2.3→VA-19,
2.1.1→VA-14, 1.5.1→VA-15, 5.3.1→VA-16, 3.1.1→VA-17, 7.1.2→VA-18); Browser: R01
rendert klickbare Deep-Links auf VA-19 und REG-PROJECTS. tsc grün.

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

seed/isms-vorlagenpaket-v2/richtlinien/R01_ISMS-Organisation-und-Rollen.md

@@ -107,7 +107,7 @@ Bei hohem Schutzbedarf ist eine organisatorische Funktionstrennung (z. B. Umsetz
 **Umsetzung bei {{ORG_NAME}}**
 
 <!-- IMPL 1.2.3 -->
-Projekte werden zu Beginn anhand eines dokumentierten Kriterienkatalogs hinsichtlich Informationssicherheitsbedarf klassifiziert; die Einstufung wird im {{TOOL_TICKET}} bzw. ISMS-Tool dokumentiert. In einer frühen Phase und bei Änderungen erfolgt eine Risikobewertung; abgeleitete Maßnahmen werden als Aufgaben im {{TOOL_TICKET}} nachgehalten und vor Projektabschluss geprüft; bei erhöhtem Schutzbedarf wird {{ROLE_ISB}} eingebunden.
+Projekte werden zu Beginn anhand des dokumentierten Kriterienkatalogs (BL-PROJ-01) hinsichtlich Informationssicherheitsbedarf klassifiziert; Einstufung, Risikobewertung und abgeleitete Maßnahmen werden im Projektregister ({{LINK:REG-PROJECTS}}) geführt. In einer frühen Projektphase und bei Änderungen erfolgt eine Risikobewertung nach dem Verfahren Informationssicherheit in Projekten ({{LINK:VA-19}}); Maßnahmen werden als Aufgaben in {{TOOL_TICKET}} nachgehalten und vor Projektabschluss geprüft. Verantwortlich ist die Projektleitung; bei erhöhtem Schutzbedarf wird {{ROLE_ISB}} eingebunden.
 
 {{#if FLAG_ELEVATED_PROTECTION}}
 <!-- IMPL 1.2.3-elev -->

seed/isms-vorlagenpaket-v2/richtlinien/R03_Risikomanagement-und-Auditrichtlinie.md

@@ -80,7 +80,7 @@ Das dokumentierte Risikomanagement-Verfahren (siehe {{LINK:VA-09}}) mit Bewertun
 **Umsetzung bei {{ORG_NAME}}**
 
 <!-- IMPL 1.5.1 -->
-Die Einhaltung von Richtlinien, Verfahren und technischen Anforderungen wird organisationsweit nach einem Auditplan durch interne Audits und Kontrollen regelmäßig überprüft; Ergebnisse werden aufgezeichnet und aufbewahrt, Abweichungen als Maßnahmen im ISMS-Tool nachverfolgt.
+Die Einhaltung von Richtlinien, Verfahren und technischen Anforderungen wird organisationsweit nach dem Audit-Programm ({{LINK:REG-AUDIT-PLAN}}) und dem Audit-/Complianceprüfungs-Verfahren ({{LINK:VA-15}}) durch interne Audits und Kontrollen regelmäßig überprüft (Turnus BL-GOV-01); Ergebnisse werden aufgezeichnet und aufbewahrt, Abweichungen als Maßnahmen im {{TOOL_NAME}} nachverfolgt; Verantwortlich: {{ROLE_ISB}}.
 
 ### 3.3 Unabhängige Überprüfung des ISMS (ISA 1.5.2)
 

seed/isms-vorlagenpaket-v2/richtlinien/R05_Personalsicherheit-und-Awareness.md

@@ -46,7 +46,7 @@ Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SC
 **Umsetzung bei {{ORG_NAME}}**
 
 <!-- IMPL 2.1.1 -->
-Sensible Tätigkeiten sind bestimmt; Anforderungen an Positionen sind in Stellenbeschreibungen hinterlegt und werden erfüllt. Die Identität wird bei Einstellung verifiziert; die persönliche Eignung wird im rechtlich zulässigen Rahmen geprüft (Gespräch, bei sensiblen Rollen erweiterte Prüfungen wie Referenzen/Führungszeugnis).
+Sensible Arbeitsbereiche und Tätigkeiten sind im Register sensibler Tätigkeiten ({{LINK:REG-SENS-ROLES}}) bestimmt und mit der geforderten Prüftiefe hinterlegt; Anforderungen an Positionen sind in Stellenbeschreibungen dokumentiert und werden erfüllt. Identitätsverifizierung sowie die persönliche und – bei sensiblen Rollen – erweiterte Eignungsprüfung (Gespräch, Referenzen, Führungszeugnis im rechtlich zulässigen Rahmen) erfolgen nach dem Eignungs- und Verifizierungsverfahren ({{LINK:VA-14}}); Verantwortlich: {{ROLE_HR_LEAD}}; Nachweis in der Personalakte.
 
 ### 3.2 Vertragliche Verpflichtung des Personals (ISA 2.1.2)
 
@@ -72,7 +72,7 @@ Sensible Tätigkeiten sind bestimmt; Anforderungen an Positionen sind in Stellen
 **Umsetzung bei {{ORG_NAME}}**
 
 <!-- IMPL 2.1.2 -->
-Alle Beschäftigten werden bei Eintritt vertraglich zur Vertraulichkeit und zur Einhaltung der Informationssicherheitsrichtlinien verpflichtet ({{ROLE_HR_LEAD}}); Informationssicherheitsaspekte sind Bestandteil der Arbeitsverträge, die Vertraulichkeit gilt nachvertraglich fort. Ein Verfahren zum Umgang mit Verstößen ist beschrieben; der Nachweis wird in der Personalakte geführt.
+Alle Beschäftigten werden bei Eintritt vertraglich zur Vertraulichkeit und zur Einhaltung der Informationssicherheitsrichtlinien verpflichtet ({{ROLE_HR_LEAD}}); Informationssicherheitsaspekte sind Bestandteil der Arbeitsverträge, die Vertraulichkeit gilt nachvertraglich fort. Ein dokumentiertes Verfahren zum Umgang mit Verstößen (siehe {{LINK:VA-14}}) ist etabliert; der Nachweis wird in der Personalakte geführt.
 
 ### 3.3 Sensibilisierung und Schulung (ISA 2.1.3)
 

seed/isms-vorlagenpaket-v2/richtlinien/R07_Physische-Sicherheit.md

@@ -62,7 +62,7 @@ Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SC
 **Umsetzung bei {{ORG_NAME}}**
 
 <!-- IMPL 3.1.1 -->
-Ein Sicherheitszonenkonzept (BL-PHY-01) mit umgesetzten Schutzmaßnahmen und bekanntem Verhaltenskodex ist vorhanden; Zutrittsrechte werden über {{TOOL_TICKET}} bedarfsorientiert vergeben, dokumentiert und bei Wegfall entzogen (BL-PHY-02). Besuchermanagement, Regeln für mobile Geräte, Schutz von Netz-/Infrastrukturkomponenten und externe Liegenschaften sind berücksichtigt.
+Ein Sicherheitszonenkonzept (BL-PHY-01) mit umgesetzten Schutzmaßnahmen und bekanntem Verhaltenskodex ist vorhanden; Zutrittsrechte werden über {{TOOL_TICKET}} bedarfsorientiert vergeben, dokumentiert und bei Wegfall entzogen (BL-PHY-02, Ablauf siehe {{LINK:VA-17}}). Besuchermanagement, Regeln für mobile Geräte, Schutz von Netz-/Infrastrukturkomponenten und externe Liegenschaften sind berücksichtigt.
 
 {{#if FLAG_ELEVATED_PROTECTION}}
 <!-- IMPL 3.1.1-elev -->

seed/isms-vorlagenpaket-v2/richtlinien/R11_Sichere-Systembeschaffung-und-Entwicklung.md

@@ -64,7 +64,7 @@ Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SC
 **Umsetzung bei {{ORG_NAME}}**
 
 <!-- IMPL 5.3.1 -->
-Informationssicherheitsanforderungen sind fester Bestandteil von Design, Beschaffung, Erweiterung und Änderung von IT-Diensten (Security by Design); Anforderungsspezifikationen werden erstellt und geprüft, Abnahmetests unter Sicherheitsaspekten durchgeführt, Produktivsetzung erst nach Prüfung im {{TOOL_TICKET}}. Produktivdaten in Tests werden vermieden/anonymisiert, Testsysteme angemessen geschützt.{{#if FLAG_DEV_INHOUSE}} Für die Eigenentwicklung gelten Secure-Coding-Vorgaben mit Code-Reviews und automatisierten Sicherheitstests (SAST/Dependency-Scan).{{/if}}
+Informationssicherheitsanforderungen sind fester Bestandteil von Design, Beschaffung, Erweiterung und Änderung von IT-Diensten (Security by Design); Anforderungsspezifikation, Prüfung und Abnahmetests unter Sicherheitsaspekten erfolgen nach dem Verfahren Sichere Beschaffung/Entwicklung & Abnahme ({{LINK:VA-16}}); Produktivsetzung erst nach Prüfung in {{TOOL_TICKET}}. Produktivdaten in Tests werden vermieden/anonymisiert, Testsysteme angemessen geschützt.{{#if FLAG_DEV_INHOUSE}} Für die Eigenentwicklung gelten Secure-Coding-Vorgaben mit Code-Reviews und automatisierten Sicherheitstests (SAST/Dependency-Scan) gemäß {{LINK:VA-16}}.{{/if}}
 
 {{#if FLAG_ELEVATED_PROTECTION}}
 <!-- IMPL 5.3.1-elev -->

seed/isms-vorlagenpaket-v2/richtlinien/R14_Compliance-und-Datenschutz.md

@@ -57,7 +57,7 @@ Relevante rechtliche, regulatorische und vertragliche Anforderungen werden regel
 **Umsetzung bei {{ORG_NAME}}**
 
 <!-- IMPL 7.1.2 -->
-Rechtliche und vertragliche Anforderungen an die Verarbeitung personenbezogener Daten (DSGVO) sind bestimmt; Regelungen sind definiert, den Beteiligten bekannt und im ISMS berücksichtigt. {{ROLE_DPO}} ist eingebunden, das Verzeichnis der Verarbeitungstätigkeiten wird im ISMS-Tool ({{TOOL_NAME}}) geführt, TOM und Löschkonzepte (BL-DEL-01) sind geregelt.
+Rechtliche und vertragliche Anforderungen an die Verarbeitung personenbezogener Daten (DSGVO) sind bestimmt; Regelungen sind definiert, den Beteiligten bekannt und im ISMS berücksichtigt. {{ROLE_DPO}} ist eingebunden, das Verzeichnis der Verarbeitungstätigkeiten wird im ISMS-Tool ({{TOOL_NAME}}) geführt, TOM und Löschkonzepte (BL-DEL-01) sind geregelt; Rechtsregister-Review, Löschfristen und Betroffenenrechte werden nach dem Datenschutz-/Compliance-Pflegeverfahren ({{LINK:VA-18}}) bearbeitet.
 
 {{/if}}
 ## 4. Verbindlichkeit