ISMS as Code  UPDATE

Zum Wochenende habe ich auf Codeberg ein Beispiel-Repository veröffentlicht.¹ Es enthält den methodischen Vorschlag, eine ISMS-Dokumentation wie Code zu behandeln. Konkretes Beispiel ist die ISO 27001 Risikobewertung von Assets in Organisationen. Im Mittelpunkt steht dabei weniger das konkrete Dokument als vielmehr das dahinterstehende Konzept.

Geschrieben ist alles in einem universellen Text-Only-Format, das garantiert auch noch in 50 Jahren in jedem Editor bearbeitet werden kann: Markdown.²

Markdown hat dabei einige praktische Eigenschaften:

• bleibt auch ohne Renderer les- und bearbeitbar
• erlaubt Checkboxen für Aufgaben und Review-Prozesse
• unterstützt strukturierte Tabellen, Listen und Metadaten
• ermöglicht mit Mermaid Ablaufdiagramme³
• funktioniert in Wissensdatenbanken und Wikis (z.B. BookStack)⁴

Mit Git⁵ als Versionierungssystem auf einem eigenen Server wie Forgejo⁶ entstehen zusätzliche Möglichkeiten der Dokumenten- und Zugriffssteuerung. Gleichzeitig entsteht automatisch eine Änderungshistorie.

Aus einer Markdown-Datei als “Single Source of Truth”⁷ kann automatisiert eine PDF oder das von einem Kunden oder Auditor gewünschte Format generiert werden. Dazu stehen beinahe grenzenlose Umwandlungs- und Formatierungsmöglichkeiten mit Pandoc,⁸ LaTeX,⁹ HTML,¹⁰ oder zur Not auch der CLI-Funktionen eines Headless LibreOffice zur Verfügung.¹¹ Eigene Skripte helfen dabei, alles zu automatisieren. Das Ergebnis ist ein sauberes Dokument wie im nachfolgenden Screenshot sichtbar.

Screenshot des fertigen PDFs aus dem Markdown-Dokument

Der aufmerksame Leser wird die Ähnlichkeit zu den PDFs dieses Blogs und meinen Whitepapers feststellen.¹² Ich arbeite seit vielen Jahren mit einem vergleichbaren PDF-Workflow. Eine klassische Office-Anwendung wird eher seltener geöffnet.

Diese Methodik aus der Opensource-Softwareentwicklung steht im Kontrast zur häufig anzutreffenden Praxis in Unternehmen. Dort wird meiner Beobachtung nach immer noch wie in den 80er Jahren des letzten Jahrtausends gearbeitet: Lose Dateisammlungen in verschachtelten Verzeichnisstrukturen auf freigegebenen Laufwerken, damals noch auf Bus-verkabelten PCs mit BNC-Steckern, T-Stücken und 50-Ohm-Abschlusswiderständen.¹³

Solche Strukturen sind bereits für einzelne Personen fehleranfällig und schwer zu beherrschen. Versehentlich überschriebene oder gelöschte Dateien oder schlimmer, verschobene Verzeichnisstrukturen unterminieren jede Nachvollziehbarkeit. Das Ganze multipliziert sich mit Anzahl der Personen und der Zeit. Und wehe es kommt eine neue Version der verwendeten proprietären Software heraus, mit künstlich eingezogenen Inkompatibilitäten oder neuen Dateiformaten. Das sind seit vier Jahrzehnten immer die gleichen Dinge, die nerven und einem wertvolle Zeit klauen.

Offene Dateiformate und ein Git-basierter Ansatz auf einem Forgejo-Server beheben die typischen Probleme dateibasierter Ablagen. Änderungen werden bis auf den einzelnen Buchstaben in einem Dokument nachvollziehbar. Der Zugriff über System- und Netzwerkgrenzen wird plötzlich möglich, in einem universellen, überall lesbaren Format.

Der größte Vorteil jedoch: Abläufe lassen sich automatisieren und mit geringem Aufwand auf neue Kunden oder Projekte wiederverwenden. Es entsteht eine Infrastruktur, die in alle Richtungen wachsen und sauber skalieren kann. Wie im letzten Blog vorgestellt gilt in der IT der Grundsatz:¹⁴

Keine Skalierung ohne Automatisierung.

Das setzt allerdings einen organisatorischen Reifegrad und Wissensstand voraus. Mitarbeitende müssen wie Softwareentwickler “im Code” und Prozessen denken können. Statt vieler, repetitiver Mausklicks in sich ständig ändernden Anwendungen übernehmen Skripte die eigentliche Arbeit. Das fällt vielen, insbesondere im Mittelstand, schwer. Digitalisierung wird häufig als digitale Abbildung analoger Prozesse verstanden und sämtliche Fortschritte der letzten Jahrzehnte ignoriert.

Screenshot Bookstack als ISMS im Einsatz.

Ein ISMS wird in vielen Organisationen noch immer wie klassische Büroarbeit behandelt. Dabei ist es kein statisches System aus losen Dateien. Es lebt. Es muss kontinuierlich angepasst und weiterentwickelt werden und es skaliert idealerweise zusammen mit der Organisation.

Vor einigen Jahren bereits habe ich hier im Blog geschrieben, dass Digitalisierung ohne Versionierung eine ziemlich gute Heuristik für sich anbahnende Fehlschläge ist.¹⁵

In diesem Sinne,
Tomas Jakobs

Update vom 08.03.2026

Vielen Dank für die vielen, bereits kurz nach Veröffentlichung eingetroffenen Feedbacks und Rückfragen. Ich war positiv überrascht und habe diese prompt im heutigen Update aufgegriffen.

Umgang mit mehreren Dateien

Die meisten Fragen gingen in die Richtung, wie mit mehreren Dokumenten umzugehen ist. Diesen Punkt habe ich in einem aktualisierten makefile adressiert, der alle .md Dateien im /src Verzeichnis durchläuft und mit Pandoc als PDF generiert.

Weiteres Dokument: Remote-Access-Vertrag

Zum besseren Verständnis habe ich ein zweites Dokument aus meiner Dokumentensammlung (hier ein typischer Remote-Access-Vertrag für Externe) beigefügt.¹⁶

Anpassungen und Overrides der Standard-LaTeX-Vorlage

Eine weitere Fragestellung: Wie lassen sich abweichende Eigenschaften der Standard-LaTeX-Vorlage anpassen?

Einfache Antwort: Mit einer extra Datei. Für die Risikomatrix im Querformat besteht das Dokument nun aus zwei Bestandteilen, dem eigentlichen .md Markdown und einer .custom.tex Datei.

Die Default-LaTeX-Vorlage ist A4-Hochformat, so dass das zweite Dokument (Remote-Access-Regelung) keine eigene .custom.tex benötigt.

Konsequenterweise habe ich die Standard-Vorlage in ein eigenes /assets Verzeichnis im Repo verschoben und das Dokument mit der Risiko-Matrix neu generiert.¹⁷

pdfcpu als Post-Processor

Eine andere Fragestellung: Wie kann die von mir unlängst bei Heise vorgestellten Automatisierung bei PDF-Formularen genutzt werden?¹⁸ PDF-Formulare müssten ja demnach weiterhin händisch erstellt werden.

Pdfcpu arbeitet in beide Richtungen und kann sowohl Formulare lesen, als auch erzeugen. Die Vorgehensweise ist hier eine andere und benötigt die Formulardaten in einer .json Datei.

Analog zur .custom.tex Override-Datei wird optional nun auch eine .pdfcpu.json Datei abgefragt, wo die gewünschten Formularfelder definiert sind. Nach Erstellung der PDF mit pandoc übernimmt pdfcpu und fügt das Formular automatisiert ein.

Zusammenfassend kann (nicht muss) ein Dokument aus drei Bestandteilen aufgebaut sein:

dateiname.md
dateiname.custom.tex (optional)
dateiname.pdfcpu.json (optional)

Frontmatter

Im Blog unerwähnt blieben bisher die Frontmatter-Eigenschaften im Markdown.¹⁹ Das sind im Grunde Metainformationen, die auch Schalter für die weitere Verarbeitung enthalten können. Das README im Repo habe ich nun besser dokumentiert.

Update vom 09.03.2026

Da der Funktionsumfang des Repos eindeutig den ursprünglichen Namen des Repos übersteigt habe ich dieses nun umbenannt. Und bei dieser Gelegenheit das README angepasst.

Logic Flow des Repos

Neu hinzugekommen ist zudem ein Pre-Processor, der dynamisch Inhalte (Snippets) in das Markdown einfügt z.B. Git-Versionsinformationen zu einem Dokument, Datenbank Exporte aus Asset-Managementsystemen oder Abfragen aus REST-APIs.

Your mileage may vary!
Have fun!