Wenn Sie KI-Systeme betreiben oder entwickeln, nutzen Sie die ISO/IEC 27090 als KI-spezifische Bedrohungs- und Maßnahmenebene innerhalb Ihres bestehenden Programms nach ISO/IEC 27001 oder ISO/IEC 42001. Behandeln Sie sie nicht als eigenständiges Compliance-Projekt.
Zusammenfassung
Die ISO/IEC 27090:2026 ist ein veröffentlichter Leitfaden zu KI-spezifischen Sicherheitsbedrohungen. Sie ist nicht zertifizierbar. Nutzen Sie sie, um Ihren Risikoprozess nach ISO/IEC 27001 und Ihr KI-Managementsystem nach ISO/IEC 42001 zu erweitern. Beginnen Sie mit einem KI-Inventar, Bedrohungsmodellen für Systeme mit hoher Auswirkung, Herkunftsnachweisen, Agentenberechtigungen und Testnachweisen. Sie stützt die Konformität mit Artikel 15 des AI Act im Bereich Cybersicherheit, belegt sie aber allein nicht.
Die ISO/IEC 27090:2026 ist inzwischen eine veröffentlichte internationale Norm. Die ISO führt sie als veröffentlicht mit dem Meilenstein 14. Oktober 2026. Sie wurde vom Komitee ISO/IEC JTC 1/SC 27 erarbeitet, das sich mit Informationssicherheit befasst. Dieser Artikel erklärt, was die Norm abdeckt, was sie nicht leistet und wie sie sich zu ISO/IEC 27001 und ISO/IEC 42001 verhält.
Über den Autor
Verfasst von Alexis Hirschhorn, Trainer bei Abilene Academy. Zertifizierter ISO/IEC 42001 Lead Implementer, Certified Artificial Intelligence Professional, CISSP, CISM, CISA, ISO/IEC 27001 Senior Lead Auditor und PECB Certified Trainer. Rund 25 Jahre praktische Erfahrung in Informationssicherheit, Cloud-Sicherheit und KI-Governance, u. a. für multinationale Konzerne, öffentliche Stellen und internationale Organisationen. Profil: https://www.abileneacademy.ch/de/about/team/alexis-hirschhorn
Die Praxiszitate in diesem Artikel spiegeln die Schulungserfahrung von Abilene Academy wider und sind keine Positionen der ISO. Die ISO/IEC 27090 ist eine veröffentlichte Norm; maßgeblich für Status und Inhalt ist der Katalog der ISO.
Status
ISO/IEC 27090:2026, Ausgabe 1, veröffentlicht im Oktober 2026. 56 Seiten. Leitlinien zu Sicherheitsbedrohungen und Kompromittierungen von KI-Systemen. Gremium: ISO/IEC JTC 1/SC 27.
Nicht zertifizierbar
Sie können nicht nach ISO/IEC 27090 zertifiziert werden. Sie können sie aber innerhalb eines nach ISO/IEC 27001 zertifizierten ISMS oder eines nach ISO/IEC 42001 zertifizierten KI-Managementsystems nutzen und Auditoren sowie Kunden zeigen, wie Sie KI-Bedrohungen behandelt haben.
Warum jetzt eine Sicherheitsnorm für KI
Die meisten KI-Systeme in Unternehmen wurden nicht vom Sicherheitsteam entwickelt. Sie kommen als Funktion eines SaaS-Produkts, als Modell hinter einer API, als Agent, der an ein Ticketsystem angebunden ist, oder als Coding-Assistent im Entwicklungsteam. Jedes davon erzeugt Angriffspfade, die ein klassischer Schwachstellenscan nicht erfasst: vergiftete Trainingsdaten, Prompts, die versteckte Anweisungen einschleusen, und Modellausgaben, die nachgelagerte Aktionen auslösen.
Die 27090 gibt Sicherheitsteams eine gemeinsame Sprache und eine Bedrohungsliste für diese Pfade. Sie verpflichtet Sie nicht, ein Werkzeug zu kaufen. Sie benennt, welche Kompromittierungen zu berücksichtigen sind, wie sie sich zeigen, wie Sie sie erkennen und wie Sie sie reduzieren.
Nicht autorisierte KI macht das Inventar dringend. In einer WatchGuard-Umfrage vom April 2026 gaben 64 % der Beschäftigten an, für ihre Arbeit nicht genehmigte KI-Werkzeuge zu nutzen. Die Stichprobe umfasste 684 Beschäftigte kleiner und mittlerer Organisationen, und die Angaben sind selbstberichtet. Quelle: WatchGuard, 2026 Cybersecurity Hygiene Report.
Was die ISO/IEC 27090 ist und was nicht
Die Norm besteht aus einem kurzen normativen Rahmen, einem Hauptteil mit Leitlinien und drei informativen Anhängen. Klausel 5 beschreibt, wie Informationssicherheit auf KI anzuwenden ist, einschließlich Governance, Zero-Trust-Prinzipien, Softwareentwicklungspraktiken, Lieferkettenmanagement, Bedrohungsmodellierung und Red Teaming. Klausel 6 beschreibt die Arten von Kompromittierungen, von der Datenvergiftung bis zur Prompt-Injection. Klausel 7 behandelt Gegenmaßnahmen, auch wie sie miteinander in Konflikt geraten und mit der Zeit an Wirksamkeit verlieren können.
„Behandeln Sie jedes Modellartefakt, jeden Datensatz, jede Prompt-Vorlage und jede Werkzeugberechtigung als Angriffsfläche. Kann ein Element das Modellverhalten ändern oder ein nachgelagertes System erreichen, gehört es ins Bedrohungsmodell.“
Alexis Hirschhorn, Trainer bei Abilene Academy
Wie die ISO/IEC 27090 zu den Normen passt, die Sie bereits nutzen
Norm: ISO/IEC 27001:2022 (Anforderungen an das Managementsystem)
Norm: ISO/IEC 27002:2022 (Leitlinien zu Maßnahmen)
Norm: ISO/IEC 42001:2023 (Anforderungen an das KI-Managementsystem)
Norm: ISO/IEC 23894:2023 (Leitlinien zum KI-Risikomanagement)
Norm: ISO/IEC 27090:2026 (Sicherheitsleitlinien für KI)
Norm: ETSI EN 304 223 (europäische Basisanforderungen an die Cybersicherheit von KI)
Zwei Grenzen sind wichtig. Erstens geht es bei der 27090 um den Schutz von KI-Systemen, nicht um den Einsatz von KI zur Verteidigung von Netzwerken. Zweitens garantiert sie nicht, dass ein System gegen Angriffe immun ist. Ihre Maßnahmen senken das Risiko, und das Restrisiko muss weiterhin von jemandem getragen und akzeptiert werden.
Die KI-Bedrohungen, die Sie zuerst verstehen sollten
Klausel 6 beschreibt zu jeder Kompromittierung deren Wesen, die daraus entstehenden Fehlerbilder, die Erkennung und die Gegenmaßnahme. Die Tabelle verwendet einfache Sprache. Die Klauselverweise stammen aus der Norm; die Zuordnungen zu anderen Rahmenwerken sind unsere Auslegung und sollten anhand der aktuellen Versionen geprüft werden.
Bedrohungen der ISO/IEC 27090 mit Beispiel
Bedrohung: Datenvergiftung
Bedrohung: Evasion
Bedrohung: Mitgliedschaftsinferenz
Bedrohung: Modellexfiltration
Bedrohung: Modellinversion
Bedrohung: Direkte Modellvergiftung
Bedrohung: Sensible Modellausgabe
Bedrohung: Prompt-Injection
Bedrohung: Ausgabe mit Injection
Zwei Lücken sollten Sie kennen. Das Inhaltsverzeichnis enthält keinen eigenen Abschnitt zu Jailbreaks, und Risiken von Agenten und Werkzeugmissbrauch werden kürzer behandelt als in spezialisierten Katalogen. Nutzen Sie dafür die OWASP Top 10 für LLM-Anwendungen und die MITRE-ATLAS-Wissensbasis ergänzend zur 27090.
Warum das jetzt zählt: der regulatorische Zeitplan
Eine Norm ist nur dann nützlich, wenn jemand den Nachweis verlangt. Vier Regelwerke tun das heute.
AI Act, Artikel 15
Hochrisiko-KI-Systeme müssen gegen Versuche resistent sein, Datenvergiftung, Modellvergiftung, adversariale Beispiele und Angriffe auf die Vertraulichkeit auszunutzen. Klausel 6 der 27090 behandelt jede dieser Kategorien namentlich. Quelle: Verordnung (EU) 2024/1689, Artikel 15, und der Dienst AI Act Service Desk der Europäischen Kommission.
Der Digitale Omnibus zur KI, Verordnung (EU) 2026/1744, hat die eigenständigen Hochrisiko-Pflichten nach Anhang III auf den 2. Dezember 2027 und die nach Anhang I auf den 2. August 2028 verschoben. Den vollständigen Zeitplan finden Sie im Beitrag EU-KI-Verordnung: Hochrisiko-Fristen. Der Aufschub verändert den Zeitpunkt, zu dem eine Aufsichtsbehörde handeln kann; er verringert nicht das Risiko, das Ihre Systeme tragen.
Die NIS-2-Richtlinie verpflichtet wesentliche und wichtige Einrichtungen, die Sicherheit von Lieferkette und Entwicklung zu steuern, und KI-Dienste fallen in diese Maßnahmen, wenn sie Teil der Leistung sind. Seit dem 11. September 2026 müssen Hersteller nach dem Cyber Resilience Act (CRA) aktiv ausgenutzte Schwachstellen melden. Eine Prompt-Injection-Lücke in einem Produkt, das in der Praxis ausgenutzt wird, kann daher meldepflichtig sein. Die Fristen finden Sie in den CRA-Meldepflichten.
In der Schweiz hat der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte (EDÖB) erklärt, dass das revidierte Datenschutzgesetz (revDSG) unmittelbar auf KI-gestützte Bearbeitungen personenbezogener Daten anwendbar ist. Mitgliedschaftsinferenz, Modellinversion und sensible Ausgaben sind daher Vertraulichkeitsverletzungen im Sinne der Pflicht zur Datensicherheit und gehören in die Datenschutz-Folgenabschätzung.
„In der Schweiz ist eine KI-Funktion, die personenbezogene Daten verarbeitet, eine Bearbeitung wie jede andere. Die Innovation entbindet nicht von der Pflicht, Zweck, Datenflüsse, Sicherheitsrisiken, Aufbewahrung und den verantwortlichen Owner zu dokumentieren.“
Von der Bedrohungsliste zu Maßnahmen mit Nachweisen
Ein nützlicher Test lautet: Hinterlässt eine Maßnahme Nachweise, die ein Auditor stichprobenartig prüfen kann? Die Tabelle zeigt, wo jede Bedrohung in den Lebenszyklus eintritt und welche Maßnahme der 27090 greift.
Wo KI-Bedrohungen in den Lebenszyklus eintreten und welche Maßnahme der 27090 gilt
Phase: 1. Daten
Phase: 2. Training
Phase: 3. Evaluation
Phase: 4. Bereitstellung
Phase: 5. Überwachung
Phase: 6. Außerbetriebnahme
Ein Reifegradmodell für KI-Sicherheitsmaßnahmen
Versuchen Sie nicht, den gesamten Katalog auf einmal umzusetzen. Arbeiten Sie in drei Stufen und behandeln Sie jede als Nachweisbündel, das Sie vorlegen können.
Reifegradstufen für die Maßnahmen der ISO/IEC 27090
Stufe: Minimum
Stufe: Etabliert
Stufe: Fortgeschritten
Warum das Inventar zuerst kommt
Nicht genehmigte KI ist in beiden Umfragen, die wir gesichtet haben, weit verbreitet. Ein KI-Inventar muss eingebettete KI-Funktionen, Browser-Erweiterungen, Coding-Assistenten und von Mitarbeitenden gewählte Werkzeuge umfassen, nicht nur die Modelle, die die Organisation bewusst eingeführt hat.
Datenabfluss
In einer PagerDuty-Umfrage unter 1.250 Bürobeschäftigten in Organisationen mit einem Jahresumsatz von mindestens 500 Millionen US-Dollar gaben 43 % an, E-Mails oder andere Korrespondenz in öffentliche KI-Werkzeuge eingegeben zu haben, 34 % Kundendaten und 31 % Finanzinformationen oder vertrauliche Dokumente. Beschäftigte geben Kundendaten und vertrauliche Dokumente möglicherweise bereits in Werkzeuge außerhalb Ihrer verwalteten Umgebung ein.
Quellen der Zahlen oben: WatchGuard, 2026 Cybersecurity Hygiene Report (Umfrage vom April 2026, selbstberichtet); PagerDuty Shadow AI Survey (Juni 2026).
Praxisbeispiel: ein KI-Support-Agent mit CRM-Zugriff
Dies ist ein zusammengesetztes Beispiel, kein Kundenfall. Betrachten Sie einen KI-Assistenten, der Kundentickets beantwortet und Notizen im CRM anlegen kann. Das ist eine verbreitete Konfiguration, und an ihr lassen sich die meisten Bedrohungen der 27090 in einem einzigen System zeigen.
Inventar. Das System ist mit seinem Owner (der Leiterin bzw. dem Leiter Kundenbetrieb), seinem Modell und Anbieter, seinen Datenquellen (Tickettext, CRM-Datensätze), seinen Werkzeugen (Notiz anlegen, Status aktualisieren) und seinen menschlichen Freigaben erfasst. Auch die KI-Funktionen des Ticketsystems sind aufgenommen.
Bedrohungsmodell. Vier Bedrohungen sind zentral: indirekte Prompt-Injection über Kunden-E-Mails (6.9), übermäßige CRM-Berechtigungen des Agenten (5.3, 6.11.3), sensible Ausgaben, die den Datensatz eines anderen Kunden offenlegen (6.8), und Werkzeugaufrufe, die niemand protokolliert (7.5).
Maßnahmen. Der Agent erhält eine eigene Zugangsdaten mit dem minimalen CRM-Umfang. Änderungen an Kundendatensätzen erfordern eine menschliche Freigabe. Die Ausgabe wird bereinigt, bevor sie die CRM-Oberfläche erreicht (6.10). Werkzeugaufrufe werden mit Nutzer, Eingabe und Ergebnis protokolliert. Für den Endpunkt gelten Ratenbegrenzungen (7.8). Red-Team-Tests mit injizierten E-Mail-Inhalten laufen vierteljährlich.
Nachweise, die ein Auditor stichprobenartig prüfen würde. Der Umfang der Agenten-Zugangsdaten im Berechtigungsregister. Drei stichprobenartig gezogene Werkzeugaufruf-Protokolle, mit einer Freigabe und einer abgelehnten Aktion. Der letzte Red-Team-Bericht mit seinen Injection-Testfällen und den Behebungstickets. Der Änderungseintrag, der zeigt, wann die Berechtigungen des Agenten zuletzt geprüft wurden.
Entscheidung über das Restrisiko. Eine Injection kann den Agenten weiterhin dazu bringen, eine falsche Notiz zu entwerfen. Sie kann jedoch keinen Kundendatensatz ohne Freigabe ändern und keine Datensätze anderer Kunden lesen. Der Owner akzeptiert das Restrisiko eines falschen Entwurfs, hält diese Entscheidung fest und legt ein Prüfdatum fest, das an die nächste Modell- oder Berechtigungsänderung gekoppelt ist.
Agenten und Werkzeuge: wo der Wirkungsradius zählt
Bei agentischer KI ist die Norm am knappsten. Die 27090 wendet Zero Trust auf Agentenoperationen an und empfiehlt das Least-Privilege-Prinzip für das Modell. Das ist eine gute Grundlage, aber sie liefert keine vollständige Liste von Szenarien für den Werkzeugmissbrauch. Die praktischen Fragen sind konkret: Welche Werkzeuge kann der Agent aufrufen, mit welchen Zugangsdaten, welche Aktionen brauchen eine menschliche Freigabe, und was geschieht, wenn eine Anweisung innerhalb abgerufener Inhalte auftaucht? Die OWASP Top 10 für LLM-Anwendungen (Ausgabe 2025) führen übermäßige Handlungsbefugnisse (Excessive Agency) unter den Kernrisiken. Eine Modellausgabe, die Werkzeuge auslösen, Daten schreiben oder Nachrichten versenden kann, braucht Berechtigungen, die so eng sind wie bei jedem Dienstkonto.
„Ein Filter gegen Prompt-Injection ist eine nützliche Kontrolle, aber kein Berechtigungsmodell. Gestalten Sie den Agenten für den Tag, an dem das Modell getäuscht wird: Begrenzen Sie seine Zugangsdaten, trennen Sie seine Berechtigungen von denen des Nutzers, verlangen Sie eine Freigabe für irreversible Aktionen und machen Sie jeden Werkzeugaufruf beobachtbar.“
Alexis Hirschhorn, Trainer bei Abilene Academy
Agenten-Governance
In der Studie AI Agents at Work 2026 von Okta gaben 92 % der Führungskräfte an, dass autonome KI-Agenten in ihrer Organisation bereits weit verbreitet (58 %) oder moderat (35 %) genutzt werden. 58 % der Führungskräfte berichteten von einem KI-bezogenen Sicherheitsvorfall oder einem Beinahe-Vorfall in den vergangenen zwölf Monaten. Agenten sollten nicht standardmäßig die weitreichenden Rechte der Nutzer erben. Legen Sie vor dem Einsatz die Identität des Agenten, die erlaubten Werkzeuge, den Datenumfang, die Freigabeschwellen, die Protokollierung und eine Möglichkeit zum Stoppen fest. Dies sind Umfragewerte von Führungskräften, keine geprüften Vorfallszahlen.
Unsere Schulung Lead AI Risk Manager behandelt diese Themen: Identifikation von KI-Risiken, nachvollziehbare Entscheidungen und belastbare Maßnahmen über den gesamten Lebenszyklus eines Systems.
Was reale Vorfälle lehren
Vier öffentliche Fälle zeigen, wie sich die Bedrohungen der 27090 realisieren. Jeder wird aus der Originalforschung bzw. dem Originalbericht des Anbieters zusammengefasst, mit verlinkter Quelle.
Klickfreie Prompt-Injection in einem Unternehmensassistenten. Forschende von Aim Labs beschrieben eine präparierte E-Mail, mit der ein Assistent nach Art von Microsoft 365 Copilot Daten aus seinem Kontext preisgab, ohne dass der Nutzer etwas tat. Die Lücke ist als CVE-2025-32711 dokumentiert und in arXiv 2509.10540 analysiert. Der Angriff verkettete mehrere Umgehungen: die Evasion eines Klassifikators, die Umgehung der Link-Schwärzung und eine Bildanfrage an eine erlaubte Domain. Microsoft behob die Lücke serverseitig. Lehre: Die Darstellung einer Ausgabe, die Netzwerkanfragen auslöst, ist ein Datenabflussweg.
Bösartige Modelle auf einer öffentlichen Plattform. In einem JFrog-Blogbeitrag vom 27. Februar 2024 meldete das Unternehmen rund 100 bösartige Modelle auf Hugging Face. Eines nutzte die Pickle-Serialisierung von Python, um beim Laden eine Verbindung zu einer entfernten Adresse zu öffnen. Lehre: Eine Modelldatei ist Code. Behandeln Sie sie wie ein Drittanbieter-Binary und bevorzugen Sie sichere Formate wie safetensors.
KI-orchestrierte Eindringkampagne. In seinem Bericht vom November 2025 beschreibt Anthropic einen Akteur, den das Unternehmen mit hoher Zuversicht einer staatlich unterstützten Gruppe zuordnet. Dieser setzte ein agentisches Coding-Werkzeug ein, um Aufklärungs- und Eindringschritte gegen mehrere Organisationen auszuführen, wobei Menschen nur an wenigen Entscheidungspunkten eingriffen. Der Akteur stellte die Arbeit als legitimen Test dar, um Schutzmechanismen zu umgehen. Lehre: Die Widerstandsfähigkeit gegen Jailbreaks kann versagen, daher zählen Erkennung und die Fähigkeit, den Zugriff zu unterbinden.
Diebstahl eines Teils eines produktiven Modells. In arXiv 2403.06634 (ICML 2024) rekonstruierten Carlini et al. über die öffentliche API die Projektionsmatrix produktiver Sprachmodelle. Lehre: Das Design einer API ist eine Sicherheitsentscheidung. Logprobs und Logit-Bias erweitern, was ein Angreifer lernen kann.
Die Offenlegung von Schwachstellen ist uneinheitlich. Eine Untersuchung der Offenlegungsrichtlinien von 264 KI-Anbietern (arXiv 2509.06136) ergab, dass 36 % keinen Kanal zur Meldung von Schwachstellen bereitstellten und nur 18 % KI-Risiken ausdrücklich erwähnten. Datenzugriff, Autorisierung und Modellextraktion wurden am häufigsten als im Geltungsbereich liegend genannt, während Jailbreaks und Halluzinationen meist ausgenommen waren. Einkaufsteams sollten eine konkrete Frage stellen: Wie lautet Ihre Richtlinie zur Offenlegung von KI-Schwachstellen, und sind Prompt-Injection, Modellextraktion und Datenvergiftung im Geltungsbereich? Die Studie misst veröffentlichte Richtlinien, nicht das tatsächliche Verhalten der Anbieter.
Die 27090 im Rahmen von ISO/IEC 27001 und ISO/IEC 42001 nutzen
Wenn Sie ein ISMS nach ISO/IEC 27001 betreiben, nehmen Sie die KI-Bedrohungen in Ihr Risikoregister und in die Begründungen Ihrer Erklärung zur Anwendbarkeit (SoA) auf. Wenn Sie ein KI-Managementsystem nach ISO/IEC 42001 betreiben oder planen, verknüpfen Sie die KI-Auswirkungsbewertung und den Risikoprozess mit dem Bedrohungskatalog. Die Norm verweist für das Managementsystem auf die 42001 und für Maßnahmenleitlinien auf die 27002. Die drei Normen funktionieren daher als Einheit.
Auditoren eines 42001-Systems suchen nach Nachvollziehbarkeit: von einer Modellversion über ihre Auswirkungsbewertung, Datenentscheidungen, Testergebnisse und Freigabe bis zur Überwachung. Der Beitrag ISO-42001-Audit 2026: Welche Nachweise ein KI-Managementsystem liefern muss beschreibt die Nachweisakte im Detail.
„Bereitschaft ist kein Zustand, den man erreicht. Sie ist eine Eigenschaft Ihrer Nachweise. Existieren Ihre Nachweise nur, weil jemand sie für das Audit zusammengestellt hat, waren Sie nie bereit, sondern nur vorbereitet, und das ist etwas anderes.“
Alexis Hirschhorn, Trainer bei Abilene Academy
Für KI-Systeme heißt das: Inventar, Bedrohungsmodell, Datenherkunft, Testergebnisse und Überwachungsprotokolle müssen als Teil des laufenden Betriebs gepflegt werden und dürfen nicht erst vor einem Audit zusammengestellt werden. Nutzen Sie dieses Prinzip als Test für die folgende Nachweisliste.
- KI-Inventar mit Verantwortlichen, Zwecken, Datenquellen und Anbietern
- Bedrohungsmodell für jedes KI-System im Geltungsbereich, auf Basis von Klausel 6
- Herkunfts- und Abstammungsnachweise für Trainings- und Feintuning-Daten
- Hashes oder Signaturen der Modellartefakte und sichere Serialisierung vor dem Laden
- Regeln für die Behandlung von Ein- und Ausgaben für jede KI-Funktion, die einen Nutzer oder ein Werkzeug erreicht
- Red-Team- oder adversariale Testberichte mit dem Stand der Behebung
- Protokollierung und Ratenbegrenzung für Inferenz-Endpunkte mit Überwachung von Abfragemustern
- Protokoll der Abwägungsentscheidungen, etwa Datenschutz gegen Genauigkeit oder Protokollierung gegen Datenminimierung
Teams, die KI-Inventar, Bedrohungsmodelle und den Nachweispfad an einem Ort führen wollen, nutzen oft eine KI-native GRC-Plattform wie Acuna GRC, die diese Einträge mit den Maßnahmen verknüpft, die sie belegen.
Fünf Fragen vor dem Einsatz
Stellen Sie diese Fragen, bevor ein KI-System in Betrieb geht. Jede Antwort sollte durch die Nachweise in der rechten Spalte belegt sein.
Fünf Fragen vor dem Einsatz
Frage: Welche KI-Systeme und eingebetteten KI-Funktionen gibt es?
Frage: Auf welche Daten kann das System zugreifen oder welche Daten erzeugt es?
Frage: Was kann das Modell veranlassen, dass ein anderes System tut?
Frage: Wie würden Sie Missbrauch oder eine Kompromittierung erkennen?
Frage: Welcher Nachweis belegt, dass die Maßnahme wirkt?
Wer handeln sollte und wofür er verantwortlich ist
Wer zuerst handeln sollte und welche Nachweise jede Rolle verantwortet
Rolle: CISO / Security-Lead
Rolle: Produkt und Engineering
Rolle: KI-Governance-Verantwortliche
Rolle: Einkauf
Rolle: Auditor / Compliance
Was die 27090 nicht löst
Die Norm zu überschätzen ist der häufigste Fehler. Seien Sie klar in den Grenzen. Sie zertifiziert keine Organisation. Sie begründet keine Konformitätsvermutung nach dem AI Act: Die Vermutung nach Artikel 40 hängt von harmonisierten Normen ab, die im Amtsblatt veröffentlicht wurden. Sie ersetzt weder die ISO/IEC 27001 noch die 27002 oder die 42001. Sie liefert keinen vollständigen Maßnahmenkatalog für Agenten und Werkzeugmissbrauch. Sie entbindet nicht von einer systemspezifischen Risikobewertung und einer dokumentierten Entscheidung über das Restrisiko.
Häufige Fragen
Ist die ISO/IEC 27090 veröffentlicht?
Ja. Die ISO führt die ISO/IEC 27090:2026 als veröffentlicht, Ausgabe 1, mit dem Veröffentlichungsmeilenstein 14. Oktober 2026. Entwürfe beschreiben einen Text, der sich danach geändert hat. Prüfen Sie daher die veröffentlichte Fassung, bevor Sie daraus zitieren.
Kann eine Organisation nach ISO/IEC 27090 zertifiziert werden?
Nein. Es handelt sich um eine Leitliniennorm, und für sie existiert kein Zertifizierungsschema. Lassen Sie sich nach ISO/IEC 27001 oder ISO/IEC 42001 zertifizieren und nutzen Sie die 27090 als Referenz, um KI-Bedrohungen innerhalb dieses Geltungsbereichs zu behandeln.
Ersetzt die ISO/IEC 27090 die Maßnahmen der ISO/IEC 27002 für KI-Systeme?
Nein. Die Norm hält fest, dass die klassischen Maßnahmen der Informationssicherheit je nach Risiko weiterhin gelten. Die 27090 ergänzt sie um die KI-spezifischen Bedrohungen und die Maßnahmen, die diese adressieren.
Deckt die ISO/IEC 27090 Prompt-Injection ab?
Ja. Klausel 6.9 behandelt Prompt-Injection, und ihre Definition umfasst Inhalte, die in eine Anweisung eingebettet werden. Damit ist die indirekte Injection über Dokumente, E-Mails und Webseiten erfasst. Klausel 6.10 behandelt Ausgaben, die eine Injection-Nutzlast enthalten.
Hilft die ISO/IEC 27090 bei der Einhaltung des AI Act?
Sie ist eine relevante Orientierung für die Cybersicherheitsanforderungen von Artikel 15 an Hochrisiko-KI-Systeme. Sie ist keine harmonisierte Norm, daher begründet ihre Anwendung allein noch keine Konformitätsvermutung nach dem AI Act.
Wann gelten die Pflichten des AI Act für Hochrisiko-KI-Systeme?
Nach der Verordnung (EU) 2026/1744 gelten die Pflichten für Hochrisiko-Systeme nach Anhang III ab dem 2. Dezember 2027, die nach Anhang I ab dem 2. August 2028. Die Transparenzpflichten nach Artikel 50 gelten seit dem 2. August 2026.
Ist die ISO/IEC 27090 in der Schweiz relevant?
Ja. Der EDÖB hat erklärt, dass das revidierte Datenschutzgesetz (revDSG) unmittelbar auf KI-gestützte Bearbeitungen personenbezogener Daten anwendbar ist. Die Hinweise der Norm zu Angriffen auf die Privatsphäre unterstützen die Pflichten zur Datensicherheit und zur Datenschutz-Folgenabschätzung. Schweizer Unternehmen mit Kunden in der EU unterliegen zudem dem AI Act und dem CRA.
Worin unterscheidet sich die ISO/IEC 27090 von der ISO/IEC 42001?
Die ISO/IEC 42001 legt Anforderungen fest, um KI in der gesamten Organisation verantwortungsvoll zu steuern, und sie ist zertifizierbar. Die ISO/IEC 27090 geht tiefer auf die Sicherheitsbedrohungen von KI-Systemen ein und darauf, wie man sie erkennt und reduziert. Die meisten Organisationen werden beide nutzen.
Behandelt die Norm agentische KI?
Teilweise. Sie wendet Zero Trust auf Agentenoperationen an und empfiehlt das Least-Privilege-Prinzip für das Modell. Für Werkzeugmissbrauch und Vertrauen zwischen Agenten ergänzen Sie die OWASP Top 10 für LLM und den MITRE-ATLAS-Katalog.
Wie wir diese Norm in der Schulung einsetzen
In unseren Sitzungen zu KI-Sicherheit und ISO/IEC 42001 bitten wir Teams, eine reale KI-Funktion mitzubringen. Wir erfassen ihre Datenquellen, das Modell bzw. den Anbieter, die Werkzeuge, die menschlichen Freigaben, die Protokolle und die Fehlerszenarien. Die häufigste Lücke ist nicht eine fehlende technische Maßnahme. Es ist eine KI-Funktion ohne Owner, die in ein bestehendes Geschäftssystem eingebettet ist.
Wo Sie sich danach weiterbilden können
Security- und SOC-Teams. Die Schulung Lead AI Risk Manager behandelt die Identifikation und Behandlung von KI-Risiken mit dem risikobasierten Ansatz, den die 27090 verlangt. Alexis Hirschhorn ist einer der Trainer; sein Trainerprofil finden Sie hier.
Verantwortliche für Managementsysteme. Die Schulung ISO/IEC 42001 Lead Implementer behandelt das KI-Managementsystem, und die Schulung ISO/IEC 27001 Lead Implementer behandelt das ISMS, in das die KI-Bedrohungen einfließen.
Der Hub KI-Governance zeigt den gesamten Weiterbildungspfad.
Quellen und Prüfung
Status, Struktur und Geltungsbereich der Norm: Katalog der ISO zur ISO/IEC 27090:2026 und die Erläuterung der ISO. Klauselstruktur und Definitionen: öffentliche Vorschau der Norm, soweit zulässig. Artikel 15 des AI Act: Verordnung (EU) 2024/1689 und der Dienst AI Act Service Desk der Europäischen Kommission. Zeitplan des AI Act: Verordnung (EU) 2026/1744 im Amtsblatt. Vorfälle: die oben verlinkten Quellen mit ihren Veröffentlichungsdaten. Zuordnungen zu Rahmenwerken (NIST AI 100-2e2025, OWASP Top 10 für LLM 2025, MITRE ATLAS) sind unsere Auslegung und sollten anhand der aktuellen Versionen geprüft werden.
Dieser Artikel ist eine Planungszusammenfassung. Der volle Normtext ist kostenpflichtig. Prüfen Sie konkrete Klauselanforderungen gegen die veröffentlichte Fassung, bevor Sie sich darauf verlassen.
