EVB-IT-Wartungsverträge: Warum die leeren Felder teurer sind als die Klauseln

Ende Dezember 2027 endet der kostenlose Sicherheitssupport für TYPO3 v13 LTS. Danach bestehen zwei Wege: der Bezug kostenpflichtiger ELTS-Leistungen oder ein Upgrade auf eine dann unterstützte Version.

Für Hochschulen, die gerade relauncht haben, liegt dieses Datum mitten in der Laufzeit ihres Wartungsvertrags. Und die Frage, wer den Wechsel bezahlt, ist im Zweifel längst beantwortet, nämlich im Kleingedruckten der EVB-IT Service-AGB.

Dort werden Patch, Update, Upgrade und neues Release zwar einzeln definiert, dann aber unter einem Oberbegriff zusammengefasst: Programmstand. Wird im Vertragsformular die Überlassung neuer Programmstände weitreichend vereinbart, ohne Updates und Hauptversionswechsel gegeneinander abzugrenzen, kann daraus die Pflicht entstehen, auch neue Hauptversionen zu installieren, zu integrieren und vorhandene Anpassungen zu übertragen. Ob das von der Wartungspauschale gedeckt ist, hängt von der Auswahl im Formular und von der vereinbarten Vergütungsregelung ab.

Im ungünstigen Fall heißt das: Erhebliche Portierungsleistungen werden von der monatlichen Pauschale erfasst. Ein Vorhaben, das je nach Zahl der Extensions und Testaufwand einen erheblichen fünfstelligen Aufwand erreichen kann, steckt dann in einer Position, die für Monitoring und Sicherheitsupdates kalkuliert wurde.

Ein sorgfältig kalkulierender Bieter wird das nicht übersehen. Er macht das Risiko zum Gegenstand einer Bieterfrage, er berücksichtigt es kalkulatorisch, oder er sieht von einer Angebotsabgabe ab. In jedem dieser Fälle zahlt die Hochschule dafür, dass ein Feld leer geblieben ist.

Die EVB-IT sind besser als ihr Ruf

Das ist keine Anklage gegen das Regelwerk. Die EVB-IT sind durchdacht, und sie sind gerade spürbar besser geworden.

Der IT-Planungsrat hat im November 2025 eine umfassende Überarbeitung beschlossen, veröffentlicht wurde sie im März 2026. Betroffen sind acht der elf Vertragstypen, darunter Pflege S, Dienstleistung, System, Erstellung und Service. Die neuen Muster berücksichtigen Open-Source-Software ausdrücklich. Zudem lässt sich eine Software Bill of Materials als Vertragsleistung vereinbaren, was sowohl die Lizenz-Compliance als auch die Reaktion auf Sicherheitslücken unterstützt.

Für Hochschulen ist das ein Gewinn. Die Vergabestelle muss keinen IT-Vertrag von Grund auf entwerfen, die Risikoverteilung ist bekannt, das Regelwerk greift auf etablierte vertragsrechtliche Kategorien und langjährig verwendete Muster zurück, und die Bieter wissen vorher, worauf sie sich einlassen. Bei einem Auftrag im sechsstelligen Bereich ist das viel wert.

Ein Vertragstyp für agile Entwicklung fehlt allerdings weiterhin. Den gab es vor der Reform nicht und danach auch nicht. Wer iterativ arbeiten will, baut sich das aus den vorhandenen Typen zusammen.

Das Regelwerk ist ein Fragebogen

Hier liegt der Punkt, den ich in der Praxis am häufigsten übersehen sehe.

Ich habe die Vorbehaltsformeln in der Fassung 2.0.0 der Service-AGB ausgezählt und komme auf 70 Stellen. Allein „soweit nichts anderes vereinbart“ steht 25 mal im Text, „soweit vereinbart“ 16 mal, dazu knapp 30 konditionale Varianten. Die Ziffer zur Haftungsbeschränkung stellt sich selbst ausdrücklich unter den Vorbehalt, dass keine andere Haftungsvereinbarung getroffen wurde. Die Ziffer zur Preisanpassung nennt ihre Konditionen nur für den Fall, dass nichts anderes vorgesehen ist.

Diese Stellen sind gewollt. Die AGB regeln, was gelten soll, wenn die Parteien schweigen, und laden zugleich dazu ein, etwas Projektspezifisches an ihre Stelle zu setzen. Der dafür vorgesehene Ort ist das Vertragsformular selbst, samt seinem Feld für sonstige Vereinbarungen.

Daraus folgt zweierlei, und beides ist unbequem.

Die Voreinstellung ist keine neutrale Wahl. Sie ist auf den Regelfall geeicht und nicht auf dieses Projekt. Wer sie stehen lässt, hat eine Entscheidung getroffen, ohne es zu merken. Der Upgrade-Fall oben ist davon die teuerste Variante.

Und ein beigefügtes Dienstleister-SLA setzt sich nicht von allein durch. Die Vertragsbedingungen des Landes NRW etwa bestimmen, dass anderslautende Geschäftsbedingungen des Auftragnehmers nicht Vertragsbestandteil werden. Wirksam wird ein solches Dokument erst, wenn es ausdrücklich in das Auftragsschreiben oder das EVB-IT-Formular einbezogen und seine Stellung in der Rangfolge eindeutig bestimmt ist. Am sichersten stehen projektspezifische Abweichungen unmittelbar im Formular oder in einer dort ausdrücklich benannten Anlage.

Damit steht die übliche Erzählung auf dem Kopf. Der Vorwurf lautet meist, die EVB-IT seien zu starr für moderne Zusammenarbeit. Tatsächlich sind sie beweglicher, als sie aussehen. Woran es hakt, ist die Bereitschaft, die Felder zu füllen.

Warum die Entscheidung vorher fallen muss

Der naheliegende Einwand: Man kann das doch später regeln, wenn sich zeigt, was gebraucht wird.

Ausgeschlossen ist das nicht, aber es wird eng. § 132 GWB zieht die Grenzen für Änderungen an einem laufenden öffentlichen Auftrag, und wesentliche Änderungen können ein neues Vergabeverfahren erfordern. Absehbare Anpassungen, Optionen und Überprüfungsmechanismen gehören deshalb klar, genau und eindeutig in die Vergabeunterlagen. Soweit die Leistungen über eine Rahmenvereinbarung im Anwendungsbereich der VgV beschafft werden, kommt hinzu, dass deren Laufzeit grundsätzlich vier Jahre nicht überschreitet.

Deshalb trägt der Pragmatismus auf Arbeitsebene nur begrenzt. Man kennt sich, man regelt das, und es funktioniert bis zum Personalwechsel im Dezernat oder bis zur nächsten Rechnungsprüfung. Wer den Spielraum nicht von Anfang an anlegt, muss jede spätere Änderung an den engeren Voraussetzungen des § 132 GWB messen lassen.

Umgekehrt lässt sich Beweglichkeit sehr wohl ausschreiben. Ein monatliches Kontingent darf während der Laufzeit angepasst werden, wenn die Vergabeunterlagen dafür einen klar beschriebenen Mechanismus mit Umfangsgrenzen und Vergütungsfolgen vorsehen und der Gesamtcharakter des Auftrags unverändert bleibt. Ein festes Entscheidungsdatum für die Upgrade-Frage funktioniert nach demselben Muster. Beides schafft der Hochschule Planungssicherheit.

Sechs Felder, die über die Zusammenarbeit entscheiden

Aus der Arbeit mit Wartungs- und Serviceverträgen kommen immer wieder dieselben Stellen zurück. Sie kosten die Vergabestelle nichts und entscheiden darüber, ob der Vertrag über Jahre trägt.

Leistungsart zuordnen

Die Service-AGB stufen Serviceleistungen im Regelfall als Werkleistung mit Erfolgsverantwortung ein, kennen daneben aber ausdrücklich Dienstleistungen mit milderen Rechtsfolgen. Monitoring, Bereitschaft und laufende Beratung lassen sich als Dienstleistungen ausgestalten. Je stärker dagegen ein konkreter Erfolg geschuldet wird, desto eher spricht das für Werkvertragsrecht, etwa bei Entwicklung oder Wiederherstellung. Maßgeblich ist nicht die Bezeichnung, sondern der konkret vereinbarte Leistungsinhalt. Eine saubere Zuordnung erspart beiden Seiten die Dauerfrage, was abnahmepflichtig ist und wann eine Rechnung fällig wird, und sie wirkt gleichzeitig auf Mängelrechte und Vergütungsfälligkeit.

Erledigungszeiten nur dort vereinbaren, wo sie beherrschbar sind

Die Service-AGB kennen zwei Fristen. Die Reaktionszeit bestimmt, wann mit der Serviceleistung begonnen werden muss. Die Erledigungszeit ist die Frist für den erfolgreichen Abschluss. Wer zusätzlich eine reine Eingangsbestätigung oder eine vorläufige Priorisierung will, muss sie gesondert definieren und eindeutig vom Beginn der technischen Bearbeitung abgrenzen, sonst verschwimmen die Stufen.

Heikel ist die Erledigungszeit. Pauschal über alle Störungsklassen gesetzt, kann sie den Dienstleister zur erfolgreichen Erledigung binnen Frist verpflichten, auch wenn die Ursache in Community-Code liegt, den er weder geschrieben hat noch steuern kann. Sinnvoll ist sie dort, wo der Auftragnehmer die Ursache tatsächlich beherrscht, etwa bei eigenem Code oder der Konfiguration. Für alles andere ist die Auffangregel der angemessenen Frist die sachgerechtere Lösung. Diese Unterscheidung gehört ausdrücklich in den Vertrag, sonst wird sie später zur Auslegungsfrage.

Upgrades von Updates trennen

Sollen Upgrades und neue Hauptversionen nicht von der Pauschale erfasst sein, muss das im Formular ausdrücklich abgegrenzt werden. Ohne Abgrenzung kann die Vereinbarung neuer Programmstände je nach Reichweite auch weitgehende Installations-, Integrations- und Anpassungsleistungen einschließen. Dazu gehört ein festes Datum, bis zu dem die Hochschule zwischen ELTS-Bezug und Upgrade entscheidet. Die Kompatibilitätsbewertung und den Upgrade-Plan kann man in der Pauschale belassen, das ist Beratungsleistung und gehört dorthin.

Preisanpassung regeln

Wird eine Preisanpassung vereinbart, ohne sie näher auszugestalten, begrenzt Ziffer 13.7 der Service-AGB die Erhöhung grundsätzlich auf drei Prozent. Angekündigt werden kann sie frühestens zwölf Monate nach Leistungsbeginn, wirksam wird sie frühestens drei Monate nach Zugang der Ankündigung. Die erste Erhöhung greift damit praktisch frühestens zum Ablauf des 15. Monats. Bei zwei Jahren Laufzeit bleibt davon wenig übrig, weshalb Bieter einen Risikoaufschlag in den Anfangspreis einrechnen können.

Eine transparent ausgestaltete Anpassungsklausel senkt diese Unsicherheit und damit den Risikoaufschlag. Welcher Index dafür taugt, ist eine Einzelfallfrage: Bei personalintensiven IT-Leistungen liegt ein Lohn- oder Dienstleistungsindex meist näher an der tatsächlichen Kostenentwicklung als der allgemeine Verbraucherpreisindex. Die vergabe- und preisklauselrechtliche Zulässigkeit sollte mitgeprüft werden.

Mitwirkung mit Rechtsfolge versehen

Service Level stehen typischerweise unter Bedingungen: übermittelte Zugangsdaten, ein erreichbares System, ein aktuelles Backup. Fehlt eine notwendige Mitwirkung, kann das Vertretenmüssen des Auftragnehmers schon nach allgemeinen Regeln entfallen. Verlässlicher ist eine ausdrückliche Vereinbarung, nach der die betroffenen Fristen für die Dauer der Behinderung ausgesetzt oder verlängert werden. Sie kostet die Hochschule nichts und erspart die Auseinandersetzung darüber, wer eine Verzögerung verursacht hat.

Budgets sauber trennen

Wird ein Kontingent für Weiterentwicklung ausgeschrieben und sollen zugleich Störungen von demselben Kontingent abgezogen werden, greifen zwei Zwecke auf einen Topf zu. Ein einzelner größerer Vorfall bindet dann das Monatsbudget, und die Roadmap steht still. Getrennte Blöcke erhöhen die Kosten- und Planungstransparenz und verhindern, dass ein außergewöhnlicher Störungsfall das Entwicklungsbudget aufzehrt. Ob sie am Ende günstiger sind, hängt von Preis, Abrufvolumen und Risikoverteilung ab. Sollen sich zusätzlich Haftungsobergrenzen oder Vertragsstrafen allein nach dem betroffenen Leistungsblock bemessen, muss auch das ausdrücklich im Vertrag stehen.

Für die nächste Ausschreibung

Gehen Sie die Vorbehaltsklauseln durch. Jede Stelle mit „soweit nichts anderes vereinbart“ ist eine Entscheidung, die Sie treffen oder verschenken.

Ordnen Sie die Leistungsarten zu, Dienstleistung oder Werkleistung, für jeden Block einzeln und anhand des tatsächlichen Leistungsinhalts. Legen Sie die Support-Enden der eingesetzten Systeme gegen die geplante Vertragslaufzeit und setzen Sie ein Entscheidungsdatum, wo sich beides überschneidet. Nehmen Sie eine Preisanpassungsklausel auf, mit passendem Index, Bagatellgrenze und Deckel. Trennen Sie Kontingente nach Zweck und beschreiben Sie den Anpassungsmechanismus vorab.

Und nehmen Sie Bieterfragen ernst. Wer in der Fragephase auf ein leeres Feld hinweist, liefert eine Vorabprüfung, die sonst später Geld kostet.

Zum Schluss

Die EVB-IT ersticken keine Zusammenarbeit. Sie regeln, was gilt, wenn niemand hinsieht, und sagen an Dutzenden Stellen selbst dazu, dass man es anders regeln darf.

Zäh werden Wartungsverträge durch die Entscheidungen, die niemand getroffen hat. Der Aufwand, sie zu treffen, fällt einmal an, bei der Erstellung der Vergabeunterlagen. Der Aufwand, sie zu vermeiden, fällt jeden Monat an, verteilt auf Rückfragen, Angebote über wenige Stunden und irgendwann die eine große Rechnung, mit der niemand gerechnet hatte.

Stand: September 2026. Die Angaben beziehen sich auf die EVB-IT Service-AGB in der Fassung 2.0.0 vom 01.03.2026. Der Beitrag beschreibt Praxiserfahrungen aus Hochschulprojekten und ersetzt keine Rechtsberatung. Für die konkrete Vertragsgestaltung sollten die Vergabestelle und gegebenenfalls eine vergaberechtliche Beratung eingebunden werden.

Bild: AdobeStock