certvia/docs/reviews/richtlinien-gap-report.md

GAP-Report Runde 2 (strenger Re-Sweep): Richtlinien & Verfahrensanweisungen — ISMS-Vorlagenpaket v2

Angabe	Wert
Prüfgegenstand	seed/isms-vorlagenpaket-v2/ (Source of Truth; nicht der Spiegel unter .next/standalone/…)
Standard	VDA ISA 2027 (Information Security) / ISO 27001:2022 / NIS2-Kontext
Umfang	15 Richtlinien (L00, R01–R14), 13 Verfahrensanweisungen (VA-01–VA-13), Baseline, Nachweisregister, mapping.json (316 Anforderungen)
Prüfraster (streng)	WAS · WIE · WO eindeutig dokumentiert · WER · NACHWEIS — je Anforderung. „erfüllt" nur, wenn ALLE fünf Dimensionen konkret beantwortet sind und operative Prozesse auf eine VA bzw. zentral gepflegte Werte auf Register/Baseline verweisen. Sobald eine Dimension fehlt/vage/doppeldeutig ist → mindestens „teilweise".
Runde	2 (Korrektur der zu milden Runde 1)
Erstellt	2026-07-22
Status	Review-Report (read-only) — es wurde nichts am Vorlagenpaket geändert; nur diese Report-Datei wurde neu erzeugt.

Hinweis: Reiner Prüfbericht. Keine Datei des Vorlagenpakets, kein Code, keine DB, kein Seed wurde geändert; kein Commit, kein Push. Alle Textvorschläge sind einpflegefertig, aber nicht eingepflegt.

---

1. Management-Summary

Das Vorlagenpaket hat weiterhin einen überdurchschnittlichen Reifegrad (zentrale Baseline mit BL-IDs, zentrales Nachweisregister, 316 REQ-Anker ↔ 316 Mapping-IDs ohne Waisen, -elev-Blöcke für alle HOCH/SEHR-HOCH-Controls). Runde 1 hat diesen Reifegrad jedoch zu wohlwollend in Verdikte übersetzt: Sie hat Anforderungen als „erfüllt" gewertet, deren Umsetzungstext den strengen Rubric (eindeutiger Nachweisort, Inline-VA-Verweis, verwaltetes Register) nicht besteht. Runde 2 legt den skeptischen Maßstab konsequent an.

Was gegenüber Runde 1 strenger/korrigiert wurde:

• 8 Controls von „erfüllt" auf „teilweise" herabgestuft (Details in §2): 1.2.3, 2.1.2, 3.1.1, 5.2.6, 5.2.8, 5.3.4-KI, 6.1.3, 7.1.2. Die neue Control-Verteilung ist 14 erfüllt / 30 teilweise / 2 GAP (Runde 1: 22 / 22 / 2).
• Doppeldeutige Verortung („im {{TOOL_TICKET}} bzw. ISMS-Tool") wird konsequent als fehlender eindeutiger Nachweisort (G2) gewertet — betrifft u. a. 1.2.3 und 1.6.1.
• „Liste/Freigabeliste im ISMS-Tool" ohne Register-ID, Pflichtattribute und Review-Turnus wird als fehlendes verwaltetes Register (G4/G8) gewertet — auch dort, wo Runde 1 „erfüllt" vergeben hatte (1.3.3, 1.3.4, 5.3.4, 5.3.4-KI, 6.1.3, 5.2.8, 5.2.7, 5.1.2).
• Inline-VA-Verweis wird control-genau geprüft: Von 23 Controls mit zuständiger VA verweisen nur 8 im Umsetzungstext auf ihre VA; 15 nennen das Verfahren nur generisch bzw. im Anhang → G3.

Die drei in Runde 1 bestätigten Misses — in Runde 2 sauber aufgearbeitet:

1. ISA 1.2.3 / R01 §3.3 (Informationssicherheit in Projekten): In Runde 1 fälschlich „erfüllt". Tatsächlich deckt keine VA 1.2.3 ab (kein FULFILLS 1.2.3 in den VA-Headern, kein Eintrag in mapping.json → verfahren). Der Umsetzungstext verortet doppeldeutig („die Einstufung wird im {{TOOL_TICKET}} bzw. ISMS-Tool dokumentiert"), und weder der genannte „dokumentierte Kriterienkatalog" noch ein Projektregister/Projektverzeichnis sind als verwaltetes Artefakt referenziert. → Neu bewertet: teilweise; Befund G4 (neue VA „Informationssicherheit in Projekten") + G2/G8 (eindeutiger Nachweisort, Kriterienkatalog- und Projektregister). Textvorschläge in §8 (A-N1).
2. Rendering-/Konsistenzbug {{TOOL_TICKET}} u. ä.: Der Default von {{TOOL_TICKET}} ist „das Ticketsystem"; das Muster „im {{TOOL_TICKET}}" rendert daher zu „im das Ticketsystem" (Doppelartikel). Analog {{TOOL_NAME}} = „das ISMS-Tool" und {{TOOL_IAM}} = „das zentrale Verzeichnis …". Systemischer G6-Befund mit 11 konkreten Fundstellen (§6), inkl. eines zusätzlichen Kasus-Fehlers bei in {{TOOL_IAM}} (R08:153).
3. Software-Whitelist als verwaltetes Register mit Lieferantenbezug UND Asset-Kopplung: Empfehlung REG-SW-WHITELIST mit Spalten u. a. Software, Version/Patch-Stand, Quelle/Lieferant/Dienstleister, Freigabestatus, Verantwortlich, Review — doppelt cross-verlinkt an R13/VA-10 (Lieferantensteuerung) (zugelassene Software hat einen steuerbaren Lieferanten) und an R02/VA-08 (Asset & Klassifizierung) (zugelassene Software ist als Asset geführt). Analog REG-EXT-SERVICES für externe/Cloud-/KI-Dienste (§5, §8 A-N3).

Reifegrad-Einschätzung Runde 2: Inhaltlich bleibt die Abdeckung auf Ebene der 312 konsolidierten ISA-Zeilen hoch; die Herabstufungen betreffen überwiegend Nachweisführung und Verortung (Inline-Verweis, verwaltetes Register, eindeutiger Ort), nicht fehlenden Sachinhalt. Zwei echte Inhalts-GAPs bleiben (2.1.1, 3.1.3). Mit der Roadmap in §7 erreicht das Paket ein durchgängig audittaugliches Niveau.

---

2. Bewertungs-Übersicht

2.1 Verteilung Control-Ebene (46 Controls)

Verdikt	Runde 1	Runde 2	Controls (Runde 2)
erfüllt	22	14	1.1.1; 1.2.1; 1.2.2; 3.1.4; 4.1.2; 5.1.1; 5.2.2; 5.2.3; 5.2.4; 5.2.5; 5.2.9; 5.3.3; 6.1.1; 7.1.1
teilweise	22	30	1.2.3; 1.3.1; 1.3.2; 1.3.3; 1.3.4; 1.4.1; 1.5.1; 1.5.2; 1.6.1; 1.6.2; 1.6.3; 2.1.2; 2.1.3; 2.1.4; 3.1.1; 4.1.1; 4.1.3; 4.2.1; 5.1.2; 5.2.1; 5.2.6; 5.2.7; 5.2.8; 5.3.1; 5.3.2; 5.3.4; 5.3.4-KI; 6.1.2; 6.1.3; 7.1.2
GAP	2	2	2.1.1; 3.1.3

Die 46 Controls = 45 Controls in mapping.json + der „Phantom"-Control 3.1.3 (IMPL-Stub in R07 ohne REQ-Anker und ohne mapping.json-Eintrag; siehe GAP G-B2).

2.2 Gegenüber Runde 1 KORRIGIERTE Einstufungen (alle: erfüllt → teilweise/GAP)

Control	Richtlinie	Runde 1	Runde 2	Grund der Verschärfung	GAP-Typ
1.2.3	R01	erfüllt	teilweise	Keine VA deckt 1.2.3 ab; Verortung doppeldeutig („{{TOOL_TICKET}} bzw. ISMS-Tool"); Kriterienkatalog & Projektregister nicht als verwaltete Artefakte referenziert	G2, G4, G8, G6
2.1.2	R05	erfüllt	teilweise	„Ein Verfahren zum Umgang mit Verstößen ist beschrieben" — Verfahren nicht verortet/verlinkt (kein VA-/Dok-Verweis)	G1, G2
3.1.1	R07	erfüllt	teilweise	Zutrittsvergabe/-entzug (S1) und Besuchermanagement (S2) nur als „berücksichtigt" pauschaliert; kein Verfahren/VA verortet	G1, G3
5.2.6	R10	erfüllt	teilweise	VA-06 erfüllt laut FULFILLS 5.2.6-M1, wird im IMPL 5.2.6 aber nicht inline referenziert	G3
5.2.8	R04	erfüllt	teilweise	Kritische IT-Dienste nur „identifiziert"; kein verwaltetes Register (RTO/RPO nur im -elev-Block, keine BIA-Register-ID)	G8
5.3.4-KI	R12	erfüllt	teilweise	„Freigabeliste im ISMS-Tool" ist informelles Register ohne Register-ID/Attribute/Turnus (REG-EXT-SERVICES)	G8, G4
6.1.3	R13	erfüllt	teilweise	VA-10 erfüllt laut FULFILLS 6.1.3-M1, IMPL 6.1.3 verweist nicht inline; „Liste der IT-Dienste" (elev) informell	G3, G8
7.1.2	R14	erfüllt	teilweise	Kein referenzierter Prozess für Betroffenenrechte/Löschfristen-Review (nur BL-DEL-01 statisch); keine Datenschutz-Pflege-VA	G4

2.3 Anforderungsebene (316 Einzelanforderungen) — Schwerpunkte

• Inline-VA-Verweis: 23 Controls haben eine zuständige VA; 8 verweisen inline (5.1.1, 5.2.4, 5.2.5*, 5.2.8, 5.2.9, 5.3.4, 5.3.4-KI, 6.1.1), 15 nicht (G3). *5.2.5 verweist auf VA-06, nicht auf das ebenfalls zuständige VA-04.
• Register/Baseline-Bezug fehlt (G8/G4) bei allen „Liste im Tool"-Formulierungen: 1.2.3 (Kriterienkatalog/Projektregister), 1.3.3 & 5.3.4/5.3.4-KI (externe/Cloud/KI-Dienste), 1.3.4 (Software-Whitelist), 1.5.1 (Auditplan), 2.1.1 (sensible Rollen), 5.1.2 & 5.2.7 (Netz/Netzdienste), 5.2.8 & 6.1.3 (kritische IT-Dienste).
• Leere Anforderung / Mapping-Bruch: 3.1.3 (leerer REQ-Block, IMPL-Stub ohne Mapping); ISA 3.1.2 fehlt in R07 und mapping.json vollständig.
• Strukturhinweis: Control 1.1.1 (L00) hat keinen gebündelten IMPL-Block; impl_anchor == req_anchor — die „Umsetzung" ist die Leitlinien-Prosa selbst. Inhaltlich vertretbar (Leitlinie), aber vom übrigen IMPL <control>-Muster abweichend (siehe auch F-Tooling).

---

3. Vollständige Verlinkungs-/Coverage-Matrix — ALLE 46 Controls

Spalten: Inline im Umsetzungstext verlinkt? = verweist der IMPL <control>-Block per {{LINK:VA-xx}}/„siehe … Verfahren" auf die zuständige VA (ja) oder steht die VA nur generisch/im Anhang (nein); „n.a." = keine VA zuständig.

#	Control	Anf.-Stufe(n)	Zuständige VA (FULFILLS)	Inline verlinkt?	Register/Baseline-Bezug	Status	Bemerkung
1	1.1.1	M×5 / S×4	n.a.	n.a.	Nachweisregister; ISMS-Tool	erfüllt	Leitlinie; kein IMPL-Block (impl_anchor=req_anchor)
2	1.2.1	M×6	n.a.	n.a.	ISMS-Tool; Managementbewertung	erfüllt	Governance vollständig verortet
3	1.2.2	M×4 / S×2 / H×1	n.a.	n.a.	Rollenmatrix; ISMS-Tool	erfüllt	Funktionstrennung im -elev
4	1.2.3	M×1 / S×3 / H×1	keine	n.a. (VA fehlt)	kein Kriterienkatalog-/Projektregister; keine BL	teilweise	KORRIGIERT v. erfüllt; G2/G4/G8/G6 (Miss #1)
5	1.3.1	M×2 / S×1	VA-08	nein	Asset-Inventar (ISMS-Tool)	teilweise	G3
6	1.3.2	M×3 / S×1	VA-08	nein	Klassifizierungsschema	teilweise	G3
7	1.3.3	M×2 / S×4	n.a.	n.a.	„Freigabeliste im ISMS-Tool" (informell)	teilweise	G8/G4 → REG-EXT-SERVICES
8	1.3.4	M×2 / S×5 / V×1	n.a.	n.a.	„Whitelist im ISMS-Tool" (informell)	teilweise	G8/G4 → REG-SW-WHITELIST (Miss #3)
9	1.4.1	M×4 / S×4	VA-09	nein	Risikoregister (ISMS-Tool)	teilweise	G3
10	1.5.1	M×5 / S×1	n.a.	n.a.	„Auditplan" (informell); keine BL-Frequenz	teilweise	G4/G2/G8 → VA-15, REG-AUDIT-PLAN
11	1.5.2	M×2 / S×1	n.a.	n.a.	unabhängige Prüfung; kein Turnus/BL	teilweise	G2/G8
12	1.6.1	M×3 / S×6 / V×1	VA-01	nein	Meldeweg; „{{TOOL_TICKET}} bzw. ISMS-Tool"	teilweise	G3/G2/G6 (doppeldeutig)
13	1.6.2	M×3 / S×3 / H×5 / V×1	VA-01	nein	{{TOOL_TICKET}}	teilweise	G3/G6
14	1.6.3	M×3 / S×6 / H×5 / V×1	VA-02	nein	Krisenplan; keine BL-Übungsfrequenz	teilweise	G3/G8
15	2.1.1	M×3 / S×2	keine	n.a. (VA fehlt)	kein Register sensibler Rollen	GAP	G1/G2/G4/G5 → VA-14, REG-SENS-ROLES
16	2.1.2	M×2 / S×3	n.a.	n.a.	Personalakte; Verstoß-„Verfahren" unverortet	teilweise	KORRIGIERT v. erfüllt; G1/G2
17	2.1.3	M×1 / S×6	VA-12	nein	BL-HR-01; {{TOOL_NAME}}	teilweise	G3/G6
18	2.1.4	M×1 / S×2 / H×1	n.a.	n.a.	„eine Regelung" — nicht verortet	teilweise	G2/G1
19	3.1.1	M×3 / S×5 / H×1	n.a.	n.a.	BL-PHY-01/02; Besucher/Zutritt generisch	teilweise	KORRIGIERT v. erfüllt; G1/G3 → VA-17
20	3.1.3	— (leer)	n.a.	n.a.	IMPL-Stub ohne REQ/Mapping	GAP	G6/G1; ISA 3.1.2 fehlt zudem ganz
21	3.1.4	M×1 / S×1 / H×1	n.a.	n.a.	TECH_MDM; BL-EP-02	erfüllt	Baseline-verankert
22	4.1.1	M×1 / S×1 / H×1	VA-03	nein	BL-IAM-07; TOOL_IAM	teilweise	G3
23	4.1.2	M×2 / S×3 / H×1 / V×1	n.a.	n.a.	BL-IAM-01/02; TECH_MFA	erfüllt	Baseline-verankert
24	4.1.3	M×7 / S×10	VA-03	nein	TOOL_IAM	teilweise	G3
25	4.2.1	M×2 / S×5 / H×1 / V×2	VA-03	nein	BL-IAM-05; RECERT_FREQ	teilweise	G3
26	5.1.1	M×1 / S×1 / H×1	VA-07	ja	BL-CRY-02/05	erfüllt	Vorbildliche Referenzkette
27	5.1.2	M×3 / S×3 / H×1 / V×1	VA-07	nein	BL-CRY-01/04; Netzdienste informell	teilweise	G3/G8 → REG-NET
28	5.2.1	M×1 / S×4 / H×1	VA-04	nein	BL-OPS-09; {{TOOL_TICKET}}	teilweise	G3/G6
29	5.2.2	M×2 / S×1	n.a.	n.a.	Trennung Dev/Test/Prod	erfüllt	Konkret
30	5.2.3	M×2 / S×8	n.a.	n.a.	BL-OPS-03; TECH_MALWARE	erfüllt	Baseline-verankert
31	5.2.4	M×5 / S×3 / H×2 / V×1	VA-13	ja	BL-OPS-04; LOG_RETENTION	erfüllt	Referenzkette vollständig
32	5.2.5	M×3 / S×3	VA-04, VA-06	teils	BL-OPS-01/02; PATCH_SLA_CRIT	erfüllt	VA-06 inline; VA-04 nicht inline
33	5.2.6	M×5 / S×3 / H×1 / V×1	VA-06	nein	BL-OPS-07/08; PENTEST_FREQ	teilweise	KORRIGIERT v. erfüllt; G3
34	5.2.7	M×2 / S×2 / H×1	n.a.	n.a.	BL-NET-01/02; „Netzplan" informell	teilweise	G8/G2 → REG-NET
35	5.2.8	M×2 / S×3 / H×7 / V×3	VA-02	ja	kein REG-CRIT-SERVICES; RTO/RPO nur elev	teilweise	KORRIGIERT v. erfüllt; G8
36	5.2.9	M×2 / S×1 / H×2 / V×3	VA-05	ja	BL-OPS-05; BACKUP_SCHEME/RETENTION	erfüllt	Referenzkette vollständig
37	5.3.1	M×4 / S×5 / V×1	n.a.	n.a.	{{TOOL_TICKET}}; keine Secure-Dev-VA	teilweise	G4/G1/G6 → VA-16
38	5.3.2	M×1 / S×3 / H×1	n.a.	n.a.	„über ein Verfahren" (generisch)	teilweise	G1/G4 → VA-16
39	5.3.3	S×1	n.a.	n.a.	BL-DEL-01; Löschprotokoll	erfüllt	Konkret
40	5.3.4	M×1 / S×1	VA-11	ja	„Freigabeliste im ISMS-Tool" (informell)	teilweise	G8 → REG-EXT-SERVICES
41	5.3.4-KI	M×3 / S×1	VA-11	ja	„Freigabeliste im ISMS-Tool" (informell)	teilweise	KORRIGIERT v. erfüllt; G8/G4
42	6.1.1	M×3 / S×2 / H×3 / V×2	VA-10	ja	BL-SUP-01; Lieferantenverzeichnis	erfüllt	Referenzkette vollständig
43	6.1.2	M×4 / S×5	VA-10	nein	NDAs „im ISMS-Tool" (informell)	teilweise	G3
44	6.1.3	M×5 / S×2 / H×5	VA-10	nein	„Liste der IT-Dienste" (elev, informell)	teilweise	KORRIGIERT v. erfüllt; G3/G8
45	7.1.1	M×2 / S×1	n.a.	n.a.	Compliance-/Rechtsregister (ISMS-Tool)	erfüllt	Register vorhanden
46	7.1.2	M×3	n.a.	n.a.	VVT (ISMS-Tool); BL-DEL-01	teilweise	KORRIGIERT v. erfüllt; G4 (Betroffenenrechte/Löschfristen-Prozess) → VA-18

---

4. GAP-Tabelle

Legende Schwere: hoch = unmittelbar auditrelevant / Inhaltslücke · mittel = schwächt Nachweisführung / Konsistenz · niedrig = Feinschliff. GAP-Typen: G1 zu generisch · G2 kein/eindeutiger Nachweisort fehlt · G3 fehlende Inline-Verlinkung · G4 fehlende VA/Register · G5 Verantwortlicher unklar · G6 Widerspruch/Redundanz/veraltet/Rendering · G7 Schutzbedarf nicht adressiert · G8 Baseline-/Register-Referenz fehlt.

#	Richtlinie	Control	Anf. (M/S/H/V)	Umsetzung heute (Kurz)	GAP-Typ	Schwere	Empfehlung	Konkreter Textvorschlag	Ziel-Referenz
N1	R01	1.2.3	M/S/H	„Klassifizierung anhand Kriterienkatalog; Einstufung im {{TOOL_TICKET}} bzw. ISMS-Tool; Maßnahmen als Aufgaben" — keine VA, doppeldeutiger Ort, Kriterienkatalog/Projektregister nicht referenziert	G4, G2, G8, G6	hoch	Neue VA „Informationssicherheit in Projekten"; Kriterienkatalog + Projektregister als verwaltete Artefakte; eindeutigen Ort setzen; Rendering fixen	siehe A-N1	Neue VA-19, REG-PROJECTS, Kriterienkatalog (BL-PROJ-01)
G-B1	R05	2.1.1	M×3 / S×2	„Sensible Tätigkeiten sind bestimmt; Eignung im rechtlich zulässigen Rahmen geprüft" — ohne Register, ohne Einstellungs-/Verifizierungs-VA, WER unklar	G1, G2, G4, G5	hoch	Register sensibler Tätigkeitsbereiche + VA-14 (Eignungs-/Verifizierungsprozess)	siehe A-G-B1	Neue VA-14, REG-SENS-ROLES
G-B2	R07	3.1.3	— (leer)	Anforderungsblock leer; IMPL-Stub ohne REQ/Mapping; ISA 3.1.2 fehlt ganz	G6, G1	hoch	Scope 3.1.2/3.1.3 klären; REQ-Anker + Mapping ergänzen oder Stub entfernen	siehe A-G-B2	mapping.json, R07
N2	R05	2.1.2	M/S	„Ein Verfahren zum Umgang mit Verstößen ist beschrieben" — Verfahren nicht verortet/verlinkt	G1, G2	mittel	Verstoß-/Disziplinarverfahren benennen & verorten (Dok/VA-14)	„… ein dokumentiertes Verfahren zum Umgang mit Verstößen (siehe {{LINK:VA-14}}) ist etabliert; Nachweis in der Personalakte."	{{LINK:VA-14}} / Personalakte
N3	R07	3.1.1	M/S/H	Besuchermanagement, Zutrittsvergabe/-entzug (S1/S2) nur als „berücksichtigt" pauschaliert	G1, G3	mittel	Zutritts-/Besuchermanagement-Verfahren verorten	„… Zutrittsrechte werden über {{TOOL_TICKET}} vergeben/entzogen (Ablauf siehe {{LINK:VA-17}}); Besuchermanagement (Registrierung/Begleitung) ist geregelt (BL-PHY-…)."	Neue VA-17
N4	R10	5.2.6	M/S/H/V	Härtung/technische Prüfungen; VA-06 erfüllt 5.2.6-M1, aber nicht inline referenziert	G3	mittel	VA-06 im IMPL 5.2.6 inline referenzieren	„… risikoorientiert geprüft (siehe {{LINK:VA-06}}); Ergebnisse werden gespeichert, der Leitung berichtet …"	{{LINK:VA-06}}
N5	R04	5.2.8	M/S/H/V	Kritische IT-Dienste „identifiziert"; RTO/RPO nur im -elev-Block; kein Register	G8	mittel	Register kritischer IT-Dienste inkl. BIA/RTO/RPO referenzieren	„Kritische IT-Dienste sind mit Geschäftsauswirkung im Register kritischer IT-Dienste ({{LINK:REG-CRIT-SERVICES}}) (inkl. RTO/RPO, Wiederanlaufreihenfolge) erfasst … (siehe {{LINK:VA-02}})."	REG-CRIT-SERVICES
N6	R12	5.3.4-KI	M/S	„Freigabeliste im ISMS-Tool" ohne Register-ID/Attribute/Turnus	G8, G4	mittel	KI-/externe Dienste als verwaltetes Register mit Lieferant+Asset-Kopplung	siehe A-N6	REG-EXT-SERVICES, {{LINK:VA-11}}
N7	R13	6.1.3	M/S/H	VA-10 erfüllt 6.1.3-M1, IMPL nicht inline; „Liste IT-Dienste/Dienstleister" (elev) informell	G3, G8	mittel	VA-10 inline; Dienste-/Dienstleister-Register formalisieren	„… Verantwortlichkeiten … definiert (siehe {{LINK:VA-10}}); betroffene IT-Dienste und Dienstleister im {{LINK:REG-EXT-SERVICES}} geführt."	{{LINK:VA-10}}, REG-EXT-SERVICES
N8	R14	7.1.2	M	VVT im Tool; kein referenzierter Prozess für Betroffenenrechte/Löschfristen-Review	G4	mittel	Datenschutz-/Compliance-Pflege-VA referenzieren	siehe A-N8	Neue VA-18
N9	R09	5.1.2	M/S/H/V	VA-07 erfüllt 5.1.2-M1/S1, IMPL 5.1.2 verweist nicht inline; Netzdienste nur „identifiziert"	G3, G8	mittel	VA-07 inline; Netzdienste-Register	„Genutzte Netzdienste sind im {{LINK:REG-NET}} identifiziert/dokumentiert; Krypto-/Schlüsselverwaltung (siehe {{LINK:VA-07}})."	{{LINK:VA-07}}, REG-NET
F3	R02	1.3.1, 1.3.2	M/S	IMPL ohne Inline-Verweis auf VA-08	G3	mittel	VA-08 im Umsetzungstext inline referenzieren	„… als Katalog gepflegt (siehe {{LINK:VA-08}}); Zu-/Abgänge über {{TOOL_TICKET}}."	{{LINK:VA-08}}
F4	R03	1.4.1	M/S	„Das dokumentierte Risikomanagement-Verfahren …" ohne Inline-Link auf VA-09	G3	mittel	VA-09 inline referenzieren	„Das dokumentierte Risikomanagement-Verfahren (siehe {{LINK:VA-09}}) …"	{{LINK:VA-09}}
F5	R04	1.6.1, 1.6.2	M/S/H/V	„nach einem definierten Incident-Verfahren im {{TOOL_TICKET}}" ohne Inline-Link auf VA-01	G3	mittel	VA-01 inline referenzieren	„… nach einem definierten Incident-Verfahren (siehe {{LINK:VA-01}}) … behandelt und dokumentiert."	{{LINK:VA-01}}
F6	R04	1.6.3	M/S/H/V	Krisenmanagement generisch; VA-02 nur im Anhang	G3, G8	mittel	VA-02 inline; Übungsfrequenz in Baseline	„Ein Krisenmanagement … ist etabliert (Auslösung/Wiederanlauf siehe {{LINK:VA-02}}) (Übungen BL-IR-01)."	{{LINK:VA-02}}, BL-IR-01
F7	R05	2.1.3	M/S	Awareness stark (BL-HR-01); VA-12 nur im Anhang	G3	mittel	VA-12 inline referenzieren	„… mindestens {{REVIEW_CYCLE}} … geschult (Ablauf siehe {{LINK:VA-12}})."	{{LINK:VA-12}}
F8	R08	4.1.1, 4.1.3, 4.2.1	M/S/H/V	JML/Rezertifizierung stark, aber VA-03 nur im Anhang	G3	mittel	VA-03 inline referenzieren	„Benutzerkonten werden über einen definierten Lebenszyklus (Joiner/Mover/Leaver) (siehe {{LINK:VA-03}}) … verwaltet."	{{LINK:VA-03}}
F9	R10	5.2.1	M/S/H	„formales Change-Verfahren … im {{TOOL_TICKET}} (BL-OPS-09)" ohne Inline-Link auf VA-04	G3	mittel	VA-04 inline referenzieren	„Änderungen durchlaufen ein formales Change-Verfahren (siehe {{LINK:VA-04}}) …"	{{LINK:VA-04}}
F10	R02	1.3.4	M/S/V	„Liste zugelassener Software (Whitelist) … im ISMS-Tool" ohne Register-ID, Lieferant/Freigabestatus	G8, G4	mittel	REG-SW-WHITELIST mit Lieferant- UND Asset-Kopplung	siehe A-N3 (Miss #3)	REG-SW-WHITELIST
F11	R02 / R12	1.3.3 / 5.3.4	M/S	„Freigabeliste im ISMS-Tool" für externe/Cloud-/KI-Dienste — generisch	G8, G4	mittel	Gemeinsames REG-EXT-SERVICES mit Schutzbedarf/Exit/Lieferant	siehe A-N6	REG-EXT-SERVICES, {{LINK:VA-11}}
F12	R03	1.5.1, 1.5.2	M/S	Audits „nach einem Auditplan"; kein Audit-Verfahren, keine Verortung/Frequenz	G2, G4, G8	mittel	Audit-Verfahren (VA-15) + Audit-Programm-Register + Baseline-Frequenz	siehe A-F12	Neue VA-15, REG-AUDIT-PLAN, BL-GOV-01
F13	R11	5.3.1, 5.3.2	M/S/H/V	Security-by-Design/Abnahme, aber keine VA; 5.3.2 „über ein Verfahren umgesetzt"	G4, G1	mittel	VA-16 (Sichere Beschaffung/Entwicklung & Abnahme) inline	siehe A-F13	Neue VA-16
F14	R09 / R10	5.1.2 / 5.2.7	M/S/H	„Netzplan/Segmentierungskonzept wird gepflegt", „Netzdienste identifiziert" — ohne Register-ID	G2, G8	niedrig	Verwaltetes Netz-/Netzdienste-Register mit Turnus	„… ein aktueller Netzplan/Segmentierungskonzept wird im {{LINK:REG-NET}} gepflegt (Review {{REVIEW_CYCLE}})."	REG-NET
F16	R06	2.1.4	M/S/H	„Mobiles Arbeiten ist in einer Regelung festgelegt" — welche, wo?	G2, G1	niedrig	Regelung konkret benennen/verorten	„Mobiles Arbeiten ist in der Regelung mobiles Arbeiten (im ISMS-Tool ({{TOOL_NAME}}) hinterlegt) festgelegt …"	{{TOOL_NAME}}
F17	— (Tooling)	—	—	mapping.json ohne implementation-Feld (0/316); Integrationsleitfaden §5/§8 setzt es voraus (Assessment-Export)	G6	mittel	Feld implementation ergänzen oder Leitfaden korrigieren (impl_anchor-Auflösung dokumentieren)	siehe A-F17	mapping.json / 00_Integrationsleitfaden_Wizard.md
F18	Alle (elev)	div.	H/V	-elev-Blöcke mischen HOCH- und SEHR-HOCH-Sätze unter einem FLAG_ELEVATED_PROTECTION; bei nur HOCH erscheint „Bei sehr hohem Schutzbedarf …"	G6, G7	niedrig	SEHR-HOCH-Sätze in {{#if FLAG_VERY_HIGH_PROTECTION}} auslagern	siehe A-F18	R04/R08/R10 u. a. -elev-Blöcke
F19	R13	6.1.2	M/S	NDA-Prozess stark; VA-10 deckt 6.1.2-M1/S1, IMPL nicht inline	G3	niedrig	VA-10 auch bei NDA inline referenzieren	„… gültige NDAs auf Basis geprüfter Standardvorlagen (Ablauf siehe {{LINK:VA-10}}) …"	{{LINK:VA-10}}
F21	VA-10	6.1.x	—	RACI-Schritttexte in der Tabelle abgeschnitten („… (Schutzb", „…(Selbstauskunft/Nac")	G6	niedrig	Spaltentext vervollständigen	RACI-Schrittbezeichnungen ausschreiben	VA-10
R-1..R-11	R01/R04/R05/R08/R10/R11	div.	—	Rendering-Doppelartikel „im {{TOOL_TICKET/TOOL_NAME/TOOL_IAM}}" → „im das …"	G6	mittel	Präposition anpassen (siehe §6)	„… dokumentiert im Ticketsystem ({{TOOL_TICKET}}) …" bzw. „… im {{TOOL_TICKET}}" → „… in {{TOOL_TICKET}}"-Muster entschärfen	§6

---

5. Empfohlene neue VAs / Register

5.1 Neue Verfahrensanweisungen

ID	Titel	Zweck	Betroffene Controls	Priorität
VA-19 (NEU, Miss #1)	Informationssicherheit in Projekten	Projektklassifizierung nach dokumentiertem Kriterienkatalog; Risikobewertung in früher Phase & bei Änderungen; Maßnahmenableitung/-verfolgung; Pflege des Projektregisters; ISB-Einbindung bei erhöhtem Schutzbedarf	1.2.3 (M1, S1–S3, H1)	hoch
VA-14	Personalsicherheit – Eignungsprüfung & sensible Tätigkeiten	Definition sensibler Bereiche; Einstellungs-/Verifizierungsprozess (Identität, Referenzen, Führungszeugnis im rechtlich zulässigen Rahmen); Umgang mit Verstößen gegen IS-/Vertraulichkeitspflichten	2.1.1 (M1–M3, S1–S2), 2.1.2	hoch
VA-15	Interne Audits & Complianceprüfungen	Auditprogramm, -planung, Durchführung, Berichterstattung, Maßnahmenverfolgung; unabhängige Überprüfung	1.5.1 (M1–M5, S1), 1.5.2 (M1–M2, S1)	mittel
VA-16	Sichere Beschaffung, Entwicklung & Abnahme	Sicherheitsanforderungen in Design/Beschaffung/Änderung; Abnahmetests; (bei Eigenentwicklung) Secure-Coding/SAST/Dependency-Scan; Testdaten-Handling	5.3.1 (M1–M4, S1–S5, V1), 5.3.2	mittel
VA-17 (optional)	Zutritts- & Besuchermanagement (physisch)	Vergabe/Entzug Zutrittsrechte, Besucherregistrierung/-begleitung, Umgang mit Betriebsmitteln	3.1.1 (S1–S5), 3.1.3	niedrig
VA-18 (optional)	Datenschutz- & Compliance-Pflege	Rechtsregister-Review, Löschfristen/Löschkonzept, Betroffenenrechte, VVT-Pflege	7.1.1, 7.1.2	niedrig

5.2 Neue / zu formalisierende Register

Register-ID	Inhalt / Pflichtattribute	Cross-Link	Ersetzt heutige Formulierung in	Priorität
REG-SW-WHITELIST (Miss #3)	Software, Version/Patch-Stand, Quelle/Lieferant/Dienstleister, Freigabestatus, Freigeber/Verantwortlich, Review-Datum	R13/VA-10 (Lieferant steuerbar) + R02/VA-08 (als Asset geführt)	R02 1.3.4 („Liste zugelassener Software")	mittel
REG-EXT-SERVICES (Miss #3 analog)	Externe/Cloud/KI-Dienste: Schutzbedarf, Datenlokation (EU), Verschlüsselung, Exit-Strategie, Quelle/Lieferant, Freigabestatus, Freigeber	R13/VA-10 + R02/VA-08	R02 1.3.3; R12 5.3.4 / 5.3.4-KI; R13 6.1.3	mittel
REG-SENS-ROLES	Sensible Tätigkeitsbereiche/Rollen, geforderte Eignungsnachweise, Prüftiefe	R05/VA-14	R05 2.1.1	hoch
REG-PROJECTS (NEU, Miss #1)	Projekte, IS-Klassifizierung, Risikobewertung, abgeleitete Maßnahmen/Status, ISB-Einbindung	R01/VA-19	R01 1.2.3	hoch
REG-CRIT-SERVICES	Kritische IT-Dienste, BIA-Einstufung, RTO/RPO, Abhängigkeiten, Wiederanlaufreihenfolge	R04/VA-02	R04 5.2.8; R13 6.1.3	mittel
REG-NET	Netzplan/Segmentierung, Netzdienste, Zonen, Review-Turnus	R09/R10, VA-07	R09 5.1.2; R10 5.2.7	niedrig
REG-AUDIT-PLAN	Auditprogramm: Zeitplan, Umfang, geprüfte Controls, Prüfer, Ergebnisse	R03/VA-15	R03 1.5.1 (S1)	mittel

Mehrere „Register" existieren heute implizit als Datensätze im ISMS-Tool. Empfehlung: als benannte, verwaltete Register mit Register-ID führen und über {{LINK:REG-…}} konsistent referenzieren (analog zur Baseline-/VA-Mechanik). Dazu Link-Auflösungstabelle (Integrationsleitfaden §6) und ggf. variables.schema.json um die neuen Ziele erweitern.

5.3 Ergänzung Baseline

BL-ID	Parameter	Vorschlag
BL-GOV-01	Audit-/Prüfzyklus	Interne Prüfung {{REVIEW_CYCLE}}; unabhängige Prüfung/Assessment mind. alle 3 Jahre bzw. nach grundlegenden Änderungen
BL-IR-01	Krisen-/Notfallübungen	Tabletop {{REVIEW_CYCLE}} (HOCH); Vollübung mit Entscheidungsträgern (SEHR HOCH)
BL-PROJ-01	Projekt-Klassifizierungskriterien	Dokumentierter Kriterienkatalog zur IS-Klassifizierung von Projekten (Auslöser/Schwellen für ISB-Einbindung)

---

6. Konsistenz-/Rendering-Befunde (G6)

Ursache: Mehrere Variablen-Defaults beginnen bereits mit einem Artikel: {{TOOL_TICKET}}=„das Ticketsystem", {{TOOL_NAME}}=„das ISMS-Tool", {{TOOL_IAM}}=„das zentrale Verzeichnis (Entra ID / Active Directory)", {{TECH_MDM}}=„das eingesetzte MDM", {{TECH_MFA}}=„die eingesetzte MFA-Lösung" usw. Steht davor eine kontrahierte Präposition („im", „in"), entsteht beim Rendern ein Doppelartikel („im das Ticketsystem") bzw. ein Kasus-Fehler.

Konkrete Fundstellen (Datei : Zeile — Control):

#	Fundstelle	Muster (rendert zu)	Control
R-1	R01_ISMS-Organisation-und-Rollen.md:110	„im {{TOOL_TICKET}}" → „im das Ticketsystem" (2× in der Zeile)	1.2.3
R-2	R04_Incident-…:69	„im {{TOOL_TICKET}} bzw. ISMS-Tool" (Doppelartikel + doppeldeutiger Ort G2)	1.6.1
R-3	R04_Incident-…:126	„im {{TOOL_TICKET}}" → „im das Ticketsystem"	1.6.2
R-4	R05_Personalsicherheit-…:111	„im {{TOOL_NAME}}" → „im das ISMS-Tool"	2.1.3
R-5	R08_Identitaets-…:45	„im {{TOOL_TICKET}}" → „im das Ticketsystem"	4.1.1
R-6	R08_Identitaets-…:153	„in {{TOOL_IAM}}" → „in das zentrale Verzeichnis …" (Doppelartikel + Kasus: müsste „im zentralen Verzeichnis")	4.1.3
R-7	R08_Identitaets-…:199	„im {{TOOL_TICKET}}" → „im das Ticketsystem"	4.2.1
R-8	R10_Betriebssicherheit.md:57	„im {{TOOL_TICKET}}" → „im das Ticketsystem"	5.2.1
R-9	R10_Betriebssicherheit.md:203	„im {{TOOL_TICKET}}" → „im das Ticketsystem"	5.2.5
R-10	R11_Sichere-Systembeschaffung-…:67	„im {{TOOL_TICKET}}" → „im das Ticketsystem"	5.3.1
R-11	R01_…:110 (2. Vorkommen)	„als Aufgaben im {{TOOL_TICKET}} nachgehalten" → „im das …"	1.2.3

Zusätzlich doppeldeutig verortet (G2, „… bzw. ISMS-Tool"): R01:110 („im {{TOOL_TICKET}} bzw. ISMS-Tool") und R04:69 („Formular im {{TOOL_TICKET}} bzw. ISMS-Tool"). Diese Stellen brechen den Grundsatz „ein Nachweisort je Sachverhalt" und sind Auslöser der Herabstufung von 1.2.3 (und Mitgrund bei 1.6.1).

Grammatikalisch unkritisch (kein Fix nötig) sind Vorkommen ohne kontrahierte Präposition, z. B. „über {{TOOL_IAM}}", „und {{TOOL_TICKET}}", „{{TOOL_TICKET}}-Aufträge" — hier passt der eingebettete Artikel bzw. es entsteht keine Doppelung.

Empfohlener Fix (zwei Varianten):

• Variante A (Text): Präpositionsmuster „im {{VAR}}" → „in {{VAR}}" bzw. Artikel explizit ausschreiben: „im Ticketsystem ({{TOOL_TICKET}})". Bei R08:153 zusätzlich Kasus/Präposition „im {{TOOL_IAM}}" verwenden.
• Variante B (Daten): Variablen-Defaults ohne führenden Artikel definieren ({{TOOL_TICKET}}=„Ticketsystem") und Artikel im Fließtext setzen. Achtung: wirkt global auf alle Fundstellen; nur konsistent umsetzen.

---

7. Priorisierte Roadmap

Priorität 1 — Inhalts-GAPs & Fehleinstufungen mit hoher Auditrelevanz:

1. N1 / VA-19 / REG-PROJECTS — R01 1.2.3 Informationssicherheit in Projekten: VA anlegen, Kriterienkatalog (BL-PROJ-01) + Projektregister formalisieren, eindeutigen Ort setzen, Rendering fixen. (Miss #1)
2. G-B1 / VA-14 / REG-SENS-ROLES — R05 2.1.1 Personalsicherheit konkretisieren.
3. G-B2 — R07 3.1.3 leeren Anforderungsblock beheben; ISA-Scope 3.1.2/3.1.3 klären; Mapping ergänzen oder Stub entfernen.

Priorität 2 — Nachweiskette & Konsistenz (geringer Aufwand, hoher Nutzen): 4. F3–F9, F19, N4, N7, N9 — Inline-Verlinkung der Verfahren in den 15 Umsetzungstexten vereinheitlichen (VA-01/02/03/04/06/07/08/09/10/12). 5. §6 / R-1..R-11 — Rendering-Doppelartikel {{TOOL_TICKET}} u. ä. beheben; doppeldeutige Orte („bzw. ISMS-Tool") auflösen. (Miss #2) 6. F17 — mapping.json ↔ Integrationsleitfaden abgleichen (implementation-Feld ergänzen oder Leitfaden korrigieren).

Priorität 3 — Register formalisieren (Reifegrad): 7. F10/F11/N5/N6/N7 / REG-SW-WHITELIST, REG-EXT-SERVICES, REG-CRIT-SERVICES, REG-NET — verwaltete Register mit Pflichtattributen + {{LINK:REG-…}}; REG-SW-WHITELIST/REG-EXT-SERVICES mit Lieferant- UND Asset-Kopplung. (Miss #3) 8. F12 / VA-15 / REG-AUDIT-PLAN / BL-GOV-01 und F13 / VA-16 — Audit- und Secure-Development-Verfahren.

Priorität 4 — Feinschliff: 9. N2, N3, N8, F14, F16, F18, F21 — Verstoß-Verfahren verorten; VA-17/VA-18 (optional); Netz-/mobile-Regelung verorten; SEHR-HOCH-{{#if}}-Trennung; VA-10 RACI-Text.

---

8. Anhang: Einfügefertige Textvorschläge

Alle Vorschläge im bestehenden Stil (Variablen {{…}}, Baseline-/VA-/Register-Verweise), nicht eingepflegt.

A-N1 — R01 §3.3 (ISA 1.2.3), IMPL 1.2.3 (Ersatztext, Miss #1)

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.

Ergänzung Abschnitt 8 „Verwandte Dokumente" von R01: - Zugehörige Verfahren: {{LINK:VA-19}}; Register: {{LINK:REG-PROJECTS}}

Hinweis: Damit entfällt die doppeldeutige Verortung („{{TOOL_TICKET}} bzw. ISMS-Tool"), der Kriterienkatalog wird als Baseline-Artefakt (BL-PROJ-01) geführt, und die fehlende VA/das fehlende Register werden geschlossen.

A-G-B1 — R05 3.1 (ISA 2.1.1), IMPL 2.1.1 (Ersatztext)

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.

A-G-B2 — R07 3.2 (ISA 3.1.3) Anforderungsblock (heute leer)

(a) Falls 3.1.3 im ISA-Scope ist — Anforderungstext + Anker ergänzen und mapping.json-Einträge nachziehen:

<!-- REQ 3.1.3-M1 -->

• [MUSS] Der Umgang mit unterstützenden Betriebsmitteln (z. B. Verkabelung, Strom-/Klimaversorgung, Serverräume) ist bestimmt; Schutz gegen Ausfall, Wartung und Überwachung sind geregelt.

(b) Falls 3.1.3 nicht im Scope ist — Abschnitt 3.2 samt IMPL-Stub entfernen, damit kein Umsetzungstext ohne zugehörige Anforderung/Mapping verbleibt.

In beiden Fällen: Klären, ob ISA 3.1.2 bewusst ausgelassen ist (fehlt in R07 und mapping.json) und dokumentieren.

A-N3 — R02 3.4 (ISA 1.3.4), IMPL 1.3.4 (REG-SW-WHITELIST, Miss #3)

Software (inkl. Spezial-/Wartungssoftware) wird vor Einsatz freigegeben. Zugelassene Software wird im Register Software-Whitelist ({{LINK:REG-SW-WHITELIST}}) mit Version/Patch-Stand, Quelle/Lieferant, Freigabestatus und Freigeber geführt; jeder Eintrag ist mit dem verantwortlichen Lieferanten ({{LINK:VA-10}} / {{LINK:R13}}) und – als verwaltetes Asset – mit dem Asset-Inventar ({{LINK:VA-08}} / {{LINK:R02}}) verknüpft. Beschaffung/Freigabe läuft über {{TOOL_TICKET}}; Repositorys sind gegen Manipulation geschützt; Verantwortlich: {{ROLE_IT_LEAD}}; Review {{REVIEW_CYCLE}}.

A-N6 — R12 3.1 (ISA 5.3.4 / 5.3.4-KI), IMPL (REG-EXT-SERVICES)

… Cloud-/KI-Dienste werden vor Nutzung bewertet (Schutzbedarf, Datenlokation/EU, Verschlüsselung, Exit) und von {{ROLE_ISB}} freigegeben; Freigaben werden im Register externe IT-/Cloud-/KI-Dienste ({{LINK:REG-EXT-SERVICES}}) mit Schutzbedarf, Datenlokation, Quelle/Lieferant, Freigabestatus und Freigeber geführt und mit Lieferantensteuerung ({{LINK:VA-10}}) sowie Asset-Inventar ({{LINK:VA-08}}) verknüpft (Ablauf siehe {{LINK:VA-11}}); die ausschließliche Nutzung freigegebener Dienste wird {{REVIEW_CYCLE}} geprüft.

A-N8 — R14 (ISA 7.1.2), IMPL 7.1.2 (Datenschutz-Pflege-VA)

… 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; Verantwortlich: {{ROLE_DPO}}.

A-F12 — R03 3.2 (ISA 1.5.1), IMPL 1.5.1 (VA-/Register-Verweis)

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}}.

A-F13 — R11 3.1 (ISA 5.3.1), IMPL 5.3.1 (VA-Verweis)

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}}

A-F17 — mapping.json / Integrationsleitfaden

Variante 1 (Daten an Leitfaden angleichen): je Anforderung ein Feld implementation mit dem gebündelten Umsetzungstext (bzw. eindeutiger Kennung des Control-IMPL-Blocks) aufnehmen, damit der Assessment-Export (§8, „Implementation description") direkt aus mapping.json speisbar ist.

Variante 2 (Leitfaden an Daten angleichen, geringerer Aufwand): In §5/§8 dokumentieren, dass implementation nicht in mapping.json liegt, sondern zur Laufzeit über impl_anchor (control-gebündelter Anker IMPL <control>) aus der jeweiligen .md aufgelöst wird. Zusätzlich klären: Für Control 1.1.1 ist impl_anchor == req_anchor (kein IMPL 1.1.1-Block; Leitlinien-Prosa) — diese Sonderauflösung im Leitfaden explizit ausweisen.

A-F18 — Trennung SEHR-HOCH in -elev-Blöcken (Muster)

Statt eines gemeinsamen {{#if FLAG_ELEVATED_PROTECTION}}-Blocks, der HOCH- und SEHR-HOCH-Sätze mischt:

{{#if FLAG_HIGH_PROTECTION}} … HOCH-Umsetzungssätze … {{/if}} {{#if FLAG_VERY_HIGH_PROTECTION}} … „Bei sehr hohem Schutzbedarf …" … {{/if}}

So erscheint der SEHR-HOCH-Umsetzungstext nur, wenn auch die zugehörigen [SEHR HOCH]-Anforderungen im Set sind (betrifft u. a. IMPL 1.2.2-elev, 1.6.2-elev, 1.6.3-elev, 4.1.2-elev, 4.2.1-elev, 5.1.2-elev, 5.2.4-elev, 5.2.6-elev, 5.2.9-elev, 6.1.1-elev).

---

9. Positiv-Befunde (zur Absicherung, kein Handlungsbedarf)

• Baseline-Disziplin: konkrete Werte durchgängig in Technische-Sicherheits-Baseline.md zentralisiert (31 BL-IDs); Umsetzungstexte referenzieren korrekt (z. B. R08 4.1.2 → BL-IAM-01/02, R10 5.2.9 → BL-OPS-05).
• Vorbildliche Referenzketten: 5.1.1, 5.2.4, 5.2.8, 5.2.9, 6.1.1 verbinden IMPL ↔ VA ↔ Baseline eindeutig — Zielbild für die übrigen Controls.
• Mapping-Integrität: 316 REQ-Anker ↔ 316 Mapping-IDs, keine Waisen (verifiziert); VA-FULFILLS-Header stimmen mit mapping.json → verfahren überein.
• Schutzbedarf: -elev-Abdeckung für alle Controls mit HOCH/SEHR-HOCH-Anforderungen vorhanden (Trennungs-Feinschliff siehe F18).
• KI-/GenAI-Ergänzung (R12 3.2) inhaltlich stark und aktuell (Datenklassen je Dienst, kein Training auf Eingaben, Human-in-the-Loop, EU AI Act) — die Herabstufung von 5.3.4-KI betrifft ausschließlich die Register-Formalisierung, nicht den Sachinhalt.