IT-Sicherheit bei Softwareprojekten: Was Auftraggeber von Dienstleistern erwarten sollten

Eine Frage sollte jeder Auftraggeber vor dem Start eines IT-Projekts stellen: Wie stellt der Dienstleister sicher, dass das System auch in Zukunft sicher und wartbar bleibt?

Diese Frage trennt saubere Projektarbeit von kurzfristiger Umsetzung. Denn viele Softwarelösungen funktionieren beim Go-Live gut. Die eigentlichen Herausforderungen kommen später: Updates werden aufgeschoben, Abhängigkeiten veralten, Zuständigkeiten sind unklar und bekannte Sicherheitslücken bleiben offen, bis ihre Behebung teuer oder dringend wird.

IT-Sicherheit ist deshalb keine Aufgabe, die mit dem Projektabschluss erledigt ist. Ein System bleibt nur dann belastbar, wenn Sicherheit, Wartung und Updates von Anfang an Teil der Projektlogik sind.

Ich stelle mir diese Frage auch intern konsequent. Wenn die eigene Entwicklungsumgebung nicht gepflegt wird, entstehen dort dieselben technischen und sicherheitsrelevanten Risiken, die später beim Kunden zum Problem werden können.

Warum IT-Sicherheit keine Einmalaufgabe ist

In vielen IT-Projekten liegt der Fokus auf Delivery. Der Termin muss gehalten werden, die Features müssen funktionieren und das Team arbeitet nach dem Go-Live bereits am nächsten Thema. Genau dabei entsteht eine gefährliche Lücke zwischen Entwicklung, Auslieferung und dauerhaftem Betrieb.

Software verändert sich ständig. Betriebssysteme erhalten Updates, Bibliotheken werden aktualisiert, neue Sicherheitslücken werden veröffentlicht und Abhängigkeiten ändern sich. Eine Anwendung, die heute sicher betrieben werden kann, braucht deshalb auch morgen Aufmerksamkeit.

Typische Probleme sehe ich in unterschiedlichen Umgebungen, unabhängig davon, ob macOS, Windows oder Linux eingesetzt wird:

• Veraltete Bibliotheken mit bekannten Schwachstellen
• Fehlende Routinen für Security Checks und Dependency Checks
• Keine klaren Verantwortlichen für Updates und Freigaben
• Technische Schulden, die durch Zeitdruck immer weiter verschoben werden
• Unklare Dokumentation darüber, warum Risiken akzeptiert oder geschlossen wurden
• Fehlende regelmäßige Überprüfung von Entwicklungs- und Produktionsumgebungen

Das ist kein rein technisches Detail. Es ist ein Geschäftsrisiko. Ein Sicherheitsvorfall kann den Betrieb beeinträchtigen, Kosten verursachen, die Reputation beschädigen und je nach Branche zusätzliche regulatorische Pflichten auslösen.

Was Auftraggeber von einem professionellen IT-Dienstleister erwarten sollten

Gute Dienstleister beantworten die Frage nach IT-Sicherheit nicht mit allgemeinen Aussagen wie „Wir achten darauf“. Sie können erklären, welche Sicherheits- und Wartungsroutinen eingesetzt werden, wer dafür verantwortlich ist und wie offene Risiken behandelt werden.

Diese Punkte sollten Auftraggeber konkret einfordern:

1. Fester Wartungsrhythmus. Es gibt definierte Intervalle für Dependency Checks, Security Patches und Plattform Updates.
2. Klare Verantwortlichkeiten. Eine Person oder Rolle ist benannt, priorisiert Risiken und steuert die Umsetzung.
3. Risikobasierte Priorisierung. Kritische Schwachstellen werden schnell behandelt. Weniger kritische Themen werden mit klarer Frist eingeplant.
4. Nachvollziehbare Dokumentation. Änderungen, offene Risiken und Entscheidungen werden transparent festgehalten.
5. Regelmäßige Reviews. Sicherheit, Wartbarkeit und technische Schulden werden strukturiert überprüft und nicht nur dann betrachtet, wenn bereits ein Problem entstanden ist.

Fehlt einer dieser Punkte, ist das zumindest ein Warnsignal. Dann besteht die Gefahr, dass sich technische Schulden und Sicherheitsrisiken über Monate oder Jahre aufbauen.

Wartung beginnt bereits bei der Architektur

Eine gute Wartungsroutine kann nicht erst nach dem Go-Live beginnen. Schon bei der Entwicklung sollte darauf geachtet werden, dass Komponenten aktualisierbar sind, Abhängigkeiten nachvollziehbar bleiben und Sicherheitsprüfungen in den Entwicklungsprozess integriert werden können.

Das betrifft nicht nur den eigentlichen Anwendungscode. Auch Frameworks, Libraries, Container, Betriebssysteme, Build Tools und externe Schnittstellen gehören zur technischen Gesamtumgebung.

Je transparenter diese Abhängigkeiten sind, desto einfacher lassen sich spätere Updates planen. Wer dagegen eine Anwendung mit vielen unbekannten oder veralteten Komponenten übernimmt, bezahlt häufig später für technische Schulden, die während der Entwicklung entstanden sind.

Mein Ansatz: Wartung als Teil der Projektlogik

Ich behandle Wartung nicht als Nachgedanken, sondern als Bestandteil von Architektur und Delivery. Das Ziel ist einfach: Risiken früh sichtbar machen und in überschaubaren Zyklen bearbeiten.

1. Basis-Check zu Beginn

Zum Projektstart erfasse ich den Ist-Zustand der Umgebung. Welche Komponenten laufen? Welche Versionen sind im Einsatz? Welche Abhängigkeiten sind kritisch? Welche Updates sind bereits überfällig?

So entsteht eine belastbare Ausgangsbasis statt eines Bauchgefühls. Gerade bei bestehenden Systemen ist dieser Schritt wichtig, weil technische Risiken sonst oft erst während eines späteren Projekts sichtbar werden.

2. Wartungsroutine mit festen Intervallen

Ich definiere direkt einen klaren Rhythmus für Prüfungen und Updates. Dazu gehören beispielsweise Security Scans, Dependency Reviews, Betriebssystem Updates und die Überprüfung relevanter Plattformkomponenten.

Der genaue Rhythmus richtet sich nach Risiko und Systemkritikalität. Eine geschäftskritische Anwendung braucht eine andere Wartungsroutine als ein internes Hilfswerkzeug.

3. Verantwortlichkeit und Eskalation

Jede Wartungsaufgabe braucht einen Owner. Offene Risiken werden nicht nur gesammelt, sondern mit Frist und Entscheidung versehen.

Wenn ein kritischer Punkt nicht sofort geschlossen werden kann, sollte dokumentiert sein, wer das Risiko bewertet, welche Übergangslösung gilt und wann die endgültige Behebung erfolgen soll.

4. Transparenter Wartungsreport

Auftraggeber erhalten regelmäßige Statusberichte mit drei einfachen Fragen: Was wurde geschlossen? Was ist noch offen? Welche Auswirkungen hat das auf das Risiko?

Damit wird Wartung steuerbar und überprüfbar. Gleichzeitig entsteht eine nachvollziehbare Grundlage für Gespräche mit IT, Geschäftsführung, Datenschutz oder gegebenenfalls Auditoren.

Security Updates sind Teil des normalen Betriebs

Ein häufiger Fehler ist, Sicherheitsupdates als Ausnahme zu behandeln. In einer professionell betriebenen Softwareumgebung gehören sie zum normalen Lebenszyklus.

Natürlich kann ein Update nicht immer sofort eingespielt werden. Abhängigkeiten müssen getestet werden, produktive Systeme dürfen nicht unnötig ausfallen und manche Änderungen benötigen eine Freigabe.

Entscheidend ist deshalb nicht, dass jedes Update innerhalb von Stunden installiert wird. Entscheidend ist, dass es einen definierten Prozess gibt, mit dem neue Schwachstellen bewertet, priorisiert, getestet und nachvollziehbar geschlossen werden.

Ergebnis: Mehr Sicherheit und planbarer Betrieb

Wenn Wartungs- und Sicherheitsroutinen sauber umgesetzt werden, entsteht ein klarer betrieblicher Vorteil:

• Weniger kritische Sicherheitslücken im laufenden Betrieb
• Weniger ungeplante Notfalleinsätze
• Schnellere Reaktion auf neue Schwachstellen
• Bessere Nachvollziehbarkeit für Audits und Compliance
• Weniger technische Schulden
• Planbarere Kosten statt teurer Ad-hoc-Maßnahmen

Das macht den Unterschied zwischen einem Projekt, das nur erfolgreich startet, und einem System, das auch langfristig zuverlässig betrieben und weiterentwickelt werden kann.

Praxisbeispiel: Automatisierte Dokumentenverarbeitung

Ein häufiger Fall aus Mittelstandsprojekten ist die automatisierte Verarbeitung von Dokumenten. Zum Go-Live funktioniert der Prozess: Rechnungen, Bestellungen oder Schadendokumente werden erkannt, relevante Informationen extrahiert und an die nächste Station weitergegeben.

Ohne Wartungsroutine kann die Qualität jedoch mit der Zeit sinken. Neue Dokumententypen kommen hinzu, Bibliotheken ändern sich, Datenformate variieren und externe Schnittstellen werden angepasst.

Mit einer sauberen Wartungsroutine bleibt der Prozess stabil. Modelle und Abhängigkeiten werden überprüft, Regeln werden angepasst, neue Dokumenttypen werden berücksichtigt und Ausnahmen werden dokumentiert.

Das Ergebnis ist nicht nur technische Stabilität. Es geht vor allem um verlässliche Prozessqualität für die Fachabteilung.

Was Sie als Auftraggeber vor dem Projektstart prüfen sollten

Wenn Sie aktuell mit einem IT-Dienstleister arbeiten oder ein neues Softwareprojekt planen, prüfen Sie diese Fragen:

1. Gibt es einen dokumentierten Wartungsplan mit festen Intervallen?
2. Sind Verantwortliche für Sicherheitsupdates eindeutig benannt?
3. Werden Abhängigkeiten regelmäßig auf bekannte Schwachstellen geprüft?
4. Gibt es einen definierten Prozess für kritische Sicherheitslücken?
5. Werden offene Risiken und technische Schulden transparent dokumentiert?
6. Ist geregelt, wie Updates getestet und in die produktive Umgebung übernommen werden?

Wenn Sie hier mehrfach mit „Nein“ antworten, ist das kein nebensächliches Detail. Es ist ein konkreter Hinweis darauf, dass Wartung und IT-Sicherheit im Projekt stärker verankert werden sollten.

Fazit: Eine sichere Softwarelösung braucht kontinuierliche Pflege

IT-Sicherheit entsteht nicht dadurch, dass ein System einmal sicher entwickelt und anschließend sich selbst überlassen wird. Software ist ein laufendes System. Abhängigkeiten ändern sich, neue Schwachstellen werden bekannt und Anforderungen entwickeln sich weiter.

Professionelle Softwareentwicklung endet deshalb nicht mit dem Go-Live. Wartungsroutinen, Security Checks, Updates und klare Verantwortlichkeiten gehören genauso zum Projekt wie Architektur, Entwicklung und Testing.

Genau das sollten Auftraggeber von einem professionellen IT-Dienstleister erwarten können: nicht das Versprechen, dass ein System für immer sicher ist, sondern einen nachvollziehbaren Prozess, mit dem Sicherheit und Wartbarkeit dauerhaft im Blick bleiben.

Bei Pilicore denke ich deshalb nicht nur bis zum Go-Live. Ich baue Systeme so, dass sie auch danach gewartet, geprüft und weiterentwickelt werden können.