Konstantin Ziouras Blog Artikel

Wenn die Kennzahl zum Ziel wird – eine kleine Parabel über KPI und Wirksamkeit

Mon, 05 Oct 2026 19:37:42 GMT

Wenn die Kennzahl zum Ziel wird – eine kleine Parabel über KPI und Wirksamkeit

Wenn die Kennzahl zum Ziel wird – eine kleine Parabel über KPI und Wirksamkeit

Eine Kennzahl kann steigen, ein Ziel kann als erreicht gelten – und trotzdem kann der eigentliche Erfolg ausbleiben.

Warum?

Weil das, was leicht messbar ist, nicht immer das ist, was wirklich zählt.

Dazu drei Beispiele aus völlig unterschiedlichen Welten.

Sun Tzu: Die Schlacht ist nicht der Krieg

Sun Tzu schreibt in Die Kunst des Krieges sinngemäß:

„Hundert Schlachten zu gewinnen ist nicht die höchste Kunst. Die höchste Kunst besteht darin, den Widerstand des Gegners zu brechen, ohne zu kämpfen.“

Der Gedanke dahinter ist einfach:

Die gewonnene Schlacht ist nicht das eigentliche Ziel.

Man kann eine Schlacht gewinnen und trotzdem den Krieg verlieren.

Und damit sind wir schon mitten im Thema Kennzahlen.

Vietnam: Wenn die Zahl zum Erfolg wird

Ein makabres Beispiel liefert der Vietnamkrieg.

Auf amerikanischer Seite wurden unter anderem Body Counts, Kill Ratios und die Zahl „befriedeter“ Dörfer als Kennzahlen für militärischen Erfolg verwendet. Die Zahlen sollten zeigen, dass der Gegner geschwächt wurde und der Krieg erfolgreich verlief. Das U.S. Naval History and Heritage Command beschreibt diese damalige „success offensive“ ausdrücklich.

Das Problem war nicht unbedingt, dass die Zahlen falsch waren.

Das Problem war:

Sie konnten eine Frage beantworten, die nicht identisch mit der eigentlichen strategischen Frage war.

Viele getötete Gegner sind eine messbare Größe.

Aber sie beantworten nicht automatisch die Frage:

Ist das strategische Ziel erreicht?

Die Tet-Offensive von 1968 zeigt diese Diskrepanz besonders deutlich: Militärisch erlitten die kommunistischen Kräfte schwere Verluste. Gleichzeitig hatte die Offensive erhebliche psychologische und strategische Auswirkungen und schwächte die Unterstützung für den Krieg in den USA.

Eine Kennzahl kann also durchaus korrekt sein und trotzdem ein unvollständiges Bild des Erfolgs liefern.

Goodhart: Wenn die Kennzahl selbst zum Ziel wird

Genau hier passt Goodhart's Law :

“When a measure becomes a target, it ceases to be a good measure.”

Sinngemäß:

Wenn eine Messgröße zum Ziel wird, verliert sie ihre Eignung als gute Messgröße.

(Ursprünglich wurde der Gedanke vom britischen Ökonomen Charles Goodhart 1975 im Zusammenhang mit der Geldpolitik formuliert. Die heute bekannte Formulierung wurde 1997 von der Anthropologin Marilyn Strathern verallgemeinert.)

Das Problem entsteht, wenn aus

„Wir messen X, weil X etwas über unseren Erfolg aussagt.“

unmerklich wird:

„Wir müssen X erreichen, weil X unsere Kennzahl ist.“

Dann verändert sich das Verhalten.

Ein Beispiel aus der Softwareentwicklung

Nehmen wir an, ein Unternehmen möchte die Produktivität seiner Softwareentwickler messen.

Die Kennzahl lautet:

Anzahl geschriebener Codezeilen pro Monat.

10.000 Zeilen sind besser als 5.000.

Oder?

Natürlich nicht unbedingt.

Guter Softwarecode zeichnet sich nicht dadurch aus, möglichst umfangreich zu sein.

Im Gegenteil:

weniger Code kann einfacher zu warten sein,
unnötiger Code erhöht die Komplexität,
redundanter Code kann Fehler verursachen,
eine gute Lösung kann darin bestehen, 10.000 Zeilen auf 2.000 zu reduzieren.

Wenn aber die Anzahl der Codezeilen zur Leistungskennzahl und gleichzeitig zum Ziel wird, entsteht ein bemerkenswerter Effekt:

Der Entwickler hat einen Anreiz, mehr Code zu produzieren – nicht unbedingt bessere Software.

Die Kennzahl steigt.

Der eigentliche Nutzen muss deshalb noch lange nicht steigen.

Und genau hier liegt die Parallele zu Managementsystemen

Das gleiche Muster findet sich auch in Qualitätsmanagement, Informationssicherheit und Compliance.

Man kann beispielsweise

100 % der Mitarbeiter schulen,
100 % der Maßnahmen abschließen,
100 % der Backups durchführen,
100 % der Risiken bewerten

und trotzdem das eigentliche Ziel verfehlen.

Nicht weil diese Kennzahlen schlecht sind.

Sondern weil sie nur einen Ausschnitt der Realität beschreiben .

Die entscheidende Frage lautet deshalb nicht:

„Ist unsere Kennzahl grün?“

Sondern:

„Was wissen wir tatsächlich, wenn sie grün ist?“

Der kleine Gedanken-Happen zum Schluss

Vielleicht ist das eine der wichtigsten Fragen beim Aufbau eines KPI-Systems:

Wenn unsere Kennzahl morgen 100 % erreicht – woran erkennen wir, dass wir dadurch tatsächlich besser geworden sind?

Denn:

Eine gewonnene Schlacht ist nicht automatisch ein gewonnener Krieg.

10.000 Zeilen Code sind nicht automatisch bessere Software.

100 % umgesetzte Maßnahmen sind nicht automatisch wirksame Maßnahmen.

Und deshalb:

Nicht die Kennzahl ist das Ziel.

Die Kennzahl soll uns helfen zu erkennen, ob wir dem Ziel näherkommen.

Oder noch kürzer:

Wer die falsche Kennzahl optimiert, kann erfolgreich sein – und trotzdem das Ziel verfehlen.

ISMS-Wirksamkeit messen – Ein Mindestmaß an Zielen, KPI und Metriken

Mon, 05 Oct 2026 09:12:33 GMT

ISMS-Wirksamkeit messen – Ein Mindestmaß an Zielen, KPI und Metriken

ISMS-Wirksamkeit messen – Ein Mindestmaß an Zielen, KPI und Metriken

Ein Informationssicherheitsmanagementsystem (ISMS) kann viele Prozesse, Richtlinien und Sicherheitsmaßnahmen besitzen und trotzdem nicht wirksam sein.

Ein ISMS kann beispielsweise:

100 % der Mitarbeiter geschult haben,
alle Richtlinien freigegeben haben,
regelmäßige Risikobewertungen durchführen,
Backups erstellen,
Schwachstellen überwachen und
zahlreiche technische Controls betreiben.

Doch daraus folgt noch nicht automatisch:

Die Informationssicherheitsziele werden tatsächlich erreicht.

Für die Bewertung der Wirksamkeit braucht es deshalb neben Aktivitäts- und Prozesskennzahlen auch Ergebnis- und Wirksamkeitsmetriken .

Dieser Artikel beschreibt ein pragmatisches Mindestmaß an Wirksamkeitszielen für ein ISMS .

1. KPI ist nicht gleich Wirksamkeitsnachweis

Ein wichtiger Grundsatz lautet:

Ein KPI zeigt, was gemessen wird. Ein Wirksamkeitsnachweis zeigt, ob das Sicherheitsziel tatsächlich erreicht wird.

Ein einfaches Beispiel:

Ziel: Mitarbeiter sollen Sicherheitsrisiken erkennen.

KPI:

98 % der Mitarbeiter haben die Awareness-Schulung absolviert.

Das ist eine gute Kennzahl für die Durchführung der Schulung .

Aber sie beantwortet noch nicht die Frage:

Haben die Mitarbeiter tatsächlich gelernt, Phishing und andere Angriffe zu erkennen?

Dafür wäre beispielsweise eine kontrollierte Phishing-Simulation wesentlich aussagekräftiger.

Die drei Ebenen

Eine sinnvolle Messlogik unterscheidet daher:

Aktivität / Control

Was haben wir getan?

KPI / Prozessleistung

Wie gut funktioniert unser Prozess?

Wirksamkeitsnachweis / Outcome

Erreichen wir damit tatsächlich unser Sicherheitsziel?

Diese Unterscheidung ist für ein wirksames ISMS entscheidend.

2. Ein pragmatisches Mindestset für das ISMS

Ein Unternehmen muss nicht hunderte Kennzahlen erheben.

Für eine grundlegende Wirksamkeitsbewertung reicht häufig ein überschaubares Set von 8 bis 10 zentralen Wirksamkeitszielen .

Die konkrete Auswahl hängt natürlich von Unternehmensgröße, Geschäftsmodell, Risiken und regulatorischen Anforderungen ab.

Das folgende Set kann jedoch als praktischer Ausgangspunkt dienen.

3. Mindestmaß an ISMS-Wirksamkeitszielen (Siehe detailierte Tabelle am Ende)

Vertraulichkeit wird wirksam geschützt
Integrität wird wirksam geschützt
Verfügbarkeit kritischer Services wird sichergestellt
Sicherheitsvorfälle werden rechtzeitig erkannt
Sicherheitsvorfälle werden wirksam behandelt
Wiederherstellung funktioniert
Schwachstellen werden wirksam beherrscht
Informationssicherheitsrisiken werden beherrscht
Lieferanten- und Drittparteirisiken werden beherrscht
Mitarbeiter können Sicherheitsrisiken wirksam erkennen

Diese Tabelle sollte nicht als universelle normative Mindestanforderung verstanden werden.

Sie ist vielmehr ein praxisorientiertes Mindestset , mit dem ein Unternehmen beginnen kann, die tatsächliche Wirksamkeit seines ISMS zu bewerten.

4. Vertraulichkeit: Haben wir tatsächlich Informationen geschützt?

Ein typisches ISMS misst beispielsweise:

MFA-Abdeckung
Berechtigungsüberprüfungen
DLP-Regeln
Verschlüsselungsquote
Anzahl blockierter Übertragungen

Diese Kennzahlen sind wichtig.

Sie zeigen jedoch hauptsächlich die Innensicht .

Für die Wirksamkeit interessiert zusätzlich die Außensicht:

Sind Informationen tatsächlich in unberechtigte Hände gelangt?

Beispiel

KPI:

98 % der privilegierten Konten verwenden MFA.

Metrik:

Anzahl erfolgreicher unberechtigter Zugriffe.

Wirksamkeitsnachweis:

Anzahl tatsächlicher Datenabflüsse
Anzahl betroffener Datensätze
Schutzbedarf der betroffenen Informationen
betroffene Kunden oder Geschäftspartner
tatsächlich überschrittene Vertrauensgrenzen

Damit wird aus einer technischen Kennzahl eine Aussage über die tatsächliche Wirkung.

5. Integrität: Wurden Informationen tatsächlich manipuliert?

Ein Unternehmen kann sehr gute Change-Management-Prozesse besitzen.

Das allein beweist noch nicht, dass die Integrität seiner Informationen geschützt ist.

KPI

Anteil kontrollierter Änderungen.

Metriken

Anzahl nicht autorisierter Änderungen
Anzahl erkannter Manipulationen
Zeit bis zur Erkennung
Anzahl betroffener Systeme oder Datensätze

Wirksamkeitsnachweis

Können unberechtigte oder unbeabsichtigte Veränderungen tatsächlich erkannt und aus einer vertrauenswürdigen Quelle vollständig wiederhergestellt werden?

Hier zeigt sich ein wichtiger Unterschied zwischen Kontrolle und Wirksamkeit .

6. Verfügbarkeit: Funktionieren die kritischen Services tatsächlich?

Eine Verfügbarkeitskennzahl von beispielsweise 99,9 % kann gut aussehen.

Für das Management ist jedoch entscheidend:

Welche Services waren tatsächlich betroffen und welche Auswirkungen hatte der Ausfall?

KPI

Verfügbarkeit kritischer Services.

Metriken

tatsächliche Ausfallzeit
Anzahl Ausfälle
Anzahl betroffener Nutzer
verlorene Transaktionen
Dauer der Geschäftsunterbrechung

Wirksamkeitsnachweis

Die tatsächliche Verfügbarkeit liegt innerhalb der für den Geschäftsprozess definierten Anforderungen und die Auswirkungen bleiben innerhalb akzeptierter Grenzen.

7. Erkennung von Sicherheitsvorfällen

Ein ISMS muss nicht nur Angriffe verhindern.

Es muss auch erkennen können, wenn Schutzmaßnahmen versagen.

KPI

Mean Time to Detect – MTTD

Metriken

Zeit zwischen Ereignis und Erkennung
Anteil innerhalb definierter Zeit erkannter Vorfälle
Anzahl unentdeckter oder verspätet erkannter Vorfälle

Wirksamkeitsnachweis

Ein tatsächlicher Sicherheitsvorfall wird innerhalb des definierten Zeitfensters erkannt.

Dabei ist Vorsicht bei einer scheinbar einfachen Kennzahl geboten:

„0 erkannte Vorfälle“ bedeutet nicht automatisch „0 Vorfälle“.

Es kann auch bedeuten, dass die Organisation einen Vorfall nicht erkannt hat.

8. Reaktion und Eindämmung

Die Erkennung allein reicht nicht.

Nach einem Sicherheitsvorfall muss die Organisation wirksam reagieren können.

KPI

Mean Time to Respond / Mean Time to Contain

Metriken

Zeit bis zur ersten Reaktion
Zeit bis zur Eindämmung
Zeit bis zur Beseitigung
Anteil innerhalb definierter Zielwerte behandelter Vorfälle

Wirksamkeitsnachweis

Die Organisation kann einen tatsächlichen Sicherheitsvorfall innerhalb der definierten Anforderungen wirksam eindämmen und seine Auswirkungen begrenzen.

9. Wiederherstellbarkeit: Funktionieren unsere Backups wirklich?

Hier zeigt sich besonders deutlich der Unterschied zwischen KPI und Wirksamkeitsnachweis.

KPI

99,8 % der geplanten Backups wurden erfolgreich durchgeführt.

Das ist eine wichtige Kennzahl.

Aber:

Ein erfolgreiches Backup ist noch kein erfolgreicher Restore.

Metriken

Restore-Testquote
erfolgreiche Restore-Tests
tatsächliche Wiederherstellungszeit
tatsächlicher Datenverlust
RTO-Erfüllung
RPO-Erfüllung

Wirksamkeitsnachweis

Ein kritisches System kann tatsächlich innerhalb des definierten RTO wiederhergestellt werden und der Datenverlust bleibt innerhalb des definierten RPO.

Damit wird aus:

„Wir haben Backups.“

die wesentlich wichtigere Aussage:

„Wir können unsere kritischen Informationen und Systeme tatsächlich wiederherstellen.“

10. Schwachstellenmanagement

Eine hohe Zahl behobener Schwachstellen bedeutet nicht automatisch, dass das Unternehmen gut geschützt ist.

Interessanter ist:

Werden die kritischen Schwachstellen rechtzeitig behandelt?

KPI

Anteil fristgerecht behandelter kritischer Schwachstellen.

Metriken

Anzahl kritischer Schwachstellen
Alter kritischer Schwachstellen
Zeit bis zur Behebung
Anteil außerhalb definierter Fristen
tatsächlich ausgenutzte Schwachstellen

Wirksamkeitsnachweis

Kritische Schwachstellen werden innerhalb der definierten Risikofrist behandelt oder es existieren dokumentierte und akzeptierte kompensierende Maßnahmen.

11. Risikomanagement

Ein ISMS soll nicht möglichst viele Risiken dokumentieren.

Es soll Informationssicherheitsrisiken wirksam beherrschen .

KPI

Anteil behandelter kritischer Risiken.

Metriken

Anzahl kritischer Risiken
Anteil innerhalb definierter Frist behandelter Risiken
Anzahl überfälliger Maßnahmen
Anzahl akzeptierter Restrisiken
Entwicklung des Gesamtrisikos

Wirksamkeitsnachweis

Das verbleibende Risiko liegt innerhalb der definierten Akzeptanzkriterien oder wurde durch die zuständigen Verantwortlichen bewusst akzeptiert.

Dabei ist eine wichtige Unterscheidung notwendig:

Ein geschlossenes Risiko-Ticket ist noch kein Beweis für eine wirksame Risikobehandlung.

Die entscheidende Frage lautet:

Hat sich das Risiko tatsächlich ausreichend reduziert?

12. Lieferanten- und Drittparteirisiken

Gerade bei Cloud-Diensten und ausgelagerten IT-Services kann die Informationssicherheit eines Unternehmens erheblich von externen Parteien abhängen.

KPI

Anteil kritischer Lieferanten mit aktueller Sicherheitsbewertung.

Metriken

Anteil bewerteter kritischer Lieferanten
Anzahl überfälliger Bewertungen
Anzahl kritischer Feststellungen
Anzahl Lieferanten-Sicherheitsvorfälle

Wirksamkeitsnachweis

Nicht nur:

„98 % der Lieferanten wurden bewertet.“

Sondern:

Sind kritische Abhängigkeiten tatsächlich angemessen beherrscht und haben Lieferantenereignisse keine unakzeptablen Auswirkungen auf unsere Informationssicherheit?

13. Awareness: Schulungsquote ist nicht gleich Wirksamkeit

Die klassische Kennzahl lautet:

100 % der Mitarbeiter haben an der Awareness-Schulung teilgenommen.

Das ist eine gute Teilnahmequote .

Aber sie sagt wenig darüber aus, ob Mitarbeiter tatsächlich sicherheitsbewusst handeln.

KPI

Awareness-Teilnahmequote.

Metriken

Teilnahmequote
Testergebnisse
Phishing-Klickrate
Melderate verdächtiger Nachrichten
Wiederholungsfehler

Wirksamkeitsnachweis

Mitarbeiter erkennen und melden relevante Sicherheitsereignisse in realistischen Situationen zuverlässig.

Damit wird aus:

„Mitarbeiter wurden geschult.“

die deutlich bessere Aussage:

„Mitarbeiter zeigen in realistischen Situationen das gewünschte Sicherheitsverhalten.“

14. Leading und Lagging Indicators

Die Unterscheidung zwischen Leading und Lagging Indicators kann die Systematik zusätzlich unterstützen.

Leading Indicators (Frühindikatoren)

Sie zeigen, ob die Organisation gute Voraussetzungen geschaffen hat.

Beispiele:

MFA-Abdeckung
Patch-Quote
Schulungsquote
Backup-Quote
Anteil bewerteter Lieferanten
Anteil behandelter Risiken

Lagging / Outcome Indicators (Spätindikatoren)

Sie zeigen, was tatsächlich passiert ist.

Beispiele:

erfolgreiche Datenabflüsse
tatsächliche Manipulationen
Ausfallzeiten
tatsächlicher Datenverlust
erfolgreiche Angriffe
tatsächlich ausgenutzte Schwachstellen
tatsächliche Lieferanten-Sicherheitsvorfälle

Eine gute Wirksamkeitsbewertung benötigt beide Perspektiven .

Denn:

Leading Indicators zeigen, ob wir vorbereitet sind. Outcome Indicators zeigen, ob diese Vorbereitung tatsächlich Wirkung zeigt.

15. Ein einfaches Mindest-Dashboard für das Management

Für ein Management-Review muss daraus kein Dashboard mit 100 Kennzahlen entstehen.

Ein kompaktes ISMS-Wirksamkeitsdashboard könnte beispielsweise folgende zehn Fragen beantworten:

Frage? Beispiel-Kennzahl

1. Werden vertrauliche Informationen tatsächlich geschützt? erfolgreiche Datenabflüsse

2. Werden Informationen vor Manipulation geschützt? erfolgreiche Manipulationen

3. Sind kritische Services verfügbar? tatsächliche Ausfallzeit

4. Erkennen wir Angriffe schnell genug? MTTD

5. Reagieren wir schnell genug? MTTR / Containment Time

6. Können wir Systeme tatsächlich wiederherstellen? RTO-/RPO-Erfüllung

7. Beherrschen wir kritische Schwachstellen? fristgerechte Behebung

8. Reduzieren wir unsere wesentlichen Risiken? Entwicklung des Restrisikos

9. Beherrschen wir unsere Lieferantenrisiken? kritische Lieferantenrisiken

10. Verhalten sich Mitarbeiter tatsächlich sicher? Awareness-/Phishing-Ergebnis

Damit erhält das Management keine reine Aktivitätenliste , sondern eine Aussage darüber, ob das ISMS seine wesentlichen Ziele tatsächlich erreicht.

16. Der wichtigste Grundsatz

Bei der Auswahl von KPI und Metriken sollte immer die Frage gestellt werden:

„Wenn sich dieser Wert verbessert, wissen wir dann wirklich, dass unsere Informationssicherheit besser geworden ist?“

Wenn die Antwort „Nein“ lautet, handelt es sich möglicherweise lediglich um eine Aktivitäts- oder Prozesskennzahl.

Das bedeutet nicht, dass solche KPI nutzlos sind.

Sie sind wichtig für die Steuerung .

Sie sollten aber nicht mit einem Wirksamkeitsnachweis verwechselt werden.

17. Von KPI zur Wirksamkeit

Die vollständige Logik lässt sich damit sehr einfach darstellen:

· Informationssicherheitsziel

· Sicherheitsanforderung

· Control / Maßnahme

· Prozessziel

· KPI

· Metrik

· Wirksamkeitsnachweis

· Managementbewertung

Ein Beispiel:

· Ziel: Vertraulichkeit
Anforderung: Nur Berechtigte dürfen auf vertrauliche Daten zugreifen
Control: MFA + Rollenberechtigungen + DLP
Prozessziel: Berechtigungen werden korrekt verwaltet
KPI: Anteil fristgerecht geprüfter Berechtigungen
Metrik: erfolgreiche unberechtigte Zugriffe
Wirksamkeitsnachweis: keine bzw. akzeptable tatsächliche Datenoffenlegung
Managementbewertung: Ziel erreicht / teilweise erreicht / nicht erreicht

Fazit

Ein wirksames ISMS benötigt nicht möglichst viele Kennzahlen.

Es benötigt die richtigen Kennzahlen .

Ein sinnvolles Mindestmaß sollte deshalb mindestens die folgenden Fragen beantworten:

Sind Informationen vertraulich?
Bleiben Informationen integer?
Sind kritische Services verfügbar?
Erkennen wir Sicherheitsvorfälle rechtzeitig?
Können wir wirksam reagieren?
Können wir tatsächlich wiederherstellen?
Beherrschen wir kritische Schwachstellen?
Reduzieren und beherrschen wir unsere wesentlichen Risiken?
Beherrschen wir kritische Drittparteirisiken?
Zeigen Mitarbeiter tatsächlich das erwartete Sicherheitsverhalten?

Der entscheidende Unterschied liegt dabei zwischen „Wir haben etwas getan“ und „Es wirkt“ .

Nicht nur messen, ob das ISMS arbeitet – messen, ob es wirkt.

Das ist letztlich der Kern einer wirksamen Informationssicherheitssteuerung.

Software Testing und Test Management nach ISTQB - International Software Testing Qualifications Board

Tue, 22 Sep 2026 19:42:25 GMT

Software Testing und Test Management nach ISTQB - International Software Testing Qualifications Board

Software Testing und Test Management nach ISTQB - International Software Testing Qualifications Board

Warum gutes Testen mehr ist als „Fehler finden“

Software wird heute in nahezu allen Produkten und Geschäftsprozessen eingesetzt. Gleichzeitig steigen die Anforderungen an Qualität, Sicherheit, Verfügbarkeit und Zuverlässigkeit.

Trotzdem wird Software Testing in vielen Projekten noch immer auf eine einfache Frage reduziert:

„Funktioniert die Software?“

Das reicht längst nicht mehr aus.

Die entscheidenden Fragen lauten vielmehr:

Erfüllt die Software die definierten Anforderungen?
Erfüllt sie die Erwartungen der Benutzer und Stakeholder?
Ist sie unter realistischen Bedingungen zuverlässig?
Ist sie ausreichend performant?
Ist sie sicher?
Was passiert bei Fehlbedienung oder ungewöhnlichen Eingaben?
Wie verhält sie sich unter hoher Last?
Was passiert nach Änderungen?
Können wir objektiv nachweisen, dass die Anforderungen erfüllt sind?
Und vor allem: Woher wissen wir, dass wir ausreichend getestet haben?

Genau hier setzt das International Software Testing Qualifications Board (ISTQB) an.

Der aktuelle ISTQB Certified Tester Foundation Level (CTFL) v4.0 vermittelt eine gemeinsame Terminologie und ein systematisches Verständnis von Software Testing. Der Ansatz ist dabei ausdrücklich unabhängig vom verwendeten Softwareentwicklungsmodell und kann beispielsweise in klassischen, agilen, DevOps- und Continuous-Delivery-Umgebungen eingesetzt werden.

1. Was bedeutet Software Testing eigentlich?

Testing ist wesentlich mehr als das Ausführen von Testfällen.

Aus Sicht des ISTQB umfasst Software Testing eine Reihe von Aktivitäten, die dazu dienen, Qualität zu bewerten und Fehler bzw. Defekte zu erkennen.

Dabei geht es nicht nur um die Frage:

„Gibt es Fehler?“

Sondern auch um:

„Welche Risiken bestehen, welche Qualitätsmerkmale sind relevant und welche Informationen benötigen wir für eine fundierte Entscheidung?“

Testing liefert damit Informationen für Entscheidungen.

Zum Beispiel:

Kann eine Version freigegeben werden?
Sind bestimmte Anforderungen erfüllt?
Welche Risiken bestehen noch?
Welche Defekte sind offen?
Ist die Testabdeckung ausreichend?
Welche Bereiche müssen weiter untersucht werden?

Damit wird Testing zu einem wichtigen Bestandteil des Qualitätsmanagements.

2. Testen ist nicht dasselbe wie Debugging

Ein wichtiger Unterschied:

Testing

Testing versucht, Fehler bzw. Defekte sichtbar zu machen und Informationen über die Qualität des Systems zu gewinnen .

Debugging

Debugging ist die Tätigkeit, mit der Entwickler die Ursache eines beobachteten Fehlverhaltens analysieren und beseitigen .

Vereinfacht:

Tester:
„Das System liefert bei dieser Eingabe ein falsches Ergebnis.“

Entwickler:
„Ich analysiere, warum das passiert und korrigiere die Ursache.“

Danach beginnt erneut der Test.

Diese Trennung ist wichtig, weil Testing nicht automatisch bedeutet, dass der Tester auch die Fehlerursache beheben muss.

3. Die sieben grundlegenden Testprinzipien

Die Testprinzipien gehören zu den wichtigsten Grundlagen des ISTQB.

Sie erklären, warum Testing anders funktioniert als viele andere Prüfprozesse.

Prinzip 1: Testing zeigt das Vorhandensein von Defekten

Der vielleicht wichtigste Grundsatz lautet:

Testing kann zeigen, dass Defekte vorhanden sind – es kann nicht beweisen, dass keine Defekte vorhanden sind.

Wenn ein Test einen Fehler findet, wissen wir:

Mindestens ein Defekt existiert.

Wenn 10.000 Tests erfolgreich sind, wissen wir dagegen nicht:

Es gibt keine weiteren Defekte.

Das ist ein fundamentaler Unterschied.

Ein erfolgreicher Test bedeutet:

Unter den geprüften Bedingungen wurde kein Fehlverhalten beobachtet.

Nicht:

Die Software ist fehlerfrei.

4. Prinzip 2: Vollständiges Testen ist unmöglich

Ein System kann eine nahezu unendliche Anzahl möglicher:

Eingaben,
Benutzerzustände,
Datenkombinationen,
Systemzustände,
Schnittstellenzustände,
Konfigurationen

besitzen.

Alle Kombinationen zu testen ist in der Praxis normalerweise unmöglich.

Deshalb muss Testing risikoorientiert priorisiert werden.

Beispiel:

Ein Online-Shop besitzt 50 Eingabefelder.

Man könnte versuchen, alle möglichen Kombinationen zu testen.

Das wäre praktisch nicht machbar.

Stattdessen konzentriert man sich beispielsweise auf:

kritische Geschäftsfunktionen,
Grenzwerte,
häufige Nutzung,
sicherheitsrelevante Funktionen,
finanzielle Transaktionen,
bekannte Fehlerbereiche,
besonders komplexe Funktionen.

Damit wird aus:

„Wir testen alles.“

die realistische Aussage:

„Wir testen gezielt dort, wo Fehler die größten Auswirkungen haben oder besonders wahrscheinlich sind.“

5. Prinzip 3: Frühes Testen spart Zeit und Geld

Fehler werden teurer, je später sie entdeckt werden.

Ein Missverständnis in einer Anforderung kann beispielsweise entstehen, bevor überhaupt eine Zeile Code geschrieben wurde.

Wenn dieser Fehler bereits beim Requirements Review entdeckt wird, ist die Korrektur vergleichsweise einfach.

Wird derselbe Fehler erst nach:

Architektur,
Entwicklung,
Integration,
Systemtest

entdeckt, können erhebliche Nacharbeiten entstehen.

Deshalb gehört Testing nicht ans Ende des Projekts.

Testing beginnt bereits bei:

Anforderungen → Architektur → Design → Implementierung → Integration → System → Abnahme

Das wird häufig als Shift Left bezeichnet.

Dabei bedeutet Shift Left nicht lediglich:

„Tester sollen früher testen.“

Vielmehr geht es darum, Qualität und Testbarkeit bereits früh in den Entwicklungsprozess einzubauen .

6. Prinzip 4: Fehler treten häufig gehäuft auf

Defekte verteilen sich nicht unbedingt gleichmäßig über ein System.

Häufig konzentrieren sich viele Defekte auf relativ wenige Komponenten oder Bereiche.

Mögliche Ursachen:

hohe Komplexität
häufige Änderungen
schlechte Wartbarkeit
unklare Anforderungen
hohe technische Verschuldung
schwierige Schnittstellen
fehlendes Wissen
neue Technologien

Daraus folgt eine wichtige Konsequenz:

Tester sollten ihre Aufmerksamkeit nicht gleichmäßig über das gesamte System verteilen.

Wenn ein Modul bereits mehrfach schwerwiegende Fehler gezeigt hat, kann dies ein Hinweis auf ein erhöhtes Risiko sein.

7. Prinzip 5: Wiederholte Tests verlieren ihre Wirksamkeit

Das ISTQB bezeichnet dieses Phänomen als Pesticide Paradox .

Wenn immer wieder exakt dieselben Testfälle ausgeführt werden, finden sie irgendwann möglicherweise keine neuen Fehler mehr.

Nicht unbedingt deshalb, weil das System perfekt geworden ist.

Sondern weil die Tests immer dieselben Bereiche und Zustände prüfen.

Deshalb sollten Tests regelmäßig weiterentwickelt werden.

Zum Beispiel durch:

neue Testdaten,
andere Eingabekombinationen,
neue Grenzwerte,
negative Tests,
exploratives Testen,
neue Testtechniken,
neue Risiken.

Testing ist daher kein statischer Prozess.

8. Prinzip 6: Testing ist kontextabhängig

Es gibt nicht die eine richtige Testmethode .

Die richtige Vorgehensweise hängt vom Kontext ab.

Ein medizinisches Gerät benötigt andere Tests als:

ein Computerspiel,
eine Banking-Anwendung,
eine interne Zeiterfassung,
eine Steuerungssoftware,
ein Cloud-Service.

Relevant sind beispielsweise:

Risiko
Branche
regulatorische Anforderungen
Sicherheitsbedarf
Kritikalität
Benutzergruppe
Systemkomplexität
Entwicklungsmodell
verfügbare Ressourcen

Deshalb ist die Aussage

„Wir testen genauso wie im letzten Projekt.“

grundsätzlich kritisch zu hinterfragen.

9. Prinzip 7: Die Abwesenheit von Fehlern ist kein Qualitätsbeweis

Eine Software kann praktisch keine gefundenen Defekte aufweisen und trotzdem ungeeignet sein.

Beispielsweise kann sie:

die falschen Anforderungen erfüllen,
am Benutzer vorbei entwickelt worden sein,
die falschen Geschäftsprozesse unterstützen,
zu kompliziert sein,
zu langsam sein,
nicht ausreichend sicher sein.

Das ISTQB bezeichnet dies als Absence-of-Errors Fallacy .

Der entscheidende Gedanke lautet:

Eine Software ist nicht automatisch qualitativ hochwertig, nur weil wir keine Fehler gefunden haben.

Testing muss deshalb auch prüfen:

Bauen wir das richtige System?

und nicht nur:

Bauen wir das System richtig?

Damit entsteht eine direkte Verbindung zu Requirements Engineering.

10. Die Verbindung zwischen Requirements Engineering und Testing

Der Blog Artikel über Requirements Engineering führt direkt zu dieser Frage:

Wie wird aus einer Anforderung ein Test?

Beispiel:

Anforderung

Das System muss eine Standard-Suchanfrage bei bis zu 10 Millionen Datensätzen innerhalb von maximal 2 Sekunden beantworten.

Daraus können wir ableiten:

Akzeptanzkriterium

Mindestens 95 % der definierten Suchanfragen müssen innerhalb von 2 Sekunden beantwortet werden.

Testfall

Durchführung eines Performance-Tests mit 10 Millionen Datensätzen und definiertem Lastprofil.

Testergebnis

98 % der Suchanfragen ≤ 2 Sekunden.

Entscheidung

Anforderung erfüllt.

Damit entsteht eine Kette:

Anforderung → Akzeptanzkriterium → Testfall → Testergebnis → Entscheidung

Genau diese Verbindung macht Requirements Engineering und Testing zu zwei Seiten desselben Qualitätsprozesses.

11. Testlevels nach ISTQB

ISTQB unterscheidet Testlevels als Gruppen von Testaktivitäten, die gemeinsam organisiert und gesteuert werden. Im CTFL v4.0 werden fünf Testlevels beschrieben.

1. Component Testing

Hier werden einzelne Komponenten bzw. Einheiten getestet.

Beispielsweise:

einzelne Funktionen
Klassen
Module
Services

Ziel ist es, Fehler möglichst früh zu erkennen.

2. Component Integration Testing

Hier wird geprüft, ob Komponenten korrekt miteinander funktionieren.

Beispiele:

API-Aufruf
Datenübergabe
Service-Kommunikation
Schnittstellen
Datenformate

Gerade Schnittstellen sind häufig risikoreich.

3. System Testing

Hier wird das gesamte System bzw. eine vollständige Systemlösung getestet.

System Testing ist besonders wichtig, weil sich Fehler häufig erst aus dem Zusammenspiel verschiedener Komponenten ergeben.

Beispielsweise:

Benutzer → Anwendung → API → Datenbank → externer Service

Jede einzelne Komponente kann für sich funktionieren.

Das Gesamtsystem kann trotzdem fehlerhaft sein.

4. System Integration Testing

Wenn mehrere Systeme miteinander verbunden sind, muss auch deren Zusammenspiel getestet werden.

Beispiele:

ERP ↔ CRM
Anwendung ↔ Payment Provider
Cloud ↔ On-Premises-System
IoT-Gerät ↔ Cloud
Software ↔ externe API

5. Acceptance Testing

Acceptance Testing betrachtet das System aus Sicht der vorgesehenen Nutzung bzw. Abnahme.

Die zentrale Frage lautet:

Erfüllt das System die vereinbarten Anforderungen und den vorgesehenen Zweck?

Beteiligte können beispielsweise sein:

Kunde
Fachbereich
Benutzer
Product Owner
Betreiber

12. Testlevels sind nicht dasselbe wie Testarten

Eine häufige Verwechslung:

Testlevel beschreibt:

Wo bzw. auf welcher Systemebene testen wir?

Testart / Testtyp beschreibt:

Was untersuchen wir?

Beispielsweise kann ein Systemtest gleichzeitig sein:

funktionaler Test
Performance-Test
Security-Test
Usability-Test
Reliability-Test

ISTQB unterscheidet Testlevels und Testtypes ausdrücklich. Testtypes beziehen sich auf bestimmte Qualitätsmerkmale und können grundsätzlich auf verschiedenen Testlevels eingesetzt werden.

13. Funktionales Testing

Funktionales Testing untersucht, ob das System die erwarteten Funktionen korrekt ausführt.

Beispiele:

Login
Bestellung
Rechnungserstellung
Suche
Datenimport
Datenexport
Benutzerverwaltung

Die Frage lautet:

Tut das System das Richtige?

14. Nichtfunktionales Testing

Nichtfunktionales Testing untersucht Qualitätsmerkmale.

Dazu gehören beispielsweise:

Performance
Sicherheit
Usability
Zuverlässigkeit
Kompatibilität
Wartbarkeit
Skalierbarkeit

Beispiel:

Funktional:

„Der Benutzer kann einen Auftrag speichern.“

Nichtfunktional:

„Der Auftrag muss innerhalb von maximal 2 Sekunden gespeichert werden.“

Oder:

„Nur berechtigte Benutzer dürfen den Auftrag ändern.“

Damit wird deutlich:

Funktionale Anforderungen und Qualitätsanforderungen benötigen unterschiedliche Testperspektiven.

15. Black-Box- und White-Box-Testing

Eine weitere wichtige Unterscheidung betrifft den Blickwinkel.

Black Box

Der Tester betrachtet das System von außen.

Er kennt möglicherweise nicht die interne Implementierung.

Er prüft beispielsweise:

Eingabe → System → Ergebnis

Typische Techniken:

Äquivalenzklassen
Grenzwertanalyse
Entscheidungstabellen
Zustandsübergangstests
Use-Case-Tests

White Box

Hier wird die interne Struktur berücksichtigt.

Beispielsweise:

Code
Kontrollfluss
Bedingungen
Pfade
Anweisungen

White-Box-Techniken können insbesondere für Entwickler und technische Tester relevant sein.

16. Testen beginnt nicht erst mit Testfällen

Ein professioneller Testprozess beginnt wesentlich früher.

Ein typischer Ablauf ist:

· Testplanung

· Testanalyse

· Testentwurf

· Testimplementierung

· Testausführung

· Bewertung

· Testabschluss

Dabei werden beispielsweise folgende Fragen beantwortet:

Was soll getestet werden?
Warum?
Mit welchem Risiko?
Welche Testbedingungen gibt es?
Welche Testdaten benötigen wir?
Welche Testumgebung ist erforderlich?
Welche Testfälle werden benötigt?
Welche Ergebnisse erwarten wir?
Wann gilt der Test als erfolgreich?
Wann darf der Test abgeschlossen werden?

17. Test Management

Test Management sorgt dafür, dass Testing nicht zu einer Ansammlung einzelner Testfälle wird.

Das ISTQB CTFL v4.0 behandelt ausdrücklich:

Testplanung
Risikomanagement
Testmonitoring
Teststeuerung
Testabschluss.

Ein Testmanager bzw. Testverantwortlicher muss beispielsweise entscheiden:

Was wird getestet?

Testumfang und Testobjekte.

Wie wird getestet?

Teststrategie und Testansatz.

Mit welchem Risiko?

Priorisierung nach Produkt- und Projektrisiken.

Wer testet?

Rollen und Verantwortlichkeiten.

Wann?

Zeitplanung und Abhängigkeiten.

Womit?

Testumgebung, Tools und Testdaten.

Wann sind wir fertig?

Exit-Kriterien.

18. Risikobasiertes Testing

Ein besonders wichtiger Grundsatz lautet:

Nicht jede Funktion verdient denselben Testaufwand.

Beispiel:

Eine Software besitzt:

eine selten verwendete Hilfefunktion,
eine Zahlungsfunktion,
eine Benutzerverwaltung,
eine Datenlöschfunktion.

Es wäre kaum sinnvoll, allen vier Bereichen exakt denselben Testaufwand zuzuweisen.

Bei der Priorisierung können beispielsweise betrachtet werden:

Wahrscheinlichkeit × Auswirkung

Zusätzlich können berücksichtigt werden:

Sicherheitsrisiko
regulatorisches Risiko
wirtschaftlicher Schaden
Benutzeranzahl
Komplexität
Änderungsumfang
bisherige Defekte

Damit wird Testing zu einer risikoorientierten Qualitätsmaßnahme .

19. Testfälle müssen nicht nur „happy path“ prüfen

Ein häufiger Fehler in Softwareprojekten:

Es wird hauptsächlich der erwartete Normalfall getestet.

Beispiel:

Benutzer gibt korrekte Zugangsdaten ein → Login erfolgreich.

Aber was passiert bei:

falschem Passwort?
leerem Passwort?
gesperrtem Benutzer?
abgelaufener Session?
manipuliertem Request?
fehlendem Netzwerk?
überlastetem System?

Gutes Testing untersucht deshalb auch:

Was passiert, wenn etwas nicht so läuft wie vorgesehen?

Gerade hier treffen sich Software Testing und Informationssicherheit.

20. Testdesign: Wie entstehen gute Testfälle?

ISTQB behandelt verschiedene Testtechniken.

Besonders bekannt sind:

Äquivalenzklassen

Eingaben werden in Klassen aufgeteilt, die sich hinsichtlich ihres erwarteten Verhaltens ähnlich verhalten.

Grenzwertanalyse

Besonders interessant sind die Grenzen.

Beispiel:

Zulässiger Wert: 1–100

Dann sind beispielsweise besonders relevant:

Entscheidungstabellen

Geeignet für komplexe Kombinationen von Bedingungen.

Zustandsübergangstests

Geeignet, wenn sich das Verhalten abhängig vom aktuellen Zustand verändert.

Use-Case-Testing

Testen aus Sicht konkreter Anwendungsszenarien.

Erfahrungsbasierte Verfahren

Beispielsweise:

Error Guessing
Exploratory Testing

Die Auswahl der Technik sollte zum Risiko und zum Testziel passen.

21. System Testing: Die Realität entscheidet

System Testing ist besonders interessant, weil hier das Zusammenspiel des Systems sichtbar wird.

Ein System kann aus einzelnen Komponenten bestehen, die jeweils erfolgreich getestet wurden:

Komponente A – OK

Komponente B – OK

Komponente C – OK

Trotzdem kann gelten:

Gesamtsystem – NICHT OK

Warum?

Weil beispielsweise:

Schnittstellen nicht zusammenpassen,
Datenformate unterschiedlich interpretiert werden,
Timing-Probleme auftreten,
Berechtigungen falsch zusammenspielen,
Fehlerzustände nicht korrekt behandelt werden.

Deshalb ist System Testing keine einfache Addition von Component Tests.

22. Regression Testing

Eine Änderung kann funktionieren und trotzdem bestehende Funktionen beschädigen.

Beispiel:

Ein Entwickler ändert die Benutzerverwaltung.

Der Login funktioniert weiterhin.

Aber plötzlich funktioniert der Export nicht mehr.

Deshalb muss nach Änderungen geprüft werden:

Was könnte durch diese Änderung unbeabsichtigt beeinflusst worden sein?

Regression Testing ist deshalb ein wesentlicher Bestandteil eines kontrollierten Änderungsprozesses.

Besonders relevant ist dies bei:

Releases
Patches
Security Updates
Refactoring
Architekturänderungen
Datenbankänderungen
API-Änderungen

23. Testautomatisierung ist kein Ersatz für Testmanagement

„Wir haben 10.000 automatisierte Tests.“

Das klingt zunächst beeindruckend.

Aber die Anzahl der Tests sagt allein wenig über die Testqualität aus.

Entscheidend ist:

Was wird getestet?
Welche Risiken werden abgedeckt?
Sind die Tests aktuell?
Sind die erwarteten Ergebnisse korrekt?
Werden kritische Randbedingungen geprüft?
Welche Anforderungen sind abgedeckt?
Welche Tests schlagen tatsächlich fehl, wenn etwas kaputtgeht?

Ein automatisierter Test kann sehr effizient sein.

Er kann aber auch sehr effizient das Falsche testen.

Deshalb gilt:

Automatisierung verbessert die Effizienz des Testens – sie ersetzt nicht die Teststrategie.

24. Testbarkeit beginnt bereits bei den Anforderungen

Hier schließt sich der Kreis zum Requirements Engineering.

Eine gute Anforderung sollte testbar sein.

Beispiel:

„Das System muss benutzerfreundlich sein.“

Wie testen wir das?

Schwierig.

Besser:

„Ein Benutzer mit definierter Vorerfahrung muss einen Standardauftrag innerhalb von maximal fünf Minuten ohne Unterstützung erfassen können.“

Jetzt können wir einen Test entwerfen.

Damit entsteht:

· Gute Anforderung

· Gutes Akzeptanzkriterium

· Guter Testfall

· Objektiver Nachweis

Die Qualität des Tests hängt deshalb bereits von der Qualität der Anforderungen ab.

25. Testing und Security Testing

Bei modernen Softwareprodukten darf Informationssicherheit nicht als separates Thema betrachtet werden.

Security Testing kann beispielsweise untersuchen:

Authentifizierung
Autorisierung
Session Management
Eingabevalidierung
Verschlüsselung
Logging
Fehlerbehandlung
Schnittstellen
Schwachstellen
Konfiguration
Berechtigungen

Besonders wichtig:

Security Testing darf nicht erst kurz vor dem Release beginnen.

Sicherheitsanforderungen müssen bereits bei der Anforderungsanalyse berücksichtigt werden.

Danach folgen:

Security Requirement → Security Design → Secure Implementation → Security Test → Nachweis

26. Testing und Cyber Resilience

Für Software und Produkte mit digitalen Elementen wird Testing auch aus regulatorischer Sicht immer wichtiger.

Beispielsweise müssen bei sicherheitsrelevanten Produkten nicht nur Funktionen nachgewiesen werden.

Es geht auch um:

Cybersecurity-Anforderungen
Schwachstellen
sichere Updates
Schutzmechanismen
technische Dokumentation
Nachweise

Damit entsteht eine Verbindung zwischen:

Requirements Engineering

Software Testing

Security Testing

Vulnerability Management

Compliance

Testing ist damit nicht nur eine technische Entwicklungsaktivität.

Es wird Teil der Nachweisführung über die Qualität und Sicherheit eines Produkts.

27. Testmanagement und Qualitätssicherung

Testen und Qualitätssicherung sind nicht identisch.

Testing ist eine wichtige Qualitätsbewertungsaktivität .

Quality Assurance geht darüber hinaus.

Sie fragt beispielsweise:

Sind unsere Prozesse geeignet, um systematisch gute Software zu entwickeln?

Beispiele:

Sind Anforderungen klar definiert?
Werden Reviews durchgeführt?
Gibt es definierte Testprozesse?
Werden Testergebnisse dokumentiert?
Werden Defekte analysiert?
Werden Ursachen betrachtet?
Werden Prozesse verbessert?

Testing liefert also Informationen über das Produkt.

Quality Assurance betrachtet zusätzlich die Prozesse, die dieses Produkt hervorbringen.

28. Defect Management

Ein gefundenes Problem ist noch kein gelöster Fehler.

Ein professioneller Defect-Prozess sollte beispielsweise enthalten:

· Defect entdeckt

· Dokumentation

· Klassifikation

· Priorisierung

· Analyse

· Korrektur

· Retest

· Regressionstest

· Abschluss

Dabei sollten zumindest folgende Informationen nachvollziehbar sein:

Was ist passiert?
Unter welchen Bedingungen?
Wie lässt sich der Fehler reproduzieren?
Welche Version ist betroffen?
Welche Auswirkungen hat der Fehler?
Wie kritisch ist er?
Wer ist verantwortlich?
Wie wurde er behoben?
Wurde die Korrektur getestet?

29. Testabschluss bedeutet nicht einfach „alle Tests sind grün“

Auch das ist ein wichtiger Punkt.

Ein Projekt kann beispielsweise 98 % erfolgreiche Tests haben.

Die entscheidende Frage lautet:

Welche 2 % sind fehlgeschlagen?

Wenn darunter ein kritischer Security Test ist, kann das wesentlich relevanter sein als 500 erfolgreiche Tests einer unwichtigen Funktion.

Deshalb braucht Test Management definierte Exit-Kriterien .

Zum Beispiel:

alle kritischen Tests erfolgreich,
keine offenen kritischen Defekte,
definierte Testabdeckung erreicht,
Security Tests abgeschlossen,
Performance-Ziele erreicht,
Akzeptanzkriterien erfüllt.

Die konkreten Kriterien müssen natürlich zum Projekt und Risiko passen.

30. Welche Testmetriken sind sinnvoll?

Metriken können helfen, den Testfortschritt zu steuern.

Beispiele:

Anzahl geplanter Testfälle
ausgeführte Testfälle
erfolgreiche Tests
fehlgeschlagene Tests
offene Defekte
Defekte nach Kritikalität
Defekttrend
Testabdeckung
Anforderungsabdeckung
Regressionsergebnisse
Automatisierungsgrad

Aber auch hier gilt:

Eine Metrik ist kein Qualitätsbeweis.

Ein hoher Automatisierungsgrad bedeutet beispielsweise nicht automatisch hohe Qualität.

Metriken müssen immer im Kontext interpretiert werden.

31. Unabhängigkeit beim Testen

ISTQB berücksichtigt auch die Frage der Unabhängigkeit.

Je nach Situation kann es sinnvoll sein, dass Tests von Personen durchgeführt werden, die nicht selbst für die Entwicklung des getesteten Ergebnisses verantwortlich waren.

Dabei geht es nicht darum, Entwicklern das Testen zu verbieten.

Im Gegenteil:

Entwickler sollten selbstverständlich testen.

Aber eine zusätzliche unabhängige Perspektive kann wertvoll sein.

Insbesondere bei:

kritischen Systemen
regulierten Produkten
sicherheitsrelevanten Funktionen
Abnahmetests
unabhängigen Reviews

kann eine gewisse Unabhängigkeit die Wahrscheinlichkeit erhöhen, dass andere Fehlerarten erkannt werden.

32. Der „Whole Team“-Gedanke

ISTQB CTFL 4.0 legt einen starken Schwerpunkt auf Zusammenarbeit und ein gemeinsames Qualitätsverständnis.

Testing ist nicht mehr ausschließlich:

„Aufgabe des Testers.“

Qualität betrifft das gesamte Team.

Dazu gehören beispielsweise:

Product Owner
Business Analyst
Requirements Engineer
Entwickler
Tester
Security
Operations
Fachbereich
Management

ISTQB beschreibt CTFL 4.0 ausdrücklich als Grundlage für ein gemeinsames Verständnis von Qualität und Testing und hebt den „whole team approach“ hervor.

Das ist besonders wichtig in agilen und DevOps-orientierten Entwicklungsmodellen.

33. Testing als Informationsgewinn

Eine interessante Perspektive auf Testing lautet:

Testing produziert Informationen.

Zum Beispiel:

Welche Anforderungen sind erfüllt?
Welche Risiken bestehen?
Wo liegen Defekte?
Welche Komponenten sind instabil?
Welche Qualitätsziele werden erreicht?
Welche Risiken bleiben offen?

Der Testmanager ist damit nicht nur Organisator von Testfällen.

Er unterstützt Management und Projektverantwortliche bei Entscheidungen.

Zum Beispiel:

„Kann diese Version freigegeben werden?“

Die Antwort sollte nicht allein auf einem Bauchgefühl beruhen.

Sie sollte auf nachvollziehbaren Informationen basieren.

34. Die Verbindung von Requirements Engineering und Testing

Damit lässt sich die gesamte Kette aus dem vorherigen Artikel erweitern:

· Stakeholder-Bedürfnis

· Anforderung

· Qualitätsanforderung / Security Requirement

· Risiko

· Architektur / Design

· Implementierung

· Testanalyse

· Testfall

· Testausführung

· Testergebnis

· Defect / Korrektur

· Regressionstest

· Abnahme

· Release

· Betrieb

· Änderung

· erneutes Testing

Das ist der eigentliche Lebenszyklus einer Anforderung.

35. Was sollte ein guter Testnachweis enthalten?

Für einen nachvollziehbaren Nachweis sollten beispielsweise folgende Informationen vorhanden sein:

Element - Frage

Test-ID - Welcher Test ist gemeint?
Anforderung- Was soll nachgewiesen werden?
Testziel -Was soll geprüft werden?
Testbedingungen -Unter welchen Bedingungen?
Testdaten -Mit welchen Daten?
Testumgebung -Wo wurde getestet?
Testschritte -Was wurde durchgeführt?
Erwartetes Ergebnis -Was sollte passieren?
Tatsächliches Ergebnis -Was ist passiert?
Status -Passed / Failed etc.
Defect - Gibt es eine Abweichung?
Tester - Wer hat getestet?
Datum- Wann wurde getestet?
Version- Welche Softwareversion?

Damit wird aus: „Wir haben getestet.“ ein belastbarer Nachweis:

„Wir haben diese Anforderung unter definierten Bedingungen mit diesem Test geprüft und dieses Ergebnis erhalten.“

36. Was bedeutet „ausreichend getestet“?

Eine der schwierigsten Fragen im Testmanagement.

Die Antwort lautet:

Nicht alle möglichen Fälle wurden getestet – sondern die definierten Testziele und risikobasierten Kriterien wurden ausreichend erfüllt.

Dafür braucht ein Projekt beispielsweise:

Teststrategie
Risikobewertung
Testziele
Testumfang
Testkriterien
Exit-Kriterien
Testmetriken
dokumentierte Testergebnisse

Die Aussage

„Wir haben keine Zeit mehr, aber die Tests sehen gut aus.“

ist dagegen kein belastbares Testabschlusskriterium.

37. Die zehn wichtigsten Prinzipien für die Praxis

Aus dem ISTQB-Ansatz lassen sich für die Praxis zehn besonders wichtige Regeln ableiten:

1. Testen beginnt früh.

Nicht erst nach der Entwicklung.

2. Anforderungen müssen testbar sein.

Unklare Anforderungen führen zu unklaren Tests.

3. Testen ist risikobasiert.

Nicht alles ist gleich wichtig.

4. Testen kann Fehler finden, aber Fehlerfreiheit nicht beweisen.

5. Tests müssen weiterentwickelt werden.

Immer dieselben Tests reichen nicht.

6. Normalfälle reichen nicht.

Grenzwerte, Fehlerfälle und Missbrauchsszenarien sind wichtig.

7. Systemtests testen das Zusammenspiel.

Nicht nur einzelne Komponenten.

8. Änderungen erfordern Regressionstests.

Ein Fix kann neue Fehler verursachen.

9. Testmanagement braucht klare Kriterien.

Wann beginnen wir? Was testen wir? Wann sind wir fertig?

10. Qualität ist Teamarbeit.

Testing ist keine isolierte Tätigkeit.

38. Die wichtigste Verbindung zu gutem Requirements Engineering

Der vielleicht wichtigste gemeinsame Nenner von IREB und ISTQB lautet:

Eine Anforderung sollte so beschrieben sein, dass ihre Erfüllung überprüft werden kann.

IREB hilft dabei, Anforderungen:

eindeutig,
verständlich,
vollständig,
notwendig,
angemessen und
verifizierbar

zu formulieren.

ISTQB zeigt anschließend, wie daraus:

Testbedingungen,
Testfälle,
Testdaten,
Testverfahren und
Testnachweise

entstehen können.

Damit ergänzen sich beide Ansätze hervorragend.

39. Ein praktisches Gesamtbild

Man kann Requirements Engineering und Testing auf eine gemeinsame Kette reduzieren:

IREB

· Was brauchen wir?

· W arum brauchen wir es?

· Wie formulieren wir es eindeutig?

· Woran erkennen wir die Erfüllung?

ISTQB

· Wie prüfen wir die Erfüllung?

· Welche Risiken müssen wir berücksichtigen?

· Welche Testfälle benötigen wir?

· Was ist das Testergebnis?

· Welche Entscheidung treffen wir?

Das Ergebnis ist:

Anforderung → Test → Nachweis → Entscheidung

Und genau diese Verbindung ist eine der wichtigsten Grundlagen für belastbare Softwarequalität.

40. Fazit

Software Testing nach ISTQB ist weit mehr als das Suchen nach Fehlern.

Es ist ein systematischer Prozess zur Bewertung von Qualität, zur Reduzierung von Risiken und zur Gewinnung belastbarer Informationen über ein System .

Die sieben Testprinzipien zeigen dabei sehr deutlich die Grenzen und Möglichkeiten des Testens:

Testing findet Defekte – es beweist keine Fehlerfreiheit.

Vollständiges Testen ist nicht möglich – deshalb muss risikobasiert priorisiert werden.

Frühes Testen reduziert spätere Kosten.

Fehler konzentrieren sich häufig auf bestimmte Bereiche.

Tests müssen weiterentwickelt werden.

Testing muss zum Kontext passen.

Und ein fehlerfreies Testergebnis bedeutet noch nicht, dass das richtige Produkt gebaut wurde.

Der aktuelle ISTQB CTFL v4.0 verbindet diese Grundlagen mit Testlevels, Testarten, Testtechniken, Testmanagement, Risikomanagement, Monitoring und Testabschluss.

Für die Praxis ergibt sich daraus eine einfache, aber wirkungsvolle Kette:

Gute Anforderungen → gute Testbarkeit → risikoorientiertes Testing → belastbare Testergebnisse → fundierte Freigabeentscheidung.

Und genau deshalb beginnt gutes Software Testing nicht erst beim ersten Testfall.

Es beginnt bei der Anforderung.

Ihr Konstantin Ziouras

Anforderungsmanagement nach IREB - International Requirements Engineering Board

Tue, 22 Sep 2026 19:29:23 GMT

Anforderungsmanagement nach IREB - International Requirements Engineering Board

Anforderungsmanagement nach IREB: Anforderungen richtig verstehen, strukturieren und beschreiben

Warum gute Anforderungen der Anfang guter Produkte sind

(IREB: International Board of Requirements Engineering)

Viele Probleme in Software- und Systemprojekten beginnen nicht mit schlechtem Code, einer falschen Architektur oder unzureichenden Tests.

Sie beginnen häufig viel früher – bei einer Anforderung, die nie richtig verstanden, nicht eindeutig formuliert oder schlicht nicht überprüfbar ist.

„Das System soll schnell sein.“

„Die Anwendung muss sicher sein.“

„Der Benutzer soll die Daten einfach ändern können.“

„Das System muss intuitiv bedienbar sein.“

Solche Aussagen klingen zunächst plausibel. Für Entwicklung und Qualitätssicherung sind sie jedoch nur bedingt hilfreich. Was bedeutet „schnell“? Welche Sicherheitsanforderungen sind gemeint? Was ist „einfach“? Und woran erkennen wir später objektiv, dass die Anforderung erfüllt ist?

Genau hier setzt Requirements Engineering (RE) an.

Das International Requirements Engineering Board – IREB – beschreibt Requirements Engineering als einen systematischen und disziplinierten Ansatz zur Spezifikation und Verwaltung von Anforderungen. Ziel ist es, die Bedürfnisse und Wünsche der Stakeholder zu verstehen und das Risiko zu reduzieren, ein System zu entwickeln, das diese Bedürfnisse nicht erfüllt.

Requirements Engineering ist damit weit mehr als das Schreiben eines Lasten- oder Pflichtenhefts.

Es geht um die Frage:

Was soll ein System leisten, warum soll es das leisten und wie können wir später nachweisen, dass es dies tatsächlich leistet?

1. Requirements Engineering und Anforderungsmanagement – nicht ganz dasselbe

Im Alltag werden die Begriffe Requirements Engineering , Requirements Management und Anforderungsmanagement häufig synonym verwendet. Nach IREB lohnt sich jedoch eine Unterscheidung.

Requirements Engineering

Requirements Engineering umfasst insbesondere:

Anforderungen ermitteln
Anforderungen analysieren
Anforderungen dokumentieren
Anforderungen abstimmen
Anforderungen validieren
Anforderungen verwalten

Der Requirements Engineer arbeitet dabei mit Stakeholdern, Entwicklern, Fachbereichen, Testern und weiteren Beteiligten zusammen.

Requirements Management

Requirements Management beschäftigt sich stärker mit den bereits vorhandenen Anforderungen und den dazugehörigen Arbeitsergebnissen.

Dazu gehören beispielsweise:

Speicherung und Strukturierung
Versionierung
Änderungen
Priorisierung
Status
Beziehungen zwischen Anforderungen
Traceability
Umgang mit Änderungsanträgen

IREB definiert Requirements Management als den Prozess der Verwaltung bestehender Anforderungen und anforderungsbezogener Arbeitsergebnisse einschließlich Speicherung, Änderung und Nachverfolgbarkeit.

Kurz gesagt:

Requirements Engineering hilft uns, die richtigen Anforderungen zu verstehen und zu formulieren.
Requirements Management sorgt dafür, dass diese Anforderungen über ihren Lebenszyklus kontrolliert und nachvollziehbar bleiben.

2. Was ist eine Anforderung?

Eine der wichtigsten Fragen im Requirements Engineering lautet erstaunlicherweise:

Was ist eigentlich eine Anforderung?

IREB verwendet hierfür eine Definition mit drei Perspektiven:

Eine Anforderung ist

ein von einem Stakeholder wahrgenommenes Bedürfnis,
eine Fähigkeit oder Eigenschaft, die ein System besitzen soll, oder
eine dokumentierte Darstellung eines solchen Bedürfnisses, einer Fähigkeit oder Eigenschaft.

Diese Definition ist wichtig, weil sie zeigt:

Eine Anforderung ist nicht einfach jeder Wunsch, der irgendwo aufgeschrieben wurde .

Zwischen einem ursprünglichen Bedürfnis und einer konkreten Systemanforderung findet ein Übersetzungsprozess statt.

Beispiel

Ein Kunde sagt:

„Unsere Mitarbeiter sollen Bestellungen schneller bearbeiten können.“

Das ist zunächst ein Bedürfnis bzw. Ziel .

Daraus könnte beispielsweise die Anforderung entstehen:

REQ-024: Das System muss die Erfassung einer Standardbestellung innerhalb von maximal 30 Sekunden ermöglichen.

Jetzt haben wir eine deutlich konkretere Aussage.

Noch besser wird die Anforderung, wenn wir festlegen können, wie ihre Erfüllung überprüft wird:

Nachweis: Messung der Bearbeitungszeit anhand eines definierten Testszenarios mit 100 Standardbestellungen.

Damit entsteht eine Kette:

Bedürfnis → Anforderung → messbare Eigenschaft → Test/Nachweis

Genau diese Kette ist für professionelles Requirements Engineering entscheidend.

3. Anforderung versus Spezifikation

Ein besonders wichtiger Unterschied wird in der Praxis häufig übersehen:

Eine einzelne Anforderung ist nicht dasselbe wie eine Spezifikation.

IREB definiert eine Requirements Specification als eine systematisch dargestellte Sammlung von Anforderungen , die bestimmte Kriterien erfüllt.

Eine Spezifikation kann beispielsweise enthalten:

funktionale Anforderungen
Qualitätsanforderungen
Randbedingungen
Schnittstellenanforderungen
regulatorische Anforderungen
Sicherheitsanforderungen
Datenanforderungen
Abnahmekriterien
Modelle
Beziehungen zwischen Anforderungen

Vereinfacht:

Begriff

Bedeutung

Bedürfnis

„Wir müssen schneller arbeiten können.“

Anforderung

„Das System muss die Bestellung innerhalb von 30 Sekunden erfassen können.“

Spezifikation

Systematisch strukturierte Sammlung aller relevanten Anforderungen

Design

Beschreibung, wie die Anforderungen technisch umgesetzt werden

Implementierung

Realisierung der Lösung

Test

Nachweis, ob die Anforderungen erfüllt sind

Eine Spezifikation beantwortet deshalb nicht nur die Frage:

„Was soll das System können?“

Sie stellt Anforderungen in einen strukturierten Zusammenhang.

4. Die neun grundlegenden IREB-Prinzipien

IREB stellt Requirements Engineering auf neun grundlegende Prinzipien. Diese Prinzipien sind besonders wertvoll, weil sie nicht einfach eine Dokumentationsmethode beschreiben, sondern eine Denkweise für Requirements Engineering .

1. Value Orientation – Orientierung am Nutzen

Anforderungen sind Mittel zum Zweck und kein Selbstzweck.

Es geht nicht darum, möglichst viele Anforderungen zu produzieren oder möglichst umfangreiche Dokumente zu erstellen.

Eine Anforderung ist dann wertvoll, wenn sie beispielsweise:

einen Stakeholder-Nutzen unterstützt,
Risiken reduziert,
Fehlentwicklungen verhindert,
Klarheit schafft oder
spätere Nacharbeit reduziert.

Das ist ein wichtiger Grundsatz:

Nicht möglichst viele Anforderungen sind das Ziel, sondern die richtigen Anforderungen.

2. Stakeholders – Stakeholder berücksichtigen

Requirements Engineering beschäftigt sich mit den Bedürfnissen und Erwartungen der Stakeholder.

Dabei gibt es selten nur „den Kunden“.

Stakeholder können beispielsweise sein:

Auftraggeber
Benutzer
Betreiber
Management
Entwicklung
Qualitätssicherung
Informationssicherheit
Datenschutz
Einkauf
Service
Behörden
Auditoren
Lieferanten

Diese Gruppen können unterschiedliche und sogar widersprüchliche Erwartungen haben.

Ein Benutzer möchte beispielsweise maximale Benutzerfreundlichkeit.

Die Informationssicherheit fordert möglicherweise zusätzliche Authentifizierung.

Der Betrieb möchte einfache Administration.

Der Kunde möchte niedrige Kosten.

Requirements Engineering muss diese unterschiedlichen Perspektiven sichtbar machen und zu einem gemeinsamen Verständnis führen.

3. Shared Understanding – gemeinsames Verständnis

Ein Dokument allein erzeugt noch kein gemeinsames Verständnis.

Das ist einer der wichtigsten Punkte im Requirements Engineering.

Wenn fünf Personen eine Anforderung lesen und fünf unterschiedliche Interpretationen entwickeln, ist die Anforderung nicht gut.

IREB stellt deshalb das gemeinsame Verständnis als grundlegendes Prinzip heraus.

Eine gute Anforderung muss deshalb nicht nur „korrekt geschrieben“, sondern von den relevanten Beteiligten gleich verstanden werden.

4. Context – Kontext

Ein System existiert niemals isoliert.

Eine Anforderung muss deshalb immer im Kontext betrachtet werden.

Beispielsweise:

Wer verwendet das System?
Welche Prozesse unterstützt es?
Mit welchen anderen Systemen kommuniziert es?
Welche gesetzlichen Anforderungen gelten?
Welche technischen Randbedingungen bestehen?
Welche Risiken existieren?
Welche Umgebung ist relevant?

Die Aussage

„Das System muss verfügbar sein“

ist ohne Kontext kaum sinnvoll.

Erst die Ergänzung

„Das System muss während der Betriebszeit von Montag bis Freitag zwischen 06:00 und 22:00 Uhr eine Verfügbarkeit von mindestens 99,9 % erreichen.“

macht daraus eine wesentlich belastbarere Anforderung.

5. Problem – Requirement – Solution

IREB betrachtet Problem, Anforderung und Lösung als eng miteinander verbundene Konzepte.

Das ist ein sehr wichtiger Gedanke.

Eine Anforderung sollte nicht vorschnell mit einer technischen Lösung verwechselt werden.

Beispiel:

„Das System muss eine Oracle-Datenbank verwenden.“

Das klingt wie eine Anforderung.

Tatsächlich kann es sich aber bereits um eine Lösungsentscheidung handeln.

Die eigentliche Anforderung könnte beispielsweise sein:

„Die Anwendung muss Transaktionsdaten dauerhaft und konsistent speichern.“

Erst danach stellt sich die Frage:

Wie lösen wir dieses Problem technisch?

Diese Trennung schafft Freiraum für Architektur und technische Innovation.

6. Validation – Anforderungen validieren

Eine nicht validierte Anforderung ist nach IREB nicht ausreichend.

Bei der Validierung wird insbesondere geprüft:

Haben wir tatsächlich das Richtige spezifiziert?

Das ist etwas anderes als die spätere technische Prüfung.

Beispiel:

Der Kunde sagt:

„Das System benötigt einen Export nach Excel.“

Die technische Umsetzung kann korrekt funktionieren.

Aber vielleicht bestand das eigentliche Problem darin, dass der Kunde monatlich bestimmte Kennzahlen an die Geschäftsführung liefern muss.

Dann könnte eine automatische Berichtsfunktion das eigentliche Bedürfnis besser erfüllen als ein Excel-Export.

Requirements Engineering muss deshalb nicht nur fragen:

„Haben wir die Anforderung richtig umgesetzt?“

sondern bereits vorher:

„Ist dies überhaupt die richtige Anforderung?“

7. Evolution – Anforderungen verändern sich

Anforderungen sind nicht statisch.

Neue Erkenntnisse, neue Technologien, neue Kundenanforderungen, neue Risiken oder neue gesetzliche Anforderungen können zu Änderungen führen.

IREB betrachtet diese Entwicklung nicht als Ausnahme, sondern als normalen Bestandteil des Requirements Engineering.

Professionelles Requirements Management bedeutet deshalb nicht:

„Wir verhindern Änderungen.“

Sondern:

„Wir machen Änderungen kontrolliert, nachvollziehbar und beherrschbar.“

8. Innovation – nicht nur Bestehendes fortschreiben

Requirements Engineering darf nicht zu einer reinen Verwaltung bestehender Lösungen werden.

Die Frage sollte nicht nur lauten:

„Wie machen wir das bisherige Verfahren digital?“

Sondern auch:

„Welches Problem wollen wir eigentlich lösen – und gibt es dafür eine bessere Lösung?“

Das verhindert, dass bestehende Prozesse einfach unverändert in Software gegossen werden.

9. Systematic and disciplined work – systematisches und diszipliniertes Arbeiten

Requirements Engineering braucht Struktur.

Das bedeutet beispielsweise:

definierte Verantwortlichkeiten
nachvollziehbare Anforderungen
einheitliche Begriffe
eindeutige Identifikation
Reviews
Validierung
Priorisierung
Änderungsmanagement
Traceability

IREB beschreibt Requirements Engineering ausdrücklich als systematischen und disziplinierten Ansatz .

5. Anforderungen richtig kategorisieren

Ein häufiger Fehler besteht darin, verschiedene Klassifizierungen von Anforderungen miteinander zu vermischen.

IREB unterscheidet insbesondere bei den Systemanforderungen zwischen:

funktionalen Anforderungen
Qualitätsanforderungen
Constraints bzw. Randbedingungen.

Qualitätsanforderungen und Constraints werden dabei auch als nichtfunktionale Anforderungen bezeichnet.

Funktionale Anforderungen

Funktionale Anforderungen beschreiben, was ein System tun oder wie es sich verhalten soll .

Beispiele:

Das System muss Bestellungen erfassen können.
Das System muss Benutzer authentifizieren.
Das System muss Rechnungen erzeugen.
Das System muss Daten an das ERP-System übertragen.
Das System muss bei einem Fehler eine Fehlermeldung anzeigen.

Eine funktionale Anforderung beschreibt also insbesondere:

Welche Funktion bzw. welches Verhalten wird erwartet?

Qualitätsanforderungen

Qualitätsanforderungen beschreiben Eigenschaften des Systems, die über eine konkrete Funktion hinausgehen.

Typische Beispiele sind:

Performance
Verfügbarkeit
Zuverlässigkeit
Sicherheit
Wartbarkeit
Benutzbarkeit
Skalierbarkeit
Übertragbarkeit
Wiederherstellbarkeit

Beispiel:

Nicht:

„Das System muss schnell sein.“

Sondern:

„Das System muss eine Suchanfrage bei einer Datenmenge von bis zu 10 Millionen Datensätzen innerhalb von maximal 2 Sekunden beantworten.“

Damit wird aus einer allgemeinen Qualitätsvorstellung eine überprüfbare Anforderung.

IREB ordnet beispielsweise Performanceanforderungen den Qualitätsanforderungen zu.

Constraints – Randbedingungen

Constraints schränken den Lösungsraum ein.

Beispiele:

„Die Anwendung muss auf Windows Server 2025 betrieben werden.“

„Die Kommunikation zwischen den Systemkomponenten muss über HTTPS erfolgen.“

„Die Lösung muss die vorgegebene Unternehmensarchitektur berücksichtigen.“

„Für die Verschlüsselung müssen vom Unternehmen freigegebene kryptografische Verfahren verwendet werden.“

Der entscheidende Unterschied:

Eine funktionale Anforderung beschreibt was das System leisten soll .

Eine Qualitätsanforderung beschreibt welche Qualitätseigenschaft erreicht werden soll .

Ein Constraint beschreibt welche Grenzen oder Vorgaben bei der Lösung einzuhalten sind .

6. Eine wichtige zweite Dimension: Anforderungsebene

Neben der Art der Anforderung kann man Anforderungen auch nach ihrer Abstraktionsebene oder Herkunft betrachten.

Beispielsweise:

Geschäftsanforderung

„Das Unternehmen möchte die Bearbeitungszeit von Kundenaufträgen reduzieren.“

Stakeholder-Anforderung

„Der Sachbearbeiter soll einen Auftrag ohne Medienbruch erfassen können.“

Systemanforderung

„Das System muss die Auftragsdaten aus dem Kundenportal automatisch übernehmen.“

Diese Aussagen sind nicht einfach drei verschiedene Formulierungen derselben Kategorie.

Sie stehen in einer Beziehung zueinander .

Aus einem Geschäftsziel können Stakeholder-Bedürfnisse entstehen. Daraus werden konkrete Systemanforderungen abgeleitet.

Damit entsteht beispielsweise:

Geschäftsziel → Stakeholder-Bedürfnis → Systemanforderung → Design → Implementierung → Test

Genau diese Beziehungen sind später für Traceability besonders wertvoll.

7. Was ist eine gute Anforderung?

Eine gute Anforderung ist nicht einfach eine sprachlich schöne Anforderung.

IREB nennt für einzelne Anforderungen unter anderem folgende Qualitätskriterien:

angemessen / adäquat
notwendig
eindeutig
vollständig
verständlich
verifizierbar.

Besonders interessant ist dabei die IREB-Perspektive auf Adäquanz .

Eine Anforderung ist adäquat, wenn sie die tatsächlichen und abgestimmten Bedürfnisse der Stakeholder ausdrückt.

Das ist etwas anderes als lediglich „grammatikalisch korrekt“.

8. Die gefährlichsten Wörter in Anforderungen

Ein guter Praxistest ist die Suche nach Begriffen, die unterschiedliche Interpretationen zulassen.

Problematisch sind beispielsweise:

schnell
einfach
intuitiv
benutzerfreundlich
sicher
möglichst
angemessen
ausreichend
zeitnah
effizient
regelmäßig
komfortabel
modern
robust

Beispiel:

„Das System muss eine schnelle Verarbeitung ermöglichen.“

Was bedeutet „schnell“?

500 ms?

2 Sekunden?

10 Sekunden?

Oder eine Minute?

Eine bessere Formulierung wäre:

REQ-017: Das System muss eine Standard-Suchanfrage bei bis zu 10 Millionen Datensätzen innerhalb von maximal 2 Sekunden beantworten.

Jetzt ist die Anforderung:

eindeutig,
messbar,
überprüfbar,
testbar.

9. Eine gute Struktur für die Beschreibung einer Anforderung

IREB schreibt nicht vor, dass jede Organisation exakt eine bestimmte Vorlage verwenden muss. IREB beschreibt vielmehr verschiedene Möglichkeiten zur Dokumentation von Anforderungen, darunter natürliche Sprache, Vorlagen und Modelle.

Für die Praxis hat sich jedoch eine strukturierte Anforderungsbeschreibung bewährt.

Eine einzelne Anforderung könnte beispielsweise so aufgebaut sein:

Feld - Inhalt

ID - Eindeutige Kennung
Titel - Kurze verständliche Bezeichnung
Kategorie - Funktional / Qualität / Constraint
Anforderung - Eigentliche Anforderung
Quelle - Stakeholder, Vertrag, Gesetz, Risiko etc.
Begründung - Warum wird die Anforderung benötigt?
Kontext - Relevante Rahmenbedingungen
Priorität - z. B. Muss / Soll / Kann
Abhängigkeiten - Verknüpfte Anforderungen
Risiken - Relevante Risiken
Akzeptanzkriterium - Woran erkennen wir die Erfüllung?
Verifikation - Wie wird die Erfüllung geprüft?
Status - Entwurf / geprüft / freigegeben / geändert
Verantwortlicher - Zuständiger Stakeholder bzw. Owner
Version - Änderungsstand
Traceability - Beziehungen zu Design, Test, Risiko etc.

Damit wird aus einem einfachen Satz ein kontrolliertes Arbeitsergebnis .

10. Der eigentliche Kern: Die Anforderung selbst

Das wichtigste Feld bleibt natürlich die eigentliche Anforderung.

Eine praxistaugliche Grundstruktur lautet:

Das System muss [Objekt] [Aktion/Verhalten] unter [Bedingung] mit [messbarem Kriterium].

Beispiel:

Das System muss bei einer erfolgreichen Anmeldung das Benutzerkonto innerhalb von maximal 2 Sekunden anzeigen , sofern der Authentifizierungsdienst verfügbar ist.

Noch besser ist es, wenn die Anforderung anschließend unmittelbar mit einem Prüfverfahren verbunden wird.

Anforderung

Das System muss die Benutzeroberfläche nach erfolgreicher Anmeldung innerhalb von maximal 2 Sekunden anzeigen.

Akzeptanzkriterium

Bei 100 aufeinanderfolgenden Anmeldungen darf die Zeit zwischen erfolgreicher Authentifizierung und Anzeige der Startseite in mindestens 95 Fällen 2 Sekunden nicht überschreiten.

Verifikation

Performance-Test unter definierter Systemlast.

Damit entsteht eine sehr wichtige Verbindung:

Anforderung → Akzeptanzkriterium → Test → Ergebnis

11. Anforderungen sollten nicht die technische Lösung vorwegnehmen

Eine der wichtigsten Regeln für gute Anforderungen lautet:

Nicht vorschnell das Wie mit dem Was verwechseln.

Beispiel:

Schlechte Anforderung

„Das System muss eine PostgreSQL-Datenbank verwenden.“

Wenn die Datenbanktechnologie nicht aus einer Randbedingung heraus zwingend vorgeschrieben ist, beschreibt diese Aussage möglicherweise bereits eine Designentscheidung.

Besser

„Das System muss die Geschäftsdaten dauerhaft, konsistent und gegen unbeabsichtigten Verlust geschützt speichern.“

Damit bleibt zunächst offen, wie diese Eigenschaft realisiert wird.

Die Architektur und Entwicklung können anschließend eine geeignete technische Lösung bestimmen.

Das entspricht dem IREB-Prinzip Problem – Requirement – Solution .

12. Anforderungen müssen überprüfbar sein

Eine besonders wichtige Eigenschaft ist die Verifizierbarkeit .

IREB definiert Verifizierbarkeit als den Grad, zu dem die Erfüllung einer Anforderung durch das implementierte System überprüft werden kann. Dies kann beispielsweise durch Testfälle, Messungen oder Inspektionen erfolgen.

Daraus folgt eine einfache Praxisfrage:

Wie würde ich diese Anforderung später prüfen?

Wenn darauf keine klare Antwort möglich ist, sollte die Anforderung überarbeitet werden.

Beispiel

Nicht gut:

Das System muss benutzerfreundlich sein.

Besser:

Neue Benutzer müssen nach einer maximal 30-minütigen Einweisung in der Lage sein, einen Standardauftrag ohne Unterstützung anzulegen.

Noch besser:

Die Benutzerfreundlichkeit wird mit einem definierten Usability-Test anhand von fünf Standardaufgaben überprüft.

Damit wird die Qualitätsanforderung tatsächlich prüfbar.

13. Akzeptanzkriterien sind kein Ersatz für Anforderungen

Akzeptanzkriterien werden häufig mit Anforderungen gleichgesetzt.

Das ist nicht ganz richtig.

Eine Anforderung beschreibt, was benötigt wird .

Ein Akzeptanzkriterium beschreibt, woran die Erfüllung erkannt werden kann .

Beispiel:

Anforderung

Das System muss Benutzerkonten nach fünf fehlgeschlagenen Anmeldeversuchen sperren.

Akzeptanzkriterien

Nach dem fünften fehlgeschlagenen Versuch wird das Konto gesperrt.
Ein weiterer Login ist nicht möglich.
Die Sperrung wird protokolliert.
Ein berechtigter Administrator kann die Sperrung aufheben.

Die Akzeptanzkriterien machen die Anforderung operationalisierbar.

14. Traceability: Die Anforderung bekommt einen Lebenslauf

Eine gute Anforderung steht nicht allein.

Sie sollte mit anderen Arbeitsergebnissen verbunden werden können.

Beispielsweise:

Stakeholder-Bedürfnis
Anforderung REQ-017
Risiko R-023
Architekturentscheidung
Implementierung
Testfall TC-081
Testergebnis
Release 2.4

IREB beschreibt Traceability als die Möglichkeit, explizite Beziehungen zwischen zusammengehörigen Arbeitsergebnissen herzustellen – beispielsweise zurück zur Quelle, vorwärts zur Implementierung und zu den zugehörigen Tests.

Das ist insbesondere bei sicherheitskritischen, regulierten oder auditierbaren Produkten von hoher Bedeutung.

15. Requirements Engineering und Informationssicherheit

Gerade bei Software reicht es heute nicht mehr aus, nur funktionale Anforderungen zu betrachten.

Sicherheitsanforderungen müssen frühzeitig in das Requirements Engineering integriert werden.

Beispiele:

Funktionale Anforderung

Das System muss Benutzern die Änderung ihrer Kontaktdaten ermöglichen.

Sicherheitsanforderung

Das System darf die Änderung der Kontaktdaten nur nach erfolgreicher Authentifizierung ermöglichen.

Weitere Sicherheitsanforderung

Änderungen an Kontaktdaten müssen mit Benutzerkennung, Zeitstempel und geändertem Feldwert protokolliert werden.

Qualitätsanforderung

Die Protokolldaten müssen mindestens 12 Monate manipulationsgeschützt aufbewahrt werden.

Jetzt wird sichtbar:

Eine scheinbar einfache Funktion kann mehrere unterschiedliche Anforderungen erzeugen.

Funktion – Qualität – Sicherheit – Nachweis

gehören zusammen.

16. Requirements Engineering als Verbindung zwischen Qualität, Sicherheit und Compliance

Hier wird Requirements Engineering besonders interessant.

Eine Anforderung kann gleichzeitig mehrere Perspektiven haben.

Beispielsweise:

„Das System muss bei einem Ausfall der primären Datenbank innerhalb von 60 Sekunden auf ein redundantes System umschalten.“

Diese eine Anforderung betrifft möglicherweise:

Funktionalität
Verfügbarkeit
Resilienz
Informationssicherheit
Business Continuity
Architektur
Testbarkeit
Abnahme
Risikomanagement

Deshalb ist Requirements Engineering nicht nur eine Aufgabe der Softwareentwicklung.

Es ist eine verbindende Disziplin zwischen:

Business
Produktmanagement
Entwicklung
Architektur
Qualität
Informationssicherheit
Risikomanagement
Test
Compliance
Betrieb

17. Ein praktisches Beispiel: „Das System muss sicher sein“

Eine typische Aussage aus Projekten lautet:

„Das System muss sicher sein.“

Aus Sicht des Requirements Engineering ist das noch keine ausreichend konkrete Anforderung.

Die Aussage muss zunächst analysiert werden.

Welche Schutzbedürfnisse bestehen?

Beispielsweise:

Vertraulichkeit
Integrität
Verfügbarkeit
Authentizität
Nachvollziehbarkeit

Welche Risiken bestehen?

Beispielsweise:

unberechtigter Zugriff
Manipulation
Datenverlust
Schadsoftware
Missbrauch von Schnittstellen

Welche Anforderungen ergeben sich daraus?

Zum Beispiel:

Das System muss Benutzer vor dem Zugriff auf geschützte Funktionen authentifizieren.

oder:

Das System muss sicherstellen, dass Benutzer nur auf Daten zugreifen können, für die sie berechtigt sind.

oder:

Sicherheitsrelevante Änderungen müssen revisionssicher protokolliert werden.

Aus einem abstrakten Ziel entsteht damit eine Menge konkreter, überprüfbarer Anforderungen.

18. Ein häufiger Fehler: Anforderungen und Tests werden zu spät miteinander verbunden

Ein sehr einfacher Qualitätstest für Anforderungen lautet:

Kann ich aus dieser Anforderung einen sinnvollen Testfall ableiten?

Wenn die Antwort „nein“ lautet, ist die Anforderung möglicherweise:

zu unklar,
zu allgemein,
nicht messbar,
nicht vollständig oder
noch nicht ausreichend abgestimmt.

IREB stellt die Verifizierbarkeit ausdrücklich als Qualitätskriterium heraus.

Das führt zu einer wichtigen Denkweise:

Der Test beginnt gedanklich bereits bei der Anforderung.

Nicht erst beim Testfall.

19. Die fünf wichtigsten Fragen für jede Anforderung

In der Praxis lässt sich die Qualität einer Anforderung mit wenigen Fragen überprüfen:

1. Warum?

Welches Problem oder Bedürfnis steckt dahinter?

2. Was?

Welche Fähigkeit oder Eigenschaft soll das System besitzen?

3. Für wen?

Welcher Stakeholder benötigt diese Eigenschaft?

4. Woran erkennen wir die Erfüllung?

Wie kann die Anforderung objektiv überprüft werden?

5. Was hängt davon ab?

Welche Risiken, Anforderungen, Designs, Tests oder regulatorischen Vorgaben stehen damit in Verbindung?

Wenn diese fünf Fragen beantwortet werden können, ist bereits ein großer Teil des Requirements Engineering erledigt.

20. Die praktische Struktur einer guten Anforderung

Für viele Unternehmen reicht eine relativ einfache Vorlage.

Anforderungen-ID

REQ-SEC-017

Titel

Schutz vor unberechtigtem Zugriff

Kategorie

Security Requirement / Qualitätsanforderung

Anforderung

Das System muss den Zugriff auf administrative Funktionen ausschließlich für authentifizierte und entsprechend berechtigte Benutzer ermöglichen.

Begründung

Schutz vor unberechtigter Änderung sicherheitsrelevanter Systemeinstellungen.

Quelle

Informationssicherheitsrisiko R-023; Security Architecture.

Priorität

Muss

Akzeptanzkriterium

Ein nicht authentifizierter Benutzer darf keine administrative Funktion aufrufen können. Ein authentifizierter Benutzer ohne entsprechende Berechtigung darf ebenfalls keinen Zugriff erhalten.

Verifikation

Security Test / Penetration Test / funktionaler Test.

Traceability

R-023 → REQ-SEC-017 → Design SEC-ARCH-004 → TC-081

Damit ist die Anforderung nicht nur ein Satz in einem Dokument.

Sie ist ein identifizierbares, prüfbares und nachverfolgbares Arbeitsergebnis .

21. Anforderungen sind keine Bürokratie

Eine häufige Kritik an Requirements Engineering lautet:

„Das erzeugt doch nur zusätzliche Dokumentation.“

Das kann tatsächlich passieren – wenn Requirements Engineering falsch verstanden wird.

IREB stellt deshalb die Value Orientation an die erste Stelle.

Nicht jede Information muss in ein 20-seitiges Dokument.

Nicht jede Anforderung benötigt dieselbe Detailtiefe.

Nicht jedes Projekt benötigt dieselben Methoden.

Entscheidend ist der Nutzen.

Bei einem kleinen internen Tool kann ein strukturierter Backlog mit guten Anforderungen vollkommen ausreichend sein.

Bei einem sicherheitskritischen oder regulierten Produkt können dagegen detaillierte Anforderungen, Traceability, Reviews, Testnachweise und formale Freigaben notwendig sein.

Die richtige Frage lautet daher nicht:

„Wie viel Dokumentation brauchen wir?“

Sondern:

„Welche Klarheit und Nachweisbarkeit brauchen wir für das Risiko, die Komplexität und den Zweck unseres Systems?“

22. Anforderungen als Bindeglied zum Qualitätsmanagement

Gerade aus Sicht des Qualitätsmanagements ist Requirements Engineering besonders interessant.

Denn Qualität entsteht nicht erst beim Test des fertigen Produkts.

Sie beginnt bereits bei der Definition dessen, was überhaupt geliefert werden soll .

Eine schlechte Anforderung kann zu:

Fehlentwicklungen
Missverständnissen
zusätzlichen Änderungsrunden
Fehltests
Abweichungen
Reklamationen
Sicherheitslücken
Verzögerungen

führen.

Eine gute Anforderung schafft dagegen eine gemeinsame Grundlage für:

Entwicklung → Test → Abnahme → Freigabe → Betrieb → Änderung

Damit wird Requirements Engineering zu einem wichtigen Bestandteil präventiver Qualitätssicherung.

23. Die wichtigste Verbindung: Anforderung → Nachweis

Aus meiner Sicht lässt sich gutes Requirements Engineering auf eine zentrale Kette reduzieren:

Bedürfnis
Anforderung
Klarheit
Abnahmekriterium
Implementierung
Test
Nachweis
Freigabe

Und bei sicherheitsrelevanten Systemen zusätzlich:

Risiko
Security Requirement
Security Control
Security Test
Nachweis

Damit wird aus Requirements Engineering eine echte Verbindung zwischen Business, Entwicklung, Qualität, Sicherheit und Compliance.

24. Fazit

Requirements Engineering nach IREB ist weit mehr als das Schreiben von Anforderungen.

Es geht darum,

Bedürfnisse zu verstehen,
Stakeholder zusammenzubringen,
Probleme von Lösungen zu unterscheiden,
Anforderungen sinnvoll zu kategorisieren,
Anforderungen eindeutig zu formulieren,
Anforderungen zu validieren,
ihre Erfüllung überprüfbar zu machen,
Änderungen kontrolliert zu behandeln und
Beziehungen zwischen Anforderungen, Risiken, Design, Implementierung und Tests nachvollziehbar zu halten.

Die neun IREB-Prinzipien liefern dafür eine wichtige Denkgrundlage:

Nutzenorientierung – Stakeholder – gemeinsames Verständnis – Kontext – Problem/Anforderung/Lösung – Validierung – Evolution – Innovation – systematisches Arbeiten.

Der vielleicht wichtigste Gedanke dabei ist:

Eine Anforderung ist nicht deshalb gut, weil sie schön formuliert ist. Sie ist gut, wenn sie das richtige Bedürfnis beschreibt, von den Beteiligten verstanden wird und eindeutig festgestellt werden kann, ob sie erfüllt wurde.

Oder noch praktischer:

Wenn Entwicklung, Test, Qualitätssicherung und Kunde dieselbe Anforderung unterschiedlich verstehen, haben wir kein Softwareproblem – wir haben ein Requirements-Problem.

Und genau deshalb beginnt gute Qualität häufig nicht beim Test.

Sie beginnt bei der Anforderung.

Quellen und weiterführende Informationen

Die Aussagen zu Definitionen, Prinzipien, Anforderungskategorien und Qualitätskriterien orientieren sich am aktuellen CPRE-Foundation-Level-Konzept und dem IREB-Glossar. IREB stellt den CPRE Foundation Level als Einstieg in professionelles Requirements Engineering dar und behandelt dort unter anderem Prinzipien, Arbeitsergebnisse, Dokumentationspraktiken, Anforderungsermittlung, Validierung und Prozessgestaltung.

Stichworte für Internetsuche

IREB – CPRE Foundation Level

IREB – CPRE Online Glossar

Ihr Konstantin Ziouras

Requirements Engineering als Qualitäts- und Sicherheitsfaktor

Tue, 22 Sep 2026 19:07:24 GMT

Requirements Engineering als Qualitäts- und Sicherheitsfaktor

Requirements Engineering als Qualitäts- und Sicherheitsfaktor

Warum strukturiertes Anforderungsmanagement für Software und vernetzte Systeme immer wichtiger wird

„Das System funktioniert doch.“

Dieser Satz kann in einem Softwareprojekt gefährlich sein.

Denn ein System kann technisch funktionieren und trotzdem die Anforderungen des Kunden nicht erfüllen. Es kann schnell genug sein, aber nicht sicher. Es kann sicher sein, aber nicht die geforderte Verfügbarkeit erreichen. Es kann alle Funktionen bereitstellen, aber nicht nachweisen können, dass regulatorische Anforderungen erfüllt wurden.

Genau hier beginnt die Bedeutung von Requirements Engineering .

Requirements Engineering – kurz RE – ist weit mehr als das Schreiben von Lasten- und Pflichtenheften oder das Verwalten von User Stories. Es schafft die Verbindung zwischen den Erwartungen der Stakeholder, den technischen Eigenschaften eines Systems, den Qualitätszielen, den Sicherheitsanforderungen und letztlich dem Nachweis, dass das entwickelte Produkt tatsächlich das leistet, was es leisten soll.

Mit zunehmender Vernetzung von Produkten und Software gewinnt dieser Zusammenhang zusätzlich an Bedeutung. Der europäische Cyber Resilience Act (CRA) stellt Anforderungen an die Cybersicherheit von Produkten mit digitalen Elementen über deren gesamten Lebenszyklus.

Damit wird eine Frage immer wichtiger:

Wie kann ein Unternehmen nachweisen, dass die relevanten Anforderungen erkannt, umgesetzt, geprüft und über den Lebenszyklus beherrscht werden?

Eine wesentliche Antwort darauf lautet: durch ein professionelles Requirements Engineering.

1. Was bedeutet Requirements Engineering?

Das International Requirements Engineering Board (IREB) beschreibt Requirements Engineering als einen systematischen und disziplinierten Ansatz zur Spezifikation und Verwaltung von Anforderungen.

Dabei geht es nicht nur darum, Anforderungen aufzuschreiben.

Requirements Engineering umfasst insbesondere:

Anforderungen ermitteln
Anforderungen analysieren
Anforderungen dokumentieren
Anforderungen validieren
Anforderungen mit Stakeholdern abstimmen
Anforderungen priorisieren
Anforderungen ändern und versionieren
Beziehungen zwischen Anforderungen und anderen Entwicklungsartefakten nachvollziehbar machen

Damit ist Requirements Engineering ein kontinuierlicher Prozess.

Eine Anforderung ist also nicht einfach ein Satz in einem Dokument.

Sie ist ein steuerndes Element des Entwicklungsprozesses .

Von einer Anforderung können beispielsweise Designentscheidungen, Testfälle, Sicherheitsmaßnahmen, Abnahmekriterien und letztlich die Freigabe eines Produktes abhängen.

2. Anforderungen sind mehr als Funktionen

Ein häufiger Fehler besteht darin, Anforderungen hauptsächlich als funktionale Anforderungen zu betrachten.

Beispiel:

„Der Benutzer muss sich am System anmelden können.“

Das beschreibt eine Funktion.

Aber für ein reales Produkt entstehen sofort weitere Fragen:

Welche Authentisierung ist erforderlich?
Muss eine Mehrfaktor-Authentisierung verwendet werden?
Was passiert bei fünf falschen Anmeldeversuchen?
Wie lange darf eine Sitzung bestehen?
Wie werden Passwörter gespeichert?
Welche Ereignisse müssen protokolliert werden?
Welche Anforderungen gelten für Administratoren?
Was passiert bei einem kompromittierten Benutzerkonto?

Damit entstehen neben den funktionalen Anforderungen weitere Anforderungen – beispielsweise an:

Sicherheit
Performance
Verfügbarkeit
Zuverlässigkeit
Bedienbarkeit
Datenschutz
Wartbarkeit
Wiederherstellbarkeit
Protokollierung
Kompatibilität

Gerade diese sogenannten Qualitäts- oder nichtfunktionalen Anforderungen werden in Projekten häufig zu spät betrachtet.

Das ist problematisch.

Denn eine Eigenschaft, die erst nach Abschluss der Entwicklung als „wichtig“ erkannt wird, lässt sich häufig nur mit erheblichem Aufwand nachrüsten.

3. Von der Anforderung zur überprüfbaren Eigenschaft

Eine gute Anforderung muss nicht nur verständlich sein.

Sie muss auch überprüfbar sein.

Eine Aussage wie:

„Das System muss eine gute Performance haben.“

ist keine ausreichend präzise Anforderung.

Was bedeutet „gut“?

Eine bessere Formulierung wäre beispielsweise:

„Das System muss 95 % aller Suchanfragen innerhalb von maximal 500 ms beantworten, gemessen unter einer definierten Last von 1.000 gleichzeitig aktiven Benutzern.“

Jetzt existieren überprüfbare Kriterien.

Die Entwicklung weiß, was erreicht werden soll.

Der Tester weiß, was geprüft werden muss.

Der Kunde weiß, was er erwarten kann.

Und das Qualitätsmanagement verfügt über ein objektives Kriterium.

Genau diese Verbindung zwischen Anforderung und Nachweis ist ein Kern des Requirements Engineering.

4. Requirements Engineering und Qualitätsmanagement

Requirements Engineering und Qualitätsmanagement haben ein gemeinsames Ziel:

Nicht erst am Ende feststellen, dass das falsche Produkt gebaut wurde.

Qualität entsteht nicht erst beim Test.

Sie beginnt mit der Frage:

Was muss das Produkt eigentlich leisten?

Das Qualitätsmanagement kann deshalb einen wichtigen Beitrag bereits bei der Definition und Bewertung von Anforderungen leisten.

Critical to Quality – CTQ

Ein besonders hilfreiches Konzept sind Critical to Quality (CTQ) -Anforderungen.

CTQs beschreiben Eigenschaften, die für die Qualität oder den geschäftlichen Erfolg eines Produktes besonders kritisch sind.

Beispiele:

CTQ - Anforderung - Nachweis

Performance - 95 % der Anfragen < 500 ms - Performance-Test

Verfügbarkeit - ≥ 99,9 % im definierten Zeitraum - Monitoring / Auswertung

Datenintegrität - Keine unbemerkte Veränderung gespeicherter Datensätze - Integritätsprüfung

Wiederherstellbarkeit - Wiederherstellung innerhalb von 4 Stunden - Recovery-Test

Security - Kontosperrung nach definierter Anzahl fehlerhafter Anmeldeversuche - Security-Test

Auditierbarkeit - sicherheitsrelevante Ereignisse werden nachvollziehbar protokolliert - Review / Test

Der entscheidende Punkt:

CTQs dürfen nicht nur als Qualitätsziele formuliert werden. Sie müssen in konkrete, überprüfbare Anforderungen übersetzt werden.

5. Abnahmekriterien: Wann ist eine Anforderung wirklich erfüllt?

Eine Anforderung ohne Abnahmekriterium lässt häufig Interpretationsspielraum.

Ein Satz wie:

„Das System muss sicher sein.“

ist praktisch nicht abnahmefähig.

Eine konkrete Anforderung könnte dagegen lauten:

„Nach fünf aufeinanderfolgenden fehlgeschlagenen Authentisierungsversuchen wird das Benutzerkonto für mindestens 15 Minuten gesperrt.“

Dazu lässt sich ein eindeutiges Abnahmekriterium formulieren:

Bei fünf unmittelbar aufeinanderfolgenden fehlerhaften Anmeldeversuchen wird das Konto gesperrt und kann während der Sperrzeit nicht erfolgreich authentisiert werden.

Damit wird aus einer abstrakten Erwartung eine prüfbare Eigenschaft.

Das ist genau die Verbindung zwischen:

Requirement → Acceptance Criteria → Test Case → Test Result

ISTQB beschreibt Akzeptanzkriterien als messbare Kriterien, anhand derer überprüft wird, ob eine Anforderung beziehungsweise User Story wie erwartet umgesetzt wurde.

Damit wird deutlich:

Testen beginnt nicht erst nach der Programmierung. Testen beginnt bei der Qualität der Anforderungen.

6. Traceability – die Verbindung zwischen Anforderung und Nachweis

Eine der wichtigsten Eigenschaften eines professionellen Requirements Engineering ist die Traceability , also die Nachverfolgbarkeit.

Eine Anforderung sollte beispielsweise mit folgenden Informationen verbunden werden können:

Stakeholder / Bedarf

↓

Requirement

↓

Risiko

↓

Architektur / Design

↓

Implementierung

↓

Testfall

↓

Testergebnis

↓

Freigabe / Nachweis

Damit kann beispielsweise auf die Frage:

„Warum existiert diese Sicherheitsfunktion?“

eine belastbare Antwort gegeben werden.

Man kann auf das zugrunde liegende Risiko, die Sicherheitsanforderung, die technische Umsetzung und den Testnachweis zurückverweisen.

Das ist nicht nur für Audits interessant.

Es hilft auch Entwicklern, Testern, Product Ownern, Qualitätsmanagern und Security-Verantwortlichen im täglichen Projektgeschäft.

7. Was passiert ohne strukturiertes Requirements Engineering?

Die Folgen eines schwachen Anforderungsmanagements sind in vielen Projekten ähnlich.

Typische Symptome sind:

unterschiedliche Vorstellungen zwischen Kunde und Entwicklung
widersprüchliche Anforderungen
nicht dokumentierte Annahmen
fehlende Qualitätsanforderungen
vergessene Sicherheitsanforderungen
fehlende Abnahmekriterien
Tests, die nicht zu den Anforderungen passen
Änderungen ohne kontrollierte Auswirkungsanalyse
hoher Aufwand für Nacharbeiten
Diskussionen über die Frage, wann ein Produkt „fertig“ ist

Besonders problematisch ist der letzte Punkt.

Wenn nicht definiert wurde, was „fertig“ bedeutet , wird die Diskussion darüber häufig erst am Ende eines Projektes geführt.

Dann ist es allerdings sehr teuer.

8. Informationssicherheit beginnt beim Requirement

Ein Penetrationstest kann Schwachstellen finden.

Er kann aber nicht feststellen, ob das Produkt überhaupt die richtigen Sicherheitsanforderungen besitzt.

Deshalb beginnt Informationssicherheit wesentlich früher.

Beispielsweise kann bereits während der Anforderungsanalyse festgelegt werden:

welche Daten geschützt werden müssen
welche Benutzergruppen existieren
welche Zugriffsrechte erforderlich sind
welche Authentisierung verwendet werden muss
welche Ereignisse protokolliert werden
welche kryptografischen Verfahren erforderlich sind
welche Schnittstellen abgesichert werden müssen
wie Updates durchgeführt werden
wie Schwachstellen behandelt werden
welche Wiederherstellungszeiten erforderlich sind

Damit werden aus allgemeinen Sicherheitszielen konkrete Security Requirements .

9. Security Requirements Engineering

Security Requirements sollten nicht einfach aus einer Checkliste kopiert werden.

Sie sollten aus dem tatsächlichen System, seinem Einsatzzweck und den relevanten Risiken abgeleitet werden.

Ein sinnvoller Zusammenhang ist beispielsweise:

Asset

→ Was ist schützenswert?

Threat

→ Was kann passieren?

Risk

→ Welche Konsequenz hat das?

Security Requirement

→ Welche Eigenschaft muss das System deshalb besitzen?

Security Control

→ Wie wird diese Eigenschaft technisch oder organisatorisch umgesetzt?

Security Test

→ Wie wird nachgewiesen, dass sie funktioniert?

Beispiel:

Asset: Kundendaten

Bedrohung: Unberechtigter Zugriff

Risiko: Offenlegung vertraulicher Informationen

Security Requirement: Zugriff auf Kundendaten darf nur nach erfolgreicher Authentisierung und entsprechender Autorisierung möglich sein.

Abnahmekriterium: Ein Benutzer ohne entsprechende Berechtigung erhält weder über die Benutzeroberfläche noch über die API Zugriff auf fremde Kundendaten.

Test: Positiver und negativer Autorisierungstest.

Damit entsteht eine nachvollziehbare Kette von Risiko bis Test.

10. Requirements Engineering und der Cyber Resilience Act

Der Cyber Resilience Act verändert die Rahmenbedingungen für Hersteller von Produkten mit digitalen Elementen.

Der CRA fordert unter anderem, dass Cybersicherheitsrisiken berücksichtigt werden und Produkte entsprechend ihrer Risiken entwickelt und produziert werden.

Zu den Anforderungen gehören unter anderem Aspekte wie:

angemessenes Cybersicherheitsniveau auf Basis der Risiken
sichere Standardkonfiguration
Begrenzung von Angriffsflächen
Schutz von Vertraulichkeit und Integrität
Schutz wesentlicher Funktionen
Sicherheitsinformationen und Logging
sichere Update-Mechanismen
Schwachstellenmanagement
regelmäßige Sicherheitsprüfungen
Dokumentation von Komponenten und Schwachstellen
Software Bill of Materials (SBOM)
technische Dokumentation

Entscheidend ist dabei nicht nur die einzelne Sicherheitsmaßnahme.

Entscheidend ist die Nachweisbarkeit über den gesamten Entwicklungs- und Produktlebenszyklus .

Genau hier entsteht eine starke Verbindung zum Requirements Engineering.

11. CRA-Anforderungen müssen in Entwicklungsanforderungen übersetzt werden

Regulatorische Anforderungen sind zunächst häufig abstrakt.

Beispielsweise lautet das Ziel:

Das Produkt soll angemessen gegen Cyberangriffe geschützt sein.

Die Entwicklung benötigt jedoch konkrete Anforderungen.

Daraus können beispielsweise Anforderungen entstehen wie:

Das Produkt muss eine sichere Standardkonfiguration besitzen.
Nicht benötigte Netzwerkdienste müssen deaktiviert sein.
Administrative Funktionen müssen authentisiert und autorisiert werden.
Sicherheitsereignisse müssen nachvollziehbar protokolliert werden.
Sicherheitsupdates müssen sicher eingespielt werden können.
Schwachstellen müssen identifiziert, bewertet und behandelt werden.
Komponenten und Abhängigkeiten müssen nachvollziehbar sein.

Damit wird aus einer regulatorischen Vorgabe eine Menge konkreter Engineering Requirements.

Und genau diese müssen wiederum:

implementiert → getestet → dokumentiert → nachgewiesen

werden.

Der CRA schreibt dabei nicht vor, dass hierfür ein bestimmtes IREB-Requirements-Engineering-Verfahren verwendet werden muss. Er schafft aber einen regulatorischen Rahmen, in dem ein strukturiertes Anforderungs-, Entwicklungs- und Nachweismanagement praktisch sehr relevant wird.

12. Der besondere Vorteil: Eine Anforderung kann mehrere Ziele gleichzeitig erfüllen

Eine sauber formulierte Anforderung kann gleichzeitig für verschiedene Management- und Engineering-Bereiche relevant sein.

Beispiel:

„Das System muss sicherheitsrelevante administrative Aktionen revisionsfähig protokollieren und die Protokolle gegen unbefugte Veränderung schützen.“

Diese eine Anforderung kann Berührungspunkte haben mit:

funktionalen Anforderungen
Qualitätsanforderungen
Informationssicherheit
Datenschutz
Risikomanagement
Testmanagement
Auditierung
regulatorischen Anforderungen

Das zeigt:

Requirements Engineering ist eine Integrationsdisziplin.

Es verbindet die unterschiedlichen Perspektiven auf ein Produkt.

13. Der wirtschaftliche Nutzen

Strukturiertes Requirements Engineering wird manchmal als zusätzlicher Dokumentationsaufwand betrachtet.

Das greift zu kurz.

Der eigentliche Nutzen entsteht dadurch, dass Fehler möglichst früh erkannt werden.

Eine unklare Anforderung verursacht zunächst vielleicht nur eine Diskussion.

Später kann daraus ein falsches Design entstehen.

Noch später eine falsche Implementierung.

Danach entstehen Testfehler.

Und am Ende möglicherweise eine Änderung kurz vor der Freigabe.

Je später ein grundlegendes Missverständnis entdeckt wird, desto größer sind typischerweise die Auswirkungen.

Requirements Engineering verschiebt deshalb einen Teil der Problemlösung nach vorne – dorthin, wo Änderungen noch vergleichsweise einfach möglich sind.

14. Was bedeutet das für Unternehmen?

Ein wirksames Requirements Engineering benötigt nicht zwangsläufig ein großes Bürokratiemonster.

Es benötigt vor allem klare Spielregeln.

Zum Beispiel:

1. Einheitliche Qualitätskriterien für Anforderungen

Jede wichtige Anforderung sollte beispielsweise auf folgende Fragen geprüft werden:

Ist sie eindeutig?
Ist sie verständlich?
Ist sie vollständig?
Ist sie widerspruchsfrei?
Ist sie eindeutig identifiziert?
Ist sie testbar?
Ist sie priorisiert?
Ist ihre Quelle bekannt?

2. Abnahmekriterien bereits bei der Anforderung

Nicht:

Requirement heute – Test irgendwann später.

Sondern:

Requirement und Nachweisbarkeit gemeinsam denken.

3. Security früh integrieren

Security Requirements gehören in die Anforderungsphase und nicht ausschließlich in den Penetrationstest vor der Auslieferung.

4. Traceability etablieren

Nicht jede Information muss mit jeder anderen Information verknüpft werden.

Aber für kritische Anforderungen sollte nachvollziehbar sein:

Woher kommt die Anforderung – warum existiert sie – wie wurde sie umgesetzt – wie wurde sie geprüft?

5. Änderungen kontrollieren

Eine neue Anforderung kann Auswirkungen auf Architektur, Security, Tests, Dokumentation und Zulassung haben.

Deshalb braucht Requirements Management auch ein funktionierendes Change Management.

15. Die entscheidende Verbindung

Am Ende lässt sich Requirements Engineering auf eine einfache Frage reduzieren:

Was muss das Produkt können – und wie können wir beweisen, dass es das tatsächlich kann?

Für moderne Software und softwarebasierte Systeme reicht diese Frage jedoch noch nicht ganz aus.

Hinzu kommen:

Warum muss das Produkt diese Eigenschaft besitzen?

Welches Risiko wird damit behandelt?

Welche Qualitätsanforderung steckt dahinter?

Welche Sicherheitsanforderung ergibt sich daraus?

Wie wird die Anforderung getestet?

Welcher Nachweis bleibt nach der Entwicklung bestehen?

Damit entsteht eine belastbare Engineering-Kette:

Need → Requirement → Risk → Design → Implementation → Test → Evidence

Und genau diese Kette verbindet Requirements Engineering mit Qualitätsmanagement, Informationssicherheit und regulatorischen Anforderungen.

Fazit

Requirements Engineering ist keine reine Dokumentationsdisziplin.

Es ist eine Methode, um Komplexität beherrschbar zu machen.

Ein strukturiertes Anforderungsmanagement schafft Klarheit darüber,

was ein Produkt leisten muss,
welche Qualitätsmerkmale kritisch sind,
welche Risiken berücksichtigt werden müssen,
welche Sicherheitsfunktionen erforderlich sind,
wie Anforderungen getestet werden,
wann ein Produkt tatsächlich abnahmefähig ist
und wie die Erfüllung der Anforderungen nachgewiesen werden kann.

Gerade bei Software und vernetzten Produkten wird diese Fähigkeit immer wichtiger.

Der Cyber Resilience Act verstärkt diese Entwicklung: Cybersicherheit muss bereits in Entwicklung und Produktlebenszyklus berücksichtigt und durch geeignete Nachweise belegbar gemacht werden.

Dabei geht es nicht darum, noch mehr Dokumente zu produzieren.

Es geht darum, die richtigen Fragen frühzeitig zu stellen.

Denn ein Grundsatz gilt für Software genauso wie für klassische Produkte:

Was nicht eindeutig gefordert wurde, kann schwerlich eindeutig entwickelt werden.

Und was nicht eindeutig definiert wurde, lässt sich später nur schwer objektiv prüfen.

Requirements Engineering schafft deshalb die Verbindung zwischen Anforderung, Qualität, Sicherheit und Nachweis .

Nicht mehr Dokumentation ist das Ziel.

Mehr Klarheit ist das Ziel.

P.S. und die Geschichte wird komplizierter, spannender und ganzheitlicher��

Requirements Engineering als Bindeglied zwischen Qualitätsmanagement und Informationssicherheit

Requirements Engineering steht nicht isoliert neben dem Qualitätsmanagement und dem Informationssicherheitsmanagement.

Im Gegenteil:

Ein strukturiertes Requirements Engineering verbindet zentrale Anforderungen der ISO 9001 mit den Anforderungen der ISO/IEC 27001 und schafft damit eine gemeinsame Grundlage für Entwicklung, Qualitätssicherung und Informationssicherheit.

Für Unternehmen, die Software oder softwarebasierte Produkte entwickeln, entsteht dadurch ein besonders interessanter Zusammenhang:

ISO 9001 beschreibt, wie Anforderungen an Produkte und Dienstleistungen systematisch bestimmt, entwickelt, umgesetzt und überprüft werden.

ISO/IEC 27001 ergänzt diese Perspektive um die systematische Behandlung von Informationssicherheitsrisiken und Sicherheitsanforderungen.

Requirements Engineering kann diese beiden Perspektiven in einem gemeinsamen Entwicklungsprozess zusammenführen.

1. ISO 9001:2015 – Requirements Engineering aus Sicht des Qualitätsmanagements

Die ISO 9001:2015 fordert nicht ausdrücklich einen Prozess mit der Bezeichnung „Requirements Engineering“.

Sie enthält jedoch eine Reihe von Anforderungen, die sich unmittelbar mit den Inhalten eines professionellen Requirements Engineering überschneiden.

Besonders relevant sind die Kapitel:

8.1 – Betriebliche Planung und Steuerung
8.2 – Anforderungen an Produkte und Dienstleistungen
8.3 – Entwicklung von Produkten und Dienstleistungen
8.4 – Steuerung von extern bereitgestellten Prozessen, Produkten und Dienstleistungen
8.5 – Produktion und Dienstleistungserbringung
8.5.6 – Steuerung von Änderungen
8.6 – Freigabe von Produkten und Dienstleistungen
8.7 – Steuerung nichtkonformer Ergebnisse
9.1 – Überwachung, Messung, Analyse und Bewertung
10.2 – Nichtkonformität und Korrekturmaßnahmen

Besonders deutlich wird die Verbindung bei 8.2 und 8.3 .

Die ISO-9001-Auditing-Practices-Guidance beschreibt Design und Entwicklung ausdrücklich als einen Prozess, in dem Anforderungen in spezifizierte Produkt- beziehungsweise Serviceeigenschaften überführt werden.

Das ist im Kern genau die Aufgabe des Requirements Engineering.

2. ISO 9001 Kapitel 8.2 – Anforderungen an Produkte und Dienstleistungen

Kapitel 8.2 ist für Requirements Engineering besonders interessant.

Hier geht es darum, Anforderungen an Produkte und Dienstleistungen zu bestimmen und zu überprüfen.

Aus Sicht des Requirements Engineering bedeutet dies beispielsweise:

Kundenanforderung

→ Was erwartet der Kunde?

Gesetzliche/regulatorische Anforderungen

→ Was muss aufgrund externer Vorgaben erfüllt werden?

Weitere Anforderungen der Organisation

→ Welche zusätzlichen Anforderungen ergeben sich aus Strategie, Qualität, Security oder internen Standards?

Review

→ Sind die Anforderungen eindeutig und erfüllbar?

Kommunikation

→ Sind die relevanten Anforderungen an Entwicklung, Test und andere Beteiligte kommuniziert?

Damit entsteht eine direkte Verbindung zwischen ISO 9001 und Requirements Engineering.

Ein professionelles Requirements-Engineering-Verfahren kann deshalb als praktische Umsetzung dieser Anforderungen dienen.

3. ISO 9001 Kapitel 8.3 – Entwicklung und Requirements Engineering

Noch enger wird die Verbindung bei 8.3 – Design und Entwicklung von Produkten und Dienstleistungen .

Für ein Softwareunternehmen ist dieser Abschnitt besonders relevant.

Requirements Engineering liefert dabei die Grundlage für die Entwicklung.

Vereinfacht:

8.2 – Was wird benötigt?

↓

Requirements Engineering – Was bedeutet diese Anforderung konkret?

↓

8.3.3 – Design- und Entwicklungsinputs

↓

Architektur / Design

↓

Implementierung

↓

Verifikation und Validierung

↓

8.3.5 – Design- und Entwicklungsergebnisse

↓

8.3.6 – Änderungen

Die Auditing-Practices-Guidance der ISO/IAF beschreibt genau diese Funktion von Design und Entwicklung: Anforderungen werden in spezifizierte Produkt- bzw. Serviceeigenschaften überführt.

Für Softwareentwicklung bedeutet das beispielsweise:

Requirements Engineering - ISO 9001:2015

Kundenanforderungen - 8.2

System Requirements - 8.3.3

Qualitätsanforderungen - 8.3.3

Security Requirements - 8.3.3

Architekturentscheidungen - 8.3.4

Design Reviews - 8.3.4

Verifikation - 8.3.4 / 8.3.5

Validierung - 8.3.4 / 8.3.5

Designänderungen - 8.3.6

Abnahmekriterien - 8.6

Nicht erfüllte Anforderungen - 8.7 / 10.2

Damit wird deutlich:

Requirements Engineering ist praktisch ein wesentlicher Bestandteil eines beherrschten Entwicklungsprozesses nach ISO 9001.

4. CTQ-Anforderungen und ISO 9001

Das im Artikel beschriebene Konzept der Critical to Quality (CTQ) -Anforderungen lässt sich ebenfalls sehr gut mit ISO 9001 verbinden.

Beispiel:

Das System muss bei 1.000 gleichzeitig aktiven Benutzern 95 % der Anfragen innerhalb von 500 ms beantworten.

Aus RE-Sicht ist dies eine nichtfunktionale Anforderung.

Aus QM-Sicht ist sie ein objektiv überprüfbares Qualitätsmerkmal.

Daraus können entstehen:

Requirement → Performance-Anforderung

CTQ → Antwortzeit

Acceptance Criterion → 95 % < 500 ms

Test Case → definierter Lasttest

Test Result → Messergebnis

Release Decision → Anforderung erfüllt / nicht erfüllt

Damit wird aus einem Qualitätsziel ein objektiver Nachweis .

Genau diese Verbindung zwischen Anforderungen, Akzeptanzkriterien, Prüfung und Freigabe ist für ein wirksames Qualitätsmanagement wesentlich. Die ISO-9001-Leitlinien zur dokumentierten Information nennen beispielsweise Nachweise zur Freigabe einschließlich Akzeptanzkriterien und Rückverfolgbarkeit.

5. ISO 9001 Kapitel 8.6 – Abnahme und Freigabe

Hier wird ein weiterer wichtiger Punkt aus dem ursprünglichen Artikel besonders deutlich:

Eine Anforderung sollte bereits bei ihrer Definition so formuliert werden, dass später festgestellt werden kann, ob sie erfüllt wurde.

Requirements Engineering und Qualitätsmanagement treffen sich damit bei der Frage:

Wann darf ein Produkt freigegeben werden?

Beispiel:

Nicht:

„Das System muss sicher funktionieren.“

Sondern:

„Nach fünf aufeinanderfolgenden fehlgeschlagenen Authentisierungsversuchen wird das Benutzerkonto für mindestens 15 Minuten gesperrt.“

Daraus lassen sich direkt:

Abnahmekriterien
Testfälle
Testergebnisse
Freigabekriterien

ableiten.

Das ist eine sehr starke Verbindung zwischen RE und ISO 9001.

6. ISO 9001 Kapitel 8.5.6 – Änderungen

Software lebt von Änderungen.

Neue Funktionen, Fehlerkorrekturen, Sicherheitsupdates, Änderungen von Schnittstellen oder Änderungen von Abhängigkeiten können Auswirkungen auf bereits bestehende Anforderungen haben.

Deshalb gehört Change Management unmittelbar zum Requirements Management.

Eine Änderung sollte beispielsweise die Frage beantworten:

Welche bestehenden Anforderungen, Risiken, Tests und Nachweise sind von dieser Änderung betroffen?

Damit entsteht eine Verbindung:

Change Request

→ betroffene Requirements

→ betroffene Risiken

→ betroffene Architektur

→ betroffene Softwarekomponenten

→ betroffene Tests

→ erneute Verifikation

→ Freigabe

Die ISO/IAF-Guidance nennt bei Änderungen unter anderem die Dokumentation der Änderung, deren Überprüfung und die dafür autorisierten Personen.

7. ISO/IEC 27001:2022 – die Security-Perspektive

Während ISO 9001 den Schwerpunkt auf die Fähigkeit legt, Produkte und Dienstleistungen entsprechend den Anforderungen bereitzustellen, betrachtet ISO/IEC 27001 das Thema aus der Perspektive des Informationssicherheitsrisikomanagements.

ISO/IEC 27001:2022 definiert Anforderungen an ein Information Security Management System (ISMS).

Für Requirements Engineering sind insbesondere die Kapitel 6 und 8 sowie verschiedene Controls aus Annex A relevant.

Besonders wichtig sind:

6.1.1 – Maßnahmen zur Behandlung von Risiken und Chancen
6.1.2 – Informationssicherheits-Risikobeurteilung
6.1.3 – Behandlung von Informationssicherheitsrisiken
6.2 – Informationssicherheitsziele
6.3 – Planung von Änderungen
8.1 – Betriebliche Planung und Steuerung
8.2 – Informationssicherheits-Risikobeurteilung
8.3 – Behandlung von Informationssicherheitsrisiken

Damit entsteht eine zweite Kette:

Asset

→ Threat

→ Risk

→ Security Requirement

→ Security Control

→ Security Test

→ Evidence

Das ist die Security-Variante der bereits beschriebenen Requirements-Kette.

8. ISO/IEC 27001:2022 Annex A – direkte Verbindung zur Softwareentwicklung

Besonders interessant für Softwarehersteller sind die Controls A.8.25 bis A.8.34 .

Hier findet sich ein regelrechter „Security Requirements Engineering Block“.

A.8.25 – Secure Development Life Cycle

Ein sicherer Entwicklungslebenszyklus muss etabliert und angewendet werden.

Das betrifft beispielsweise:

Security bereits in der Planung
Security Requirements
sichere Architektur
sichere Implementierung
Security Testing
Security im gesamten Entwicklungsprozess

A.8.26 – Application Security Requirements

Hier wird die Verbindung zum Requirements Engineering besonders unmittelbar.

Bei der Entwicklung oder Beschaffung von Anwendungen müssen Informationssicherheitsanforderungen identifiziert, spezifiziert und genehmigt werden.

Das ist praktisch eine direkte Security-Requirements-Engineering-Anforderung.

A.8.27 – Secure System Architecture and Engineering Principles

Security Requirements müssen sich anschließend in Architektur und Engineering wiederfinden.

Eine Anforderung wie:

„Mandantendaten müssen voneinander getrennt sein.“

ist beispielsweise nicht nur eine funktionale Anforderung.

Sie kann eine konkrete Auswirkung auf die Systemarchitektur haben.

A.8.28 – Secure Coding

Aus den Anforderungen und Architekturprinzipien entstehen konkrete Regeln für die Implementierung.

A.8.29 – Security Testing in Development and Acceptance

Hier schließt sich die Kette wieder:

Security Requirement

→ Implementierung

→ Security Test

→ Acceptance

A.8.30 – Outsourced Development

Auch bei ausgelagerter Entwicklung dürfen Anforderungen nicht einfach „an den Dienstleister abgegeben“ werden.

Die Organisation muss die Entwicklung steuern, überwachen und überprüfen.

A.8.32 – Change Management

Änderungen an Software und Systemen müssen kontrolliert werden.

Damit besteht erneut eine direkte Verbindung zu Requirements Management.

Die Controls A.8.25–A.8.34 bilden damit einen besonders relevanten Teil der ISO/IEC 27001:2022 für einen sicheren Softwareentwicklungsprozess.

9. Eine gemeinsame Sicht auf ISO 9001 und ISO/IEC 27001

Besonders interessant wird es, wenn man beide Managementsysteme gemeinsam betrachtet.

Requirements-Engineering-Aktivität - ISO 9001:2015 - ISO/IEC 27001:2022

Kundenanforderungen ermitteln - 8.2 - 4.2 / 6.1

regulatorische Anforderungen - 8.2 - 4.2 / 6.1

Anforderungen analysieren - 8.2 / 8.3 - 6.1 / 8.2

Qualitätsanforderungen - 8.3.3 - 6.2 / risikobezogen

CTQ - 8.3.3 / 8.5 / 8.6 - risikobezogen

Security Requirements - 8.3.3 - 6.1.2 / 6.1.3 / A.8.26

Architektur - 8.3.4 - A.8.27

Secure Development - 8.3 - A.8.25

Secure Coding - 8.5 / 8.3 - A.8.28

Security Testing - 8.3.4 / 8.6 - A.8.29

Abnahmekriterien - 8.6 - A.8.29

Traceability - 8.3 / 8.5.2 / 8.6 - 6.1 / 8 / A.8

Änderungsmanagement - 8.3.6 / 8.5.6 - 6.3 / A.8.32

Lieferantenentwicklung - 8.4 - A.5.19–A.5.22 / A.8.30

Nichtkonformitäten - 8.7 / 10.2 - A.5.24–A.5.28, je nach Sachverhalt

Verbesserung - 10 - 10

Die Tabelle sollte dabei nicht als formales 1:1-Mapping der beiden Normen verstanden werden. Sie zeigt vielmehr, wo sich die Themen fachlich überschneiden und durch einen gemeinsamen Prozess sinnvoll integrieren lassen .

10. Der eigentliche Mehrwert eines integrierten Ansatzes

Für ein Unternehmen, das beispielsweise eine Cloud-Anwendung entwickelt, könnte eine einzige Anforderung mehrere Perspektiven gleichzeitig bedienen.

Beispiel:

„Administrative Benutzer müssen sich vor dem Zugriff auf privilegierte Funktionen mit einer starken Authentisierung authentisieren. Fehlgeschlagene Authentisierungsversuche sind zu protokollieren.“

Daraus können entstehen:

Requirements Engineering

Security Requirement
Functional Requirement
Acceptance Criteria

Qualitätsmanagement

CTQ
Prüfkriterium
Testfall
Freigabekriterium

Informationssicherheit

Risiko
Security Control
Logging
Authentication

Softwareentwicklung

Architekturentscheidung
Implementierung
Secure Coding
Security Test

Audit / Compliance

Requirement
Risiko
Umsetzung
Testnachweis
Freigabenachweis

Das ist der eigentliche Vorteil eines integrierten Ansatzes:

Eine sauber definierte Anforderung kann mehrere Managementsysteme und Entwicklungsaktivitäten miteinander verbinden.

11. Requirements Engineering als gemeinsamer Prozess für QMS und ISMS

Aus diesen Zusammenhängen lässt sich ein integrierter Prozess ableiten:

Schritt 1 – Anforderungen ermitteln

Kunden, Benutzer, Markt, Gesetzgebung und interne Organisation.

Schritt 2 – Anforderungen klassifizieren

Zum Beispiel:

funktional
Qualität
Performance
Security
Safety
Regulatory
Usability
Business Continuity

Schritt 3 – Risiken analysieren

Welche Risiken entstehen, wenn eine Anforderung nicht erfüllt wird?

Schritt 4 – Anforderungen spezifizieren

Eindeutig, messbar, testbar und priorisiert.

Schritt 5 – Design und Architektur

Wie wird die Anforderung technisch umgesetzt?

Schritt 6 – Implementierung

Entwicklung entsprechend den definierten Anforderungen.

Schritt 7 – Verifikation und Validierung

Wurde die Anforderung korrekt umgesetzt?

Und:

Erfüllt das Produkt tatsächlich den vorgesehenen Zweck?

Schritt 8 – Nachweis

Requirement → Test → Ergebnis → Freigabe.

Schritt 9 – Änderungsmanagement

Was ändert sich bei neuen Anforderungen, Schwachstellen oder regulatorischen Vorgaben?

12. Und hier kommt der CRA ins Spiel

Der Cyber Resilience Act erweitert diese Betrachtung um regulatorische Anforderungen an die Cybersicherheit von Produkten mit digitalen Elementen.

Damit entsteht für Hersteller eine besonders interessante Dreiecksbeziehung:

ISO 9001

→ Produkt- und Prozessqualität

ISO/IEC 27001

→ Informationssicherheitsrisiken und Security Management

CRA

→ regulatorische Cybersicherheitsanforderungen für betroffene Produkte

Requirements Engineering kann diese drei Perspektiven miteinander verbinden.

Das bedeutet beispielsweise:

CRA-Anforderung

Security Requirement

Risk Assessment

Design Requirement

Implementierung

Security Test

Acceptance Criterion

Technical Documentation

Nachweis der Erfüllung

Damit wird Requirements Engineering zu einem wichtigen Bindeglied zwischen Managementsystem und Produktentwicklung.

13. Die Konsequenz für Unternehmen

Für Unternehmen, die gleichzeitig Qualitätsmanagement, Informationssicherheitsmanagement und Produkt-Compliance beherrschen müssen, liegt deshalb eine wichtige Erkenntnis nahe:

Requirements Engineering sollte nicht ausschließlich Aufgabe der Entwicklung sein.

Es ist eine gemeinsame Schnittstelle von:

Produktmanagement
Entwicklung
Qualitätsmanagement
Informationssicherheit
Risikomanagement
Testmanagement
Compliance
gegebenenfalls Regulatory Affairs

Die entscheidende Frage lautet daher nicht:

„Wer schreibt unsere Anforderungen?“

Sondern:

„Wie stellen wir sicher, dass alle relevanten Anforderungen erkannt, bewertet, umgesetzt, getestet und nachgewiesen werden?“

Genau hier beginnt ein professionelles Requirements Engineering.

Fazit

ISO 9001, ISO/IEC 27001 und der Cyber Resilience Act sind keine drei voneinander isolierten Themen.

Für einen Softwarehersteller lassen sie sich entlang des Produktlebenszyklus miteinander verbinden:

Anforderung

→ Risiko

→ Qualität

→ Security

→ Design

→ Implementierung

→ Test

→ Abnahme

→ Nachweis

→ Änderung

→ Verbesserung

ISO 9001 liefert dabei den Rahmen für die systematische Beherrschung von Kunden-, Produkt- und Entwicklungsanforderungen.

ISO/IEC 27001 ergänzt die Perspektive des Informationssicherheitsrisikomanagements und enthält mit A.8.25 bis A.8.34 besonders relevante Controls für die sichere Softwareentwicklung.

Der CRA bringt zusätzlich regulatorische Anforderungen an die Cybersicherheit von Produkten mit digitalen Elementen und deren Lebenszyklus hinzu.

Requirements Engineering kann diese Anforderungen in eine gemeinsame, nachvollziehbare Struktur überführen.

Damit wird aus Requirements Engineering mehr als eine Methode der Softwareentwicklung: Es wird zu einem verbindenden Prozess zwischen Produktqualität, Informationssicherheit, Risikomanagement und Compliance.

Ihr Konstantin Ziouras

Unterschiede zwischen EULA, SLA und AVV

Mon, 18 May 2026 18:38:36 GMT

Unterschiede zwischen EULA, SLA und AVV

Ein paar Gedanken zu Verträgen

1. EULA – End User License Agreement

Was ist es? Ein Nutzungsvertrag zwischen Softwarehersteller und Anwender.

Regelt vor allem:

Nutzungsrechte (z. B. Anzahl Geräte, kommerzielle Nutzung)
Verbote (Reverse Engineering, Weitergabe)
Haftungsausschlüsse
Update‑ und Wartungsbedingungen
Telemetrie & Datennutzung
Beendigung der Nutzung

Zweck:

Die EULA definiert, wie du die Software nutzen darfst – und was du nicht darfst.

2. SLA – Service Level Agreement

Was ist es? Ein Leistungsversprechen des Anbieters, meist bei Cloud‑ oder IT‑Services.

Regelt vor allem:

Verfügbarkeit (z. B. 99,9 %)
Reaktionszeiten
Supportzeiten
Eskalationsprozesse
Kompensationen bei Ausfällen

Zweck:

Das SLA definiert, welche Servicequalität du bekommst.

3. AVV – Auftragsverarbeitungsvertrag (DSGVO Art. 28)

Was ist es? Ein Datenschutzvertrag , wenn ein Dienstleister personenbezogene Daten verarbeitet.

Regelt vor allem:

Datenarten & Zwecke
Sicherheitsmaßnahmen
Subunternehmer
Löschfristen
Kontrollrechte
Datenübermittlungen in Drittstaaten

Zweck:

Die AVV definiert, wie personenbezogene Daten geschützt werden müssen.

Wie berücksichtigt man EULA‑Risiken in der Softwarebewertung?

Die EULA ist oft ein großer versteckter Risikotreiber bei Software. Hier sind die wichtigsten Kriterien, die du prüfen musst:

1. Nutzungsrechte

Risiko:

Nutzung nur auf bestimmten Geräten
Nutzung nur durch namentlich benannte User
Verbot von Mehrfachinstallationen

Bewertung:

Passt das Lizenzmodell zu deinem Einsatzszenario?
Gibt es Einschränkungen, die später teuer werden?

2. Lizenzrestriktionen

Risiko:

Verbot von Automatisierung
Verbot von API‑Zugriffen
Verbot von Customizing

Bewertung:

Behindert die EULA deine Prozesse oder Integrationen?

3. Haftungsausschlüsse

Risiko:

Hersteller übernimmt keine Verantwortung für Datenverlust
Keine Garantie für Fehlerfreiheit
Haftung oft stark begrenzt

Bewertung:

Passt die Haftungsregelung zu deinem Risikoprofil?

4. Update‑ und Supportbedingungen

Risiko:

Updates nur gegen Aufpreis
Support nur eingeschränkt
Keine garantierten Reaktionszeiten

Bewertung:

Wie lange ist die Software zukunftssicher?
Gibt es EOL‑Risiken?

5. Datenschutz & Telemetrie

Risiko:

Software sendet Daten an den Hersteller
Unklare Datenverarbeitungszwecke
Keine AVV möglich

Bewertung:

Ist die Nutzung DSGVO‑konform?
Werden sensible Daten übertragen?

6. Beendigung & Exit‑Regeln

Risiko:

Nutzung endet sofort bei Vertragskündigung
Keine Exportfunktion
Datenverlust möglich

Bewertung:

Wie gut ist die Exit‑Strategie?
Gibt es Vendor‑Lock‑in‑Risiken?

Ergo

EULA, SLA und AVV haben völlig unterschiedliche Zwecke:

EULA → Wie darfst du die Software nutzen?
SLA → Welche Servicequalität bekommst du?
AVV → Wie werden personenbezogene Daten geschützt?

Bei der Softwarebewertung ist die EULA ein zentraler Risikofaktor, weil sie:

Nutzung einschränken kann
Integrationen verhindern kann
Haftung ausschließt
Datenschutzrisiken erzeugt
Vendor Lock‑in verstärken kann

Wer diese Risiken systematisch prüft, bewertet Software nicht nur technisch , sondern rechtlich, wirtschaftlich und strategisch !

Unterschiede und Parallelen für Bewertungen (Lieferanten, Software, Cloud-Dienstleistern)

Mon, 18 May 2026 18:30:31 GMT

Unterschiede und Parallelen bezüglich Bewertungen, bezüglich Lieferanten, Software, Cloud Dienstleistern

Lieferant, Software oder Cloud-Dienst?

Unterschiede und Parallelen bei der Bewertung

Bei Auswahl und Bewertung externer Leistungen kommt es immer wieder zu Verwechslungen.

Ist die Bewertung einer Software eigentlich eine Lieferantenbewertung?

Ist ein Cloud Provider nur ein weiterer IT-Lieferant?

Und gelten für die Auswahl einer Software dieselben Kriterien wie für die Auswahl eines klassischen Produktions- oder Logistiklieferanten?

Die Antwort lautet: teilweise.

Die grundlegenden Bewertungsmethoden sind häufig ähnlich. Bewertungsobjekt, Risikotreiber und Schwerpunkte unterscheiden sich jedoch deutlich.

Dieser Artikel soll helfen, die Begriffe und Bewertungsansätze voneinander zu unterscheiden.

1. Zunächst eine wichtige Abgrenzung

Die drei Begriffe beschreiben nicht vollständig dieselbe Ebene.

Ein Lieferant ist zunächst eine Organisation, von der ein Unternehmen eine Leistung, ein Produkt oder eine Dienstleistung bezieht.

Eine Software ist dagegen ein Produkt bzw. eine technische Lösung.

Ein Cloud-Dienst ist eine bereitgestellte Dienstleistung, bei der Software, Plattform oder Infrastruktur über einen Anbieter betrieben bzw. bereitgestellt wird.

Damit kann beispielsweise gelten:

Ein Cloud Provider ist gleichzeitig ein Lieferant – aber die Bewertung seiner Cloud-Leistung erfordert zusätzliche Kriterien.

Ebenso kann ein Softwarehersteller ein Lieferant sein.

Die eigentliche Frage lautet deshalb:

Was genau wird bewertet – die Organisation, das Produkt, die Dienstleistung oder die daraus entstehende Abhängigkeit?

Diese Unterscheidung ist für eine belastbare Bewertung entscheidend.

2. Bewertung klassischer Lieferanten

Hier geht es beispielsweise um:

Hersteller
Produktionsunternehmen
Logistikdienstleister
Wartungsunternehmen
Beratungsunternehmen
externe Dienstleister
Facility Management
technische Dienstleister

Was wird bewertet?

Typische Kriterien sind:

Qualität und Prozessfähigkeit
Lieferfähigkeit
Termintreue
Mengentreue
Reklamationsquote
Informationssicherheit
wirtschaftliche Stabilität
finanzielle Leistungsfähigkeit
Subunternehmer
Lieferkette
Standort- und geografische Risiken
Nachhaltigkeit
rechtliche und regulatorische Anforderungen

Je nach Branche können außerdem beispielsweise menschenrechtliche und umweltbezogene Sorgfaltspflichten relevant sein.

Dabei sollte jedoch nicht pauschal angenommen werden, dass das Lieferkettensorgfaltspflichtengesetz (LkSG) für jeden Lieferanten und jedes Unternehmen gleichermaßen anzuwenden ist. Entscheidend ist der jeweilige gesetzliche Anwendungsbereich.

Typische Risiken

Lieferengpässe
Qualitätsmängel
Produktionsausfälle
verspätete Lieferung
Abhängigkeit von einzelnen Lieferanten
Sub-Lieferantenrisiken
geopolitische Risiken
finanzielle Schwierigkeiten
physische Sicherheitsrisiken
mangelnde Ausweichmöglichkeiten

Besonderheiten

Der Schwerpunkt liegt häufig auf:

Lieferfähigkeit → Qualität → Kosten → Prozessfähigkeit → Resilienz

Bei physischen Produkten kommen beispielsweise hinzu:

Transport
Lagerung
Verpackung
Zoll
Incoterms (International Commercial Terms)
Materialqualität
Produktionskapazitäten

Auch die Vertragsbeziehung ist häufig langfristig angelegt, beispielsweise über Rahmenverträge oder mehrjährige Liefervereinbarungen.

3. Bewertung von Software

Bei Software steht zunächst nicht die Organisation des Herstellers im Mittelpunkt, sondern das Produkt bzw. die technische Lösung .

Beispiele:

On-Premise-Software
lokal installierte Software
Standardsoftware
Individualsoftware
Fachanwendungen
Entwicklungswerkzeuge
Security Software

Was wird bewertet?

Typische Kriterien sind:

Funktionsumfang
fachliche Eignung
Usability
Performance
Systemkompatibilität
Integrationsfähigkeit
Schnittstellen und APIs
Architektur
Skalierbarkeit
Wartbarkeit
Informationssicherheit
Schwachstellenmanagement
Update- und Patchfähigkeit
Support
Roadmap
EOL-/End-of-Support-Strategie

Eine Fit-Gap-Analyse ist dabei ein wichtiges Instrument:

Was kann die Software bereits – und welche Anforderungen werden nicht oder nur mit Anpassungen erfüllt?

4. Typische Risiken bei Software

Beispiele sind:

Bugs und Fehlfunktionen
Sicherheitslücken
bekannte Schwachstellen bzw. CVEs
fehlende Sicherheitsupdates
Integrationsprobleme
unzureichende Schnittstellen
mangelnde Benutzerakzeptanz
Abhängigkeit vom Hersteller
fehlende Dokumentation
End of Life
fehlender Support
proprietäre Datenformate
schwierige Migration
fehlende Weiterentwicklung

Gerade bei geschäftskritischer Software ist deshalb die Frage nach dem Lebenszyklus entscheidend:

Wie lange wird die Software unterstützt, aktualisiert und sicher betrieben?

5. Software ist nicht nur eine Funktionsbewertung

Eine Software kann fachlich hervorragend geeignet sein und trotzdem ein erhebliches Risiko darstellen.

Beispielsweise:

Software A

erfüllt 95 % der Anforderungen
gute Usability
günstiger Preis

aber:

keine regelmäßigen Sicherheitsupdates
Hersteller beendet den Support in zwei Jahren
proprietäres Datenformat
keine brauchbaren Exportmöglichkeiten

Software B

erfüllt nur 90 % der Anforderungen
etwas höhere Kosten

aber:

klare Roadmap
regelmäßige Sicherheitsupdates
offene Schnittstellen
gute Exportmöglichkeiten
definierter Supportzeitraum

Die bessere Entscheidung ist deshalb nicht zwangsläufig die Software mit dem höchsten Funktionsumfang.

6. Bewertung von Cloud-Dienstleistern

Cloud-Dienste unterscheiden sich wesentlich von klassischer On-Premise-Software.

Beispiele:

SaaS (Software as a Service)
PaaS (Platform as a Service)
IaaS (Infrastructure as a Service)
Cloud Storage
Cloud-Datenbanken
Cloud Security Services
CRM- und ERP-Plattformen

Hier wird nicht nur ein Produkt gekauft.

Der Anbieter übernimmt einen Teil des Betriebs und der technischen Verantwortung .

Damit verschiebt sich die Bewertung stärker in Richtung:

Service → Betrieb → Sicherheit → Verfügbarkeit → Abhängigkeit

7. Was wird bei Cloud-Diensten bewertet?

Typische Kriterien sind:

Verfügbarkeit
SLA
Performance
Datensicherheit
Datenschutz
Datenverarbeitung
Datenlokation
Rechtsraum
Mandantentrennung
Identitäts- und Berechtigungsmanagement
Verschlüsselung
Protokollierung
Backup und Recovery
Business Continuity
Incident Management
Subunternehmer
Shared Responsibility
Skalierbarkeit
Integrationsfähigkeit
Exit- und Migrationsmöglichkeiten

Bei Cloud-Diensten ist außerdem besonders wichtig:

Wer ist wofür verantwortlich?

Das wird häufig über das Shared-Responsibility-Modell beschrieben.

8. Typische Risiken bei Cloud-Diensten

Beispiele:

Ausfall des Dienstes
Datenverlust
Fehlkonfiguration
unzureichende Berechtigungen
Sicherheitsvorfälle beim Provider
Datenschutzrisiken
Abhängigkeit vom Anbieter
Vendor Lock-in
fehlende Exit-Möglichkeiten
unzureichende Backup-/Recovery-Möglichkeiten
Abhängigkeit von Subunternehmern
Änderungen des Cloud-Angebots
Änderung von Preisen oder Vertragsbedingungen
Änderung der Datenlokation
Einschränkungen durch den Rechtsraum

Gerade bei Cloud-Diensten sollte deshalb eine Frage immer gestellt werden:

Was passiert, wenn wir diesen Dienst morgen nicht mehr nutzen können?

9. Der entscheidende Unterschied: Produkt oder laufender Service?

Ein wesentlicher Unterschied zwischen Software und Cloud liegt im Betriebsmodell.

Bei einer klassischen On-Premise-Software kann das Unternehmen beispielsweise selbst für folgende Punkte verantwortlich sein:

Server
Betriebssystem
Netzwerk
Backup
Updates
Berechtigungen
Verfügbarkeit
Monitoring

Bei einem Cloud-Service werden diese Aufgaben teilweise oder weitgehend vom Provider übernommen.

Damit verschiebt sich das Risiko.

Aus:

„Ist die Software sicher?“

wird zusätzlich:

„Wie sicher und zuverlässig wird der Service betrieben?“

10. Was alle drei Bewertungen gemeinsam haben

Trotz der Unterschiede gibt es eine Reihe gemeinsamer Bewertungsdimensionen.

10.1 Nutzen

Die zentrale Frage lautet:

Unterstützt der Lieferant, die Software oder der Cloud-Dienst die Unternehmensziele?

Beispiele:

Effizienzsteigerung
Automatisierung
Qualitätsverbesserung
Kostenreduzierung
Flexibilität
Skalierbarkeit
Digitalisierung
Verbesserung der Informationssicherheit

10.2 Kosten – Total Cost of Ownership

Nicht nur der Anschaffungs- oder Lizenzpreis sollte betrachtet werden.

Relevant sind beispielsweise:

Anschaffung
Lizenzen
Implementierung
Migration
Betrieb
Wartung
Support
Schulung
Integration
Sicherheitsmaßnahmen
Upgrades
Anpassungen
Vertragskosten
Exit- und Migrationskosten

Damit wird aus dem Preis eine Betrachtung der:

Total Cost of Ownership (TCO)

11. Risikoanalyse

Auch die Risikoanalyse folgt grundsätzlich ähnlichen Prinzipien.

Gemeinsame Bewertungsdimensionen können beispielsweise sein:

finanzielle Stabilität
Informationssicherheit
Datenschutz
Compliance
Verfügbarkeit
Abhängigkeit
Subunternehmer
geografische Risiken
Ausfallrisiken
Exit-Fähigkeit

Aber:

Nicht jedes Kriterium ist für jede Bewertung gleich relevant.

Ein Büromateriallieferant benötigt beispielsweise eine andere Prüftiefe als ein Cloud Provider mit administrativem Zugriff auf geschäftskritische Systeme.

12. Methoden können gleich sein – Kriterien nicht

Für alle drei Bewertungsarten können ähnliche Methoden eingesetzt werden:

Kriterienkatalog
Nutzwertanalyse
SWOT-Analyse
Risikomatrix
Scoring
Kostenvergleich
TCO-Analyse
Due Diligence
Assessment
Audit
Zertifikats- und Nachweisprüfung

Die Methode ist also nicht das Entscheidende.

Entscheidend ist:

Welche Kriterien werden mit welcher Gewichtung bewertet?

13. Eine gemeinsame Bewertungslogik

Trotz der unterschiedlichen Schwerpunkte kann für alle drei Kategorien eine gemeinsame Grundstruktur verwendet werden:

1. Anforderung

Was benötigen wir?

2. Nutzen

Welchen geschäftlichen Nutzen erwarten wir?

3. Abhängigkeit

Wie kritisch wird die Leistung für unser Unternehmen?

4. Risiko

Was kann schiefgehen?

5. Sicherheit und Compliance

Welche Anforderungen müssen erfüllt werden?

6. Kosten

Was kostet die Lösung über ihren gesamten Lebenszyklus?

7. Alternativen

Welche Alternativen existieren?

8. Exit

Wie können wir die Lösung oder den Lieferanten wieder verlassen?

9. Entscheidung

Ist das Gesamtrisiko für das Unternehmen akzeptabel?

Damit ergibt sich eine einfache Kette:

Anforderung → Nutzen → Risiko → Kosten → Abhängigkeit → Compliance → Exit → Entscheidung

14. Besonders wichtig: Die Exit-Fähigkeit

Ein häufig unterschätztes Kriterium ist die Frage:

Wie einfach können wir diese Entscheidung später wieder rückgängig machen?

Das gilt für alle drei Bewertungsobjekte.

Lieferant

Gibt es einen alternativen Lieferanten?

Software

Können Daten exportiert und auf eine andere Software migriert werden?

Cloud

Können Daten, Konfigurationen und Anwendungen zu einem anderen Provider übertragen werden?

Je schwieriger ein Exit ist, desto größer kann die langfristige Abhängigkeit werden.

15. Bewertung sollte risikoorientiert sein

Nicht jeder Lieferant, jede Software und jeder Cloud-Dienst benötigt dieselbe Prüftiefe.

Ein sinnvoller Ansatz ist:

Niedriges Risiko
→ vereinfachte Bewertung

Mittleres Risiko
→ erweiterte Bewertung und Nachweise

Hohes Risiko
→ detaillierte Risikoanalyse, Sicherheitsprüfung, Vertragsanforderungen, Nachweise und regelmäßige Neubewertung

Die Risikoklasse sollte dabei nicht einfach aus dem Namen oder Typ des Anbieters abgeleitet werden.

Entscheidend ist die konkrete Nutzung und Abhängigkeit .

Ein Cloud-Dienst für eine unkritische Anwendung kann weniger kritisch sein als eine lokal installierte Software, die einen geschäftskritischen Prozess steuert.

16. Fazit

Die Bewertung von Lieferanten, Software und Cloud-Diensten folgt grundsätzlich ähnlichen Prinzipien:

Anforderungen verstehen – Nutzen bewerten – Risiken analysieren – Kosten betrachten – Abhängigkeiten erkennen – Entscheidung treffen.

Die Schwerpunkte unterscheiden sich jedoch.

· Lieferanten

o Fokus auf Leistung, Qualität, Lieferfähigkeit und Abhängigkeit

· Software

o Fokus auf Funktionalität, Produktqualität, Architektur und Lebenszyklus

· Cloud-Dienste

o Fokus auf Service, Betrieb, Verfügbarkeit, Sicherheit, Datenverarbeitung und Exit-Fähigkeit

Die wichtigste Erkenntnis lautet deshalb:

Nicht die Bewertungsmethode muss für jeden Fall neu erfunden werden – aber die Bewertungskriterien müssen zum Bewertungsobjekt und zum konkreten Risiko passen.

Und noch ein wichtiger Punkt:

Ein Cloud Provider oder Softwarehersteller ist selbstverständlich auch ein Lieferant. Die spezielle Bewertung entsteht dadurch, dass zusätzlich das Produkt, der Service, die technische Abhängigkeit und die Betriebsverantwortung betrachtet werden müssen.

Damit lassen sich Verwechslungen vermeiden und gleichzeitig Synergien schaffen.

Eine gute Lieferanten- und Lösungsbewertung ist deshalb kein einmaliges Auswahlverfahren, sondern ein risikoorientierter Entscheidungsprozess über den gesamten Lebenszyklus.

Die spezifischen Schwerpunkte im Vergleich

Risiken bezüglich Lieferanten

Sun, 10 May 2026 18:36:18 GMT

Risiken bezüglich Lieferanten

Lieferantenrisiken richtig bewerten – drei Blickwinkel, ein Risikoprofil

Lieferanten werden häufig zunächst unter einem klassischen Gesichtspunkt bewertet: Kann der Lieferant die vereinbarte Leistung in der geforderten Qualität, zum richtigen Zeitpunkt und zu akzeptablen Kosten erbringen?

Für viele Unternehmen reicht diese Betrachtung heute jedoch nicht mehr aus.

Ein Lieferant kann gleichzeitig ein Qualitätsrisiko, Informationssicherheitsrisiko und kaufmännisches bzw. strategisches Risiko darstellen. Hinzu kommen Abhängigkeiten aus der Lieferkette, von Subunternehmern, von einzelnen Technologien oder von bestimmten Standorten.

Besonders kritisch wird es, wenn ein Lieferant Zugang zu vertraulichen Informationen, IT-Systemen oder privilegierten Funktionen hat oder für einen geschäftskritischen Prozess benötigt wird.

Eine belastbare Lieferantenbewertung sollte deshalb nicht nur fragen:

„Wie gut ist dieser Lieferant?“

sondern vor allem:

„Welche Abhängigkeit entsteht durch diesen Lieferanten – und was passiert, wenn seine Leistung morgen ausfällt?“

1. Drei Blickwinkel auf das Lieferantenrisiko

Eine praxisgerechte Bewertung kann zunächst aus drei Perspektiven erfolgen:

Qualität und Leistung
Informationssicherheit
Kaufmännische und strategische Aspekte

Diese Perspektiven sollten nicht isoliert betrachtet werden. Erst ihre Kombination ergibt ein belastbares Lieferanten-Risikoprofil .

2. Qualitäts- und Leistungsrisiken

Die klassische Lieferantenbewertung beschäftigt sich vor allem mit der Fähigkeit des Lieferanten, die vereinbarte Leistung zuverlässig und in der geforderten Qualität zu erbringen.

Typische Risiken sind:

verspätete Lieferungen
Ausfall oder Unterbrechung der Leistung
hohe Fehler- oder Reklamationsquote
mangelnde Prozessreife
unzureichende Dokumentation
fehlende Nachvollziehbarkeit
Abhängigkeit von einzelnen Personen
mangelnde Kapazitäten
häufige Änderungen von Ansprechpartnern
instabile Sub-Lieferanten
Qualitätsprobleme in der vorgelagerten Lieferkette

Mögliche Auswirkungen

Die Folgen können erheblich sein:

Produktionsunterbrechungen
Verzögerungen bei Kundenprojekten
zusätzliche Prüf- und Nacharbeitskosten
Vertragsverletzungen
Kundenbeschwerden
Imageschäden
erhöhte operative Belastung
Nichterfüllung eigener Qualitätsanforderungen

Gerade bei kritischen Lieferanten reicht deshalb eine einmalige Bewertung bei der Lieferantenauswahl nicht aus.

Die Leistungsfähigkeit muss während der gesamten Geschäftsbeziehung überwacht werden.

3. Informationssicherheitsrisiken

Bei vielen modernen Lieferantenbeziehungen ist die Informationssicherheit mindestens ebenso relevant wie die Qualität.

Ein Lieferant kann beispielsweise:

auf vertrauliche Informationen zugreifen
personenbezogene Daten verarbeiten
Zugang zu internen IT-Systemen erhalten
Remote-Zugriffe durchführen
administrative Berechtigungen besitzen
Software entwickeln oder betreiben
Cloud-Dienste bereitstellen
Sicherheits- oder Betriebsprozesse übernehmen
Daten speichern oder übertragen
weitere Subunternehmer einsetzen

Damit entsteht eine zusätzliche Risikofläche außerhalb der direkten Kontrolle des eigenen Unternehmens.

Typische Informationssicherheitsrisiken

Beispiele sind:

unzureichendes Berechtigungsmanagement
nicht ausreichend geschützte Remote-Zugänge
fehlende oder unzureichende MFA
unzureichende Verschlüsselung
fehlende Protokollierung
unzureichendes Schwachstellenmanagement
mangelhaftes Incident Management
unzureichende Datensicherung
fehlende Business-Continuity-Maßnahmen
unkontrollierte Subunternehmer
unzureichende Trennung von Kundendaten
fehlende Regelungen zur Rückgabe oder Löschung von Daten

Die zentrale Frage lautet dabei nicht:

„Ist der Lieferant ein IT-Dienstleister?“

Sondern:

„Welche Informationen, Systeme und Berechtigungen erhält dieser konkrete Lieferant?“

Ein externer Dienstleister mit administrativem Zugriff auf produktive Systeme kann beispielsweise ein wesentlich höheres Risiko darstellen als ein IT-Lieferant, der lediglich Standardhardware liefert.

4. Kaufmännische und strategische Risiken

Neben Qualität und Informationssicherheit sollte auch die wirtschaftliche und strategische Abhängigkeit betrachtet werden.

Typische Risiken sind:

finanzielle Instabilität
Insolvenzrisiko
starke Preissteigerungen
unklare Preis- und Abrechnungsmodelle
ungünstige Vertragsbedingungen
unzureichende Haftungsregelungen
zu lange Vertragsbindungen
fehlende Kündigungs- oder Exit-Möglichkeiten
hohe Migrationskosten
fehlende alternative Lieferanten
Vendor Lock-in
mangelnder Support
fehlende strategische Perspektive
Abhängigkeit von einer bestimmten Technologie
Währungsrisiken
geopolitische Risiken
Export- oder Sanktionsrisiken

Gerade bei Cloud- und Softwaredienstleistungen kann der Exit ein wesentliches Risiko darstellen.

Die Frage lautet dann beispielsweise:

Was passiert, wenn der Anbieter den Dienst einstellt oder wir den Vertrag kurzfristig beenden müssen?

Kann das Unternehmen seine Daten exportieren?

Gibt es einen alternativen Anbieter?

Wie lange dauert die Migration?

Welche Kosten entstehen?

Kann der eigene Betrieb die Leistung vorübergehend übernehmen?

5. Lieferketten- und Resilienzrisiken

Eine zusätzliche Betrachtung ist heute häufig erforderlich: die Stabilität der Lieferkette .

Ein Lieferant kann selbst von weiteren Unternehmen abhängig sein.

Beispielsweise:

Unternehmen → IT-Dienstleister → Cloud Provider → Rechenzentrum → Netzbetreiber

Oder:

Unternehmen → Hersteller → Zulieferer → Rohstofflieferant

Ein Ausfall kann deshalb mehrere Ebenen der Lieferkette gleichzeitig betreffen.

Relevant sind beispielsweise:

Single Source
fehlende Alternativen
Abhängigkeit von einzelnen Standorten
Abhängigkeit von einzelnen Subunternehmern
geopolitische Risiken
Naturkatastrophen
Transport- und Logistikrisiken
Energieversorgung
politische Instabilität
Abhängigkeit von kritischen Technologien
Konzentrationsrisiken bei Cloud- oder Plattformanbietern

Diese Aspekte überschneiden sich mit den drei oben genannten Perspektiven. Sie sollten deshalb nicht zwingend als vierter separater Bewertungsprozess behandelt werden, sondern können als Querschnittsthema der Lieferantenrisikobewertung verstanden werden.

6. Nicht der Lieferantentyp entscheidet – sondern die konkrete Abhängigkeit

Eine häufige Vereinfachung lautet:

Lieferant - Risikoklasse

Cloud Provider - hoch

IT-Dienstleister - hoch

Marketingagentur - mittel

Büromaterial - niedrig

Eine solche Einstufung kann als erste Orientierung dienen, ist aber für eine belastbare Risikobewertung zu pauschal.

Entscheidend sind die tatsächlichen Eigenschaften der Geschäftsbeziehung.

Ein besserer Ansatz ist:

Niedriges Risiko

kein Zugriff auf kritische Informationen
kein Zugriff auf IT-Systeme
keine privilegierten Berechtigungen
kein Einfluss auf kritische Prozesse
kurzfristig ersetzbar
geringe wirtschaftliche Abhängigkeit

Mittleres Risiko

Zugriff auf interne Informationen oder Prozesse
begrenzter Systemzugriff
gewisse Abhängigkeit
Lieferant nicht unmittelbar ersetzbar
moderate Auswirkungen bei Ausfall

Hohes Risiko

Zugriff auf sensible oder kritische Informationen
privilegierter oder administrativer Zugriff
Unterstützung kritischer Geschäftsprozesse
hohe Verfügbarkeitsabhängigkeit
schwer ersetzbarer Lieferant
erhebliche regulatorische, finanzielle oder operative Auswirkungen
starke Abhängigkeit von Subunternehmern
erheblicher Aufwand für Migration oder Exit

Die Einstufung sollte daher immer auf der konkreten Lieferantenbeziehung basieren.

7. Eine einfache Kernfrage für die Risikobewertung

Eine besonders hilfreiche Frage lautet:

Was passiert, wenn dieser Lieferant morgen für 30 Tage nicht mehr verfügbar ist?

Die Antwort liefert häufig bereits wichtige Informationen für die Risikobewertung.

Dabei sollte betrachtet werden:

Welche Prozesse sind betroffen?
Welche Informationen sind betroffen?
Welche Systeme sind betroffen?
Welche Kunden sind betroffen?
Welche gesetzlichen oder vertraglichen Verpflichtungen sind betroffen?
Gibt es einen alternativen Lieferanten?
Kann die Leistung intern übernommen werden?
Wie schnell kann eine Ersatzlösung aufgebaut werden?
Welche Kosten entstehen?
Welche Daten befinden sich beim Lieferanten?
Welche Zugriffsrechte besitzt der Lieferant?
Können Daten und Systeme zurückgeführt werden?
Gibt es einen funktionierenden Exit- oder Notfallplan?

Damit wird aus einer allgemeinen Lieferantenbewertung eine konkrete Abhängigkeits- und Risikobetrachtung .

8. Lieferantenrisiko anhand konkreter Kriterien bewerten

Eine einfache Bewertungsmatrix kann beispielsweise folgende Dimensionen verwenden:

Dimension: Leitfrage

Kritikalität: Wie wichtig ist die Leistung für das Unternehmen?

Informationen: Auf welche Informationen hat der Lieferant Zugriff?

Systemzugriff : Auf welche Systeme kann der Lieferant zugreifen?

Berechtigungen: Besitzt er privilegierte oder administrative Rechte?

Verfügbarkeit: Welche Folgen hat ein Ausfall?

Qualität: Welche Folgen haben Fehler oder mangelhafte Leistungen?

Subunternehmer: Welche weiteren Unternehmen sind beteiligt?

Abhängigkeit: Wie stark ist das Unternehmen vom Lieferanten abhängig?

Ersetzbarkeit: Gibt es kurzfristig Alternativen?

Exit: Wie schwierig ist eine Beendigung bzw. Migration?

Wirtschaftlichkeit: Welche finanziellen Risiken bestehen?

Compliance: Welche gesetzlichen oder regulatorischen Anforderungen sind betroffen?

Geografie: Welche Länder-, Standort- oder geopolitischen Risiken bestehen?

Resilienz: Wie robust ist die Lieferkette gegenüber Ausfällen?

Aus diesen Kriterien kann anschließend eine Lieferanten-Risikoklasse abgeleitet werden.

9. Informationssicherheit nach ISO/IEC 27001:2022

Für ein Informationssicherheitsmanagementsystem nach ISO/IEC 27001:2022 ist die Lieferantenbeziehung insbesondere im Annex A relevant.

Besonders wichtig sind:

A.5.19 – Information security in supplier relationships
A.5.20 – Addressing information security within supplier agreements
A.5.21 – Managing information security in the ICT supply chain
A.5.22 – Monitoring, review and change management of supplier services
A.5.23 – Information security for use of cloud services

Damit wird deutlich: Lieferantenmanagement ist nicht nur eine Frage der Einkaufspolitik.

Es ist auch Bestandteil des Informationssicherheitsmanagements.

Dabei geht es nicht ausschließlich um die Auswahl eines Lieferanten. Die Lieferantenbeziehung muss über ihren gesamten Lebenszyklus gesteuert werden.

10. Der Lieferanten-Lebenszyklus

Eine praktische Struktur ist:

Auswahl → Vertrag → Onboarding → Leistungserbringung → Überwachung → Änderung → Neubewertung → Exit

a. Auswahl

Leistungsfähigkeit bewerten
Risiken identifizieren
Informationen und Zugriffe bestimmen
Alternativen betrachten
Risikoklasse festlegen

b. Vertrag

Je nach Risiko können beispielsweise geregelt werden:

Leistungsumfang
SLA
Informationssicherheit
Datenschutz
Vertraulichkeit
Berechtigungen
Incident-Meldungen
Audit- und Nachweisrechte
Subunternehmer
Änderungsmanagement
Business Continuity
Datenrückgabe
Löschung
Exit

c. Onboarding

Der Lieferant erhält nur die Zugriffe und Informationen, die tatsächlich benötigt werden.

Besonders bei IT-Dienstleistern sollte der Grundsatz gelten:

So viel Zugriff wie erforderlich – so wenig Zugriff wie möglich.

d. Überwachung

Je nach Risikoklasse können beispielsweise überwacht werden:

SLA-Erfüllung
Qualitätskennzahlen
Sicherheitsvorfälle
Schwachstellen
Auditberichte
Zertifikate
Änderungen beim Lieferanten
Subunternehmer
finanzielle Situation
Leistungsfähigkeit

e. Neubewertung

Eine Neubewertung sollte nicht nur in festen Intervallen erfolgen.

Sie ist insbesondere bei wesentlichen Änderungen sinnvoll, beispielsweise:

neue Dienstleistung
neue Systeme
neue Daten
neue Zugriffsrechte
neuer Subunternehmer
Standortwechsel
Übernahme oder Fusion
Sicherheitsvorfall
erhebliche Leistungsprobleme
Änderung gesetzlicher Anforderungen

f. Exit

Auch das Ende einer Lieferantenbeziehung sollte geplant sein.

Dazu gehören beispielsweise:

Rückgabe der Daten
Löschung der Daten
Entzug von Berechtigungen
Rückgabe von Geräten
Übergabe von Dokumentation
Migration
Übergang zu einem Ersatzlieferanten
Nachweis der vollständigen Beendigung des Zugriffs

11. Hohe Lieferantenrisiken erfordern stärkere Maßnahmen

Nicht jeder Lieferant benötigt die gleiche Prüftiefe.

Bei einem Lieferanten mit geringem Risiko kann eine einfache Bewertung ausreichend sein.

Bei einem kritischen Lieferanten können dagegen zusätzliche Maßnahmen erforderlich sein:

detaillierter Sicherheitsfragebogen
Prüfung von Zertifizierungen
Bewertung eines ISO/IEC-27001-Zertifikats
Prüfung von SOC-Berichten oder anderen Nachweisen
Sicherheitsanforderungen im Vertrag
definierte Incident-Meldezeiten
Audit- oder Assessment-Rechte
Regelungen zu Subunternehmern
regelmäßige Neubewertung
technische Sicherheitsanforderungen
Business-Continuity-Anforderungen
Exit- und Fallback-Strategie

Der Grundsatz sollte lauten:

Je höher die Abhängigkeit und das Risiko, desto höher sollte auch die Tiefe der Lieferantensteuerung sein.

12. Lieferantenrisiko ist nicht nur ein Einkaufsthema

Eine gute Lieferantenbewertung benötigt häufig mehrere Fachbereiche.

Beispielsweise:

Einkauf
→ Vertrag, Preise, Lieferfähigkeit, Alternativen

Fachbereich
→ Prozesskritikalität, Leistungsanforderungen, Qualität

IT / Informationssicherheit
→ Systeme, Daten, Zugriffe, Sicherheitsanforderungen

Datenschutz
→ personenbezogene Daten, Auftragsverarbeitung

Qualitätsmanagement
→ Qualitätsanforderungen, Reklamationen, Audits

Business Continuity / Resilienz
→ Abhängigkeiten, Ausfallszenarien, Wiederanlauf

Dadurch entsteht kein isoliertes Lieferantenrating, sondern ein integriertes Lieferanten-Risikoprofil .

13. Ein praktisches Beispiel

Ein Unternehmen beauftragt einen externen IT-Dienstleister mit dem Betrieb eines geschäftskritischen Systems.

Der Dienstleister:

besitzt administrativen Zugriff,
verarbeitet vertrauliche Unternehmensdaten,
unterstützt einen kritischen Geschäftsprozess,
nutzt selbst einen Cloud Provider,
ist nur schwer kurzfristig ersetzbar.

Aus den drei Perspektiven ergibt sich:

Qualität

Ausfall oder mangelhafte Leistung kann den Geschäftsprozess unterbrechen.

Informationssicherheit

Der Dienstleister besitzt privilegierte Zugriffsrechte und verarbeitet vertrauliche Informationen.

Kaufmännisch / strategisch

Eine kurzfristige Ablösung wäre schwierig und mit erheblichen Kosten verbunden.

Lieferkette / Resilienz

Zusätzlich besteht eine Abhängigkeit vom Cloud Provider des Dienstleisters.

Das Ergebnis ist eindeutig:

Die konkrete Lieferantenbeziehung besitzt ein hohes Risikoprofil.

Entsprechend sollte auch die Steuerung intensiver sein.

14. Lieferantenrisiko als Bestandteil des Risikomanagements

Lieferantenrisiken sollten nicht als isolierte Excel-Liste neben dem eigentlichen Risikomanagement existieren.

Sie sollten mit dem bestehenden Risikomanagement verbunden sein.

Eine mögliche Kette lautet:

· Lieferant identifizieren

· Abhängigkeit verstehen

· Risiken bewerten

· Risikoklasse bestimmen

· Anforderungen festlegen

· vertragliche / technische / organisatorische Maßnahmen umsetzen

· Leistung und Risiken überwachen

· bei Änderungen neu bewerten

· Exit- und Fallback-Fähigkeit sicherstellen

Damit wird aus der Lieferantenbewertung ein kontinuierlicher Steuerungsprozess.

15. Fazit

Lieferantenrisiken lassen sich nicht allein anhand von Qualität, Einkaufspreisen oder einer Checkliste für Informationssicherheit bewerten.

Eine belastbare Bewertung betrachtet mindestens drei Perspektiven:

Qualität und Leistung
→ Kann der Lieferant die erforderliche Leistung zuverlässig erbringen?

Informationssicherheit
→ Welche Informationen, Systeme und Berechtigungen sind betroffen?

Kaufmännische und strategische Aspekte
→ Welche wirtschaftliche und strategische Abhängigkeit entsteht?

Ergänzend sollte die Resilienz der Lieferkette betrachtet werden.

Dabei ist die entscheidende Frage nicht:

„Welche Art Lieferant ist das?“

Sondern:

„Welche konkrete Abhängigkeit entsteht durch diesen Lieferanten?“

Genau daraus lässt sich ableiten, welche Anforderungen, Vertragsregelungen, Kontrollen, Überwachungsmaßnahmen und Exit-Strategien erforderlich sind.

Ein Lieferantenrisiko endet deshalb auch nicht mit der Auswahl des Lieferanten.

Es muss über den gesamten Lebenszyklus gesteuert werden – von der Auswahl über den Vertrag und die Leistungserbringung bis zur Neubewertung und zum Exit.

Das Ziel ist nicht, jeden Lieferanten maximal zu kontrollieren.

Das Ziel ist:

Die richtigen Lieferanten angemessen steuern – abhängig von ihrer tatsächlichen Kritikalität, ihrem Zugriff, ihrer Abhängigkeit und ihrem Risiko.

Viel Erfolg, Ihr Konstantin Ziouras

Lieferanten, Auswahl und Bewertung

Sun, 10 May 2026 18:24:10 GMT

Lieferanten, Auswahl und Bewertung

Lieferanten auswählen und bewerten – mehr als Qualität und ein Zertifikat

Unternehmen müssen sicherstellen, dass Lieferanten und Geschäftspartner nicht nur gute Produkte oder Dienstleistungen liefern. Sie müssen auch zuverlässig, wirtschaftlich tragfähig und – abhängig von der konkreten Geschäftsbeziehung – sicher im Umgang mit Informationen, Systemen und anvertrauten Daten sein.

Zertifikate wie ISO 9001 oder ISO/IEC 27001 können dabei ein wertvoller Nachweis sein. Sie ersetzen jedoch nicht die eigene Bewertung des Lieferanten.

Denn entscheidend ist nicht nur:

„Hat der Lieferant ein Zertifikat?“

Sondern:

„Erfüllt dieser Lieferant mit seiner konkreten Leistung unsere Anforderungen und ist das damit verbundene Risiko für uns akzeptabel?“

Die Anforderungen können sich außerdem im Laufe der Zusammenarbeit verändern. Deshalb endet die Lieferantenbewertung nicht mit der Auswahl.

Eine gute Lieferantensteuerung besteht aus:

Auswahl → Vertrag → Onboarding → Leistungserbringung → Überwachung → Neubewertung → Änderung → Exit

Die Bewertung sollte dabei mindestens drei Blickwinkel berücksichtigen:

Qualität und Leistung
Informationssicherheit
Kaufmännische und strategische Aspekte

Je nach Unternehmen und Lieferanten können weitere Perspektiven hinzukommen, beispielsweise Datenschutz, Nachhaltigkeit, Arbeitssicherheit, Umwelt, regulatorische Anforderungen oder Business Continuity.

1. Ein Zertifikat ist kein Freifahrtschein

Viele Unternehmen verlassen sich bei der Lieferantenauswahl auf ein scheinbar einfaches Kriterium:

„Der Lieferant hat ISO 9001 bzw. ISO 27001 – also passt alles.“

Das greift zu kurz.

Ein Zertifikat ist ein wichtiger Nachweis, aber es beantwortet nicht automatisch die Frage, ob der Lieferant für die konkrete Leistung und die konkrete Organisation geeignet ist .

Auch der Scope eines Zertifikats ist relevant.

Ein ISO-27001-Zertifikat kann beispielsweise gültig sein, aber:

der betrachtete Scope umfasst nicht die relevante Dienstleistung,
bestimmte Standorte sind nicht eingeschlossen,
die von uns benötigte Leistung liegt außerhalb des zertifizierten Bereichs,
unsere konkreten Sicherheitsanforderungen sind nicht vollständig abgedeckt.

Ein Zertifikat sollte daher als ein Baustein der Bewertung verstanden werden – nicht als Ersatz für die Bewertung.

Das lässt sich gut mit einem Autokauf vergleichen.

Eine Straßenzulassung bedeutet nicht, dass das Fahrzeug automatisch das richtige Fahrzeug für dich ist.

Du prüfst zusätzlich:

Größe
Sitzplätze
Verbrauch
Ausstattung
Sicherheit
Kofferraum
Anhängelast
Wartung
Kosten
Service
persönliche Anforderungen

Genauso sollte ein Unternehmen einen Lieferanten bewerten.

2. Initiale Lieferantenauswahl

Die erste Frage lautet:

Ist dieser Lieferant grundsätzlich geeignet?

Beim Autokauf prüfst du, ob das Fahrzeug zu deinen Anforderungen passt.

Bei der Lieferantenauswahl prüfst du, ob der Lieferant zu den fachlichen, qualitativen, sicherheitsbezogenen und wirtschaftlichen Anforderungen deines Unternehmens passt.

Dabei können mindestens drei Perspektiven betrachtet werden:

Qualität
Informationssicherheit
Kaufmännische und strategische Aspekte

3. Qualitätsblickwinkel

Autokauf

Beim Auto können beispielsweise betrachtet werden:

Verarbeitung
Zuverlässigkeit
Fahrverhalten
Verbrauch
Technik
Garantie
Servicequalität

Lieferantenauswahl

Entsprechende Kriterien können sein:

Prozessreife
Qualitätsmanagement
Fehlerquote
Reklamationshistorie
Lieferperformance
Kapazität
Stabilität der Lieferkette
Dokumentationsqualität
Rückverfolgbarkeit
Fachkompetenz und Know-how
Qualifikation des Personals
Referenzen
Zertifizierungen
Auditergebnisse

Die entscheidende Frage lautet:

Kann der Lieferant das liefern, was wir tatsächlich benötigen – in der geforderten Qualität und zuverlässig über die gesamte Vertragslaufzeit?

Ein ISO-9001-Zertifikat kann dabei ein wichtiger Nachweis sein.

Aber mehrere Lieferanten können über ein ISO-9001-Zertifikat verfügen und trotzdem sehr unterschiedliche Leistungen erbringen.

4. Informationssicherheitsblickwinkel

Autokauf

Bei einem Auto können beispielsweise folgende Sicherheitsmerkmale relevant sein:

Airbags
Notbremsassistenz
Assistenzsysteme
Abstandsregelung
Diebstahlschutz
Parkassistenz
Sicherheitsbewertungen
Software- und Sicherheitsupdates

Nicht jedes Merkmal ist für jeden Käufer gleich wichtig.

Lieferantenauswahl

Auch bei Lieferanten muss zunächst betrachtet werden:

Welche Informationen, Systeme, Standorte und Prozesse sind überhaupt betroffen?

Je nach Geschäftsbeziehung können beispielsweise relevant sein:

ISMS und Sicherheitsorganisation
Zugriffskontrollen
Berechtigungsmanagement
MFA
Verschlüsselung
Logging und Monitoring
Schwachstellenmanagement
Incident Management
Meldewege
Business Continuity
Backup und Recovery
Umgang mit Subunternehmern
Standort und Rechtsraum
eingesetzte Technologien
Security Awareness
technische und organisatorische Maßnahmen
Datenschutz
Auftragsverarbeitung
Exit- und Datenlöschungskonzepte

Bei einem Lieferanten ohne Zugriff auf Unternehmensinformationen sind viele dieser Kriterien möglicherweise nicht oder nur eingeschränkt relevant.

Bei einem Cloud Provider mit privilegiertem Zugriff auf geschäftskritische Systeme können sie dagegen entscheidend sein.

Ergo

Ein Auto kann technisch hervorragend sein und trotzdem nicht die Sicherheitsausstattung besitzen, die du benötigst.

Genauso kann ein Lieferant hervorragende Qualität liefern und gleichzeitig aus Sicht deines Unternehmens ein nicht akzeptables Informationssicherheitsrisiko darstellen.

5. Kaufmännischer und strategischer Blickwinkel

Autokauf

Beispielsweise:

Kaufpreis
Preis-Leistungs-Verhältnis
Betriebskosten
Wartungskosten
Wiederverkaufswert
Finanzierung
Vertragsbedingungen

Lieferantenauswahl

Hier können betrachtet werden:

einmalige Kosten
wiederkehrende Kosten
variable Kosten
Total Cost of Ownership
Preisentwicklung
finanzielle Stabilität
Vertragslaufzeit
Kündigungsfristen
Haftung
Gewährleistung
SLA
Support
Skalierbarkeit
Flexibilität
Abhängigkeit
Alternativen
Exit- und Migrationskosten

Ein günstiger Lieferant kann langfristig teuer werden, wenn beispielsweise:

die Qualität nicht stimmt,
ständig nachgebessert werden muss,
zusätzliche Leistungen teuer verrechnet werden,
die Abhängigkeit steigt,
ein späterer Anbieterwechsel sehr aufwendig wird.

Deshalb gilt:

Nicht nur den Preis betrachten – sondern die Kosten und Risiken über den gesamten Lebenszyklus.

6. Die eigentliche Lieferantenentscheidung

Die drei Perspektiven können zu einem gemeinsamen Lieferantenprofil zusammengeführt werden:

Perspektive:Zentrale Frage

Qualität: Kann der Lieferant die benötigte Leistung zuverlässig erbringen?

Informationssicherheit: Können Informationen, Systeme und Daten angemessen geschützt werden?

Kaufmännisch/strategisch: Ist die Zusammenarbeit wirtschaftlich tragfähig und strategisch sinnvoll?

Dazu kommen – abhängig vom Lieferanten – weitere Fragen:

Datenschutz?
Compliance?
Nachhaltigkeit?
Arbeitssicherheit?
Umwelt?
Resilienz?
regulatorische Anforderungen?
Business Continuity?
geopolitische Risiken?

7. Vertragliche Klärung – die Grundlage der Zusammenarbeit

Die beste Lieferantenauswahl nützt wenig, wenn anschließend nicht klar geregelt wird, was der Lieferant tatsächlich leisten muss .

Beim Autokauf wird ebenfalls nicht nur das Fahrzeug betrachtet. Der Kaufvertrag regelt unter anderem Preis, Leistung, Gewährleistung und weitere Bedingungen.

Genauso muss eine Lieferantenvereinbarung die relevanten Anforderungen verbindlich machen.

Der Vertrag verbindet damit:

Auswahl → Leistungserbringung → Bewertung

8. Qualitätsbezogene vertragliche Regelungen

Qualitätsanforderungen sollten möglichst konkret, messbar und überprüfbar sein.

Mögliche Inhalte:

Leistungsbeschreibung
Lieferzeiten
Service Level Agreements
Verfügbarkeiten
Fehlerquoten
Qualitätskennzahlen
Prüfprozesse
Dokumentationspflichten
Änderungsmanagement
Reklamationsprozess
Eskalationsprozess
Nachbesserungsfristen
kontinuierliche Verbesserung
Lessons Learned
Audit- und Nachweisrechte

Denn:

Was nicht eindeutig vereinbart ist, lässt sich später nur schwer objektiv bewerten.

9. Informationssicherheitsbezogene vertragliche Regelungen

Bei relevanten Lieferantenbeziehungen sollten Informationssicherheitsanforderungen angemessen in Vereinbarungen berücksichtigt werden.

Im Kontext von ISO/IEC 27001:2022 ist insbesondere A.5.20 – Addressing information security within supplier agreements relevant.

Mögliche Inhalte sind:

Sicherheitsanforderungen
Zugriffskontrollen
Authentisierung
Verschlüsselung
Logging und Monitoring
Schwachstellenmanagement
Incident-Meldepflichten
definierte Meldefristen
Eskalationswege
Anforderungen an Subunternehmer
Audit- und Nachweisrechte
Business Continuity
Disaster Recovery
Backup
Datenlokation
Rechtsraum
Datenschutz
technische und organisatorische Maßnahmen
Auftragsverarbeitung gemäß Art. 28 DSGVO, sofern relevant
Exit-Regelungen
Datenrückgabe
Datenlöschung

Auch Zertifizierungen oder andere Nachweise können vereinbart werden, beispielsweise:

ISO/IEC 27001
SOC 2
TISAX

Dabei sollte jedoch immer geprüft werden, ob der jeweilige Nachweis für die konkrete Leistung und das konkrete Risiko tatsächlich aussagekräftig ist .

10. Kaufmännische und rechtliche Regelungen

Hier geht es um Kosten, Verantwortlichkeiten, Haftung und Flexibilität.

Mögliche Inhalte:

Preis- und Kostenmodelle
TCO (Total Cost of Ownership)
Preisänderungen
Zahlungsbedingungen
Haftung
Gewährleistung
Haftungsobergrenzen
Vertragslaufzeiten
Kündigungsfristen
automatische Verlängerungen
Support
Verfügbarkeit
Rollen und Verantwortlichkeiten
Änderungsmanagement
Eskalationsmechanismen
Exit-Regelungen
Daten- und Leistungstransfer bei Vertragsende

Gerade bei langfristigen oder kritischen Lieferantenbeziehungen ist die Frage wichtig:

Wie kommen wir wieder aus der Abhängigkeit heraus?

Exit-Fähigkeit sollte deshalb bereits bei der Auswahl berücksichtigt werden – nicht erst beim Vertragsende.

11. Wiederkehrende Lieferantenbewertung

Nach der Auswahl endet die Lieferantenbewertung nicht.

Im Gegenteil:

Jetzt beginnt die eigentliche Beobachtung der Leistungsfähigkeit.

Die Bewertung sollte regelmäßig und risikobasiert erfolgen.

Das muss nicht zwingend bei jedem Lieferanten jährlich geschehen.

Ein kritischer Lieferant kann beispielsweise häufiger bewertet werden als ein Lieferant mit geringem Risiko.

Zusätzlich sollte eine Neubewertung ausgelöst werden, wenn wesentliche Änderungen eintreten.

Beispiele:

neue Dienstleistung
neue Systeme
neue Daten
neue Zugriffsrechte
neue Standorte
neue Subunternehmer
Sicherheitsvorfall
Qualitätsprobleme
Eigentümerwechsel
finanzielle Probleme
neue regulatorische Anforderungen
wesentliche Vertragsänderungen

12. Qualitätsbewertung im laufenden Betrieb

Auto-Service

Beim Fahrzeug werden beispielsweise betrachtet:

Zustand von Bremsen und Reifen
Reparaturen
Verschleiß
Rückrufe
Softwareupdates
Zuverlässigkeit
Zufriedenheit des Fahrers

Lieferantenbewertung

Entsprechende Kriterien können sein:

Termintreue
Lieferperformance
Fehlerquote
Reklamationen
SLA-Erfüllung
Änderungen bei Prozessen
Personalwechsel
Umsetzung von Verbesserungsmaßnahmen
Ergebnisse von Audits
Lieferantenaudits
neue Risiken
Verbesserungspotenziale
Zufriedenheit der Fachbereiche

Ergo

Auch ein gutes Auto kann schlechter werden.

Genauso kann sich die Leistungsfähigkeit eines Lieferanten verändern.

13. Informationssicherheitsbewertung im laufenden Betrieb

Auto-Service

Beispielsweise:

Funktion der Assistenzsysteme
Softwareupdates
Sicherheitsrückrufe
technischer Zustand
neue Sicherheitsfunktionen

Lieferantenbewertung

Mögliche Kriterien:

Gültigkeit und Scope relevanter Zertifizierungen
Sicherheitsvorfälle
Änderungen im ISMS
relevante Änderungen der Sicherheitsorganisation
neue Subunternehmer
Änderungen der Technologie
Audit- und Assessment-Ergebnisse
relevante Pen-Test- oder SOC-Nachweise, sofern vereinbart
Einhaltung vertraglicher Sicherheitsanforderungen
neue Risiken
Änderungen des Rechtsraums
Änderungen der Datenverarbeitung
Änderungen bei Zugriffsrechten

Wichtig:

Nicht jeder Lieferant benötigt einen Penetrationstest, einen SOC-Bericht oder ein jährliches Audit.

Die Prüftiefe sollte sich am Risiko und an der Kritikalität der Lieferantenbeziehung orientieren.

Ergo

Informationssicherheit ist kein einmaliger Zustand. Sie muss über die gesamte Zusammenarbeit hinweg überwacht und weiterentwickelt werden.

14. Kaufmännische und strategische Neubewertung

Auto-Service

Beispielsweise:

Reparaturkosten
Betriebskosten
Zuverlässigkeit
Wertentwicklung
Zufriedenheit
veränderte persönliche Anforderungen

Vielleicht hat sich die Situation verändert:

Familie größer
Hund
Kinderwagen
Fahrradträger
veränderte Fahrleistung
anderes Budget

Das Fahrzeug kann technisch noch völlig in Ordnung sein – aber nicht mehr zum aktuellen Bedarf passen.

Lieferantenbewertung

Entsprechende Veränderungen können sein:

Kostenentwicklung
SLA-Erfüllung
finanzielle Stabilität
Marktveränderungen
Abhängigkeiten
strategische Ausrichtung
neue gesetzliche Anforderungen
neue regulatorische Anforderungen
Vertragsänderungen
veränderte Unternehmensziele
veränderte Anforderungen der Fachbereiche

Ergo

Ein Lieferant kann weiterhin gute Leistungen erbringen und trotzdem nicht mehr zur aktuellen strategischen Situation des Unternehmens passen.

15. Kriterien müssen bewertbar sein

Ein wichtiger Punkt wird in der Praxis häufig unterschätzt:

Lieferantenkriterien sollten nachvollziehbar und möglichst objektiv bewertbar sein.

Das bedeutet jedoch nicht, dass jedes Kriterium zwingend ein KPI sein muss.

Geeignete Bewertungsformen können sein:

KPI
Scorecard
Scoring
Ja/Nein-Kriterium
Audit
Assessment
Zertifikatsnachweis
Dokumentenprüfung
qualitative Bewertung
Risikomatrix

Beispiel:

Lieferperformance

→ KPI: Termintreue 97 %

Informationssicherheit

→ Nachweis: ISO/IEC 27001-Zertifikat mit passendem Scope

Incident Management

→ Bewertung: definierter Prozess vorhanden / nicht vorhanden

Exit-Fähigkeit

→ Assessment: Datenexport und Migration innerhalb definierter Zeit möglich

Damit wird aus einer allgemeinen Einschätzung eine nachvollziehbare Bewertung.

16. Kritikalität bestimmt die Prüftiefe

Nicht jeder Lieferant benötigt denselben Aufwand.

Ein möglicher Ansatz:

Niedrige Kritikalität

einfache Lieferantenbewertung
grundlegende Qualitätsprüfung
Vertragsprüfung
geringe Überwachungsintensität

Mittlere Kritikalität

detaillierter Kriterienkatalog
zusätzliche Nachweise
regelmäßige Bewertung
definierte Sicherheits- und Qualitätsanforderungen

Hohe Kritikalität

detaillierte Risikoanalyse
intensive Lieferantenprüfung
Sicherheitsassessment
gegebenenfalls Audit
umfangreiche vertragliche Anforderungen
regelmäßige Neubewertung
Business-Continuity-Anforderungen
Exit- und Fallback-Strategie

Damit gilt:

Je höher die Kritikalität und das Risiko, desto höher sollte die Tiefe der Lieferantensteuerung sein.

17. Die Bewertung als Regelkreis

Letztendlich ist Lieferantenmanagement kein einmaliges Auswahlverfahren.

Es ist ein Regelkreis:

· Anforderung definieren

· Lieferant auswählen

· Risiken bewerten

· Vertragliche Anforderungen festlegen

· Lieferant onboarden

· Leistung überwachen

· Bewerten

· Verbessern oder Maßnahmen einleiten

· Risiken neu bewerten

· Weiterführen, ändern oder Exit

Dieser Regelkreis verbindet Qualitätsmanagement, Informationssicherheitsmanagement und kaufmännische Steuerung.

18. Fazit

Eine gute Lieferantenauswahl bedeutet mehr als:

„Der Lieferant ist zertifiziert.“

Und eine gute Lieferantenbewertung bedeutet mehr als:

„Die letzte Lieferung war pünktlich.“

Eine belastbare Bewertung betrachtet den Lieferanten aus mehreren Perspektiven:

Qualität
→ Kann er die erforderliche Leistung zuverlässig erbringen?

Informationssicherheit
→ Kann er Informationen, Systeme und Daten angemessen schützen?

Kaufmännisch / strategisch
→ Ist die Zusammenarbeit wirtschaftlich sinnvoll und langfristig tragfähig?

Je nach Geschäftsbeziehung kommen weitere Perspektiven hinzu.

Entscheidend ist außerdem die zeitliche Betrachtung:

Vor der Auswahl:
Passt der Lieferant zu unseren Anforderungen?

Während der Zusammenarbeit:
Erbringt er weiterhin zuverlässig die vereinbarte Leistung?

Bei Veränderungen:
Hat sich das Risiko verändert?

Vor dem Exit:
Können wir die Abhängigkeit kontrolliert beenden?

Die zentrale Erkenntnis lautet:

Lieferantenbewertung ist kein einmaliges Auswahlverfahren, sondern ein risikoorientierter Regelkreis über den gesamten Lebenszyklus der Geschäftsbeziehung.

Oder – um bei der Analogie zu bleiben:

Ein Auto kauft man nicht nur nach dem Prospekt. Man prüft, ob es zu den eigenen Anforderungen passt, hält es instand und stellt regelmäßig fest, ob es noch zuverlässig seinen Zweck erfüllt. Bei Lieferanten ist es nicht anders.

Nicht das Zertifikat allein entscheidet – sondern die Eignung, das Risiko, die Leistung und die langfristige Beherrschbarkeit der Lieferantenbeziehung.

Viel Erfolg,

Ihr Konstantin Ziouras

Endpoint Security, einfach erklärt

Wed, 15 Apr 2026 05:35:52 GMT

Endpoint Security, einfach erklärt

Endpoint Security bedeutet:

Schutz aller Endgeräte, die mit IT Systemen verbunden sind – also Laptops, Desktops, Smartphones, Tablets, Server, virtuelle Maschinen, Container Hosts, OT HMI Rechner etc. Bildlich: Jedes Gerät ist eine Tür ins Unternehmen.

Endpoint Security sorgt dafür, dass diese Türen:

• nicht offenstehen

• nicht mit gestohlenen Schlüsseln geöffnet werden

• und im Idealfall einen Alarm auslösen, wenn jemand versucht einzubrechen.

Warum das Thema heute wichtig ist

1. Angriffe starten fast immer am Endpoint

• Phishing Mails → Klick → Malware auf dem Laptop

• Ransomware → Verschlüsselung startet am Endpoint

• Initial Access Broker → kompromittierte Endgeräte werden verkauft

2. Arbeitswelt hat sich verändert

• Homeoffice, Remote Work, BYOD

• Cloud Zugriffe von überall

• Mehr Endgeräte, weniger klarer Perimeter

3. Business Relevanz

• Ein kompromittierter Endpoint kann:

o Zugang zu AD / Identitäten geben

o Ransomware ins gesamte Netz bringen

o Datenabfluss ermöglichen

• Direkte Auswirkungen: Ausfall, Lösegeld, Reputationsschäden, NIS2 Sanktionen.

Technische Grundlagen

Kernidee: Endpoint Security kombiniert Schutz, Erkennung und Reaktion direkt auf dem Gerät.

Wichtige Bausteine:

• Antivirus / Anti Malware: Signatur und verhaltensbasierter Schutz

• Host Firewall: Filtert eingehenden/ausgehenden Traffic

• Endpoint Detection & Response (EDR): Erkennung verdächtigen Verhaltens, Forensik, Response

• Extended Detection & Response (XDR): Korrelation von Endpoint Daten mit Netzwerk, Cloud, Identitäten

• Hardening: Konfiguration, die Angriffsfläche reduziert (z. B. Deaktivierung unnötiger Dienste)

• Patch Management: Schließen von Schwachstellen

Stand der Technik / Best Practices

1. Von klassischem AV zu EDR/XDR

• Klassischer Virenscanner allein ist nicht mehr ausreichend.

• Stand der Technik: EDR/XDR Lösungen, die Verhalten analysieren, Prozesse korrelieren und Angriffe in frühen Phasen erkennen.

2. Zero Trust am Endpoint

• Endpoint wird nicht automatisch vertraut, nur weil er „im Netz“ ist.

• Kombination aus:

o Gerätestatus (Compliance)

o Identität (User)

o Kontext (Ort, Zeit, Risiko)

3. Harter Fokus auf Identitäten

• Endpoint Security ist eng mit Identity & Access Management verknüpft.

• Kompromittierter Endpoint → kompromittierte Identität → lateral movement.

4. Standardisierte Baselines

• CIS Benchmarks, BSI Empfehlungen, Hardening Guides

• Standardisierte Konfigurationen für Windows, macOS, Linux, Mobile, OT Systeme.

Typische Risiken & Fehler in der Praxis

• Nur Antivirus, kein EDR/XDR

• Kein zentrales Management der Endpoints

• Ungepatchte Systeme (insbesondere Drittsoftware wie Browser, Java, Office Plugins)

• Lokale Adminrechte für Benutzer

• Kein Application Whitelisting (alles darf laufen)

• Shadow IT (private Geräte, nicht verwaltete Systeme)

• OT Endpoints ohne Schutz, weil „Produktionssysteme darf man nicht anfassen“

• Fehlende Integration in SIEM/SOC – Alarme bleiben unbemerkt

Moderne Lösungsansätze & Technologien

• EDR/XDR Plattformen

o Sammeln Telemetrie (Prozesse, Registry, Netzwerk, Dateien)

o Erkennen verdächtige Muster (z. B. Ransomware Verhalten)

o Unterstützen Incident Response (Isolieren von Endpoints, Forensik)

• Zero Trust Network Access (ZTNA)

o Zugriff auf Anwendungen nur, wenn Endpoint „gesund“ ist (Compliance Check)

• Mobile Device Management (MDM) / Unified Endpoint Management (UEM)

o Verwaltung von Laptops, Smartphones, Tablets, teilweise auch IoT/OT

o Erzwingung von Policies (Verschlüsselung, PIN, Jailbreak Erkennung)

• Application Control / Whitelisting

o Nur erlaubte Anwendungen dürfen laufen

o Sehr wirksam gegen Malware und Ransomware

• Hardware basierte Sicherheit

o TPM, Secure Boot, Device Guard, Plattferverschlüsselung (BitLocker, FileVault)

Relevanz für Informationssicherheit & Compliance

NIS2

• Verlangt „Stand der Technik“ bei technischen und organisatorischen Maßnahmen.

• Endpoint Security ist zentral für:

o Schutz vor Ransomware

o Incident Detection & Response

o Nachweis von Maßnahmen gegenüber Aufsichtsbehörden.

ISO 27001:2022

• Relevante Controls u. a.:

o A.5.15: Access control

o A.5.23: Information security for use of mobile devices

o A.8.7: Protection against malware

o A.8.8: Management of technical vulnerabilities

o A.8.9: Configuration management

IEC 62443 (für OT)

• Endpoint ähnliche Systeme (Engineering Stationen, HMI, Server) müssen:

o gehärtet sein

o nur notwendige Dienste bereitstellen

o überwacht werden

o in Zonen/Conduits eingebettet sein.

Endpoint Security ist damit ein Pflichtbaustein für jede ernsthafte Umsetzung von NIS2, ISO 27001 und IEC 62443.

Empfehlungen für Unternehmen (konkret, priorisiert)

Priorität 1 – Basis schaffen

• Zentrales Endpoint Management einführen (Windows, macOS, Linux, Mobile)

• EDR Lösung ausrollen (mindestens auf kritischen Systemen)

• Patch Management etablieren (inkl. Drittsoftware)

• Plattferverschlüsselung aktivieren (Laptops, mobile Geräte)

• Lokale Adminrechte abschaffen (Role Based Access, Just in Time Admin)

Priorität 2 – Reifegrad erhöhen

• Application Whitelisting für besonders kritische Systeme

• Zero Trust Policies: Zugriff nur bei „gesundem“ Endpoint

• Integration in SIEM/SOC: Alarme zentral auswerten

• Standardisierte Hardening Baselines (CIS, BSI)

Priorität 3 – OT & Spezialumgebungen

• OT Endpoints inventarisieren (Engineering Stationen, HMI, SCADA Server)

• Schutzkonzept definieren:

o Hardening

o Segmentierung

o Monitoring (passiv, wo aktiv nicht möglich)

• Remote Zugriffe auf OT nur über kontrollierte Jump Hosts mit starker Authentifizierung und Session Recording.

CTO Checkliste: Die 3 entscheidenden Fragen

1) „Wie erkennen und stoppen wir heute einen Angriff auf einen Endpoint, der keine bekannte Malware Signatur hat?“

Diese Frage trennt klassischen Antivirus von echtem EDR/XDR. Eine moderne Antwort muss enthalten:

• verhaltensbasierte Erkennung

• Prozess und Speicheranalyse

• Telemetrie Korrelation

• automatische Isolation des Endpoints

• Integration ins SOC/SIEM

Wenn die Antwort nur „Antivirus“ oder „Signaturen“ enthält → nicht modern.

2) „Wie stellen wir sicher, dass alle Endgeräte (inkl. Homeoffice, mobile Geräte, Admin Laptops, OT Engineering Stationen) vollständig verwaltet, gepatcht und gehärtet sind?“

Diese Frage deckt Management Reifegrad, Patch Prozesse und Hardening auf. Eine moderne Antwort muss enthalten:

• zentrales Endpoint Management (UEM/MDM)

• automatisiertes Patch Management (inkl. Drittsoftware)

• CIS/BSI Hardening Baselines

• Compliance Checks vor Zugriff (Zero Trust)

Wenn die Antwort „Wir patchen regelmäßig“ lautet → nicht ausreichend.

3) „Wie schnell können wir einen kompromittierten Endpoint identifizieren, isolieren und forensisch analysieren – und wer macht das konkret?“

Diese Frage prüft Incident Response Fähigkeit und operative Realität. Eine moderne Antwort muss enthalten:

• EDR gestützte Isolation per Klick

• klare Rollen (SOC, IT Ops, Dienstleister)

• forensische Daten (Prozesse, Registry, Netzwerk, Timeline)

• definierte Reaktionszeiten

• Playbooks

Wenn die Antwort unklar ist oder niemand zuständig ist → kritische Lücke.

Firewall, einfach erklärt

Tue, 14 Apr 2026 19:39:30 GMT

Firewall, einfach erklärt

1. Was ist eine Firewall?

Stell dir dein Netzwerk wie ein Gebäude vor.

Eine Firewall ist:

• Der Türsteher: Prüft, wer rein darf.

• Der Sicherheitszaun: Hält unerwünschte Besucher draußen.

• Die Schleuse: Kontrolliert jeden, der das Gelände betreten oder verlassen will.

Sie entscheidet basierend auf Regeln: Wer darf mit wem worüber sprechen?

2. Was ist ein Gateway?

Ein Gateway ist wie ein Grenzübergang zwischen zwei Bereichen:

• zwischen internem Netzwerk und Internet

• zwischen IT und OT

• zwischen Cloud und On Premises

• zwischen verschiedenen Sicherheitszonen

Es kontrolliert:

• welche Daten passieren dürfen

• wie sie geprüft werden

• ob sie sicher sind

3. Warum braucht man Firewalls und Gateways?

Weil Netzwerke ohne sie offene Häuser wären.

Sie schützen vor:

• Hackern

• Malware

• Ransomware

• Datenklau

• unbefugten Zugriffen

• Angriffen auf OT Systeme

Ohne Firewalls wäre jedes Gerät direkt aus dem Internet erreichbar — ein Albtraum.

4. Welche Arten von Firewalls gibt es?

1) Klassische Firewalls

• prüfen IP Adressen und Ports

• wie ein Türsteher, der nur auf die Eintrittskarte schaut

2) Next Generation Firewalls (NGFW)

• prüfen Inhalte

• erkennen Angriffe

• filtern Apps (z. B. „erlaube nur Teams, blockiere Torrent“)

• wie ein Türsteher, der auch Taschen kontrolliert

3) Web Application Firewalls (WAF)

• schützen Webseiten und APIs

• blockieren SQL Injection, XSS, Bots

4) OT Firewalls

• verstehen industrielle Protokolle (Modbus, OPC UA)

• blockieren gefährliche Befehle

• schützen Produktionsanlagen

5) Cloud Firewalls

• steuern Traffic in AWS, Azure, GCP

• sind Teil moderner Cloud Architekturen

5. Wie schützen Firewalls uns?

Sie:

• blockieren Angriffe

• verhindern unbefugte Zugriffe

• segmentieren Netzwerke

• überwachen Datenverkehr

• erkennen Anomalien

• stoppen Malware

• schützen kritische Systeme

6. Typische Fehler (die in der Praxis noch vorkommen)

• „Allow ANY ANY“ (alles erlaubt)

• keine Segmentierung (Flat Network)

• keine Dokumentation

• veraltete Regeln

• keine Überwachung

• keine TLS Inspection → Blindflug

• OT Netze ohne Protokollfilter

7. Was bedeutet das für Unternehmen?

Sie brauchen:

• klare Netzwerkzonen

• moderne Firewalls

• regelmäßige Regelwerks Reviews

• Monitoring & Logging

• Zero Trust Prinzipien

• OT spezifische Schutzmaßnahmen

• Cloud Firewalls für moderne Umgebungen

8. Verbindung zu Standards

• NIS2 verlangt „angemessene technische Maßnahmen“ → Firewalls sind Pflicht

• ISO 27001 verlangt Netzwerksegmentierung und Zugriffskontrollen

• IEC 62443 verlangt Zonen/Conduits und OT Firewalls

• ISO 22301 verlangt Schutz kritischer Systeme

Kurz gesagt

Firewall und Gateway Sicherheit bedeutet:

• Netzwerke in sichere Bereiche aufteilen

• nur erlaubten Verkehr zulassen

• Angriffe erkennen und blockieren

• OT und Cloud Systeme speziell schützen

• Regeln regelmäßig prüfen

• Monitoring aktiv betreiben

Es ist die Grundlage jeder modernen Sicherheitsarchitektur.

Checkliste für Firewall und Gateway Sicherheit

1. Architektur & Netzwerkdesign

• Netzwerk in Sicherheitszonen segmentiert (z. B. IT, OT, DMZ, Cloud)

• Klare Trust Boundaries definiert

• Firewalls an allen Übergängen zwischen Zonen platziert

• Redundante Firewall Cluster vorhanden

• Zero Trust Prinzipien berücksichtigt

• OT Netze strikt von IT getrennt

• Remote Zugänge nur über gesicherte Gateways

2. Regelwerk & Policies

• „Deny by default“ als Grundprinzip

• Nur explizit erlaubte Verbindungen freigeschaltet

• Keine ANY Regeln (Any Source, Any Destination, Any Service)

• Identity-based Rules (Regeln basieren auf User-Gruppen, nicht nur IPs)

• Regeln nach Least Privilege Prinzip

• Regelwerk dokumentiert und versioniert

• Regelwerk regelmäßig überprüft (mind. quartalsweise)

• Alte oder ungenutzte Regeln entfernt

• Regeln nach Zonen, Services und Verantwortlichkeiten strukturiert

3. Traffic Analyse & Inspektion

• Deep Packet Inspection (DPI) aktiviert

• TLS Inspection für relevante Verbindungen aktiviert

• Intrusion Prevention System (IPS) aktiv

• Virtual Patching (WAF/IPS schützt vor Lücken, für die es noch kein Software-Update gibt).

• Malware Scanning aktiviert

• Bot und Anomalie Erkennung aktiv

• Geo Blocking (falls sinnvoll)

• Rate Limiting für kritische Services

4. Web , API und Cloud Gateways

• Web Application Firewall (WAF) für Web Anwendungen aktiv

• API Gateway mit Auth, Rate Limit, Input Validation

• Schutz vor OWASP API Top 10

• Cloud Firewalls (AWS/Azure/GCP) korrekt konfiguriert

• Keine offenen Cloud Security Groups

• CDN /Edge Security integriert (falls genutzt)

5. OT /ICS spezifische Firewall Sicherheit

• OT Firewalls verstehen industrielle Protokolle (Modbus, OPC UA, S7)

• Protokoll Whitelisting aktiv

• Unidirektionale Gateways (Data Diodes) für kritische Systeme

• Engineering Ports nur temporär freigeschaltet

• Keine direkten Verbindungen zwischen IT und OT

• OT Zonen nach IEC 62443 modelliert

6. Zugriffskontrolle & Administration

• Administrationszugänge nur über Jump Server

• MFA für alle Admin Zugänge

• RBAC für Firewall Management

• Änderungen nur über Change Management

• Konfigurations Backups vorhanden

• Firmware aktuell und signiert

• Admin Sessions geloggt

7. Logging, Monitoring & SIEM

• Zentrales Logging aller Firewall Events

• Logs werden mindestens 12 Monate aufbewahrt

• SIEM Integration vorhanden

• Alerts für kritische Ereignisse (z. B. Port Scans, Blocked Traffic)

• Anomalie Erkennung aktiv

• Regelmäßige Auswertung der Logs

• Forensik Daten vollständig

8. Tests & Qualitätssicherung

• Regelmäßige Penetrationstests

• Firewall Regelwerk wird automatisiert geprüft

• Konfigurations Drift Erkennung aktiv

• Notfall Szenarien getestet (Failover, Cluster Switch)

• Testumgebung für Regeländerungen vorhanden

• Regelmäßige Überprüfung der TLS Inspection

9. Dokumentation & Compliance

• Vollständige Dokumentation der Firewall Topologie

• Regelwerk dokumentiert und nachvollziehbar

• Verantwortlichkeiten definiert

• Audit Trails vorhanden

• Konformität zu Standards geprüft, z.B.

o NIS2

o ISO 27001 (A.8.20, A.8.16, A.5.17/18)

o IEC 62443 (Zonen/Conduits, SR 3.x, SR 5.x, SR 7.x)

o ISO 22301 (Schutz kritischer Systeme)

10. Typische Fehler, die vermieden werden müssen

• Keine ANY Regeln

• Keine offenen Ports „zur Sicherheit“

• Keine unüberwachten Remote Zugänge

• Keine veralteten Firewall Versionen

• Keine ungenutzten Regeln

• Keine direkte IT ↔OT Kommunikation

• Keine / fehlende TLS Inspection

Docker, einfach erklärt

Tue, 14 Apr 2026 19:31:03 GMT

Docker, einfach erklärt

Docker ist eine Technologie, mit der Software in Container verpackt wird. Ein Container ist wie eine kleine, abgeschlossene Box, in der alles drin ist, was ein Programm zum Laufen braucht:

die Anwendung selbst
Bibliotheken
Konfigurationen
Systemabhängigkeiten

Dadurch läuft die Software überall gleich, egal ob:

auf einem Laptop
in der Cloud
auf einem Server
in einem Rechenzentrum

Docker löst das klassische Problem „Bei mir läuft’s, bei dir nicht“ vollständig.

Warum Container?

Weil klassische Software oft abhängig ist von:

• bestimmten Versionen von Bibliotheken
• bestimmten Betriebssystemen
• bestimmten Konfigurationen

Container isolieren diese Abhängigkeiten — wie ein eigenes Mini System.

Wie funktioniert Docker technisch?

Docker nutzt Containerisierung, nicht Virtualisierung.

Virtual Machine (VM)

enthält ein komplettes Betriebssystem
braucht viel Speicher
startet langsam

Docker Container

nutzt das Host Betriebssystem mit
ist extrem leichtgewichtig
startet in Sekundenbruchteilen

Technisch basiert Docker auf:

Namespaces (Isolation)
cgroups (Ressourcenbegrenzung)
Union File Systems (schichtbasierte Images)

Woraus besteht Docker?

1. Docker Image

Ein Image ist eine Bauvorlage für Container. Beispiel: „Webserver Image“, „Python App Image“.

2. Docker Container

Ein laufendes Exemplar eines Images. Beispiel: „Webserver Container läuft jetzt auf Port 80“.

3. Dockerfile

Eine Textdatei, die beschreibt, wie ein Image gebaut wird.

4. Docker Engine

Die Software, die Container startet und verwaltet.

5. Docker Hub

Eine Art „App Store“ für fertige Images.

Wofür wird Docker genutzt?

1. Softwareentwicklung

Entwickler können identische Umgebungen nutzen.

2. DevOps & CI/CD

Automatisierte Builds, Tests und Deployments. Ein Entwickler kann per Knopfdruck eine komplexe Datenbank-Umgebung starten, ohne sie lokal installieren zu müssen. Automatisches Testen von Code in einer sauberen Umgebung.

3. Microservices

Jeder Service läuft in seinem eigenen Container. Statt einer riesigen, schweren Software nutzt man 20 kleine Container, die miteinander kommunizieren.

4. Cloud Betrieb

Container sind perfekt für AWS, Azure, GCP.

5. Skalierung

Container können automatisch hoch und runtergefahren werden.

Sicherheitsaspekte (für Nicht Admins)

Container sind isoliert, aber teilen sich den Kernel. Das bedeutet:

• sie sind sicherer als klassische Apps

• aber weniger isoliert als VMs

Wichtige Sicherheitsmechanismen:

Signierte Images
Trusted Registries
Schwachstellenscans (z.B. mit Trivy, Clair)
Least Privilege (keine Root Container)

Was eine KI Richtlinie berücksichtigen sollte

Mon, 30 Mar 2026 20:34:23 GMT

KI-Richtlinie 2026:

Was eine moderne AI Policy für Unternehmen regeln sollte

Von ChatGPT zur autonomen KI: Warum eine KI-Richtlinie heute weit mehr als ein Verbot vertraulicher Daten im Prompt sein muss

Künstliche Intelligenz hat sich in kurzer Zeit grundlegend verändert.

Noch vor wenigen Jahren bestand die typische KI-Nutzung in Unternehmen darin, einen Text mit ChatGPT zu erstellen, eine Präsentation zusammenzufassen oder einen Programmcode generieren zu lassen.

Heute reicht das Spektrum wesentlich weiter:

Large Language Models (LLMs)
Generative KI
RAG-Systeme mit Unternehmenswissen (Retrieval-Augmented Generation)
AI Copilots
multimodale KI
lokale und private KI-Modelle
Fine-Tuning
AI-as-a-Service
KI-gestützte Softwareentwicklung
autonome bzw. agentische KI-Systeme
AI Agents mit Zugriff auf Unternehmenssysteme
Multi-Agent-Systeme
KI mit Zugriff auf APIs, Datenbanken und Tools

Damit verändert sich auch das Risiko.

Eine KI kann heute nicht mehr nur Information erzeugen . Sie kann Informationen suchen, interpretieren, Entscheidungen vorbereiten, Software verändern und – bei entsprechendem Zugriff – Aktionen in IT-Systemen ausführen.

Eine moderne KI-Richtlinie muss deshalb drei Fragen beantworten:

Welche KI darf eingesetzt werden?
Unter welchen Bedingungen darf sie eingesetzt werden?
Welche Kontrolle bleibt beim Menschen?

1. Warum eine klassische KI-Richtlinie nicht mehr ausreicht

Viele Unternehmen haben inzwischen eine einfache KI-Nutzungsrichtlinie:

„Keine vertraulichen Informationen in ChatGPT eingeben.“

Das ist sinnvoll – aber nicht mehr ausreichend.

Denn moderne KI-Systeme erzeugen neue Risikoklassen.

Beispielsweise kann ein Mitarbeiter heute einen AI Agent mit seinem Microsoft-365-Konto verbinden. Der Agent kann anschließend E-Mails lesen, Dokumente analysieren, Termine verwalten oder andere Systeme über APIs ansprechen.

Das Risiko entsteht damit nicht mehr ausschließlich durch den Prompt.

Es entsteht durch die Kombination aus:

KI-Modell + Daten + Identität + Berechtigungen + Tools + Schnittstellen + Prozess + Mensch.

Das ist ein grundlegender Unterschied.

Eine moderne KI-Richtlinie sollte deshalb nicht nur die Nutzung von Chatbots regeln, sondern den gesamten AI Lifecycle .

2. Das regulatorische Umfeld hat sich erheblich erweitert

Eine KI-Richtlinie steht heute nicht mehr isoliert.

Je nach Unternehmen können unter anderem folgende Regelwerke relevant sein:

Regelwerk / Standard, Bedeutung für KI

EU AI Act: Risikoklassifizierung, Verbote, Transparenz, AI Literacy, Anforderungen an bestimmte KI-Systeme
DSGVO: Verarbeitung personenbezogener Daten, Betroffenenrechte, Zweckbindung, Datenschutz-Folgenabschätzung
NIS2: Cybersecurity, Risikomanagement und Incident Management für betroffene Organisationen
DORA: Digitale operationale Resilienz im Finanzsektor
Cyber Resilience Act (CRA): Cybersecurity-Anforderungen an Produkte mit digitalen Elementen
EU Data Act: Datenzugang, Datennutzung und Datenverarbeitung
Produkthaftungsrecht: Haftungsfragen bei Software, KI und digitalen Produkten
ISO/IEC 27001: In formationssicherheitsmanagement
ISO/IEC 42001: AI Management System
ISO/IEC 23894: Risikomanagement für KI
ISO/IEC 22989: Begriffe und Konzepte rund um KI
OWASP GenAI Security: Technische Risiken von LLM- und GenAI-Anwendungen
OWASP Agentic AI: Risiken autonomer, tool-nutzender KI-Agenten

Der EU AI Act ist dabei besonders wichtig. Seit 2. August 2026 sind wesentliche Teile des AI Act anwendbar; die Verbote bestimmter KI-Praktiken und die Anforderungen an AI Literacy gelten bereits seit Februar 2025. Die Regelungen für General-Purpose AI gelten seit August 2025. Für bestimmte Hochrisiko-KI gelten allerdings verlängerte Übergangsfristen.

Für Unternehmen mit digitalen Produkten kommt zusätzlich der Cyber Resilience Act hinzu. Die Meldepflichten für aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle gelten bereits seit 11. September 2026 ; die wesentlichen CRA-Anforderungen werden ab Dezember 2027 vollständig anwendbar.

Für Finanzunternehmen ist DORA bereits seit 17. Januar 2025 anzuwenden.

NIS2 gilt ebenfalls bereits im europäischen Rechtsrahmen; die Mitgliedstaaten mussten die Richtlinie grundsätzlich bis Oktober 2024 umsetzen.

Eine KI-Richtlinie sollte daher Teil eines übergeordneten Compliance- und Managementsystems sein – nicht als isoliertes Dokument betrachtet werden.

3. AI Governance: Wer ist eigentlich verantwortlich?

Eine der wichtigsten Ergänzungen gegenüber älteren KI-Richtlinien ist die Frage nach der Governance .

Es sollte nicht einfach heißen:

„Die IT ist für KI verantwortlich.“

KI betrifft viele Unternehmensbereiche.

Eine sinnvolle Governance kann beispielsweise folgende Rollen enthalten:

Geschäftsführung
AI Governance / AI Management
Informationssicherheit
Datenschutz
IT
Legal / Compliance
Fachabteilungen
HR
Einkauf
Softwareentwicklung
Risikomanagement
Qualitätsmanagement

Dabei sollte eindeutig geregelt werden:

Wer darf KI genehmigen?
Wer führt die Risikoanalyse durch?
Wer prüft Datenschutz und Informationssicherheit?
Wer genehmigt Hochrisiko-Anwendungen?
Wer überwacht KI-Systeme im Betrieb?
Wer entscheidet über Abschaltung oder Rücknahme?

ISO/IEC 42001 bietet hierfür inzwischen einen eigenen Managementsystem-Ansatz. Der Standard beschreibt ein AI Management System für Organisationen, die KI entwickeln, bereitstellen oder nutzen.

4. KI-Inventar statt nur einer White List

Eine reine White List mit „erlaubten Tools“ reicht nicht mehr aus.

Unternehmen sollten ein KI-Inventar aufbauen.

Für jedes relevante KI-System sollten mindestens folgende Informationen vorhanden sein:

Name des Systems
Anbieter
verwendetes Modell
Version
Zweck
Fachprozess
verantwortlicher Owner
Benutzergruppen
verwendete Daten
personenbezogene Daten?
vertrauliche Daten?
Geschäftsgeheimnisse?
Schnittstellen
verwendete Tools
Berechtigungen
Standort / Datenverarbeitung
Subprozessoren
Modelltraining mit Kundendaten?
Risiko-Klasse
Human Oversight
Protokollierung
Notfallverfahren
Abschaltmöglichkeit

Damit entsteht aus der KI-Richtlinie ein praktisches AI Asset Management .

5. Risikoklassifizierung: Nicht jede KI ist gleich

Eine moderne KI-Richtlinie sollte verschiedene Risikoklassen unterscheiden.

Klasse 1 – Assistive KI

Beispiele:

Textentwürfe
Übersetzungen
Zusammenfassungen
Brainstorming
allgemeine Recherche

Risiko: vergleichsweise niedrig.

Klasse 2 – Unternehmensinterne KI

Beispiele:

RAG über interne Dokumente (Retrieval-Augmented Generation)
interner Wissensassistent
KI für Vertragsanalyse
KI für Support

Hier werden bereits Unternehmensdaten verarbeitet.

Klasse 3 – Entscheidungsunterstützende KI

Beispiele:

Bewerbervorauswahl
Kreditbewertung
Qualitätsentscheidung
Risikoanalyse
medizinische Entscheidungsunterstützung

Hier steigen Datenschutz-, Compliance- und Haftungsrisiken erheblich.

Klasse 4 – Hochrisiko-KI

Hier sind die Anforderungen des AI Act zu berücksichtigen.

Klasse 5 – Autonome / agentische KI

Beispiele:

Agent darf Tickets selbstständig schließen
Agent kann Bestellungen auslösen
Agent verändert Daten
Agent schreibt und deployed Software
Agent kann E-Mails versenden
Agent greift auf ERP-, CRM- oder Cloud-Systeme zu

Hier entsteht eine neue Risikodimension:

Was darf die KI selbstständig tun?

6. LLMs verändern das Sicherheitsmodell

Large Language Models bringen neue Angriffsmöglichkeiten mit sich.

Eine moderne KI-Richtlinie sollte deshalb mindestens folgende Risiken berücksichtigen:

Prompt Injection
Indirect Prompt Injection
Jailbreaking
Sensitive Information Disclosure
Model / Data Poisoning
Supply-Chain-Risiken
Improper Output Handling
System-Prompt Leakage
Vector- und Embedding-Risiken
Halluzinationen
Unbounded Consumption
Excessive Agency

Diese Risiken werden beispielsweise im OWASP GenAI Security Project systematisch behandelt. Die OWASP Top 10 für LLM-Anwendungen adressiert unter anderem Prompt Injection, Sensitive Information Disclosure, Supply-Chain-Risiken, Excessive Agency und Vector-/Embedding-Schwachstellen.

Damit sollte eine KI-Richtlinie nicht mehr nur fragen:

„Welche Daten dürfen in die KI eingegeben werden?“

sondern auch:

„Welche Anweisungen darf die KI ausführen und welchen Daten und Systemen darf sie vertrauen?“

7. Agentic AI: Die neue Risikoklasse

Besonders wichtig ist die Entwicklung von AI Agents.

Ein klassischer Chatbot antwortet.

Ein Agent kann dagegen:

ein Ziel erhalten,
Informationen recherchieren,
einen Plan erstellen,
Tools auswählen,
APIs aufrufen,
Ergebnisse bewerten,
weitere Aktionen durchführen.

Damit wird aus einem Informationssystem zunehmend ein handelndes System.

Ein Agent könnte beispielsweise:

„Prüfe alle offenen Kundenreklamationen, analysiere die Ursachen, erstelle Antworten und schließe die Tickets, wenn die Voraussetzungen erfüllt sind.“

Das ist qualitativ etwas anderes als:

„Fasse mir diese Reklamationen zusammen.“

Für Agenten sollte eine Richtlinie deshalb zusätzliche Kontrollen verlangen.

Agent Permissions

Jeder Agent benötigt klar definierte Berechtigungen:

Read
Create
Modify
Delete
Approve
Execute
Send
Purchase

Das Prinzip sollte lauten:

Least Privilege für AI Agents.

Ein Agent sollte niemals mehr Rechte besitzen als unbedingt erforderlich.

8. Human-in-the-Loop reicht bei Agenten nicht immer aus

Der klassische Begriff Human in the Loop muss präzisiert werden.

Ein Mensch, der nur gelegentlich auf einen „OK“-Button klickt, ist keine ausreichende Kontrolle, wenn die KI bereits umfangreiche Aktionen durchführen kann.

Daher sollte zwischen verschiedenen Kontrollstufen unterschieden werden:

Human-in-the-Loop

Der Mensch muss die Aktion freigeben.

Human-on-the-Loop

Der Mensch überwacht den Prozess und kann eingreifen.

Human-in-Command

Der Mensch kann den Agenten jederzeit stoppen und besitzt die letztendliche Entscheidungshoheit.

Für kritische Aktionen sollte beispielsweise gelten:

Keine autonome Ausführung ohne menschliche Freigabe bei:

Geldtransaktionen
Vertragsabschluss
Personalentscheidungen
Löschung wichtiger Daten
produktiven Systemänderungen
Veröffentlichung externer Kommunikation
sicherheitskritischen Änderungen
Änderungen an Berechtigungen

9. Identität und Berechtigungen von KI

Ein neues Thema, das in älteren KI-Richtlinien fast vollständig fehlt:

KI benötigt eine digitale Identität.

Wenn ein Agent auf Unternehmenssysteme zugreift, darf er nicht einfach die Identität eines Mitarbeiters übernehmen.

Es sollte nachvollziehbar sein:

welcher Benutzer
welcher Agent
welches Modell
welcher Prozess
welcher Auftrag
welche Berechtigung
welche Aktion

eine Änderung durchgeführt hat.

Damit wird AI Identity & Access Management zu einem wichtigen Bestandteil der KI-Governance.

10. RAG und Unternehmenswissen

Viele Unternehmen trainieren heute nicht ihr eigenes LLM.

Stattdessen verwenden sie Retrieval-Augmented Generation (RAG) .

Dabei greift ein LLM auf Unternehmensdokumente, Datenbanken oder Wissensbestände zu.

Das bringt neue Risiken:

falsche Dokumente werden gefunden
Benutzer sehen Dokumente ohne Berechtigung
veraltete Informationen werden verwendet
manipulierte Dokumente beeinflussen die Antwort
vertrauliche Informationen werden in Antworten zusammengeführt

Deshalb muss gelten:

Die Zugriffskontrolle des RAG-Systems muss mindestens so streng sein wie die Zugriffskontrolle der zugrunde liegenden Daten.

Ein Mitarbeiter darf über einen KI-Assistenten nicht plötzlich Dokumente lesen können, auf die er im Originalsystem keinen Zugriff hat.

11. Daten- und Datenschutz-Governance für KI

Der Datenschutzteil der alten Richtlinie sollte ebenfalls erweitert werden.

Nicht nur die Eingabe ist relevant.

Zu betrachten sind:

Input → Verarbeitung → Retrieval → Modell → Output → Speicherung → Logging → Training

Besondere Themen:

personenbezogene Daten
besondere Kategorien personenbezogener Daten
Geschäftsgeheimnisse
Kundendaten
Mitarbeiterdaten
Trainingsdaten
Prompts
Chatverläufe
Embeddings
Vektordatenbanken
Logs
Telemetriedaten

Der EDSA hat inzwischen ausdrücklich Aspekte der Verarbeitung personenbezogener Daten bei Entwicklung und Einsatz von KI-Modellen behandelt. Dazu gehören unter anderem Anonymität, berechtigtes Interesse und die Folgen einer unrechtmäßigen Verarbeitung von Trainingsdaten.

Eine wichtige Konsequenz:

„Die Daten stehen im Internet“ bedeutet nicht automatisch „Die Daten dürfen für KI verwendet werden“.

12. KI-Output ist nicht automatisch richtig

Eine KI kann überzeugend falsche Informationen erzeugen.

Deshalb sollte die Richtlinie abhängig vom Risiko unterschiedliche Prüfpflichten definieren.

Niedriges Risiko

Stichprobenartige Kontrolle.

Mittleres Risiko

Fachliche Prüfung vor Verwendung.

Hohes Risiko

Dokumentierte menschliche Freigabe.

Kritische Entscheidungen

Keine alleinige Entscheidung durch KI.

Zu prüfen sind insbesondere:

Fakten
Quellen
Berechnungen
rechtliche Aussagen
technische Aussagen
personenbezogene Aussagen
Bias
Manipulation
Halluzinationen
Aktualität

13. KI-gestützte Softwareentwicklung

Ein eigener Abschnitt ist heute zwingend sinnvoll.

Beispiele:

GitHub Copilot
Coding Agents
KI-generierter Quellcode
automatisierte Code Reviews
KI-generierte Tests
KI-generierte Infrastructure-as-Code
KI-generierte SQL-Abfragen

Regeln sollten unter anderem festlegen:

keine vertraulichen Quellcodes in nicht freigegebenen Systemen
Code muss durch Entwickler geprüft werden
Security Testing bleibt erforderlich
Lizenz- und Open-Source-Risiken prüfen
Secrets dürfen nicht in Prompts gelangen
generierter Code muss nachvollziehbar geprüft werden
KI darf nicht eigenständig produktive Änderungen durchführen, sofern dies nicht ausdrücklich freigegeben ist

Besonders bei Coding Agents wird die Grenze zwischen „Assistenz“ und „autonomer Softwareentwicklung“ zunehmend fließend.

14. AI Supply Chain Management

KI wird häufig von Drittanbietern bezogen.

Damit entsteht ein klassisches Third-Party-Risk-Management .

Zu prüfen sind beispielsweise:

Anbieter
Modell
Subprozessoren
Hosting
Datenstandort
Datenschutz
Informationssicherheit
Zertifizierungen
Vertragsbedingungen
Training mit Kundendaten
Retention
Löschkonzept
Incident Management
Business Continuity
Modelländerungen
Abhängigkeit vom Anbieter
Exit-Strategie

Besonders wichtig:

Welches Modell wird tatsächlich verwendet?

Ein Anbieter kann seine zugrunde liegenden Modelle ändern, ohne dass sich die Benutzeroberfläche verändert.

Daher gehört Model Change Management in eine moderne KI-Governance.

15. AI Lifecycle Management

Eine KI-Anwendung sollte wie ein IT-System behandelt werden.

Der Lifecycle umfasst:

Idee → Bewertung → Entwicklung → Freigabe → Betrieb → Monitoring → Änderung → Review → Abschaltung

Für jede Phase sollten Verantwortlichkeiten definiert werden.

Besonders wichtig:

Before Go-Live

Risikoanalyse
Datenschutzprüfung
Security Assessment
AI-Act-Klassifizierung
fachliche Freigabe
Test
Dokumentation

During Operation

Monitoring
Incident Management
Performance Monitoring
Bias Monitoring
Security Monitoring
Modelländerungen

End of Life

Abschaltung
Löschung von Daten
Entzug von Berechtigungen
Archivierung relevanter Nachweise
Entfernung von APIs und Credentials

16. AI Security Testing

Klassische Funktionstests reichen bei KI nicht aus.

Zusätzlich erforderlich können sein:

Prompt-Injection-Tests
Jailbreak-Tests
Datenschutztests
Halluzinationstests
Bias-Tests
Robustheitstests
Red Teaming
Abuse Cases
Adversarial Testing
Tool- und API-Sicherheit
Agent-Hijacking-Tests

Gerade Agenten benötigen neue Testansätze.

NIST hat beispielsweise auf das Risiko des Agent Hijacking hingewiesen: Manipulierte Inhalte können indirekte Prompt Injection verursachen und einen Agenten zu unerwünschten Aktionen bewegen.

OWASP hat deshalb inzwischen einen eigenen Top 10-Ansatz für Agentic Applications veröffentlicht. Dieser adressiert unter anderem Goal Hijacking, Tool Misuse, Identity & Privilege Abuse, Agentic Supply Chain Vulnerabilities und unerwartete Codeausführung.

17. Logging und Audit Trail

Eine moderne KI-Governance benötigt nachvollziehbare Protokollierung.

Je nach Risiko sollten beispielsweise dokumentiert werden:

Benutzer
KI-System
Modell
Version
Prompt
relevante Datenquelle
verwendete Tools
Agent Actions
Entscheidungen
Freigaben
Output
Fehler
Sicherheitsereignisse

Dabei muss allerdings gleichzeitig der Datenschutz berücksichtigt werden.

Es gilt daher nicht:

„Alles speichern.“

Sondern:

So viel protokollieren wie für Sicherheit, Nachvollziehbarkeit und Compliance erforderlich – und so wenig wie möglich personenbezogene Daten speichern.

18. Incident Management für KI

Eine KI-Richtlinie sollte einen eigenen AI-Incident-Prozess definieren.

Beispiele:

vertrauliche Daten wurden an ein KI-System übermittelt
KI erzeugt falsche kritische Informationen
Agent führt unerlaubte Aktion aus
Prompt Injection erfolgreich
personenbezogene Daten werden ausgegeben
Modell wird manipuliert
Trainingsdaten sind kompromittiert
API-Key eines Agenten wurde missbraucht
KI-System fällt aus
Anbieter ändert Modell unerwartet

Dabei muss die KI-Richtlinie mit bestehenden Prozessen verbunden werden:

**Information Security Incident Management

Datenschutzverletzung
Business Continuity
Crisis Management
Supplier Incident Management**

Bei Produkten mit digitalen Elementen kommt zusätzlich der CRA hinzu. Seit September 2026 bestehen für Hersteller bereits spezifische Meldepflichten für aktiv ausgenutzte Schwachstellen und schwere Sicherheitsvorfälle.

19. AI Literacy und Schulung

Schulung bedeutet heute mehr als:

„Bitte keine vertraulichen Daten in ChatGPT eingeben.“

Mitarbeiter sollten mindestens verstehen:

Was ist ein LLM?
Was ist Generative AI?
Was ist RAG?
Was ist ein AI Agent?
Was ist Prompt Injection?
Was ist eine Halluzination?
Welche Daten dürfen verwendet werden?
Wie überprüfe ich KI-Ergebnisse?
Wann muss ein Mensch entscheiden?
Wann muss ein KI-Einsatz gemeldet werden?
Welche KI-Tools sind freigegeben?

Der AI Act enthält ausdrücklich Anforderungen zur AI Literacy ; diese gelten bereits seit Februar 2025.

Für unterschiedliche Zielgruppen sollten unterschiedliche Schulungen vorgesehen werden:

Zielgruppe: Schwerpunkte

Mitarbeiter: sichere KI-Nutzung
Führungskräfte: Governance und Verantwortung
Entwickler: AI Security / Secure AI Coding
Administratoren: Identity, Access, Logging
Datenschutz: DSGVO und KI
Informationssicherheit: AI Threats
Einkauf: AI Supplier Risk
Auditoren: Nachweise und Wirksamkeit
Management: Risiko, Haftung und Governance

20. Transparenz und Kennzeichnung

Seit August 2026 sind bestimmte Transparenzpflichten des AI Act anwendbar. Dazu gehören unter anderem Anforderungen im Zusammenhang mit der Information von Personen, wenn sie mit bestimmten KI-Systemen interagieren, sowie Vorgaben für bestimmte synthetische Inhalte. Die Europäische Kommission hat hierzu 2026 eigene Leitlinien veröffentlicht.

Eine KI-Richtlinie sollte deshalb definieren:

Wann muss auf KI hingewiesen werden?
Wann müssen Inhalte gekennzeichnet werden?
Wie werden KI-generierte Bilder gekennzeichnet?
Wie werden Deepfakes behandelt?
Wie werden Chatbots kenntlich gemacht?
Wie werden KI-generierte Dokumente behandelt?

21. Urheberrecht und geistiges Eigentum

Auch dieser Punkt sollte erweitert werden.

Zu betrachten sind:

Trainingsdaten
Copyright
Lizenzbedingungen
Open Source
Softwarelizenzen
Unternehmenswissen
Geschäftsgeheimnisse
KI-generierte Inhalte
Rechte Dritter

Besonders für Softwareentwickler ist wichtig:

KI-generierter Code darf nicht ungeprüft übernommen werden.

Es müssen weiterhin die üblichen Prozesse für Lizenzprüfung, Security Review und Qualitätssicherung gelten.

22. Business Continuity und Exit Strategy

Was passiert, wenn der KI-Anbieter morgen nicht verfügbar ist?

Oder:

API fällt aus
Modell wird geändert
Anbieter erhöht Preise
Datenstandort ändert sich
Service wird eingestellt
Modell wird schlechter
Unternehmen verliert den Zugang

Für kritische KI-Systeme sollte deshalb eine Exit-Strategie existieren.

Beispiele:

alternatives Modell
alternativer Provider
lokales Modell
manueller Prozess
Fallback-System
Datenexport
Wiederanlaufverfahren

Damit wird KI auch zu einem Thema für Business Continuity Management .

23. KI und bestehende Managementsysteme verbinden

Eine der größten Chancen liegt darin, KI nicht als isoliertes Compliance-Projekt aufzubauen.

Viele Unternehmen verfügen bereits über:

ISO 9001
ISO 27001
ISO 22301
ISO 31000
ISO 13485
IT Service Management
Datenschutzmanagement
Compliance Management

KI kann in diese Systeme integriert werden.

Besonders interessant ist die Kombination:

ISO/IEC 27001 + ISO/IEC 42001 + ISO/IEC 23894

ISO/IEC 42001 stellt das Managementsystem für KI bereit, während ISO/IEC 23894 konkrete Orientierung für das Management KI-spezifischer Risiken gibt.

Damit kann beispielsweise ein bestehendes ISMS um AI Governance erweitert werden.

24. Die KI-Richtlinie als praktisches Regelwerk

Eine moderne KI-Richtlinie sollte deshalb mindestens folgende Kapitel enthalten:

1. Zweck und Geltungsbereich

2. Begriffe und Definitionen

3. AI Governance und Verantwortlichkeiten

4. KI-Inventar

5. Klassifizierung von KI-Systemen

6. EU AI Act und regulatorische Anforderungen

7. Zulässige und verbotene Anwendungen

8. Datenschutz und personenbezogene Daten

9. Informationsklassifizierung

10. LLM-Nutzung

11. RAG und Unternehmenswissen

12. AI Agents und autonome Systeme

13. Identitäten und Berechtigungen

14. Human Oversight

15. KI-Output und Qualitätssicherung

16. KI-gestützte Softwareentwicklung

17. AI Security

18. AI Supply Chain

19. Beschaffung und Third-Party Risk

20. AI Lifecycle Management

21. Testing und Red Teaming

22. Logging und Audit Trail

23. Incident Management

24. Business Continuity und Exit

25. Schulung und AI Literacy

26. Transparenz und Kennzeichnung

27. Urheberrecht und geistiges Eigentum

28. Monitoring und Audit

29. Kennzahlen und Management Review

30. Sanktionen und Verstöße

31. Revision und kontinuierliche Verbesserung

25. Ein praktischer Freigabeprozess

In der Praxis sollte ein Unternehmen nicht für jede KI-Anwendung einen mehrwöchigen Freigabeprozess benötigen.

Sinnvoll ist ein risikobasierter Ansatz.

Beispielsweise:

KI-Idee

↓

Was soll die KI tun?

↓

Welche Daten verwendet sie?

↓

Greift sie auf Unternehmenssysteme zu?

↓

Kann sie selbstständig Aktionen durchführen?

↓

Welche Personen oder Produkte sind betroffen?

↓

AI-Act-Klassifizierung

↓

Datenschutzprüfung

↓

Security Risk Assessment

↓

Supplier Assessment

↓

Test

↓

Freigabe

↓

Betrieb und Monitoring

↓

Regelmäßige Neubewertung

Fazit

Eine KI-Richtlinie für 2026 sollte nicht mehr ausschließlich eine „Do-not-do-Liste für ChatGPT“ sein.

Die eigentliche Herausforderung besteht darin, KI kontrolliert in bestehende Geschäftsprozesse zu integrieren.

Dabei sollte ein Unternehmen vier Ebenen unterscheiden:

1. Mensch
Wer darf KI verwenden und wer trägt Verantwortung?

2. Daten
Welche Informationen darf die KI sehen und verarbeiten?

3. Modell
Welches Modell wird verwendet, wie wurde es entwickelt und welchen Risiken unterliegt es?

4. Agent / Handlung
Was darf die KI selbstständig tun?

Gerade die vierte Ebene wird in den kommenden Jahren entscheidend.

Denn der Schritt von

„KI beantwortet meine Frage“

„KI erledigt die Aufgabe für mich“

verändert das Risikomodell fundamental.

Eine moderne AI Governance muss deshalb nicht nur KI-Nutzung , sondern KI-Verhalten kontrollieren.

Das Ziel sollte dabei nicht sein, KI möglichst stark einzuschränken.

Das Ziel ist vielmehr:

KI dort ermöglichen, wo sie Nutzen schafft – und dort kontrollieren, wo sie Risiken erzeugt.

So wird aus einer KI-Richtlinie ein praktischer Bestandteil von Informationssicherheit, Risikomanagement, Compliance, Datenschutz, Qualitätsmanagement und Resilienzmanagement .

KI Governance ist damit nicht mehr nur ein IT-Thema. Sie wird zu einer Managementaufgabe.

P.S.

Im Rahmen eines ISMS gemäß ISO/IEC 27001:2022, könnten folgende Kapitel als Basis dienen, einzelne Themen konkret und detaillierter zu verankern, und zu auditieren, z.B.

Auditreferenzen ISO / IEC 27001:

Richtlinien: A.5.1
Regulatorisches / Compliance / Transparenz / Kennzeichnung: A.5.31, A.5.34
AI Governance, Verantwortungen, Rollen A.5.2, A.5.4
KI Inventar: A.5.9
KI Risikobewertung, und Schutzbedarfsklassifizierung: 6.1.2, 6.1.3, A.5.12
Eigene Entwicklungen von LLM oder Agents: A.8.25 ff, und A.8.8
Agent Permissions: A.5.15 ff, A.8.3, A.8.12 (DLP)
AI Lieferanten / Cloud Dienste A.5.23
Änderungen A.8.32
Logging / Audit Trail / Monitoring: A.8.15 A:.8.16
AI Related Incident Mgmt: A:5.24 ff
BCM : A.5.29 ff
KI Kompetenz, Awareness: A.6.3
Urheberrecht / Intelectual Property: A.8.32
KVP / Reporting / Überwachung: A.5.36

Ihr Konstantin Ziouras

Cryptographic Bill of Material

Mon, 30 Mar 2026 20:15:15 GMT

Cryptographic Bill of Material (CBOM, CryptoBOM, Crypto SBOM)

Warum Kryptografie in einer SBOM unverzichtbar ist

Moderne Software nutzt an vielen Stellen kryptografische Komponenten – oft tief in Frameworks, Bibliotheken oder Protokollen verborgen. Dazu gehören u. a.:

• TLS Bibliotheken

• Hash Funktionen

• Verschlüsselungsalgorithmen

• Zertifikate

• Schlüsselmaterial

• Token Signaturen

• Kryptografische Frameworks (OpenSSL, BouncyCastle, libsodium …)

Sobald in einem dieser Bausteine eine Schwachstelle entsteht (z. B. Heartbleed, Logjam, SHA 1 Risiken), muss ein Unternehmen sofort erkennen können, ob es betroffen ist.

Eine SBOM, die Kryptografie Informationen enthält, macht genau das möglich.

A ) Wie CycloneDX Kryptografie abbildet

CycloneDX bietet ein eigenes Cryptographic Components Model, mit dem kryptografische Elemente strukturiert erfasst werden können.

1. Kryptografische Algorithmen

Beispiele:

• AES

• RSA

• ECDSA

• SHA 256

• PBKDF2

• ChaCha20

CycloneDX dokumentiert:

• verwendeter Algorithmus

• Version

• Modus (z. B. AES GCM vs. AES CBC)

2. Kryptografische Bibliotheken

Jede Bibliothek kann als Komponente erfasst werden, z. B.:

• OpenSSL

• BouncyCastle

• libsodium

• WolfSSL

• Microsoft CNG

• Java Cryptography Architecture (JCA)

Mit Metadaten wie:

• Version

• Quelle

• Hash

• Lizenz

• CVE Bezug

3. Zertifikate

CycloneDX kann Zertifikate als eigene Objekte abbilden:

• X.509 Zertifikate

• TLS Zertifikate

• Code Signing Zertifikate

Mit:

• Fingerprint

• Aussteller

• Ablaufdatum

• Key Usage

• Public Key Algorithmus

4. Schlüsselmaterial (nur Metadaten!)

CycloneDX erfasst keine Schlüssel, sondern ausschließlich Metadaten:

• Schlüssellänge

• Algorithmus

• Verwendungszweck (Signatur, Verschlüsselung, TLS Handshake)

Das ermöglicht Compliance Nachweise, ohne Sicherheitsrisiken zu erzeugen.

5. Kryptografische Services

Auch kryptografische Dienste können modelliert werden, z. B.:

• TLS Terminator

• HSM Nutzung

• Token Signaturdienste

• Key Management Systeme

B ) Wie CycloneDX Kryptografie erkennt

CycloneDX ist ein Format, kein Scanner. Die Erkennung erfolgt durch Tools wie:

• Syft

• Trivy

• CycloneDX CLI

• Snyk

• OWASP Dependency Track

Diese analysieren u. a.:

• Bibliotheken

• Container

• Build Artefakte

• Konfigurationsdateien

• Zertifikate

• Laufzeitumgebungen

und erzeugen daraus eine SBOM mit Kryptografie Einträgen.

C ) Wie man CycloneDX für Kryptografie sinnvoll nutzt

1. Kryptografische Inventarisierung

Frage: „Welche Kryptobibliotheken und Algorithmen verwenden wir überhaupt?“ CycloneDX liefert:

• vollständige Liste

• Versionen

• CVE Risiken

2. Compliance & Regulierung

Regulatorien wie NIS2, DORA, ISO 27001, ETSI EN 303 645 verlangen:

• sichere Algorithmen

• keine veralteten Hashes

• keine unsicheren Cipher Suites

CycloneDX zeigt z. B.:

• ob SHA 1 noch genutzt wird

• ob TLS 1.0/1.1 aktiv ist

• ob schwache RSA Schlüssel existieren

3. Schwachstellenmanagement

Wenn eine Kryptobibliothek eine CVE hat (z. B. OpenSSL):

• Wo wird sie verwendet?

• In welcher Version?

• In welchen Produkten oder Komponenten?

CycloneDX ermöglicht sofortige Impact Analysen.

4. Lieferkettensicherheit

CycloneDX zeigt, ob Drittanbieter:

• unsichere Algorithmen nutzen

• abgelaufene Zertifikate einsetzen

• veraltete Bibliotheken einbinden

Damit wird Kryptografie zu einem prüfbaren Bestandteil des Software Supply Chain Risikos.

D ) Checkliste für SBOM Kryptografie Check

(für CycloneDX, NIS2, Secure SDLC, Lieferkettensicherheit)

1. Vollständigkeit der Kryptografie Erfassung

• Enthält die SBOM kryptografische Komponenten gemäß CycloneDX Crypto Model?

• Werden alle relevanten Kryptoelemente erfasst:

o Algorithmen

o Bibliotheken

o Zertifikate

o Schlüsselmaterial (nur Metadaten)

o Kryptografische Services

• Sind auch transitive Abhängigkeiten berücksichtigt?

• Prüfen, ob Tools wie Syft/Trivy/Snyk korrekt konfiguriert sind.

• Prüfen, ob Container Images und Build Artefakte gescannt wurden.

2. Kryptografische Algorithmen

• Sind alle verwendeten Algorithmen dokumentiert?

• Werden unsichere oder veraltete Algorithmen genutzt?

o SHA 1

o MD5

o RSA < 2048 Bit

o AES CBC ohne zusätzliche Integrität

• Sind die Betriebsmodi korrekt dokumentiert (z. B. AES GCM vs. AES CBC)?

• Abgleich mit BSI TR 02102, NIST SP 800 131A, ETSI Empfehlungen.

3. Kryptografische Bibliotheken

• Sind alle Kryptobibliotheken als Komponenten erfasst?

• Sind Version, Hash, Lizenz und Quelle dokumentiert?

• Gibt es bekannte CVEs zu diesen Bibliotheken?

• Werden veraltete oder ungepatchte Versionen eingesetzt?

• Speziell prüfen: OpenSSL, BouncyCastle, libsodium, WolfSSL.

4. Zertifikate

• Sind alle Zertifikate in der SBOM enthalten?

• Sind folgende Metadaten vollständig:

o Fingerprint

o Aussteller

o Ablaufdatum

o Key Usage

o Public Key Algorithmus

• Gibt es abgelaufene oder bald ablaufende Zertifikate?

• Werden schwache Schlüssel verwendet?

• Prüfen auf TLS 1.0/1.1, Self Signed Certificates, SHA 1 Signaturen.

5. Schlüsselmaterial (Metadaten)

• Werden nur Metadaten erfasst (keine Schlüssel selbst)?

• Sind Schlüssellängen und Algorithmen dokumentiert?

• Ist der Verwendungszweck klar (Signatur, Verschlüsselung, TLS Handshake)?

• Gibt es Hinweise auf schwache Schlüssel?

• Prüfen auf RSA < 2048 Bit, ECC < 256 Bit.

6. Kryptografische Services

• Sind externe oder interne Kryptoservices dokumentiert?

o HSM

o Key Management Systeme

o Token Signaturdienste

o TLS Terminatoren

• Sind deren Versionen und Konfigurationen nachvollziehbar?

• Prüfen, ob Schlüsselrotation dokumentiert ist.

7. Schwachstellenmanagement

• Werden kryptografische Komponenten regelmäßig auf CVEs geprüft?

• Gibt es Prozesse zur Bewertung kryptografischer Schwachstellen?

• Ist dokumentiert, wo eine betroffene Bibliothek eingesetzt wird?

• Gibt es definierte Reaktionszeiten (MTTD/MTTR)?

• Prüfen, ob Dependency Track oder Snyk Alerts genutzt werden.

8. Lieferkettensicherheit

• Enthält die SBOM kryptografische Informationen von Drittanbietern?

• Werden unsichere Algorithmen oder abgelaufene Zertifikate in Fremdkomponenten erkannt?

• Gibt es Anforderungen an Lieferanten zur Kryptografie Hygiene?

• Prüfen, ob AV Verträge oder SLA kryptografische Mindeststandards enthalten.

9. Compliance & Regulierung

• Erfüllt die Kryptografie die Anforderungen aus:

o NIS2

o DORA

o ISO 27001

o DSGVO Art. 32

o BSI Empfehlungen

• Werden unsichere Cipher Suites aktiv verhindert?

• Gibt es dokumentierte Kryptografie Policies?

• Prüfen, ob „Crypto Agility“ vorgesehen ist (schneller Algorithmuswechsel).

10. Dokumentation & Governance

• Ist die Kryptografie SBOM vollständig versioniert?

• Gibt es Verantwortlichkeiten (Owner, Maintainer)?

• Ist die SBOM in CI/CD integriert?

• Werden Änderungen an Kryptokomponenten automatisch erkannt?

• Prüfen, ob SBOM Updates Teil des Release Prozesses sind.

Kurzversion : 10 Punkte Check

1. Alle Kryptokomponenten vollständig erfasst?

2. Sichere Algorithmen und Betriebsmodi?

3. Kryptobibliotheken aktuell und ohne CVEs?

4. Zertifikate gültig und sicher?

5. Schlüsselmetadaten vollständig und sicher?

6. Kryptoservices dokumentiert?

7. Schwachstellenmanagement aktiv?

8. Lieferkette kryptografisch bewertet?

9. Compliance Anforderungen erfüllt?

10. SBOM Governance etabliert?

SBOM - Software Bill of Materials einfach erklärt

Mon, 30 Mar 2026 19:37:41 GMT

SBOM? einfach erklärt

Eine Software Bill of Materials (SBOM) ist eine Stückliste aller Bauteile einer Software — ähnlich wie die Zutatenliste auf einer Lebensmittelverpackung.

Sie zeigt:

• Welche Komponenten in einer Software enthalten sind

• Welche Versionen verwendet werden

• Woher die Komponenten stammen

• Welche Risiken (z. B. CVEs) damit verbunden sind

Warum das wichtig ist:

Moderne Software besteht zu 70–90% aus Fremdkomponente n (Open Source, Bibliotheken, Frameworks). Wenn dort eine Schwachstelle auftaucht, muss man wissen:

Sind wir betroffen? Wo genau? Wie kritisch?

Eine SBOM liefert genau diese Transparenz.

Wer fordert eine SBOM?

• NIS2 (EU)

• DORA (Finanzsektor)

• US Executive Order 14028

• ISO 27001 / TISAX (indirekt über Lieferketten Sicherheit)

• Viele Kunden in Automotive, Health, KRITIS

SBOMs sind also längst ein Pflichtbestandteil moderner Software Sicherheit.

Was muss mindestens in einer SBOM enthalten sein? (Mindestanforderungen)

Die Mindestanforderungen orientieren sich an NTIA und CycloneDX/SPDX Standards.

1. Komponenteninformationen

• Name der Komponente

• Version

• Hersteller / Quelle

• Lizenztyp

2. Identifikatoren

• Package URL (purl)

• Hash (z. B. SHA 256)

• SPDX ID oder CycloneDX ID

3. Abhängigkeiten

• Welche Komponenten hängen voneinander ab?

4. Metadaten

• Erstellungsdatum

• Ersteller (Firma/Tool)

• SBOM Format (SPDX, CycloneDX)

Was enthält eine ideale SBOM? (Best Practice)

Eine ideale SBOM geht deutlich weiter:

5. Sicherheitsinformationen

• Bekannte CVEs pro Komponente

• CVSS Scores

• Exploit Status (z. B. CISA KEV)

• Patch Status

6. Integritätsinformationen

• Signaturen

• Hashes aller Dateien

• Lieferketten Nachweise (SLSA Level)

7. Build Informationen

• Build Server

• Build Pipeline

• Compiler Version

• verwendete Flags

8. Lizenz Compliance

• Lizenztyp

• Lizenzrisiken

• Nutzungseinschränkungen

9. Runtime Informationen

• Welche Komponenten werden tatsächlich genutzt?

• Welche sind nur „mitgeliefert“?

10. Abhängigkeitsgraph

• Visualisierung aller Beziehungen

• Erkennung kritischer Ketten

Wichtige Tools zur Erstellung einer SBOM

Automatisierte SBOM Generatoren

• CycloneDX CLI

• SPDX Tools

• Syft (Anchore)

• Trivy

• Snyk

• GitHub SBOM Export

• GitLab Dependency Scanning

CI/CD Integration

• GitHub Actions

• GitLab CI

• Azure DevOps Pipelines

Checkliste für SBOM‑Pflichten nach NIS2 / DORA

Hinweis: NIS2 und DORA schreiben nicht „SBOM“ wörtlich vor, verlangen aber faktisch SBOM‑ähnliche Transparenz über Software‑Komponenten und Lieferketten.

1. Governance & Verantwortlichkeiten

Verantwortung definiert: [ ] Rolle/Owner für SBOM‑Management benannt (z. B. CISO, Head of Engineering)
Richtlinie vorhanden: [ ] Interne Richtlinie zu SBOM, Third‑Party‑Software und Open‑Source‑Nutzung
Scope definiert: [ ] Welche Systeme/Applikationen SBOM‑pflichtig sind (kritische Dienste, regulierte Services, Cloud‑Plattformen)

2. Erstellung & Aktualität

Automatisierte Erstellung: [ ] SBOM wird automatisiert in CI/CD erzeugt (z. B. pro Build/Release)
Aktualität: [ ] SBOM wird bei jeder neuen Version aktualisiert [ ] SBOM‑Stand ist nachvollziehbar (Datum, Version, Tool)
Formatstandard: [ ] Nutzung eines anerkannten Standards (SPDX oder CycloneDX)

3. Inhaltliche Mindestanforderungen

Komponenteninformationen: [ ] Name, Version, Hersteller/Quelle jeder Komponente [ ] Lizenzinformationen (Open Source / kommerziell)
Identifikatoren: [ ] Eindeutige IDs (z. B. purl, SPDX‑ID) [ ] Hashes für Integrität (wo sinnvoll)
Abhängigkeiten: [ ] Abhängigkeitsbeziehungen (Dependency Graph) dokumentiert

4. Schwachstellen‑ und Risikomanagement

CVE‑Bezug: [ ] Komponenten werden regelmäßig gegen CVE‑Datenbanken geprüft
Bewertung: [ ] Kritische CVEs (z. B. CISA KEV, CVSS ≥ 7.0) werden priorisiert
Prozess: [ ] Definierter Prozess zur Behandlung von SBOM‑basierten Findings (Patch, Mitigation, Risk Acceptance)
Nachweisbarkeit: [ ] Dokumentation von Entscheidungen (z. B. „Known Vulnerable but Accepted“)

5. Lieferkette & Drittanbieter

Lieferantenanforderungen: [ ] Vertragliche Pflicht für kritische Lieferanten, SBOMs bereitzustellen
Prüfung: [ ] Eingehende SBOMs werden geprüft (CVE, Lizenzen, kritische Komponenten)
Integration: [ ] SBOMs von Dritten in eigenes Risiko‑ und Asset‑Register integriert

6. Resilienz, Reporting & Aufsicht

Business Impact: [ ] Kritische Komponenten sind mit Geschäftsprozessen/Services verknüpft
Reporting: [ ] Regelmäßige Berichte an Management/Board zu SBOM‑Risiken (z. B. kritische CVEs in Kernsystemen)
Aufsichtsanforderungen: [ ] Nachweisfähigkeit gegenüber Aufsichtsbehörden (DORA/NIS2‑Audits) durch dokumentierte SBOM‑Prozesse
Übungen: [ ] Szenarienübungen: „Kritische CVE in weit verbreiteter Bibliothek – wie reagieren wir?“

Zielmatrix für Integrierte Management Systeme ISMS, QMS, Datenschutz

Mon, 30 Mar 2026 19:23:05 GMT

Zielmatrix für Integrierte Management Systeme ISMS, QMS, Datenschutz

Ziel- und Wirksamkeitsmatrix für integrierte Managementsysteme – ISMS, QMS und Datenschutz

Gemeinsame Ziele schaffen – unterschiedliche Anforderungen wirksam steuern

Qualität, Informationssicherheit und Datenschutz werden in Unternehmen häufig gemeinsam betrachtet. Die Gründe liegen auf der Hand: Sie greifen auf dieselben Prozesse, Mitarbeiter, Informationen, IT-Systeme und teilweise auch auf dieselben Lieferanten und Dienstleister zu.

Doch daraus entsteht schnell ein Problem:

Es werden drei Zielwelten nebeneinander aufgebaut, obwohl die zugrunde liegenden Prozesse und Ressourcen weitgehend dieselben sind.

Ein integriertes Managementsystem kann hier einen erheblichen Vorteil bieten.

Dabei ist allerdings eine saubere begriffliche Trennung wichtig:

Qualitätsmanagement und Informationssicherheitsmanagement sind Managementsysteme, beispielsweise nach ISO 9001 bzw. ISO/IEC 27001.
Datenschutz ist dagegen zunächst ein gesetzlicher und regulatorischer Rahmen sowie ein Governance-Thema. Die DSGVO schreibt kein Managementsystem nach dem Muster eines ISO-Managementsystems vor.

Datenschutz kann und sollte selbstverständlich systematisch organisiert und gesteuert werden. Für ein integriertes Managementsystem ist es jedoch fachlich sauberer, von

Qualitätsmanagement, Informationssicherheitsmanagement und Datenschutz-Governance

zu sprechen.

Die entscheidende Frage lautet deshalb nicht:

„Wie bauen wir drei Managementsysteme nebeneinander auf?“

Sondern:

„Wie können wir gemeinsame Ziele, Prozesse und Steuerungsmechanismen nutzen und gleichzeitig die unterschiedlichen Anforderungen von Qualität, Informationssicherheit und Datenschutz berücksichtigen?“

Genau hier setzt eine Ziel- und Wirksamkeitsmatrix an.

1. Eine Zielmatrix ist mehr als eine Sammlung von KPIs

Eine klassische Zielmatrix enthält häufig Aussagen wie:

Fehlerquote reduzieren
Verfügbarkeit erhöhen
Mitarbeiter schulen
Risiken reduzieren
Lieferanten bewerten
Compliance sicherstellen

Dazu werden einige Kennzahlen ergänzt.

Das ist ein guter Anfang – reicht aber nicht aus.

Denn ein KPI beantwortet zunächst nur die Frage:

Was messen wir?

Die entscheidende Managementfrage lautet jedoch:

Erreichen wir mit unseren Maßnahmen tatsächlich das gewünschte Ergebnis?

Dafür müssen unterschiedliche Ebenen voneinander getrennt werden:

Ziel → Anforderung/Zielwert → Maßnahme/Control → KPI → Ergebnis → Wirksamkeitsnachweis

Beispiel:

Ziel:
Kritische IT-Services bleiben verfügbar.

Anforderung:
Wiederherstellung innerhalb von maximal vier Stunden.

Maßnahmen:
Backup, Redundanz, Notfallverfahren und Wiederherstellungstests.

KPI:
Anteil der Wiederherstellungstests, die innerhalb des definierten RTO erfolgreich abgeschlossen wurden.

Ergebnis:
Tatsächliche Wiederherstellungszeit.

Wirksamkeitsnachweis:
Der kritische Service konnte im realistischen Test innerhalb des definierten RTO wiederhergestellt werden.

Damit wird sichtbar:

Maßnahme ist nicht gleich Wirksamkeit.

2. Warum Ziele messbar und überwachbar sein müssen

Eine Zielmatrix soll nicht nur dokumentieren, was das Management wichtig findet. Sie muss die Steuerung und Bewertung ermöglichen.

Für das Qualitätsmanagement ist diese Verbindung ausdrücklich relevant. ISO 9001 fordert im Abschnitt 6.2 Qualitätsziele und deren Planung; Ziele sollen unter anderem überwacht und bei Bedarf aktualisiert werden. Auch die ISO-Auditing-Practice-Guidance betont die Verbindung zwischen strategischen Zielen, Managementzielen und operativen Aktivitäten sowie die Notwendigkeit, Ziele im Zeitverlauf zu überprüfen und weiterzuentwickeln.

Eine vergleichbare Logik findet sich auch im ISMS: Informationssicherheitsziele sollen überwacht werden; ISO/IEC 27001 verbindet damit die Messung und Bewertung der Leistung und Wirksamkeit des ISMS.

Damit entsteht eine gemeinsame Managementlogik:

Ziel definieren
Ziel messbar bzw. bewertbar machen
Umsetzung steuern
Ergebnis überwachen
Wirksamkeit bewerten
Ziel bzw. Maßnahmen bei Bedarf aktualisieren

Das ist der Kern einer guten Zielmatrix.

3. Datenschutz ist dabei eine eigene Governance-Perspektive

Der Datenschutz sollte in einer IMS-Matrix nicht einfach als „drittes Managementsystem“ neben ISO 9001 und ISO/IEC 27001 dargestellt werden.

Gleichzeitig bietet die DSGVO mehrere sehr starke Anknüpfungspunkte für eine integrierte Steuerung.

Besonders relevant sind:

Art. 5 Abs. 1 lit. f DSGVO: Integrität und Vertraulichkeit
Art. 5 Abs. 2 DSGVO: Rechenschaftspflicht / Accountability
Art. 24 DSGVO: Verantwortung des Verantwortlichen
Art. 32 DSGVO: Sicherheit der Verarbeitung

Art. 5 Abs. 2 verlangt ausdrücklich, dass der Verantwortliche die Einhaltung der Datenschutzgrundsätze nicht nur sicherstellt, sondern sie auch nachweisen können muss . Art. 24 fordert geeignete technische und organisatorische Maßnahmen und deren Überprüfung bzw. Aktualisierung, soweit erforderlich.

Damit entsteht eine sehr gute Verbindung zu Managementsystemen:

Nicht nur handeln – sondern Verantwortung übernehmen, steuern, nachweisen und die Wirksamkeit bewerten.

4. Die gemeinsame Zielstruktur

Ein integriertes System sollte nicht versuchen, aus Qualität, Informationssicherheit und Datenschutz eine einzige Disziplin zu machen.

Viel sinnvoller ist eine gemeinsame Zielstruktur.

Beispielsweise:

Damit entsteht eine gemeinsame Steuerungsarchitektur , ohne die fachlichen Unterschiede aufzugeben.

5. Prozessqualität und Prozesssicherheit

Gemeinsames Ziel

Geschäftsprozesse sind beherrscht, stabil, nachvollziehbar und erfüllen die definierten Anforderungen.

QMS

Prozessfähigkeit
Fehlervermeidung
stabile Abläufe
Kundenanforderungen

ISMS

Schutz sicherheitsrelevanter Prozesse
sichere Informationsverarbeitung
definierte Verantwortlichkeiten

Datenschutz-Governance

Datenschutzanforderungen in relevanten Prozessschritten
geeignete technische und organisatorische Maßnahmen
Berücksichtigung der Risiken für betroffene Personen

Mögliche KPIs

Prozessfehlerquote
Anzahl Prozessabweichungen
Anzahl sicherheitsrelevanter Prozessabweichungen
Anzahl datenschutzrelevanter Abweichungen

Wirksamkeitsnachweis

Nicht:

„Der Prozess ist dokumentiert.“

Sondern:

„Der Prozess erreicht seine definierten Qualitäts-, Sicherheits- und Datenschutzanforderungen zuverlässig.“

6. Vertraulichkeit und Schutz von Informationen

Gemeinsames Ziel

Vertrauliche Informationen und personenbezogene Daten werden vor unbefugtem Zugriff und unzulässiger Offenlegung geschützt.

QMS

Schutz vertraulicher Kunden-, Produkt- und Unternehmensinformationen.

ISMS

Schutz schützenswerter Informationen durch angemessene Zugriffskontrollen und Sicherheitsmaßnahmen.

Datenschutz

Schutz personenbezogener Daten vor unbefugter oder unrechtmäßiger Verarbeitung.

Art. 5 Abs. 1 lit. f DSGVO nennt ausdrücklich Integrität und Vertraulichkeit personenbezogener Daten.

Mögliche KPIs

MFA-Abdeckung
Anteil regelmäßig überprüfter Berechtigungen
Anteil klassifizierter Informationen
Anteil kritischer Systeme mit angemessener Zugriffskontrolle

Ergebnis-/Wirksamkeitsmetriken

unbefugte Zugriffe
tatsächliche Datenabflüsse
Datenschutzverletzungen
Anzahl betroffener Datensätze
Schweregrad von Sicherheitsereignissen

Eine MFA-Abdeckung von 100 % kann ein gutes Steuerungsziel sein.

Sie beweist aber noch nicht, dass Kontoübernahmen wirksam verhindert werden.

7. Integrität und Datenqualität

Gemeinsames Ziel

Daten und Informationen sind korrekt, vollständig, konsistent und vor unzulässiger Veränderung geschützt.

QMS

Datenqualität
Produktqualität
Vollständigkeit
Aktualität

ISMS

Schutz vor unbefugter oder unbeabsichtigter Veränderung

Datenschutz

Art. 5 Abs. 1 lit. d DSGVO fordert die Richtigkeit personenbezogener Daten; Art. 5 Abs. 1 lit. f adressiert deren Integrität und Vertraulichkeit.

Mögliche KPIs

Datenfehlerquote
Anzahl Integritätsverletzungen
Anteil durchgeführter Datenprüfungen
Anteil korrigierter Datensätze

Wirksamkeitsnachweis

tatsächliche Manipulationen
fehlerhafte Datensätze
Auswirkungen auf Produkte oder Prozesse
erfolgreiche Wiederherstellung aus vertrauenswürdigen Quellen

8. Verfügbarkeit, Kontinuität und Wiederherstellbarkeit

Gemeinsames Ziel

Kritische Prozesse, Systeme und Informationen bleiben verfügbar oder können innerhalb definierter Grenzen wiederhergestellt werden.

QMS

Prozess- und Lieferfähigkeit.

ISMS

Verfügbarkeit kritischer Systeme und Informationen sowie Business Continuity.

Datenschutz

Art. 32 DSGVO nennt ausdrücklich Vertraulichkeit, Integrität, Verfügbarkeit und Belastbarkeit sowie die Fähigkeit zur zeitnahen Wiederherstellung personenbezogener Daten. Außerdem verlangt die DSGVO eine regelmäßige Prüfung, Bewertung und Evaluierung der Wirksamkeit der technischen und organisatorischen Maßnahmen.

RTO und RPO sind keine KPIs

Ein wichtiger Unterschied:

RTO/RPO = Ziel- bzw. Anforderungswerte

KPI = Anteil erfolgreicher Tests, die RTO/RPO einhalten

Metrik = tatsächlich gemessene Wiederherstellungszeit bzw. tatsächlicher Datenverlust

Beispiel:

RTO: maximal 4 Stunden
tatsächliche Recovery Time: 3 Stunden 20 Minuten
Ergebnis: Ziel erreicht

Ein vorhandenes Backup ist deshalb noch kein Wirksamkeitsnachweis.

Der Wirksamkeitsnachweis entsteht erst durch eine nachgewiesene erfolgreiche Wiederherstellung .

9. Nachweisbarkeit, Verantwortlichkeit und Rechenschaftspflicht

Dieser Bereich ist ein besonders wichtiger Integrationspunkt.

QMS

dokumentierte Information
Rückverfolgbarkeit
Prüf- und Freigabenachweise
Auditnachweise

ISMS

Logging
Monitoring
Nachvollziehbarkeit
Verantwortlichkeiten
Auditierbarkeit

Datenschutz-Governance

Nachweis der Einhaltung
Verzeichnis von Verarbeitungstätigkeiten
Nachweise zu technischen und organisatorischen Maßnahmen
dokumentierte Entscheidungen
Accountability

Die DSGVO geht hier über eine reine Dokumentationspflicht hinaus:

Der Verantwortliche muss die Einhaltung der Datenschutzgrundsätze nachweisen können.

Das ist der Kern der Rechenschaftspflicht (Accountability) nach Art. 5 Abs. 2 DSGVO.

Damit ist Accountability ein hervorragender Anknüpfungspunkt für ein integriertes Managementsystem.

10. Risiko- und Chancenmanagement

Ein weiterer wichtiger Punkt ist die Unterscheidung zwischen Risiken und Chancen .

Eine Zielmatrix sollte nicht nur fragen:

„Was kann schiefgehen?“

Sondern auch:

„Welche Möglichkeiten können wir nutzen, um unsere Ziele besser zu erreichen?“

Risiken

Informationssicherheitsrisiken
Qualitätsrisiken
Prozessrisiken
Datenschutzrisiken
regulatorische Risiken

Chancen

Prozessdigitalisierung
Automatisierung
Qualitätssteigerung
Innovation
Effizienzsteigerung
neue Produkte oder Dienstleistungen
Wettbewerbsvorteile

Gemeinsames Ziel

Risiken werden innerhalb akzeptierter Grenzen beherrscht und relevante Chancen zur Verbesserung der Zielerreichung systematisch bewertet und genutzt.

Mögliche KPIs für Risiken

Anzahl kritischer offener Risiken
Anteil fristgerecht behandelter Risiken
Anteil der Risiken innerhalb der Akzeptanzkriterien
Alter kritischer Risiken
Entwicklung des Residualrisikos

Mögliche Kennzahlen für Chancen

Anzahl bewerteter Verbesserungschancen
realisierte Effizienzsteigerungen
Automatisierungsgrad
erzielte Qualitätsverbesserungen
wirtschaftlicher Nutzen von Verbesserungsmaßnahmen

Wichtig ist auch hier:

„Risiko bewertet“ bedeutet nicht „Risiko beherrscht“.

Entscheidend ist das verbleibende Risiko und dessen Akzeptierbarkeit.

11. Kompetenz und Awareness

Schulung ist eine Aktivität.

Kompetenz und richtiges Verhalten sind das eigentliche Ziel.

QMS

Fachkompetenz
Prozesskompetenz
Qualifikation

ISMS

Security Awareness
Phishing-Resilienz
Erkennen und Melden von Sicherheitsereignissen

Datenschutz

Datenschutzbewusstsein
korrekter Umgang mit personenbezogenen Daten
Erkennen und Melden von Datenschutzverletzungen

Mögliche KPIs

Schulungsquote
Teilnahmequote
Qualifikationsquote
Testergebnisse

Wirksamkeitsmetriken

Verhalten in Phishing-Simulationen
Meldequote
Zeit bis zur Meldung
tatsächliche Fehler
reale Sicherheits- oder Datenschutzvorfälle

Die entscheidende Frage lautet deshalb nicht:

„Sind alle Mitarbeiter geschult?“

Sondern:

„Verhalten sich die Mitarbeiter in einer relevanten Situation tatsächlich richtig?“

12. Lieferanten und externe Parteien

Lieferanten können gleichzeitig Qualitäts-, Sicherheits- und Datenschutzrisiken verursachen.

Gemeinsames Ziel

Kritische externe Parteien werden risikoorientiert ausgewählt, bewertet, überwacht und gesteuert.

QMS

Lieferantenqualität
Lieferfähigkeit
Reklamationsquote

ISMS

Supplier Security
Cloud-/IT-Dienstleister
Sicherheitsanforderungen
Sicherheitsvorfälle

Datenschutz

Auftragsverarbeitung
Datenschutzvereinbarungen
Drittlandtransfers
technische und organisatorische Maßnahmen

Mögliche KPIs

Anteil bewerteter kritischer Lieferanten
Lieferantenfehlerquote
Anteil fristgerecht durchgeführter Bewertungen
offene Lieferantenrisiken

Wirksamkeitsnachweis

Nicht:

„Lieferant wurde bewertet.“

Sondern:

„Kritische Lieferantenrisiken werden innerhalb der definierten Grenzen beherrscht und führen nicht zu unakzeptablen Auswirkungen.“

13. Kontinuierliche Verbesserung

Ein integriertes Managementsystem sollte nicht nur Abweichungen schließen, sondern Ursachen beseitigen und Verbesserungen realisieren.

Gemeinsames Ziel

Schwachstellen, Abweichungen, Risiken und Verbesserungspotenziale werden systematisch erkannt und nachhaltig bearbeitet.

Mögliche KPIs

Anteil fristgerecht abgeschlossener Maßnahmen
Anzahl realisierter Verbesserungen
Bearbeitungszeit
Anzahl wiederkehrender Abweichungen

Wirksamkeitsnachweis

Eine abgeschlossene Maßnahme ist noch kein Wirksamkeitsnachweis.

Beispiel:

Maßnahme: zusätzliche Schulung durchgeführt.

Wirksamkeit: Fehlerquote sinkt und der Fehler tritt im definierten Zeitraum nicht erneut auf.

Damit wird zwischen Maßnahmenabschluss und tatsächlicher Verbesserung unterschieden.

14. Compliance – vom Erfüllen von Anforderungen zum Beherrschen regulatorischer Risiken

Auch bei Compliance sollte eine Zielmatrix nicht auf der operativen Ebene stehen bleiben.

„Anforderungen umgesetzt“ ist wichtig – aber es ist noch kein strategisches Ziel.

Eine höhere Zielsetzung lautet:

Regulatorische und vertragliche Compliance-Risiken werden wirksam beherrscht.

Daraus ergeben sich operative Anforderungen:

relevante Anforderungen identifizieren
Änderungen überwachen
Anforderungen bewerten
Verantwortlichkeiten festlegen
Anforderungen umsetzen
Nachweise führen
Erfüllung regelmäßig überprüfen

Mögliche KPI

Anteil bewerteter Anforderungen
Anzahl überfälliger Compliance-Maßnahmen
Anzahl kritischer Findings
Anzahl überfälliger regulatorischer Maßnahmen

Ergebnis-/Wirksamkeitsindikatoren

wesentliche Compliance-Verstöße
wiederkehrende Abweichungen
regulatorische Auswirkungen
finanzielle oder rechtliche Folgen
Eskalationen gegenüber Aufsichtsbehörden

Das eigentliche Managementziel ist damit nicht:

„Wir haben alle Anforderungen in einer Liste.“

Sondern:

„Das Unternehmen beherrscht seine wesentlichen regulatorischen Risiken.“

Das ist für Geschäftsführung und Aufsicht wesentlich aussagekräftiger.

15. Typische Irrtümer bei der Messung von Wirksamkeit

Hier zeigt sich besonders deutlich, warum eine reine Maßnahmen- oder KPI-Liste nicht ausreicht.

Diese Unterscheidung ist einer der wichtigsten Grundsätze einer wirksamen Managementsteuerung:

Aktivität ist nicht Ergebnis. Ergebnis ist nicht automatisch Wirksamkeit.

16. Die IMS-Ziel- und Wirksamkeitsmatrix

Aus den genannten Prinzipien ergibt sich folgende Matrix:

17. Von der Zielmatrix zum Management-Dashboard

Die Matrix kann anschließend in ein Management-Dashboard überführt werden.

Für jedes Ziel sollten mindestens folgende Informationen vorhanden sein:

Strategisches Ziel

→ konkrete Anforderung / Zielwert

→ Verantwortlicher

→ Maßnahmen / Controls

→ KPI

→ Ist-Wert

→ Trend

→ Risiko

→ tatsächliches Ergebnis

→ Wirksamkeitsnachweis

→ Managemententscheidung

Damit wird die Zielmatrix zu einem echten Steuerungsinstrument.

18. Die entscheidende Kette

Für die praktische Umsetzung eines integrierten Managementsystems empfehle ich deshalb folgende Logik:

· Strategisches Ziel

· Anforderung / Zielwert

· Risiko oder Chance

· Maßnahme / Control

· Prozess

· KPI / Steuerungskennzahl

· tatsächliches Ergebnis

· Wirksamkeitsnachweis

· Managementbewertung

· Verbesserung / Anpassung

Diese Kette verbindet die unterschiedlichen Anforderungen von QMS, ISMS und Datenschutz-Governance, ohne sie künstlich gleichzumachen.

19. Fazit

Eine gute IMS-Zielmatrix ist keine Sammlung von Kennzahlen.

Sie ist ein Instrument, um strategische Ziele, Anforderungen, Risiken, Maßnahmen, Messung und tatsächliche Wirksamkeit miteinander zu verbinden .

Dabei sollten Qualität, Informationssicherheit und Datenschutz nicht als identische Managementsysteme behandelt werden.

Vielmehr gilt:

Gemeinsame Prozesse und Ziele können integriert gesteuert werden – die fachlichen und regulatorischen Anforderungen bleiben dabei unterschiedlich.

Besonders wichtig ist die konsequente Trennung:

Ziel ≠ Anforderung ≠ Maßnahme ≠ KPI ≠ Ergebnis ≠ Wirksamkeitsnachweis

Denn:

100 % Schulungsquote ist nicht dasselbe wie wirksames Verhalten.

100 % abgeschlossene Maßnahmen sind nicht dasselbe wie Risikoreduktion.

Vorhandene Backups sind nicht dasselbe wie nachgewiesene Wiederherstellbarkeit.

Eingeführte MFA ist nicht dasselbe wie nachgewiesener Schutz vor Kontoübernahmen.

Keine Auditabweichung ist nicht dasselbe wie vollständige Compliance.

Bewertete Risiken sind nicht dasselbe wie beherrschte Risiken.

Die zentrale Frage eines integrierten Managementsystems sollte deshalb lauten:

Nicht nur: „Was haben wir getan?“

Sondern: „Was hat es bewirkt?“

Oder kurz:

Nicht nur messen, was wir tun – messen, was tatsächlich w irkt.

Viel Erfolg,

Ihr Konstantin Ziouras

Qualitätsmanagement Ziele

Mon, 30 Mar 2026 19:14:21 GMT

Erweiterte Ziele im Qualitätsmanagement (QM)

Erweiterte Qualitätsziele im Qualitätsmanagement – von der Zielsetzung zu wirksamen KPIs

Qualitätsmanagement wird häufig mit Prozessbeschreibungen, Arbeitsanweisungen, Audits und Kennzahlen verbunden. Doch ein funktionierendes QM-System sollte mehr leisten: Es soll messbar dazu beitragen, dass Produkte und Dienstleistungen die Anforderungen erfüllen, Prozesse zuverlässig funktionieren und Kundenanforderungen nachhaltig erfüllt werden.

Dafür braucht es geeignete Qualitätsziele und Kennzahlen.

Dabei ist eine wichtige Unterscheidung erforderlich:

Ein KPI (Key Performance Indicator) ist nicht das Ziel. Der KPI zeigt, ob und wie gut das Ziel erreicht wird.

Ein Ziel beschreibt den gewünschten Zustand. Der KPI beschreibt, woran die Zielerreichung gemessen wird . Eine Metrik konkretisiert, wie der KPI berechnet oder beobachtet wird. Ergänzend sollte ein Zielwert festgelegt werden, damit eine Bewertung möglich wird.

Ein einfaches Beispiel:

Qualitätsziel: Fehler in der Auftragsbearbeitung reduzieren
KPI: Fehlerquote bei Aufträgen
Metrik: fehlerhafte Aufträge / Gesamtzahl der Aufträge × 100
Zielwert: ≤ 1 %
Bewertung: Entwicklung über die Zeit und Wirksamkeit eingeleiteter Verbesserungsmaßnahmen

Damit wird aus einer allgemeinen Absicht ein steuerbares Qualitätsziel.

I. Welche Qualitätsziele sind für ein Unternehmen sinnvoll?

Nicht jedes Ziel ist automatisch ein klassisches Qualitätsziel. Einige Ziele betreffen unmittelbar die Qualität von Produkten, Dienstleistungen und Prozessen. Andere unterstützen das QM-System oder gehören zu übergeordneten Unternehmenszielen.

Eine sinnvolle Struktur kann daher drei Ebenen unterscheiden:

Primäre Qualitätsziele

Sie beziehen sich unmittelbar auf die Qualität und Konformität von Produkten, Dienstleistungen und Prozessen:

Produkt- und Dienstleistungsqualität
Kundenzufriedenheit
Prozessqualität
Prozessstabilität
Fehlervermeidung
Termintreue
Konformität

Unterstützende Qualitätsziele

Sie schaffen die Voraussetzungen für eine nachhaltige Qualität:

Kompetenz und Qualifikation
Wissensmanagement
Lieferantenqualität
Risikomanagement
Dokumentationsqualität
kontinuierliche Verbesserung

Übergeordnete Unternehmens- und Managementziele

Diese Ziele können eng mit dem QM verbunden sein, gehen aber über das eigentliche Qualitätsmanagement hinaus:

Wirtschaftlichkeit
Innovation
Nachhaltigkeit
Compliance
Flexibilität und Reaktionsfähigkeit

Gerade in einem integrierten Managementsystem (IMS) ist diese Verbindung sinnvoll. Entscheidend ist jedoch, die unterschiedlichen Zielarten nicht miteinander zu vermischen.

II. Erweiterte Qualitätsziele und geeignete KPIs

1. Prozessqualität

Ziel:
Prozesse sollen zuverlässig, effizient und fehlerarm durchgeführt werden und die definierten Anforderungen erfüllen.

Geeignete KPIs:

Fehlerquote
First Pass Yield
Nacharbeitsquote
Ausschussquote
Prozessdurchlaufzeit
Anzahl Prozessabweichungen

Beispielmetrik:
Fehlerhafte Vorgänge / Gesamtzahl der Vorgänge × 100

Ein einzelner KPI reicht dabei selten aus. Ein Prozess kann beispielsweise sehr schnell sein, gleichzeitig aber eine hohe Fehlerquote aufweisen. Qualität und Effizienz müssen daher gemeinsam betrachtet werden.

2. Produkt- und Dienstleistungsqualität

Dies sollte als eines der zentralen Qualitätsziele ausdrücklich betrachtet werden.

Ziel:
Produkte und Dienstleistungen erfüllen die festgelegten Anforderungen zuverlässig.

Geeignete KPIs:

Fehlerquote
Reklamationsquote
Rücklaufquote
First Pass Yield
Nacharbeitsquote
Anzahl kritischer Produktfehler
Service-Level-Erfüllung

Beispiel:
Anteil fehlerfreier Produkte bei der Endprüfung ≥ 99 %.

Hier zeigt sich unmittelbar, ob das QM-System seine eigentliche Aufgabe erfüllt: konforme Ergebnisse zu erzeugen.

3. Kundenzufriedenheit

Kundenzufriedenheit ist ein klassisches Qualitätsziel und sollte nicht nur über allgemeine Umfragen betrachtet werden.

Ziel:
Die Anforderungen und Erwartungen der Kunden werden zuverlässig erfüllt.

Geeignete KPIs:

Kundenzufriedenheitsindex
Reklamationsquote
Anzahl Kundenbeschwerden
Wiederkaufsquote
Weiterempfehlungsrate
Erfüllungsgrad vereinbarter Service Levels

Beispielmetrik:
Kundenzufriedenheit auf einer Skala von 1–5.

Wichtig ist die Kombination aus subjektiver Wahrnehmung und objektiven Daten. Ein guter Zufriedenheitswert bedeutet beispielsweise wenig, wenn gleichzeitig die Reklamationsquote deutlich steigt.

4. Effizienz und Kosten

Wirtschaftlichkeit ist nicht automatisch ein Qualitätsziel. Ein reines Kostensenkungsziel kann sogar zu Lasten der Qualität gehen.

Sinnvoller ist daher:

Wirtschaftliche Prozesse bei gleichbleibender oder verbesserter Qualität.

Geeignete KPIs:

Prozesskosten
Kosten je Produkt oder Vorgang
Durchlaufzeit
Produktivität
Kosten der Nichtqualität
Nacharbeitskosten

Beispiel:
Kosten pro Auftrag reduzieren, ohne Fehlerquote und Kundenzufriedenheit zu verschlechtern.

Besonders interessant ist dabei der Cost of Poor Quality (COPQ) : Welche Kosten entstehen durch Fehler, Reklamationen, Ausschuss, Nacharbeit oder Korrekturen?

5. Termintreue

Ziel:
Produkte, Dienstleistungen und vereinbarte Leistungen werden zum zugesagten Zeitpunkt erbracht.

Geeignete KPIs:

Anteil termingerechter Lieferungen
On-Time Delivery
On-Time Performance
SLA-Erfüllungsgrad
durchschnittliche Terminabweichung

Beispielmetrik:
Termingerechte Lieferungen / Gesamtzahl der Lieferungen × 100

Für Dienstleistungen kann anstelle der Liefertermintreue beispielsweise die Erfüllung vereinbarter Service Levels betrachtet werden.

6. Fehlervermeidung – Prevention statt Detection

Ein gutes QM-System sollte Fehler möglichst verhindern , anstatt sie erst am Ende des Prozesses zu entdecken.

Ziel:
Fehler frühzeitig vermeiden und die Entstehung von Fehlern systematisch reduzieren.

Geeignete KPIs:

First Pass Yield
Fehlerentstehungsrate
Nacharbeitsquote
Ausschussquote
Kosten der Nichtqualität
Anteil präventiv behandelter Fehlerursachen

Die Anzahl von Feststellungen aus internen Audits ist dagegen nur eingeschränkt als KPI für Fehlerprävention geeignet. Sie zeigt zunächst, dass Abweichungen gefunden wurden – nicht, dass Fehler in den operativen Prozessen verhindert werden.

Die entscheidende Frage lautet:

Entdecken wir Fehler – oder verhindern wir, dass sie überhaupt entstehen?

7. Kontinuierliche Verbesserung

Kontinuierliche Verbesserung ist ein wesentlicher Bestandteil eines wirksamen QM-Systems.

Ziel:
Prozesse, Produkte und das Managementsystem werden kontinuierlich verbessert.

Geeignete KPIs:

Anzahl umgesetzter Verbesserungsmaßnahmen
Umsetzungsquote
Durchlaufzeit von Verbesserungsmaßnahmen
erzielte Qualitätsverbesserung
erzielte Kosteneinsparung
Wirksamkeit abgeschlossener Maßnahmen

Die reine Anzahl eingereichter Verbesserungsvorschläge ist nur ein Aktivitätsindikator.

100 Vorschläge sind nicht automatisch besser als zehn.

Entscheidend ist:

Welche Verbesserungen wurden umgesetzt und welche nachweisbare Wirkung haben sie erzielt?

8. Mitarbeiterkompetenz und Engagement

Menschen beeinflussen unmittelbar die Fähigkeit eines Unternehmens, konforme Produkte und Dienstleistungen zu erzeugen.

Ziel:
Mitarbeiter verfügen über die für ihre Aufgaben erforderlichen Kompetenzen und können diese wirksam einsetzen.

Geeignete KPIs:

Erfüllungsgrad definierter Kompetenzanforderungen
Anteil qualifizierter Mitarbeiter
erfolgreiche Qualifikationen
Schulungswirksamkeit
Mitarbeiterzufriedenheit
Engagement-Index

Die Anzahl durchgeführter Schulungen allein ist dabei wenig aussagekräftig.

Eine Schulung wurde durchgeführt – aber wurde die erforderliche Kompetenz tatsächlich aufgebaut?

Deshalb sollte neben der Schulungsaktivität auch die Wirksamkeit betrachtet werden.

9. Innovation

Innovation ist in erster Linie ein strategisches Unternehmensziel, kann aber für das QM relevant sein.

Ziel:
Neue oder verbesserte Produkte, Dienstleistungen und Prozesse werden systematisch entwickelt.

Geeignete KPIs:

Anzahl erfolgreich eingeführter Innovationen
Anteil neuer Produkte am Umsatz
Time-to-Market
Erfolgsquote von Entwicklungsprojekten
Kundennutzen neuer Produkte

Dabei sollte nicht nur gezählt werden, wie viele Innovationen entstanden sind.

Die entscheidende Frage ist:

Erzeugt die Innovation einen nachweisbaren Nutzen für Kunden und Unternehmen?

10. Risikomanagement

Qualitätsrisiken sollten systematisch erkannt, bewertet und behandelt werden.

Ziel:
Wesentliche Qualitätsrisiken werden frühzeitig erkannt und wirksam behandelt.

Geeignete KPIs:

Anteil bewerteter kritischer Risiken
Anteil behandelter kritischer Risiken
Anteil wirksam behandelter Risiken
Anzahl wiederkehrender Fehlerursachen
Zeit bis zur Risikobehandlung

Die Anzahl identifizierter Risiken ist dabei kein geeigneter Erfolgsindikator.

Ein Unternehmen, das plötzlich mehr Risiken erkennt, muss nicht schlechter geworden sein – möglicherweise ist lediglich die Risikoerkennung besser geworden.

Aussagekräftiger ist beispielsweise:

Anteil kritischer Risiken mit wirksamer Behandlung.

11. Lieferantenqualität

Lieferanten können einen erheblichen Einfluss auf die Qualität der eigenen Produkte und Dienstleistungen haben.

Ziel:
Lieferanten liefern zuverlässig die vereinbarte Qualität und Leistung.

Geeignete KPIs:

Anteil fehlerfreier Lieferungen
Reklamationsquote
Termintreue
Anzahl kritischer Lieferantenabweichungen
Reaktionszeit bei Lieferantenproblemen
Wirksamkeit von Lieferantenmaßnahmen

Eine Lieferantenbewertung sollte dabei nicht nur die Produktqualität betrachten. Je nach Lieferant können auch Termintreue, Service, Kommunikation, Informationssicherheit, Compliance, Abhängigkeit und Ausfallrisiko relevant sein.

12. Nachhaltigkeit und Umwelt

Nachhaltigkeit ist nicht automatisch ein klassisches QM-Ziel. In einem integrierten Managementsystem kann sie jedoch eine wichtige Zielgröße darstellen.

Ziel:
Ressourcen werden effizient eingesetzt und relevante Umwelt- und Nachhaltigkeitsanforderungen erfüllt.

Geeignete KPIs:

Energieverbrauch
Materialverbrauch
Anteil recycelter Materialien
Abfallmenge
CO₂-Emissionen
Ausschuss- und Materialverluste

Beispielsweise:

Materialverlust je produzierter Einheit

kann sowohl eine ökologische als auch eine wirtschaftliche Qualitätsdimension sichtbar machen.

13. Compliance und rechtliche Konformität

Ein Unternehmen muss seine relevanten gesetzlichen, regulatorischen und sonstigen verbindlichen Anforderungen kennen und einhalten.

Ziel:
Relevante Anforderungen werden systematisch identifiziert, bewertet, umgesetzt und überwacht.

Geeignete KPIs:

Anzahl festgestellter Compliance-Abweichungen
Anteil bewerteter Anforderungen
Anteil fristgerecht umgesetzter Änderungen
Bearbeitungszeit bei neuen Anforderungen
Anteil geschlossener Maßnahmen

„Null Verstöße“ klingt zunächst gut, ist aber als alleiniger KPI problematisch. Nicht erkannte Verstöße würden ebenfalls als „null“ erscheinen.

Deshalb sollte zusätzlich betrachtet werden, wie systematisch Anforderungen überwacht und bewertet werden.

14. Flexibilität und Reaktionsfähigkeit

Märkte, Kundenanforderungen, Technologien und gesetzliche Anforderungen verändern sich.

Ziel:
Das Unternehmen kann relevante Veränderungen schnell und kontrolliert umsetzen, ohne die Qualität zu beeinträchtigen.

Geeignete KPIs:

Zeit zur Umsetzung neuer Anforderungen
Time-to-Market
Durchlaufzeit von Änderungsanträgen
Reaktionszeit auf Kundenanforderungen
Zeit bis zur Umsetzung regulatorischer Änderungen

Entscheidend ist jedoch nicht allein die Geschwindigkeit.

Eine Änderung, die schnell umgesetzt wurde, aber anschließend Fehler produziert, ist kein Erfolg.

Deshalb sollte die Qualität der Umsetzung ebenfalls bewertet werden.

15. Prozessstabilität und Robustheit

Ein guter Prozess produziert nicht nur gelegentlich ein gutes Ergebnis. Er soll wiederholbar und stabil gute Ergebnisse liefern.

Ziel:
Prozesse liefern innerhalb definierter Grenzen stabile und vorhersehbare Ergebnisse.

Geeignete KPIs:

Prozessfähigkeit
Prozessstreuung
Abweichungsrate
Ausschussquote
First Pass Yield
Cp/Cpk, soweit statistisch sinnvoll einsetzbar

Die Standardabweichung kann ein geeignetes statistisches Maß sein, ist aber nicht für jeden Prozess automatisch der beste KPI.

Bei geeigneten Produktionsprozessen können beispielsweise statistische Prozessregelung und Prozessfähigkeitskennzahlen aussagekräftiger sein.

16. Qualität der dokumentierten Information

Dokumentation ist kein Selbstzweck. Sie soll sicherstellen, dass relevante Informationen verfügbar, verständlich, aktuell und nachvollziehbar sind.

Ziel:
Dokumentierte Informationen sind aktuell, geeignet, verfügbar und werden wirksam genutzt.

Geeignete KPIs:

Anteil fristgerecht geprüfter Dokumente
Anteil veralteter Dokumente
Durchlaufzeit von Dokumentenänderungen
Anzahl dokumentationsbedingter Fehler
Anteil korrekt freigegebener Dokumente

Dabei reicht „100 % aktuelle Dokumente“ nicht aus.

Ein Dokument kann formal aktuell sein und trotzdem unverständlich, schwer auffindbar oder im Arbeitsprozess unbrauchbar.

Deshalb sollte auch betrachtet werden:

Wird die dokumentierte Information tatsächlich verstanden und angewendet?

17. Wissensmanagement und Kompetenzentwicklung

Wissen ist eine wesentliche Ressource eines Unternehmens. Kritisches Wissen darf nicht ausschließlich an einzelne Personen gebunden sein.

Ziel:
Relevantes Wissen wird identifiziert, verfügbar gemacht, erhalten und weiterentwickelt.

Geeignete KPIs:

Anteil kritischer Kompetenzen mit Vertretungsregelung
Anzahl qualifizierter Mitarbeiter je Schlüsselkompetenz
Zeit bis zur Einarbeitung neuer Mitarbeiter
dokumentierte Schlüsselprozesse
Kompetenzabdeckung

Auch hier gilt:

Anzahl der Trainingsstunden ≠ Kompetenz.

Trainingsstunden messen eine Aktivität. Die eigentliche Frage lautet, ob die erforderliche Kompetenz vorhanden und im Arbeitsprozess wirksam ist.

III. Von der Kennzahl zur tatsächlichen Wirksamkeit

Eine häufige Schwäche von Managementsystemen besteht darin, dass sehr viele Kennzahlen erhoben werden, aber nur wenige wirklich zur Steuerung beitragen.

Ein Unternehmen kann beispielsweise folgende Kennzahlen vorweisen:

98 % der Schulungen durchgeführt
100 % der Dokumente geprüft
95 % der Audits durchgeführt
100 % der Lieferanten bewertet

Das klingt zunächst hervorragend.

Aber was sagen diese Zahlen über die tatsächliche Qualität aus?

Vielleicht gleichzeitig:

steigt die Reklamationsquote,
nimmt die Nacharbeit zu,
wiederholen sich Fehler,
verschlechtert sich die Kundenzufriedenheit,
werden kritische Risiken nicht ausreichend behandelt.

Dann arbeitet das QM-System zwar – aber möglicherweise nicht wirksam genug.

Deshalb sollten Kennzahlen möglichst mehrere Ebenen abdecken.

Input

Welche Ressourcen und Voraussetzungen stehen zur Verfügung?

Beispiele:

Schulungsbudget
verfügbare Mitarbeiter
Prüfmittel
Ressourcen für Verbesserungsmaßnahmen

Prozess

Was wird tatsächlich durchgeführt?

Beispiele:

durchgeführte Schulungen
abgeschlossene Lieferantenbewertungen
durchgeführte Audits
geprüfte Dokumente

Output

Welche Ergebnisse entstehen?

Beispiele:

Anzahl bearbeiteter Reklamationen
abgeschlossene Verbesserungsmaßnahmen
geprüfte Produkte

Outcome / Wirksamkeit

Welche tatsächliche Wirkung wird erzielt?

Beispiele:

sinkende Fehlerquote
weniger Reklamationen
höhere Kundenzufriedenheit
stabilere Prozesse
geringere Kosten der Nichtqualität
reduzierte Risiken

Gerade die letzte Ebene wird in Managementsystemen häufig unterschätzt.

IV. Eine einfache Struktur für wirksame Qualitätsziele

Für die Praxis hat sich eine einfache Kette bewährt:

Qualitätsziel → KPI → Metrik → Zielwert → Maßnahmen → Wirksamkeitsbewertung

Ein Beispiel

Element: Beispiel

Qualitätsziel: Fehler in der Auftragsbearbeitung reduzieren

KPI: Fehlerquote

Metrik: fehlerhafte Aufträge / Gesamtaufträge × 100

Zielwert: ≤ 1 %

Maßnahme: Ursachenanalyse und Prozessoptimierung

Verantwortlich: Prozessverantwortlicher

Termin : 30.06.2027

Wirksamkeitsbewertung: Fehlerquote sinkt dauerhaft unter 1 %

Damit wird aus einer abstrakten Qualitätsabsicht ein steuerbares Managementinstrument .

V. Nicht nur messen, ob das QM arbeitet – messen, ob es wirkt

Ein gutes Qualitätsmanagement sollte nicht möglichst viele Kennzahlen produzieren.

Es sollte die richtigen Kennzahlen verwenden.

Dabei sollte jede Kennzahl eine konkrete Managementfrage beantworten:

Erreichen wir unsere Qualitätsziele?
Erfüllen unsere Produkte und Dienstleistungen die Anforderungen?
Sind unsere Prozesse stabil?
Werden Fehler verhindert oder nur entdeckt?
Sind unsere Lieferanten zuverlässig?
Werden Risiken wirksam behandelt?
Sind Verbesserungsmaßnahmen tatsächlich wirksam?
Sind unsere Mitarbeiter ausreichend kompetent?
Steigt die Kundenzufriedenheit?
Verbessert sich die Qualität messbar?

Die entscheidende Perspektive lautet deshalb:

Nicht nur messen, ob das QM-System arbeitet – messen, ob es wirkt.

Genau darin liegt der Unterschied zwischen einem QM-System, das vor allem Dokumente, Audits und Kennzahlen verwaltet, und einem QM-System, das tatsächlich zur Qualität, Stabilität und Leistungsfähigkeit des Unternehmens beiträgt.

Ein wirksames Qualitätsmanagement verbindet deshalb Anforderungen, Ziele, Risiken, Prozesse, Kennzahlen und Verbesserungen zu einem geschlossenen Regelkreis:

Anforderung → Qualitätsziel → Prozess → KPI → Bewertung → Verbesserung → Wirksamkeitsnachweis

So wird Qualitätsmanagement von einer reinen Dokumentations- und Nachweisfunktion zu einem praktischen Steuerungsinstrument für die Organisation .

Viel Erfolg,

Ihr Konstantin Ziouras

Informationssicherheitsziele

Mon, 30 Mar 2026 19:04:03 GMT

Informationssicherheitsziele

Informationssicherheitsziele – von den klassischen Schutzzielen zur tatsächlichen Wirksamkeit

Informationssicherheit wird häufig mit den drei klassischen Schutzzielen Vertraulichkeit, Integrität und Verfügbarkeit – kurz V.I.V. oder C.I.A. (Confidentiality, Integrity, Availability) – beschrieben.

Diese drei Ziele bilden nach wie vor das Fundament eines Informationssicherheitsmanagementsystems (ISMS). In der Praxis reichen sie jedoch häufig nicht aus, um die tatsächlichen Anforderungen eines Unternehmens, seiner Kunden, Mitarbeiter, Lieferanten und regulatorischen Rahmenbedingungen vollständig zu beschreiben.

Moderne Informationssicherheit umfasst deshalb weitere Eigenschaften wie Authentizität, Nachvollziehbarkeit, Resilienz, Wiederherstellbarkeit, Datenschutz, Lieferkettensicherheit oder Missbrauchsschutz .

Entscheidend ist dabei nicht nur die Frage:

„Welche Maßnahmen haben wir umgesetzt?“

Sondern vor allem:

„Erreichen wir damit tatsächlich unsere Informationssicherheitsziele?“

Damit kommt eine wichtige Unterscheidung ins Spiel: Innensicht und Außensicht .

1. Informationssicherheitsziele sind mehr als eine Liste von Controls

Ein häufiger Fehler in der Praxis besteht darin, Informationssicherheit über Maßnahmen zu beschreiben:

Wir haben eine Firewall.
Wir verwenden MFA.
Wir erstellen Backups.
Wir führen Awareness-Schulungen durch.
Wir haben ein Berechtigungskonzept.
Wir überwachen unsere Systeme.
Wir führen Lieferantenbewertungen durch.

Das sind jedoch Maßnahmen bzw. Controls und noch keine Informationssicherheitsziele.

Ein Sicherheitsziel beschreibt zunächst den gewünschten Zustand .

Beispielsweise:

Vertrauliche Informationen dürfen nur von dazu berechtigten Personen, Systemen oder Prozessen verarbeitet werden.

Erst danach stellt sich die Frage:

Welche Anforderungen und Maßnahmen benötigen wir, um dieses Ziel zu erreichen?

Und anschließend:

Woran erkennen wir, ob die Maßnahmen tatsächlich wirksam sind?

Damit entsteht eine wichtige Kette:

Informationssicherheitsziel → Sicherheitsanforderung → Maßnahmen/Controls → Prozess → Messung → tatsächliche Wirkung

Diese Systematik wird in einem separaten Beitrag zu KPI und Metriken für Informationssicherheitsziele ausführlicher behandelt.

2. Die klassische Basis: CIA

2.1 Vertraulichkeit – Confidentiality

Ziel:

Informationen sollen ausschließlich denjenigen Personen, Systemen oder Prozessen zugänglich sein, die dafür berechtigt sind.

Vertraulichkeit betrifft damit nicht nur technische Zugriffe. Auch Fehlversendungen, falsch konfigurierte Cloud-Speicher, Social Engineering, Insider oder unzureichend geschützte Dokumente können zu einem Verlust der Vertraulichkeit führen.

Innensicht – Prävention und Beherrschung

Typische Kriterien sind:

angemessene Berechtigungskonzepte
Least Privilege
MFA
Verschlüsselung
Netzwerksegmentierung
DLP
sichere Cloud-Konfiguration
Zugriffskontrollen
Awareness
Schutz vertraulicher Dokumente
regelmäßige Überprüfung von Berechtigungen

Hier wird beispielsweise gemessen:

Anteil regelmäßig überprüfter Berechtigungen
Anteil privilegierter Konten mit MFA
Anzahl kritischer Fehlkonfigurationen
Anzahl blockierter unzulässiger Datenübertragungen
Anteil geschulter Mitarbeiter

Außensicht – tatsächliches Ergebnis

Die entscheidende Frage lautet:

Sind vertrauliche Informationen tatsächlich in unberechtigte Hände gelangt?

Beispielsweise:

erfolgreiche unberechtigte Zugriffe
tatsächlich exfiltrierte Daten
Fehlversendungen vertraulicher Informationen
Anzahl betroffener Datensätze
Schutzbedarf der offengelegten Informationen
Anzahl betroffener Kunden oder Geschäftspartner
Umfang der tatsächlich verlassenen Vertrauensgrenze

Eine besonders aussagekräftige Frage lautet:

Wie viele schützenswerte Informationen haben tatsächlich die definierte Vertrauensgrenze verlassen?

Damit wird deutlich: Eine Organisation kann sehr viele Sicherheitsmaßnahmen besitzen und trotzdem einen erheblichen Vertraulichkeitsverlust erleiden.

2.2 Integrität – Integrity

Ziel:

Informationen sollen richtig, vollständig und konsistent sein und vor unbefugten oder unbeabsichtigten Veränderungen geschützt werden.

Integrität bedeutet daher nicht einfach „Unveränderbarkeit“.

Eine Datenbank, die überhaupt nicht verändert werden kann, wäre beispielsweise nicht automatisch integer. Entscheidend ist, dass Änderungen autorisiert, korrekt, nachvollziehbar und vollständig erfolgen.

Innensicht

Typische Kriterien:

Berechtigungskonzepte
Trennung von Rollen
Vier-Augen-Prinzip
Change Management
Versionierung
digitale Signaturen oder Hashwerte
Protokollierung
Integritätsprüfungen
kontrollierte Datenübertragung
Backup und Wiederherstellung

Außensicht

Hier geht es um die tatsächlich eingetretene Veränderung:

Wie viele Daten wurden unberechtigt verändert?
Welche Datensätze waren betroffen?
Welche Systeme oder Geschäftsprozesse waren betroffen?
Wie lange blieb die Manipulation unentdeckt?
Konnte die Veränderung vollständig erkannt werden?
Konnte ein vertrauenswürdiger Zustand wiederhergestellt werden?
Welche Veränderungen waren nicht mehr rekonstruierbar?

Die entscheidende Wirksamkeitsfrage lautet:

Welche Informationen wurden tatsächlich unberechtigt verändert – und welche Veränderungen konnten nicht mehr zuverlässig aus einer vertrauenswürdigen Quelle wiederhergestellt werden?

2.3 Verfügbarkeit – Availability

Ziel:

Informationen und die dafür erforderlichen Systeme sollen für berechtigte Nutzer verfügbar sein, wenn sie benötigt werden.

Verfügbarkeit bedeutet dabei nicht zwangsläufig 100 % technische Verfügbarkeit.

Entscheidend ist vielmehr die für den jeweiligen Geschäftsprozess erforderliche Verfügbarkeit.

Innensicht

Beispiele:

Redundanz
Hochverfügbarkeit
Backup
Failover
Monitoring
Notfallverfahren
Kapazitätsmanagement
Wartung
Wiederanlaufverfahren
Disaster Recovery

Außensicht

Hier zählt das tatsächlich erlebte Ergebnis:

tatsächliche Ausfallzeit
betroffene Geschäftsservices
betroffene Nutzer oder Kunden
verlorene Transaktionen
verzögerte Geschäftsprozesse
tatsächliche Geschäftsunterbrechung

Die entscheidende Frage lautet:

Wie stark und wie lange war der Geschäftsbetrieb tatsächlich beeinträchtigt?

3. Innensicht und Außensicht – zwei Seiten eines Sicherheitsziels

Die Unterscheidung zwischen Innen- und Außensicht lässt sich auf praktisch jedes Informationssicherheitsziel übertragen.

Innensicht

Die Innensicht betrachtet beispielsweise:

Sind wir angemessen vorbereitet und beherrschen wir die Risiken?

Hier stehen Controls, Prozesse, Verantwortlichkeiten und Prävention im Mittelpunkt.

Außensicht

Die Außensicht betrachtet:

Was konnte tatsächlich passieren bzw. welche Wirkung ist tatsächlich eingetreten?

Dabei geht es nicht ausschließlich um externe Angreifer.

Die Außensicht umfasst beispielsweise:

Cyberangriffe
Fehlkonfigurationen
menschliche Fehler
Insider
Lieferanten
technische Ausfälle
Naturereignisse
Fehlbedienung
Social Engineering
unzureichende Prozesse

Die Außensicht ist damit die tatsächliche Wirkung in der Realität .

4. Von der Maßnahme zur tatsächlichen Wirkung

Eine sinnvolle Betrachtung von Informationssicherheit kann deshalb mehrere Ebenen unterscheiden:

1. Innensicht – Kontrolle

Was haben wir umgesetzt?

2. Prävention und Detektion

Was konnten wir verhindern oder erkennen?

3. Außensicht – Outcome

Was ist tatsächlich passiert?

4. Auswirkung und Wiederherstellung

Welche Konsequenzen entstanden und wie schnell konnten wir einen vertrauenswürdigen Zustand wiederherstellen?

Vereinfacht:

Control → Prävention → Detektion → erfolgreicher Vorfall → Auswirkung → Wiederherstellung

Diese Betrachtung verhindert einen typischen Fehler:

Viele implementierte Controls bedeuten nicht automatisch wirksame Informationssicherheit.

Ebenso bedeutet ein gemessener Wert von „0 Vorfällen“ nicht automatisch, dass keine Vorfälle stattgefunden haben. Ein nicht erkannter Angriff kann schließlich ebenfalls als „0 Vorfälle“ erscheinen.

Deshalb sollten Control-, Präventions-, Detektions- und Outcome-Metriken sinnvoll miteinander kombiniert werden.

5. Erweiterte Informationssicherheitsziele

Neben den klassischen CIA-Schutzzielen können abhängig vom Kontext weitere Ziele relevant sein.

Dabei sollte allerdings unterschieden werden:

Nicht jede gewünschte Systemeigenschaft ist automatisch ein primäres Informationssicherheitsziel .

Beispielsweise können Skalierbarkeit, Wartbarkeit oder Interoperabilität wichtige technische oder betriebliche Ziele sein. Sie können aber gleichzeitig erhebliche Auswirkungen auf die Informationssicherheit haben.

Die konkrete Auswahl sollte deshalb aus Kontext, Risiken, Geschäftsanforderungen, gesetzlichen Anforderungen und den Bedürfnissen interessierter Parteien abgeleitet werden.

5.1 Authentizität

Ziel: Es soll zuverlässig festgestellt werden können, ob ein Benutzer, System, Gerät, Dokument oder Kommunikationspartner tatsächlich derjenige ist, der er vorgibt zu sein.

Innensicht:

starke Authentifizierung
MFA
Zertifikate
Identitätsmanagement
sichere Geräteidentitäten

Außensicht:

tatsächlich akzeptierte gefälschte Identitäten
erfolgreiche Account-Übernahmen
manipulierte Kommunikationspartner
gefälschte Dokumente oder Nachrichten

Wirksamkeitsfrage:

Wurden tatsächlich nicht authentische Identitäten oder Kommunikationsinhalte als echt akzeptiert?

5.2 Autorisierung

Ziel: Nur berechtigte Personen und Systeme dürfen definierte Aktionen durchführen.

Innensicht:

Rollen- und Berechtigungskonzepte
Least Privilege
Rezertifizierung
Segregation of Duties

Außensicht:

tatsächlich unberechtigt ausgeführte Aktionen
missbrauchte Privilegien
erfolgreiche Privilege Escalation

5.3 Nachvollziehbarkeit und Zurechenbarkeit

Ziel: Relevante Aktionen sollen einer verantwortlichen Identität oder einem verantwortlichen System zugeordnet werden können.

Innensicht:

Logging
eindeutige Benutzerkonten
Zeitstempel
manipulationsgeschützte Audit Trails
Protokollierungsanforderungen

Außensicht:

Können wir einen tatsächlichen Sicherheitsvorfall oder eine relevante Transaktion zuverlässig rekonstruieren?

5.4 Auditierbarkeit

Ziel: Sicherheitsrelevante Prozesse, Entscheidungen und Kontrollen sollen überprüfbar sein.

Innensicht:

dokumentierte Prozesse
Audit Trails
Nachweise
Prüfpläne
Verantwortlichkeiten

Außensicht:

Können wir einen konkreten Vorgang im Nachhinein tatsächlich nachvollziehbar und belastbar nachweisen?

5.5 Transparenz

Ziel: Relevante Informationen über Prozesse, Entscheidungen und Systemverhalten sollen für die jeweils berechtigten Interessengruppen verständlich und nachvollziehbar sein.

Innensicht:

dokumentierte Verantwortlichkeiten
nachvollziehbare Prozesse
transparente Entscheidungsregeln
geeignete Berichte

Außensicht:

Verstehen Betroffene und Verantwortliche tatsächlich, was ein System oder Prozess gemacht hat und warum?

Bei KI-Systemen gewinnt dieses Ziel beispielsweise besondere Bedeutung.

5.6 Datenschutz und Privacy

Ziel: Personenbezogene Daten sollen entsprechend den rechtlichen, vertraglichen und organisatorischen Anforderungen geschützt und verarbeitet werden.

Innensicht:

Datenschutzanforderungen
Zugriffsschutz
Löschkonzepte
Privacy by Design
Verzeichnis von Verarbeitungstätigkeiten
technische und organisatorische Maßnahmen

Außensicht:

tatsächliche Datenschutzverletzungen
betroffene Personen
Umfang der offengelegten personenbezogenen Daten
tatsächliche Auswirkungen auf Betroffene

5.7 Datenminimierung

Ziel: Es sollen nur diejenigen personenbezogenen oder schützenswerten Daten erhoben, verarbeitet und gespeichert werden, die tatsächlich benötigt werden.

Außensicht:

Nicht nur:

„Haben wir ein Löschkonzept?“

sondern:

„Wie viele nicht mehr erforderliche Daten befinden sich tatsächlich noch in unseren Systemen?“

5.8 Zweckbindung

Ziel: Informationen sollen nur für festgelegte und zulässige Zwecke verarbeitet werden.

Die Wirksamkeit zeigt sich daher nicht allein in einer dokumentierten Zweckbeschreibung, sondern auch darin, ob Daten tatsächlich für nicht vorgesehene Zwecke verwendet werden.

5.9 Resilienz

Ziel: Die Organisation soll auch bei Störungen, Angriffen oder unerwarteten Ereignissen handlungsfähig bleiben.

Innensicht:

Resilienzkonzepte
Redundanzen
Notfallorganisation
Szenarien
Übungen
Krisenmanagement

Außensicht:

Wie gut konnte die Organisation einen tatsächlichen Angriff oder eine Störung verkraften, ohne ihre kritischen Funktionen zu verlieren?

5.10 Wiederherstellbarkeit

Ziel: Ein vertrauenswürdiger Zustand soll nach einer Störung oder einem Angriff wiederhergestellt werden können.

Innensicht:

Backups
Recovery-Verfahren
Wiederanlaufpläne
getestete Restore-Verfahren

Außensicht:

tatsächlich benötigte Wiederherstellungszeit
tatsächlich verlorene Daten
tatsächlich wiederhergestellte Systeme
verbleibende Schäden

Wichtig:

RTO und RPO sind in erster Linie Ziel- bzw. Anforderungswerte.

Die eigentlichen KPI können beispielsweise messen, ob die tatsächlich erreichte Wiederherstellungszeit und der tatsächliche Datenverlust diese Anforderungen eingehalten haben.

5.11 Kontinuität

Ziel: Kritische Geschäftsprozesse sollen auch bei erheblichen Störungen aufrechterhalten oder innerhalb definierter Grenzen wieder aufgenommen werden können.

Die Außensicht zeigt sich beispielsweise in:

tatsächlicher Dauer der Geschäftsunterbrechung
Anzahl betroffener Geschäftsprozesse
tatsächlich ausgefallenen Leistungen
tatsächlich entstandenen Auswirkungen auf Kunden

5.12 Robustheit

Ziel: Systeme und Prozesse sollen gegenüber Fehlern, Belastungen und Störungen ausreichend widerstandsfähig sein.

Die Außensicht betrachtet beispielsweise:

tatsächliche Fehlerraten
Ausfallverhalten
Auswirkungen unerwarteter Eingaben
Verhalten unter außergewöhnlicher Belastung

5.13 Missbrauchsschutz

Ziel: Informationen, Systeme und Berechtigungen sollen nicht für unzulässige Zwecke missbraucht werden können.

Dazu gehören beispielsweise:

Missbrauch privilegierter Konten
Insider-Aktivitäten
Credential Theft
Missbrauch von APIs
automatisierter Missbrauch
Social Engineering

Die entscheidende Frage lautet:

Welche Missbrauchsszenarien konnten tatsächlich erfolgreich umgesetzt werden?

5.14 Compliance

Ziel: Anwendbare gesetzliche, regulatorische, vertragliche und normative Anforderungen sollen eingehalten werden.

Dabei ist „100 % Compliance“ als pauschales Ziel wenig aussagekräftig.

Sinnvoller sind beispielsweise:

Anteil identifizierter anwendbarer Anforderungen
Anteil fristgerecht umgesetzter Anforderungen
Anzahl bestätigter Compliance-Verstöße
Dauer bis zur Behebung von Abweichungen

Die Frage lautet:

Werden die für uns relevanten Anforderungen tatsächlich eingehalten?

5.15 Lieferkettensicherheit

Ziel: Risiken aus Lieferanten, Dienstleistern, Cloud-Anbietern und anderen externen Abhängigkeiten sollen angemessen beherrscht werden.

Innensicht:

Lieferantenbewertung
Sicherheitsanforderungen in Verträgen
Due Diligence
regelmäßige Bewertungen
Überwachung kritischer Dienstleister

Außensicht:

tatsächlich eingetretene Lieferanten-Sicherheitsvorfälle
Ausfälle kritischer Dienstleister
tatsächlich entstandene Abhängigkeiten
Auswirkungen eines Lieferantenausfalls

Dabei sollte nicht das unrealistische Ziel formuliert werden:

„Drittanbieter stellen kein Risiko dar.“

Sinnvoller ist:

Risiken aus Drittparteien werden identifiziert, bewertet, behandelt und überwacht.

5.16 Reaktionsfähigkeit

Ziel: Sicherheitsereignisse sollen schnell und angemessen erkannt, bewertet und behandelt werden können.

Innensicht:

Incident-Management
Alarmierung
Verantwortlichkeiten
Eskalationswege
Playbooks
Übungen

Außensicht:

tatsächliche Zeit bis zur Erkennung
tatsächliche Zeit bis zur Reaktion
tatsächliche Zeit bis zur Eindämmung
Auswirkungen des Vorfalls vor der Eindämmung

5.17 Nichtabstreitbarkeit

Ziel: Das spätere Abstreiten einer relevanten Aktion oder Transaktion soll unter definierten Bedingungen verhindert bzw. erschwert werden.

Relevant sind beispielsweise:

digitale Signaturen
beweissichere Protokollierung
Zeitstempel
Transaktionsnachweise

Die Außensicht stellt die Frage:

Können wir eine konkrete Transaktion oder Handlung im Streitfall tatsächlich belastbar nachweisen?

5.18 Steuerbarkeit und Kontrollierbarkeit

Ziel: Sicherheitsrelevante Zustände und Maßnahmen sollen gezielt beeinflusst und kontrolliert werden können.

Beispiele:

Berechtigungen sperren
Systeme isolieren
Zugriffe deaktivieren
Sicherheitskonfigurationen ändern
Notfallmaßnahmen auslösen

Die Außensicht zeigt sich darin, ob diese Maßnahmen im tatsächlichen Ereignisfall rechtzeitig und wirksam umgesetzt werden konnten.

5.19 Anonymität

Ziel: Wenn Anonymität erforderlich ist, soll die Identität einer Person nicht über das vorgesehene Maß hinaus ermittelt werden können.

Dabei ist zwischen Anonymisierung und Pseudonymisierung zu unterscheiden.

Das Ziel ist nicht grundsätzlich „maximale Anonymität“, sondern ein angemessener Schutz der Identität entsprechend dem jeweiligen Anwendungsfall und den geltenden Anforderungen.

5.20 Datenqualität

Ziel: Für sicherheits- und geschäftskritische Entscheidungen sollen Daten ausreichend korrekt, vollständig, aktuell und konsistent sein.

Datenqualität ist nicht ausschließlich ein Informationssicherheitsziel. Sie kann ebenso ein Qualitäts-, Prozess- oder Data-Governance-Ziel sein.

Sie wird jedoch sicherheitsrelevant, wenn fehlerhafte oder manipulierte Daten zu falschen Sicherheits- oder Geschäftsentscheidungen führen.

5.21 Vertrauenswürdigkeit

Ziel: Systeme, Informationen und Ergebnisse sollen unter definierten Bedingungen als vertrauenswürdig eingestuft werden können.

Bei KI-Systemen können beispielsweise folgende Aspekte relevant sein:

Genauigkeit
Robustheit
Nachvollziehbarkeit
Datenschutz
Informationssicherheit
menschliche Aufsicht
Zuverlässigkeit

Die Bewertung sollte daher nicht auf einen einzelnen Wert wie eine „Halluzinationsrate“ reduziert werden.

5.22 Interoperabilität

Ziel: Systeme sollen sicher und zuverlässig miteinander kommunizieren und Informationen austauschen können.

Informationssicherheitsrelevant sind beispielsweise:

sichere Schnittstellen
definierte Protokolle
Authentifizierung
Integrität der übertragenen Daten
kontrollierte Datenflüsse

5.23 Skalierbarkeit

Ziel: Sicherheitsmechanismen sollen auch bei wachsender Benutzerzahl, Datenmenge, Systemanzahl oder Transaktionsvolumen wirksam bleiben.

Die Frage lautet beispielsweise:

Funktioniert unser Sicherheitskonzept auch dann noch, wenn sich die Anzahl der Systeme oder Benutzer verdoppelt?

Skalierbarkeit ist dabei eher eine technische bzw. betriebliche Eigenschaft als ein klassisches Schutzziel.

5.24 Wartbarkeit

Ziel: Sicherheitsrelevante Systeme und Maßnahmen sollen dauerhaft betrieben, aktualisiert und angepasst werden können.

Beispiele:

Patchbarkeit
Updatefähigkeit
Austausch veralteter Komponenten
Wartbarkeit von Sicherheitskonfigurationen
Aktualisierung von Regeln und Signaturen

Auch hier handelt es sich eher um eine unterstützende technische Eigenschaft als um ein klassisches Schutzziel.

5.25 Supply-Chain- und Abhängigkeitssicherheit

Neben der klassischen Lieferantensicherheit kann es sinnvoll sein, kritische Abhängigkeiten explizit zu betrachten:

Cloud-Abhängigkeiten
Softwarebibliotheken
Open-Source-Komponenten
Managed Services
externe Identitätsprovider
Kommunikationsanbieter
Single Points of Failure

Die entscheidende Frage lautet:

Was passiert mit unserer Informationssicherheit, wenn eine kritische externe Abhängigkeit ausfällt oder kompromittiert wird?

6. Nicht jedes Ziel ist ein primäres Informationssicherheitsziel

Die große Zahl möglicher Ziele zeigt auch eine wichtige Grenze.

Nicht jedes Unternehmensziel sollte automatisch zu einem Informationssicherheitsziel erklärt werden.

Eine sinnvolle Struktur kann beispielsweise so aussehen:

Primäre Informationssicherheitsziele

Vertraulichkeit
Integrität
Verfügbarkeit

Erweiterte Sicherheits- und Governance-Ziele

Authentizität
Autorisierung
Nachvollziehbarkeit
Auditierbarkeit
Nichtabstreitbarkeit
Zurechenbarkeit
Transparenz
Steuerbarkeit

Resilienz- und Continuity-Ziele

Resilienz
Wiederherstellbarkeit
Kontinuität
Robustheit
Reaktionsfähigkeit

Datenschutz- und Datenziele

Datenschutz
Datenminimierung
Zweckbindung
Anonymität
Datenqualität

Externe und regulatorische Ziele

Compliance
Lieferkettensicherheit

Technische unterstützende Eigenschaften

Interoperabilität
Skalierbarkeit
Wartbarkeit

Vertrauens- und KI-relevante Ziele

Vertrauenswürdigkeit
Missbrauchsschutz

Diese Einteilung ist keine normative Vorgabe. Sie dient dazu, Ziele im jeweiligen Unternehmenskontext sinnvoll zu strukturieren.

7. Von der Innensicht zur Außensicht: Wie wird Wirksamkeit sichtbar?

Ein modernes Informationssicherheitsmanagement sollte nicht bei der Frage stehen bleiben:

„Haben wir die Maßnahme umgesetzt?“

Viel interessanter sind drei aufeinander aufbauende Fragen:

1. Sind wir vorbereitet?

Beispielsweise:

Sind alle kritischen Systeme identifiziert?
Sind Berechtigungen definiert?
Sind Backups vorhanden?
Sind Lieferanten bewertet?

2. Funktionieren unsere Kontrollen?

Beispielsweise:

Werden Angriffe erkannt?
Werden unzulässige Zugriffe blockiert?
Funktionieren Backups?
Werden kritische Schwachstellen rechtzeitig behoben?

3. Was passiert tatsächlich?

Beispielsweise:

Sind Daten tatsächlich abgeflossen?
Wurden Daten tatsächlich manipuliert?
Wie lange waren Systeme tatsächlich nicht verfügbar?
Wie viele Kunden waren tatsächlich betroffen?
Wie viel Datenverlust ist tatsächlich entstanden?

Damit verschiebt sich die Perspektive:

Nicht nur messen, was wir tun. Messen, was wir verhindern – und was trotz unserer Maßnahmen tatsächlich passiert.

8. Informationssicherheitsziel ist nicht gleich KPI

Ein häufiger Fehler besteht darin, einen KPI mit einem Ziel gleichzusetzen.

Beispiel:

Ziel:
Vertraulichkeit schützenswerter Informationen sicherstellen.

Anforderung:
Nur autorisierte Personen dürfen auf vertrauliche Informationen zugreifen.

Maßnahme:
Rollenbasierte Zugriffskontrolle und MFA.

Prozessziel:
Berechtigungen werden korrekt und fristgerecht vergeben, geändert und entzogen.

KPI/Metrik:

Anteil fristgerecht bearbeiteter Berechtigungsänderungen
Anzahl kritischer Berechtigungsfehler
Anzahl blockierter unberechtigter Zugriffsversuche
Anzahl erfolgreicher unberechtigter Zugriffe

Outcome:

tatsächlich offengelegte Informationen
Anzahl betroffener Datensätze
Schutzbedarf der betroffenen Informationen
tatsächliche Auswirkungen

Erst die Gesamtheit dieser Betrachtung ermöglicht eine belastbare Aussage über die Wirksamkeit.

9. Die entscheidende Frage: Wirkt unser ISMS?

Ein ISMS sollte nicht nur nachweisen können:

„Wir haben Prozesse.“

oder:

„Wir haben Controls.“

oder:

„Wir haben KPI.“

Die entscheidende Frage lautet:

Erreichen wir mit unserem ISMS tatsächlich die definierten Informationssicherheitsziele?

Dafür müssen Ziele, Anforderungen, Maßnahmen, Prozesse und Messgrößen miteinander verbunden werden.

Die grundlegende Logik lautet:

· Informationssicherheitsziel

· konkrete Sicherheitsanforderung

· geeignete Controls und Maßnahmen

· Prozessziel

· KPI und Metriken

· tatsächliches Ergebnis / Outcome

· Bewertung der Wirksamkeit

Damit wird aus einer Sammlung von Sicherheitsmaßnahmen ein steuerbares und bewertbares Informationssicherheitsmanagement .

Fazit

Informationssicherheitsziele beginnen mit den klassischen Schutzzielen Vertraulichkeit, Integrität und Verfügbarkeit . In modernen Organisationen müssen sie jedoch häufig um weitere Eigenschaften ergänzt werden – beispielsweise Authentizität, Nachvollziehbarkeit, Resilienz, Wiederherstellbarkeit, Datenschutz, Lieferkettensicherheit oder Missbrauchsschutz.

Entscheidend ist dabei die Verbindung von Innensicht und Außensicht .

Die Innensicht beantwortet:

Sind wir angemessen vorbereitet und beherrschen wir unsere Risiken?

Die Außensicht beantwortet:

Was konnte tatsächlich passieren und welche Auswirkungen sind tatsächlich eingetreten?

Erst beide Perspektiven zusammen ermöglichen eine realistische Bewertung der Informationssicherheit.

Oder kurz gesagt:

Nicht nur messen, ob das ISMS arbeitet – messen, ob es wirkt.

Der nächste Schritt ist deshalb die Übersetzung der Sicherheitsziele in eine belastbare Messlogik:

Ziel → Anforderung → Control → Prozessziel → KPI/Metrik → Outcome → Wirksamkeitsbewertung.

Genau diese Systematik zeigt, wie aus Informationssicherheitszielen messbare und steuerbare Ziele werden.

Was ist ein CVE (Common Vulnerabilities and Exposures)

Mon, 30 Mar 2026 18:32:09 GMT

Was ist ein CVE (Common Vulnerabilities and Exposures)

CVE bedeutet „Common Vulnerabilities and Exposures“,

Eine CVE ist einmalig wie eine ISBN Nummer für Sicherheitslücken

Sie sorgt dafür, dass alle Hersteller, Sicherheitsfirmen und Behörden über dieselbe Schwachstelle sprechen — ohne Verwirrung.

Beispiel: CVE 2021 44228 = Log4Shell (eine der gefährlichsten Lücken der letzten Jahre)

Woher kommt die Nummerierung?

Jede CVE hat das Format:

Code

CVE-JAHR-Laufende Nummer

Beispiel: CVE 2024-12345

• 2024 = Jahr der Registrierung

• 12345 = eindeutige ID

Die Nummern werden nicht nach Schwere sortiert, sondern einfach fortlaufend vergeben.

Wer verwaltet das CVE System?

Das CVE Programm wird betrieben von:

1. MITRE Corporation

• eine Non Profit Organisation in den USA

• arbeitet im Auftrag der US Regierung

• verwaltet die CVE Datenbank

• koordiniert die Vergabe der IDs

• https://attack.mitre.org/

2. US Behörde CISA

• unterstützt das Programm

• veröffentlicht Warnungen

• betreibt die „Known Exploited Vulnerabilities“ (KEV) Liste

3. CNA Organisationen (CVE Numbering Authorities)

Das sind Firmen, die selbst CVEs vergeben dürfen, z. B.:

• Microsoft

• Google

• Cisco

• Intel

• Red Hat

• Siemens

• GitHub

• Palo Alto Networks

Insgesamt über 300 CNAs weltweit.

Wie entsteht eine CVE? (Der Prozess)

1. Forscher oder Hersteller entdeckt eine Schwachstelle

2. Meldung an MITRE oder eine CNA

3. Prüfung, ob es eine neue, eigenständige Lücke ist

4. Vergabe einer CVE Nummer

5. Veröffentlichung der Details (ohne Exploit Code)

6. Hersteller veröffentlicht Updates / Patches

7. CVSS Bewertung (Schweregrad) wird vergeben

Wie wird die Schwere bewertet? (CVSS)

CVSS = Common Vulnerability Scoring System

Skala von 0.0 bis 10.0

Bereich Bedeutung

0.0–3.9 Niedrig

4.0–6.9 Mittel

7.0–8.9 Hoch

9.0–10.0 Kritisch

Beispiel: Log4Shell → CVSS 10.0 (kritisch)

Kategorien von CVEs

CVE Einträge werden nicht offiziell nach Kategorien sortiert, aber in der Praxis unterscheidet man:

1. Betriebssysteme

• Windows

• Linux (Ubuntu, Debian, Red Hat)

• macOS

2. Netzwerkgeräte

• Firewalls (Fortinet, Palo Alto, Cisco ASA)

• Router & Switches

• VPN Gateways

3. Cloud Dienste

• AWS

• Azure

• Google Cloud

4. Web Anwendungen

• WordPress

• Drupal

• Apache

• Nginx

5. Software Bibliotheken

• Log4j

• OpenSSL

• Python Pakete

• Node.js Module

6. Mobile Systeme

• Android

• iOS

7. Industrielle Systeme (OT/ICS)

• Siemens

• Schneider Electric

• Rockwell Automation

Wichtige Tools & Module zur Arbeit mit CVEs

1. Schwachstellenscanner (automatisch), z.B.

• Nessus

• Qualys

• Rapid7 InsightVM

• OpenVAS

Diese Tools scannen Systeme und melden bekannte CVEs.

2. Paket und Dependency Scanner

• GitHub Dependabot

• GitLab Dependency Scanning

• Snyk

• Mend (WhiteSource)

Sie prüfen Bibliotheken in Softwareprojekten.

3. Container Scanner

• Trivy

• Anchore

• Clair

Sie prüfen Docker Images auf CVEs.

4. Betriebssystem Scanner

• Microsoft Defender Vulnerability Management

• Lynis (Linux)

• OSQuery

5. Offizielle CVE Datenbanken

• MITRE CVE Database

• NVD (National Vulnerability Database)

• CISA KEV Catalog (besonders wichtig für Exploits in freier Wildbahn)

Kurz erklärt: Warum CVEs wichtig sind

• Sie schaffen Transparenz über Sicherheitslücken

• Sie ermöglichen Vergleichbarkeit

• Sie sind Grundlage für Patch Management

• Sie sind Pflichtbestandteil von ISO 27001, TISAX, NIS2

• Sie helfen Unternehmen, Risiken zu priorisieren

Marktübersicht Developer Tools & Code Repositories

Mon, 30 Mar 2026 06:28:50 GMT

Marktübersicht Developer Tools & Code Repositories

Ohne Anspruch auf Vollständigkeit

Wichtige Entscheidungskriterien für Developer Tools & Code Repositories

Mon, 30 Mar 2026 06:26:33 GMT

Wichtige Entscheidungskriterien für Developer Tools & Code Repositories

Die Auswahl eines Developer Tools oder Code Repository Systems ist längst keine rein technische Entscheidung mehr. Moderne Softwareentwicklung ist komplex, global verteilt und sicherheitskritisch. Unternehmen müssen daher Plattformen wählen, die nicht nur funktional überzeugen, sondern auch höchsten Anforderungen an Informationssicherheit, Compliance und strategische Zukunftsfähigkeit gerecht werden.

1. Funktionale Anforderungen: Die Basis für effiziente Entwicklung

Ein leistungsfähiges Developer Tool muss moderne Git Workflows unterstützen, flexible Code Review Prozesse ermöglichen und sich nahtlos in bestehende Toolchains integrieren. Besonders wichtig sind:

• Versionierung & Branching Modelle wie Git Flow oder trunk based Development

• Integrierte CI/CD Pipelines, die Builds und Deployments automatisieren

• Integrationen zu IDEs, Ticketing Systemen, Container Registries und Secrets Management

• Skalierbarkeit, um große Monorepos und tausende parallele Build Jobs zu bewältigen

• Betriebsmodell: Self Hosting für maximale Kontrolle oder SaaS für schnelle Skalierung

Diese Kriterien bestimmen, wie produktiv Teams arbeiten können und wie gut sich die Plattform in bestehende Entwicklungsprozesse einfügt.

2. Informationssicherheit: Der entscheidende Faktor

Da Source Code ein zentrales Unternehmensasset ist, stehen Sicherheitsanforderungen im Mittelpunkt. Moderne Plattformen müssen umfassende Schutzmechanismen bieten, darunter:

• Identity & Access Management mit SSO, SAML, SCIM, MFA und fein granularen RBAC Modellen

• Security Scanning wie SAST, SCA, DAST und IaC Analysen

• Supply Chain Security, etwa signierte Commits, SBOM Unterstützung und automatisierte Dependency Updates

• Audit & Compliance durch unveränderbare Logs und SIEM Anbindung

• Zero Trust Prinzipien wie Least Privilege, Branch Protection und verpflichtende Reviews

Diese Funktionen sind entscheidend, um Risiken wie Code Manipulation, Credential Leaks oder Supply Chain Angriffe zu minimieren.

3. Strategische Kriterien: Zukunftssicherheit und Unternehmensrisiken

Neben Funktionalität und Sicherheit spielen strategische Überlegungen eine immer größere Rolle:

• Datenhoheit: Dürfen Quellcodes in einer US Cloud liegen oder ist EU Hosting bzw. On Premise erforderlich

• Skalierbarkeit: Wie verhält sich das System bei extremen Lastspitzen

• Vendor Lock in: Wie einfach ist eine spätere Migration

• Erweiterbarkeit: Gibt es APIs und ein Plugin Ökosystem für interne Tools

Diese Faktoren entscheiden darüber, ob die Plattform langfristig tragfähig ist und sich an zukünftige Anforderungen anpassen lässt.

4. Kritische Sicherheitsfeatures: Must Haves für moderne DevSecOps

Einige Funktionen gelten heute als unverzichtbar:

• Fine grained RBAC für präzise Zugriffskontrolle

• Branch Protection zur Durchsetzung des Vier Augen Prinzips

• Secret Scanning zur Vermeidung von Credential Leaks

• Audit Logging für Compliance und forensische Analysen

• SCA & SAST für automatisierte Schwachstellenerkennung

• SAML/SSO & SCIM für zentrale Identitätsverwaltung

Diese Features bilden das Fundament einer sicheren und skalierbaren Entwicklungsumgebung.

Übersicht der Entscheidungskriterien für Developer Tools & Code Repositories, etwas detaillierter

1. Funktionale Kriterien

Versionierung & Branching-Modell

• Git Flow

• Trunk based Development

• Granulare Berechtigungen (fein abgestufte Zugriffsrechte)

Code Review Workflows

• PRs (Pull Requests)

• Merge Checks

• Reviewer Zuweisung

CI/CD Integration

• CI (Continuous Integration)

• CD (Continuous Delivery / Continuous Deployment)

• Nativ oder über Plugins

Integrationen

• IDE (Integrated Development Environment)

• Ticketing-Systeme

• Secrets Management

• Container Registry

Skalierbarkeit & Performance

• Große Monorepos

• LFS (Large File Storage)

• Verteilte Teams / globale Standorte

Betriebsmodell

• Self Hosting

• SaaS (Software as a Service)

• Compliance Anforderungen

• Kosten & Kontrolle

2. Informationssicherheitsrelevante Kriterien

Identity & Access Management

• SSO (Single Sign-On)

• SAML (Security Assertion Markup Language)

• SCIM (System for Cross-domain Identity Management)

• MFA (Multi-Factor Authentication)

• RBAC (Role-Based Access Control)

• Fein granulare Rechte

Security Scanning

• SAST (Static Application Security Testing)

• SCA (Software Composition Analysis)

• DAST (Dynamic Application Security Testing)

• Secret Scanning

• IaC Scanning (Infrastructure as Code Scanning)

Supply Chain Security

• Signierte Commits (GPG – GNU Privacy Guard / Sigstore)

• SBOM (Software Bill of Materials)

• Automatisierte Dependency Updates

Audit & Compliance

• Audit Logs

• Unveränderbare Logs (Immutable Logging)

• Exportfähigkeit

• SIEM Integration (Security Information and Event Management)

Data Governance

• Verschlüsselung at rest (Daten im Ruhezustand)

• Verschlüsselung in transit (Daten während der Übertragung)

• Geo Hosting

• Backup & Restore

Zero Trust Fähigkeiten

• Least Privilege (Minimalprinzip)

• Branch Protection

• Mandatory Reviews (erzwungene Vier Augen Prinzipien)

Betriebsmodell für regulierte Branchen

• On Prem (On-Premise) für Banking, Automotive, Defense

Security Hardening

• Secret Leak Prevention

• Automatisierte Fixes

• Policy as Code (Sicherheitsrichtlinien als Code)

3. Strategische Entscheidungskriterien

1. Sovereignty (Datenhoheit)

• Cloud vs. On Premise

• Dürfen Source Code Daten (IP = Intellectual Property) in einer US Cloud liegen

• Bedarf an EU Hosting oder eigenem Rechenzentrum

2. Scalability & Performance

• Verhalten bei 10.000+ parallelen Build Jobs

• Monorepos im Terabyte Bereich

• Build Pipeline Durchsatz

3. Vendor Lock in

• Aufwand einer Migration

• Risiken bei steigenden Lizenzkosten

• Export /Import Fähigkeiten

4. Extensibility

• API (Application Programming Interface)

• Plugin Ökosystem

• Integration interner Tools

4. Kritische Informationssicherheits Features (konkret & operativ)

Fine grained RBAC (Role-Based Access Control)

• Rollenbasierte Zugriffskontrolle bis auf Branch Ebene

Branch Protection

• Erzwungene Reviews

• Status Checks vor Merge

• Keine direkten Pushes auf kritische Branches

Secret Scanning

• Automatisches Blockieren von Commits mit Passwörtern, API Keys oder Tokens

Audit Logging

• Lückenlose, manipulationssichere Protokollierung

• SIEM Anbindung (Security Information and Event Management)

SCA & SAST Integration

• Automatisierte Schwachstellenscans in Bibliotheken (SCA)

• Statische Codeanalyse (SAST)

SAML/SSO & SCIM

• Zentrale Identitätsverwaltung

• Automatische De Provisionierung bei Mitarbeiter Austritt

Übersicht: IEC 62443 – Industrielle Cyber-Sicherheit

Fri, 27 Mar 2026 10:38:17 GMT

Übersicht: IEC 62443 – Industrielle Cyber-Sicherheit

IEC 62443 ist eine internationale Normenreihe für IT-Sicherheit in industriellen Automatisierungs- und Steuerungssystemen (Industrial Automation and Control Systems, IACS). Sie deckt die gesamte Lieferkette ab: Hersteller, Betreiber und Integratoren.

Ziel: Schutz von industriellen Anlagen vor Cyberangriffen, von der Produktentwicklung bis zum Betrieb.

1. Allgemeines / Rahmenwerke

• IEC 62443-1-x: Grundlagen und Konzepte

o 62443-1-1: Terminologie, Konzepte, Definitionen

o 62443-1-2: Abwehrmaßnahmen für die Unternehmensorganisation

o 62443-1-3: Systemrisiken, Risikomanagement-Ansatz

• Ziel: Verständnis der Bedrohungslandschaft, Risikoanalyse und Sicherheitsstrategie

2. Richtlinien für Betreiber (Operators)

• IEC 62443-2-x: Sicherheitsmanagement für Betreiber

o 62443-2-1: Anforderungen an das Sicherheitsmanagement-System (Cybersecurity Management System, CSMS)

o 62443-2-3: Spezifische Leitlinien für Betrieb und Wartung

• Ziel:

o Aufbau eines Cybersecurity Management Systems für industrielle Anlagen

o Regelmäßige Bewertung und Verbesserung der Sicherheit

3. Anforderungen an Systemintegratoren

• IEC 62443-3-x: Systemanforderungen

o 62443-3-2: Sicherheitsanforderungen für die Integration von Systemen

o 62443-3-3: Technische Sicherheitsanforderungen für IACS

• Ziel:

o Absicherung von Gesamtsystemen

o Festlegung von Sicherheitszielen für Steuerungssysteme (z. B. Zugriffskontrolle, Netzwerksegmentierung)

4. Anforderungen an Produkte / Komponenten

• IEC 62443-4-x: Produktentwickler

o 62443-4-1: Sicherheitsanforderungen für Produktentwicklung (Secure Development Lifecycle)

o 62443-4-2: Technische Anforderungen an Produkte (Security Level SL1–SL4)

• Ziel:

o Integration von Sicherheit bereits in der Entwicklung

o Definition von Sicherheitsstufen für Komponenten

5. Sicherheitslevel (Security Levels – SL)

• SL1–SL4: Abstufung nach Bedrohungsprofil und Schutzbedarf

o SL1: Schutz gegen zufällige oder unbewusste Gefahren

o SL2: Schutz gegen einfache absichtliche Angriffe

o SL3: Schutz gegen gezielte Angriffe durch versierte Gegner

o SL4: Schutz gegen hochqualifizierte, gezielte Angriffe

6. Kernelemente der IEC 62443

• Zonierung & Conduits: Segmentierung von Netzwerken in Sicherheitszonen

• Risikomanagement: Bewertung von Bedrohungen und Umsetzung von Controls

• Sicheres Design / Secure Development Lifecycle (SDL)

• Kontinuierliche Verbesserung: Überwachung, Audits, Incident Response

7. Praxisrelevanz

• Für Betreiber: Aufbau eines CSMS, Risikoanalyse, Auditfähigkeit

• Für Integratoren: Umsetzung technischer Sicherheitsanforderungen in Systemen

• Für Hersteller: Entwicklung sicherer Produkte mit Sicherheitsstufen SL1–SL4

Entscheidungskriterien für KI Nutzung

Fri, 27 Mar 2026 10:08:08 GMT

Entscheidungskriterien für KI Tools & KI Plattformen

Entscheidungskriterien für KI-Tools und KI-Plattformen (Ein risikobasierten „Enterprise-AI-Assessment)

Nicht das beste KI-Tool suchen – sondern das passende für den konkreten Anwendungsfall

Die Auswahl eines KI-Tools wirkt auf den ersten Blick einfach:

ChatGPT, Claude, Gemini, Copilot, Mistral, Llama – welches System ist das beste?

Für Unternehmen ist diese Frage allerdings zu kurz gedacht.

Denn bei der Einführung von KI geht es nicht nur um Modellqualität oder Benutzerfreundlichkeit. Entscheidend sind unter anderem Datenschutz, Informationssicherheit, Integration in die bestehende IT-Landschaft, Kosten, Skalierbarkeit, Governance, regulatorische Anforderungen und – zunehmend wichtig – die Sicherheit von KI-Agenten.

Die entscheidende Frage lautet deshalb nicht:

„Welches KI-Tool ist das beste?“

sondern:

„Welche KI-Plattform erfüllt unsere Anforderungen für den konkreten Anwendungsfall hinsichtlich Daten, Risiko, Sicherheit, Integration, Kosten und Governance?“

Das ist ein wesentlicher Perspektivwechsel.

Ein KI-Tool für die Erstellung eines Marketingtexts hat andere Anforderungen als ein KI-System, das auf interne Unternehmensdaten zugreift, Software entwickelt, Personalentscheidungen unterstützt oder selbstständig Aktionen in Unternehmenssystemen ausführt.

1. Datenschutz, Datenverarbeitung und Compliance

Bei der Auswahl eines KI-Dienstes sollte zunächst geklärt werden:

Welche Daten verlassen eigentlich unser Unternehmen – und was passiert anschließend damit?

Dabei reicht die Aussage „DSGVO-konform“ nicht aus.

Datenschutz- und Compliance-Anforderungen hängen immer vom konkreten Anwendungsfall, den verarbeiteten Daten, der Rechtsgrundlage, den Vertragsbedingungen, den beteiligten Dienstleistern und der technischen Umsetzung ab.

1.1 Datenresidenz und Datensouveränität

Zu prüfen sind beispielsweise:

Wo werden Eingaben verarbeitet?
Wo werden Prompts und Outputs gespeichert?
Wo befinden sich Backups?
Welche Regionen können Daten verarbeiten?
Welche Subdienstleister sind beteiligt?
Welche internationalen Datenübermittlungen finden statt?
Gibt es EU-, EWR- oder andere definierte Datenresidenzoptionen?
Welche technischen und vertraglichen Möglichkeiten bestehen für die Kontrolle der Daten?

Dabei sollte zwischen verschiedenen Begriffen unterschieden werden:

Datenresidenz ≠ Datensouveränität ≠ Datenschutz.

Ein Anbieter kann beispielsweise eine Verarbeitung in einer europäischen Region anbieten, während gleichzeitig weitere technische oder organisatorische Abhängigkeiten außerhalb Europas bestehen.

Für besonders schützenswerte Informationen kann deshalb eine weitergehende Bewertung erforderlich sein.

1.2 Kein Training mit Unternehmensdaten

Ein wichtiges Auswahlkriterium ist die Frage:

Werden unsere Eingaben und Ergebnisse zum Training oder zur Verbesserung von Modellen verwendet?

Hier sollten keine Marketingaussagen ausreichen. Entscheidend sind:

Vertragsbedingungen
Datenschutzvereinbarung
technische Dokumentation
Konfiguration
Produktvariante
konkrete API- oder Workspace-Nutzung

Bei verschiedenen Enterprise-Angeboten wird beispielsweise ausdrücklich zugesichert, dass Geschäftsdaten standardmäßig nicht zum Training verwendet werden. Auch OpenAI beschreibt dies für seine Business- und API-Angebote.

1.3 No Training ist nicht Zero Retention

Ein besonders wichtiger Unterschied:

„Kein Training“ bedeutet nicht automatisch „keine Speicherung“.

Ein Anbieter kann Daten nicht für das Training verwenden und sie trotzdem für einen bestimmten Zeitraum speichern.

Deshalb sollten mindestens drei Fragen getrennt betrachtet werden:

Frage

Bedeutung

Wird mit unseren Daten trainiert?

Nutzung der Daten zur Modellverbesserung

Wie lange werden Daten gespeichert?

Retention

Wo werden Daten verarbeitet/gespeichert?

Datenresidenz

Bei bestimmten API-Angeboten existieren inzwischen auch Zero-Data-Retention-Modelle. OpenAI beschreibt beispielsweise eine Zero-Data-Retention-Option für berechtigte API-Kunden.

Für die Bewertung zählt jedoch immer die konkrete Produktvariante und Konfiguration.

2. EU AI Act und regulatorische Anforderungen

Der EU AI Act macht aus der KI-Nutzung zunehmend eine Governance-Aufgabe.

Seit dem 2. August 2026 gelten unter anderem neue Transparenzanforderungen nach Art. 50. Dazu gehören beispielsweise Anforderungen an die Kennzeichnung bestimmter KI-generierter Inhalte und die Information von Personen, wenn sie direkt mit bestimmten KI-Systemen interagieren.

Bei der Auswahl eines Tools sollte deshalb nicht nur gefragt werden:

„Ist das Tool AI-Act-ready?“

Sondern:

Welche Rolle hat unser Unternehmen?
Sind wir Anbieter oder Betreiber eines KI-Systems?
Welche KI-Systeme und Modelle werden eingesetzt?
Welche Risikokategorie ist relevant?
Welche Transparenzanforderungen bestehen?
Welche Dokumentation wird benötigt?
Welche Anforderungen bestehen an menschliche Aufsicht?
Wie werden Änderungen am Modell behandelt?
Wie wird die KI-Nutzung überwacht?
Wie werden KI-Vorfälle behandelt?

Die regulatorische Bewertung ist deshalb nicht ausschließlich eine Eigenschaft des Tools .

Sie entsteht aus dem Zusammenspiel von:

Tool + Anwendungsfall + Daten + Organisation + Prozess + Nutzung.

3. Integration und Architektur

Ein KI-System ist selten eine isolierte Anwendung.

In Unternehmen soll KI beispielsweise mit

Microsoft 365
SAP
Salesforce
ServiceNow
Atlassian
CRM-Systemen
ERP-Systemen
Dokumentenmanagement
Entwicklungsumgebungen
Datenbanken
APIs
internen Wissensplattformen

zusammenarbeiten.

Damit wird die Frage der Architektur zentral.

3.1 API First

Ein professionelles KI-Angebot sollte geeignete Integrationsmöglichkeiten besitzen:

REST APIs
Graph APIs
Webhooks
SDKs
standardisierte Schnittstellen
Authentifizierung und Autorisierung
Monitoring
Rate Limiting

Dabei sollte nicht nur gefragt werden:

„Gibt es eine API?“

Sondern:

„Kann die API sicher und kontrolliert in unsere Unternehmensarchitektur integriert werden?“

4. Identität und Berechtigungen

Dieser Punkt wird bei KI-Systemen häufig unterschätzt.

Eine KI darf nicht plötzlich mehr sehen oder mehr tun dürfen als der Benutzer, in dessen Kontext sie arbeitet.

Besonders bei RAG-Systemen und KI-Agenten ist deshalb eine saubere Berechtigungsarchitektur erforderlich.

Zu prüfen sind beispielsweise:

Integration mit Entra ID / IAM
Single Sign-on
RBAC / ABAC
Benutzerkontext
Service Accounts
Service Principals
Delegated Access
Least Privilege
Rollen für KI-Agenten
Trennung von Benutzer- und Maschinenidentitäten
Rechte auf Datenquellen
Rechte auf Tools und APIs

Ein wichtiger Grundsatz lautet:

Die KI sollte grundsätzlich keine Berechtigungen erhalten, die der zugrunde liegende Benutzer oder Prozess nicht benötigt.

5. RAG – Unternehmenswissen statt Model Training

Retrieval Augmented Generation, kurz RAG , ist inzwischen ein wichtiger Baustein vieler Enterprise-AI-Architekturen.

Dabei wird ein Sprachmodell nicht unbedingt mit den Unternehmensdaten neu trainiert. Stattdessen werden relevante Informationen zur Laufzeit aus einer Wissensbasis abgerufen und dem Modell als Kontext zur Verfügung gestellt.

Das ist praktisch – aber keineswegs automatisch sicher.

Bei RAG sollte unter anderem geprüft werden:

Welche Dokumente werden aufgenommen?
Wer darf Dokumente einstellen?
Wer darf sie ändern?
Welche Benutzer dürfen sie lesen?
Wie werden Berechtigungen aus dem Quellsystem übernommen?
Wie schnell werden Änderungen übernommen?
Wie werden veraltete Informationen erkannt?
Wie wird die Qualität der Treffer getestet?
Werden Quellen im Ergebnis angezeigt?
Wie wird mit widersprüchlichen Informationen umgegangen?
Wie werden Prompt-Injection-Angriffe in Dokumenten verhindert?
Wie werden Embeddings geschützt?
Wer darf die Wissensbasis administrieren?

Besonders wichtig:

Eine RAG-Lösung ist nur dann wirklich Enterprise-tauglich, wenn auch die Berechtigungslogik der zugrunde liegenden Informationsquellen berücksichtigt wird.

6. Modellagnostik und Vendor Lock-in

Viele Unternehmen wollen heute nicht mehr von einem einzigen Modellanbieter abhängig sein.

Das kann strategische Gründe haben:

unterschiedliche Modellqualitäten
unterschiedliche Preise
unterschiedliche Datenschutzanforderungen
unterschiedliche Regionen
Performance
Verfügbarkeit
regulatorische Anforderungen
technologische Entwicklung

Eine modellagnostische Architektur kann deshalb Vorteile bieten.

Beispielsweise könnte eine Anwendung abhängig vom Anwendungsfall unterschiedliche Modelle verwenden:

Standardaufgabe → günstiges Modell

komplexe Analyse → leistungsfähigeres Modell

sensible Daten → bestimmtes Deployment

Ausfall → alternatives Modell

Modellagnostik reduziert allerdings nicht automatisch den Vendor Lock-in.

Auch die darüberliegende Plattform, RAG-Architektur, Agent-Frameworks und proprietäre APIs können Abhängigkeiten erzeugen.

Deshalb sollte die Frage lauten:

Wo entstehen in unserer AI-Architektur Abhängigkeiten – und wie können wir sie kontrollieren?

7. Total Cost of Ownership – nicht nur Tokenpreise betrachten

Die Kosten eines KI-Systems bestehen selten nur aus den Kosten für Tokens oder Benutzerlizenzen.

Zu berücksichtigen sind beispielsweise:

Lizenzkosten
Tokenkosten
API-Kosten
Infrastruktur
GPU-Kosten
RAG-Infrastruktur
Vektordatenbanken
Datenaufbereitung
Schnittstellen
Monitoring
Security
Governance
Tests
Schulungen
Administration
Support
Integration
Migration
laufende Modellbewertung

Bei Agenten können zusätzliche Kosten entstehen, weil ein einzelner Benutzerauftrag mehrere Modellaufrufe, Datenbankzugriffe oder Tool-Aufrufe auslösen kann.

Deshalb sollte ein Unternehmen nicht nur fragen:

„Was kostet eine Anfrage?“

sondern:

„Was kostet der gesamte Geschäftsprozess mit KI?“

8. Skalierbarkeit und Performance

Ein System, das mit zehn Benutzern funktioniert, muss nicht automatisch für 10.000 Benutzer geeignet sein.

Zu prüfen sind beispielsweise:

maximale Benutzerzahl
gleichzeitige Anfragen
API Rate Limits
Token Limits
Kontextgrößen
Antwortzeiten
regionale Latenz
Verfügbarkeit
Skalierungsmechanismen
Mandantenfähigkeit
Lastverhalten
Failover

Gerade bei produktiven KI-Anwendungen sollte Performance nicht nur anhand von Herstellerangaben bewertet werden.

Ein Proof of Concept mit realistischen Last- und Nutzungsszenarien liefert häufig wesentlich bessere Erkenntnisse.

9. Enterprise Security

KI bringt klassische Informationssicherheitsanforderungen mit neuen Angriffsmöglichkeiten zusammen.

Dabei sollte zwischen mindestens zwei Bereichen unterschieden werden:

LLM Security

Beispiele:

Prompt Injection
Indirect Prompt Injection
Jailbreaks
Sensitive Information Disclosure
Data Leakage
Model Manipulation
Data Poisoning
Insecure Output Handling
Supply-Chain-Risiken
Unbounded Consumption

Agent Security

Bei autonomen oder teilautonomen Agenten kommen zusätzliche Risiken hinzu:

Excessive Agency
übermäßige Berechtigungen
Missbrauch von Tools
Manipulation von Agentenzielen
Zugriff auf nicht vorgesehene APIs
Aktionen ohne menschliche Freigabe
Agent-to-Agent-Kommunikation
Identitätsmissbrauch
unkontrollierte Folgeaktionen

Damit verändert sich das klassische Sicherheitsmodell.

Ein Chatbot erzeugt möglicherweise nur eine Antwort.

Ein Agent kann dagegen:

lesen → entscheiden → API aufrufen → Daten verändern → weitere Aktionen auslösen.

Die Sicherheitsanforderungen sind entsprechend höher.

10. Guardrails und Policy Enforcement

Ein Enterprise-KI-System sollte nicht ausschließlich auf das Modell selbst vertrauen.

Zusätzliche Kontrollmechanismen können beispielsweise festlegen:

Welche Daten dürfen eingegeben werden?
Welche Inhalte dürfen verarbeitet werden?
Welche Modelle dürfen verwendet werden?
Welche Benutzer dürfen welche Modelle verwenden?
Welche Tools darf ein Agent verwenden?
Welche Aktionen benötigen eine Freigabe?
Welche Informationen dürfen das Unternehmen verlassen?
Welche Antworten müssen geprüft werden?

Guardrails können damit eine technische Umsetzung von Unternehmensrichtlinien unterstützen.

Sie ersetzen jedoch keine Governance .

11. Auditierbarkeit und Nachvollziehbarkeit

„Explainable AI“ wird häufig so verstanden, als müsse das Unternehmen die vollständige interne Entscheidungslogik eines großen Sprachmodells nachvollziehen können.

Das ist in der Praxis nicht immer realistisch.

Für Enterprise-Anwendungen ist deshalb häufig ein anderer Ansatz sinnvoll:

Traceability statt vollständiger Modelltransparenz

Nachvollziehbar sollten beispielsweise sein:

Benutzer
Zeitpunkt
verwendetes Modell
Modellversion
Prompt bzw. relevante Eingabeinformationen
verwendete Datenquellen
RAG-Dokumente
Tool-Aufrufe
ausgeführte Aktionen
Guardrails
Freigaben
Ergebnis
Fehler
Sicherheitsereignisse

Damit entsteht ein nachvollziehbarer AI Audit Trail .

Dabei muss allerdings auch das Logging selbst datenschutz- und sicherheitskonform gestaltet werden.

„Alles loggen“ ist daher nicht automatisch die richtige Lösung.

12. AI Governance und Lifecycle Management

Hier liegt aus meiner Sicht eine der wichtigsten Erweiterungen klassischer KI-Tool-Auswahlverfahren.

Ein KI-System ist kein einmal angeschafftes Softwareprodukt.
Modelle verändern sich.
Prompts verändern sich.
RAG-Daten verändern sich.
Benutzer verändern ihre Nutzung.
Agenten erhalten neue Tools.
Anbieter ändern Preise, Modelle und Funktionen.
Deshalb braucht KI einen eigenen Lifecycle.

Ein möglicher Ablauf:

Idee → Bewertung → Freigabe → Implementierung → Test → Betrieb → Monitoring → Änderung → Re-Evaluierung → Ablösung

Dazu gehören unter anderem:

AI Inventory
Use-Case-Beschreibung
Risikobewertung
Klassifizierung
Verantwortlichkeiten
Freigabeprozess
Modellmanagement
Datenmanagement
Testmanagement
Monitoring
Incident Management
Change Management
Lieferantenmanagement
regelmäßige Reviews
Exit-Strategie

Hier lässt sich KI-Governance sehr gut mit bestehenden Managementsystemen verbinden, beispielsweise mit ISO/IEC 27001 und ISO/IEC 42001 .

13. AI Inventory – wissen, wo KI eingesetzt wird

Eine überraschend einfache Frage ist:

Welche KI-Systeme werden in unserem Unternehmen überhaupt eingesetzt?

Die Antwort ist in vielen Unternehmen nicht vollständig bekannt.

Neben offiziell eingeführten Anwendungen existieren häufig:

private ChatGPT-Nutzung
Copilot-Nutzung
Browser-Plugins
KI-Funktionen in SaaS-Anwendungen
Entwicklerwerkzeuge
KI-gestützte Meeting-Tools
automatische Übersetzung
OCR und Dokumentenanalyse
RAG-Systeme
eigene KI-Anwendungen
Agenten

Ein AI Inventory sollte deshalb beispielsweise enthalten:

KI-System: internes RAG-System
Anbieter: Anbieter X
Modell: Modell Y
Zweck: Wissenssuche
Benutzer: Mitarbeiter
Daten: interne Dokumente
Kritikalität: hoch
Risiko: mittel
Verantwortlicher: Fachbereich
Freigabe: Management
Rechtsgrundlage: geprüft
letzte Bewertung: Datum
nächste Review: Datum

Damit wird aus einer unübersichtlichen Tool-Landschaft eine steuerbare Umgebung.

14. AI Literacy und Benutzerkompetenz

Technologie allein reicht nicht.

Mitarbeiter müssen verstehen:

Was kann das System?
Was kann es nicht?
Welche Daten dürfen eingegeben werden?
Wie zuverlässig sind Ergebnisse?
Wann muss ein Mensch prüfen?
Wie werden Fehler erkannt?
Wie werden KI-generierte Inhalte gekennzeichnet?
Welche Unternehmensregeln gelten?

Gerade bei generativer KI ist ein Grundsatz entscheidend:

Eine überzeugend formulierte Antwort ist nicht automatisch eine richtige Antwort.

AI Literacy sollte deshalb nicht nur eine einmalige Schulung sein, sondern Bestandteil des laufenden AI-Governance-Programms.

15. Lieferanten- und Ökosystemmanagement

Eine KI-Plattform besteht häufig nicht nur aus einem Anbieter.

Dahinter können stehen:

Unternehmen → AI-Plattform → Gateway → Modellanbieter → Cloud Provider → RAG → Datenbank → Plugin → API → weitere Dienstleister

Damit entsteht eine komplexe Lieferkette.

Zu bewerten sind beispielsweise:

Subdienstleister
Cloud Provider
Modellanbieter
Datenverarbeitung
Sicherheitsnachweise
Zertifizierungen
SLA
Support
Incident Management
Änderungsmanagement
Auditrechte
Exit-Möglichkeiten
Datenexport
Löschung
Portabilität

16. Support, Skills und Ökosystem

Eine technisch hervorragende Plattform kann trotzdem ungeeignet sein, wenn sie intern nicht betrieben werden kann.

Deshalb sollten auch folgende Fragen gestellt werden:

Welche Fähigkeiten benötigen wir intern?
Gibt es Low-Code-/No-Code-Möglichkeiten?
Wie hoch ist der Administrationsaufwand?
Wie groß ist das Ökosystem?
Gibt es Integrationen?
Gibt es verfügbare Spezialisten?
Wie gut ist die Dokumentation?
Wie schnell entwickelt sich die Plattform?
Wie belastbar ist der Support?
Welche SLA werden angeboten?

Hier sollte auch zwischen Innovation und Betriebsstabilität unterschieden werden.

Ein Startup kann sehr schnell innovative Funktionen liefern.

Ein etablierter Anbieter kann andere Vorteile bei Support, Compliance und langfristiger Verfügbarkeit bieten.

Die Bewertung sollte deshalb zum jeweiligen Risiko und Anwendungsfall passen.

17. Die strategische Architektur: AI Gateway

Mit zunehmender Nutzung verschiedener KI-Modelle entsteht eine weitere Architekturfrage:

Wie verhindern wir, dass jede Anwendung direkt mit einem anderen Modellanbieter verbunden ist?

Eine mögliche Antwort ist eine zentrale AI-Gateway-Schicht .

Vereinfacht:

Unternehmensanwendung

↓

AI Gateway

↓

GPT / Claude / Gemini / Mistral / Llama / weitere Modelle

Das Gateway kann als zentrale Vermittlungsschicht dienen.

Beispiele für Funktionen können sein:

einheitliche API
Modell-Routing
Fallback
Rate Limiting
Kostenkontrolle
Authentifizierung
Logging
Monitoring
Guardrails
zentrale Policies
Modellwechsel

Ein Beispiel für einen solchen technischen Ansatz ist LiteLLM. Die aktuelle Dokumentation beschreibt unter anderem eine einheitliche Schnittstelle für mehr als 100 LLMs, Routing und Fallback, Kosten-/Budgetsteuerung sowie zentrale Authentifizierungs-, Logging- und Monitoring-Funktionen.

18. AI Gateway ist aber kein Allheilmittel

Ein AI Gateway kann ein wichtiger Baustein einer Enterprise-AI-Architektur sein.

Es ersetzt jedoch nicht:

IAM
Datenschutz
Informationsklassifizierung
RAG-Berechtigungen
AI Governance
Risikomanagement
sichere Softwareentwicklung
Agenten-Governance
Lieferantenmanagement
Business Continuity
regulatorische Bewertung

Insbesondere bei Agenten muss die Architektur weiter gedacht werden.

Ein mögliches Zielbild:

Benutzer

↓

AI-Anwendung

↓

AI Gateway

↓

Modell

↙︎ ↘︎

RAG Tools / APIs

↓ ↓

Wissensbasis Unternehmenssysteme

Dabei müssen insbesondere Identität, Berechtigungen, Policies, Logging und Freigaben durchgängig berücksichtigt werden.

19. Was sollte ein Unternehmen konkret bewerten?

Aus den genannten Punkten lässt sich eine praktische Bewertungsmatrix entwickeln.

Dimension

Typische Prüffragen

Datenschutz: Wo werden Daten verarbeitet?
Datenverwendung: Werden Daten gespeichert oder zum Training verwendet?
Compliance: Welche regulatorischen Anforderungen sind relevant?
Sicherheit: Wie werden Daten, Zugänge und Schnittstellen geschützt?
LLM Security: Wie werden Prompt Injection und Data Leakage behandelt?
Agent Security: Welche Aktionen darf ein Agent ausführen?
IAM: Werden bestehende Benutzerrechte berücksichtigt?
Architektur: Wie gut lässt sich die Lösung integrieren?
RAG: Wie werden Datenquellen und Berechtigungen umgesetzt?
Modellstrategie: Wie stark ist die Abhängigkeit von einem Modellanbieter?
TCO: Welche Gesamtkosten entstehen?
Skalierbarkeit: Wie verhält sich die Lösung bei steigender Nutzung?
Governance: Wie werden KI-Systeme freigegeben und überwacht?
Lifecycle: Wie werden Änderungen und neue Modellversionen behandelt?
Monitoring: Welche Logs, Metriken und Alarme gibt es?
Lieferanten: Wie werden Anbieter und Subdienstleister bewertet?
Exit: Wie können Daten, Konfiguration und Anwendungen migriert werden?
Kompetenz: Welche Fähigkeiten benötigen die Mitarbeiter?

20. Ein einfaches Bewertungsmodell

Für die Praxis muss eine solche Bewertung nicht kompliziert sein.

Ein Unternehmen kann beispielsweise für jeden Use Case fünf grundlegende Fragen beantworten:

1. Daten

Welche Daten werden verarbeitet und wie sensibel sind sie?

2. Risiko

Was passiert, wenn die KI einen Fehler macht?

3. Zugriff

Welche Informationen darf die KI lesen und welche Aktionen darf sie ausführen?

4. Abhängigkeit

Wie stark machen wir uns von Anbieter, Modell oder Plattform abhängig?

5. Governance

Wie können wir die Nutzung kontrollieren, überwachen und bei Bedarf wieder abschalten?

Je höher das Risiko eines Anwendungsfalls, desto detaillierter sollte die Bewertung erfolgen.

21. Von der Tool-Auswahl zum AI Assessment

Damit verändert sich auch der Auswahlprozess.

Nicht:

Tool A vs. Tool B vs. Tool C

sondern:

Schritt 1 – Use Case definieren

Was soll die KI konkret leisten?

Schritt 2 – Daten bestimmen

Welche Informationen werden verarbeitet?

Schritt 3 – Risiko bewerten

Was passiert bei falschen Ergebnissen oder Fehlfunktionen?

Schritt 4 – regulatorische Anforderungen bestimmen

Welche Anforderungen ergeben sich beispielsweise aus AI Act, DSGVO oder branchenspezifischen Vorgaben?

Schritt 5 – Architektur definieren

Wie werden KI, RAG, IAM, APIs und Unternehmenssysteme verbunden?

Schritt 6 – Anbieter bewerten

Welche Plattform erfüllt die Anforderungen?

Schritt 7 – Proof of Concept

Funktioniert die Lösung mit realistischen Daten und Prozessen?

Schritt 8 – Security & Compliance Assessment

Sind die technischen und organisatorischen Anforderungen erfüllt?

Schritt 9 – Freigabe

Wer trägt die Verantwortung für die Einführung?

Schritt 10 – Betrieb und Monitoring

Wie wird die KI dauerhaft überwacht und weiterentwickelt?

22. Fazit

Die Auswahl einer KI-Plattform ist heute keine reine Technologieentscheidung mehr.

Sie betrifft:

Daten + Sicherheit + Architektur + Kosten + Prozesse + Menschen + Governance + Regulierung.

Besonders bei generativer KI und KI-Agenten wird dieser Zusammenhang immer wichtiger.

Ein Unternehmen sollte deshalb nicht fragen:

„Welche KI ist die beste?“

Sondern:

„Welche KI-Lösung ist für diesen konkreten Anwendungsfall unter unseren technischen, organisatorischen, wirtschaftlichen und regulatorischen Rahmenbedingungen geeignet?“

Das führt zu einer anderen Art der KI-Auswahl:

Nicht technologiegetrieben, sondern anwendungs- und risikobasiert.

Und genau hier entsteht die Verbindung zu etablierten Managementsystemen.

AI Governance kann beispielsweise in ein bestehendes Informationssicherheitsmanagement nach ISO/IEC 27001 integriert werden. Für ein umfassenderes AI Management System bietet sich ISO/IEC 42001 an.

Die eigentliche Herausforderung besteht damit nicht darin, möglichst schnell möglichst viele KI-Tools einzuführen.

Die Herausforderung besteht darin, KI so in die Organisation zu integrieren, dass ihr Nutzen entsteht, ohne dass Sicherheit, Datenschutz, Compliance, Kontrolle und Verantwortlichkeit auf der Strecke bleiben.

Praxis statt PowerPoint gilt damit auch für KI:

Nicht die Anzahl der eingesetzten KI-Tools entscheidet über den Erfolg.

Entscheidend ist, ob KI kontrolliert, sicher und sinnvoll in die bestehenden Prozesse integriert wird.

Tools für Informationssicherheit EDR, XDR, SIEM, SOAR

Fri, 27 Mar 2026 09:36:47 GMT

EDR vs. XDR vs. SIEM vs. SOAR – Die wichtigsten Unterschiede

Kurzfassung der Kategorien und Begriffe

EDR = Endpoint Detection & Response → Schutz & Analyse auf Endpoints (Windows, macOS, Linux, Server)
XDR = Extended Detection & Response → Korrelation von Endpoint + Identity + Cloud + Network + Email → Eine Plattform, die mehrere Security Datenquellen zusammenführt
SIEM = Security Information & Event Management → Zentrale Log Sammelstelle + Korrelation + Compliance → Fundament für ein SOC (Security Operations Center)
SOAR = Automatisierung + Orchestrierung + Incident Response Playbooks, Ziel Alerts reduzieren, Reaktionszeiten verkürzen, SOC Teams entlasten

1. EDR – Endpoint Detection & Response

Was ist EDR? EDR überwacht Endgeräte (Clients, Server) in Echtzeit und erkennt Angriffe anhand von Verhalten, Telemetrie und Prozessketten.

Was kann EDR?

• Prozessüberwachung

• Malware Erkennung

• Ransomware Schutz

• Endpoint Forensik

• Isolierung von Endpoints

• Automatisierte Reaktionen (Kill Process, Quarantine File)

Wofür ist EDR ideal?

• Schutz vor Ransomware

• Erkennung von Zero Day Angriffen

• Forensik auf Endpoints

• SOC Teams, die Endpoint Angriffe analysieren müssen

Limitierung

EDR sieht nur Endpoints — keine Cloud Angriffe, keine Identitätsangriffe, keine Netzwerk Anomalien.

2. XDR – Extended Detection & Response

Was ist XDR? XDR erweitert EDR um zusätzliche Datenquellen:

• Endpoint

• Identity (AD, Entra ID, Okta)

• Cloud (AWS, Azure, GCP)

• Email (M365, Google Workspace)

• Netzwerk

• SaaS Apps

Was macht XDR besonders? XDR korreliert Daten über mehrere Security Domänen hinweg.

Beispiel: Ein kompromittierter Endpoint + verdächtige Entra ID Anmeldung + ungewöhnlicher API Call in Azure → 1 Incident, nicht 3 getrennte Alerts.

Wofür ist XDR ideal?

• Moderne Cloud Umgebungen

• Identity basierte Angriffe

• Ransomware Kill Chains

• Konsolidierung von Security Tools

• SOC Teams, die weniger Alerts wollen

Limitierung

XDR ist plattformgebunden (z. B. Microsoft, CrowdStrike, Palo Alto). Es ist kein vollständiger Ersatz für ein SIEM.

3. SIEM – Security Information & Event Management

Was ist SIEM? Ein SIEM sammelt alle Logs aus der gesamten IT Landschaft:

• Firewalls

• Identity Provider

• Server

• Cloud Dienste

• Applikationen

• Datenbanken

• EDR/XDR Tools

• Netzwerkgeräte

Was kann ein SIEM?

• Zentrale Log Aggregation

• Korrelation von Events

• Compliance Reporting (ISO 27001, SOC2, PCI DSS, BSI)

• Langzeit Retention

• Forensik

• SOC Dashboards

Wofür ist SIEM ideal?

• Große Unternehmen mit SOC

• Compliance Anforderungen

• Forensik & Incident Response

• Multi Cloud /Hybrid Umgebungen

Limitierung

• Teuer (v. a. Log Ingest)

• Hoher Betriebsaufwand

• Erfordert Experten (SIEM Engineers, SOC Analysten)

4. SOAR – Security Orchestration, Automation & Response

Was kann SOAR konkret? Automatisierte Incident Response

• Endpoint isolieren

• Firewall Regeln setzen

• Benutzerkonto deaktivieren

• Forensik Daten sammeln

• Alerts deduplizieren

Playbook Engine

• Visuelle Workflows

• Bedingte Logik

• API basierte Aktionen

• Mensch im Loop (Approval Steps)

Alert Reduktion

• Automatische Triage

• False Positive Filter

• Enrichment (Threat Intel, GeoIP, Sandbox)

SOC Effizienz

• Weniger manuelle Tickets

• Schnellere Reaktionszeiten

• Standardisierte Prozesse

• Weniger Analysten Burnout

Wofür ist SOAR ideal?

• Unternehmen mit SOC Teams

• Organisationen mit hohem Alert Volumen

• Multi Tool Landschaften (EDR + SIEM + Cloud + Identity)

• Konzerne mit Compliance Pflichten

• Security Teams, die Automatisierung brauchen

Grenzen von SOAR

• Kein Ersatz für SIEM oder XDR

• Benötigt gute Datenqualität (Garbage in → Garbage out)

• Playbooks müssen gepflegt werden

• Einführung erfordert Prozess Reife

Entscheidungskriterien / Bewertungskriterien für Pen Test Tools & Angebote

Fri, 27 Mar 2026 08:08:49 GMT

Entscheidungskriterien / Bewertungskriterien für Pen Test Tools & Angebote

1.Technische & funktionale Kriterien

Abdeckungsgrad (Coverage ) Wie gut deckt das Tool moderne IT Landschaften ab?

• Cloud native Workloads (AWS, Azure, GCP)

• APIs (REST, GraphQL, SOAP)

• Microservices / Container / Kubernetes

• Active Directory & Entra ID

• Mobile Apps (iOS/Android)

• OT/ICS (falls relevant)

Warum wichtig: Tools mit geringer Coverage erzeugen Blind Spots und erhöhen das Risiko unentdeckter Schwachstellen.

Tiefe der Analyse

• Reconnaissance

• Schwachstellenscans

• Exploitation

• Post Exploitation

• Lateral Movement

• Reporting

Warum wichtig: Manche Tools sind reine Scanner, andere unterstützen vollständige Angriffsketten.

Automatisierung & Skalierbarkeit

• API Zugriff

• CI/CD Integration

• Scheduling

• Mandantenfähigkeit

• Massen Scans

Warum wichtig: Große Organisationen benötigen wiederholbare, skalierbare Prozesse.

False Positive Rate

• Wie hoch ist der Rauschanteil?

• Wie viel manueller Aufwand entsteht durch Validierung?

• Gibt es Mechanismen zur FP Reduktion (ML, heuristische Filter)?

Warum wichtig: Ein günstiges Tool mit 300 False Positives pro Scan ist teurer als ein Premium Tool mit 5 echten Findings.

DevSecOps Integration

• Jira, Azure DevOps, ServiceNow

• SIEM Systeme (Splunk, Sentinel, QRadar)

• Vulnerability Management (Tenable, Qualys, Rapid7)

• Ticket Automatisierung

Warum wichtig: Findings müssen in den Engineering Workflow, nicht in PDF Ordner.

Actionability (Remediation Guidance)

• Priorisierte Findings

• Klare technische Fix Anleitungen

• CVSS Bewertung

• Exploit Verfügbarkeit

• Business Impact

Warum wichtig: Ein Finding ohne Handlungsempfehlung ist wertlos.

Reporting & Nachvollziehbarkeit

• PDF, JSON, CSV

• Mapping auf CVSS, CWE, OWASP Top 10

• Historie & Trendanalysen

• Mandantenfähigkeit

2. Sicherheits- & Compliance Kriterien

Identity & Access Management

• SSO / SAML

• SCIM

• MFA

• RBAC

• Audit Logs

Compliance Mapping Automatische Zuordnung der Findings z.B.:

• BSI IT Grundschutz

• ISO/IEC 27001

• SOC 2

• PCI DSS

• NIST 800 53

• CIS Benchmarks

Warum wichtig: Erleichtert Audits, reduziert manuellen Aufwand und verbessert Governance.

Datenhaltung & Datenschutz

• On Prem vs. SaaS

• Datenresidenz (EU, CH, US)

• Verschlüsselung at rest / in transit

• Log Retention

Update Zyklus & Exploit Datenbank

• Wie schnell werden neue CVEs eingepflegt?

• Wie groß ist die Exploit Bibliothek?

• Wie aktiv ist die Community / der Vendor?

3. Strategische & kommerzielle Kriterien

Lizenzmodell & TCO

• Per Asset

• Per Scan

• Per User

• Subscription vs. Perpetual

• Kosten für große Umgebungen

Vendor Lock in

• Offene APIs

• Exportformate

• Proprietäre Datenbanken?

Erweiterbarkeit & Ökosystem

• Plugin System

• API Reife

• Integration interner Tools

Skill Level & Usability

• GUI vs. CLI

• Eignung für interne Teams vs. Red Teams

• Lernkurve

Marktübersicht Pen Test Tools

Wichtige Entscheidungskriterien für Developer Tools & Code Repositories

Fri, 27 Mar 2026 06:59:13 GMT

Wichtige Entscheidungskriterien für Developer Tools & Code Repositories

1. Funktionale Anforderungen: Die Basis für effiziente Entwicklung

Versionierung & Branching Modelle wie Git Flow oder trunk based Development
Integrierte CI/CD Pipelines, die Builds und Deployments automatisieren
Integrationen zu IDEs, Ticketing Systemen, Container Registries und Secrets Management
Skalierbarkeit, um große Monorepos und tausende parallele Build Jobs zu bewältigen
Betriebsmodell: Self Hosting für maximale Kontrolle oder SaaS für schnelle Skalierung
Diese Kriterien bestimmen, wie produktiv Teams arbeiten können und wie gut sich die Plattform in bestehende Entwicklungsprozesse einfügt.

2. Informationssicherheit: Der entscheidende Faktor

Da Source Code ein zentrales Unternehmensasset ist, stehen Sicherheitsanforderungen im Mittelpunkt. Moderne Plattformen müssen umfassende Schutzmechanismen bieten, darunter:

Identity & Access Management mit SSO, SAML, SCIM, MFA und fein granularen RBAC Modellen
Security Scanning wie SAST, SCA, DAST und IaC Analysen
Supply Chain Security, etwa signierte Commits, SBOM Unterstützung und automatisierte Dependency Updates
Audit & Compliance durch unveränderbare Logs und SIEM Anbindung
Zero Trust Prinzipien wie Least Privilege, Branch Protection und verpflichtende Reviews

Diese Funktionen sind entscheidend, um Risiken wie Code Manipulation, Credential Leaks oder Supply Chain Angriffe zu minimieren.

3. Strategische Kriterien: Zukunftssicherheit und Unternehmensrisiken

Neben Funktionalität und Sicherheit spielen strategische Überlegungen eine immer größere Rolle:

• Datenhoheit: Dürfen Quellcodes in einer US Cloud liegen oder ist EU Hosting bzw. On Premise erforderlich

• Skalierbarkeit: Wie verhält sich das System bei extremen Lastspitzen

• Vendor Lock in: Wie einfach ist eine spätere Migration in ein anderes System (Exit Strategie)

• Erweiterbarkeit: Gibt es APIs und ein Plugin Ökosystem für interne Tools

Diese Faktoren entscheiden darüber, ob die Plattform langfristig tragfähig ist und sich an zukünftige Anforderungen anpassen lässt.

4. Kritische Sicherheitsfeatures: Must Haves für moderne DevSecOps

Einige Funktionen gelten heute als unverzichtbar:

Fine grained RBAC für präzise Zugriffskontrolle (Role-Based Access Control)
Branch Protection zur Durchsetzung des Vier Augen Prinzips
Secret Scanning zur Vermeidung von Credential Leaks
Audit Logging für Compliance und forensische Analysen
SCA & SAST für automatisierte Schwachstellenerkennung (Software Composition Analysis, Static Application Security Testing)
SAML/SSO & SCIM für zentrale Identitätsverwaltung (Security Assertion Markup Language)

Diese Features bilden das Fundament einer sicheren und skalierbaren Entwicklungsumgebung.

Übersicht der Entscheidungskriterien für Developer Tools & Code Repositories, etwas detaillierter

1. Funktionale Kriterien

Versionierung & Branching-Modell

• Git Flow

• Trunk based Development

• Granulare Berechtigungen (fein abgestufte Zugriffsrechte)

Code Review Workflows

• PRs (Pull Requests)

• Merge Checks

• Reviewer Zuweisung

CI/CD Integration

• CI (Continuous Integration)

• CD (Continuous Delivery / Continuous Deployment)

• Nativ oder über Plugins

Integrationen

• IDE (Integrated Development Environment)

• Ticketing-Systeme

• Secrets Management

• Container Registry

Skalierbarkeit & Performance

• Große Monorepos

• LFS (Large File Storage)

• Verteilte Teams / globale Standorte

Betriebsmodell

• Self Hosting

• SaaS (Software as a Service)

• Compliance Anforderungen

• Kosten & Kontrolle

2. Informationssicherheitsrelevante Kriterien

Identity & Access Management

• SSO (Single Sign-On)

• SAML (Security Assertion Markup Language)

• SCIM (System for Cross-domain Identity Management)

• MFA (Multi-Factor Authentication)

• RBAC (Role-Based Access Control)

• Fein granulare Rechte

Security Scanning

• SAST (Static Application Security Testing)

• SCA (Software Composition Analysis)

• DAST (Dynamic Application Security Testing)

• Secret Scanning

• IaC Scanning (Infrastructure as Code Scanning)

Supply Chain Security

• Signierte Commits (GPG – GNU Privacy Guard / Sigstore)

• SBOM (Software Bill of Materials)

• Automatisierte Dependency Updates

Audit & Compliance

• Audit Logs

• Unveränderbare Logs (Immutable Logging)

• Exportfähigkeit

• SIEM Integration (Security Information and Event Management)

Data Governance

• Verschlüsselung at rest (Daten im Ruhezustand)

• Verschlüsselung in transit (Daten während der Übertragung)

• Geo Hosting

• Backup & Restore

Zero Trust Fähigkeiten

• Least Privilege (Minimalprinzip)

• Branch Protection

• Mandatory Reviews (erzwungene Vier Augen Prinzipien)

Betriebsmodell für regulierte Branchen

• On Prem (On-Premise) für Banking, Automotive, Defense

Security Hardening

• Secret Leak Prevention

• Automatisierte Fixes

• Policy as Code (Sicherheitsrichtlinien als Code)

3. Strategische Entscheidungskriterien

1. Sovereignty (Datenhoheit)

• Cloud vs. On Premise

• Dürfen Source Code Daten (IP = Intellectual Property) in einer US Cloud liegen

• Bedarf an EU Hosting oder eigenem Rechenzentrum

2. Scalability & Performance

• Verhalten bei 10.000+ parallelen Build Jobs

• Monorepos im Terabyte Bereich

• Build Pipeline Durchsatz

3. Vendor Lock in

• Aufwand einer Migration

• Risiken bei steigenden Lizenzkosten

• Export /Import Fähigkeiten

4. Extensibility

• API (Application Programming Interface)

• Plugin Ökosystem

• Integration interner Tools

4. Kritische Informationssicherheits Features (konkret & operativ)

Fine grained RBAC (Role-Based Access Control)

• Rollenbasierte Zugriffskontrolle bis auf Branch Ebene

Branch Protection

• Erzwungene Reviews

• Status Checks vor Merge

• Keine direkten Pushes auf kritische Branches

Secret Scanning

• Automatisches Blockieren von Commits mit Passwörtern, API Keys oder Tokens

Audit Logging

• Lückenlose, manipulationssichere Protokollierung

• SIEM Anbindung (Security Information and Event Management)

SCA & SAST Integration

• Automatisierte Schwachstellenscans in Bibliotheken (SCA)

• Statische Codeanalyse (SAST)

SAML/SSO & SCIM

• Zentrale Identitätsverwaltung

• Automatische De Provisionierung bei Mitarbeiter Austritt

Muster Scorecard für Kriterien und Gewichtungen

Marktübersicht Developer Tools

Interne Audits als wirksames Instrument

Mon, 16 Mar 2026 19:37:40 GMT

Die Macht von Internen Audits

Interne Audits: Der unterschätzte Erfolgsfaktor für Managementsysteme

Interne Audits sind ein zentraler Bestandteil von Managementsystemen. Trotzdem werden sie in vielen Unternehmen lediglich durchgeführt, um eine Normanforderung zu erfüllen.

Dabei können interne Audits weit mehr leisten: Sie sind ein wirkungsvolles Instrument zur Verbesserung von Prozessen und zur Weiterentwicklung des Managementsystems.

Was interne Audits eigentlich leisten sollen

Normen wie ISO 9001 oder ISO/IEC 27001 etc. verlangen regelmäßige interne Audits.

Der Zweck ist dabei nicht Kontrolle, und schon gar nicht Fehler zu finden und Schuldige zu finden sondern:

Überprüfung der Wirksamkeit des Managementsystems
Identifikation von Verbesserungspotenzialen
frühzeitige Erkennung von Risiken oder Schwachstellen

Richtig eingesetzt sind interne Audits ein wichtiges Steuerungsinstrument. Sie dienen dazu, die Organisation als Ganzes sowie das Zusammenwirken von Prozessen, Rollen und Verantwortlichkeiten zu bewerten.

Typische Probleme bei internen Audits

In der Praxis treten häufig folgende Schwierigkeiten auf:

Audits werden als reine Pflichtübung gesehen
Auditoren stellen nur formale Fragen
Auditoren prüfen nur das Vorhandensein von Dokumentation
Prozesse werden nicht wirklich hinterfragt
Ergebnisse führen nicht zu Verbesserungen

Dadurch bleibt der eigentliche Nutzen von Audits ungenutzt.

Was gute interne Audits auszeichnet

Ein wirksames internes Audit konzentriert sich auf Prozesse statt nur auf Dokumente!

Ein Auditor prüft nicht nur das Vorhandensein von Dokumentationen, sondern vor allem, ob die Prozesse tatsächlich funktionieren. Dabei werden folgende Punkte betrachtet:

Abgleich von Theorie und Praxis: Stimmen die dokumentierten Prozesse mit der gelebten Praxis überein?
Konsistenz der Prozesse: Gibt es Inkonsistenzen oder widersprüchliche Abläufe?
Praxisrelevanz: Werden die Prozesse aktiv gelebt und sind sie sinnvoll definiert?
Risikobewusstsein: Sind Risiken bekannt und werden angemessene Gegenmaßnahmen umgesetzt?
Zielerreichung: Sind die Ziele definiert und werden sie erreicht?
Kontinuierliche Verbesserung: Wird Verbesserungspotenzial identifiziert, erfasst und bewertet?

Interne Audits als Lernprozess

Die besten Audits fördern einen offenen Dialog zwischen Auditor und Organisation.

Sie helfen dabei:

Prozesse besser zu verstehen
Schwachstellen frühzeitig zu erkennen
kontinuierliche Verbesserungen anzustoßen

Die Ziele eines Audits

Überprüfung und Bewertung der Normkonformität der auditierten Organisation
Überprüfung und Bewertung der Konformität mit den eigenen Prozessen
Überprüfung der Eignung des Management Systems zur Unterstützung des Unternehmens die relevanten rechtlichen, regulatorischen und vertraglichen Anforderungen einzuhalten (Kein Rechtsaudit)
Unterstützung der kontinuierlichen Verbesserung

Methoden des Auditierens

Interview, Dokumentenprüfung, Einblick, Sichtung, Begehung, Stichproben aus der gelebten Praxis einsehen und besprechen

Damit werden interne Audits zu einem echten Werkzeug der Organisationsentwicklung.

Ihr Konstantin Ziouras

Anforderungen die aus dem Klimawandel resultieren (AMD1:2024)

Mon, 16 Mar 2026 19:16:11 GMT

Anforderungen durch den Klimawandel

Wie Unternehmen den Klimawandel im Managementsystem adressieren – Anforderungen nach Amendment 1:2024 zu ISO 9001 und ISO/IEC 27001

In 2024 hat die Internationale Organisation für Normung (ISO) in einem Amendment 1:2024 zentrale Managementsystemnormen um ein neues Element ergänzt: die explizite Berücksichtigung des Klimawandels im Kontext der Organisation und bei den Anforderungen interessierter Parteien. Dazu gehören auch ISO 9001 und ISO/IEC 27001.

Die Änderungen betreffen primär die Normkapitel 4.1 „Verstehen der Organisation und ihres Kontextes“

und 4.2 „Verstehen der Erfordernisse und Erwartungen interessierter Parteien“.

Warum diese Änderung?

Es soll sichergestellt werden, dass Organisationen bei der Gestaltung und Anwendung ihrer Managementsysteme strukturiert prüfen, inwiefern der Klimawandel als externer Einflussfaktor relevant ist. Dadurch sollen Risiken und Chancen im Zusammenhang mit klimatischen Veränderungen, gesetzlichen Anforderungen und Erwartungen der Stakeholder berücksichtigt werden – auch für Qualitäts und Informationssicherheitsmanagementsysteme

Kernpunkte des Amendments 2024

1. Erweiterung von Kapitel 4.1 – Kontextanalyse

„Die Organisation muss bestimmen, ob sich Herausforderungen aus dem Klimawandel ergeben.“

D.h., beim Verständnis der internen und externen Themen muss nun explizit geprüft werden, ob klimabedingte Risiken oder Chancen existieren.

Beispiele können sein:

Extremwetterereignisse und ihre Auswirkungen auf Infrastruktur oder Lieferketten
neue gesetzliche Vorgaben im Zusammenhang mit Emissionsberichten oder CO₂ Preisregeln
Energie oder Ressourcenkosten, die durch klimapolitische Maßnahmen beeinflusst werden
Auswirkungen auf Personal, Betriebssicherheit, IT Infrastruktur und Datenverfügbarkeit
Extremtemperaturen (Hitze oder Kälte) und deren Auswirkungen auf Gebäude, Arbeitsbedingungen, technische Anlagen, Serverräume, Rechenzentren, Energieverbrauch für Klimatisierung bzw. Heizung.
Starkregen, Hochwasser oder Überflutungen mit möglichen Schäden an Gebäuden, Technikräumen oder Infrastruktur
Stürme, Schneelast oder Gewitterereignisse, die Gebäude, Hallen, Außenstellen, Baustellen, Energieversorgung oder Betrieb beeinträchtigen können
Wetterbedingte Einschränkungen der Erreichbarkeit von Standorten für Mitarbeiter oder Dienstleister (z. B. Schnee, Blitzeis)
Auswirkungen auf IT-Infrastruktur und technische Systeme, z. B. durch Überhitzung, Stromausfälle oder Wasserschäden

2. Erweiterung von Kapitel 4.2 – Anforderungen interessierter Parteien

„Hinweis: Relevante interessierte Parteien können Anforderungen in Bezug auf den Klimawandel haben.“

D.h., dass bei der Analyse von Interessen und Erwartungen von Stakeholdern (z. B. Kunden, Lieferanten, Behörden, Mitarbeitenden) Unternehmen künftig auch prüfen müssen, ob diese klimabezogene Erwartungen oder Anforderungen haben.

Beispiele:

Kundenvorgaben zu klimafreundlicher Produktion oder Reporting
Regulatorische Anforderungen zu CO₂ Emissionen im Qualitätsbereich
Erwartungen von Versicherungen in Bezug auf Resilienz gegenüber Klimarisiken, z.B. auch hinsichtlich Schutzmaßnahmen gegen klimabedingte Schäden (z. B. Hochwasser oder Sturm)
Anforderungen von Kunden zu Nachhaltigkeits- oder Klimaberichten in Lieferketten
Erwartungen von Behörden hinsichtlich Einhaltung klimabezogener Umwelt- und Energieregelungen
Vorgaben von Auftraggebern zu Energieeffizienz, Emissionsreduktion oder nachhaltiger Beschaffung
Anforderungen von Investoren oder Eigentümern zur Berücksichtigung von Klimarisiken im Risikomanagement
Erwartungen von Mitarbeitenden hinsichtlich sicherer Arbeitsbedingungen bei zunehmenden Extremwetterereignissen, oder einfach bezüglich Arbeitsplatzkomfort.
Verfügbarkeit von Cloud Diensten
Ökologisch nachhaltige Entwicklung und Produktion, bzw. Betrieb, z. B. energieeffiziente Datenverarbeitung

Praxis: Wie setzt ein Unternehmen diese Anforderungen um?

1. Kontextanalyse erweitern

Gibt es klimatische Veränderungen oder Trends, die Einfluss auf das Unternehmen haben?
Welche internen oder externen klimabezogenen Risiken beeinflussen die Produktionsprozesse bzw. Dienstleistungsprozesse?
Gibt es Chancen durch klimabezogene Themen (z. B. neue Märkte, Green Deals)?
Inwieweit wirken sich klimatische Risiken auf die Erreichung der Ziele des Managementsystems aus?

Dokumentieren Sie diese Überlegungen systematisch – z. B. in einer erweiterten Kontextmatrix oder SWOT Analyse.

2. Stakeholder Analyse anpassen

Ergänzen Sie bei der Bestimmung relevanter interessierter Parteien:

Klima aktive Kunden oder Branchenverbände
Regulatorische Behörden mit zukünftigen Klimaberichtspflichten
Lieferanten mit klimabezogenen Lieferanforderungen
Versicherungen, die klimabedingte Risiken einkalkulieren

Bewerten Sie, ob diese Parteien Anforderungen an dein Managementsystem stellen, z. B. Berichterstattung, Risikoprävention oder Kontinuitätsplanung.

Hier kann es Überschneidungen zum Business Continuity Management geben.

3. Risiko und Chancenbewertung integrieren

Leiten Sie aus der Kontext und Stakeholder Analyse konkrete Risiken und Chancen ab:

Beispiel Risiken:

Störungen der Lieferkette durch Extremwetter
Ausfall von IT Infrastruktur bei Klimafolgeschäden
neue regulatorische Anforderungen, die Compliance Prozesse beeinflussen
Beispiel Chancen:
Wettbewerbsvorteile durch klimafreundliche Prozesse
Effizienzsteigerung durch nachhaltige Ressourcennutzung

4. Maßnahmen planen

Definieren Sie Maßnahmen, die Risiken mindern oder Chancen nutzen:

Schulung der Verantwortlichen über klimabedingte Risiken
Integration klimabezogener Indikatoren in Kennzahlen
Anpassungen in Lieferantenbewertungen
Vorbereitung von Business Continuity Plänen für klimabedingte Störungen

5. Managementbewertung anpassen

• Welche klimabezogenen Themen haben Relevanz?

• Wie wurden Anforderungen interessierter Parteien berücksichtigt?

• Welche Risiken und Chancen wurden identifiziert und wie wurde darauf reagiert?

Achtung:

Auch wenn die Anforderungen keine eigenen Maßnahmen vorschreiben, muss das Ergebnis nachweisbar dokumentiert sein.

Fazit – neue Anforderung nutzen statt nur erfüllen

Das Amendment 1:2024 heißt nicht, dass plötzlich ein umfassendes Klimamanagementsystem eingeführt werden muss. Es bedeutet aber:

Der Klimawandel ist ein externer Einflussfaktor, der im Kontext des Managementsystems zu betrachten ist.

Klimabezogene Anforderungen relevanter Stakeholder müssen identifiziert und berücksichtigt werden.

Die Ergebnisse sind Teil der bestehenden Prozesse zur Risiko und Chancenbewertung, zur Planung und zur Managementbewertung.

Damit können Unternehmen nicht nur Auditanforderungen erfüllen, sondern auch ihre Resilienz gegenüber klimabedingten Herausforderungen systematisch verbessern und Chancen strategisch nutzen

Prozesslandschaft

Sat, 14 Mar 2026 11:14:59 GMT

Prozesslandschaft

Ein Bild sagt mehr als Tausend Worte

Risikobetrachtung nach der Bow-Tie-Methode

Sat, 14 Mar 2026 10:15:08 GMT

Risikobetrachtung nach der Bow-Tie-Methode

Eine detaillierte Betrachtung erleichtert eine zielgerichtete Analyse und ermöglicht einen präziseren Blick auf die Risiken . Dabei sollten folgende Aspekte berücksichtigt werden:

Mögliche Ursachen / Schwachstellen: Identifikation von Stellen, die potenziell ausgenutzt oder beeinträchtigt werden können.
Bestehende Maßnahmen: Welche Kontrollen oder Schutzmaßnahmen sind bereits implementiert?
Mögliche Konsequenzen: Welche Auswirkungen könnten eintreten, wenn ein Risiko eintritt?
Zusätzlicher Handlungsbedarf: Welche Maßnahmen sind noch erforderlich, um die Schwachstellen zu adressieren und Risiken zu reduzieren?

Oft werden Risiken zu allgemein formuliert, mögliche Ursachen nicht berücksichtigt, und die Auswirkungen nur oberflächlich bewertet. Dadurch werden Maßnahmen unpräzise und die Wirksamkeit des Risikomanagements eingeschränkt.

Fazit: Risiken sollten konkret beschrieben, ihre Ursachen analysiert und Konsequenzen klar bewertet werden, um gezielte, wirksame Maßnahmen ableiten zu können.

Ihr Konstantin Ziouras

Turtle Prozessdiagramm und Ideale Prozessbeschreibung

Sat, 14 Mar 2026 09:49:04 GMT

Turtle Prozessdiagramm und ideale Prozessbeschreibung

Ein Bild sagt mehr als tausend Worte

Anekdote:
Ein Berater befragte einen meiner Mitarbeiter zu unseren Tätigkeiten, erfasste die Antworten und stellte mir anschließend eine Liste mit 23 Aktivitäten in ungeordneter Reihenfolge vor – ohne Rollen, Verantwortlichkeiten oder weitere Details wie Eingaben, Ergebnisse oder Schnittstellen – und bezeichnete das als Prozessbeschreibung meines Verantwortungsbereichs.

Kernaussage:
Ein Prozess besteht aus deutlich mehr Elementen als nur einer bloßen Aktivitätsliste.

Fazit:
Für eine vollständige Prozessdarstellung sollten Rollen, Verantwortlichkeiten, Eingaben, Ergebnisse, Schnittstellen, Messgrößen und Ressourcen berücksichtigt werden – genau wie sie im Turtle-Diagramm visualisiert werden.

Beschreiben Sie Was, Wer, Wann, Wie, Womit und Wozu!

Mögliche Inhalte einer Prozessbeschreibung / Verfahrensanweisung

Titel / Name des Prozesses
Zweck des Prozesses (in Prosa)
Ziele und Kennzahlen / Metriken
Critical to Quality Anforderungen / Ziele, KPI, Informationssicherheitsziele ...
Geltungsbereich
Abteilungen, Standorte, Systeme, Produkte oder Services
Ausnahmen, Einschränkungen
Rollen und Verantwortlichkeiten
Prozessverantwortlicher, Mitwirkende
RACI-Matrix, Qualifikationen und notwendige Trainings
Inputs / Eingaben
Auch Schnittstellen zu anderen Prozessen
Outputs / Ergebnisse
Dokumentation, Reports, Produkte
Schnittstellen zu anderen Prozessen
Vorgelagerte und nachgelagerte Prozesse
z.B.: Asset Management, Change Management, Qualitätssicherung, Informationssicherheit, Risikomanagement, Umweltmanagement, Arbeitssicherheit ...
Risiken und mitigierende Maßnahmen
Chancen und Maßnahmen
Prinzipien / Guidelines / Richtlinien
Tätigkeiten / Aktivitäten
Reihenfolge, zeitlicher Ablauf, Workflow
Methodik / Methoden
Nötige Tools, Equipment, Hilfsmittel, Schulungsunterlagen, Anlagen
Referenzen / Dokumente
Vorgelagerte Dokumente, mitgeltende Dokumente, Anhänge
Definitionen / Abkürzungen / Begriffe
Versionierung / Historie
Optimierung und Kontrolle der Wirksamkeit
KPIs, Trendanalyse, Auswertungen
Vorlagen, Templates, Formulare, Toolauswahl
Normen- und Rechtsbezug
Referenzen zu Normen, Gesetzen und Regularien
Nachweisführung
Welche Nachweise müssen dokumentiert werden (Außenwirkung, Innenwirkung, Nachweis "Sorgfaltspflicht")

Update 2026 - etwas detaillierter:

Mögliche Inhalte einer Prozessbeschreibung / Verfahrensanweisung

Eine Prozessbeschreibung bzw. Verfahrensanweisung sollte nicht nur beschreiben, was getan wird, sondern auch warum , durch wen , mit welchen Eingaben und Ergebnissen , unter welchen Rahmenbedingungen und wie die Wirksamkeit des Prozesses überprüft wird .

Je nach Organisation, Prozess und Zweck können insbesondere folgende Inhalte sinnvoll sein:

1. Prozessbezeichnung und Zweck

Titel / Name des Prozesses
Zweck und Aufgaben des Prozesses
Welches Problem bzw. welches Bedürfnis soll der Prozess erfüllen?
Beitrag des Prozesses zu den Unternehmenszielen

2. Ziele und Kennzahlen

Prozessziele
Critical-to-Quality-Anforderungen (CTQ)
Qualitätsziele
KPIs / Leistungskennzahlen
Informationssicherheitsziele, soweit relevant
Weitere relevante Messgrößen

3. Geltungsbereich

Betroffene Abteilungen und Organisationseinheiten
Standorte
Produkte und Services
Systeme und Anwendungen
Beginn und Ende des Prozesses
Ausnahmen und Einschränkungen

4. Rollen und Verantwortlichkeiten

Prozessverantwortlicher / Process Owner
Beteiligte Rollen und Funktionen
Verantwortlichkeiten und Befugnisse
RACI-Matrix, sofern sinnvoll
Erforderliche Qualifikationen
Notwendige Schulungen und Unterweisungen

5. Prozessinput und Eingangsvoraussetzungen

Benötigte Eingaben
Informationen und Daten
Dokumente und Freigaben
Vorgelagerte Prozesse
Eingangskriterien und Voraussetzungen

6. Prozessoutput und Ergebnisse

Ergebnisse bzw. Liefergegenstände des Prozesses
Produkte und Services
Dokumente und Aufzeichnungen
Reports und Auswertungen
Übergaben an nachgelagerte Prozesse

7. Prozessschnittstellen

Vorgelagerte und nachgelagerte Prozesse
Interne und externe Schnittstellen
Abhängigkeiten zu anderen Prozessen

Beispiele:

Asset Management
Change Management
Incident / Problem Management
Qualitätssicherung
Informationssicherheitsmanagement
Risikomanagement
Lieferantenmanagement

8. Risiken, Chancen und Rahmenbedingungen

Prozessrisiken
Informationssicherheitsrisiken
Qualitätsrisiken
Compliance- und rechtliche Risiken
Maßnahmen zur Risikobehandlung
Chancen und Verbesserungspotenziale
Kritische Abhängigkeiten und Randbedingungen

9. Prinzipien, Vorgaben und Regeln

Grundsätze des Prozesses
Unternehmensrichtlinien
interne Vorgaben
relevante Standards und Guidelines
Freigabe- und Eskalationsregeln

10. Prozessablauf und Aktivitäten

Beschreibung der einzelnen Tätigkeiten
Reihenfolge der Aktivitäten
Workflow bzw. Prozessablauf
Entscheidungspunkte
Freigaben
Übergaben
Eskalationen
ggf. grafische Darstellung als Prozessmodell / Flowchart

11. Methoden und Arbeitsmittel

Angewandte Methoden und Verfahren
IT-Systeme und Tools
Equipment und Hilfsmittel
Checklisten
Schulungsunterlagen
erforderliche Vorlagen und Arbeitsanweisungen

12. Dokumentierte Informationen und Nachweise

Welche Dokumente entstehen?
Welche Aufzeichnungen / Records sind erforderlich?
Welche Nachweise müssen geführt werden?
Verantwortlichkeit für Erstellung und Pflege
Aufbewahrungsfristen
Ablage und Zugriff
Schutz vor unbefugter Änderung oder Löschung

13. Vorlagen und Templates

Formulare
Checklisten
Reports
Protokolle
Freigabeformulare
Tool-Templates
sonstige unterstützende Arbeitsmittel

14. Normen-, Rechts- und Compliance-Bezug

Relevante Normen
Gesetze und Verordnungen
regulatorische Anforderungen
Kundenanforderungen
vertragliche Anforderungen

Dabei sollte möglichst konkret angegeben werden, welche Anforderung durch welchen Prozess umgesetzt wird .

15. Definitionen und Abkürzungen

Fachbegriffe
Abkürzungen
organisationsspezifische Begriffe
eindeutige Definitionen kritischer Begriffe

16. Überwachung und Wirksamkeitsbewertung

Prozess-KPIs
Überwachungs- und Messverfahren
Trendanalysen
interne Audits
Management Reviews, soweit relevant
Bewertung der Zielerreichung
Wirksamkeit von Maßnahmen
Fehler, Abweichungen und Reklamationen

17. Prozessverbesserung

identifizierte Verbesserungspotenziale
Korrekturmaßnahmen
Verbesserungsmaßnahmen
Lessons Learned
kontinuierliche Verbesserung
Änderungen des Prozesses aufgrund von Erfahrungen, Risiken oder neuen Anforderungen

18. Dokumentenlenkung und Versionierung

Dokumenten-ID
Version / Revisionsstand
Ersteller
Prüfer
Genehmiger
Gültigkeitsdatum
Änderungshistorie
Regelung zur Verteilung und Verfügbarkeit

Eine Prozessbeschreibung ist nicht eine Arbeitsanweisung und muss nicht alle Arbeitstätigkeiten im Detail erklären.

Es ist sinnvoll eine Dokumentenhierarchie für das Unternehmen zu definieren, z.B.

Managementsystem / Prozesslandschaft
↓
Prozessbeschreibung – Was wird gemacht und wie ist der Prozess organisiert?
↓
Verfahrensanweisung – Welche Regeln und Vorgehensweisen gelten?
↓
Arbeitsanweisung – Wie wird eine konkrete Tätigkeit durchgeführt?
↓
Checkliste / Formular / Template – Womit wird die Tätigkeit praktisch unterstützt bzw. nachgewiesen? Wie und wo wird dokumentiert?

Das verhindert, dass eine Prozessbeschreibung zu einem 50-seitigen Dokument wird, das niemand mehr liest .

Die W-Fragen aus dem Turtle Diagramm sollten auf jeden Fall in einer Prozessbeschreibung beantwortet werden, falls Sie noch mehr W-Fragen für wichtig erachten, erklären Sie diese ebenso, z.B.

Woran erkennen wir Erfolg? KPIs, Qualität, Wirksamkeitskontrolle

Was kann schiefgehen? Risiken, Kontrollen, Eskalationen

etc.

Ihr Konstantin Ziouras

risiko management nach iso 27001

Fri, 13 Mar 2026 20:17:24 GMT

Aspekte in der Bewertung und Behandlung von Risiken und Chancen, die oft vernachlässigt werden (gemäß ISO 27001)

Risikomanagement für Informationssicherheit – mehr als eine Risikomatrix

Risiken erkennen, bewerten, behandeln und wirksam steuern nach ISO/IEC 27001:2022 und ISO/IEC 27005:2019

Risikomanagement ist eine der zentralen Säulen eines Informationssicherheits-Managementsystems (ISMS).

Trotzdem wird Risikomanagement in der Praxis häufig auf eine Risikomatrix reduziert:

Eintrittswahrscheinlichkeit × Auswirkung = Risikowert

Damit ist zwar ein Teil der Aufgabe erledigt – aber noch lange kein funktionierendes Risikomanagement etabliert.

Ein wirksames Informationssicherheits-Risikomanagement beginnt wesentlich früher und endet wesentlich später:

Kontext verstehen → Risiken identifizieren → Risiken analysieren → Risiken bewerten → Maßnahmen auswählen → Maßnahmen umsetzen → Restrisiko bewerten und akzeptieren → Wirksamkeit überwachen → Risiken regelmäßig überprüfen

Genau hier setzen ISO/IEC 27001:2022 und ISO/IEC 27005:2019 an.

Dieser Artikel betrachtet das Thema bewusst aus einer praktischen Perspektive. Er zeigt, was die ISO/IEC 27001 fordert, welche Rolle ISO/IEC 27005 spielt und wo sich Risikobetrachtungen im täglichen Betrieb eines ISMS wiederfinden.

1. Zunächst die Grundlagen: Was fordert ISO/IEC 27001?

Die zentralen Anforderungen an das Risikomanagement finden sich insbesondere in den Kapiteln 6.1.1, 6.1.2, 6.1.3, 8.2 und 8.3 .

Dabei sollte man unterscheiden zwischen:

Risiken und Chancen des ISMS,
Informationssicherheitsrisiken,
Risikobewertung,
Risikobehandlung,
Restrisiken,
Überwachung und Wirksamkeitsbewertung.

Kapitel 6.1.1 – Maßnahmen zum Umgang mit Risiken und Chancen

Die Organisation muss die Risiken und Chancen bestimmen, die sich aus ihrem Kontext und den Anforderungen interessierter Parteien ergeben und die für das ISMS relevant sind.

Dabei geht es beispielsweise um:

externe und interne Themen,
gesetzliche und regulatorische Anforderungen,
Anforderungen von Kunden,
technologische Entwicklungen,
Veränderungen des Geschäftsmodells,
Lieferanten und Dienstleister,
neue Bedrohungen,
organisatorische Veränderungen

Hier kann beispielsweise eine PESTEL-Analyse eine sinnvolle Methode sein:

P olitical – politische Faktoren
E conomic – wirtschaftliche Faktoren
S ocial – gesellschaftliche Faktoren
T echnological – technologische Faktoren
E nvironmental – Umweltfaktoren
L egal – rechtliche Faktoren

PESTEL ist dabei keine von ISO/IEC 27001 vorgeschriebene Methode. Sie kann aber helfen, externe Einflussfaktoren systematisch zu erfassen.

Seit dem Amendment 1:2024 ist außerdem ausdrücklich zu berücksichtigen, ob der Klimawandel ein relevantes Thema für die Organisation ist und ob interessierte Parteien Anforderungen bezüglich des Klimawandels haben.

Wichtig ist außerdem:

Maßnahmen allein zu implementieren reicht nicht. Ihre geplante Integration und ihre Wirksamkeit müssen berücksichtigt werden.

Eine interessante praktische Frage lautet deshalb:

Woher wissen wir eigentlich, dass eine Risikomaßnahme tatsächlich funktioniert?

2. Kapitel 6.1.2 – Informationssicherheits-Risikobewertung

Die Organisation muss einen Prozess für die Informationssicherheits-Risikobewertung festlegen.

Dieser Prozess sollte insbesondere sicherstellen, dass:

Kriterien für die Risikobewertung definiert sind,
Kriterien für die Risikoakzeptanz definiert sind,
vergleichbare und wiederholbare Ergebnisse entstehen,
Informationssicherheitsrisiken innerhalb des ISMS-Scope identifiziert werden,
Risiken hinsichtlich ihrer Auswirkungen und ihrer Wahrscheinlichkeit analysiert werden,
Risikoniveaus bestimmt werden,
Risiken mit den festgelegten Kriterien verglichen werden,
Risiken priorisiert werden.

Dabei stehen insbesondere die Auswirkungen auf die Vertraulichkeit, Integrität und Verfügbarkeit von Informationen im Mittelpunkt. (V. I. V. oder Confidentiality, Integrity, Availability: C.I.A.)

Je nach Organisation können darüber hinaus beispielsweise betrachtet werden:

Datenschutz,
gesetzliche Anforderungen,
finanzielle Auswirkungen,
Vertragsverletzungen,
Kundenbeeinträchtigungen,
Produktionsausfälle,
Lieferfähigkeit,
Reputation,
Business Continuity,
Auswirkungen auf Produkte und Dienstleistungen.

Die Ergebnisse der Risikobewertung müssen als dokumentierte Information nachvollziehbar sein.

Eine bestimmte „Risikoakte“ schreibt die Norm nicht vor. Ein Risikoregister bzw. eine Risikoakte ist jedoch in der Praxis ein sehr sinnvolles Steuerungsinstrument.

3. Risikobewertung ist mehr als eine Risikomatrix

Ein häufiger Fehler besteht darin, Risikoanalyse und Risikobewertung gleichzusetzen.

Praktisch lässt sich der Prozess beispielsweise so darstellen:

Risikoidentifikation

Was kann passieren?

Risikoanalyse

Wie wahrscheinlich ist es und welche Auswirkungen hätte es?

Risikoevaluation

Ist das Risiko im Vergleich zu unseren Kriterien akzeptabel?

Risikobehandlung

Was tun wir dagegen?

Restrisiko

Was bleibt nach den Maßnahmen übrig?

Risikoakzeptanz

Wer akzeptiert das verbleibende Risiko?

Monitoring & Review

Hat sich das Risiko verändert und sind die Maßnahmen weiterhin wirksam?

Das entspricht wesentlich besser dem Gedanken eines kontinuierlichen Risikomanagements, wie er auch in ISO/IEC 27005 beschrieben wird.

4. ISO/IEC 27005: Der Blick auf den vollständigen Risikomanagement-Prozess

ISO/IEC 27005 ergänzt ISO/IEC 27001 insbesondere um eine systematische Betrachtung des Informationssicherheits-Risikomanagements.

Der Fokus liegt nicht nur auf der Frage:

„Wie hoch ist das Risiko?“

Sondern auf dem gesamten Lebenszyklus.

Dazu gehören insbesondere:

Kontext herstellen,
Risikoidentifikation,
Risikoanalyse,
Risikoevaluation,
Risikobehandlung,
Risikoakzeptanz,
Kommunikation und Konsultation,
Monitoring und Review.

Damit wird deutlich:

Ein Risikoregister ist kein Archiv. Es ist ein Steuerungsinstrument.

5. Wie entsteht eigentlich ein Informationssicherheitsrisiko?

Eine gute Risikobewertung beginnt mit einer guten Beschreibung des Risikos.

Zu häufig findet man in Risikoregistern Einträge wie:

„Ransomware – hoch“

oder:

„Cyberangriff – mittel“

oder:

„Datenverlust – hoch“

Das ist für eine belastbare Risikobehandlung zu wenig.

Denn:

Ransomware ist eine Bedrohung.

Datenverlust ist eine mögliche Konsequenz.

Dazwischen liegt das eigentliche Risikoszenario.

Eine präzisere Betrachtung könnte beispielsweise so aussehen:

Bedrohung

Ransomware-Angriff

Ursache

Phishing / kompromittiertes Benutzerkonto

Schwachstelle

Unzureichende Absicherung und Segmentierung

Risikoereignis

Angreifer kann Schadsoftware in das Unternehmensnetzwerk einbringen und verbreiten

Konsequenz

Verschlüsselung kritischer Systeme und Unterbrechung wesentlicher Geschäftsprozesse

Jetzt lässt sich sinnvoll bewerten:

Wie wahrscheinlich ist das?
Welche Systeme sind betroffen?
Welche Informationen sind betroffen?
Welche Auswirkungen entstehen?
Welche Controls existieren bereits?
Welche Maßnahmen fehlen?
Welches Restrisiko bleibt?

6. Eine gute Risikobeschreibung betrachtet mehrere Ebenen

Eine detaillierte Betrachtung ermöglicht eine zielgerichtete Analyse.

Folgende Aspekte sollten mindestens betrachtet werden:

1. Asset / Information

Was soll geschützt werden?

Beispielsweise:

Kundendaten,
Quellcode,
Produktionsdaten,
Geschäftsgeheimnisse,
Identitäten,
IT-Systeme.

2. Bedrohung

Was kann passieren?

Beispielsweise:

Phishing,
Ransomware,
Insider,
technische Schwachstelle,
Fehlkonfiguration,
Lieferantenausfall.

3. Ursachen

Warum kann es passieren?

Beispielsweise:

fehlende Schulung,
unzureichende Prozesse,
technische Schwachstellen,
fehlende Trennung von Netzwerken,
unzureichende Zugriffskontrollen.

4. Schwachstellen

Was kann ausgenutzt werden?

5. Risikoereignis

Was passiert konkret?

6. Konsequenzen

Welche Auswirkungen entstehen?

7. Bestehende Maßnahmen

Was wurde bereits dagegen implementiert?

8. Restrisiko

Wie hoch ist das Risiko nach Berücksichtigung der bestehenden Maßnahmen?

9. Zusätzlicher Handlungsbedarf

Welche weitere Risikobehandlung ist erforderlich?

10. Verantwortung und Akzeptanz

Wer ist Risk Owner und wer akzeptiert gegebenenfalls das Restrisiko?

7. Inhärentes Risiko und Restrisiko

Ein besonders hilfreiches Konzept ist die Unterscheidung zwischen dem Risiko vor und nach Berücksichtigung vorhandener Maßnahmen.

Beispiel:

Inhärentes Risiko

Ransomware

Eintrittswahrscheinlichkeit: hoch
Auswirkung: hoch
Risiko: hoch

Vorhandene Controls:

MFA
EDR
Patch Management
Netzwerksegmentierung
Backups
Restore-Tests
Awareness Training

Nach Berücksichtigung dieser Maßnahmen:

Restrisiko

Eintrittswahrscheinlichkeit: mittel
Auswirkung: hoch
Restrisiko: mittel

Jetzt stellt sich die entscheidende Managementfrage:

Ist dieses Restrisiko innerhalb der festgelegten Risikoakzeptanzgrenze?

Wenn ja, kann das Restrisiko durch den zuständigen Risikoeigner akzeptiert werden.

Wenn nein, sind weitere Maßnahmen erforderlich.

8. Risikobehandlung nach 6.1.3

Die Risikobehandlung besteht nicht einfach darin, eine Maßnahme in eine Liste einzutragen.

Die Organisation muss geeignete Behandlungsmaßnahmen bestimmen und deren Umsetzung planen.

Typische Optionen sind:

Risiko vermeiden

Die risikobehaftete Aktivität wird beendet oder gar nicht erst durchgeführt.

Risiko reduzieren

Eintrittswahrscheinlichkeit oder Auswirkungen werden reduziert.

Risiko teilen bzw. übertragen

Beispielsweise durch Versicherungen oder vertragliche Vereinbarungen.

Risiko akzeptieren

Das Risiko wird bewusst übernommen, wenn es innerhalb der definierten Akzeptanzkriterien liegt.

Wichtig:

„Wir haben ein Control implementiert“ bedeutet nicht automatisch „Risiko ist behandelt“.

Entscheidend ist die Frage:

Hat die Maßnahme das Risiko tatsächlich ausreichend reduziert?

9. Die Wirksamkeit von Maßnahmen

Dieser Punkt wird in der Praxis häufig unterschätzt.

Eine Maßnahme sollte nicht nur einen Status bekommen:

„implementiert“

sondern auch eine Aussage darüber ermöglichen:

„wirksam“

Beispielsweise:

Maßnahme

Backup-System eingeführt.

Das allein sagt noch wenig aus.

Interessanter sind Fragen wie:

Werden die Backups tatsächlich durchgeführt?
Sind sie gegen Manipulation geschützt?
Sind kritische Systeme enthalten?
Sind Wiederherstellungszeiten definiert?
Wurde ein Restore-Test durchgeführt?
War der Restore erfolgreich?
Wird die Wirksamkeit regelmäßig überprüft?

Damit wird aus:

„Control vorhanden“

ein:

„Control funktioniert nachweislich.“

10. Die Rolle der Statement of Applicability

Die Statement of Applicability (SoA) ist ein wichtiger Bestandteil des Risikobehandlungsprozesses.

Die Organisation muss die notwendigen Controls bestimmen und diese mit den Controls des Annex A abgleichen.

Dabei ist Annex A nicht einfach eine Checkliste, die vollständig „abgehakt“ werden muss.

Der entscheidende Prozess ist vielmehr:

Risiken + Kontext + Anforderungen + Geschäftsanforderungen
notwendige Maßnahmen
Abgleich mit Annex A
SoA

Damit soll unter anderem sichergestellt werden, dass relevante Controls nicht übersehen werden.

Die SoA dokumentiert insbesondere:

welche Controls erforderlich sind,
warum sie erforderlich sind,
ob sie implementiert sind,
und – soweit ein Control nicht erforderlich ist – warum es nicht angewendet wird.

11. Ist die gesamte ISO/IEC 27001 risikobasiert?

Ja – aber mit einer wichtigen Einschränkung.

ISO/IEC 27001 ist wesentlich risikobasiert. Aber nicht jede einzelne Anforderung stellt eine eigenständige Risikobewertung dar.

Es gibt direkte und indirekte Bezüge.

Direkte Anforderungen

Besonders relevant sind:

6.1.1 – Risiken und Chancen
6.1.2 – Informationssicherheits-Risikobewertung
6.1.3 – Informationssicherheits-Risikobehandlung
8.2 – Durchführung der Informationssicherheits-Risikobewertung
8.3 – Durchführung der Informationssicherheits-Risikobehandlung

Indirekte bzw. risikoorientierte Bezüge

Andere Anforderungen schaffen Rahmenbedingungen für risikobasierte Entscheidungen, beispielsweise:

4.1 – Kontext der Organisation
4.2 – interessierte Parteien
5.1 – Führung und Verpflichtung
5.2 – Informationssicherheitspolitik
9.1 – Überwachung, Messung, Analyse und Bewertung
9.3 – Managementbewertung
10.1 – Nichtkonformität und Korrekturmaßnahmen

Dabei sollte man nicht behaupten, dass jedes dieser Kapitel eine eigene Risikobewertung fordert.

Vielmehr tragen sie dazu bei, dass das ISMS Risiken systematisch berücksichtigt, Entscheidungen nachvollziehbar getroffen und deren Wirksamkeit bewertet werden.

12. Risikomanagement findet nicht nur im Risikoregister statt

Hier liegt meiner Meinung nach einer der interessantesten Aspekte eines funktionierenden ISMS.

Risikomanagement findet nicht nur einmal jährlich im Rahmen einer zentralen Risikobewertung statt.

Risiken entstehen auch im täglichen Betrieb.

Lieferanten

Bei neuen Lieferanten oder Änderungen bestehender Lieferantenbeziehungen müssen beispielsweise betrachtet werden:

Abhängigkeiten,
Zugriff auf Informationen,
Subdienstleister,
Cloud-Nutzung,
Standort,
Vertragsanforderungen,
Verfügbarkeit,
Datenschutz,
Informationssicherheit.

Besonders relevant sind hier beispielsweise:

A.5.19 – Information Security in Supplier Relationships

A.5.20 – Addressing Information Security within Supplier Agreements

A.5.21 – Managing Information Security in the ICT Supply Chain

A.5.23 – Information Security for Use of Cloud Services

13. Risikomanagement im Change Management

Ein klassisches Beispiel ist ein IT-Change.

Ein Change sollte nicht nur die Frage beantworten:

„Was soll technisch geändert werden?“

Sondern auch:

Welche Systeme sind betroffen?
Welche Informationen sind betroffen?
Welche Sicherheitsanforderungen ändern sich?
Welche neuen Schwachstellen können entstehen?
Welche Abhängigkeiten existieren?
Wie wird getestet?
Wie kann zurückgerollt werden?
Welche Auswirkungen hätte ein Fehler?

Eine sinnvolle Kette lautet:

Change
Risikoanalyse
Sicherheitsanforderungen
Test
Freigabe
Implementierung
Monitoring
Fallback / Rollback
Review

Hier zeigt sich besonders deutlich, dass Risikomanagement Bestandteil des operativen Managements sein sollte.

14. Risikomanagement in der Softwareentwicklung

Auch Softwareentwicklung bietet zahlreiche Beispiele.

Risiken können entstehen durch:

unsichere Anforderungen,
fehlende Security Requirements,
Schwachstellen,
unsicheren Code,
Open-Source-Komponenten,
fehlende Tests,
unzureichende Zugriffskontrollen,
unsichere Schnittstellen,
Fehlkonfigurationen,
fehlende Protokollierung.

Relevante Annex-A-Controls sind beispielsweise:

A.8.8 – Management of Technical Vulnerabilities
A.8.25 – Secure Development Life Cycle
A.8.26 – Application Security Requirements
A.8.28 – Secure Coding
A.8.29 – Security Testing in Development and Acceptance

Auch hier gilt:

Security by Design bedeutet letztlich, Risiken frühzeitig in Anforderungen, Architektur, Entwicklung und Tests zu berücksichtigen.

15. Risikomanagement bei Standorten und physischer Sicherheit

Informationssicherheit ist nicht nur IT-Sicherheit.

Ein Unternehmen kann beispielsweise Risiken durch folgende Faktoren haben:

Hochwasser,
Feuer,
Stromausfall,
Einbruch,
unbefugten Zutritt,
Ausfall eines Rechenzentrums,
Standortkonzentration,
Abhängigkeit von einer einzigen Infrastruktur.

Gerade bei mehreren Standorten sollte deshalb die Frage gestellt werden:

Welche standortbezogenen Risiken beeinflussen die Informationssicherheit?

Dabei können beispielsweise folgende Faktoren betrachtet werden:

geografische Lage,
Infrastruktur,
Stromversorgung,
Internetanbindung,
Naturgefahren,
politische bzw. regulatorische Faktoren,
Lieferantenabhängigkeiten.

Auch hier kann PESTEL als strukturierendes Werkzeug sinnvoll sein – allerdings als Methode der Organisation , nicht als normative Forderung der ISO/IEC 27001.

16. Risikomanagement bei Business Continuity

Informationssicherheitsrisiken und Business Continuity sind eng miteinander verbunden.

Ein Ausfall eines IT-Systems kann beispielsweise nicht nur ein IT-Problem sein.

Die eigentliche Frage lautet:

Welche Geschäftsprozesse können dadurch nicht mehr durchgeführt werden?

Damit kommen unter anderem folgende Themen ins Spiel:

kritische Geschäftsprozesse,
Wiederanlaufzeiten,
Wiederherstellungspunkte,
Abhängigkeiten,
Ersatzverfahren,
Backup,
Recovery,
Krisenmanagement.

A.5.30 – ICT Readiness for Business Continuity ist dabei ein wichtiges Control.

Eine Business Impact Analysis (BIA) ist dabei nicht einfach mit einer Risikoanalyse gleichzusetzen. Sie liefert vielmehr wichtige Informationen darüber, welche Auswirkungen ein Ausfall auf das Geschäft hätte und welche Kontinuitätsanforderungen daraus entstehen.

17. Annex A und Risiko – nicht jedes Control verlangt eine eigene Risikobewertung

Der Annex A enthält zahlreiche Controls, bei denen Risiken eine wichtige Rolle spielen.

Man sollte aber zwischen drei Situationen unterscheiden.

Kategorie 1 – explizit risikoorientierte Controls

Beispielsweise:

A.5.19 Supplier Relationships
A.5.23 Cloud Services
A.8.8 Technical Vulnerabilities
A.8.32 Change Management

Kategorie 2 – Controls, deren Ausgestaltung von Risiken bzw. Schutzbedarf beeinflusst wird

Beispielsweise:

A.5.3 Segregation of Duties
A.5.12 Classification of Information
A.6.1 Screening
A.7.1 Physical Security Perimeters
A.8.2 Privileged Access Rights
A.8.16 Monitoring Activities

Kategorie 3 – Controls, deren konkrete Anwendung stark vom Kontext abhängt

Beispielsweise:

A.5.32 Protection of Intellectual Property
A.8.11 Data Masking
A.8.26 Application Security Requirements
A.8.28 Secure Coding

Daraus folgt:

Nicht jedes Control benötigt eine separate Risikobewertung. Aber die Auswahl, Ausgestaltung und Priorisierung von Controls sollte im Gesamtkontext des ISMS nachvollziehbar sein.

18. Risiko verändert sich

Ein Risiko ist keine statische Eigenschaft.

Ein Beispiel:

2025

Cloud Provider
Risiko: mittel

Dann ändern sich beispielsweise:

Bedrohungslage,
technische Architektur,
Subdienstleister,
Vertragsbedingungen,
gesetzliche Anforderungen,
Geschäftsprozesse,
Abhängigkeiten.

Das Risiko kann dadurch 2026 plötzlich hoch sein.

Deshalb braucht ein funktionierendes Risikomanagement:

regelmäßige Bewertungen,
Reviews,
Monitoring,
Anlassbewertungen.

Anlassbezogene Neubewertungen können beispielsweise erforderlich werden bei:

wesentlichen Changes,
neuen Systemen,
neuen Lieferanten,
neuen Bedrohungen,
Sicherheitsvorfällen,
neuen regulatorischen Anforderungen,
organisatorischen Änderungen,
neuen Standorten,
wesentlichen Technologieänderungen.

19. Die oft unterschätzte Frage: Was hat sich seit der letzten Bewertung verändert?

Eine sehr praktische Auditfrage lautet:

„Was hat sich seit der letzten Risikobewertung verändert?“

Wenn die Antwort lautet:

„Nichts.“

sollte man nachfragen.

Denn möglicherweise haben sich verändert:

Bedrohungen,
Schwachstellen,
Lieferanten,
Mitarbeiter,
Technologien,
Systeme,
Geschäftsprozesse,
regulatorische Anforderungen,
geopolitische Rahmenbedingungen.

Risikomanagement sollte deshalb nicht nur dokumentieren:

„Risiko = mittel“

sondern auch:

„Warum ist das Risiko heute mittel und was hat sich seit der letzten Bewertung verändert?“

20. Die Qualität der Risikobeschreibung entscheidet über die Qualität der Maßnahmen

Ein häufiges Problem in Risikoregister lautet:

„Risiko: Datenverlust“

Maßnahme:

„Backup verbessern.“

Das ist zu unspezifisch.

Eine bessere Beschreibung könnte lauten:

„Durch einen kompromittierten privilegierten Account kann ein Angreifer auf produktive Daten zugreifen und diese verändern oder löschen. Aufgrund unzureichend geschützter Backup-Zugänge besteht zusätzlich das Risiko, dass Wiederherstellungsdaten manipuliert werden. Im Falle eines erfolgreichen Angriffs können Verfügbarkeit und Integrität kritischer Geschäftsdaten beeinträchtigt werden.“

Jetzt lassen sich gezielt Maßnahmen ableiten:

MFA,
Privileged Access Management,
getrennte Backup-Accounts,
Immutable Backup,
Netzwerksegmentierung,
Monitoring,
Restore-Tests.

Die Qualität der Maßnahme hängt also wesentlich von der Qualität der Risikoanalyse ab.

21. Eine praktische Checkliste für ein gutes Risikoszenario

Für die Praxis kann folgende Checkliste verwendet werden:

Risikoidentifikation
Was wollen wir schützen?
Bedrohung
Was kann passieren?
Ursache
Warum kann es passieren?
Schwachstelle
Was kann ausgenutzt werden?
Risikoereignis
Was passiert konkret?
Konsequenz
Welche Auswirkungen entstehen?
Bestehende Controls
Was haben wir bereits dagegen?
Risikobewertung
Wie wahrscheinlich ist das Ereignis und wie groß ist die Auswirkung?
Restrisiko
Wie hoch ist das Risiko nach Berücksichtigung der bestehenden Maßnahmen?
Risikobehandlung
Was müssen wir zusätzlich tun?
Verantwortlichkeit
Wer ist Risk Owner?
Risikoakzeptanz
Wer akzeptiert das Restrisiko?
Wirksamkeit
Woran erkennen wir, dass die Maßnahme funktioniert?
Monitoring
Wann und unter welchen Bedingungen wird das Risiko erneut bewertet?

22. Das Risikoregister sollte deshalb mehr sein als eine Excel-Tabelle

Eine praktische Risikoakte könnte beispielsweise folgende Informationen enthalten:

Element

Beispiel

Risiko-ID: R-023

Asset / Prozess: Kundendatenbank

Bedrohung: Phishing

Ursache: Social Engineering

Schwachstelle: fehlende MFA

Risikoereignis: kompromittierter Account

Konsequenz: Verlust der Vertraulichkeit

CIA: C

Inhärentes Risiko: Hoch

Bestehende Controls: MFA, EDR, Awareness

Restrisiko: Mittel

Behandlung: weitere Absicherung

Maßnahme: MFA für alle externen Zugriffe

Risk Owner: CISO

Termin: 30.06.

Akzeptanzgrenze: Mittel

Status: Offen

Wirksamkeitsnachweis: MFA-Abdeckung > 99 %

Review: quartalsweise

Damit wird aus einem Risikoregister ein echtes Managementinstrument .

23. Die Verbindung zu Managementbewertung und kontinuierlicher Verbesserung

Risikomanagement endet nicht beim Risk Owner.

Die Ergebnisse müssen wieder in das Managementsystem zurückfließen.

Das Management sollte beispielsweise wissen:

Welche Risiken sind aktuell kritisch?
Welche Risiken haben sich verändert?
Welche Maßnahmen sind überfällig?
Welche Restrisiken wurden akzeptiert?
Wo gibt es wiederkehrende Probleme?
Welche neuen Risiken sind entstanden?
Welche Maßnahmen sind nicht wirksam?
Wo müssen Ressourcen angepasst werden?

Damit entsteht der Kreislauf:

Risiko
Entscheidung
Maßnahme
Wirksamkeitsprüfung
Managementbewertung
Verbesserung
neue Risikobewertung

Das ist der eigentliche Mehrwert eines ISMS.

24. Fazit: Risikomanagement ist keine einmalige Übung

Ein gutes Informationssicherheits-Risikomanagement besteht nicht darin, einmal pro Jahr eine Risikomatrix zu aktualisieren.

Es bedeutet:

Risiken verstehen, bevor sie zum Problem werden.

Dazu gehört:

den Kontext der Organisation zu verstehen,
relevante Bedrohungen und Schwachstellen zu erkennen,
Risiken konkret zu beschreiben,
Ursachen und Konsequenzen zu analysieren,
bestehende Controls zu berücksichtigen,
Risiken nachvollziehbar zu bewerten,
geeignete Maßnahmen auszuwählen,
Restrisiken bewusst zu akzeptieren,
die Wirksamkeit der Maßnahmen zu überprüfen,
und Risiken bei Veränderungen erneut zu betrachten.

ISO/IEC 27001 liefert dafür den verbindlichen Rahmen.

ISO/IEC 27005 unterstützt dabei, den Risikomanagement-Prozess methodisch zu strukturieren.

Die eigentliche Herausforderung liegt jedoch in der praktischen Umsetzung.

Denn Informationssicherheitsrisiken entstehen nicht nur im Risikoregister.

Sie entstehen bei:

neuen Lieferanten, Cloud-Diensten, Changes, Projekten, Softwareentwicklung, Schwachstellen, neuen Standorten, neuen Technologien, organisatorischen Veränderungen und neuen regulatorischen Anforderungen.

Deshalb sollte die entscheidende Frage nicht nur lauten:

„Wie hoch ist unser Risiko?“

Sondern:

„Verstehen wir, warum dieses Risiko besteht, was wir dagegen tun, ob unsere Maßnahmen tatsächlich wirken und welches Restrisiko wir bewusst akzeptieren?“

Das ist der Unterschied zwischen einer Risikomatrix und einem wirksamen Risikomanagement .

Kurzform für die Praxis

Was schützen wir?
Was kann passieren?
Warum kann es passieren?
Welche Konsequenzen entstehen?
Was haben wir bereits dagegen?
Wie hoch ist das Restrisiko?
Was müssen wir zusätzlich tun?
Wer trägt die Verantwortung?
Wer akzeptiert das Restrisiko?
Wie überprüfen wir die Wirksamkeit?
Was hat sich verändert?

Genau hier beginnt praktisches Informationssicherheits-Risikomanagement.

Viel Erfolg, Ihr Konstantin Ziouras

P.S. Im Portfolio:

Zwei-Tägige Kurse zur Behandlung von Risiko Management im Integrierten Management System, oder in der Informationssicherheit!

Konstantin Ziouras Blog Artikel

Wenn die Kennzahl zum Ziel wird – eine kleine Parabel über KPI und Wirksamkeit

Wenn die Kennzahl zum Ziel wird – eine kleine Parabel über KPI und Wirksamkeit

ISMS-Wirksamkeit messen – Ein Mindestmaß an Zielen, KPI und Metriken

ISMS-Wirksamkeit messen – Ein Mindestmaß an Zielen, KPI und Metriken

Software Testing und Test Management nach ISTQB - International Software Testing Qualifications Board

Software Testing und Test Management nach ISTQB - International Software Testing Qualifications Board

Anforderungsmanagement nach IREB - International Requirements Engineering Board

Anforderungsmanagement nach IREB - International Requirements Engineering Board

Requirements Engineering als Qualitäts- und Sicherheitsfaktor

Requirements Engineering als Qualitäts- und Sicherheitsfaktor

Unterschiede zwischen EULA, SLA und AVV

Unterschiede zwischen EULA, SLA und AVV

Unterschiede und Parallelen für Bewertungen (Lieferanten, Software, Cloud-Dienstleistern)

Unterschiede und Parallelen bezüglich Bewertungen, bezüglich Lieferanten, Software, Cloud Dienstleistern

Risiken bezüglich Lieferanten

Risiken bezüglich Lieferanten

Lieferanten, Auswahl und Bewertung

Lieferanten, Auswahl und Bewertung

Endpoint Security, einfach erklärt

Endpoint Security, einfach erklärt

Firewall, einfach erklärt

Firewall, einfach erklärt

Docker, einfach erklärt

Docker, einfach erklärt

Was eine KI Richtlinie berücksichtigen sollte

KI-Richtlinie 2026:

﻿ Was eine moderne AI Policy für Unternehmen regeln sollte

Cryptographic Bill of Material

Cryptographic Bill of Material (CBOM, CryptoBOM, Crypto SBOM)

SBOM - Software Bill of Materials einfach erklärt

SBOM? einfach erklärt

Zielmatrix für Integrierte Management Systeme ISMS, QMS, Datenschutz

Zielmatrix für Integrierte Management Systeme ISMS, QMS, Datenschutz

Qualitätsmanagement Ziele

Erweiterte Ziele im Qualitätsmanagement (QM)

Informationssicherheitsziele

Informationssicherheitsziele

Was ist ein CVE (Common Vulnerabilities and Exposures)

Was ist ein CVE (Common Vulnerabilities and Exposures)

Marktübersicht Developer Tools & Code Repositories

Marktübersicht Developer Tools & Code Repositories

Wichtige Entscheidungskriterien für Developer Tools & Code Repositories

Wichtige Entscheidungskriterien für Developer Tools & Code Repositories

Übersicht: IEC 62443 – Industrielle Cyber-Sicherheit

Übersicht: IEC 62443 – Industrielle Cyber-Sicherheit

Entscheidungskriterien für KI Nutzung

Entscheidungskriterien für KI Tools & KI Plattformen

Tools für Informationssicherheit EDR, XDR, SIEM, SOAR

EDR vs. XDR vs. SIEM vs. SOAR – Die wichtigsten Unterschiede

Entscheidungskriterien / Bewertungskriterien für Pen Test Tools & Angebote

Entscheidungskriterien / Bewertungskriterien für Pen Test Tools & Angebote

Wichtige Entscheidungskriterien für Developer Tools & Code Repositories

Wichtige Entscheidungskriterien für Developer Tools & Code Repositories

Interne Audits als wirksames Instrument

Die Macht von Internen Audits

Anforderungen die aus dem Klimawandel resultieren (AMD1:2024)

Anforderungen durch den Klimawandel

Prozesslandschaft

Risikobetrachtung nach der Bow-Tie-Methode

Turtle Prozessdiagramm und Ideale Prozessbeschreibung

Turtle Prozessdiagramm und ideale Prozessbeschreibung

Ein Bild sagt mehr als tausend Worte

Mögliche Inhalte einer Prozessbeschreibung / Verfahrensanweisung

risiko management nach iso 27001

Was eine moderne AI Policy für Unternehmen regeln sollte