GAP WP2.1: Inline-VA-Verweise + Verify-Fix (F17)

Umsetzung aus dem GAP-Report Runde 2 (Umsetzungsanleitung), Etappe 1. - WP2.1 (F3–F9, F19, N4, N7, N9): In 14 IMPL-Blöcken den zuständigen VA-Verweis inline ergänzt ({{LINK:VA-xx}}) — R02 1.3.1/1.3.2→VA-08, R03 1.4.1→VA-09, R04 1.6.1/1.6.2→VA-01 & 1.6.3→VA-02, R05 2.1.3→VA-12, R08 4.1.1/4.1.3/4.2.1→VA-03, R09 5.1.2→VA-07, R10 5.2.1→VA-04 & 5.2.6→VA-06, R13 6.1.2/6.1.3→VA-10. Damit verweisen alle 23 Controls mit zuständiger VA inline (zuvor 8). - WP2.3/F17: _verify.py lief nicht (KeyError 'implementation' — Feld existiert nicht in mapping.json). Gefixt via .get(): Umsetzungstext wird zur Laufzeit über impl_anchor aus der .md aufgelöst (Variante 2 der Anleitung). Verifiziert: _verify.py Render-Probleme 0, Mapping beidseitig sauber, keine neuen Befunde (einzig vorbestehendes IMPL 3.1.3 = WP1.3/E2, ISB-Scope). Nicht-destruktiver Re-Import in den Demo-Mandanten (8 Dokumente aktualisiert, Status/Anforderungen erhalten); Browser: R02 rendert „(siehe VA-08)" als klickbaren Deep-Link. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-22 20:19:05 +02:00
parent 742277f4b4
commit 522508aaf3
10 changed files with 341 additions and 16 deletions
@@ -43,7 +43,9 @@ for fp in glob.glob(os.path.join(BASE,"richtlinien/*.md")):
    for m in re.findall(r"<!-- (REQ|IMPL) ([0-9.\-A-Za-z]+) -->",open(fp,encoding="utf-8").read()): fa.add(m[0]+" "+m[1])
 ma=set()
 for a in d["anforderungen"]: ma.add(a["req_anchor"]); ma.add(a["impl_anchor"])
-leftover_hb=any("{{" in a["requirement"] or "{{" in a["implementation"] for a in d["anforderungen"])
+# F17: mapping.json enthaelt kein 'implementation'-Feld; der Umsetzungstext wird zur
+# Laufzeit ueber impl_anchor (Control-IMPL-Block) aus der jeweiligen .md aufgeloest.
+leftover_hb=any("{{" in a["requirement"] or "{{" in a.get("implementation","") for a in d["anforderungen"])
 print("Render-Probleme:",problems)
 print("mapping-Anker ohne Datei:",sorted(ma-fa))
 print("Datei-Anker ohne mapping:",sorted(fa-ma))
@@ -40,7 +40,7 @@ Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SC
 **Umsetzung bei {{ORG_NAME}}**

 <!-- IMPL 1.3.1 -->
-Informationswerte und unterstützende Assets werden im ISMS-Tool ({{TOOL_NAME}}) im Asset-Inventar mit Attributen (Owner, Standort, Schutzbedarf) erfasst und als Katalog gepflegt; Zu-/Abgänge werden über {{TOOL_TICKET}} ausgelöst.
+Informationswerte und unterstützende Assets werden im ISMS-Tool ({{TOOL_NAME}}) im Asset-Inventar mit Attributen (Owner, Standort, Schutzbedarf) erfasst und als Katalog gepflegt (siehe {{LINK:VA-08}}); Zu-/Abgänge werden über {{TOOL_TICKET}} ausgelöst.

 ### 3.2 Klassifizierung von Informationswerten (ISA 1.3.2)

@@ -60,7 +60,7 @@ Informationswerte und unterstützende Assets werden im ISMS-Tool ({{TOOL_NAME}})
 **Umsetzung bei {{ORG_NAME}}**

 <!-- IMPL 1.3.2 -->
-Es gilt ein konsistentes vierstufiges Klassifizierungsschema (Öffentlich / Intern / Vertraulich / Streng vertraulich) für Vertraulichkeit; die Einstufung erfolgt nach definierten Kriterien durch den Asset Owner im ISMS-Tool und berücksichtigt auch Integrität und Verfügbarkeit. Handhabungsvorgaben je Schutzklasse (Kennzeichnung, Speicherung, Transport, Übertragung BL-CRY-01/04, Löschung BL-DEL-01) sind definiert, umgesetzt und bekannt gemacht.
+Es gilt ein konsistentes vierstufiges Klassifizierungsschema (Öffentlich / Intern / Vertraulich / Streng vertraulich) für Vertraulichkeit; die Einstufung erfolgt nach definierten Kriterien durch den Asset Owner im ISMS-Tool und berücksichtigt auch Integrität und Verfügbarkeit. Handhabungsvorgaben je Schutzklasse (Kennzeichnung, Speicherung, Transport, Übertragung BL-CRY-01/04, Löschung BL-DEL-01) sind definiert, umgesetzt und bekannt gemacht (siehe {{LINK:VA-08}}).

 ### 3.3 Nutzung freigegebener externer IT-Dienste/Hardware (ISA 1.3.3)

@@ -56,7 +56,7 @@ Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SC
 **Umsetzung bei {{ORG_NAME}}**

 <!-- IMPL 1.4.1 -->
-Das dokumentierte Risikomanagement-Verfahren mit Bewertungs- und Akzeptanzkriterien wird im ISMS-Tool ({{TOOL_NAME}}) umgesetzt: Risiken werden regelmäßig ({{REVIEW_CYCLE}}) und anlassbezogen identifiziert, bewertet (Eintritt × Schaden) und dokumentiert; je Risiko sind Risk Owner, Behandlungsoption und Maßnahmen mit Terminen hinterlegt und werden nachverfolgt. Restrisiken akzeptiert die {{ROLE_MANAGEMENT}} dokumentiert.
+Das dokumentierte Risikomanagement-Verfahren (siehe {{LINK:VA-09}}) mit Bewertungs- und Akzeptanzkriterien wird im ISMS-Tool ({{TOOL_NAME}}) umgesetzt: Risiken werden regelmäßig ({{REVIEW_CYCLE}}) und anlassbezogen identifiziert, bewertet (Eintritt × Schaden) und dokumentiert; je Risiko sind Risk Owner, Behandlungsoption und Maßnahmen mit Terminen hinterlegt und werden nachverfolgt. Restrisiken akzeptiert die {{ROLE_MANAGEMENT}} dokumentiert.

 ### 3.2 Prüfung der Einhaltung im IS-Betrieb (ISA 1.5.1)

@@ -66,7 +66,7 @@ Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SC
 **Umsetzung bei {{ORG_NAME}}**

 <!-- IMPL 1.6.1 -->
-Eine bekannte Definition meldepflichtiger Ereignisse und ein niedrigschwelliger Meldeweg (Meldebutton/Formular im {{TOOL_TICKET}} bzw. ISMS-Tool, E-Mail an {{ROLE_ISB}}, für gravierende Fälle Echtzeitkanal) stehen allen Beschäftigten und Externen zur Verfügung; der Meldeweg ist über Onboarding/Awareness (BL-HR-01) bekannt, ein Rückmeldeverfahren ist etabliert.
+Eine bekannte Definition meldepflichtiger Ereignisse und ein niedrigschwelliger Meldeweg (Meldebutton/Formular im {{TOOL_TICKET}} bzw. ISMS-Tool, E-Mail an {{ROLE_ISB}}, für gravierende Fälle Echtzeitkanal) stehen allen Beschäftigten und Externen zur Verfügung; der Meldeweg ist über Onboarding/Awareness (BL-HR-01) bekannt, ein Rückmeldeverfahren ist etabliert (siehe {{LINK:VA-01}}).

 {{#if FLAG_ELEVATED_PROTECTION}}
 <!-- IMPL 1.6.1-elev -->
@@ -123,7 +123,7 @@ Bei sehr hohem Schutzbedarf werden Tests und Übungen der Ereignismeldung regelm
 **Umsetzung bei {{ORG_NAME}}**

 <!-- IMPL 1.6.2 -->
-Ereignisse werden ohne Verzögerung nach einem definierten Incident-Verfahren im {{TOOL_TICKET}} kategorisiert, qualifiziert, priorisiert, behandelt und dokumentiert; Verantwortlichkeiten und Eskalationswege sind zugewiesen ({{ROLE_ISB}} koordiniert, {{ROLE_IT_LEAD}} setzt um). Lessons Learned fließen in die Verbesserung ein; eine Strategie zur Behörden-/Strafverfolgungsmeldung besteht.
+Ereignisse werden ohne Verzögerung nach einem definierten Incident-Verfahren (siehe {{LINK:VA-01}}) im {{TOOL_TICKET}} kategorisiert, qualifiziert, priorisiert, behandelt und dokumentiert; Verantwortlichkeiten und Eskalationswege sind zugewiesen ({{ROLE_ISB}} koordiniert, {{ROLE_IT_LEAD}} setzt um). Lessons Learned fließen in die Verbesserung ein; eine Strategie zur Behörden-/Strafverfolgungsmeldung besteht.

 {{#if FLAG_ELEVATED_PROTECTION}}
 <!-- IMPL 1.6.2-elev -->
@@ -192,7 +192,7 @@ Bei hohem Schutzbedarf sind maximale Reaktionszeiten je Schwere definiert, Eskal
 **Umsetzung bei {{ORG_NAME}}**

 <!-- IMPL 1.6.3 -->
-Ein Krisenmanagement mit Plan, definiertem und genehmigtem Krisenstab, Rollen, Auslöse-/Eskalations-, Kommunikations- und Entscheidungswegen sowie strategischen Zielen ist etabliert; erforderliche Ressourcen sind verfügbar, Verantwortliche qualifiziert. Erkennungsmethoden bestehen, die Krisenplanung wird regelmäßig überprüft und aktualisiert; der Krisenstab wird durch die {{ROLE_MANAGEMENT}} einberufen.
+Ein Krisenmanagement mit Plan, definiertem und genehmigtem Krisenstab, Rollen, Auslöse-/Eskalations-, Kommunikations- und Entscheidungswegen sowie strategischen Zielen ist etabliert (Auslösung/Wiederanlauf siehe {{LINK:VA-02}}); erforderliche Ressourcen sind verfügbar, Verantwortliche qualifiziert. Erkennungsmethoden bestehen, die Krisenplanung wird regelmäßig überprüft und aktualisiert; der Krisenstab wird durch die {{ROLE_MANAGEMENT}} einberufen.

 {{#if FLAG_ELEVATED_PROTECTION}}
 <!-- IMPL 1.6.3-elev -->
@@ -108,7 +108,7 @@ Alle Beschäftigten werden bei Eintritt vertraglich zur Vertraulichkeit und zur
 **Umsetzung bei {{ORG_NAME}}**

 <!-- IMPL 2.1.3 -->
-Ein von der Leitung genehmigtes, rollenspezifisches Schulungs-/Awareness-Konzept (BL-HR-01) ist etabliert; Beschäftigte werden bei Eintritt und danach mindestens {{REVIEW_CYCLE}} sowie anlassbezogen geschult. Zielgruppen sind identifiziert, Teilnahmenachweise werden im {{TOOL_NAME}} geführt, Ansprechpartner für Informationssicherheit sind bekannt; die Wirksamkeit wird (z. B. Phishing-Simulation) geprüft.
+Ein von der Leitung genehmigtes, rollenspezifisches Schulungs-/Awareness-Konzept (BL-HR-01) ist etabliert; Beschäftigte werden bei Eintritt und danach mindestens {{REVIEW_CYCLE}} sowie anlassbezogen geschult (Ablauf siehe {{LINK:VA-12}}). Zielgruppen sind identifiziert, Teilnahmenachweise werden im {{TOOL_NAME}} geführt, Ansprechpartner für Informationssicherheit sind bekannt; die Wirksamkeit wird (z. B. Phishing-Simulation) geprüft.

 ## 4. Verbindlichkeit

@@ -42,7 +42,7 @@ Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SC
 **Umsetzung bei {{ORG_NAME}}**

 <!-- IMPL 4.1.1 -->
-Identifikationsmittel (Benutzerkennungen, Token, Zertifikate) werden über den Lebenszyklus eindeutig personenbezogen und unter kontrollierten Bedingungen über {{TOOL_IAM}} vergeben; Ausgabe, Rücknahme und Sperrung werden im {{TOOL_TICKET}} beantragt, genehmigt und dokumentiert (BL-IAM-07).
+Identifikationsmittel (Benutzerkennungen, Token, Zertifikate) werden über den Lebenszyklus eindeutig personenbezogen und unter kontrollierten Bedingungen über {{TOOL_IAM}} vergeben; Ausgabe, Rücknahme und Sperrung werden im {{TOOL_TICKET}} beantragt, genehmigt und dokumentiert (BL-IAM-07, siehe {{LINK:VA-03}}).

 {{#if FLAG_ELEVATED_PROTECTION}}
 <!-- IMPL 4.1.1-elev -->
@@ -150,7 +150,7 @@ Bei hohem Schutzbedarf sind Authentifizierung/Zugangskontrolle durch ergänzende
 **Umsetzung bei {{ORG_NAME}}**

 <!-- IMPL 4.1.3 -->
-Benutzerkonten werden über einen definierten Lebenszyklus (Joiner/Mover/Leaver) eindeutig personalisiert in {{TOOL_IAM}} verwaltet; Auslöser sind {{TOOL_TICKET}}-Aufträge aus HR-/Vorgesetztenmeldungen. Konten Ausgeschiedener werden unverzüglich deaktiviert, Konten regelmäßig überprüft (auch in Kundensystemen), Sammelkonten sind geregelt. Anmeldeinformationen werden sicher bereitgestellt; Standardkonten/-passwörter sind deaktiviert, Basiskonten mit Minimalrechten genutzt, Erstellung erfolgt im Vier-Augen-Prinzip, interaktive Anmeldung technischer Konten ist unterbunden.
+Benutzerkonten werden über einen definierten Lebenszyklus (Joiner/Mover/Leaver) (siehe {{LINK:VA-03}}) eindeutig personalisiert in {{TOOL_IAM}} verwaltet; Auslöser sind {{TOOL_TICKET}}-Aufträge aus HR-/Vorgesetztenmeldungen. Konten Ausgeschiedener werden unverzüglich deaktiviert, Konten regelmäßig überprüft (auch in Kundensystemen), Sammelkonten sind geregelt. Anmeldeinformationen werden sicher bereitgestellt; Standardkonten/-passwörter sind deaktiviert, Basiskonten mit Minimalrechten genutzt, Erstellung erfolgt im Vier-Augen-Prinzip, interaktive Anmeldung technischer Konten ist unterbunden.

 ### 3.4 Zugriffsrechte (ISA 4.2.1)

@@ -196,7 +196,7 @@ Benutzerkonten werden über einen definierten Lebenszyklus (Joiner/Mover/Leaver)
 **Umsetzung bei {{ORG_NAME}}**

 <!-- IMPL 4.2.1 -->
-Zugriffsrechte werden nach dem Minimalprinzip (need-to-know/least privilege) rollenbasiert (RBAC) über {{TOOL_IAM}} vergeben; Antrag, fachliche Prüfung und Genehmigung erfolgen im {{TOOL_TICKET}}. Rechte werden bei Änderung/Wegfall aktualisiert bzw. entzogen und mindestens {{RECERT_FREQ}} rezertifiziert (BL-IAM-05), auch in Kundensystemen; Standardkonten erhalten keine privilegierten Rechte.
+Zugriffsrechte werden nach dem Minimalprinzip (need-to-know/least privilege) rollenbasiert (RBAC) über {{TOOL_IAM}} vergeben; Antrag, fachliche Prüfung und Genehmigung erfolgen im {{TOOL_TICKET}} (siehe {{LINK:VA-03}}). Rechte werden bei Änderung/Wegfall aktualisiert bzw. entzogen und mindestens {{RECERT_FREQ}} rezertifiziert (BL-IAM-05), auch in Kundensystemen; Standardkonten erhalten keine privilegierten Rechte.

 {{#if FLAG_ELEVATED_PROTECTION}}
 <!-- IMPL 4.2.1-elev -->
@@ -83,7 +83,7 @@ Bei hohem Schutzbedarf sind Anforderungen an die Schlüsselhoheit (insbesondere
 **Umsetzung bei {{ORG_NAME}}**

 <!-- IMPL 5.1.2 -->
-Genutzte Netzdienste sind identifiziert und dokumentiert; Richtlinien/Verfahren entsprechend der Klassifizierung sind umgesetzt. Informationen werden schutzbedarfsgerecht bei der Übertragung geschützt (mindestens {{TLS_MIN}}, BL-CRY-01), korrekte Adressierung sichergestellt und Fernzugriffe abgesichert; Regeln für E-Mail-/Dateiverschlüsselung sind definiert (BL-CRY-04).
+Genutzte Netzdienste sind identifiziert und dokumentiert; Richtlinien/Verfahren entsprechend der Klassifizierung sind umgesetzt. Informationen werden schutzbedarfsgerecht bei der Übertragung geschützt (mindestens {{TLS_MIN}}, BL-CRY-01), korrekte Adressierung sichergestellt und Fernzugriffe abgesichert; Regeln für E-Mail-/Dateiverschlüsselung sind definiert (BL-CRY-04, Krypto-/Schlüsselverwaltung siehe {{LINK:VA-07}}).

 {{#if FLAG_ELEVATED_PROTECTION}}
 <!-- IMPL 5.1.2-elev -->
@@ -54,7 +54,7 @@ Diese Richtlinie gilt innerhalb des definierten ISMS-Geltungsbereichs ({{ISMS_SC
 **Umsetzung bei {{ORG_NAME}}**

 <!-- IMPL 5.2.1 -->
-Änderungen durchlaufen ein formales Change-Verfahren mit Antrag, Auswirkungs-/Risikobewertung, Planung, Test, Genehmigung, Rollback-Plan und Dokumentation im {{TOOL_TICKET}} (BL-OPS-09); Informationssicherheitsanforderungen sind bestimmt und erfüllt.
+Änderungen durchlaufen ein formales Change-Verfahren (siehe {{LINK:VA-04}}) mit Antrag, Auswirkungs-/Risikobewertung, Planung, Test, Genehmigung, Rollback-Plan und Dokumentation im {{TOOL_TICKET}} (BL-OPS-09); Informationssicherheitsanforderungen sind bestimmt und erfüllt.

 {{#if FLAG_ELEVATED_PROTECTION}}
 <!-- IMPL 5.2.1-elev -->
@@ -240,7 +240,7 @@ Schwachstelleninformationen werden erhoben (Herstellerinfos, CVE, Scans BL-OPS-0
 **Umsetzung bei {{ORG_NAME}}**

 <!-- IMPL 5.2.6 -->
-Anforderungen und Umfang technischer Prüfungen sind bestimmt und mit Betreibern/Nutzern abgestimmt; Systeme werden nach Härtungsvorgaben (BL-OPS-07, z. B. CIS-Benchmarks) konfiguriert und risikoorientiert geprüft. Ergebnisse werden nachvollziehbar gespeichert, der Leitung berichtet und Maßnahmen fristgerecht umgesetzt.
+Anforderungen und Umfang technischer Prüfungen sind bestimmt und mit Betreibern/Nutzern abgestimmt; Systeme werden nach Härtungsvorgaben (BL-OPS-07, z. B. CIS-Benchmarks) konfiguriert und risikoorientiert geprüft (siehe {{LINK:VA-06}}). Ergebnisse werden nachvollziehbar gespeichert, der Leitung berichtet und Maßnahmen fristgerecht umgesetzt.

 {{#if FLAG_ELEVATED_PROTECTION}}
 <!-- IMPL 5.2.6-elev -->
@@ -109,7 +109,7 @@ Bei hohem Schutzbedarf wird das Sicherheitsniveau des Lieferanten nachgewiesen (
 **Umsetzung bei {{ORG_NAME}}**

 <!-- IMPL 6.1.2 -->
-Vertraulichkeitsanforderungen sind bestimmt und bekannt; vor Weitergabe schutzbedürftiger Informationen werden gültige NDAs auf Basis geprüfter Standardvorlagen (mit Parteien, Informationsart, Gegenstand, Gültigkeit, Verantwortlichkeiten und nachvertraglichen Regelungen) abgeschlossen und im ISMS-Tool hinterlegt. Anforderungen/Verfahren und Gültigkeitsdauern werden regelmäßig überwacht, Nachweismöglichkeiten sind definiert.
+Vertraulichkeitsanforderungen sind bestimmt und bekannt; vor Weitergabe schutzbedürftiger Informationen werden gültige NDAs auf Basis geprüfter Standardvorlagen (Ablauf siehe {{LINK:VA-10}}) (mit Parteien, Informationsart, Gegenstand, Gültigkeit, Verantwortlichkeiten und nachvertraglichen Regelungen) abgeschlossen und im ISMS-Tool hinterlegt. Anforderungen/Verfahren und Gültigkeitsdauern werden regelmäßig überwacht, Nachweismöglichkeiten sind definiert.

 ### 3.3 Abgrenzung der Verantwortlichkeiten (ISA 6.1.3)

@@ -157,7 +157,7 @@ Vertraulichkeitsanforderungen sind bestimmt und bekannt; vor Weitergabe schutzbe
 **Umsetzung bei {{ORG_NAME}}**

 <!-- IMPL 6.1.3 -->
-Betroffene IT-Dienste und ihre Sicherheitsanforderungen sind identifiziert; Verantwortlichkeiten zwischen der Organisation und externen IT-Dienstleistern (inkl. Mechanismen für geteilte Verantwortung) sind definiert, bekannt und werden erfüllt. Die Konfiguration ist anforderungsbasiert umgesetzt und dokumentiert, das Personal geschult.
+Betroffene IT-Dienste und ihre Sicherheitsanforderungen sind identifiziert; Verantwortlichkeiten zwischen der Organisation und externen IT-Dienstleistern (inkl. Mechanismen für geteilte Verantwortung) sind definiert, bekannt und werden erfüllt (siehe {{LINK:VA-10}}). Die Konfiguration ist anforderungsbasiert umgesetzt und dokumentiert, das Personal geschult.

 {{#if FLAG_ELEVATED_PROTECTION}}
 <!-- IMPL 6.1.3-elev -->