ISO 27001 und KI: KI-Systeme sauber ins ISMS aufnehmen

Ja. ISO/IEC 27001 schreibt keine Technologie vor, sondern einen Prozess. Wer KI-Werkzeuge einsetzt, behandelt sie wie jeden anderen Wert im ISMS: erfassen, Risiko beurteilen, Maßnahmen festlegen, Wirksamkeit prüfen. Neu ist nicht die Methode, neu sind die Fragen, die Auditoren stellen.

Ein Informationssicherheits-Managementsystem (ISMS) ist das dokumentierte Zusammenspiel aus Leitlinie, Rollen, Risikobeurteilung und Maßnahmen, mit dem eine Organisation Informationssicherheit steuert. ISO/IEC 27001 legt die Anforderungen an dieses System fest und ist zertifizierbar.

Die aktuelle Fassung ISO/IEC 27001:2022 ordnet die Maßnahmen im Anhang A neu: 93 Controls in vier Themen (organisatorisch A.5, personenbezogen A.6, physisch A.7, technologisch A.8) statt 114 Controls in 14 Abschnitten. Mehrere der neuen Controls passen direkt auf KI-Nutzung, etwa Informationssicherheit für Cloud-Dienste (A.5.23), Verhinderung von Datenlecks (A.8.12) und Informationen über die Bedrohungslage (A.5.7).

Die Umstellung ist abgeschlossen: Die Übergangsfrist endete im Oktober 2025, nicht umgestellte Zertifikate nach der Fassung 2013 sind ausgelaufen (Übersicht der Anhang-A-Controls). Wer in Unterlagen noch Nummern wie A.9.2.1 oder A.16.1.1 führt, arbeitet mit einer Zuordnung, die im Audit nicht mehr passt.

Für KI gibt es kein eigenes Control. Relevant sind die Maßnahmen, die ohnehin für Anwendungen, Dienstleister und Daten gelten. Die folgende Zuordnung deckt die Punkte ab, die im Audit zu KI-Systemen tatsächlich zur Sprache kommen.

Zwei häufige Verwechslungen lohnen den zweiten Blick. Erstens: Die Risikobeurteilung ist kein Anhang-A-Control, sondern Anforderung der Abschnitte 6.1.2 (Verfahren) und 8.2 (Durchführung). A.5.2 regelt etwas anderes, nämlich Rollen und Verantwortlichkeiten. Zweitens: Der Anhang A ist eine Referenzliste. Welche Controls Sie anwenden und welche nicht, begründen Sie in der Erklärung zur Anwendbarkeit nach Abschnitt 6.1.3.

Die Control-Titel oben sind sinngemäß übersetzt; verbindlich ist der Normtext. Für die Verbindung zu Datenschutzpflichten hilft die Checkliste für Auftragsverarbeitungsverträge mit KI-Anbietern.

Mit derselben Methode wie bei jedem anderen Wert: Risiken identifizieren, analysieren, bewerten, behandeln und das Ergebnis dokumentieren. Neu ist nur der Katalog der Ereignisse, die Sie betrachten. Erfundene Eintrittswahrscheinlichkeiten helfen dabei nicht; nachvollziehbare Begründungen schon.

Diese sechs Risiken decken den Großteil der Praxis ab:

1. Vertrauliche Inhalte im Prompt. Beschäftigte fügen Verträge, Personaldaten oder Quelltext in ein Werkzeug ein, das dafür nicht freigegeben ist. Maßnahmen: Klassifizierung, klare Nutzungsregeln, Freigabe von Modellen und Datenquellen je Team, Schutz vor Datenlecks.
2. Indirekte Prompt Injection. Anweisungen stecken in Dokumenten, E-Mails oder Webseiten, die das System verarbeitet. Maßnahmen: Rechte der angebundenen Werkzeuge begrenzen, Ausgaben prüfen, kritische Aktionen bestätigen lassen. Hintergrund im Artikel zu Prompt Injection und LLM-Sicherheit.
3. Falsche Ausgaben in Entscheidungen. Eine plausible, aber falsche Antwort landet im Angebot oder im Prüfbericht. Maßnahmen: Quellenbezug, Vier-Augen-Prinzip für externe Wirkung, Stichproben.
4. Zu weite Berechtigungen auf Wissensspeicher. Die Suche findet Inhalte, die die anfragende Person im Quellsystem nie sehen dürfte. Maßnahmen: Rechte des Quellsystems spiegeln, Prüfintervall für Freigaben.
5. Nicht freigegebene Werkzeuge. Private Konten und Browser-Erweiterungen entziehen sich jeder Kontrolle. Maßnahmen: Angebot schaffen, Nutzung erfassen, Regeln durchsetzen. Vorgehen im Artikel zu Schatten-KI im Unternehmen.
6. Abhängigkeit und Ausfall. Ein Modell wird abgekündigt, ein Anbieter ändert Bedingungen oder fällt aus. Maßnahmen: Ausweichmodell benennen, Ausstieg und Datenrückgabe regeln, Lieferantenleistung überwachen.

Halten Sie zu jedem Risiko fest, welche Maßnahmen greifen und welches Restrisiko die Leitung annimmt. Genau diese Verbindung aus Risiko, Maßnahme und Entscheidung prüft ein Auditor.

Diese Frage beantwortet nicht das Produkt, sondern Ihre Klassifizierung. Legen Sie je Klasse fest, welches System, welches Betriebsmodell und welche Modelle zulässig sind, und schreiben Sie die Regel in die Nutzungsrichtlinie.

Der Serverstandort ist dabei ein Kriterium unter mehreren. ISO/IEC 27001 verlangt keinen bestimmten Standort, sondern eine begründete, dokumentierte Entscheidung. Auch die DSGVO erlaubt Übermittlungen in Drittländer, wenn eine Transfergrundlage vorliegt. Dokumentieren Sie deshalb Standort, Datenflüsse und Drittlandbezug statt eines pauschalen Versprechens.

Wer bekommt welche Rechte?

Bilden Sie die Rollen ab, die eine KI-Plattform tatsächlich kennt, und halten Sie sie im ISMS fest:

• Nutzer: arbeitet in freigegebenen Bereichen, sieht nur eigene Verläufe und geteilte Inhalte.
• Team-Verantwortliche: geben Modelle, Datenquellen und Vorlagen für ihr Team frei und verwalten Mitgliedschaften.
• Plattform-Administration: verwaltet Organisation, Anbindungen, Zugangsdaten und Kostensteuerung.
• Prüfende Rollen: Informationssicherheit und Datenschutz sehen Protokolle, ohne fachlich mitzuarbeiten.

Ergänzen Sie zwei Angaben, nach denen regelmäßig gefragt wird: Wie kommen Rechte weg, wenn jemand das Team wechselt oder das Unternehmen verlässt, und in welchem Intervall werden Berechtigungen überprüft. Für die Anmeldung selbst ist Single Sign-On mit dem zentralen Verzeichnis der kürzeste Weg zu belastbaren Nachweisen.

Was protokollieren Sie?

Sinnvoll sind Anmeldungen, Rechteänderungen, Freigaben von Modellen und Datenquellen, Zugriffe auf Wissensspeicher und administrative Eingriffe. Legen Sie Aufbewahrungsdauer und Auswertungszweck schriftlich fest. Personenbezogene Auswertungen sind in Betrieben mit Betriebsrat mitbestimmungspflichtig; die Grenzen gehören in eine Betriebsvereinbarung zur KI-Nutzung.

Wie sieht ein Vorfallplan für KI aus?

Sie brauchen keinen eigenen Prozess, sondern Ergänzungen im bestehenden. Nehmen Sie diese Fälle auf:

• Vertrauliche Daten in einem nicht freigegebenen Werkzeug
• Prompt Injection mit Datenabfluss oder ausgelöster Aktion
• Falsch vergebene Berechtigungen auf einen Wissensspeicher
• Sicherheitsvorfall oder Ausfall beim Modell- oder Plattformanbieter
• Schädigende Ausgabe, die ein Kunde oder eine Behörde bemerkt

Je Fall gehören Meldeweg, Sofortmaßnahme, Beweissicherung und Nachbereitung dazu. Üben Sie den Ablauf einmal im Jahr gemeinsam mit den Fachbereichen.

Die Fragen sind selten überraschend. Überraschend ist meist nur, wie schnell der Nachweis fehlt. Bereiten Sie zu jeder Frage ein Dokument vor, nicht eine Erklärung:

1. Welche KI-Systeme nutzen Sie? Nachweis: vollständiges Inventar mit Stand und verantwortlicher Person.
2. Wo werden die Daten verarbeitet? Nachweis: Betriebsmodell, Standorte, Datenflüsse, Bewertung des Drittlandbezugs.
3. Welche Verträge liegen vor? Nachweis: Auftragsverarbeitungsverträge, Liste der Unterauftragnehmer, Regelungen zur Nutzung der Daten für Training.
4. Wer hat Zugriff? Nachweis: Rollenkonzept, Rechteliste, Nachweis über Entzug bei Austritt.
5. Welche Daten fließen in das System? Nachweis: Klassifizierung und die Regel je Klasse.
6. Wo ist die Risikobeurteilung? Nachweis: Beurteilung je System nach Abschnitt 6.1.2, mit Maßnahmen und akzeptiertem Restrisiko.
7. Wie erkennen und behandeln Sie Vorfälle? Nachweis: ergänzter Vorfallplan, Protokolle, Bericht einer Übung.
8. Wie werden Beschäftigte eingewiesen? Nachweis: Nutzungsrichtlinie, Schulungsübersicht mit Datum und Inhalt.

Findet der Auditor eine Abweichung, wird das Zertifikat nicht automatisch ausgesetzt. Üblich sind Korrekturmaßnahmen innerhalb einer Frist; bei schwerwiegenden Abweichungen kann die Zertifizierungsstelle die Zertifizierung verweigern oder aussetzen. Klären Sie Fristen und Vorgehen früh mit Ihrer Zertifizierungsstelle, nicht erst im Abschlussgespräch.

Beides, wenn KI für Ihr Geschäft zentral wird. ISO/IEC 27001 schützt Informationen. ISO/IEC 42001:2023 beschreibt dagegen ein KI-Managementsystem: Leitlinie für den Umgang mit KI, Verantwortlichkeiten, Bewertung der Auswirkungen von KI-Systemen, Steuerung über den Lebenszyklus, Umgang mit Daten und Anbietern sowie Aufsicht durch Menschen.

Beide Normen folgen derselben Grundstruktur für Managementsysteme. Risikoverfahren, interne Audits, Managementbewertung und Dokumentenlenkung lassen sich gemeinsam betreiben; wer ein ISMS hat, setzt ein KI-Managementsystem darauf auf, statt es daneben zu bauen. Zertifiziert wird nach ISO/IEC 42001 durch unabhängige Prüfstellen, große Anbieter lassen ihre KI-Dienste bereits danach auditieren (Beispiel Microsoft).

Wichtig für die Erwartungshaltung: Eine Zertifizierung nach ISO/IEC 42001 ersetzt keine Pflicht aus der KI-Verordnung. Sie erleichtert aber Nachweise gegenüber Kunden und Aufsicht, weil Verantwortlichkeiten, Bewertungen und Kontrollen bereits geordnet vorliegen. Den regulatorischen Rahmen dazu erklärt der Compliance-Leitfaden zu DSGVO und KI-Verordnung.

Wann lohnt sich der Schritt? Wenn Sie KI-Funktionen selbst anbieten oder erkennbar in Produkte einbauen, wenn Kunden in Ausschreibungen danach fragen, oder wenn KI in regulierten Prozessen mitentscheidet. Für den reinen Einsatz freigegebener Werkzeuge genügt in der Regel ein sauber erweitertes ISMS.

Ein großer Teil der Audit-Arbeit hängt an der Frage, wie viele Werkzeuge Sie überhaupt nachweisen müssen. Eine zentrale Plattform reduziert die Zahl der Verträge, Rollenkonzepte und Protokollquellen auf eine überschaubare Menge.

Plotdesk verbindet eine KI-Plattform mit einem Umsetzungsteam für den Mittelstand. Für das ISMS sind vor allem diese Punkte belegbar: Betrieb als dedizierte Instanz in der EU oder im eigenen Tenant mit DSGVO-konformem Auftragsverarbeitungsvertrag, Anmeldung über Single Sign-On, Rollen mit mehr als 40 Berechtigungen, Protokollierung von Aktionen, Freigabe von Modellen und Datenquellen je Team aus mehr als 100 Modellvarianten von zehn Provider-Typen sowie Nutzungs- und Kostenauswertungen je Bereich. Anbindungen an ERP, Fileserver oder Ticketsysteme laufen über Plotdesk Connect und werden damit selbst zu dokumentierbaren Schnittstellen.

Für die Zuordnung im Anhang A heißt das konkret: Das Inventar (A.5.9) führt eine Instanz statt zwölf Einzelabos, die Zugriffscontrols (A.5.15 bis A.5.18) hängen am zentralen Verzeichnis, die Lieferantencontrols (A.5.19 bis A.5.23) betreffen einen Vertrag mit bekannten Unterauftragnehmern, und die Protokollierung (A.8.15) kommt aus einer Quelle.

KI bringt kein neues Regelwerk in Ihr ISMS, sondern neue Werte, neue Lieferanten und ein paar zusätzliche Vorfallarten. Wer die Zuordnung auf die Fassung 2022 umstellt, das Inventar pflegt und die Risikobeurteilung je System dokumentiert, hat den größten Teil erledigt.

Der zweite Schritt ist eine Entscheidung, keine Pflicht: Wird KI für Ihr Geschäft zentral, ist ISO/IEC 42001 der geordnete Weg, Verantwortung und Aufsicht über KI-Systeme nachzuweisen. Beginnen Sie mit dem Inventar. Alles Weitere ergibt sich daraus.