Cybersecurity &
Compliance.
Informationssicherheit ist selten ein Dokumentenproblem. Sie scheitert an Netzwerken, die historisch gewachsen sind, an Anwendungen, die nie jemand bedroht modelliert hat, und an Lieferanten, die Zertifikate vorzeigen, aber keine Kontrollen betreiben. Diese Seite beschreibt, wie ich Sicherheits- und Compliance-Programme aufbaue — als Engineer, nicht als Auditor.
Wo Compliance und Sicherheit auseinanderlaufen.
In vielen Unternehmen läuft ein paralleles Spiel. Auf der einen Seite ein Compliance-Projekt: eine Richtlinie, eine Matrix, ein Statement of Applicability, am Ende ein Zertifikat an der Wand. Auf der anderen Seite die eigentliche IT: eine Active-Directory-Landschaft, die seit Jahren mitgeschleppt wird, ein OT-Netz, das man lieber nicht anfasst, eine SaaS-Wildnis, die keine Abteilung vollständig überblickt. Beide Seiten bewegen sich, aber sie treffen sich nie.
Die Folge ist ein Zustand, den man aus Konzernen kennt und der im Mittelstand gerade wiederholt wird: dokumentierte Kontrollen ohne technische Wirkung. Ein Passwort-Policy-Dokument ersetzt kein Conditional Access. Ein Patch-Management-Prozess in einer Richtlinie patcht keine SPS in der Produktion. Ein Lieferantenkatalog mit Risikoklassifizierung verhindert keinen Angriff über einen Wartungszugang, den niemand mehr auf dem Schirm hatte.
Der Reflex ist häufig, beim Auditor nachzuhaken, statt in der Architektur. Das bringt das nächste Zertifikat, aber nicht die nächste Stufe an Reife. Interessant wird es dort, wo ein echter Vorfall die Lücke offenlegt — dann wird sichtbar, dass die meisten Organisationen nicht an Dokumentation scheitern, sondern an Durchsetzung.
Was in den nächsten Jahren verbindlich wird.
Die regulatorische Landschaft für Informationssicherheit hat sich in den letzten drei Jahren grundlegend verschoben. Was früher für Banken, KRITIS-Betreiber und ein paar DAX-Konzerne galt, wird zunehmend Pflichtprogramm für Mittelstand und Industrie. Vier Regelwerke prägen das Bild, und sie greifen ineinander.
NIS2 ist in der EU seit dem 17. Oktober 2024 anwendbar. Die deutsche Umsetzung — das NIS2-Umsetzungs- und Cybersicherheitsstärkungsgesetz — erweitert den Kreis der betroffenen Einrichtungen erheblich: Hersteller, Logistiker, Lebensmittelproduzenten, Abfallentsorger, digitale Diensteanbieter. Wer bislang nie mit dem BSI zu tun hatte, fällt plötzlich unter Registrierungs-, Melde- und Nachweispflichten — mit persönlicher Verantwortung der Geschäftsleitung.
ISO/IEC 27001 bleibt die praktischste Grundlage, um diese Anforderungen strukturiert umzusetzen. Die Revision von 2022 hat den Controls-Katalog modernisiert — Threat Intelligence, Cloud-Sicherheit, Datenmaskierung, sichere Softwareentwicklung sind nicht mehr optional. Wer jetzt baut, baut gegen die aktuelle Fassung.
Ein Zertifikat belegt, dass ein Managementsystem existiert. Es belegt nicht, dass es funktioniert. Diese beiden Sätze lassen sich nur dann zur Deckung bringen, wenn jemand die Kontrollen tatsächlich betreibt — und nicht nur beschreibt.
Hinzu kommen zwei Regelwerke, die für bestimmte Zielgruppen relevant werden: Der Cyber Resilience Act (CRA) verpflichtet Hersteller von Produkten mit digitalen Elementen — eingebettete Software, IoT-Geräte, Industriekomponenten — zu Security-by-Design, Schwachstellenmanagement und Meldepflichten über die gesamte Produktlaufzeit. DORA adressiert die Finanzbranche und ihre IT-Dienstleister und definiert erstmals verbindliche Anforderungen an Drittanbieter-Risikomanagement und Resilienztests.
Kein einzelnes dieser Regelwerke ist überraschend. Überraschend ist die Geschwindigkeit, mit der sie zusammengreifen — und die Tatsache, dass die meisten Organisationen Strukturen aufgebaut haben, die für eines davon passen, aber nicht für alle.
Konkrete Arbeit, kein Phasenmodell.
Die folgenden fünf Bereiche decken den weitaus größten Teil der Mandate ab. Manchmal ist es ein einzelner Baustein — ein NIS2-Readiness-Assessment, ein OT-Review vor einem Werkumbau, eine Bewertung der Security-Posture im Rahmen einer Transaktion. Manchmal ist es der komplette Aufbau eines Informationssicherheits-Programms für eine Organisation, die erstmals einen CISO bräuchte, aber keinen einstellen kann.
-
01
ISO-27001-Vorbereitung und Begleitung
Gap-Analyse gegen die Fassung 2022, Risikoanalyse, Risikobehandlungsplan, Statement of Applicability, Aufbau des ISMS im Tagesgeschäft — bis zum externen Audit. Ziel ist ein Managementsystem, das den Auditor überzeugt und gleichzeitig im operativen Betrieb nicht zur Schattenverwaltung wird.
-
02
NIS2-Readiness-Assessment
Betroffenheitsanalyse nach NIS2UmsuCG, Bewertung der zehn Mindestmaßnahmen aus Art. 21 NIS2, Ableitung eines Maßnahmenplans mit realistischer Priorisierung. Inklusive Meldeprozess, Lieferkettenbetrachtung und Dokumentation für die Geschäftsleitung, die im Zweifel persönlich haftet.
-
03
OT-Security-Architektur
Segmentierung nach Purdue-Referenzmodell, Bewertung von Fernwartungszugängen, Absicherung von Engineering-Stationen, Integration von OT-Monitoring ohne aktive Scans. Der Mythos vom Airgap ist in den meisten Produktionsnetzen längst gebrochen — die Frage ist, was an seine Stelle tritt, ohne dass Uptime und Verfügbarkeit leiden.
-
04
Application Security & Secure SDLC
Threat Modeling für kritische Anwendungen, Review von Architekturentscheidungen, Integration von SAST, SCA und Secrets-Scanning in bestehende CI/CD-Strecken. Besonders relevant für Teams, die mit KI-gestützten Entwicklungswerkzeugen arbeiten — die Geschwindigkeit hat sich verdreifacht, die Review-Disziplin hat nicht immer mitgehalten.
-
05
Incident-Response-Planung und Tabletop-Übungen
Response-Plan, Rollen, Entscheidungswege, Kommunikationsmatrix — und die Übung, die zeigt, was davon im Ernstfall trägt. Die meisten Pläne scheitern nicht am Fehlen einer Maßnahme, sondern daran, dass niemand weiß, wer wen um 03:00 Uhr morgens anruft. Tabletop-Szenarien für Ransomware, OT-Ausfall und Lieferanten-Kompromittierung.
Wie eine ISO-27001-Begleitung läuft.
Stellvertretend für die größeren Mandate der typische Ablauf einer ISO-27001-Einführung. Je nach Größe der Organisation und Reife der bestehenden IT dauert der Weg zwischen sechs und vierzehn Monaten. Nicht, weil die Arbeit so umfangreich wäre, sondern weil ein Managementsystem erst dann echt ist, wenn es mindestens ein paar volle Quartalsrhythmen überstanden hat.
-
01
Gap-Analyse
Bestandsaufnahme des aktuellen Sicherheitsniveaus gegen Annex A der ISO 27001:2022 und die zehn NIS2-Mindestmaßnahmen. Kein Fragebogen-Ausfüllen, sondern Gespräche mit den Leuten, die die Systeme tatsächlich betreiben.
-
02
Scope, Risikoanalyse, Risikobehandlung
Festlegung des ISMS-Geltungsbereichs, methodische Risikoanalyse nach ISO 27005, Priorisierung der Behandlungsmaßnahmen. Am Ende steht ein Maßnahmenplan, der sich im Budget eines Quartals ausdrücken lässt — nicht erst in der Fünfjahresplanung.
-
03
Statement of Applicability & Policies
Dokumentation der Controls, die gelten sollen, inklusive Begründung für Ausschlüsse. Die Policies entstehen entlang der tatsächlichen Prozesse, nicht aus einem Template-Paket — das spart zwei Runden mit dem Auditor.
-
04
Rollout und ISMS-Betrieb
Umsetzung der priorisierten Maßnahmen, Einführung von Awareness, Lieferantenbewertung, Monitoring und Management-Review. Ab diesem Punkt läuft das System — und muss laufen, bevor der Auditor kommt.
-
05
Internes Audit und Korrekturmaßnahmen
Ein ehrlich geführtes internes Audit, kein Stempel-Termin. Findings werden dokumentiert, bewertet, abgearbeitet. Das ist der Moment, in dem sich Zertifizierungs-Theater von einem funktionierenden ISMS trennt.
-
06
Zertifizierungsaudit — Stage 1 & 2
Begleitung durch die Dokumentenprüfung und das Vor-Ort-Audit der Zertifizierungsstelle. Mein Ziel ist, dass der Auditor keine Überraschung erlebt — und der Kunde auch nicht.
Warum jemand, der selbst noch Systeme baut.
Die meisten Security-Berater waren irgendwann einmal Techniker und sind es nicht mehr. Das ist selten böswillig, sondern eine Folge der Branche: Wer lange genug auditiert, verliert den Zugang zu den Systemen, die er bewertet. Ich habe mich bewusst anders organisiert. Sechs Jahre Enterprise Security bei einem DAX-40-Konzern — OT-Security in Produktionswerken, Application Security für Konzernanwendungen, klassische Enterprise-IT-Sicherheit inklusive Incident-Response-Einsätzen. Parallel CISSP-zertifiziert bei ISC².
Heute baue ich als CTO eines PropTech-AI-Startups produktive Systeme — Cloud-Architektur, LLM-Pipelines, Integrationen mit Drittdiensten. Das ist kein Nebensatz, sondern der Grund, warum Secure SDLC bei mir kein abstraktes Kapitel ist: Ich schreibe die CI/CD-Policies, mit denen ich arbeite, selbst. Beratung und Betrieb kreuzen sich wöchentlich, und das merkt man den Empfehlungen an.
Ein kurzes Gespräch reicht meistens.
Wenn bei Ihnen eine ISO-27001-Zertifizierung ansteht, ein Kunde einen NIS2-Nachweis fordert, ein Produktionsnetz segmentiert werden muss oder eine Due-Diligence-Security-Bewertung benötigt wird: schreiben Sie mir. Das erste Gespräch ist kostenlos und hat kein Verkaufsskript. Nach zwanzig bis dreißig Minuten lässt sich üblicherweise einschätzen, welcher Schritt als nächstes sinnvoll ist — und ob ich dafür der richtige bin oder jemand anderes.
enes@enkaconsulting.de
Düsseldorf, Deutschland · LinkedIn →