Patch-Dokumentation

„Wir haben das letzte Quartal alle kritischen Patches eingespielt." Beweise es. Das ist der Sinn der Patch-Dokumentation: nachvollziehen, welcher Patch wann von wem auf welchem System installiert wurde. Sie ist gleichzeitig Pflicht (Audits, ISO 27001, BSI-Grundschutz, Versicherungen), Werkzeug (für Troubleshooting: „seit wann tritt das Problem auf?") und Schutz (im Schadensfall ist der lückenlose Patch-Stand juristisch entlastend). Das Problem in der Praxis: Patch-Daten sind verteilt – ein Teil im Change-Ticket, ein Teil im Patch-Tool-Log, ein Teil in der CMDB, ein Teil im Compliance-Report. Diese Lektion zeigt dir, was in einen guten Patch-Dokumentations-Eintrag gehört, welche Information in welches System gehört (die Was-wo-Matrix) und welche Rahmenwerke das fordern.

1) Warum Patch-Dokumentation überhaupt?

Vier Gründe, die immer wieder gelten:

• Compliance/Audit. ISO 27001 (A.12.6.1), BSI IT-Grundschutz (OPS.1.1.3 Patch- und Änderungsmanagement), DSGVO Art. 32 (Stand der Technik), branchenspezifische Standards (BAIT, KRITIS, KAIT) – alle fordern nachvollziehbares Patch-Management.
• Troubleshooting. Bei Incidents: „Was wurde in den letzten 72 h auf diesem System geändert?" Ohne Doku: Stundenlanges Raten. Mit Doku: 30-Sekunden-Antwort.
• Forensik nach Sicherheitsvorfall. Bei einem Cyberangriff fragt jeder Externe als erstes: „War das System aktuell gepatcht?" Wer das nicht belegen kann, wirkt fahrlässig.
• Reporting / KPIs. Patch-Compliance-Quote, Mean Time to Patch – aus Doku-Daten errechnet, siehe Patch-Compliance.

2) Anatomie eines Patch-Dokumentations-Eintrags

Realistisches Beispiel eines konkreten Patch-Tickets. Klick die Annotationen, um zu sehen, was jedes Feld leistet:

3) Welche Information gehört wohin?

Patch-Doku besteht aus vielen Datenpunkten – die meisten haben ein natürliches Heimat-System. Die folgende Matrix zeigt, welche Information üblicherweise in welchem System gepflegt wird. Klick eine Zelle für Details:

4) Konkrete Systeme und ihre Rollen

5) Compliance-Anforderungen im Detail

Verschiedene Rahmenwerke stellen ähnliche, aber nicht identische Anforderungen:

6) Aufbewahrungsfristen

Wie lange müssen Patch-Dokumentation aufbewahrt werden?

• Allgemein: mindestens für die Dauer des Anlagen-Lebenszyklus + 1 Jahr (Standard-IT-Compliance).
• Bei DSGVO-Bezug: 3 Jahre (allgemeine zivilrechtliche Verjährung).
• Bei Steuer-relevanten Systemen: 10 Jahre (GoBD/HGB).
• Bei Banken-/Versicherungs-IT: 10 Jahre (BAIT/VAIT).
• Forensik-relevante Logs: mindestens 1 Jahr revisionssicher.

7) Patch-Reports – typische Inhalte

• Monthly Patch Report – was wurde diesen Monat gepatcht, was steht noch offen.
• Compliance Dashboard – Patch-Quote nach System, Abteilung, Standort. Live-Anzeige.
• CVE-Heat-Map – welche CVEs sind in der Umgebung noch detektierbar? Aufschlüsselung nach Kritikalität.
• SLA-Erfüllung – Anteil der Patches, die innerhalb der vereinbarten Frist installiert wurden.
• Mean Time to Patch (MTTP) – Durchschnittliche Zeit von Patch-Verfügbarkeit bis vollständigem Rollout.
• Audit-Auszug – auf Anfrage erstellbarer Bericht mit allen Patches einer Zeitperiode.

Mehr zu Reports in Patch-Compliance und Reporting.

8) Antipatterns

• „Wir dokumentieren, indem wir das Patch-Tool anschauen." Funktioniert, bis das Tool wechselt oder die Logs rollen. Permanente Doku im Ticketsystem ist Pflicht.
• Verteilte Doku ohne System. Tickets in JIRA, Patches in MECM, CMDB in Confluence-Tabelle. Keine Korrelation. Lösung: definierte Quellsysteme, automatisierte Verknüpfung (z. B. RFC-ID in MECM-Job-Name).
• Patch wird gemacht, kein Ticket dafür. „Mal eben". Bei Audit ein Albtraum – ein Patch ist immer ein Change. Lösung: kein Zugriff auf Produktion ohne RFC.
• Backout nicht dokumentiert. Patch ging schief, wurde zurückgerollt, niemand hat es aufgeschrieben. Bei nächstem Versuch wird der Fehler wiederholt. Lösung: Backout ist Teil des PIR.
• Test-Ergebnisse nur im Kopf. Tester probiert, „läuft" – kein Log, kein Screenshot, keine Zeitstempel. Bei Problemen kein Nachweis. Lösung: Test-Logs ans Ticket anhängen.
• Doku zu spät. Patch installiert, Doku „später ergänzen" – wird nie ergänzt. Lösung: Doku ist Pflicht-Bestandteil des Workflows, nicht Optional.
• Persönliche Notizen statt System. „Steht alles in meinem OneNote" – Mitarbeiter wechselt, Wissen weg. Lösung: zentrale Systeme.

Zusammenfassung

Patch-Dokumentation ist Pflicht für Compliance (ISO 27001, BSI, DSGVO, BAIT, PCI DSS), Troubleshooting („was wurde wann geändert?"), Forensik nach Vorfällen und KPI-Reporting. Ein vollständiger Patch-Eintrag enthält: Patch-ID, Patch-Typ, CVE-Bezug, betroffene CIs, Hersteller-Quelle, Wellen-Rollout-Daten, durchführende Person, Test-Ergebnisse, Backout-Plan + tatsächliche Backouts, Post-Implementation Review, Lessons Learned. Daten sind verteilt über mehrere Systeme: Ticket-System (RFC, Genehmigung, Tests), CMDB (Patch-Stand pro CI), Patch-Tool-Logs (Rohdaten der Installation), Reports (aggregierte KPIs), Vulnerability-Scanner (Verifikation), SIEM (Langzeit-Aufbewahrung). Aufbewahrungsfristen: 3-10 Jahre je nach Branche. Antipatterns: nur im Tool dokumentieren, Patches ohne Ticket, Backouts nicht dokumentieren, Test-Ergebnisse nicht festhalten, Doku „später" nachholen, persönliche Notizen statt System.

Verwandte Lektionen: Patch-Compliance & Reporting · CMDB · Change Management · und mehrWeitere relevante LektionenPatch-Management-ProzessRollbackCVE/CVSSKEDBServer-DokumentationTOMsTicketsysteme