BAM Core · Release
BAM Core 2.0.3 exportiert die Gap-Analyse, am Montag folgen Container und Druckansicht
🎧 Artikel anhören
Executive Summary
- Was ist passiert
- BAM Core 2.0.3 gibt die Gap-Analyse als Arbeitspapier aus, in CSV, XLSX und JSON. Am Montag folgt 2.0.4 mit einem Container und einer Druckansicht.
- Wer ist betroffen
- Revisoren und Compliance-Verantwortliche, die Ergebnisse aus dem Modell in Arbeitspapiere übernehmen müssen. Dazu alle, die sich BAM Core bisher wegen des Einrichtungsaufwands gespart haben.
- Priorität
- Keine regulatorische. Dies ist eine Werkzeugmeldung, keine Rechtsänderung.
- Frist
- Keine. Wer auf 2.0 steht, kann im eigenen Takt nachziehen.
- Aufwand
- Der Umstieg innerhalb der 2.0-Reihe kostet nichts, die Bezeichner bleiben unverändert. Für den XLSX-Export wird zusätzlich openpyxl benötigt, CSV und JSON laufen ohne.
- Erster Schritt
- Im Dashboard den Reiter Export aufrufen und ein leeres Arbeitspapier ziehen. Das zeigt die Spaltenstruktur, bevor überhaupt bewertet wurde.
- BAM-Bezug
- Keine der drei Neuerungen ändert das Datenmodell. Die Bezeichner aus 2.0 gelten unverändert weiter, jede Exportzeile trägt ihre BAM-ID mit.
Ein Datenmodell, das man erst zusammenbauen muss, bevor man hineinsehen kann, wird nicht benutzt. Und ein Ergebnis, das man abtippen muss, landet nicht in der Prüfungsakte. BAM Core 2.0.3 löst das zweite Problem, am Montag folgt das erste. Am Modell selbst ändert beides nichts, und genau das ist der Punkt.
Was jetzt verfügbar ist: die Gap-Analyse als Arbeitspapier
Bisher endete die Arbeit mit BAM Core am Bildschirm. Wer einen Bewertungsstand in ein Arbeitspapier übernehmen wollte, kopierte ihn heraus und formatierte ihn neu. Das ist genau die Stelle, an der ein offenes Modell im Revisionsalltag verliert: nicht weil die Inhalte fehlen, sondern weil sie nicht in der Form ankommen, in der eine Prüfungsakte sie braucht.
Version 2.0.3 gibt den Bewertungsstand deshalb in drei Formaten aus: CSV, XLSX und JSON. Im Dashboard gibt es dafür einen eigenen Reiter Export, mit Feldern für die Organisation, die bewertende Stelle und eine Anmerkung sowie der Option, nur die Feststellungen auszugeben statt des vollständigen Katalogs.
Das Arbeitspapier umfasst 21 Spalten. Darunter die Anforderung mit Fundstelle, die Prüffrage, die Bewertung, die Feststellung, die Maßnahme samt Aufwandsschätzung, das Control, die Nachweisart und die Zuordnung zu ISO 27001. Entscheidend ist eine Spalte, die in einer gewöhnlichen Tabellenausgabe fehlt: Jede Zeile trägt ihre BAM-ID und deren dauerhafte Adresse. Eine Position aus dem Arbeitspapier bleibt damit nachschlagbar, auch zwei Jahre später und auch von jemandem, der die Tabelle nicht erstellt hat. Die XLSX-Mappe enthält zusätzlich ein Deckblatt und eine Zusammenfassung je Regulierung.
Praktischer Nebeneffekt: Ein leeres Arbeitspapier lässt sich auch ohne jeden Bewertungsstand ziehen. Damit ist der Anforderungskatalog als Prüfvorlage verfügbar, bevor die erste Bewertung existiert.
Warum der Export nichts speichert
Die Exportschnittstelle ist zustandslos. Der Bewertungsstand wird im Request übergeben und nicht gespeichert. BAM Core 2.0.x hält ihn im Browser, eine serverseitige Persistenz kommt erst mit dem Instanz-Layer in 2.2. Das POST an der Schnittstelle bedeutet hier also "Daten mitgeben", nicht "Daten anlegen".
Das klingt nach einer technischen Fußnote, ist aber die Architekturentscheidung, die BAM Core von einem GRC-Werkzeug trennt. Wer Bewertungsstände serverseitig hält, führt einen Arbeitsstand. Wer sie nur durchleitet, führt einen Kanon. Zu dieser Grenze weiter unten mehr.
Was am Montag folgt: Container und Druckansicht
Version 2.0.4 bringt zwei Dinge in einem Durchgang.
Der Container
Heute setzt der Einstieg einen Repository-Klon, eine Python-Umgebung und einen manuellen Start voraus. Ein docker compose up ersetzt das. Statt das Repository zu klonen, eine Umgebung zu bauen und die Werkzeuge einzeln aufzurufen, startet man ein Abbild und hat das Modell samt Resolver und Ausgabe vor sich.
Das ist weniger eine Funktion als eine Entscheidung darüber, wie viele Leute BAM je ausprobieren. Für ein Projekt, das als Spezifikation begonnen hat, ist der Schritt größer, als die Versionsnummer vermuten lässt. Ein Modell, das man liest, und ein Modell, das man startet, werden unterschiedlich benutzt. Das erste wird zitiert, das zweite ausprobiert.
Die Druckansicht
Die Druckansicht ist nicht dasselbe wie der Export, und die Unterscheidung lohnt sich. Der Export liefert eine Tabelle zur Weiterverarbeitung. Die Druckansicht macht aus dem Bewertungsstand ein Dokument statt eines ausgedruckten Tabellenblatts: Deckblatt, Zusammenfassung und Feststellungen als Fließtext.
Zwei Ausgaben für zwei Leser also. Das XLSX geht an die Stelle, die damit weiterrechnet, das Dokument an die, die es liest. Das PDF entsteht über den Druckdialog des Browsers, ohne zusätzliche Bibliothek. Ein serverseitiger Berichtsgenerator mit Anwendbarkeitserklärung, Managementbericht und Prüferpaket bleibt Version 2.4 vorbehalten.
Warum das keine 2.1 ist
Die Versionsnummer ist hier keine Formsache, sondern eine Aussage. BAM Core verspricht seit 2.0 stabile Bezeichner, und dieses Versprechen ist der Grund, warum sich ein Compliance-Nachweis überhaupt auf eine BAM-ID stützen kann. Zu den Zusagen gehört, dass eine ID nicht wiederverwendet wird, dass ersetzte Objekte über superseded_by gekennzeichnet statt gelöscht werden und dass jede Minor-Version archiviert und mit einem DOI versehen wird. Wer ein solches Versprechen gibt, muss an der Versionsnummer ablesbar machen, ob das Modell angefasst wurde.
Export, Druckansicht und Container fassen es nicht an. Sie verpacken und geben aus, was ohnehin da ist. Deshalb laufen sie als Patch-Versionen innerhalb der 2.0-Reihe. Die Minor-Nummern bleiben den Modellerweiterungen vorbehalten, und 2.1 ist in der Roadmap schon belegt: dem Fristenmanagement.
Was BAM Core damit wird, und was nicht
Ein Container weckt eine Erwartung, die enttäuscht werden muss: dass hier ein GRC-Werkzeug entsteht. Das ist ausdrücklich nicht geplant und steht so auch in der Roadmap, im Abschnitt über die Punkte, zu denen Vorschläge geschlossen und nicht diskutiert werden. Der Unterschied ist leicht zu übersehen, weil beides aussieht, als liefe es auf einem Server.
BAM Core beantwortet die Frage, welche Anforderungen es gibt, wie sie heißen und wo sie sich überschneiden. Ein GRC-Werkzeug beantwortet die Frage, wer in Ihrem Haus bis wann was erledigt. Das Erste ist ein Kanon, das Zweite ein Arbeitsstand. Wer beides vermischt, bekommt ein Modell, das nicht mehr zitierfähig ist, weil es sich mit jedem Bearbeitungsstand ändert.
Zwei weitere Abgrenzungen gehören dazu, weil sie in der Praxis regelmäßig erwartet werden. BAM Core wird kein Dokumentenmanagement: Ab Version 2.3 verweist ein Nachweisobjekt über WebDAV auf eine Datei, statt sie zu enthalten, und die Datei bleibt beim Betreiber. Und es werden keine Anforderungsobjekte automatisch aus Gesetzestexten erzeugt. Die fachliche Kuratierung ist der Kern des Modells, und für noch nicht entschiedene Gesetzgebungsverfahren werden weiterhin keine spekulativen Objekte angelegt.
Was als Nächstes ansteht
Die Roadmap nennt bewusst keine Termine, sondern eine Reihenfolge. Der Grund ist nachvollziehbar: Die Prioritäten ergeben sich nicht aus einer internen Planung, sondern aus einer externen Uhr. Die Hauptpflichten des Cyber Resilience Act greifen am 11. Dezember 2027, die Hochrisiko-Fristen des EU AI Act laufen nach der Omnibus-Staffelung am 2. Dezember 2027 und am 2. August 2028 aus, die Nachweispflichten nach dem neugefassten BSIG bis Ende 2028. Was in der Liste oben steht, steht dort, weil ein Gesetz es dorthin gestellt hat.
In Arbeit ist Version 2.1, das Fristenmanagement. Fristen werden eigenständige Objekte mit vier Typen: gesetzliche Stichtage, wiederkehrende Pflichten, ereignisgetriebene Fristen und selbst gesetzte Zieldaten. Der wichtigste Typ ist der dritte, denn Meldefristen sind kein Kalender, sondern eine Stoppuhr. Sie starten mit der Kenntniserlangung und laufen in Stunden, wie die 24- und 72-Stunden-Kette nach NIS-2 Artikel 23.
Danach folgt der Instanz-Layer in 2.2, der Kanon und Zustand trennt und damit erst den Mehrbenutzerbetrieb ermöglicht. Dann der Evidence-Layer in 2.3, der Nachweise zu eigenen Objekten mit Gültigkeitszeitraum und Prüfintervall macht. Erst damit gilt "Collect Once. Comply Many." auch für den Nachweis und nicht nur für die Anforderung.
Diese Reihenfolge ist kein Zufall. Jede Stufe setzt die vorherige voraus. Eine Frist ohne Instanz-Layer ist bloße Anzeige, weil ihr der Verantwortliche und der persistente Erledigungsstatus fehlen. Und ein abgelaufener Nachweis kann nur dann automatisch eine wiederkehrende Frist erzeugen, wenn Fristen vorher Objekte geworden sind.
Unsere Empfehlung
Wenn Sie BAM Core bereits einsetzen, ziehen Sie als erstes ein leeres Arbeitspapier über den Export-Reiter. Die 21 Spalten zeigen deutlicher als jede Beschreibung, welche Angaben das Modell je Anforderung vorhält, und die Vorlage ist auch ohne BAM-Installation als Prüfraster brauchbar. Für den XLSX-Export wird openpyxl benötigt; fehlt das Paket, funktionieren CSV und JSON unverändert weiter, und ein eigener Endpunkt gibt Auskunft darüber, welche Formate eine Installation ausliefern kann.
Wenn Sie BAM Core bisher nur gelesen haben, warten Sie bis Montag und starten Sie den Container, statt die Einrichtung von Hand zu versuchen. Der Unterschied zwischen Lesen und Ausprobieren ist bei einem Datenmodell größer als bei einer Anwendung: Erst im Zugriff merkt man, ob die Zuordnungen die eigenen Fragen beantworten.
Wer bereits auf 2.0 arbeitet, kann in jedem Fall im eigenen Takt nachziehen. Die Bezeichner ändern sich nicht, bestehende Verweise bleiben gültig. Genau dafür ist die Trennung zwischen Patch- und Minor-Versionen da.
Wie sich ein solches Modell in die tägliche Nachweisführung übersetzt, behandelt Executable Compliance. Einzelne Bezeichner lassen sich über Compliance Trace auflösen.
Häufige Fragen
Muss ich von 2.0 auf 2.0.3 wechseln?
Nein. Das Datenmodell ist identisch, die Bezeichner sind es auch. Der Wechsel lohnt, wenn Sie den Gap-Export brauchen, und ab Montag, wenn Sie Druckansicht oder Container nutzen wollen.
Ändern sich BAM-IDs durch diese Versionen?
Nein, und das ist der Grund für die Patch-Nummerierung. Die Stabilitätszusage gilt seit 2.0: IDs werden nicht wiederverwendet, ersetzte Objekte werden gekennzeichnet statt gelöscht, und jede Änderung ist im Änderungsprotokoll einzeln aufgeführt.
Wird der Bewertungsstand auf dem Server gespeichert?
Nein. Die Export-Endpunkte sind zustandslos, der Stand wird im Request übergeben. Gehalten wird er im Browser. Eine serverseitige Persistenz kommt erst mit dem Instanz-Layer in Version 2.2.
Was ist der Unterschied zwischen Export und Druckansicht?
Der Export liefert eine Tabelle zur Weiterverarbeitung in CSV, XLSX oder JSON. Die Druckansicht liefert ein lesbares Dokument mit Deckblatt, Zusammenfassung und Feststellungen als Fließtext, als PDF über den Druckdialog des Browsers.
Wird BAM Core damit zu einem GRC-Werkzeug?
Nein. Das ist ausdrücklich ausgeschlossen und steht so in der Roadmap. BAM Core führt den Kanon der Anforderungen, nicht den Arbeitsstand einer Organisation.
Unter welcher Lizenz steht das Ganze?
Der Code unter AGPLv3, das Datenmodell unter CC BY-SA 4.0 mit Pflicht zur Namensnennung. Das gilt unverändert auch für die neuen Versionen.
Quellen
- Brain-Media Audit Model, Repository mit README, CHANGELOG, ROADMAP und docs/IDENTIFIERS.md, GitHub.
- Compliance Trace, Auflösung einzelner BAM-Bezeichner, bam.brain-media.de.