ISO 42001 Statement of Applicability (SoA) ist das Pflichtdokument, in dem ein Unternehmen für alle 38 Annex A Controls begründet, ob und wie sie angewendet werden. Wer ein AIMS nach ISO/IEC 42001:2023 aufbauen, auditfähig machen und mit einem ISO-42001-Leitfaden praktisch verbinden will, braucht ein SoA als belastbaren Index für Entscheidungen, Umsetzungsstand und Nachweise.
Das Dokument wird häufig unterschätzt, obwohl es in der Praxis den Kern der Auditfähigkeit bildet. Das SoA übersetzt den Scope Ihres KI-Managementsystems in konkrete Kontrollentscheidungen: Welche Controls gelten immer, welche nur für bestimmte KI-Systeme, welche sind ausgeschlossen und welche Evidenz belegt die Umsetzung? Genau deshalb ist das SoA nicht nur Verwaltung, sondern Steuerungsinstrument.
Was ist ein Statement of Applicability?
Ein Statement of Applicability ist die formale Anwendbarkeitserklärung Ihres KI-Managementsystems. ISO/IEC 42001:2023 verlangt in Clause 6.1.3, dass Organisationen die für ihr AIMS relevanten Controls bestimmen, begründen und dokumentieren. Das SoA ist dafür das zentrale Pflichtdokument.
Der Zweck ist doppelt. Erstens zwingt das SoA dazu, alle 38 Controls aus Annex A einmal vollständig zu prüfen, statt nur offensichtliche Themen wie Risikoanalyse oder Richtlinien zu bearbeiten. Zweitens schafft es Nachvollziehbarkeit für interne Teams, Auditoren, Kunden und Management. Wer später fragt, warum ein bestimmter Kontrollbereich gewählt, ausgeschlossen oder nur teilweise umgesetzt wurde, findet die Antwort im SoA.
Inhaltlich ähnelt das SoA der bekannten Logik aus ISO 27001. Auch dort dient es als Brücke zwischen Risikobewertung, Scope und Kontrollauswahl. Der Unterschied liegt im Gegenstand: ISO 27001 fokussiert Informationssicherheit, ISO 42001 fokussiert KI-Governance. Deshalb behandelt ein ISO-42001-SoA zusätzlich Themen wie Auswirkungen auf Personen und Gruppen, Datenherkunft, Transparenz, menschliche Aufsicht, Monitoring von Bias sowie die Steuerung von KI über den gesamten Lebenszyklus.
Für deutsche Unternehmen ist wichtig: Das SoA ist kein rein akademisches Tabellenwerk. Es verbindet operative Dokumente wie Inventar, Risiko-Register, Impact Assessments, Monitoring, Incident-Logs und Schulungsnachweise. Wer sich parallel mit ISO 42001 Implementierung oder einer ISO 42001 Checkliste befasst, wird feststellen, dass das SoA alle diese Bausteine in einer auditierbaren Übersicht zusammenführt.
Aufbau des SoA
Ein gutes SoA ist knapp, vollständig und belastbar verlinkt. Die Minimalstruktur besteht aus sechs Spalten: Control-ID, Titel, Anwendbar Ja oder Nein, Begründung, Umsetzungsstatus und Verweis auf Dokumentation. Mehr brauchen kleine und mittlere Unternehmen am Anfang oft nicht.
Die Tabellenlogik ist wichtig, weil Auditoren keine Fließtexte durchsuchen wollen. Sie erwarten eine Übersicht, aus der sofort hervorgeht, welche Control-Entscheidung getroffen wurde, auf welcher Begründung sie beruht und welches Dokument als Evidenz dient. Genau deshalb sollte jede Zeile auf reale Artefakte verweisen, nicht auf Absichtserklärungen.
| Control-ID | Titel | Anwendbar | Begründung | Umsetzungsstatus | Verweis auf Dokumentation |
|---|---|---|---|---|---|
| A.5.4 | KI-Risikobewertung | Ja | Für alle KI-Systeme im Scope verpflichtend | Umgesetzt | KI-Risiko-Register |
| A.7.2 | Datenherkunft und Lineage | Ja | Trainings- und Betriebsdaten müssen nachvollziehbar sein | Teilweise umgesetzt | Datenkatalog, Lineage-Diagramm |
| A.8.1 | Erklärbarkeit | Ja | Fachbereiche und Betroffene müssen Ergebnisse nachvollziehen können | Geplant | Erklärbarkeitskonzept |
| A.7.4 | Datenaufbewahrung | Nein | Keine eigenen Trainingsdaten, nur SaaS-Nutzung mit vertraglich geregelter Retention | Delegiert | Anbieterunterlagen, Vertragsanhang |
Beim Umsetzungsstatus reichen in der Praxis vier Zustände: umgesetzt, teilweise umgesetzt, geplant mit Termin oder nicht anwendbar. Kritisch ist dabei die Konsistenz. Ein Control darf nicht im Statusfeld als geplant erscheinen und gleichzeitig ohne Begründung als nicht anwendbar markiert sein.
Zusätzlich empfiehlt sich eine Gruppierung nach den neun Annex-A-Themenbereichen. Damit wird aus der Tabelle nicht nur eine Liste, sondern eine sinnvolle Arbeitsstruktur:
- A.2 Richtlinien zu KI
- A.3 Interne Organisation
- A.4 Ressourcen für KI-Systeme
- A.5 Bewertung von Auswirkungen von KI-Systemen
- A.6 Lebenszyklus von KI-Systemen
- A.7 Daten für KI-Systeme
- A.8 Informationen für interessierte Parteien
- A.9 Nutzung von KI-Systemen
- A.10 Beziehungen zu Dritten und Kunden
Diese Gruppierung hilft besonders dann, wenn Sie die Tiefe der Controls erst noch aufbauen. Für einen vertieften Überblick über Kontrolllogik und typische Kontrollfamilien lohnt sich auch der Beitrag zu ISO 42001 Annex A Controls.
Alle 38 Controls systematisch prüfen
Alle 38 Controls systematisch zu prüfen bedeutet, jede Zeile bewusst gegen Scope, reale KI-Systeme, Risiken, Datenflüsse und Nutzungsformen zu bewerten. Genau hier scheitern viele Erstentwürfe. Teams markieren zu schnell pauschal alles als anwendbar oder schließen Controls ohne tragfähige Begründung aus.
Die bessere Vorgehensweise ist ein fester Prüfraster. Für jedes Control sollten Sie mindestens fünf Fragen beantworten:
- Bezieht sich das Control auf ein KI-System, einen Prozess oder einen Lieferanten im Scope?
- Entsteht aus Nutzung, Entwicklung, Beschaffung oder Betrieb ein reales Risiko, das durch dieses Control adressiert wird?
- Wird das Thema intern gesteuert oder vertraglich an einen Anbieter delegiert?
- Gibt es bereits Evidenz, die die Umsetzung belegt?
- Ändert sich die Entscheidung je nach Systemklasse oder Nutzungskontext?
Ein Control ist nur dann nicht anwendbar, wenn der Scope die zugrunde liegende Aktivität tatsächlich nicht umfasst. Typische legitime Gründe sind zum Beispiel: Es werden keine biometrischen Anwendungen eingesetzt. Es werden keine eigenen Modelle trainiert. Es gibt keine KI-Systeme mit direkter Interaktion gegenüber externen Betroffenen. Oder die betreffende technische Maßnahme liegt vollständig beim Cloud- oder SaaS-Anbieter und wird vertraglich gesteuert.
Nicht zulässig sind schwache Begründungen wie fehlendes Budget, fehlende Zeit, fehlende Zuständigkeit oder die Aussage, dass das Thema aktuell keine Priorität habe. Ein SoA ist keine Wunschliste, sondern eine dokumentierte Managemententscheidung. Gerade im Audit wird schnell sichtbar, ob ein Ausschluss aus dem Scope folgt oder nur ein Umsetzungsdefizit kaschieren soll.
Praktisch bewährt sich die Prüfung entlang der neun Kategorien:
- A.2 bis A.4 prüfen Governance, Rollen, Inventar, Ressourcen und organisatorische Grundlagen.
- A.5 bis A.7 prüfen Auswirkungen, Lebenszyklus, Datenqualität, Datenherkunft und Dokumentation.
- A.8 bis A.10 prüfen Transparenz, Nutzung, menschliche Aufsicht, externe Parteien und Lieferantenbeziehungen.
Die lokale Research-Basis für ISO 42001 zeigt außerdem einen wichtigen Realitätscheck: In den meisten Organisationen sind 90 bis 95 Prozent der Controls zumindest für einzelne Systeme oder Prozesse anwendbar. Wer also überraschend viele Controls mit Nein markiert, sollte den Scope und die Begründungen nochmals kritisch prüfen.
Gerade bei Systemen mit Bezug zu Personen, Entscheidungen oder sensiblen Daten steigt die Relevanz von Controls rund um Risiko, Bias, Erklärbarkeit, Datenqualität und menschliche Aufsicht stark an. Für Unternehmen mit Bezug zu Anhang III des EU AI Act ist diese Nachvollziehbarkeit zusätzlich wertvoll, weil sie sich mit ISO 42001 Audit Vorbereitung und regulatorischen Pflichtnachweisen verzahnen lässt.
SoA erstellen — Schritt für Schritt
Ein SoA lässt sich in fünf klaren Schritten erstellen. Der Prozess ist weniger komplex, als viele Teams denken, wenn Scope, Inventar und Mindestdokumentation bereits vorliegen.
1. Controls listen
Der erste Schritt ist vollständig, nicht kreativ. Übernehmen Sie alle 38 Controls in eine Tabelle. Arbeiten Sie nie mit einer gekürzten Liste, weil Sie sonst das Grundprinzip des SoA verfehlen. Ergänzen Sie die neun Control-Bereiche als Strukturspalte oder Abschnittslogik.
2. Anwendbarkeit prüfen
Der zweite Schritt ist der eigentliche Governance-Test. Prüfen Sie pro Control, ob es aufgrund Ihres Scopes, Ihrer KI-Systeme, Datenquellen, Lieferanten und Einsatzkontexte anwendbar ist. Ausgangspunkt sind Inventar, Systemkarten, Risiko-Register und Prozessbeschreibungen. Wenn Sie diese Grundlage noch nicht sauber haben, zuerst dort nacharbeiten, nicht im SoA improvisieren.
3. Begründung schreiben
Der dritte Schritt ist entscheidend für die Auditqualität. Schreiben Sie pro Control eine kurze, konkrete Begründung. Gute Begründungen nennen den Bezug zu Systemen, Risiken oder organisatorischen Tatsachen. Schlechte Begründungen bleiben abstrakt. Beispiel gut: "Anwendbar, da das Recruiting-System Bewerbungen vorsortiert und daher Bias-, Transparenz- und Oversight-Controls erforderlich sind." Beispiel schlecht: "Anwendbar, weil wichtig."
4. Status erfassen
Der vierte Schritt trennt Entscheidung und Reifegrad. Ein Control kann anwendbar sein und trotzdem erst teilweise umgesetzt sein. Genau das muss sichtbar werden. Typische Statuswerte sind umgesetzt, teilweise umgesetzt, geplant bis Datum oder delegiert. Der Status muss immer mit einem Evidenzverweis verbunden werden.
5. Review durchführen
Der fünfte Schritt ist der formale Review. Verantwortliche aus Governance, Fachbereich, Datenschutz, IT und gegebenenfalls Einkauf sollten den Entwurf gemeinsam prüfen. Ziel ist nicht sprachliche Perfektion, sondern Konsistenz. Stimmen Scope, Begründungen, Status und Evidenz zusammen? Fehlen Controls? Sind Ausschlüsse nachvollziehbar? Gibt es Widersprüche zum Risiko-Register?
Für KMU ist ein pragmischer Ablauf oft ideal: Erst ein belastbarer Tabellenentwurf, dann ein 60- bis 90-minütiger Review mit den relevanten Rollen, danach Freigabe durch die verantwortliche Stelle. Wer parallel den Gesamtaufbau eines AIMS plant, sollte das SoA früh mit dem Glossar zu ISO 42001 und bestehenden Implementierungsunterlagen verzahnen.
Praxisbeispiel — SoA für ein KMU
Ein KMU mit 180 Beschäftigten nutzt drei KI-Anwendungen im Scope: ein internes Assistenzsystem für Wissensarbeit, ein Recruiting-Tool mit automatischer Vorsortierung und einen extern bezogenen Support-Copiloten. Das Unternehmen entwickelt keine eigenen Foundation-Modelle, verarbeitet aber personenbezogene Daten im Recruiting und nutzt Drittanbieter für Hosting und Teile der Sicherheitskontrollen.
Für dieses KMU wären im SoA typischerweise viele Controls anwendbar, weil mehrere Nutzungskontexte, personenbezogene Daten, externe Anbieter und operative Entscheidungen betroffen sind. Die folgende Beispieltabelle zeigt einen realistischen Ausschnitt mit 18 Controls und typischen Begründungen:
| Control-ID | Titel | Anwendbar | Begründung | Status | Evidenz |
|---|---|---|---|---|---|
| A.5.1 | Ressourcen und Verantwortlichkeiten | Ja | Jedes KI-System braucht benannte Owner und Entscheidungswege | Umgesetzt | Rollenmatrix |
| A.5.2 | KI-Lebenszyklusmanagement | Ja | Einführung, Tests, Betrieb und Änderungen müssen gesteuert werden | Teilweise umgesetzt | Lifecycle-Prozess |
| A.5.3 | Datenqualität | Ja | Recruiting- und Supportdaten beeinflussen Ergebnisse direkt | Umgesetzt | Datenqualitätsrichtlinie |
| A.5.4 | Risikobewertung | Ja | Für alle drei KI-Systeme erforderlich | Umgesetzt | Risiko-Register |
| A.5.5 | Auswirkungen auf Personen und Gruppen | Ja | Recruiting-System wirkt auf Bewerber und Chancengleichheit | Teilweise umgesetzt | Impact-Assessment |
| A.6.1 | Impact Assessment vor Inbetriebnahme | Ja | Neue Systeme werden vor Einsatz freigegeben | Umgesetzt | Freigabe-Checkliste |
| A.6.2 | Bias und Fairness | Ja | Recruiting-Tool benötigt regelmäßige Fairness-Prüfung | Teilweise umgesetzt | Fairness-Testbericht |
| A.7.1 | Datenquellen dokumentieren | Ja | Herkunft der Trainings- und Betriebsdaten muss nachvollziehbar sein | Umgesetzt | Dateninventar |
| A.7.2 | Datenherkunft und Lineage | Ja | Änderungen an Datenflüssen müssen nachweisbar sein | Teilweise umgesetzt | Lineage-Diagramm |
| A.7.3 | Datenqualitätskriterien | Ja | Qualitätsgrenzen für Eingaben und Trainingsdaten notwendig | Umgesetzt | Qualitätskatalog |
| A.7.4 | Datenaufbewahrung | Ja | Personenbezogene Daten im Recruiting brauchen Retention-Regeln | Umgesetzt | Löschkonzept |
| A.7.5 | Provenance-Nachweis | Ja | Wer Daten wann und warum geändert hat, muss nachweisbar sein | Teilweise umgesetzt | Audit-Logs |
| A.8.1 | Erklärbarkeit | Ja | HR und Fachbereiche müssen Ergebnisse plausibilisieren können | Teilweise umgesetzt | Erklärbarkeitsleitfaden |
| A.8.2 | Bias- und Fairness-Monitoring | Ja | Leistung und Gruppenabweichungen werden fortlaufend geprüft | Geplant bis Q2 | Monitoring-Konzept |
| A.9.1 | Change Management | Ja | Modell- und Prompt-Änderungen verändern Risikolage | Umgesetzt | Änderungsprotokoll |
| A.9.2 | Feedback nach Deployment | Ja | Beschwerden und Nutzerfeedback sind Governance-Signale | Umgesetzt | Feedback-Prozess |
| A.10.1 | Kompetenz | Ja | Rollenbezogene Schulung ist für Betrieb und Aufsicht erforderlich | Umgesetzt | Schulungsnachweise |
| A.10.2 | Awareness | Ja | Allgemeine KI-Governance-Grundsätze müssen bekannt sein | Umgesetzt | Onboarding-Modul |
Nicht anwendbar wären in diesem Beispiel nur Controls, die eindeutig außerhalb des Scopes liegen. Wenn das Unternehmen etwa keine biometrischen Anwendungen, keine eigenen Modelltrainings oder keine selbst betriebenen Infrastrukturdienste hat, kann es einzelne Controls mit enger, sauber dokumentierter Begründung ausschließen oder als delegiert markieren. Eine tragfähige Begründung lautet dann zum Beispiel: "Nicht anwendbar, da keine eigenen Trainingspipelines betrieben werden; technische Sicherheitsmaßnahme wird vollständig über vertraglich bewerteten SaaS-Anbieter abgedeckt."
Wichtig ist, dass Ausschlüsse nie pauschal für die gesamte Organisation formuliert werden, wenn sie nur für ein einzelnes System gelten. Das SoA muss erkennen lassen, ob eine Control-Entscheidung global oder systemspezifisch ist. Gerade bei KMU mit wenigen, aber sehr unterschiedlichen KI-Anwendungen ist diese Präzision oft entscheidender als die formale Größe des Dokuments.
SoA im Audit
Im Audit ist das SoA eines der ersten Dokumente, an denen sich Reifegrad und Denkqualität eines AIMS zeigen. Auditoren prüfen nicht nur, ob die Tabelle existiert, sondern ob sie logisch mit Scope, Risiko-Register, Policies, Prozessdokumentation und Evidenz verbunden ist.
Typische Prüfhandlungen im Audit sind:
- Abgleich zwischen Scope und markierten Controls
- Stichprobe auf ausgeschlossene Controls und deren Begründung
- Abgleich von Statusangaben mit realer Evidenz
- Prüfung, ob Risiken und Control-Entscheidungen zusammenpassen
- Prüfung, ob delegierte Kontrollen vertraglich und operativ gesteuert werden
Häufige Findings sind erstaunlich ähnlich. Erstens fehlen belastbare Begründungen für ausgeschlossene Controls. Zweitens wird "teilweise umgesetzt" eingetragen, ohne Maßnahmenplan oder Termin. Drittens verweisen Unternehmen auf Dokumente, die nicht existieren oder inhaltlich nicht zur Behauptung passen. Viertens stimmen SoA und tatsächlicher Scope nicht überein, etwa wenn ein Recruiting-System im Inventar auftaucht, aber Bias-, Transparenz- oder Oversight-Controls nicht bewertet wurden.
Die notwendige Dokumentationstiefe ist dabei überschaubar. Auditoren erwarten keine seitenlangen Essays pro Zeile. Sie erwarten präzise, prüfbare Begründungen und funktionierende Verweise. Ein guter SoA-Eintrag ist in einem Satz verständlich, in der Evidenz belastbar und im Risiko- oder Prozesskontext wieder auffindbar.
Wenn Sie sich auf ein Audit vorbereiten, sollte das SoA daher immer zusammen mit Inventar, Risiko-Register, Impact Assessments, Monitoring, Incident-Log und Trainingsnachweisen reviewed werden. Isoliert gepflegt verliert es schnell seinen Wert.
SoA pflegen und aktualisieren
Ein SoA ist kein Einmalprojekt. Sobald sich der Scope oder ein KI-System verändert, kann sich auch die Anwendbarkeit einzelner Controls ändern. Genau deshalb gehört das SoA in den regulären Change- und Review-Prozess des AIMS.
Typische Trigger für Updates sind:
- neues KI-System im Scope
- neuer Anbieter oder Wechsel eines SaaS-Dienstes
- Änderung von Datenquellen, Features oder Trainingslogik
- neue Nutzung in HR, Kundenservice, Compliance oder anderen sensiblen Bereichen
- Incidents, Beschwerden oder auffällige Monitoring-Ergebnisse
- regulatorische Änderungen oder neue interne Vorgaben
Versionierung ist Pflicht, weil Auditoren und interne Stakeholder nachvollziehen müssen, wann warum welche Control-Entscheidung angepasst wurde. Praktisch reicht oft eine dokumentierte Versionshistorie mit Datum, Owner, Änderungsgrund und Freigabe.
Change Management ist dabei mehr als Dateiverwaltung. Wenn ein bisher rein internes Assistenzsystem plötzlich externen Kunden zugänglich gemacht wird, ändern sich Transparenz-, Oversight- und Dokumentationsanforderungen. Wenn ein Recruiting-Tool neue Datenquellen erhält, ändern sich Datenqualitäts-, Bias- und Retention-Themen. Das SoA muss diese Änderungen sichtbar machen, nicht erst im Audit nachträglich erklären.
Mindestens einmal pro Jahr sollte ein vollständiger Review stattfinden, zusätzlich ereignisgesteuert bei wesentlichen Änderungen. Wer ISO 42001 nicht nur dokumentieren, sondern im Unternehmen wirksam machen will, sollte das SoA als lebendes Steuerungsdokument behandeln und mit einer praxisnahen ISO-42001-Schulung verknüpfen. Genau dort werden Rollen, Kontrolllogik und Auditnachweise so vermittelt, dass aus Tabellen echte Governance wird.
FAQ
Müssen alle 38 Controls im SoA stehen?
Ja. Ein vollständiges SoA listet alle 38 Annex-A-Controls auf. Nicht anwendbare Controls werden nicht weggelassen, sondern mit einer nachvollziehbaren Begründung dokumentiert.
Was passiert wenn man Controls ohne Begründung ausschließt?
Controls ohne Begründung auszuschließen führt im Audit regelmäßig zu Findings. Es entsteht der Eindruck, dass die Organisation den Scope oder die Risikologik nicht sauber beherrscht.
Wie detailliert muss die Begründung sein?
Die Begründung muss kurz, aber konkret sein. Ein Satz reicht oft aus, wenn daraus klar hervorgeht, welches System, welcher Prozess oder welcher Scope-Fakt den Ausschluss oder die Anwendung trägt.
Gibt es ein SoA-Template zum Download?
Ein gutes Template ist meist eine einfache Tabelle mit Control-ID, Titel, Anwendbarkeit, Begründung, Status und Evidenz. Wichtig ist weniger das Layout als die konsistente Pflege über alle Controls hinweg.
Wie unterscheidet sich das SoA von ISO 42001 und ISO 27001?
Die Methode ist ähnlich, der Inhalt anders. ISO 27001 fokussiert Sicherheitskontrollen, ISO 42001 fokussiert KI-Governance, Auswirkungen, Transparenz, Daten, Nutzung und menschliche Aufsicht.
Wann muss das SoA aktualisiert werden?
Das SoA muss bei wesentlichen Änderungen aktualisiert werden und sollte mindestens jährlich im Management-Review geprüft werden. Ohne laufende Pflege verliert es seine Auditfunktion.
Wenn Sie das SoA nicht nur erstellen, sondern als funktionierendes Arbeitsinstrument nutzen möchten, verbinden Sie diesen Beitrag mit dem ISO-42001-Leitfaden, den Artikeln zu ISO 42001 Implementierung und ISO 42001 Annex A Controls sowie einer vertiefenden ISO-42001-Schulung. So entsteht aus der Anwendbarkeitserklärung ein belastbarer Governance-Prozess statt einer einmaligen Audit-Vorlage.