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.

Abbildung 1: Der Gap-Export ist zustandslos Wo der Bewertungsstand liegt und wo nicht Browser hält den Stand je BAM-ID localStorage Bewertungsstand BAM Core POST /api/v2/export/gap zustandslos speichert nichts Arbeitspapier Arbeitspapier CSV · XLSX · JSON 21 Spalten je Zeile mit BAM-ID und Adresse Serverseitige Persistenz erst mit 2.2 Der Bewertungsstand verlässt den Browser nur für die Dauer eines Exports. Brain-Media.de 2026 · CC BY-SA 4.0
Abbildung 1 · Der Gap-Export ist zustandslosDer Bewertungsstand einer Organisation wird mitgegeben, verarbeitet und zurückgegeben, aber nicht abgelegt. Das ist der Grund, warum eine Installation von BAM Core keinen Mehrbenutzerbetrieb kennt, und gleichzeitig der Grund, warum sie keine Prüfungsdaten vorhält. Beides ändert sich erst mit dem Instanz-Layer in Version 2.2, und zwar bewusst zusammen.

Eigene Darstellung nach der Beschreibung der Export-Endpunkte in README.md des Repositorys brain-media-audit-model (Stand Release 2.0.3).
Darstellung: Brain-Media.de, lizenziert unter CC BY-SA 4.0.

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.

Abbildung 2: Wo die Patch-Versionen ansetzen und wo nicht Roadmap 2.1 bis 3.0 Modellerweiterungen Fristen, Instanz-Layer, Evidence-Layer, Reporting, Mandanten Minor-Nummer 2.0.x Patch-Reihe Werkzeuge und Ausgabe Gap-Export, Druckansicht, Container, Resolver Patch-Nummer 2.0 unverändert Datenmodell und Bezeichner 59 Anforderungsobjekte, BAM-IDs, ISO-27001-Zuordnung Stabilitätszusage Brain-Media.de 2026 · CC BY-SA 4.0
Abbildung 2 · Wo die Patch-Versionen ansetzenDie Stabilitätszusage gilt der unteren Schicht. Solange eine Version nur die mittlere anfasst, bleibt sie eine Patch-Version, und wer sich auf eine BAM-ID stützt, muss nichts prüfen. Erst wenn die obere Schicht erreicht wird, ändert sich die Minor-Nummer, und erst dann lohnt der Blick ins Änderungsprotokoll.

Eigene Darstellung der Versionslogik von BAM Core nach den Zusagen in docs/IDENTIFIERS.md und der Reihenfolge in ROADMAP.md.
Darstellung: Brain-Media.de, lizenziert unter CC BY-SA 4.0.

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.

Abbildung 3: Kanon und Arbeitsstand BAM Core der Kanon GRC-Werkzeug der Arbeitsstand Welche Anforderungen gibt es Wie heißen sie dauerhaft Wo überschneiden sie sich Wer ist zuständig Bis wann ist es erledigt Wie ist der Stand heute liefert IDs Export und Container machen den Kanon benutzbar. Zum Arbeitsstand machen sie ihn nicht. Brain-Media.de 2026 · CC BY-SA 4.0
Abbildung 3 · Kanon und ArbeitsstandDie linke Spalte ist das, was BAM Core führt und wofür es stabile Bezeichner vergibt. Die rechte Spalte gehört in ein Werkzeug, das Ihren Betrieb abbildet, und ändert sich täglich. Dass der Gap-Export nichts speichert, ist genau diese Grenze in technischer Form: Die rechte Seite wird mitgegeben, nicht geführt.

Eigene Darstellung der in ROADMAP.md festgehaltenen Abgrenzung, wonach BAM Core ausdrücklich kein vollständiges GRC-Werkzeug werden soll.
Darstellung: Brain-Media.de, lizenziert unter CC BY-SA 4.0.

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

  1. Brain-Media Audit Model, Repository mit README, CHANGELOG, ROADMAP und docs/IDENTIFIERS.md, GitHub.
  2. Compliance Trace, Auflösung einzelner BAM-Bezeichner, bam.brain-media.de.