---
title: "Patch-Management: Definition und Compliance-Leitfaden"
description: "Erfahren Sie, wie Sie Patch-Management implementieren, das ISO 27001, SOC 2, NIS2 und DORA erfüllt. Umfasst Patching-Strategien, SLA-Zeitlinien, Schwachstellen-Priorisierung und Compliance-Nachweise."
canonical: https://www.orbiqhq.com/de/glossar/patch-management
html: https://www.orbiqhq.com/de/glossar/patch-management
publisher: Orbiq GmbH
language: en
---
# Patch-Management: Definition und Compliance-Leitfaden

Erfahren Sie, wie Sie Patch-Management implementieren, das ISO 27001, SOC 2, NIS2 und DORA erfüllt. Umfasst Patching-Strategien, SLA-Zeitlinien, Schwachstellen-Priorisierung und Compliance-Nachweise.


## Was ist Patch-Management?

Patch-Management ist der systematische Prozess der Identifizierung, Prüfung und Bereitstellung von Software-Updates zur Behebung von Sicherheitslücken und Fehlern in der IT-Umgebung einer Organisation. Ungepatchte Schwachstellen bleiben einer der am meisten ausgenutzten Angriffsvektoren, wodurch Patch-Management eine der wirksamsten Sicherheitskontrollen ist.

Für compliance-orientierte Organisationen ist Patch-Management eine Kernkontrolle, die von ISO 27001, SOC 2, NIS2 und DORA gefordert wird. Auditoren prüfen spezifisch Patching-Richtlinien, SLA-Konformität und Ausnahmenmanagement.

## Patching-SLA-Framework

| Schweregrad | CVSS-Score | Patch-SLA | Beispiel |
| --- | --- | --- | --- |
| **Kritisch** | 9.0-10.0 | 24-72 Stunden | Remote Code Execution, Zero-Day-Exploits |
| **Hoch** | 7.0-8.9 | 7-14 Tage | Privilege Escalation, Authentifizierungsumgehung |
| **Mittel** | 4.0-6.9 | 30 Tage | Informationsoffenlegung, Cross-Site-Scripting |
| **Niedrig** | 0.1-3.9 | 90 Tage | Geringe Informationslecks, Low-Impact-Bugs |

## Patch-Management-Prozess

| Phase | Aktivitäten | Ergebnis |
| --- | --- | --- |
| **Entdeckung** | Verfügbare Patches aller Hersteller identifizieren | Patch-Inventar mit Schweregraden |
| **Bewertung** | Anwendbarkeit und Risiko jedes Patches evaluieren | Priorisierte Patch-Liste |
| **Test** | Patches in Staging-Umgebung auf Kompatibilität testen | Testergebnisse und Freigabe |
| **Planung** | Bereitstellungsfenster planen, Rollback-Pläne vorbereiten | Bereitstellungsplan und Change-Requests |
| **Bereitstellung** | Patches auf Produktionssysteme ausrollen | Bereitstellungsbestätigungslogs |
| **Verifizierung** | Scannen zur Bestätigung, Funktionalität testen | Post-Patch-Scan-Ergebnisse |
| **Berichterstattung** | Compliance dokumentieren, Ausnahmen verfolgen | Patch-Compliance-Bericht |

## Patch-Compliance-Metriken

| Metrik | Ziel | Messmethode |
| --- | --- | --- |
| **Patch-Compliance-Rate** | > 95% | Innerhalb SLA gepatchte Systeme ÷ Gesamtsysteme |
| **Mittlere Patch-Zeit (kritisch)** | < 72 Stunden | Durchschnittliche Tage von Release bis Bereitstellung |
| **Abdeckung kritischer Patches** | 100% | Kritische Patches innerhalb SLA angewendet |
| **Ausnahmenanzahl** | < 5% der Assets | Systeme mit genehmigten Ausnahmen |
| **Patch-Fehlerrate** | < 2% | Patches, die Rollback erfordern |

## Compliance-Anforderungen

### Framework-Zuordnung

| Anforderung | ISO 27001 | SOC 2 | NIS2 | DORA |
| --- | --- | --- | --- | --- |
| Schwachstellenmanagement | A.8.8 | CC7.1 | Art. 21(2)(e) | Art. 9(2) |
| Zeitnahes Patching | A.8.8 | CC7.1 | Art. 21(2)(e) | Art. 9(2) |
| Change Management | A.8.32 | CC8.1 | Art. 21(2)(e) | Art. 9(4)(e) |
| Risikobewertung | A.8.8 | CC3.2 | Art. 21(2)(a) | Art. 9(1) |

### Auditnachweise

| Nachweistyp | Beschreibung | Framework |
| --- | --- | --- |
| Patch-Management-Richtlinie | Dokumentierte Richtlinie mit SLAs nach Schweregrad | Alle Frameworks |
| Patch-Compliance-Berichte | Monatliche Berichte zur SLA-Einhaltung | Alle Frameworks |
| Ausnahmenregister | Dokumentierte Ausnahmen mit Risikoakzeptanz und Behebungsplänen | Alle Frameworks |
| Schwachstellen-Scan-Ergebnisse | Vor- und Nach-Patch-Scan-Vergleiche | Alle Frameworks |
| Change-Records | Change-Tickets für Patch-Bereitstellungen | ISO 27001, SOC 2 |
| Testergebnisse | Nachweis der Patch-Tests vor Produktionsbereitstellung | Alle Frameworks |

## Häufige Fehler

| Fehler | Risiko | Lösung |
| --- | --- | --- |
| Keine definierten Patching-SLAs | Keine Verantwortlichkeit für Patching-Geschwindigkeit | Schweregrad-basierte SLAs in Richtlinie dokumentieren |
| OS patchen, Anwendungen nicht | Drittanbieter-Schwachstellen werden ausgenutzt | Alle Software in Patch-Scope einbeziehen |
| Kein Staging-Umgebungstest | Patches stören Produktionssysteme | In Staging vor Produktionsbereitstellung testen |
| Firmware und IoT ignorieren | Netzwerkgeräte und IoT bleiben verwundbar | Firmware in Patch-Inventar einbeziehen |
| Nur manuelles Tracking | Patches werden verpasst, Compliance-Lücken unentdeckt | Automatisierte Patch-Management-Tools nutzen |

## Wie Orbiq Patch-Management-Compliance unterstützt

Orbiq hilft Ihnen, Patch-Management-Kontrollen nachzuweisen:

- **Nachweissammlung** — Zentralisieren Sie Patch-Richtlinien, Compliance-Berichte und Ausnahmenregister
- **Kontinuierliches Monitoring** — Verfolgen Sie Patch-Compliance-Raten und SLA-Einhaltung
- **Trust Center** — Teilen Sie Ihre Schwachstellenmanagement-Postur über Ihr [Trust Center](/de/glossar/trust-center)
- **Compliance-Mapping** — Ordnen Sie Patching-Kontrollen ISO 27001, SOC 2, NIS2 und DORA zu
- **Audit-Bereitschaft** — Vorgefertigte Nachweispakete für Auditorenprüfungen

## Weiterführende Informationen

- [Schwachstellenmanagement](/de/glossar/vulnerability-management) — Umfassender Schwachstellen-Lebenszyklus
- [Endpoint Security](/de/glossar/endpoint-security) — Endpunktschutz einschließlich Patching
- [Cloud Security](/de/glossar/cloud-security) — Patching in Cloud-Umgebungen
- [DevSecOps](/de/glossar/devsecops) — Automatisiertes Patching in CI/CD-Pipelines
- [Incident Response](/de/glossar/incident-response) — Reaktion auf durch ungepatchte Schwachstellen verursachte Vorfälle