Updates, Patches und Pflege vertraglich regeln

Die Fachabteilung meldet eine Sicherheitslücke, der Hersteller verweist auf eine neuere Version und der IT-Einkauf fragt sich, ob deren Bereitstellung vom Wartungsvertrag gedeckt ist. Genau an dieser Stelle zeigen sich unklare Pflegeklauseln. Wenn im Vertrag nur allgemein von „Updates“ oder „Wartung“ die Rede ist, können Anbieter und Kunde sehr unterschiedliche Erwartungen haben. Für dich bedeutet das im schlechtesten Fall: Sicherheitsrisiken bleiben offen, notwendige Leistungen werden gesondert berechnet oder ein Projekt verzögert sich wegen eines ungeplanten Versionswechsels.

Warum allgemeine Wartungszusagen nicht reichen

Viele IT-Verträge enthalten Formulierungen wie „Der Anbieter stellt Updates nach Maßgabe seiner Produktpolitik bereit.“ Das klingt zunächst ausreichend, lässt aber zentrale Fragen unbeantwortet:

• Welche Leistungen sind konkret umfasst?
• Gibt es Sicherheitsupdates für alle eingesetzten Versionen oder nur für die aktuelle Version?
• Wie schnell reagiert der Anbieter auf kritische Schwachstellen?
• Muss der Anbieter ein Update nur bereitstellen oder auch einspielen?
• Wer prüft vorher die Kompatibilität mit Schnittstellen, Eigenentwicklungen und Drittsoftware?
• Wann wird aus einer Pflegeleistung ein kostenpflichtiges Upgrade oder Migrationsprojekt?

Diese Punkte gehören nicht allein in ein Service Level Agreement. Sie betreffen auch den Leistungsgegenstand, Vergütung, Mitwirkungspflichten, Haftung und das Ende des Vertrags. Ein belastbares Regelwerk besteht deshalb meist aus mehreren aufeinander abgestimmten Teilen: Hauptvertrag, Leistungsbeschreibung, Pflegevereinbarung, SLA, Vergütungsregelung und gegebenenfalls einem Betriebs- oder Sicherheitskonzept.

Fehlerbehebung, Update und Upgrade sauber unterscheiden

Die Begriffe werden im Alltag oft vermischt. Vertraglich solltest du sie definieren, statt dich auf das allgemeine Sprachverständnis zu verlassen.

Fehlerbehebung

Fehlerbehebung bedeutet, dass eine vereinbarte Funktion nicht vertragsgemäß arbeitet und wiederhergestellt werden muss. Maßstab ist die geschuldete Beschaffenheit der Software oder des Services. Die Fehlerbehebung kann durch Konfigurationsänderungen, Korrekturen im Code, Workarounds oder Patches erfolgen.

Wichtig ist die Abgrenzung: Nicht jede Änderungsanforderung ist ein Fehler. Wenn ein Fachbereich eine neue Auswertung, ein zusätzliches Rollenmodell oder eine geänderte Schnittstelle verlangt, handelt es sich regelmäßig um eine Erweiterung. Der Vertrag sollte festlegen, wie Fehler klassifiziert werden und wann ein Fehler als behoben gilt.

Eine praxistaugliche Definition kann klarstellen, dass ein Fehler erst dann beseitigt ist, wenn die vereinbarte Funktion wiederhergestellt oder ein zumutbarer, dokumentierter Workaround bereitgestellt wurde. Ob ein Workaround genügt, hängt von der Fehlerklasse ab. Bei einer kritischen Sicherheitslücke wird er oft nicht dauerhaft ausreichen.

Update

Ein Update ist eine Weiterentwicklung innerhalb eines bestehenden Versionsstands. Es kann Fehlerkorrekturen, Verbesserungen, kleinere Funktionsanpassungen und Sicherheitsupdates enthalten. In vielen Modellen sind Updates durch die laufende Pflegevergütung abgedeckt.

Das ist aber nur dann verlässlich, wenn der Vertrag beschreibt, was unter einem Update verstanden wird. Der Anbieter kann sonst argumentieren, dass eine Funktionserweiterung oder eine neue technische Voraussetzung nicht mehr zur Pflege gehört. Du solltest deshalb festhalten, ob Updates unabhängig davon geschuldet sind, ob sie nur Fehler korrigieren oder zusätzliche Funktionen enthalten.

Patch

Ein Patch ist meist eine gezielte, eher begrenzte Änderung. Häufig schließt er Sicherheitslücken oder korrigiert einen konkreten Fehler. Im Vertrag sollte nicht untergehen, dass Patches besonders dringlich sein können. Ein monatlicher Standardzyklus kann für normale Korrekturen sinnvoll sein, für kritische Schwachstellen jedoch zu langsam.

Unterscheide deshalb mindestens zwischen sicherheitskritischen Patches und regulären Patches. Außerdem muss geregelt werden, ob ein Patch für deine eingesetzte Version verfügbar gemacht wird oder ob du zuerst auf eine andere Version wechseln musst.

Upgrade

Ein Upgrade bezeichnet regelmäßig den Wechsel auf eine neue Hauptversion oder einen erheblich erweiterten Leistungsstand. Ein Upgrade kann neue Systemanforderungen, geänderte Datenmodelle, Anpassungen von Schnittstellen und Schulungsbedarf auslösen. Deshalb ist es häufig nicht vollständig in der laufenden Pflege enthalten.

Das darf aber nicht zu einer überraschenden Kostenfalle werden. Der Vertrag sollte transparent sagen, welche Upgrade-Leistungen von der Vergütung umfasst sind und welche Leistungen gesondert beauftragt werden müssen. Dazu gehören insbesondere Planung, Test, Datenmigration, Anpassung von Individualentwicklungen und Produktivsetzung.

Sicherheitspatches: Fristen, Prioritäten und unterstützte Versionen

Die wichtigste Frage lautet nicht nur, ob der Anbieter Sicherheitspatches liefert. Entscheidend ist, wann, für welche Version und in welcher Form er dies tut.

Lege zunächst ein nachvollziehbares Priorisierungsschema fest. Es kann sich an der Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit orientieren. Kritisch sind insbesondere Schwachstellen, die ohne besondere Berechtigung ausnutzbar sind, den Zugriff auf vertrauliche Daten ermöglichen oder den Betrieb wesentlich gefährden.

Für jede Prioritätsstufe sollten mindestens folgende Punkte vereinbart werden:

• Reaktionszeit: Wann bestätigt der Anbieter die Meldung und beginnt mit der Analyse?
• Bereitstellungszeit: Bis wann liefert der Anbieter einen Patch, eine Konfigurationsanweisung oder einen belastbaren Workaround?
• Einspielpflicht: Wer installiert die Maßnahme in Entwicklungs-, Test- und Produktivumgebung?
• Kommunikationspflicht: Welche Informationen erhältst du zu Risiko, Betroffenheit, Abhilfe und möglichen Nebenwirkungen?
• Nachweis: Wie wird dokumentiert, welche Systeme betroffen waren und wann die Maßnahme umgesetzt wurde?

Bei Cloud- und SaaS-Leistungen übernimmt der Anbieter die technische Installation häufig selbst. Das entbindet dich aber nicht von einer klaren Regelung. Der Vertrag sollte festlegen, ob Wartungsfenster gelten, wie der Anbieter über sicherheitsrelevante Änderungen informiert und welche Mitwirkungen du leisten musst, etwa bei Konfigurationsfreigaben oder Funktionstests.

Bei On Premises Software liegt das Einspielen oft bei dir oder deinem Betriebsdienstleister. Dann muss der Anbieter zumindest sicherstellen, dass Patches in geeigneter Form, mit verständlicher Dokumentation und für die vereinbarte Version bereitstehen. Eine bloße Veröffentlichung in einem Kundenportal ist bei kritischen Vorfällen häufig zu wenig, wenn keine aktive Benachrichtigung vorgesehen ist.

Den Versionsstand verbindlich festhalten

Ohne dokumentierten Ausgangsstand kannst du später kaum beurteilen, welche Pflege geschuldet ist. Nimm daher eine Versionsübersicht in die Vertragsunterlagen auf. Sie sollte mindestens enthalten:

• Produktname und eingesetzte Edition
• Hauptversion, Nebenversion und Build-Stand
• Betriebssystem, Datenbank und weitere technische Abhängigkeiten
• eingesetzte Module und Schnittstellen
• individuelle Anpassungen und Erweiterungen
• Status der Unterstützung durch den Hersteller
• Verantwortlichkeit für die Fortschreibung der Dokumentation

Diese Übersicht darf kein einmaliger Anhang bleiben. Vereinbare einen Prozess für Änderungen. Nach jedem Update, Patch oder Upgrade muss nachvollziehbar sein, welcher Stand in welcher Umgebung läuft. Gerade bei mehreren Mandanten, Testsystemen oder internationalen Standorten entstehen sonst schnell Abweichungen.

Besonders wichtig ist die Regelung zum Ende der Unterstützung, oft als „End of Support“ bezeichnet. Der Anbieter sollte dich rechtzeitig informieren, wenn eine Version aus der regulären Pflege fällt. Der Vertrag sollte außerdem sagen, welche Folgen daraus entstehen: Gibt es noch Sicherheitspatches, einen verlängerten Support oder nur noch Unterstützung gegen gesonderte Vergütung? Ohne diese Klarstellung kann der Anbieter berechtigt sein, Patches nur noch für die aktuelle Hauptversion zu liefern.

Pflegepflichten beider Seiten festlegen

Pflege ist keine Einbahnstraße. Der Anbieter kann Updates nur sinnvoll liefern, wenn du deine Umgebung dokumentierst, Ansprechpartner benennst und Tests ermöglichst. Umgekehrt darf der Anbieter notwendige Informationen nicht zurückhalten oder Risiken pauschal auf dich verlagern.

Regle auf Kundenseite insbesondere:

• Wer Updates freigibt und wer sie technisch einspielt.
• Welche Testumgebung vorhanden ist und welche Tests du vor der Produktivsetzung durchführst.
• Innerhalb welcher Frist du Rückmeldungen, Logdaten oder Zugangsdaten bereitstellst.
• Wie du Konfigurationsänderungen und Eigenentwicklungen dokumentierst.
• Wann ein Notfallverfahren greift, wenn ein kritischer Patch nicht regulär getestet werden kann.

Auf Anbieterseite gehören dazu:

• Bereitstellung geprüfter Installationspakete und verständlicher Release Notes.
• Beschreibung von Voraussetzungen, Abhängigkeiten und bekannten Einschränkungen.
• Information über sicherheitsrelevante Änderungen und erforderliche Konfigurationsschritte.
• Rückfallkonzept, falls ein Update zu Störungen führt.
• Unterstützung bei der Ursachenanalyse, wenn Probleme im Zusammenhang mit einem Patch auftreten.

Formulierungen wie „Der Kunde testet eigenverantwortlich“ reichen allein nicht. Sie können dazu führen, dass du das gesamte Risiko eines fehlerhaften Updates trägst. Besser ist eine ausgewogene Regelung: Du führst die vereinbarten Abnahmetests oder Regressionstests durch, der Anbieter steht für die vertragsgemäße Bereitstellung und Dokumentation seiner Leistung ein.

Typische Vertragsfallen vermeiden

Eine häufige Falle ist die Klausel, dass Pflege nur für die „jeweils aktuelle Version“ geschuldet wird. Das kann sachlich gerechtfertigt sein, wenn der Anbieter alte Versionen technisch nicht sinnvoll warten kann. Dann brauchst du aber klare Übergangsfristen und planbare Upgrade-Regeln.

Problematisch sind auch pauschale Ausschlüsse für Schnittstellen, Fremdsoftware oder kundenspezifische Anpassungen. Solche Ausschlüsse können berechtigt sein, dürfen aber nicht unklar bleiben. Definiere, welche Komponenten der Anbieter prüft, für welche Konstellationen er Kompatibilität zusagt und wann ein gesonderter Aufwand entsteht.

Achte außerdem darauf, dass sich die Fehlerpriorisierung nicht allein nach der Einschätzung des Anbieters richtet. Sinnvoll ist ein Verfahren, in dem beide Seiten die Priorität anhand festgelegter Kriterien bestimmen. Bei Streit sollte zunächst eine vorläufige Schutzmaßnahme möglich sein, statt auf eine langwierige Einigung über die Klassifizierung zu warten.

Checkliste für deine Vertragsprüfung

Prüfe vor Unterschrift oder bei der nächsten Vertragsänderung diese Fragen:

• Sind Fehlerbehebung, Updates, Patches und Upgrades eindeutig definiert?
• Ist klar, welche Leistungen von der Pflegevergütung umfasst sind?
• Gibt es verbindliche Zeiten für Reaktion, Bereitstellung und Kommunikation bei Sicherheitslücken?
• Sind unterstützte Versionen und das Ende ihrer Unterstützung dokumentiert?
• Ist geregelt, wer Patches testet, freigibt, installiert und dokumentiert?
• Gibt es ein Verfahren für Notfallpatches außerhalb regulärer Wartungsfenster?
• Sind Abhängigkeiten zu Betriebssystemen, Datenbanken, Schnittstellen und Anpassungen berücksichtigt?
• Besteht ein Rückfallkonzept für fehlgeschlagene Updates?
• Werden Release Notes, Sicherheitsinformationen und bekannte Einschränkungen geschuldet?
• Sind Mehrkosten für Upgrades, Migrationen und Anpassungen transparent geregelt?

Wenn du diese Fragen beantwortest, wird aus einer allgemeinen Wartungszusage ein steuerbarer Betriebsprozess. Passende Seminare und Termine findest du bei uns auf cmt.de.

Eine sorgfältige Vertragsgestaltung ersetzt keine technische Pflegeplanung. Sie schafft aber die Grundlage dafür, dass IT-Betrieb, Informationssicherheit, Einkauf und Rechtsabteilung im Ernstfall wissen, was zu tun ist und wer verantwortlich ist.