MRIS.bd 2.0, benutzerdefinierte Bausteine für den IT-Grundschutz. Stand 19.09.2026
Die 13 MHC als Bausteinfamilie für den IT-Grundschutz
Ein Prozessbaustein für den gesamten Informationsverbund und vier Systembausteine für Identitäts- und Zugangssysteme, Datensicherung, Ausführungsplattformen und KI-Agenten. 23 Anforderungen mit Umsetzungshinweisen, Kreuzreferenztabelle und maschinenlesbarer Fassung, direkt nutzbar in Modellierung und IT-Grundschutz-Check.
Kostenlos unter CC BY-SA 4.0, ohne Registrierung. Benutzerdefinierte Bausteine nach BSI-Standard 200-2, keine offiziellen Anforderungen des BSI.
Wählen Sie ein Feld aus, um Anforderung, Stufe, Zuständigkeit und umgesetztes MHC zu sehen.
23 Anforderungen in 5 Bausteinen
14 Basis-, 6 Standard- und 3 Anforderungen bei erhöhtem Schutzbedarf. Alle 13 MHC sind abgedeckt.
bd.1
bd.2.1
bd.2.2
bd.2.3
bd.2.4
Was sich mit Version 2.0 ändert
Bausteinfamilie
Ein Prozessbaustein und vier Systembausteine mit je einer Modellierungsregel statt eines Einzelbausteins.
Regelung und Technik getrennt
Phishing-resistente MFA, Datensicherung und KI-Agenten: Festlegung in MRIS.bd.1, Durchsetzung am Zielobjekt.
KI-Verordnung
Rolle (Anbieter oder Betreiber) und Einstufung je KI-Agent im Inventar; 10 informative Zuordnungen zu Vorschriften der KI-VO.
Grundschutz-Begriffe statt SoA
Sicherheitskonzept, Modellierung, IT-Grundschutz-Check und „entbehrlich“. Die SoA bleibt nur als Hinweis für ISO 27001 auf der Basis von IT-Grundschutz.
21 neue Anforderungssätze
Aus Feedback und den Umsetzungshinweisen v1.3. MUSS nur noch in Basis-Anforderungen, je Satz ein Modalverb.
YAML als Master
Struktur, Anforderungstexte und Herkunft je Satz in einer Datei; Bausteine und Kreuzreferenztabelle werden daraus erzeugt.
Der Prozessbaustein regelt, was für den gesamten Informationsverbund einmal festzulegen ist; die Systembausteine setzen es an den Zielobjekten technisch um. Jeder Baustein hat genau eine Modellierungsregel und ergänzt die Bausteine des IT-Grundschutz-Kompendiums, die für diese Zielobjekte ohnehin gelten. Er ersetzt keinen davon.
MRIS.bd.1, Prozessbaustein
Mythos-resistente Härtung des ISMS
Zielobjekte
gesamter Informationsverbund (einmal)
Anforderungen
11: 6 Basis, 4 Standard, 1 erhöhter Schutzbedarf
Zuständig
Informationssicherheitsbeauftragte (ISB); weitere Rollen: IT-Betrieb, Entwickler
Einmal auf den gesamten Informationsverbund anzuwenden. Die Systembausteine MRIS.bd.2.1 bis MRIS.bd.2.4 sind zusätzlich auf die jeweiligen Zielobjekte anzuwenden.
MRIS.bd.2.1, Systembaustein
Identitäts- und Zugangssysteme
Zielobjekte
Identitätsanbieter, Verzeichnisdienste, Fernzugänge, PAM-Systeme, Anwendungen mit eigener Anmeldung
Anforderungen
2: 1 Basis, 1 Standard
Zuständig
IT-Betrieb
Ergänzt
ORP.4, APP.2.1, APP.2.2, APP.2.3, NET.3.3
Modellierungsregel
Auf jeden Identitätsanbieter, jeden Verzeichnisdienst, jeden Fernzugang (etwa VPN) und jedes System für privilegierte Zugänge (PAM) anzuwenden, außerdem auf jede Anwendung mit eigener Anmeldung, für deren Zugänge nach MRIS.bd.1.A2 phishing-resistente Verfahren festgelegt sind.
MRIS.bd.2.2, Systembaustein
Datensicherungssysteme
Zielobjekte
Systeme, die Datensicherungen speichern oder verwalten
Anforderungen
2: 2 Basis
Zuständig
IT-Betrieb
Ergänzt
CON.3, SYS.1.8
Modellierungsregel
Auf jedes System anzuwenden, das Datensicherungen speichert oder verwaltet, etwa Backup-Server, Speichersysteme für Sicherungskopien und Backup-Dienste in der Cloud.
MRIS.bd.2.3, Systembaustein
Ausführungsplattformen
Zielobjekte
Container-, Virtualisierungs- und Cloud-Plattformen
Anforderungen
3: 1 Basis, 2 erhöhter Schutzbedarf
Zuständig
IT-Betrieb; weitere Rollen: Entwickler
Ergänzt
SYS.1.5, SYS.1.6, APP.4.4, OPS.2.2
Modellierungsregel
Auf jede Plattform anzuwenden, auf der produktive Anwendungen und Dienste betrieben werden, insbesondere Container-Orchestrierung, Virtualisierung und Cloud-Plattformen (IaaS, PaaS).
MRIS.bd.2.4, Systembaustein
KI-Agenten
Zielobjekte
produktiv eingesetzte KI-Agenten und agentische Abläufe
Anforderungen
5: 4 Basis, 1 Standard
Zuständig
IT-Betrieb; weitere Rollen: Entwickler, Fachverantwortliche
Ergänzt
kein Kompendium-Baustein
Modellierungsregel
Auf jeden produktiv eingesetzten KI-Agenten und jeden agentischen Ablauf anzuwenden. Gleichartige KI-Agenten können nach den Regeln der Strukturanalyse zu Gruppen zusammengefasst werden.
15 spezifische Gefährdungen
Seit Mitte 2026 sind agentische Frontier-AI-Modelle der Mythos-Klasse anbieterübergreifend verfügbar. Viele Wirksamkeitsannahmen des bewusst technologieneutralen Kompendiums setzen weiterhin auf die begrenzte Geduld, Geschwindigkeit und Kapazität menschlicher Angreifer. Der Prozessbaustein benennt fünf übergreifende Verschiebungen, die Systembausteine zehn Gefährdungen ihrer Zielobjekte.
bd.1 Mythos-resistente Härtung des ISMS
bd.1.G1Kollaps des Zeitfensters zwischen Patch und ExploitZwischen der Veröffentlichung eines Patches und der Verfügbarkeit eines funktionierenden Exploits liegen unter KI-Bedingungen Stunden statt Tage oder Wochen.
bd.1.G2Kompression der ReaktionszeitachseKI-gesteuerte Angriffe laufen schneller ab, als menschliche Reaktionsketten entscheiden können.
bd.1.G3Fragmentierung von Angriffen in unauffällige MikroschritteAgentische Angreifer zerlegen einen Gesamtangriff in Einzelaktionen, die jeweils wie legitime technische Anfragen erscheinen.
bd.1.G4Entkopplung von Angreiferfähigkeit und AkteurstypDie Kapazitätsbarriere zwischen Gelegenheitstätern und hochprofessionellen Angreifergruppen ist weitgehend entfallen.
bd.1.G5Ungeregelter Einsatz privilegierter KI-AgentenProduktiv eingesetzte KI-Agenten mit weitreichenden Rechten bilden eine neue, oft ungemanagte Angriffsfläche innerhalb der Institution.
bd.2.1 Identitäts- und Zugangssysteme
bd.2.1.G1KI-gestütztes Phishing auf Spear-Phishing-NiveauAgentische KI-Modelle erzeugen individualisierte, sprachlich fehlerfreie Phishing-Kampagnen in beliebiger Zahl, sodass die Erkennbarkeit für Benutzende als Schutz entfällt.
bd.2.1.G2Umgehung über Rückfall- und WiederherstellungsverfahrenBleiben schwächere Verfahren als Rückfalloption aktiv oder ist die Wiederherstellung von Authentisierungsmitteln ungesichert, weichen Angreifer gezielt auf diese Pfade aus.
bd.2.2 Datensicherungssysteme
bd.2.2.G1Manipulation von Sicherungen über kompromittierte AdministrationsrechteWird die Datensicherung mit Rechten der Produktionsumgebung verwaltet, können kompromittierte Administrationskonten Sicherungen löschen, verschlüsseln oder ihre Unveränderlichkeit aufheben.
bd.2.2.G2Abschluss des Angriffs vor der ErkennungKI-gesteuerte Angriffe können abgeschlossen sein, bevor Erkennung und Reaktion greifen; dann entscheidet allein die Wiederherstellbarkeit über den Schaden.
bd.2.3 Ausführungsplattformen
bd.2.3.G1Seitwärtsbewegung über gemeinsame Geheimnisse und NetzwerkvertrauenLanglebige gemeinsame Geheimnisse und eine Autorisierung anhand der Netzwerklage ermöglichen es Angreifern, sich nach einem ersten Zugriff unbemerkt zwischen Diensten zu bewegen.
bd.2.3.G2Manipulierte Images in der LieferketteUnsignierte oder ungeprüfte Images können manipulierte Komponenten unbemerkt in den Produktivbetrieb bringen.
bd.2.3.G3Mandantenübergreifende AusbreitungIst die Mandantentrennung nur auf Anwendungsebene umgesetzt, genügt ein einzelner Fehler, damit ein Angreifer aus einem Mandanten auf andere zugreift.
bd.2.4 KI-Agenten
bd.2.4.G1Übernahme von KI-Agenten durch Prompt-Injection und manipulierte WerkzeugdefinitionenEin übernommener KI-Agent handelt mit seinen Rechten innerhalb der legitimen Infrastruktur, ohne dass der Angreifer eigene Zugangsdaten benötigt.
bd.2.4.G2Pauschale Rechte und fehlende ZuordenbarkeitKI-Agenten mit pauschalen Rechten unter persönlichen Benutzerkonten und ohne Audit-Trail sind weder begrenzbar noch sauber zuordenbar.
bd.2.4.G3Unkontrollierte agentische KomponentenMCP-Server, IDE-Erweiterungen und Skills aus ungeprüften Quellen erweitern KI-Agenten um Code, der außerhalb jeder Sicherheitsbetrachtung liegt.
Kreuzreferenz zu den elementaren Gefährdungen
Ein Punkt bedeutet: Die Anforderung wirkt der elementaren Gefährdung des IT-Grundschutz-Kompendiums entgegen. 23 Anforderungen, 19 elementare Gefährdungen, 61 Zuordnungen; identisch mit der Kreuzreferenztabelle im Paket.
Kreuzreferenz: Anforderungen und elementare Gefährdungen
Anforderung
0.14
0.15
0.18
0.19
0.20
0.21
0.23
0.28
0.29
0.30
0.31
0.32
0.36
0.37
0.39
0.40
0.42
0.45
0.46
Summe
bd.1.A1
1
bd.1.A2
3
bd.1.A3
3
bd.1.A4
3
bd.1.A5
3
bd.1.A6
3
bd.1.A7
3
bd.1.A8
2
bd.1.A9
3
bd.1.A10
3
bd.1.A11
4
bd.2.1.A1
3
bd.2.1.A2
2
bd.2.2.A1
2
bd.2.2.A2
3
bd.2.3.A1
4
bd.2.3.A2
3
bd.2.3.A3
3
bd.2.4.A1
2
bd.2.4.A2
1
bd.2.4.A3
2
bd.2.4.A4
2
bd.2.4.A5
3
Summe
3
1
3
2
5
5
7
4
2
4
2
5
4
2
4
1
3
2
2
61
Bezeichnungen der elementaren Gefährdungen
G 0.14 Ausspähen von Informationen (Spionage)
G 0.15 Abhören
G 0.18 Fehlplanung oder fehlende Anpassung
G 0.19 Offenlegung schützenswerter Informationen
G 0.20 Informationen oder Produkte aus unzuverlässiger Quelle
G 0.21 Manipulation von Hard- oder Software
G 0.23 Unbefugtes Eindringen in IT-Systeme
G 0.28 Software-Schwachstellen oder -Fehler
G 0.29 Verstoß gegen Gesetze oder Regelungen
G 0.30 Unberechtigte Nutzung oder Administration von Geräten und Systemen
G 0.31 Fehlerhafte Nutzung oder Administration von Geräten und Systemen
G 0.32 Missbrauch von Berechtigungen
G 0.36 Identitätsdiebstahl
G 0.37 Abstreiten von Handlungen
G 0.39 Schadprogramme
G 0.40 Verhinderung von Diensten (Denial of Service)
G 0.42 Social Engineering
G 0.45 Datenverlust
G 0.46 Integritätsverlust schützenswerter Informationen
23 Anforderungen, drei Stufen, fünf Bausteine
Jede Anforderung mit ihren Sätzen im Wortlaut, dem umgesetzten MHC, der Zuständigkeit, dem Bezug zu ISO/IEC 27002 und einer Messgröße. Sätze mit Bezug zur KI-Verordnung sind markiert.
23 von 23 Anforderungen.
MRIS.bd.1 Mythos-resistente Härtung des ISMS
bd.1.A1Neubewertung der Wirksamkeitsannahmen bestehender SicherheitsmaßnahmenBasis
Die Institution MUSS die Wirksamkeits- und Wahrscheinlichkeitsannahmen der implementierten Sicherheitsmaßnahmen gegen die KI-beschleunigte Bedrohungslage neu bewerten.
Sicherheitsmaßnahmen, deren Schutzwirkung überwiegend auf Angreiferreibung statt auf einer harten strukturellen Barriere beruht, MÜSSEN dabei identifiziert werden.
Die Ergebnisse der Neubewertung MÜSSEN in die Risikoanalyse einfließen.
Falls die Schutzwirkung einer Maßnahme als degradiert bewertet wird, dann MUSS über Härtung, Kompensation oder begründete Risikoübernahme entschieden werden.
Die Neubewertung MUSS bei wesentlichen Änderungen der Bedrohungslage wiederholt werden.
Setzt um
übergreifend, kein einzelnes MHC
Zuständig
Informationssicherheitsbeauftragte (ISB)
ISO/IEC 27002
entspricht Annex A (gesamt)
Gefährdungen
bd.1.G1, bd.1.G2, bd.1.G3, bd.1.G4, bd.1.G5 G 0.18
Messung
Anteil der neu bewerteten Annex-A-Maßnahmen (Zielwert 100 %); dokumentierte Entscheidung je degradierter Maßnahme
Die Institution MUSS in einer Authentisierungsrichtlinie festlegen, für welche Benutzenden, Anwendungen und Zugänge phishing-resistente Verfahren verpflichtend sind.
In der Authentisierungsrichtlinie MÜSSEN je Zugangsklasse die zugelassenen Verfahren festgelegt werden.
Für alle privilegierten Zugänge MÜSSEN Verfahren nach FIDO2/WebAuthn (Passkeys oder Hardware-Token) festgelegt werden.
Für alle Zugänge zu extern erreichbaren Diensten MÜSSEN phishing-resistente Verfahren festgelegt werden.
Für Zugänge zu Systemen mit erhöhtem Schutzbedarf SOLLTEN phishing-resistente Verfahren festgelegt werden.
SMS-basierte Verfahren und einfache Push-Bestätigungen ohne Number-Matching DÜRFEN für neue Zugänge NICHT eingesetzt werden.
Für bestehende Legacy-MFA-Verfahren MUSS ein Ablösungsplan mit Termin dokumentiert werden.
Ausnahmen von der Authentisierungsrichtlinie MÜSSEN befristet werden.
Ausnahmen MÜSSEN mit Begründung dokumentiert werden.
Die Registrierungs- und Wiederherstellungsprozesse für Authentisierungsmittel MÜSSEN gegen Social Engineering abgesichert werden.
Die Authentisierungsrichtlinie SOLLTE regelmäßig überprüft werden.
Anteil der Anmeldungen über phishing-resistente Verfahren je Zugangsklasse (Zielwert: vollständige Abdeckung der privilegierten und extern erreichbaren Zugänge)
bd.1.A3Vorhalten unveränderlicher Datensicherungen mit regelmäßigen WiederherstellungstestsBasis
Für alle geschäftskritischen Datenbestände MUSS mindestens eine unveränderliche oder vom Netz getrennte Sicherungskopie vorgehalten werden.
Die Datensicherung SOLLTE nach dem 3-2-1-1-0-Prinzip aufgebaut werden.
Wiederherstellungstests MÜSSEN mindestens vierteljährlich durchgeführt werden.
Die Wiederherstellungstests MÜSSEN dokumentiert werden.
Falls ein Wiederherstellungstest fehlschlägt, dann MUSS die Ursache unverzüglich behoben werden.
Erfolgsquote der vierteljährlichen Wiederherstellungstests (Zielwert 100 %)
bd.1.A4Aufbau einer verhaltensbasierten Angriffserkennung mit EreigniskorrelationBasis
Die Institution MUSS über Verfahren zur Erkennung von Angriffen anhand von Verhaltensauffälligkeiten und der Korrelation zusammenhängender Ereignisse verfügen.
Die Erkennungsregeln MÜSSEN sich an einem anerkannten Katalog von Angriffstechniken (MITRE ATT&CK) orientieren.
Die Abdeckung der wichtigsten Angriffstechniken MUSS gemessen werden.
Die gemessene Abdeckung MUSS regelmäßig überprüft werden.
Threat-Hunting SOLLTE als feste Funktion mit dokumentierter Methodik etabliert werden.
Falls kein eigenes Security Operations Center betrieben wird, dann SOLLTE ein Managed-Detection-and-Response-Dienst mit vergleichbarem Leistungsumfang beauftragt werden.
Gemessene und durch Tests bestätigte ATT&CK-Abdeckung (Richtwert ≥ 60 % der zehn wichtigsten Techniken der eigenen Branche); Zahl und Ergebnis der Hunts
bd.1.A5Erstellung eines kryptografischen Inventars und einer Post-Quantum-MigrationsstrategieBasis
Die Institution MUSS ein Inventar aller eingesetzten kryptografischen Verfahren, Schlüssellängen und Implementierungen führen.
Falls Daten mit langer Vertraulichkeitsdauer verarbeitet werden, dann MUSS eine dokumentierte Migrationsstrategie zu quantensicheren Verfahren vorliegen.
Falls Daten mit langer Vertraulichkeitsdauer übertragen werden, dann SOLLTEN im Übergang hybride Verfahren eingesetzt werden.
Inventar und Strategie MÜSSEN mindestens jährlich oder anlassbezogen überprüft werden.
Bei Neubeschaffungen SOLLTE die Unterstützung quantensicherer oder austauschbarer Verfahren als Anforderung aufgenommen werden.
Setzt um
MHC-01 Post-Quantum-Strategie und kryptografisches Inventar
Zuständig
Informationssicherheitsbeauftragte (ISB)
ISO/IEC 27002
flankiert A.8.24
Gefährdungen
bd.1.G4 G 0.14, G 0.15, G 0.19
Messung
Anteil der erfassten und nach Migrationspriorität eingestuften Verfahren; Toleranzgrenze: keine langlebig vertraulichen Daten ohne Migrationsplan
bd.1.A6Geregelter Einsatz von KI-AgentenBasis
Die Institution MUSS ein Inventar aller produktiv eingesetzten KI-Agenten und agentischen Abläufe führen.
Das Inventar MUSS selbst entwickelte Agenten ebenso umfassen wie Agenten, die als Software-as-a-Service oder über Low-Code- und No-Code-Plattformen betrieben werden.
Das Inventar MUSS je KI-Agent ausweisen, welche Rolle die Institution nach der KI-Verordnung einnimmt (Anbieter, Betreiber oder beides) und wie das zugrunde liegende KI-System eingestuft ist.KI-VO
Bei wesentlichen Änderungen an einem KI-Agenten SOLLTE geprüft werden, ob sich die Rolle der Institution dadurch ändert.KI-VO
Falls KI-Agenten produktiv eingesetzt werden, dann MÜSSEN diese wie privilegierte Systeme behandelt werden.
Für jeden produktiven KI-Agenten MUSS eine verantwortliche Person benannt werden.KI-VO
Für agentische Komponenten wie MCP-Server, IDE-Erweiterungen und Skills MUSS eine Freigabeliste gepflegt werden.
Inventar-Abdeckung (Zielwert 100 %); Governance-Abdeckung: Anteil mit dokumentiertem Bedrohungsmodell, benannter verantwortlicher Person, begrenzter Identität und Berechtigungsgrenzen (Zielwert 100 %)
bd.1.A7Erzeugung von Software-Stücklisten und Build-Provenance-NachweisenStandard
Für jede selbst erstellte und weitergegebene Software SOLLTE automatisch in der Build-Pipeline eine Software-Stückliste (SBOM) in einem standardisierten Format erzeugt werden.
Die Stückliste SOLLTE auch die transitiven Abhängigkeiten erfassen.
Die erfassten Komponenten SOLLTEN automatisiert gegen Schwachstellendatenbanken abgeglichen werden.
Falls eine neue Schwachstelle bekannt wird, dann SOLLTE die eigene Betroffenheit anhand der Stücklisten innerhalb von 24 Stunden ermittelbar sein.
Für kritische Artefakte SOLLTE eine manipulationssichere Build-Provenance vorgehalten werden.
Von kritischen Softwarelieferanten SOLLTE die Bereitstellung einer Stückliste vertraglich eingefordert werden.
SBOM-Coverage: Anteil der ausgelieferten Artefakte mit aktueller, automatisch erzeugter Stückliste (Zielwert: vollständige Abdeckung)
bd.1.A8Integration automatisierter Sicherheitstests in die Entwicklungs-PipelineStandard
Sicherheitsprüfungen des Quellcodes, der Abhängigkeiten und der laufenden Anwendung SOLLTEN automatisiert in der Entwicklungs-Pipeline bei jeder Änderung ausgeführt werden.
Schwerwiegende Funde SOLLTEN die Übernahme in den Hauptzweig blockieren.
KI-generierter Code SOLLTE als eigener Risikofaktor im Standard für sichere Entwicklung und in der Risikobewertung berücksichtigt werden.
KI-generierter Code SOLLTE zusätzlich geprüft werden.
Für geeignete Anwendungen SOLLTEN ergänzend KI-gestützte Testverfahren eingesetzt werden.
Falls eine aktiv ausgenutzte Schwachstelle in einer eingesetzten Komponente bekannt wird, dann SOLLTE für internet-exponierte Systeme innerhalb von 24 Stunden eine wirksame Behebung umgesetzt werden.
Als wirksame Behebung gelten Patch, Umgehungslösung, kompensierende Maßnahme, Trennung vom Netz oder Ablösung der Komponente.
Behebungslatenz für aktiv ausgenutzte Schwachstellen (KEV) ab Verfügbarkeit einer belastbaren Behebung (Richtwert für internet-exponierte Systeme < 24 h); Anteil der Pipelines mit Sicherheitsprüfung und Pre-Merge-Block
bd.1.A9Automatisierung der Vorfallsreaktion mit abgesicherten PlaybooksStandard
Für eindeutige Vorfallstypen SOLLTEN vordefinierte, automatisierte Reaktions-Playbooks vorliegen.
Die Eindämmung eindeutiger Vorfälle SOLLTE automatisiert innerhalb von Minuten eingeleitet werden.
Mehrdeutige oder schwerwiegende Fälle SOLLTEN gezielt an dafür zuständige Personen eskaliert werden.
Falls eine automatische Aktion eine große Schadwirkung entfalten kann, dann SOLLTE vor der Ausführung eine menschliche Freigabe erfolgen.
Die Automatisierungsschicht selbst SOLLTE gehärtet werden, insbesondere durch authentisierte Auslöser, vollständigen Audit-Trail und Rate-Limits.
Übungen für mehrere parallele Vorfälle SOLLTEN mindestens halbjährlich durchgeführt werden.
Falls kein eigenes Security-Team vorhanden ist, dann KANN ein Managed-Detection-and-Response-Dienst mit vertraglich vereinbarter Eindämmungszeit genutzt werden.
Zeit bis zur Eindämmung eindeutiger Vorfälle (Richtwert < 10 min bei hoher Eindeutigkeit)
bd.1.A10Einrichtung einer kontinuierlichen automatisierten WirksamkeitsprüfungStandard
Die Einhaltung der im Sicherheitskonzept vorgesehenen Sicherheitsmaßnahmen SOLLTE laufend und automatisiert gegen festgelegte Soll-Zustände geprüft werden.
Sicherheitsvorgaben SOLLTEN, wo möglich, als ausführbare Regeln (Policy-as-Code) formuliert werden.
Diese Regeln SOLLTEN in die Bereitstellungs- und Betriebsprozesse eingebunden werden.
Abweichungen SOLLTEN alarmiert werden.
Abweichungen SOLLTEN nachverfolgt werden.
Eine automatisierte Reaktion auf Abweichungen SOLLTE angestrebt werden.
Die Institution SOLLTE dokumentieren, welche Sicherheitsmaßnahmen technisch automatisiert prüfbar sind.
Der Anteil der automatisiert geprüften Maßnahmen SOLLTE bezogen auf diese als automatisierbar eingestuften Maßnahmen gemessen werden.
Automatisierungs-Eignung: Anteil der im Sicherheitskonzept vorgesehenen Maßnahmen, die technisch automatisiert prüfbar sind; Continuous-Monitoring-Coverage (Richtwerte ≥ 60 % nach 12, ≥ 80 % nach 24 Monaten)
bd.1.A11Durchführung bedrohungsgeleiteter Penetrationstests mit KI-Szenarienerhöhter Schutzbedarf
Die Wirksamkeit der Schutzmaßnahmen SOLLTE regelmäßig durch bedrohungsgeleitete Penetrationstests (Threat-Led Penetration Testing) geprüft werden.
Die Testszenarien SOLLTEN KI-typische Vorgehensweisen einschließen, insbesondere fragmentierte Angriffsketten, parallele Multi-Vector-Angriffe und KI-gestütztes Spear-Phishing.
Zwischen den Testzyklen SOLLTEN gemeinsame Übungen von Angriffs- und Verteidigungsseite (Purple Team) stattfinden.
Festgestellte kritische Funde SOLLTEN innerhalb eines vereinbarten Zeitfensters behoben werden.
Anteil der Zugänge des Systems, die technisch auf die festgelegten Verfahren beschränkt sind (Zielwert 100 %); keine aktive Rückfalloption mit nicht zugelassenen Verfahren
bd.2.1.A2Protokollierung von AuthentisierungsvorgängenStandard
Das bei einer Anmeldung verwendete Authentisierungsverfahren SOLLTE protokolliert werden.
Die Registrierung und die Änderung von Authentisierungsmitteln SOLLTEN protokolliert werden.
Nachweis der getrennten Rechtevergabe; kein Administrationskonto der Produktionsumgebung mit Zugriff auf das Datensicherungssystem
bd.2.2.A2Technische Durchsetzung der UnveränderlichkeitBasis
Falls Sicherungskopien unveränderlich vorgehalten werden, dann MUSS die Unveränderlichkeit technisch erzwungen werden.
Die Aufbewahrungssperre MUSS so konfiguriert werden, dass sie während der Aufbewahrungsfrist auch mit administrativen Rechten nicht aufgehoben werden kann.
Die Aufbewahrungs- und Sperreinstellungen SOLLTEN dokumentiert werden.
Anteil der produktiven Dienst-zu-Dienst-Verbindungen mit Workload-Identität und mTLS (Richtwerte: Stufe 1 ≥ 80 % der privilegierten Service-Workloads, Stufe 2 mTLS für ≥ 95 % des Ost-West-Verkehrs); Zeit bis zum Entzug einer Identität
bd.2.3.A2Einsatz signierter Container-Images und geschützter Ausführungsumgebungenerhöhter Schutzbedarf
Falls auf der Plattform produktive Container betrieben werden, dann SOLLTEN diese ausschließlich aus signierten, vor dem Start geprüften Images aus kontrollierten Registries gestartet werden.
Die Prüfung SOLLTE technisch über die Plattform durchgesetzt werden, etwa mit Admission-Controller-Policies.
Falls Workloads einen besonders hohen Schutzbedarf haben, dann SOLLTEN geschützte Ausführungsumgebungen (Confidential Computing) mit Remote-Attestation eingesetzt werden.
Anteil der produktiven Container aus signierten, geprüften Images (Zielwert: vollständig); Abdeckung von Confidential Computing bei hochsensiblen Workloads; Toleranzgrenze: kein produktiver Container ohne gültige Signatur und Prüfung
bd.2.3.A3Umsetzung einer nachweisbaren Mandantentrennungerhöhter Schutzbedarf
Falls mandantenfähige Dienste betrieben werden, dann SOLLTEN Daten, Netzwerke und Rechenressourcen je Mandant getrennt werden.
Die Datentrennung SOLLTE mit mandantenspezifischen Schlüsseln umgesetzt werden.
Die Wirksamkeit der Trennung SOLLTE durch regelmäßige, möglichst automatisierte Tests nachgewiesen werden.
Falls ein mandantenübergreifender Zugriff festgestellt wird, dann SOLLTE dieser unverzüglich unterbunden werden.
Ergebnis der Trennungstests (kein mandantenübergreifender Zugriff nachweisbar); Häufigkeit und Abdeckung der Tests
MRIS.bd.2.4 KI-Agenten
bd.2.4.A1Einrichtung einer begrenzten Identität für den KI-AgentenBasis
Der KI-Agent MUSS eine technische, auf die erforderlichen Rechte begrenzte Identität erhalten.
Falls die eingesetzte Plattform keine agentenspezifische Identität unterstützt, dann MUSS eine kontrollierte Delegation mit minimalen Rechten über ein eigenes Dienstkonto erfolgen.
Die Berechtigungsgrenzen dieser Delegation MÜSSEN dokumentiert werden.
Zeit bis zum Entzug kompromittierter Agent-Identitäten (Zielwert < 5 min)
bd.2.4.A2Protokollierung der Aktionen des KI-AgentenBasis
Aktionen des KI-Agenten mit Schreib- oder Netzwerkrechten MÜSSEN lückenlos und der auslösenden menschlichen Identität zuordenbar protokolliert werden.KI-VO
Die Aufbewahrungsdauer der Protokolle SOLLTE unter Berücksichtigung gesetzlicher, vertraglicher und forensischer Anforderungen festgelegt werden.KI-VO
Anteil der eingesetzten agentischen Komponenten, die in der Freigabeliste geführt sind (Zielwert 100 %)
bd.2.4.A5Prüfung der Agentensteuerung vor der ProduktivsetzungStandard
Falls Prompts, Werkzeugdefinitionen, Retrieval-Pipelines oder Eskalationslogik des KI-Agenten unter der Kontrolle der Institution stehen, dann SOLLTEN diese Komponenten wie Produktivcode einem Code-Review unterzogen werden.KI-VO
Falls diese Komponenten vom Hersteller kontrolliert werden, dann SOLLTEN stattdessen Nachweise des Herstellers zu ihrer Absicherung eingefordert werden.KI-VO
Vor der Produktivsetzung SOLLTE der KI-Agent auf Anfälligkeit für Prompt-Injection und Confused-Deputy-Angriffe getestet werden.KI-VO
Anteil der produktiven KI-Agenten mit dokumentierter Prüfung vor der Produktivsetzung (Zielwert 100 %)
In das Sicherheitskonzept übernehmen
Modellierung
MRIS.bd.1 einmal für den gesamten Informationsverbund, MRIS.bd.2.1 bis MRIS.bd.2.4 auf die jeweiligen Zielobjekte. Gibt es keine Zielobjekte eines Typs, entfällt der zugehörige Systembaustein.
IT-Grundschutz-Check
Nicht zutreffende Anforderungen werden als entbehrlich gekennzeichnet und begründet, typisch MRIS.bd.1.A7 und A8 ohne eigene Softwareentwicklung (das Prinzip wirkt dann über die Beschaffung) und MRIS.bd.2.3.A3 ohne mandantenfähigen Betrieb.
Reihenfolge
Neubewertung (MRIS.bd.1.A1) vor Investitionen. Erkennung (A4) vor Reaktionsautomatisierung (A9). Stücklisten (A7) vor Pipeline-Tests (A8). Regelung in MRIS.bd.1 vor Durchsetzung in den Systembausteinen. Bedrohungsgeleitete Tests (A11) nach der Basisumsetzung.
Zuständigkeiten
Grundsätzlich zuständig sind der ISB für MRIS.bd.1 und der IT-Betrieb für die Systembausteine. Weitere Rollen: Entwickler (MRIS.bd.1, MRIS.bd.2.3, MRIS.bd.2.4) und Fachverantwortliche (MRIS.bd.2.4).
ISO 27001 auf der Basis von IT-Grundschutz
Die IT-Grundschutz-Methodik kennt keine SoA. Bei einer ISO-27001-Zertifizierung auf der Basis von IT-Grundschutz lassen sich die Anforderungen zusätzlich in die Erklärung zur Anwendbarkeit übernehmen.
Reifegrade
Die Umsetzungshinweise beschreiben je Maßnahme die Stufen Initial, Defined und Managed. Erst ab Defined gilt die Anforderung grundsätzlich als umgesetzt; Initial dokumentiert einen begonnenen Umsetzungspfad.
KI-Agenten und KI-Verordnung
MRIS.bd.1.A6 verlangt, je KI-Agent die Rolle der Institution nach der KI-Verordnung und die Einstufung des KI-Systems im Inventar auszuweisen. Daraus folgende Rechtspflichten setzt die Institution über das Compliance Management um (ORP.5); sie sind keine Anforderungen der Bausteinfamilie. Die Sicherheitsmaßnahmen gelten für alle produktiven KI-Agenten, unabhängig von ihrer Einstufung.
Anbieter
Entwickelt ein KI-System und bringt es unter eigenem Namen in Verkehr oder nimmt es in Betrieb, auch zum Eigengebrauch (Art. 3 Nr. 3 i. V. m. Nr. 11).
Betreiber
Verwendet ein KI-System in eigener Verantwortung (Art. 3 Nr. 4).
Rollenwechsel
Bei wesentlichen Änderungen an einem KI-Agenten wird geprüft, ob sich die Rolle der Institution ändert (Art. 25 Abs. 1).
Fristen
Nach dem Stand von September 2026 gelten die Pflichten für Hochrisiko-KI-Systeme nach Anhang III ab dem 2. Dezember 2027 und nach Anhang I ab dem 2. August 2028.
Informative Zuordnung der Anforderungssätze zur KI-Verordnung
Anforderung
Satz
Anwendbar bei
Rolle und Fundstelle
bd.1.A6Satz 3
Das Inventar MUSS je KI-Agent ausweisen, welche Rolle die Institution nach der KI-Verordnung einnimmt (Anbieter, Betreiber oder beides) und wie das zugrunde liegende KI-System eingestuft ist.Aus Rolle und Einstufung folgen Rechtspflichten, die keine Anforderungen dieser Bausteinfamilie sind, etwa die technische Dokumentation eines Hochrisiko-KI-Systems durch den Anbieter (Art. 11 i. V. m. Anhang IV); Umsetzung über ORP.5.
alle KI-Systeme
Anbieter: Art. 3 Nr. 3 i. V. m. Nr. 11 Betreiber: Art. 3 Nr. 4 beide: Art. 6, Art. 50
bd.1.A6Satz 4
Bei wesentlichen Änderungen an einem KI-Agenten SOLLTE geprüft werden, ob sich die Rolle der Institution dadurch ändert.
Hochrisiko-KI-System
Betreiber: Art. 25 Abs. 1
bd.1.A6Satz 6
Für jeden produktiven KI-Agenten MUSS eine verantwortliche Person benannt werden.
Hochrisiko-KI-System
Betreiber: Art. 26 Abs. 2
bd.2.4.A2Satz 1
Aktionen des KI-Agenten mit Schreib- oder Netzwerkrechten MÜSSEN lückenlos und der auslösenden menschlichen Identität zuordenbar protokolliert werden.
Hochrisiko-KI-System
Anbieter: Art. 12 Abs. 1
bd.2.4.A2Satz 2
Die Aufbewahrungsdauer der Protokolle SOLLTE unter Berücksichtigung gesetzlicher, vertraglicher und forensischer Anforderungen festgelegt werden.Aufbewahrung mindestens sechs Monate
Falls Prompts, Werkzeugdefinitionen, Retrieval-Pipelines oder Eskalationslogik des KI-Agenten unter der Kontrolle der Institution stehen, dann SOLLTEN diese Komponenten wie Produktivcode einem Code-Review unterzogen werden.Wer ein KI-System entwickelt und unter eigenem Namen zum Eigengebrauch in Betrieb nimmt, ist Anbieter (Art. 3 Nr. 3 i. V. m. Nr. 11).
Hochrisiko-KI-System
Anbieter: Art. 15 Abs. 5
bd.2.4.A5Satz 2
Falls diese Komponenten vom Hersteller kontrolliert werden, dann SOLLTEN stattdessen Nachweise des Herstellers zu ihrer Absicherung eingefordert werden.
Hochrisiko-KI-System
Betreiber: Art. 26 Abs. 1 i. V. m. Art. 13
bd.2.4.A5Satz 3
Vor der Produktivsetzung SOLLTE der KI-Agent auf Anfälligkeit für Prompt-Injection und Confused-Deputy-Angriffe getestet werden.
Hochrisiko-KI-System
Anbieter: Art. 15 Abs. 5
Informative Zuordnung, keine Anforderung und keine Rechtsberatung. Maßgeblich ist die Verordnung (EU) 2024/1689 (KI-Verordnung) in der Fassung der Verordnung (EU) 2026/1744: 2024/1689 bei EUR-Lex.
MRIS.bd und der BSI-Prüfkatalog A5
Beide Werke befassen sich mit KI, aus entgegengesetzten Blickrichtungen. Sie schließen sich nicht aus, sondern ergänzen sich.
BSI-Prüfkatalog A5
AI Audit and Assurance Assessment Architecture, Community Draft vom 6. Juli 2026
Gegenstand ist das KI-System selbst
Prüft die Vertrauenswürdigkeit von KI-Systemen entlang ihres Lebenszyklus
Knüpft über ein Betriebsmodul an den C5-Katalog an
Bausteinfamilie MRIS.bd
Benutzerdefinierte Bausteine für den IT-Grundschutz
Gegenstand sind das ISMS und seine Zielobjekte
Härtet die Wirksamkeit bestehender Maßnahmen gegen Angreifer, die selbst KI einsetzen
Behandelt KI-Agenten als privilegierte Systeme mit Identität, Protokollierung und menschlicher Kontrolle
Wo der IT-Grundschutz steht und was MRIS.bd ändert
Im MRIS-Marktvergleich steht der BSI IT-Grundschutz bei hoher Umsetzungsnähe (8,4), aber begrenzter Gen-AI-Abdeckung (3,0). MRIS.bd adressiert diese Lücke dort, wo Grundschutz-Praktiker arbeiten: in den Bausteinen. Die Kombination behält die Umsetzungsnähe des IT-Grundschutz und ergänzt die Gen-AI-Abdeckung des MRIS-Layers.
Qualitatives Experten-Scoring auf einer Skala von 0 bis 10, Bewertungsstand August 2026. Der Kombinationspunkt folgt der Kombinationsregel des Marktvergleichs: X entspricht der Gen-AI-Abdeckung des MRIS-Layers (9,4), Y dem Wert des IT-Grundschutz (8,4); ein Aufschlag wäre nur mit einem extern validierten Prüfschema für die MHC begründbar. BSI A5 ist ein Community Draft vom 6. Juli 2026 und noch kein finaler Standard. Vollständige Daten und Lesart auf der ISO-SeiteAlle Positionen als Tabelle
Werk
Typ
Gen-AI-Abdeckung
Umsetzungsnähe
IT-Grundschutz + MRIS.bd
Kombination
9,4
8,4
BSI IT-Grundschutz
Norm / Methodik
3,0
8,4
Mythos-Ready (CSA/SANS/[un]prompted/OWASP)
Programm-Agenda
8,8
4,6
OWASP Top 10 for Agentic Applications
Risiko-Top-10 (Community)
7,8
3,8
MITRE ATT&CK v19.2 / ATLAS
Taxonomie / Wissensbasis
6,8
6,4
BSI C5:2026
Prüfkatalog
5,4
9,0
NIST AI RMF 1.0 + GenAI-Profil (AI 600-1)
Governance-Rahmenwerk
5,0
5,8
ISO/IEC 42001:2023
Managementsystem-Norm
4,6
6,2
BSI A5 (AI Audit and Assurance Assessment Architecture)
Prüfkatalog, Community Draft
3,9
5,7
CISA Zero Trust Maturity Model v2.0
Reifegradmodell
4,0
6,8
NIST CSF 2.0
Rahmenwerk
3,6
7,0
CSA Cloud Controls Matrix v4
Kontrollkatalog
3,5
8,6
CIS Controls v8.1
Praxis-Framework
3,2
7,6
ISO/IEC 27002:2022
Norm
2,2
9,0
Von Version 1.3 zu 2.0
Für alle, die MRIS.bd.1 v1.3 bereits modelliert haben: wo jede Anforderung jetzt steht. Version 1.3 ist zurückgezogen; maßgeblich ist ausschließlich Version 2.0.
Von 107 Anforderungssätzen sind 60 unverändert, 21 neu, 19 angepasst und 7 redaktionell geändert. Die maschinenlesbare Fassung weist die Herkunft jedes Satzes aus.
Zuordnung der Anforderungen von Version 1.3 zu Version 2.0
MRIS.bd ist eine Familie benutzerdefinierter Bausteine im Sinne der IT-Grundschutz-Methodik (BSI-Standard 200-2), die eigene Bausteine für nicht abgedeckte Themen ausdrücklich vorsieht. Die Bausteine enthalten keine offiziellen Anforderungen des BSI, wurden vom BSI weder geprüft noch freigegeben, sind kein Bestandteil des IT-Grundschutz-Kompendiums und ersetzen keine Zertifizierung. MRIS ist ein unabhängiges Projekt und kein Angebot des BSI. Nutzung im Rahmen von IT-Sicherheitskonzepten nach IT-Grundschutz ausdrücklich erwünscht. Keine Rechts- oder Zertifizierungsberatung; Anwendung in eigener Verantwortung.