ISO 27090 erklärt für KI-Sicherheitsteams

ISO/IEC 27090:2026 ist eine internationale Norm mit Leitlinien zu Sicherheitsbedrohungen und Kompromittierungen, die Systeme der künstlichen Intelligenz betreffen. Sie wurde am 14. Oktober 2026 veröffentlicht und beschreibt, wie Organisationen diese Bedrohungen über den gesamten KI-Lebenszyklus verstehen, erkennen und mindern können. Ihr offizieller Titel lautet Cybersecurity — Artificial intelligence (AI) — Addressing security threats and compromises to AI systems. ISO-Normeintrag

Für ein Sicherheitsteam ist die praktische Frage einfach: Was könnte ein Angreifer an einem KI-System verändern, daraus entwenden oder es tun lassen, und was würde den daraus entstehenden Schaden begrenzen?

Dieser Leitfaden erklärt den Anwendungsbereich von ISO 27090, die wichtigsten Bedrohungen für KI-Sicherheit, das Verhältnis zu ISO 27001 und ISO 42001 sowie einen praktischen Weg, die Leitlinien in Sicherheitsarbeit mit Verantwortlichen, Schutzmaßnahmen und Nachweisen zu übersetzen. Die zugrunde liegende Recherche wurde am 18. Oktober 2026 geprüft.

Was ISO 27090 abdeckt

ISO 27090 konzentriert sich auf den Schutz von KI-Systemen. Ihr Gegenstand reicht über generative KI, große Sprachmodelle und Chatbots hinaus und umfasst KI-Systeme im Allgemeinen. ISO-Erläuterung zu ISO 27090

Die veröffentlichte Norm verbindet etablierte Praktiken der Informationssicherheit mit KI-spezifischen Bedrohungen. Ihre Inhalte behandeln Governance, Lieferkettensicherheit, Bedrohungsmodellierung und Red Teaming, gefolgt von Arten der Kompromittierung wie Poisoning, Evasion, Offenlegung von Informationen und Prompt Injection. Außerdem betrachtet sie, wie Gegenmaßnahmen zusammenwirken und im Zeitverlauf wirksam bleiben. Veröffentlichte Leseprobe von ISO/IEC 27090

Der Anwendungsbereich umfasst Organisationen jeder Größe, die KI entwickeln oder nutzen, darunter Unternehmen, Behörden und gemeinnützige Organisationen. Wer einen KI-Dienst eines Drittanbieters einkauft, gehört also weiterhin zur Zielgruppe. IEC-Normeintrag

Ein guter Ausgangspunkt ist eine gemeinsame Prüfung mit Sicherheit, Entwicklung, Datenteam, Einkauf und fachlich verantwortlicher Person. Jede Seite sollte erklären können, welchen Teil des Systems sie steuert und auf welche Entscheidungen anderer sie angewiesen ist.

Warum KI-Systeme zusätzliche Sicherheitsanalysen brauchen

Eine KI-Anwendung verbindet mehrere Elemente, die jeweils eine eigene Prüfung verdienen: Software, Daten, Modelldateien oder -dienste, Anweisungen, Nutzende und nachgelagerte Aktionen.

Nehmen Sie einen Dokumentenassistenten, der mit einer internen Wissensdatenbank verbunden ist. Eine herkömmliche Prüfung betrachtet vielleicht Authentifizierung, Verschlüsselung und Softwareschwachstellen. Eine KI-Sicherheitsprüfung sollte zusätzlich fragen, was passiert, wenn ein abgerufenes Dokument versucht, die Anweisungen des Assistenten zu ändern, ob Nutzende Inhalte außerhalb ihrer Berechtigungen abrufen können und welche Aktionen generierte Ausgaben auslösen können.

Diese Fragen wiegen schwerer, wenn ein Assistent Datensätze ändern oder externe Werkzeuge aufrufen kann. Eine falsche Antwort und eine unbefugte Aktion haben unterschiedliche Folgen und erfordern unterschiedliche Schutzmaßnahmen.

Klären Sie für Ihre erste Prüfung drei Fragen:

• Was kann das System beeinflussen? Berücksichtigen Sie Trainingsdaten, abgerufene Inhalte, Prompts, Anbieter und Modellaktualisierungen.
• Was kann das System verlassen? Berücksichtigen Sie Antworten, Logs, Exporte und Modell-Assets.
• Was kann das System verändern? Berücksichtigen Sie Dateien, Tickets, Konten, Transaktionen und andere verbundene Dienste.

Dies ist eine praktische Methode zur Abgrenzung für die folgenden Beispiele, keine Wiedergabe der Abschnitte der Norm.

Bedrohungen für KI-Sicherheit, die Sie kennen sollten

Die folgenden Erläuterungen verwenden die Terminologie des NIST zu Adversarial Machine Learning und die Leitlinien von OWASP für LLM-Anwendungen. Die Szenarien dienen der Veranschaulichung. NIST-Taxonomie zu Adversarial Machine Learning OWASP-Leitlinien zu Prompt Injection OWASP-Leitlinien zur Ausgabeverarbeitung

Halten Sie die Unterscheidungen bei der Risikobeurteilung klar. Ein schädliches Dokument, das eine Retrieval-Augmented-Generation-Anwendung (RAG) abruft, ist nicht automatisch Poisoning von Trainingsdaten: Der Abruf allein verändert keine Modellgewichte. Er kann die Anwendung stattdessen indirekter Prompt Injection aussetzen.

Für LLM-Sicherheit sind stärkere Prompts allein eine unvollständige Kontrollstrategie. OWASP empfiehlt Schutzmaßnahmen wie eingeschränkte Berechtigungen und Freigaben für sensible Aktionen, während das NCSC betont, Prompt Injection über Systemdesign und Betrieb als fortbestehendes Risiko zu steuern. OWASP-Leitlinien zu Prompt Injection NCSC-Leitlinien zum Risiko Prompt Injection

ISO 27090 im Vergleich zu ISO 27001 und ISO 42001

Diese Normen unterstützen unterschiedliche Teile der Sicherheits- und KI-Governance-Arbeit einer Organisation.

Die Unterscheidungen folgen den Beschreibungen der Herausgeber zu ISO 27001, ISO 27002 und ISO 42001.

Für ein Team, das bereits ein ISMS betreibt, ist es praktisch, bestehende Aufzeichnungen zu erweitern. Nehmen Sie relevante KI-Systeme in das Asset-Inventar auf, bewerten Sie ihre Angriffspfade, benennen Sie Verantwortliche für die Behandlung und verknüpfen Sie unterstützende Nachweise. Hintergrund zur Organisation dieser Arbeit bietet die ISO-27001-Checkliste.

Eine praktische Checkliste zur Umsetzung von ISO 27090

Die folgenden Schritte sind ein Umsetzungsansatz, der aus den Inhalten der Norm und öffentlich verfügbaren Leitlinien zu sicherer KI abgeleitet ist. Sie sind weder eine offizielle ISO-Checkliste noch eine Aufzählung verbindlicher Abschnitte.

1. System und Verantwortliche festlegen

Wählen Sie einen KI-Anwendungsfall mit klarem geschäftlichem Zweck. Halten Sie die verantwortliche Person, die Nutzenden, den Modellanbieter, das Hosting und die verbundenen Dienste fest.

Ziehen Sie dann die Grenze der Prüfung. Schließen Sie die Anwendung und ihre Abhängigkeiten ein, nicht nur den Modell-Endpunkt. Ein kundenseitiger Assistent mit Werkzeugzugriff braucht eine andere Bewertung als ein interner Textzusammenfasser ohne Berechtigung zu handeln.

Nützliches Ergebnis: ein Systemeintrag mit Zweck, Grenzen, Abhängigkeiten, erlaubten Aktionen und verantwortlicher Person.

2. Herkunft von Daten und Modellen nachvollziehen

Halten Sie fest, woher Datensätze und Modellartefakte stammen, wer sie ändern kann und welche Versionen im Einsatz sind. Berücksichtigen Sie Fine-Tuning-Daten, Abrufsammlungen, Prompts und Feedbackkanäle, die für das System relevant sind.

Die NCSC-Leitlinien zur Entwicklung empfehlen, KI-Assets und ihre Herkunft zu verfolgen, sie zu schützen und die Informationen aufzubewahren, die zur Wiederherstellung vertrauenswürdiger Versionen nötig sind. NCSC-Leitlinien zur sicheren KI-Entwicklung

Fragen Sie bei einem eingekauften Modell den Anbieter, welche Verantwortlichkeiten er übernimmt und welche Informationen er bereitstellt, wenn sich Modelle oder Dienste ändern.

Nützliches Ergebnis: ein versioniertes Inventar mit Quellen, Zugriffsregeln, Änderungshistorie und Verantwortlichkeiten der Anbieter.

3. Den tatsächlichen Ablauf mit einem Bedrohungsmodell prüfen

Betrachten Sie das System aus der Perspektive eines Angreifers. Bestimmen Sie Einstiegspunkte, schützenswerte Assets, Berechtigungen und die Folgen einer erfolgreichen Kompromittierung. Die NCSC-Leitlinien zum sicheren Design empfehlen Bedrohungsmodellierung sowie Aufmerksamkeit für Drittanbieterkomponenten und minimale Berechtigungen. NCSC-Leitlinien zum sicheren KI-Design

Formulieren Sie konkrete Szenarien. „KI-Risiko“ ist zu allgemein, um eine sinnvolle Maßnahme auszulösen. „Ein von einer externen Partei hochgeladenes Dokument bringt den Assistenten dazu, eine gesperrte Nachweisdatei anzufordern“ gibt einem Team etwas Konkretes zur Analyse.

Priorisieren Sie nach Exposition und möglichem Schaden. Halten Sie fest, wer ein verbleibendes Risiko akzeptiert und wann diese Entscheidung erneut geprüft werden soll.

Nützliches Ergebnis: ein kurzes Risikoregister, das Angriffsszenarien mit Assets, Folgen, Schutzmaßnahmen und Verantwortlichen verknüpft.

4. Schutzmaßnahmen an den relevanten Grenzen setzen

Wählen Sie Maßnahmen für das Szenario, das Sie behandeln. Für Modell-Assets kann das geschützte Speicherung, Zugriffsbeschränkungen und Integritätsprüfungen bedeuten. Für bereitgestellte Dienste kommen Authentifizierung, Trennung von Umgebungen und Maßnahmen gegen unbefugten Zugriff oder Datenabfluss in Betracht. Das sind Themen der NCSC-Leitlinien zur Bereitstellung. NCSC-Leitlinien zur sicheren KI-Bereitstellung

Validieren und kodieren Sie generierte Ausgaben für ihr Ziel, bevor ein anderes System darauf reagiert. Die OWASP-Leitlinien zur Ausgabeverarbeitung erklären, warum Modellausgaben keine Befugnis erlangen sollten, nur weil sie vom Modell stammen. OWASP-Leitlinien zur Ausgabeverarbeitung

Nützliches Ergebnis: ein Maßnahmeneintrag, der die geschützte Grenze, die verantwortliche Person und den Nachweis zur Prüfung nennt.

5. Die vollständige Anwendung testen

Gestalten Sie Tests entlang der Folgen, die Sie im Bedrohungsmodell ermittelt haben. Verwenden Sie für einen RAG-Assistenten präparierte Dokumente und Nutzende mit unterschiedlichen Berechtigungen. Testen Sie bei einem Agenten, was passiert, wenn abgerufene Inhalte ihn auffordern, seine erlaubten Aktionen zu überschreiten.

Legen Sie das erwartete Ergebnis vor dem Test fest. Ein Beispiel: Die Anwendung muss eine Anfrage nach einer gesperrten Datei ablehnen, selbst wenn das Modell versucht, diese Anfrage zu stellen.

Halten Sie Anwendungskonfiguration, Modellversion, Testeingaben, Ergebnis und etwaige Behebung fest. Wählen Sie Testdaten, die keine echten vertraulichen Informationen unnötig offenlegen.

Nützliches Ergebnis: wiederholbare Sicherheitstests, die mit konkreten Risiken und Freigabeentscheidungen verknüpft sind.

6. Änderungen überwachen und Reaktion vorbereiten

Prüfen Sie die Auswirkungen von Modell-, Daten- und Prompt-Aktualisierungen. Überwachen Sie relevante Ein- und Ausgaben und schützen Sie dabei sensible Informationen in Logs. Die NCSC-Leitlinien zum Betrieb heben Verhaltensüberwachung und die Sicherheitsfolgen von Änderungen während des gesamten Betriebs hervor. NCSC-Leitlinien zum sicheren KI-Betrieb

Legen Sie vorab fest, wer ein Werkzeug deaktivieren, ein Zugangsdatum widerrufen, eine Integration isolieren oder ein Release zurücknehmen darf. Definieren Sie Auslöser für eine erneute Prüfung, etwa einen neuen Anbieter, erweiterte Berechtigungen, eine wesentliche Modellaktualisierung oder einen Sicherheitsvorfall.

Nützliches Ergebnis: Zuständigkeiten für die Überwachung, Kriterien für die Prüfung von Änderungen, ein Verfahren zur Vorfallsreaktion und ein getesteter Wiederherstellungsweg.

KI-Sicherheitsrisiken in Nachweise übersetzen

Die folgende Tabelle ist eine vorgeschlagene Arbeitsvorlage. Ihre Nachweisbeispiele sind praktische Empfehlungen, keine Liste von Dokumenten, die ISO 27090 vorschreibt.

Stellen Sie sich zum Beispiel ein Sicherheitsteam vor, das mit einem Assistenten Kundennachweise zusammenfasst. Ein Dokument eines Anbieters enthält die Anweisung, die Nachweise an eine externe Adresse hochzuladen.

Der Test des Teams sollte der versuchten Aktion durch die Anwendung folgen. Hat der Assistent ein Werkzeug, das Dateien hochladen kann? Setzt dieses Werkzeug die Berechtigungen der Nutzenden durch? Sind Ziele eingeschränkt? Muss eine verantwortliche Person die Übertragung freigeben?

Ein nützlicher Prüfeintrag würde das Szenario, die Grenze, die die Übertragung verhindert, das Testergebnis und die Person nennen, die das verbleibende Risiko akzeptiert hat. Ändert sich das System, zeigt dieser Eintrag der nächsten prüfenden Person, was erneut geprüft werden muss.

So erhält eine Bewertung mehr Substanz als die Behauptung, das System nutze „verantwortungsvolle KI“. Die Sicherheitsentscheidung wird mit etwas verbunden, das eine andere Person prüfen kann. Mehr zur Organisation unterstützender Unterlagen lesen Sie unter Audit Readiness strukturieren.

Zertifizierung und Anforderungen von ISO 27090

ISO 27090 bietet Sicherheitsleitlinien, keine Zertifizierungsanforderungen an ein Managementsystem. Die Erläuterung der ISO grenzt ihren Zweck von den AIMS-Anforderungen in ISO 42001 ab. ISO-Erläuterung zu ISO 27090

Legen Sie zuerst fest, welche Zusicherung Sie brauchen: eine Sicherheitsprüfung, eine Antwort auf Kundenanfragen zur Sicherheit, eine interne Gap-Analyse oder eine Zertifizierung nach einer anwendbaren Managementsystemnorm.

Bitten Sie alle Anbieter einer Bewertung, Umfang, Kriterien und Prüfschema zu benennen. Das macht das Ergebnis leichter interpretierbar und verhindert, dass eine Prüfung von KI-Sicherheitspraktiken mit der Zertifizierung eines Managementsystems verwechselt wird.

Beschaffen Sie für ein Umsetzungsprojekt die veröffentlichte Norm, gleichen Sie die Leitlinien mit Ihren eigenen Systemen ab und halten Sie fest, warum bestimmte Schutzmaßnahmen angemessen sind. Die Beispiele in diesem Artikel bieten eine Ausgangsstruktur für diese Arbeit.

ISO 27090 und die KI-Verordnung der EU

Die Anwendung einer internationalen Norm begründet nicht automatisch die Einhaltung der KI-Verordnung der EU (AI Act). Artikel 40 knüpft eine Konformitätsvermutung an harmonisierte Normen, deren Fundstellen im Amtsblatt der EU veröffentlicht wurden, und nur soweit sie die betreffenden Anforderungen oder Pflichten abdecken. Artikel 40 der KI-Verordnung

Nutzen Sie eine Sicherheitsprüfung nach ISO 27090 als einen Baustein einer gesondert abgegrenzten Compliance-Bewertung. Halten Sie die geprüfte rechtliche Pflicht, die stützenden Nachweise und verbleibende Lücken fest.

Häufige Fragen zu ISO 27090

Wann wurde ISO 27090 veröffentlicht?

Die erste Ausgabe, ISO/IEC 27090:2026, wurde am 14. Oktober 2026 veröffentlicht. Prüfen Sie den aktuellen Eintrag des Herausgebers, wenn ältere Quellen auf einen Entwurf oder ein früheres Jahr verweisen. IEC-Normeintrag

Deckt ISO 27090 generative KI und LLM-Sicherheit ab?

Die veröffentlichten Inhalte umfassen Prompt Injection und sensible Modellausgaben und sind damit für die Sicherheit generativer KI relevant. Der Anwendungsbereich schließt auch andere KI-Systeme ein. Veröffentlichte Leseprobe von ISO/IEC 27090 ISO-Erläuterung zu ISO 27090

Kann ein Unternehmen, das KI von Drittanbietern nutzt, die Norm anwenden?

Ja. Die genannte Zielgruppe umfasst Organisationen, die KI nutzen, ebenso wie Organisationen, die sie entwickeln. Beginnen Sie mit den Risiken und Verantwortlichkeiten in Ihrem Einflussbereich und klären Sie, was Sie über Ihre Anbieter wissen müssen. IEC-Normeintrag

Bedeutet eine ISO-27001-Zertifizierung, dass ein KI-System sicher ist?

Eine Managementsystem-Zertifizierung garantiert nicht, dass eine einzelne Anwendung jedem Angriff standhält. Nutzen Sie das Managementsystem, um Risikoentscheidungen zu ordnen, und bewerten Sie Design, Konfiguration und Verhalten des KI-Systems selbst. ISO 27090 kann diese Sicherheitsarbeit unterstützen.

Wo erhalte ich ISO 27090 als PDF?

Nutzen Sie den offiziellen ISO-Katalog oder den IEC Webstore für die veröffentlichte Norm und Lizenzoptionen. Achten Sie auf die Bezeichnung ISO/IEC 27090:2026. Ein Artikel oder eine Leseprobe enthält nur einen Teil des Materials.

KI-Sicherheitsarbeit prüfbar machen

Beginnen Sie mit einem folgenreichen KI-Anwendungsfall. Ermitteln Sie, wie er kompromittiert werden könnte, wählen Sie Schutzmaßnahmen für die relevanten Grenzen und legen Sie fest, welche Nachweise zeigen, dass diese Schutzmaßnahmen wirken. Geben Sie jeder Maßnahme eine verantwortliche Person und einen Auslöser für die erneute Prüfung.

Secani verbindet Anforderungen, Risiken, Maßnahmen, Nachweise, Verantwortliche und Prüfentscheidungen in einem gemeinsamen Arbeitsbereich für Sicherheit und Compliance. Sprechen Sie mit Secani darüber, wie Sie Ihre KI-Sicherheitsarbeit so organisieren, dass Teams sehen, was bewertet wurde, was Aufmerksamkeit braucht und wer verantwortlich ist.