ISO/IEC 27090: Sicherheitsbedrohungen für KI-Systeme erkennen, bewerten und beherrschen

Vom Projektstart 2022 bis zur Veröffentlichung 2026

Das Projekt wurde am 15.09.2022 genehmigt, die Konsultation zum Committee Draft begann im Januar 2024, die DIS-Abstimmung am 16.04.2025. Der Final Draft wurde vom 23.06. bis 19.08.2026 abgestimmt und wechselte noch am Abstimmungstag in den Status „under publication“; am 14.10.2026 folgte die Veröffentlichung mit Stage-Code 60.60. Das Abstimmungsergebnis ist nicht öffentlich, der Übergang ohne Rückverweis belegt aber die Annahme. Unterwegs änderte sich der Titel: Aus „Guidance for addressing security threats and failures“ wurde „Addressing security threats and compromises to AI systems“, aus Fehlern wurden Kompromittierungen, der Umfang wuchs von 46 auf 56 Seiten mit 115 Bibliografie-Einträgen.

Herausgeber und Gremien

Erarbeitet hat die Norm ISO/IEC JTC 1/SC 27 „Information security, cybersecurity and privacy protection“ mit Sekretariat beim DIN (Chair Dr. Andreas Wolf); zuständig war die Arbeitsgruppe WG 4 „Security controls and services“ unter Convenor Faud Khan vom kanadischen SCC, die Projekt-Editoren nennt keine öffentliche Quelle. Das SC 27 Journal vom September 2026 beschreibt 27090 als erste Norm des Unterausschusses speziell zur Sicherheit von KI-Systemen. In Deutschland spiegelt der Arbeitskreis NA 043-04-27-04 „IT-Sicherheitsmaßnahmen und Dienste“ die WG 4; seine Projektliste enthält mit Stand 22.10.2026 weder ein Übernahmeprojekt noch eine Stellungnahme zu 27090.

Bezug, Sprache, nationale Fassungen

Die Norm erscheint ausschließlich auf Englisch. ISO verlangt CHF 204, DIN Media vertreibt das ISO-Original als ISO/IEC 27090:2026-10 für 218,32 Euro netto, im IEC-Webstore läuft sie als Publikation 117332. Eine deutsche Fassung existiert nicht: DIN Media und SNV vertreiben nur das englische ISO-Original, eine ÖNORM-Übernahme ist nicht bekannt, und die britische Übernahme BS ISO/IEC 27090:2026 ist für den 31. Oktober 2026 angekündigt. Kostenfrei einsehbar sind Vorschauen mit Inhaltsverzeichnis, Introduction, Clause 1 bis 4, 5.1 bis 5.3 und Bibliografie; Clause 5.4 bis 7, Table 1 und die Annexe gibt es nur in der Vollversion, Aussagen dieser Seite dazu stützen sich auf Inhaltsverzeichnis und FDIS-Auswertungen und sind so gekennzeichnet.

Leitfaden, nicht Managementsystemnorm

ISO/IEC 27090 ist ein International Standard mit Leitfadencharakter. ISOs eigener Explainer spricht von Sicherheitsleitlinien, nicht von Anforderungen an ein KI-Managementsystem; dafür verweist Abschnitt 5.2 auf ISO/IEC 42001. Es gibt kein Zertifikat „ISO 27090“, kein Audit „nach 27090“ und keine Konformitätsvermutung nach KI-Verordnung oder Cyber Resilience Act. Eine reine Empfehlungssammlung ist die Norm dennoch nicht: Abschnitt 5.1 enthält zwei belegte shall-Sätze, wonach Informationssicherheits-Controls etwa aus ISO/IEC 27002 risikobasiert umzusetzen und KI-spezifische Kompromittierungen über den gesamten Lebenszyklus zu berücksichtigen sind. Für die Praxis gilt: keine zertifizierbaren Anforderungen, aber eine klare Erwartung, die Bedrohungen aus Clause 6 im eigenen Risikomanagement zu behandeln.

Scope: entwickeln oder nutzen

Clause 1 beschreibt den Gegenstand so: sicherheitsrelevante Bedrohungen und Kompromittierungen, die spezifisch für KI-Systeme sind, deren Folgen sowie Erkennung und Minderung über den gesamten Lebenszyklus — anwendbar auf Unternehmen, Behörden und Non-Profit-Organisationen, die KI-Systeme entwickeln oder nutzen. Die Introduction spricht von entwickeln oder bereitstellen, Abschnitt 5.1 von Akteuren entlang der Lieferkette. Die Rollen Anbieter und Betreiber aus der KI-Verordnung und die Stakeholder-Rollen aus ISO/IEC 22989 definiert Clause 3 nicht; jede Zuordnung von Maßnahmen zu Rollen ist deshalb Interpretation. Der Scope ist nicht auf generative KI beschränkt.

Normative und informative Bezüge

Normativ zitiert die Norm genau zwei Dokumente: ISO/IEC 22989 undatiert, also einschließlich künftiger Änderungen wie des laufenden Amendments zu generativer KI, und ISO/IEC 23053:2022. ISO/IEC 27001, 27002, 42001, 23894, 5338 und 38507 stehen nur in der Bibliografie, werden in 5.1 und 5.2 aber ausdrücklich als Arbeitsgrundlage genannt. Die Schutzziele übernimmt Clause 3 aus der neuen ISO/IEC 27000:2026, Bedrohung, Angriff und Schwachstelle aus ISO/IEC 27002:2022.

Was nicht Gegenstand ist

• Anforderungen an ein KI-Managementsystem: Abschnitt 5.2 verweist auf ISO/IEC 42001.
• Datenschutzrisiken von KI-Systemen: Gegenstand der Schwesternorm ISO/IEC 27091.
• KI als Verteidigungswerkzeug sowie Bedrohungen, die KI nur einsetzen, etwa Deepfakes oder KI-gestütztes Phishing.
• Angriffe von KI auf KI sowie funktionale Sicherheit (Safety), für die ISO/IEC TR 5469 einschlägig ist.
• Eine Konformitätsvermutung nach KI-Verordnung oder Cyber Resilience Act: 27090 ist keine harmonisierte Norm, ein offizielles Mapping auf prEN 18282 oder ETSI TS 104 223 existiert nicht.

27090 und 27091: Sicherheit und Datenschutz als Paar

ISO/IEC 27091 „Cybersecurity and Privacy — Artificial Intelligence — Privacy protection“ ist noch nicht veröffentlicht; die FDIS-Abstimmung hatte am 22.10.2026 nicht begonnen. Nach DIS-basierten Zusammenfassungen behandelt sie Datenschutzanalyse, Privatsphäre von KI-Modellen und Privacy Engineering im Lebenszyklus. Die Überschneidung ist sichtbar: Membership Inference und Model Inversion stehen in beiden Normen, in 27090 als Sicherheitsbedrohung gegen die Vertraulichkeit der Trainingsdaten, in 27091 als Datenschutzrisiko. Ein Erscheinen Anfang 2027 ist plausibel, aber kein ISO-Zieldatum.

Clause 5: 5.1 als Rahmen, sechs Praktiken

Abschnitt 5.1 setzt den Rahmen: KI-Systeme sind integrierte Softwarekomponenten, für die die Controls der ISO/IEC 27002 risikobasiert gelten, und KI-spezifische Kompromittierungen einschließlich der in Table 1 aufgeführten sind über den Lebenszyklus nach ISO/IEC 22989 und 5338 zu berücksichtigen. Als effizienten Startpunkt nennt die Norm die Härtung des Software-Stacks gegen direkten Modelldiebstahl, als Beispiele ETSI EN 304 223 und das NIST Secure Software Development Framework. Abschnitt 5.2 beschreibt ein Governance-Programm mit Inventar, Risikoanalyse und Risikobehandlung, 5.5 gliedert das Lieferkettenmanagement in fünf Unterabschnitte von allgemeinen über KI-spezifische Bedrohungen bis zu Gegenstrategien. Abschnitt 5.3 übernimmt die sechs Zero-Trust-Prinzipien aus ISO/IEC 27002 8.27, illustriert sie mit fünf Beispielen bis hin zur Verifikation von Agentenaktionen und kündigt an, dass sie in alle Minderungsabschnitte von Clause 6 einfließen.

Clause 6: neun Typen in einheitlichem Raster

Table 1 wird in 5.1 referenziert, steht dort aber nicht; nach unserer Lesart ist sie in 6.1 verortet und listet laut FDIS-Auswertung zwölf Angriffstypen, neun aus Clause 6 und drei aus Annex B.

Clause 7 und die Annexe

Clause 7 ist mit vier Seiten kurz, nach unserer Einschätzung aber die für Maßnahmenentscheidungen wichtigste Stelle der Norm. Abschnitt 7.2 behandelt widersprüchliche Wechselwirkungen, die FDIS-Auswertung nennt als Beispiel ein Adversarial Training, das die Anfälligkeit für Patch-Angriffe erhöhte, und empfiehlt, alle Maßnahmen gemeinsam vor dem Deployment zu testen. Abschnitt 7.3 behandelt die Kontinuität der Maßnahmen über den Lebenszyklus, 7.4 beschreibt den Verfall von Modell und Maßnahmen mit Monitoring, Nachtraining bei Bedarf und Revalidierung vor der Rückführung in den Betrieb; 7.7 trennt Out-of-Distribution-Eingaben, die nicht notwendig Angriffe sind, von adversarialen Eingaben. Annex A ordnet Angriffe Lebenszyklus und Assets zu, Annex B beschreibt KI-Varianten konventioneller Angriffe, Annex C föderiertes Lernen.

Begriffe, Abkürzungen, Bibliografie

Clause 3 definiert 30 Begriffe, darunter die Dreiteilung des Angreiferwissens in Zero-, Partial- und Perfect-Knowledge-Angriffe anstelle der Black-, Grey- und White-Box-Metapher. Die Angriffstypen stehen in 3.13 bis 3.24, Prompt Injection so weit gefasst, dass Inhalte, die als oder in einer Eingabeinstruktion wirken, auch die indirekte Variante abdecken. Nicht definiert sind KI-Agent, Kompromittierung und prädiktive KI. Clause 4 listet 15 Abkürzungen von AI über DP, JIT, OOD und RAG bis RT; MCP fehlt, was nach den ISO/IEC-Direktiven ein starkes Indiz ist, dass das Model Context Protocol im Normtext nicht vorkommt. Nicht zitiert sind NIST AI RMF, NIST AI 100-2, die OWASP Top 10 für LLM-Anwendungen, die OWASP Agentic Top 10 und das Model Context Protocol — genau die Dokumente, mit denen diese Seite die Norm ergänzt.

Grundthese der Introduction

Die Introduction formuliert vier Gedanken, die den Rest der Norm tragen. Erstens bleibt die Praxis nach ISO/IEC 27001 und 27002 empfohlen, weil KI-Systeme Software sind und alle bekannten Schwachstellen teilen. Zweitens können Betriebsdaten bei kontinuierlichem Lernen zu Trainingsdaten werden, womit der Betrieb zum Poisoning-Vektor wird. Drittens gelingt die Exfiltration eines Modells über legitime Abfragen, obwohl alle Standard-Controls intakt sind; Rate Limiting hilft. Viertens ist die Erkennung schwierig, aber unverzichtbar, weshalb die Norm Defence-in-Depth als Leitprinzip setzt und jedem Angriffstyp einen eigenen Erkennungsabschnitt gibt.

Assets und Angreiferziele

Nach der FDIS-basierten Auswertung von Table 1 sortiert die Norm ihre zwölf Angriffstypen nach dem zuerst betroffenen Asset: Modell, Trainingsdaten, Testdaten, Output und Dienst. Dazu kommt aus 5.1 der Software-Stack, in den das KI-System integriert ist, und aus 5.5 die Lieferkette, die laut FDIS-Auswertung vortrainierte Modelle, gekaufte Datensätze, Notebook-Plattformen und MLOps-Werkzeuge umfasst. Ein KI-Inventar nach 5.2 sollte deshalb je System Modellartefakt, Daten, Retrieval-Quellen, System-Prompts, Schnittstellen, Werkzeugrechte und Pipeline erfassen. Hinter den neun Typen stehen nach unserer Lesart sechs Angreiferziele.

Angreiferwissen und Phasenlagen

Clause 3 unterscheidet in 3.10 bis 3.12 Angriffe ohne, mit teilweiser und mit vollständiger Kenntnis des Modells, jeweils ohne Zugangsdaten. Das legt den Fokus der Erstausgabe offen: Der typische Angreifer ist ein gezielt handelnder Außenstehender. Gary Hinson hat kritisiert, dass zufällige Bedrohungen, Innentäter und Folgen jenseits der eigenen Organisation unterrepräsentiert sind; immerhin kennzeichnet Table 1 nach der FDIS-Auswertung jeden Typ als Angreifer- oder Unfallszenario. Innentäter mit legitimen Rechten und Fehlkonfigurationen müssen Sie im Risikoregister selbst ergänzen. Zeitlich ordnet 5.1 Angriffe danach, ob sie während Entwicklung und Training, während Inferenz und Betrieb oder in beiden Lagen ansetzen.

Die Norm nennt in 5.1 den Lebenszyklus nach ISO/IEC 22989 und 5338 von der Idee bis zur Stilllegung und ordnet in Annex A Angriffe Lebenszyklus und Assets zu; die Spalten dieses Annexes sind über die Vorschauen nicht sichtbar. Die sechs Phasen dieser Seite plus die Querschnitte Lieferkette und Governance sind ein Arbeitsmodell von VamiSec, das sich an diesen beiden Normen orientiert, aber keine Stufenbezeichnung der 27090 wiedergibt.

1. 1
   Phase 01 · Entwicklung/TrainingDaten und Beschaffung

   Data Poisoning (6.2) und die Annex-B-Typen Direct Training Data Leak und Model Input Leak; beschaffte Datensätze sind nach 5.5 Teil der Lieferkette. Anker: Provenienz (6.11.4), Datenlimitierung (6.11.2).

2. 2
   Phase 02 · Entwicklung/TrainingEntwicklung und Training

   Direct Model Poisoning (6.7) und Backdoors (3.24) zielen auf Modellartefakt und Pipeline. Anker: Entwicklungsumgebung (7.6), Software-Engineering (5.4), Zero Trust für Trainingsdaten (5.3).

3. 3
   Phase 03 · ÜbergangVerifikation und Validierung

   Hier wird die Anfälligkeit für Evasion, Membership Inference und Model Inversion messbar, bevor Angreifer sie ausnutzen. Anker: Red Teaming (5.7), Threat Modelling (5.6), gemeinsames Testen aller Maßnahmen (7.2).

4. 4
   Phase 04 · Inferenz/BetriebBereitstellung und Integration

   Mit der Anbindung an Anwendungen, Retrieval-Quellen und Werkzeuge entstehen die Angriffsflächen für Prompt Injection (6.9) und Output mit Injection-Angriffen (6.10). Anker: Anwendungsgrenzen und Modellzugriff einschließlich RAG (5.3), Eingabefilterung (7.7), Drosselung (7.8).

5. 5
   Phase 05 · Inferenz/BetriebBetrieb und Überwachung

   Evasion (6.3), Membership Inference (6.4), Model Exfiltration (6.5), Model Inversion (6.6) und Sensitive Model Output (6.8) laufen über legitime Abfragen. Anker: Logging und Monitoring (7.5), Erkennungsabschnitte 6.x.3, unerwünschtes Modellverhalten im Betrieb (6.11.3).

6. 6
   Phase 06 · Beide LagenNeubewertung und Stilllegung

   Modell und Maßnahmen verfallen über die Zeit (7.4): Monitoring, Nachtraining bei Bedarf, Revalidierung vor der Rückführung. Nachtraining mit Betriebsdaten öffnet erneut den Poisoning-Vektor aus 6.2. Zur Stilllegung schweigt die frei zugängliche Fassung; ETSI EN 304 223 führt dafür ein eigenes Prinzip.

Kontinuierliches Lernen: der Betrieb wird zur Trainingsphase

Introduction und ISO-Katalogseite betonen denselben Punkt: Nachtraining und Updates brauchen Sicherheitsaufmerksamkeit, weil Betriebseingaben zu Trainingsdaten werden können. Abschnitt 6.7 sieht direktes Model Poisoning in Entwicklung oder Betrieb vor, 7.3 behandelt die Kontinuität der Maßnahmen, 7.4 beschreibt den Verfall von Modell und Maßnahmen, und 5.3 spannt Zero Trust vom Management der Trainingsdaten bis zum Agentenbetrieb. Für CISOs heißt das: Jede Rückkopplung von Nutzerdaten in ein Modell, auch über Feedback-Funktionen, Memory-Speicher oder RAG-Indizes, ist ein Übergang in die Trainingsphase und braucht dieselben Freigaben wie die ursprüngliche Datenbeschaffung.

6.2 Data Poisoning: Integrität der Trainingsdaten

Data Poisoning manipuliert die Daten, aus denen ein Modell lernt, und setzt in Entwicklung und Training an, bei kontinuierlichem Lernen auch im Betrieb. Gezielte Varianten verfälschen die Integrität von Trainingsdaten und Output, ungezielte treffen die Verfügbarkeit; Backdoor-Angriffe führt die Norm als generischen Begriff, nicht als eigenen Kompromittierungstyp. Die FDIS-Auswertung beschreibt den Erkennungsabschnitt als Eingeständnis: Automatisierte Verfahren trennen vergiftete Daten nicht zuverlässig von Ausreißern. Die Minderung verlagert sich deshalb nach vorn, auf Provenienz, Integritätsprüfungen entlang der Pipeline und die Begrenzung der Daten, die überhaupt in ein Modell gelangen (6.11.4, 6.11.2). Die Vergiftung einer Retrieval-Basis behandelt die Norm nicht als eigenen Typ; OWASP führt dafür LLM05, LLM09 und ASI06, MITRE ATLAS die Technik AML.T0080, die BaFin-Orientierungshilfe nennt die Wissensvergiftung einer RAG-Basis ausdrücklich. VamiSec-Empfehlung: RAG-Indizes, Memory-Speicher und Feedback-Daten wie Trainingsdaten freigeben.

6.7 Direct Model Poisoning: Manipulation am Modell selbst

Direktes Model Poisoning nach 3.18 setzt nicht an den Daten, sondern direkt am Modell an, in der Entwicklung oder im Betrieb; betroffen ist die Integrität des Modells. Die Maßnahmenfamilie umfasst nach unserer Lesart den Schutz der Entwicklungsumgebung nach 7.6, Signaturen und Prüfsummen für Modellartefakte und die Ausführung in einer Trusted Execution Environment, die Clause 3 aus ISO/IEC 27071 übernimmt. Zwei Fälle zeigen den Mechanismus: PoisonGPT vom Juli 2023, ein per Modellbearbeitung manipuliertes GPT-J-6B unter dem Typosquat „EleuterAI“ auf Hugging Face, und nullifAI vom Februar 2025, zwei Modelle mit beschädigten Pickle-Dateien und Reverse Shell. Beide sind überwiegend Proof of Concept. Die Grenze zur Lieferkette ist fließend, weshalb Kapitel 13 dieser Seite den Modellbezug gesondert behandelt.

6.8 und Annex B: Daten, die das Modell preisgibt

Sensitive Model Output nach 6.8 bedeutet, dass ein Modell vertrauliche Trainingsdaten oder nach 3.22 auch frühere Eingaben über seine Ausgabe offenlegt, während der Inferenz; die Minderung besteht nach unserer Lesart aus Ausgabefiltern und Datenlimitierung nach 6.11.2. Annex B ergänzt die konventionellen Wege zum selben Ergebnis: den direkten Diebstahl von Trainingsdaten und das Leck von Modelleingaben, definiert in 3.20 und 3.21. Das prominenteste Beispiel für 6.8 ist EchoLeak, eine Zero-Click-Schwachstelle in Microsoft 365 Copilot, über die interne Daten per Ausgabe abfließen konnten (CVE-2025-32711, behoben Mai 2025). Membership Inference und Model Inversion behandelt Kapitel 7 dieser Seite.

Evasion: täuschen statt manipulieren

Evasion ist der klassische Angriff auf prädiktive Modelle: Ein Bild, eine Transaktion oder ein Text wird minimal verändert, und die Klassifikation kippt. Die Erkennung ordnet die Norm in 7.7 ein, das Out-of-Distribution-Eingaben von adversarialen Eingaben trennt. Zur Minderung gehört Adversarial Training; die Abkürzungen EOT, RT und IDBT in Clause 4 deuten auf Eingabetransformationen als weitere Technik hin, ihre Zuordnung zu 6.3.4 ist jedoch unsere Lesart. Entscheidend ist der Hinweis aus 7.2: Die Norm nennt laut FDIS-Auswertung ein Adversarial Training, das die Anfälligkeit für Patch-Angriffe erhöhte, und empfiehlt deshalb, alle Maßnahmen gemeinsam zu testen, bevor ein Modell in Betrieb geht. Ein verifizierter produktiver Evasion-Vorfall ist bislang nicht öffentlich.

Model Exfiltration: Diebstahl per Abfrage

Die Introduction nennt Model Exfiltration als Paradebeispiel dafür, dass alle Standard-Controls intakt sein können und das Modell trotzdem verloren geht, weil jede einzelne Abfrage legitim ist. Erkennung und Abwehr stützen sich auf Logging und Monitoring nach 7.5, wofür die Norm ausdrücklich ISO/IEC 27002 8.15 und 8.16 nennt, auf die Drosselung der Modellnutzung nach 7.8 und die Optimierung der Modellgröße nach 7.9. Annex B stellt daneben den direkten Modelldiebstahl nach 3.19, den 5.1 als Grund nennt, den Software-Stack zuerst zu härten. Der bekannteste Fall ist ein Vorwurf: OpenAI äußerte ab dem 28.01.2025, DeepSeek könnte seine Modelle unzulässig destilliert haben; Belege wurden nicht veröffentlicht.

Membership Inference und Model Inversion: Vertraulichkeit der Trainingsdaten

Beide Angriffe nutzen aus, dass Modelle ihre Trainingsdaten teilweise speichern und über Wahrscheinlichkeiten, Konfidenzwerte oder Formulierungen preisgeben. Die Minderung setzt nach unserer Lesart an drei Stellen an: Differential Privacy im Training, dessen Abkürzung DP Clause 4 führt, Begrenzung der Ausgaben auf das Nötige und Datenlimitierung nach 6.11.2. Für 2024 bis 2026 ist kein produktiver Vorfall öffentlich belegt; die Bibliografie verweist mit der Arbeit von Carlini zur Extraktion von Trainingsdaten aus Sprachmodellen auf die Forschungsgrundlage. Die KI-Verordnung fasst diese Angriffe unter Confidentiality Attacks, die BaFin-Orientierungshilfe unter dem Sammelbegriff Inference Attacks und empfiehlt differentielle Privatsphäre gegen Rückschlüsse aus Mehrfachabfragen.

Was die Norm zu generativer KI sagt

Clause 3 definiert Foundation Model, LLM und generative KI (3.27 bis 3.29) und fasst Prompt Injection in 3.23 so, dass Inhalte, die als oder in einer Eingabeinstruktion wirken, erfasst sind, womit die indirekte Injection über Dokumente, Webseiten oder E-Mails eingeschlossen ist. Abschnitt 6.9 ordnet den Angriff der Inferenz zu; betroffen sind die Integrität des Outputs und die Vertraulichkeit interner Systeminformationen wie System-Prompts. Die Minderung umfasst nach unserer Lesart die Eingabefilterung aus 7.7, die Trennung von Instruktion und Daten und menschliche Freigabe für folgenreiche Aktionen. Abschnitt 6.10 behandelt den Fall, dass die Modellausgabe selbst Injection-Angriffe gegen nachgelagerte Systeme trägt; die Abwehr liegt nach unserer Lesart in Ausgabekodierung und Allowlists auf Empfängerseite. RAG kommt in Clause 4 und zweimal in 5.3 vor, wo jede Dokumentabfrage einzeln authentisiert und autorisiert werden soll.

Was die Norm zu Agenten sagt und was nicht

Das Wort Agent erscheint in den frei zugänglichen Teilen dreimal, ausschließlich in 5.3: im Beispiel Verifikation von Agentenaktionen, bei dem jede Aktion einzeln verifiziert und autorisiert wird, Zugriff Just-in-time mit begrenztem Umfang erfolgt und Rechte nach Abschluss der Aufgabe verfallen, und in der Lebenszyklusformel bis zum Agentenbetrieb. Das Wort Tool fehlt in den frei zugänglichen Teilen, MCP fehlt in Abkürzungsverzeichnis und Bibliografie, KI-Agent ist nicht definiert, und weder die OWASP Top 10 für LLM-Anwendungen noch die Agentic Top 10 noch NIST AI 100-2 sind zitiert. Heise fasst zusammen, dass die Erstausgabe agentische Systeme mit Werkzeugzugriff nur am Rande behandelt. Das ist Folge des Normungstakts: Der Committee Draft stammt vom Januar 2024, die Welle agentischer Vorfälle begann 2025.

Realfälle 2025 bis 2026: Prompt Injection ist operativ

Die Fallliste für 6.9 und 6.10 ist lang und überwiegend real: EchoLeak in Microsoft 365 Copilot (Zero-Click, behoben Mai 2025), ForcedLeak in Salesforce Agentforce, bei dem CRM-Daten als Bildanfrage an eine abgelaufene Allowlist-Domain flossen (CVSS 9.4), ShareLeak in Copilot Studio (CVE-2026-21520), die Forschungsdemo Comment and Control vom April 2026, bei der eine Injection im Titel eines Pull Requests einen Coding-Agenten seinen eigenen API-Schlüssel veröffentlichen ließ, und die Schwachstelle in der Claude Code GitHub Action (behoben am 05.05.2026). Unit 42 zählte im März 2026 zwölf Fälle indirekter Prompt Injection in freier Wildbahn mit 22 Payload-Techniken. Für 6.10 ist Amazon Q Developer 1.84.0 lehrreich: Eingeschleuster Code sollte einen Agenten ohne Rückfrage mit allen Werkzeugrechten starten und Daten löschen, scheiterte aber an einem Syntaxfehler (CVE-2025-8217).

Die zwei Muss-Sätze in 5.1 — und was sie bedeuten

In den frei zugänglichen Teilen der Norm finden sich nach unserer Prüfung zwei verbindlich formulierte Sätze im fachlichen Text, beide in 5.1 — das formale Foreword-Boilerplate nicht gezählt: Informationssicherheits-Controls, wie sie ISO/IEC 27002 beschreibt, sind risikobasiert umzusetzen, und KI-spezifische Kompromittierungen, darunter die in Table 1 aufgeführten, sind über den gesamten Lebenszyklus zu berücksichtigen. Alles Weitere in den zugänglichen Teilen ist Leitfaden; eine Gesamtzahl für das ganze Dokument lässt sich nicht angeben, weil die Seiten 8 bis 50 nur in der Vollversion vorliegen. Zertifizierbare Anforderungen enthält die Norm in keinem Fall. Die Botschaft ist klar: erst das ISMS, dann die KI-spezifische Erweiterung. 5.1 behandelt KI-Systeme als integrierte Softwarekomponenten und nennt die Härtung des Software-Stacks gegen direkten Modelldiebstahl als effizienten Startpunkt.

5.2 Governance-Programm: Inventar, Risikoanalyse, Steuerung

Abschnitt 5.2 beschreibt drei Bausteine: ein Inventar der KI-Systeme, eine Risikoanalyse und die Steuerung der erkannten Risiken. Für die Governance verweist die Norm auf ISO/IEC 38507, für die Umsetzung als Managementsystem auf ISO/IEC 42001. Was sie nicht leistet: Clause 3 definiert weder die KI-VO-Rollen Provider und Deployer noch die Stakeholder-Rollen der ISO/IEC 22989. Wer Verantwortlichkeiten zuordnet, tut das als eigene Auslegung und sollte das im Governance-Dokument kennzeichnen.

Was ins KI-Inventar gehört

• Modellquelle und Version: eigen trainiert, Open-Source-Modell aus einem Repository, Foundation-Modell im eigenen Tenant oder externe API — die Bezugsvariante bestimmt die Angriffsfläche.
• Trainings-, Fine-Tuning- und Retrieval-Datenquellen mit Herkunft, Freigabe und Eigentümer; 6.11.4 behandelt die Herkunft von System und Daten als eigenes Thema.
• Abfrage- und API-Zugang: wer das Modell mit welchen Limits abfragen darf — Grundlage gegen Extraktion (6.5) und Inferenzangriffe (6.4, 6.6).
• Werkzeuge, Aktionen und Berechtigungen agentischer Komponenten; die Rechtsanalyse in arXiv 2604.04604 nennt ein vollständiges Inventar externer Aktionen und Datenflüsse als erste Pflicht.
• Eigentümer, Kritikalität und regulatorische Einstufung: Hochrisiko nach KI-VO, kritische oder wichtige Funktion nach DORA, Produkt mit digitalen Elementen nach CRA.

Der blinde Fleck heißt Shadow AI: In der CSA/Token-Security-Umfrage vom 21.04.2026 berichteten 82 Prozent von 418 Befragten von unbekannten KI-Agenten, und laut IBM-Report vom 30.07.2025 fehlten bei 97 Prozent der KI-bezogenen Sicherheitsverletzungen KI-Zugriffskontrollen. Die Studien sind herstellergesponsert, die Richtung ist eindeutig: Ohne Inventar bleibt die Risikoanalyse nach 5.2 unvollständig, und jede Maßnahme trifft nur Systeme, die man kennt.

Zitierhinweis: Table 1 wird in 5.1 referenziert, steht dort aber nicht; Verortung und Inhalt sind nur in der Vollversion einsehbar. Diese Seite zählt die neun Typen aus 6.2 bis 6.10.

Software-Engineering für KI (5.4): kein Sonderweg

Abschnitt 5.4 überträgt bewährte Praktiken der Softwareentwicklung auf KI-Systeme; die Norm verweist auf das NIST Secure Software Development Framework (SP 800-218), die Bibliografie führt zudem die NCSC-Leitlinien zur sicheren KI-Entwicklung. Die Haltung ist pragmatisch: Ein KI-System ist zuerst Software, und wer seinen Stack nicht härtet, verliert das Modell über konventionelle Wege — Annex B führt den direkten Modelldiebstahl als KI-spezifische Variante eines klassischen Angriffs. In der ISO/IEC 42001 liegt die Entsprechung nach unserer Lesart in A.6.2.3, der Dokumentation von Design und Entwicklung, die 27090 in 5.1 zitiert.

Datenbezogene Abwehr: Herkunft, Integrität, Limitierung

Erkennung: eine offene Forschungsfrage

Bei der Erkennung von Data Poisoning (6.2.3) ist die Norm auffällig zurückhaltend: Nach der FDIS-basierten Auswertung beschreibt sie das Thema als offene Forschungsfrage, weil automatisierte Verfahren vergiftete Daten nicht zuverlässig von Ausreißern trennen. Daraus folgt eine Gewichtung, die wir teilen: Prävention über Herkunft, Freigabe und Zugriff wiegt schwerer als nachträgliche Detektion, und das Monitoring auf Modellverschlechterung in 7.4 wird zur zweiten Verteidigungslinie. Die Introduction nennt den Mechanismus, der das Thema in den Betrieb trägt: Bei kontinuierlichem Lernen werden Betriebsdaten zu Trainingsdaten, und jede Retraining-Runde ist ein neuer Poisoning-Vektor.

Für Retrieval Augmented Generation gilt dasselbe Prinzip auf der Wissensseite: 5.3 beschreibt im Beispiel zu Anwendungsgrenzen, dass jede Dokumentabfrage einzeln authentisiert und autorisiert wird, und die BaFin-Orientierungshilfe spricht von Wissensvergiftung der RAG-Basis (S. 29). Wer Unternehmensdokumente ungeprüft in einen Vektorindex lädt, baut sich den Poisoning-Vektor selbst.

Was die Norm zum Testen sagt

Clause 5 stellt Threat Modelling in 5.6 und Red Teaming in 5.7 neben Governance und Lieferkette als Grundpraktiken; jeder Kompromittierungstyp in Clause 6 trägt einen Unterabschnitt zur Erkennung. Clause 7 begründet, warum einmaliges Testen nicht reicht: 7.2 beschreibt Wechselwirkungen zwischen Maßnahmen und nennt als Beispiel, dass adversariales Training die Anfälligkeit für Patch-Angriffe erhöhte — die Norm empfiehlt, alle Maßnahmen vor der Bereitstellung gemeinsam zu testen. 7.4 ergänzt den Verfall über die Zeit mit Monitoring, Retraining bei Bedarf und Revalidierung vor der Rückkehr in den Betrieb.

Wann testen: Auslöser statt Kalender

• Vor der Bereitstellung: alle Mitigationen gemeinsam testen, weil sie sich gegenseitig schwächen können (7.2).
• Nach Änderung von Modell, System-Prompt oder Retrieval-Quelle — die drei Auslöser, die Kertos für die Wiederholung des Red Teamings nennt.
• Nach jeder Retraining-Runde: Revalidierung vor der Rückkehr in den Betrieb (7.4).
• Nach Modellupdates eines Anbieters: Update-Ankündigungen gehören deshalb in die Lieferantenanforderungen — Kertos nennt sie als Vertragspunkt, die BaFin-Orientierungshilfe nennt für bezogene Modelle als Praxis Due Diligence und SLAs (Kap. IV.2).
• Wiederkehrend für Maßnahmen, deren Wirkung nachlässt: Eingabefilter und Anomalieschwellen altern mit der Bedrohungslage.
• Bei agentischen Systemen nach jeder Änderung an Werkzeugen, Berechtigungen oder Anbindungen (VamiSec-Empfehlung über 5.3 hinaus).

Der regulatorische Anschluss ist eng: Für Hochrisiko-KI verlangt die KI-Verordnung in Art. 9 Abs. 6 bis 8 Tests im Risikomanagement; DORA verlangt in Art. 24 und 25 ein Testprogramm mit Penetrationstests und Quellcodeprüfungen, und die BaFin beschreibt als Praxis je nach Kritikalität Adversarial Testing, adversariale Penetrationstests mit dem Cloud-Anbieter und Stresstests. ISO/IEC 27090 liefert die Angriffsbegriffe und die Testlogik — nicht die Pflicht.

Red Teaming ist in ISO/IEC 27090 keine Pflicht- oder Zertifizierungsprüfung. Umfang und Turnus bestimmen Risikoanalyse, Kritikalität und, wo einschlägig, KI-VO, DORA oder CRA.

5.3 Zero Trust: fünf Beispiele, die in alle Mitigationen einfließen

• Schutz der Trainingsdaten — die Norm stellt ihn an den Anfang der Beispielliste.
• Modellzugriffskontrollen einschließlich des Zugriffs über RAG.
• Anwendungsgrenzen: Jede Dokumentabfrage wird einzeln authentisiert und autorisiert — keine pauschale Vertrauensstellung zwischen Modell und Datenquelle.
• Verifikation von Agentenaktionen: Einzelautorisierung je Agentenaktion, Rechte nur für die Dauer der Aufgabe.
• Kontinuierliches Monitoring vom Training über die Bereitstellung bis zum Agentenbetrieb.

Diese Linie deckt sich mit den Behördenpapieren seit 2025: BSI und ANSSI beschreiben in ihren Design Principles für LLM-basierte Systeme vom 11.08.2025 sechs Prinzipien von Authentisierung und Autorisierung über Sandboxing und Monitoring bis Awareness und halten fest, dass ein LLM nie selbst authentisieren darf; die NSA stellt in ihrer MCP-Sicherheitsbetrachtung vom Mai 2026 fest, dass Autorisierung im Protokoll optional ist. ISO/IEC 27090 ist nach unserer Einschätzung nicht die detaillierteste, aber die an ISMS und AIMS am besten anschlussfähige Formulierung dieses Konsenses.

Betriebsmaßnahmen je Kompromittierungstyp

Erkennung und Vorfälle: was die Norm sagt und was das ISMS leisten muss

Die Introduction formuliert den Kern: Erkennung ist schwierig, aber essenziell, und Modellexfiltration gelingt über legitime Abfragen trotz intakter Standard-Controls — Rate Limiting hilft. Jeder Kompromittierungstyp hat deshalb einen Erkennungsabschnitt, 7.5 bündelt Logging und Monitoring. Einen eigenen Abschnitt zur Vorfallbehandlung hat die Gliederung der Norm nicht; das Incident-Management des ISMS braucht aus unserer Sicht drei Ergänzungen: KI-Kennzeichnung für Vorfälle, Meldewege zu Modellanbietern und Erkennungsregeln für Abfragemuster, Tool-Aufrufe und Ausgabeanomalien.

Die Realfälle des Betriebs zeigen, dass der Ausgabepfad Angriffsfläche ist: EchoLeak (CVE-2025-32711, CNA-CVSS 9.3) erlaubte per Zero-Click-Injection den Abfluss interner M365-Daten über die Copilot-Ausgabe — gefixt im Mai 2025, ohne bekannte Ausnutzung; ForcedLeak nutzte in Salesforce Agentforce eine abgelaufene Allowlist-Domain für den Abfluss von CRM-Daten; die Claude Code GitHub Action las nach einer Injection in Issue-Texten Umgebungsvariablen außerhalb der Sandbox. In allen drei Fällen hätten nach unserer Einschätzung Output-Filter, Allowlists und Tool-Call-Logging aus 6.8.4, 6.10.4 und 7.5 den Abfluss erschwert oder sichtbar gemacht. Im Finanzsektor kommt der Aktionsplan hinzu, den die EZB-Bankenaufsicht von bedeutenden Instituten bis 31.10.2026 erwartet — unter anderem Logging und kontinuierliche Verifikation von APIs und Service-Konten, allerdings mit Blick auf KI als Angriffswerkzeug, nicht auf die 27090-Bedrohungen.

Logging nach ISO/IEC 27002 8.15 und RTS RMF Art. 12 dient der Sicherheit; die Aufzeichnungspflichten nach Art. 12 und Art. 26 KI-VO sind ein eigenes Regime — beide Anforderungen getrennt dokumentieren.

Nach der FDIS-basierten Auswertung nennt 5.5 als Lieferkettenelemente vortrainierte Modelle, gekaufte Datensätze, MLOps-Werkzeuge und Notebook-Plattformen. Für die Akteure entlang der Kette verweist 5.1 auf die Controls A.6.2.3 und A.6.2.6 der ISO/IEC 42001, und Annex B führt nach der DIS-basierten Darstellung auch Supply-Chain-Angriffe als KI-spezifische Variante konventioneller Angriffe. Die Norm beschreibt die Kette damit von der Datenquelle über das Modell bis zur Werkzeugumgebung, ohne eine Bezugsform zu bevorzugen.

Drei Bezugsvarianten, drei Risikoprofile

AI-BOM: was die Stückliste enthalten sollte

• Modelle mit Quelle, Version, Hash oder Signatur und Lizenz, einschließlich der Basismodelle hinter Fine-Tunings.
• Datensätze mit Herkunft, Freigabe und Verwendungszweck (Training, Fine-Tuning, Retrieval, Test).
• Pakete und Bibliotheken mit Versions-Pinning, Hash-Prüfung und Abgleich gegen Advisories.
• Werkzeuge, Konnektoren und MCP-Server agentischer Systeme mit ihren Berechtigungen.
• System-Prompts, Prompt-Vorlagen und Retrieval-Quellen — jede Änderung ist ein Testauslöser.
• Anbieterzusagen zu ISO/IEC 27002 5.19/5.20: Verwendung der Eingaben fürs Training, Verifikation vortrainierter Komponenten, Ankündigung von Updates, Tests gegen Evasion und Injection.

Das gemeinsame Cybersecurity Information Sheet zu Risiken der KI/ML-Lieferkette, von der NSA am 13.03.2026 gelistet, empfiehlt die AI-BOM als Ergänzung zur SBOM. Die BaFin-Orientierungshilfe nennt für Finanzunternehmen als Praxis Due Diligence, SLAs und einen Exit mit Export von Modellen, Trainingsdaten und Metadaten (Kap. IV.2); EIOPA erwartet in ihrer Opinion vom 06.08.2025 von Versicherern Informationen und Zusicherungen der Drittanbieter. ISO/IEC 27090 liefert die Angriffsbegriffe, mit denen sich diese Anforderungen gegenüber dem Anbieter konkret formulieren lassen.

Realfälle 2024–2026: Lieferkette als bevorzugter Weg

Zwei Lehren: Erstens reagiert die Infrastruktur — PyPI lehnt seit 22.07.2026 neue Dateien für Releases ab, die älter als 14 Tage sind. Zweitens reicht das nicht: Der Oktober-Vorfall lief mit sauberem Git-Tag und aktiviertem Trusted Publishing. Für Betreiber heißt das Versions-Pinning mit Hash-Prüfung, ein interner Spiegel mit Freigabeverzug, kurzlebige Secrets mit begrenztem Scope — und die Erkenntnis, dass die Credentials von KI-Werkzeugen selbst zum Ziel geworden sind.

Drei Normen, drei Rollen — und die Schwester 27091

SoA-Mechanik: 27090 als Control-Quelle

ISO/IEC 27001 erlaubt in 6.1.3, Maßnahmen aus beliebiger Quelle zu bestimmen; Annex A ist Prüfliste, nicht Grenze. Genau hier wird 27090 anschlussfähig: Die Mitigationen aus 6.x.4 und Clause 7 lassen sich als Quelle in der Erklärung zur Anwendbarkeit zitieren — etwa 6.8.4 für Ausgabefilter oder 6.9.4 gegen Prompt Injection — ohne zweites Managementsystem. Zur Kennzeichnung eignen sich die Control-Attribute nach ISO/IEC 27002 4.2. Ein KI-Amendment zur 27002:2022 ist nicht registriert, ebenso wenig eine Revision der 42001:2023; neu ist nur ISO/IEC AWI 42003 als Umsetzungsleitfaden zur 42001.

1. 1
   ISO/IEC 27002 5.9 · 42001 A.4.3KI-Systeme als Werte inventarisieren

   Modellquelle, Trainings- und Fine-Tuning-Daten, Retrieval-Quellen, Abfragezugang und agentische Berechtigungen je System erfassen.

2. 2
   ISO/IEC 27001 6.1.2 · 27090 Clause 6Neun Typen in die Risikobewertung aufnehmen

   Je System bewerten, welche Kompromittierungstypen und Annex-B-Varianten realistisch sind — mit Bezug auf Bezugsvariante und Lebenszyklusphase.

3. 3
   ISO/IEC 27001 6.1.3Maßnahmen wählen und 27090 in der SoA zitieren

   Gewählte Mitigationen mit Abschnittsnummer dokumentieren, ausgeschlossene begründen, Wechselwirkungen nach 7.2 vermerken.

4. 4
   ISO/IEC 27002 5.19/5.20 · 42001 A.10.3Lieferantenprüfung auf Modellanbieter ausweiten

   Fragenkatalog aus Kapitel 13 dieser Seite anwenden, Antworten in der AI-BOM ablegen, Zusagen zu Updates und Tests vertraglich festhalten.

5. 5
   ISO/IEC 27090 5.7 · 42001 A.6.2.4Testen und bei Änderung wiederholen

   Red Teaming vor Bereitstellung und nach Änderung von Modell, System-Prompt oder Retrieval-Quelle; Berichte in Risikoregister und SoA zurückführen.

Was Auditoren künftig fragen

Zur Zertifizierungslandschaft: Akkreditierungsgrundlage für 42001-Zertifizierer ist ISO/IEC 42006:2025. In der DAkkS-Datenbank fand sich am 22.10.2026 keine akkreditierte Zertifizierungsstelle für ISO/IEC 42001, während für ISO/IEC 27001 37 Stellen gelistet sind; international haben unter anderem BSI Group (ANAB, UKAS, RvA) und DQS (ANAB) im März 2026 Akkreditierungen erhalten. Wer ein 42001-Zertifikat anstrebt, sollte den Akkreditierer der gewählten Stelle einzeln prüfen.

Formulierungen wie „ISO-27090-Zertifizierung“, „27090-konform“ oder „Audit nach 27090“ sind sachlich falsch; korrekt ist: Maßnahmen nach ISO/IEC 27090 im ISMS nach 27001 oder im AIMS nach 42001 umgesetzt.

Art. 15 Abs. 5 KI-VO: Begriffe, die 27090 ausfüllt

Der Vermutungsweg über Art. 42 verdient einen genauen Blick: Abs. 2 verweist auf Zertifikate unter einem Schema des Cybersecurity Act, doch ENISA führt bis heute kein Kandidatenschema für KI. Praktisch nutzbar ist der durch die Omnibus-Verordnung eingefügte Abs. 3 — Hochrisiko-KI im Anwendungsbereich des CRA gilt als konform mit Art. 15, wenn die Anforderungen nach CRA Art. 12 Abs. 1 erfüllt und in der EU-Konformitätserklärung nachgewiesen sind. Die CRA-Umsetzung trägt damit die Cybersicherheitsseite der KI-VO mit; 27090 ist nach unserer Einschätzung das Werkzeug, mit dem sich die Anforderungen des CRA-Anhangs I für die KI-Komponente konkretisieren lassen.

Ein zweiter Punkt betrifft Rollen: Nach Art. 25 KI-VO wird ein Betreiber zum Anbieter, wenn er ein Hochrisiko-System unter eigenem Namen vermarktet, wesentlich verändert oder dessen Zweck ändert; Fine-Tuning fremder Modelle kann diese Schwelle überschreiten, und da 27090 die Rollen nicht definiert, muss die Zuordnung der Maßnahmen zur eigenen Rolle im Governance-Dokument explizit erfolgen. Zum DACH-Status: Eine deutsche Fassung gibt es nicht, DIN Media und SNV vertreiben das englische Original, eine ÖNORM-Übernahme ist nicht bekannt, und das BSI nennt die Norm in keiner Publikation; die britische Übernahme BS ISO/IEC 27090:2026 ist für den 31.10.2026 angekündigt. TÜV Rheinland riet im Mai 2026, nicht auf harmonisierte Normen zu warten — nach der abgelehnten Enquiry zu prEN 18282 gilt das umso mehr.

Eine Konformitätsvermutung nach KI-Verordnung oder Cyber Resilience Act erzeugt ISO/IEC 27090 nicht; vorgesehen ist dafür prEN 18282 von CEN/CENELEC JTC 21, noch im Entwurf. Der Normungsauftrag M/613 löst M/593 ab; ob er ihn formal aufhebt oder ändert, ist öffentlich nicht belegt.

1. 1
   Tage 1–14 · 27090 5.2 · 27001 6.1Mandat, Scope und Zielniveau klären

   Leitung bestätigt das Vorhaben und benennt Verantwortliche; Scope umfasst alle KI-Systeme einschließlich API-Nutzung; Zielniveau je System aus Hochrisiko-Einstufung, Kritikalität und Bezugsvariante ableiten.

2. 2
   Tage 15–45 · 27002 5.9 · 27090 5.6Inventar und Threat Model

   KI-Inventar mit AI-BOM aufbauen; je System ein Threat Model entlang der neun Typen und Annex B; Agenten mit Werkzeugen und Berechtigungen gesondert erfassen.

3. 3
   Tage 46–90 · 27001 6.1.2/6.1.3 · 27090 Clause 6Risikobewertung und SoA

   Risiken bewerten, Mitigationen aus 6.x.4 und Clause 7 wählen, 27090 in der SoA zitieren; Sofortmaßnahmen: Abfragebudgets, Logging von Eingaben, Ausgaben und Tool-Aufrufen, Versions-Pinning mit Hash-Prüfung.

4. 4
   Monate 4–6 · 27090 5.3, 5.5, 7.5–7.8Härten: Zero Trust, Lieferkette, Betrieb

   Modell- und Datenzugriff nach 5.3 umbauen, Agentenrechte just-in-time mit Scope und Ablauf; Lieferantenprüfung auf Modellanbieter ausweiten; Eingabe- und Ausgabefilter, Throttling und Anomalieerkennung in Betrieb nehmen.

5. 5
   Monate 7–9 · 27090 5.7, 7.2, 7.4Testen: Red Teaming und Wechselwirkungen

   Red Teaming der priorisierten Systeme, Mitigationen gemeinsam testen, Modellleistung mitmessen; Testauslöser für Modell-, Prompt- und Retrieval-Änderungen im Änderungsmanagement verankern.

6. 6
   Monate 10–12 · 42001 A.6.2.6 · 27001 ManagementbewertungWirksamkeit nachweisen und Zyklus schließen

   Monitoring- und Drift-Berichte auswerten, Testergebnisse in Risikoregister und SoA zurückführen, Kennzahlen an die Leitung berichten, Fahrplan für das Folgejahr aus dem Gap-Check ableiten.

Kennzahlen, die der Vorstand versteht

Einwände — und was wir antworten

Als Plausibilitätsprüfung eignet sich das dreistufige Reifegradmodell von Abilene Academy: ein Minimum nach 30 Tagen mit Inventar, Threat Models und Logging von Inferenz- und Tool-Aufrufen; ein etablierter Stand nach 90 Tagen mit Herkunftsnachweisen, Red-Team-Tests, Lieferantenanforderungen und KI-Incident-Response; ein fortgeschrittener Stand mit laufendem Monitoring, Review von Modelländerungen und Prüfung von Agentenrechten. Der dort formulierte Grundsatz, jedes Modellartefakt, jeden Datensatz, jede Prompt-Vorlage und jede Werkzeugberechtigung als Angriffsfläche zu behandeln, deckt sich mit unserer Lesart der Norm.

ISO/IEC 27090 ist ein Leitfaden ohne zertifizierbare Anforderungen. Verbindlich sind die Verpflichtungen aus dem eigenen ISMS oder AIMS sowie KI-VO, CRA, NIS2 und DORA. Der Fahrplan ist eine Empfehlung von VamiSec und keine Rechtsberatung.