Seit Oktober 2026 existiert mit ISO/IEC 27090:2026 eine internationale Norm, die Sicherheitsbedrohungen spezifisch für KI-Systeme beschreibt – über deren gesamten Lebenszyklus, vom Training bis zum laufenden Betrieb. Adressiert sind Organisationen jeder Größe, die KI entwickeln oder einsetzen: Unternehmen, Behörden und Non-Profit-Organisationen. Wer KI-Risiken bisher allein über ein ISMS nach ISO/IEC 27001 abgebildet hat, bekommt damit eine eigene Bedrohungs- und Maßnahmenliste für KI. Und wer annimmt, die Norm zertifiziere irgendetwas, liegt falsch.
ISO/IEC 27090 ist ein Leitfaden, keine Zertifizierungsnorm
Die Einordnung ist der entscheidende Punkt. Herausgekommen ist Edition 1 mit 56 Seiten, verantwortet vom Technischen Komitee ISO/IEC JTC 1/SC 27, Klassifikation ICS 35.030. Der Status lautet „Published", Stage 60.60 – die Norm ist damit formell fertig, aber ausdrücklich gilt: „security guidance, not requirements for an AI management system".
Praktisch heißt das: Es gibt keine Konformitätsprüfung, kein Audit, kein Zertifikat „KI-sicher nach 27090". Wer die Norm umsetzt, dokumentiert damit eine Methodik – nicht einen Prüferfolg. Werbetreibende sollten Formulierungen wie „zertifiziert" oder „verpflichtend" also genau dann hinterfragen, wenn sie in Angeboten auftauchen.
National ist die Norm bereits übernommen: in Großbritannien als BS ISO/IEC 27090:2026 mit Status „Current", zuständiges Komitee IST/33/4, ISBN 978 0 539 24338 3; in den Niederlanden als NEN-ISO/IEC 27090:2026 en. Eine deutsche Übernahme über DIN oder eine Bewertung durch das BSI ist in den vorliegenden Quellen nicht belegt.
Data Poisoning, Model Exfiltration, Prompt Injection: der Bedrohungskatalog
Inhaltlich ist der Katalog breiter, als der erste Eindruck vermuten lässt. Genannt werden Data Poisoning, Model Exfiltration, Evasion Attacks, Membership Inference, Model Inversion, Direct Model Poisoning sowie Angriffe über Ein- und Ausgaben – also auch Prompt Injection und Modellausgaben, die selbst wieder Injections enthalten.
Einige dieser Angriffe sind aus der klassischen IT bekannt, andere sind neu. Data Poisoning bedeutet: Angreifer schieben bösartige oder unerwünschte Daten in die Trainingsdaten und verschieben damit das Verhalten des Modells gezielt in eine Richtung. Model Exfiltration beschreibt die Extraktion eines Modells – teils über Abfragen, die einzeln betrachtet völlig legitim wirken. Als behandelte Kernthemen gelten Data Poisoning und Modelldiebstahl.
Wichtig für die Reichweite: Der Scope ist nicht auf Generative AI oder Chatbots begrenzt. Klassische Machine-Learning-Systeme in der Betrugserkennung, der Bildklassifikation oder der Produktionssteuerung fallen genauso darunter.
Defence in Depth statt Einzelmaßnahme
Der empfohlene Grundansatz ist Defence in Depth – mehrere Schutzschichten übereinander, bei gleichzeitiger Anerkennung, dass sich manche KI-Bedrohungen nur schwer erkennen lassen. Konkret gehören dazu KI-Governance, Zero-Trust-Prinzipien, Software-Engineering-Praktiken, Supply-Chain-Security, Threat Modelling und Red Teaming.
Für die Betriebsphase kommen Logging und Monitoring, der Schutz der Entwicklungsumgebungen, die Erkennung bösartiger Eingaben und die Begrenzung der Modellnutzung hinzu. Ein Detail, das in Sicherheitskonzepten häufig fehlt: Schutzmaßnahmen dürfen nicht isoliert geplant werden. Sie können sich gegenseitig behindern, und sie können über die Zeit an Wirkung verlieren – Modelle und ihre Absicherung degradieren.
Der unterschätzte Punkt: Betriebsdaten werden zu Trainingsdaten
Der praxisnäheste Abschnitt betrifft die Rückkopplung zwischen Betrieb und Training. Daten, die im laufenden Betrieb erhoben werden, fließen später in Updates oder Retraining ein. Sind sie korrumpiert, entstehen Schwachstellen nicht im aktuellen System, sondern in künftigen Versionen – der Angriff wirkt verzögert. Bei kontinuierlich lernenden Systemen werden Betriebseingaben sogar unmittelbar selbst zu Trainingsdaten.
Damit verschiebt sich die Zuständigkeit. Sicherheit endet nicht mit der Freigabe eines Modells, sondern muss die Datenpipelines danach mitprüfen. Wer KI-Betriebsdaten sammelt, ohne deren Herkunft und Historie zu prüfen, betreibt im Zweifel kontinuierliches Poisoning auf eigene Rechnung.
Wie ISO/IEC 27090 neben 27001, 27002 und 42001 steht
Die Abgrenzung ist klar, aber erklärungsbedürftig. ISO/IEC 27001 enthält die Anforderungen an ein Managementsystem für Informationssicherheit, ISO/IEC 27002 die Controls-Guidance dazu. 27090 ergänzt beide um KI-spezifische Bedrohungen, ersetzt sie aber nicht – die etablierten Praktiken bleiben die Grundlage.
Anders gelagert ist ISO/IEC 42001: Diese Norm regelt das organisationale Management von KI insgesamt. 27090 betrachtet ausschließlich Sicherheitsbedrohungen und deren Adressierung – „security is part of responsible AI management, but it is not the whole picture". Als normative Referenzen dienen ISO/IEC 22989 für KI-Terminologie sowie ISO/IEC 23053:2022 als Framework zur Beschreibung von ML-basierten KI-Systemen.
Fazit: Einzuordnen, nicht abzuhaken
ISO/IEC 27090 schließt eine Lücke, die in vielen ISMS-Dokumenten offen geblieben ist: Sie benennt KI-Angriffsvektoren und ordnet ihnen Maßnahmen zu, ohne eine Zertifizierung zu versprechen. Genau darin liegt ihr Wert – und ihre Grenze.
Für Verantwortliche heißt das: Wer die Norm als Nachweis behandelt, hat nichts gewonnen. Wer sie als Prüfliste nutzt, um Trainingsdaten-Herkunft, Modellzugriffe, Eingabevalidierung und Retraining-Pipelines zu bewerten, hat einen belastbaren Rahmen – vorausgesetzt, man liest sie als das, was sie ist: eine Guidance.