Software-Wartung für Behörden und öffentliche Auftraggeber

© kaliel

Warum Software-Wartung in Behörden besondere Anforderungen hat

Behörden betreiben Software unter Rahmenbedingungen, die sich grundlegend von der Privatwirtschaft unterscheiden. Drei Faktoren machen die Software-Wartung im öffentlichen Sektor besonders anspruchsvoll:

Vergaberecht: Wartungsleistungen müssen ausgeschrieben oder über Rahmenverträge beschafft werden. Spontane Dienstleisterwechsel oder kurzfristige Beauftragungen ohne formales Verfahren sind nicht zulässig. Das erfordert vorausschauende Planung – ein auslaufender Wartungsvertrag ohne Nachfolgelösung kann Fachverfahren gefährden.

Regulatorische Dichte: NIS-2, DSGVO, BITV, BSI-Grundschutz und das Onlinezugangsgesetz (OZG) erzeugen ein Geflecht von Anforderungen, die sich direkt auf die laufende Wartung auswirken. Sicherheitsupdates sind keine Kür, sondern Pflicht – mit dokumentierter Nachvollziehbarkeit.

Langlebigkeit der Systeme: Fachverfahren in der Verwaltung sind häufig über Jahrzehnte im Einsatz. Die Wartung muss Technologiewechsel, Personalfluktuation beim Dienstleister und sich ändernde Standards überdauern.

Mehr zu softwareseitigen Wartungsthemen und Softwaremodernisierung kann im Leitfaden zu Application Management nachgelesen werden.

EVB-IT: Vertragsrahmen für die öffentliche Hand

Was ist der EVB-IT Servicevertrag?

Die Ergänzenden Vertragsbedingungen für IT (EVB-IT) sind Musterverträge, die von der öffentlichen Hand für die Beschaffung von IT-Leistungen entwickelt wurden. Für die laufende Software-Wartung ist vor allem der EVB-IT Servicevertrag relevant. Er regelt wiederkehrende IT-Dienstleistungen wie Monitoring, Fehlerbehebung, Updates und Support.

Der EVB-IT Servicevertrag bietet eine standardisierte Struktur, die beiden Seiten Sicherheit gibt:

• Klare Leistungsbeschreibung mit messbaren Qualitätskriterien
• Definierte Reaktions- und Wiederherstellungszeiten
• Regelungen zur Mitwirkung des Auftraggebers
• Vertragsstrafen bei Nichterfüllung
• Regelungen zu Vertraulichkeit und Datenschutz

EVB-IT in der Vergabepraxis

In der Praxis werden EVB-IT-Verträge häufig als Grundlage in Ausschreibungsunterlagen verwendet und dann an die spezifischen Anforderungen des Fachverfahrens angepasst. IT-Verantwortliche sollten dabei auf folgende Punkte achten:

• Leistungsabgrenzung: Was ist Wartung, was ist Weiterentwicklung? Diese Grenze muss im Vertrag eindeutig sein, da Weiterentwicklung unter Umständen separat ausgeschrieben werden muss.
• Laufzeit und Verlängerung: EVB-IT-Verträge haben in der Regel feste Laufzeiten. Die rechtzeitige Planung einer Anschlussvergabe – mindestens 12 Monate vor Vertragsende – verhindert Versorgungslücken.
• Übergabe und Dokumentation: Der Vertrag muss regeln, welche Dokumentation der Dienstleister bei Vertragsende übergibt: Quellcode, technische Dokumentation, Betriebshandbücher, Monitoring-Konfigurationen.

Regulatorische Anforderungen an die laufende Wartung

NIS-2 und Software-Wartung

Die NIS-2-Richtlinie verpflichtet Betreiber wesentlicher und wichtiger Einrichtungen zu einem systematischen Umgang mit Cybersicherheitsrisiken. Für viele Behörden und behördennahe Einrichtungen bedeutet das: Die laufende Software-Wartung ist kein optionaler Service, sondern ein nachweispflichtiger Bestandteil des IT-Sicherheitsmanagements.

Konkret wirkt sich NIS-2 auf Wartungsverträge in folgenden Bereichen aus:

• Patch-Management: Sicherheitsupdates müssen zeitnah eingespielt werden. Der Wartungsvertrag muss Fristen definieren – z. B. kritische Patches innerhalb von 72 Stunden.
• Schwachstellenmanagement: Der Dienstleister muss bekannte Schwachstellen in eingesetzten Komponenten proaktiv identifizieren und melden.
• Incident Response: Bei Sicherheitsvorfällen muss der Dienstleister innerhalb definierter Zeiten reagieren und dokumentieren. Diese Anforderung muss vertraglich verankert sein.
• Lieferkettensicherheit: NIS-2 fordert die Bewertung von Risiken in der Lieferkette. Der Wartungsdienstleister ist Teil dieser Kette und muss seine eigenen Sicherheitsmaßnahmen nachweisen können.

DSGVO und Wartungszugriff

Jeder Wartungszugriff auf ein System, das personenbezogene Daten verarbeitet, ist datenschutzrechtlich relevant. Der Wartungsvertrag muss deshalb einen Auftragsverarbeitungsvertrag (AVV) nach Art. 28 DSGVO enthalten oder referenzieren. Folgende Punkte sind zu klären:

• Welche Daten kann der Dienstleister bei der Wartung einsehen?
• Wie wird der Zugriff protokolliert?
• Werden Daten in Testumgebungen übertragen – und wenn ja, anonymisiert?
• Wo befinden sich die Server des Dienstleisters (Stichwort: Drittlandtransfer)?

BITV und barrierefreie Updates

Die BITV 2.0 verpflichtet Behörden zur digitalen Barrierefreiheit. Das hat direkte Auswirkungen auf die Wartung: Jedes Update, jede Änderung an der Benutzeroberfläche muss die Barrierefreiheitsanforderungen einhalten. Der Wartungsvertrag sollte deshalb festlegen:

• Accessibility-Tests als Bestandteil jedes Release-Prozesses
• Dokumentation des Barrierefreiheitsstatus nach jedem Update
• Verpflichtung zur Behebung von Accessibility-Regressionen innerhalb definierter Fristen

Weiterführende Informationen zum Thema WCAG und Barrierefreiheit finden sich im Leitfaden zu den WCAG-Richtlinien.

BSI-Grundschutz

Behörden, die nach IT-Grundschutz des BSI arbeiten, müssen Wartungsprozesse in ihr Sicherheitskonzept einbetten. Das betrifft insbesondere das Änderungsmanagement (Change Management), die Dokumentation von Systemzuständen und die regelmäßige Überprüfung der Wirksamkeit technischer Maßnahmen.

Praxis: Wartungsvertrag für Fachverfahren strukturieren

Fachverfahren – von der elektronischen Akte über Meldewesen bis zu Geoinformationssystemen – haben spezifische Wartungsanforderungen. Ein praxistauglicher Wartungsvertrag für Behörden sollte folgende Struktur haben:

Leistungsmodule definieren

Statt eines monolithischen Vertrags empfiehlt sich eine modulare Struktur:

• Basismodul: Monitoring, Sicherheitsupdates, Fehlerbehebung, Verfügbarkeitssicherung
• Erweiterungsmodul Compliance: Dokumentation für Audits, Barrierefreiheitstests, Datenschutz-Protokollierung
• Erweiterungsmodul Betrieb: Nutzerverwaltung, Datenbankpflege, Backup-Management
• Optionsmodul Weiterentwicklung: Kleinere Anpassungen innerhalb eines Stundenkontingents

Diese Modularisierung erleichtert die Vergabe, weil einzelne Module bei Bedarf separat ausgeschrieben oder angepasst werden können.

Reaktionszeiten staffeln

Nicht jedes Problem erfordert dieselbe Dringlichkeit. Eine bewährte Staffelung:

Für kritische Fachverfahren sollte die Vereinbarung auch Bereitschaftszeiten außerhalb der Geschäftszeiten abdecken.

Dokumentation und Nachweispflichten

Behörden müssen jederzeit nachweisen können, dass ihre Systeme dem Stand der Technik entsprechen. Der Wartungsvertrag sollte deshalb regelmäßige Berichte vorsehen:

• Monatlicher Wartungsbericht mit Patch-Status, Verfügbarkeitswerten und offenen Tickets
• Quartalsweise Sicherheitsbewertung der eingesetzten Komponenten
• Jährlicher Service-Review mit Bewertung der SLA-Erfüllung

Diese Berichte dienen nicht nur der internen Steuerung, sondern sind auch bei Prüfungen durch Rechnungshöfe, Datenschutzbeauftragte oder Aufsichtsbehörden relevant.

Typische Fallstricke bei der Behördenwartung

Vertragslücke zwischen Projekt und Wartung: Viele Fachverfahren werden im Rahmen eines Projekts entwickelt und abgenommen – aber der Wartungsvertrag wird erst Monate später geschlossen. In dieser Lücke entstehen Sicherheitsrisiken und ungeklärte Verantwortlichkeiten.

Fehlende Übergaberegelung: Wenn ein Dienstleister wechselt und keine strukturierte Übergabe vereinbart wurde, geht Betriebswissen verloren. Das kann bei spezialisierten Fachverfahren den Betrieb über Wochen beeinträchtigen.

Wartung ohne Testumgebung: Updates direkt auf dem Produktivsystem einzuspielen ist riskant – aber in der Praxis nicht selten, wenn keine Testumgebung vorgesehen oder budgetiert wurde. Der Wartungsvertrag sollte eine Testumgebung als Voraussetzung definieren.

Unterschätzter Barrierefreiheitsbedarf: Interface-Änderungen im Rahmen der Wartung können bestehende Barrierefreiheit zerstören. Ohne automatisierte und manuelle Accessibility-Checks nach jedem Release entsteht ein schleichendes Compliance-Problem.

Weiterführende Informationen

• Application Management: Optimierung und Risikominimierung
• Legacy Software modernisieren
• Service-Level-Agreements (SLAs) in der Praxis