Part 2 of 2

The first part of this article looked at how to prepare well-informed IT security decisions. However, the real work is not done once technologies or service providers have been selected; in fact, that is when it really begins.

For IT managers, this means that the decision taken must be translated into a stable, transparent and sustainably functioning security operation. It is precisely here that the biggest gaps arise in practice. Systems are implemented but not integrated. Processes are defined but not put into practice. Responsibilities are unclear.

This article shows what really matters once the decision has been made.

[Translate to English:]

Ein Produkt ist beschafft, ein Dienstleister beauftragt – und damit scheint das Projekt abgeschlossen. Tatsächlich beginnt an diesem Punkt erst die entscheidende Phase: die Übersetzung in ein Betriebsmodell.

Das bedeutet konkret: Aus einer technischen oder strategischen Entscheidung muss ein klar definierter Service werden. Mit eindeutigem Geltungsbereich, festen Verantwortlichkeiten, dokumentierten Prozessen und messbaren Zielen.

Zu den zentralen Fragen gehören:

• Welche Systeme und Daten sind konkret im Scope?
• Wer ist fachlich und operativ verantwortlich?
• Wie werden Incidents erkannt, bewertet und bearbeitet?
• Welche Eskalationswege gelten im Ernstfall?
• Welche Nachweise müssen erbracht werden?

Ohne diese Übersetzung wird IT-Security kein belastbarer Bestandteil des Unternehmensbetriebs.

[Translate to English:]

Die Anfangsphase nach der Entscheidung ist entscheidend. Ein strukturierter Onboarding-Prozess hilft dabei, die richtigen Grundlagen zu schaffen und Sicherheitskonzepte in die Praxis zu überführen.

• In den ersten Wochen geht es vor allem darum, Klarheit herzustellen. Der Scope muss definiert, ein verantwortlicher Service Owner benannt und Eskalationswege festgelegt werden. Parallel dazu werden Systeme, Datenquellen und Schnittstellen erfasst.
• In der nächsten Phase folgt die technische Umsetzung: Log-Quellen werden angebunden, erste Use Cases definiert und Alarmmechanismen eingerichtet. Wichtig ist dabei, nicht nur Technik zu implementieren, sondern auch Prozesse zu testen – etwa Meldewege oder Notfallkontakte.
• Anschließend sollte ein Pilotbetrieb stattfinden. Hier werden erste Kennzahlen erhoben, Fehlalarme reduziert und Abläufe geschärft.
• Zum Abschluss steht nicht nur das Go-Live, sondern auch eine erste Überprüfung: Funktionieren Incident-Playbooks? Lassen sich Systeme tatsächlich wiederherstellen? Sind Reporting und Steuerung etabliert?

Der entscheidende Punkt: Diese Phase ist kein einmaliges, abschließbares Implementierungsprojekt, sondern eine Service-Übergabe in den Regelbetrieb.

[Translate to English:]

Nach der Entscheidung für eine Lösung stellt sich in der Praxis vor allem eine Frage: Wer übernimmt welche Aufgaben im laufenden Betrieb?

Unabhängig vom gewählten Modell gilt: Die Verantwortung verbleibt immer beim Unternehmen. Auch wenn Leistungen ausgelagert werden, müssen IT-Leitungen sicherstellen, dass Anforderungen erfüllt und Prozesse eingehalten werden.

[Translate to English:]

Sicherheit entsteht nicht durch Tools, sondern durch Auswertung und Anwendung – ein gutes Beispiel dafür ist Security Monitoring. Logs allein schaffen keine Sicherheit; erst ihre Auswertung und die daraus abgeleitete Reaktion machen den Unterschied.

In der Praxis hat sich eine klare Rollenverteilung etabliert:

• Ein SIEM-System sammelt und korreliert sicherheitsrelevante Daten.
• Ein SOC (Security Operations Center) bewertet diese Daten, priorisiert Ereignisse und koordiniert die Reaktion.

Entscheidend ist dabei nicht die Technologie, sondern die Fähigkeit zur kontinuierlichen Überwachung und schnellen Reaktion.

Das führt zu einer unangenehmen, aber wichtigen Frage: Reicht ein Betrieb zu Bürozeiten aus? Für viele Unternehmen lautet die ehrliche Antwort: nein. Angriffe erfolgen nicht nach Zeitplan – und kritische Systeme sind häufig rund um die Uhr erreichbar. Wenn ein Sicherheitsvorfall eintritt, entscheidet sich innerhalb kurzer Zeit, wie groß der Schaden wird. Genau deshalb sollte Incident Response kein Notfallthema sein, sondern ein vorbereiteter Prozess.

[Translate to English:]

Ein funktionierender Incident Response-Ablauf umfasst mehrere Schritte:

• Erkennung und erste Bewertung des Vorfalls
• Eindämmung und Sicherung von Systemen
• Analyse der Ursache
• Wiederherstellung des Betriebs
• Nachbereitung und Verbesserung

Zusätzlich kommen regulatorische Anforderungen hinzu. In vielen Fällen bestehen Meldepflichten – etwa gegenüber Behörden oder im Rahmen der DSGVO. Das bedeutet: Neben der technischen Bearbeitung muss auch die Kommunikation funktionieren. Wer meldet was, wann und an wen? Ohne klare Playbooks entstehen hier Verzögerungen – und genau die sind im Ernstfall kritisch.

[Translate to English:]

Viele IT-Sicherheitsprobleme haben keine spektakulären Ursachen. Sie entstehen durch fehlende oder unzureichend gelebte Grundlagen.

[Translate to English:]

Ein häufiger Schwachpunkt in IT-Security ist die fehlende Messbarkeit. Maßnahmen werden umgesetzt – aber ihre Wirksamkeit bleibt unklar.

Dabei ist genau das entscheidend: IT-Leitungen müssen beurteilen können, ob ihre Sicherheitsstrategie funktioniert.

Typische Kennzahlen sind:

• Zeit bis zur Erkennung eines Vorfalls
• Zeit bis zur Reaktion
• Anteil unbearbeiteter kritischer Alarme
• Patch-Status kritischer Systeme
• Erfolgsquote von Wiederherstellungen

Diese Kennzahlen sind kein Selbstzweck. Sie zeigen, ob aus theoretischer Sicherheit tatsächliche Handlungsfähigkeit wird.

[Translate to English:]

Neben Technik und Prozessen ist die Organisation der dritte entscheidende Faktor.

In der Praxis bewährt sich eine klare Aufteilung:

[Translate to English:]

Wichtig ist dabei vor allem eines: Verantwortlichkeiten müssen klar benannt und dokumentiert sein.

Unklare Zuständigkeiten sind einer der häufigsten Gründe für Verzögerungen im Ernstfall.

[Translate to English:]

Technische Maßnahmen greifen zu kurz, wenn organisatorische und menschliche Faktoren nicht berücksichtigt werden.

Phishing-Angriffe, Social Engineering oder Fehlkonfigurationen entstehen häufig dort, wo Prozesse nicht verstanden oder nicht gelebt werden.

Deshalb gehört Awareness fest in den Sicherheitsbetrieb:

• regelmäßige Schulungen
• realistische Simulationen
• messbare Ergebnisse

Entscheidend ist auch hier die Perspektive: Nicht die Schulung ist das Ziel, sondern die Veränderung des Verhaltens.

[Translate to English:]

Gerade in regulierten Umgebungen reicht es nicht aus, Sicherheitsmaßnahmen umzusetzen. Sie müssen auch nachweisbar sein.

Das betrifft unter anderem:

[Translate to English:]

In der Praxis bedeutet das: Es braucht einen zentralen Ort, an dem diese Informationen strukturiert abgelegt sind. Ohne diese Nachweise entsteht eine Lücke – nicht nur technisch, sondern auch rechtlich.

[Translate to English:]

Wie bereits im ersten Teil gilt auch hier eine zentrale Erkenntnis: IT-Security ist kein Produkt. Sie entsteht aus dem Zusammenspiel von Technologie, Prozessen, Menschen und Governance. Erst wenn diese Komponenten ineinandergreifen, entsteht ein stabiler Sicherheitsbetrieb.

[Translate to English:]

Die Qualität einer IT-Security-Entscheidung zeigt sich erst im täglichen Betrieb. Technologien und Konzepte allein schaffen noch keine Sicherheit – entscheidend ist, wie konsequent sie in Prozesse, Verantwortlichkeiten und Abläufe übersetzt werden.

Für IT-Leitungen bedeutet das: Aus einer strategischen Entscheidung muss ein steuerbarer Betriebszustand werden. Prozesse müssen funktionieren, regelmäßig geprüft werden und im Ernstfall greifen. Gleichzeitig braucht es Transparenz darüber, ob Maßnahmen tatsächlich wirksam sind.

Am Ende geht es nicht um einzelne Tools, sondern um Steuerbarkeit. Wer weiß, was kritisch ist, wie Vorfälle behandelt werden und wie wirksam die eigenen Maßnahmen sind, kann Sicherheit aktiv managen – statt nur zu reagieren.

IT-Security ist damit kein Projekt, sondern ein dauerhafter Betriebszustand.