Referenzen

Auf dieser Seite stehen keine Kundennamen. Das ist keine Lücke, sondern Teil der Leistung.

Warum keine Namen

Wer mich beauftragt, zeigt mir seine Schwachstellen: Lücken in der Dokumentation, Risiken, die noch nicht behandelt sind, Vorfälle, die nicht öffentlich wurden. Vertraulichkeit darüber ist keine Höflichkeit, sondern Voraussetzung dafür, dass diese Offenheit überhaupt entsteht. Wer seine Kunden öffentlich aufzählt, würde über Sie genauso reden.

Im persönlichen Gespräch nenne ich Namen und Ansprechpartner, soweit die jeweiligen Kunden dem zugestimmt haben. Bis dahin beschreibe ich Projekte nur nach Branche und Größenordnung.

Aus der Praxis

Die Steckbriefe folgen demselben Aufbau: Ausgangslage, Auftrag, Vorgehen, Ergebnis. Die Einordnung darunter erklärt, warum der jeweilige Schritt zählt. Sie ist allgemeine Fachkenntnis, keine Aussage über den jeweiligen Kunden.

IT-naher Dienstleister, KMU

Externer Informationssicherheitsbeauftragter

Ausgangslage: Ein Dienstleister, der selbst in Projekten mit NIS2- und DORA-Bezug arbeitet, brauchte die Funktion des Informationssicherheitsbeauftragten, aber keine Vollzeitstelle.
Auftrag: Laufende Führung der Informationssicherheit als externer Informationssicherheitsbeauftragter.
Vorgehen: Anforderungsprüfung gegen NIS2, Schutzbedarfsfeststellungen, Begleitung von Change-Projekten, Behandlung von Sicherheitsvorfällen. Wiederkehrende Abläufe sind automatisiert, damit sie ohne händisches Nachhalten laufen.
Ergebnis: Informationssicherheit als laufender Prozess mit fester Zuständigkeit statt als Thema, das bei jedem Kundenfragebogen neu aufkommt.
Einordnung: Dienstleister geraten über ihre Kunden unter Druck, noch bevor sie selbst unter ein Gesetz fallen: Wer für ein Unternehmen arbeitet, das NIS2 oder DORA erfüllen muss, bekommt dessen Anforderungen als Vertragsklausel und Fragebogen weitergereicht. Eine feste Zuständigkeit macht aus diesen Anfragen Routine.

Produzierendes Unternehmen, rund 25 Mitarbeiter

ISMS-Grundlagen und Prozessautomatisierung

Ausgangslage: Ein kleines Produktionsunternehmen ohne eigene IT-Sicherheitsfunktion wollte wissen, wo es steht und welche Ausfälle es sich nicht leisten kann.
Auftrag: Aufbau der Grundlagen eines Informationssicherheits-Managementsystems.
Vorgehen: Business-Impact-Analyse, Aufbau des Risikomanagements, Dokumentenlenkung und Schutzbedarfsfeststellung. Parallel dazu wurde der Helpdesk-Prozess automatisiert.
Ergebnis: Das Unternehmen kennt seine kritischen Prozesse und deren tolerierbare Ausfallzeiten, bewertet Risiken nach einer festen Methode und führt seine Dokumente gelenkt.
Einordnung: Für kleine Unternehmen ist die Reihenfolge entscheidend. Die Business-Impact-Analyse steht am Anfang, weil sie zeigt, wo sich Aufwand lohnt — und wo nicht. Die Automatisierung des Helpdesks war kein Nebenprojekt: Sie entlastet genau die Personen, die sonst die Zeit für Informationssicherheit nicht hätten.

Gemeinnützige Organisation

Berechtigungsmanagement

Ausgangslage: Benutzerkonten und Berechtigungen wurden händisch vergeben. Wer wann worauf Zugriff erhalten hatte, ließ sich im Nachhinein nur mit Mühe feststellen.
Auftrag: Schutzbedarfsfeststellung und Automatisierung des Benutzer- und Berechtigungsmanagements.
Vorgehen: Nach der Schutzbedarfsfeststellung wurden Anlage, Änderung und Entzug von Berechtigungen vollständig automatisiert, einschließlich einer Überwachung der Abläufe.
Ergebnis: Jede Berechtigungsvergabe ist lückenlos nachvollziehbar, ohne dass dafür jemand Protokoll führen muss.
Einordnung: Berechtigungen sind einer der häufigsten Prüfpunkte in Audits und eine der häufigsten Ursachen für Vorfälle: Konten, die nach einem Austritt weiterbestehen, Rechte, die sich über Jahre ansammeln. Eine händische Lösung skaliert nicht und dokumentiert sich nicht. Die Schutzbedarfsfeststellung vorab sorgt dafür, dass die Automatisierung dort am strengsten ist, wo es darauf ankommt.

Beaufsichtigtes Kreditinstitut

Information Security Officer, in Anstellung

Ausgangslage: Neue regulatorische Anforderungen an die digitale Widerstandsfähigkeit trafen auf ein gewachsenes Risikomanagement und eine anstehende aufsichtsbehördliche Prüfung.
Auftrag: Rolle des Information Security Officer mit Verantwortung für das Umsetzungsprojekt und das IKT-Risikomanagement.
Vorgehen: Aufbau und Führung des IKT-Risikomanagements, Business-Impact-Analysen und Notfallplanung, Vorfallmanagement mit Meldeprozess, Lieferantenaudits, Steuerung des Security Operation Center, Berichte an Vorstand und Aufsicht, Begleitung der Prüfung.
Ergebnis: Ein Risikomanagement und ein Meldeprozess, die den Anforderungen der Aufsicht standhielten — geprüft von der Aufsicht selbst.
Einordnung: Diese Station war eine Anstellung, kein Beratungsauftrag, und ist hier deshalb auch so bezeichnet. Sie steht auf dieser Seite, weil sie zeigt, was eine aufsichtsbehördliche Prüfung tatsächlich verlangt: nicht die Existenz von Dokumenten, sondern den Nachweis, dass Prozesse wirken. Diese Perspektive fließt in jedes heutige Projekt ein.

Woran Sie mich sonst messen können

Diese Belege brauchen keine Kundenfreigabe. Sie lassen sich bei den ausstellenden Stellen überprüfen:

Berufung durch die CIS für ISO/IEC 27001
Personenzertifizierungen als Information Security Auditor und Information Security Manager (CIS, nach EN ISO/IEC 17024)
Dipl.-Ing., Informatik & Security, FH St. Pölten
Beruflicher Werdegang auf LinkedIn