BAM Core 2.0 ist veröffentlicht. Damit stellt sich die Frage, was als Nächstes kommt und in welcher Reihenfolge. Dieser Beitrag beantwortet beides, beginnt aber bewusst nicht mit einer Feature-Liste, sondern mit einem Datum, das in wenigen Tagen wirksam wird und exemplarisch zeigt, warum die nächste Version so aussieht, wie sie aussieht.

Am 11. September 2026 werden die Meldepflichten des Cyber Resilience Act anwendbar. Wer sie als Termin im Kalender führt, hat sie bereits missverstanden.

Die 24-Stunden-Kette

Der CRA ist seit Dezember 2024 in Kraft, seine Hauptpflichten greifen erst ab dem 11. Dezember 2027. Dazwischen liegt ein vorgezogener Pflichtenkomplex: Art. 14 wird am 11. September 2026 anwendbar.

Ab diesem Tag muss ein Hersteller eine aktiv ausgenutzte Schwachstelle oder einen schwerwiegenden Sicherheitsvorfall in drei Stufen melden. Eine Frühwarnung binnen 24 Stunden nach Kenntniserlangung, eine technische Meldung binnen 72 Stunden, danach ein Abschlussbericht. Adressaten sind das zuständige nationale CSIRT und die ENISA. Nach Art. 69 Abs. 3 CRA erfasst die Pflicht ausdrücklich auch Produkte, die vor dem Stichtag in Verkehr gebracht wurden. Die Steuerung, die seit 2019 im Feld steht und längst nicht mehr weiterentwickelt wird, fällt also darunter.

Verstöße gegen die Meldepflicht ordnet Art. 64 Abs. 2 CRA in dieselbe Bußgeldstufe ein wie Verstöße gegen die grundlegenden Cybersicherheitsanforderungen. Ein Meldeversäumnis wiegt regulatorisch damit so schwer wie das Inverkehrbringen eines unsicheren Produkts.

Der eigentliche Punkt

Der 11. September 2026 ist kein Termin, an dem etwas zu tun ist. Er ist der Tag, ab dem eine Uhr laufen kann. Die eigentliche Frist beginnt irgendwann danach, an einem Datum, das niemand kennt, ausgelöst durch ein Ereignis. Ein Kalendereintrag bildet das nicht ab.

Vier Arten von Fristen

Dasselbe Muster findet sich im gesamten europäischen Regulierungsrahmen. Die Meldepflichten nach NIS-2 Art. 23 folgen der Staffelung 24 Stunden, 72 Stunden, ein Monat. Die Meldung einer Verletzung des Schutzes personenbezogener Daten nach Art. 33 DSGVO läuft binnen 72 Stunden. In Deutschland stehen die entsprechenden Pflichten in § 32 BSIG. Keine dieser Fristen hat ein Datum.

Wer Fristen sauber modellieren will, braucht deshalb mindestens vier Typen:

TypAuslöserBeispiel
statutoryFester Stichtag im RechtsaktCRA Art. 14 ab 11.09.2026
recurringZyklusJährliche Überprüfung, Schulungsturnus
event_triggeredEreignis, Uhr läuft in StundenMeldekette nach NIS-2 Art. 23
derivedEigene PlanungInternes Zieldatum für eine Maßnahme

Der dritte Typ ist der, den Werkzeuge regelmäßig auslassen, und zugleich der, an dem Bußgelder hängen.

Was 2.1 konkret bringt

Fristen werden eigenständige Objekte, nicht Felder in einem Anforderungsobjekt. Das hat zwei Konsequenzen.

Erstens lassen sich ereignisgesteuerte Ketten als Ablauf abbilden. Ein Vorfall startet die Uhr, die Stufen werden nacheinander fällig, jede Stufe hat einen Verantwortlichen und einen Nachweis. Wer die 24-Stunden-Frist reißt, tut das in aller Regel nicht aus technischen Gründen, sondern weil Herstellerrolle, Zuständigkeit und Entscheidungsweg nicht vorab geklärt waren.

Zweitens werden Fristen an den Regulatory-Change-Layer aus 2.0 gekoppelt. Der AI-Omnibus hat die Hochrisiko-Fristen des EU AI Act gestaffelt, auf den 2. Dezember 2027 für Anhang III und den 2. August 2028 für Anhang I. Wenn die Frist ein eigenes Objekt mit Verweis auf den auslösenden Änderungsvorgang ist, aktualisiert ein Change-Eintrag sie. Steht sie dagegen als Feld im Anforderungsobjekt, widerspricht sie ihm irgendwann.

Stresstest · 20 Minuten

Trägt Ihre Meldekette am 11. September?

Kostenloser Compliance-Stresstest, unabhängig vom eigenen BAM-Core-Einsatz.

Stresstest starten →

Die Roadmap: Reihenfolge statt Termine

Die vollständige Roadmap liegt als ROADMAP.md im Repository. Sie nennt bewusst keine Termine, sondern eine Reihenfolge, und zwar aus demselben Grund, der oben schon trägt: Die Prioritäten von BAM ergeben sich aus einer externen Uhr, nicht aus einer internen Planung. Was oben steht, steht dort, weil ein Rechtsakt es dorthin gestellt hat.

2.2 Instanz-Layer

Trennung von Kanon und Zustand. Das Datenmodell bleibt das frei lizenzierte, versionierte Referenzwerk. Der Bewertungszustand einer Organisation bekommt eine eigene Persistenz: Gap-Status je Objekt, Begründung, Verantwortlicher, Zieldatum, Historie. Eine Frist ohne Verantwortlichen ist Anzeige, keine Steuerung. Insofern ist 2.2 weniger ein eigenes Feature als die Voraussetzung dafür, dass 2.1 im Betrieb trägt.

2.3 Evidence Layer

Nachweise werden eigenständige Objekte mit Mehrfachbeziehung zu den Anforderungen. Erst damit gilt das Prinzip Collect Once. Comply Many. auch für den Nachweis und nicht nur für die Anforderung. Ein einzelnes Berechtigungsreview belegt gleichzeitig Pflichten aus NIS-2, DORA und ISO 27001.

Dazu kommt eine Eigenschaft, die in der Praxis unterschätzt wird: Nachweise altern. Ein Penetrationstestbericht von 2024 ist 2026 kein gültiger Nachweis mehr. Mit Gültigkeitszeitraum und Prüfintervall erzeugt ein ablaufender Nachweis automatisch eine wiederkehrende Frist. Die beiden Versionen greifen ineinander.

Vorgesehen ist außerdem ein eigener Zustand für "als erfüllt bewertet, aber ohne hinterlegten Nachweis". Das ist der Unterschied zwischen einer Selbstauskunft und einem prüffähigen Ergebnis.

2.4 Reporting

Erzeugung prüffähiger Dokumente aus dem vorhandenen Modell. Die Anwendbarkeitserklärung nach ISO 27001 lässt sich aus dem bereits enthaltenen Control-Mapping über alle 93 Controls ableiten. Dazu Managementbericht für das Leitungsorgan, Maßnahmenplan mit Aufwandsschätzung und ein Prüferpaket aus Anforderung, Nachweisverweis und Änderungshistorie.

2.5 Nationale Umsetzungsebene

Hier liegt die größte inhaltliche Lücke. BAM bildet NIS-2 auf EU-Artikelebene ab. Geprüft wird in Deutschland gegen das neugefasste BSI-Gesetz, das seit dem 6. Dezember 2025 gilt und keine materiellen Übergangsfristen kennt. Die Registrierungspflicht nach § 33 BSIG war drei Monate später fällig, zum 6. März 2026. Erreicht wurde sie von deutlich weniger als der Hälfte der rund 29.500 betroffenen Einrichtungen.

Ein Zuordnungsfeld je Objekt, das die nationale Vorschrift neben den EU-Artikel stellt, ist für den deutschen Markt der größte einzelne Zugewinn. Parallel dazu ein JSON Schema für das Datenmodell samt Validierung in der CI, ohne das Beiträge von außen nicht handhabbar sind.

3.0 und danach

Mandantenfähigkeit mit Rollen und Freigabeworkflow markiert die Schwelle vom Einzelplatzwerkzeug zum mehrbenutzerfähigen System. Erwogen, aber noch nicht entschieden sind eine MCP-Schnittstelle für Agenten und LLM-Workflows, Konnektoren für technisch erhobene Nachweise und ein eigener Objekttyp für Dienstleister entlang des DORA-Informationsregisters.

Was bewusst nicht kommt

BAM wird kein vollständiges GRC-Werkzeug. Der Wert liegt im Datenmodell und in der fachlichen Kuratierung, nicht in der Oberfläche. Und Anforderungsobjekte werden weiterhin nicht automatisch aus Gesetzestexten erzeugt. Solange ein Verfahren offen ist, wird es beobachtet und dokumentiert, nicht in Anforderungen übersetzt. Diese Zurückhaltung ist kein Mangel an Automatisierung, sie ist das Qualitätsmerkmal.

Vier Fragen für die kommende Woche

Wer heute prüfen will, ob die eigene Meldekette trägt, braucht dafür kein Werkzeug. Vier Fragen genügen: Wer erklärt eine Schwachstelle für aktiv ausgenutzt? Wer entscheidet innerhalb von 24 Stunden über die Meldung? Wer hat Zugang zur Meldeplattform? Und wer übernimmt das am Wochenende?

Wenn eine dieser Fragen offen ist, ist das kein Compliance-Problem, sondern ein Organisationsproblem. Genau deshalb steht Fristenmanagement in der Roadmap vor allem anderen.

Quellen