SIGNAL · Operative Resilienz
SAP-Patchtag: Kritische Lücken brauchen Prozessverantwortung

SAP veröffentlichte am 8. September 2026 19 neue Security Notes und ein Update. Vier der neuen Schwachstellen sind als kritisch eingestuft. Die höchste Bewertung, CVSS 10.0, betrifft Extended Passport Processing. Weitere kritische Einträge betreffen den NetWeaver Message Server, die CAP-Komponente sap/cds-mtxs und SAP GUI for Java.

Für ein Unternehmen ist damit noch nicht bewiesen, dass es betroffen ist. Aber es reicht, um eine Führungsfrage auszulösen: Können Betrieb, Sicherheit und Prozessverantwortung innert Stunden denselben belastbaren Status liefern?

Eine CVE ist noch keine Risikoentscheidung

Die CVSS-Bewertung beschreibt technische Schwere. Sie beantwortet nicht, ob die betroffene Komponente im Unternehmen installiert, erreichbar oder für einen kritischen Geschäftsprozess relevant ist. Zwischen der SAP-Note und einer Risikoentscheidung liegen Inventar, Konfiguration, Exponierung und Prozessabhängigkeit.

Genau dort scheitern Patchprozesse oft. Das Team kennt den Patch. Die Geschäftsleitung erhält aber keine Antwort darauf, ob Auftragsabwicklung, Finanzabschluss, Produktion oder Kundenzugang gefährdet sind, falls der Patch nicht sofort eingespielt werden kann.

Der Status braucht einen verantwortlichen Namen

Für jede kritische Note sollte es einen gemeinsamen Entscheidungsstand geben: Ist die Komponente vorhanden? Welcher Geschäftsprozess hängt daran? Wer verantwortet die technische Umsetzung? Wer akzeptiert das Betriebsrisiko bis zur Behebung? Und welche Massnahmen reduzieren die Gefährdung in der Zwischenzeit?

Diese Fragen sind keine zusätzliche Bürokratie. Sie verhindern, dass ein technischer Patchtag zu einer ungeklärten Betriebsunterbrechung oder zu einer späten Überraschung für die Geschäftsleitung wird.

Kompensierende Kontrollen sind kein Freipass

Wenn ein Patch wegen Tests, Wartungsfenster oder Abhängigkeiten nicht sofort möglich ist, braucht es eine nachvollziehbare Zwischenlösung. Je nach Architektur können eingeschränkte Erreichbarkeit, Segmentierung, strengere administrative Zugriffe, verstärktes Monitoring oder vorbereitete manuelle Fallback-Prozesse sinnvoll sein. Welche Massnahme trägt, muss die Organisation für ihre konkrete Landschaft prüfen.

Entscheidend ist die zeitliche Begrenzung. Eine temporäre Risikobehandlung ohne Eigentümer, Enddatum und Rückmeldung zum Patchfortschritt wird schnell zum Dauerzustand.

Konsequenz

Der nächste Lagebericht zum SAP-Patchtag sollte nicht mit einer Note-Liste enden. Er sollte zeigen, welche kritischen Komponenten abgeglichen wurden, welche Geschäftsprozesse betroffen sein könnten, welchen Umsetzungsplan es gibt und wer ein verbleibendes Risiko verantwortet. Erst dann wird aus Patchmanagement operative Resilienz.

Quellen

Autor

Dieser Beitrag stammt von Martin Bischoff, Interim CIO/CISO für regulierte Organisationen in der DACH-Region und Herausgeber von STOP.LI. Für die Umsetzung steht seine Gesellschaft 4T2 Solutions GmbH zur Verfügung.

Comments are closed