Der Fall zeigt exemplarisch, woran viele IT-Vorhaben scheitern. Nicht an einer einzelnen Technikfrage, sondern am Zusammenspiel von Prozessen, Verantwortlichkeiten, Infrastruktur und organisatorischen Rahmenbedingungen. Genau dieses Zusammenspiel vor Einführung oder Änderung eines IT-Services beschreibt der Begriff Service Readiness.

Was bedeutet Service Readiness?

Ihre Organisation ist auf kritische IT-Services angewiesen. Fallen etwa das ERP-System für Auftragsabwicklung und Abrechnung, die Produktionssteuerung oder das zentrale Identity- und Access-Management aus, stehen im schlimmsten Fall ganze Fachbereiche oder das Kerngeschäft still.

Für IT-Verantwortliche beginnt die Absicherung solcher Services daher nicht erst im laufenden Betrieb. Ein technisch verfügbares System ist noch kein zuverlässig erbringbarer Service. Service Readiness prüft vor Einführungen, Änderungen und Betriebsübergaben, ob alle Voraussetzungen für einen stabilen Regelbetrieb erfüllt sind. Vier Bereiche sind dabei besonders wichtig.

1. Dokumentation allein schafft keine Prozessreife

Bei einer zentralen Datenplattform eines Energieversorgers funktionierte das Incident-Management formal einwandfrei: Vorfälle wurden erfasst, priorisiert und geschlossen. Das Problem-Management existierte dagegen nur auf dem Papier. Für die Ursachenanalyse waren keine Kapazitäten eingeplant.

Die Folge: Eine fehlerhafte Datenlieferung wurde monatelang immer wieder einzeln korrigiert. Die eigentliche Ursache – eine fehlerhafte Datentransformation im Quellsystem – blieb unbearbeitet.

Tipp: Ein Prozess ohne eingeplante Kapazitäten existiert faktisch nicht, selbst wenn er vollständig dokumentiert ist.

Trick: Definieren Sie verbindliche Auslöser für den Gesamtprozess. Tritt dieselbe Störung beispielsweise dreimal innerhalb von 30 Tagen auf, wird automatisch ein Problem-Record eröffnet.

Best Practice: Überprüfen Sie halbjährlich nicht nur die Existenz, sondern auch die tatsächliche Wirksamkeit Ihrer Betriebsprozesse.

2. Rollen benötigen Zeit und Mandat

Ein Analyse-Service wurde von zwei Fachbereichen eines Versicherungsunternehmens genutzt. Ein Service Owner war zwar benannt, verfügte jedoch weder über ausreichende Entscheidungsbefugnisse noch über ein festes Zeitbudget.

Als ein Konflikt über eine Funktionserweiterung eskalierte, konnte niemand verbindlich entscheiden. Erst ein Eingriff des Vorstands löste die Situation – verbunden mit einem spürbaren Vertrauensverlust in die IT-Steuerung.

Tipp: Rollen ohne Mandat können schädlicher sein als fehlende Rollen. Sie suggerieren klare Verantwortlichkeiten, die in der Praxis nicht bestehen.

Trick: Halten Sie Aufgaben, Entscheidungsbefugnisse, Eskalationswege und Zeitkontingente in einem verbindlichen Rollensteckbrief fest.

Best Practice: Trennen Sie die strategische Verantwortung des Service Owners von der operativen Steuerung durch den Service Manager. Bei einer Personalunion sollten Zuständigkeiten und Sparringsrollen trotzdem eindeutig definiert sein.

3. Realistische Testumgebungen sind unverzichtbar

In einem Kundenprojekt sollte eine neue Fachanwendung eingeführt werden. Das Team war aufgestellt, das Change-Management etabliert und die Betriebsprozesse dokumentiert. Was fehlte, war eine referenznahe Umgebung zwischen Test und Produktion. Aus Kostengründen sollte diese erst später aufgebaut werden.

Kurz nach dem Go-live installierte das Infrastrukturteam ein Betriebssystem-Update in der Produktivumgebung. Da das Update zuvor nicht unter realistischen Bedingungen mit der Fachanwendung getestet werden konnte, fiel die Anwendung aus. Die Ursachenanalyse dauerte mehrere Tage.

Tipp: Ein durchgängiges Staging-Konzept aus Test-, Referenz- und Produktivumgebung ist eine Grundvoraussetzung für einen stabilen Betrieb.

Trick: Testen Sie Backup und Restore sowie Failover vor dem Go-live unter realistischen Bedingungen, statt diese Abläufe ausschließlich zu dokumentieren.

Best Practice: Bewerten Sie Einsparungen bei der Infrastruktur immer im Verhältnis zu möglichen Ausfällen, Nacharbeiten und Vertrauensverlusten im späteren Betrieb.

4. Services brauchen eine tragfähige Organisation

In einem weiteren Kundenprojekt wurde ein neuer Service erfolgreich produktiv gesetzt. Rollen, Prozesse und Governance waren klar definiert. Trotzdem kam seine Weiterentwicklung nach wenigen Monaten zum Stillstand.

Die Verantwortung war auf zwei Abteilungen verteilt, die unterschiedlichen Vorständen unterstanden. Beide Bereiche verfolgten andere Prioritäten. Der Service Owner konnte formal entscheiden, war für jede Umsetzung aber auf Ressourcen aus beiden Abteilungen angewiesen. Die Organisationsstruktur blockierte damit die Weiterentwicklung des Services.

Tipp: Prüfen Sie frühzeitig, ob Ihre Organisationsstruktur einen dauerhaft steuerbaren Servicebetrieb tatsächlich ermöglicht.

Trick: Machen Sie strukturelle Hindernisse transparent – auch wenn sie außerhalb der unmittelbaren IT-Verantwortung liegen oder unangenehme Entscheidungen erfordern.

Best Practice: Denken Sie Service Readiness gemeinsam mit notwendigen organisatorischen Veränderungen. Häufig ist die wirksamste Serviceoptimierung keine technische, sondern eine strukturelle.

Service Readiness beginnt vor dem Go-live

Die Beispiele folgen einem gemeinsamen Muster: Ausfälle, Konflikte und Stillstand entstehen selten durch eine einzelne technische Ursache. Häufig fehlen Kapazitäten, Befugnisse, realistische Tests oder geeignete organisatorische Strukturen.

Um viele dieser Probleme künftig zu verhindern und erhebliche Folgekosten zu vermeiden, fragen Sie nicht nur, ob Ihr nächster IT-Service technisch fertig ist. Fragen Sie auch, ob Ihre Organisation bereit ist, ihn dauerhaft zu erbringen, zu steuern und weiterzuentwickeln.

Ist Ihr nächster IT-Service bereit für den Regelbetrieb?

Vor Go-live, größerer Änderung oder Betriebsübergabe prüfen wir einen konkreten IT-Service entlang von Anforderungen, Beteiligten, operativer Vorbereitung und Durchführung. Sie erhalten eine priorisierte Maßnahmenliste mit konkreten Handlungsempfehlungen für einen stabilen Regelbetrieb.

Mehr erfahren: https://www.hisolutions.com/…

Was bedeutet Financial Operations (FinOps)?

FinOps steht für Financial Operations und beschreibt eine Arbeitsweise, bei der IT, Finance, Einkauf, Fachbereiche und Betrieb gemeinsam Verantwortung für Cloud-Kosten und den daraus entstehenden Wert übernehmen. Es geht nicht nur darum, Rechnungen zu prüfen oder einzelne Ressourcen günstiger zu betreiben. FinOps schafft die Grundlage, um Technologieausgaben transparent, steuerbar und entscheidungsfähig zu machen.

Die entscheidende Frage lautet deshalb nicht: „Wie sparen wir schnell Geld?“, sondern „Sind wir organisatorisch, technisch und prozessual überhaupt in der Lage, Cloud-Kosten dauerhaft zu steuern?“ Diese Fähigkeit bezeichnen wir als FinOps Readiness.

Warum Cloud-Kosten heute ein strategisches Steuerungsthema sind

Cloud-Kosten sind heute kein Randthema mehr. Laut dem Marktforschungsunternehmen Gartner sollen die weltweiten Ausgaben für Public-Cloud-Services 2026 um 21,3 Prozent wachsen; bis 2029 wird ein Marktvolumen von 1,48 Billionen US-Dollar erwartet. Gleichzeitig steigt die Komplexität: Multi-Cloud-Architekturen, hybride Betriebsmodelle, Software-as-a-Service, Datenplattformen und zunehmend auch künstliche Intelligenz erzeugen neue Kostenstrukturen, die sich nicht mehr mit klassischen Budgetlogiken allein steuern lassen.

Das bestätigt auch die Entwicklung der FinOps-Disziplin selbst. Die FinOps Foundation beschreibt FinOps nicht mehr nur als reaktives Cloud Cost Management, sondern als Management von Technologiewert. Im State of FinOps 2026 wird insbesondere sichtbar, dass FinOps in neue Kostenbereiche hineinwächst: 98 Prozent der befragten Organisationen managen inzwischen auch AI Spend, also Ausgaben für KI-bezogene Services und Infrastruktur. Damit wird FinOps zunehmend zu einer Voraussetzung, um Innovation finanzierbar zu halten.

Für Unternehmen bedeutet das: Wer Cloud nur technisch betrachtet, übersieht einen zentralen Steuerungshebel. Kosten entstehen nicht allein durch virtuelle Maschinen, Datenbanken oder Storage. Sie entstehen durch Architekturentscheidungen, fehlende Standards, unklare Verantwortlichkeiten und nicht abgestimmte Betriebsmodelle. FinOps Readiness ist deshalb kein später Optimierungsschritt, sondern sollte bereits in Planung, Migration und Betrieb mitgedacht werden.

5 typische Kostenfallen, die Cloud-Transformationen teuer machen

1. Fehlende Transparenz

Eines der am häufigsten beobachteten Muster in Projekten ist die fehlende Transparenz über die Zusammensetzung der Cloud-Kosten. Viele Organisationen können ihre Cloud-Ausgaben zwar auf Provider- oder Rechnungsebene sehen, aber nicht sauber auf Anwendungen, Teams, Produkte oder Geschäftsservices herunterbrechen. Ohne diese Zuordnung bleibt jede Optimierung grob. Es wird diskutiert, aber nicht aktiv gesteuert.

2. Unzureichendes Tagging

Ein weiterer häufiger Schmerzpunkt betrifft das unzureichende Tagging. Tags sind Metadaten, mit denen Cloud-Ressourcen beispielsweise Kostenstellen, Applikationen, Umgebungen oder verantwortlichen Personen zugeordnet werden. Ohne verbindliches Tagging-Konzept gibt es keine belastbare Kostenallokation. Noch kritischer wird es, wenn Ressourcen ohne Pflicht-Tags provisioniert werden können. Dann entstehen Umgebungen, bei denen später niemand mehr sicher sagen kann, wem sie gehören, warum sie laufen oder ob sie noch benötigt werden.

3. Ungenutzte oder überdimensionierte Ressourcen

Der dritte Stolperstein liegt in ungenutzten oder überdimensionierten Ressourcen. Test- und Entwicklungsumgebungen laufen nachts und am Wochenende durch. Snapshots, Backups und Storage wachsen unkontrolliert. Instanzen sind größer dimensioniert als notwendig, weil in der Migration Sicherheitspuffer eingeplant wurden oder niemand die tatsächliche Auslastung regelmäßig bewertet. Rightsizing, also die Anpassung von Ressourcen an den tatsächlichen Bedarf, wird häufig erst dann zum Thema, wenn die Kosten bereits sichtbar eskaliert sind.

4. Schatten-IT

Ein vierter Punkt ist die Entstehung einer Schatten-IT. Darunter fallen Tools, Cloud-Services oder Software-as-a-Service-Lösungen, die außerhalb zentraler Steuerung beschafft oder genutzt werden. Für Fachbereiche kann das kurzfristig pragmatisch sein, für IT, Security, Einkauf und Controlling entsteht jedoch ein Steuerungsproblem. Kosten, Lizenzen, Datenflüsse und Risiken werden verteilt, aber nicht gesamtheitlich verantwortet und gesteuert.

5. Lift and Shift

Und schließlich wird Lift and Shift oft zur Kostenfalle. Bei diesem Ansatz werden bestehende Systeme weitgehend unverändert in die Cloud verschoben. Das kann unter Zeitdruck sinnvoll sein, etwa wenn Rechenzentren abgekündigt sind oder Hardware ausläuft. Ohne terminierte Modernisierungspläne wird Lift and Shift aber schnell teuer: Die Cloud wird dann wie ein klassisches Rechenzentrum genutzt, nur mit verbrauchsabhängiger Rechnung.

FinOps Readiness: Die 5 Stufen von Financial Operations

FinOps Readiness beschreibt die Fähigkeit einer Organisation, Cloud- und Technologieausgaben transparent zu erfassen, sinnvoll zuzuordnen, aktiv zu optimieren und dauerhaft in Entscheidungsprozesse einzubinden. Dafür reicht kein einzelnes Tool. Benötigt wird ein Zusammenspiel aus Datenqualität, Governance, Prozessen, Rollen und Kultur.

Ein praxistaugliches Reifegradmodell kann dabei helfen, den eigenen Standort einzuordnen. 

• Auf Stufe 1 steht meist der reaktive Betrieb: Kosten werden nachträglich geprüft, Budgets werden überschritten, Verantwortlichkeiten sind unklar.
• Auf Stufe 2 entsteht erste Transparenz: Dashboards zeigen Top-Kostentreiber, grundlegende Tags werden eingeführt, erste Quick Wins werden umgesetzt.
• Auf Stufe 3 werden Verantwortlichkeiten und Prozesse verbindlicher: Kostenverantwortliche sind benannt, monatliche Reviews finden statt, Budgets und Alerts werden genutzt.
• Auf Stufe 4 wird FinOps in Architektur, Provisionierung und Einkauf integriert: Policies, Freigabeprozesse, Standard-Services und Optimierungsroutinen greifen ineinander.
• Auf Stufe 5 ist FinOps Teil der strategischen Steuerung: Technologieausgaben werden nicht nur reduziert, sondern bewusst gegen Business Value, Geschwindigkeit, Resilienz und Risiko abgewogen.

Dieses Modell passt gut zur Logik der FinOps Foundation, die den FinOps-Zyklus in die Phasen Inform, Optimize und Operate einteilt. In der Inform-Phase werden Kosten sichtbar und zuordenbar. In der Optimize-Phase werden konkrete Maßnahmen abgeleitet, etwa Rightsizing, Abschalten ungenutzter Ressourcen oder Savings Plans. In der Operate-Phase werden Regeln, Verantwortlichkeiten und Entscheidungsprozesse etabliert, damit Optimierung kein einmaliges Projekt bleibt.

Quick Wins sind wichtig, aber nicht der eigentliche Hebel

In der Praxis braucht es oft schnelle Erfolge. Wenn Cloud-Kosten bereits außer Kontrolle geraten sind, helfen Quick Wins, Vertrauen zurückzugewinnen und Handlungsspielraum zu schaffen. Dazu zählen vier Hebel, die sich in vielen Umgebungen kurzfristig prüfen lassen: 

1. Rabattmodelle wie Reserved Instances oder Savings Plans für stabile Lasten
2. das Eliminieren ungenutzter Ressourcen
3. Rightsizing auf Basis realer Auslastung
4. klare Kosten-Verantwortlichkeiten

Wichtig ist jedoch die Einordnung: Quick Wins sind keine Zielarchitektur. Ein Reserved-Instance-Modell kann in einer Übergangsphase sinnvoll sein, ersetzt aber keine saubere Architekturentscheidung. Das Abschalten vergessener Ressourcen spart Geld, verhindert aber nicht automatisch, dass neue Ressourcen wieder ohne klare Verantwortlichkeit entstehen. Rightsizing senkt Kosten, löst aber keine Governance-Lücke. Und Kosten-Ownership bedeutet nicht, nur einen Namen in ein Tag-Feld zu schreiben. Kostenverantwortliche müssen Kosten verstehen, Entscheidungen treffen können und in einen funktionierenden Prozess eingebunden sein.

Der eigentliche Erfolgshebel liegt deshalb darin, aus wiederkehrenden Fehlern zu lernen und Strukturen zu schaffen, die diese Fehler künftig verhindern. Viele Kostenprobleme entstehen nicht aus der Cloud an sich, sondern aus fehlender Steuerung, unklaren Entscheidungswegen oder nicht vollständig definierten Betriebsmodellen. Hilfreich ist es daher, Erfahrungen aus Planung, Migration und Betrieb auszuwerten, typische Kostenfallen frühzeitig zu erkennen und die daraus gewonnenen Erkenntnisse in verbindliche Standards, Verantwortlichkeiten und Prozesse zu überführen.

Wie Sie den Einstieg in FinOps Readiness schaffen

Der Einstieg in FinOps Readiness sollte pragmatisch bleiben. Ein sinnvoller erster Schritt ist ein Readiness-Assessment oder Quick-Check. Dabei geht es nicht darum, wochenlang Daten zu sammeln, sondern die wichtigsten Steuerungsfragen zu beantworten: 

• Welche Kosten sind sichtbar?
• Welche Kosten sind zuordenbar?
• Gibt es verbindliche Tags?
• Wer verantwortet Budgets und Verbrauch?
• Welche Quick Wins sind kurzfristig realistisch?
• Welche Governance-Lücken müssen geschlossen werden?

Aus dieser Standortbestimmung entsteht ein priorisierter Maßnahmenplan. In den ersten 30 Tagen können Unternehmen typischerweise Transparenz schaffen, Top-Kostentreiber identifizieren, offensichtliche Leerlauf-Ressourcen bereinigen und Verantwortlichkeiten festziehen. Danach sollten verbindliche Standards folgen: Tagging-Minimum-Standard, Budgetalarme, Kostenreviews, Freigabe- und Provisionierungsworkflows sowie klare Regeln für Storage, Backup, Archivierung, Netzwerk- und Traffic-Kosten.

Gerade in hybriden, Multi-Cloud- oder Managed-Service-Provider-Modellen ist dieser strukturierte Einstieg wichtig. Nicht jedes Unternehmen startet am gleichen Punkt. Planung, Migration und Betrieb brauchen unterschiedliche Hebel. Entscheidend ist, dass FinOps nicht isoliert im Controlling oder in einem Cloud-Team hängen bleibt, sondern als gemeinsame Steuerungsaufgabe verstanden wird.

FinOps ist kein Nice-to-have

FinOps Readiness ist die Voraussetzung dafür, Cloud-Kosten nicht nur kurzfristig zu senken, sondern dauerhaft steuerbar zu machen. Unternehmen brauchen Transparenz, klare Verantwortlichkeiten, belastbare Daten, praktikable Governance und eine Kultur, die aus Fehlern lernt. Quick Wins sind dabei ein wichtiger Startpunkt. Der langfristige Nutzen entsteht jedoch erst, wenn daraus ein wiederholbarer Steuerungsprozess wird.

Die Kernbotschaft ist klar: FinOps ist kein Nice-to-have und kein reines Sparprogramm. Es ist ein strategischer Ansatz, um Technologieausgaben mit Business Value, Geschwindigkeit und Kontrolle zu verbinden. Wer Cloud-Transformation ernst meint, sollte FinOps Readiness frühzeitig prüfen – idealerweise bevor Kostenprobleme eskalieren.

Prüfen Sie Ihre FinOps Readiness

Mit einem kompakten, unverbindlichen FinOps Quick-Check oder einem detaillierten Readiness-Assessment analysieren wir, wie gut Ihre Cloud-Kosten heute steuerbar sind: von Transparenz und Tagging über Kostenverantwortung und Governance bis zu kurzfristigen Optimierungspotenzialen.

So identifizieren wir gemeinsam die wichtigsten Kostentreiber, realistische Quick Wins und konkrete nächste Schritte für eine belastbare Cloud-Kostensteuerung – vom ersten Kosten-Dashboard bis zum wirksamen FinOps Operating Model.

Machen Sie den Quick-Check: https://www.hisolutions.com/…

Ziele

Einheitliche Sicherheitssteuerung; gemeinsames Framework; standortweite Umsetzung

Ziel des Projektes war es, ein CSMS zu entwickeln. Dabei sollten zentrale Sicherheitsdisziplinen wie Informationssicherheit, Security Risk Management, Business Continuity Management, Personalsicherheit und Physische Sicherheit in einer einheitlichen Regelungs- und Prozessstruktur zusammengeführt werden.

Ein wesentlicher Schwerpunkt lag darin, die unterschiedlichen Anforderungen der Unternehmenssparten Schnellecke Logistics (SLSE) und KWD-Automotive (KWD) in einem gemeinsamen Security Control Framework (SCF) zu bündeln. Die Sparten unterscheiden sich hinsichtlich ihrer Geschäftsmodelle, Kundenanforderungen und regulatorischen Rahmenbedingungen. Das SCF sollte daher als gemeinsamer Rahmen dienen, um diese unterschiedlichen Anforderungen zu konsolidieren und daraus einheitliche Vorgaben und Bewertungsmechanismen abzuleiten, die für jeden Standort umgesetzt werden sollten.

Herausforderungen

Unklare Verantwortlichkeiten; regulatorische Vielfalt; unterschiedliche Anforderungen

Herausforderungen ergaben sich am Anfang insbesondere aus den zunächst unklaren Rollen und Verantwortlichkeiten in den beteiligten Bereichen der Schnellecke Group. 

Zudem müssen beide Sparten die TISAX-Vorgaben sowohl aufrechterhalten als auch neue sparten- und standortspezifische Anforderungen fortlaufend integrieren. Die KWD ist von NIS-2 betroffen, inklusive der jeweiligen nationalen Umsetzungsgesetze für die Standorte in Deutschland, Portugal, Spanien und Tschechien. Einzelne Standorte der SLSE unterliegen hingegen kundenspezifischen Anforderungen und streben daher beispielweise eine ISO-Zertifizierung an.

Umsetzung

CSMS aufgebaut; Rollen etabliert; Standorte bewertet

HiSolutions unterstützte Schnellecke beim erfolgreichen Aufbau einer gruppenweiten Sicherheitsorganisation und eines individualisierten CSMS. Über eine mehrjährige Zusammenarbeit wurden die erforderlichen Rollen, Aufgaben, Kompetenzen und Verantwortlichkeiten definiert, etabliert und in die Organisation überführt. Ein wesentlicher Bestandteil der Begleitung war die kontinuierliche Umsetzung und Weiterentwicklung der Anforderungen in zentralen Sicherheits- und Managementbereichen. Dabei wurden geeignete Methoden und Bewertungsformate wie Schutzbedarfsfeststellungen, Business-Impact-Analysen und Soll-Ist-Abgleiche eingesetzt, um Lücken und Risiken strukturiert zu identifizieren sowie angemessene Behandlungsmaßnahmen abzuleiten.
 
Durch den maßgeschneiderten Aufbau und die fachliche Begleitung konnten über 80 internationale Standorte detailliert bewertet und in eine einheitliche Steuerungs- und Prozessstruktur eingebunden werden. Dadurch wurde eine nachhaltige Grundlage geschaffen, um Sicherheitsanforderungen gruppenweit wirksam umzusetzen, Synergien zu nutzen und wesentliche Geschäftsprozesse langfristig abzusichern.

Ergebnis

Tragfähiges System; eigenständiger Betrieb; höherer Reifegrad

Das Kernergebnis war der Aufbau eines tragfähigen Systems für rund 17.000 Mitarbeitende, das durch eine voll etablierte Security Organisation getragen und von einem CSMS-Kernteam von drei Personen gesteuert, eigenständig betrieben und weiterentwickelt werden kann. Ein weiteres zentrales Ergebnis stellt das aufgebaute SCF mit 19 Sicherheitsthemenfeldern dar. Dieses Framework bildet das Fundament für das gesamte CSMS und ermöglicht eine risikoorientierte Steuerung der Unternehmenssicherheit.

Durch gezieltes Coaching und die Vermittlung von Methoden wurde sichergestellt, dass die Schnellecke Group das System eigenständig betreiben kann. Der Wissenstransfer wurde im Projektverlauf erfolgreich etabliert und wird auch weiterhin fortgeführt. 

Die definierten Ziele wurden erreicht und mit Blick auf den Reifegrad teilweise bereits weiter verbessert. Informationssicherheit ist dadurch heute als nicht verhandelbarer Bestandteil der Gesamtstrategie verankert, und die Organisation ist zugleich besser auf neue Anforderungen vorbereitet.  

Das sagt unser Partner

Die Zusammenarbeit mit dem HiSolutions-Team war von Beginn an einen absoluten Mehrwert für uns. Das Team hat es auf Anhieb verstanden, eine vertrauensvolle und verlässliche Atmosphäre zu schaffen.

Wichtig war mir bei dem Projekt insbesondere, dass wir eine für unser Unternehmen passgenaue Lösung finden ohne vorgefertigte Schablonen – und das haben wir gemeinsam geschafft! Besonders beeindruckt hat mich dabei, wie präzise unsere Anforderungen verstanden und umgesetzt wurden.

Durch das fundierte Know-how und die kontinuierliche Unterstützung des HiSolutions-Teams ist es uns gelungen, eine funktionierende Sicherheitsorganisation aufzubauen, die robust und zukunftsfähig gestaltet ist.

Janine Rauch, Head of Corporate Security & CISO

 
Über die Schnellecke Group AG Co. KG

Die Schnellecke Group AG Co. KG ist ein international betriebenes, familiengeführtes Unternehmen, das eine Vielzahl von Logistik- und Produktionsdienstleistungen anbietet.

Zu den Grundwerten der Schnellecke Group gehört das Engagement für kontinuierliche Innovation, sowie der Fokus auf Effizienz, Klimaschutz und soziale Verantwortung.

Ziele

Vorfall schnell klären, Datenabfluss analysieren, Systeme absichern

Um den Betrieb der Seniorenpflege sicherzustellen, galt es vorrangig zu ermitteln, ob neben dem E-Mail-Konto weitere Systeme durch Angreifer kompromittiert wurden. Gleichzeitig war die Gefahr einer Ransomware-Verschlüsselung von betriebskritischen IT-Systemen und Daten abzuwehren.

Herausforderungen

Unklare Angriffslage, kompromittierte Konten, sensible Datenrisiken

Um eine Versorgung der Bewohner und Bewohnerinnen ohne Unterbrechungen sicherzustellen, war es zwingend notwendig, Ausfälle der betriebskritischen IT-Systeme zu verhindern. Innerhalb kürzester Zeit mussten daher belastbare Untersuchungsergebnisse vorliegen, um einschätzen zu können, ob die Angreifer sich über das initial befallene System hinaus ausbreiten konnten und ob gegebenenfalls eine Ransomware‑Verschlüsselung droht.

Umsetzung

Forensische Analyse, Kontenbereinigung durchführen, Sicherheitsmaßnahmen einleiten

HiSolutions führte ein Compromise Assessment durch, um das Ausmaß des Angriffs zu bewerten und resultierende Risiken für die kritischen Systeme abzuschätzen. Parallel wurde der Angriff auf das betroffene E-Mail-Konto und den Passwortspeicher forensisch untersucht. Mit einem Assumed-Breach-Ansatz wurden Mitigationsmaßnahmen abgestimmt, um eine Ausweitung auf weitere IT-Systeme zu verhindern und die IT-Umgebung der Seniorenpflege Birkholz abzusichern.

Ergebnis

Angriff abgewehrt, Systeme stabilisiert, Sicherheitsniveau erhöht

Durch sorgfältige Maßnahmen zur Eindämmung des Angriffs konnten eine Ausbreitung auf weitere Systeme verhindert werden und die Versorgung der Bewohner und Bewohnerinnen die Betriebsfähigkeit ohne Unterbrechungen sichergestellt werden. Die Ergebnisse der forensischen Untersuchung bestätigten zudem, dass keine weiteren IT-Systeme kompromittiert wurden. Für die Seniorenpflege Birkholz wurde so Gewissheit geschaffen, dass der Angriff keine ernsthaften Folgen hatte und das Risiko weiterer Schäden reduziert wurde.

Das sagt unser Kunde

"Durch die schnelle Umsetzung der empfohlenen Sicherheitsmaßnahmen bestätigte sich kein weitergehender Kompromittierungsverdacht und für die Zukunft sind wir jetzt besser geschützt.“

Reik Hoffmann,
Geschäftsführer

Über Seniorenpflege Birkholz Betriebs GmbH

Die Seniorenpflege Birkholz verbindet drei eng zusammenarbeitende Bereiche: die stationäre Pflege im Haus Birkholz, die Praxis für Physiotherapie nach dem Motto „Rehabilitation hat Vorrang vor der Pflege" und das Ehrenamt der Seniorenpflege Birkholz.

Diese Verzahnung erlaubt es uns, auf jede Pflegesituation individuell zu reagieren. Jeder Mensch ist einzigartig, jede Pflegesituation ebenso. Beides erfordert Flexibilität und Ideenreichtum. Dabei greifen wir auf 50 Jahre Erfahrung in der Pflege und Betreuung von Senioren und behinderten Menschen zurück.

Ziele: Ein Sicherheitsstandard, geprüft aus drei realen Angriffsperspektiven

Ziel des Projekts Global Technical Audit war ein umfassender vergleichender Überblick über das Sicherheitsniveau der weltweiten Sozietäten aus drei komplementären Blickwinkeln:

• Sicht externer Angreifender aus dem Internet
• Sicht eines Angreifenden, der bereits einen Rechner im internen Netz übernommen hat
• technische Compliance-Sicht: Verifikation der Umsetzung konkreter Sicherheitsanforderungen aus den Bereichen Asset Management, Identity and Access Management, Schwachstellenmanagement, Protokollierung, Back-up und Netzwerkarchitektur

Dabei standen technische Detailtiefe und Praxisnähe im Vordergrund. Risiken sollten spezifisch im Kontext der individuellen IT-Umgebung und der realen Geschäftspraxis der einzelnen Sozietäten bewertet werden. Bei Empfehlungen zur Verbesserung des Sicherheitsniveaus waren der konkret eingesetzte Technologie-Stack und der Kontext der Organisation zu berücksichtigen.

Herausforderungen: 20 eigenständige Sozietäten, ein vergleichbarer Maßstab

Die zentrale Herausforderung lag im Spannungsfeld zwischen Einheitlichkeit und Eigenheit. Das Vorgehen musste über alle Sozietäten vergleichbar bleiben und zugleich die individuellen Merkmale jeder einzelnen Organisation berücksichtigen. Zu auditieren waren Organisationen unterschiedlicher Größe, vom IT-Eigenbetrieb bis zu umfassender Dienstleisterunterstützung über verschiedene Technologie-Stacks hinweg, von On-Premises bis zu Cloud-First.

Umsetzung: Vom gemeinsamen Prüfkatalog bis zur verifizierten Wirksamkeit

HiSolutions erarbeitete in Abstimmung mit der CMS CISO Group zu Projektbeginn die Prüfgrundlage. Diese beinhaltete konkrete Pentest-Szenarien, einen umfassenden Prüfkatalog für die technische Auditierung sowie abgestimmte Bewertungskriterien.

Sowohl die externen und internen Penetrationstests als auch alle Audits wurden vollständig remote und in englischer Sprache durchgeführt. Die Prüfteams verifizierten technische Anforderungen durch Einsichtnahme in Konfigurationen via Screensharing im Detail. Die Ergebnisse wurden für jede Sozietät in einem eigenen Bericht ausführlich dargelegt und mit den technischen Verantwortlichen im Detail erörtert. Die Projektteams von HiSolutions standen anschließend bei der Umsetzung der aus den Prüfungen resultierenden Empfehlungen für Rückfragen beratend zur Seite. Abschließend hat HiSolutions alle Verbesserungsmaßnahmen erneut auditiert und ihre Wirksamkeit verifiziert. Während des gesamten Projektverlaufs wurde die CMS CISO Group durch ein zentrales Projektmanagerteam aus erfahrenen Penetrationstestern über den Projektfortschritt auf dem Laufenden gehalten.

Ergebnis: Belastbare Compliance statt Selbstauskunft

CMS Law verfügt nach dem Audit über einen umfassenden Überblick über die Sicherheitslage in allen Mitgliedssozietäten auf der Basis von realen Angriffsszenarien. Compliance-Aussagen konnten durch unabhängige technische Audits hinterlegt werden. Die Mitgliedssozietäten konnten Awareness und Know-how erweitern und das eigene Sicherheitsniveau durch gezielte Maßnahmen weiter steigern.

Das sagt unser Partner

"Wir danken dem Team von HiSolutions für die Professionalität, die Reaktionsschnelligkeit und die Qualität der Arbeit, die es während unserer gesamten Zusammenarbeit in den vergangenen Jahren unter Beweis gestellt hat, und hoffen, dass wir die Zusammenarbeit mit Ihrem Team fortsetzen können."

Über CMS law

CMS Law ist eine internationale Anwaltskanzlei mit mehr als 20 weltweit verteilten Sozietäten in über 50 Ländern. CMS arbeitet mit einem breit gefächerten Mandantenkreis, der von Großkonzernen über mittelständische Unternehmen bis zu Start-ups reicht. Die Kanzlei unterstützt diese dabei, die Herausforderungen und Chancen in ihren Märkten zu meistern.

Kurz gesagt, beschreibt Cloud-Transformation den Wechsel von eigener IT-Infrastruktur hin zu Cloud-Services – also weg vom Betrieb auf eigenen Servern, hin zu Leistungen von Cloud-Anbietern. Das hat unter anderem die Vorteile, dass Ressourcen flexibel skalierbar sind, nutzungsbasiert abgerechnet werden und ortsunabhängig verfügbar sind.

Eine Cloud-Transformation bedeutet allerdings mehr als „nur“ ein Serverwechsel und stellt Sie vor viele Herausforderungen, die über die reine Migration hinausgehen. Wo liegen die größten Chancen und welche Stolpersteine sollten Sie kennen?

Stolperstein 1: Ohne klare Ziele wird die Cloud-Transformation zum Blindflug

Aus unserer Beratungspraxis wissen wir, dass eine zentrale Frage am Anfang oft nicht ausreichend geklärt wird: Welche Ziele verfolgen wir mit der Cloud-Transformation – und teilen alle das gleiche Verständnis davon?

Fehlt diese Klarheit, ziehen verschiedene Stakeholder in unterschiedliche Richtungen. Prioritäten bleiben unklar, Entscheidungen werden inkonsistent getroffen und Fortschritt lässt sich nur schwer messen.

Also: Tauschen Sie sich über Ziele aus. Was wollen Sie mit der Cloud-Transformation eigentlich konkret erreichen? 

Sind Sie sich unschlüssig, ziehen Sie als Startpunkt die NIST-Definition von Cloud Computing heran und entwickeln Sie Ihre Ziele iterativ.

So entwickeln Sie Ziele für Ihre Cloud-Transformation

NIST, also das National Institute of Standards and Technology, beschreibt fünf zentrale Eigenschaften von Cloud Computing:

• On-Demand Self-Service: IT-Ressourcen können bei Bedarf selbstständig und ohne manuellen Aufwand bereitgestellt werden
• Broad Network Access: Der Zugriff erfolgt flexibel über standardisierte Netzwerke – unabhängig vom Endgerät oder Standort
• Resource Pooling: Ressourcen werden zentral vom Anbieter gebündelt und mehreren Kunden gleichzeitig zur Verfügung gestellt
• Rapid Elasticity: Kapazitäten lassen sich schnell anpassen – sowohl nach oben als auch nach unten
• Measured Service: Die Nutzung wird transparent gemessen und nur das tatsächlich Verbrauchte abgerechnet

Fragen Sie sich: Welche dieser Eigenschaften sind für uns relevant? Wie könnte das bei uns konkret aussehen? Welche Vorteile bringen sie?

Beispiel Rapid Elasticity: Bei stark schwankenden Lasten – etwa im saisonalen Geschäft – kann die Cloud einen klaren Vorteil bieten, da keine eigene Infrastruktur für Lastspitzen vorgehalten werden muss. 

Daraus könnten Sie also folgendes Ziel der Cloud-Transformation ableiten: Systeme sollen sich automatisch an die aktuelle Last anpassen. Das heißt: Bei hoher Nachfrage stehen sofort mehr Ressourcen zur Verfügung, bei geringer Last werden sie wieder reduziert. 

Stolperstein 2: Ohne Cloud-Strategie verzettelt sich das Team schnell

Sind die Ziele gefunden, braucht es klare Leitplanken – von der strategischen Ausrichtung bis zur Umsetzung. Also eine Cloud-Strategie. 

Diese definiert zentrale Grundsätze – etwa zu Sicherheit, Souveränität, Compliance, Business Continuity und Datenstrategien – und übersetzt sie in eine Zielarchitektur.

Eine Zielarchitektur kann zum Beispiel auf einer übergeordneten Ebene festlegen, dass geschäftskritische Anwendungen in einer bestimmten Cloud-Region betrieben werden, Identitäten zentral über einen Identity Provider verwaltet werden und neue Anwendungen grundsätzlich containerbasiert aufgebaut sind. Außerdem beinhaltet sie viele weitere Details, die im weiteren Verlauf der Cloud-Transformation festgeschrieben werden.

So schaffen Sie Klarheit für typische Entscheidungen im Projektalltag und sie müssen nicht jedes Detail aufs Neue diskutieren.

Stolperstein 3: Ohne die richtigen Skills wird die Cloud zur Dauerbaustelle

Kaum ein Unternehmen startet seine Cloud-Transformation mit einem vollständig cloud-erfahrenen IT-Team. Es ist nicht schlimm, wenn Sie das auch so machen.

Kritisch wird es erst, wenn der Aufbau dieser Fähigkeiten nicht aktiv eingeplant wird. In der Praxis bewährt sich eine Kombination aus gezieltem Skillaufbau und Unterstützung durch erfahrene Partner. Gleichzeitig muss frühzeitig geklärt werden, wie der spätere Betrieb aussieht:

• Welche Leistungen übernimmt das interne Team?
• Welche Rolle spielen externe Dienstleister?
• Welche Services werden direkt vom Cloud Provider bezogen?

Das Shared Responsibility Model hilft, diese Fragen strukturiert zu beantworten und fundierte Entscheidungen zu treffen: Der Cloud-Anbieter ist beispielsweise für die physische Infrastruktur verantwortlich, während Sie als Kunde für Themen wie Zugriffskontrolle, Konfiguration und Datensicherheit zuständig bleiben.

Stolperstein 4: Ohne Automatisierung verschenken Sie das Potenzial der Cloud

Automatisierung ist einer der größten Mehrwerte, die eine Cloud-Transformation mit sich bringen kann. Man muss sie allerdings wollen und von Anfang an umsetzen.

Das Schlagwort ist hier Infrastructure as Code (IaC). Dabei wird Infrastruktur nicht manuell eingerichtet, sondern als Code beschrieben und automatisiert bereitgestellt – etwa, wenn Server, Netzwerke und Berechtigungen per Skript statt per Klick im Portal erstellt werden. Das ermöglicht eine schnellere Implementierung, geringere Fehlerquoten, bessere Nachvollziehbarkeit und stabilere Betriebsprozesse.

Das erfordert Disziplin: Prozesse müssen angepasst, Mitarbeitende geschult und manuelle Eingriffe konsequent vermieden werden, damit die Automatisierung nicht gleich wieder unterlaufen wird.

Unsere Erfahrung zeigt: Wer Automatisierung nicht von Anfang an mitdenkt, muss diesen Schritt später nur mit großem Aufwand nachholen – oft nur mit mäßigem Erfolg.

Stolperstein 5: Ohne Governance wird die Cloud zum Risiko

Die Cloud-Transformation verändert nicht nur die IT-Prozesse, sondern auch Governance-Frameworks.

Besonders betroffen sind etablierte Frameworks wie Information Security Management System (ISMS) und Business Continuity Management (BCM). Diese müssen an neue Betriebsmodelle und Verantwortlichkeiten angepasst werden.

Spätestens beim nächsten Audit wird sichtbar, ob diese Anpassungen erfolgt sind. 

Wer Governance früh integriert, reduziert nicht nur Risiken, sondern kann zusätzliche Potenziale erschließen – etwa durch automatisierte Compliance-Prüfungen (Compliance-as-Code).

Stolperstein 6: Ohne Migrationsstrategie verläuft die Transformation unkoordiniert

Nachdem Ziele und Strategie klar sind, braucht es einen konkreten Plan für den Weg in die Cloud: die Migrationsstrategie.

Ohne sie wird die Transformation schnell unkoordiniert: Systeme werden isoliert migriert, Abhängigkeiten übersehen und Prioritäten unsauber gesetzt.

Planen Sie die Migration deshalb gezielt und priorisieren Sie klar. Ausgangspunkt sind die Geschäftsanforderungen – ergänzt durch technische und organisatorische Rahmenbedingungen.

Gehen Sie schrittweise vor und starten Sie mit klar abgegrenzten Einheiten, die bereits für sich einen Nutzen liefern. So sammeln Sie früh Erfahrungen und reduzieren Risiken. Dieses Vorgehen orientiert sich häufig an sogenannten Minimal Viable Products (MVPs) – also kleinen, lauffähigen Schritten mit konkretem Mehrwert.

Ein weiterer Punkt wird oft unterschätzt: die Datenmigration im laufenden Betrieb. Sie ist aufwendig und kann den Zeitplan erheblich beeinflussen. Räumen Sie deshalb frühzeitig auf – etwa durch Archivierungs- und Löschkonzepte, um unnötige Daten gar nicht erst mitzunehmen.

Erfolgreiche Cloud-Transformation: mehr als ein Infrastrukturprojekt

Unsere Erfahrung aus vielen Projekten zeigt: Der Erfolg einer Cloud-Transformation entscheidet sich nicht allein darin, Systeme technisch in die Cloud zu verlagern.

Viele Unternehmen schaffen zwar die initiale Migration, scheitern aber daran, den laufenden Betrieb effizient zu organisieren, die Potentiale der Cloud auszuschöpfen oder die Kosten unter Kontrolle zu halten. Häufig fehlen klare Ziele, ausreichende Expertise, ein Automatisierungsgrad sowie eine wirksame Governance. Dabei gehören genau diese Aspekte zu den wichtigsten Erfolgsfaktoren einer gelungenen Cloud-Transformation. 

Ziele:

Sicherstellung eines unterbrechungsfreien Betriebs; Analyse der gesetzlichen und KRITIS-relevanten Anforderungen; Ableitung von Maßnahmen zur Compliance

Für die ALDB als federführende Stelle im operativen Betrieb des Digitalfunks der BDBOS ist ein reibungslos ablaufender Betrieb des Digitalfunks für Rettungsdienste und Polizei essenziell.

„Die Bundesanstalt hat die Aufgabe, die Kommunikationsinfrastruktur der Netze des Bundes aufzubauen, zu betreiben, weiterzuentwickeln und deren Funktionsfähigkeit sicherzustellen“
§ 2 (2) Bundesanstalt für den Digitalfunk der Behörden und Organisationen mit Sicherheitsaufgaben (BDBOSG)

Zur Klärung, welchen regulatorischen Anforderungen die ALDB als KRITIS-Betreiber unterliegt, hat HiSolutions eine Analyse der spezifischen Aufgaben der ALBD im operativen Betrieb des Digitalfunks und eine Gegenüberstellung zu den KRITIS-Anforderungen und weiteren regulatorischen Auflagen in Abstimmung mit dem BSI, der BNetzA und dem BMI durchgeführt.

Herausforderungen:

Komplexe gesetzliche Rahmenbedingungen; Schwierige eindeutige Zuordnung; Abstimmung mit mehreren Behörden

Die ALDB agiert als Dienstleister der BDBOS in einem besonderen regulatorischen Umfeld, da die BDBOS eine Anstalt des öffentlichen Rechts ist, für die spezielle gesetzliche Vorgaben gelten. Dementsprechend ist die Ermittlung der zutreffenden gesetzlichen Regularien für die ALDB anspruchsvoll. Auf Basis der sehr guten Zusammenarbeit und eines pragmatischen Vorgehens hat HiSolutions geprüft, ob die ALDB als KRITIS-Betreiber einzustufen ist, und welche weiteren Anforderungen in der Cybersecurity zu berücksichtigen sind.

Umsetzung:

Systematische Analyse relevanter Rechtsgrundlagen; Abgleich der gesetzlichen Anforderungen mit den Aufgaben der ALDB; Ableitung und transparente Dokumentation der Cybersicherheitsanforderungen

HiSolutions hat eine umfassende Recherche im Grundgesetz, im BSI-Gesetz, im BDBOS-Gesetz sowie allen weiteren relevanten regulatorischen Anforderungen und Verordnungen durchgeführt, die gesetzlichen Anforderungen an die ALDB abgestimmt, die Cybersicherheitsanforderungen daraus abgeleitet und nachvollziehbar dokumentiert.

Ergebnis:

Erfolgreiche Analyse und Abstimmung der regulatorischen Sicherheitsanforderungen; Identifikation und Dokumentation relevanter Vorgaben; Beitrag zur Schließung möglicher Abweichungen

HiSolutions hat für die ALDB die regulatorischen Sicherheitsanforderungen erfolgreich abgestimmt und analysiert.  Die Beratung basiert auf einer fachlichen Bewertung aus Sicht der IT-Sicherheit sowie auf den Vorgaben zu KRITIS und den BSI-Mindeststandards.

Die erfolgreiche Beratung und Analyse hat dazu beigetragen, dass die Ergebnisse aus der Analyse effektiv zur Abdeckung möglicher vorhandener Abweichungen zum bereits umgesetzten IT-Grundschutz beigetragen haben.

Das sagt unser Kunde:

„Informationssicherheit ist kein Privileg der Kritischen Infrastrukturen, sondern ihre Voraussetzung – auch für Organisationen, die nicht unter die KRITIS-Verordnung fallen. Wer seine Systeme schützt, stärkt nicht nur die eigene Handlungsfähigkeit und das Vertrauen seiner Kunden, sondern leistet zugleich einen aktiven Beitrag zur öffentlichen Sicherheit in unserer vernetzten Gesellschaft.“

Rafael Brzoska, Leiter Informationssicherheit und IT-Innovationsmanagement

Über die ALDB GmbH

Als Alcatel-Lucent Digitalfunk Betriebsgesellschaft mbH wurde die ALDB im Jahr 2010 gegründet. Im selben Jahr hat ALDB den Betrieb des BOS-Digitalfunknetzes für die Behörden und Organisationen mit Sicherheitsaufgaben übernommen. Die ALDB betreibt das weltweit größte BOS‑Digitalfunknetz für die BDBOS und die autorisierten Stellen der Bundesländer und des Bundes.

Kreditrisiken sind heute auch Cyberrisiken. Zusammen mit der heise academy begleitete HiSolutions die Kreditentscheidenden einer internationalen Großbank auf einer fünfstufigen Lernreise. Das Ziel: Die Teilnehmenden befähigen, die IT-Sicherheit ihrer Klienten fundiert zu bewerten. Der Prozess ist ein Programm, das theoretisches Wissen, technische Grundlagen und interne Bankprozesse praxisnah verknüpft – für fundiertere Kreditentscheidungen.

Die Ausgangslage & Ziele:
Cybersicherheit im Kreditvergabeprozess verankern

Die Kreditabteilung der Großbank stand vor einer Herausforderung: Rund 100 Kreditentscheide sollten in die Lage versetzt werden, die Informationssicherheit ihrer Kundinnen und Kunden – vom KMU bis zum Großkonzern – kritisch zu hinterfragen und Cyberrisiken im Kreditvergabeprozess korrekt einzuordnen.

Das Ziel war kein klassisches Frontal-Training, sondern eine nachhaltige Befähigung. Die Bank forderte einen Mix aus Theorie, Fachaustausch und der praktischen Anwendung interner Werkzeuge. Außerdem war wichtig, dass die Teilnehmenden auch nach Abschluss der Lernreise auf Methoden zur Selbsthilfe zugreifen können.

Die Herausforderungen:
Komplexes Wissen trifft auf straffen Zeitplan

Die Konzeption der Lernreise musste drei Hürden überwinden:

1. Zeit vs. Tiefe: Wie vermittelt man komplexe Bedrohungsszenarien und Schutzmaßnahmen umfassend, ohne das operative Tagesgeschäft der Kreditentscheiden zu blockieren?
2. Heterogenes Vorwissen: Die Teilnehmenden kamen mit unterschiedlichem technischem Hintergrundwissen in die Schulung.
3. Vertraulichkeit: Da HiSolutions keinen direkten Einblick in die Kundendaten der Bank hatte, wurde der Erfahrungsaustausch so gestaltet, dass trotz Wahrung höchster Diskretion ein praxisnaher und konkreter Austausch möglich war.

Die Lösung:
Eine modulare Lernreise in fünf Etappen

Um Flexibilität und Lerntiefe zu vereinen, entwickelten HiSolutions und die heise academy gemeinsam mit der Bank eine digitale Lernreise. Das Schulungskonzept befähigt die Kreditentscheidenden, Cyberrisiken nicht nur technisch zu verstehen, sondern deren mögliche Auswirkungen auf die finanzielle Stabilität und Bonität der Kunden fundiert zu bewerten. Das Programm gliedert sich auf die folgenden fünf aufeinander aufbauenden Module, die Theorie, branchenspezifische Vertiefung und die praktische Anwendung interner Tools kombinieren.

Modul 1: Das Fundament – Bedrohungslage & Regulatorik
Den Auftakt bildete der „Big Picture“-Überblick. Die Teilnehmenden lernten die aktuelle Bedrohungslandschaft (z. B. Ransomware, Deepfakes, KI-Angriffe) sowie deren finanzielle Auswirkungen auf Unternehmen kennen. Zudem wurden regulatorische Spannungsfelder, Compliance-Anforderungen (z. B. KRITIS) und der Nutzen von Zertifizierungen (ISO 27001) sowie Cyber-Versicherungen eingeordnet.

Modul 2: Deep Dive – Branchenspezifische Sicherungsstrukturen
Sicherheit ist nicht für alle Klienten gleich. In diesem Modul lernten die Teilnehmenden, IT-Sicherheitsarchitekturen in Abhängigkeit vom Geschäftsmodell zu bewerten. Durch die Aufteilung in spezifische Cluster (z. B. Automotive, Pharma, Logistik) wurden der Blick für branchenspezifische Angriffsflächen geschärft und aufgezeigt, wie passgenaue Präventionsmaßnahmen aussehen müssen.

Modul 3: Die Symbiose – Risiko, IT & Management
Hier stand die Wechselwirkung zwischen Angriffsmustern, IT-Schutz und Managemententscheidungen im Fokus. Die Kreditentscheidenden wurden befähigt, kritische Wertschöpfungsprozesse zu identifizieren und mit ihren Kundinnen und Kunden auf Augenhöhe zu kommunizieren. In Break-out-Sessions teilten die Teilnehmenden ihre praktischen Erfahrungen und wendeten die Theorie direkt auf ihre internen Arbeitswerkzeuge an.

Modul 4: Der Reality-Check
Aus Theorie wurde Praxis: Anhand fiktiver Kundenbeispiele und realer „Red Flags“ wendeten die Teilnehmenden ihre Arbeitswerkzeuge aktiv an. In Break-out-Sessions trainierten sie, abweichende Antworten zu interpretieren, Warnsignale zu erkennen und daraus konkrete Konsequenzen für die Kreditvergabe abzuleiten.

Modul 5: Lessons Learned & Ausblick
Den Abschluss bildete der konsolidierte Erfahrungsaustausch. Die Teilnehmenden reflektierten die „Lessons Learned“ der gesamten Lernreise, diskutierten offene Fragen und definierten Best Practices für die künftige Anwendung im Arbeitsalltag.

Zusätzlich erhielten die Teilnehmenden kuratierte „Extended Handouts“ mit Verweisen auf öffentliche Quellen, um auch künftig beim „Stand der Technik“ up to date zu bleiben.

Das Ergebnis:
Kritischer Blick und messbare Zufriedenheit

Das Feedback der Teilnehmenden war eindeutig: Die komplexe Materie wurde verständlich und anwendbar vermittelt.

Kompetenzaufbau: Die Kreditentscheidenden sind nun in der Lage, technische Sicherheitsinformationen ihrer Kundinnen und Kunden kritisch zu prüfen und Cyberrisiken aktiv in die Kreditbewertung einzubeziehen.

Prozessoptimierung: Durch das finale Modul entstanden wertvolle Impulse, um den bankinternen Kreditvergabeprozess weiter zu schärfen.

Bewertung: In der internen Evaluation der Bank erhielt die durchgeführte Lernreise positive Bewertungen – besonders gelobt wurde der modulare Aufbau, die fachliche Kompetenz der Referentinnen und Referenten und die Beispielszenarien.

Das sagt unser Partner:

„Die Expertinnen und Experten von HiSolutions haben in den Trainings deutlich ihre fachlichen Kenntnisse beweisen können. Trotz des umfassenden Branchenportfolios der Bank war HiSolutions durch ihre Projekt- und Auditerfahrung jederzeit in der Lage, die Rückfragen und Diskussionen der Teilnehmenden einzuordnen und Rückmeldungen zu vermitteln.“

Konstantinos Toubekis
General Manager, heise academy

Über die heise academy

Als Schulungsanbieter von IT-Trainings und Fortbildungen gehört heise Academy zu den größten Anbietern für digitale und analoge Schulungen im deutschsprachigen Raum. Durch ihr breites Portfolio an standardisierten sowie individuellen Schulungen ist heise Academy in der Lage, auch großen Teilnehmendenzahlen fundiertes Wissen zu vermitteln. Im Bedarfsfall greift sie hierbei auf fachliche Schulungspartner zu, die sich in der mehr-jährigen Unternehmenshistorie etabliert haben.

Was steht auf der Agenda für 2026?

Das IT‑Marktforschungs- und Beratungshaus Gartner prognostiziert, dass die globalen IT-Ausgaben im Jahr 2026 erstmals die Marke von 6 Billionen US-Dollar überschreiten werden. Ein deutlicher Anstieg gegenüber dem Vorjahr. Während in den letzten Jahren vor allem die Entwicklung und Erprobung von KI-Technologien ein wesentlicher Kostentreiber waren, hat sich der Schwerpunkt zuletzt spürbar verschoben. IT-Services machen inzwischen den mit Abstand größten Ausgabenblock aus. Organisationen investieren damit immer weniger in einzelne Technologien und zunehmend in dauerhafte Leistungsfähigkeit, die unmittelbar fürs Business relevant ist. Diese Verschiebung verändert die Rolle der IT grundlegend: Sie wird nicht mehr primär daran gemessen, Projekte abzuschließen oder Systeme bereitzustellen, sondern daran, stabile, steuerbare und belastbare Services zu liefern. Für viele mittelgroße IT-Organisationen entsteht daraus ein strukturelles Spannungsfeld, denn während die Ausgabenlogik bereits servicegetrieben ist, folgen Governance, Priorisierung und Organisationsdesign häufig noch einer technikzentrierten Logik, bei der in den Umsetzungsprojekten keine Service- oder Geschäftsziele identifiziert wurden und/oder diese nicht nachgehalten werden. Der eigentliche Engpass liegt damit weniger im Budget oder in der Technologie selbst, sondern in der Art, wie IT organisiert und gesteuert wird.

Vor diesem Hintergrund haben wir eine Vielzahl aktueller Reports und Studien analysiert (Zukunftsinstitut, World Economic Risk Report, BSI, Gartner, Bitkom, Wavestone PwC etc.) und mit unseren Erfahrungen aus zahlreichen Kundenprojekten gegenübergestellt. Eines wird dabei klar: Viele der drängendsten Herausforderungen sind weniger innovations- als risikogetrieben. IT-Abteilungen stehen vor der Aufgabe, vor die Welle zu kommen, statt ständig nur hinterherzurennen. Dieser Artikel konzentriert sich nicht auf neue Technologien, sondern auf konkreten Handlungsbedarf und die Entscheidungen, die IT-Organisationen jetzt treffen müssen, um 2026 handlungsfähig, resilient und steuerbar zu bleiben.

Trend 1: KI ohne klare Verantwortung relativiert den Wert von Organisationen

Während in den letzten Jahren die Erwartungen an KI und Automatisierung explodierten, wird inzwischen klar, dass der Hype mehr versprach, als technologisch und organisatorisch derzeit möglich ist. Die erste Welle, auf die sich viele IT-Organisationen 2026 vorbereiten müssen, ist der Backlash unkontrollierter KI-Investitionen. 

Laut Studien von Gartner und McKinsey verharren über zwei Drittel aller KI-Initiativen in Pilotstadien. Aus unserer Sicht fehlt es diesen Initiativen häufig an einem klaren Zielbild. Datenqualität, Ownership und Prozesslogik werden dabei unterschätzt und oft erst im Verlauf der Initiativen als zentrale Probleme sichtbar. Statt integrierter Lösungen entstehen Insellösungen, die kein End-to-End-Verständnis bieten, Schnittstellenchaos produzieren, Sicherheitslücken öffnen und ineffektive Lizenzmodelle nach sich ziehen. 

Diese strukturellen Defizite wirken direkt auf den operativen Betrieb. IT-Organisationen tragen die Kosten dieses Hypes, ohne dessen Mehrwert zu realisieren. Fehlentscheidungen nehmen zu, wenn Incident-Management, Self-Service oder Automatisierung auf unvollständigen oder falschen Daten basieren. Entgegen der Erwartung, dass KI entlastet und Effizienz steigert, erhöht sie in diesen Fällen die Komplexität der Organisation erheblich. 

Wer 2026 handlungsfähig bleiben will, braucht kein weiteres KI-Tool, sondern Datenklarheit, Governance und transparente Kostensteuerung als Grundlage. „AI-ready Data“ bedeutet verlässliche Datenflüsse, nachvollziehbares Ownership und klare Zugriffspolitik, sowie eine präzise Kontrolle über Lizenzen, Plattformnutzung und token-basierte KI-Kosten. Erst wenn diese Basis steht, kann KI sinnvoll skalieren – nicht als Selbstzweck, sondern als Multiplikator funktionierender Prozesse, der echten Wert schafft und unnötige Ausgaben vermeidet.

Trend 2: Cybersecurity entfaltet Wirkung erst durch echte Resilienz

2026 rückt Cybersecurity für mittelgroße IT-Organisationen endgültig ins Zentrum. Während KI und Automatisierung die Aufmerksamkeit binden, steigt das reale Risiko im Hintergrund weiter. Laut dem Wirtschaftsschutzreport der Bitkom verursachten Cyberangriffe 2025 Schäden von rund 289 Milliarden Euro. Das sind knapp 10 Prozent mehr als im Vorjahr und fast 50 Prozent mehr als 2023. Ein bedrohlicher Anstieg. 

Zusätzlich warnt das World Economic Forum vor einer neuen Dimension digitaler Risiken: Gezielte Desinformation und digitale Spionage nehmen auf einem neuen Niveau zu. Die Zahlen sprechen eine klare Sprache: mehr Angriffe, mehr Meldungen, mehr Aufwand. Organisationen müssen Sicherheitslücken schließen, Prozesse anpassen und Compliance-Anforderungen erfüllen und dabei die gleichen Ressourcen wie sonst auch verwenden. Diese ohnehin komplexe Aufgabe wird durch die wachsende Vernetzung weiter erschwert. Die Nutzung externer Cloud- und SaaS-Dienste erfordert neue Steuerungsmechanismen, da sich operative Risiken nicht mehr allein durch interne Maßnahmen beherrschen lassen.

Um dieser Komplexität zu begegnen, setzen viele Organisationen auf standardisierte Managementsysteme wie ISMS. Doch die bloße Existenz solcher Rahmenwerke garantiert noch keine Sicherheit. Laut dem BSI verfügen rund 80 Prozent der Unternehmen und Organisationen über einen Reifegrad 3, doch weniger als die Hälfte nutzt automatische Angriffserkennung. Nur zwei Drittel kennen ihre kritischen Prozesse und verfügen über Notfallpläne und deutlich weniger sind für den Ernstfall tatsächlich gewappnet. Denn eine reine Papier-Planung besteht noch keine Krise. 

Genau hier setzt die NIS-2-Richtlinie an: Sie verlangt nicht nur eine lückenlose Dokumentation und strengere Nachweispflichten, sondern rückt die tatsächliche Wirksamkeit der Schutzmaßnahmen in den Fokus. Governance und Reporting werden so zum Dauerstress, denn Compliance ist nun direkt mit der Haftung der Geschäftsführung verknüpft. Die Folge: Sicherheit wandelt sich endgültig vom reinen Technikthema zur strategischen Führungsaufgabe. 

Passend dazu verlangt die wachsende Bedrohungslage einen fundamentalen Kurswechsel. Weg von der rein präventiven Absicherung, hin zu echter Resilienz. Organisationen müssen Angriffe nicht nur verhindern, sondern auch erkennen, eindämmen und schnell wieder arbeitsfähig werden. Dazu braucht es klare Verantwortlichkeiten für Security, Business Continuity und Third-Party-Risiken eingebettet in eine Sicherheitsarchitektur, die von Anfang an mitgedacht wird: Security by Design statt nachträglicher Absicherung.

Zero Trust und Multi-Faktor-Authentifizierung werden dabei zum Mindeststandard, nicht zum Wettbewerbsvorteil. Ebenso entscheidend ist Transparenz: Service-Risiken müssen offen gegenüber dem Business kommuniziert werden, damit fundierte Entscheidungen getroffen werden können. IT-Sicherheit gehört künftig in den Servicekatalog, um als Qualitätsmerkmal gesehen zu werden.

Darüber hinaus gewinnt die bewusste Gestaltung regionalisierter IT-Architekturen an Bedeutung, sei es aus regulatorischen Gründen oder zur Absicherung geschäftskritischer Prozesse. Schließlich muss Security- und Risk-Literacy über die IT hinaus etabliert werden und zur kollektiven Kompetenz der gesamten Organisation werden.

Cybersecurity entscheidet 2026 nicht mehr nur über Schutz, sondern über die Überlebensfähigkeit von Services.

Trend 3: IT scheitert, wenn Projekte Services verdrängen

Die dritte Welle, die mittelgroße IT-Organisationen 2026 weiterhin spürbar trifft, ist die Projektüberlastung. Viele Organisationen steuern faktisch hundert oder mehr Initiativen gleichzeitig, während die personellen und organisatorischen Kapazitäten begrenzt sind. Das Ergebnis: ständiger Kontextwechsel, Qualitätsverluste und steigende individuelle Überlastung. Wissen bleibt oft personen- statt systemgebunden, und starre Rollenmodelle verhindern flexible Anpassung an neue Anforderungen.

In dieser Situation wird IT als reaktiv, langsam und intransparent wahrgenommen, und die Lernfähigkeit der Organisation sinkt. Wer weiterhin Projekte ohne klare Service- und Wertlogik abarbeitet, riskiert, dass steigende Kosten und Überlastung die operative Leistungsfähigkeit untergraben.

Die Lösung dieser Herausforderung liegt in der grundlegenden Transition zu einer serviceorientierten IT mit stabilen, am Wertbeitrag ausgerichteten Service- und Produktteams. Projekte dienen dabei gezielt als Mittel zur Entwicklung und Weiterentwicklung von Services und Produkten und werden nach Abschluss systematisch in den Regelbetrieb überführt, an klar benannte Service-Owner übergeben und in die bestehenden Betriebsprozesse integriert. Reife Praktiken des IT-Service-Managements (ITSM), etwa Automated Incident Response, Observability oder Change-Automation, unterstützen anschließend eine effiziente Steuerung dieser Betriebsprozesse und sichern den Wertbeitrag verlässlich ab. Zugleich wird Lernfähigkeit zum Designprinzip: Wissen wird systematisch erfasst, geteilt und weiterentwickelt, statt an Einzelpersonen zu hängen.

In der operativen Praxis stoßen jedoch insbesondere mittelgroße Organisationen bei dieser Transition an ihre Grenzen. Die Notwendigkeit, all diese neuen Verantwortlichkeiten zu etablieren, während die bestehenden Kernkompetenzen im Parallelbetrieb weiterlaufen müssen, führt zu einer massiven Überforderung der personellen und fachlichen Kapazitäten. Der Aufbau dieses dualen Skill-Portfolios erweist sich in der Transitionsphase oft als die größte Hürde. 

Hier kann ein schlanker Service Readiness Ansatz für die Transition angewendet werden, um neue IT-Services reibungslos in den Betrieb zu überführen und parallel eine nutzenorientierte Serviceoptimierung für den laufenden Betrieb angestoßen werden. Dabei kann es sinnvoll sein, über die Migration geeigneter Services in die Public Cloud nachzudenken. Ein bloßer “Lift & Shift”-Ansatz ist hier nicht hinreichend. Er verschiebt zwar die Infrastruktur, löst aber weder das Kostenproblem noch die operative Überlastung.

Wirkliche Entlastung kann allerdings erst entstehen, wenn höher integrierte Cloud-Services genutzt werden. Im Sinne des Shared Responsibility Models können so Aufgaben an den Provider übertragen werden, die neuen Freiraum für die gesamte IT-Organisation schaffen. Ein Beispiel dafür stellen Managed Database Services dar. Durch die Übernahme von Patching, Load Balancing und Backups mit Zero Downtime vom Cloud Provider können sich IT-Organisationen auf die wesentlichen Aufgaben konzentrieren, wie die Verwaltung der Schemata oder den eigentlichen Wertbeitrag für das Business zu generieren und gewinnen so die nötige Kapazität für die strategische Absicherung des Unternehmens. 

Die entscheidende Zukunftsfrage lautet damit nicht „Welche Technologie?“, sondern „Wie organisieren wir IT?“. Wer 2026 handlungsfähig bleiben will, muss Projekte entlang von Services steuern, Skills und Wissen systematisch managen und die Organisation lernfähig gestalten.

Fazit

Die IT-Trends 2026 lassen sich nicht auf neue Tools oder Technologien reduzieren. Sie offenbaren vor allem die strukturellen Grenzen mittelgroßer Organisationen und den Zwang, diese aktiv zu gestalten. Entscheidend wird sein, ob IT-Teams es schaffen:

• Technologie zu führen, statt nur zu konsumieren,
• Services zu steuern, statt planlos Projekte abzuarbeiten,
• und Organisationen resilient sowie lernfähig zu gestalten. 

Wer diese Weichen jetzt stellt, begegnet Risiken nicht nur, sondern verwandelt sie in Wert für das Business. 2026 wird damit kein Technologie-, sondern ein Gestaltungsjahr für IT-Organisationen. Eines, in dem Struktur, Governance und Handlungsfähigkeit mehr über Erfolg entscheiden als jedes neue Tool oder jede Plattform.