Files
craftvia/seed/isms-vorlagenpaket-v2/verfahren/VA-04_Change-und-Patch-Management-Verfahren.md
msolarczekandClaude Opus 5 c8e6f30a27
CI / build-and-check (push) Canceled after 0s
CI / audit (push) Canceled after 0s
CI / sbom (push) Canceled after 0s
Basis: Certvia dev@a48c5fb als Fundament für Craftvia
Unveränderter Stand von certvia/dev (a48c5fb) plus Craftvia-Spezifikation
und Brandbook unter docs/craftvia/. ISMS-Module werden im Folgecommit entfernt.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-14 11:05:39 +02:00

72 lines
2.7 KiB
Markdown

# Change- und Patch-Management-Verfahren
| Dokumenteninformation | Wert |
|-----------------------|------|
| Dokumententyp | Verfahrensanweisung (VA-04) |
| 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.2.1-M1, 5.2.5-M1, A.7.13-1, A.8.19-1, A.8.32-1, A.8.9-1 | POLICY R10 -->
## 1. Zweck
Dieses Verfahren regelt geplante Änderungen an IT-Systemen sowie das risikoorientierte Einspielen von Patches. Es operationalisiert die zugehörige Richtlinie ({{LINK:R10}}).
## 2. Geltungsbereich
Gilt innerhalb des ISMS-Geltungsbereichs ({{ISMS_SCOPE_DESCRIPTION}}).
## 3. Auslöser
Änderungsbedarf, verfügbarer Patch oder identifizierte Schwachstelle (VA-06).
## 4. Eingaben
- Change-/Patch-Antrag
- Risikoeinschätzung
- Patch-SLA (BL-OPS-01)
## 5. Ablauf
1. Change beantragen & klassifizieren (Standard/Normal/Notfall) im {{TOOL_TICKET}}.
2. Risiko-/Auswirkungsbewertung inkl. Rollback-Plan.
3. Genehmigung durch CAB/verantwortliche Rolle.
4. Test in getrennter Umgebung (BL-OPS, R10).
5. Umsetzung in Produktion gemäß Patch-SLA (kritisch {{PATCH_SLA_CRIT}}).
6. Verifikation & Dokumentation des Ergebnisses im {{TOOL_TICKET}}.
## 6. RACI
| # | Schritt | R (Durchführung) | A (Rechenschaft) | C (Konsultiert) | I (Informiert) |
|---|---------|------------------|------------------|-----------------|----------------|
| 1 | Change beantragen & klassifizieren (Stan | Antragsteller | {{ROLE_IT_LEAD}} | - | - |
| 2 | Risiko-/Auswirkungsbewertung inkl. Rollb | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
| 3 | Genehmigung durch CAB/verantwortliche Ro | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - |
| 4 | Test in getrennter Umgebung (BL-OPS, R10 | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | - |
| 5 | Umsetzung in Produktion gemäß Patch-SLA | {{ROLE_IT_LEAD}} | {{ROLE_IT_LEAD}} | - | Betroffene |
| 6 | Verifikation & Dokumentation des Ergebni | {{ROLE_IT_LEAD}} | {{ROLE_ISB}} | - | - |
## 7. Ergebnis & Nachweis
Dokumentierte, genehmigte und verifizierte Änderung/Patch im {{TOOL_TICKET}}. Nachweise werden im zentralen Nachweisregister ({{LINK:NACHWEISREGISTER}}) referenziert.
## 8. Kennzahlen (KPI)
- Patch-Compliance je Kritikalität
- Anteil erfolgreicher Changes (ohne Rollback)
- Durchlaufzeit kritischer Patches
## 9. Verwandte Dokumente
- Zugehörige Richtlinie: {{LINK:R10}}
- {{LINK:VA-06}}
- 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. -->