Wartungsverträge für Verteidigungssoftware: Was einzubeziehen und zu verhandeln ist

Die meisten Beschaffungsvorgänge für Verteidigungssoftware investieren erheblichen Aufwand in die Akquisitionsphase — technische Bewertung, Quellenauswahl und Vertragsvergabe — und behandeln den Wartungsvertrag als nachrangige Formalität. Das ist rückwärts gedacht. Die Beschaffungsentscheidung legt fest, was Sie kaufen. Der Wartungsvertrag bestimmt, ob Sie es in fünf Jahren noch nutzen können, ob Sie rechtliche Handhabe haben, wenn der Anbieter den Support einstellt, und ob Ihr Programm die Insolvenz des Anbieters übersteht, ohne operative Fähigkeiten zu verlieren.

Ein im Jahr 2026 beschafftes Verteidigungssoftwaresystem wird voraussichtlich noch im Jahr 2036 oder 2040 in Betrieb sein. Der Anbieter, der es entwickelt hat, kann übernommen worden sein, sich einem anderen Markt zugewandt haben oder den Betrieb vollständig eingestellt haben. Die Software wird CVEs angehäuft haben. Das Betriebssystem, auf dem sie läuft, wird mehrere End-of-Life-Zyklen durchlaufen haben. Das Engineering-Team, das sie gebaut hat, wird ausgewechselt worden sein. All das ist nicht ungewöhnlich — es ist schlicht das, was über einen 15-jährigen Programmlebenszyklus geschieht. Ein gut konstruierter Wartungsvertrag für Verteidigungssoftware ist der Mechanismus, der die operative Fähigkeit durch all das hindurch aufrechthält.

Warum Wartungsverträge bei Verteidigungsprogrammen scheitern

Kommerzielle Software-Wartungsvereinbarungen sind für kurzlebige SaaS-Produkte konzipiert, bei denen der Anbieter die Umgebung kontrolliert und der Kunde innerhalb von Wochen den Anbieter wechseln kann. Verteidigungsprogramme teilen fast keine dieser Merkmale. Systeme sind klassifiziert oder arbeiten in luftdicht abgetrennten Umgebungen, in denen externe Wartungsunternehmen nicht einfach auf eine Produktionsinstanz zugreifen können. Austauschzeiträume werden in Jahren gemessen, nicht in Wochen. Die Software kann so umfassend modifiziert worden sein, dass sie dem kommerziellen Produkt des Anbieters kaum noch ähnelt.

Das Ergebnis ist, dass standardmäßige kommerzielle Wartungsvereinbarungen bei Verteidigungsprogrammen auf vorhersehbare Weise versagen. Sie definieren keine Schweregrade, die der operativen Realität entsprechen. Sie behandeln keine Sicherheits-Patch-Zeitpläne für Schwachstellen in Drittanbieter-Abhängigkeiten. Sie verlangen nicht, dass der Anbieter ältere Versionen pflegt, während ein Programm Upgrade-Tests durchläuft. Sie enthalten keine Quellcode-Hinterlegungsklauseln, die es dem Programm ermöglichen würden, fortzubestehen, wenn der Anbieter verschwindet. Und sie beinhalten Ausstiegsklauseln, die einen geordneten Übergang zu einem Ersatzsystem praktisch unmöglich machen.

Diese Versagensmodi zu verstehen, bevor man den Vertrag ausarbeitet, ist der Ausgangspunkt, um die richtigen Bedingungen zu erzielen.

SLA-Struktur: Schweregrade und Reaktionsfenster

Das häufigste Defizit in Wartungsverträgen für Verteidigungssoftware ist eine einzige, undifferenzierte Support-Stufe mit einer vagen Reaktionszeitverpflichtung. Ein System, das einer im Einsatz befindlichen Einheit Lagebewusstsein bietet, erfordert eine grundlegend andere Reaktionsverpflichtung, wenn es vollständig ausfällt, als wenn eine Berichtsexportfunktion ein falsches Datumsformat erzeugt. Beide auf der gleichen Prioritätsstufe zu behandeln, überzahlt entweder bei trivialen Problemen oder unterprotektiert bei echten operativen Ausfällen.

Ein gut strukturiertes Verteidigungs-Software-SLA definiert mindestens drei Schweregrade.

P1 — kritisch

P1 gilt, wenn das System vollständig nicht verfügbar ist, die Datenintegrität gefährdet ist oder eine Sicherheitsschwachstelle aktiv ausgenutzt wird. Der Vertrag sollte eine Erstreaktion — d. h. ein qualifizierter Ingenieur ist eingebunden und hat das Problem bestätigt — innerhalb von ein bis zwei Stunden festlegen. Eine Lösung oder ein dokumentierter Workaround sollte innerhalb von vier bis acht Stunden geliefert werden. P1-SLAs müssen rund um die Uhr gelten, ohne Ausnahmen für Wochenenden, Feiertage oder Zeitzonenunterschiede. Der Vertrag sollte Eskalationskontakte namentlich benennen — nicht nur eine Support-Warteschlange — und festlegen, dass P1-Eskalation Standardaufnahmeprozesse umgeht.

P2 — schwerwiegend

P2 gilt, wenn eine erhebliche Fähigkeit beeinträchtigt ist, das System aber teilweise betriebsfähig bleibt und ein Workaround existiert. Erstreaktion innerhalb von vier Stunden, Lösung innerhalb von 24 bis 48 Stunden. P2-SLAs sollten ebenfalls kontinuierlich gelten, nicht nur während der Geschäftszeiten, da eine beeinträchtigte operative Fähigkeit in einer Einsatzumgebung schnell eskaliert.

P3 — geringfügig

P3 umfasst Fehler mit geringer operativer Auswirkung — falsche Anzeigeausgaben, unkritische Berichtsfehler, kosmetische Probleme. Bestätigung innerhalb eines Werktages, Lösung im nächsten geplanten Wartungs-Release gebündelt. P3 ist das einzige Schweregrade, bei dem eine Messung nach Geschäftszeiten angemessen ist.

Über Reaktionsfenster hinaus sollte der Vertrag Patch-Lieferfristen getrennt von der allgemeinen Fehlerbehebung festlegen. Der Patch-Rhythmus sollte als maximales Intervall zwischen geplanten Wartungs-Releases definiert werden — 90 Tage sind ein gängiger Richtwert für Verteidigungssysteme — mit einer Bestimmung für Notfall-Patches außerhalb des Zyklus bei kritischen Sicherheitsschwachstellen.

Quellcode-Hinterlegung: Kontinuität über Anbieterrisiken hinweg sichern

Die Quellcode-Hinterlegung ist die am meisten unterschätzte Klausel in Verteidigungssoftwareverträgen. Sie ist auch diejenige, die die gravierendsten Folgen hat, wenn sie fehlt. Wenn ein Verteidigungssoftwareanbieter von einem Wettbewerber übernommen wird, der das Produkt einstellt, oder schlicht als Unternehmen scheitert, verliert ein Programm ohne Hinterlegungsklauseln die Fähigkeit, seine eigene Software zu erstellen, zu modifizieren oder eigenständig zu warten. In einer klassifizierten Umgebung, in der der Nachfolgeunternehmer keinen Zugang zur ursprünglichen Entwicklungsumgebung des Anbieters hat, ist dies ohne jahrelangen Neubeschaffungsaufwand keine überwindbare Situation.

Eine Hinterlegungsvereinbarung verpflichtet den Anbieter, den Quellcode der Software, Build-Skripte, Test-Suites, Manifeste für Drittanbieter-Abhängigkeiten und Umgebungsspezifikationen bei einem unabhängigen, akkreditierten Treuhänder zu hinterlegen. Die Hinterlegung wird vom Treuhänder verwahrt und nur dann an die beschaffende Organisation freigegeben, wenn definierte Auslösebedingungen erfüllt sind.

Auslösebedingungen für die Hinterlegung definieren

Auslösebedingungen müssen so präzise sein, dass sie objektiv überprüfbar sind. Standardauslöser sind: Insolvenz oder Insolvenzantrag des Anbieters; Übernahme des Anbieters durch einen Wettbewerber, der das Produkt einstellt; schriftliche Ankündigung des Produktendes durch den Anbieter; sowie jeder kontinuierliche 12-monatige Zeitraum, in dem der Anbieter keine Wartungs-Releases liefert. Vage Bedingungen — „Anbieter stellt den Produktsupport ein" — laden zu Streitigkeiten ein, wenn genau das eintritt. Bedingungen müssen so definiert sein, dass sie ohne Zustimmung des Anbieters geltend gemacht werden können.

Nutzbarkeit der Hinterlegung verifizieren

Eine Hinterlegung, die keinen funktionierenden Build erzeugen kann, ist wertlos. Der Vertrag muss eine jährliche Überprüfung der Hinterlegung verlangen: einen unabhängigen Build-Test, bei dem das hinterlegte Material verwendet wird, um die Software in einer sauberen Umgebung zu reproduzieren. Die beschaffende Organisation oder ein designierter Dritter prüft das Ergebnis. Anbieter, die die jährliche Überprüfung der Hinterlegung nicht bestehen, sollten als vertragsbrüchig betrachtet werden. Hinterlegung ist kein Speicherdienst — sie ist ein Kontinuitätsmechanismus, der nur funktioniert, wenn das hinterlegte Material als erstellbar nachgewiesen ist.

Sicherheits-Patch-Verpflichtungen und CVE-Reaktion

Die Sicherheits-Patch-Anforderungen in den meisten kommerziellen Software-Wartungsvereinbarungen sind für IT-Unternehmensumgebungen geschrieben, in denen Updates in einem wöchentlichen Rhythmus getestet und bereitgestellt werden können. Verteidigungsprogramme können das nicht. Das Testen eines Sicherheits-Patches in einer klassifizierten Umgebung vor der Bereitstellung kann vier bis sechs Wochen dauern. Die Bereitstellung in einem verteilten, luftdicht abgetrennten Netzwerk nimmt zusätzliche Zeit in Anspruch. Der Wartungsvertrag muss diese Asymmetrie berücksichtigen.

Der Ausgangspunkt ist, Patch-Lieferverpflichtungen an CVSS-Schweregrade zu knüpfen. Ein realistischer Richtwert für die Wartung von Verteidigungssoftware: CVSS 9,0–10,0 (kritisch) erfordert eine Anbieterbenachrichtigung innerhalb von 24 Stunden nach öffentlicher Bekanntmachung und einen Patch oder eine dokumentierte Abhilfemaßnahme innerhalb von 72 Stunden. CVSS 7,0–8,9 (hoch) erfordert einen Patch innerhalb von 14 Tagen. CVSS 4,0–6,9 (mittel) erlaubt bis zu 45 Tage. CVSS unter 4,0 wird in das nächste geplante Wartungs-Release eingebunden.

Ebenso wichtig ist die Anforderung einer proaktiven Zero-Day-Benachrichtigung. Wenn der Anbieter von einer ausgenutzten Schwachstelle in der Software erfährt, bevor sie öffentlich bekannt gemacht wird — durch seine eigene Reaktion auf Vorfälle, durch einen Kundenbericht oder auf einem anderen Weg — sollte der Wartungsvertrag ihn verpflichten, den designierten Sicherheitskontakt der beschaffenden Organisation innerhalb von 24 Stunden zu benachrichtigen. Dies ist eine nicht standardmäßige Klausel, der Anbieter widerstehen werden. Sie sollte nicht wegverhandelt werden.

Der Vertrag sollte auch verlangen, dass der Anbieter eine aktuelle Software Bill of Materials (SBOM) — ein vollständiges Inventar der im Produkt enthaltenen Drittanbieter-Bibliotheken, Frameworks und Abhängigkeiten — pflegt. CVEs in Drittanbieter-Abhängigkeiten machen die Mehrheit der ausnutzbaren Schwachstellen in den meisten Verteidigungssoftwaresystemen aus. Ohne eine SBOM kann die beschaffende Organisation die Exponierung des Anbieters nicht eigenständig verfolgen oder überprüfen, ob Patch-Verpflichtungen erfüllt werden. Es ist für jeden Anbieter, der eine moderne Build-Pipeline betreibt, technisch unkompliziert und zumutbar, die SBOM mit jedem Wartungs-Release zu aktualisieren.

Ausstiegs- und Übergangsbestimmungen

Übergangsbestimmungen sind die Klauseln, die bestimmen, ob eine geordnete Migration zu einem Ersatzsystem möglich ist. Sie gehören auch zu den am häufigsten herausgehandelten Klauseln bei Vertragsverhandlungen, da der Anbieter kein Interesse daran hat, seine eigene Ablösung zu erleichtern. Beschaffungsteams, die knappe Ausstiegsklauseln akzeptieren, zahlen Jahre später dafür, wenn die Übergangskosten eskalieren und Programme vom Wohlwollen des Incumbent-Anbieters abhängig werden.

Ein vollständiges Ausstiegs- und Übergangsrahmen behandelt vier Bereiche.

Datenportabilität. Alle vom System generierten operativen Daten — Spurverläufe, Missionsaufzeichnungen, Konfigurationszustände, abgeleitete Geheimdienstprodukte — müssen innerhalb eines definierten Fensters nach Vertragsbeendigung, typischerweise 30 bis 90 Tage, in dokumentierten, nicht proprietären Formaten exportierbar sein. Der Vertrag sollte Formate explizit benennen: wenn CSV und JSON akzeptabel sind, sollte das so niedergeschrieben sein. „Standardformate" ist nicht präzise genug, um durchsetzbar zu sein.

Migrationsunterstützung. Der Anbieter muss für einen definierten Überlappungszeitraum — sechs bis zwölf Monate sind der Standardbereich für komplexe Verteidigungssoftware — aktive technische Unterstützung für die Integration mit oder Migration zu einem Ersatzsystem leisten. Dazu gehören das Beantworten technischer Fragen des Nachfolgeunternehmers, das Bereitstellen von API-Dokumentation, die möglicherweise nicht in der öffentlichen Produktdokumentation enthalten ist, sowie die Unterstützung bei der Validierung der Datenmigration.

Wissenstransfer. Der Anbieter muss aktualisierte technische Dokumentation — Architekturdiagramme, Bereitstellungs-Runbooks, Konfigurationshandbücher — liefern und dem Nachfolgeunternehmer oder dem internen Team eine mindestens definierte Anzahl von Stunden technischer Schulung anbieten. „Dokumentation" muss definiert werden: welche Dokumente, in welchem Versionsstand, in welchem Format. Wissenstransfer-Liefergegenstände sollten als Vertragsposten mit Abnahmekriterien aufgeführt werden, nicht in allgemeinen Begriffen beschrieben.

Lizenzfortbestand. Alle Lizenzen für operative Daten, abgeleitete Analyseprodukte, trainierte Modellgewichte bei Vorhandensein von KI-Komponenten und Konfigurationsartefakte müssen die Vertragsbeendigung überdauern. Dies ist besonders wichtig für jedes System, das im Laufe der Zeit operativen Wert aufbaut — ein Spurverschmelzungssystem, dessen Fusionsmodelle mit operativen Daten trainiert wurden, stellt eine erhebliche Investition dar, die der beschaffenden Organisation gehört, nicht dem Anbieter.

Leistungsgarantien und Verfügbarkeits-SLAs

Verfügbarkeits-SLAs für missionskritische Verteidigungssoftware erfordern erheblich mehr Präzision als ein einfacher Uptime-Prozentwert. Eine 99,9-%-Verfügbarkeitsverpflichtung klingt stark, erlaubt aber fast neun Stunden Ausfallzeit pro Jahr — die, konzentriert in einem einzigen Vorfall zum falschen Zeitpunkt, schwerwiegende operative Konsequenzen haben kann. Noch wichtiger ist, dass eine Verfügbarkeitsklausel ohne definierte Messmethodik praktisch nicht durchsetzbar ist.

Die Messmethodik muss festlegen, was als Ausfallzeit gilt, wie diese verfolgt wird und wie sie verifiziert wird. „Ausfallzeit" sollte in Begriffen der Serviceauswirkung definiert werden — zählt ein System, das auf 30 % des normalen Durchsatzes gedrosselt ist, als „verfügbar"? — nicht in Begriffen des Systemzustands. Die Messung sollte kontinuierlich und automatisiert sein, nicht vom Anbieter gemeldet. Der Vertrag sollte festlegen, wer Zugang zu Verfügbarkeitskennzahlen hat und wie Streitigkeiten über gemeldete Zahlen gelöst werden.

Strafklauseln müssen echte finanzielle Anreize zur Einhaltung der SLA-Ziele schaffen. Service-Credits von 5 % bis 15 % des monatlichen Vertragswerts pro Prozentpunkt Verfügbarkeits-SLA-Verfehlung sind ein vertretbarer Rahmen. Die Strafstruktur sollte bei wiederholten Verstößen in aufeinanderfolgenden Zeiträumen eskalieren — ein Anbieter, der konsistent knapp verfehlt und dabei Credits zahlt, hat weniger Anreiz, in Zuverlässigkeit zu investieren, als einer, der mit eskalierenden finanziellen Konsequenzen konfrontiert ist.

Der Vertrag sollte auch einen schriftlichen Abhilfeplan innerhalb von fünf Werktagen nach jedem P1-SLA-Verstoß verlangen. Der Plan muss die Grundursache, die ergriffene Korrekturmaßnahme und die umgesetzten Präventivmaßnahmen zur Vermeidung einer Wiederholung dokumentieren. Abhilfepläne erfüllen zwei Funktionen: Sie schaffen eine Aufzeichnung für die Programmaufsicht und geben der beschaffenden Organisation eine frühzeitige Warnung vor systemischen Zuverlässigkeitsproblemen, bevor diese eskalieren.

Für Systeme, die in luftdicht abgetrennten oder verbindungsbeeinträchtigten Umgebungen betrieben werden, benötigt das Verfügbarkeits-SLA-Framework eine gesonderte Degraded-Mode-Spezifikation. Wie verhält sich das System, wenn die Konnektivität zu zentralen Diensten nicht verfügbar ist? Was ist die maximale autonome Betriebsdauer? Dies sind keine Standard-Verfügbarkeits-SLA-Fragen — sie erfordern einen verteidigungsspezifischen Anhang zur Wartungsvereinbarung, der die operativen Grenzen unter realistischen Feldbedingungen definiert.

Für zusätzlichen Kontext zur Anbieterbewertung vor der Vertragsvergabe — einschließlich der Frage, wie Support-Kapazität und langfristige Überlebensfähigkeit bewertet werden, bevor der Wartungsvertrag unterzeichnet wird — siehe unseren Leitfaden zur Verteidigungssoftware-Anbieterbewertung. Für den umfassenderen Beschaffungslebenszyklus, einschließlich der Frage, wie Wartungsbestimmungen in die vollständige Vertragsstruktur passen, behandelt der Leitfaden zum Verteidigungsbeschaffungsprozess von RFP bis Vertrag den End-to-End-Prozess.

EOL-Ankündigungsfristen und Versions-Support-Fenster

Verteidigungsprogramme können keine 90-Tage-Ankündigungsfrist für das Produktlebensende absorbieren. Der Beschaffungszyklus zur Identifizierung, Bewertung und Beauftragung eines Ersatzsystems dauert in den meisten Verteidigungsumgebungen 12 bis 24 Monate. Ein Wartungsvertrag, der dem Anbieter erlaubt, den Support mit einer 90-Tage-Frist zu beenden, lässt ein Programm potenziell für fast zwei Jahre ohne Support. Die minimale tragfähige EOL-Ankündigungsfrist für ein missionskritisches Verteidigungssoftwareprodukt beträgt 24 Monate — genug Zeit, um eine wettbewerbsfähige Neubeschaffung abzuschließen.

Versions-Support-Fenster sind ein verwandtes und häufig vernachlässigtes Thema. Verteidigungsprogramme können oft nicht auf dem bevorzugten Zeitplan des Anbieters upgraden. Regulatorische Neuzertifizierung, Integrationstests in klassifizierten Umgebungen und der Engineering-Aufwand zur Validierung einer neuen Version können Upgrade-Zeitpläne 12 bis 18 Monate über den GA-Release des Anbieters hinaus verschieben. Der Wartungsvertrag muss festlegen, wie viele frühere Hauptversionen der Anbieter gleichzeitig unterstützt und wie lange nach der Veröffentlichung einer neuen Hauptversion diese weiter gepflegt werden. Zwei frühere Hauptversionen, die 24 Monate nach dem Release gepflegt werden, sind ein vertretbarer Richtwert für komplexe Verteidigungssoftware.

Der Ansatz von Corvus Intelligence für langfristigen Support