Wenn Technik auf Prozesse trifft: Warum technische ITler oft mit ISMS-Dokumenten kämpfen

VonJulian Bednara

„Was soll ich jetzt konkret tun?“ – Eine typische ISMS-Szene

„Ganz ehrlich – ich hab keine Ahnung, was ich jetzt machen soll.“
Der Satz kommt von einem erfahrenen Netzwerkadministrator. Wir sitzen gemeinsam im Vorbereitungsmeeting zur ISMS-Auditierung. Vor uns liegt ein sauber gegliederter Prozess zur Benutzerverwaltung: Rollen, Freigabeschritte, Eskalationspfade. Alles drin – auf dem Papier.

Doch statt Klarheit bringt das Dokument Verunsicherung.
Und das ist kein Einzelfall.

In vielen Projekten beobachte ich genau dieses Muster:
Fachlich versierte IT-Kräfte, die im Tagesgeschäft souverän agieren, kommen mit ISMS-Dokumenten oft nicht zurecht – nicht wegen fehlender Kompetenz, sondern weil Form und Sprache dieser Dokumente nicht zur Arbeitsrealität passen.

Was auf den ersten Blick paradox wirkt, hat oft tieferliegende Gründe: Prozesse, die aus der ISO 27001 abgeleitet wurden, treffen auf eine Arbeitsrealität, die anders tickt. Während die Dokumentation sauber strukturiert ist, fehlt der Brückenschlag zur Praxis.

Warum ist das so?
Warum fällt es gerade technischen Anwendenden schwer, mit ISMS-Dokumenten zu arbeiten?
 Und vor allem: Was lässt sich besser machen – ganz konkret und praxisnah?

Warum das so häufig passiert – und was dahintersteckt

Wenn Technik auf Prozesse trifft, prallen oft zwei Welten aufeinander. Nicht im Streit – sondern in der Perspektive.

Technische Fachkräfte denken in konkreten Funktionen:
„Welche Konfiguration brauche ich?“
„Wie wirkt sich das Update auf das System aus?“
„Welche Logs zeigen mir, was passiert ist?“

Das ISMS dagegen tickt anders.
Es fragt:
„Wer trägt die Verantwortung?“
„Wie wird dokumentiert, dass der Prozess funktioniert?“
„Ist die Umsetzung nachweisbar?“

Und genau hier beginnt das Dilemma. Denn für viele aus der Technik wirkt das ISMS wie eine Parallelwelt:

  • Abstrakte Rollenmodelle statt klarer Verantwortlichkeiten („Ich bin’s doch eh, der’s macht.“)
  • Seitenlange Prozessbeschreibungen, aber keine klare Handlungsanleitung
  • Nachweisdokumentation, die im Alltag als Zusatzaufwand empfunden wird

Der Effekt:
Dokumente werden gelesen – und gleich wieder vergessen.
Oder gar nicht erst geöffnet, weil „eh nix Konkretes drinsteht“.
In der Praxis höre ich dann Sätze wie:

„Wenn was unklar ist, frage ich lieber direkt meinen Kollegen. Im SharePoint finde ich das eh nicht.“

Dieses Verhalten ist nicht Faulheit. Es ist ein Symptom für ein grundlegendes Missverständnis:
Das ISMS wird oft als Kontrollinstrument wahrgenommen – nicht als Hilfsmittel.

Dazu kommt ein weiterer Reibungspunkt:
Viele ISMS-Dokumente entstehen ohne technisches Feedback. Sie orientieren sich an Normforderungen oder Auditorenerwartungen – nicht an tatsächlichen Arbeitsabläufen.

Dabei ist genau das entscheidend: Gute Dokumentation darf nicht nur normgerecht sein (z. B. ISO 27001 Anhang A.7 oder A.16), sie muss auch im Alltag funktionieren – sonst wird sie ignoriert.
Das führt zu Papieren, die formell korrekt, aber inhaltlich leer wirken.

Typische Muster, die ich immer wieder sehe:

  • Prozesse ohne „Trigger“: Die Technik weiß nicht, wann sie was tun soll
  • Fließtexte ohne Struktur: Keine klare Entscheidungshilfe für operative Fälle
  • Dokumente im PDF-Archiv, aber nicht eingebunden in Tools oder Arbeitsumgebungen
  • Verantwortlichkeiten auf dem Papier – aber nicht in der Realität gelebt

Kurz: Die Brücke zwischen formaler Ordnung und technischer Wirklichkeit fehlt.

Und solange die fehlt, bleibt das ISMS ein Papiertiger – gut gemeint, aber schlecht genutzt.

Warum ISMS Dokumentation für Technik oft nicht funktioniert

Wenn ich in Projekte komme, in denen die Technik mit den ISMS-Dokumenten kämpft, erlebe ich oft dieselben Muster – aber auch dieselben Lösungsansätze, die Wirkung zeigen. Was funktioniert, hat weniger mit Normtext zu tun als mit gesundem Menschenverstand und Alltagsnähe.

1. Dokumentation vom Nutzungskontext her denken

Die erste Frage, die ich mir mit meinen Kundinnen und Kunden stelle, lautet nie:
„Was verlangt die ISO 27001?“
Sondern:
„Wer soll das wann lesen – und warum?“

Ein Change-Prozess ist ein gutes Beispiel. In der Norm geht es um Definition, Genehmigung und Dokumentation von Änderungen. Aber für die Technik zählt vor allem:

  • Wann muss ich ein Ticket eskalieren?
  • Muss ich jemanden informieren, wenn ich eine Firewallregel ändere?
  • Gibt es einen Standardfall, den ich einfach absegnen darf?

Wenn ein Dokument diese Fragen beantwortet, wird es genutzt.
 Wenn nicht – bleibt es im SharePoint-Regal.

2. Technik einbinden – nicht nachträglich „belehren“

Ein ISMS kann nicht „über die IT drübergestülpt“ werden. Wenn technische Anwendende den Eindruck haben, sie bekommen nur Dokumente zur Unterschrift, ist die Akzeptanz schon verloren.
Was besser funktioniert:

  • Workshops, die gemeinsam Prozesse visualisieren – mit realen Fällen
  • Sparringsgespräche auf Augenhöhe: „Wie läuft das bei Euch aktuell?“ statt „So muss das laut ISO aussehen“
  • Erfahrungswissen wertschätzen – gerade von langjährigen Admins, die Prozesse leben, auch wenn sie nicht dokumentiert sind

Technik ist selten unwillig – aber oft ungefragt.

3. Formate überdenken: Weniger Fließtext, mehr Klarheit

ISMS-Dokumentation muss kein Word-Monolith sein – sie sollte anwenderorientiert, klar strukturiert und direkt in den IT-Alltag integrierbar sein. Ich habe gute Erfahrungen mit Formaten gemacht, die sich an der Arbeitslogik technischer Teams orientieren:

  • Entscheidungsmatrizen („Wenn A, dann B – außer X“)
  • Kurzanleitungen mit Screenshots oder Mailvorlagen
  • Prozesse als einfache Ablaufdiagramme mit Rollenbezug
  • Einbindung in bestehende Tools (z. B. Wiki, ITSM-Systeme, SOP-Plattformen)

Diese Formate erfüllen weiterhin die Anforderungen aus ISO 27001 (z. B. A.12 Betriebssicherheit) – aber so, dass sie im Alltag auch tatsächlich genutzt werden.

Ein Beispiel:
Ein Kunde hat seinen Incident-Management-Prozess von einem 10-seitigen Word-Dokument auf eine Seite im IT-Wiki umgebaut – mit zwei Buttons: „Meldepflichtig?“ und „Nicht meldepflichtig?“.
Hinter jedem Button steckt eine Mini-Anleitung mit Ansprechpartner, Frist und Formularlink.
Seitdem wird der Prozess gelebt – vorher wurde er ignoriert.

4. Sprache und Realität abgleichen

Oft scheitert die Wirkung von ISMS-Dokumenten schon an der Sprache:

  • „Erstellung einer qualifizierten Risikobewertung unter Berücksichtigung relevanter Assets“ klingt nach Pflichtlektüre für Auditoren – aber nicht nach Praxis.
  • „Was kann passieren, wenn X ausfällt?“ ist verständlicher – und genauso wirksam.

Die beste ISMS Dokumentation ist die, die niemand erklären muss – weil sie verständlich, anschlussfähig und praxisnah formuliert ist.
Denn sie spricht dieselbe Sprache wie ihre Zielgruppe.
Und diese Zielgruppe ist in vielen Unternehmen die Technik.

Was Du mitnehmen kannst – drei Dinge, die helfen

1. Dokumente sind nur dann wirksam, wenn sie genutzt werden.
 Ein ISMS-Prozess mag normkonform beschrieben sein – aber wenn niemand im Alltag damit arbeitet, verfehlt er sein Ziel. Gute Dokumentation ist kein Pflichtanhang, sondern echte Unterstützung für die Praxis.

2. Technik braucht keine Übersetzung – sondern Beteiligung.
 Je früher technische Anwendende eingebunden werden, desto besser funktioniert die Umsetzung. Wer Prozesse mitentwickelt, erkennt sich darin wieder – und übernimmt Verantwortung, ohne dass es „aufgezwungen“ wirkt.

3. Format schlägt Formvorgabe.
 Entscheidungshilfen, Ablaufdiagramme oder Mailvorlagen bringen oft mehr als perfekt gegliederte Fließtexte. Was zählt, ist Klarheit im richtigen Moment – nicht Seitenzahl oder Normsprache.

Impulsfragen für Dich und Dein Team:

  • Welche ISMS-Dokumente nutzt Eure Technik tatsächlich – und warum gerade diese?
  • Wann war das letzte Mal, dass ein technischer Prozess gemeinsam dokumentiert und ausprobiert wurde?
  • Wie könntet Ihr mit wenig Aufwand eine Seite im ISMS so gestalten, dass sie im Alltag wirklich hilft?

Wenn Du das kennst: Es gibt Lösungen – aber sie beginnen nicht in der ISO, sondern bei den Menschen, die sie leben sollen.

Was Du jetzt tun kannst

Quick-Check:
Wissen Eure technischen Admins, wann ein ISMS-Prozess sie betrifft?
Werden technische Rollen in die Dokumentation eingebunden?
Ist Eure ISMS-Dokumentation in Formaten gestaltet, die die IT wirklich nutzt?

Regekwerksbezug: Dieses Thema hängt zusammen mit ISO 27001 Annex A.7 (Personalsicherheit), A.12 (Betriebssicherheit) und A.16 (Incident Management) sowie den Anforderungen der NIS2.

Fang mit einem Dokument an, das Eure Techniker wirklich brauchen: Formuliere es kurz, praxisnah und gemeinsam mit ihnen.

Hinweis zur Einordnung

Dieser Erfahrungsartikel basiert auf realen Beobachtungen und typischen Praxismustern. Die beschriebenen Maßnahmen können Orientierung bieten – sie ersetzen jedoch keine vollständige Umsetzung regulatorischer Anforderungen (z. B. gemäß NIS2, ISO 27001 oder branchenspezifischer Standards).
Wenn Dein Unternehmen unter die NIS2-Richtlinie fällt, sind zusätzliche strukturierte Analysen, dokumentierte Verfahren und ein systematischer Aufbau der Sicherheitsorganisation erforderlich.

Ähnliche Beiträge