MRIS für ISO/IEC 27001:2022, Annex A. Fassung 2.0, September 2026
Wirken Ihre ISO-27001-Controls noch, wenn der Angreifer eine KI ist?
MRIS analysiert alle 93 Controls aus ISO/IEC 27001:2022 Annex A (ISO/IEC 27002:2022) gegen KI-beschleunigte Angriffe. Für jede Lücke benennt die Analyse flankierende Mythos-Härtungs-Controls, und der Implementation Guide beschreibt deren Umsetzung.
Wählen Sie ein Feld aus, um Control, Einstufung und Härtungsmaßnahme zu sehen.
Alle 93 Controls
93 Controls: 29 standfest, 37 teilweise degradiert, 4 reine Reibung, 23 nicht betroffen.
Analysematrix
Alle 93 Controls mit Einstufung und flankierenden MHC, gemäß MRIS Anhang A. Suchen Sie nach Nummer, Titel oder MHC, oder filtern Sie nach Einstufung.
93 von 93 Controls
| Control | Titel | Einstufung | Flankierende MHC |
|---|---|---|---|
| A.5 Organisatorische Maßnahmen 37 Controls | |||
| A.5.1 | Informationssicherheitsrichtlinien | nicht betroffen | – |
| A.5.2 | Informationssicherheitsrollen und -verantwortlichkeiten | nicht betroffen | – |
| A.5.3 | Aufgabentrennung | teilweise degradiert | MHC-05 |
| A.5.4 | Verantwortlichkeiten der Leitung | nicht betroffen | – |
| A.5.5 | Kontakt mit Behörden | teilweise degradiert | MHC-11 |
| A.5.6 | Kontakt mit speziellen Interessengruppen | nicht betroffen | – |
| A.5.7 | Threat Intelligence | teilweise degradiert | MHC-05 |
| A.5.8 | Informationssicherheit im Projektmanagement | nicht betroffen | – |
| A.5.9 | Inventar von Informationen und zugehörigen Werten | standfest | MHC-13 |
| A.5.10 | Akzeptable Nutzung von Informationen | nicht betroffen | – |
| A.5.11 | Rückgabe von Werten | nicht betroffen | – |
| A.5.12 | Klassifizierung von Informationen | standfest | – |
| A.5.13 | Kennzeichnung von Informationen | nicht betroffen | – |
| A.5.14 | Informationsübertragung | teilweise degradiert | MHC-05 |
| A.5.15 | Zugriffskontrolle | teilweise degradiert | MHC-04, MHC-05 |
| A.5.16 | Identitätsmanagement | standfest | MHC-04, MHC-13 |
| A.5.17 | Authentisierungsinformation | teilweise degradiert | MHC-03 |
| A.5.18 | Zugangsrechte | teilweise degradiert | MHC-10 |
| A.5.19 | Informationssicherheit in Lieferantenbeziehungen | teilweise degradiert | MHC-02 |
| A.5.20 | Adressierung in Lieferantenvereinbarungen | teilweise degradiert | MHC-02 |
| A.5.21 | Management der ICT-Lieferkette | teilweise degradiert | MHC-02 |
| A.5.22 | Überwachung Lieferantendienstleistungen | teilweise degradiert | MHC-02 |
| A.5.23 | Cloud-Dienste | teilweise degradiert | MHC-06, MHC-07 |
| A.5.24 | Planung IR-Management | teilweise degradiert | MHC-11 |
| A.5.25 | Beurteilung und Entscheidung zu Ereignissen | reine Reibung | MHC-11 |
| A.5.26 | Reaktion auf Vorfälle | teilweise degradiert | MHC-11 |
| A.5.27 | Lernen aus Vorfällen | standfest | – |
| A.5.28 | Sammlung von Beweismaterial | standfest | – |
| A.5.29 | Informationssicherheit während einer Störung | teilweise degradiert | MHC-08 |
| A.5.30 | ICT-Bereitschaft für BCM | standfest | MHC-08 |
| A.5.31 | Identifikation rechtlicher Anforderungen | nicht betroffen | – |
| A.5.32 | Rechte an geistigem Eigentum | nicht betroffen | – |
| A.5.33 | Schutz von Aufzeichnungen | teilweise degradiert | MHC-08 |
| A.5.34 | Datenschutz und PII | teilweise degradiert | – |
| A.5.35 | Unabhängige Überprüfung | teilweise degradiert | MHC-10, MHC-12 |
| A.5.36 | Einhaltung von Richtlinien | reine Reibung | MHC-10 |
| A.5.37 | Dokumentierte Betriebsprozesse | nicht betroffen | – |
| A.6 Personenbezogene Maßnahmen 8 Controls | |||
| A.6.1 | Überprüfung (Screening) | nicht betroffen | – |
| A.6.2 | Beschäftigungsbedingungen | nicht betroffen | – |
| A.6.3 | Bewusstsein, Aus- und Weiterbildung | teilweise degradiert | – |
| A.6.4 | Disziplinarverfahren | nicht betroffen | – |
| A.6.5 | Verantwortlichkeiten nach Beendigung | standfest | – |
| A.6.6 | Vertraulichkeitsvereinbarungen | nicht betroffen | – |
| A.6.7 | Remote-Arbeit | teilweise degradiert | MHC-03, MHC-04 |
| A.6.8 | Meldung von Sicherheitsereignissen | teilweise degradiert | – |
| A.7 Physische Maßnahmen 14 Controls | |||
| A.7.1 | Physische Sicherheitsperimeter | standfest | – |
| A.7.2 | Physische Zutrittskontrolle | standfest | – |
| A.7.3 | Sicherung Büros und Einrichtungen | standfest | – |
| A.7.4 | Physische Sicherheitsüberwachung | standfest | – |
| A.7.5 | Schutz vor physischen und Umwelt-Bedrohungen | nicht betroffen | – |
| A.7.6 | Arbeiten in Sicherheitsbereichen | standfest | – |
| A.7.7 | Clear Desk und Screen Lock | nicht betroffen | – |
| A.7.8 | Aufstellung und Schutz von Geräten | nicht betroffen | – |
| A.7.9 | Sicherheit von Werten außerhalb der Räumlichkeiten | teilweise degradiert | – |
| A.7.10 | Speichermedien | standfest | – |
| A.7.11 | Versorgungseinrichtungen | nicht betroffen | – |
| A.7.12 | Verkabelungssicherheit | nicht betroffen | – |
| A.7.13 | Wartung von Geräten | nicht betroffen | – |
| A.7.14 | Sichere Entsorgung oder Wiederverwendung | standfest | – |
| A.8 Technologische Maßnahmen 34 Controls | |||
| A.8.1 | Benutzer-Endpunktgeräte | teilweise degradiert | MHC-03, MHC-05 |
| A.8.2 | Privilegierte Zugriffsrechte | standfest | MHC-04 |
| A.8.3 | Einschränkung des Informationszugangs | teilweise degradiert | MHC-05 |
| A.8.4 | Zugang zu Quellcode | teilweise degradiert | MHC-02, MHC-05 |
| A.8.5 | Sichere Authentisierung | teilweise degradiert | MHC-03 |
| A.8.6 | Kapazitätsmanagement | nicht betroffen | – |
| A.8.7 | Schutz vor Malware | teilweise degradiert | MHC-05 |
| A.8.8 | Verwaltung technischer Schwachstellen | reine Reibung | MHC-09 |
| A.8.9 | Konfigurationsmanagement | standfest | MHC-10 |
| A.8.10 | Informationslöschung | standfest | – |
| A.8.11 | Datenmaskierung | standfest | – |
| A.8.12 | Verhinderung von Datenabfluss | teilweise degradiert | MHC-05 |
| A.8.13 | Informationssicherung (Backup) | standfest | MHC-08 |
| A.8.14 | Redundanz | standfest | MHC-08 |
| A.8.15 | Protokollierung (Logging) | standfest | MHC-05 |
| A.8.16 | Überwachungsaktivitäten | teilweise degradiert | MHC-05 |
| A.8.17 | Uhrenzeit-Synchronisation | standfest | – |
| A.8.18 | Privilegierte Hilfsprogramme | standfest | – |
| A.8.19 | Software-Installation | standfest | – |
| A.8.20 | Netzwerksicherheit | teilweise degradiert | MHC-04 |
| A.8.21 | Sicherheit von Netzwerkdiensten | teilweise degradiert | MHC-04 |
| A.8.22 | Trennung in Netzwerken | teilweise degradiert | MHC-04, MHC-07 |
| A.8.23 | Webfilterung | reine Reibung | MHC-03 |
| A.8.24 | Verwendung von Kryptographie | standfest | MHC-01 |
| A.8.25 | Sicherer Entwicklungslebenszyklus | teilweise degradiert | MHC-09 |
| A.8.26 | Sicherheitsanforderungen für Anwendungen | teilweise degradiert | MHC-09 |
| A.8.27 | Prinzipien der sicheren Systemarchitektur | standfest | MHC-13 |
| A.8.28 | Sicheres Programmieren | teilweise degradiert | MHC-09 |
| A.8.29 | Sicherheitsprüfung in Entwicklung und Abnahme | standfest | MHC-09, MHC-12 |
| A.8.30 | Ausgelagerte Entwicklung | teilweise degradiert | MHC-02 |
| A.8.31 | Trennung von Umgebungen | standfest | MHC-06 |
| A.8.32 | Änderungsmanagement | teilweise degradiert | MHC-09 |
| A.8.33 | Testinformationen | standfest | – |
| A.8.34 | Schutz während Audittests | nicht betroffen | – |
Kein Control passt zu dieser Suche. Prüfen Sie die Schreibweise oder setzen Sie den Filter zurück.
Was sich an der Bedrohungslage verändert hat
Die Methodik der ISO/IEC 27001 bleibt intakt. Destabilisiert sind ihre Eingaben: Annahmen über Zeit, Aufwand und Fähigkeiten der Angreifer.
- Kollaps des Patch-Fensters
- Die Zeit zwischen bekannter Schwachstelle und Ausnutzung schrumpft gegen null.
- Kompression der Zeitachse
- Vom ersten Zugriff bis zum Schaden vergehen Minuten, nicht Tage.
- Fragmentierung
- Angriffe laufen parallel und verteilt, um die Reaktion zu überlasten.
- Entkopplung von Fähigkeit und Akteur
- Angriffsfähigkeit hängt nicht mehr an der Ressourcenstärke des Akteurs.
Sieben systematische Lücken der ISO/IEC 27002:2022
Die Lückenanalyse (Kapitel 8) verdichtet diese Verschiebungen zu Anforderungen, die andere Rahmenwerke bereits verbindlich kennen und die unter Mythos-Bedingungen harte Schutzwirkung entfalten:
- Post-Quantum-Strategie und Crypto-Agility
- Supply-Chain-Transparenz mit SBOM-Pflicht
- Container, Confidential Computing und Multi-Tenancy
- Zeitbasierte Meldefristen und Root-Cause-Pflicht
- Kontinuierliche Prüfung statt periodischer Audits
- Phishing-resistente MFA und Workload-Identität
- Automatisierungspflicht und Parallel-Incident-Testing
Alle sieben Lücken im Detail: Forderungen der Rahmenwerke und zugeordnete MHC
Einstufung und Risikobewertung
Jedes Control erhält eine von vier Einstufungen. Das Ergebnis fließt direkt in die Risikobewertung nach ISO/IEC 27005 ein.
- Standfest
- 29
- 31 %
- Wirkt strukturell weiter – kryptografische oder architektonische Härte.
- Teilweise degradiert
- 37
- 40 %
- Wirkt eingeschränkt – braucht eine flankierende Härtung.
- Reine Reibung
- 4
- 4 %
- Kernwirkung entfällt – muss ersetzt oder umgestaltet werden.
- Nicht betroffen
- 23
- 25 %
- Von der KI-Bedrohung neutral – bleibt unverändert wichtig.
Brücke zu ISO/IEC 27005. Ein teilweise degradiertes Control hebt die Eintrittswahrscheinlichkeit um eine Stufe, ein Control mit reiner Reibung um zwei Stufen.
Hebelwirkung: wenige Maßnahmen tragen viele Lücken
Wie viele der 41 degradierten Controls (teilweise degradiert und reine Reibung) jedes MHC flankiert. MHC-01 und MHC-13 flankieren nur standfeste Controls, können je nach Datenlage und Einsatz von AI-Agenten aber trotzdem Priorität P0 haben.
| MHC | Degradierte Controls | Auch standfest flankiert | Charakter |
|---|---|---|---|
| MHC-05 Verhaltensbasierte Detection | 10 | A.8.15 | breit querschnittlich |
| MHC-02 SBOM und Build-Provenance | 6 | – | Lieferkette |
| MHC-03 Phishing-resistente MFA | 5 | – | Identität und Authentisierung |
| MHC-04 Workload-Identität und Zero Trust | 5 | A.5.16, A.8.2 | Identität und Zugriff |
| MHC-09 AI-gestütztes Security-Testing | 5 | A.8.29 | sichere Entwicklung |
| MHC-11 SOAR und Tier-1-Automation | 4 | – | Incident Response |
| MHC-10 Continuous Control Monitoring | 3 | A.8.9 | Prüfung |
| MHC-07 Multi-Tenancy-Isolation | 2 | – | Cloud |
| MHC-08 Unveränderliche Backups | 2 | A.5.30, A.8.13, A.8.14 | Resilienz |
| MHC-06 Container und Confidential Computing | 1 | A.8.31 | eng |
| MHC-12 Threat-Led Penetration Testing | 1 | A.8.29 | eng, validierend |
| MHC-01 Post-Quantum-Strategie und kryptografisches Inventar | 0 | A.8.24 | flankiert nur standfeste Controls |
| MHC-13 AI-Agent-Governance | 0 | A.5.9, A.5.16, A.8.27 | flankiert nur standfeste Controls |
Implementation Guide: von der Lücke zur Umsetzung
Der Implementation Guide beschreibt jedes der 13 MHC in derselben Gliederung, damit Leitung, IT und Audit an derselben Stelle nachschlagen:
- Control-Statement
- Zweck und Bedrohungsbezug
- Organisatorische Umsetzung aus Leitungsperspektive
- Technische Umsetzung für IT-Fachleute
- Umsetzungsbeispiele
- Reifegrad-Pfad (Initial, Defined, Managed)
- Messung und Audit-Nachweis
- Typische Fehler
- Abgrenzung, Restrisiko und Verweise
Priorisierung nach Threat Priority Score
Die MHC sind keine lineare Reihenfolge. Der Guide korreliert sie mit Bedrohungsszenarien und bildet je Szenario einen Score: Threat-Relevanz × Business Impact × Exposure × Control Gap, jeweils auf einer Skala von 1 bis 5. Daraus ergibt sich ein Standard-Tiering als anpassbares Template:
P0 sofort
- MHC-03 Phishing-resistente MFAHohe Eintrittswahrscheinlichkeit, schnelle Risikoreduktion bei Admins und externen Zugängen.
- MHC-08 Unveränderliche BackupsBasisfähigkeit gegen Ransomware und destruktive Angriffe.
- MHC-05 Verhaltensbasierte DetectionOhne Detection keine belastbare Reaktion und keine sinnvolle SOAR-Automation.
- MHC-04 Workload-Identität und Zero TrustReduziert Lateral Movement und ist Enabler für AI-Agenten.
P1 danach
- MHC-02 SBOM und Build-ProvenanceGrundlage für Supply-Chain-Transparenz und Pipeline-Testing.
- MHC-09 AI-gestütztes Security-TestingWirksam bei vorhandener Pipeline und SBOM-Basis.
- MHC-11 SOAR und Tier-1-AutomationErst automatisieren, wenn Detection stabil ist.
- MHC-10 Continuous Control MonitoringQuerschnitts-Control für laufende Abweichungserkennung.
P2 risikobasiert
- MHC-06 Container und Confidential ComputingHoch relevant bei Container- und Cloud-Plattformen.
- MHC-07 Multi-Tenancy-IsolationNur bei Multi-Tenant-Plattformen oder SaaS-Betrieb direkt anwendbar.
- MHC-13 AI-Agent-GovernanceHoch relevant bei AI-Agenten, Tool-Calling oder Automatisierung; dann nach P0 hochstufen.
- MHC-01 Post-Quantum-Strategie und kryptografisches InventarHöher priorisieren bei langlebig vertraulichen Daten.
- MHC-12 Threat-Led Penetration TestingValidierung nach Basisumsetzung, danach regelmäßig.
Das Tiering ist ein Beispiel für typische Enterprise-Umgebungen und mit Bedrohungslage, Asset-Kritikalität und Anwendbarkeit abzugleichen. Der Score ist ordinal: Er dient der Reihung, nicht der Messung.
Marktvergleich
Fünfzehn Positionen, eine Frage: Welchen Beitrag leistet ein Werk für ein ISMS unter der aktuellen Gen-AI-Bedrohungslage? Gemessen werden die Mythos- und Gen-AI-Abdeckung und die Umsetzungsnähe und Auditierbarkeit.
ISO/IEC 27002 allein ist maximal zertifizierungsfähig, aber als Werk von 2022 ohne Antwort auf die Gen-AI-Bedrohungslage. Das ist keine Wertung der Norm, sondern ihrer Abdeckung dieser Bedrohungslage.
MRIS allein erreicht die höchste Gen-AI-Abdeckung des Vergleichsfelds, ist aber bewusst kein eigenständiges ISMS: ein Wirksamkeits-Layer, kein Ersatz, und ohne Normfundament nicht zertifizierungsfähig.
Die Kombination aus ISO/IEC 27002 und MRIS ist die entscheidungsrelevante Einheit für die Praxis: höchste Gen-AI-Abdeckung (9,4) und höchste Ausführungsstärke (9,0) des Feldes. Zertifiziert wird weiterhin das ISMS nach ISO/IEC 27001, mit einer um die 13 MHC erweiterten Anwendbarkeitserklärung.
Alle 15 Positionen als Tabelle
| Werk | Typ | Gen-AI-Abdeckung | Umsetzungsnähe |
|---|---|---|---|
| ISO/IEC 27002 + MRIS for ISO 27001 | Kombination | 9,4 | 9,0 |
| MRIS for ISO 27001 (v2.0) | Wirksamkeits-Layer | 9,4 | 6,5 |
| 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 |
| BSI IT-Grundschutz | Norm / Methodik | 3,0 | 8,4 |
| ISO/IEC 27002:2022 | Norm | 2,2 | 9,0 |
Was MRIS leistet und was bewusst nicht
MRIS leistet
- Wirksamkeitsanalyse aller 93 Controls der ISO/IEC 27002 gegen die KI-Bedrohung
- Lückenanalyse zu C5:2026, NIST, DORA, CRA und NIS2
- Einen auditfähigen Katalog von 13 Mythos-Härtungs-Controls mit Reifegraden
- Eine Brücke in den Risikoprozess nach ISO/IEC 27005
MRIS leistet bewusst nicht
- Kein vollständiges ISMS; ein etabliertes ISMS wird vorausgesetzt
- Keinen eigenen Risikomanagement-Prozess
- Kein Compliance-Mapping- oder Zertifizierungswerkzeug
- Keine organisationsspezifische Policy-Hierarchie
Analysiert gegen ISO/IEC 27001:2022, ISO/IEC 27002:2022, BSI C5:2026, NIST, DORA, CRA, NIS2-Richtlinie und NIS2-Durchführungsverordnung.
Downloads
Neu in Fassung 2.0 (September 2026): Qualitäts-Release nach externer Prüfung (Fachreview, Leitungsperspektive, Audit-Logik), verbindliche Lesart der Reifegrade (Initial belegt keine Umsetzung) und Control-Statements aller 13 MHC auf die Stufe Defined synchronisiert.
| Publikation | Fassung | Stand | Lizenz | Dateien |
|---|---|---|---|---|
| Analyse MRIS | 2.0 | September 2026 | CC BY-SA 4.0 | DEEN |
| Implementation Guide | 2.0 | September 2026 | CC BY-SA 4.0 | DEEN |
| Maschinenlesbare Fassung | 2.0 | September 2026 | CC BY-SA 4.0 | YAML |
MRIS und der Implementation Guide sind Arbeitshilfen zur Wirksamkeitsanalyse bestehender Sicherheitsmaßnahmen. Sie setzen ein etabliertes ISMS voraus und ersetzen es nicht. Sie stellen keine Rechts-, Compliance- oder Zertifizierungsberatung dar, erheben keinen Anspruch auf Vollständigkeit und begründen keine Gewährleistung. Die Anwendung erfolgt in eigener Verantwortung.