Change undRemediation Workflow.
Diese Klasse führt die kontrollierte Umsetzung technischer Änderungen, etwa nach einem Patch-, Exposure- oder Konfigurationsbefund. Sie bewertet Auswirkung, verantwortet Freigabe, hält Umsetzung und Rückfallweg fest und schliesst erst mit einem nachvollziehbaren Ergebnis.
Von der Feststellung
zur wirksamen Änderung.
Patch Management liefert und verteilt Updates. Vulnerability Management bewertet Befunde. Der Change-Workflow hält die operative Entscheidung und die Wirkung der Umsetzung über Systeme und Teams hinweg zusammen.
Die Klasse ist kein eigener Markt neben ITSM. Change und Remediation sind Fähigkeiten umfassender Service-Management-Plattformen. Verglichen wird daher die Ausprägung dieser Fähigkeit.
Zehn Plattformen mit Change-Kontext.
| Plattform | Belegte Abdeckung | Typischer Schwerpunkt | Im Pilot klären |
|---|---|---|---|
| ServiceNow ITSM | Change, Incident, Problem, CMDB, Workflow | Enterprise Change Enablement | Standard-, Normal- und Emergency Change, CMDB-Bezug |
| BMC Helix ITSM | Change, Release, CMDB, ITSM | Enterprise und Hybrid | Modulgrenzen, Freigabemodell und Release-Prozess |
| Xurrent | Change, Incident, Problem, Request, Workflow | SaaS-Service Management | Change-Vorlagen, Servicekontext und Remediation-Übergabe |
| Jira Service Management | Change, Incident, Assets, DevOps-Integration | Entwicklung und Betrieb | Change Calendar, Deployment-Integration und Freigaben |
| Freshservice | Change, Workflow, CMDB, ITAM | Cloud-ITSM | Vorlagen, Automatisierung und Edition |
| ManageEngine ServiceDesk Plus | Change, Release, Problem, CMDB | Integriertes ITSM | Cloud oder On-Premises und Workflow-Tiefe |
| EasyVista EV Service Manager | ITSM, Change, Orchestration, CMDB | Service und Automatisierung | Modulzuschnitt und Orchestrierung |
| HaloITSM | Change, Problem, Asset, Workflow | Konfigurierbares ITSM | Freigaben, Audit Trail und Integrationen |
| OpenText SMAX | Change, Release, CMDB, Workflow | Enterprise Service Management | Architektur, Bereitstellung und Produktpakete |
| Ivanti Neurons for ITSM | ITSM, Workflow, Asset, Self Service | Service und Endpoint-Umfeld | Aktuelle Modulgrenzen und Betriebsmodell |
Vom Befund
zur geschlossenen Schleife.
- Wiederkehrende, risikoarme Korrekturen (z. B. monatliche Updates, Standardhärtungen) als vorab freigegebene Standard-Changes definieren, damit das Change Advisory Board sich auf Einzelfälle konzentriert.
- Einen Notfallpfad für aktiv ausgenutzte Schwachstellen festlegen: wer freigibt, welche Tests mindestens nötig sind und innert welcher Frist die Dokumentation nachgeführt wird.
- Befund-ID und Change-ID technisch verknüpfen, damit jeder Befund bis zur Umsetzung verfolgbar ist.
- Den Befund erst schliessen, wenn ein erneuter Scan oder eine Messung den neuen Zustand bestätigt.
- Anteil sicherheitsbezogener Changes, die nach der Umsetzung technisch verifiziert wurden
- Zeit von der Befundfreigabe bis zur Umsetzung je Risikoklasse
- Anteil Notfall-Changes mit fristgerecht nachgeführter Dokumentation
Der Service Owner entscheidet über Zeitpunkt und Risiko der Änderung, der Change Manager verantwortet den Prozess. Betriebsteams setzen um, Security priorisiert die Befunde.
ISO/IEC 27001:2022 Annex A 8.32 (Änderungsmanagement) und 8.8 (technische Schwachstellen); DORA Art. 9 Abs. 4 lit. e verlangt risikobasierte Verfahren, damit Änderungen an IKT-Systemen erfasst, getestet, bewertet, genehmigt, umgesetzt und verifiziert werden.
ISO/IEC 20000-1:2018 stellt Anforderungen an das Change Management als Teil des Service-Management-Systems; für Banken in der Schweiz unterstützt der Workflow den Nachweis zum IKT-Änderungsmanagement nach FINMA-RS 2023/1.
Mehr Freigabestufen machen Changes nicht sicherer. Lange Freigabewege verzögern Sicherheitskorrekturen; das Risiko senken Tests, Rückfallweg und Verifikation, nicht zusätzliche Unterschriften.
Die kritische Änderung testen.
- Befund bis Change: Einen echten Vulnerability- oder Exposure-Befund in einen verantworteten Change überführen.
- Auswirkung: Betroffene Services, Owner, Wartungsfenster und Rückfallweg müssen sichtbar sein.
- Abschluss: Umsetzung, Wirksamkeitsprüfung und offene Restpunkte voneinander unterscheiden.
Patch Management und Vulnerability Management bleiben die fachlichen Quellen für Befunde und technische Behandlung.
Security Tool Navigator · Gebiet 14
Im Gebiet Service Operations und Workflow einordnen.
Diese Werkzeugklasse gehört zum Gebiet Service Operations und Workflow. Der Gebietshub zeigt, wie die Werkzeugklassen zusammenwirken, wo sie sich abgrenzen und welche Fragen CIO und CISO jeweils klären.