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/verfahren/VA-16_Sichere-Beschaffung-Entwicklung-und-Abnahme.md

@@ -0,0 +1,72 @@
+# Sichere Beschaffung, Entwicklung & Abnahme
+
+| Dokumenteninformation | Wert |
+|-----------------------|------|
+| Dokumententyp | Verfahrensanweisung (VA-16) |
+| Geltungsbereich | {{ISMS_SCOPE}} |
+| Organisation | {{ORG_NAME}} |
+| Prozessverantwortlich | {{ROLE_IT_LEAD}} |
+| Freigabe durch | {{ROLE_ISB}} |
+| Version | {{DOC_VERSION}} |
+| Datum | {{DOC_DATE}} |
+| Status | {{DOC_STATUS}} |
+
+<!-- FULFILLS 5.3.1-M1, 5.3.1-M2, 5.3.1-M3, 5.3.1-M4, 5.3.1-S1, 5.3.1-S2, 5.3.1-S3, 5.3.1-S4, 5.3.1-S5, 5.3.1-V1, 5.3.2-M1, 5.3.2-S1, 5.3.2-S2, 5.3.2-S3, 5.3.2-H1 | POLICY R11 -->
+
+## 1. Zweck
+
+Dieses Verfahren stellt sicher, dass Informationssicherheitsanforderungen fester Bestandteil von Beschaffung, Design, Entwicklung, Erweiterung und Änderung von IT-Diensten und -Systemen sind (Security by Design), inklusive Abnahmetests und Testdatenhandhabung. Es operationalisiert die zugehörige Richtlinie ({{LINK:R11}}).
+
+## 2. Geltungsbereich
+
+Gilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}) für Beschaffung, Eigen-/Fremdentwicklung und Änderung von IT-Diensten/Systemen.
+
+## 3. Auslöser
+
+Beschaffung, Neu-/Weiterentwicklung oder wesentliche Änderung eines IT-Dienstes/Systems.
+
+## 4. Eingaben
+
+- Sicherheits-/Schutzbedarfsanforderungen; anwendbare ISA-Controls
+- Test-/Abnahmekonzept
+- Ggf. externe Dienste ({{LINK:REG-EXT-SERVICES}})
+
+## 5. Ablauf
+
+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}}).
+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}}
+
+## 6. RACI
+
+| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
+|---|---------|------------------|------------------|-----------------|----------------|
+| 1 | Sicherheitsanforderungen spezifizieren | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | Fachbereich | - |
+| 2 | Beschaffung/Änderung durchführen | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
+| 3 | Sicherheits-Abnahme / Freigabe | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | Fachbereich | - |
+| 4 | Testdaten-Handling | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | {{ROLE_DPO}} | - |
+| 5 | Secure Coding / Sicherheitstests | Entwicklung | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
+| 6 | Zusätzliche Prüfung (sehr hoher Schutzbedarf) | unabhängiger Prüfer | {{ROLE_ISB}} | {{ROLE_IT_LEAD}} | - |
+
+## 7. Ergebnis & Nachweis
+
+Abnahmeprotokolle, Testberichte und Freigaben (in {{TOOL_TICKET}}). Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
+
+## 8. Kennzahlen (KPI)
+
+- Anteil Projekte mit dokumentierter Sicherheits-Abnahme
+- Kritische Sicherheits-Findings vor Go-Live
+- Anteil Tests ohne echte Produktivdaten
+
+## 9. Verwandte Dokumente
+
+- Zugehörige Richtlinie: {{LINK:R11}}
+- Change-Verfahren: {{LINK:VA-04}}
+- Cloud-/KI-Freigabe: {{LINK:VA-11}}; Register: {{LINK:REG-EXT-SERVICES}}
+- Technische Sicherheits-Baseline: {{LINK:BASELINE}}
+- ISA-Mapping-Matrix: {{LINK:ISA_MAPPING}}
+
+<!-- Erfüllt die oben unter FULFILLS gelisteten Anforderungen; Kopplung in mapping.json. Im Lesemodus nicht sichtbar. -->