# Cyber Academy. Full content dump (Deutsch) > GRC & cybersecurity certification training. Led by Christophe Mazzola (a practicing CISO) alongside a small team of practitioners. > Canonical URL: https://cyberacademy.net/de/ > Author: Christophe Mazzola (https://cyberacademy.net/de/christophe) > Index: https://cyberacademy.net/de/llms.txt > Other languages: https://cyberacademy.net/llms-full.txt | https://cyberacademy.net/fr/llms-full.txt | https://cyberacademy.net/es/llms-full.txt | https://cyberacademy.net/it/llms-full.txt | https://cyberacademy.net/de/llms-full.txt | https://cyberacademy.net/pt/llms-full.txt === # PILLAR PAGES # NIS 2: der Leitfaden, der Ihre rechtliche Beobachtung ersetzt. **URL:** https://cyberacademy.net/de/resources/pillars/nis-2 **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition NIS 2 (Richtlinie (EU) 2022/2555) ist die EU-Richtlinie, die Vorstände für Cybersicherheit in die Pflicht nimmt. Mittelgroße und größere Einrichtungen in 18 gelisteten Sektoren fallen in den Anwendungsbereich. Bei einem erheblichen Vorfall: 24-Stunden-Frühwarnung, 72-Stunden-Meldung, vollständiger Bericht nach einem Monat. Sanktionen bis zu 10 Millionen Euro oder 2 % des weltweiten Umsatzes für wesentliche Einrichtungen. Seit Oktober 2024 in den Mitgliedstaaten uneinheitlich umgesetzt. ## TL;DR - Im Anwendungsbereich: 18 Sektoren, mittelgroße (50+ Vollzeitkräfte / 10 Mio.+ Umsatz) und größere Einrichtungen. Zwei Kategorien, wesentlich und wichtig, mit unterschiedlicher Aufsichtsintensität. - Zehn Risikomanagementmaßnahmen für die Cybersicherheit nach Artikel 21. Die Richtlinie sagt, was zu tun ist; ISO 27001 ist das gängigste Wie. - Meldung von Vorfällen: 24-Stunden-Frühwarnung, 72-Stunden-Meldung, vollständiger Bericht nach einem Monat. Legen Sie den Ablauf fest, bevor Sie ihn brauchen. - Persönliche Haftung und Verantwortlichkeit der Leitung sind nun ausdrücklich geregelt. Der Vorstand steht in der Pflicht, nicht nur der CISO. - Der Stand der Umsetzung variiert von Land zu Land; prüfen Sie Ihre nationale Behörde, bevor Sie davon ausgehen, dass der EU-Text unverändert gilt. ## Full content ## Klären, ob und in welcher Kategorie Sie in den Anwendungsbereich fallen Der Anwendungsbereich ist die Frage, die alles andere entscheidet, klären Sie ihn also zuerst und halten Sie die Begründung schriftlich fest. NIS 2 gilt für Einrichtungen, die in einem der 18 gelisteten Sektoren tätig sind und zugleich einen Größenschwellenwert erreichen. Die Grundregel ist die Untergrenze für mittlere Unternehmen: mindestens 50 Beschäftigte oder Jahresumsatz und Bilanzsumme über 10 Millionen Euro. Unterhalb dieser Schwelle fallen Sie in der Regel heraus, aber nicht immer: Die Richtlinie bezieht bestimmte Anbieter unabhängig von der Größe ein, wenn der Dienst kritisch genug ist (zum Beispiel DNS-Anbieter, Register für Domänennamen oberster Stufe sowie einige Anbieter öffentlicher elektronischer Kommunikation und Vertrauensdienste). Die beiden Kategorien, wesentlich und wichtig, sind nicht zwei Listen, aus denen Sie wählen. Sie ergeben sich aus Ihrem Sektor und Ihrer Größe. Die Sektoren mit hoher Kritikalität (Energie, Verkehr, Bankwesen, Finanzmarktinfrastrukturen, Gesundheit, Trinkwasser, Abwasser, digitale Infrastruktur, öffentliche Verwaltung, Weltraum) bringen bei den größeren Größen wesentliche Einrichtungen hervor; die übrigen gelisteten Sektoren sowie kleinere Einrichtungen in den hochkritischen Sektoren werden im Allgemeinen als wichtig eingestuft. Die praktische Folge ist die Aufsichtsintensität, nicht ein milderer Pflichtenkatalog: Die Sicherheitsmaßnahmen und die Meldefristen sind für beide Kategorien gleich. > **Machen Sie den Scope-Test auf dem Papier, und behalten Sie ihn** Der häufige Fehler besteht darin, die Frage "Fallen wir in den Anwendungsbereich?" wie ein Flurgespräch zu behandeln. Führen Sie den Test ausdrücklich durch: Sektor, Größe und jeder größenunabhängige Auslöser, mit den Zahlen, die in jede Antwort eingeflossen sind. Eine nationale Behörde, die anderer Meinung ist, wird fragen, wie Sie zu dem Schluss gekommen sind, nicht erfasst zu sein, und "wir dachten, es gelte nicht" ist keine haltbare Position, wenn die Haftung bei der Leitung liegt. ## Wesentlich vs. wichtig: wo die beiden Kategorien tatsächlich auseinandergehen Beide Kategorien tragen dieselben Maßnahmen nach Artikel 21 und dieselbe Meldefrist für Vorfälle. Was sich ändert, ist, wie die Aufsichtsbehörde Sie beobachtet und was sie tun kann, wenn etwas schiefläuft. Wesentliche Einrichtungen unterliegen einer proaktiven Aufsicht ex ante: Eine Behörde kann ohne Abwarten eines Vorfalls prüfen und Nachweise verlangen. Wichtige Einrichtungen werden reaktiv beaufsichtigt, ex post, das heißt, die Prüfung folgt typischerweise einem Vorfall oder einer glaubhaften Beschwerde. Auch die Bußgeldobergrenzen unterscheiden sich, und diese Lücke ist der am häufigsten genannte Grund, Ihre Kategorie frühzeitig zu bestätigen. **NIS-2-Aufsicht und Sanktionen nach Einrichtungskategorie** | Dimension | Wesentliche Einrichtungen | Wichtige Einrichtungen | | --- | --- | --- | | Aufsichtsmodell | Proaktiv (ex ante): Inspektionen und Nachweisanforderungen jederzeit | Reaktiv (ex post): ausgelöst durch einen Vorfall oder eine Beschwerde | | Maximale Geldbuße | Mindestens 10 Millionen Euro oder 2 % des gesamten weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist | Mindestens 7 Millionen Euro oder 1,4 % des gesamten weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist | | Sicherheitspflichten (Artikel 21) | Alle zehn Maßnahmen gelten | Alle zehn Maßnahmen gelten (identisch) | | Meldefrist | 24 Std. / 72 Std. / 1 Monat (identisch) | 24 Std. / 72 Std. / 1 Monat (identisch) | | Verantwortlichkeit der Leitung | Ausdrücklich; Gremien können haftbar gemacht werden, Einzelpersonen können vorübergehende Leitungsverbote treffen | Ausdrücklich; persönliche Haftung gilt, Leitungsverbote sind im Allgemeinen wesentlichen Einrichtungen vorbehalten | Lesen Sie die Tabelle so, wie es eine Prüferin tun wird: Die Maßnahmen und Fristen sind für alle nicht verhandelbar, sodass die Kategorie Ihnen vor allem sagt, wie viel Fehlerspielraum Sie haben, bevor jemand vorbeischaut. Wesentliche Einrichtungen sollten davon ausgehen, dass eine Inspektion an einem ruhigen Dienstag stattfinden kann. Wichtige Einrichtungen sollten davon ausgehen, dass die erste echte Prüfung ein laufender Vorfall sein wird, der schlechteste Moment, um festzustellen, dass Ihre Nachweise dünn sind. ## Die zehn Maßnahmen nach Artikel 21, und warum ISO 27001 die übliche Antwort ist Artikel 21 Absatz 2 listet zehn Kategorien von Risikomanagementmaßnahmen für die Cybersicherheit auf, die jede in den Anwendungsbereich fallende Einrichtung im Verhältnis zu ihrem Risiko umsetzen muss. Die Richtlinie beschreibt Ergebnisse, nicht Kontrollen, und das ist Absicht: Sie sagt Ihnen, was abgedeckt werden muss, und überlässt Ihnen das Wie. 1. Konzepte für die Risikoanalyse und die Sicherheit von Informationssystemen. 1. Bewältigung von Sicherheitsvorfällen (Erkennung, Reaktion und die nachstehenden Meldepflichten). 1. Aufrechterhaltung des Betriebs, einschließlich Backup-Management und Wiederherstellung nach einem Notfall, sowie Krisenmanagement. 1. Sicherheit der Lieferkette, einschließlich der Sicherheit der Beziehungen zu direkten Lieferanten und Diensteanbietern. 1. Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen, einschließlich Schwachstellenbehandlung und -offenlegung. 1. Konzepte und Verfahren zur Bewertung der Wirksamkeit der Maßnahmen. 1. Grundlegende Verfahren der Cyberhygiene und Sicherheitsschulungen. 1. Konzepte und Verfahren für Kryptografie und, soweit angemessen, Verschlüsselung. 1. Sicherheit des Personals, Konzepte für die Zugriffskontrolle und das Management von Anlagen. 1. Multi-Faktor-Authentifizierung, gesicherte Kommunikation und, soweit angemessen, gesicherte Notfallkommunikation. Stellt man diese Liste neben einen Kontrollsatz aus Anhang A, ist die Überschneidung offensichtlich. Deshalb ist in der Praxis der häufigste Weg zur nachweisbaren Konformität ein Informationssicherheits-Managementsystem nach ISO 27001. NIS 2 benennt die Ergebnisse; ISO 27001 liefert Ihnen das Managementsystem, die Disziplin der Risikobehandlung und die dokumentierten Nachweise, die sich ohne viel Übersetzungsaufwand auf neun der zehn Kategorien abbilden lassen. Sie brauchen streng genommen kein Zertifikat, um NIS 2 zu erfüllen, aber die ISMS-Struktur ist der sauberste Weg, die Aufzeichnungen zu erstellen, die eine Behörde erwartet. Der schnellste Weg für ein Team, sowohl die Verpflichtung als auch die Umsetzung zu verinnerlichen, besteht darin, die regulatorische Sicht mit der Umsetzungssicht zu verbinden: der Kurs NIS 2 Directive Lead Implementer für das Programm selbst und der Kurs ISO 27001 Lead Implementer, um das ISMS aufzubauen, das den Großteil der Last aus Artikel 21 trägt. > **Einmal zuordnen, für immer pflegen** Erstellen Sie eine einzige Matrix von Kontrollen zu Anforderungen, die Ihre Anwendbarkeitserklärung (SoA) nach ISO 27001 den zehn Kategorien aus Artikel 21 gegenüberstellt. Wenn eine nationale Behörde fragt, wie Sie die Sicherheit der Lieferkette oder die Kryptografie abdecken, verweisen Sie auf eine Zeile, anstatt die Argumentation unter Druck neu zu rekonstruieren. Pflegen Sie sie als lebendes Dokument, nicht als einmalige Zuordnungsübung. ## Die Meldefrist: 24 Stunden, 72 Stunden, ein Monat Die Meldepflicht wird bei einem erheblichen Vorfall ausgelöst, also einem, der schwerwiegende Betriebsstörungen oder finanzielle Verluste verursacht hat oder verursachen kann oder der andere durch erhebliche materielle oder immaterielle Schäden beeinträchtigt hat. Die Frist läuft dann in drei Stufen gegenüber Ihrem nationalen CSIRT oder der zuständigen Behörde. - 24 Stunden: eine Frühwarnung. Geben Sie an, ob Sie vermuten, dass der Vorfall rechtswidrig oder böswillig ist und ob er grenzüberschreitende Auswirkungen haben könnte. Das ist ein Hinweis, kein forensischer Bericht. - 72 Stunden: eine Meldung des Vorfalls. Ergänzen Sie die Frühwarnung um eine erste Einschätzung, einschließlich Schwere, Auswirkungen und etwaiger Kompromittierungsindikatoren, die Ihnen vorliegen. - Ein Monat: ein Abschlussbericht. Eine vollständige Darstellung des Vorfalls, seiner wahrscheinlichen Ursache, der ergriffenen Abhilfemaßnahmen und etwaiger grenzüberschreitender Auswirkungen. Dauert der Vorfall nach einem Monat noch an, legen Sie einen Fortschrittsbericht und beim Abschluss einen Abschlussbericht vor. Die Fristen wirken großzügig, bis man sie auf einen echten Vorfall überträgt. Die 24-Stunden-Warnung fällt an, während Sie noch bestätigen, was passiert ist, also muss der Ablauf vorab definiert sein: Wer entscheidet, dass ein Vorfall "erheblich" ist, wer verfasst die Frühwarnung, wer hat die Befugnis zur Einreichung und an welches Portal oder welchen Kontakt geht sie in jedem Mitgliedstaat, in dem Sie tätig sind. Üben Sie es. Eine Tabletop-Übung, die mit einer gegen die Uhr verfassten Entwurfs-Frühwarnung endet, ist mehr wert als jedes Richtliniendokument über die Meldung. ## Haftung der Leitung und die Fehler, die im Prüfungsraum auftauchen NIS 2 verlagert die Verantwortlichkeit nach oben. Leitungsorgane müssen die Risikomanagementmaßnahmen für die Cybersicherheit billigen, ihre Umsetzung überwachen und Schulungen absolvieren, damit sie Risiken selbst erkennen können. Verstöße können namentlich genannten Einzelpersonen zugerechnet werden, und bei wesentlichen Einrichtungen können Behörden vorübergehende Verbote für Einzelpersonen verhängen, Leitungsfunktionen auszuüben. Der Vorstand steht in der Pflicht, und "der CISO kümmert sich um die Sicherheit" ist gegenüber einer Aufsichtsbehörde keine vollständige Antwort mehr. Die wiederkehrenden Fehler, die wir sehen, sind selten exotisch. Sie sind vorhersehbar, und sie sind vermeidbar: - Die Umsetzung als einheitlich behandeln. Die Richtlinie wird in nationales Recht umgesetzt, und die Fristen, Schwellenwerte, Registrierungspflichten und Meldeportale variieren von Land zu Land. Prüfen Sie für jeden Mitgliedstaat, in dem Sie tätig sind, die nationale Behörde, bevor Sie davon ausgehen, dass der EU-Text unverändert gilt. - Die Registrierungs- und Selbstidentifizierungspflicht ignorieren. Viele Mitgliedstaaten verlangen, dass in den Anwendungsbereich fallende Einrichtungen sich bei der zuständigen Behörde registrieren. Im Anwendungsbereich, aber nicht registriert zu sein, ist eine eigene Beanstandung, unabhängig von jeder Sicherheitslücke. - Zu wenig in die Sicherheit der Lieferkette investieren. Sie ist eine der zehn Maßnahmen, und sie ist der Bereich, in dem die größten Einrichtungen am stärksten exponiert sind. Ein dünner Lieferanten-Risikoprozess ist eine sichtbare Schwäche. - Kategorien mit Pflichten verwechseln. Wichtige Einrichtungen nehmen manchmal an, dass leichtere Aufsicht leichtere Pflichten bedeutet. Das tut sie nicht: Dieselben Maßnahmen und dieselbe Meldefrist gelten. - Kein eingeübter Meldeablauf. Die 24-Stunden-Warnung ist die am häufigsten versäumte Pflicht, weil niemand für die Entscheidung und den Entwurf zuständig war, bis der Vorfall es erzwang. Wenn Ihr Team sich bei Anwendungsbereich, Kategorien und Pflichten orientieren muss, bevor es sich auf eine Umsetzung festlegt, ist der Kurs NIS 2 Directive Foundation der richtige Ausgangspunkt; gehen Sie zu den Tracks Lead Implementer und ISO 27001 über, sobald Sie das Programm selbst dimensionieren. NIS 2 wirkt mit anderen EU-Regelwerken zusammen (DORA regelt die operationelle Resilienz des Finanzsektors und hat dort als die speziellere Regel im Allgemeinen Vorrang; der AI Act fügt eigene Pflichten für KI-Systeme hinzu), klären Sie also, welches Regelwerk für eine bestimmte Pflicht führend ist, anstatt denselben Vorfall doppelt zu melden oder, schlimmer noch, gar nicht. Im Zweifel ist die sichere Haltung diejenige, die die Richtlinie selbst belohnt: dokumentierte Entscheidungen, eine gepflegte Kontrollzuordnung und ein Meldeablauf, den Sie durchgespielt haben, bevor Sie ihn brauchten. ## FAQ ### Falle ich in den Anwendungsbereich von NIS 2? Zwei Filter: Sektor und Größe. Sie müssen in einem der 18 gelisteten Sektoren tätig sein (Energie, Verkehr, Finanzwesen, Gesundheit, digitale Infrastruktur, öffentliche Verwaltung, Weltraum, Lebensmittel, Chemie, Postdienste, Herstellung kritischer Produkte, Forschung, Abfallwirtschaft sowie einige weitere). Und Sie müssen den Größenschwellenwert erreichen: 50+ Beschäftigte oder 10 Millionen Euro Jahresumsatz. Darunter fallen Sie standardmäßig aus dem Anwendungsbereich heraus, mit nationalen Ausnahmen für kritische Einrichtungen jeder Größe. Zwei Kategorien innerhalb des Anwendungsbereichs: Wesentliche Einrichtungen (Energie, Verkehr, Bankwesen, Finanzmarktinfrastrukturen, Gesundheit, Trinkwasser, Abwasser, digitale Infrastruktur, Verwaltung von IKT-Diensten B2B, öffentliche Verwaltung, Weltraum) unterliegen einer strengeren Aufsicht und höheren Sanktionen. Wichtige Einrichtungen (Post, Abfall, Chemie, Lebensmittel, verarbeitendes Gewerbe, digitale Anbieter, Forschung) unterliegen einer leichteren Aufsicht, aber denselben Sicherheitspflichten. ### Was sind die zehn Maßnahmen nach Artikel 21? Artikel 21 Absatz 2 listet zehn Risikomanagementmaßnahmen für die Cybersicherheit auf: (a) Konzepte für die Risikoanalyse und die Sicherheit von Informationssystemen; (b) Bewältigung von Sicherheitsvorfällen; (c) Aufrechterhaltung des Betriebs und Krisenmanagement; (d) Sicherheit der Lieferkette; (e) Sicherheit bei Erwerb, Entwicklung und Wartung; (f) Konzepte und Verfahren zur Bewertung der Wirksamkeit der Risikomanagementmaßnahmen für die Cybersicherheit; (g) grundlegende Verfahren der Cyberhygiene und Schulungen zur Cybersicherheit; (h) Konzepte für Kryptografie und Verschlüsselung; (i) Sicherheit des Personals, Konzepte für die Zugriffskontrolle und das Management von Anlagen; (j) Einsatz von Multi-Faktor-Authentifizierung, gesicherter Sprach-, Video- und Textkommunikation und gesicherter Notfallkommunikation. Die Richtlinie schreibt nicht vor, wie jede Maßnahme umzusetzen ist. ISO 27001 lässt sich sauber auf alle zehn abbilden; NIST CSF und CIS Controls decken die meisten ab. Wählen Sie ein Rahmenwerk, dokumentieren Sie die Zuordnung, und die Aufsichtsbehörde ist zufrieden. ### Wie sieht der Zeitplan für die Meldung von Vorfällen aus? Bei einem erheblichen Vorfall gibt es drei Fristen: 24-Stunden-Frühwarnung (erste Einschätzung, ob der Vorfall vermutlich auf rechtswidrige oder böswillige Handlungen zurückzuführen ist, mögliche grenzüberschreitende Auswirkungen); 72-Stunden-Meldung (umfassendere Einschätzung, Kompromittierungsindikatoren); Abschlussbericht nach einem Monat (ausführliche Beschreibung des Vorfalls, Schwere, Auswirkungen, ergriffene Abhilfemaßnahmen, soweit verfügbar eine Ursachenanalyse). Ein erheblicher Vorfall ist einer, der schwerwiegende Betriebsstörungen oder finanzielle Verluste verursacht hat oder verursachen kann oder andere durch erhebliche materielle oder immaterielle Schäden beeinträchtigt. Die Schwellenwerte werden von den nationalen Behörden präzisiert; prüfen Sie Ihre. ### Wie hoch sind die Sanktionen? Wesentlichen Einrichtungen drohen Geldbußen von bis zu 10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes, je nachdem, welcher Betrag höher ist. Wichtigen Einrichtungen drohen bis zu 7 Millionen Euro oder 1,4 % des weltweiten Jahresumsatzes. Nationale Behörden können auch nichtfinanzielle Sanktionen verhängen: Anordnungen zur Einhaltung, öffentliche Bekanntmachung der Verstöße, vorübergehende Verbote für Leitungspersonen, ihre Funktion auszuüben. Sanktionen sind nicht der einzige Durchsetzungshebel. Aufsichtsdialog, Audits und Anordnungen zur Durchführung konkreter Abhilfemaßnahmen liegen alle unterhalb der Bußgeldschwelle und sind in der Praxis häufiger. ### Wie wirkt NIS 2 mit DORA und dem AI Act zusammen? Für Finanzunternehmen ist DORA lex specialis in IKT-Fragen: Wo DORA gilt, geht es bei den IKT-bezogenen Bestimmungen NIS 2 vor. Finanzunternehmen wenden NIS 2 weiterhin für die nicht IKT-bezogenen Themen an, die von der Richtlinie erfasst werden. Der AI Act läuft parallel; er regelt KI-Systeme, nicht Cybersicherheitsprogramme. Wenn Sie Hochrisiko-KI-Systeme in einem kritischen Sektor betreiben, unterliegen Sie beidem: NIS 2 für die Cybersicherheits-Grundlinie, dem AI Act für die KI-Konformitätsarbeit. ## Official sources - [EUR-Lex, Directive (EU) 2022/2555 (NIS 2)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) - [ENISA, NIS 2 hub](https://www.enisa.europa.eu/topics/cybersecurity-policy/nis-directive-new) - [ANSSI, Transposition NIS 2 (France)](https://cyber.gouv.fr/nis-2) --- # DORA: was Ihr RSSI Ihnen nicht gesagt hat. **URL:** https://cyberacademy.net/de/resources/pillars/dora **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition DORA (Regulation (EU) 2022/2554) ist die EU-Verordnung, die Finanzunternehmen und ihren kritischen IKT-Drittdienstleistern einen einheitlichen Rahmen für die digitale operationale Resilienz auferlegt. Anwendbar seit dem 17. Januar 2025. Fünf Säulen: IKT-Risikomanagement, Meldung von Vorfällen, Resilienztests einschließlich bedrohungsgeleiteter Penetrationstests, IKT-Drittparteienrisiko, Informationsaustausch. Lex specialis gegenüber NIS 2 bei IKT-Themen. ## TL;DR - Gilt für rund 20 Kategorien von Finanzunternehmen sowie für benannte kritische IKT-Drittdienstleister, seit dem 17. Januar 2025. - Fünf Säulen. Das Drittparteienregister (Säule 4) und die Resilienztests (Säule 3, einschließlich TLPT für bedeutende Unternehmen) sind die operativsten und die am stärksten geprüften. - Für bedeutende Unternehmen: bedrohungsgeleitete Penetrationstests alle drei Jahre, beaufsichtigt von der nationalen Behörde im Rahmen von TIBER-EU. - Kritische IKT-Drittdienstleister werden direkt von den Europäischen Aufsichtsbehörden (ESAs) beaufsichtigt. Ihr Konzentrationsrisiko ist nun auf EU-Ebene relevant. - Kombinieren Sie mit ISO 22301 für das BCMS, ISO 27001 für das IKT-Risikomanagement und Lead Operational Resilience Manager für die der Aufsicht zugewandte Ebene. ## Full content Die meisten Finanzunternehmen haben DORA nicht bei null begonnen. Sie hatten ein ISMS, einen Geschäftsfortführungsplan, eine Auslagerungsrichtlinie und ein Drittparteien-Inventar, das größtenteils aus Beschaffungsverträgen bestand. DORA wirft das nicht weg. Es rahmt es neu, hebt die Messlatte insbesondere bei zwei Säulen an und verschiebt das Gespräch von "Haben Sie eine Kontrolle" zu "Können Sie nachweisen, dass Ihr Dienst weiterläuft, wenn ein IKT-Dienstleister ausfällt." Auf dieser Seite geht es um diese Lücke: wie die fünf Säulen tatsächlich im Betrieb ankommen, was eine Aufsichtsbehörde zuerst öffnet und wo Teams Zeit verlieren. ## Die fünf Säulen und wer bei jeder geprüft wird Die Verordnung beruht auf fünf Säulen. In der Praxis sind sie nicht gleich gewichtet. Säule 1 ist grundlegend, aber jedem vertraut, der ein ISMS betreibt. Die Säulen 3 und 4 sind es, wo sich die aufsichtliche Aufmerksamkeit konzentriert, weil sie Nachweise erzeugen, die schwer zu fälschen und leicht zu prüfen sind. Die folgende Tabelle ist die Fassung, die wir verwenden, um einen Vorstand zu briefen: was jede Säule verlangt und wer im Unternehmen am Ende am stärksten exponiert ist, wenn die Aufsicht Nachweise verlangt. **Die fünf DORA-Säulen: Anforderung und die bei jeder am stärksten geprüfte Funktion** | Säule | Was sie verlangt | Am stärksten daran geprüft | | --- | --- | --- | | 1. IKT-Risikomanagement | Ein dokumentierter Governance-Rahmen: Erfassung von Vermögenswerten und Abhängigkeiten, Risikoidentifikation, Schutz- und Erkennungskontrollen, Reaktion und Wiederherstellung, mit Verantwortung des Vorstands und einer benannten rechenschaftspflichtigen Funktion. | CISO / RSSI und das Leitungsorgan, das aktive Aufsicht nachweisen muss, nicht Delegation. | | 2. IKT-Vorfallmanagement und -meldung | IKT-bezogene Vorfälle anhand harmonisierter Kriterien klassifizieren, dann schwerwiegende Vorfälle der zuständigen Behörde nach dem Zeitplan Erstmeldung / Zwischenmeldung / Abschlussmeldung melden. | Incident Response und das SOC sowie diejenigen, die für aufsichtliche Meldungen zuständig sind. | | 3. Tests der digitalen operationalen Resilienz | Ein risikobasiertes Testprogramm; für bedeutende Unternehmen bedrohungsgeleitete Penetrationstests (TLPT) an produktiven Live-Systemen mindestens alle drei Jahre. | Security-Testing, Red Team und die fachlichen Verantwortlichen der in den Anwendungsbereich gezogenen Systeme. | | 4. IKT-Drittparteienrisiko | Ein Register aller IKT-Drittparteienvereinbarungen, Vertragsklauseln zu Prüfung, Ausstieg und Unterauftragsvergabe sowie eine Konzentrationsrisikoanalyse. | Beschaffung, Lieferantenmanagement und Recht, die das Register und die Verträge auf Anforderung vorlegen müssen. | | 5. Informationsaustausch | Freiwillige Vereinbarungen zum Austausch von Cyber-Bedrohungsinformationen unter Finanzunternehmen. | Threat Intelligence; die leichteste Säule und selten allein eine Feststellung. | ## Was zuerst zu tun ist Der Fehler besteht darin, mit der Aktualisierung der Richtlinien zu beginnen, weil das die bequeme Arbeit ist. Beginnen Sie stattdessen mit den beiden Artefakten, die eine Aufsicht schriftlich anfordern kann und deren korrekter Aufbau am längsten dauert: das IKT-Drittparteienregister und die Zuordnung kritischer oder wichtiger Funktionen zu den IKT-Vermögenswerten und Dienstleistern, die sie stützen. Alles andere hängt von dieser Zuordnung ab. Sie können den Umfang der Resilienztests nicht festlegen, Sie können die Schwere von Vorfällen nicht klassifizieren und Sie können nicht über Konzentrationsrisiko nachdenken, bevor Sie wissen, welche Funktionen kritisch sind und wovon sie abhängen. Eine praktikable Abfolge für die ersten 90 Tage: 1. Definieren Sie Ihre kritischen oder wichtigen Funktionen. Das ist eine geschäftliche Entscheidung, keine sicherheitstechnische. Sie bestimmt den Umfang fast jeder anderen Verpflichtung. 1. Ordnen Sie jede kritische Funktion den IKT-Dienstleistungen zu, intern und ausgelagert, auf die sie angewiesen ist. Das ist Ihr Abhängigkeitsgraph. 1. Bauen Sie das Drittparteienregister aus diesem Graphen auf, nicht aus der Beschaffungstabelle. Das Register muss Vereinbarungen beschreiben, die Funktionen stützen, einschließlich der Unterauftragnehmer in der Kette. 1. Schließen Sie die von DORA geforderten vertraglichen Lücken (Prüfungsrechte, Ausstiegsstrategien, Transparenz der Unterauftragsvergabe, Zusammenarbeit bei Vorfällen) zuerst bei den Vereinbarungen, die kritische Funktionen stützen. 1. Erst danach formalisieren Sie den IKT-Risikomanagementrahmen und das Testprogramm, weil beide nun einen definierten Umfang haben, gegen den sie arbeiten können. > **Das Register vor den Richtlinien einordnen** Wenn Sie begrenzte Kapazität haben, sind das Register und die Zuordnung kritischer Funktionen die tragende Arbeit. Sie erschließen die Klassifizierung von Vorfällen, den Testumfang und die Konzentrationsanalyse. Eine wunderschön geschriebene IKT-Risikorichtlinie ohne darunterliegende Abhängigkeitskarte ist das Erste, was ein Prüfer durchschaut. ## Das IKT-Drittparteienregister (Säule 4) in der Praxis Das Register ist keine Lieferantenliste. Es ist ein strukturierter Satz von Informationsregistern, den das Unternehmen pflegt und den die zuständigen Behörden in einer definierten Vorlage einsammeln, um die IKT-Konzentration über den gesamten Finanzsektor hinweg zu erkennen. Das ändert, wie Sie es aufbauen. Ein Feld, das für den internen Gebrauch "nah genug" ist, wird zu einem Datenqualitätsproblem, wenn es auf nationaler und EU-Ebene aggregiert wird. Drei Dinge verursachen den größten Teil des Aufwands. Erstens ist die Einheit die vertragliche Vereinbarung, nicht der Lieferant. Ein Dienstleister kann hinter mehreren Vereinbarungen stehen, und eine Vereinbarung kann mehrere Funktionen stützen. Sie beschreiben einen Viele-zu-viele-Graphen, und ihn in eine Zeile pro Lieferant zu flachzudrücken, wird die Prüfung nicht überstehen. Zweitens müssen Sie der Kette folgen. Das Register muss Unterauftragnehmer erfassen, die eine kritische oder wichtige Funktion tatsächlich stützen, was bedeutet, dass Ihre Sicht auf den Dienstleister über Ihre direkte Gegenpartei hinausreichen muss. Wenn Ihr Vertrag Ihnen nicht das Recht gibt zu wissen, wer die vierte Partei ist, dann ist das eine zu schließende vertragliche Lücke, kein leer zu lassendes Feld. Drittens ist das Funktionskritikalitäts-Kennzeichen bei jeder Vereinbarung das Feld, an dem sich alles andere ausrichtet. Markieren Sie zu viel als kritisch, ertränken Sie Ihre eigenen Tests und vertraglichen Nachbesserungen; markieren Sie zu wenig, untertreiben Sie das Konzentrationsrisiko und führen die Aufsicht in die Irre. Treffen Sie die Kritikalitätsbewertung einmal richtig, auf Funktionsebene, und lassen Sie sie sich fortpflanzen. > **Das Konzentrationsrisiko ist nun ein Anliegen auf EU-Ebene** Wenn ein einzelner Cloud- oder Kernbanken-Dienstleister kritische Funktionen über viele Unternehmen hinweg stützt, kann dieser Dienstleister als kritischer IKT-Drittdienstleister benannt und direkt von den ESAs beaufsichtigt werden. Ihr Register ist einer der Eingaben, die dies sichtbar machen. Behandeln Sie die Datenqualität im Register als aufsichtliche Exposition, nicht als Verwaltungsaufgabe. ## Bedrohungsgeleitete Penetrationstests (Säule 3): wie der Raum tatsächlich aussieht TLPT ist die Säule, die Menschen überrascht, weil sie sich von einem routinemäßigen Penetrationstest unterscheidet. Sie ist intelligence-geleitet, läuft gegen produktive Live-Systeme, ist auf die kritischen oder wichtigen Funktionen zugeschnitten und wird nach der TIBER-EU-Methodik unter Beteiligung der nationalen Behörde durchgeführt. Bedeutende Unternehmen führen sie mindestens in einem Dreijahreszyklus durch. Sie ähnelt eher einer beaufsichtigten Red-Team-Übung als einem Schwachstellenscan, und das entscheidende Ergebnis ist nicht die Liste der Feststellungen; es ist der Nachweis, dass Erkennung und Reaktion funktioniert haben, oder die ehrliche Darlegung, warum nicht. Drei Realitäten, die Teams unterschätzen: - Der Umfang wird von kritischen Funktionen bestimmt, nicht davon, was bequem zu testen ist. Wenn eine Funktion einen ausgelagerten Dienstleister umfasst, muss dieser Dienstleister möglicherweise in den Anwendungsbereich aufgenommen werden, was bedeutet, dass die Mitwirkung des Dienstleisters im Voraus vertraglich gesichert werden muss. - Das Blue Team wird in der Regel nicht informiert. Der Wert liegt darin, echte Erkennung und Reaktion zu testen, sodass ein TLPT, vor dem die Verteidiger gewarnt wurden, den größten Teil seines Sinns verloren hat. Das hat organisatorische Folgen, die Sie einplanen, nicht mitten in der Übung entdecken. - Tester und Threat-Intelligence-Anbieter müssen Anforderungen an Kompetenz und Unabhängigkeit erfüllen, und die Behörde überprüft den Prozess. Sie können nicht einfach den jährlichen Pentest des Vorjahres als TLPT umetikettieren. Wenn Ihr Unternehmen unter der Bedeutsamkeitsschwelle liegt, führen Sie kein TLPT durch, schulden aber dennoch ein risikobasiertes Testprogramm: Schwachstellenbewertungen, szenariobasierte Tests und Resilienztests des Wiederherstellungspfads. Der Kurs Lead Operational Resilience Manager ist genau um diese der Aufsicht zugewandte Test- und Nachweisebene herum aufgebaut, und der Kurs DORA Lead Manager behandelt, wie das gesamte Programm durchgängig gesteuert wird. ## DORA als lex specialis gegenüber NIS 2 für Banken Banken und die meisten anderen Finanzunternehmen fallen in den Anwendungsbereich sowohl von NIS 2 als auch von DORA. Die beiden überschneiden sich stark bei IKT-Risiko, Vorfallmeldung und Lieferkettensicherheit, was die naheliegende Befürchtung weckt, alles doppelt zu tun. DORA löst dies: Bei den IKT-Angelegenheiten, die es regelt, ist DORA lex specialis. Die spezielle Regel verdrängt die allgemeine. Wo DORA die Pflicht zum IKT-Risikomanagement und zur Vorfallmeldung festlegt, folgt ein Finanzunternehmen DORA, und die zuständigen Behörden sollten für dasselbe IKT-Thema nicht zusätzlich die entsprechende NIS-2-Anforderung anwenden. Was dies nicht bedeutet: Es schaltet NIS 2 für ein Finanzunternehmen nicht vollständig ab, und es ändert nicht, wer für IKT-fremde Angelegenheiten Ihre zuständige Behörde ist. Die praktische Entscheidung für eine Bank besteht darin, jede Verpflichtung ihrem maßgeblichen Instrument zuzuordnen: IKT-operationale Resilienz, Vorfallmeldung und IKT-Drittparteienrisiko laufen unter DORA; alles außerhalb von DORA ist Umfang, den Sie gesondert bewerten. Dokumentieren Sie diese Zuordnung. Sie ist die Antwort auf die Frage "Zählen Sie doppelt oder zählen Sie zu wenig", die Prüfer und Auditoren gleichermaßen stellen. > **Die Lex-specialis-Logik ist ein Entscheidungsinstrument, kein Schlupfloch** Nutzen Sie sie, um doppelte Meldungen und widersprüchliche Fristen zu vermeiden, nicht um eine Verpflichtung wegzuargumentieren. Wenn ein IKT-Thema von DORA geregelt wird, erfüllen Sie den DORA-Standard; Sie dürfen sich nicht das weniger anspruchsvolle der beiden Regime aussuchen. ## Häufige Fehler und wo die Kompetenz aufzubauen ist Die wiederkehrenden Fehler sind nicht exotisch. Das Register wird pro Lieferant statt pro Vereinbarung aufgebaut und bricht in dem Moment, in dem die Unterauftragsvergabe relevant wird. Die Kritikalität kritischer Funktionen wird von der IT statt vom Geschäft bewertet, sodass der Umfang von allem Nachgelagerten falsch ist. Schwellenwerte für die Klassifizierung von Vorfällen werden geschrieben, aber nie gegen einen echten Vorfall getestet, sodass das erste schwerwiegende Ereignis zur ersten Probe für den Meldezeitplan wird. Und die Geschäftsfortführung wird als gesondertes ISO-22301-Projekt behandelt statt als der Wiederherstellungsmuskel, den die DORA-Tests trainieren sollen. Dieser letzte Punkt ist wichtig: DORA ersetzt kein Business-Continuity-Managementsystem, es setzt eines voraus. Die Wiederherstellungsziele und der getestete Wiederherstellungspfad, die Ihnen ein BCMS gibt, sind das, was die Resilienztests validieren. Bauen Sie das BCMS mit dem Kurs ISO 22301 Lead Implementer richtig auf, und es wird zum Substrat, auf dem die Pflichten zur operationalen Resilienz stehen, statt zu einem parallelen Ordner, den niemand öffnet. Wenn Sie von der Verordnung selbst ausgehen, vermittelt der Kurs DORA Foundation dem gesamten Team eine gemeinsame, präzise Lesart der fünf Säulen und des Anwendungsbereichs, bevor jemand das Register oder das Testprogramm anfasst. Von dort aus ist der Kurs DORA Lead Manager die Implementierungs- und Governance-Ebene für die Personen, die den Rahmen verantworten werden, und der Kurs Lead Operational Resilience Manager ist für die Funktion, die vor die Aufsicht treten und zeigen muss, dass Resilienz real ist, nicht nur dokumentiert. ## FAQ ### Wer fällt in den Anwendungsbereich von DORA? Rund 20 Kategorien von Finanzunternehmen: Kreditinstitute, Zahlungsinstitute, E-Geld-Institute, Wertpapierfirmen, zentrale Gegenparteien, Handelsplätze, Zentralverwahrer, Erst- und Rückversicherungsunternehmen, Vermittler, Anbieter von Krypto-Dienstleistungen, Kontoinformationsdienstleister, Verwalter alternativer Investmentfonds, Verwaltungsgesellschaften, Datenbereitstellungsdienste, Ratingagenturen, Administratoren kritischer Referenzwerte, Schwarmfinanzierungsdienstleister, Verbriefungsregister. Hinzu kommt ein gesondertes Regime für kritische IKT-Drittdienstleister (CTPPs), die von den ESAs auf Grundlage einer Kritikalitätsbewertung benannt werden. CTPPs unterliegen einer direkten Aufsicht durch ein von den ESAs geleitetes gemeinsames Überwachungsforum. ### Was ist TLPT und wer braucht es? Threat-Led Penetration Testing ist eine aufsichtlich beaufsichtigte Red-Team-Übung, die für bedeutende Finanzunternehmen nach DORA vorgeschrieben ist. Sie baut auf dem TIBER-EU-Rahmen (Threat Intelligence-Based Ethical Red Teaming) auf. Mindestens alle drei Jahre. TLPT ist intelligence-gesteuert (Bedrohungsprofil von einem separaten Intelligence-Team), zielt auf die kritischen oder wichtigen Funktionen des Unternehmens ab und wird von der nationalen Behörde beaufsichtigt. Mehrmonatig, kostspielig und der anspruchsvollste Test, dem sich ein CISO im Finanzsektor stellen wird. ### Wie wirkt DORA mit NIS 2 für Banken zusammen? DORA ist lex specialis bei IKT-Themen. Wo DORA anwendbar ist, geht es bei den IKT-bezogenen Bestimmungen NIS 2 vor. Für IKT-fremde NIS-2-Themen (physische Sicherheit, bestimmte Governance-Aspekte, Umfang der Schulungen) gilt NIS 2 weiterhin parallel. In der Praxis setzt eine Bank, die in den Anwendungsbereich beider fällt, DORA vollständig für IKT-Risiko, Vorfallmeldung, Resilienztests und IKT-Drittparteienrisiko um und liest NIS 2 für die verbleibende Cybersicherheits-Governance-Grundlage. ### Was gehört in das IKT-Drittparteienregister? Article 28 sowie die EBA-RTS zur Unterauftragsvergabe und zum Informationsregister legen die Felder fest. Jede vertragliche Vereinbarung mit einem IKT-Dienstleister wird erfasst mit: Art der Dienstleistungen, Kritikalität, der für das Unternehmen sichtbaren Unterauftragskette, Standort der Dienstleistungen, Datenstandort, Leistungs-SLAs, Ausstiegsstrategie, Governance-Regelungen. Das Register ist das Dokument, nach dem die Aufsichtsbehörde zuerst fragt. Die meisten Finanzunternehmen unterschätzen den Pflegeaufwand; ein veraltetes Register wird als Feststellung behandelt. ### Wie ist das Verhältnis zwischen DORA und ISO 22301? DORA schreibt keine ISO-22301-Zertifizierung vor, aber die BCM- und Disaster-Recovery-Pflichten der Verordnung (Articles 11-12) entsprechen nahezu eins zu eins einem ISO-22301-konformen BCMS. Die meisten Unternehmen, die bereits ein 22301-BCMS betreiben, setzen die DORA-spezifische Test- und Berichtsebene obenauf, ohne die Grundlagen neu aufzubauen. ## Official sources - [EUR-Lex, Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) - [European Banking Authority, DORA hub](https://www.eba.europa.eu/regulation-and-policy/digital-operational-resilience-act) - [ESMA, DORA implementation](https://www.esma.europa.eu/regulation/digital-operational-resilience) --- # ISO 27001: Foundation, Lead Implementer, Lead Auditor, welcher ist der richtige? **URL:** https://cyberacademy.net/de/resources/pillars/iso-27001-foundation-li-la **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition ISO 27001 hat drei Zertifizierungsstufen: Foundation (2 Tage, Vokabular und Struktur), Lead Implementer (5 Tage, das ISMS aufbauen) und Lead Auditor (5 Tage, ein ISMS auditieren). Foundation ist die Voraussetzung für die Senior-Zertifikate. Lead Implementer passt zu Sicherheits- und GRC-Teams, die das ISMS verantworten; Lead Auditor passt zu internen Auditoren und Praktikern von Zertifizierungsstellen. ## TL;DR - Foundation ist die Voraussetzung. Sie vermittelt das Vokabular und das mentale Modell eines Managementsystems. Zwei Tage, einstündige Prüfung. - Lead Implementer (5 Tage) lehrt Sie, das ISMS aufzubauen, die SoA zu schreiben, die Risikobehandlung durchzuführen und den Zyklus der Managementbewertung zu betreiben. - Lead Auditor (5 Tage) lehrt Sie, Audits durch Dritte oder interne Audits zu planen und zu leiten. Eine andere Denkweise: Nachweise, Stichprobenziehung, Interviewtechnik, Berichterstattung. - Die meisten CISOs und Sicherheitsverantwortlichen absolvieren Lead Implementer. Interne Auditoren und Big-Four-Berater absolvieren Lead Auditor. Beides ist über einen Zeitraum von 12 bis 18 Monaten üblich. - Bestehensquoten in von Trainern geleiteten PECB-Kohorten: 99,1 % beim ersten Versuch in unseren Durchführungen; der Marktdurchschnitt liegt je nach Partner bei 80 % bis 85 %. ## Full content ## Die Entscheidung, auf die es wirklich ankommt: Bauen Sie auf oder auditieren Sie? Die drei ISO 27001-Zertifikate sind keine einzelne Leiter, die man der Reihe nach erklimmt. Foundation ist die gemeinsame Grundlage, doch darüber gabelt sich der Weg in zwei verschiedene Tätigkeiten. Die eine Tätigkeit besteht darin, ein Informationssicherheits-Managementsystem (ISMS) innerhalb einer Organisation zu gestalten und zu betreiben. Die andere besteht darin, das ISMS eines anderen anhand des Standards zu prüfen und ein unabhängiges Urteil zu bilden. Die Titel signalisieren das: Lead Implementer ist ein Aufbauender, Lead Auditor ein Prüfender. Die falsche Wahl verschwendet eine Schulungswoche und beschert Ihnen ein Zertifikat, das nicht zur Arbeit vor Ihnen passt. Stellen Sie sich eine Frage, bevor Sie irgendetwas buchen: Werden Sie in den nächsten zwölf Monaten dafür verantwortlich sein, dass ein ISMS existiert und funktioniert, oder dafür, zu beurteilen, ob eines funktioniert? Wenn Sie das Statement of Applicability, den Risikobehandlungsplan und die Managementbewertung verantworten, dann bauen Sie auf. Wenn Sie hereinkommen, Nachweise per Stichprobe prüfen und Feststellungen formulieren, dann auditieren Sie. Das Verb, das Sie an den meisten Tagen ausüben, ist die ganze Entscheidung. So oder so beginnen Sie am selben Punkt. Der ISO 27001 Foundation-Kurs vermittelt Ihnen das Vokabular, die Steuerungsstruktur von Annex A und die Logik des Managementsystems, die beide Senior-Pfade als bereits vorhanden voraussetzen. ## Was jede Prüfung tatsächlich abfragt (jenseits der Broschüre) Die Stufenbeschreibungen nennen Ihnen die Dauer. Sie sagen Ihnen nicht, was die Bewertung belohnt, und genau das bestimmt, wie Sie sich vorbereiten sollten. ### Foundation Foundation ist eine Wissensprüfung. Sie prüft, ob Sie den Standard lesen können, ohne sich zu verlieren: die Kapitel 4 bis 10, den Plan-Do-Check-Act-Zyklus, den Unterschied zwischen einer Maßnahme und einem Maßnahmenziel und wo Annex A im Verhältnis zu den Hauptanforderungen steht. Sie verlangt nicht, dass Sie etwas unter Druck anwenden. Wenn Sie erklären können, warum die SoA sowohl Einschlüsse als auch Ausschlüsse begründen muss, sind Sie bereit. ### Lead Implementer Lead Implementer ist eine Kompetenzprüfung, die um Szenarien herum aufgebaut ist. Sie erhalten eine fiktive Organisation und werden gefragt, was Sie tun würden: wie Sie den Geltungsbereich des ISMS festlegen, wie Sie die Risikobewertung durchführen, was in den Risikobehandlungsplan gehört, wie Sie mit einer nicht konformen Maßnahme umgehen würden. Die Fragen belohnen Urteilsvermögen, nicht Auswendiglernen. Der Lead Implementer-Kurs ist um das vollständige Umsetzungsprojekt herum strukturiert, sodass sich die Prüfungsszenarien wie Arbeit anfühlen, die Sie bereits erledigt haben. ### Lead Auditor Lead Auditor prüft einen anderen Muskel: die Auditmethodik nach ISO 19011, angewandt auf ISO 27001. Die Szenarien versetzen Sie in den Auditraum. Sie entscheiden, welcher Nachweis belegt, dass ein Kapitel erfüllt ist, wie Stichproben zu ziehen sind, wie eine Feststellung zu formulieren ist und wie sie als schwere oder geringfügige Abweichung einzustufen ist. Die Falle, in die Kandidaten tappen, ist, so zu auditieren, wie sie umsetzen würden, also dem Auditierten zu sagen, wie er Dinge beheben soll, anstatt festzustellen, was nicht konform ist. Der Lead Auditor-Kurs schult die Disziplin „Nachweis zuerst, Urteil statt Beratung“, die sowohl die Prüfung als auch reale Audits verlangen. ## Die drei Stufen im direkten Vergleich **ISO 27001-Zertifizierungsstufen im Vergleich** | | Foundation | Lead Implementer | Lead Auditor | | --- | --- | --- | --- | | Kernaufgabe | Den Standard verstehen | Das ISMS aufbauen und betreiben | Ein ISMS auditieren | | Typische Rolle | Alle, die neu in ISO 27001 sind | CISO, Sicherheitsverantwortlicher, GRC-Verantwortlicher | Interner Auditor, Auditor einer Zertifizierungsstelle oder Beratung | | Dauer | 2 Tage | 5 Tage | 5 Tage | | Prüfungsstil | Wissen, kurze Prüfung | Szenariobasiert, angewandtes Urteilsvermögen | Auditmethodik (ISO 19011), Nachweise und Feststellungen | | Wichtiges Ergebnis, das Sie danach liefern können | Den Standard lesen und darin navigieren | Geltungsbereich, SoA, Risikobehandlungsplan, Managementbewertung | Auditplan, Auditprogramm, Feststellungsbericht | | Denkweise | Vokabular und Struktur | Gestalten, betreiben, verbessern | Nachweise, Stichproben, unabhängiges Urteil | | Voraussetzung | Keine | Kenntnisse auf Foundation-Niveau | Kenntnisse auf Foundation-Niveau | ## Voraussetzungen und was der nächste Schritt tatsächlich bringt Foundation ist die Voraussetzung für die Senior-Zertifikate, doch lesen Sie das genau: Die meisten Akkreditierungsschemata verlangen Kenntnisse auf Foundation-Niveau, nicht zwingend ein separates, vorab abgelegtes Foundation-Zertifikat. In der Praxis beginnen die Senior-Kurse mit einer komprimierten Wiederholung der Grundlagen und setzen sie dann voraus. Wenn Sie ohne diese Basis erscheinen, verbringen Sie den ersten Tag mit Aufholen statt mit dem Erlernen der Methode, und die Szenarioarbeit später in der Woche landet auf seichtem Grund. Foundation zuerst abzulegen ist kein bürokratisches Abhaken; es ist das, was den fünftägigen Kurs in voller Tiefe lehren lässt. Was der nächste Schritt bringt, ist Hebelwirkung, nicht nur eine Zeile im Lebenslauf. Foundation verschafft Ihnen die Fähigkeit, an einem ISMS-Gespräch teilzunehmen, ohne den Faden zu verlieren. Lead Implementer verschafft Ihnen die Fähigkeit, dafür verantwortlich zu sein, dass das System existiert: Sie können seinen Geltungsbereich festlegen, die SoA gegenüber einem Auditor verteidigen und den Zyklus betreiben. Lead Auditor verschafft Ihnen Unabhängigkeit: Sie können Feststellungen unterzeichnen, auf die sich eine Zertifizierungsstelle oder ein Vorstand verlässt. Das sind tatsächlich unterschiedliche Formen von Autorität, weshalb es üblich und nützlich ist, beides über zwölf bis achtzehn Monate zu absolvieren. Ein Implementer, der sich auch als Auditor ausgebildet hat, baut ein ISMS, das ein Audit übersteht, weil er weiß, worauf der Auditor achten wird. > **Erst aufbauen, dann auditieren (in der Regel)** Wenn Sie ein ISMS verantworten oder verantworten werden, absolvieren Sie zuerst Lead Implementer. Nachdem Sie den Aufbau durchlaufen haben, ergibt der Auditkurs sofort Sinn, weil Sie wissen, wie ein guter Nachweis aussieht. Die umgekehrte Reihenfolge funktioniert für reine interne Auditoren, die nie eine Maßnahme verantworten werden, aber das ist der Minderheitsfall. Wählen Sie den Pfad, der zu Ihrem Arbeitsalltag passt, nicht den, der seniorer klingt. ## Häufige Fehler, die eine Woche kosten Einige Muster tauchen immer wieder auf, wenn Menschen diese Kurse auswählen oder ablegen. Sie sind vermeidbar. 1. Lead Auditor als die statushöhere Version von Lead Implementer zu betrachten. Er steht nicht darüber; er steht daneben. Ihn aus Prestigegründen zu buchen, wenn Ihre Aufgabe der Aufbau des ISMS ist, verschafft Ihnen eine Fähigkeit, die Sie selten nutzen werden. 1. Die Foundation-Basis zu überspringen, um zwei Tage zu sparen, und dann im Senior-Kurs mehr als zwei Tage zu verlieren, während man Vokabular nachholt und alle anderen es bereits anwenden. 1. Implementer, die durch Erteilen von Ratschlägen auditieren, und Auditoren, die durch Schreiben von Verbesserungsplänen auditieren. Der Auditor stellt fest, was nicht konform ist, und verweist auf das Kapitel; die Behebung obliegt dem Auditierten. Diese Grenze zu überschreiten lässt Prüfungsszenarien scheitern und gefährdet reale Audits. 1. Den Standard mit den Maßnahmen zu verwechseln. Annex A ist ein Referenzkatalog, aus dem Sie über die SoA auswählen. Die zertifizierbaren Anforderungen stehen in den Kapiteln 4 bis 10. Kandidaten, die Maßnahmen auswendig lernen, aber die Managementsystem-Kapitel nicht erklären können, haben in beiden Senior-Prüfungen Schwierigkeiten. ## Die Realität im Auditraum, und warum sie beide Pfade prägt Für welche Seite Sie sich auch ausbilden, stellen Sie sich das Zertifizierungsaudit vor, denn dort treffen die beiden Rollen aufeinander. Der Auditor verlangt Nachweise, dass ein Kapitel erfüllt ist und dass eine ausgewählte Maßnahme so funktioniert, wie die SoA behauptet. Der Implementer muss diesen Nachweis auf Anforderung erbringen: Aufzeichnungen der Risikobewertung, die Behandlungsentscheidungen, das Protokoll der Managementbewertung, die Ergebnisse des internen Audits, die Korrekturmaßnahmen. Nichts beeindruckt einen Auditor; nur Nachweise tun es. Eine Maßnahme, die existiert, aber keine Aufzeichnung hinterlässt, ist für Auditzwecke eine Maßnahme, die nicht existiert. Deshalb verstehen die stärksten Praktiker beide Perspektiven, selbst wenn sie nur eine Tätigkeit ausüben. Der Implementer gestaltet das ISMS so, dass das Erledigen der Arbeit zugleich die Spur erzeugt. Der Auditor liest diese Spur, ohne dass ihm eine Geschichte darüber erzählt wird. Wenn Sie Ihren ersten Kurs wählen, wählen Sie die Rolle, in der Sie leben werden, und planen Sie den zweiten Kurs für den Zeitpunkt, an dem Sie die andere Hälfte des Bildes wollen. Der Standard ist ein System, gesehen von zwei Stühlen aus, und das Zertifikat, das Sie wählen, sollte zu dem Stuhl passen, auf dem Sie sitzen. ## FAQ ### Sollte ich zuerst Lead Implementer oder Lead Auditor absolvieren? Richten Sie sich nach Ihrer Rolle. Wenn Sie das ISMS aufbauen, betreiben oder pflegen (Sicherheitsmanager, GRC-Analyst, CISO einer kleineren Organisation), dann zuerst Lead Implementer. Der Kurs lehrt Sie, die SoA zu schreiben, die Risikobehandlung durchzuführen, die Richtlinien zu erstellen und die Managementbewertung zu betreiben. Wenn Sie auditieren (internes Auditteam, Big-Four-Berater, Auditor einer Zertifizierungsstelle), dann zuerst Lead Auditor. Der Kurs lehrt den Auditzyklus, die Stichprobenziehung von Nachweisen, die Interviewtechnik und die Disziplin, Feststellungen zu formulieren. Beides ist üblich. Die Reihenfolge spielt in diesem Fall keine große Rolle; manche Praktiker gehen erst LI, dann LA, um die operative Tiefe vor der Auditperspektive zu erlangen, andere gehen erst LA, dann LI, um zu verinnerlichen, worauf Auditoren achten, bevor sie aufbauen. ### Ist Foundation wirklich erforderlich? Ja, formal. PECB verlangt Foundation als Voraussetzung für die Prüfungszulassung zu Lead Implementer und Lead Auditor. Die Kohorte selbst dauert zwei Tage und behandelt das mentale Modell eines Managementsystems, die Struktur von ISO 27001:2022 und den Steuerungskatalog von Annex A. Für Senior-Praktiker mit vorheriger ISO 27001-Erfahrung oder einem anderen ISO-Managementsystem-Zertifikat kann die Foundation-Anforderung manchmal über die PECB-Anerkennung gleichwertiger Schulungen erlassen werden. Prüfen Sie das, bevor Sie buchen; wir ordnen Ihren Fall im Erstgespräch ein. ### Wie sieht die Lead Implementer-Prüfung aus? Drei Stunden, Open-Book, online über die PECB-Plattform. Eine Mischung aus Multiple-Choice- und essayartigen Szenariofragen. Bei den Szenariofragen verlieren die meisten Kandidaten Punkte: Sie erhalten den Kontext einer fiktiven Organisation und müssen dann die ISMS-Methodik durchgängig anwenden, den Geltungsbereich definieren, Risiken identifizieren, Maßnahmen vorschlagen, die Struktur der SoA begründen, die Managementbewertung planen. Eine Vorbereitung auf die Methodik vor der Kohorte ist unverzichtbar. ### Wie viel kostet es in Europa im Jahr 2026? Standardpreise für von Trainern geleitete PECB-Kurse in Europa Anfang 2026: Foundation rund 1.200 Euro, Lead Implementer 2.800 bis 3.200 Euro, Lead Auditor 2.800 bis 3.200 Euro. Inbegriffen sind der Kurs, die offiziellen PECB-Materialien, die Zertifizierungsgebühr, die Prüfung, eine Wiederholungsprüfung und das lebenslange Zertifikat. Selbstlernen ist in der Regel 30 % bis 40 % günstiger, aber langsamer im Abschluss. Inhouse-Kohorten werden pro Team statt pro Platz abgerechnet; rechnen Sie mit 12.000 bis 18.000 Euro für eine fünftägige Lead Implementer-Kohorte mit bis zu 12 Lernenden, vor Ort oder virtuell. ### Überschneiden sich PECB- und ISACA-Zertifikate? Sie decken verwandte, aber unterschiedliche Bereiche ab. PECB vergibt Zertifikate zu ISO-Standards (ISO 27001, 27005, 31000, 22301, 42001…) und zu EU-Regulierungen (NIS 2, DORA). ISACA vergibt Zertifikate zu beruflichen Disziplinen (Audit, Sicherheitsmanagement, Risiko, Governance, Datenschutz), die auf COBIT und ISACA-Frameworks aufbauen. Die meisten Senior-Praktiker halten beides: einen ISO 27001 Lead Implementer oder Lead Auditor (PECB) plus CISA oder CISM (ISACA). Der Auditpfad (CISA → CRISC → ISO 27001 LA) ist die maßgebliche Abfolge. ## Official sources - [PECB, ISO/IEC 27001 Lead Implementer](https://pecb.com/en/education-and-certification-for-individuals/iso-iec-27001) - [ISO, ISO/IEC 27001:2022](https://www.iso.org/standard/27001) --- # ISO 42001 und KI-Governance: die Landkarte für Zertifizierung und Schulung. **URL:** https://cyberacademy.net/de/resources/pillars/iso-42001-ai-governance **Author:** Christophe Mazzola **Published:** 2026-06-24 **Last reviewed:** 2026-06-24 ## Definition KI-Governance ist die Disziplin, KI-Systeme unter Kontrolle zu betreiben: Risiko, Transparenz, Verzerrung (Bias), Validierung, Sicherheit und regulatorische Exposition. Das maßgebliche Managementsystem ist ISO/IEC 42001, veröffentlicht im Dezember 2023, das KI-Pendant zum ISMS der ISO 27001. Die Qualifikationslandschaft teilt sich in zwei Ebenen: ISO 42001 (PECB) für die Managementsystem-Ebene und die ISACA Advanced in AI Zertifizierungen (AAIA für Audit, AAIR für Risiko, AAISM für Sicherheit) für die Ebene der fachlichen Disziplin. Beide bilden sich auf den EU AI Act und das NIST AI RMF ab. ## TL;DR - ISO/IEC 42001 ist die Managementsystem-Norm für KI (ein KI-Managementsystem, oder AIMS), veröffentlicht im Dezember 2023. Sie ist das AIMS-Pendant zum ISMS der ISO 27001. PECB stellt den Pfad Foundation, Lead Implementer und Lead Auditor aus. - Der Advanced in AI Track von ISACA ist die Ebene der fachlichen Disziplin: AAIA (Audit), AAIR (Risiko), AAISM (Sicherheitsmanagement). Jede setzt eine bestehende ISACA-Zertifizierung voraus (CISA, CRISC, CISM). - Der EU AI Act sagt Ihnen, was Sie für ein Hochrisikosystem nachweisen müssen. ISO 42001 sagt Ihnen, wie Sie den Nachweis organisieren. Das NIST AI RMF ist die operative Risikomethode, die es ausfüllt. - Wählen Sie nach Rolle: das System aufbauen, ISO 42001 Lead Implementer. KI auditieren, AAIA. KI-Risiko steuern, AAIR oder PECB AI Risk Manager. Modelle absichern, AAISM. KI-Lieferung leiten, CAIP. - Es gibt keine einzelne "KI-Governance-Zertifizierung". Eine erfahrene Fachkraft kombiniert die ISO 42001 Managementsystem-Qualifikation mit einer Disziplin-Qualifikation. ## Full content Fragen Sie fünf Anbieter nach einer KI-Governance-Zertifizierung, und Sie erhalten fünf verschiedene Antworten, weil sich der Markt noch nicht gesetzt hat. Es gibt kein einzelnes KI-Governance-Zertifikat in der Weise, wie es eine einzelne CISM oder eine einzelne CISA gibt. Es gibt zwei unterschiedliche Ebenen, ausgestellt von zwei verschiedenen Stellen, die zwei verschiedene Fragen beantworten: Wie steuern Sie KI als Organisation, und wie auditieren, bewerten oder sichern Sie sie als Fachkraft? Diese Seite bildet die beiden Ebenen auf die Norm (ISO/IEC 42001), die Regulierung (den EU AI Act) und das US-Rahmenwerk (NIST AI RMF) ab und sagt Ihnen dann, welche Qualifikation zu welcher Rolle passt und wie Sie ein Team schulen, ohne alle in denselben fünftägigen Kurs zu schicken. Sie ist für den CISO, die GRC-Leitung oder den Auditor geschrieben, der die Entscheidung treffen muss. ## Die zwei Ebenen der KI-Governance-Qualifikationen Jede KI-Governance-Qualifikation am Markt liegt auf einer von zwei Ebenen. - Die Managementsystem-Ebene beantwortet "Wie steuert die Organisation ihre KI?". Die Referenz ist ISO/IEC 42001, die internationale Norm für KI-Managementsysteme. PECB stellt dagegen einen Pfad aus Foundation, Lead Implementer und Lead Auditor aus, genau wie bei ISO 27001. - Die Ebene der fachlichen Disziplin beantwortet "Was macht diese Fachkraft mit KI?". Die Referenz ist der Advanced in AI Track von ISACA: AAIA für Auditoren, AAIR für Risikomanager, AAISM für Sicherheitsmanager. Jede ist Advanced und setzt voraus, dass Sie die passende ISACA-Zertifizierung bereits halten. Die zwei Ebenen ergänzen einander. Eine reife KI-Governance-Funktion hält beide: eine ISO 42001 Managementsystem-Qualifikation, um das System aufzubauen und zu betreiben, und je eine ISACA Disziplin-Qualifikation pro Funktion, die darin arbeitet. ## ISO/IEC 42001: das KI-Managementsystem ISO/IEC 42001:2023, veröffentlicht im Dezember 2023, ist die erste internationale Norm für ein KI-Managementsystem (AIMS). Sie ist das KI-Pendant zum ISMS der ISO 27001: eine Politik, definierte Rollen, ein KI-Risikobewertungsprozess, Maßnahmen über den Lebenszyklus des KI-Systems, ein Anhang A mit KI-spezifischen Maßnahmen und ein Managementbewertungszyklus, der das Ganze ehrlich hält. Der PECB-Zertifizierungspfad dagegen spiegelt ISO 27001: - ISO 42001 Foundation (2 Tage) vermittelt das Vokabular und das Managementsystem-Modell. Es ist die Voraussetzung für die höheren Qualifikationen. - ISO 42001 Lead Implementer (5 Tage) lehrt Sie, das AIMS aufzubauen: Geltungsbereich, KI-Risikobewertung, die Statement of Applicability (SoA), die Maßnahmen, den Betriebszyklus. Dies ist die Qualifikation für denjenigen, der die KI-Governance verantwortet. - ISO 42001 Lead Auditor (5 Tage) lehrt Sie, ein AIMS zu auditieren: Nachweise, Stichprobenziehung, Interviewtechnik, Feststellungen. Dies ist die Qualifikation für die Interne Revision und für Auditoren von Zertifizierungsstellen. > **Einen einzigen ISO 42001 Kurs wählen?** Es ist fast immer Lead Implementer. Sie bauen das System weitaus häufiger auf, als Sie das eines anderen auditieren. ## Der ISACA Advanced in AI Track: AAIA, AAIR, AAISM Die Advanced in AI Qualifikationen von ISACA sind die Ebene der fachlichen Disziplin. Sie sind von Grund auf Advanced: Jede setzt voraus, dass Sie die grundlegende ISACA-Zertifizierung für diese Disziplin bereits halten, und jede ist auf ISO 42001 und die Hochrisiko-Pflichten des EU AI Act abgebildet, statt im luftleeren Raum gelehrt zu werden. **Die drei ISACA Advanced in AI Qualifikationen** | Qualifikation | Disziplin | Setzt voraus | Konzipiert für | | --- | --- | --- | --- | | AAIA, Advanced in AI Audit | Auditieren von KI-Systemen, Modellen und Governance | CISA | Erfahrene IT-Auditoren, Compliance-Verantwortliche | | AAIR, Advanced in AI Risk | KI-Risikobewertung, Quantifizierung, Behandlung, Überwachung | CRISC | IT-Risikomanager, CROs | | AAISM, Advanced in AI Security Management | KI-Bedrohungsmodellierung, sicherer Modelllebenszyklus, KI-Sicherheitsbetrieb | CISM | CISOs, Sicherheitsarchitekten | Die drei Kurse bei Cyber Academy sind AAIA, AAIR und AAISM. Wählen Sie nach dem, was Sie tun, nicht nach dem, was am neuesten ist. ## Wo PECB AI Risk Manager und CAIP hinpassen Zwei weitere PECB-Qualifikationen liegen neben dem ISO 42001 Pfad. AI Risk Manager ist eine fokussierte Risiko-Qualifikation für Fachkräfte, die KI-spezifische Risikoprogramme betreiben, Modellrisiko, Bias, Drift, Risiko durch Drittmodelle, ohne den vollen Managementsystem-Umfang von Lead Implementer. Certified Artificial Intelligence Professional (CAIP) ist die breitere Praktiker-Qualifikation für Personen, die KI über den Lebenszyklus hinweg verantwortungsvoll aufbauen und einsetzen, nützlich für technische Leads, die das Governance-Vokabular benötigen, ohne das AIMS zu verantworten. Wenn Sie bereits ein ISO 27001 Risikoprogramm betreiben und es auf KI ausweiten wollen, ist AI Risk Manager die kürzeste Brücke. Wenn Sie die KI-Lieferung leiten und die Governance-Kompetenz benötigen, die der AI Act nun von Ihnen verlangt, ist CAIP die bessere Wahl. ## Wie sich die Qualifikationen auf den AI Act und das NIST AI RMF abbilden Keine dieser Qualifikationen existiert isoliert. Sie werden gegen die Regulierung und die Rahmenwerke gelehrt, die eine KI-Governance-Funktion tatsächlich erfüllen muss. **Was jedes Instrument beantwortet** | Instrument | Was es ist | Zertifizierbar? | Rolle in Ihrem Programm | | --- | --- | --- | --- | | EU AI Act | Regulation (EU) 2024/1689 | Nein, Konformitätsbewertung, keine Zertifizierung | Was für ein Hochrisikosystem nachzuweisen ist | | ISO/IEC 42001 | Norm für KI-Managementsysteme | Ja, AIMS-Zertifizierung + PECB-Qualifikationen | Wie der Nachweis zu organisieren ist | | NIST AI RMF | Freiwilliges US-Risikorahmenwerk (Govern, Map, Measure, Manage) | Nein | Operative Risikomethode, die das System ausfüllt | | ISO/IEC 23894 | Leitlinie zum KI-Risikomanagement | Nein | Risikomethodik, ISO-konform, innerhalb des AIMS | Der kanonische Weg für eine europäische Organisation: das AIMS mit ISO 42001 Lead Implementer aufbauen, die Hochrisiko-Pflichten des AI Act auf die AIMS-Maßnahmen abbilden und das NIST AI RMF oder ISO 23894 als Risikomethodik verwenden. Die ISACA Advanced Qualifikation rüstet dann diejenige Funktion aus, Audit, Risiko oder Sicherheit, die innerhalb dieses Systems arbeiten muss. ## Wie man ein Team in KI-Governance schult Der Fehler ist, alle auf denselben Kurs zu schicken. KI-Governance ist funktionsübergreifend, und die Funktionen benötigen unterschiedliche Tiefe. 1. Beginnen Sie mit einer gemeinsamen Grundlage. ISO 42001 Foundation oder eine AI-Act-Literacy-Unterweisung, die die KI-Kompetenzpflicht aus Artikel 4 des Rechtsakts erfüllt, gibt allen dasselbe Vokabular, bevor sie sich spezialisieren. 1. Senden Sie die Governance- und Compliance-Verantwortlichen zu ISO 42001 Lead Implementer. Sie bauen das AIMS auf und betreiben es. 1. Senden Sie die Interne Revision zu AAIA, die Risikofunktion zu AAIR und die Sicherheitsfunktion zu AAISM. Jede arbeitet aus ihrer eigenen Perspektive innerhalb des AIMS. 1. Fügen Sie ISO 42001 Lead Auditor nur hinzu, wenn Sie ein internes Auditprogramm gegen das AIMS betreiben oder bei einer Zertifizierungsstelle sitzen. > **Ein ganzes Team schulen?** Ein Inhouse-Kurs wird pro Kohorte statt pro Platz abgerechnet und stimmt die Übungen auf Ihren tatsächlichen KI-Bestand ab. Das Erstgespräch klärt, welche Rollen welche Qualifikation benötigen, bevor jemand bucht. Die meisten Teams kaufen zu viele Lead-Implementer-Plätze und zu wenige Disziplin-Qualifikationen. ## Die Entscheidung, in einer Zeile Das System aufbauen: ISO 42001 Lead Implementer. KI auditieren: AAIA. KI-Risiko steuern: AAIR oder PECB AI Risk Manager. Modelle absichern: AAISM. KI-Lieferung leiten und Governance-Kompetenz benötigen: CAIP. Es gibt kein einzelnes KI-Governance-Zertifikat, und wer Ihnen eines verkauft, verkauft Ihnen einen Ausschnitt. ## FAQ ### Gibt es eine KI-Governance-Zertifizierung, und welche sollte ich absolvieren? Es gibt keine einzelne KI-Governance-Zertifizierung. Das Feld teilt sich in zwei Ebenen. Die Managementsystem-Ebene ist ISO/IEC 42001: PECB stellt Foundation (2 Tage), Lead Implementer (5 Tage, das AIMS aufbauen) und Lead Auditor (5 Tage, eines auditieren) aus. Die Ebene der fachlichen Disziplin ist der Advanced in AI Track von ISACA: AAIA für das Auditieren von KI, AAIR für KI-Risiko, AAISM für KI-Sicherheitsmanagement. Für jemanden, der KI organisatorisch steuert, ist ISO 42001 Lead Implementer der Grundstein. Für jemanden, der KI innerhalb einer bestehenden GRC-Rolle auditiert, Risiken bewertet oder absichert, ist die passende ISACA Advanced Qualifikation das stärkere Signal. Die meisten erfahrenen Fachkräfte halten je eine von beiden. ### Was ist ISO/IEC 42001 und wie verhält sie sich zum EU AI Act? ISO/IEC 42001:2023 ist die internationale Norm für KI-Managementsysteme, veröffentlicht im Dezember 2023. Sie definiert, wie eine Organisation die Governance ihrer KI-Systeme einführt, betreibt und verbessert: Politik, Rollen, KI-Risikobewertung, den Lebenszyklus des KI-Systems, einen Anhang A mit KI-spezifischen Maßnahmen und den Managementbewertungszyklus. Sie ist das AIMS-Pendant zum ISMS der ISO 27001. Die Norm erfüllt den EU AI Act nicht aus sich selbst heraus. Der Rechtsakt enthält produktspezifische technische Anforderungen für Hochrisikosysteme. Aber ISO 42001 liefert die Managementsystem-Grundlage, die Auditoren und benannte Stellen anerkennen. Der kanonische Weg ist ISO 42001, um das AIMS aufzubauen, und dann die Hochrisiko-Pflichten des AI Act auf die AIMS-Maßnahmen abzubilden. ### AAIA vs. AAIR vs. AAISM: welche ISACA KI-Zertifizierung? Drei Perspektiven auf KI, alle mit der Annahme einer bestehenden ISACA-Qualifikation. AAIA (Advanced in AI Audit) ist für Auditoren: das Auditieren von KI-Systemen, Modellen und Governance, abgebildet auf ISO 42001 und den AI Act. Üblicherweise zusammen mit CISA gehalten. AAIR (Advanced in AI Risk) ist für Risikofachkräfte: KI-Risikobewertung, Quantifizierung, Behandlung und Überwachung. Üblicherweise zusammen mit CRISC gehalten. AAISM (Advanced in AI Security Management) ist für Sicherheitsverantwortliche: KI-Bedrohungsmodellierung, der sichere Modelllebenszyklus und KI-Sicherheitsbetrieb. Üblicherweise zusammen mit CISM gehalten. ### Wie schule ich ein ganzes Team in KI-Governance? Sequenzieren Sie es nach Funktion. Beginnen Sie mit einer gemeinsamen Grundlage (ISO 42001 Foundation oder eine AI-Act-Literacy-Unterweisung, die Artikel 4 erfüllt). Senden Sie Governance- und Compliance-Verantwortliche zu ISO 42001 Lead Implementer; die Interne Revision zu AAIA; die Risikofunktion zu AAIR; die Sicherheitsfunktion zu AAISM. Für einen Rollout über mehrere Teams hinweg wird ein Inhouse-Kurs pro Kohorte abgerechnet und die Übungen werden auf Ihren KI-Bestand abgestimmt. Das Erstgespräch klärt, welche Rollen welche Qualifikation zuerst benötigen. Die meisten Teams kaufen zu viele Lead-Implementer-Plätze und zu wenige Disziplin-Qualifikationen. ### Wo passt das NIST AI RMF neben ISO 42001? Das NIST AI Risk Management Framework (AI RMF 1.0, Januar 2023) ist das freiwillige US-Rahmenwerk, strukturiert um Govern, Map, Measure und Manage. Es ist nicht zertifizierbar und keine Managementsystem-Norm. Es ist ein Handbuch für die Risikofunktion. ISO 42001 und das NIST AI RMF ergänzen einander. ISO 42001 liefert das zertifizierbare Managementsystem; das NIST AI RMF liefert die operative Risikomethode, die es ausfüllt. Organisationen, die sowohl europäischen als auch US-Kontexten ausgesetzt sind, betreiben ein ISO 42001 AIMS mit dem NIST AI RMF und der zugehörigen Leitlinie ISO/IEC 23894 als Risikomethodik darin. ## Official sources - [ISO, ISO/IEC 42001:2023 (AI management systems)](https://www.iso.org/standard/81230.html) - [EUR-Lex, Regulation (EU) 2024/1689 (AI Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) - [NIST, AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework) - [ISACA, Advanced in AI (AAIA / AAIR / AAISM)](https://www.isaca.org/credentialing) --- # KI-Verordnung (AI Act): Compliance ohne Abstraktion. **URL:** https://cyberacademy.net/de/resources/pillars/ai-act **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition Die EU-KI-Verordnung (Regulation (EU) 2024/1689) ist die weltweit erste umfassende KI-Regulierung. Vier Risikostufen: inakzeptabel (verboten), hoch (umfangreiche Pflichten und Konformitätsbewertung), begrenzt (Transparenz), minimal. Eigene Regeln für KI-Modelle mit allgemeinem Verwendungszweck. Anwendung in Phasen bis August 2027. ISO 42001 ist die Managementsystem-Antwort auf die organisatorischen Anforderungen der KI-Verordnung. ## TL;DR - Risikobasiert: inakzeptable Praktiken verboten (seit Februar 2025), Hochrisikosysteme stark reguliert, begrenztes Risiko erfordert Transparenz, minimales Risiko unangetastet. - Hochrisikosysteme (Beschäftigung, kritische Infrastruktur, Bildung, Biometrie, Strafverfolgung, Justiz…) erfordern Risikomanagement, Daten-Governance, technische Dokumentation, Transparenz, menschliche Aufsicht, Genauigkeit und Cybersicherheit. - GPAI-Modellregeln gelten für Anbieter von KI mit allgemeinem Verwendungszweck, mit strengeren Pflichten für Modelle mit systemischem Risiko. - Konformitätsbewertung erforderlich, bevor ein Hochrisikosystem auf dem EU-Markt in Verkehr gebracht wird. Die CE-Kennzeichnung gilt. - Kombinieren Sie dies mit ISO/IEC 42001 für die Managementsystem-Ebene. Die KI-Verordnung sagt Ihnen, was Sie nachweisen müssen; ISO 42001 sagt Ihnen, wie Sie den Nachweis organisieren. ## Full content ## Klassifizieren Sie das System, bevor Sie irgendetwas anderes tun Jede Entscheidung im Rahmen der KI-Verordnung beginnt mit einer Frage: In welche Stufe fällt dieses System. Klassifizieren Sie falsch, so überkonstruieren Sie entweder einen Chatbot oder unterschützen ein Tool zum Lebenslauf-Screening, das eine Aufsichtsbehörde als hochriskant einstufen wird. Die vier Stufen sind kein Spektrum, auf dem Sie sich bewegen; es sind diskrete Kategorien mit unterschiedlichen rechtlichen Folgen, und ein einzelnes Produkt kann in mehr als einer liegen, wenn es mehrere Funktionen bündelt. Die Klassifizierung ist eine Funktion des Zweckbestimmung, nicht der technischen Raffinesse. Eine einfache logistische Regression, die entscheidet, wer einen Kredit erhält, ist hochriskant. Ein großes multimodales Modell, das Rezepte empfiehlt, ist es nicht. Die Verordnung betrachtet, wofür das System verwendet wird und wen es betrifft, weshalb die Klassifizierungsarbeit Produkt und Compliance gemeinsam zukommt, nicht dem Data-Science-Team allein. **Die vier Risikostufen der EU-KI-Verordnung und wozu jede Sie verpflichtet** | Risikostufe | Beispiele | Kernpflicht | Hürde vor dem Inverkehrbringen | | --- | --- | --- | --- | | Inakzeptabel | Social Scoring, ungezieltes Auslesen für Gesichtserkennung, manipulative oder ausbeuterische Systeme | Verboten. Die Praxis darf überhaupt nicht in Verkehr gebracht oder verwendet werden. | Vollständig untersagt (Verbote gelten ab Februar 2025) | | Hoch | Beschäftigung und Personalbeschaffung, Kreditscoring, kritische Infrastruktur, Bildung, Biometrie, Strafverfolgung, Justiz | Vollständiger Pflichtenkatalog: Risikomanagement, Daten-Governance, technische Dokumentation, Protokollierung, menschliche Aufsicht, Genauigkeit, Robustheit, Cybersicherheit | Konformitätsbewertung plus CE-Kennzeichnung und Registrierung in der EU-Datenbank | | Begrenzt | Chatbots, Emotionserkennung, Deepfakes und andere generierte Inhalte | Nur Transparenz: Menschen mitteilen, dass sie mit KI interagieren oder dass Inhalte KI-generiert sind | Keine Konformitätsbewertung; Offenlegungspflichten | | Minimal | Spamfilter, Empfehlungssysteme, die meisten Verbraucher-KI-Funktionen | Keine verpflichtenden Pflichten nach der Verordnung; freiwillige Kodizes werden gefördert | Keine | Die meisten Streitfragen im Audit-Raum drehen sich nicht um minimal gegen hoch; sie drehen sich an der Grenze um hoch gegen begrenzt. Wenn Sie die Klassifizierung nicht schriftlich verteidigen können, behandeln Sie sie als die höhere Stufe, bis Sie es können. Der Kurs AI Risk Manager geht die Klassifizierungslogik durch und den Nachweis, den Sie benötigen, um hinter einer Entscheidung zu stehen. ## Was "hochriskant" im Betrieb tatsächlich bedeutet Das TL;DR listet die sieben Pflichtenbereiche auf. Die betriebliche Realität ist, dass jeder davon ein wiederkehrender Prozess ist, kein Dokument, das Sie einmal schreiben. Hochrisiko-Compliance ist ein System, das Sie über die gesamte Lebensdauer des Produkts betreiben, und die Verordnung erwartet, dass Sie nachweisen, dass das System aktiv ist, nicht dass es am Tag der Markteinführung existierte. 1. Risikomanagement ist fortlaufend. Sie identifizieren vorhersehbaren Missbrauch und Schäden, mindern sie, prüfen das Restrisiko und wiederholen dies bei jeder wesentlichen Änderung. Ein eingefrorenes Risikoregister von der Markteinführung ist eine Feststellung, kein Control. 1. Daten-Governance erfasst die Trainings-, Validierungs- und Testdatensätze: Repräsentativität, Prüfung auf Verzerrungen, Lücken und die Herkunft der Daten. Sie müssen zeigen, was Sie geprüft und was Sie gefunden haben, nicht nur behaupten, die Daten seien "gut" gewesen. 1. Die technische Dokumentation ist das Rückgrat der Akte. Sie beschreibt das System, seinen Zweck, seine Designentscheidungen, seine Leistungskennzahlen und seine Grenzen so detailliert, dass eine Drittstelle daraus die Konformität bewerten könnte. 1. Aufzeichnungen bedeuten automatische Protokollierung über die Lebensdauer des Systems, damit Ereignisse nachvollziehbar sind. Wenn etwas schiefläuft, müssen Sie rekonstruieren können, was das System getan hat. 1. Menschliche Aufsicht muss von Anfang an eingebaut sein, nicht nachträglich angesetzt: Die das System beaufsichtigenden Personen brauchen die Fähigkeit, zu verstehen, einzugreifen und zu übersteuern, und die Schnittstelle muss dies ermöglichen. 1. Genauigkeit, Robustheit und Cybersicherheit müssen gemessen und erklärt und dann unter realen Bedingungen, einschließlich gegnerischer, gehalten werden. "Es funktioniert in der Demo" ist keine Robustheitsaussage. Diese Pflichten lassen sich sauber auf ein Managementsystem abbilden, weshalb Teams die Verordnung mit ISO/IEC 42001 kombinieren. Der Kurs ISO 42001 Lead Implementer baut das Betriebsmodell auf, das diese sieben Bereiche in wiederholbare Prozesse mit Verantwortlichen, Nachweisen und Überprüfungszyklen verwandelt. ## Der Ablauf der Konformitätsbewertung Die Konformitätsbewertung ist die Hürde, die ein Hochrisikosystem nimmt, bevor es auf dem EU-Markt in Verkehr gebracht wird. Für die meisten Hochrisikokategorien ist dies eine vom Anbieter durchgeführte Bewertung auf Grundlage einer internen Kontrolle gegen die Anforderungen der Verordnung; bestimmte Kategorien, insbesondere einige biometrische, laufen über eine notifizierte Stelle. So oder so ist die Abfolge dieselbe, und es lohnt sich, sie eher als Projektplan denn als Checkliste zu behandeln. 1. Bestätigen Sie die Klassifizierung und die geltenden Anforderungen für Ihren konkreten Anwendungsfall und Ihre Kategorie. 1. Richten Sie die Prozesse für Risikomanagement und Daten-Governance ein und betreiben Sie sie, sodass echte Nachweise statt Platzhalter entstehen. 1. Stellen Sie die technische Dokumentation so zusammen, dass sie vollständig und intern konsistent mit den Protokollen, Testergebnissen und dem Risikoregister ist. 1. Führen Sie die Konformitätsbewertung durch (intern oder, wo erforderlich, über eine notifizierte Stelle) und schließen Sie die dabei aufgedeckten Lücken. 1. Erstellen Sie die EU-Konformitätserklärung, bringen Sie die CE-Kennzeichnung an und registrieren Sie das System vor der Markteinführung in der EU-Datenbank. 1. Gehen Sie ab dem ersten Tag in die Beobachtung nach dem Inverkehrbringen über, denn die Pflicht endet nicht mit der Markteinführung. > **Die Dokumentation muss wahr sein, nicht nur vollständig** Auditoren gleichen quer ab. Wenn die technische Dokumentation eine Genauigkeitskennzahl nennt, die die Testprotokolle nicht stützen, oder ein menschliches Aufsichtscontrol beschreibt, das die tatsächliche Schnittstelle nicht bietet, verliert die gesamte Akte an Glaubwürdigkeit. Bauen Sie die Dokumentation aus dem Nachweis auf, niemals umgekehrt, und gleichen Sie die Akte mit dem System ab, bevor jemand von außen sie zu Gesicht bekommt. ## Beobachtung nach dem Inverkehrbringen und der gestufte Zeitplan Das Inverkehrbringen eines Systems ist der Mittelpunkt der Pflicht, nicht das Ende. Anbieter müssen einen Plan zur Beobachtung nach dem Inverkehrbringen betreiben, der aktiv Leistungs- und Vorfalldaten über die eingesetzte Lebensdauer des Systems erhebt, und schwerwiegende Vorfälle müssen den Behörden innerhalb festgelegter Fristen gemeldet werden. Wesentliche Änderungen können eine erneute Konformitätsbewertung auslösen, weshalb Ihr Änderungsmanagementprozess und Ihr KI-Verordnungsprozess miteinander verzahnt sein müssen. Der Zeitplan ist gestuft, was Teams zu Fall bringt, die "August 2027" lesen und annehmen, sie hätten für alles bis dahin Zeit. Die Verbote inakzeptabler Praktiken gelten bereits. GPAI-Pflichten und mehrere Governance-Bestimmungen greifen früher im Zeitplan, und die Hochrisikopflichten greifen je nach Kategorie über den Zeitraum bis August 2027 gestaffelt. Die richtige Haltung besteht darin, jedes Ihrer Systeme seinem eigenen geltenden Datum zuzuordnen, statt auf eine einzige Klippe hin zu planen. Den Beobachtungs- und Vorfallkreislauf zu betreiben, ist der Punkt, an dem sich die KI-Auditoren- und Risikorollen bezahlt machen. Der Kurs AI Auditor (AAIA) behandelt, wie man ein KI-Managementsystem gegen diese Nachweise auditiert, und der Kurs Advanced AI Auditor (AAIR) geht tiefer auf die Test- und Assurance-Arbeit ein, die hinter einer belastbaren Akte zur Beobachtung nach dem Inverkehrbringen steht. ## KI mit allgemeinem Verwendungszweck: eine separate Pflicht, die Sie erben können Die GPAI-Modellregeln stehen neben den Risikostufen, nicht in ihnen. Wenn Sie ein Modell mit allgemeinem Verwendungszweck erstellen oder feinabstimmen, tragen Sie Anbieterpflichten: technische Dokumentation für das Modell, Informationen für nachgelagerte Betreiber, eine Urheberrechtsstrategie und eine öffentliche Zusammenfassung der Trainingsinhalte. Modelle, die als systemisch risikobehaftet eingestuft werden, übernehmen strengere Pflichten, darunter Modellbewertung, gegnerische Tests und Vorfallmeldung. Die Falle für die meisten Teams liegt auf der anderen Seite dieser Beziehung. Wenn Sie ein Basismodell eines Drittanbieters in Ihr eigenes Hochrisikosystem integrieren, entkommen Sie der Verordnung nicht, indem Sie auf den Modellanbieter verweisen. Sie erben das Integrationsrisiko und bleiben dafür verantwortlich, dass Ihr System die Konformität erreicht. Behandeln Sie die Dokumentation des Modellanbieters als Eingabe in Ihre Akte, nicht als Ersatz dafür, und richten Sie die vertraglichen Weitergabepflichten ein, bevor Sie ausliefern. ## Häufige Fehler und die Entscheidung, die vor Ihnen liegt - Die Klassifizierung als einmaligen Vorgang behandeln. Eine Funktion, die als Empfehlungssystem begann, wird in dem Moment hochriskant, in dem sie eine Einstellungs- oder Kreditentscheidung steuert. Klassifizieren Sie bei jeder wesentlichen Zweckänderung neu. - Dokumentation als Artefakt der Markteinführung schreiben. Die Akte muss mit dem laufenden System synchronisiert bleiben; eine veraltete Akte ist schlimmer als eine unvollständige, weil sie aktiv in die Irre führt. - Das Managementsystem mit der Regulierung verwechseln. ISO 42001 organisiert Ihren Nachweis, macht aber für sich genommen kein System KI-Verordnungs-konform. Sie klassifizieren, bewerten und registrieren weiterhin gegen die Verordnung. - Annehmen, dass die GPAI-Anbieterpflichten Ihre Integration abdecken. Tun sie nicht. Ihr Hochrisikosystem braucht seine eigene Konformitätsgeschichte. - Auf eine einzige Frist hin planen. Die gestuften Daten bedeuten, dass einige Pflichten bereits aktiv sind, während andere Jahre entfernt liegen; planen Sie pro System, pro Kategorie. Die Entscheidung, die vor den meisten Teams liegt, ist nicht, ob sie Compliance herstellen, sondern wie sie die Fähigkeit aufbauen, sie wiederholt herzustellen. Wenn Sie bei null beginnen, gibt der Kurs ISO 42001 Foundation dem Team ein gemeinsames Vokabular, und der Kurs AI Security Management (AAISM) verbindet die Cybersicherheits- und Robustheitspflichten der Verordnung mit dem Sicherheitsprogramm, das Sie bereits betreiben. Wählen Sie die Rolle, die Ihrer Lücke am nächsten liegt, und bauen Sie von dort aus weiter. > **Beginnen Sie mit einer Bestandsaufnahme, nicht mit einer Richtlinie** Bevor Sie eine einzige Prozedur entwerfen, listen Sie jedes KI-System und jede wesentliche KI-Funktion auf, die Sie ausliefern oder nutzen, und klassifizieren Sie jede einzelne. Die meisten Organisationen stellen fest, dass sie mehr Systeme im Anwendungsbereich haben als erwartet und weniger, die wirklich hochriskant sind, als befürchtet. Die Bestandsaufnahme verwandelt eine abstrakte Regulierung in eine endliche, priorisierte Arbeitsliste. ## FAQ ### Ist mein KI-System hochriskant? Annex III listet acht Kategorien von Hochrisiko-KI-Systemen auf: Biometrie, kritische Infrastruktur, allgemeine und berufliche Bildung, Beschäftigung und Personalmanagement, Zugang zu wesentlichen öffentlichen und privaten Diensten, Strafverfolgung, Migration und Grenzkontrolle, Justiz und demokratische Prozesse. Hinzu kommen KI-Systeme, die als Sicherheitsbauteil fungieren oder von EU-Harmonisierungsrechtsvorschriften erfasste Produkte sind (Annex I). Wenn Ihr System in eine dieser Kategorien fällt, ist es hochriskant. Es gibt eine eng gefasste Ausnahme nach Article 6(3), wenn das System eine eng begrenzte verfahrenstechnische Aufgabe erfüllt, das Ergebnis einer zuvor abgeschlossenen menschlichen Tätigkeit verbessert, Entscheidungsmuster erkennt, ohne die menschliche Bewertung zu ersetzen, oder eine vorbereitende Aufgabe ausführt. Dokumentieren Sie die Ausnahme; die Aufsichtsbehörde wird danach fragen. ### Wann gilt die KI-Verordnung? Stufenweise Anwendung. Die Verbote (Article 5) und die KI-Kompetenzpflichten gelten ab dem 2. Februar 2025. Die GPAI-Pflichten gelten ab dem 2. August 2025. Der Großteil der Hochrisikopflichten gilt ab dem 2. August 2026. Bestimmte Hochrisikopflichten, die sich auf bereits auf dem Markt befindliche Systeme und auf unter Annex I fallende Systeme beziehen, gelten ab dem 2. August 2027. Praktische Konsequenz: Wenn Sie 2026 ein Hochrisikosystem auf dem EU-Markt in Verkehr bringen, gilt der Großteil der Pflichten aus Chapter III. Beginnen Sie jetzt mit der Arbeit an der Konformitätsbewertung. ### Wie sieht die Konformitätsbewertung aus? Für die meisten Hochrisikosysteme erfolgt eine Konformitätsbewertung auf Grundlage einer internen Kontrolle nach Annex VI. Der Anbieter erklärt die Konformität selbst, gestützt auf: ein Qualitätsmanagementsystem, technische Dokumentation gemäß Annex IV, Beobachtung nach dem Inverkehrbringen und Registrierung in der EU-Datenbank. Für bestimmte Hochrisikosysteme (insbesondere biometrische Identifizierungssysteme) muss eine notifizierte Drittstelle eingebunden werden (Annex VII). Es folgen die CE-Kennzeichnung und eine EU-Konformitätserklärung. ### Welche Rolle spielt ISO/IEC 42001? ISO/IEC 42001 ist die internationale Norm für KI-Managementsysteme (AIMS), veröffentlicht Ende 2023. Sie ist für das AIMS das Gegenstück zum ISMS von ISO 27001. Die Norm erfüllt die KI-Verordnung nicht im Alleingang, denn die Verordnung enthält produktspezifische technische Anforderungen, aber sie liefert das Managementsystem-Fundament, das Auditoren und notifizierte Stellen anerkennen werden. Ein typischer Weg zur Bereitschaft: ISO 42001 Lead Implementer, um das AIMS aufzubauen, dann die Hochrisikopflichten der KI-Verordnung auf die AIMS-Controls abbilden, dann für jedes in den Anwendungsbereich fallende System die Konformitätsbewertung durchführen. ### Wie steht es um KI-Modelle mit allgemeinem Verwendungszweck? Articles 51-56 regeln Anbieter von KI-Modellen mit allgemeinem Verwendungszweck. Grundpflichten: technische Dokumentation, Informationen für nachgelagerte Anbieter, eine Strategie zur Einhaltung des Urheberrechts, eine Zusammenfassung der Trainingsdaten. GPAI-Modelle mit systemischem Risiko (derzeit solche mit einer kumulierten Trainingsrechenleistung über 10^25 FLOP) unterliegen strengeren Pflichten, darunter Modellbewertung, Bewertung und Minderung systemischer Risiken sowie Meldung von Vorfällen. Das AI Office bei der Europäischen Kommission gibt einen Verhaltenskodex heraus, der die GPAI-Pflichten konkretisiert. Die meisten Nicht-Frontier-Anbieter halten sich an den Kodex, anstatt Compliance von Grund auf neu auszuhandeln. ## Official sources - [EUR-Lex, Regulation (EU) 2024/1689 (AI Act)](https://eur-lex.europa.eu/eli/reg/2024/1689/oj) - [European Commission, AI Office](https://digital-strategy.ec.europa.eu/en/policies/ai-office) - [ISO, ISO/IEC 42001:2023](https://www.iso.org/standard/81230.html) --- # Operative Resilienz: DORA, NIS 2 und ISO 22301 an einem Ort. **URL:** https://cyberacademy.net/de/resources/pillars/operational-resilience-dora-nis-2-iso-22301 **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition Operative Resilienz ist die Fähigkeit einer Organisation, kritische Dienste auch durch Störungen hindurch zu erbringen und sich anschließend zu erholen. Drei Rahmenwerke regeln sie in Europa: ISO 22301 (BCMS-Standard, die operative Ebene), NIS 2 (Article 21, Pflicht zur Geschäftsfortführung für in den Anwendungsbereich fallende Einrichtungen), DORA (Articles 11-12 für Finanzunternehmen, dazu eigene Tests). Ein einziges Programm kann allen drei genügen; sie als getrennte Arbeitsstränge zu betreiben, dupliziert Arbeit und erzeugt Inkonsistenzen. ## TL;DR - ISO 22301 ist das operative Rückgrat: BIA, Wiederherstellungsziele, BCP, Runbooks, Tabletop-Übungen, BCMS unter Managementbewertung. - NIS 2 ergänzt die Meldung von Vorfällen (Frühwarnung innerhalb von 24 Stunden, Benachrichtigung innerhalb von 72 Stunden, Bericht innerhalb eines Monats) und die Kontinuität der Lieferkette. - DORA ergänzt finanzunternehmensspezifische Tests (bedrohungsorientierte Penetrationstests für bedeutende Einrichtungen alle drei Jahre), das IKT-Drittparteienregister und die Aufsicht auf ESA-Ebene für kritische Anbieter. - Der Lead Operational Resilience Manager (PECB-Zertifizierung) ist gezielt darauf ausgelegt, die drei zu integrieren. - Einmal abbilden, dreifach auditieren: ein einziges, an 22301 ausgerichtetes BCMS mit Kontrollabbildungen für NIS 2 und DORA genügt allen drei Audits. ## Full content ## Warum ein Programm und nicht drei Der Reflex in den meisten Organisationen ist, ISO 22301, NIS 2 und DORA als drei getrennte Compliance-Projekte zu behandeln, die oft von drei verschiedenen Teams verantwortet werden: Business Continuity, Security Operations und einer Finanzregulierungs- oder Risikofunktion. Das ist der teuerste Weg, es zu tun. Sie enden mit drei Business-Impact-Analysen, die sich uneinig sind, welche Dienste kritisch sind, drei Sätzen von Wiederherstellungszielen, die niemand abgleicht, und drei Übungskalendern, die dieselben Leute erschöpfen. Auditoren bemerken die Nahtstellen sofort. Die Rahmenwerke sind keine Konkurrenten. ISO 22301 liefert Ihnen das Managementsystem: die Business-Impact-Analyse (BIA), die Wiederherstellungszeit- und Wiederherstellungspunktziele, die Kontinuitäts- und Wiederherstellungspläne, die Übungen und die Schleife der Managementbewertung. NIS 2 und DORA ersetzen nichts davon. Sie fügen Pflichten obendrauf hinzu, vor allem rund um die Vorfallmeldung, die Absicherung der Lieferkette und (bei DORA) ein spezifisches Testregime. Wenn Ihr BCMS gut aufgebaut ist, lassen sich die regulatorischen Ebenen darauf aufsetzen, statt es zu duplizieren. Bauen Sie zuerst das Rückgrat. Der Kurs ISO 22301 Lead Implementer ist derjenige, der Ihnen beibringt, das Managementsystem aufzubauen, an dem alles andere hängt; wenn Sie nur die Struktur und das Vokabular verstehen müssen, beginnen Sie mit dem Kurs ISO 22301 Foundation. ## Was jedes Rahmenwerk tatsächlich hinzufügt Die ehrliche Lesart der drei ist die eines operativen Kerns plus zweier regulatorischer Überlagerungen. ISO 22301 ist der Kern, weil es das einzige der drei ist, das vorschreibt, wie die Kontinuitätsfähigkeit selbst aufgebaut und gepflegt wird. NIS 2 und DORA setzen voraus, dass diese Fähigkeit existiert, und legen dann Pflichten obendrauf: wem Sie es melden müssen, wenn etwas ausfällt, wie schnell und wie Sie nachweisen müssen, dass die Fähigkeit funktioniert. **Wie ISO 22301, NIS 2 und DORA ineinandergreifen** | Rahmenwerk | Was es dem Kern hinzufügt | Für wen es gilt | | --- | --- | --- | | ISO 22301 | Das Business-Continuity-Managementsystem selbst: BIA, RTO/RPO, Kontinuitäts- und Wiederherstellungspläne, Runbooks, Übungen, Managementbewertung. Das operative Rückgrat, das die anderen beiden voraussetzen. | Jede Organisation, freiwillig. Zertifizierbar, aber gesetzlich nicht vorgeschrieben. | | NIS 2 | Fristen für die Vorfallmeldung (Frühwarnung, Benachrichtigung, Abschlussbericht), Pflichten zur Geschäftsfortführung und zum Krisenmanagement, Sicherheit der Lieferkette und Verantwortlichkeit der Leitungsebene. | Wesentliche und wichtige Einrichtungen in benannten Sektoren in der gesamten EU (Energie, Verkehr, Gesundheit, digitale Infrastruktur, öffentliche Verwaltung und mehr). | | DORA | IKT-Resilienz im Finanzsektor: ein Programm zum Testen der digitalen operationalen Resilienz einschließlich bedrohungsorientierter Penetrationstests für bedeutende Einrichtungen, das IKT-Drittparteienregister und die direkte Beaufsichtigung kritischer IKT-Anbieter. | Finanzunternehmen in der EU (Banken, Versicherer, Wertpapierfirmen, Anbieter von Kryptowerten) und ihre kritischen IKT-Drittparteien. | Lesen Sie die Tabelle von oben nach unten, und das Konzept wird offensichtlich. Sie implementieren ISO 22301 einmal. NIS 2 und DORA sagen Ihnen dann, welche Nachweise die Aufsichtsbehörde aus diesem einen System sehen will, und DORA fügt eine Testdisziplin hinzu, die über die von ISO 22301 erwarteten Tabletop-Übungen hinausgeht. ## Wie es im Betrieb funktioniert Im Alltag lebt die Integration in drei Artefakten, und sie richtig hinzubekommen ist der Großteil der Arbeit. Das erste ist ein einziger, maßgeblicher Servicekatalog samt BIA. Entscheiden Sie einmal, welche Dienste kritisch sind, wie hoch ihre Toleranz gegenüber Störungen ist und wovon sie abhängen. Jedes Rahmenwerk liest dann aus dieser einen Quelle. Wenn Ihr NIS 2-Anwendungsbereich und Ihre DORA-Liste kritischer oder wichtiger Funktionen Ihrer ISO 22301-BIA widersprechen, haben Sie das Auditargument bereits verloren, bevor es beginnt. Das zweite ist eine vereinheitlichte Vorfall-Pipeline. ISO 22301 verlangt von Ihnen, zu erkennen, zu reagieren und Kontinuitätspläne auszulösen. NIS 2 und DORA verlangen von Ihnen, fristgerecht an eine zuständige Behörde zu melden. Bauen Sie einen einzigen Erkennungs- und Triage-Prozess, dessen Ausgabe sowohl die interne Kontinuitätsreaktion als auch den regulatorischen Meldeworkflow speist. Die Meldefrist beginnt mit der Kenntnisnahme, daher ist der Engpass selten der Kontinuitätsplan; es ist die Entscheidung, ob ein Ereignis meldepflichtig ist, und die Geschwindigkeit beim Verfassen der Frühmeldung. Vorab erstellte Meldevorlagen und ein klarer Eskalationsverantwortlicher sind hier mehr wert als jedes Werkzeug. Das dritte Artefakt ist das Test- und Übungsprogramm, und hier drängt DORA am stärksten. ISO 22301-Übungen validieren die Pläne; DORA verlangt ein dokumentiertes Testprogramm und, für bedeutende Einrichtungen, bedrohungsorientierte Penetrationstests in einem mehrjährigen Zyklus. Der Kurs DORA Lead Manager behandelt das Testregime und das IKT-Drittparteienregister in der Tiefe, die die Verordnung verlangt, während der Kurs Lead Operational Resilience Manager derjenige ist, der gezielt darauf ausgelegt ist, die drei Rahmenwerke als ein einziges Programm zu betreiben. > **Einmal abbilden, dreifach belegen** Führen Sie eine einzige Tabelle zur Kontrollabbildung, die jede Kontrolle einmal auflistet und mit den Klauseln versieht, die sie erfüllt (ISO 22301, NIS 2 Article 21, DORA Articles 11-12). Wenn ein Auditor für ein beliebiges der Rahmenwerke Nachweise verlangt, filtern Sie nach dessen Kennzeichnung und übergeben dieselben zugrunde liegenden Artefakte. Diese eine Gewohnheit ist der Unterschied zwischen einem ruhigen Audit und drei hektischen. ## Die Entscheidung: zertifizieren, ausrichten oder beides Eine häufige Frage ist, ob Sie eine ISO 22301-Zertifizierung benötigen, um NIS 2 oder DORA zu erfüllen. Tun Sie nicht. Keine der beiden Verordnungen schreibt das Zertifikat vor. Doch der Standard ist die am weitesten anerkannte Blaupause für die Fähigkeit, die beide Verordnungen voraussetzen, weshalb sich die meisten Teams an ISO 22301 ausrichten, selbst wenn sie sich gegen eine Zertifizierung entscheiden. Die Entscheidung lässt sich sauber aufteilen: Richten Sie sich an ISO 22301 aus, um ein kohärentes, belastbares BCMS zu erhalten; zertifizieren Sie obendrauf nur, wenn ein Kunde, eine Ausschreibung oder ein Vorstand eine Bestätigung durch Dritte wünscht. Wenn Sie das Zertifikat anstreben, verstehen Sie die Auditperspektive von beiden Seiten des Tisches. Implementierer bauen das System auf; Auditoren prüfen, ob es standhält. Um das Zertifizierungsaudit durchzuführen (intern oder als Zertifizierungsstelle), lehrt der Kurs ISO 22301 Lead Auditor die Auditmethodik und wie man ein BCMS gegen den Standard bewertet, was zugleich der schnellste Weg ist, zu lernen, anhand welcher Nachweise Ihr eigenes Programm beurteilt wird. ## Wo Programme scheitern Die wiederkehrenden Fehler sind vorhersehbar, und fast alle entstehen daraus, die Rahmenwerke als getrennt statt als geschichtet zu behandeln. 1. Drei sich widersprechende BIAs. Continuity, Security und Finance setzen Kritikalität jeweils anders an. Beheben Sie es, indem Sie eine BIA vorschreiben, die alle drei Funktionen unterzeichnen. 1. Pläne, die die Übung bestehen, aber am Ereignis scheitern. Tabletop-Übungen, die eine Präsentation durchgehen, beweisen nichts. Testen Sie die Auslösung, nicht die Erzählung: schwenken Sie tatsächlich um, stellen Sie tatsächlich aus dem Backup wieder her, erreichen Sie tatsächlich die Personen auf der Anrufliste. 1. Verwechslung der Continuity-, Recovery- und Incident-Response-Funktionen. Business Continuity hält den Dienst am Laufen, Disaster Recovery stellt die Technologie wieder her, und Incident Response dämmt die Ursache ein. Es sind eigenständige Disziplinen, die sauber ineinander übergeben müssen. 1. Die Meldefrist verpassen. Der Kontinuitätsplan hat funktioniert, aber niemand hat die Frühwarnung rechtzeitig eingereicht. Die regulatorische Benachrichtigung ist eine separate, fristgebundene Pflicht und braucht einen eigenen Verantwortlichen. 1. Krisenmanagement als nachrangig behandeln. Wenn ein Vorfall eskaliert, ist die Entscheidungsfindung, nicht die technische Wiederherstellung, der Schwachpunkt. Zwei dieser Fehler haben eigene Gegenmittel. Der Kurs Lead Disaster Recovery Manager trennt die Technologiewiederherstellung von der Geschäftsfortführung, sodass die beiden nicht mehr verwechselt werden, und der Kurs Certified Lead Crisis Manager baut die Führungs-, Kommunikations- und Entscheidungsstruktur auf, die hält, wenn ein Vorfall zur Krise wird. ## Die Realität im Auditraum Was ein Prüfer für eines der drei Rahmenwerke wirklich auslotet, ist, ob Ihre Resilienz echt ist oder nur auf dem Papier steht. Er wird nach der BIA fragen und dann fragen, wer sie genehmigt hat und wann sie zuletzt überprüft wurde. Er wird nach Ihrer letzten Übung fragen und dann fragen, was gescheitert ist und was Sie daraufhin geändert haben, denn eine Übung ohne Befunde ist ein Warnsignal, kein Persilschein. Bei DORA-Einrichtungen wird er nach dem Testprogramm und dem Drittparteienregister fragen und erwarten, dass beide aktuell sind und nicht erst in der Woche zuvor rekonstruiert wurden. Die Teams, die ruhig bestehen, sind diejenigen, die ein einziges Programm betreiben: eine BIA, eine Vorfall-Pipeline, die sowohl die interne Reaktion als auch die regulatorische Meldung speist, ein Übungskalender, der tatsächlich Dinge zu Bruch gehen lässt, und eine Kontrollabbildung, die es ihnen ermöglicht, drei Aufsichtsbehörden aus derselben Nachweisbasis zu beantworten. Bauen Sie das ISO 22301-Rückgrat richtig auf, setzen Sie die Pflichten von NIS 2 und DORA bewusst darauf, und die Wendung, die Ihre Audits beschreiben sollte, lautet: einmal abbilden, dreifach auditieren. ## FAQ ### Benötige ich unter NIS 2 oder DORA eine ISO 22301-Zertifizierung? Nein. Weder NIS 2 noch DORA schreiben eine ISO 22301-Zertifizierung vor. Beide verlangen, dass die Organisation Fähigkeiten zur Geschäftsfortführung und Resilienz betreibt, die bestimmte Ergebnisse erreichen (Wiederherstellung innerhalb vereinbarter Fristen, Meldung von Vorfällen innerhalb der Fristen, Erprobung der Pläne). Ein ISO 22301-konformes BCMS weist diese Fähigkeiten gegenüber einer Aufsichtsbehörde sauber nach. In der Praxis streben Finanzunternehmen und Betreiber von Diensten wesentlicher Bedeutung häufig eine ISO 22301-Zertifizierung an, weil die von NIS 2 und DORA geforderten Auditnachweise nahezu eins zu eins mit den Zertifizierungsnachweisen übereinstimmen. ### Wie hängen BCP, DR und Incident Response zusammen? Drei sich überschneidende Disziplinen. Business Continuity Plans (BCPs) regeln, wie das Unternehmen den Betrieb durch eine Störung hindurch aufrechterhält: Personaleinsatz, Ausweichstandorte, Behelfslösungen, Kommunikation. Disaster Recovery (DR) deckt die IT-spezifische Wiederherstellung von Systemen und Daten ab. Incident Response (IR) deckt den Zyklus von der Erkennung bis zur Wiederherstellung von Sicherheitsvorfällen ab. Ein ausgereiftes Programm betreibt sie als Einheit. Dasselbe Playbook führt von der Vorfallerkennung (IR) über die Systemwiederherstellung (DR) bis zur Fortführung des Geschäftsbetriebs (BCP). Verschiedene Teams können verschiedene Phasen ausführen, doch der Plan ist integriert. ### Was sind bedrohungsorientierte Penetrationstests unter DORA? TLPT ist die von der Aufsichtsbehörde überwachte Red-Team-Übung, die für bedeutende Finanzunternehmen unter DORA mindestens alle drei Jahre erforderlich ist. Sie baut auf TIBER-EU auf. Sie ist nachrichtendienstgesteuert (ein separates Threat-Intelligence-Team erstellt das Angreiferprofil), zielt auf kritische oder wichtige Funktionen ab und wird von der nationalen Behörde beaufsichtigt. TLPT ist eine mehrmonatige Arbeit im sechsstelligen Eurobereich. Es ist der strengste Resilienztest, dem sich ein Finanz-CISO stellen wird, und derjenige, der das SOC, die Erkennungsregeln und die Incident-Response-Kette so offenlegt, wie sie wirklich sind. ### Wie strukturiere ich ein einziges Resilienzprogramm? Beginnen Sie mit dem BCMS (ISO 22301 als Rückgrat): Anwendungsbereich, BIA, Wiederherstellungsziele, Pläne, Tests, Managementbewertung. Ergänzen Sie die Verfahren zur Vorfallmeldung nach NIS 2 und die Pflichten zur Kontinuität der Lieferkette aus Article 21. Ergänzen Sie den DORA-spezifischen Testplan, das IKT-Drittparteienregister und die Klassifizierung von Vorfällen für Finanzunternehmen. Bilden Sie die Kontrollen in einem einzigen Abbildungsdokument ab, das zeigt, welche Klausel welches Rahmenwerks jede Kontrolle erfüllt. Auditoren erkennen die Abbildung und hören auf, doppelte Fragen zu stellen. ## Official sources - [ISO, ISO 22301:2019 Business continuity management](https://www.iso.org/standard/75106.html) - [EUR-Lex, Directive (EU) 2022/2555 (NIS 2)](https://eur-lex.europa.eu/eli/dir/2022/2555/oj) - [EUR-Lex, Regulation (EU) 2022/2554 (DORA)](https://eur-lex.europa.eu/eli/reg/2022/2554/oj) --- # DSGVO im Jahr 2026: was sich seit 2018 geändert hat. **URL:** https://cyberacademy.net/de/resources/pillars/gdpr-2026 **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition Im Jahr 2026 bleibt die DSGVO die EU-Verordnung, die personenbezogene Daten regelt (Regulation (EU) 2016/679, in Kraft seit Mai 2018). Was sich seit 2018 geändert hat: der Rahmen für internationale Datenübermittlungen (Schrems II, neue SCC, EU-US Data Privacy Framework), die Durchsetzungsintensität (CNIL, DPC, AEPD als die aktiven Aufsichtsbehörden), das Zusammenspiel mit dem AI Act bei der automatisierten Verarbeitung sowie Klarstellungen des EuGH zu Einwilligung, berechtigtem Interesse und Recht auf Vergessenwerden. ## TL;DR - Die DSGVO selbst wurde nicht geändert. Bewegt haben sich die Rechtsprechung, die EDPB-Leitlinien, die SCC und der Rahmen für internationale Datenübermittlungen. - Schrems II hat 2020 den Privacy Shield für ungültig erklärt. Das EU-US Data Privacy Framework (DPF) hat ihn im Juli 2023 ersetzt; Übermittlungen an DPF-zertifizierte US-Importeure benötigen keine zusätzlichen Maßnahmen mehr. - Die SCC von 2021 haben die Versionen von 2010 ersetzt. Jede Übermittlung außerhalb des EWR ohne Angemessenheitsbeschluss erfordert ein dokumentiertes Transfer Impact Assessment. - Die Durchsetzung durch EDPB und nationale Behörden erreicht eine Rekordintensität. Wichtige Fälle 2023-2025: Meta (1,2 Milliarden Euro, Übermittlungen), LinkedIn (310 Millionen Euro, verhaltensbasierte Werbung), Clearview AI (mehrere Behörden). - Zusammenspiel mit dem AI Act: Hochrisiko-KI-Systeme, die personenbezogene Daten verarbeiten, müssen beide einhalten. DPIA + Konformitätsbewertung nach AI Act zusammen. ## Full content ## Warum der Text stillstand und die Praxis sich bewegte Die DSGVO wurde nicht neu geschrieben. Die Artikelnummern, die Sie 2018 gelernt haben, sind die Artikelnummern, die Sie 2026 anwenden. Was sich geändert hat, liegt eine Ebene tiefer: die Rechtsprechung, die den Text auslegt, die EDPB-Leitlinien, die ihn operationalisieren, die Standardvertragsklauseln, die Ihre Übermittlungen absichern, und die Angemessenheitsmechanik, die regelt, wo Daten rechtmäßig landen dürfen. Ein 2018 aufgebautes und seither nie angefasstes Datenschutzprogramm ist auf dem Papier nicht falsch. Es ist in der Praxis veraltet, und veraltet ist genau das, was die Durchsetzung heute findet. Diese Seite richtet sich an die Person, die die Verordnung bereits versteht und wissen muss, was aufzufrischen ist. Sie setzt voraus, dass Sie personenbezogene Daten, einen Verantwortlichen und eine Rechtsgrundlage definieren können. Sie konzentriert sich auf die vier beweglichen Teile, die 2026 tatsächlich Feststellungen erzeugen: internationale Übermittlungen, das Transfer Impact Assessment, die Überschneidung mit dem AI Act und die Frage, ob Sie überhaupt verpflichtet sind, einen Data Protection Officer zu benennen. ## Internationale Übermittlungen: der Entscheidungsbaum, nicht die Schlagzeile Die meisten Teams kennen die Schlagzeilen. Schrems II hat 2020 den Privacy Shield für ungültig erklärt. Das EU-US Data Privacy Framework hat ihn 2023 ersetzt. Die SCC von 2021 haben die Versionen von 2010 ersetzt. Die Schlagzeilen sind wahr und für sich genommen fast nutzlos, denn die eigentliche Arbeit besteht darin, eine bestimmte Übermittlung einem bestimmten Instrument zuzuordnen und dann zu entscheiden, ob darüber hinaus ein Transfer Impact Assessment erforderlich ist. Das ist ein Entscheidungsbaum, und Sie durchlaufen ihn je Datenfluss, nicht einmalig für das gesamte Unternehmen. Beginnen Sie beim Ziel. Wenn der Importeur in einem Land mit einem aktuellen EU-Angemessenheitsbeschluss sitzt, übermitteln Sie auf Grundlage des Angemessenheitsbeschlusses und benötigen für diesen Fluss weder SCC noch ein TIA. Liegt das Ziel in den Vereinigten Staaten und ist der Importeur für die betreffenden Datenkategorien selbst nach dem Data Privacy Framework zertifiziert, stützt sich dieser Fluss auf das DPF als eigene Angemessenheitsgrundlage: keine SCC, keine zusätzlichen Maßnahmen. In dem Moment, in dem Sie über beides hinausgehen, befinden Sie sich bei den Garantien nach Article 46, was in der Praxis die SCC von 2021 bedeutet, und die SCC bringen eine TIA-Pflicht mit sich, die Schrems II zur Pflicht gemacht hat. **Übermittlungsszenario, erforderliches Instrument und ob ein TIA gilt** | Übermittlungsszenario | Erforderliches Instrument | TIA erforderlich? | | --- | --- | --- | | EWR in ein Land mit aktuellem Angemessenheitsbeschluss | Angemessenheitsbeschluss (kein zusätzlicher Vertrag) | Nein | | EWR an einen US-Importeur, der nach dem DPF selbstzertifiziert ist, für erfasste Daten | DPF-Zertifizierung (wirkt als Angemessenheit) | Nein | | EWR an einen US-Importeur, der NICHT dem DPF unterliegt | SCC von 2021 | Ja | | EWR in ein nicht angemessenes Drittland (allgemeiner Fall) | SCC von 2021 | Ja | | Konzerninterne Übermittlungen über viele Einheiten und Länder hinweg | Binding Corporate Rules (oder SCC) | Ja (je Ziel zu bewerten) | | Weiterübermittlung durch Ihren Auftragsverarbeiter an dessen eigenen Unterauftragsverarbeiter im Ausland | Durchgereichte SCC in der Auftragsverarbeiterkette | Ja (die Kette erbt die Pflicht) | > **Das DPF ist kein pauschaler Freibrief für die USA** Dass ein US-Anbieter "DPF-gelistet" ist, bedeutet nicht, dass jeder Fluss zu ihm erfasst ist. Die Zertifizierung ist auf bestimmte Datenkategorien und auf Organisationen auf der aktiven Liste beschränkt. Vergewissern Sie sich, dass der Importeur derzeit für die Daten zertifiziert ist, die Sie senden, und halten Sie eine SCC-Rückfalloption bereit, denn ein Angemessenheitsbeschluss kann angefochten und ausgesetzt werden, wie es beim Privacy Shield der Fall war. Eine laufende Anfechtung des DPF nach Schrems-Art ist genau das Risiko, um das ein widerstandsfähiges Programm herum plant. ## Das Transfer Impact Assessment im Betrieb Ein TIA ist das Dokument, das eine Frage beantwortet: Untergräbt das Recht und die Praxis des Zielstaats den Schutz, den Ihre SCC auf dem Papier versprechen? Es ist kein Kontrollkästchen. Es ist ein kleines Stück rechtlich-technischer Analyse, das Sie je Übermittlung (oder je Gruppe materiell identischer Übermittlungen) erstellen und für den Tag aufbewahren, an dem eine Aufsichtsbehörde danach fragt. In der Praxis leistet ein belastbares TIA vier Dinge. Es beschreibt die Übermittlung konkret: wer exportiert, wer importiert, welche Daten, welches Volumen, welcher Zweck. Es bewertet das rechtliche Regime des Ziellandes, mit besonderem Augenmerk auf staatliche Zugriffsbefugnisse und darauf, ob eine betroffene Person über einen wirksamen Rechtsbehelf verfügt. Es identifiziert zusätzliche Maßnahmen, wo das rechtliche Regime schwach ist, und die Maßnahme, die tatsächlich etwas bewirkt, ist eine von Ihnen kontrollierte Verschlüsselung, bei der der Importeur die Schlüssel nie hält. Und es hält eine begründete Schlussfolgerung fest: durchführen, mit Maßnahmen durchführen oder nicht übermitteln. 1. Bilden Sie den Fluss präzise ab, einschließlich aller Weiterübermittlungen, die Ihr Auftragsverarbeiter an Unterauftragsverarbeiter vornimmt. Die Flüsse, die Sie vergessen, sind die, die bei einer Datenpanne ans Licht kommen. 1. Bewerten Sie das Recht des Ziellandes anhand der EDPB-Kriterien, nicht anhand Ihres Bauchgefühls über das Land. 1. Wenden Sie zusätzliche Maßnahmen an, wo nötig, und behandeln Sie eine starke, schlüsselverwaltete Verschlüsselung als technische Standardmaßnahme statt allein auf vertragliche Zusagen zu setzen. 1. Dokumentieren und datieren Sie die Schlussfolgerung und legen Sie dann einen Überprüfungsauslöser fest, damit sie nicht stillschweigend abläuft. > **Verknüpfen Sie das TIA mit Ihrem RoPA, nicht mit einem Ordner** Die Teams, die Übermittlungsprüfungen sauber bestehen, sind diejenigen, deren Verzeichnis von Verarbeitungstätigkeiten jeden Fluss kennzeichnet, der den EWR verlässt, und jeder gekennzeichnete Fluss verweist auf ein aktuelles TIA. Wenn das Verzeichnis und die Bewertungen verknüpft sind, dauert "zeigen Sie mir Ihre Übermittlungen" nur Minuten. Wenn sie auf getrennten Laufwerken liegen, dauert es eine panische Woche und bringt meist einen undokumentierten Fluss zutage. ## Wo die DSGVO auf den AI Act trifft Der AI Act ersetzt die DSGVO nicht und lockert sie nicht. Wo ein KI-System personenbezogene Daten verarbeitet, gelten beide in vollem Umfang und Sie erfüllen beide. Die Überschneidung lässt sich am klarsten anhand des Artefakts erkennen, das jedes Regime erwartet. Die DSGVO verlangt ein Data Protection Impact Assessment, wenn eine Verarbeitung voraussichtlich ein hohes Risiko für Personen darstellt. Der AI Act verlangt für Hochrisiko-KI eine Konformitätsbewertung, technische Dokumentation und (für einige Systeme) eine Grundrechte-Folgenabschätzung. Das sind unterschiedliche Dokumente, die unterschiedliche Fragen beantworten, und ein Hochrisiko-KI-System, das personenbezogene Daten berührt, benötigt beide, in sich stimmig zueinander. Die Reibungspunkte sind vertraute DSGVO-Probleme in neuem Gewand. Automatisierte Entscheidungsfindung mit rechtlicher oder ähnlich erheblicher Wirkung löste bereits die Pflichten nach Article 22 aus; der AI Act legt Transparenz- und Aufsichtspflichten obendrauf. Trainingsdaten werfen Fragen zur Rechtsgrundlage und zur Zweckbindung auf, die nicht verschwinden, weil das Ergebnis ein Modell ist. Profiling und Inferenz waren immer im Anwendungsbereich. Die praktische Regel für 2026: Betreiben Sie keinen KI-Governance-Arbeitsstrang, der Ihren DPO ignoriert, und betreiben Sie kein Datenschutzprogramm, das so tut, als wäre das Modelltraining das Problem von jemand anderem. Die beiden Bewertungen sollten aufeinander verweisen. Privacy Engineers, die diese Regime in Build-Entscheidungen überbrücken müssen, sind genau die Zielgruppe für die CDPSE-Zertifizierung, die sich um Governance, Architektur und Datenlebenszyklus statt allein um Gesetzestext gliedert. Um Datenschutz als Managementsystem zu operationalisieren, das sauber neben einem ISMS steht, behandelt der ISO 27701 Foundation-Kurs das PIMS-Modell, und der ISO 27701 Lead Implementer-Kurs führt Sie durch dessen Aufbau und Betrieb. ## Durchsetzung ist ein Signal, nicht nur ein Risiko Lesen Sie aktuelle Durchsetzungsmaßnahmen als Landkarte dafür, wohin die Behörden schauen, denn sie sagen Ihnen, wo Ihre eigene Exposition wahrscheinlich liegt. Das Muster von 2023 bis 2025 ist konsistent. Internationale Übermittlungen brachten die höchsten Einzelstrafen hervor, wobei die Meta-Entscheidung (1,2 Milliarden Euro) sich um EU-US-Datenflüsse drehte. Verhaltensbasierte Werbung und die Rechtsgrundlage für Ad-Targeting führten zur LinkedIn-Entscheidung (310 Millionen Euro). Gescrapte biometrische Daten lösten wiederholte Maßnahmen gegen Clearview AI bei mehreren Behörden aus. Die aktiven Behörden sind die, die Sie erwarten würden: die CNIL in Frankreich, die DPC in Irland für die großen Plattformen, die AEPD in Spanien. Die operative Erkenntnis lautet, die Durchsetzung nicht länger als die Schlagzeile eines anderen zu behandeln. Wenn Übermittlungen, Ad-Tech-Einwilligung und biometrische oder KI-nahe Verarbeitung dort liegen, wo die Bußgelder fallen, sind das die drei Akten, nach denen eine Aufsichtsbehörde Sie statistisch am wahrscheinlichsten fragt. Ein Programm, das ein aktuelles TIA, einen belastbaren Einwilligungsnachweis und eine DPIA für seine risikoreichste Verarbeitung vorlegen kann, ist ein Programm, das die tatsächlich gestellten Fragen übersteht. ## Benötigen Sie wirklich einen DPO? Die DPO-Frage wird am häufigsten reflexartig statt anhand des Textes beantwortet. Article 37 macht einen DPO in drei Situationen verpflichtend: Sie sind eine Behörde oder öffentliche Stelle; Ihre Kerntätigkeiten bestehen in einer umfangreichen regelmäßigen und systematischen Überwachung betroffener Personen; oder Ihre Kerntätigkeiten bestehen in der umfangreichen Verarbeitung besonderer Kategorien von Daten oder von Daten über strafrechtliche Verurteilungen. Trifft keine davon zu, erzwingt die DSGVO die Benennung nicht, auch wenn einige nationale Gesetze eigene Auslöser hinzufügen und ein freiwilliger DPO oft die kluge Wahl ist. Der Begriff, der die meisten realen Fälle entscheidet, ist "Kerntätigkeiten". Ein Krankenhaus überwacht Gesundheitsdaten als seine Kerntätigkeit und benötigt daher einen DPO. Ein Hersteller, der eine Gehaltsabrechnung betreibt, verarbeitet personenbezogene Daten, aber das ist eine unterstützende Funktion, keine Kerntätigkeit, sodass die Gehaltsabrechnung allein die Pflicht nicht auslöst. Die Fehler häufen sich an den Rändern: jemanden zu benennen, dem die von Article 38 geforderte Unabhängigkeit und Berichtslinie fehlt, einen DPO zu benennen, der einen Interessenkonflikt hat, weil er auch die Verarbeitung verantwortet, die er beaufsichtigen soll, oder auf dem Papier zu benennen und der Rolle dabei keine Autorität zu geben. Ein DPO, der den Vorstand nicht erreichen und nicht nein sagen kann, ist eine Feststellung, die nur darauf wartet, geschrieben zu werden. Wenn die Rolle von Ihnen zu besetzen oder zu beaufsichtigen ist, kommt es auf die Tiefe an. Der GDPR Foundation-Kurs ist der richtige Ausgangspunkt für das Team rund um die Rolle, und der GDPR Certified Data Protection Officer-Kurs ist für die Person gemacht, die den Titel trägt, und behandelt die Unabhängigkeit, die Aufgaben und die Rechenschaftspflicht, die die Verordnung tatsächlich verlangt. ## Was Sie vor Ihrem nächsten Audit auffrischen sollten Bringen Sie die beweglichen Teile auf den aktuellen Stand, und der Rest des Programms regelt sich weitgehend von selbst. Vergewissern Sie sich, dass jede Übermittlung auf den SCC von 2021 beruht, nicht auf dem zurückgezogenen Satz von 2010, denn Altklauseln sind eine sofortige Feststellung. Prüfen Sie, dass jede nicht angemessene Übermittlung ein datiertes TIA hat, das aus Ihrem RoPA verlinkt ist. Überprüfen Sie, dass jeder US-Anbieter, auf den Sie sich verlassen, derzeit für die Daten, die Sie senden, DPF-zertifiziert ist, und dass Sie eine SCC-Rückfalloption haben, falls nicht. Stellen Sie sicher, dass Ihre risikoreichste Verarbeitung eine DPIA hat und dass alles KI-Getriebene die AI-Act-Artefakte daneben liegen hat. Testen Sie schließlich die DPO-Frage erneut anhand Ihrer tatsächlichen Kerntätigkeiten statt anhand der Antwort, die Sie 2018 gegeben haben. > **Die Realität im Auditraum** Aufsichtsbehörden beanstanden Organisationen selten für die Existenz einer Übermittlung oder eines KI-Systems. Sie beanstanden sie für das Fehlen des Dokuments, das zeigt, dass die Entscheidung bewusst getroffen wurde. Die belastbare Antwort auf nahezu jede schwierige Frage lautet: "Hier ist die Bewertung, hier ist das Datum, hier ist, wer sie unterzeichnet hat." Ein Programm, das diese drei Dinge auf Anfrage vorlegen kann, erfüllt seine Aufgabe; eines, das es nicht kann, ist exponiert, ganz gleich, wie sorgfältig der tägliche Umgang ist. ## FAQ ### Benötige ich seit der Annahme des EU-US DPF weiterhin SCC? Für Übermittlungen an US-Importeure, die sich selbst nach dem EU-US Data Privacy Framework zertifiziert haben, nein: Der Angemessenheitsbeschluss vom Juli 2023 deckt diese Übermittlungen ab. Prüfen Sie die Zertifizierung des Importeurs auf der DPF-Liste des Department of Commerce. Für Übermittlungen an Importeure in den USA, die nicht dem DPF unterliegen, oder Übermittlungen in jedes andere Drittland ohne Angemessenheitsbeschluss sind die SCC von 2021 (oder ein anderes Übermittlungsinstrument) plus ein Transfer Impact Assessment erforderlich. ### Was ist ein Transfer Impact Assessment und wann benötige ich eines? Ein TIA ist die seit Schrems II erforderliche dokumentierte Analyse für jede Übermittlung personenbezogener Daten außerhalb des EWR ohne Angemessenheitsbeschluss. Es bewertet, ob das Recht des Zielstaats ein Schutzniveau bietet, das dem innerhalb der EU garantierten Schutzniveau der Sache nach gleichwertig ist, und identifiziert gegebenenfalls zusätzliche Maßnahmen. Sie benötigen ein TIA für jede solche Übermittlung, bezogen auf den jeweiligen Übermittlungsfluss. Die EDPB Recommendations 01/2020 liefern die Methodik. Die meisten Organisationen, die nicht-europäische SaaS-Anbieter nutzen, unterschätzen den Aufwand für das TIA und verlassen sich auf die Vorlage des Anbieters, die für sich genommen rechtlich nicht ausreichend ist. ### Wie wirkt der AI Act mit der DSGVO zusammen? Der AI Act ist eine zusätzliche Ebene über der DSGVO, kein Ersatz. Wo Hochrisiko-KI-Systeme personenbezogene Daten verarbeiten, gelten beide Verordnungen: die DSGVO für die Rechtsgrundlage, die Betroffenenrechte, die DPIA, den Rahmen für internationale Übermittlungen; der AI Act für die Konformitätsbewertung, das Risikomanagement, die technische Dokumentation, die menschliche Aufsicht. In der Praxis integrieren Organisationen die DPIA und die Konformitätsbewertung nach AI Act nach Möglichkeit in ein einziges Dokument, um doppelte Arbeit und widersprüchliche Risikobehandlungen zu vermeiden. ### Welche Durchsetzungstrends sollte ich beobachten? Drei Trends seit 2022: (1) eine stärkere Zusammenarbeit der Aufsichtsbehörden (One-Stop-Shop-Entscheidungen, gemeinsame Untersuchungen), wobei die DPC in Irland weiterhin bei grenzüberschreitenden Fällen gegen US-Tech führend ist, die verbindlichen Beschlüsse des EDPB ihren Spielraum jedoch enger fassen; (2) hohe Bußgelder bei verhaltensbasierter Werbung und Dark Patterns (Meta, LinkedIn, Amazon, Google); (3) Durchsetzung bei Cookies und Tracking-Technologien nach der ePrivacy-Richtlinie (CNIL besonders aktiv). Der Trend dürfte sich fortsetzen: mehr grenzüberschreitende verbindliche Beschlüsse, eine strengere Prüfung des berechtigten Interesses als Grundlage für verhaltensbasierte Verarbeitung und eine wachsende Aufmerksamkeit für KI-bezogene Verarbeitung nach Article 22 der DSGVO (automatisierte Entscheidungsfindung). ### Benötigt meine Organisation einen DPO? Die Articles 37 bis 39 der DSGVO verlangen einen DPO, wenn: (a) der Verantwortliche oder Auftragsverarbeiter eine Behörde oder öffentliche Stelle ist; (b) die Kerntätigkeiten eine umfangreiche regelmäßige und systematische Überwachung betroffener Personen erfordern; (c) die Kerntätigkeiten in der umfangreichen Verarbeitung besonderer Kategorien von Daten oder von personenbezogenen Daten über strafrechtliche Verurteilungen bestehen. Über die gesetzliche Anforderung hinaus benennen viele Organisationen der Privatwirtschaft aus Gründen des Risikomanagements freiwillig einen DPO. DPOs auf Konzernebene sind zulässig und in multinationalen Unternehmen üblich; sie müssen für betroffene Personen und für die Aufsichtsbehörde erreichbar bleiben. ## Official sources - [EUR-Lex, Regulation (EU) 2016/679 (GDPR)](https://eur-lex.europa.eu/eli/reg/2016/679/oj) - [European Data Protection Board](https://www.edpb.europa.eu/) - [CNIL, Guidance and decisions](https://www.cnil.fr/) --- # EBIOS RM vs. ISO 27005: das Duell. **URL:** https://cyberacademy.net/de/resources/pillars/ebios-rm-vs-iso-27005 **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition EBIOS Risk Manager ist die von der ANSSI veröffentlichte französische nationale Methode zur Risikobewertung mit Fokus auf strategische Cyberangriffsszenarien. ISO/IEC 27005 ist die internationale Norm für das Risikomanagement in der Informationssicherheit, an ISO 31000 ausgerichtet und als Methodenebene für die Arbeit am ISO 27001 ISMS genutzt. Beide sind praxisorientierte Methoden; sie sind eher komplementär als Alternativen. ## TL;DR - EBIOS RM ist strategisch und szenarienbasiert. Es bildet Geschäftsprozesse auf die Ziele von Angreifern ab und leitet daraus technische Maßnahmen ab. Stark im französischen öffentlichen Sektor und bei Betreibern von vitaler Bedeutung. - ISO 27005 ist methodenneutral und lässt sich nativ mit ISO 27001 Annex A kombinieren. Standard in internationalen Audits. - EBIOS RM liefert eine kleinere Anzahl von Szenarien mit hoher Auswirkung und reicher Erzählstruktur. ISO 27005 liefert ein umfassendes Risikoregister. - Beide sind akkreditierte PECB-Zertifizierungen: EBIOS Risk Manager (5 Tage), ISO/IEC 27005 Risk Manager (5 Tage). Lead Risk Manager existiert nur für ISO 31000. - In der Praxis: ISO 27005 für das ISMS-Risikoregister, EBIOS RM als Ergänzung, um die strategischen Szenarien zu identifizieren, die Aufmerksamkeit auf Vorstandsebene verdienen. ## Full content ## Wie jede Methode in einem Projekt tatsächlich abläuft Die Trennung zwischen den beiden Methoden ist keine Frage der Qualität, sondern des Ausgangspunkts. ISO 27005 beginnt bei Werten und Bedrohungen und arbeitet sich nach außen zu einem vollständigen Risikoregister vor. EBIOS RM beginnt bei dem, was die Organisation zu verlieren fürchtet, und arbeitet sich rückwärts über den Angreifer vor, der diesen Verlust verursachen würde. Beide erzeugen unterschiedliche Artefakte, weil sie unterschiedliche Eröffnungsfragen stellen, und genau dieser Unterschied ist es, den Ihr Auditor, Ihr Vorstand und Ihr Projektplan spüren werden. Die Arbeit mit ISO 27005 ist von Natur aus iterativ und umfassend. Sie schaffen den Kontext, identifizieren Risiken über den gesamten Geltungsbereich, analysieren Eintrittswahrscheinlichkeit und Folgen, bewerten anhand von Akzeptanzkriterien und behandeln sie dann. Das Ergebnis ist ein lebendes Register, das Sie zyklisch erneut durchlaufen. Es ist die natürliche Risiko-Engine für ein ISO 27001 ISMS, weil es dieselbe Sprache spricht wie das Managementsystem: Geltungsbereich, Kriterien, Behandlungsplan, Restrisiko, Freigabe. EBIOS RM läuft als fünf Workshops mit einer festgelegten Abfolge ab: Rahmen und Sicherheitsbasis, Risikoursprünge, strategische Szenarien, operative Szenarien und Risikobehandlung. Die Methode zwingt Sie, zuerst die gefürchteten Ereignisse zu benennen, dann die Risikoquellen (wer würde angreifen und warum), dann die übergeordneten Angriffspfade, bevor Sie überhaupt eine Maßnahme berühren. Der EBIOS Risk Manager Kurs durchläuft jeden Workshop mit echten Ergebnissen, sodass Sie die Abfolge moderieren können und sie nicht nur beschreiben. ## EBIOS RM vs. ISO 27005 auf einen Blick Die folgende Tabelle ist der Vergleich, den die meisten Teams im Raum brauchen: nicht die Philosophie, sondern worauf jede Methode den Fokus legt, was sie Ihnen am Ende liefert und wo sie tatsächlich erwartet wird. **EBIOS RM vs. ISO 27005: Fokus, Ergebnis und wo jede erwartet wird** | Dimension | EBIOS RM | ISO 27005 | | --- | --- | --- | | Ursprung | Französische nationale Methode, veröffentlicht von der ANSSI | Internationale Norm, ISO/IEC, ausgerichtet an ISO 31000 | | Fokus | Strategische Angriffsszenarien; geschäftliche Einsätze auf Bedrohungsquellen abgebildet | Systematische Identifikation von Informationssicherheitsrisiken über den gesamten Geltungsbereich | | Ausgangspunkt | Gefürchtete Ereignisse und Risikoursprünge (Top-down) | Werte, Bedrohungen, Schwachstellen (Bottom-up) | | Ergebnis | Eine kleine Menge erzählerischer Szenarien mit hoher Auswirkung und Behandlungsstrategie | Ein umfassendes, wiederholbares Risikoregister mit Behandlungsplan | | Granularität | Wenige Szenarien, tiefe Erzählung, vorstandslesbar | Viele Risiken, strukturiert, ISMS-lesbar | | Verhältnis zu ISO 27001 | Ergänzung; speist strategische Risiken in das ISMS ein | Native Methodenebene für Clause 6.1.2 und Annex A | | Wo erwartet | Französischer öffentlicher Sektor, OIV/OES, ANSSI-geprägte Beschaffung | Internationale Audits, multinationales ISMS, Kundenversicherung | | Akkreditierte Zertifizierung | PECB EBIOS Risk Manager (5 Tage) | PECB ISO/IEC 27005 Risk Manager (5 Tage) | ## Wie sich beide auf ISO 27001 abbilden ISO 27001 verlangt einen definierten Prozess zur Bewertung und Behandlung von Informationssicherheitsrisiken, schreibt aber keine bestimmte Methode vor. Genau diese eine Tatsache ist der Grund, warum dieser Vergleich überhaupt existiert. Clause 6.1.2 fordert Sie auf, Risiken zu bewerten und ein Statement of Applicability zu erstellen; sie sagt Ihnen nicht, ISO 27005 oder etwas anderes zu verwenden. Auditoren prüfen, ob Ihr Prozess konsistent und wiederholbar ist und vertretbare Behandlungsentscheidungen hervorbringt. Die Methode ist Ihre Wahl. ISO 27005 ist hier der Weg des geringsten Widerstands, weil sie geschrieben wurde, um die Methodenebene unter der Norm zu sein. Ihre Terminologie, ihre Logik der Akzeptanzkriterien und ihre Struktur des Behandlungsplans fügen sich ohne Übersetzung direkt in das ISMS ein. Wenn Sie das Managementsystem aufbauen oder betreiben, lernen Sie die Engine, die dazu passt: Der ISO/IEC 27005 Risk Manager Kurs deckt den vollständigen Bewertungs- und Behandlungszyklus ab, während der ISO/IEC 27005 Foundation Kurs der richtige Einstiegspunkt ist, wenn Sie die Konzepte benötigen, bevor Sie moderieren. EBIOS RM bildet sich aus einem anderen Blickwinkel auf dieselbe Clause ab. Es ersetzt das Register nicht; es schärft dessen Spitze. Die strategischen Szenarien werden zu der kleinen Menge an Risiken, die in der SoA und im Vorstandsdossier die höchste Prüfung rechtfertigen. Teams, die die Methode durchgängig beherrschen müssen, einschließlich der Governance der Bewertung und der leitenden Rolle über eine gesamte Organisation hinweg, belegen den ISO/IEC 27005 Lead Risk Manager Kurs. > **ISO 27001 verlangt nicht ISO 27005** Clause 6.1.2 schreibt einen Risikoprozess vor, keine benannte Methode. Sie können EBIOS RM, ISO 27005, eine interne Methode oder eine Mischung anwenden, solange sie dokumentiert und wiederholbar ist und nachvollziehbare Behandlungsentscheidungen hervorbringt. Auditoren prüfen den Prozess, nicht die Marke. ## Die Entscheidung: welche, und wann beide Die meisten Teams fassen dies als Entweder-oder auf und bereuen es dann. Die ehrliche Antwort ist, dass die Frage zwei Ebenen hat: Was verlangt Ihr Audit oder Ihr Sektor, und was braucht Ihr Risikobild tatsächlich. Klären Sie sie in dieser Reihenfolge. 1. Wenn ein ANSSI-geprägter Käufer, ein französischer öffentlicher Auftrag oder eine OIV/OES-Verpflichtung im Spiel ist, ist EBIOS RM die erwartete Sprache. Führen Sie damit auf der strategischen Ebene. 1. Wenn Ihre Versicherung aus einem internationalen ISO 27001 Zertifikat oder aus multinationalen Kundenaudits kommt, ist ISO 27005 der Standard, den der Auditor fließend liest. 1. Wenn Sie ein echtes Gegnerproblem haben (ein hochwertiges Ziel, ein regulierter kritischer Dienst, Cyberrisiko auf Vorstandsebene), führen Sie EBIOS RM zusätzlich zum Register aus, um die Szenarien zutage zu fördern, die eine Eskalation rechtfertigen. 1. Wenn Sie weder ein Mandat im französischen Sektor noch ein akutes Gegnerprofil haben, genügt ISO 27005 allein und ist im Betrieb günstiger. Beide auszuführen ist nicht redundant, wenn Sie es richtig zuschneiden. ISO 27005 gibt Ihnen Breite: jedes Risiko im Register, behandelt und nachverfolgt. EBIOS RM gibt Ihnen Tiefe bei den wenigen Szenarien, die tatsächlich schaden würden. Der Fehler besteht darin, beide auf derselben Granularität auszuführen, was die Arbeit verdoppelt und zwei Register hervorbringt, die niemand abgleicht. Nutzen Sie EBIOS RM zum Auswählen und Erzählen; nutzen Sie ISO 27005 zum Aufzählen und Nachverfolgen. > **Schneiden Sie EBIOS RM bewusst eng zu** EBIOS RM ist am wertvollsten, wenn Sie es auf einen kleinen, einsatzkritischen Perimeter richten: den Kronjuwelen-Dienst, die Funktion, deren Verlust ein Vorstandsereignis ist. Auf die gesamte Organisation gerichtet, wird es langsam und verwässert seine eigene Stärke. Lassen Sie ISO 27005 die Breite tragen und behalten Sie EBIOS RM für die Szenarien vor, die eine Erzählung rechtfertigen. ## Häufige Fehler und die Realität im Auditraum Die Fehler sind vorhersehbar und betreffen selten die Methode selbst. - Die Methode nach Vorliebe statt nach Zielgruppe wählen. Die richtige Frage lautet, wer das Ergebnis liest: Ein französischer öffentlicher Käufer erwartet die Begrifflichkeit von EBIOS RM, ein internationaler Zertifizierungsauditor erwartet ein nach ISO 27005 geformtes Register. Wählen Sie für den Leser. - EBIOS RM Szenarien als Ersatz für ein vollständiges Register behandeln. Strategische Szenarien sind bewusst wenige. Ein Auditor, der die ISO 27001 Abdeckung prüft, wird fragen, wo der Rest der Risikolandschaft dokumentiert ist, und eine Handvoll Erzählungen ist keine Antwort. - ISO 27005 als einmalige Tabellenkalkulation betreiben. Die Norm ist iterativ. Ein Register, das vor achtzehn Monaten datiert ist und keinen Überprüfungstakt hat, ist eine Beanstandung, die nur darauf wartet einzutreten. - Die Zertifizierungen verwechseln. Es gibt keinen Lead Auditor oder Lead Risk Manager für EBIOS RM, und die einzige Lead Risk Manager Zertifizierung liegt unter ISO 31000, nicht unter ISO 27005. Planen Sie den Zertifizierungspfad Ihres Teams anhand dessen, was tatsächlich existiert. Im Auditraum ist die Realität einfacher, als es die Debatte vermuten lässt. Der Zertifizierungsauditor bewertet Ihre Methode nicht gegen eine konkurrierende; er prüft, ob Ihr gewählter Prozess dokumentiert, konsistent angewandt und vom Risiko über die Behandlung bis zur Akzeptanz des Restrisikos nachvollziehbar ist. EBIOS RM hilft Ihnen zu erklären, warum bestimmte Risiken mit hoher Auswirkung bestimmte Aufmerksamkeit erhalten haben. ISO 27005 hilft Ihnen zu zeigen, dass nichts durch die Lücken gefallen ist. Die stärkste Haltung für Organisationen, die wirklich beide benötigen, ist ein ISO 27005 Register als System der Aufzeichnung, mit darüber gelagerten EBIOS RM Szenarien, um die Entscheidungen zu rechtfertigen, die am meisten zählten. ## FAQ ### Welche erwartet mein Auditor? Für ein ISO 27001 Zertifizierungsaudit erwartet der Auditor standardmäßig eine an ISO/IEC 27005 ausgerichtete Methode. Die Revision 2022 von ISO 27005 schlägt ausdrücklich die Brücke zu ISO 27001 Clause 6 und zu den Prinzipien von ISO 31000. Für Audits im französischen öffentlichen Sektor (HFDS, ANSSI-Inspektionen von Betreibern von vitaler Bedeutung im Rahmen der LPM, NIS 2 Aufsicht durch die ANSSI) ist EBIOS RM die erwartete Sprache. Werden strategische Szenarien nicht in der Begrifflichkeit von EBIOS RM formuliert, wird dies beanstandet. ### Kann ich beide gleichzeitig nutzen? Ja, und viele Organisationen tun das. EBIOS RM erzeugt 5 bis 10 strategische Angriffsszenarien mit benannten Bedrohungsquellen, Geschäftswerten und gefürchteten Ereignissen; diese werden zu den Eingangsgrößen eines ISO 27005 Risikoregisters, das die operative Ebene abdeckt (Kombinationen aus Schwachstelle und Wert, Bewertung von Eintrittswahrscheinlichkeit und Auswirkung, Behandlungsoptionen). Die Kombination funktioniert, weil EBIOS RM auf der Szenarioebene arbeitet (vorstandstauglich), während ISO 27005 auf der Ebene von Werten und Maßnahmen arbeitet (audittauglich). Die Abbildung beider erfordert Disziplin, ist aber in französischen Einrichtungen, die sowohl der ANSSI-Aufsicht als auch der ISO 27001 Zertifizierung unterliegen, gut erprobtes Terrain. ### Ist EBIOS RM nur in Frankreich relevant? Größtenteils ja. Außerhalb Frankreichs ist ISO 27005 die Lingua franca für die ISMS-Risikomethodik. EBIOS RM wird von der ENISA in einigen Veröffentlichungen anerkannt und in französisch geprägten Rechtsräumen verwendet, doch in Audits außerhalb Frankreichs oder des frankophonen Afrikas werden Sie ihm selten begegnen. Ist Ihr Auditumfeld rein international, ist ISO 27005 die sicherere Einzelwahl. Sind Sie in Frankreich tätig, im öffentlichen Sektor oder verkaufen Sie an französische staatliche Stellen, wird die Vertrautheit mit EBIOS RM erwartet. ### Was deckt die PECB EBIOS Risk Manager Zertifizierung ab? Fünf Tage. Sie deckt die fünf EBIOS RM Workshops ab: Geltungsbereich und Sicherheitsbasis, Risikoquellen, strategische Szenarien, operative Szenarien, Risikobehandlung. Die Prüfung erfolgt mit offenen Unterlagen, dauert drei Stunden und kombiniert Multiple-Choice- und Szenariofragen. Die Zertifizierung wird von der ANSSI über den PECB Gold Partner Akkreditierungsweg anerkannt. Sie ersetzt nicht den ISO/IEC 27005 Risk Manager, wenn Ihr Auditor die ISO-Methode erwartet; sie ergänzt ihn. ## Official sources - [ANSSI, EBIOS Risk Manager method](https://cyber.gouv.fr/la-methode-ebios-risk-manager) - [ISO, ISO/IEC 27005:2022](https://www.iso.org/standard/80585.html) --- # Der tatsächliche Preis eines ISO 27001 Lead Implementer in Europa. **URL:** https://cyberacademy.net/de/resources/pillars/iso-27001-lead-implementer-price-europe **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition In Europa kostet eine von einem Trainer geleitete ISO 27001 Lead Implementer Kohorte im Jahr 2026 zwischen 2.800 und 3.200 Euro pro Platz für eine standardmäßige 5-tägige Durchführung, all-inclusive (Kurs, PECB-Unterlagen, Zertifizierungsgebühr, Prüfung, eine Wiederholung). Selbstgesteuert ist 30 % bis 40 % günstiger. Inhouse-Kohorten kosten 12.000 bis 18.000 Euro für bis zu 12 Teilnehmende. ## TL;DR - Standard mit Trainer (Live-Online oder Vor-Ort-Kohorte), 5 Tage, all-inclusive: 2.800 bis 3.200 Euro pro Platz. Die Schwankung ergibt sich aus der Partnerstufe und dem Standort, nicht aus dem Lehrplan. - Selbstgesteuert (aufgezeichnete Module, offizielle PECB-Unterlagen, Prüfung inklusive): 1.700 bis 2.200 Euro. Langsamerer Abschluss, weniger live beantwortete Fragen. - Private Inhouse-Kohorte, bis zu 12 Teilnehmende, vor Ort oder virtuell: 12.000 bis 18.000 Euro für die vollen 5 Tage. Angebot innerhalb eines Werktages über die Inhouse-Schulungsseite zugesendet. - PECB Gold- und Platinum-Partner liegen preislich 5 % bis 15 % über den niedrigeren Stufen, im Gegenzug für mehr Akkreditierungstiefe und die Zertifizierungs- oder Rückerstattungsgarantie, sofern anwendbar. - Achten Sie auf das Paket: Schulungsgebühr, Zertifizierungsgebühr, Prüfungsgebühr, Wiederholung, Unterlagen, Coaching nach der Kohorte. Günstigere Angebote schnüren die Zertifizierungsgebühr oft aus dem Paket heraus. ## Full content ## Was Sie tatsächlich kaufen Die Schlagzeilenzahl auf einer Lead Implementer Seite ist selten die Zahl, die Sie zahlen. Der Kurs lehrt Sie, ein Informationssicherheits-Managementsystem anhand der ISO 27001 Controls zu konzipieren und zu betreiben, doch der Posten, der Ihre tatsächlichen Kosten bestimmt, ist das Zertifizierungs-Credential, nicht der Platz im Raum. Ein glaubwürdiges Angebot bündelt sechs Dinge: die Schulungsdurchführung, die offiziellen Unterlagen, die Zertifizierungsgebühr, die Prüfung, mindestens eine Wiederholung und idealerweise etwas Unterstützung nach der Kohorte. Wenn ein Preis niedrig erscheint, wurde meist eines dieser sechs Dinge von der Seite genommen und auf eine zweite Rechnung verschoben, die Sie später erhalten. Das Credential, für das Sie zahlen, liegt eine Stufe über dem Foundation-Niveau und eine Stufe unter dem Audit-Pfad. Wenn Sie noch nie innerhalb eines ISMS gearbeitet haben, ist der ISO 27001 Foundation Kurs der günstigere Einstiegspunkt und er zeigt Ihnen, ob der Implementer-Pfad überhaupt die richtige Investition ist. Wenn Ihre Rolle darin besteht, die Systeme anderer zu bewerten statt eigene aufzubauen, ist der ISO 27001 Lead Auditor Pfad derjenige, den Sie stattdessen kalkulieren sollten. ## Mit Trainer, selbstgesteuert oder Inhouse: der eigentliche Abwägungspunkt Die drei Durchführungsformen sind keine drei Qualitätsstufen. Sie sind drei Antworten auf eine andere Frage: Wie viel Live-Zugang zu einem Trainer benötigen Sie, und wie viele Personen zertifizieren Sie gleichzeitig? Mit Trainer eignet sich für eine einzelne lernende Person, die ihre Fragen im Raum beantwortet haben möchte und ein festes fünftägiges Zeitfenster, das den Abschluss erzwingt. Selbstgesteuert eignet sich für eine disziplinierte lernende Person, die Live-Antworten gegen einen niedrigeren Preis und einen flexiblen Zeitplan eintauscht. Inhouse ist erst sinnvoll, sobald Sie eine Kohorte haben, denn die Gebühr für die private Kohorte ist pauschal, unabhängig davon, ob Sie vier oder zwölf Plätze füllen. **ISO 27001 Lead Implementer in Europa, 2026: Durchführungsform, Preisspanne und was die Spanne enthält** | Durchführungsform | Preisspanne (EUR) | Was die Spanne enthalten sollte | Am besten geeignet für | | --- | --- | --- | --- | | Mit Trainer, 5 Tage (Live-Online oder vor Ort) | 2.800 bis 3.200 pro Platz | Kurs, offizielle Unterlagen, Zertifizierungsgebühr, Prüfung, eine Wiederholung | Eine einzelne lernende Person, die Live-Antworten und ein festes Abschlussfenster möchte | | Selbstgesteuert (aufgezeichnete Module) | 1.700 bis 2.200 pro Platz | Aufgezeichnete Module, offizielle Unterlagen, Prüfung inklusive; weniger live beantwortete Fragen | Eine disziplinierte lernende Person, die Live-Zugang gegen einen niedrigeren Preis eintauscht | | Private Inhouse-Kohorte (bis zu 12 Teilnehmende) | 12.000 bis 18.000 gesamt | Volle 5 Tage für die Gruppe, pro Kohorte statt pro Platz kalkuliert | Teams, die mehrere Personen gleichzeitig auf demselben Standard zertifizieren | Rechnen Sie die Inhouse-Zahl pro Kopf durch, bevor Sie sich entscheiden. Eine private Kohorte am unteren Ende der Spanne, gefüllt mit acht oder mehr Teilnehmenden, liegt deutlich unter dem Pro-Platz-Satz mit Trainer und hält die Diskussion an Ihren eigenen Systemen und Ihrer eigenen Statement of Applicability verankert. Unterhalb von etwa fünf Teilnehmenden ist die öffentliche Kohorte pro Platz in der Regel günstiger. ## Die Entbündelungs-Tricks, auf die Sie achten sollten Die meiste Preisverwirrung in diesem Markt ist beabsichtigt. Ein Katalog wirbt mit einer Zahl, die nur die Schulung abdeckt, dann treffen die Zertifizierungsgebühr, die Prüfung und die Unterlagen als separate Posten ein, sobald Sie sich gebunden haben. Die Summe landet nahe bei oder über einer all-inclusive Kohorte, die auf dem ersten Bildschirm teurer wirkte. Dies sind die Posten, die Sie vor der Unterschrift schriftlich bestätigen lassen sollten: - Zertifizierungsgebühr: die Gebühr für das Credential selbst, getrennt von der Prüfung. Dies ist der Posten, der am häufigsten vom Schlagzeilenpreis weggenommen wird. - Prüfungsgebühr und Wiederholung: Bestätigen Sie, dass die Prüfung enthalten ist und dass mindestens eine Wiederholung abgedeckt ist. Eine separat gekaufte Wiederholung ist selten günstig. - Offizielle Unterlagen: das lizenzierte Kursmaterial, kein Folienexport. Wenn die Seite vage über die Quelle ist, fragen Sie nach. - Unterstützung nach der Kohorte: Coaching oder Trainerzugang nach den fünf Tagen. Wird bei günstigen Angeboten oft weggelassen, ist aber für eine erstmals implementierende Person oft der nützlichste Teil. > **Lesen Sie die Zertifizierungszeile vor der Preiszeile** Wenn ein Angebot die Zertifizierungsgebühr nicht als separaten, enthaltenen Posten benennt, gehen Sie davon aus, dass sie ausgeschlossen ist, und fragen Sie nach. Die Lücke zwischen "Kurs" und "Kurs plus Zertifizierung" ist die mit Abstand größte Quelle überraschender Rechnungen in diesem Markt, und sie ist am einfachsten vor der Unterschrift zu beheben. ## Wie Sie das Firmenangebot verhandeln Öffentliche Pro-Platz-Preise haben wenig Spielraum; die Partnerstufe und der Standort bestimmen die Spanne, nicht Ihr Verhandeln. Der Hebel liegt im Inhouse-Angebot, wo die Gebühr pauschal ist und die Grenzkosten eines zusätzlichen Teilnehmenden für den Anbieter nahe null liegen. Die Schritte, die eine Firmenzahl tatsächlich bewegen: 1. Füllen Sie den Raum. Die Kohortengebühr ist für vier oder zwölf Plätze dieselbe, also senkt jeder Platz über dem Break-even-Punkt Ihre effektiven Kosten pro Kopf. Stellen Sie die Gruppe zusammen, bevor Sie um einen Rabatt bitten. 1. Bündeln Sie die Niveaus. Wenn ein Teil des Teams Foundation und andere das Implementer-Credential benötigen, fragen Sie nach beidem in einem Angebot. Kohorten mit gemischten Niveaus lassen sich leichter rabattieren als ein einzelner Kurs für sich. 1. Legen Sie sich auf ein Datum fest. Ein Anbieter kalkuliert einen bestätigten Kalendertermin schärfer als ein Vielleicht. Ein festes Zeitfenster und eine bestätigte Teilnehmerzahl mitzubringen ist mehr wert, als um einen Prozentsatz Nachlass zu bitten. 1. Fragen Sie, was entfernbar ist, nicht nur, was günstiger ist. Wenn Sie die Unterlagen bereits besitzen oder nur einen Teil des Teams zertifizieren müssen, kann ein Anbieter das Paket neu zuschneiden, anstatt es zu rabattieren. Wenn die Kohorte aufgebaut und das Datum festgelegt ist, liefert die ISO 27001 Lead Implementer Inhouse-Seite innerhalb eines Werktages ein Angebot pro Kohorte, und das ist die Zahl, gegen die Sie verhandeln, nicht der öffentliche Pro-Platz-Satz. ## Warum die Partnerstufe mehr kostet und wann sie sich lohnt PECB Gold- und Platinum-Partner liegen preislich über den niedrigeren Stufen, und der Aufschlag ist nicht willkürlich. Er erkauft Akkreditierungstiefe, erfahrenere Trainer und, sofern ein Anbieter sie bietet, eine Zertifizierungs-oder-Rückerstattungs-Garantie. Für eine erstmals implementierende Person, die mit einem funktionierenden ISMS und einer bestandenen Prüfung herausgehen muss, zahlt sich dieser Aufschlag oft schon durch eine einzige vermiedene Wiederholung und den damit verbundenen Zugang nach der Kohorte aus. Für eine erfahrene Fachkraft, die ein Credential auffrischt, reicht die niedrigere Stufe in der Regel aus. > **Kalkulieren Sie das Ergebnis, nicht den Platz** Die günstigste Kohorte ist nur dann günstig, wenn Sie bestehen und das ISMS danach tatsächlich aufbauen können. Wägen Sie den all-inclusive Preis mit Trainer gegen ein günstiges selbstgesteuertes Angebot plus einer wahrscheinlichen Wiederholung plus den Beratungsstunden ab, die Sie später kaufen werden, um die fehlende Unterstützung auszugleichen. Die niedrigere Schlagzeilenzahl verliert diesen Vergleich häufig. ## Die Entscheidung, in einem Durchgang Beginnen Sie mit der Teilnehmerzahl. Eine lernende Person, die Live-Antworten benötigt: mit Trainer, all-inclusive, 2.800 bis 3.200 Euro, Zertifizierungsgebühr schriftlich bestätigt. Eine disziplinierte lernende Person mit knappem Budget: selbstgesteuert für 1.700 bis 2.200, mit langsamerem Abschluss und weniger Live-Antworten. Ein Team von fünf oder mehr Personen auf demselben Standard: Inhouse für 12.000 bis 18.000 für die Kohorte, rechnen Sie die Kosten pro Kopf durch, füllen Sie den Raum und verhandeln Sie das Paket statt des Platzes. In jedem Fall entscheidet über Ihre tatsächlichen Kosten, ob die Zertifizierungsgebühr im Angebot enthalten ist oder auf einer zweiten Rechnung wartet. ## FAQ ### Warum steht der Preis nicht in jedem Katalog? Die meisten Schulungsanbieter greifen standardmäßig auf "ab" oder "kontaktieren Sie uns für ein Angebot" zurück, um den Verhandlungsspielraum zu kontrollieren. Der Nachteil ist Reibung: Einzelkäufer springen ab, Firmenkäufer warten Tage auf eine Zahl, und die Preise driften für dieselbe Kohorte auseinander. Cyber Academy veröffentlicht den Standardpreis auf jeder Katalog-Kursseite; der Angebotsprozess ist Inhouse- und Mehrplatz-Vorhaben vorbehalten, bei denen ein maßgeschneidertes Angebot tatsächlich nützlich ist. ### Was sollte das Paket enthalten? Ein sauberes ISO 27001 Lead Implementer Paket in Europa enthält: die 5-tägige Schulungsgebühr, die offiziellen PECB-Kursunterlagen (digital und gedruckt), die an PECB gezahlte Zertifizierungsgebühr, den ersten Prüfungsversuch, eine kostenlose Wiederholung und die lebenslange Gültigkeit des Zertifikats (keine Verlängerungsgebühr für das Lead Implementer Zertifikat selbst). Häufige Auslassungen in günstigeren Angeboten: die Zertifizierungsgebühr (später hinzugefügt als "wir führen die Schulung durch, PECB stellt das Zertifikat separat aus"), die Wiederholung (mit 200 bis 400 Euro berechnet) oder die offiziellen Unterlagen (als separates Kit verkauft). ### Wie funktioniert die Inhouse-Preisgestaltung? Inhouse-Kohorten werden pro Kohorte und nicht pro Platz berechnet. Eine standardmäßige 5-tägige Lead Implementer Kohorte für bis zu 12 Teilnehmende kostet in Europa im Jahr 2026 zwischen 12.000 und 18.000 Euro. Der Preis deckt die Trainerzeit, die offiziellen PECB-Unterlagen für jeden Teilnehmenden, die Zertifizierungsgebühr für jeden Teilnehmenden und die Prüfung für jeden Teilnehmenden ab. Variablen, die den Preis verändern: Standort (Anreise vor Ort), Zeitplan (einzelner Block vs. aufgeteilte Sitzungen), Sprache (Englisch als Standard, weitere Sprachen auf Anfrage), Branchenanpassung (Beispiele und Übungen auf den Kontext des Käufers zugeschnitten) und die Seniorität des angefragten Trainers. ### Lohnt sich die günstigste Kohorte? Oft nicht. Das untere Ende des europäischen Marktes (1.500 bis 2.200 Euro mit Trainer, inklusive Prüfung) bedeutet typischerweise: Junior-Trainer, große Kohorte (15 bis 25 Teilnehmende), dünnes Coaching vor der Prüfung, begrenzte Nachbetreuung nach der Kohorte. Das Zertifikat, das Sie erhalten, ist dasselbe; die Wahrscheinlichkeit, beim ersten Versuch zu bestehen, ist deutlich geringer, und der operative Wissenstransfer ist uneinheitlich. Unsere Erstversuchs-Bestehensquote von 99,1 % bei von Trainern geleiteten PECB-Kohorten beruht teils auf dem Trainerpool und teils auf der Kohortengröße (10 bis 15, niemals darüber). Beides hat seinen Preis. ## Official sources - [PECB, ISO/IEC 27001 Lead Implementer training course](https://pecb.com/en/education-and-certification-for-individuals/iso-iec-27001) --- # ISO 31000: Foundation → Risk Manager → Lead Risk Manager. **URL:** https://cyberacademy.net/de/resources/pillars/iso-31000-foundation-risk-manager-lead-risk-manager **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition ISO 31000 ist die internationale Leitliniennorm für das Risikomanagement: Grundsätze, Rahmenwerk, Prozess, anwendbar auf jede Organisation und jede Art von Risiko. Sie ist nicht zertifizierbar; der PECB-Pfad lautet Foundation, Risk Manager und anschließend Lead Risk Manager. Es gibt keinen ISO 31000 Lead Auditor: ISO 31000 ist eine Leitlinie, keine Managementsystemnorm, daher gibt es nichts, wogegen auditiert werden könnte. ## TL;DR - ISO 31000 ist eine Leitlinie, kein zertifizierbares Managementsystem. Es gibt keinen Lead Auditor. - PECB-Pfad: Foundation (2 Tage), Risk Manager (5 Tage), Lead Risk Manager (5 Tage). Die höchste Qualifikation ist Lead Risk Manager. - Foundation vermittelt das Vokabular, die Grundsätze und das Prozessmodell. Erforderliche Voraussetzung für die höheren Qualifikationen. - Risk Manager wendet ISO 31000 auf einen bestimmten Anwendungsbereich an. Lead Risk Manager leitet das unternehmensweite Risikoprogramm über alle Funktionen hinweg. - Ergänzt ISO 27005 (informationssicherheitsspezifisches Risiko) und EBIOS RM (strategische Cyber-Szenarien): unterschiedliche Blickwinkel auf dieselbe Risikodisziplin. ## Full content ## Wie der ISO-31000-Pfad in einer Organisation tatsächlich funktioniert ISO 31000 implementiert man nicht so, wie man ein Managementsystem implementiert. Es gibt keine Erklärung zur Anwendbarkeit, keine verbindlichen Klauseln, die zu erfüllen sind, keinen Überwachungsauditzyklus. Was Sie stattdessen aufbauen, ist ein Risikomanagement-Rahmenwerk: eine Art und Weise, wie Risiken organisationsweit einheitlich identifiziert, analysiert, behandelt, überwacht und berichtet werden, sowie ein Prozess, dem die Personen in operativen Rollen tatsächlich folgen. Die Norm liefert Ihnen die Grundsätze und das Vokabular; die eigentliche Arbeit besteht darin, sie in Ihrer Governance, Ihren Gremien und Ihren Entscheidungspunkten mit Leben zu füllen. Deshalb verläuft der Pfad so, wie er verläuft. Foundation gibt Ihnen die gemeinsame Sprache, damit "Eintrittswahrscheinlichkeit", "Risikokriterien", "Risikoappetit" und "Restrisiko" für alle im Raum dasselbe bedeuten. Risk Manager lehrt Sie, den Prozess innerhalb eines definierten Anwendungsbereichs zu führen: einer Abteilung, eines Programms, einer Produktlinie. Lead Risk Manager lehrt Sie, das Rahmenwerk selbst über alle Funktionen hinweg zu gestalten und zu steuern, was ebenso sehr eine Governance-Aufgabe wie eine fachliche ist. Der Pfad ist bewusst sequenziell aufgebaut. Foundation ist die Voraussetzung für die höheren Qualifikationen, weshalb die meisten Praktiker mit dem ISO 31000 Foundation-Kurs beginnen, bevor sie entscheiden, ob sie die Stufe Risk Manager oder Lead Risk Manager benötigen. ## Die Wahl Ihrer Stufe: Risk Manager oder Lead Risk Manager Die Entscheidung hängt nicht von der hierarchischen Stellung auf dem Papier ab, sondern davon, wofür Sie verantwortlich sein werden. Risk Manager ist für die Person, die den Risikoprozess innerhalb eines Anwendungsbereichs führt und ein Risikoregister verantwortet: Sie moderieren Workshops, bewerten Risiken anhand vereinbarter Kriterien, schlagen Maßnahmen vor und halten das Register über die Zeit hinweg verlässlich. Lead Risk Manager ist für die Person, die das Ganze über die Organisation hinweg kohärent machen muss: die Risikokriterien und den Risikoappetit festlegen, das Rahmenwerk gestalten, es mit der Strategie und den anderen Assurance-Funktionen integrieren und an den Vorstand berichten. Ein nützlicher Test: Wenn Ihre Aufgabe lautet, zu beantworten "was sind unsere größten Risiken in diesem Bereich und was tun wir dagegen", ist Risk Manager die richtige Stufe. Wenn Ihre Aufgabe lautet, zu beantworten "ist unser Risikomanagement-Rahmenwerk zweckmäßig, und kann die Führung sich darauf verlassen, um Entscheidungen zu treffen", benötigen Sie Lead Risk Manager. Viele absolvieren zunächst Risk Manager, führen ein oder zwei Jahre ein Programm und absolvieren dann Lead Risk Manager, wenn sie in eine unternehmensweite oder CISO-nahe Rolle wechseln. **ISO 31000 PECB-Pfad: Stufe, Anwendungsbereich und für wen er passt** | Stufe | Dauer | Anwendungsbereich | Für wen er passt | | --- | --- | --- | --- | | Foundation | 2 Tage | Grundsätze, Rahmenwerk und Prozessmodell; nur Vokabular, keine Umsetzungsverantwortung | Alle, die die gemeinsame Sprache benötigen: Analysten, Projektmanager, Auditoren aus anderen Bereichen, Neueinsteiger ins Risikomanagement | | Risk Manager | 5 Tage | Den ISO-31000-Prozess innerhalb eines definierten Anwendungsbereichs anwenden; ein Risikoregister verantworten und führen | Praktiker, die Beurteilungen moderieren und das Risiko für eine Abteilung, ein Programm oder ein Produkt verwalten | | Lead Risk Manager | 5 Tage | Das unternehmensweite Risiko-Rahmenwerk gestalten und leiten; Kriterien und Appetit festlegen; an die Führung berichten | Heads of Risk, CISOs und erfahrene GRC-Rollen, die für das gesamte Programm verantwortlich sind | ## Warum es keinen ISO 31000 Lead Auditor gibt Diese Frage kommt ständig auf, weil die meisten anderen ISO-Qualifikationen paarweise auftreten: Lead Implementer und Lead Auditor, als Spiegelbild der zertifizierbaren Norm dahinter. ISO 31000 hat keinen Lead Auditor, weil es nichts gibt, wogegen auditiert werden könnte. Ein Audit prüft die Konformität mit Anforderungen, den "shall"-Aussagen einer Managementsystemnorm wie ISO 27001 oder ISO 9001. ISO 31000 enthält Leitlinien, das "should" der guten Praxis, keine Anforderungen. Sie können eine Organisation nicht nach ISO 31000 zertifizieren, also können Sie kein Zertifizierungsaudit dagegen durchführen, also gibt es keine Auditoren-Qualifikation. Das bedeutet nicht, dass sich das Risikomanagement der Prüfung entzieht. Es wird indirekt bewertet. Wenn ein ISO-27001-Auditor Ihren Risikobeurteilungs- und Risikobehandlungsprozess untersucht, prüft er die Konformität mit den ISO-27001-Klauseln 6.1 und 8.2/8.3, und ISO 31000 (oft über ISO 27005) ist die anerkannte Referenz dafür, wie dieser Prozess aussehen sollte. Der Lead Risk Manager baut also das Rahmenwerk auf, und der Managementsystem-Auditor prüft, ob das Rahmenwerk dort angewendet wird, wo eine zertifizierbare Norm es verlangt. Das sind zwei verschiedene Aufgaben, und ihre Vermischung ist das häufigste Missverständnis, das die Teilnehmer in den Schulungsraum mitbringen. > **Die Realität im Auditraum** In einem ISO-27001-Audit fragt niemand "sind Sie nach ISO 31000 zertifiziert". Man möchte Ihre Risikokriterien, Ihre Risikobeurteilungsergebnisse, Ihren Risikobehandlungsplan und den Nachweis sehen, dass Sie ihn überprüft haben. Ein sauberes, auf ISO 31000 basierendes Rahmenwerk macht diesen Teil des Audits kurz. Ein Rahmenwerk, das nur als Richtliniendokument existiert, mit einem Register, das seit einem Jahr niemand angefasst hat, ist die Quelle von Feststellungen. ## Wie ISO 31000 ISO 27005 und EBIOS RM ergänzt Dies sind keine konkurrierenden Normen; es sind unterschiedliche Blickwinkel auf dieselbe Disziplin, und erfahrene Praktiker nutzen sie gemeinsam. ISO 31000 ist der generische Rahmen, der für jedes Risiko in jeder Organisation gilt. ISO 27005 verengt diesen Rahmen auf Informationssicherheitsrisiken, mit den Details zu Werten, Bedrohungen und Schwachstellen, die ein ISMS benötigt. EBIOS Risk Manager, die französische Methode (ANSSI), nähert sich dem Problem von strategischen Angriffsszenarien und dem Ökosystem aus Angreifern und Stakeholdern her, was bei kritischen Cyber-Risiken stark ist und im öffentlichen und regulierten Sektor der EU zunehmend erwartet wird. Das praktische Muster ist geschichtet: ISO 31000 legt die Grundsätze, das Rahmenwerk und den Prozess fest, die die gesamte Organisation teilt; ISO 27005 Risk Manager gibt Ihnen die informationssicherheitsspezifische Methode, die sich in ein ISO-27001-ISMS einfügt; und EBIOS Risk Manager gibt Ihnen die szenariengetriebene, angreiferzentrierte Sicht für die wichtigsten Cyber-Risiken. Sie widersprechen einander nicht, und das Vokabular von ISO 31000 ist es, was einem Team erlaubt, ohne Verwirrung zwischen ihnen zu wechseln. **ISO 31000 vs. ISO 27005 vs. EBIOS RM** | | ISO 31000 | ISO 27005 | EBIOS RM | | --- | --- | --- | --- | | Anwendungsbereich | Jedes Risiko, jede Organisation | Informationssicherheitsrisiko | Strategische Cyber-Risikoszenarien | | Rolle | Grundsätze, Rahmenwerk, Prozess | IS-spezifische Risikomethode für ein ISMS | Angreifer- und ökosystemgetriebene Analyse | | Passt zu | Unternehmensweite Governance | ISO-27001-Zertifizierung | ANSSI / regulierter und öffentlicher Sektor | | Ansatz | Generisch und top-down | Wert, Bedrohung, Schwachstelle | Szenario- und stakeholdergetrieben | ## Relevanz über Cyber hinaus und die häufigen Fehler Da ISO 31000 risikoartunabhängig ist, deckt dasselbe Rahmenwerk operationelle, finanzielle, Lieferketten-, Projekt-, Sicherheits-, Compliance- und strategische Risiken ab. Genau das ist ihr eigentlicher Wert für einen CISO, der einen Platz am Tisch des Unternehmens einnehmen möchte: ISO 31000 zu sprechen bedeutet, die Sprache zu sprechen, die der Vorstand und die übergeordnete Risikofunktion bereits verwenden, und nicht einen Cyber-Dialekt, den sie übersetzen müssen. Die Qualifikation lässt sich gut außerhalb der Sicherheit einsetzen, was mit ein Grund dafür ist, dass sie im Zentrum einer ernsthaften GRC-Laufbahn steht und nicht an deren Rand. Die Fehler sind über Organisationen hinweg konsistent. Man behandelt das Risikoregister als Compliance-Artefakt, das einmal im Jahr zu erstellen ist, statt als lebendiges Entscheidungswerkzeug. Man definiert Risikokriterien, denen niemand zustimmt, sodass die Bewertung zur Inszenierung wird. Man verwechselt Risikoappetit (eine Führungsentscheidung) mit Risikotoleranz (der Betriebsspielraum) und legt weder das eine noch das andere ausdrücklich fest, was bedeutet, dass Behandlungsentscheidungen keinen Anker haben. Und man überspringt Foundation und wirft ein ganzes Team in einen Risk-Manager-Kurs, in dem die Hälfte des Raumes noch darüber streitet, was "Eintrittswahrscheinlichkeit" bedeutet. Wenn Sie ein Programm aufbauen und nicht nur eine Prüfung ablegen, ist die Reihenfolge, die funktioniert: Bringen Sie das Team durch ISO 31000 Foundation, um ein gemeinsames Vokabular zu schaffen, schicken Sie Ihre Bereichsverantwortlichen durch ISO 31000 Risk Manager, und lassen Sie diejenige Person, die das unternehmensweite Rahmenwerk verantwortet, ISO 31000 Lead Risk Manager absolvieren. Diese Reihenfolge vermeidet den teuersten Fehlermodus, nämlich ein Rahmenwerk, das nur eine einzige Person versteht. > **Legen Sie den Appetit fest, bevor Sie bewerten** Beginnen Sie nicht mit der Risikobewertung, bevor die Führung die Risikokriterien vereinbart und einen Appetit benannt hat, und sei er nur grob. Ohne diesen Anker ist jede Risikobewertung eine private Meinung, und Ihre Behandlungsentscheidungen sind nicht zu verteidigen. Lead Risk Manager existiert weitgehend dazu, diesen Schritt richtig zu machen. ## FAQ ### Warum gibt es keinen ISO 31000 Lead Auditor? ISO 31000 ist eine Leitlinie, keine Managementsystemnorm. Es gibt kein zertifizierbares System, gegen das auditiert werden könnte. Manche Schulungskataloge bewerben einen ISO 31000 Lead Auditor; diese Qualifikation existiert im PECB-Programm nicht. Wer danach fragt, meint in der Regel den ISO 27001 Lead Auditor (der das ISMS mit der Risikomethodik von ISO 27005 auditiert) oder den ISO/IEC 27005 Risk Manager (der die Methodik auf die Informationssicherheit anwendet). Wenn Ihr Auditor ein ISO-31000-Audit erwartet, widersprechen Sie: Es gibt kein zertifizierbares Konformitätskriterium. Vermutlich meint er eine Reifegradbeurteilung des Risikomanagement-Rahmenwerks, was eine andere Aufgabe ist. ### Risk Manager oder Lead Risk Manager: Was ist das Richtige für mich? Risk Manager (5 Tage) richtet sich an Praktiker, die einen definierten Risikobereich verantworten: eine Abteilung, ein Programm, eine Tochtergesellschaft. Der Kurs lehrt Sie, ISO 31000 innerhalb dieses Bereichs umzusetzen. Die meisten GRC-Analysten und Risk Officers bleiben auf dieser Stufe. Lead Risk Manager (5 Tage) richtet sich an erfahrene Praktiker, die das unternehmensweite Risikoprogramm verantworten: den Risikoappetit festlegen, das Rahmenwerk gestalten, das Risiko über Geschäftsbereiche hinweg integrieren und an den Vorstand berichten. Erforderlich, wenn die Rollenbezeichnung Head of Risk, Chief Risk Officer oder gleichwertig lautet. ### Wie verhält sich ISO 31000 zu ISO 27005? Unterschiedliche Anwendungsbereiche. ISO 31000 ist die generische Risikomanagement-Leitlinie und gilt für finanzielle Risiken, operationelle Risiken, strategische Risiken, Compliance-Risiken, Informationssicherheitsrisiken, kurzum für alles. ISO 27005 ist die Anwendung der Grundsätze von ISO 31000 speziell auf Informationssicherheitsrisiken im Kontext eines ISO-27001-ISMS. Eine Risikofachkraft mit ISO-31000-Qualifikationen arbeitet unternehmensweit. Eine auf Informationssicherheitsrisiken spezialisierte Fachkraft mit ISO-27005-Qualifikationen arbeitet innerhalb des ISMS-Anwendungsbereichs. Erfahrene Praktiker verfügen häufig über beides. ### Ist ISO 31000 auch außerhalb der Cybersicherheit relevant? Ja, sehr. ISO 31000 ist branchenunabhängig. Sie wird im Finanzrisikomanagement (neben den Basel- und Solvency-Rahmenwerken), im unternehmensweiten Risikomanagement (neben COSO ERM), im Lieferketten-, Umwelt-, Projekt- und operationellen Risiko eingesetzt. Die Grundsätze und das Prozessmodell sind über alle Bereiche hinweg identisch; nur die Werte- und Bedrohungskategorien ändern sich. ## Official sources - [ISO, ISO 31000:2018 Risk management](https://www.iso.org/iso-31000-risk-management.html) - [PECB, ISO 31000 Risk Manager](https://pecb.com/en/education-and-certification-for-individuals/iso-31000) --- # CISO vs. DPO vs. RSSI: Wer macht wirklich was. **URL:** https://cyberacademy.net/de/resources/pillars/ciso-dpo-rssi **Author:** Christophe Mazzola **Published:** 2026-05-14 **Last reviewed:** 2026-06-24 ## Definition Der CISO (Chief Information Security Officer) verantwortet die Informationssicherheitsstrategie und das zugehörige Programm. Der DPO (Data Protection Officer) verantwortet die durch die GDPR vorgeschriebene unabhängige Überwachung der Verarbeitung personenbezogener Daten. Der RSSI (Responsable de la Sécurité des Systèmes d'Information) ist das französische Pendant zum CISO. Die drei Rollen überschneiden sich am Perimeter der Datensicherheit, unterliegen aber unterschiedlichen Mandaten: CISO und RSSI gegenüber der Geschäftsleitung, der DPO gegenüber der Aufsichtsbehörde. ## TL;DR - CISO und RSSI sind dieselbe Rolle mit unterschiedlicher Bezeichnung. RSSI ist der französische Titel; CISO ist der internationale Titel. Gleicher Aufgabenbereich. - Der DPO ist durch die Konzeption der GDPR unabhängig, berichtet an die höchste Leitungsebene, kann für die Ausübung der Rolle nicht abberufen werden und ist die Anlaufstelle für die Aufsichtsbehörde. - Verantwortung des CISO/RSSI: Informationssicherheitsstrategie, Risikoregister, Incident Response, Berichterstattung an den Vorstand. Mandat von der Geschäftsleitung. - Verantwortung des DPO: Überwachung der GDPR-Konformität, Prüfung von DPIA, Rechte betroffener Personen, Dialog mit der Aufsichtsbehörde. Mandat aus der Verordnung. - Sie überschneiden sich bei der Datensicherheit (Article 32 der GDPR) und bei der Incident Response. In bedeutenden Organisationen sollte eine einzelne Person nicht beide Rollen innehaben; der DPO muss unabhängig von den Datenverarbeitungsentscheidungen bleiben, die der CISO umsetzt. ## Full content ## Zwei Verantwortlichkeiten, ein Perimeter Die Verwechslung dieser Rollen liegt nicht an den Stellenbezeichnungen. Sie liegt daran, welcher Autorität jede Person verantwortlich ist. Der CISO und der RSSI führen ein Programm im Auftrag der Geschäftsleitung: Sie werden daran gemessen, ob die Organisation sicher genug ist, um den Betrieb aufrechtzuerhalten, und ob der Vorstand das verbleibende Risiko versteht, das er trägt. Der DPO ist einem ganz anderen Herrn verantwortlich. Die Rolle existiert, weil die GDPR eine unabhängige Compliance-Funktion innerhalb der Organisation verankert hat, und diese Funktion berichtet an die höchste Leitungsebene, während sie sich aus den operativen Entscheidungen heraushält, die sie zu bewerten hat. Die eine Seite optimiert für das Geschäft. Die andere Seite muss in der Lage sein, dem Geschäft zu sagen, dass es falsch liegt. Operativ betrachtet bauen und verteidigen der CISO und der RSSI; der DPO prüft und hinterfragt. Wenn ein Marketingteam eine Kundendatenbank mit Drittdaten anreichern will, fragt der CISO, ob es sicher umgesetzt werden kann, und der DPO fragt, ob es unter den Maßstäben der Rechtmäßigkeit, Datenminimierung und Zweckbindung überhaupt getan werden sollte. Beide Fragen sind berechtigt. Es sind nicht dieselben Fragen, und in dem Moment, in dem man sie in einer Person zusammenführt, verliert man die zweite. ## Der Vergleich, auf den es wirklich ankommt Die meisten veröffentlichten Vergleiche enden bei Definitionen. Die Unterscheidung, die Auseinandersetzungen um das Organigramm entscheidet, ist die Berichtslinie und die Quelle des Mandats, denn das bestimmt, wer wen überstimmen kann und wer die Haftung trägt, wenn etwas schiefgeht. **CISO vs. DPO vs. RSSI: Mandat, Berichtslinie und signalisierende Zertifizierungen** | Dimension | CISO | DPO | RSSI | | --- | --- | --- | --- | | Primäres Mandat | Informationssicherheitsstrategie und -programm | Unabhängige Überwachung der Verarbeitung personenbezogener Daten | Wie der CISO (französischer Titel) | | Quelle der Autorität | Delegiert durch die Geschäftsleitung | Durch die GDPR vorgeschrieben und geschützt | Delegiert durch die Geschäftsleitung | | Berichtet an | CEO, Vorstand oder Risikoausschuss | Höchste Leitungsebene, mit Unabhängigkeit | Direction générale oder DSI | | Verantwortlich für | Risikoregister, Kontrollen, Incident Response, Berichterstattung an den Vorstand | Prüfung von DPIA, Rechte betroffener Personen, Verzeichnis von Verarbeitungstätigkeiten, Dialog mit der Aufsichtsbehörde | Gleicher Aufgabenbereich wie der CISO, französischer regulatorischer Kontext | | Kann für die Ausübung der Aufgabe abberufen werden? | Ja, wie jede Führungskraft | Nein, geschützt vor Abberufung für die Ausübung der Rolle | Ja, wie jede Führungskraft | | Signalisierende Zertifizierungen | CISM, PECB CCISO, Lead Cybersecurity Manager, CRISC | GDPR DPO, CDPSE, ISO 27701 Lead Implementer | Wie der CISO, oft zusätzlich ISO 27001 für den französischen Markt | Die Zertifizierungsspalte ist das praktische Signal, das ein einstellender Manager liest. Ein Sicherheitsführungsprofil baut auf CISM als Nachweis auf Managementebene, dem PECB Certified CISO für die Führungsperspektive und Lead Cybersecurity Manager für den Programmaufbau auf. Ein Datenschutzprofil signalisiert über den Certified Data Protection Officer und eine Privacy-Engineering-Ebene wie CDPSE. Die beiden Profile sind nicht austauschbar, und ein Lebenslauf, der sie ohne klare primäre Rolle vermischt, signalisiert in der Regel jemanden, der keines von beiden in der Tiefe gemacht hat. ## Wo sie sich wirklich überschneiden: Article 32 und Vorfälle Die Überschneidung ist real, und das Gegenteil zu behaupten ist der Weg, auf dem Organisationen Lücken bekommen. Article 32 der GDPR verlangt geeignete technische und organisatorische Maßnahmen zum Schutz personenbezogener Daten: Verschlüsselung, Resilienz, die Fähigkeit, die Verfügbarkeit wiederherzustellen, und regelmäßige Tests dieser Maßnahmen. Das ist Sicherheitsarbeit. Der CISO verantwortet die Kontrollen, die sie liefern. Doch der DPO muss in der Lage sein zu beurteilen, ob diese Maßnahmen dem Risiko für die betroffenen Personen angemessen sind, was eine andere Perspektive ist als die Angemessenheit für das Geschäft. Der saubere Weg, dies zu handhaben: Der CISO ist verantwortlich für die Umsetzung und den Betrieb der Maßnahmen nach Article 32, und der DPO ist verantwortlich dafür, sich eine unabhängige Meinung über ihre Angemessenheit zu bilden. Der CISO erstellt den Standard für Verschlüsselung im Ruhezustand; der DPO hält in der DPIA fest, dass er für die betreffende Verarbeitung ausreichend ist, oder weist darauf hin, dass er es nicht ist. Niemand bewertet seine eigene Arbeit. ISO 27701 sitzt genau auf dieser Nahtstelle. Sie erweitert ein ISO 27001 ISMS zu einem Datenschutz-Informationsmanagementsystem, was dem CISO und dem DPO einen gemeinsamen Kontrollrahmen statt zweier voneinander getrennter Begriffswelten gibt. Der Kurs ISO 27701 Lead Implementer ist die mit Abstand nützlichste Qualifikation für die Person, die das Sicherheitsprogramm und das Datenschutzprogramm in einen gemeinsamen Dialog bringen muss. Incident Response ist die zweite Überschneidung und diejenige, die unter Druck bricht. Der CISO führt die technische Reaktion: eindämmen, beseitigen, wiederherstellen. Der DPO führt die regulatorische Uhr: Die GDPR gibt 72 Stunden, um der Aufsichtsbehörde eine Verletzung des Schutzes personenbezogener Daten zu melden, und diese Einschätzung (ist es eine Verletzung, ist sie meldepflichtig, sind betroffene Personen gefährdet) ist die Entscheidung des DPO, nicht des CISO. Wenn diese beiden Personen nicht innerhalb der ersten Stunde eines schwerwiegenden Vorfalls im selben Raum sind, werden Sie entweder zu viel melden und Ihre Glaubwürdigkeit bei der Aufsichtsbehörde verlieren oder zu wenig melden und die Frist überschreiten. > **Ein Incident-Playbook führen, nicht zwei** Der häufigste Fehler ist ein Plan zur Reaktion auf Sicherheitsvorfälle, der den DPO nie erwähnt, und ein Verfahren für Datenschutzverletzungen, das die Eindämmung nie erwähnt. Führen Sie sie zusammen. Der Auslöser, der den CISO alarmiert, muss auch den DPO alarmieren, mit einem definierten Entscheidungspunkt zur Meldepflicht, bevor das 72-Stunden-Fenster zu laufen beginnt. ## Warum eine Person nicht CISO und DPO zugleich sein sollte Der Grund ist struktureller Natur, nicht eine Frage der Arbeitslast. Die GDPR verlangt, dass der DPO frei von jeglichem Interessenkonflikt ist: Der DPO darf keine Position innehaben, die das Festlegen der Zwecke und Mittel der Verarbeitung personenbezogener Daten umfasst. Genau das tut ein CISO. Der CISO entscheidet, welche Protokolle aufbewahrt werden, wie lange Backups bestehen, welche Überwachung den Datenverkehr von Mitarbeitenden inspiziert, welche Anbieter Daten verarbeiten. Das sind Verarbeitungsentscheidungen. Eine einzelne Person, die sie sowohl trifft als auch unabhängig prüfen soll, kann die zweite Aufgabe nicht erfüllen, denn die Aufsichtsbehörde wird Selbstprüfung nicht als unabhängige Überwachung akzeptieren. Das ist keine Meinung von Cyber Academy. Europäische Aufsichtsbehörden haben bereits Organisationen mit Bußgeldern belegt, die einen DPO ernannt haben, der zugleich eine operative Rolle über die Verarbeitung innehatte, die er überwachen sollte. In einer kleinen Organisation haben Sie möglicherweise tatsächlich eine fähige Person, die beides könnte. Die Antwort darauf ist nicht, die Rollen zu kombinieren; sie ist, diese Person zum CISO zu machen und den DPO extern zu bestellen, oder umgekehrt. Ein externer DPO ist eine anerkannte und oft sauberere Lösung, gerade weil die Unabhängigkeit von vornherein eingebaut ist. > **Das Muster für kleine Organisationen, das standhält** Unterhalb der Mitarbeiterzahl, ab der ein dedizierter DPO gerechtfertigt ist, halten Sie die Sicherheitsführung intern und vergeben Sie die DPO-Rolle an einen externen Dienstleister. Sie erhalten die geschützte Unabhängigkeit, die die GDPR will, der CISO behält die volle operative Autorität, und Sie haben eine dokumentierte Trennung, die ein Audit übersteht. ## Die Realität im Audit-Raum Wenn ein ISO 27001 Auditor oder eine Aufsichtsbehörde dies betrachtet, prüfen sie auf eine einzige Sache: Können Sie nachweisen, dass Sicherheitsentscheidungen und Datenschutzentscheidungen von Personen mit der richtigen Autorität und der richtigen Unabhängigkeit getroffen wurden. Die Nachweise, die sie verlangen, sind banal und konkret. 1. Eine RACI-Matrix oder ein gleichwertiges Dokument, das benennt, wer für das Risikoregister gegenüber dem Verzeichnis von Verarbeitungstätigkeiten verantwortlich ist, wobei keine Person für dieselbe Kontrolle zugleich die Rolle des Betreibens und des Überwachens innehat. 1. Vorfallaufzeichnungen, die zeigen, dass der DPO bei der Meldepflicht und der CISO bei der Eindämmung eingebunden war, mit Zeitstempeln, die in das 72-Stunden-Fenster passen. 1. DPIA, die eine unabhängige Stellungnahme des DPO zu den Sicherheitsmaßnahmen enthalten, nicht eine Sicherheitsfreigabe, die als Datenschutzprüfung umbenannt wurde. Die Audit- und Assurance-Kompetenzen, die dies nachweisbar machen, gehören wiederum zu einem eigenen Profil. CISA baut die Audit- und Nachweisdisziplin auf, und CRISC baut die Sprache der Risikoquantifizierung auf, die es dem CISO ermöglicht, dem Vorstand das verbleibende Risiko in Begriffen zu präsentieren, über die er tatsächlich entscheiden kann. Das sind die Nachweise, die eine vertretbare Struktur in eine nachweisbare verwandeln. ## Häufige Fehler, die es zu vermeiden gilt - CISO und RSSI als zwei separat zu besetzende Rollen zu behandeln. Sie sind dieselbe Rolle; der Titel folgt der Sprache und dem regulatorischen Kontext, nicht dem Aufgabenbereich. - Den DPO an den CISO oder die IT-Funktion berichten zu lassen. Das zerstört die von der GDPR geforderte Unabhängigkeit und ist eine einfache Feststellung für jede Aufsichtsbehörde. - Anzunehmen, dass die höchstrangige Zertifizierung gewinnt. Ein CISM-Inhaber ist deshalb nicht als DPO qualifiziert, und ein starker DPO-Nachweis macht aus jemandem keine Sicherheitsführungskraft. Stimmen Sie den Nachweis auf das Mandat ab. - Einen Vorstandsbericht zu schreiben, der Sicherheitsrisiko und Datenschutzrisiko zu einer einzigen Zahl vermischt. Der Vorstand muss beide sehen, denn die Konsequenzen und die beteiligten Behörden sind unterschiedlich. Die Organisationen, die dies richtig machen, haben nicht mehr Personal als jene, die es falsch machen. Sie haben eine klare Antwort auf eine einzige Frage: Wer baut bei jeder Entscheidung über personenbezogene Daten die Lösung, und wer beurteilt sie unabhängig. Halten Sie diese beiden Antworten in zwei verschiedenen Personen, geben Sie jeder den Nachweis, der zu ihrem Mandat passt, und das Organigramm hört auf, eine Quelle von Audit-Feststellungen zu sein. ## FAQ ### Kann dieselbe Person CISO und DPO sein? Technisch ja in kleinen Organisationen, doch der EDPB rät davon dringend ab. Der DPO muss unabhängig von den Verarbeitungsentscheidungen bleiben; der CISO setzt diese Entscheidungen um. In einer kleinen Organisation, in der dieselbe Person die Entscheidung trifft, ist die Unabhängigkeit fiktiv. In jeder Organisation von nennenswerter Größe (mehr als 50 Vollzeitkräfte, die in nennenswertem Umfang personenbezogene Daten verarbeiten) sollten die Rollen getrennt werden. Der DPO kann im Rechtsteam oder im Risikoteam angesiedelt sein oder direkt an den CEO berichten. Der CISO ist in der Technologie- oder Sicherheitsorganisation angesiedelt. ### Welche Zertifizierungen stehen für einen CISO? CISM (ISACA) ist der häufigste Nachweis in einem CISO-Lebenslauf; etwa 60 % der CISO-Ausschreibungen in Europa verlangen ihn. ISO 27001 Lead Implementer oder Lead Auditor (PECB) ist der zweithäufigste. CISSP ist die traditionelle Alternative im US-Stil. Für französische RSSI-Rollen haben von der ANSSI anerkannte Qualifikationen (EBIOS Risk Manager, Qualifikationen über die Programme SecNumCloud oder PASSI) Gewicht, zusätzlich zu oder anstelle von internationalen Nachweisen. ### Welche Zertifizierungen stehen für einen DPO? Der Certified Data Protection Officer (CDPO, von PECB ausgestellt, an der GDPR ausgerichtet) ist die europäische Referenz. Der CIPP/E (IAPP) ist der alternative internationale Datenschutznachweis, besonders anerkannt in Unternehmen mit US-Präsenz. Für technische DPOs (Privacy Engineers, die innerhalb oder neben dem Sicherheitsteam arbeiten) ist CDPSE (ISACA) die technische Ergänzung. ISO/IEC 27701 Lead Implementer (PECB) ist der Managementsystem-Nachweis für Organisationen, die ein Datenschutz-ISMS betreiben. ### Wie unterscheiden sich ihre Gehälter in Europa? Große Schwankungsbreite je nach Land und Branche. In Frankreich verdient ein erfahrener CISO/RSSI im Jahr 2026 in einem CAC-40-Unternehmen 130.000 bis 220.000 Euro Grundgehalt. Ein erfahrener DPO im selben Unternehmen verdient 90.000 bis 150.000 Euro Grundgehalt. Im Finanzdienstleistungssektor liegen beide Rollen tendenziell 20 % bis 30 % höher. Im Mittelstand liegen beide Rollen tendenziell 30 % bis 40 % niedriger. Die Gehaltsspanne spiegelt den Aufgabenbereich wider: CISO/RSSI verantwortet Budget, Personal und Technologieentscheidungen. Der DPO verantwortet Überwachung, Unabhängigkeit und den Kontakt zur Aufsichtsbehörde. ## Official sources - [EDPB, Guidelines on Data Protection Officers](https://www.edpb.europa.eu/) - [ANSSI, Référentiel d'exigences pour les RSSI](https://cyber.gouv.fr/) --- # ENCYCLOPEDIA ## AI Risk Manager **URL:** https://cyberacademy.net/de/resources/encyclopedia/ai-risk-manager **Last reviewed:** 2026-06-24 AI Risk Manager ist die Zertifizierung (PECB / ISACA emerging) für Praktiker, die KI-spezifische Risikoprogramme verantworten: Modellrisiko, Bias, Drift, Transparenz, Drittanbieter-Modellrisiko. Operative Schicht, die ISO 42001 (Systemebene) und den AI Act (regulatorische Ebene) ergänzt. Häufige Ergänzung zu einem CISO oder Lead AI Auditor. AI Risk Manager ist die operative Rolle und das aufkommende Zertifikat für Personen, die das KI-Risikoprogramm einer Organisation im Tagesgeschäft steuern. Während ISO 42001 das Managementsystem aufsetzt und der EU AI Act die rechtliche Untergrenze festlegt, ist der AI Risk Manager die Person, die diese Rahmenwerke in ein funktionierendes Register überführt: zu erkennen, wo ein Modell versagen kann, zu entscheiden, welche Kontrollen es umgeben, und das Restrisiko an die Leitung zu berichten. Es ist das KI-spezifische Pendant zum Risikomanager der Informationssicherheit und übernimmt den Großteil seiner Methode aus dem klassischen Risikomanagement, ergänzt um die Fehlermodi, die für maschinelles Lernen typisch sind. ## Was die Rolle tatsächlich umfasst Das klassische IT-Risiko fragt, ob ein System verfügbar, vertraulich und integer ist. Das KI-Risiko behält all dies bei und fügt eine Ebene von Fragen hinzu, die herkömmliche Kontrollen nie beantworten mussten. Ein AI Risk Manager arbeitet über den gesamten Modelllebenszyklus hinweg und verantwortet typischerweise die folgenden Risikofamilien. - Modellrisiko: Das Modell liegt auf schwer erkennbare Weise falsch, schneidet im Test gut, bei realen Eingaben jedoch schlecht ab oder versagt bei Randfällen unbemerkt. - Bias und Fairness: Das Modell erzeugt systematisch schlechtere Ergebnisse für bestimmte Gruppen, die häufig aus den Trainingsdaten übernommen werden. - Drift: Eingabedaten oder die reale Welt verändern sich nach der Inbetriebnahme, sodass die Genauigkeit mit der Zeit nachlässt und das Modell Überwachung sowie Auslöser für ein erneutes Training benötigt. - Transparenz und Erklärbarkeit: Stakeholder, Auditoren oder Regulierungsbehörden müssen verstehen, wie eine Entscheidung zustande kam, insbesondere bei Anwendungsfällen mit hoher Auswirkung. - Risiko durch Dritt- und Lieferkettenmodelle: Foundation-Modelle, APIs und Datensätze, die Sie nicht selbst erstellt haben, für die Sie aber verantwortlich sind. ## Wo sie sich im Verhältnis zu ISO 42001 und dem AI Act einordnet Am klarsten lässt sich die Rolle über Ebenen verorten. Der AI Act ist die regulatorische Ebene, die angibt, welche Pflichten für welche Risikostufe gelten. ISO 42001 ist die Ebene des Managementsystems, die die Governance-Struktur, die Rechenschaftspflicht und den Regelkreis der kontinuierlichen Verbesserung liefert, um diese Pflichten zu erfüllen. Der AI Risk Manager ist die darunterliegende operative Ebene, die die wiederkehrende Bewertungsarbeit leistet, die Nachweise an das AIMS liefert und belegt, dass die Hochrisikopflichten in der Praxis erfüllt werden. Deshalb ist die Rolle in der Regel eine Ergänzung zu einem CISO oder einem Lead AI Auditor und kein Ersatz dafür. **Die KI-Governance-Ebenen und die Rolle des AI Risk Managers** | Ebene | Artefakt | Frage, die sie beantwortet | | --- | --- | --- | | Regulatorisch | EU AI Act | Welche rechtlichen Pflichten gelten für dieses KI-System? | | Managementsystem | ISO/IEC 42001 (AIMS) | Wie regelt die Organisation den verantwortungsvollen Umgang mit KI? | | Operativ | KI-Risikoregister und Kontrollen | Wo kann dieses Modell versagen und was reduziert dieses Risiko? | | Assurance | KI-Audit (z. B. AAIA-Umfang) | Funktioniert das Obige wie beabsichtigt? | ## Die Zertifikatslandschaft Der Titel konsolidiert sich noch. PECB und ISACA sind die beiden Stellen, die am stärksten mit der Formalisierung von Kompetenz im KI-Risiko verbunden sind, und der Zertifizierungsmarkt ist jünger als bei etablierten Disziplinen wie dem CISA oder dem ISO 27001 Lead Implementer. In der Praxis ist es Arbeitgebern weniger wichtig, welches Abzeichen Sie tragen, als ob Sie eine belastbare KI-Risikobewertung durchführen, ein Kontrollset begründen und Ihre Arbeit auf die Klauseln von ISO 42001 und die Risikostufen des AI Act abbilden können. Betrachten Sie das Zertifikat als Nachweis der Methode, nicht als die Aufgabe selbst. > **Hinweis aus der Praxis** Wenn Sie bereits das Risiko der Informationssicherheit managen, haben Sie den Großteil des Weges hinter sich. Die übertragbaren Fähigkeiten sind das Risikoregister, Behandlungsentscheidungen und das Reporting an Stakeholder. Der neu aufzubauende Muskel ist das Verständnis des Modellverhaltens: Bias-Tests, Drift-Überwachung und Erklärbarkeit sowie die Lieferketten-Exposition, die mit der Nutzung von Foundation-Modellen einhergeht, die Sie nicht selbst trainiert haben. --- ## Advanced in AI Audit (AAIA) **URL:** https://cyberacademy.net/de/resources/encyclopedia/aaia **Last reviewed:** 2026-06-24 AAIA ist die weiterführende ISACA-Zertifizierung für die Prüfung von KI-Systemen, KI-Modellen und KI-Governance. Neu ab 2024. Setzt eine bestehende CISA oder gleichwertige Qualifikation voraus. Konzipiert für erfahrene Prüfer, die ihre KI-Kompetenz ausbauen. Ausgerichtet an ISO/IEC 42001 sowie den Hochrisikopflichten des EU AI Act. ## Wozu die AAIA-Zertifizierung dient Advanced in AI Audit (AAIA) ist eine ISACA-Zertifizierung für erfahrene Auditoren, die ihre Praxis auf künstliche Intelligenz ausweiten müssen. Sie ist eine jüngere Ergänzung des ISACA-Portfolios, eingeführt in dem Moment, in dem KI von Pilotprojekten zu Produktivsystemen überging, deren Verlässlichkeit Vorstände, Aufsichtsbehörden und Kunden nun erwarten. Die Prämisse ist eng und bewusst gewählt: Sie setzt voraus, dass Sie bereits auditieren können. AAIA bringt Ihnen den Auditprozess nicht erneut bei. Sie lehrt Sie, die Audit-Disziplin auf KI-Systeme, die dahinterstehenden Modelle und die sie umgebende Governance anzuwenden. Dieser Fokus ist der Grund, warum AAIA als fortgeschritten und nicht als Einstiegsniveau positioniert ist. Sie richtet sich an Auditoren, die bereits eine Audit-Zertifizierung sowie eine sichere Beherrschung von Kontrollen, Nachweisen und Berichterstattung besitzen und die nun Fragen beantworten müssen, für die ein traditionelles IT-Audit nie ausgelegt war. Sind die Trainingsdaten zweckdienlich? Lässt sich das Verhalten des Modells erklären? Gibt es eine wirksame menschliche Aufsicht dort, wo das System folgenreiche Entscheidungen trifft? Wird die KI ausschließlich für ihren erklärten Zweck genutzt? Genau diese Lücken soll AAIA schließen. ## Voraussetzungen und Einordnung AAIA ist darauf ausgelegt, auf einer bestehenden Audit-Grundlage aufzubauen, statt für sich allein zu stehen. ISACA positioniert sie für erfahrene Auditoren, und in der Praxis wird von den Kandidaten erwartet, dass sie CISA oder eine gleichwertige anerkannte Audit-Zertifizierung besitzen, bevor sie sie angehen. Die Logik ist dieselbe, die ISACA über sein gesamtes fortgeschrittenes Angebot anwendet: Die Zertifizierung fügt eine Spezialisierung auf einer bewährten Basis hinzu, sie ersetzt diese Basis nicht. Ein Auditor, der nie einen Auftrag geleitet hat, wird wenig aus AAIA ziehen, während ein erfahrener CISA-Inhaber einen strukturierten Weg erhält, KI-Aufträge belastbar zu machen. > **AAIA setzt voraus, dass Sie bereits auditieren können** Betrachten Sie AAIA als eine Spezialisierung, die auf einer bestehenden Audit-Zertifizierung wie CISA aufsetzt, nicht als erste Zertifizierung. Sie erweitert den Auditor, der Sie bereits sind, auf KI-Systeme, Modelle und Governance. ## Wie sie sich auf ISO 42001 und den EU AI Act bezieht Was AAIA praktisch statt akademisch macht, ist ihre Verankerung in den Rahmenwerken, an denen Auditoren nun prüfen sollen. Sie bezieht sich auf ISO/IEC 42001, die Managementsystemnorm für KI, die einem Auditor eine anerkannte Kontrollstruktur für KI-Governance liefert: Rechenschaftspflicht, Datenqualität, Transparenz, menschliche Aufsicht und Folgenabschätzung. Sie steht zudem im Einklang mit den Pflichten, die der EU AI Act Hochrisikosystemen auferlegt, bei denen Anbieter ein Risikomanagementsystem betreiben, technische Dokumentation führen, menschliche Aufsicht sicherstellen und eine Beobachtung nach dem Inverkehrbringen durchführen müssen. AAIA befähigt einen Auditor, Nachweise genau gegen diese Erwartungen zu sammeln. Hier unterscheidet sich AAIA von einer allgemeinen KI-Governance-Qualifikation. Ein Governance-Zertifikat bringt Ihnen bei, ein KI-Managementsystem zu gestalten und zu betreiben. AAIA bringt Ihnen bei, es unabhängig zu beurteilen: ein KI-Audit zu planen, es um den vorgesehenen Zweck und das Risiko herum abzugrenzen, die Kontrollen zu prüfen, die Nachweise zu bewerten und Feststellungen zu berichten, auf die ein Vorstand oder eine Aufsichtsbehörde reagieren kann. Es ist das Assurance-Gegenstück zu den Aufbau- und Betriebskompetenzen, die Rahmenwerke wie ISO 42001 verankern. ## Was AAIA-Inhaber tatsächlich tun In der Praxis arbeitet ein Auditor mit AAIA-Kompetenz bei einem KI-Auftrag meist eine erkennbare Abfolge ab: 1. Den Audit-Umfang um den vorgesehenen Zweck des KI-Systems, seine Risikoklassifizierung und die Rolle der Organisation als Entwickler, Anbieter oder Betreiber abgrenzen. 1. Die Governance bewerten: ob Rechenschaftspflicht zugewiesen ist, ob KI-Risiko- und Folgenabschätzungen existieren und ob sie aktuell gehalten werden. 1. Die für KI maßgeblichen Kontrollen prüfen, einschließlich Daten-Governance, Modelldokumentation, Transparenz gegenüber betroffenen Nutzern und menschlicher Aufsicht. 1. Die Überwachung nach der Bereitstellung, die Vorfallbehandlung und die Rückkopplungsschleife bewerten, die das System innerhalb seiner erklärten Grenzen hält. 1. Feststellungen in einer Audit-Sprache berichten, die sauber auf die ISO-42001-Kontrollen und die Pflichten des AI Act abbildet, damit die Organisation Lücken mit Nachweisen schließen kann. Der Wert für eine Organisation ist Unabhängigkeit. Ein KI-Governance-Team kann bescheinigen, dass Kontrollen existieren; ein mit AAIA ausgestatteter Auditor kann die Assurance im Stil einer dritten Partei liefern, dass diese Kontrollen tatsächlich funktionieren, was Aufsichtsbehörden, Unternehmenskunden und Beschaffungsstellen zunehmend sehen wollen. --- ## Business Continuity Management (BCM) **URL:** https://cyberacademy.net/de/resources/encyclopedia/bcm **Last reviewed:** 2026-06-24 BCM ist die Disziplin, die Bedrohungen für Ihre kritischen Betriebsabläufe identifiziert und anschließend die Pläne und Verfahren entwickelt, um diese bei einer Störung aufrechtzuerhalten. Kein einmaliges Projekt. Das BCM-Team, das bei einem realen Vorfall liefert, ist dasjenige, das vor vier Monaten eine Tabletop-Übung durchgeführt und dokumentiert hat, was dabei versagt hat. ## Was das Business Continuity Management tatsächlich abdeckt Das Business Continuity Management ist die Managementdisziplin, die die wichtigsten Aktivitäten einer Organisation am Laufen hält oder schnell wieder in Gang bringt, wenn etwas schiefgeht. Der Auslöser kann ein Cybervorfall, der Ausfall eines Lieferanten, eine Überschwemmung, ein Stromausfall oder eine Pandemie sein. Die Bedrohung muss nicht namentlich vorhergesagt werden. Entscheidend ist, dass die Aktivität, die sie lahmlegen würde, identifiziert, priorisiert und mit einem getesteten Plan zur Wiederherstellung innerhalb eines akzeptablen Zeitfensters ausgestattet wurde. Der Geltungsbereich ist bewusst breit angelegt. Das Business Continuity Management betrachtet Menschen, Räumlichkeiten, Technik, Lieferanten und Informationen, nicht nur die IT-Landschaft. Das ist das Erste, was es von der Disaster Recovery unterscheidet, dem IT-fokussierten Teilbereich, der sich mit der Wiederherstellung von Infrastruktur, Anwendungen und Daten befasst. Eine Bank kann jeden Server wiederherstellen und dennoch nicht arbeitsfähig sein, weil das Callcenter keinen Platz hat und der Dritte, der ihre Geschäfte bewertet, nicht erreichbar ist. Das Business Continuity Management verantwortet dieses Gesamtbild. Es ist außerdem ein kontinuierlicher Zyklus, kein Projekt mit Enddatum. Pläne veralten in dem Moment, in dem sich eine Organisation umstrukturiert, ein neues System einführt oder einen neuen kritischen Lieferanten anbindet. Die Teams, die bei einem echten Vorfall überzeugen, sind diejenigen, die kürzlich ein Szenario geübt und festgehalten haben, was nicht funktioniert hat, und es dann vor der nächsten Runde behoben haben. ## Der grundlegende Lebenszyklus des Business Continuity Management Die meisten Programme folgen einer erkennbaren Abfolge, die sich in der internationalen Norm ISO 22301 widerspiegelt: 1. Business-Impact-Analyse. Die strukturierte Untersuchung, die jede Aktivität danach einstuft, wie stark eine Störung im Zeitverlauf schadet, und die Wiederherstellungsziele hervorbringt. 1. Risikobeurteilung. Die Bedrohungen und Schwachstellen identifizieren, die am ehesten die priorisierten Aktivitäten stören. 1. Strategie und Lösungen. Festlegen, wie Aktivitäten am Laufen gehalten oder wiederhergestellt werden: Ausweichstandorte, Behelfslösungen, Redundanz, Diversifizierung der Lieferanten. 1. Pläne und Verfahren. Den Business-Continuity-Plan, die Struktur der Vorfallreaktion und die Wiederherstellungs-Runbooks verfassen, die die Menschen unter Druck tatsächlich nutzen werden. 1. Übungen und Überprüfung. Planübungen und Live-Tests, Nachbesprechungen nach Vorfällen und Audits, die Korrekturen in den Zyklus zurückführen. > **Die Zahlen kommen aus dem Geschäft, nicht aus dem Serverraum** Die Ziele für Wiederherstellungszeit und Wiederherstellungspunkt gehören den Personen, die für den Prozess verantwortlich sind, validiert durch die Business-Impact-Analyse. RTO- und RPO-Vorgaben, die ein Technikteam isoliert festlegt, sind diejenigen, die versagen, wenn eine echte Störung sie auf die Probe stellt. ## Wo das Business Continuity Management in der Regulierungslandschaft steht Kontinuität hat sich in mehreren Sektoren von der guten Praxis zur beaufsichtigten Pflicht entwickelt. ISO 22301 legt die Anforderungen an ein zertifizierbares Business-Continuity-Managementsystem fest und ist die Referenz, an der sich die meisten Organisationen ausrichten. In der Europäischen Union legt der Digital Operational Resilience Act Erwartungen an Kontinuität und Tests für Finanzunternehmen fest, und die NIS-2-Richtlinie verlangt von Betreibern in wesentlichen und wichtigen Sektoren Maßnahmen zur Geschäftskontinuität, einschließlich Datensicherung und Krisenmanagement. Eine Zertifizierung ist nicht zwingend erforderlich, um Business Continuity Management gut zu betreiben, aber sie verschafft Auditoren, Aufsichtsbehörden und Großkunden eine anerkannte Grundlage. Ob ein Programm ein Zertifikat anstrebt oder nicht, es gelten dieselben Disziplinen: die kritischen Aktivitäten kennen, vertretbare Wiederherstellungsziele festlegen, nutzbare Pläne verfassen und durch Tests nachweisen, dass sie funktionieren. --- ## Business Email Compromise (BEC) **URL:** https://cyberacademy.net/de/resources/encyclopedia/bec **Last reviewed:** 2026-06-24 BEC ist ein gezielter Social-Engineering-Angriff, bei dem ein Angreifer eine Führungskraft oder einen Lieferanten imitiert, um eine Zahlung umzuleiten oder einen Mitarbeiter zur Freigabe zu verleiten. Keine Malware erforderlich; reines Pretexting. Der durchschnittliche Schaden pro Vorfall übersteigt den bei Ransomware. Prozesskontrollen (Funktionstrennung, Rückrufverifikation) erkennen ihn; Technologie allein nicht. ## Was BEC vom gewöhnlichen Phishing unterscheidet Business Email Compromise ist Betrug, der über einen Vorwand statt über eine Schadlast ausgeführt wird. Der Angreifer braucht weder einen schädlichen Link noch einen Anhang, der Malware einschleust. Er braucht eine glaubwürdige Geschichte, ein Gefühl der Dringlichkeit und ein Opfer mit der Befugnis, Geld oder Daten zu bewegen. Eine gefälschte oder ähnlich aussehende Domain, ein kompromittiertes Postfach oder eine frisch registrierte Adresse, die einem bekannten Lieferanten ähnelt, genügen, um die Szene zu setzen. Da nichts technisch Schädliches über die Leitung geht, lassen sichere E-Mail-Gateways, Virenscanner und Link-Sandboxen die Nachricht häufig durch. Der Angriff lebt vollständig in der Konversation. Deshalb steht BEC in derselben Familie neben dem Phishing, verhält sich in der Praxis jedoch anders. Generisches Phishing ist ein breites Netz, das nach Zugangsdaten oder Klicks ausgeworfen wird. BEC ist geduldig und gezielt: Der Angreifer recherchiert das Organigramm, lernt, wer Rechnungen freigibt, studiert den Ton interner E-Mails und wartet auf einen glaubwürdigen Moment, etwa eine Übernahme, ein Immobiliengeschäft oder einen ins Ausland reisenden Finanzvorstand. Der Ertrag ist eine einzige betrügerische Überweisung oder eine umgeleitete Gehaltszahlung, oft über einen hohen Betrag, statt eines erbeuteten Passworts. ## Die gängigen Varianten, die Fachleute sehen BEC ist eine Kategorie, kein einzelner Trick. Dieselbe Vorwand-Logik wird gegen jeden Prozess wiederverwendet, der Werte innerhalb der Organisation bewegt. - CEO-Betrug: Ein Angreifer gibt sich als hochrangige Führungskraft aus und drängt einen Mitarbeiter der Finanzabteilung, eine dringende, vertrauliche Überweisung durchzuführen, wobei er sich auf Hierarchie und Diskretion stützt, um Rückfragen zu unterbinden. - Lieferanten- oder Vendor-Betrug, auch Rechnungsumleitung genannt: Ein vertrauenswürdiger Lieferant scheint per E-Mail neue Bankdaten mitzuteilen, sodass die nächste rechtmäßige Rechnung auf das Konto des Angreifers bezahlt wird. - Gehaltsumleitung: Ein Mitarbeiter scheint eine Änderung des Zielkontos für sein Gehalt zu beantragen und leitet so heimlich seine eigene Bezahlung an den Betrüger um. - Kontoübernahme: Ein echtes internes Postfach wird kompromittiert, sodass die betrügerische Anfrage von einer echten Adresse mit echter Historie eintrifft, was die meisten üblichen Warnzeichen beseitigt. - Anwalts- oder Juristen-Imitation: Der Vorwand stützt sich auf ein vertrauliches, zeitkritisches Geschäft, bei dem Geheimhaltung erwartet wird und eine Überprüfung unhöflich wirkt. ## Warum hier der Prozess die Technik schlägt E-Mail-Authentifizierung hilft. SPF, DKIM und DMARC erhöhen die Kosten reiner Domain-Fälschung und sollten eingesetzt werden. Doch sie richten nichts aus gegen eine ähnlich aussehende Domain, eine kostenlose Webmail-Adresse oder ein tatsächlich kompromittiertes internes Postfach, also die Kanäle, die echter BEC am häufigsten nutzt. Die entscheidenden Kontrollen sind prozeduraler Natur und liegen bei Finanzwesen und Betrieb statt beim Sicherheitswerkzeug. - Funktionstrennung, sodass keine einzelne Person eine Zahlung sowohl anfordern als auch freigeben kann. - Out-of-Band-Rückrufverifizierung: Bestätigen Sie jede neue oder geänderte Bankverbindung und jede ungewöhnliche Überweisung über eine bereits hinterlegte Telefonnummer, niemals über eine Nummer oder einen Kontakt, der innerhalb der Anfrage selbst angegeben wurde. - Eine strikte Regel, dass Dringlichkeit und Vertraulichkeit niemals den standardmäßigen Freigabeweg umgehen; diese beiden Emotionen sind die Werkzeuge des Angreifers. - Schwellenwerte für die doppelte Autorisierung bei Überweisungen und Änderungen von Lieferanten-Bankdaten. > **Die Anfrage prüfen, nicht das Postfach** Der gefährlichste BEC kommt von einer echten, vertrauenswürdigen Adresse, weil das Postfach übernommen wurde. Ein sauberer Absender, eine gültige Signatur und ein vertrauter Signaturblock beweisen nichts. Prüfen Sie die Anweisung selbst über einen separaten Kanal, bevor Geld fließt. ## Wo BEC im regulatorischen Bild steht BEC ist eine Hauptursache für finanzielle Verluste im Zusammenhang mit E-Mail, was es klar in den Geltungsbereich rückt, den ein Informationssicherheits-Managementsystem adressieren soll. Unter einem ISO 27001 ISMS ist die einschlägige Behandlung eine Mischung aus Awareness-Schulungen, Kontrollen der Lieferantenbeziehungen und den operativen Verfahren, die Zahlungen regeln. Wenn BEC gelingt und personenbezogene Daten offengelegt werden, etwa durch ein kompromittiertes Postfach voller Korrespondenz, kann es zudem Pflichten zur Meldung einer Verletzung des Schutzes personenbezogener Daten nach der DSGVO auslösen, weshalb der Reaktionsplan die Rechtsabteilung und die Datenschutzfunktion einbeziehen muss, nicht nur Finanzwesen und IT. Für Fachleute lautet die Erkenntnis, dass die Abwehr von BEC eine geteilte Verantwortung ist. Die Sicherheit verantwortet E-Mail-Authentifizierung, Überwachung und Awareness. Das Finanzwesen verantwortet die Zahlungskontrollen, die den Betrug tatsächlich stoppen. Es als rein technisches Problem zu behandeln, das durch ein besseres Gateway gelöst wird, ist der Fehler, der die Verluste in Gang hält. --- ## Business Impact Analysis (BIA) **URL:** https://cyberacademy.net/de/resources/encyclopedia/bia **Last reviewed:** 2026-06-24 Eine BIA ist die strukturierte Analyse, die die Auswirkungen einer Unterbrechung auf jede kritische Aktivität über die Zeit quantifiziert. Die Ergebnisse umfassen den Recovery Time Objective, den Recovery Point Objective und den Minimum Business Continuity Objective. Pflichtgrundlage für ISO 22301 und DORA. Gut durchgeführt, wird sie zum Dokument, das der Vorstand tatsächlich liest. ## Was eine BIA tatsächlich leistet Eine Business Impact Analysis beantwortet eine Frage, von der der Rest des Kontinuitätsprogramms abhängt: Wenn diese Aktivität ausfällt, wie schlimm wird es, und wie schnell? Sie nehmen jede Geschäftsaktivität, projizieren sie in die Zeit und beschreiben die Folgen ihrer Unterbrechung für jedes Intervall. Manche Aktivitäten schmerzen innerhalb von Minuten, die Zahlungsabwicklung oder die Aufnahme in einem Krankenhaus. Andere können tagelang ausfallen, bevor jemand außerhalb des Teams es bemerkt. Die BIA ist das, was beide voneinander trennt, damit die knappen Wiederherstellungsressourcen dorthin fließen, wo sich der Schaden am schnellsten ansammelt, und nicht dorthin, wo zufällig der lauteste Manager sitzt. Die Auswirkung wird über mehrere Dimensionen hinweg bewertet, nicht nur über entgangene Umsätze. Der finanzielle Verlust ist der offensichtliche, doch eine ernsthafte BIA erfasst auch die regulatorische und rechtliche Exposition, vertragliche Strafzahlungen, die Sicherheit von Personen und den Reputationsschaden. Eine Folge, die in Euro trivial ist, kann in Bezug auf Vertrauen existenziell sein. Der Sinn der Betrachtung über mehrere Dimensionen besteht darin, dass die Aktivität, die finanziell ganz oben auf der Liste steht, selten dieselbe ist, die rechtlich oder bei der Sicherheit ganz oben steht, und der Vorstand muss sie alle sehen, bevor er Prioritäten setzt. ## Von der Auswirkung zu den Zielen Die BIA hört nicht bei der Beschreibung auf. Sie liefert die Zahlen, auf denen die Wiederherstellungsstrategie aufbaut. Während die Auswirkung im Zeitverlauf steigt, erreichen Sie den Punkt, an dem sie inakzeptabel wird. Diese Schwelle setzt das recovery time objective, den maximal tolerierbaren Zeitraum, in dem die Aktivität ausgefallen bleiben kann. Das recovery point objective ergibt sich aus derselben Übung auf der Datenseite: Wie viel jüngste Arbeit, gemessen in Zeit, kann verloren gehen, bevor die Störung einen inakzeptablen Schaden verursacht. Das minimum business continuity objective beschreibt das reduzierte Betriebsniveau, das Sie während der Störung aufrechterhalten müssen, nicht den vollen Betrieb, aber genug, um lebensfähig zu bleiben. Diese Ergebnisse sind der formale Input für die Kontinuitätsstrategie. Ein recovery time objective ist eine Anforderung an die Wiederherstellungslösung, kein Wunsch. Wenn die BIA besagt, dass eine Aktivität innerhalb eines engen Zeitfensters wieder verfügbar sein muss, müssen die Strategie und das Budget das liefern, oder die Organisation muss die Lücke bewusst akzeptieren. Deshalb ist die BIA das Dokument, das von den Geschäftsverantwortlichen freigegeben und vom Vorstand gelesen werden sollte, statt von der IT isoliert verfasst zu werden. > **Die Zahlen gehören dem Geschäft** Das häufigste Versagen ist eine BIA, deren Wiederherstellungsziele von technischem Personal festgelegt wurden, ohne dass die Aktivitätsverantwortlichen im Raum waren. Diese Zahlen wirken auf dem Papier präzise und brechen bei einem echten Vorfall zusammen, weil niemand, der die Folge trägt, ihnen je zugestimmt hat. Validieren Sie jedes RTO und RPO mit den Personen, die für die Aktivität verantwortlich sind. ## Wo die BIA in den Standards verortet ist Nach ISO 22301 ist die BIA ein erforderlicher Schritt bei der Einrichtung eines Business-Continuity-Management-Systems. Der Standard erwartet von Ihnen, die Aktivitäten zu bestimmen, die die Lieferung von Produkten und Dienstleistungen unterstützen, die Auswirkungen ihrer Nichtdurchführung im Zeitverlauf zu bewerten und das zu nutzen, um priorisierte Zeitrahmen für die Wiederaufnahme festzulegen. Die BIA fließt direkt in die Risikobeurteilung und die Wahl der Kontinuitätsstrategie ein. Nach DORA gilt dieselbe Logik für die digitale operationale Resilienz: Von Finanzunternehmen wird erwartet, dass sie die Auswirkung einer Störung auf ihre kritischen oder wichtigen Funktionen verstehen, und dieses Verständnis beginnt mit einer Auswirkungsanalyse. Eine BIA ist keine Risikobeurteilung, und beide zu vermengen schwächt beide. Die Risikobeurteilung fragt, was eine Störung verursachen könnte und wie wahrscheinlich sie ist. Die BIA ist bewusst bedrohungsagnostisch: Sie fragt, wie sehr eine Störung schmerzt, unabhängig von der Ursache, ob der Auslöser ein Cyberangriff, eine Überschwemmung oder ein ausgefallener Lieferant ist. Sie führen sie als ergänzende Übungen durch. Die BIA sagt Ihnen, was geschützt werden muss und wie schnell es sich erholen muss; die Risikobeurteilung sagt Ihnen, was es am wahrscheinlichsten bedroht. Zusammen rechtfertigen sie, wohin die Kontinuitätsinvestition fließt. Praktisch wird eine BIA in einem Zyklus und nach größeren Veränderungen wiederholt, weil Aktivitäten, Abhängigkeiten und Toleranzen sich verschieben. Der Lieferant, der letztes Jahr peripher war, befindet sich jetzt auf Ihrem kritischen Pfad; der Prozess, den Sie zwei Tage lang verlieren konnten, hat jetzt Kundenkontakt. Eine BIA, die zwei Umstrukturierungen alt ist, ist Dekoration. --- ## CIS Controls **URL:** https://cyberacademy.net/de/resources/encyclopedia/cis-controls **Last reviewed:** 2026-06-24 Die CIS Critical Security Controls sind ein priorisierter Satz von 18 Kontrollkategorien, veröffentlicht vom Center for Internet Security. Implementierungsgruppen (IG1, IG2, IG3) orientieren sich an der Reife der Organisation. Der schnellste Weg, eine kleine oder mittelgroße Organisation von null auf ein verteidigungsfähiges Niveau zu bringen. Lässt sich sauber auf ISO/IEC 27001 Annex A abbilden. ## Was die CIS Controls tatsächlich sind Die CIS Critical Security Controls sind eine geordnete, klar positionierte Antwort auf eine Frage, vor der jeder Verteidiger steht: Von allem, was Sie tun könnten, was sollten Sie zuerst tun? Veröffentlicht und gepflegt vom Center for Internet Security, verdichten sie reale Angriffsdaten zu einem priorisierten Satz von Schutzmaßnahmen, gegliedert in 18 Kontrollkategorien, vom Inventar der Unternehmensassets und der Software über Datenschutz, Zugriffskontrolle, kontinuierliches Schwachstellenmanagement, Verwaltung von Audit-Protokollen bis zur Reaktion auf Vorfälle. Anders als ein Rahmenwerk, das Ihnen sagt, einen Prozess einzurichten, sagen Ihnen die Controls konkret, was zu implementieren ist und ungefähr in welcher Reihenfolge, weshalb sie oft der schnellste Weg von keinem Sicherheitsprogramm zu einem belastbaren sind. Das bestimmende Merkmal ist die Priorisierung. Die Liste ist weder alphabetisch noch theoretisch; die frühen Kontrollen sind diejenigen, die die häufigsten Angriffe blockieren. Zu wissen, welche Hardware und Software Sie besitzen, sie sicher zu konfigurieren, administrative Berechtigungen zu kontrollieren und bekannte Schwachstellen zu patchen, verhindert einen großen Teil realer Vorfälle, bevor Sie einen einzigen Euro für fortgeschrittene Werkzeuge ausgeben. Genau diese Reihenfolge ist der Wert: Ein kleines Team mit begrenzter Zeit kann oben beginnen und sich nach unten arbeiten, in der Gewissheit, die Lücken zu schließen, die Angreifer tatsächlich ausnutzen. ## Die Implementation Groups: IG1, IG2, IG3 Die Controls skalieren über drei Implementation Groups, sodass derselbe Katalog sowohl einem Zwei-Personen-Betrieb als auch einem multinationalen Konzern dient. IG1 ist als grundlegende Cyber-Hygiene definiert, der Mindestsatz, den jede Organisation eingerichtet haben sollte, ausgelegt für Unternehmen mit begrenztem Fachwissen und begrenzten Ressourcen zum Schutz vor unraffinierten, opportunistischen Angriffen. IG2 ergänzt Schutzmaßnahmen für Organisationen, die sensiblere Daten verwalten und es mit fähigeren Gegnern zu tun haben. IG3 ist der vollständige Satz, gedacht für reife Organisationen, die kritische Assets halten und sich gegen gezielte, raffinierte Angriffe verteidigen müssen. Jede Gruppe ist kumulativ: IG2 enthält alles aus IG1, und IG3 enthält alles aus IG1 und IG2. **CIS Implementation Groups** | Gruppe | Für wen sie passt | Sicherheitslage | | --- | --- | --- | | IG1 | Kleine bis mittelgroße Organisationen, begrenzte IT- und Sicherheitsressourcen | Wesentliche Cyber-Hygiene, Basisverteidigung | | IG2 | Organisationen mit sensibleren Daten, eigenes Sicherheitspersonal | Gehärtet gegen fähigere Angreifer | | IG3 | Reife Organisationen mit kritischen Assets und hoher Exposition | Vollständiger Satz an Schutzmaßnahmen gegen gezielte Angriffe | In der Praxis bewerten Sie sich selbst hin zu einer Implementation Group und behandeln dann die Schutzmaßnahmen dieser Gruppe als Ihren Arbeitsplan. Die meisten kleinen und mittelgroßen Organisationen sollten zuerst klar auf IG1 abzielen und erst zu IG2 übergehen, sobald diese steht. Das macht die Controls dort zugänglich, wo ein vollständiges Managementsystem unerreichbar wirken kann: Ihnen wird eine endliche, überprüfbare Checkliste in die Hand gegeben, die auf Ihre Realität zugeschnitten ist. ## Wo sie neben ISO 27001 und anderen Rahmenwerken stehen Die CIS Controls sind ein Kontrollkatalog, kein zertifizierbares Managementsystem, und diese Unterscheidung ist wichtig. ISO 27001 zertifiziert, dass Sie ein Informationssicherheits-Managementsystem mit Risikobeurteilung, einer Erklärung zur Anwendbarkeit und kontinuierlicher Verbesserung betreiben; CIS gibt Ihnen einen konkreten, priorisierten Satz technischer und operativer Schutzmaßnahmen, die Sie darunter umsetzen. Sie sind eher ergänzend als konkurrierend. CIS veröffentlicht Zuordnungen seiner Schutzmaßnahmen zu Anhang A der ISO 27001 und zu anderen Referenzen wie den NIST-Rahmenwerken, sodass die Umsetzungsarbeit, die Sie für CIS leisten, zu einem Nachweis wird, den Sie gegenüber einem ISO-Kontrollsatz vorlegen können. Teams nutzen CIS häufig, um die praktische Härtung voranzutreiben, und ordnen diesen Aufwand dann demjenigen Rahmenwerk zu, das ihre Auditoren oder Kunden verlangen. > **Beginnen Sie oben, nicht überall** Die Controls sind aus gutem Grund geordnet. Ein kleines Team gewinnt mehr Schutz, indem es IG1 der Reihe nach abschließt, beginnend mit dem Inventar von Assets und Software und der sicheren Konfiguration, als indem es fortgeschrittene Schutzmaßnahmen herauspickt, während die Grundlagen offen bleiben. --- ## COBIT **URL:** https://cyberacademy.net/de/resources/encyclopedia/cobit **Last reviewed:** 2026-06-24 COBIT ist das ISACA-Framework für die Governance und das Management der Unternehmens-IT. Die aktuelle Ausgabe ist COBIT 2019. Die Big Four nutzen dieses Framework zur Bewertung der IT-Governance-Reife; es dient zudem als Referenz für die CGEIT-Zertifizierung. Strategischer ausgerichtet als ISO 27001, weniger präskriptiv als NIST. ## Was COBIT tatsächlich steuert COBIT ist das Rahmenwerk der ISACA für die Governance und das Management der Unternehmens-IT. Seine grundlegende Unterscheidung, und diejenige, über die Praktiker am häufigsten stolpern, ist die Trennlinie, die es zwischen Governance und Management zieht. Governance ist Sache des Vorstands und der Geschäftsleitung: die Richtung vorgeben, Optionen bewerten und Ergebnisse überwachen. Management umfasst das Planen, Aufbauen, Betreiben und Überwachen der Aktivitäten, die diese Richtung umsetzen. COBIT hält diese beiden Bereiche getrennt, damit diejenigen, die entscheiden, was die IT erreichen soll, nicht dieselben sind, die berichten, ob es erreicht wurde. Diese Trennung ist der Grund, warum Auditoren zu COBIT greifen, wenn eine Norm für Informationssicherheit nicht ausreicht. ISO 27001 sagt Ihnen, wie Sie ein Informationssicherheits-Managementsystem betreiben. NIST liefert Ihnen einen Katalog von Maßnahmen und Ergebnissen. COBIT steht über beiden: Es beantwortet, ob die IT als Ganzes auf die Ziele des Unternehmens ausgerichtet ist, ob Risiken und Ressourcen verantwortungsvoll gehandhabt werden und ob die Stakeholder Wert erhalten. Es ist breiter angelegt als Sicherheit und bewusst weniger präskriptiv als eine Maßnahmenliste. ## Die Struktur von COBIT 2019 Die aktuelle Ausgabe ist COBIT 2019. Sie gliedert die Arbeit in Ziele, die unter Governance- und Management-Domänen gruppiert sind, und ordnet jedem die Komponenten zu, die zum Funktionieren erforderlich sind: Prozesse, Organisationsstrukturen, Richtlinien, Informationsflüsse, Kultur, Kompetenzen und Services. Der Kern ist, dass ein Prozess auf dem Papier nichts bedeutet, wenn die Strukturen, Kompetenzen und die Kultur darum herum fehlen, sodass COBIT Sie zwingt, sie alle gemeinsam zu betrachten. Zwei Konzepte machen COBIT 2019 in der Praxis nutzbar und nicht bloß zu einem Poster an der Wand: - Die Gestaltungsfaktoren. Unternehmensstrategie, Risikoprofil, Compliance-Anforderungen, Rolle der IT und Sourcing-Modell bestimmen gemeinsam, welche Ziele Aufmerksamkeit verdienen. COBIT setzt nicht voraus, dass jede Organisation dasselbe Governance-System benötigt, sodass Sie das Rahmenwerk an den Kontext anpassen, statt es pauschal zu übernehmen. - Fähigkeit und Reifegrad. Jedes Governance- und Management-Ziel kann auf einer Fähigkeitsskala bewertet werden, und das Rahmenwerk unterstützt zudem eine Reifegradbetrachtung über Schwerpunktbereiche hinweg. So erstellen die Big Four und interne Auditteams ein belastbares Bild von «Wo stehen wir, wo sollten wir stehen» anstelle einer subjektiven Meinung. > **COBIT ist eine Betrachtungsweise, keine Checkliste** Man «implementiert COBIT» nicht so, wie man ein ISMS implementiert. Man nutzt es, um zu beurteilen, wie gut die IT gesteuert wird, um ein zum eigenen Kontext passendes Governance-System zu entwerfen und um die bereits eingesetzten Normen wie ISO 27001, NIST oder ITIL zu einem kohärenten Ganzen zusammenzuführen und zu rationalisieren. ## Wo COBIT neben anderen Rahmenwerken steht Praktiker setzen COBIT fast immer neben anderen Rahmenwerken ein, statt an deren Stelle. Ein gängiges Muster: COBIT definiert die Governance-Ziele und die Reifegrad-Baseline, ISO 27001 operationalisiert die Informationssicherheit, ITIL übernimmt das Service-Management, und ein Risiko-Rahmenwerk speist das Risikobild. COBIT wird zum Schirm, der zeigt, wie diese Bausteine den Unternehmenszielen dienen und wo die Lücken liegen. **COBIT im Vergleich zu benachbarten Rahmenwerken** | Rahmenwerk | Primärer Fokus | Ausrichtung | | --- | --- | --- | | COBIT | Governance und Management der Unternehmens-IT | Strategisch, auf Rahmenwerksebene, an den Kontext angepasst | | ISO 27001 | Informationssicherheits-Managementsystem | Zertifizierbar, operativ, sicherheitsbezogener Geltungsbereich | | NIST-Rahmenwerke | Cybersicherheitsergebnisse und Maßnahmenkataloge | Detailliert, präskriptiv, maßnahmenorientiert | | ITIL | IT-Service-Management | Operativ, auf die Servicebereitstellung ausgerichtet | COBIT ist außerdem der Wissenskörper hinter der CGEIT-Zertifizierung der ISACA, die sich an Fachleute richtet, die für die Governance der Unternehmens-IT verantwortlich sind. Wenn Ihre Rolle darin besteht, die Steuerung der IT auf Vorstandsebene zu prüfen oder zu gestalten, ist COBIT das Referenzrahmenwerk und CGEIT die passende Zertifizierung. --- ## Certificate of Cloud Auditing Knowledge (CCAK) **URL:** https://cyberacademy.net/de/resources/encyclopedia/ccak **Last reviewed:** 2026-06-24 CCAK ist die gemeinsame Zertifizierung von ISACA und der Cloud Security Alliance für Cloud-Auditoren. Themen sind Cloud-Governance, CCM, das STAR-Programm sowie hyperscalerspezifische Prüfungsaspekte. Die logische Erweiterung für einen CISA-Inhaber, dessen Prüfungsumfang cloud-first geworden ist. ## Was das CCAK tatsächlich zertifiziert Das Certificate of Cloud Auditing Knowledge ist ein gemeinsamer Nachweis von ISACA und der Cloud Security Alliance und schließt eine bestimmte Lücke. Die klassische IT-Audit-Ausbildung setzt voraus, dass Sie durch das Rechenzentrum gehen, die Change-Tickets prüfen und Kontrollen, die die Organisation vollständig selbst besitzt, durchgängig testen können. In der Cloud bricht diese Annahme zusammen. Der Anbieter betreibt die physische Infrastruktur, den Hypervisor und große Teile der Plattform, und Sie bekommen sie nie zu Gesicht. Das CCAK ist darauf ausgerichtet, wie man genau diese Konstellation prüft und absichert: wie sich die Kontrollverantwortung zwischen Kunde und Anbieter aufteilt, welche Nachweise Sie tatsächlich erlangen können und wie man über Assurance argumentiert, wenn man den Test nicht selbst durchführen kann. Es handelt sich um ein Wissenszertifikat und nicht um eine an Erfahrung gebundene Zertifizierung, daher ist keine mehrjährige Berufserfahrung als Voraussetzung damit verknüpft, wie es beim CISA der Fall ist. Das macht es früher in einer Laufbahn zugänglich, doch es ist als Ergänzung zu tiefergehenden Audit-Nachweisen positioniert und nicht als Ersatz. Der naheliegende Leser ist jemand, der die Audit-Methodik bereits beherrscht und nun die cloudspezifische Schicht obendrauf benötigt. ## Was der Wissensbestand abdeckt Das CCAK ist an die eigenen Werkzeuge der CSA verankert und nicht an die Dokumentation eines einzelnen Anbieters, und genau das hält es herstellerneutral. Zu den zentralen Referenzpunkten, mit denen Praktiker zu arbeiten lernen, gehören: - Die Cloud Controls Matrix (CCM), das Kontroll-Framework der CSA, das über die Cloud-Domänen hinweg abgebildet und mit Normen wie ISO 27001 sowie den wichtigsten Regulierungsregimen verknüpft ist. Es ist der Kontrollkatalog, gegen den Sie eine Cloud-Umgebung bewerten. - Das Consensus Assessments Initiative Questionnaire (CAIQ), der standardisierte Fragenkatalog, den ein Kunde einem Anbieter stellt, um zu verstehen, welche CCM-Kontrollen der Anbieter betreibt und wie. - Das STAR-Programm (Security, Trust, Assurance and Risk), das Assurance-Register der CSA. STAR umfasst Stufen, die von der Selbstbewertung des Anbieters bis zur Zertifizierung durch Dritte reichen, und das CCAK lehrt Sie zu lesen, was jede Stufe belegt und was nicht. - Geteilte Verantwortung, Kontrollzuordnung und anbieterspezifische Audit-Aspekte über die wichtigsten Hyperscaler hinweg, sodass Sie wissen, welche Kontrollen Sie testen, welche der Anbieter attestiert und wo die Nahtstelle zwischen beiden liegt. > **Ein Wissenszertifikat, keine ISMS-Zertifizierung** Das CCAK zertifiziert das Cloud-Audit-Wissen einer Person. Es unterscheidet sich von CSA STAR, über das ein Cloud-Dienst selbst Assurance erlangt. Sie lernen, STAR zu bewerten; STAR wird nicht an Sie verliehen. ## Wo das CCAK neben CISA und CCSP steht Praktiker verwechseln das CCAK regelmäßig mit den beiden Nachweisen, zwischen denen es angesiedelt ist, daher lohnt es sich, die Abgrenzung sauber zu ziehen. Das CISA belegt, dass Sie Informationssysteme überhaupt prüfen können. Das CCSP von (ISC)2 ist ein breiter Nachweis für Design und Architektur der Cloud-Sicherheit. Das CCAK ist enger und spezifischer als beide: Es geht um die Absicherung der Cloud, nicht um deren Aufbau und nicht um das Prüfen von Systemen im Allgemeinen. **Das CCAK im Vergleich zu benachbarten Nachweisen** | Nachweis | Hauptfokus | Ausrichtung | | --- | --- | --- | | CCAK | Prüfung und Absicherung von Cloud-Umgebungen | Cloudspezifisch, wissensbasiert, herstellerneutral | | CISA | Prüfung von Informationssystemen im Allgemeinen | Breite Audit-Methodik, an Erfahrung gebunden | | CCSP | Entwurf und Absicherung der Cloud-Architektur | Sicherheitsarchitektur, nicht auf Audit ausgerichtet | In der Praxis ist die stärkste Kombination CISA plus CCAK. Das CISA liefert die Audit-Disziplin, die Nachweisstandards und die Haltung der Unabhängigkeit; das CCAK ergänzt die Cloud-Überlagerung, sodass ein CISA-Inhaber, dessen Aufgabenbereich cloud-first geworden ist, die Grenzen der geteilten Verantwortung bewerten und STAR-Nachweise lesen kann, ohne Audit von Grund auf neu zu erlernen. Das ist die Progression, der das CCAK dienen soll. --- ## Certified Cybersecurity Operations Analyst (CCOA) **URL:** https://cyberacademy.net/de/resources/encyclopedia/ccoa **Last reviewed:** 2026-06-24 CCOA ist das praxisorientierte Cybersecurity-Operations-Zertifikat von ISACA mit Fokus auf SOC-Arbeit: Monitoring, Detection, Response, Recovery. Es ist das technische Pendant zum CISM und richtet sich an Analysten und Incident Responder, nicht an Manager oder Auditoren. Der Certified Cybersecurity Operations Analyst (CCOA) ist die Zertifizierung von ISACA für die Personen, die im Security Operations Centre sitzen und die technische Arbeit leisten, nicht für jene, die darüber die Richtlinien verfassen. Sie ist auf den Arbeitsalltag im SOC ausgerichtet: Telemetrie beobachten, echte Signale vom Rauschen trennen, Alerts untersuchen, Vorfälle eindämmen und Systeme in einen bekannten, sauberen Zustand zurückführen. Während die meisten ISACA-Zertifizierungen Governance, Audit oder Managemententscheidungen validieren, validiert der CCOA, ob Sie die Werkzeuge tatsächlich bedienen und auf das reagieren können, was sie zutage fördern. ## Was der CCOA validiert Der CCOA ist um den operativen Lebenszyklus herum aufgebaut, den ein Verteidiger in einer gewöhnlichen Woche durchläuft. Die Fähigkeiten, die er zertifiziert, entsprechen der Arbeit, eine Umgebung zu überwachen, zu erkennen, wann etwas nicht stimmt, darauf zu reagieren und den Dienst wiederherzustellen. In der Praxis bedeutet das Kompetenz über einige miteinander verbundene Bereiche hinweg. - Überwachung und Erkennung: mit Logs, Netzwerk- und Endpunkt-Telemetrie sowie Erkennungswerkzeugen arbeiten, um anomale oder bösartige Aktivität aufzuspüren, statt darauf zu warten, dass sie gemeldet wird. - Triage und Untersuchung: entscheiden, welche Alerts echt sind, den Wirkungsradius eingrenzen und aus den verfügbaren Beweisen rekonstruieren, was geschehen ist. - Reaktion auf Vorfälle: Vorfälle eindämmen, beseitigen und sich davon erholen, dann das Gelernte festhalten, damit dieselbe Lücke nicht wieder aufgeht. - Zugrunde liegende technische Versiertheit: Netzwerke, Betriebssysteme, gängige Angriffstechniken und die Sicherheitskontrollen, die sich zwischen einen Angreifer und das Asset schieben. > **Eine praxisorientierte Zertifizierung, von Grund auf** Der CCOA ist als praxisnahe, leistungsorientierte Zertifizierung positioniert. Es geht darum nachzuweisen, dass Sie die Arbeit in einer realen Umgebung leisten können, nicht nur ihre Theorie beschreiben. Das verleiht ihm einen anderen Charakter als dem wissens- und urteilsbasierten Stil der Management- und Audit-Zertifizierungen von ISACA. ## Der CCOA neben dem CISM und dem übrigen ISACA-Stack Am klarsten lässt sich der CCOA einordnen, indem man überlegt, wer für welche Frage zuständig ist. Der CISM, die Flaggschiff-Managementzertifizierung von ISACA, ist für die Person gedacht, die für das Sicherheitsprogramm verantwortlich ist: Strategie, Governance, Risiko und der Rahmen für das Vorfallmanagement. Der CCOA ist für die Person gedacht, die innerhalb dieses Rahmens ausführt, wenn um 2 Uhr nachts ein Alert ausgelöst wird. Sie ergänzen einander, sie konkurrieren nicht. Ein Team kann sinnvollerweise einen CISM-Inhaber als Manager die Richtung vorgeben und CCOA-Inhaber als Analysten darunter die operative Verteidigung leisten lassen. Genau deshalb bezeichnet die shortDefinition den CCOA als das technische Pendant zum CISM. **Wo der CCOA unter den ISACA-Zertifizierungen steht** | Zertifizierung | Primäre Zielgruppe | Schwerpunkt | | --- | --- | --- | | CCOA | SOC-Analysten, Incident Responder | Praxisnahe Erkennung, Reaktion und Wiederherstellung | | CISM | Sicherheitsmanager und -führungskräfte | Programm-Governance, Strategie und Risiko | | CISA | IS-Auditoren | Unabhängige Prüfung und Test von Kontrollen | | CRISC | Fachleute für Risiko und Kontrollen | IT-Risikomanagement im Unternehmen | Da der CCOA auf die Ausführung ausgerichtet ist, passt er schlecht zu jemandem, der in Audit oder Governance wechseln möchte, und sehr gut zu jemandem, der seine operative Fähigkeit anerkannt sehen will. Analysten und Responder erhalten ein herstellerneutrales Signal, dass sie eine Umgebung verteidigen können; Manager und Auditoren sind in der Regel mit dem CISM, dem CISA oder dem CRISC besser bedient. Behandeln Sie die Wahl als Frage der Rolle, nicht der Dienstrang. ## Für wen er gedacht ist Der CCOA ergibt am meisten Sinn für Praktiker, die bereits in einer operativen Blue-Team-Rolle arbeiten oder darauf zusteuern: SOC-Analysten der Stufen eins und zwei, Junior Incident Responder und Detection Engineers, die eine anerkannte Zertifizierung wollen, die widerspiegelt, was sie tatsächlich tun. Er ist auch ein stimmiger nächster Schritt für Personen, die auf der technischen Seite begonnen haben und ein von ISACA gestütztes Abzeichen wollen, ohne ins Management zu wechseln. Wie bei jeder Zertifizierung gewichten Arbeitgeber letztlich die nachgewiesene Fähigkeit; der Wert des CCOA liegt also darin, dass er eine strukturierte, herstellerneutrale Möglichkeit bietet, die operativen Fähigkeiten zu belegen, die der Titel benennt. --- ## Certified Data Privacy Solutions Engineer (CDPSE) **URL:** https://cyberacademy.net/de/resources/encyclopedia/cdpse **Last reviewed:** 2026-06-24 CDPSE ist die technische Datenschutz-Zertifizierung von ISACA. Drei Domänen: Privacy Governance, Privacy-Architektur, Datenlebenszyklus. Die technische Ergänzung zu den policy-orientierten DPO/CDPO-Zertifizierungen. Besonders geeignet für Sicherheitsteams, die für die Datenschutz-Implementierung verantwortlich sind, sowie für Architekten, die unter GDPR oder AI Act arbeiten. ## Wozu CDPSE dient CDPSE ist die Antwort der ISACA auf eine Lücke, die entstand, sobald Datenschutz aufhörte, eine rein juristische Übung zu sein. Eine Datenschutzrichtlinie zu verfassen, Rechtsgrundlagen zu kartieren und Betroffenenanfragen zu beantworten, ist die Aufgabe eines Datenschutzbeauftragten. Doch nichts davon verhindert, dass eine undichte API personenbezogene Daten preisgibt, stellt sicher, dass Pseudonymisierung korrekt angewendet wird, oder verankert Einwilligungs- und Aufbewahrungslogik in einem System, bevor es ausgeliefert wird. CDPSE zertifiziert die Personen, die diese technische Arbeit leisten: die Ingenieure, Architekten und Sicherheitsfachleute, die Datenschutzpflichten in laufende Systeme und Kontrollen übersetzen. Das ist die definierende Haltung dieser Qualifikation. Sie ist das ingenieurseitige Pendant zu den politikorientierten Qualifikationen DPO und CDPO, nicht deren Konkurrent. Ein DPO entscheidet, was die Organisation tun muss, um die Vorgaben einzuhalten; ein CDPSE-Inhaber baut die Kontrollen, die Compliance real und überprüfbar machen. In reifen Programmen sitzen die beiden Rollen an gegenüberliegenden Seiten desselben Tisches, weshalb CDPSE als Brücke zwischen Datenschutz-Governance und der Technologie positioniert ist, die sie umsetzt. ## Die drei Domänen CDPSE ist um drei Domänen herum aufgebaut, und ihre Anteile verraten, worauf die ISACA den Schwerpunkt legt. Der Großteil der Prüfung entfällt auf die Domänen Architektur und Lebenszyklus, denn dort werden technische Entscheidungen tatsächlich getroffen. - Datenschutz-Governance. Das Bindegewebe zwischen rechtlichen Anforderungen und technischer Umsetzung: Struktur des Datenschutzprogramms, Governance und Steuerung des Datenschutzrisikos sowie die Richtlinien und Standards, auf denen die Entwicklung aufbauen muss. Hier liest ein CDPSE-Inhaber das, was der DPO und das Rechtsteam erstellt haben, und übersetzt es in Designvorgaben. - Datenschutz-Architektur. Infrastruktur, Anwendungen und Technologien aus der Datenschutzperspektive. Dies umfasst Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen als Ingenieurdisziplin: Gestaltung von Datenflüssen, technische Datenschutzkontrollen, Verschlüsselung und Pseudonymisierung, Identität und Zugriff sowie die Datenschutzauswirkungen architektonischer Entscheidungen. - Datenlebenszyklus. Personenbezogene Daten von der Erhebung über die Aufbewahrung bis zur Vernichtung. Zweckbindung, Datenminimierung, Qualität, Aufbewahrungsfristen und sichere Entsorgung, ausgedrückt als Kontrollen, die ein System durchsetzt, statt als Klauseln in einem Hinweis, den niemand liest. > **Umsetzung, nicht Auslegung** CDPSE setzt voraus, dass die rechtliche Auslegung bereits vorliegt. Ihr Wert liegt darin, diese Auslegung operativ zu machen: Einwilligung korrekt erfasst, Aufbewahrung automatisch durchgesetzt, Zugriff auf den Zweck beschränkt, Daten auf Anfrage löschbar. Wenn Ihre Aufgabe darin besteht, über die Bedeutung einer Vorschrift zu streiten, ist das DPO-Territorium; wenn Ihre Aufgabe darin besteht, das System dazu zu bringen, ihr zu folgen, ist das CDPSE-Territorium. ## Wo CDPSE neben benachbarten Qualifikationen und Standards steht CDPSE ist am nützlichsten, wenn man sie gegen das liest, was sie nicht ist. Die folgende Tabelle stellt sie neben die Qualifikationen und Standards, mit denen Praktiker sie am häufigsten verwechseln. **CDPSE im Vergleich zu benachbarten Datenschutzrollen und -standards** | Referenz | Hauptfokus | Haltung | | --- | --- | --- | | CDPSE | Technische Umsetzung von Datenschutz in Systemen | Ingenieurwesen und Architektur, laufende Kontrollen | | DPO / CDPO | Rechts- und Richtlinien-Compliance, Rechenschaftspflicht | Governance, Auslegung, Beratung | | ISO 27701 | Datenschutzmanagementsystem (PIMS) | Zertifizierbares Managementsystem als Erweiterung von ISO 27001 | | GDPR | Die rechtlichen Pflichten selbst | Regulierung, das, was die Kontrollen erfüllen müssen | Die Passung ist am stärksten für Sicherheitsteams, die die Datenschutzumsetzung geerbt haben, und für Architekten, die unter dem GDPR oder dem AI Act entwerfen, wo Datenminimierung und Zweckbindung in Modelle und Pipelines hineinkonstruiert werden müssen, statt in der Dokumentation versprochen zu werden. Ein CDPSE-Inhaber wird oft zu der Person, die in einer Design-Review sitzen und konkret sagen kann, wie ein Feature eine Datenschutzanforderung erfüllen wird. ISO 27701 begleitet die Qualifikation häufig: Der Standard definiert das Datenschutzmanagementsystem, und die für CDPSE ausgebildeten Ingenieure sind diejenigen, die die technischen Kontrollen bauen, von denen dieses System abhängt. CDPSE ist eine erfahrungsbasierte ISACA-Zertifizierung, was bedeutet, dass sie sich an Menschen richtet, die bereits im Datenschutz, in der Sicherheit oder in der IT arbeiten, und nicht an Einsteiger. Wie andere ISACA-Qualifikationen ist sie mit Anforderungen zur kontinuierlichen beruflichen Weiterbildung verbunden, um sie aktuell zu halten, was widerspiegelt, wie schnell sich sowohl die Technologie als auch die regulatorische Landschaft bewegen. --- ## Certified Information Security Manager (CISM) **URL:** https://cyberacademy.net/de/resources/encyclopedia/cism **Last reviewed:** 2026-06-24 CISM ist die ISACA-Zertifizierung für Informationssicherheitsmanager: Governance, Programmmanagement, Risikomanagement, Incident Management. Der Goldstandard für Führungsrollen im Sicherheitsbereich, der in etwa 60 % der CISO-Stellenausschreibungen gefordert wird. Andere Perspektive als CISSP: managementorientiert, weniger technisch. ## Was das CISM zertifiziert Das CISM ist die Zertifizierung von ISACA für Menschen, die Informationssicherheit managen, statt sie zu konfigurieren. Es bestätigt, dass Sie ein Sicherheitsprogramm aufbauen und steuern, es an den Geschäftszielen ausrichten und gegenüber der Geschäftsleitung und dem Vorstand dafür Rechenschaft ablegen können. Der Nachweis gliedert sich in vier fachliche Domänen: Governance der Informationssicherheit, Management von Informationssicherheitsrisiken, Entwicklung und Management des Informationssicherheitsprogramms sowie Management von Informationssicherheitsvorfällen. Diese vier Bereiche beschreiben die tatsächliche Aufgabe einer Sicherheitsführungskraft: die Richtung vorgeben, Risiko verstehen und behandeln, das Programm liefern, das die Arbeit leistet, und Vorfälle eindämmen, wenn Kontrollen versagen. Die shortDefinition liegt richtig damit, dass das CISM der Goldstandard für Führungsrollen in der Sicherheit ist. In der Praxis bedeutet das, dass Personalverantwortliche es als Indiz dafür nutzen, dass eine Person «eine Sicherheitsfunktion verantworten kann», nicht «einen Server härten kann». Von einer Person mit CISM wird erwartet, dass sie zwischen zwei Zielgruppen übersetzt: den technischen Teams, die Kontrollen betreiben, und der Geschäftsleitung, die Risiko finanziert und akzeptiert. Diese Übersetzungsschicht bildet den Kern der Rolle, und sie ist der Grund, warum sich die CISM-Kommunikation auf Governance, Berichtswege und Risikoakzeptanz stützt statt auf Werkzeuge. ## CISM gegenüber CISSP: die Management-Perspektive Die häufigste Frage von Fachleuten lautet, wie sich das CISM vom CISSP unterscheidet. Beide sind Nachweise für leitende Funktionen und beide berühren Governance, Risiko und Betrieb, doch ihr Schwerpunkt liegt anders. Das CISSP von (ISC)squared ist breiter und technischer: acht Domänen, die Architektur, Kryptografie, Netzwerksicherheit, Softwaresicherheit und Betrieb umfassen. Es ist die natürliche Zertifizierung für eine Sicherheitsfachkraft oder einen Sicherheitsarchitekten. Das CISM ist enger gefasst und managementorientiert: vier Domänen, allesamt aus der Perspektive einer Person betrachtet, die für ein Programm und ein Budget verantwortlich ist, nicht für die Umsetzung der Kontrollen. **Das CISM im Vergleich zu benachbarten Nachweisen** | Nachweis | Organisation | Hauptperspektive | | --- | --- | --- | | CISM | ISACA | Steuerung eines Sicherheitsprogramms: Governance, Risiko, Programm, Vorfälle | | CISSP | (ISC)squared | Breit aufgestellte technische Fachkraft: acht Domänen, von der Architektur bis zum Betrieb | | CISA | ISACA | Prüfung und Assurance von Informationssystemen | | CRISC | ISACA | Identifizierung, Bewertung und Behandlung von IT-Risiken im Unternehmen | Innerhalb der eigenen Familie von ISACA steht das CISM neben dem CISA und dem CRISC. Das CISA ist der Nachweis für Prüfer, ausgerichtet auf die Bewertung von Kontrollen und das Erbringen von Assurance. Das CRISC ist der Nachweis für Risikospezialisten, ausgerichtet auf die Identifizierung von IT-Risiken und die Reaktion darauf. Das CISM ist der Nachweis für Führungskräfte, ausgerichtet auf die Verantwortung für die Funktion, die Governance, Risiko und Betrieb miteinander verbindet. Viele Sicherheitsverantwortliche halten am Ende mehr als einen, weil sich die Rollen überschneiden, je weiter man aufsteigt. > **Eine Zertifizierung, kein Rahmenwerk** Das CISM schreibt keine Kontrollen vor, wie es ISO 27001 oder NIST tun. Es zertifiziert die Person, nicht die Organisation. Eine Person mit CISM betreibt typischerweise ein ISO-27001-ISMS oder ein NIST-basiertes Programm; die Zertifizierung besagt, dass sie diese Arbeit zu leiten weiß, nicht, welchen Standard sie wählen soll. ## Was es braucht, um das CISM zu halten Das CISM ist ein an Erfahrung gebundener Nachweis, nicht bloß eine Prüfung. ISACA verlangt von den Kandidaten, die Prüfung zu bestehen und einschlägige Berufserfahrung im Management der Informationssicherheit nachzuweisen, wobei ein Teil dieser Erfahrung innerhalb der vier Domänen liegen muss. Für einen Teil der Erfahrungsanforderung gibt es begrenzte Ausnahmen, und die Zertifizierung muss anschließend durch kontinuierliche berufliche Weiterbildung und die Einhaltung des berufsethischen Kodex von ISACA aufrechterhalten werden. Diese Pflicht zur Aufrechterhaltung ist der Grund, warum das CISM aktuell bleibt: Inhaberinnen und Inhaber sammeln in jedem Zyklus CPE-Stunden, statt einmal zu bestehen und sich darauf auszuruhen. Für Fachleute, die abwägen, ob sie es anstreben sollen, lautet die ehrliche Einordnung so. Wenn Ihr Weg darauf zusteuert, eine Sicherheitsfunktion zu leiten, einen Vorstand zu beraten oder einen CISO-Posten zu übernehmen, ist das CISM der Nachweis, den Personalverantwortliche am häufigsten nennen. Wenn Ihre Arbeit praktische Architektur und Engineering ist, dient Ihnen das CISSP oder eine technische Spezialisierung besser. Die beiden ergänzen einander, statt zu konkurrieren, und leitende Führungskräfte halten häufig beide. --- ## Certified Information Systems Auditor (CISA) **URL:** https://cyberacademy.net/de/resources/encyclopedia/cisa **Last reviewed:** 2026-06-24 CISA ist die führende IT-Audit-Zertifizierung, vergeben von ISACA seit 1978. Fünf Domänen decken den Auditprozess, Governance, Beschaffung, Betrieb und Asset-Schutz ab. Die Zertifizierung, auf die Big-Four-Mandate standardmäßig zurückgreifen. Weltweit anerkannt; in regulierten Branchen für viele Internal-Audit- und Compliance-Funktionen obligatorisch. ## Was CISA tatsächlich zertifiziert CISA ist der Nachweis dafür, dass Sie ein Informationssystem prüfen und die daraus gewonnene Beurteilung vertreten können. Die Zertifizierung wird von ISACA vergeben und ist seit Jahrzehnten die maßgebliche Qualifikation im IT-Audit, weshalb sie bei Mandaten der Big Four als Standarderwartung gilt und das Anforderungsmerkmal ist, das viele regulierte Arbeitgeber in Stellenbeschreibungen für interne Revision und Compliance aufnehmen. Bei der Zertifizierung geht es nicht um den Betrieb der IT oder deren Absicherung. Es geht um die unabhängige Beurteilung, ob Kontrollen vorhanden sind, ob sie wirksam sind, und ob die Nachweise diese Schlussfolgerung stützen. Die praxisrelevante Unterscheidung, die man im Blick behalten sollte, ist, dass CISA ein Prüfungs- und Assurance-Nachweis ist, kein Umsetzungsnachweis. Ein CISM-Inhaber führt ein Sicherheitsprogramm. Ein CISA-Inhaber bildet sich eine unabhängige Meinung darüber, ob dieses Programm und das umgebende, weiter gefasste IT-Umfeld kontrolliert sind. Genau diese Unabhängigkeit ist der entscheidende Punkt: Ein Prüfer, der die Kontrolle aufgebaut hat, kann sie nicht glaubwürdig bestätigen. CISA vermittelt die auf Nachweisen und Stichproben beruhende Denkweise, die die Beurteilung belastbar hält. ## Die fünf CISA-Domänen Die Prüfung und der Wissensbestand sind in fünf Domänen gegliedert. Sie reichen davon, wie Sie prüfen, über die Governance der IT, bis hin zu den drei Lebenszyklusbereichen, die ein Prüfer beurteilen können muss: - Prüfungsprozess von Informationssystemen. Planung, risikobasierte Abgrenzung, Nachweiserhebung, Stichprobenziehung und Berichterstattung. Die Disziplin, die jede andere Domäne prüfbar macht. - Governance und Management der IT. Strategie, Richtlinien, Organisationsstruktur, und wie das Unternehmen seine IT steuert und überwacht. - Beschaffung, Entwicklung und Implementierung von Informationssystemen. Ob Projekte, Änderungen und neue Systeme vom Business Case bis zum Go-live kontrolliert sind. - Betrieb von Informationssystemen und Geschäftsresilienz. Tagesbetrieb, Service-Management, Datensicherung, Kontinuität und Notfallwiederherstellung. - Schutz von Informationswerten. Logische und physische Sicherheit, Identität und Zugriff, Verschlüsselung, und Kontrollen zum Datenschutz. > **CISA prüft Urteilsvermögen, nicht Auswendiglernen** Die Prüfung ist szenariobasiert. Die Fragen verlangen, welche Handlung ein Prüfer in einer gegebenen Situation zuerst vornehmen sollte oder welche Feststellung am bedeutsamsten ist. Bewertet werden Ihr Prüfungsurteil und Ihre Risikopriorisierung, nicht das Aufsagen von Kontrolllisten, weshalb praktische Prüfungserfahrung ebenso zählt wie das Lernen. ## Wo CISA neben verwandten Nachweisen steht CISA steht im ISACA-Katalog nicht allein, und Fachleute kombinieren sie routinemäßig mit anderen. Die häufigsten Schritte sind seitlich in den Risikobereich mit CRISC oder aufwärts in die Sicherheitsführung mit CISM. Gegenüber der ISO-Welt bescheinigen CISA und der PECB Lead Auditor beide eine Prüfungskompetenz, jedoch in unterschiedlichen Bahnen: CISA ist eine breit angelegte IT-Audit-Qualifikation, die an die ISACA-Domänen gebunden ist, während Lead Auditor auf ISO 19011 aufbaut und auf die Prüfung eines bestimmten Managementsystems abzielt, etwa eines ISMS nach ISO 27001, oft als Weg, akkreditierter Prüfer einer Zertifizierungsstelle zu werden. **CISA im Vergleich zu verwandten Nachweisen** | Nachweis | Stelle | Primärer Fokus | | --- | --- | --- | | CISA | ISACA | Breite IT-Audit-Assurance über fünf Domänen | | CISM | ISACA | Management und Governance eines Informationssicherheitsprogramms | | CRISC | ISACA | Identifikation, Bewertung und Behandlung von IT-Risiken | | Lead Auditor | PECB | Prüfung eines bestimmten Managementsystems auf Basis von ISO 19011 | Den Nachweis zu erlangen, ist mehr als das Bestehen der Prüfung. ISACA verlangt nachgewiesene berufliche IT-Audit-Erfahrung, die Einhaltung eines berufsethischen Kodex, und eine laufende berufliche Weiterbildung, um die Zertifizierung aktiv zu halten. Diese Erfahrungsanforderung ist der Grund, warum CISA Gewicht hat: Sie bestätigt, dass der Inhaber die Arbeit tatsächlich geleistet und nicht nur studiert hat. --- ## Certified in Risk and Information Systems Control (CRISC) **URL:** https://cyberacademy.net/de/resources/encyclopedia/crisc **Last reviewed:** 2026-06-24 CRISC ist die ISACA-Zertifizierung im Risikobereich für IT-Risk-Praktiker. Identifikation, Bewertung, Reaktion und Überwachung im Kontext von Informationssystemen. Sie verbindet Business- und IT-Risikomanagement. Die natürliche Ergänzung zu CISA für Auditoren, die in den Risikobereich wechseln, sowie zu ISO 27005 / 31000 für ISO-zertifizierte Praktiker, die das ISACA-Vokabular ergänzen möchten. ## Was CRISC zertifiziert CRISC ist der Nachweis von ISACA für Praktiker, die IT- und Informationssystemrisiken verantworten, anstatt sie im Nachhinein zu auditieren. Er bestätigt, dass der Inhaber den vollständigen Risikolebenszyklus für Technologie-Assets steuern kann: Exposition identifizieren, Eintrittswahrscheinlichkeit und Auswirkung bewerten, eine Reaktion entwerfen und empfehlen sowie die Restrisikoposition über die Zeit überwachen. Das unterscheidende Merkmal von CRISC ist die Übersetzungsebene. Vom Inhaber wird erwartet, dass er eine Datenbankschwachstelle oder eine Cloud-Fehlkonfiguration in den Begriffen ausdrückt, die das Risikoregister des Unternehmens und der Vorstand tatsächlich verwenden, sodass IT-Risiko zu einer Eingangsgröße des Unternehmensrisikos wird und nicht zu einem parallelen Gespräch in einer eigenen Sprache. Wo viele technische Zertifizierungen bei den Kontrollen aufhören, stellt CRISC Kontrollen als Folge einer Risikoentscheidung dar. Vom Inhaber wird erwartet, dass er beim Risikoszenario, bei der von der Organisation festgelegten Risikobereitschaft und Risikotoleranz sowie bei den Behandlungskosten ansetzt und dann begründet, warum eine bestimmte Kontrolle existiert und was sie unbehandelt lässt. Dieser Faden aus Risiko, Reaktion und Kontrolle ist das Rückgrat des Nachweises und der Grund, warum er neben der Governance-Arbeit steht und nicht bei rein operativer Sicherheit. ## Wo CRISC unter den benachbarten Nachweisen steht CRISC wird am häufigsten als der natürliche nächste Schritt für einen CISA-Inhaber verstanden. CISA belegt, dass Sie Informationssysteme auditieren und beurteilen können, ob Kontrollen wirksam gestaltet sind und funktionieren; CRISC belegt, dass Sie das Risiko verantworten können, auf das diese Kontrollen antworten, und entscheiden, was zu tun ist. Auditoren, die vom Erstellen von Feststellungen zum Festlegen der Risikostrategie übergehen, nutzen CRISC, um diesen Wechsel für Arbeitgeber sichtbar zu machen. Beide teilen das Vokabular und den Governance-Rahmen von ISACA, weshalb sie regelmäßig kombiniert werden. Für ISO-geschulte Praktiker ergänzt CRISC den ISACA-Dialekt um eine Methodik, die sie bereits anwenden. Wer ISO 27005 oder ISO 31000 beherrscht, führt bereits Identifikation, Analyse, Bewertung, Behandlung und Akzeptanz durch. CRISC ersetzt diesen Prozess nicht; er gibt derselben Person die ISACA-Begriffe, die Rahmung des Unternehmens-IT-Risikos und einen Nachweis, der von Arbeitgebern anerkannt wird, die sich auf ISACA statt auf ISO standardisieren. Die Methodiken sind kompatibel, und beide zu besitzen signalisiert, dass Sie sich zwischen den beiden Referenzwelten bewegen können. > **CISA beschreibt, CRISC entscheidet** Eine CISA-geprägte Lesart einer Feststellung fragt, ob die Kontrolle funktioniert. Eine CRISC-geprägte Lesart fragt, ob das Restrisiko angesichts der Risikobereitschaft akzeptabel ist, welche Reaktion erfolgen sollte und wer dafür verantwortlich ist. Dieselben Nachweise, eine andere Frage. **Wie sich CRISC mit benachbarten Nachweisen vergleicht** | Nachweis | Leitfrage | Typischer Inhaber | | --- | --- | --- | | CRISC | Welches IT-Risiko besteht und was tun wir dagegen? | IT-Risikomanager, Risikoverantwortlicher | | CISA | Sind die Kontrollen wirksam gestaltet und funktionieren sie? | IT-Auditor, interne Revision | | ISO 27005 | Wie führen wir den Prozess für Informationssicherheitsrisiken durch? | ISMS-Praktiker, Risikoanalyst | ## Was CRISC-Inhaber tatsächlich tun In der Praxis arbeitet ein CRISC-Inhaber nah an dem Punkt, an dem Technologierisiko und geschäftliche Entscheidungsfindung zusammentreffen. Zu den wiederkehrenden Aufgaben gehören die folgenden. - Aufbau und Pflege von IT-Risikoszenarien und eines Risikoregisters, das die umfassendere Unternehmensrisikofunktion nutzen kann. - Bewertung von Eintrittswahrscheinlichkeit und Auswirkung und anschließender Abgleich des Ergebnisses mit der erklärten Risikobereitschaft und Risikotoleranz der Organisation. - Empfehlung einer Reaktion (akzeptieren, mindern, übertragen oder vermeiden) und Begründung der Wahl anhand von Kosten und Restrisiko, nicht allein anhand technischer Präferenz. - Gestaltung oder Spezifikation der Informationssystemkontrollen, die eine gewählte Reaktion umsetzen, und Festlegung der Indikatoren, die zeigen, ob sie tragen. - Überwachung der wesentlichen Risikoindikatoren und Berichterstattung über die Restrisikoposition an Governance-Gremien in geschäftlichen Begriffen. Der rote Faden, der sich durch all dies zieht, sind Verantwortung und Kommunikation. Bei CRISC geht es weniger darum, eine neue Schwachstelle zu entdecken, als vielmehr darum, zu entscheiden, was die Organisation tun sollte, sicherzustellen, dass jemand diese Entscheidung verantwortet, und über die Zeit zu belegen, dass das Restrisiko innerhalb der vereinbarten Grenze geblieben ist. --- ## Certified in the Governance of Enterprise IT (CGEIT) **URL:** https://cyberacademy.net/de/resources/encyclopedia/cgeit **Last reviewed:** 2026-06-24 CGEIT ist die ISACA-Zertifizierung für erfahrene Fachkräfte, die in der Governance von Enterprise-IT beraten: strategische Ausrichtung, Wertschöpfung, Risiko- und Ressourcenoptimierung. Grundlage ist COBIT. Der Markt ist kleiner als bei CISA / CISM, aber CGEIT ist die richtige Zertifizierung für CIOs, IT-Berater auf Vorstandsebene und Senior Consultants. ## Was CGEIT zertifiziert CGEIT ist die Zertifizierung von ISACA für erfahrene Fachleute, die zur Governance der Unternehmens-IT beraten oder dafür verantwortlich sind. Die Betonung ist entscheidend: Es geht um Governance, nicht um Sicherheitsbetrieb und nicht um Projektabwicklung. Von einem CGEIT-Inhaber wird erwartet, über die strategische Ausrichtung zwischen IT und Geschäftszielen, die Wertschöpfung aus IT-Investitionen, die Risikooptimierung und den verantwortungsvollen Einsatz von Ressourcen zu urteilen. Das sind Anliegen auf Vorstandsebene, weshalb sich die Zertifizierung an CIOs, IT-Governance-Verantwortliche, Berater auf Vorstandsebene und Senior-Berater richtet und nicht an operativ tätige Ingenieure oder Analysten. Die Unterscheidung, über die Fachleute stolpern, ist die Grenze zwischen Governance und Management. Governance ist die Verantwortung des Vorstands und der Führungskräfte, Optionen zu bewerten, die Richtung vorzugeben und zu überwachen, ob die Ergebnisse erreicht werden. Das Management plant, baut auf, betreibt und überwacht die Aktivitäten, die diese Richtung umsetzen. CGEIT bestätigt, dass Sie auf der Governance-Seite agieren können, indem Sie das System gestalten und absichern, mit dem die IT gesteuert wird, statt die IT selbst zu betreiben. ## Wo CGEIT unter den ISACA-Zertifizierungen steht CGEIT ist nach Anzahl der Inhaber die kleinste der führenden ISACA-Zertifizierungen, was eher ein Vorzug als ein Mangel ist. CISA bestätigt die Fähigkeit, Informationssysteme zu auditieren. CISM bestätigt die Fähigkeit, ein Informationssicherheitsprogramm zu leiten. CGEIT bestätigt die Fähigkeit, die IT auf Unternehmensebene zu steuern. Sie beantworten unterschiedliche Fragen und passen zu unterschiedlichen Karrierephasen: Ein Auditor oder Sicherheitsmanager baut mit CISA oder CISM Tiefe auf, während eine Führungskraft auf dem Weg zur Verantwortung auf Vorstandsebene CGEIT ergänzt. Sie wird in der Regel später in der Laufbahn angestrebt, weil die Zulassung Jahre echter Governance-Erfahrung höher gewichtet als Unterrichtsstunden. **CGEIT im Vergleich zu benachbarten ISACA-Zertifizierungen** | Zertifizierung | Bestätigt | Typischer Inhaber | | --- | --- | --- | | CGEIT | Governance der Unternehmens-IT auf Vorstandsebene | CIO, IT-Governance-Verantwortlicher, Vorstandsberater | | CISA | Audit von Informationssystemen | IS-Auditor, Assurance-Fachkraft | | CISM | Leitung eines Informationssicherheitsprogramms | Sicherheitsmanager, CISO | | CRISC | Management von IT- und Unternehmensrisiken | Risikomanager, Control Owner | > **CGEIT ist eine Führungs-, keine technische Zertifizierung** Die Prüfung und die Erfahrungsanforderung prüfen, ob Sie ein Governance-System gestalten und absichern, die IT an der Strategie ausrichten und Wert, Risiko und Ressourcen optimieren können. Sie setzt voraus, dass Sie bereits über die technische Grundlage verfügen und nun für die Richtung statt für die Umsetzung verantwortlich sind. ## Wie COBIT die Grundlage bildet CGEIT wurzelt in COBIT, dem Rahmenwerk von ISACA für die Governance und das Management der Unternehmens-IT. COBIT liefert die Struktur, innerhalb derer ein CGEIT-Inhaber arbeitet: die Trennung von Governance- und Management-Zielen, die Komponenten, die ein Governance-System funktionsfähig machen, etwa Prozesse, Organisationsstrukturen, Richtlinien, Kompetenzen und Kultur, sowie die Gestaltungsfaktoren, die dieses System auf den Kontext einer Organisation zuschneiden. In der Praxis nutzt eine CGEIT-zertifizierte Fachkraft COBIT als Referenzmodell, um zu beurteilen, wo die Governance steht, zu entwerfen, wo sie stehen sollte, und die bereits genutzten Standards wie ISO 27001 oder ITIL zu einem kohärenten Ganzen im Dienste der Unternehmensziele zu rationalisieren. Auch deshalb werden beide üblicherweise zusammen erlernt. Das Studium von COBIT vermittelt Ihnen das Rahmenwerk; der Erwerb des CGEIT zeigt, dass Sie Governance-Denken über Strategie, Wert, Risiko und Ressourcen hinweg auf der Ebene anwenden können, auf der der Vorstand die IT zur Rechenschaft zieht. Wie bei anderen ISACA-Zertifizierungen wird CGEIT durch kontinuierliche berufliche Weiterbildung und die Einhaltung des Berufsethikkodex von ISACA aufrechterhalten. --- ## Chief Information Security Officer (CISO) **URL:** https://cyberacademy.net/de/resources/encyclopedia/ciso **Last reviewed:** 2026-06-24 Der CISO ist die Führungskraft, die für die Informationssicherheitsstrategie verantwortlich ist. Sie verantwortet das Risikoregister, leitet die Incident Response, berichtet dem Vorstand und zeichnet für das Restrisiko. Unter NIS 2 und DORA ist diese Verantwortung nun explizit und persönlich. Die Aufgabe ist Governance, nicht Umsetzung; das Schwierigste ist die Übersetzung in die Sprache des Vorstands. ## Wofür ein CISO tatsächlich verantwortlich ist Der CISO ist die Führungskraft, die für die Informationssicherheitsstrategie rechenschaftspflichtig ist, und die Betonung liegt auf rechenschaftspflichtig. Wie es die shortDefinition ausdrückt, ist die Aufgabe Governance, nicht Umsetzung. Ein CISO konfiguriert keine Firewalls und schreibt keine Erkennungsregeln; er entscheidet, wo die Organisation ihr begrenztes Sicherheitsbudget ausgibt, welche Risiken sie behandelt und welche sie akzeptiert, und wie sie reagiert, wenn etwas schiefgeht. Die täglichen Arbeitsergebnisse der Rolle sind ein Risikoregister, eine Programm-Roadmap, ein Notfallreaktionsplan und eine Reihe von Berichten auf Vorstandsebene, kein Terminal. Diese Unterscheidung ist wichtig, weil Sicherheitsführung häufig fälschlich als eine leitende Ingenieursrolle verstanden wird. Das ist sie nicht. Der CISO sitzt an der Grenze zwischen den technischen Teams, die die Kontrollen betreiben, und den Führungskräften, die sie finanzieren und die Folgen tragen. Der schwierigste Teil der Aufgabe ist, wie die shortDefinition anmerkt, die Übersetzung in den Vorstand: eine ausufernde technische Realität in eine kleine Zahl von Entscheidungen zu überführen, die ein Vorstand tatsächlich treffen kann. Ein CISO, der das Restrisiko nicht in geschäftlichen Begriffen erklären kann, kann die Aufgabe nicht erfüllen, so fundiert sein technischer Hintergrund auch sein mag. ## Rechenschaftspflicht unter NIS 2 und DORA Jahrelang trug die CISO-Rolle Verantwortung ohne viel formale Rechenschaftspflicht. Das hat sich geändert. Die shortDefinition ist eindeutig: Unter NIS 2 und DORA ist die Rechenschaftspflicht nun persönlich. NIS 2, die europäische Richtlinie über die Sicherheit von Netz- und Informationssystemen, hebt die Aufsicht über die Cybersicherheit auf die Leitungsorgane der betroffenen Einrichtungen und macht dieses Organ verantwortlich für die Genehmigung und Überwachung der Maßnahmen zum Sicherheitsrisikomanagement. DORA, der Digital Operational Resilience Act, tut das Entsprechende für den EU-Finanzsektor und verankert die Rechenschaftspflicht für die operationale Resilienz fest beim Leitungsorgan. Die praktische Folge ist, dass «die Sicherheitsfunktion gibt ihr Bestes» keine vertretbare Haltung mehr ist; eine namentlich benannte Führung muss die Risikoentscheidungen schriftlich verantworten. > **Rechenschaftspflicht kann nicht delegiert werden** Unter NIS 2 und DORA kann das Leitungsorgan den CISO und das Sicherheitsteam mit der Arbeit beauftragen, behält aber die Verantwortung für das Ergebnis. Ein CISO, der ein Restrisiko abzeichnet, dokumentiert eine Entscheidung, die die Organisation formell akzeptiert hat, er verlagert die Haftung nicht vom Vorstand weg. Deshalb verbringt ein moderner CISO so viel Zeit mit Dokumentation und Berichtsrhythmus. Das Abzeichnen des Restrisikos, das Briefen des Vorstands über die Bedrohungslage und der Nachweis, dass die Risikomanagementmaßnahmen auf der richtigen Ebene genehmigt wurden, sind keine Extras guter Praxis mehr. So weist die Organisation nach, dass sie ihre rechtlichen Pflichten erfüllt hat. Die Rolle hat sich von «das Sicherheitsteam leiten» hin zu «die Governance vertretbar machen» verschoben. ## Wie sich der CISO von benachbarten Rollen unterscheidet Der CISO wird oft mit den Personen und Funktionen um ihn herum verwechselt. Ein Security Manager oder ein CISM-zertifizierter Programmverantwortlicher führt das Sicherheitsprogramm und berichtet möglicherweise an den CISO; der CISO legt die Strategie fest und trägt die exekutive Rechenschaftspflicht dafür. Ein SOC-Leiter ist für den Betrieb von Erkennung und Reaktion verantwortlich; der CISO ist verantwortlich für die Entscheidung, wie viel Erkennungskapazität die Organisation finanziert und was sie tut, wenn das SOC einen schweren Vorfall eskaliert. Und wo die Organisation ein ISO 27001 ISMS betreibt, ist der CISO typischerweise der exekutive Sponsor dieses Managementsystems und nicht dessen täglicher Betreiber. **Der CISO im Vergleich zu angrenzenden Rollen** | Rolle | Hauptperspektive | Berichtet an | | --- | --- | --- | | CISO | Sicherheitsstrategie, Risikoakzeptanz, Rechenschaftspflicht gegenüber dem Vorstand | CEO oder Vorstand | | Security Manager | Führung des Sicherheitsprogramms und -teams | Oft den CISO | | SOC-Leiter | Erkennung, Überwachung, Betrieb der Notfallreaktion | CISO oder Security Manager | | DPO | Datenschutz-Compliance und Rechte der betroffenen Personen | Unabhängig, mit Zugang zum Vorstand | Ein Paar, das sich sauber zu trennen lohnt, ist der CISO und der Datenschutzbeauftragte. Sie überschneiden sich bei Vorfällen mit personenbezogenen Daten, aber es sind verschiedene Aufgaben. Der DPO ist eine Compliance- und Aufsichtsrolle mit gesetzlich geschützter Unabhängigkeit; der CISO ist eine Führungskraft, die die Sicherheitsstrategie verantwortet und an ihr gemessen wird. In vielen Organisationen arbeiten sie ständig zusammen und berichten über verschiedene Linien, gerade weil der DPO in der Lage sein soll, das Geschäft infrage zu stellen, einschließlich der Sicherheitsfunktion. Für Praktiker auf dem Weg in diese Position lautet die ehrliche Einordnung, dass die CISO-Rolle Urteilsvermögen und Kommunikation stärker belohnt als Werkzeuge. Das technische Fundament wird vorausgesetzt; was Menschen den Job verschafft und sie wirksam hält, ist die Fähigkeit, Risiko zu verantworten, einen Vorstand zu briefen und die Rechenschaftspflicht unter Rahmenwerken wie NIS 2 und DORA vertretbar zu machen. --- ## Commission nationale de l'informatique et des libertés (CNIL) **URL:** https://cyberacademy.net/de/resources/encyclopedia/cnil **Last reviewed:** 2026-06-24 Die CNIL ist die französische Datenschutzbehörde, gegründet 1978. Sie setzt den GDPR in Frankreich durch, erlässt verbindliche Entscheidungen und Bußgelder, veröffentlicht Leitlinien (Cookies, Biometrie, KI) und betreibt das PIA-Tool. Sie gehört zu den aktivsten Aufsichtsbehörden in der EU; ihre Entscheidungen setzen häufig EU-weite Maßstäbe. Die CNIL ist die Aufsichtsbehörde, die das europäische Datenschutzrecht in Frankreich in konkrete Konsequenzen übersetzt. Sie ist Jahrzehnte älter als die DSGVO, weshalb ihr Aufgabenbereich über die reine Durchsetzung hinausgeht: Sie berät die Regierung bei Gesetzentwürfen, akkreditiert und prüft, betreibt öffentlich zugängliche Beratung und fungiert als zentrale Anlaufstelle sowohl für betroffene Personen, die sich beschweren, als auch für Verantwortliche, die Verletzungen melden. Für eine französische Organisation ist die CNIL das praktische Gesicht der Compliance. Sie ist die Stelle, die Ihre Fragen beantwortet, die Stelle, die Sie prüft, und die Stelle, die entscheidet, ob ein Problem mit einer Verwarnung oder einem Bußgeld endet. ## Was die CNIL tatsächlich tut Betrachten Sie die CNIL als vier sich überschneidende Funktionen und nicht als eine einzige Regulierungsbehörde. Erstens erstellt sie Leitlinien, die in Frankreich zur operativen Grundlinie werden: Ihre Cookie-Regeln, ihre Rahmenwerke zu Biometrie und Personalbeschaffung sowie ihre Positionspapiere zur künstlichen Intelligenz werden als das gelesen, was gute Praxis ausmacht, selbst dort, wo der zugrunde liegende DSGVO-Text allgemein gehalten ist. Zweitens führt sie den Aufsichtsdialog, bearbeitet Beschwerden, kontrolliert Organisationen durch Aktenprüfung und Vor-Ort-Inspektion und erlässt förmliche Aufforderungen zur Herstellung der Konformität. Drittens sanktioniert sie, mit der Befugnis, verbindliche Abhilfemaßnahmen und Geldbußen zu verhängen. Viertens stattet sie die Fachleute mit Werkzeugen aus, am sichtbarsten mit der PIA-Software, die zur Strukturierung einer Datenschutz-Folgenabschätzung verwendet wird. Die meisten Verantwortlichen bekommen nie die Schlagzeilen-Bußgeld-Version der CNIL zu sehen. Sie sehen die Dialog-Version: eine Anforderung von Unterlagen, eine Frage zur Rechtsgrundlage, eine förmliche Aufforderung mit einer Frist, etwas zu beheben. Ihr Verzeichnis von Verarbeitungstätigkeiten, Ihre Folgenabschätzungen und Ihre DPO-Regelungen in Ordnung zu bringen, ist das, was eine Interaktion in diesem niedrigeren Register hält. > **Leitlinien sind der Boden, nicht die Decke** Wenn die CNIL ein Rahmenwerk veröffentlicht, wird von französischen Organisationen erwartet, dass sie es befolgen oder einen vertretbaren Grund für eine Abweichung dokumentieren. Ihre aktuellen Leitlinien zu Cookies, Biometrie und KI zu lesen, ist günstiger, als die Erwartungen der CNIL während einer Inspektion zu entdecken. ## CNIL, DSGVO und der Single Point of Contact der EU Die CNIL schreibt nicht das Gesetz, das sie durchsetzt. Die DSGVO ist die Verordnung; die CNIL ist eine der nationalen Aufsichtsbehörden, die sie anwenden. Diese Unterscheidung ist für die grenzüberschreitende Verarbeitung von Bedeutung. Im Rahmen des One-Stop-Shop-Mechanismus befasst sich eine Organisation mit Hauptniederlassung in Frankreich vorrangig mit der CNIL als federführender Behörde, und die CNIL stimmt sich mit anderen europäischen Behörden über die Verfahren der Zusammenarbeit und Kohärenz ab, statt isoliert zu handeln. Bei rein inländischer Verarbeitung handelt die CNIL eigenständig. Die CNIL gehört zudem zu den aktiveren Behörden in der EU, sodass ihre Begründungen und ihre Sanktionsentscheidungen weit über Frankreich hinaus als Hinweis darauf studiert werden, wohin sich die europäische Durchsetzung entwickelt. Auch hier fügen sich die umgebenden Rollen ineinander. Die DSGVO schafft Pflichten; der DPO ist die Rolle innerhalb der Organisation, die die Einhaltung überwacht und als Kontaktstelle zur Behörde dient; die CNIL ist die Behörde am anderen Ende dieses Kontakts. Ein Praktiker, der erklären kann, wie diese drei zusammenhängen, ist selten derjenige, der bei einer Inspektion ertappt wird. ## Was Praktiker mit der CNIL tun In der Praxis besteht gute Zusammenarbeit mit der CNIL überwiegend aus Vorbereitung statt aus Reaktion. Die konkreten Gewohnheiten sind in reifen französischen Organisationen durchgängig dieselben. - Bringen Sie die aktuellen Leitlinien der CNIL in Übereinstimmung mit Ihrer eigenen Verarbeitung, insbesondere Cookies, Biometrie, Personalbeschaffung und allen KI-gestützten Entscheidungen, und halten Sie diese Zuordnung aktuell. - Halten Sie die Rechenschaftsnachweise bereit, die die CNIL zuerst sehen möchte: das Verzeichnis von Verarbeitungstätigkeiten, abgeschlossene Folgenabschätzungen und die dokumentierte Grundlage für jeden Verarbeitungszweck. - Nutzen Sie das PIA-Werkzeug der CNIL, um Folgenabschätzungen so zu strukturieren, dass das Ergebnis die Sprache der Behörde selbst spricht. - Kennen Sie Ihren Meldeweg für Verletzungen im Voraus, damit ein meldepflichtiger Vorfall zu einem Prozess statt zu einem hektischen Durcheinander wird. - Behandeln Sie eine förmliche Aufforderung als ein fristgetriebenes Projekt, nicht als eine Verhandlung, und dokumentieren Sie jeden Schritt, den Sie zur Herstellung der Konformität unternehmen. Nichts davon ist exotisch. Es ist dieselbe Rechenschaftsdisziplin, die die DSGVO verlangt, so organisiert, dass die eine Stelle, die sie am ehesten verlangt, schnell und glaubwürdig eine Antwort erhält. --- ## Cyber Resilience Act (CRA) **URL:** https://cyberacademy.net/de/resources/encyclopedia/cra **Last reviewed:** 2026-06-24 Der Cyber Resilience Act ist die EU-Verordnung, die grundlegende Sicherheitsanforderungen an Hardware- und Softwareprodukte mit digitalen Elementen stellt, die in Europa vertrieben werden. Herstellerpflichten über den gesamten Lebenszyklus: Security-by-Design, Schwachstellenbehandlung, SBOM, fünf Jahre Patches. Ende 2024 verabschiedet, gilt ab Dezember 2027. Kombinieren Sie ihn mit NIS 2 (organisatorische Perspektive) und dem AI Act (Modellperspektive). ## Was der Cyber Resilience Act tatsächlich regelt Der Cyber Resilience Act legt Sicherheitspflichten auf das Produkt, nicht nur auf die Organisation, die es betreibt. Alles, was in der EU verkauft wird und digitale Elemente enthält, also Hardware oder Software mit einer Datenverbindung, fällt in den Anwendungsbereich: vernetzte Verbrauchergeräte, Industriesteuerungen, Betriebssysteme, Bibliotheken, mobile Apps und sogar die in einem Bauteil ausgelieferte Firmware. Die regulierte Partei ist der Wirtschaftsakteur, der das Produkt auf dem Markt bereitstellt, sodass die Hersteller die Hauptlast tragen, während Einführer und Händler an Überprüfungspflichten gebunden sind. Das ist eine Verschiebung der Haftung. Jahrelang erbte der Käufer das Risiko unsicherer Software; der CRA verlagert eine definierte Grundverantwortung zurück auf denjenigen, der das Produkt baut und verkauft. Da er Produkte statt Organisationen reguliert, erreicht der CRA kleine Anbieter und offene Komponenten, die kein organisationsbezogenes Sicherheitsgesetz je berühren würde. Ein Firmware-Hersteller ohne Niederlassung in der EU muss dennoch die Anforderungen erfüllen, wenn das Gerät in ein europäisches Regal gelangt. Diese produktbezogene Rahmung ist das mit Abstand Wichtigste, das man verstehen muss, bevor man irgendetwas anderes dazu liest. ## Die Pflichten, die einen Hersteller binden Der CRA ist um einen Lebenszyklus herum aufgebaut. Ein Produkt muss bei der Auslieferung sicher sein und für die Dauer, in der vernünftigerweise mit seiner Nutzung zu rechnen ist, wartbar bleiben, was die Verordnung auf einen Basis-Supportzeitraum von etwa fünf Jahren für die Behandlung von Schwachstellen festlegt. Die konkreten Pflichten gruppieren sich in zwei Bereiche. - Security by Design und by Default: ohne bekannte ausnutzbare Schwachstellen ausliefern, die Angriffsfläche minimieren, Vertraulichkeit und Integrität der Daten schützen und eine sichere Standardkonfiguration bereitstellen, damit das Produkt nicht direkt aus der Verpackung heraus unsicher ist. - Behandlung von Schwachstellen über den gesamten Supportzeitraum: einen Prozess der koordinierten Offenlegung unterhalten, eine Software Bill of Materials bereitstellen, damit die im Produkt enthaltenen Komponenten dokumentiert sind, Sicherheitsupdates zügig und, sofern machbar, automatisch ausliefern sowie aktiv ausgenutzte Schwachstellen und schwere Vorfälle innerhalb der in der Verordnung festgelegten Fristen an die ENISA melden. Die Konformität wird auf die Weise nachgewiesen, in der die EU andere Produktsicherheitsvorschriften handhabt: eine Bewertung, die der Risikoklasse des Produkts angemessen ist, eine technische Dokumentation und eine CE-Kennzeichnung, die signalisiert, dass die Sicherheitsgrundlage erreicht wurde. Produktkategorien mit höherem Risiko, sogenannte wichtige oder kritische, unterliegen einer strengeren, mitunter durch Dritte durchgeführten Bewertung statt einer Selbsterklärung. > **Die SBOM ist jetzt ein Liefergegenstand, keine nette Zugabe** Der CRA verwandelt die Software Bill of Materials von einem Wunsch der Sicherheitsteams in eine regulatorische Anforderung. Hersteller müssen wissen und dokumentieren, was in ihren Produkten steckt, denn sie sind für Schwachstellen in diesen Komponenten über den gesamten Supportzeitraum verantwortlich, einschließlich der Abhängigkeiten von Dritten und Open Source. ## Wie er sich zu NIS 2 und dem AI Act verhält Diese drei EU-Instrumente sind bewusst komplementär, und Praktiker sollten ihre Anwendungsbereiche nicht verwechseln. Der CRA ist der Produktwinkel: Er macht das, was man verkauft, sicher. NIS 2 ist der organisatorische Winkel: Er verpflichtet wesentliche und wichtige Einrichtungen, Cyberrisiken zu steuern, Sicherheit zu steuern und Vorfälle auf Unternehmensebene zu melden. Der AI Act ist der Modellwinkel: Er regelt, wie KI-Systeme, insbesondere Hochrisikosysteme, gebaut und auf dem Markt bereitgestellt werden. Ein vernetztes Industriegerät, das von einem regulierten Akteur verkauft wird und eine KI-Komponente einbettet, kann alle drei zugleich berühren, jedes aus einer anderen Richtung. **Vergleich der EU-Instrumente für digitale Sicherheit** | Instrument | Was es regelt | Wen es bindet | | --- | --- | --- | | Cyber Resilience Act | Sicherheit von Produkten mit digitalen Elementen | Hersteller, Einführer, Händler | | NIS 2 | Steuerung und Meldung von Cyberrisiken auf organisatorischer Ebene | Wesentliche und wichtige Einrichtungen | | AI Act | Entwicklung und Bereitstellung von KI-Systemen auf dem Markt | Anbieter und Betreiber von KI | Die praktische Folge ist, dass die CRA-Bereitschaft weitgehend ein Programm der Technik und der Produkt-Governance ist und keine Papierübung, die an ein bestehendes ISMS angeschraubt wird. Teams, die bereits koordinierte Schwachstellenoffenlegung betreiben, Abhängigkeitsinventare pflegen und in einem vorhersehbaren Takt patchen, haben den größten Teil des Wegs hinter sich. Teams, die ausliefern und vergessen, haben am meisten zu tun, denn die Pflicht, jahrelang Support zu leisten und zu patchen, ist genau das, was eine Kultur des Ausliefern-und-Weiterziehen zu vermeiden sucht. Die Verordnung wurde Ende 2024 angenommen und ihre Kernpflichten gelten ab Dezember 2027, was einen definierten Vorlauf lässt, um die Prozesse für die Behandlung von Schwachstellen und für die SBOM aufzubauen, bevor sie durchsetzbar werden. --- ## Cybersecurity Maturity Model Certification (CMMC) **URL:** https://cyberacademy.net/de/resources/encyclopedia/cmmc **Last reviewed:** 2026-06-24 CMMC ist das Cybersecurity-Reifegradmodell, das das US-Verteidigungsministerium seinen Auftragnehmern vorschreibt, die mit Federal Contract Information und Controlled Unclassified Information umgehen. CMMC 2.0 wurde auf drei Stufen reduziert (Foundational, Advanced, Expert), die an NIST SP 800-171 und 800-172 ausgerichtet sind. Wer an das DoD liefert oder Teil seiner Lieferkette ist, fällt in den Geltungsbereich. ## Was CMMC für einen Auftragnehmer tatsächlich ändert Jahrelang forderte das US Department of Defense seine Lieferanten auf, sensible Informationen zu schützen, und vertraute darauf, dass sie es taten. Auftragnehmer bestätigten selbst, dass sie die geforderten Schutzmaßnahmen erfüllten, und die Lücke zwischen dem, was behauptet wurde, und dem, was umgesetzt war, zeigte sich erst nach einem Sicherheitsvorfall. CMMC schließt diese Lücke, indem es die bestehenden Schutzanforderungen in eine überprüfbare Zertifizierung überführt. Die Substanz der Kontrollen änderte sich nicht so sehr wie die Beweislast: Wo Sie früher eine Erklärung unterschrieben, halten Sie nun eine Zertifizierung, die nach einer Bewertung bestätigt, dass Ihre Praktiken tatsächlich vorhanden sind. Wenn Sie Federal Contract Information oder Controlled Unclassified Information an irgendeiner Stelle der DoD-Lieferkette verarbeiten, ist dies der Mechanismus, der darüber entscheidet, ob Sie weiterhin Angebote abgeben dürfen. Das Modell ist weit über die US-Grenzen hinaus von Bedeutung. Europäische Lieferanten, die an amerikanische Generalauftragnehmer weitervergeben, Verteidigungskomponenten fertigen oder CUI im Auftrag eines DoD-Programms verarbeiten, erben dieselbe Verpflichtung. CMMC ist kein Rahmenwerk, das man freiwillig zur guten Hygiene übernimmt; es ist ein vertragliches Tor. Keine Zertifizierung auf der von Ihrem Vertrag geforderten Stufe, kein Zuschlag. Das unterscheidet es von einem freiwilligen Reifegradmodell und stellt es praktisch in dieselbe Kategorie wie eine regulatorische Anforderung: Compliance ist der Preis für den Marktzugang. ## Die drei Stufen und was darunter fällt CMMC 2.0 hat ein früheres fünfstufiges Schema auf drei Stufen gestrafft, jede an die Sensibilität der von Ihnen verarbeiteten Daten und an eine bestehende NIST-Baseline gebunden. Stufe 1 (Foundational) deckt den grundlegenden Schutz von Federal Contract Information ab und baut auf den Praktiken der föderalen Beschaffungsregeln auf, überprüft durch eine jährliche Selbstbewertung. Stufe 2 (Advanced) schützt Controlled Unclassified Information und richtet sich direkt nach NIST SP 800-171, dem Katalog von Kontrollen, der von Auftragnehmern, die CUI verarbeiten, bereits verlangt wird; je nach Vertrag wird sie durch eine Drittbewertung bestätigt. Stufe 3 (Expert) gilt für die sensibelsten Programme und ergänzt die verschärften Anforderungen von NIST SP 800-172 zur Abwehr von Advanced Persistent Threats, bewertet durch die Regierung selbst. **CMMC-2.0-Stufen** | Stufe | Geschützte Daten | Baseline | Bewertung | | --- | --- | --- | --- | | Stufe 1 — Foundational | Federal Contract Information (FCI) | Grundlegende Schutzanforderungen | Jährliche Selbstbewertung | | Stufe 2 — Advanced | Controlled Unclassified Information (CUI) | NIST SP 800-171 | Drittbewertung (oder Selbstbewertung) | | Stufe 3 — Expert | Hochwertige CUI, APT-Exposition | NIST SP 800-171 plus 800-172 | Behördlich geführte Bewertung | Die zentrale Erkenntnis ist, dass CMMC weniger neue Kontrollen erfindet, als vielmehr jene durchsetzt, zu deren Erfüllung Auftragnehmer ohnehin bereits verpflichtet waren. Ein Lieferant, der NIST SP 800-171 wirklich umgesetzt hat, hat den Großteil des Wegs zu Stufe 2 bereits zurückgelegt; die verbleibende Arbeit besteht darin, die Nachweise zu erbringen, die als gegeben angenommenen, aber nie operationalisierten Praktiken zu schließen und eine Bewertung durch jemanden zu bestehen, der nicht Sie selbst ist. ## Wo CMMC neben NIS 2 und ISO 27001 steht Es ist leicht, CMMC, NIS 2 und ISO 27001 in dieselbe Schublade zu stecken, doch sie beantworten unterschiedliche Fragen. ISO 27001 bescheinigt, dass Sie ein risikobasiertes Informationssicherheits-Managementsystem betreiben; es ist freiwillig, international und unabhängig davon, wessen Daten Sie halten. NIS 2 ist europäisches Recht, das wesentlichen und wichtigen Einrichtungen in kritischen Sektoren Pflichten zur Sicherheit und zur Meldung von Vorfällen auferlegt. CMMC ist enger und spezifischer: eine Beschaffungsanforderung der US-Regierung, die auf eine einzige Lieferkette abzielt und auf feste NIST-Kontrollsätze statt auf Ihre eigene Risikobewertung abgebildet ist. Eine bereits nach ISO 27001 zertifizierte Organisation wird eine Managementdisziplin aufgebaut haben, die den CMMC-Aufwand erleichtert, doch die Zertifizierungen sind nicht austauschbar, und die eine erfüllt nicht die andere. > **Die Selbstbestätigung ist vorbei** Der Sinn von CMMC ist, dass eine Unterschrift auf den höheren Stufen nicht mehr ausreicht. Wenn Ihr Angebot vom Schutz von CUI abhängt, planen Sie eine externe Bewertung ein und bauen Sie die Nachweiskette von Anfang an auf, statt sie in der Woche davor zu rekonstruieren. --- ## Cybersecurity Practitioner Certification (CSX-P) **URL:** https://cyberacademy.net/de/resources/encyclopedia/csx-p **Last reviewed:** 2026-06-24 CSX-P ist die praxisorientierte ISACA-Zertifizierung für Cybersecurity-Praktiker. Die Prüfung findet in einer Live-Cyber-Range-Umgebung statt und deckt die fünf Funktionen des NIST CSF ab. Weniger bekannt als CISM oder CISA, aber eine der seltenen Zertifizierungen, bei der die Prüfung testet, was Sie tatsächlich tun, nicht was Sie darüber schreiben können. Das CSX-P (Cybersecurity Practitioner) ist ISACAs Antwort auf eine wiederkehrende Kritik an Sicherheitszertifizierungen: dass die meisten prüfen, ob man die richtige Antwort in einer Multiple-Choice-Frage erkennt, und nicht, ob man die Arbeit tatsächlich beherrscht. Das CSX-P wird in einer Live-Cyber-Range-Umgebung abgelegt, in der die Kandidatin oder der Kandidat in realistische Szenarien versetzt wird und echte Werkzeuge unter realen Bedingungen bedienen muss. Es ist um die Funktionen des NIST Cybersecurity Framework herum aufgebaut, sodass die Prüfung den Lebenszyklus abbildet, den eine Verteidigerin oder ein Verteidiger durchläuft, statt einer Liste auswendig gelernter Definitionen. ## Was das CSX-P unterscheidet: eine Leistungsprüfung Die meisten bekannten Zertifizierungen, einschließlich ISACAs eigener CISM und CISA, sind Wissens- und Urteilsprüfungen. Sie beantworten Fragen; die Zertifizierung bescheinigt, dass Sie die Konzepte verstehen und darüber argumentieren können. Das CSX-P kehrt das um. Statt zu fragen, was Sie tun würden, versetzt es Sie in eine Umgebung und beobachtet, was Sie tatsächlich tun. Die Kandidatin oder der Kandidat bearbeitet Aufgaben über die Funktionen des NIST CSF hinweg, mit echten Systemen und Sicherheitswerkzeugen, unter Bedingungen, die der Arbeit nachempfunden sind. Deshalb beschreibt die shortDefinition es als die seltene Zertifizierung, die prüft, was Sie tun, statt was Sie darüber schreiben können. - Identify: die Umgebung, ihre Assets und den Ort der Exposition verstehen. - Protect: Kontrollen anwenden und konfigurieren, um diese Exposition zu verringern. - Detect: anomale oder bösartige Aktivität in der Telemetrie erkennen, statt zu warten, bis sie gemeldet wird. - Respond: einen Vorfall eindämmen und handeln, sobald er erkannt ist. - Recover: Systeme und Dienste nach dem Ereignis in einen bekannten, einwandfreien Zustand zurückführen. > **Leistungsbasiert, von Grund auf** Das CSX-P ist eine praktische, szenariogesteuerte Prüfung in einem virtuellen Labor. Es geht darum, operative Fähigkeit unter realistischen Bedingungen nachzuweisen. Das rückt es im Geiste näher an eine praktische Laborbewertung als an eine herkömmliche schriftliche Zertifizierung. ## Das CSX-P neben CISM und CISA Das CSX-P ist weniger bekannt als CISM oder CISA, und dieser Abstand spiegelt das Zielpublikum wider, nicht die Strenge. CISM richtet sich an die Person, die ein Sicherheitsprogramm steuert, und CISA an die Person, die unabhängige Assurance über Kontrollen erbringt. Beide validieren Urteilsvermögen und Management- oder Auditfähigkeit. Das CSX-P validiert die technische Ausführung: Können Sie eine Umgebung tatsächlich über den gesamten NIST-CSF-Lebenszyklus hinweg verteidigen. Es sind sich ergänzende Signale, keine konkurrierenden, und ein starkes Team kann alle drei über verschiedene Personen abdecken. **Wissensprüfung vs. Leistungsprüfung** | Zertifizierung | Schwerpunkt | Wie sie geprüft wird | | --- | --- | --- | | CSX-P | Praktische Cybersicherheitsarbeit | Live-Cyber-Range, leistungsbasiert | | CISM | Governance eines Sicherheitsprogramms | Wissen und Urteil, schriftlich | | CISA | IS-Audit und Assurance | Wissen und Urteil, schriftlich | Weil das CSX-P das Tun statt das Wissen nachweist, passt es schlecht zu jemandem, der gezielt auf Audit oder Governance abzielt, und sehr gut zu jemandem, der seine operative Verteidigungsfähigkeit anerkannt sehen möchte. Die Entscheidung dreht sich um die Rolle, nicht um die Seniorität: Eine Praktikerin oder ein Praktiker, die oder der praktisch arbeitet, profitiert von einer Zertifizierung, die die Arbeit widerspiegelt, während einer Managerin oder einem Auditor in der Regel CISM oder CISA besser dient. ## Für wen es geeignet ist Das CSX-P ergibt für technische Praktikerinnen und Praktiker am meisten Sinn: Analystinnen, Verteidiger und Ingenieure, die praktische Sicherheitsoperationen über die Funktionen des NIST CSF hinweg bereits ausführen oder sich darauf zubewegen wollen. Da es an diesem Framework verankert ist, eignet es sich für Personen, die in Umgebungen arbeiten, die das CSF bereits als Referenz nutzen, einschließlich der transatlantischen Organisationen, die es mit ISO 27001 kombinieren. Wie bei jeder Zertifizierung wägt ein Arbeitgeber letztlich nachgewiesene Fähigkeit ab. Der Wert des CSX-P liegt gerade darin, dass es einen herstellerneutralen, strukturierten Weg bietet, die praktischen Fähigkeiten zu belegen, die der Titel benennt, statt einen Arbeitgeber zu bitten, Kompetenz auf Vertrauen anzunehmen. --- ## Data Protection Officer (DPO) **URL:** https://cyberacademy.net/de/resources/encyclopedia/dpo **Last reviewed:** 2026-06-24 Der DPO ist die gemäß GDPR vorgeschriebene Funktion, die die Compliance überwacht, den Verantwortlichen berät und als Anlaufstelle für die Aufsichtsbehörde fungiert. Pflichtrolle für öffentliche Stellen sowie für Verarbeitungstätigkeiten, die eine umfangreiche systematische Überwachung oder die Verarbeitung besonderer Kategorien personenbezogener Daten erfordern. Unabhängigkeit und Zugang zur Leitungsebene sind die zwei Punkte, die Prüfer tatsächlich kontrollieren. ## Wozu die Rolle dient Der Data Protection Officer ist die Person, die eine Organisation benennt, um die Verarbeitung personenbezogener Daten nach der GDPR rechtskonform zu halten. Die Aufgabe besteht nicht darin, Datenschutzprojekte zu leiten oder die Compliance abzuzeichnen, sondern zu überwachen, ob die Organisation das tut, was das Gesetz und ihre eigenen Richtlinien verlangen, den Verantwortlichen und den Auftragsverarbeiter zu beraten, zu schulen und zu sensibilisieren sowie als zentrale Anlaufstelle für die Aufsichtsbehörde und für die betroffenen Personen zu dienen, die ihre Rechte ausüben möchten. Der DPO informiert und berät, doch die Verantwortung für die Verarbeitung verbleibt beim Verantwortlichen. Ein DPO ist in drei Situationen verpflichtend: wenn die Verarbeitung durch eine Behörde erfolgt, wenn die Kerntätigkeiten eine regelmäßige und systematische Überwachung von Personen in großem Umfang erfordern, und wenn die Kerntätigkeiten eine Verarbeitung besonderer Kategorien von Daten in großem Umfang umfassen, etwa Gesundheitsdaten, biometrische Daten oder Daten über strafrechtliche Verurteilungen. Organisationen, die nicht unter diese Auslöser fallen, können dennoch freiwillig einen DPO benennen, und viele tun dies, weil es ihnen einen klaren internen Verantwortlichen für Datenschutzfragen verschafft. ## Unabhängigkeit und Zugang, die beiden Punkte, die Prüfer kontrollieren Wenn eine Aufsichtsbehörde oder ein interner Prüfer die DPO-Funktion betrachtet, entscheiden zwei Punkte darüber, ob sie echt oder bloß kosmetisch ist. Der erste ist die Unabhängigkeit. Der DPO darf keine Anweisungen erhalten, wie die Aufgabe auszuführen ist, darf nicht abberufen oder benachteiligt werden, weil er seine Aufgabe ordnungsgemäß wahrnimmt, und darf nicht in eine Lage gebracht werden, in der er seine eigenen Entscheidungen prüft. Deshalb sollte ein DPO in der Regel nicht zugleich der CISO, der IT-Leiter oder der Marketing-Leiter sein, denn diese Rollen legen die Zwecke und Mittel der Verarbeitung fest, die der DPO zu überprüfen hat. Der zweite ist der Zugang. Der DPO muss der höchsten Leitungsebene berichten und frühzeitig und ordnungsgemäß in alle Fragen einbezogen werden, die den Schutz personenbezogener Daten betreffen. > **Der Interessenkonflikt ist der klassische Befund** Einen DPO zu benennen, der zugleich Eigentümer der Systeme ist, die er beaufsichtigen soll, ist einer der häufigsten Gründe, weshalb eine Aufsichtsbehörde zu dem Schluss kommt, dass die Rolle nicht wirklich unabhängig ist. Halten Sie den DPO aus Entscheidungen über die Zwecke und Mittel der Verarbeitung heraus. - Überwacht die Einhaltung der GDPR und der internen Datenschutzrichtlinien. - Berät zu Datenschutz-Folgenabschätzungen (DPIA) und hilft bei deren Überprüfung. - Arbeitet mit der Aufsichtsbehörde zusammen und ist deren Anlaufstelle. - Übernimmt die Kommunikation mit den betroffenen Personen über ihre Rechte. ## Wie der DPO sich zu benachbarten Konzepten verhält Der DPO ist eine Person und eine Pflicht, kein Kontrollrahmenwerk. Die GDPR ist die Verordnung, die die Rolle schafft und ihre Aufgaben festlegt. Die DPIA ist eines der Instrumente, zu denen der DPO berät, eine strukturierte Bewertung, die vor Beginn einer Verarbeitung mit hohem Risiko durchgeführt wird. ISO 27701 ist der Standard für das Management von Datenschutzinformationen, gegen den sich eine Organisation zertifizieren lassen kann, und eine gut geführte DPO-Funktion fügt sich naturgemäß in dessen Anforderungen ein, ohne dasselbe zu sein. Die CDPSE ist eine berufliche Zertifizierung, die bestätigt, dass ein Privacy Engineer oder ein DPO Datenschutz in Systeme einbauen kann. Ein DPO kann ein Mitarbeiter oder ein externer Dienstleister sein, und eine Unternehmensgruppe kann einen einzigen DPO benennen, solange diese Person von jeder Niederlassung aus erreichbar bleibt und genügend Unabhängigkeit und Ressourcen behält, um sie alle abzudecken. --- ## Datenschutz-Folgenabschätzung (DPIA) **URL:** https://cyberacademy.net/de/resources/encyclopedia/dpia **Last reviewed:** 2026-06-24 Eine DPIA ist die strukturierte Analyse, die das GDPR vor einer Verarbeitung mit hohem Risiko vorschreibt. Sie dokumentiert Art, Umfang, Kontext und Zwecke der Verarbeitung, bewertet Notwendigkeit und Verhältnismäßigkeit und identifiziert Maßnahmen zur Risikoминimierung. Die CNIL stellt ein kostenloses PIA-Tool bereit. Wer eine erforderliche DPIA weglässt, lädt Aufsichtsbehörden geradezu ein. ## Wann eine DSFA erforderlich ist und wann nicht Eine Datenschutz-Folgenabschätzung ist kein Formalakt, den Sie für jedes Projekt erstellen. Die DSGVO knüpft sie an einen einzigen Auslöser: eine Verarbeitung, die voraussichtlich ein hohes Risiko für die Rechte und Freiheiten natürlicher Personen zur Folge hat. Der Text nennt einige Fälle, in denen die Abschätzung verpflichtend ist, etwa eine systematische und umfassende Profilbildung, die rechtliche oder ähnlich erhebliche Wirkungen entfaltet, die umfangreiche Verarbeitung besonderer Kategorien von Daten und die umfangreiche systematische Überwachung eines öffentlich zugänglichen Bereichs. Die nationalen Aufsichtsbehörden veröffentlichen dann ihre eigenen Listen von Verarbeitungsvorgängen, die stets eine DSFA erfordern, sowie Listen von Vorgängen, die keine erfordern. In der Praxis beginnen Sie mit einer Vorprüfung. Stellen Sie der Verarbeitung eine kurze Liste von Risikokriterien gegenüber, etwa der vom Europäischen Datenschutzausschuss veröffentlichten Art, und zählen Sie, wie viele zutreffen. Kombinationen wie Bewertung oder Scoring zusammen mit automatisierter Entscheidungsfindung oder sensible Daten zusammen mit einer umfangreichen Datenverarbeitung lassen Sie die Schwelle überschreiten. Wenn die Antwort unsicher ist, besteht das vertretbare Vorgehen darin zu dokumentieren, warum Sie zu dem Schluss gekommen sind, dass keine vollständige DSFA erforderlich war, und nicht darin, die Frage stillschweigend zu übergehen. > **Der kostengünstigste Fehler, den es zu vermeiden gilt** Eine DSFA nicht durchzuführen, wenn sie erforderlich war, sie fehlerhaft durchzuführen oder die Aufsichtsbehörde nicht zu konsultieren, wenn das Restrisiko hoch bleibt, sind allesamt unmittelbar benannte Verstöße. Eine fehlende DSFA ist eine der am leichtesten erkennbaren Lücken, die eine Aufsichtsbehörde bei einer Prüfung aufdecken kann. ## Was in die Abschätzung gehört Die DSGVO legt einen Mindestinhalt fest. Eine DSFA muss eine systematische Beschreibung der Verarbeitungsvorgänge und der Zwecke, eine Bewertung der Notwendigkeit und Verhältnismäßigkeit der Verarbeitung in Bezug auf diese Zwecke, eine Bewertung der Risiken für die Rechte und Freiheiten der betroffenen Personen sowie die zur Bewältigung dieser Risiken geplanten Maßnahmen, einschließlich Garantien und Sicherheitsvorkehrungen, enthalten. Die CNIL stellt ein kostenloses PIA-Softwarewerkzeug bereit, das Sie genau durch diese Struktur führt, und es gibt keinen Grund, sie von Grund auf neu aufzubauen. Notwendigkeit und Verhältnismäßigkeit sind die Punkte, an denen die meisten Abschätzungen dünn sind. Es handelt sich um eine rechtliche Prüfung, nicht um eine sicherheitstechnische: Ist jedes Datenfeld tatsächlich für den angegebenen Zweck erforderlich, ist die Aufbewahrungsfrist gerechtfertigt, besteht eine Rechtsgrundlage, sind die Rechte der betroffenen Personen gewahrt. Die Risikoanalyse ist der sicherheitsnahe Teil, und sie entlehnt unmittelbar der Praxis des Risikomanagements. Hier liefern Ihnen ISO 27005 und EBIOS Risk Manager das Vokabular der Bedrohungen, der befürchteten Ereignisse, der Eintrittswahrscheinlichkeit und der Schwere. Eine DSFA bewertet das Risiko für die Personen, deren Daten verarbeitet werden, nicht das Risiko für die Organisation, und das ist die Unterscheidung, an der man stolpert. ## Wer sie durchführt und wie sie lebendig bleibt Der Verantwortliche ist für die Durchführung der DSFA zuständig. Ist ein Datenschutzbeauftragter benannt, muss der Verantwortliche dessen Rat einholen, und der DSB prüft in der Regel die Abschätzung und überwacht deren Durchführung. Sie sollten außerdem, soweit angebracht, den Standpunkt der betroffenen Personen oder ihrer Vertreter einholen. Auftragsverarbeiter haben eine Unterstützungspflicht. Wenn das Restrisiko nach der Minderung hoch bleibt und Sie es nicht verringern können, verlangt die DSGVO eine vorherige Konsultation der Aufsichtsbehörde, bevor die Verarbeitung beginnt. Eine DSFA ist ein lebendes Dokument. Der Verantwortliche muss sie überprüfen, wenn sich das mit der Verarbeitung verbundene Risiko ändert, etwa durch einen neuen Datenfluss, eine neue Technologie, einen neuen Zweck oder einen neuen Unterauftragsverarbeiter. Behandeln Sie sie als fortlaufend: Ein sinnvoller Rhythmus besteht darin, die Abschätzungen in einem festgelegten Zyklus und immer dann zu überprüfen, wenn sich die Gestaltung ändert, anstatt sie einmal abzulegen und zu vergessen. **Die DSFA im Vergleich zu einer allgemeinen Risikobewertung** | Dimension | DSFA | Allgemeine Sicherheitsrisikobewertung | | --- | --- | --- | | Auslöser | Risikoreiche Verarbeitung personenbezogener Daten | Jedes Asset, System oder jeder Prozess im Geltungsbereich | | Gegenstand des Risikos | Rechte und Freiheiten natürlicher Personen | Die Organisation und ihre Vermögenswerte | | Rechtlicher Status | Nach der DSGVO verpflichtend, wenn ausgelöst | Getrieben durch eine Richtlinie oder Standards wie ISO 27001 | | Typische Methode | CNIL-PIA-Werkzeug, EDPB-Kriterien, Notwendigkeitsprüfung | ISO 27005, EBIOS Risk Manager | | Ergebnis | Minderungsmaßnahmen plus mögliche vorherige Konsultation | Behandlungsplan und Akzeptanz des Restrisikos | --- ## Datenschutz-Grundverordnung (GDPR) **URL:** https://cyberacademy.net/de/resources/encyclopedia/gdpr **Last reviewed:** 2026-06-24 Die GDPR regelt personenbezogene Daten in der EU und überall dort, wo EU-Bürgerinnen und -Bürger als Nutzer adressiert werden. Rechtsgrundlage, Betroffenenrechte, Rechenschaftspflicht, Meldung von Datenschutzverletzungen, Aufsichtsdurchsetzung. Die Höchstbußgelder (20 Millionen Euro bzw. 4 % des weltweiten Jahresumsatzes) sorgen für Schlagzeilen; der Großteil der Durchsetzungsmaßnahmen erfolgt jedoch über den Aufsichtsdialog, nicht über das Maximum. ## Eine Verordnung über Rechenschaftspflicht, nicht nur über Einwilligung Die DSGVO wird in Gesprächen oft auf Cookie-Banner und Einwilligungs-Pop-ups reduziert, doch dieses Bild verfehlt, wo ihr eigentliches Gewicht liegt. Die Einwilligung ist nur eine von mehreren Rechtsgrundlagen für die Verarbeitung personenbezogener Daten, und für die meisten geschäftlichen Abläufe ist sie nicht einmal diejenige, auf die sich Organisationen stützen. Vertragserfüllung, rechtliche Verpflichtung und berechtigte Interessen tragen in der Praxis weitaus mehr Verarbeitungen. Die tiefere Verschiebung, die die DSGVO eingeführt hat, ist die Rechenschaftspflicht (accountability): Es genügt nicht, konform zu sein, man muss die Konformität auch nachweisen können. Dieses eine Prinzip ist es, das den Datenschutz von einer Rechtsauffassung in eine operative Disziplin verwandelt, mit Verzeichnissen, Bewertungen und Nachweisen hinter jeder Aussage. Weil es sich um eine Verordnung und nicht um eine Richtlinie handelt, gilt die DSGVO unmittelbar in der gesamten EU und im weiteren EWR, ohne dass jedes Land sie in nationales Recht umschreiben muss, weshalb ihre Kernpflichten in Frankreich, Deutschland und Irland gleich aussehen. Ihre Reichweite erstreckt sich auch über Europa hinaus. Eine außerhalb der EU niedergelassene Organisation fällt dennoch in ihren Anwendungsbereich, wenn sie Personen in der Union Waren oder Dienstleistungen anbietet oder deren Verhalten dort beobachtet. Diese territoriale Reichweite ist der Grund, warum ein Unternehmen ohne europäische Niederlassung dennoch einer europäischen Aufsichtsbehörde gegenüber Rede und Antwort stehen kann. ## Rechtsgrundlage, Betroffenenrechte und die daraus folgenden Pflichten Jede Verarbeitung personenbezogener Daten benötigt eine vor Beginn der Verarbeitung gewählte Rechtsgrundlage, und die gewählte Grundlage prägt die Rechte, die Personen ausüben können. Betroffene können verlangen, auf ihre Daten zuzugreifen, sie berichtigen oder löschen zu lassen, die Verarbeitung einzuschränken oder ihr zu widersprechen und sie in bestimmten Fällen in einem übertragbaren Format zu erhalten. Keines dieser Rechte ist absolut; jedes ist an Bedingungen und Ausnahmen geknüpft. Um die Rechte herum stehen die Pflichten des Verantwortlichen und des Auftragsverarbeiters: Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen, das Führen eines Verzeichnisses von Verarbeitungstätigkeiten, das Absichern der Daten durch geeignete technische und organisatorische Maßnahmen sowie das Abschließen schriftlicher Verträge, wann immer ein Auftragsverarbeiter Daten im Auftrag eines Verantwortlichen verarbeitet. Zwei Pflichten verdienen es, hervorgehoben zu werden, weil sie die tägliche Arbeit antreiben. Wenn eine Verarbeitung voraussichtlich ein hohes Risiko für die betroffenen Personen zur Folge hat, führt der Verantwortliche vor dem Fortfahren eine Datenschutz-Folgenabschätzung durch und dokumentiert das Risiko sowie die Art seiner Minderung. Und wenn eine Verletzung des Schutzes personenbezogener Daten eintritt, trifft den Verantwortlichen eine Meldepflicht gegenüber der Aufsichtsbehörde innerhalb einer kurzen, festgelegten Frist, wobei auch die betroffenen Personen informiert werden, wenn das Risiko für sie hoch ist. Das sind keine Papierkram-Rituale. Es sind die Punkte, an denen das Prinzip der Rechenschaftspflicht zu einer konkreten, fristgebundenen Verpflichtung wird. > **Die DSGVO setzt das Recht, ISO 27701 hilft Ihnen, es umzusetzen** Die DSGVO sagt Ihnen, was Sie erreichen müssen, aber nicht, wie Sie es als System betreiben. ISO/IEC 27701 erweitert ein Informationssicherheits-Managementsystem nach ISO 27001 zu einem Datenschutz-Managementsystem und gibt Ihnen wiederholbare Routinen für die Verzeichnisse, Bewertungen und Kontrollen, die die Verordnung erwartet. Eine Zertifizierung entspricht nicht der rechtlichen Konformität, aber sie macht diese Konformität prüfbar statt improvisiert. ## Wo die DSGVO zwischen benachbarten Konzepten steht Es hilft, die DSGVO von den Rollen und Werkzeugen zu trennen, die sie umkreisen. Ein DPO ist eine Person oder Funktion, die einige Organisationen benennen müssen, um die Konformität zu überwachen; eine DPIA ist der Bewertungsprozess für risikoreiche Verarbeitungen; ein ROPA ist das Verzeichnis der Verarbeitungstätigkeiten; Standardvertragsklauseln sind einer der Mechanismen, um Daten rechtmäßig aus der EU zu übermitteln. Die DSGVO ist die Verordnung, die jedes dieser Elemente vorschreibt oder ermöglicht. Nationale Aufsichtsbehörden wie die CNIL in Frankreich setzen sie durch und geben Leitlinien heraus, und der Europäische Datenschutzausschuss koordiniert sie, damit grenzüberschreitend eine einheitliche Auslegung gilt. Wie die shortDefinition anmerkt, beherrschen die Schlagzeilenwerte von bis zu 20 Millionen Euro oder 4 Prozent des weltweiten Jahresumsatzes die Presseberichterstattung, doch der größte Teil der Durchsetzung verläuft über den aufsichtsbehördlichen Dialog statt über Höchstbußgelder. Behörden ermitteln, stellen Fragen, verlangen Abhilfe und lösen Angelegenheiten oft durch Korrekturmaßnahmen weit unterhalb der Obergrenze. Für Praktiker lautet die praktische Lehre, dass nachweisbarer guter Glaube und eine durch Belege gestützte Konformitätshaltung verändern, wie dieser Dialog verläuft. Die Organisationen, die am schlechtesten abschneiden, sind in der Regel diejenigen, die nicht zeigen können, was sie mit den Daten getan haben, nicht diejenigen, die eine ehrliche, dokumentierte Abwägungsentscheidung getroffen haben. ## Wie Praktiker es operationalisieren Die Verordnung in Routinearbeit zu überführen, beginnt meist mit der Kartierung. Sie erstellen und pflegen ein Verzeichnis der Verarbeitungstätigkeiten, damit Sie wissen, welche Daten Sie halten, warum, auf welcher Rechtsgrundlage und wohin sie fließen. Von dort aus verankern Teams Datenschutz durch Technikgestaltung in neuen Projekten, führen DPIAs dort durch, wo das Risiko hoch ist, ziehen Auftragsverarbeitungsverträge straffer und üben den Pfad der Datenpannen-Meldung ein, damit die Frist sie nicht unvorbereitet trifft. Viele verankern dies in einem Managementsystem statt in einem Ordner voller Richtlinien, und genau dort verdienen sich Standards wie ISO 27701 und die unterstützenden Leitlinien der Aufsichtsbehörden ihren Platz. Das Ziel ist ein Dauerzustand des Nachweises: Jederzeit können Sie für die personenbezogenen Daten, die Sie verarbeiten, eine Rechtsgrundlage, ein Verzeichnis und eine Kontrolle vorweisen. --- ## Defense in Depth **URL:** https://cyberacademy.net/de/resources/encyclopedia/defense-in-depth **Last reviewed:** 2026-06-24 Defense in Depth ist das Prinzip der gestaffelten Kontrollen, damit kein einzelner Ausfall das gesamte System gefährdet. Netzwerk, Endpunkt, Anwendung, Daten, Personal, physische Ebene – jede Schicht verlangsamt den Angreifer, erhöht seinen Aufwand und verschafft Ihnen Zeit zur Erkennung. Grundlegend seit den 1990er Jahren. Auditoren erwarten dieses Prinzip; Anbieter nutzen es gerne, um zusätzliche Schichten zu verkaufen. ## Warum Staffelung einer einzelnen starken Mauer überlegen ist Defense in Depth geht von der pessimistischen Annahme aus, dass jede einzelne Kontrolle irgendwann versagen wird. Eine Firewall ist falsch konfiguriert, ein Patch kommt zu spät, eine Phishing-E-Mail trifft ihr Ziel, eine Zugangsdaten werden geleakt. Wenn Ihre Sicherheit auf einer einzigen Barriere beruht, bedeutet dieses eine Versagen das Ende. Kontrollen zu staffeln heißt, dass der Angreifer, der das Perimeter überwindet, immer noch auf Endpunktschutz trifft, dann auf segmentierte Netzwerke, dann auf Anwendungskontrollen, dann auf verschlüsselte Daten, dann auf eine Überwachung, die den gesamten Pfad im Blick hat. Jede Schicht ist unabhängig, sodass die Wahrscheinlichkeit, dass alle gleichzeitig versagen, weitaus geringer ist als die Wahrscheinlichkeit, dass eine einzige versagt. Der Nutzen für die Praxis ist nicht nur Prävention, es sind Zeit und Sichtbarkeit. Jede Schicht, die der Angreifer überwinden muss, kostet ihn Mühe, erzeugt Spuren und schafft eine Gelegenheit für Ihr Detection-and-Response-Team, den Eindringling zu bemerken, bevor er die Daten erreicht, auf die es ankommt. Bei Defense in Depth geht es ebenso sehr darum, Erkennungszeit zu gewinnen, wie darum, die Sicherheitsverletzung von vornherein zu stoppen. ## Die Schichten und was in jeder von ihnen liegt Praktiker denken in der Regel in konzentrischen Schichten statt in einer flachen Liste von Produkten. Worauf es ankommt, ist die Abdeckung über alle Kategorien hinweg, nicht der Kauf jedes Tools innerhalb einer Kategorie. Eine gängige Art, die Schichten zu gliedern: - Physisch: verschlossene Räumlichkeiten, Zugangsausweise und Gerätekontrollen, damit ein Angreifer nicht einfach bis zur Hardware gehen kann. - Menschen: Awareness-Schulungen, Phishing-Simulationen und klare Prozesse, denn Nutzer sind zugleich Ziel und Kontrolle. - Netzwerk: Segmentierung, Firewalls und Verkehrsinspektion, damit ein Standfuß in einer Zone nicht den Zugriff auf den gesamten Bestand verschafft. - Endpunkt: Härtung, EDR und Patch-Management auf den Maschinen, auf denen Angriffe tatsächlich ausgeführt werden. - Anwendung: sichere Entwicklung, Eingabevalidierung und Authentifizierungskontrollen auf der Softwareebene. - Daten: Verschlüsselung im Ruhezustand und während der Übertragung, Klassifizierung und Zugriffskontrollen, damit das Asset selbst geschützt bleibt, selbst wenn eine darüberliegende Schicht durchbrochen wird. > **Schichten, keine Duplizierung** Defense in Depth bedeutet unabhängige Kontrollen über verschiedene Kategorien hinweg, nicht drei Firewalls von drei Anbietern. Redundante Tools in einer Schicht zu stapeln, während eine andere Schicht blank bleibt, ist ein verbreiteter und teurer Fehler. Ordnen Sie Ihre Kontrollen den Schichten zu und suchen Sie nach den Lücken, nicht nach den Überschneidungen. ## Wie es mit Zero Trust und dem Least-Privilege-Prinzip zusammenhängt Defense in Depth ist das ältere, breitere Prinzip. Zero Trust und Least Privilege sind schärfere moderne Ausdrucksformen desselben Instinkts. Least Privilege besagt, jeder Identität nur den Zugriff zu geben, den sie benötigt, was begrenzt, wie weit ein einzelnes kompromittiertes Konto reichen kann, und damit faktisch eine Schicht innerhalb des Systems hinzufügt statt um es herum. Zero Trust verwirft die Annahme, dass alles innerhalb des Perimeters vertrauenswürdig ist, und überprüft jede Anfrage fortlaufend. Wo klassische Defense in Depth oft eine harte äußere Schale mit einem weicheren Inneren voraussetzte, treibt Zero Trust die Überprüfung an jede Grenze. Sie ergänzen sich: Ein ausgereiftes Programm nutzt Defense in Depth als Architektur und Zero Trust als Betriebsmodell, das den weichen, nachgiebigen Kern beseitigt. In Normen und Audits ist die Idee allgegenwärtig, selbst wenn der Begriff es nicht ist. ISO/IEC 27001 Annex A verteilt die Kontrollen auf organisatorische, personenbezogene, physische und technologische Themen, was Defense in Depth unter anderem Namen ist. NIST-Frameworks und die CIS Controls sind so aufgebaut, dass keine einzelne Schutzmaßnahme die gesamte Last trägt. Auditoren erwarten gestaffelte Kontrollen mit dokumentierter Begründung, und sie behandeln einen Single Point of Failure als Feststellung, nicht als Designentscheidung. --- ## Digital Operational Resilience Act (DORA) **URL:** https://cyberacademy.net/de/resources/encyclopedia/dora **Last reviewed:** 2026-06-24 DORA ist die EU-Verordnung, die Finanzunternehmen und ihren kritischen IKT-Drittanbietern einen einheitlichen Resilienzrahmen vorschreibt. Fünf Säulen: IKT-Risikomanagement, Incident Reporting, Resilienztests einschließlich TLPT, IKT-Drittparteienrisiko, Informationsaustausch. Anwendbar seit dem 17. Januar 2025. Im IKT-Bereich greift DORA schärfer als NIS 2, und als lex specialis hat es für Finanzunternehmen Vorrang. ## Warum DORA existiert und wen es bindet Vor DORA war die digitale operationale Resilienz für Finanzunternehmen in der EU ein Flickenteppich. Banken unterlagen einem Satz aufsichtlicher Erwartungen, Versicherer einem anderen, und die Regeln zu IKT-Vorfällen, Auslagerung und Tests unterschieden sich je nach Sektor und nach Mitgliedstaat. DORA ersetzt diese Zersplitterung durch eine einzige Verordnung, die unionsweit unmittelbar gilt, ohne dass eine nationale Umsetzung erforderlich ist. Ihr Anwendungsbereich ist bewusst weit gefasst: Banken, Versicherer, Wertpapierfirmen, Zahlungs- und E-Geld-Institute, Anbieter von Krypto-Dienstleistungen, Handelsplätze und viele mehr, dazu die kritischen IKT-Drittdienstleister, von denen diese Unternehmen abhängen. Genau dieser letzte Punkt unterscheidet DORA von einer gewöhnlichen Finanzregel. Es reguliert nicht nur die beaufsichtigten Unternehmen; es greift in deren Lieferkette ein. Cloud-Anbieter, Rechenzentrumsbetreiber und Softwareanbieter, die als kritisch für das Finanzsystem gelten, können auf EU-Ebene unter direkte Aufsicht gestellt werden. Für einen Praktiker ist die praktische Folge, dass Resilienz nicht länger etwas ist, das man vollständig auslagern und vergessen kann. Sie bleiben für das IKT-Risiko verantwortlich, das Ihre Dienstleister tragen, und Sie müssen es nachweisen. ## Die fünf Säulen in der Praxis DORA beruht auf fünf Säulen, und jede davon übersetzt sich in konkrete Programmarbeit statt in Papierkram: - IKT-Risikomanagement. Ein Governance-Rahmen, der dem Leitungsorgan obliegt und Identifizierung, Schutz, Erkennung, Reaktion und Wiederherstellung für IKT-Assets abdeckt. Dies ist das Rückgrat, an dem die anderen vier Säulen hängen. - Behandlung und Meldung von Vorfällen. IKT-bezogene Vorfälle nach Schweregrad klassifizieren und die schwerwiegenden der zuständigen Behörde innerhalb eines festgelegten Zeitrahmens melden. Der Schwerpunkt liegt auf einer harmonisierten Taxonomie, damit Aufseher in der gesamten EU vergleichbare Daten sehen. - Testen der digitalen operationalen Resilienz. Ein regelmäßiges Testprogramm, das von Schwachstellenbewertungen bis hin zu bedrohungsorientierten Penetrationstests (TLPT) für die bedeutendsten Unternehmen reicht und sich am realen Angreiferverhalten orientiert. - Management des IKT-Drittparteienrisikos. Vertragliche Schutzvorkehrungen, Informationsregister über alle IKT-Vereinbarungen, Ausstiegsstrategien und das Überwachungsregime für kritische Drittdienstleister. - Informationsaustausch. Freiwilliger Austausch von Bedrohungsinformationen zwischen Finanzunternehmen, gefördert statt vorgeschrieben, um die kollektive Verteidigung zu stärken. > **Resilienz, nicht nur Sicherheit** Bei DORA geht es darum, dass das Finanzsystem unter Belastung betriebsfähig bleibt, nicht nur darum, Angreifer fernzuhalten. Deshalb stützt es sich so stark auf Tests, Wiederherstellung und Drittparteienkontinuität. Es geht davon aus, dass Dinge ausfallen werden, und fragt, ob Sie Ihre kritischen Funktionen weiter erbringen können, wenn das geschieht, und genau hier überschneidet es sich mit der Betriebskontinuität und ISO 22301. ## DORA neben NIS 2 Die Frage, die Praktiker am häufigsten stellen, ist, wie sich DORA zu NIS 2 verhält, da beide EU-Instrumente sind, die die Cybersicherheit berühren, und beide ungefähr dieselbe Reifelatte ansetzen. Die kurze Antwort lautet lex specialis: Wo DORA und NIS 2 beide auf ein Finanzunternehmen im IKT-Aspekt anwendbar wären, geht DORA vor, weil es die speziellere Regel ist. NIS 2 setzt eine breite Cybersicherheits-Grundlinie über viele Sektoren hinweg; DORA geht bei der IKT-Resilienz des Finanzsektors tiefer und fügt das Drittparteien-Überwachungsregime hinzu, das NIS 2 nicht hat. **DORA im Vergleich zu NIS 2** | Dimension | DORA | NIS 2 | | --- | --- | --- | | Art des Instruments | Verordnung, unmittelbar anwendbar | Richtlinie, von den Mitgliedstaaten umgesetzt | | Hauptanwendungsbereich | Finanzunternehmen und ihre kritischen IKT-Dienstleister | Wesentliche und wichtige Einrichtungen in vielen Sektoren | | Schwerpunkt | Digitale operationale Resilienz des Finanzsystems | Allgemeines Cybersicherheits-Risikomanagement und -Meldewesen | | Drittparteienaufsicht | Direkte EU-Aufsicht über kritische IKT-Dienstleister | Lieferkettensicherheit erwartet, kein direktes Aufsichtsregime | | Vorrang für den Finanzbereich | Setzt sich als lex specialis im IKT-Aspekt durch | Tritt hinter DORA zurück, wo beide anwendbar wären | Im Tagesgeschäft kann eine Bank sich nicht eines aussuchen. Sie ordnet ihre Pflichten zu und stellt fest, dass für IKT-Risiko, Vorfallmeldung und Resilienztests DORA der maßgebliche Text ist, während NIS 2 weiterhin für Teile der Gruppe relevant sein kann, die außerhalb des Finanz-Anwendungsbereichs von DORA liegen. Der saubere Weg, dies zu handhaben, ist ein einziges Kontrollrahmenwerk, oft verankert in ISO 27001 und ISO 22301, das beide Regime erfüllt und es Ihnen erlaubt, die Konformität nur einmal nachzuweisen. --- ## Disaster Recovery (DR) **URL:** https://cyberacademy.net/de/resources/encyclopedia/disaster-recovery **Last reviewed:** 2026-06-24 Disaster Recovery ist die IT-fokussierte Teilmenge des BCM: Wiederherstellung von Infrastruktur, Anwendungen und Daten nach einer Betriebsunterbrechung. RPO, RTO und Runbooks sind hier angesiedelt. Ein DR-Plan, der nie vollständig getestet wurde, ist Fiktion. ISO 24762 deckte diesen Bereich früher ab; die aktuelle Praxis verweist auf ISO 22301 in Verbindung mit den operativen Runbooks. ## Wo die Notfallwiederherstellung innerhalb der Kontinuität angesiedelt ist Die Notfallwiederherstellung ist der technische Maschinenraum des Business Continuity Managements. Das Business Continuity Management fragt, wie die Organisation ihre kritischen Aktivitäten während einer Störung weiterhin erbringt, und umfasst dabei Menschen, Standorte, Lieferanten und Prozesse. Die Notfallwiederherstellung beantwortet eine engere Frage: Wie bringen wir die IT zurück. Server, Netzwerke, Anwendungen, Datenbanken und die Daten selbst. Wenn ein Rechenzentrum überflutet wird, ein Ransomware-Stamm die Produktion verschlüsselt oder eine Cloud-Region ausfällt, ist der DR-Plan das Dokument und das eingeübte Reaktionsvermögen, das die Systeme in einer bekannten Reihenfolge bis zu einem bekannten Zeitpunkt wieder zum Laufen bringt. Diese Unterscheidung ist wichtig, weil die beiden oft verwechselt werden. Ein Kontinuitätsplan kann manuelle Behelfslösungen beschreiben, die einen Dienst am Leben halten, während die IT ausgefallen ist. Ein DR-Plan hat diesen Luxus nicht. Er wird ausschließlich danach beurteilt, ob die Systeme zurückkommen, wie schnell und wie viele Daten verloren gingen. Die Notfallwiederherstellung als Teilmenge der Kontinuität und nicht als Synonym zu behandeln, hält den Geltungsbereich ehrlich und verhindert, dass Teams annehmen, ein wiederhergestellter Server bedeute einen wiederhergestellten Geschäftsdienst. ## RTO, RPO und das Runbook Zwei Kennzahlen bestimmen jede DR-Entscheidung. Das Recovery Time Objective (RTO) ist die maximal tolerierbare Zeit, die ein System ausfallen darf, bevor die Auswirkung untragbar wird. Das Recovery Point Objective (RPO) ist die maximal tolerierbare Menge an Datenverlust, ausgedrückt als Zeitfenster, was in der Praxis vorgibt, wie häufig Sie replizieren oder sichern. Ein RTO von vier Stunden mit einem RPO von fünfzehn Minuten ist eine ganz andere Architektur, und ein ganz anderes Budget, als ein RTO bis zum nächsten Geschäftstag mit einer täglichen Sicherung. Diese Ziele sollten aus einer Business-Impact-Analyse stammen, nicht aus dem Komfortlevel des Infrastrukturteams. - Das RTO bestimmt die Wiederherstellungsarchitektur: Hot-Standby und Replikation für enge Ziele, Wiederherstellung aus dem Backup für entspanntere Ziele. - Das RPO bestimmt die Datenschutzstrategie: synchrone Replikation, Snapshots oder periodische Backups. - Das Runbook verwandelt diese Ziele in ein getestetes, schrittweises Wiederherstellungsverfahren, dem jemand unter Stress tatsächlich folgen kann. > **Ein ungetesteter Plan ist Fiktion** Ein DR-Plan, der nie durchgängig erprobt wurde, ist eine Hypothese, keine Fähigkeit. Backups, die nie wiederhergestellt wurden, ein Failover, das nie ausgelöst wurde, und Runbooks, die niemand eingeübt hat, versagen regelmäßig im schlimmsten Moment. Planen Sie Wiederherstellungstests, führen Sie Tabletop-Durchläufe des Entscheidungsflusses durch und dokumentieren Sie die Lücken, die jede Übung aufdeckt. ## Normen, Bedrohungen und aktuelle Praxis Die Normenlandschaft hat sich verändert. ISO/IEC 24762 gab einst dedizierte Leitlinien für ICT-Notfallwiederherstellungsdienste, wurde jedoch zurückgezogen, und die aktuelle Praxis verweist zurück auf ISO 22301 für das Business-Continuity-Managementsystem, wobei ISO/IEC 27031 die ICT-Bereitschaft für die Geschäftskontinuität abdeckt. In diesem Modell ist die Notfallwiederherstellung keine eigenständige Disziplin; sie ist die operative Schicht, die die Kontinuitätsstrategie umsetzt, geregelt durch dasselbe Managementsystem und dieselbe Risikobereitschaft. Regulierte Sektoren bringen ihren eigenen Druck mit: Das Resilienzregime des EU-Finanzsektors zum Beispiel erwartet von den Unternehmen den Nachweis, dass Wiederherstellung und Kontinuität für kritische Funktionen getestet und nicht bloß dokumentiert sind. Die moderne Notfallwiederherstellung wird zudem durch die Bedrohungen geprägt, die sie abfangen muss. Insbesondere Ransomware hat das Drehbuch neu geschrieben, denn wenn Ihre Backups aus der Produktionsumgebung erreichbar und beschreibbar sind, verschlüsselt ein Angreifer auch diese. Fachleute bevorzugen heute unveränderliche und isolierte Backups, segmentierte Wiederherstellungsumgebungen und Clean-Room-Neuaufbauten, damit die Wiederherstellung nicht einfach erneut infiziert. Cloud und Infrastructure-as-Code haben manche Wiederherstellung schneller automatisierbar gemacht, sie führen jedoch eigene Single Points of Failure auf Ebene der Region, des Kontos und der Identität ein. Die Disziplin ist dieselbe wie eh und je: Kennen Sie Ihre Ziele, schützen Sie Ihre Daten, damit sie den Notfall überstehen, schreiben Sie ein Runbook, dem jemand folgen kann, und weisen Sie nach, dass es funktioniert, bevor Sie es brauchen. --- ## Distributed Denial of Service (DDoS) **URL:** https://cyberacademy.net/de/resources/encyclopedia/ddos **Last reviewed:** 2026-06-24 DDoS is the attack that floods a service from many sources to exhaust capacity. Volumetric, protocol or application layer. Mitigation has commoditised (Cloudflare, Akamai, AWS Shield). The risk question is no longer "can we block it" but "are critical services routed through the protection, including the API ones we never see in dashboards". ## Was ein Distributed-Denial-of-Service-Angriff tatsächlich bewirkt Ein Denial-of-Service-Angriff hat ein einziges Ziel: einen Dienst für diejenigen unerreichbar zu machen, die auf ihn angewiesen sind. Die verteilte Variante, DDoS, erreicht dies, indem der Datenverkehr gleichzeitig von vielen Maschinen ausgeht, oft einem Botnetz aus kompromittierten Geräten, gekaperten Servern oder gemieteter Angriffsinfrastruktur. Da die Last von Tausenden unterschiedlicher Adressen eintrifft, lässt sich nicht einfach ein einzelner Verursacher blockieren, und es ist die schiere Zahl der Quellen, die es dem Angreifer erlaubt, eine Kapazität zu überlasten, die eine einzelne Maschine niemals erreichen könnte. Das Ziel muss weder kompromittiert werden noch einen Datendiebstahl erleiden. Es muss lediglich offline genommen werden, was DDoS zu einem Angriff auf die Verfügbarkeit macht und nicht auf die Vertraulichkeit oder Integrität. Fachleute ordnen DDoS üblicherweise drei Schichten zu, denn die Schicht bestimmt die Abwehr. Volumetrische Angriffe versuchen, die Bandbreite der Verbindung selbst zu sättigen, häufig mittels Amplifikation, bei der eine kleine gefälschte Anfrage eine große, auf das Opfer gerichtete Antwort auslöst. Protokollangriffe erschöpfen den Zustand in Netzwerkgeräten und Servern, etwa indem sie halb offene Verbindungen hinterlassen, die nie abgeschlossen werden. Angriffe auf der Anwendungsschicht sind die leisesten: Sie senden Anfragen, die legitim aussehen, etwa wiederholte Aufrufe an einen Such-Endpunkt oder eine Anmeldeseite, und erschöpfen die Anwendung statt der Leitung. Die letzte Kategorie lässt sich am schwersten von echten Nutzern unterscheiden. ## Warum die Abwehr nicht mehr der schwierige Teil ist DDoS-Verkehr zu stoppen ist zur Standardware geworden. Große Anbieter wie Cloudflare, Akamai und AWS Shield absorbieren Angriffe am Rand riesiger Netze, fangen volumetrische Fluten weit oberhalb des Kunden ab und filtern Protokoll- und Anwendungsmissbrauch durch Scrubbing und Ratenbegrenzung. Für die meisten Organisationen erhält die technische Frage, ob ein Angriff blockiert werden kann, ein selbstbewusstes Ja, sofern der Datenverkehr über diesen Schutz geleitet wird. Die schwierigere Frage, und diejenige, die eine Risikofunktion stellen sollte, ist eine der Abdeckung statt der Fähigkeit. Die Lücke, die schmerzt, ist das Asset, das niemand über den Schutzschild geleitet hat. Eine öffentliche Marketing-Website sitzt hinter dem CDN, doch die API, die die mobile App aufruft, die übernommene Ursprungs-IP, die nie außer Betrieb genommen wurde, der Partner-Integrations-Endpunkt oder der von einem anderen Team hochgefahrene regionale Dienst können direkt zum Ursprung auflösen und den Schutz vollständig umgehen. Angreifer finden diese direkten Pfade und zielen darauf. Eine wirksame DDoS-Abwehr ist daher zuerst ein Inventar- und Routing-Problem: jeden mit dem Internet verbundenen Dienst zu kennen, zu bestätigen, dass jeder tatsächlich hinter der Abwehr liegt, und nachzuweisen, dass der Ursprung nicht an ihr vorbei erreichbar ist. > **Die ungeschützte API ist die eigentliche Gefährdung** Die Abwehr funktioniert nur für Datenverkehr, der durch sie hindurchfließt. Die Dienste, die eine Organisation lahmlegen, sind meist diejenigen, die man nie in einem Dashboard sieht: eine direkte Ursprungs-IP, ein API-Endpunkt oder eine vergessene Subdomain, die am Schutz vorbei auflöst. Kartieren Sie jedes mit dem Internet verbundene Asset und weisen Sie dann nach, dass jedes über den Schutzschild geleitet wird. ## Wo DDoS in Kontinuität und Standards einzuordnen ist Da DDoS die Verfügbarkeit angreift, gehört es in dieselbe Diskussion wie das Business-Continuity-Management. Ein an ISO/IEC 27001 ausgerichtetes Informationssicherheits-Managementsystem behandelt die Verfügbarkeit als eine der drei Eigenschaften, die es schützt, und ein Denial-of-Service-Szenario ist eine lehrbuchmäßige Eingabe für eine Business-Impact-Analyse: Wie lange kann jeder Dienst ausfallen, was hängt von ihm ab und was ist die Rückfalllösung. Die Antwort ist selten eine einzelne Maßnahme. Sie kombiniert vorgelagerte Abwehr, ein Incident-Response-Runbook mit namentlich benannten Ansprechpartnern beim Abwehranbieter und Kontinuitätsvorkehrungen für den Zeitraum, in dem ein Angriff absorbiert wird. Was Fachleute tatsächlich tun, über den Kauf von Abwehr hinaus, ist proben und verifizieren. Sie führen ein genaues Inventar der mit dem Internet verbundenen Dienste, bestätigen, dass jeder hinter dem Schutz liegt, und testen, dass der Ursprung nicht direkt erreichbar ist. Sie justieren Ratenbegrenzungen und Challenge-Seiten gegen Missbrauch auf der Anwendungsschicht, da diese Angriffe echten Datenverkehr nachahmen und nicht allein mit Bandbreite gelöst werden können. Sie schreiben den Eskalationspfad vor einem Vorfall, damit während einer Flut niemand nach der richtigen Telefonnummer sucht. Und sie behandeln ein DDoS-Ereignis als Kontinuitätsübung, mit klaren Schwellenwerten, um den Plan auszulösen, mit Kunden zu kommunizieren und die Dienste wieder hochzufahren, sobald der Datenverkehr abebbt. --- ## EBIOS Risk Manager (EBIOS RM) **URL:** https://cyberacademy.net/de/resources/encyclopedia/ebios-rm **Last reviewed:** 2026-06-24 EBIOS Risk Manager ist die Cyber-Risiko-Methode von ANSSI mit Fokus auf strategische Angriffsszenarien. Sie ordnet Geschäftsprozesse den Zielen von Angreifern zu und leitet daraus die technischen Kontrollen ab. Im französischen öffentlichen Sektor und bei Betreibern kritischer Infrastrukturen ist sie Standard. Für das Board eignet sie sich hervorragend, um zu zeigen, WARUM ein bestimmtes Szenario relevant ist; in multinationalen Privatsektor-Audits ist sie weniger verbreitet. ## Was EBIOS Risk Manager tatsächlich leistet EBIOS Risk Manager ist die Methode zur Bewertung von Cyberrisiken, die von ANSSI, der französischen nationalen Cybersicherheitsbehörde, gepflegt wird. Ihr prägendes Merkmal ist, beim Angreifer anzusetzen und nicht bei einer Liste von Werten. Anstatt jeden Server zu katalogisieren und zu fragen, was bei jedem einzelnen schiefgehen könnte, fragt die Methode, wer der Organisation schaden wollte, was er erreichen möchte und welche Geschäftsmissionen er dafür ins Visier nehmen würde. Die technischen Maßnahmen kommen zuletzt und werden aus den Szenarien abgeleitet, statt den Ausgangspunkt zu bilden. Diese umgekehrte Logik macht EBIOS RM vor einem Vorstand nützlich. Ein klassisches, von unten nach oben aufgebautes Risikoregister erzeugt Hunderte von Einträgen, die für Führungskräfte kaum Bedeutung haben. EBIOS RM erzeugt eine Handvoll strategischer Szenarien, etwa einen staatlich geförderten Akteur, der einen kritischen Dienst stört, oder einen Wettbewerber, der Konstruktionsdaten exfiltriert, jeweils an eine konkrete Geschäftsmission gebunden. Diese Einordnung beantwortet die Frage, die Führungskräfte tatsächlich stellen: Warum betrifft uns diese konkrete Bedrohung, und was würde sie uns kosten, wenn sie einträte. ## Die fünf Workshops EBIOS RM ist als Abfolge von Workshops strukturiert, von denen jeder auf dem vorherigen aufbaut. Die Methode ist bewusst kooperativ: Sie bringt Fachverantwortliche, Risikospezialisten und Sicherheitsteams in denselben Raum, statt die Analyse einem einzelnen Analysten zu überlassen. 1. Geltungsbereich und Sicherheitsbasis. Den geschäftlichen und technischen Perimeter definieren, die Missionen und befürchteten Ereignisse identifizieren und die bestehende Sicherheitsbasis gegen das Erwartete bewerten. 1. Risikoquellen. Die Risikoquellen und ihre angestrebten Ziele identifizieren, die Paarung aus wer angreifen könnte und was er will, und anschließend die relevantesten priorisieren. 1. Strategische Szenarien. Das Ökosystem aus Partnern, Lieferanten und Stakeholdern abbilden, bewerten, wie ein Angreifer die Organisation über sie erreichen könnte, und übergeordnete Angriffspfade aufbauen. 1. Operative Szenarien. Die strategischen Szenarien in konkrete technische Angriffssequenzen übersetzen und beschreiben, wie sich ein Angreifer tatsächlich durch die Systeme bewegen würde. 1. Risikobehandlung. Die Sicherheitsmaßnahmen festlegen, den Behandlungsplan erstellen und das Restrisiko dokumentieren, das die Leitung formell akzeptiert. > **Szenariengetrieben, nicht wertgetrieben** EBIOS RM leitet Maßnahmen aus realistischen Angriffsszenarien ab und nicht aus einer erschöpfenden Bestandsaufnahme der Werte. Das hält die Analyse auf die Bedrohungen fokussiert, die für das Geschäft wirklich von Bedeutung sind, und gibt der Leitung eine vertretbare Grundlage, um das Restrisiko zu akzeptieren oder zu behandeln. ## Wo sie passt und wo nicht EBIOS RM ist die Standardmethode im französischen öffentlichen Sektor und bei Betreibern von vitaler Bedeutung, wo die regulatorischen Erwartungen auf die Leitlinien der ANSSI verweisen. Sie wird auch in französischsprachigen Organisationen breit gelehrt und eingesetzt. Außerhalb dieses Kontexts, bei multinationalen Audits im Privatsektor, werden Sie weitaus eher ISO 27005 antreffen, die internationale Norm für das Management von Informationssicherheitsrisiken, die per Konzeption methodenunabhängig ist. Die beiden sind eher komplementär als konkurrierend. ISO 27005 beschreibt einen generischen Risikomanagementprozess, der mit ISO 27001 und ISO 31000 abgestimmt ist, schreibt aber keine einzelne Technik vor. EBIOS RM ist eine konkrete, anerkannte Art, diesen Prozess durchzuführen, und ANSSI positioniert sie als kompatibel mit dem ISO-Ansatz. Ein Team kann EBIOS-RM-Workshops durchführen und die Ergebnisse dennoch in ISO-27005-Begriffen berichten. **EBIOS Risk Manager im Vergleich zu ISO 27005** | Aspekt | EBIOS Risk Manager | ISO 27005 | | --- | --- | --- | | Ursprung | ANSSI (Frankreich) | Internationale ISO/IEC-Norm | | Charakter | Vorschreibende Methode mit definierten Workshops | Methodenunabhängige Leitlinien für das Risikomanagement | | Ausgangspunkt | Angreiferziele und Geschäftsmissionen | Werte, Bedrohungen und Schwachstellen | | Typischer Kontext | Französischer öffentlicher Sektor, Betreiber von vitaler Bedeutung | Internationale ISMS-Audits im Privatsektor | In der Praxis signalisiert die Kenntnis von EBIOS RM Vertrautheit mit dem ANSSI-Ökosystem, und die Kenntnis von ISO 27005 signalisiert Vertrautheit mit der Welt der internationalen Normen. Risikofachleute, die über europäische und französische Märkte hinweg arbeiten, profitieren davon, beide zu verstehen, denn die Methode, zu der man greift, hängt davon ab, wer den Bericht liest. --- ## EU AI Act (AI Act) **URL:** https://cyberacademy.net/de/resources/encyclopedia/ai-act **Last reviewed:** 2026-06-24 Der AI Act ist die weltweit erste umfassende KI-Regulierung. Vier Risikostufen: inakzeptabel (verboten), hoch (umfangreiche Pflichten und Konformitätsbewertung), begrenzt (Transparenz), minimal. Gilt in Phasen bis August 2027. Kombinieren Sie ihn mit ISO 42001, wenn Sie eine Managementsystem-Lösung statt einer Checkliste suchen. Die GPAI-Modellregeln kommen noch hinzu. ## Ein risikobasiertes Gesetz, kein Technologieverbot Der EU AI Act reguliert künstliche Intelligenz danach, was ein System tut und wen es betreffen kann, nicht nach dem zugrunde liegenden Algorithmus. Dieselbe Technik des maschinellen Lernens kann in einem Kontext unreguliert und in einem anderen streng kontrolliert sein. Das ist der Kerngedanke der vier Risikostufen: inakzeptable Praktiken sind unmittelbar verboten, Hochrisikosysteme tragen die schwersten Pflichten, Systeme mit begrenztem Risiko schulden den interagierenden Personen Transparenz, und Systeme mit minimalem Risiko bleiben weitgehend unberührt. Der größte Teil der alltäglich genutzten KI liegt in dieser Minimalstufe, weshalb der Act besser als gezielte Regulierung folgenreicher Anwendungen zu verstehen ist als als pauschales Lizenzregime für jede KI. Der Act ist eine Verordnung und gilt daher unmittelbar in jedem Mitgliedstaat, ohne dass ihn jedes Land in nationales Recht umsetzen muss. Seine Reichweite ist dem Geist nach auch extraterritorial: Anbieter und Betreiber außerhalb der EU fallen in den Anwendungsbereich, wenn ihr KI-System auf dem EU-Markt in Verkehr gebracht wird oder seine Ausgaben in der Union verwendet werden. Praktiker sollten ihre Systeme früh den Stufen zuordnen, denn die Einstufung bestimmt alles Weitere, von der Dokumentation bis zur Konformitätsbewertung. ## Wo die Pflichten tatsächlich greifen Nahezu das gesamte operative Gewicht entfällt auf Hochrisikosysteme. Dabei handelt es sich typischerweise um KI, die in regulierten Produkten oder in sensiblen Bereichen wie kritischer Infrastruktur, Beschäftigung, Zugang zu wesentlichen Diensten, Strafverfolgung und Rechtspflege eingesetzt wird. Für diese erwartet der Act einen funktionierenden Satz an Disziplinen statt eines einmaligen Formulars: ein über den Lebenszyklus gepflegtes Risikomanagementsystem, Daten-Governance für Trainings- und Testdaten, technische Dokumentation, Protokollierung, Transparenz und Gebrauchsanweisungen, menschliche Aufsicht, die ein sinnvolles Eingreifen einer Person ermöglicht, sowie ein angemessenes Maß an Genauigkeit, Robustheit und Cybersicherheit. Bevor ein Hochrisikosystem auf den Markt gelangt, muss es eine Konformitätsbewertung bestehen, und die Anbieter führen nach der Inbetriebnahme eine Beobachtung nach dem Inverkehrbringen durch. > **Anbieter und Betreiber sind nicht dieselbe Rolle** Der Act teilt die Pflichten auf zwischen dem Anbieter, der das System entwickelt oder in Verkehr bringt, und dem Betreiber, der es unter eigener Verantwortung nutzt. Eine Bank, die ein Kredit-Scoring-Modell eines Dritten einsetzt, trägt Betreiberpflichten wie menschliche Aufsicht und Überwachung, während der Anbieter die Anbieterpflichten trägt. Zu wissen, welchen Hut man trägt, entscheidet, welche Pflichten die eigenen sind. ## GPAI, Transparenz und der gestufte Zeitplan Über den Stufen steht ein gesondertes Regime für KI-Modelle mit allgemeinem Verwendungszweck, die Basismodelle, die viele nachgelagerte Anwendungen antreiben. Anbieter von GPAI unterliegen Transparenz- und Dokumentationspflichten, mit strengeren Anforderungen für die leistungsfähigsten Modelle, denen ein systemisches Risiko zugeschrieben wird. Diese Ebene wurde gerade deshalb hinzugefügt, weil ein einziges Modell mit allgemeinem Verwendungszweck in unzählige Hochrisiko- und Anwendungen mit begrenztem Risiko einfließen kann, sodass eine Regulierung allein der Endanwendung eine Lücke hinterließe. Pflichten bei begrenztem Risiko sind leichter, aber real. Sie konzentrieren sich auf Transparenz: Menschen sollten wissen, wann sie mit einem KI-System interagieren, und bestimmte synthetische oder manipulierte Inhalte sollten als künstlich erzeugt gekennzeichnet werden. Der Act tritt in Kraft und gilt in Phasen, wobei Verbote, GPAI-Regeln und Hochrisikopflichten zu unterschiedlichen Zeitpunkten bis 2027 in Kraft treten, was Organisationen eine Anlaufzeit gibt, aber auch eine Abfolge harter Fristen, auf die hin zu planen ist. ## Wie Praktiker es operationalisieren In der Praxis ist der Act eine Checkliste rechtlicher Pflichten, keine Managementmethode, daher koppeln Teams ihn an ein System, das diese Pflichten im Tagesgeschäft tragen kann. ISO/IEC 42001 ist die übliche Antwort: Ein KI-Managementsystem liefert die Risikobewertungen, die Daten-Governance, die Routinen der menschlichen Aufsicht und der Beobachtung nach dem Inverkehrbringen, die der Act erwartet, betrieben als wiederholbares System statt unter Termindruck improvisiert. Das NIST AI Risk Management Framework wird oft begleitend als freiwillige Struktur zur Identifizierung und Behandlung von KI-Risiken genutzt. Keines davon macht ein System für sich allein rechtlich konform. Sie machen Konformität erreichbar und prüfbar, was den Unterschied ausmacht zwischen dem Nachweis der gebotenen Sorgfalt und der Hoffnung, dass niemand fragt. --- ## Endpoint Detection and Response (EDR) **URL:** https://cyberacademy.net/de/resources/encyclopedia/edr **Last reviewed:** 2026-06-24 EDR ist die agentenbasierte Plattform, die Endpunkt-Aktivitäten aufzeichnet, verdächtiges Verhalten erkennt und Analysten ermöglicht, kompromittierte Hosts zu isolieren oder zu bereinigen. XDR erweitert die Sichtbarkeit auf Endpunkte, Netzwerk und Cloud; MDR ist die verwaltete Servicehülle. Der Endpunkt ist nach wie vor der häufigste Angriffsvektor; EDR ist heute eine Grundvoraussetzung, kein Differenzierungsmerkmal. ## Was EDR auf dem Host tatsächlich leistet Endpoint Detection and Response betreibt einen schlanken Agenten auf jeder Workstation, jedem Laptop und jedem Server, der Ihnen wichtig ist. Dieser Agent zeichnet fortlaufend auf, was das Betriebssystem tut: Prozesse, die gestartet werden, Befehlszeilen, die sie ausführen, Dateien, die geschrieben werden, Registry-Schlüssel, die sich ändern, Netzwerkverbindungen, die geöffnet werden, und Benutzersitzungen, die beginnen. Dieser Telemetriestrom ist das Herzstück von EDR. Wo das herkömmliche Antivirus eine einzige Frage stellte, «ist diese Datei als bösartig bekannt», stellt EDR eine schwierigere, «ist diese Verhaltensabfolge verdächtig», was es ihm erlaubt, dateilose Angriffe, Living-off-the-Land-Techniken und den Missbrauch legitimer Werkzeuge zu erkennen, die nie eine erkennbare Malware-Probe hinterlassen. Der «Response»-Teil ist das, was EDR von einem passiven Sensor unterscheidet. Wenn ein Host kompromittiert ist, kann ein Analyst von der Konsole aus handeln: die Maschine vom Netzwerk isolieren und dabei die Agentenverbindung am Leben halten, einen bösartigen Prozess beenden, eine Datei in Quarantäne stellen, forensische Artefakte sammeln oder Änderungen zurücksetzen. Diese Fähigkeit, einen einzelnen Endpunkt einzudämmen, ohne ihn physisch zu berühren, mitten in einem laufenden Vorfall, ist diejenige, auf die sich Praktiker am meisten verlassen. Die Telemetrie speist auch die Untersuchung, sodass die Einsatzkräfte die gesamte Kette der Handlungen eines Angreifers rekonstruieren können, statt nur die erste Phase zu blockieren. ## EDR, XDR und MDR: den Unterschied kennen Diese drei Akronyme werden nebeneinander verkauft und sind leicht zu verwechseln. Es handelt sich weniger um konkurrierende Produkte als um unterschiedliche Geltungsbereiche und Bereitstellungsmodelle, die um dieselbe Grundidee herum aufgebaut sind. **EDR vs XDR vs MDR** | Begriff | Geltungsbereich | Was es ist | | --- | --- | --- | | EDR | Nur Endpunkte | Die agentenbasierte Plattform, die auf Hosts aufzeichnet, erkennt und reagiert. Sie betreiben sie selbst. | | XDR | Endpunkt, Netzwerk, Cloud, Identität, E-Mail | Erweitert und korreliert die Erkennung über mehrere Ebenen hinweg, nicht nur den Endpunkt, um Angriffe zu sehen, die sich über mehrere Domänen erstrecken. | | MDR | Was auch immer der Anbieter abdeckt | Ein verwalteter Dienst: ein Team eines Dritten betreibt Erkennung und Reaktion in Ihrem Auftrag, häufig auf Basis von EDR oder XDR. | Die praktische Lesart ist unkompliziert. EDR ist die Technologie auf dem Host. XDR ist dieselbe Erkennungsphilosophie, erweitert, um Signale jenseits des Endpunkts aufzunehmen und zu korrelieren. MDR ist eine Outsourcing-Entscheidung: Sie kaufen die Analysten und die Rund-um-die-Uhr-Abdeckung, nicht nur das Werkzeug. Ein kleines Team ohne ein 24/7-SOC kombiniert EDR häufig mit einem MDR-Anbieter, damit Warnmeldungen um drei Uhr morgens gesichtet werden. ## Wo EDR in Ihrem Betrieb und Ihrem ISMS angesiedelt ist EDR arbeitet selten allein. Seine Erkennungen und seine Rohtelemetrie werden üblicherweise an ein SIEM weitergeleitet, um sie mit Protokollen von Firewalls, Identitätsanbietern und Anwendungen zu korrelieren, und die daraus resultierenden Warnmeldungen werden von einem SOC bearbeitet. In dieser Pipeline ist EDR der hochpräzise Sensor, der dem Ort am nächsten ist, an dem die meisten Eindringversuche beginnen, da der Endpunkt der häufigste Einstiegspunkt bleibt, durch Phishing, gestohlene Zugangsdaten und verwundbare Software. Aus Governance-Sicht ist EDR das, was mehrere Steuerungsziele real statt aspirativ werden lässt. Im Rahmen eines ISO/IEC 27001 ISMS unterstützt es Maßnahmen rund um den Schutz vor Schadsoftware, die Protokollierung, die Überwachung und die technische Seite des Vorfallmanagements, und es erzeugt die Nachweise, die ein Auditor zu sehen erwartet. Es untermauert zudem die Erkennungs- und Reaktionsfähigkeit, die Rahmenwerke wie das Cybersicherheits-Funktionsmodell des NIST und Regulierungen wie NIS2 und DORA bei einer Organisation voraussetzen. Die shortDefinition bringt es auf den Punkt: EDR ist inzwischen eine Grundvoraussetzung, kein Unterscheidungsmerkmal. > **Ein Werkzeug ist keine Fähigkeit** EDR auszurollen ist der einfache Teil. Der Wert entsteht aus der Abdeckung jedes Assets, aus abgestimmten Erkennungen und aus Menschen, die sichten und reagieren. Ein Agent, der auf der Hälfte der Flotte installiert ist und Warnmeldungen erzeugt, die niemand liest, bietet Sicherheit auf dem Papier und keine in der Praxis. --- ## Europäische Agentur für Cybersicherheit (ENISA) **URL:** https://cyberacademy.net/de/resources/encyclopedia/enisa **Last reviewed:** 2026-06-24 ENISA ist die EU-Cybersicherheitsbehörde mit Sitz in Athen. Sie unterstützt Mitgliedstaaten und EU-Institutionen in den Bereichen Cybersicherheitspolitik, operative Zusammenarbeit und den EU-Zertifizierungsrahmen. Operativ ist sie in die NIS 2-Kooperation, die Durchführungsstandards zu DORA sowie die Sicherheitsbasislinie des AI Act eingebunden. Ihr Bericht zur Bedrohungslage ist die meistzitierte jährliche Publikation in diesem Bereich. ## Was die ENISA tut und was nicht Die ENISA ist die Agentur der Europäischen Union für Cybersicherheit, die EU-Einrichtung mit der Aufgabe, das gemeinsame Cybersicherheitsniveau in der gesamten Union anzuheben. Mit Sitz in Athen arbeitet sie an der Seite der Mitgliedstaaten, der Europäischen Kommission und der EU-Institutionen und unterstützt Politik, operative Zusammenarbeit und Kapazitätsaufbau, statt selbst die nationale Verteidigung zu betreiben. Die Unterscheidung ist in der Praxis bedeutsam: Die ENISA untersucht keine Sicherheitsverletzungen, verhängt keine verbindlichen Bußgelder und beaufsichtigt keine einzelnen Unternehmen. Das tun die zuständigen nationalen Behörden und die Sektorregulierer. Die ENISA erstellt die Leitlinien, die Bedrohungsaufklärung und die technischen Grundlagen, auf die sich diese Behörden und die ihnen unterstellten regulierten Organisationen stützen. Eine nützliche Art, die ENISA einzuordnen, besteht darin, sie einer nationalen Agentur wie der französischen ANSSI gegenüberzustellen. Die ANSSI ist eine Behörde eines Mitgliedstaats mit operativen und regulatorischen Befugnissen innerhalb eines einzigen Landes. Die ENISA wirkt eine Ebene darüber, koordiniert über alle Mitgliedstaaten hinweg und gibt der EU einen einheitlichen technischen Referenzpunkt, damit siebenundzwanzig nationale Ansätze nicht auseinanderdriften. Wenn ein französischer CISO beide anführt, ist die ANSSI die Behörde, der er Rechenschaft schuldet, und die ENISA die EU-weite Quelle, an der er sich ausrichtet. ## Wo die ENISA die Vorschriften berührt, die Sie einhalten müssen Für eine GRC-Fachkraft ist die ENISA keine Abstraktion. Sie taucht direkt in den Texten auf, in deren Anwendungsbereich Sie fallen. Im Rahmen von NIS 2 unterstützt die ENISA die Kooperationsmechanismen zwischen den Mitgliedstaaten, pflegt ein gemeinsames Lagebild und trägt zu den technischen Leitlinien bei, die wesentlichen und wichtigen Einrichtungen helfen, ihre Sicherheits- und Meldepflichten bei Vorfällen einheitlich auszulegen. Im Rahmen von DORA trägt die ENISA zu den technischen Durchführungs- und Regulierungsstandards bei, die die übergeordneten Anforderungen der Verordnung für Finanzunternehmen in konkrete Erwartungen übersetzen. Und während die Sicherheitsbestimmungen des AI Act Gestalt annehmen, ist die ENISA in der Lage, mitzubestimmen, welches Cybersicherheits-Grundniveau von KI-Systemen mit hohem Risiko erwartet wird. - NIS 2: grenzüberschreitende Zusammenarbeit, Lagebild und technische Leitlinien für wesentliche und wichtige Einrichtungen. - DORA: Beitrag zu den technischen Standards, die die digitale operationale Resilienz für Finanzunternehmen operationalisieren. - EU Cybersecurity Act: Die ENISA betreibt den europäischen Rahmen für die Cybersicherheitszertifizierung und entwickelt Schemata, mit denen Produkte, Dienste und Prozesse einmal zertifiziert und in der gesamten Union anerkannt werden können. > **Der Zertifizierungsrahmen ist der konkreteste Hebel der ENISA** Der Cybersecurity Act verlieh der ENISA ein dauerhaftes Mandat und beauftragte sie mit dem Aufbau EU-weiter Zertifizierungsschemata. Statt dass ein Anbieter ein Produkt in jedem Land separat zertifiziert, erzeugt ein einziges Schema ein Zertifikat, das in allen Mitgliedstaaten anerkannt wird. Dies ist der Teil der Arbeit der ENISA, der am ehesten in einem Beschaffungs- oder Assurance-Gespräch auftaucht. ## Das Ergebnis, das Fachleute tatsächlich lesen Die ENISA veröffentlicht umfangreich, doch ihr jährlicher Threat-Landscape-Bericht ist die mit Abstand meistzitierte Arbeit, das Referenzdokument, zu dem Teams greifen, wenn sie eine autoritative, EU-weite Sicht darauf benötigen, wie sich die Bedrohungslage über die Sektoren hinweg entwickelt. Fachleute nutzen ihn, um ihre eigenen Risikobewertungen auf Plausibilität zu prüfen, um Vorstände mit einer unabhängigen, gesamteuropäischen Quelle zu informieren und um Kontrollprioritäten gegenüber Prüfern und Regulierern zu begründen. Daneben veröffentlicht die ENISA sektorspezifische Leitlinien, Leitfäden für bewährte Verfahren und die technischen Grundlagen hinter den Zertifizierungsschemata. Die praktische Erkenntnis lautet, die ENISA als Autoritätsquelle zu behandeln und nicht als Stelle, der Sie Bericht erstatten. Sie reichen bei der ENISA nichts ein. Sie richten Ihre Risikosprache, Ihre Kontrollgrundlagen und Ihre Bedrohungsannahmen an dem aus, was sie veröffentlicht, denn das ist die Referenz, die auch Ihre nationale Behörde, Ihr Prüfer und zunehmend Ihr Regulierer lesen. --- ## Französische Nationale Behörde für Cybersicherheit (ANSSI) **URL:** https://cyberacademy.net/de/resources/encyclopedia/anssi **Last reviewed:** 2026-06-24 ANSSI ist die französische nationale Behörde für Cybersicherheit, die seit 2009 dem Premierminister unterstellt ist. Als nationale Behörde für Cybersicherheitspolitik in Frankreich qualifiziert sie Produkte und Dienstleister, veröffentlicht EBIOS Risk Manager und fungiert als zuständige Behörde für die Umsetzung von NIS 2. Ihre Qualifizierungen (SecNumCloud, PVID, PASSI) gelten als Goldstandard im französischen öffentlichen Sektor. ## Was die ANSSI tut Die ANSSI (Agence nationale de la securite des systemes d'information) ist die nationale Cybersicherheitsbehoerde Frankreichs. Sie ist dem Generalsekretariat fuer Verteidigung und nationale Sicherheit unterstellt, das dem Premierminister untersteht, wodurch sie bewusst von Nachrichtendiensten und Strafverfolgungsbehoerden getrennt bleibt. Diese Trennung ist in der Praxis von Bedeutung: Die ANSSI ist von Grund auf defensiv ausgerichtet, sodass Organisationen ihr Vorfallsdetails mitteilen koennen, ohne befuerchten zu muessen, dass dieselbe Behoerde zugleich mit offensiven Operationen oder Strafverfolgung betraut ist. Ihr Aufgabenbereich ist breit. Sie legt die nationale Cybersicherheitspolitik und -doktrin fest, betreibt das operative CERT-FR fuer die Reaktion auf Vorfaelle und die Bedrohungsaufklaerung, beaufsichtigt Betreiber von vitaler Bedeutung und wesentliche Einrichtungen und veroeffentlicht Leitfaeden und Methoden, die der Rest des franzoesischen Oekosystems als Referenzmaterial behandelt. EBIOS Risk Manager, die Risikoanalysemethode, die viele franzoesische Organisationen verwenden, um die Bedrohungsszenarien hinter ihrem Sicherheitsprogramm zu erstellen, wird von der ANSSI gepflegt und nicht von einer privaten Normungsstelle. ## Qualifizierungen und Visa Der Teil der ANSSI, mit dem die meisten Fachleute unmittelbar zu tun haben, ist ihr Qualifizierungssystem. Anstatt nur Regeln zu schreiben, prueft die ANSSI Produkte und Dienstleister anhand veroeffentlichter Anforderungen und erteilt eine Qualifizierung oder ein Sicherheitsvisum. Diese Kennzeichen haben echtes Gewicht, weil der oeffentliche Sektor und regulierte Betreiber sie haeufig per Vorgabe verlangen. - SecNumCloud qualifiziert Cloud-Dienstleister anhand einer anspruchsvollen Sicherheits- und Souveraenitaetsgrundlage und wird zunehmend als Massstab fuer sensible Workloads des oeffentlichen Sektors genannt. - PASSI qualifiziert Anbieter von Sicherheitsaudits (Penetrationstests, Konfigurationspruefung, Architekturaudit), damit ein Kaeufer weiss, dass der Auditor anhand eines gemeinsamen Standards bewertet wurde. - PVID deckt Anbieter der Fernidentitaetspruefung ab, wie sie in Onboarding-Prozessen verwendet werden, die Deepfakes und Dokumentenbetrug standhalten muessen. > **Warum die Kennzeichen wichtig sind** Eine SecNumCloud- oder PASSI-Qualifizierung ist kein Marketingabzeichen. Fuer franzoesische Verwaltungen und Betreiber von vitaler Bedeutung ist sie haeufig eine Beschaffungsvoraussetzung, sodass ihr Verlust oder Fehlen einen Anbieter aus ganzen Ausschreibungen ausschliessen kann. ## Die ANSSI im Vergleich zur ENISA und das NIS-2-Bild Es ist leicht, die ANSSI mit der ENISA zu verwechseln, doch sie sind auf unterschiedlichen Ebenen angesiedelt. Die ANSSI ist die nationale Behoerde eines Mitgliedstaats, Frankreichs. Die ENISA ist die Agentur der Europaeischen Union, die alle Mitgliedstaaten unterstuetzt und den EU-Rahmen fuer die Cybersicherheitszertifizierung betreibt. Sie kooperieren, doch die ANSSI ist die Stelle, die franzoesische Einrichtungen tatsaechlich beaufsichtigt und als zustaendige Behoerde handeln kann, wenn EU-Vorschriften in franzoesisches Recht umgesetzt werden. NIS 2 ist das deutlichste Beispiel. Die Richtlinie ist europaeisch, muss aber national umgesetzt und durchgesetzt werden. In Frankreich ist die ANSSI als die zustaendige Behoerde positioniert, die festlegt, welche Einrichtungen in den Anwendungsbereich fallen, Erwartungen an das Risikomanagement und die Meldung von Vorfaellen formuliert und die Einhaltung ueberwacht. Wenn sich also eine franzoesische wesentliche oder wichtige Einrichtung fragt, wen sie nach einem erheblichen Vorfall benachrichtigen muss, fuehrt die operative Antwort ueber die ANSSI und das CERT-FR und nicht direkt nach Bruessel. Fuer eine Sicherheits- oder GRC-Fachkraft ist die praktische Erkenntnis, die ANSSI als drei Dinge zugleich zu betrachten: eine Politikbehoerde, an deren Leitlinien Sie sich ausrichten, eine Qualifizierungsstelle, deren Kennzeichen Ihre Lieferanten- und Werkzeugentscheidungen praegen, und einen nationalen Regulierer und Partner fuer die Reaktion auf Vorfaelle, mit dem Sie im Rahmen von NIS 2 zu tun haben werden. --- ## ISO 19011 (ISO 19011) **URL:** https://cyberacademy.net/de/resources/encyclopedia/iso-19011 **Last reviewed:** 2026-06-24 ISO 19011 ist die Leitliniennorm für die Auditierung von Managementsystemen. Generisch anwendbar – gilt gleichermaßen für Audits nach ISO 27001, 9001 und 22301. Die Norm definiert Auditprinzipien, Auditprogrammmanagement, den Auditzyklus und die Auditorkompetenz. Der Lead Auditor-Kurs vermittelt diese Inhalte; die Auditoren, denen Sie in der Praxis begegnen, wurden auf dieser Grundlage ausgebildet. ## Was die ISO 19011 tatsächlich abdeckt Die ISO 19011 ist das Referenzdokument für alle, die Audits von Managementsystemen planen, durchführen oder leiten. Sie ist bewusst generisch gehalten, sodass dieselben Grundsätze gelten, ob Sie ein Informationssicherheits-Managementsystem gegen die ISO 27001, ein Qualitätssystem gegen die ISO 9001 oder die Geschäftskontinuität gegen die ISO 22301 auditieren. Statt Ihnen die Anforderungen zu nennen, die eine Organisation erfüllen muss, erklärt sie Ihnen, wie Sie diese Anforderungen als Auditor betrachten : wie Sie ein Auditprogramm aufbauen, wie Sie ein einzelnes Audit von der Eröffnungs- bis zur Abschlussbesprechung durchführen und wie Sie beurteilen, ob die Personen, die das Audit durchführen, kompetent sind. Die Norm gliedert das Auditieren um einen kleinen Satz von Grundsätzen. Integrität und faire Darstellung halten die Feststellungen ehrlich. Berufliche Sorgfalt und Vertraulichkeit schützen die beteiligten Personen und Informationen. Ein evidenzbasierter Ansatz bedeutet, dass Schlussfolgerungen auf überprüfbaren Aufzeichnungen und Beobachtungen beruhen, nicht auf Eindrücken ; und das in den jüngsten Revisionen ergänzte risikobasierte Denken drängt Auditoren dazu, ihren Aufwand dort zu konzentrieren, wo er für die Ziele am wichtigsten ist. ## Auditprogramm, Auditzyklus und Kompetenz Eine nützliche Art, die ISO 19011 zu lesen, ist sie als drei ineinander verschachtelte Ebenen zu verstehen. An der Spitze steht das Auditprogramm, die Gesamtheit der über einen Zeitraum geplanten Audits und die Steuerung dieses Programms : Ziele festlegen, Ressourcen zuweisen, Ergebnisse überwachen und sich im Laufe der Zeit verbessern. Darin liegt das einzelne Audit und sein Zyklus : - Das Audit veranlassen und die Durchführbarkeit mit der auditierten Organisation bestätigen. - Die Auditaktivitäten vorbereiten, einschließlich Dokumentenprüfung und Auditplan. - Das Audit vor Ort oder remote durchführen : Eröffnungsbesprechung, Sammeln und Überprüfen von Nachweisen, Erstellen von Feststellungen. - Berichten, einschließlich der Schlussfolgerungen und der Abschlussbesprechung. - Das Audit abschließen und etwaige Folgemaßnahmen zu Korrekturmaßnahmen durchführen. Die dritte Ebene ist die Kompetenz des Auditors. Die ISO 19011 fasst Kompetenz als eine Kombination aus persönlichem Verhalten, generischem Auditwissen und -können sowie disziplinspezifischem Wissen auf und beschreibt anschließend, wie sie zu bewerten und aufrechtzuerhalten ist. Deshalb kann ein Sicherheitsfachmann die Norm nicht einfach einmal lesen. Kompetenz ist etwas, das man durch Schulung, beobachtete Audits und kontinuierliche Praxis aufbaut. > **Leitfaden, keine Zertifizierung** Die ISO 19011 ist eine Leitfadennorm, daher werden Sie nicht gegen sie zertifiziert, so wie eine Organisation gegen die ISO 27001 zertifiziert wird. Wenn Sie ein Managementsystem zertifizieren, arbeitet die Zertifizierungsstelle nach der ISO/IEC 17021-1, die auf denselben Auditkonzepten beruht. ## Wo Praktiker ihr begegnen In der Praxis begegnen Sie der ISO 19011 in zwei Rollen. Als auditierte Organisation erklärt sie, was ein kompetenter Auditor tun und nicht tun wird, was Ihnen hilft, Nachweise vorzubereiten und schwache Feststellungen zu hinterfragen. Als Auditor, intern oder gegenüber Lieferanten, ist sie das Handbuch, dem Sie folgen, um Audits wiederholbar und belastbar zu machen. Der Lead-Auditor-Kurs vermittelt diese Norm zusammen mit den Anforderungen des auditierten Systems, und die externen Auditoren, denen Sie während der Zertifizierung begegnen, wurden mit demselben Material geschult. --- ## ISO 22301 (ISO 22301) **URL:** https://cyberacademy.net/de/resources/encyclopedia/iso-22301 **Last reviewed:** 2026-06-24 ISO 22301 ist die internationale Norm für Business Continuity Management Systeme (BCMS). Sie legt die Anforderungen fest, um ein BCMS zu planen, zu betreiben, zu überwachen und zu verbessern, das kritische Betriebsabläufe nach einer Störung wiederherstellt. Seit DORA wird sie von Finanzaufsichtsbehörden zunehmend gefordert, ebenso von NIS 2-Aufsichtsbehörden für Betreiber wesentlicher Dienste. ## Was ISO 22301 tatsächlich verlangt ISO 22301 ist die Anforderungsnorm für ein Business-Continuity-Managementsystem, ein BCMS. Das Wort System ist entscheidend. Es ist kein Plan, den man einmal schreibt und ablegt, sondern ein gesteuerter Kreislauf: Sie verstehen, was Ihre Organisation tut, entscheiden, welche Aktivitäten Sie sich nicht leisten können, lange zu verlieren, bauen die Fähigkeit auf, sie am Laufen zu halten oder schnell wiederherzustellen, und halten diese Fähigkeit dann durch Übungen, Überprüfungen und Verbesserungen verlässlich. Da es sich um eine Anforderungsnorm handelt, kann eine Organisation von einer akkreditierten Stelle danach auditiert und zertifiziert werden, und genau das gibt einem Kunden oder einer Aufsichtsbehörde etwas Konkretes, dem sie vertrauen kann. Wie ISO 27001 und die anderen modernen ISO-Managementsystemnormen folgt ISO 22301 der High-Level Structure. Das bedeutet, sie teilt dasselbe Gerüst: Kontext der Organisation, Führung, Planung, Unterstützung, Betrieb, Bewertung der Leistung und Verbesserung, alles auf einem Plan-Do-Check-Act-Zyklus. In der Praxis ist das ein Geschenk, denn wenn Sie bereits ein Informationssicherheits-Managementsystem betreiben, nutzen Sie dieselbe Governance, dieselbe Risikosprache, dieselbe interne Auditmaschinerie wieder und setzen die Kontinuität obendrauf, anstatt eine parallele Struktur aufzubauen. ## Die Arbeit hinter dem Zertifikat Drei Aktivitäten stehen im Zentrum eines ISO-22301-Programms, und ein Praktiker verbringt den Großteil seiner Zeit hier statt mit der Dokumentation: - Business-Impact-Analyse. Die BIA identifiziert Ihre priorisierten Aktivitäten und ermittelt, wie schnell jede einzelne wieder verfügbar sein muss. Sie ist es, die die Wiederanlaufzeitziele erzeugt, die jede spätere Entscheidung steuern. Ohne eine belastbare BIA ist Ihre Kontinuitätsstrategie reine Mutmaßung. - Risikobeurteilung. Sie betrachten, was diese priorisierten Aktivitäten stören könnte, von einem Ransomware-Ausbruch über das Versagen eines Lieferanten bis zu einem überfluteten Rechenzentrum, damit Ihre Strategie reale Bedrohungen adressiert statt einer generischen Checkliste. - Kontinuitätsstrategie und -pläne. Auf Grundlage der BIA und des Risikobilds wählen Sie, wie jede Aktivität geschützt und wiederhergestellt wird, und schreiben und ressourcieren dann die Verfahren, denen die Menschen tatsächlich folgen, wenn das Licht ausgeht. > **Kontinuität ist breiter als IT-Wiederherstellung** ISO 22301 deckt die gesamte Organisation ab, nicht nur die Systeme. Menschen, Standorte, Lieferanten und Prozesse zählen alle. Die IT-Notfallwiederherstellung ist eine Eingabe in die Kontinuität, der Teil, der die Technik wiederherstellt, doch das BCMS stellt eine weiter gefasste Frage: Kann das Unternehmen seine kritischen Produkte und Dienstleistungen weiterhin liefern, mit welchen Mitteln auch immer, während die technische Wiederherstellung läuft. ## Warum Aufsichtsbehörden zunehmend darauf verweisen ISO 22301 war einst eine unauffällige Norm zur operativen Resilienz, die reife Organisationen freiwillig übernahmen. Das hat sich geändert. Wie die shortDefinition anmerkt, erwarten Finanzaufseher, die sich auf DORA stützen, und Aufsichtsbehörden, die NIS 2 durchsetzen, nun eine nachweisbare Kontinuitätsfähigkeit für kritische Betriebsabläufe, und ISO 22301 ist die anerkannteste Art, dies zu belegen. Die Norm nennt keine bestimmte Regulierung, doch ihre Disziplin, priorisierte Aktivitäten, definierte Wiederherstellungsziele, getestete Pläne, abgebildete Abhängigkeiten, deckt sich genau mit dem, was diese Regime verlangen. Eine Zertifizierung danach erlaubt einer Organisation, einer Aufsichtsbehörde mit einer unabhängigen Bestätigung statt mit einer Selbstbewertung zu antworten. Ein häufiger Punkt der Verwirrung ist das Verhältnis zu ISO 27001. Sie sind Geschwister, keine Ersatzstücke. ISO 27001 regelt die Informationssicherheit und schützt Vertraulichkeit, Integrität und Verfügbarkeit von Informationen. ISO 22301 regelt die Kontinuität und hält das Unternehmen durch die Störung hindurch am Laufen. Die Verfügbarkeit ist die Brücke: Eine Organisation, die es mit der Resilienz ernst meint, betreibt oft beide, zertifiziert sie gemeinsam, um Audits und Managementbewertungen zu teilen, und behandelt die Kontinuität als die Antwort auf die Frage, die die Sicherheit allein nicht beantworten kann, nämlich was geschieht, wenn die Prävention versagt und Sie dennoch liefern müssen. **ISO 22301 neben ISO 27001** | Dimension | ISO 22301 | ISO 27001 | | --- | --- | --- | | Gegenstand | Business-Continuity-Managementsystem | Informationssicherheits-Managementsystem | | Kernfrage | Können wir kritische Aktivitäten unter einer Störung weiter liefern | Schützen wir unsere Informationswerte | | Bestimmende Artefakte | Business-Impact-Analyse, Kontinuitätsstrategie, getestete Pläne | Risikobehandlung, Erklärung zur Anwendbarkeit, Maßnahmen | | Auslöser, auf den sie antwortet | Eine Störung ist eingetreten, wiederherstellen und fortführen | Eine Bedrohung für Informationen, verhindern und schützen | | Gemeinsamer Boden | High-Level Structure, PDCA, zertifizierbar, oft gemeinsam betrieben | High-Level Structure, PDCA, zertifizierbar, oft gemeinsam betrieben | --- ## ISO 31000 (ISO 31000) **URL:** https://cyberacademy.net/de/resources/encyclopedia/iso-31000 **Last reviewed:** 2026-06-24 ISO 31000 ist der generische Risikomanagement-Standard. Grundsätze, Rahmenwerk und iterativer Prozess. KEIN zertifizierbares Managementsystem; es gibt keinen ISO 31000 Lead Auditor, trotz gegenteiliger Aussagen in manchen Katalogen. Der PECB-Pfad lautet Foundation → Risk Manager → Lead Risk Manager. Setzen Sie diesen Standard ein, wenn das Risikomanagement über die Informationssicherheit hinausgeht. ## Eine generische Norm, kein Managementsystem ISO 31000 ist die internationale Referenz für das Management von Risiken jeder Art, in jeder Organisation. Sie ist bewusst generisch gehalten. Dieselben Grundsätze, derselbe Rahmen und derselbe Prozess gelten, ob das betreffende Risiko finanzieller, operativer, strategischer, sicherheitsbezogener, ökologischer oder cyberbezogener Natur ist. Genau diese Breite ist der Sinn der Sache. Eine Einkaufsentscheidung, ein Eintritt in einen neuen Markt und eine Ransomware-Exposition lassen sich alle mit demselben Vokabular und derselben Logik bewerten, was es einem Vorstand ermöglicht, Risiken zu vergleichen, die andernfalls in getrennten Silos mit nicht kompatiblen Bewertungen verbleiben würden. Das häufigste Missverständnis besteht darin, ISO 31000 wie ISO 27001 oder ISO 22301 zu behandeln. Sie ist keine Anforderungsnorm und nicht zertifizierbar. Es gibt kein ISO-31000-Managementsystem, das auditiert werden könnte, und keine Qualifikation als ISO 31000 Lead Auditor, was auch immer manche Schulungskataloge bewerben. Die Norm bietet Leitlinien, die anzupassen sind, keine Anforderungen, denen zu entsprechen ist. Organisationen integrieren sie in ihre bestehende Arbeitsweise, anstatt ein separates zertifiziertes System aufzusetzen. ## Grundsätze, Rahmen und Prozess ISO 31000 stützt sich auf drei zusammenhängende Teile, die Praktiker auseinanderzuhalten lernen. Die Grundsätze legen dar, wie gutes Risikomanagement aussieht: Es ist in die Organisation integriert, strukturiert, auf den Kontext zugeschnitten, bezieht die Interessengruppen ein, ist dynamisch, beruht auf den besten verfügbaren Informationen und ist auf die Schaffung und den Schutz von Werten ausgerichtet. Der Rahmen betrifft Führung und Governance, also wie Risikomanagement beauftragt, gestaltet, umgesetzt, bewertet und im Laufe der Zeit verbessert wird, damit es sich tatsächlich verankert. Der Prozess ist die operative Maschine, die wiederholt ausgeführt wird. 1. Festlegen des Kontexts. Definieren von Anwendungsbereich, Zielen sowie des internen und externen Umfelds, in dem das Risiko besteht. 1. Risikoidentifikation, -analyse und -bewertung, die zusammen die Risikoeinschätzung bilden. 1. Risikobehandlung. Festlegen, wie das Risiko verändert werden soll, und anschließend Umsetzen und Überprüfen der Maßnahmen. 1. Kommunikation, Konsultation, Überwachung und Überprüfung, die den gesamten Zyklus umschließen und ihn aktuell halten. > **Anzuwenden, wenn das Risiko über die Informationssicherheit hinausgeht** ISO 31000 liefert Ihnen die übergreifende Sprache für unternehmensweites Risiko. Wenn Sie sich konkret auf das Informationssicherheitsrisiko fokussieren, greifen Sie zu einer fachspezifischen Norm wie ISO 27005 oder einer Methode wie EBIOS Risk Manager, die beide problemlos unterhalb des ISO-31000-Prozesses angesiedelt sind. ## Wie sie sich zu benachbarten Normen verhält ISO 31000 ist die übergeordnete Norm. ISO 27005 wendet dieselbe Prozesslogik auf das Informationssicherheitsrisiko an und stimmt sich auf ein Informationssicherheits-Managementsystem nach ISO 27001 ab. EBIOS Risk Manager, die von der ANSSI veröffentlichte französische Methode, ist ein konkreter, szenariengetriebener Weg, eine Sicherheitsrisikoeinschätzung durchzuführen, der auf dieselben Phasen abgebildet wird. Keine dieser Ansätze widerspricht ISO 31000; sie spezialisieren sie. Ein Risk Manager, der den generischen Prozess versteht, kann zwischen ihnen wechseln, ohne die Grundlagen neu zu erlernen, weshalb die Norm zuerst gelehrt wird. Das Vokabular wird über den ISO Guide 73 geteilt, das Begleitdokument, das die Begriffe des Risikomanagements definiert, damit „Wahrscheinlichkeit“, „Konsequenz“ und „Risikobehandlung“ in allen Dokumenten und Teams dasselbe bedeuten. Sich früh auf diese Definitionen zu einigen, verhindert die Bewertungsstreitigkeiten, die viele Risiko-Workshops zum Entgleisen bringen. ## Was Praktiker tatsächlich damit machen In der Praxis prägt ISO 31000 das Risikoregister, die Bewertungs-Workshops und die Berichtslinie zur Leitung. Ein Risk Manager nutzt sie, um zu begründen, warum ein Risiko auf eine bestimmte Weise zugeordnet, bewertet und behandelt wird, und um zu zeigen, dass der Ansatz konsistent und nicht von Fall zu Fall improvisiert ist. Da die Norm nicht zertifizierbar ist, ist der anerkannte Weg, Kompetenz nachzuweisen, ein persönlicher Nachweis. Der PECB-Pfad führt über Foundation, dann Risk Manager, dann Lead Risk Manager und baut vom Bewusstsein für die Konzepte bis zur Leitung eines Risikomanagementprogramms über eine gesamte Organisation auf. --- ## ISO/IEC 27001 (ISO 27001) **URL:** https://cyberacademy.net/de/resources/encyclopedia/iso-27001 **Last reviewed:** 2026-06-24 ISO 27001 ist das zertifizierbare Framework, anhand dessen Auditoren Ihre Informationssicherheit bewerten. Die Revision 2022 hat Annex A auf 93 Controls in vier Themengruppen (organisatorisch, personell, physisch, technologisch) reduziert. Ihr ISMS steht und fällt mit der Anwendbarkeitserklärung und den operativen Nachweisen. Jeder referenziert es; wenige setzen es konsequent um. ## Was die ISO/IEC 27001 tatsächlich zertifiziert Die ISO/IEC 27001 ist die internationale Norm, die die Anforderungen an ein Informationssicherheits-Managementsystem, kurz ISMS, festlegt. Das Zertifikat sagt nicht aus, dass Ihre Systeme unangreifbar sind. Es sagt aus, dass eine akkreditierte Stelle geprüft hat, wie Sie Informationsrisiken identifizieren, über den Umgang damit entscheiden und diese Entscheidung unter der Aufsicht der Leitung am Laufen halten. Die Norm beruht auf dem Plan-Do-Check-Act-Zyklus, daher ist die Zertifizierung niemals ein einmaliges Ereignis: Sie verpflichten sich zu einem wiederkehrenden Rhythmus aus Risikobeurteilung, Behandlung, internem Audit, Managementbewertung und Korrekturmaßnahme. Eine häufige Verwechslung besteht darin, die Maßnahmen des Anhangs A als die Norm zu betrachten. Das sind sie nicht. Die zertifizierbaren Anforderungen liegen in den nummerierten Klauseln des Managementsystems (Kontext, Führung, Planung, Unterstützung, Betrieb, Bewertung der Leistung, Verbesserung). Anhang A ist ein Referenzsatz von Maßnahmen, aus dem Sie auswählen. Sie können ein Audit bestehen, ohne jede Maßnahme umzusetzen, sofern Ihre Erklärung zur Anwendbarkeit begründet, was Sie ausgeschlossen haben, und Ihre Nachweise belegen, was Sie beibehalten haben. ## Die Revision von 2022 und die Maßnahmenthemen Die Revision von 2022 hat den Anhang A in vier Themen statt der früheren vierzehn Bereiche neu gegliedert. Die Themen gruppieren die Maßnahmen nach der Art dessen, was geschützt oder geregelt wird: - Organisatorische Maßnahmen betreffen Richtlinien, Lieferantenbeziehungen, Bedrohungsaufklärung und Informationssicherheit im Projektmanagement. - Personenbezogene Maßnahmen betreffen die Überprüfung, die Beschäftigungsbedingungen, das Bewusstsein und das Disziplinarverfahren. - Physische Maßnahmen betreffen Sicherheitsbereiche, Geräte, den aufgeräumten Arbeitsplatz und die Entsorgung von Datenträgern. - Technologische Maßnahmen betreffen die Zugriffsverwaltung, die Kryptografie, die Protokollierung, die sichere Entwicklung und das Konfigurationsmanagement. Wenn Sie nach der früheren Fassung zertifiziert waren, ist die Umstellungsarbeit größtenteils eine Neuzuordnung: Schneiden Sie Ihre Erklärung zur Anwendbarkeit gegen den neuen Maßnahmensatz neu zu, bestätigen Sie, dass nichts durch die durch zusammengeführte oder neu eingeführte Maßnahmen entstandenen Lücken gefallen ist, und aktualisieren Sie die Nachweisverweise. Die Klauseln des Managementsystems haben sich weit weniger verändert als der Anhang. > **Die SoA ist der Ort, an dem Audits gewonnen oder verloren werden** Abweichungen in Stufe 2 entstehen am häufigsten durch eine Diskrepanz zwischen der Erklärung zur Anwendbarkeit, dem Risikobehandlungsplan und dem, was die Organisation tatsächlich tut. Halten Sie die drei Dokumente aufeinander abgestimmt, und das Audit wird zu einer Verifizierungsübung statt zu einer Entdeckungsübung. ## Wie sie sich zu ihren Nachbarn verhält Die ISO 27001 ist der zertifizierbare Anker einer Familie. Die ISO 27002 gibt Umsetzungsleitlinien für dieselben Maßnahmen des Anhangs A, ist aber für sich allein nicht zertifizierbar; Auditoren greifen darauf zurück, wenn sie hinterfragen wollen, wie gut Sie eine Maßnahme betreiben, und nicht nur, ob sie existiert. Die ISO 27005 liefert eine Methode für die Beurteilung des Informationssicherheitsrisikos, die Klausel 6 verlangt, aber bewusst offen lässt. Das ISMS ist die laufende Maschine, die die Norm zertifiziert, und die SoA ist deren zentrales gelenktes Artefakt. Auf der personellen Seite teilt sich die Arbeit in zwei einander ergänzende Disziplinen. Implementierer bauen das Managementsystem auf und betreiben es. Auditoren planen und leiten die Audits, die es auf die Probe stellen, und arbeiten dabei nach den Auditleitlinien der ISO 19011. Die meisten ausgereiften Sicherheitsfunktionen brauchen beide Denkweisen, selbst wenn anfangs eine Person beide Rollen ausfüllt. ## Was Praktiker tatsächlich tun Die ISO 27001 gut zu betreiben, statt nur das Zertifikat zu bestehen, sieht in der Praxis so aus: 1. Den Geltungsbereich ehrlich festlegen. Ein zu breiter Geltungsbereich begräbt Sie unter Nachweisen; ein zu enger täuscht niemanden und untergräbt das Zertifikat. 1. Eine echte Risikobeurteilung und einen Behandlungsplan durchführen und beide aktuell halten, während sich Geschäft und Bedrohungslage verändern. 1. Die Erklärung zur Anwendbarkeit als lebendes Dokument pflegen, das an tatsächliche Nachweise gebunden ist, und nicht als einmal für den Auditor ausgefüllte Tabelle. 1. Interne Audits und Managementbewertungen planmäßig durchführen und Korrekturmaßnahmen mit Nachweisen statt mit Versprechen abschließen. 1. Überwachungsaudits und den Rezertifizierungszyklus als Kontinuität behandeln, nicht als gesonderte Feuerwehrübungen. --- ## ISO/IEC 27002 (ISO 27002) **URL:** https://cyberacademy.net/de/resources/encyclopedia/iso-27002 **Last reviewed:** 2026-06-24 ISO 27002 is the implementation guidance for ISO 27001's Annex A controls. Not certifiable on its own. Auditors use it when they want to challenge HOW you operate a control, not just whether it is "in place". Treat it as the operational playbook beside the certification standard. ## Was die Norm ISO/IEC 27002 tatsächlich ist ISO/IEC 27002 ist der Umsetzungsleitfaden, der neben ISO 27001 steht. Während ISO 27001 die zertifizierbare Managementsystem-Norm ist, die die Maßnahmen aus Anhang A auflistet und verlangt, die anwendbaren zu begründen, erläutert ISO 27002 jede dieser Maßnahmen im Detail: ihren Zweck, wie gute Praxis aussieht und die praktischen Erwägungen ihrer Inbetriebnahme. Sie ist ein Verhaltenskodex (Code of Practice), keine Checkliste von Anforderungen. Man zertifiziert sich nicht gegen ISO 27002, und ein Auditor kann nicht unmittelbar eine Abweichung dagegen aussprechen. Er nutzt sie, um den Geist einer Maßnahme aus Anhang A auszulegen und zu hinterfragen, ob Ihre Umsetzung wirklich zweckmäßig ist. Diese Unterscheidung ist bei realen Audits von Bedeutung. Eine oberflächliche Prüfung fragt, ob eine Maßnahme "vorhanden" ist. Ein Auditor, der zu ISO 27002 greift, fragt, wie Sie sie betreiben: ob die Zugriffsüberprüfung tatsächlich in dem von Ihnen behaupteten Rhythmus stattfindet, ob Ihre Protokollierung die Ereignisse erfasst, die Ihnen die Erkennung eines Vorfalls ermöglichen würden, ob Ihre Lieferantenklauseln dem Kontakt mit einer realen Verletzung standhalten. Die Norm gibt beiden Seiten ein gemeinsames Vokabular für dieses Gespräch, weshalb Fachleute sie als das operative Handbuch behandeln und nicht als ergänzende Lektüre. ## Wie sie sich zu ISO 27001, der SoA und dem ISMS verhält Die drei Dokumente bilden eine Kette. Ihr ISMS ist das Managementsystem, das das gesamte Programm steuert. ISO 27001 definiert, was dieses System leisten muss, und liefert den Maßnahmensatz. Die Erklärung zur Anwendbarkeit (SoA) hält Maßnahme für Maßnahme fest, welche Sie aufgenommen, welche Sie ausgeschlossen haben und warum. ISO 27002 ist das, worauf Sie für den Inhalt jeder Maßnahme zurückgreifen, sobald die SoA Ihnen sagt, dass sie anwendbar ist. In der Praxis erstellen Teams die SoA mit geöffneter ISO 27001 für die Anforderung und geöffneter ISO 27002 für den Umsetzungsleitfaden und gestalten dann die tatsächliche Maßnahme anhand des Leitfadens. > **Sie setzen nach 27002 um, Sie zertifizieren sich gegen 27001** Eine klare Eselsbrücke für die Aufteilung: ISO 27001 sagt Ihnen, welche Maßnahmen zu berücksichtigen sind, und zwingt Sie, Ihre Entscheidungen in der SoA zu dokumentieren. ISO 27002 sagt Ihnen, wie jede Maßnahme funktionieren soll. Die Zertifizierung auditiert das Managementsystem und die von Ihnen ausgewählten Maßnahmen und verwendet ISO 27002 als Referenz dafür, wie eine kompetente Umsetzung aussieht. Moderne Ausgaben von ISO 27002 ordnen die Maßnahmen in vier Themen, organisatorisch, personenbezogen, physisch und technologisch, und kennzeichnen jede mit Attributen wie dem Maßnahmentyp, der Sicherheitseigenschaft, die sie schützt, und dem relevanten Cybersicherheitskonzept. Diese Attribute erlauben es Ihnen, den Maßnahmensatz auf unterschiedliche Weise zu zerlegen, etwa indem Sie alle präventiven Maßnahmen oder alle Maßnahmen, die die Erkennung unterstützen, herausziehen, was hilft, wenn Sie auf andere Rahmenwerke abbilden oder einen Risikobehandlungsplan erstellen. ## Was Fachleute tatsächlich damit tun In einem laufenden Programm taucht ISO 27002 in einigen wiederkehrenden Aufgaben auf: 1. Maßnahmen gestalten: Wenn die SoA eine Maßnahme als anwendbar kennzeichnet, prägt der Umsetzungsleitfaden die Richtlinie, das Verfahren oder die technische Konfiguration, die Sie aufbauen. 1. Entscheidungen begründen: Wenn Sie eine Maßnahme anpassen oder im Umfang abgrenzen, liefert Ihnen der Leitfaden die Begründung, die Sie festhalten müssen, damit ein Auditor Ihrer Argumentation folgen kann. 1. Auf das Audit vorbereiten: Teams nutzen den Leitfaden, um ihre eigenen Maßnahmen unter Druck zu setzen, bevor es der Begutachter tut, und schließen so die Lücke zwischen "dokumentiert" und "wirksam betrieben". 1. Rahmenwerke abbilden: Die Maßnahmenstruktur und die Attribute machen ISO 27002 zu einem nützlichen Rückgrat für das Überleiten auf Maßnahmensätze wie die CIS Controls oder die Leitlinien des NIST. Da ISO 27002 ein Leitfaden und keine strikte Anforderung ist, liegt das Urteil bei Ihnen. Die Norm beschreibt Absicht und gute Praxis; Sie entscheiden, wie weit Sie gehen, basierend auf Ihrer Risikobewertung. Diese Freiheit ist der Sinn der Sache. Sie erlaubt es einer kleinen Beratung und einem multinationalen Konzern, beide die Konformität mit derselben Maßnahme zu beanspruchen, während sie diese in sehr unterschiedlicher Tiefe umsetzen, jeweils angemessen für ihr Risiko. --- ## ISO/IEC 27005 (ISO 27005) **URL:** https://cyberacademy.net/de/resources/encyclopedia/iso-27005 **Last reviewed:** 2026-06-24 ISO 27005 ist die Informationssicherheits-Risikomanagementmethodik, die auf ISO 27001 aufsetzt. Identifikation, Analyse, Bewertung, Behandlung, Akzeptanz. Die Revision von 2022 orientiert sich an den Grundsätzen der ISO 31000 und klärt die Beziehung zur Klausel 6 der ISO 27001. Weniger präskriptiv als EBIOS RM, jedoch die anerkannte gemeinsame Sprache im Umgang mit Auditoren. ## Wofür die ISO/IEC 27005 da ist Die ISO/IEC 27005 ist die Leitliniennorm für das Management von Informationssicherheitsrisiken. Sie zertifiziert nichts und ersetzt nicht die ISO/IEC 27001. Stattdessen liefert sie Ihnen eine Methode, um die Risikobeurteilung und Risikobehandlung durchzuführen, die Abschnitt 6 der ISO 27001 verlangt, aber bewusst offen lässt. Die ISO 27001 sagt Ihnen, dass Sie Informationssicherheitsrisiken identifizieren, analysieren, bewerten und behandeln müssen ; die ISO 27005 zeigt Ihnen einen vertretbaren Weg, dies zu tun. Diese Aufgabenteilung ist das Wichtigste, was man über die Norm verstehen muss. Die Methode folgt einem erkennbaren Bogen : den Kontext festlegen, die Risiken identifizieren, sie analysieren, sie anhand Ihrer Kriterien bewerten und sie dann behandeln. Die Behandlung endet mit einer Entscheidung und einem Nachweis, nicht nur mit einer Liste von Maßnahmen. Zwei Ergebnisse zählen für Auditoren mehr als alle anderen. Das erste ist Ihr Satz von Risikoakzeptanzkriterien, die vereinbart werden, bevor Sie mit der Bewertung beginnen, damit die Ergebnisse nicht nachträglich auf eine bequeme Antwort zurückgerechnet werden können. Das zweite ist die dokumentierte Freigabe, wenn ein Restrisiko vom richtigen Verantwortlichen akzeptiert wird. Es sind diese Artefakte, die eine Tabelle voller Bewertungen in einen gesteuerten Prozess verwandeln. ## Die Revision 2022 und die Verbindung zur ISO 31000 Die aktuelle Revision richtet Vokabular und Struktur an der ISO 31000 aus, der organisationsweiten Norm für das Risikomanagement, damit das Informationssicherheitsrisiko dieselbe Sprache spricht wie das Unternehmensrisiko. Sie schärft außerdem die Beziehung zur ISO 27001, indem sie deren Aktivitäten den Abschnitten der ISO 27001 zuordnet, anstatt ein Paralleluniversum zu beschreiben. Wo sich ältere Ansätze stark auf das Aufzählen von Werten, Bedrohungen und Schwachstellen stützten, lässt die Revision sowohl diese ereignisbasierte Sicht als auch eine szenariobasierte Sicht zu und gibt den Teams Raum, das Risiko auf die Weise zu beurteilen, die tatsächlich zu ihrem Umfeld passt. > **Empfehlungen, keine Anforderungen** Die ISO 27005 verwendet das Wort sollte, nicht muss. Sie können nicht gegen sie zertifiziert werden, und ein Auditor kann keine Abweichung als Nichtkonformität bewerten, weil man von ihren genauen Schritten abgewichen ist. Was er prüfen wird, ist, dass die Risikobeurteilung, die Ihr ISO-27001-ISMS speist, konsistent, wiederholbar und dokumentiert ist. Die ISO 27005 ist die gängigste Art, dies nachzuweisen. ## Die ISO 27005 neben EBIOS RM Praktiker in Frankreich wägen die ISO 27005 ständig gegen EBIOS Risk Manager ab, die von der ANSSI gepflegte Methode. Sie sind weniger Rivalen als vielmehr unterschiedliche Instrumente. Die ISO 27005 ist weniger vorschreibend, international anerkannt und die gemeinsame Sprache mit Zertifizierungsauditoren, was sie zur natürlichen Wahl macht, wenn Ihr Ziel ein überall gültiges ISO-27001-Zertifikat ist. EBIOS RM ist stärker strukturiert und szenariengetrieben, aufgebaut um strategische und operative Angriffsszenarien und ausdrückliche Risikoursprünge, was zu französischen Kontexten mit hohem Einsatz oder mit Regulierung passt. Viele Organisationen führen EBIOS RM für die Analyse durch und drücken die Ergebnisse dann für das ISMS in ISO-27005-Begriffen aus. **Die ISO/IEC 27005 im Vergleich mit EBIOS Risk Manager** | Dimension | ISO/IEC 27005 | EBIOS Risk Manager | | --- | --- | --- | | Wesen | Internationale Leitliniennorm | Nationale Methode, gepflegt von der ANSSI | | Stil | Weniger vorschreibend, flexibel | Strukturiert, szenarien- und bedrohungsgetrieben | | Beste Eignung | ISO-27001-Zertifizierung, weltweite Anerkennung | Französische Kontexte mit hohem Einsatz und Regulierung | | Zielgruppe | Zertifizierungsauditoren weltweit | Französischer öffentlicher Sektor und kritische Betreiber | ## Was Praktiker tatsächlich tun Die ISO 27005 gut zu nutzen, statt ein einmaliges Dokument zu erstellen, sieht in der Praxis so aus : 1. Zuerst den Kontext festlegen : den Geltungsbereich, die Kriterien für Auswirkung und Eintrittswahrscheinlichkeit sowie die Schwellen für die Risikoakzeptanz, alle vereinbart, bevor irgendeine Bewertung beginnt. 1. Die Risiken auf die zum Umfeld passende Weise identifizieren, ob als Wert-Bedrohung-Schwachstelle-Ketten oder als durchgängige Szenarien, und vermeiden, Methoden innerhalb derselben Beurteilung uneinheitlich zu vermischen. 1. Anhand der vorab vereinbarten Kriterien analysieren und bewerten, damit die Prioritätenliste reproduzierbar ist, dann eine Behandlungsoption wählen : verändern, beibehalten, vermeiden oder teilen. 1. Das Restrisiko erfassen und eine ausdrückliche Akzeptanz vom benannten Risikoeigner einholen, denn diese Freigabe verbindet die Beurteilung mit der Rechenschaftspflicht der obersten Leitung nach ISO 27001. 1. Die Beurteilung in einem festgelegten Takt und nach wesentlichen Änderungen erneut durchgehen, damit das Risikobild aktuell bleibt, statt zwischen den Zertifizierungszyklen still zu altern. --- ## ISO/IEC 27017 (ISO 27017) **URL:** https://cyberacademy.net/de/resources/encyclopedia/iso-27017 **Last reviewed:** 2026-06-24 ISO 27017 ist die Cloud-Sicherheitserweiterung zu ISO 27001. Sie ergänzt Cloud-spezifische Controls und klärt die Aufteilung der geteilten Verantwortung zwischen Anbieter und Kunde. Wenn Ihr ISMS-Scope Hyperscaler-Workloads umfasst (AWS, Azure, GCP, OVH), werden Auditoren fragen, welche 27017-Controls Sie zuordnen. ## Was ISO/IEC 27017 tatsächlich ergänzt ISO/IEC 27017 ist kein eigenständiges Zertifizierungsschema. Es ist ein Leitfaden für die Praxis, der auf ISO/IEC 27002 aufsetzt, der Umsetzungsanleitung für die Maßnahmen von ISO/IEC 27001. Wo 27002 eine allgemeine Maßnahme zur Informationssicherheit beschreibt, ergänzt 27017 für dieselbe Maßnahme cloud-spezifische Umsetzungshinweise und führt an einigen Stellen zusätzliche Maßnahmen ein, die erst dann sinnvoll sind, wenn Ihre Daten auf einer Infrastruktur liegen, die Ihnen nicht gehört. Wenn Sie es also einführen, betreiben Sie kein paralleles ISMS. Sie erweitern jenes, das Sie bereits nach ISO 27001 zertifizieren, damit es die Sprache der Cloud spricht. Der praktische Wert liegt darin, dass es beide Seiten der Cloud-Beziehung zwingt, Dinge schriftlich festzuhalten. Die Norm ist bewusst so aufgebaut, dass jeder Leitfadenpunkt eine Fassung für den Cloud-Diensteanbieter und eine für den Cloud-Dienstekunden hat. Diese doppelte Sichtweise ist der eigentliche Kern. Eine Maßnahme wie die Zugriffsverwaltung oder die Handhabung kryptografischer Schlüssel bedeutet etwas anderes, je nachdem, ob Sie der Hyperscaler sind, der die Plattform betreibt, oder der Mandant, der Workloads darauf bereitstellt, und 27017 macht diese Aufteilung ausdrücklich, statt sie der Annahme zu überlassen. ## Geteilte Verantwortung, prüfbar gemacht Jedes Gespräch über Cloud-Sicherheit landet irgendwann bei der geteilten Verantwortung: Der Anbieter sichert die Infrastruktur, der Kunde sichert das, was er darauf ablegt. Das Problem ist, dass sich die Grenze je nach Servicemodell verschiebt. Bei Infrastructure as a Service verantwortet der Kunde das Betriebssystem, das Patchen und den Großteil der Konfiguration. Bei Software as a Service liegt fast alles beim Anbieter, und dem Kunden bleiben im Wesentlichen Identität, Zugriff und Daten-Governance. ISO 27017 verwandelt dieses unscharfe Schaubild in etwas, das ein Auditor prüfen kann. - Sie verlangt vom Anbieter zu dokumentieren, welche Sicherheitsverantwortungen er behält und welche er an den Kunden übergibt, damit keine stille Lücke entsteht. - Sie verlangt vom Kunden zu bestätigen, dass er seinen Anteil versteht und tatsächlich umgesetzt hat, statt anzunehmen, dass der Anbieter ihn abdeckt. - Sie ergänzt Hinweise speziell für mandantenfähige Umgebungen, die Härtung virtueller Maschinen, administrative Vorgänge und die Trennung von Kunden, die auf gemeinsam genutzter Hardware laufen. - Sie behandelt die Entfernung und Rückgabe von Werten bei Vertragsende, also genau dort, wo viele Cloud-Ausstiege scheitern. > **27017 ist Leitfaden, die Zertifizierung erfolgt über 27001** Es gibt kein eigenständiges ISO-27017-Zertifikat, das für sich allein steht. In der Praxis zertifiziert eine Organisation ihr ISMS nach ISO/IEC 27001 und nimmt 27017 in den Geltungsbereich auf, und weist dann nach, welche Cloud-Maßnahmen sie zugeordnet hat. Auditoren werden fragen, welche 27017-Maßnahmen auf Ihre Hyperscaler-Workloads zutreffen und wie Sie jede Seite der Aufteilung umgesetzt haben. ## Wo sie neben ihren Nachbarn steht 27017 lässt sich leicht mit den umgebenden Normen verwechseln, daher hilft es, die Familie klar zu halten. ISO/IEC 27001 ist das zertifizierbare Managementsystem. ISO/IEC 27002 ist der allgemeine Maßnahmen-Leitfaden. ISO/IEC 27017 ist die Cloud-Sicherheitserweiterung dieses Leitfadens. ISO/IEC 27018 ist das Schwesternormwerk, das sich speziell auf den Schutz personenbezogen identifizierbarer Informationen in der öffentlichen Cloud konzentriert, was zählt, wenn Ihre Cloud-Workloads auch personenbezogene Daten tragen und Sie neben Sicherheits- auch Datenschutzpflichten erfüllen. **ISO 27017 neben ihren Nachbarn** | Norm | Rolle | Eigenständig zertifizierbar | | --- | --- | --- | | ISO/IEC 27001 | Anforderungen an das Informationssicherheits-Managementsystem | Ja | | ISO/IEC 27002 | Allgemeine Umsetzungsanleitung für Sicherheitsmaßnahmen | Nein, Leitfaden | | ISO/IEC 27017 | Cloud-spezifische Sicherheitsmaßnahmen und Aufteilung zwischen Anbieter und Kunde | Nein, in den Geltungsbereich von 27001 einbezogen | | ISO/IEC 27018 | Schutz personenbezogener Daten in der öffentlichen Cloud | Nein, in den Geltungsbereich von 27001 einbezogen | Für einen Praktiker ist der Ablauf einheitlich. Sie betreiben ein ISO-27001-ISMS, nehmen Cloud-Workloads in dessen Geltungsbereich auf und nutzen 27017, um zu entscheiden, welche Cloud-Maßnahmen Sie zuordnen und wie Sie beide Seiten der Verantwortungslinie nachweisen. Wenn diese Workloads auch personenbezogene Daten verarbeiten, kombinieren Sie es mit 27018. Keine dieser Normen ersetzt Ihre vertragliche Sorgfaltsprüfung beim Anbieter; sie geben Ihnen eine strukturierte Möglichkeit, nachzuweisen, dass Sie sie durchgeführt haben. --- ## ISO/IEC 27018 (ISO 27018) **URL:** https://cyberacademy.net/de/resources/encyclopedia/iso-27018 **Last reviewed:** 2026-06-24 ISO 27018 ist die Datenschutz-Kontrollerweiterung zu ISO 27001 für Cloud-Anbieter, die als Auftragsverarbeiter personenbezogener Daten tätig sind. Sie verbindet ISO 27001 mit den GDPR-Pflichten des Auftragsverarbeiters. Die Zertifizierung wird überwiegend von Hyperscalern gehalten und von deren Kunden als Input für die Lieferantensorgfaltsprüfung genutzt. ## Was die Norm ISO/IEC 27018 zusätzlich zu ISO 27001 bietet ISO/IEC 27018 ist ein Verhaltenskodex, kein eigenständiges Managementsystem. Sie setzt voraus, dass Sie bereits ein nach ISO/IEC 27001 zertifiziertes Informationssicherheits-Managementsystem betreiben, und legt eine Datenschutzebene auf diese Basis. Konkret richtet sie sich an eine einzige Rolle: einen Anbieter von Public-Cloud-Diensten, der als Auftragsverarbeiter personenbezogener Daten (PII) im Auftrag seiner Kunden handelt. Die Norm nimmt die generischen Maßnahmen aus ISO/IEC 27002 und interpretiert sie für diesen Auftragsverarbeiter-Kontext neu, und fügt anschließend eine Reihe cloud-spezifischer Datenschutzmaßnahmen hinzu, die ISO 27001 allein nicht verlangt. Die praktische Folge ist, dass sich ISO 27018 nicht für sich allein zertifizieren lässt. Ein Anbieter ist nach ISO 27001 zertifiziert, mit ISO 27018 als anwendbarem Maßnahmensatz innerhalb des Geltungsbereichs. Deshalb sehen Sie sie als «nach ISO 27001 zertifiziert, gegen ISO 27018 auditiert» ausgedrückt und nicht als gesondertes Zertifikat. Die Maßnahmen betreffen Dinge, die ein Cloud-Kunde nicht ohne Weiteres selbst überprüfen kann: ob der Anbieter die PII der Kunden für seine eigene Werbung nutzt, ob Unterauftragsverarbeiter offengelegt werden, bevor sie beauftragt werden, wie Daten am Ende eines Vertrags behandelt werden und was geschieht, wenn Strafverfolgungsbehörden Daten anfordern. ## Wo sie zwischen ISO 27001, ISO 27017 und der DSGVO steht Drei benachbarte Referenzen werden mit ISO 27018 verwechselt, und die Unterschiede sind wichtig, wenn Sie ein Audit abgrenzen oder einen Lieferantenfragebogen ausfüllen. ISO 27001 ist das Managementsystem, das die Informationssicherheit allgemein regelt. ISO 27017 ist der Verhaltenskodex für Cloud-Sicherheit, der breiter angelegt ist als der Datenschutz und sich mit der Sicherheit von Cloud-Diensten sowohl für Anbieter als auch für Kunden befasst. ISO 27018 ist enger gefasst als beide: Es geht um Datenschutz, in der Public Cloud, ausschließlich für die Rolle des Auftragsverarbeiters. **ISO 27018 im Vergleich zu benachbarten Normen** | Referenz | Geltungsbereich | Was sie regelt | | --- | --- | --- | | ISO/IEC 27001 | Informationssicherheits-Management | Das zertifizierbare ISMS, das die anderen erweitern | | ISO/IEC 27017 | Sicherheitsmaßnahmen für die Cloud | Sicherheit von Cloud-Diensten, Anbieter und Kunde | | ISO/IEC 27018 | Cloud-Datenschutz für Auftragsverarbeiter | Schutz von PII, die von einem Cloud-Auftragsverarbeiter verarbeitet werden | | GDPR | EU-Datenschutzrecht | Rechtliche Pflichten von Verantwortlichen und Auftragsverarbeitern | ISO 27018 ist eine nützliche Brücke zu den Auftragsverarbeiter-Pflichten der DSGVO, weil sie Ideen operationalisiert, die die Verordnung in rechtlichen Begriffen ausdrückt: Zweckbindung, Transparenz über die Unterauftragsverarbeitung, Unterstützung des Verantwortlichen sowie Rückgabe oder Löschung von Daten. Aber sie ist kein Ersatz. Ein Zertifikat gegen ISO 27018 ist ein Nachweis guter Praxis als Auftragsverarbeiter, keine Feststellung rechtlicher Konformität. Die DSGVO weist Pflichten durch verbindliches Recht und durch Verträge zwischen Verantwortlichem und Auftragsverarbeiter zu; eine Norm kann das nicht für Sie übernehmen. > **Sie ist ein Input für die Lieferanten-Due-Diligence, kein Konformitätsnachweis** ISO 27018 wird überwiegend von den großen Hyperscalern gehalten und von deren Kunden als einer der Inputs für die Lieferantenbewertung gelesen. Behandeln Sie sie als Beleg dafür, dass sich ein Anbieter zu bestimmten Datenschutzpraktiken verpflichtet hat, und überprüfen Sie dann im tatsächlichen Verarbeitungsvertrag die für Sie maßgeblichen Zusagen. ## Was Praktiker tatsächlich damit anfangen Für die meisten Organisationen ist ISO 27018 etwas, das man konsumiert, statt etwas, das man selbst hält. Wenn Sie einen Cloud-Dienst auswählen und Ihre Datenschutz-Folgenabschätzung oder Ihr Drittparteien-Risikoprozess die Frage stellt «ist dieser Auftragsverarbeiter vertrauenswürdig», ist das ISO-27018-Audit des Anbieters eines der Artefakte, die Sie sammeln, neben ISO-27001-Geltungsbereichserklärungen, SOC-Berichten und dem Verarbeitungsvertrag. - Bestätigen Sie, dass das Zertifikat aktuell ist und dass der von Ihnen tatsächlich genutzte Cloud-Dienst in den auditierten Geltungsbereich fällt, nicht nur das unternehmensweite ISMS. - Lesen Sie sie zusammen mit ISO 27001 und ISO 27017, da die drei darauf ausgelegt sind, geschichtet zu werden, und ein Anbieter, der alle drei hält, Sicherheit und Datenschutz in der Cloud vollständiger abgedeckt hat. - Ordnen Sie die Maßnahmen aus ISO 27018 Ihren eigenen DSGVO-Pflichten zu, anstatt eine Überschneidung anzunehmen, denn die Norm unterstützt die Auftragsverarbeiter-Beziehung, entbindet den Verantwortlichen aber nicht von seinen rechtlichen Pflichten. - Behalten Sie den Verarbeitungsvertrag als das verbindliche Dokument. Die Norm signalisiert eine Absicht; der Auftragsverarbeitungsvertrag ist das, was Sie durchsetzen. --- ## ISO/IEC 27034 (ISO 27034) **URL:** https://cyberacademy.net/de/resources/encyclopedia/iso-27034 **Last reviewed:** 2026-06-24 ISO 27034 ist der Standard für Anwendungssicherheit. Mehrteilig. Deckt den sicheren Software-Lebenszyklus ab: Anforderungen, Design, Entwicklung, Test, Deployment, Betrieb. Weniger bekannt als 27001, weil er innerhalb des SDLC angesiedelt ist, aber der einzige ISO-Standard, der die Sprache von Entwicklungsteams spricht. Lässt sich natürlich mit OWASP und SBOM-Praktiken kombinieren. ## Was die Norm ISO/IEC 27034 erreichen will ISO/IEC 27034 ist das auf Anwendungssicherheit ausgerichtete Mitglied der Normenfamilie ISO/IEC 27000. Während ISO/IEC 27001 das Managementsystem regelt, das Ihr gesamtes Informationssicherheitsprogramm steuert, verengt ISO/IEC 27034 den Blick auf eine Sache: das Entwickeln und Betreiben sicherer Anwendungen über den gesamten Software-Lebenszyklus hinweg, von den Anforderungen und dem Entwurf über die Entwicklung, das Testen, die Bereitstellung bis hin zur Wartung. Es handelt sich um eine mehrteilige Norm, was bedeutet, dass die Vorgaben über mehrere Dokumente verteilt sind, statt in einer einzigen zertifizierbaren Spezifikation gebündelt zu sein, und diese Form sagt etwas über ihre Absicht aus. Sie soll prägen, wie die Entwicklung durchgeführt wird, und einem Auditor keine Checkliste zum Abhaken in die Hand geben. Der Grund, warum sie im Hintergrund bleibt, während ISO/IEC 27001 die Aufmerksamkeit erhält, ist struktureller Natur. Der größte Teil einer Organisation spricht über Richtlinien, Risikoregister und Zertifikate; ISO/IEC 27034 spricht zu den Menschen, die den Code schreiben und ausliefern. Sie lebt innerhalb des Softwareentwicklungslebenszyklus (SDLC), sodass ihr Publikum aus Entwicklern, Architekten und Anwendungssicherheitsingenieuren besteht und nicht aus dem Compliance-Team. Das macht sie zur ISO-Norm, die die Sprache der Entwicklungsteams am fließendsten beherrscht, und zu derjenigen, die am ehesten sauber darauf abbildet, wie eine Engineering-Organisation tatsächlich Tag für Tag arbeitet. ## Die Idee der Anwendungssicherheitskontrolle Das ordnende Konzept in ISO/IEC 27034 besteht darin, Anwendungssicherheit als einen Satz überprüfbarer Kontrollen zu behandeln, die in den Lebenszyklus eingewoben sind, statt als eine am Ende angesetzte Sicherheitsprüfung. Die Norm fasst Sicherheitsanforderungen als etwas auf, das man aus dem Kontext der Anwendung, den von ihr verarbeiteten Daten und den Bedrohungen, denen sie ausgesetzt ist, ableitet und dann durch Entwurf, Implementierung und Verifizierung weiterträgt, sodass jede Kontrolle einen definierten Punkt hat, an dem sie eingebaut wird, und einen definierten Punkt, an dem sie geprüft wird. Die praktische Wirkung ist, dass Sicherheit aufhört, ein Tor bei der Freigabe zu sein, und zu einer Eigenschaft wird, die in jeder Phase aufrechterhalten wird, was genau der Wandel ist, den die moderne Praxis der sicheren Entwicklung seit Jahren vorantreibt. Da die Norm prozessorientiert und am Lebenszyklus ausgerichtet ist, fügt sie sich bequem neben das präskriptive, praxisnahe Material ein, das Teams bereits nutzen. Sie ersetzt weder den OWASP Application Security Verification Standard noch die OWASP Top 10; sie gibt ihnen einen Governance-Rahmen, an dem sie sich aufhängen können. Sie passt auch natürlich zur Praxis des software bill of materials (SBOM), bei der das genaue Wissen darüber, welche Komponenten in einer Anwendung ausgeliefert werden, die Kontrolle der Wartungsphase ist, die den Lebenszyklus nach der Freigabe ehrlich hält. Zusammen verwendet liefert ISO/IEC 27034 die Struktur, und OWASP und das SBOM liefern die konkreten Techniken und Inventare. > **Ein Rahmen, keine Checkliste** ISO/IEC 27034 ist am nützlichsten als die Lebenszyklusstruktur, die die sichere Entwicklung organisiert. Greifen Sie für die konkreten Tests und Inventare auf OWASP ASVS, die OWASP Top 10 und SBOM-Werkzeuge zurück, und lassen Sie ISO/IEC 27034 festlegen, an welcher Stelle im Lebenszyklus jedes davon hingehört. ## Wie sie sich neben ISO/IEC 27001 einfügt Der sauberste Weg, ISO/IEC 27034 zu positionieren, ist als das Detail der Anwendungsebene unterhalb eines ISO/IEC 27001-Managementsystems. ISO/IEC 27001 zertifiziert, dass Sie ein Informationssicherheits-Managementsystem mit Risikobewertung und kontinuierlicher Verbesserung betreiben, und sein Kontrollsatz umfasst auf hoher Ebene formulierte Erwartungen an die sichere Entwicklung. ISO/IEC 27034 ist der Ort, an den Sie gehen, um diese Erwartungen tatsächlich im Engineering umzusetzen: wie sichere Anforderungen erfasst werden, wie Kontrollen verifiziert werden, wie Sicherheit durch den SDLC wandert. Ein nach ISO/IEC 27001 zertifiziertes Team kann ISO/IEC 27034 nutzen, um seinen Kontrollen für die sichere Entwicklung Substanz zu verleihen, und eine Entwicklungsorganisation kann ISO/IEC 27034 nutzen, um sicherzustellen, dass der Code, den sie ausliefert, diesem umfassenderen Managementsystem standhalten würde. In der Praxis zertifizieren sich Organisationen selten gegen ISO/IEC 27034, so wie sie sich gegen ISO/IEC 27001 zertifizieren. Sie übernehmen sie als Leitlinie, überführen die Lebenszyklusstruktur in ihren eigenen Standard für sichere Entwicklung und verweisen auf sie, wenn sie eine maßgebliche Grundlage dafür benötigen, warum Anwendungssicherheit so gehandhabt wird, wie sie gehandhabt wird. Für ein kleines Team ist der Wert derselbe wie für ein großes Unternehmen: eine anerkannte, herstellerneutrale Möglichkeit, einen sicheren SDLC zu beschreiben, die Auditoren, Kunden und Entwickler gleichermaßen akzeptieren. --- ## ISO/IEC 27037 (ISO 27037) **URL:** https://cyberacademy.net/de/resources/encyclopedia/iso-27037 **Last reviewed:** 2026-06-24 ISO 27037 ist der Standard für digitale Forensik: Er regelt die Identifizierung, Erhebung, Sicherung und Aufbewahrung digitaler Beweismittel. Interne Forensik-Teams, CERTs und Litigation-Support-Berater nutzen ihn, um die Chain of Custody lückenlos zu erhalten. Betrachten Sie ihn als das Regelwerk, an dem Auditoren und Rechtsanwälte Ihre Handlungen nach einem Vorfall messen werden. ## Was die ISO/IEC 27037 regelt Die ISO/IEC 27037 ist der internationale Leitfaden für die erste und fragilste Phase jeder digitalen Untersuchung: die Beweise in die Hand zu bekommen, ohne sie zu zerstören. Sie ist Teil der umfassenderen ISO/IEC 27000-Familie, neben der ISO/IEC 27001, doch während die 27001 vorgibt, wie ein Managementsystem zu betreiben ist, sagt die 27037 Ihren Einsatzkräften genau, wie sie einen laufenden Server, einen beschlagnahmten Laptop, ein Telefon oder ein Cloud-Konto behandeln, damit das Erfasste später einer Überprüfung standhält. Sie deckt vier aufeinanderfolgende Tätigkeiten ab: das Identifizieren potenzieller digitaler Beweise, das Sammeln physischer Geräte, das Erfassen der Daten daraus und das Bewahren sowohl der Geräte als auch der Kopien bis zur Übergabe. Die Norm führt zwei Rollen ein, auf die Praktiker immer wieder zurückkommen. Der Digital Evidence First Responder (DEFR) ist die Person vor Ort, die entscheidet, was und wie sichergestellt wird. Der Digital Evidence Specialist (DES) verfügt über die tiefere technische Fähigkeit, um die heiklen Fälle zu behandeln, etwa laufende Systeme, verschlüsselte Datenträger oder ungewöhnliche Hardware. Von beiden wird erwartet, jede Entscheidung zu dokumentieren, denn der Wert eines digitalen Beweises beruht weniger auf den Bytes selbst als darauf, ob Sie nachweisen können, dass sie nicht verändert wurden. ## Die Beweiskette und die ihr zugrunde liegenden Prinzipien Die 27037 stützt sich auf eine Handvoll Prinzipien, die in jeder glaubwürdigen forensischen Methode wiederkehren. Erfasste Beweise sollten relevant, zuverlässig und ausreichend sein. Eingriffe in das Original sollten auf das notwendige Minimum beschränkt und vollständig begründet sein. Jede kompetente Person sollte den Vorgang wiederholen und zum selben Ergebnis gelangen können, weshalb Imaging-Werkzeuge, Schreibblocker und Verifizierungs-Hashes so wichtig sind. Der rote Faden, der alles verbindet, ist die Beweiskette: eine durchgehende, dokumentierte Aufzeichnung darüber, wer den Beweis in Händen hielt, was damit geschah und wann, vom Moment der Sammlung bis zur Vorlage. - Identifizierung: erkennen, was Beweis sein könnte, von Datenträgern und Telefonen bis hin zu flüchtigem Speicher und Netzwerkmitschnitten. - Sammlung: Geräte vom Tatort entfernen, wobei die Reihenfolge der Flüchtigkeit entscheidet, was zuerst erfasst wird. - Erfassung: eine überprüfbare Kopie erstellen, in der Regel ein forensisches Abbild, das durch einen kryptografischen Hash validiert wird. - Bewahrung: das Original und die Kopien vor Veränderung, Verlust oder Kontamination schützen. > **Ein Leitfaden, keine Zertifizierung** Man lässt eine Organisation nicht nach ISO/IEC 27037 zertifizieren, wie man es nach ISO/IEC 27001 tut. Es ist eine Methode, der Ihr forensisches Team, Ihr CERT oder Ihr Berater für Prozessunterstützung folgt, und der Maßstab, an dem Auditoren und Juristen Ihren Umgang nach einem Vorfall messen werden. Verwandte Normen erweitern sie: die ISO/IEC 27041 zur Assurance, die 27042 zu Analyse und Interpretation und die 27043 zum gesamten Untersuchungsprozess. ## Wo sie in die Incident Response und die weitere Familie passt In der Praxis ist die 27037 die Brücke zwischen dem Erkennen eines Vorfalls und der Fähigkeit, mit den Artefakten danach überhaupt etwas Sinnvolles anzufangen. Ein internes SOC, das ein Festplattenabbild auf die falsche Weise zieht oder den flüchtigen Speicher durch einen Neustart eines kompromittierten Hosts löscht, kann einen Angreifer einwandfrei erkennen und am Ende dennoch über Beweise verfügen, denen kein Gericht und keine Aufsichtsbehörde vertrauen wird. Deshalb liest man sie zusammen mit den Leitlinien zum Incident-Management der ISO/IEC 27035 und den Maßnahmen aus Annex A der ISO/IEC 27001. Die Disziplin ist dieselbe, ob das Ziel eine strafrechtliche Verfolgung, ein arbeitsrechtlicher Streit, ein Versicherungsanspruch oder schlicht ein interner Bericht ist, der einer Anfechtung standhält. Für Praktiker ist die Lehre prozeduraler, nicht theoretischer Natur. Legen Sie im Voraus fest, wer Ihre DEFR und DES sind, statten Sie sie mit validierten Werkzeugen aus, verfassen Sie das Beweisketten-Formular, bevor Sie es brauchen, und üben Sie die Reihenfolge der Flüchtigkeit, damit niemand die eine Maschine neu startet, auf die es ankam. Wenn eine Untersuchung scheitert, ist es fast nie die Analyse, die versagt. Es ist die erste Stunde, genau die Stunde, über die die 27037 geschrieben ist. --- ## ISO/IEC 27701 (ISO 27701) **URL:** https://cyberacademy.net/de/resources/encyclopedia/iso-27701 **Last reviewed:** 2026-06-24 ISO 27701 ist die Erweiterung von ISO 27001 um ein Datenschutz-Informationsmanagementsystem. Es ergänzt das ISMS um Pflichten für Verantwortliche und Auftragsverarbeiter. Nützlich für Organisationen, die ein einziges zertifizierbares Managementsystem für Sicherheit und Datenschutz anstreben. Es lässt sich auf die GDPR abbilden, ersetzt die GDPR-Compliance-Arbeit jedoch nicht. ## Eine Erweiterung, keine eigenständige Norm ISO/IEC 27701 steht nicht für sich allein. Sie ist als Erweiterung von ISO/IEC 27001 und ISO/IEC 27002 konzipiert, was bedeutet, dass Sie sich nicht danach zertifizieren lassen können, ohne zuvor über ein funktionierendes Informationssicherheits-Managementsystem (ISMS) zu verfügen. Die Norm nimmt die Sicherheitsmaßnahmen, die Sie bereits betreiben, und legt datenschutzspezifische Anforderungen und Leitlinien darüber, wodurch das ISMS in ein Datenschutz-Informationsmanagementsystem (PIMS) umgewandelt wird. Für eine Organisation, die ISO 27001 bereits betreibt, ist dies ein effizienter Schritt: Sie nutzen dieselbe Governance, dieselbe Risikomethodik, denselben Auditzyklus erneut und erweitern den Anwendungsbereich auf die Verarbeitung personenbezogener Daten (PII). Diese architektonische Entscheidung ist der eigentliche Kern. Anstatt den Datenschutz als gesondertes Programm mit eigenen Gremien und eigenen Nachweisen zu betreiben, ermöglicht Ihnen ISO 27701, ein einziges Managementsystem zu zertifizieren, das sowohl Sicherheit als auch Datenschutz abdeckt. Die Erklärung zur Anwendbarkeit wird erweitert, die Risikobeurteilung betrachtet nun das Datenschutzrisiko für Personen und nicht mehr nur das Risiko für die Organisation, und dieselbe Zertifizierungsstelle auditiert das Ganze in einem einzigen Auftrag. ## Pflichten des Verantwortlichen und des Auftragsverarbeiters ISO 27701 teilt ihre zusätzlichen Anforderungen entlang derselben Linie auf, die das Datenschutzrecht zieht: zwischen der Organisation, die als Verantwortlicher handelt (und entscheidet, warum und wie PII verarbeitet werden), und der Organisation, die als Auftragsverarbeiter handelt (und PII im Auftrag einer anderen Stelle verarbeitet). Viele Organisationen sind je nach Datenbestand zugleich beides, daher gibt Ihnen die Norm zwei Sätze von Leitlinien und fordert Sie auf, jeweils denjenigen anzuwenden, der zu jeder Verarbeitungstätigkeit passt. - Themen auf Seiten des Verantwortlichen umfassen Rechtsgrundlage und Zweck, Einwilligung und Wahlmöglichkeit, Transparenz gegenüber Personen, Bearbeitung von Betroffenenanfragen, Verzeichnisse von Verarbeitungstätigkeiten sowie Pflichten, wenn Sie PII mit Dritten teilen. - Themen auf Seiten des Auftragsverarbeiters umfassen das Handeln ausschließlich auf dokumentierte Weisung, die Unterstützung des Verantwortlichen bei dessen Pflichten, die Steuerung von Unterauftragsverarbeitern sowie die Rückgabe oder Löschung von PII am Ende eines Vertrags. In der Praxis ist dies das, was ein Datenschutzteam unter modernen Datenschutzregimen bereits tut, doch ISO 27701 ordnet es in auditierbare Maßnahmen mit dokumentierten Nachweisen, und genau das verwandelt eine Datenschutzhaltung in etwas, das ein Dritter überprüfen kann. ## Wo sie neben der DSGVO steht Das häufigste Missverständnis ist, dass eine ISO-27701-Zertifizierung Sie DSGVO-konform macht. Das tut sie nicht, und sie ist sorgfältig darauf bedacht, dies nicht zu behaupten. Die DSGVO ist Gesetz, und ISO 27701 ist eine freiwillige Managementsystem-Norm. Was 27701 Ihnen bietet, ist ein strukturierter, zertifizierbarer Rahmen, dessen Maßnahmen eng auf die Datenschutzgrundsätze abbilden, sodass sie ein starker Nachweis der Rechenschaftspflicht (accountability) und ein gutes operatives Rückgrat ist. Doch die Einhaltung eines bestimmten Rechtsregimes erfordert weiterhin Ihre eigene rechtliche Analyse, Ihre Aufzeichnungen und Ihren nachweisbaren Umgang mit individuellen Rechten nach diesem Gesetz. > **Ein Zertifikat ist ein Nachweis, keine Verteidigung** Ein ISO-27701-Zertifikat zeigt, dass ein Auditor Ihr PIMS gegen die Norm geprüft hat. Aufsichtsbehörden können es als glaubwürdiges Signal der Rechenschaftspflicht werten, doch es ersetzt nicht die Erfüllung der tatsächlichen Pflichten der DSGVO oder eines anderen anwendbaren Datenschutzgesetzes. Betrachten Sie es als die Managementebene, die rechtliche Compliance wiederholbar macht, nicht als die Compliance selbst. **ISO 27701 neben der DSGVO** | Dimension | ISO/IEC 27701 | DSGVO | | --- | --- | --- | | Charakter | Freiwillige Managementsystem-Norm | Verbindliches EU-Recht | | Was sie hervorbringt | Ein zertifizierbares PIMS | Rechtliche Pflichten und individuelle Rechte | | Aufbauend auf | ISO 27001 / ISO 27002 | Datenschutzgrundsätzen | | Geprüft durch | Akkreditierte Zertifizierungsstelle | Aufsichtsbehörden und Gerichte | | Beziehung | Bildet auf Compliance ab und unterstützt sie | Die Pflicht, die 27701 Ihnen zu erfüllen hilft | Der saubere Weg, sie zu betreiben, besteht darin, den Datenschutz an demselben ISMS zu verankern, das Sie für die Sicherheit nutzen, das kombinierte System nach ISO 27001 plus ISO 27701 zu zertifizieren und Ihren Datenschutzbeauftragten und Ihr Rechtsteam als Eigentümer des Gesetzes selbst zu belassen. Die Norm übernimmt die operative Disziplin; sie übernehmen die Auslegung. --- ## ISO/IEC 42001 (ISO 42001) **URL:** https://cyberacademy.net/de/resources/encyclopedia/iso-42001 **Last reviewed:** 2026-06-24 ISO 42001 ist der erste internationale Standard für KI-Managementsysteme, veröffentlicht Ende 2023. Das AIMS-Äquivalent zum ISMS gemäß ISO 27001. Konzipiert für Organisationen, die KI-Design, -Einsatz und -Betrieb steuern müssen: Risiko, Verantwortlichkeit, Transparenz, kontinuierliche Verbesserung. Deckt sich direkt mit den Hochrisikopflichten des AI Act. ## Was die Norm ISO/IEC 42001 tatsächlich regelt ISO/IEC 42001 ist die erste zertifizierbare Managementsystemnorm, die der künstlichen Intelligenz gewidmet ist. Sie schreibt Ihnen nicht vor, welches Modell Sie trainieren oder wie Sie ein neuronales Netz abstimmen sollen. Stattdessen definiert sie ein KI-Managementsystem (AIMS): die Richtlinien, Rollen, Prozesse und Maßnahmen, die eine Organisation einführt, um KI verantwortungsvoll zu entwickeln, bereitzustellen oder zu nutzen. Wenn Sie ISO 27001 bereits kennen, lässt sich das mentale Modell direkt übertragen. Während das ISMS Informationen schützt, steuert das AIMS den Lebenszyklus von KI-Systemen, vom beabsichtigten Zweck und der Datenbeschaffung über die Bereitstellung und Überwachung bis zur Außerbetriebnahme. Die Norm folgt derselben High-Level Structure wie ISO 27001 und ISO 9001: Kontext der Organisation, Führung, Planung, Unterstützung, Betrieb, Bewertung der Leistung und Verbesserung. Dieses gemeinsame Grundgerüst ist beabsichtigt. Es ermöglicht Ihnen, das AIMS an ein bestehendes integriertes Managementsystem anzudocken, statt ein paralleles Governance-Silo zu betreiben. Die KI-spezifische Substanz steckt in den Anhängen, die Referenzmaßnahmen und Umsetzungsleitlinien zu Themen wie Rechenschaftspflicht, Datenqualität, Transparenz gegenüber Nutzern, menschliche Aufsicht und Folgenabschätzung enthalten. ## Wie sie sich von ISO 27001 und einer generischen Risikorichtlinie unterscheidet Fachleute mit Sicherheitshintergrund nehmen oft an, dass ein ISMS KI bereits abdeckt. Das tut es nicht. ISO 27001 ist auf Vertraulichkeit, Integrität und Verfügbarkeit von Informationen ausgerichtet. ISO 42001 fügt Anliegen hinzu, die in einem Sicherheitsrahmen keinen natürlichen Platz haben: ob sich ein System fair verhält, ob seine Ergebnisse erklärbar sind, ob ein Mensch sinnvoll eingreifen kann und ob die KI nur für ihren angegebenen Zweck verwendet wird. Auch das Risikodenken ist breiter angelegt. Eine Risikobeurteilung nach 42001 wägt Auswirkungen auf Einzelpersonen und die Gesellschaft ab, nicht nur auf die Organisation, weshalb eine KI-Folgenabschätzung eine eigenständige, benannte Tätigkeit innerhalb der Norm ist. > **AIMS und ISMS ergänzen sich, sie sind nicht redundant** Organisationen, die ISO 27001 besitzen, erweitern in der Regel ihre bestehende Governance, anstatt sie neu aufzubauen. Die Referenzmaßnahmen aus Anhang A von ISO 42001 stehen neben den Sicherheitsmaßnahmen, nicht innerhalb dieser, und die beiden Zertifizierungen können Audits, das Engagement der Leitung und Verbesserungszyklen gemeinsam nutzen. ## Warum sie für die EU-KI-Verordnung (EU AI Act) wichtig ist ISO 42001 bildet die Erwartungen des AI Act an Hochrisikosysteme sauber ab. Die Verordnung verlangt von Anbietern von Hochrisiko-KI, ein Risikomanagementsystem zu betreiben, eine Daten-Governance zu unterhalten, technische Dokumentation zu führen, menschliche Aufsicht sicherzustellen und eine Überwachung nach dem Inverkehrbringen durchzuführen. Genau diese Disziplinen institutionalisiert ein AIMS. Ein zertifiziertes Managementsystem ersetzt nicht die rechtliche Konformität, und eine Zertifizierung allein macht ein System nicht konform. Was sie leistet, ist eine prüfbare, wiederholbare Struktur, die Sorgfalt nachweist und die Erfüllung der Pflichten des AI Act zu einer Frage des Betriebs eines bestehenden Systems macht, statt zu einer Improvisation unter Termindruck. ## Wie die Umsetzung in der Praxis aussieht Teams, die 42001 einführen, durchlaufen in der Regel eine wiedererkennbare Abfolge: 1. Den Anwendungsbereich festlegen: welche KI-Systeme, genutzt von wem, zu welchem beabsichtigten Zweck und wo die Organisation in der Lieferkette steht (Entwickler, Anbieter, Betreiber). 1. Die KI-Risikobeurteilung und die Folgenabschätzung durchführen, dabei Risiken für Menschen und die Organisation ermitteln und Maßnahmen zu ihrer Behandlung auswählen. 1. Klare Rechenschaftspflicht zuweisen, sodass ein benannter Verantwortlicher für jedes KI-System über dessen gesamten Lebenszyklus zuständig ist. 1. Eine dem Risikoniveau angemessene Daten-Governance, Transparenzmechanismen und menschliche Aufsicht einrichten. 1. Systeme im Betrieb überwachen, Vorfälle und Rückmeldungen erfassen und sie in die kontinuierliche Verbesserung zurückführen. Die Zertifizierung ist optional, wird aber zunehmend von Enterprise-Käufern und Beschaffungsteams gefordert, die eine unabhängige Bestätigung wünschen, dass ein KI-Anbieter seine Systeme steuert, statt sie blind auszuliefern. --- ## Identity and Access Management (IAM) **URL:** https://cyberacademy.net/de/resources/encyclopedia/iam **Last reviewed:** 2026-06-24 IAM ist die Disziplin, die regelt, wer auf was zugreifen darf, wann, wie und unter welchen Bedingungen. Provisionierung, Authentifizierung, Autorisierung, Deprovisionierung. Die Identität ist der neue Perimeter. Jede Zero-Trust-Architektur ist im Kern ein anspruchsvolles IAM-Problem, das als Netzwerkproblem verkleidet ist. ## Was IAM tatsächlich umfasst Identity and Access Management ist die operative Disziplin, die entscheidet, wer auf was zugreifen darf, wann, wie und unter welchen Bedingungen. In der Praxis baut sie auf einer kleinen Gruppe wiederholbarer Funktionen auf: Bereitstellung einer Identität, wenn eine Person oder ein Dienst hinzukommt, Authentifizierung dieser Identität im Moment des Zugriffs, Autorisierung der konkret erlaubten Aktionen und Ressourcen sowie Entzug der Identität, wenn die Rolle oder Beziehung endet. Der schwierige Teil ist selten ein einzelner Anmeldebildschirm. Es geht darum, die Verbindung zwischen einer realen Person, ihren digitalen Identitäten und ihren angesammelten Berechtigungen über die Zeit hinweg konsistent zu halten, über Dutzende von Systemen hinweg, die jeweils ihre eigene Vorstellung davon haben, was ein Konto ist. Ein nützliches Denkmodell ist der Identitätslebenszyklus. Eintretende erhalten Konten und einen Basiszugriff. Wechselnde gehen von einem Team ins andere und sollten alte Berechtigungen verlieren, während sie neue erhalten. Austretende müssen sauber abgeschnitten werden. Die meisten Zugriffsvorfälle lassen sich auf ein Versagen in diesem Lebenszyklus zurückführen: verwaiste Konten, die nie deaktiviert wurden, oder Berechtigungen, die sich anhäuften, weil Zugriff gewährt, aber nie überprüft wurde. IAM ist das System, das den Ablauf von Eintritt, Wechsel und Austritt zuverlässig macht statt zu einem manuellen Gewusel. ## Identität als Perimeter IAM ist heute wichtiger, weil die Netzwerkgrenze aufgehört hat, eine sinnvolle Kontrolle zu sein. Nutzer verbinden sich von überall, Workloads laufen über mehrere Cloud-Anbieter hinweg, und Maschinenidentitäten (Dienstkonten, API-Schlüssel, Workload-Token) sind oft zahlreicher als menschliche. Wenn es kein Innen und Außen mehr zu verteidigen gibt, wird die Identität zur Linie, die über den Zugriff entscheidet. Das ist die Kernerkenntnis hinter Zero Trust: standardmäßig niemals vertrauen, jede Anfrage gegen Identität, Geräteposture und Kontext prüfen. Eine Zero-Trust-Architektur ist im Kern ein anspruchsvolles IAM-Problem, das sich als Netzwerkproblem verkleidet. IAM ist außerdem der Ort, an dem mehrere angrenzende Kontrollen ansetzen. Die Multi-Faktor-Authentifizierung stärkt den Authentifizierungsschritt. Privileged Access Management schützt die kleine Zahl von Identitäten, die den größten Schaden anrichten können. Das Prinzip der geringsten Rechte ist die Richtlinie, die IAM durchsetzt: nur den Zugriff gewähren, den eine Rolle wirklich benötigt, und nicht mehr. Behandeln Sie diese als Schichten desselben Problems und nicht als getrennte Projekte. > **Die Zugriffsüberprüfung ist nicht optional** Zugriff zu gewähren ist einfach und ihn zu überprüfen ist mühsam, daher driften Berechtigungen mit der Zeit nach oben. Die periodische Zugriffszertifizierung, bei der Verantwortliche erneut bestätigen, wer was behalten soll, ist die Kontrolle, die das Anwachsen von Privilegien erkennt, bevor es ein Auditor oder ein Angreifer tut. ## Governance- und Standardkontext IAM steht im Zentrum der meisten Sicherheitsframeworks, weil die Zugriffskontrolle grundlegend ist. ISO/IEC 27001 behandelt Zugriffskontrolle und Identitätsmanagement als zentrale Kontrollbereiche eines Informationssicherheits-Managementsystems und erwartet von Organisationen, dass sie eine Zugriffskontrollrichtlinie definieren, den Benutzerzugriff über den gesamten Lebenszyklus verwalten und Zugriffsrechte überprüfen. Das NIST Cybersecurity Framework ordnet Identitätsmanagement und Zugriffskontrolle den Schutzfunktionen zu, die jedes Programm abdecken sollte. Bei regulierten Daten unterstützt die Zugriffsdisziplin auch die Datenschutzpflichten nach der GDPR, da die Beschränkung, wer personenbezogene Daten erreichen kann, Teil des Nachweises angemessener technischer Maßnahmen ist. Was Praktiker tatsächlich tun, spiegelt dies wider. Sie bauen autoritative Identitätsquellen auf, automatisieren Bereitstellung und Entzug, zentralisieren die Authentifizierung über Single Sign-on, modellieren Berechtigungen nach Möglichkeit als Rollen, führen wiederkehrende Zugriffsüberprüfungen durch und pflegen einen Prüfpfad darüber, wem was und warum gewährt wurde. Gut umgesetzt ist IAM für die Nutzer unsichtbar und gegenüber Auditoren nachweisbar. Schlecht umgesetzt ist es die stille Grundursache hinter einem großen Anteil der Sicherheitsverletzungen. --- ## Information Systems Audit and Control Association (ISACA) **URL:** https://cyberacademy.net/de/resources/encyclopedia/isaca **Last reviewed:** 2026-06-24 ISACA ist die globale Vereinigung für IT-Audit-, Sicherheits-, Risiko- und Governance-Fachleute. Gegründet 1969, Hauptsitz Schaumburg IL, über 165.000 Mitglieder in 188 Ländern. Vergibt CISA, CISM, CRISC, CGEIT, CDPSE, AAIA, CCOA. Veröffentlicht COBIT. Cyber Academy ist ein ISACA Accredited Premium Partner. ## Was ISACA tatsächlich ist ISACA wurde 1969 als Information Systems Audit and Control Association gegründet, eine Gruppe von IT-Prüfern, die einen gemeinsamen Wissensbestand und eine Möglichkeit benötigten, sich gegenseitig die Kompetenz zu bescheinigen. Der vollständige Name ist heute weitgehend historisch; die Organisation tritt als ISACA auf und richtet sich an Fachleute aus IT-Audit, Sicherheit, Risiko, Governance und Datenschutz in mehr als 180 Ländern. Entscheidend ist in der Praxis, dass ISACA weder eine Regulierungsbehörde noch ein Normungsgremium im Sinne der ISO ist. Sie schreibt keine Gesetze und kann kein Unternehmen zertifizieren. Sie zertifiziert Personen und veröffentlicht Frameworks, auf die sich der Rest des Berufsstands stützt. Diese Unterscheidung bringt Neulinge ins Stolpern. Ein Unternehmen kann nicht «ISACA-zertifiziert» werden, so wie man ein ISO 27001-Managementsystem zertifiziert. ISACA-Zertifizierungen liegen bei den Einzelpersonen. Ein Prüfer erwirbt die CISA, ein Sicherheitsmanager die CISM, ein Risikofachmann die CRISC. Der Wert des Nachweises ergibt sich aus der Strenge der Prüfung, der dokumentierten Anforderung an Berufserfahrung, dem berufsethischen Kodex und der kontinuierlichen beruflichen Weiterbildung, die ihn aktuell hält. Arbeitgeber und Prüfungsausschüsse werten diese als Beleg dafür, dass die Person unabhängig an einer definierten Praxis gemessen wurde. ## Die Zertifizierungsfamilie und wofür jede steht Die Zertifizierungen von ISACA sind bewusst rollenspezifisch ausgelegt und nicht als eine allgemeine Qualifikation. Jede entspricht einer eigenen Tätigkeitsfunktion, weshalb Praktiker oft mehr als eine besitzen, wenn ihre Laufbahn von der Ausführung der Arbeit zu deren Steuerung übergeht. **ISACA-Zertifizierungen nach beruflicher Rolle** | Zertifizierung | Zielgruppe | Schwerpunkt | | --- | --- | --- | | CISA | IS-Prüfer | Prüfung, Kontrolle und Assurance von Informationssystemen | | CISM | Sicherheitsmanager | Governance und Management eines Informationssicherheitsprogramms | | CRISC | Risikofachleute | Identifikation und Behandlung von IT- und Unternehmensrisiken | | CGEIT | Governance-Verantwortliche | Governance der Unternehmens-IT auf Vorstandsebene | | CDPSE | Datenschutz-Ingenieure | Datenschutz durch Technikgestaltung im Technologie-Stack | | AAIA | KI-Prüfer | Prüfung von Systemen und Kontrollen künstlicher Intelligenz | | CCOA | Cyber-Operationen | Praxisnaher Cybersicherheitsbetrieb und -abwehr | > **ISACA zertifiziert Personen, ISO zertifiziert Systeme** Wenn jemand sagt, ein Unternehmen sei «ISACA-akkreditiert», meint er in der Regel, dass seine Mitarbeiter ISACA-Zertifizierungen besitzen oder dass es ein anerkannter ISACA-Schulungspartner ist. Ein Unternehmen selbst ist nicht gegen einen ISACA-Standard zertifiziert. Dafür sind ISO 27001 und ähnliche zertifizierbare Standards da. ## COBIT und ISACAs Platz in der Normenlandschaft Über die Zertifizierung von Einzelpersonen hinaus veröffentlicht ISACA COBIT, das Framework für die Governance und das Management der Unternehmens-IT. Mit COBIT kommt ISACA dem Handeln eines Normungsgremiums am nächsten, doch es bleibt ein Framework, das man übernimmt und anpasst, statt eines Standards, gegen den man zertifiziert wird. Prüfer greifen zu COBIT, wenn ein Informationssicherheitsstandard allein zu eng ist, weil es abdeckt, wie die IT als Ganzes auf die Unternehmensziele ausgerichtet wird. Deshalb werden ISACA, NIST und ISO meist gemeinsam genannt: NIST liefert Kontrollkataloge und Ergebnisse, ISO liefert zertifizierbare Managementstandards, und ISACA liefert die Audit- und Governance-Perspektive sowie die Personen, die qualifiziert sind, sie anzuwenden. Für eine Schulungsorganisation ist das Partnerprogramm von ISACA wichtig, weil die Prüfungsvorbereitung einem akkreditierten Lehrplan folgen muss, um Gewicht zu haben. Cyber Academy ist ein ISACA Accredited Premium Partner, also die Anerkennung, die ISACA Schulungsanbietern gewährt, die ihren Qualitätsmaßstab für die Durchführung der offiziellen Vorbereitung auf Zertifizierungen erfüllen. Diese Akkreditierung betrifft den Anbieter; sie ersetzt nicht, dass die Einzelperson die ISACA-Prüfung besteht und die Erfahrungsanforderung erfüllt. --- ## Informationssicherheits-Managementsystem (ISMS) **URL:** https://cyberacademy.net/de/resources/encyclopedia/isms **Last reviewed:** 2026-06-24 Ein ISMS ist das dokumentierte System, das Sie zum Schutz von Informationswerten betreiben: risikobasiert, belegt durch Nachweise, unter Management-Review. Es ist kein Ordner voller Richtlinien. Auditoren bewerten nicht Ihre Richtlinien; sie bewerten Ihre operativen Nachweise. Plan-Do-Check-Act-Zyklus, zertifiziert nach ISO/IEC 27001, mit der SoA als zentralem Artefakt. ## Was ein ISMS wirklich ist Ein Informationssicherheits-Managementsystem ist das Betriebssystem, das Sie betreiben, um Informationswerte auf bewusste, wiederholbare Weise zu schützen. Das wichtigste Wort ist „System“. Es sind nicht die Sicherheitswerkzeuge, und es ist kein Ordner mit genehmigten Richtlinien auf einem freigegebenen Laufwerk. Es ist die Gesamtheit der Prozesse, Rollen, Entscheidungen und Aufzeichnungen, mit denen eine Organisation bestimmt, welche Informationen sie schützen muss, entscheidet, wie viel Risiko sie zu akzeptieren bereit ist, Maßnahmen zur Behandlung dieses Risikos auswählt und dann nachweist, dass diese Maßnahmen im Laufe der Zeit tatsächlich wirken. Eine Richtlinie sagt, was geschehen soll. Ein ISMS ist die Maschinerie, die es geschehen lässt und den Nachweis erzeugt, dass es geschehen ist. Die bestimmenden Merkmale sind, dass es risikobasiert und durch Nachweise belegt ist und dass es unter Managementbewertung betrieben wird. Risikobasiert bedeutet, dass Maßnahmen nicht aus einer Wunschliste ausgewählt, sondern durch eine dokumentierte Bewertung der Bedrohungen für bestimmte Werte begründet werden. Durch Nachweise belegt bedeutet, dass hinter jeder Maßnahme Artefakte stehen: durchgeführte Zugriffsüberprüfungen, überwachte Protokolle, behandelte Vorfälle, durchgeführte Schulungen. Managementbewertung bedeutet, dass die Leitung Eigentümerin des Systems ist, dessen Ziele festlegt und regelmäßig prüft, ob diese erreicht werden. Entfernen Sie eines dieser drei Elemente, dann haben Sie ein Sicherheitsprogramm, kein Managementsystem. ## Warum Auditoren Nachweise bewerten, nicht Richtlinien Ein verbreitetes und teures Missverständnis ist, dass es bei der Zertifizierung darum geht, eine gute Dokumentation zu haben. Das ist nicht so. Ein Zertifizierungsauditor setzt voraus, dass Sie eine kompetente Zugriffskontrollrichtlinie verfassen können. Was er prüfen soll, ist, ob Ihre betriebliche Wirklichkeit dem entspricht, was Ihre Dokumente behaupten. Er wird die letzte Zugriffsüberprüfung sehen wollen und prüfen, ob sie tatsächlich abgeschlossen wurde, Tickets stichprobenartig prüfen, um zu bestätigen, dass Änderungen autorisiert waren, und einen Vorfall von der Erkennung bis zu den gewonnenen Erkenntnissen nachverfolgen. Schöne Richtlinien ohne betrieblichen Nachweis dahinter fallen bei Audits durch. Deshalb beschreiben Praktiker das ISMS als etwas, das man betreibt, nicht als etwas, das man schreibt. > **Die SoA ist das zentrale Artefakt** Die Erklärung zur Anwendbarkeit ist der Punkt, an dem das ISMS auditierbar wird. Sie führt jede Referenzmaßnahme auf, gibt an, ob sie zutrifft, und begründet jede Einbeziehung oder jeden Ausschluss anhand der Ergebnisse der Risikobeurteilung. Ein Auditor liest die SoA zuerst, weil sie die Landkarte zwischen Ihren Risiken und Ihren Maßnahmen ist, und geht dann auf die Suche nach dem Nachweis, dass jede anwendbare Maßnahme wirklich wirkt. ## Plan-Do-Check-Act: wie das System am Leben bleibt Ein ISMS ist darauf ausgelegt, sich fortlaufend zu verbessern, statt einmalig perfektioniert zu werden. Die meisten Umsetzungen folgen dem Plan-Do-Check-Act-Zyklus, der das System ehrlich hält: 1. Plan: den Anwendungsbereich festlegen, Risiken beurteilen, Sicherheitsziele setzen und Maßnahmen zur Behandlung der von Ihnen ermittelten Risiken auswählen. 1. Do: diese Maßnahmen und die unterstützenden Prozesse im Tagesgeschäft umsetzen und betreiben. 1. Check: überwachen, messen, intern auditieren und Managementbewertungen durchführen, um zu sehen, ob die Maßnahmen wirken und die Ziele erreicht werden. 1. Act: korrigieren, was fehlschlägt, die Ursachen von Nichtkonformitäten angehen und die Verbesserungen in den nächsten Zyklus zurückführen. Diese Schleife ist es, die ein lebendiges ISMS von einem einmaligen Compliance-Kraftakt unterscheidet. Ein Risikoregister, das einmal im Jahr überprüft und danach nie wieder angefasst wird, ist in keinem sinnvollen Sinne ein ISMS, selbst wenn es irgendwann ein Zertifikat hervorgebracht hat. ## Wo es zwischen benachbarten Begriffen steht Das ISMS ist der Rahmen, zertifiziert nach ISO/IEC 27001, der internationalen Norm, die die Anforderungen festlegt, die ein Managementsystem erfüllen muss. ISO/IEC 27001 ist die zertifizierbare Anforderungsnorm; begleitende Leitfäden wie ISO/IEC 27005 unterstützen die Arbeit der Risikobeurteilung und Risikobehandlung, die sie speist. Häufig wird das ISMS mit den darin enthaltenen Maßnahmen verwechselt, doch die Maßnahmen sind Eingaben, die das System auswählt und betreibt. Sie sind nicht das System. Die Disziplin des ISMS besteht gerade darin, dass es jede Maßnahme auf ein Risiko zurückführt und jedes Risiko auf eine dokumentierte Entscheidung von Personen, die dafür rechenschaftspflichtig sind. --- ## Inhärentes vs. Restrisiko **URL:** https://cyberacademy.net/de/resources/encyclopedia/inherent-residual-risk **Last reviewed:** 2026-06-24 Das inhärente Risiko ist die Risikoexposition vor den Kontrollen. Das Restrisiko ist das, was nach dem Betrieb der Kontrollen verbleibt. Prüfer betrachten die Lücke: Sie muss begründet, von einem namentlich genannten Eigentümer akzeptiert (oder weiterbehandelt) und mit der Risikobereitschaft vereinbar sein. Ein "Restrisiko = null" im Register ist ein Warnsignal, kein Erfolg. ## Dasselbe Risiko zu zwei Zeitpunkten betrachtet Inhärentes Risiko und Restrisiko sind nicht zwei verschiedene Risiken. Sie sind dasselbe Szenario, gemessen an zwei Punkten: bevor Ihre Kontrollen wirken, und nachdem sie gewirkt haben. Das inhärente Risiko ist die rohe Exposition, das Maß an Eintrittswahrscheinlichkeit und Auswirkung, dem Sie ausgesetzt wären, wenn die relevanten Kontrollen fehlten oder vollständig versagten. Das Restrisiko ist das, was übrig bleibt, sobald die Kontrollen umgesetzt sind und wie vorgesehen wirken. Sie nebeneinander zu lesen, ist der ganze Sinn der Sache, denn die Differenz zwischen beiden ist der sichtbare Wert Ihres Kontrollumfelds. Eine große Differenz besagt, dass die Kontrollen ihren Beitrag leisten; eine geringe Differenz besagt, dass Sie Aufwand für eine geringe Reduktion betreiben und nach dem Grund fragen sollten. Diese Werte als Paar zu behandeln, ändert, wie Sie Mittel einsetzen. Wenn zwei Szenarien ein ähnliches Restniveau aufweisen, eines aber von einem weit höheren inhärenten Niveau ausging, leistet das Kontrollset, das es niedrig hält, Schwerstarbeit und verdient Schutz im Budget. Das Szenario, das sich vom inhärenten zum Restrisiko kaum bewegt hat, ist dasjenige, das es zu überprüfen gilt: Entweder ist die Kontrolle schwach, es ist die falsche Kontrolle, oder das Risiko war nie so exponiert, wie die Bewertung behauptete. **Inhärentes Risiko und Restrisiko** | Dimension | Inhärentes Risiko | Restrisiko | | --- | --- | --- | | Zeitpunkt der Messung | Vor den Kontrollen | Nachdem die Kontrollen wirken | | Was es zeigt | Rohe Exposition des Szenarios | Exposition, die tatsächlich verbleibt | | Hauptzweck | Priorisieren, wo Kontrollen nötig sind | Über Akzeptieren, weitere Behandlung oder Transfer entscheiden | | Verglichen mit | Andere unbehandelte Szenarien | Der Risikoappetit und die Risikotoleranz | | Maßnahme des Verantwortlichen | Die Behandlung gestalten | Akzeptieren und unterzeichnen, oder die Differenz eskalieren | ## Was Auditoren und Normen erwarten Die Differenz zwischen inhärentem Risiko und Restrisiko ist der Ort, an dem die Assurance liegt, daher muss sie begründet und nicht behauptet werden. Ein Auditor liest das Register und verlangt von jedem Restwert drei Dinge: welche Kontrollen ihn reduziert haben, ob diese Kontrollen tatsächlich wirken statt nur dokumentiert zu sein, und wer das Verbleibende akzeptiert hat. Dieser letzte Punkt ist wichtig. Das Restrisiko wird von einem namentlich benannten Verantwortlichen mit der Befugnis, es zu tragen, akzeptiert, und diese Akzeptanz muss innerhalb des Risikoappetits der Organisation liegen. Ein Restniveau, das den Appetit übersteigt, ist kein abgeschlossener Eintrag; es ist ein offener Punkt, der weitere Behandlung, Transfer oder eine bewusste, dokumentierte Ausnahme verlangt. Diese Logik ist in den wichtigsten Rahmenwerken verankert. ISO 31000 fasst das Risikomanagement als iterative Schleife auf, in der die Behandlung das Risiko verändert und das veränderte Risiko anschließend neu bewertet wird, was genau dem Übergang vom inhärenten Risiko zum Restrisiko entspricht. ISO/IEC 27005 wendet dasselbe Denken auf das Informationssicherheitsrisiko an und verlangt ausdrücklich, dass das Restrisiko bewertet und vom Management förmlich akzeptiert werden muss, bevor ein System in Betrieb geht oder im Produktivbetrieb bleibt. Die NIST-Leitlinien zur Risikobewertung tragen die identische Unterscheidung zwischen dem Risiko, dem eine Organisation ausgesetzt ist, und dem Anteil, der nach Anwendung der Reaktionen verbleibt. Keine dieser Normen behandelt das Restrisiko als eine Zahl, die man einmal berechnet und ablegt. > **Ein Restrisiko von null ist ein Warnsignal, keine Trophäe** Ein Register, das ein auf null reduziertes Restrisiko zeigt, ist fast immer falsch, denn kein Kontrollset ist perfekt und Kontrollen selbst versagen. Null bedeutet meist, dass jemand das Ziel mit der Realität verwechselt oder stillschweigend aufgehört hat, das Versagen von Kontrollen zu berücksichtigen. Auditoren lesen es als Reifeproblem, nicht als Erfolg. ## Es in der Praxis gut machen In einem funktionierenden Register sollte jede Zeile es einem Leser erlauben, die inhärente Bewertung, die angewandten Kontrollen, die Restbewertung und den namentlich benannten Verantwortlichen, der sie akzeptiert hat, nachzuvollziehen. Halten Sie die Bewertungsmethode zwischen inhärentem Risiko und Restrisiko konsistent, damit beide wirklich vergleichbar sind; wenn Sie Auswirkung und Eintrittswahrscheinlichkeit auf jeder Stufe unterschiedlich bewerten, bedeutet die Differenz nichts. Bewerten Sie das Restrisiko jedes Mal neu, wenn sich eine Kontrolle ändert, verschlechtert oder bei Tests als unwirksam erweist, denn das Restrisiko ist nur so aktuell wie die Kontrollen, die dahinterstehen. Ein Restwert, der vor zwei Audits festgelegt und nie überprüft wurde, ist Dekoration, keine Assurance. Das Urteil, das sich auszahlt, besteht darin, das Restrisiko mit dem Appetit und der Behandlung zu verknüpfen. Sobald das Restrisiko auf oder unter dem Appetit liegt, ist die Akzeptanz vertretbar und der Verantwortliche unterzeichnet. Liegt es darüber, hält der ehrliche Eintrag die Differenz und den Plan zu ihrer Schließung fest, anstatt die Zahl abzurunden, damit die Seite ordentlich aussieht. Diese Disziplin ist es, die ein Register von einem Compliance-Artefakt in ein Werkzeug verwandelt, das der Vorstand tatsächlich nutzen kann, um Aufmerksamkeit zuzuteilen. --- ## Lead Auditor **URL:** https://cyberacademy.net/de/resources/encyclopedia/lead-auditor **Last reviewed:** 2026-06-24 Lead Auditor ist das PECB-Credential für Praktiker, die Drittpartei- oder interne Audits eines Managementsystems planen und leiten können. Fünftägiger Kurs auf Basis von ISO 19011. Einstiegspunkt für eine Karriere als Auditor bei einer akkreditierten Zertifizierungsstelle. Andere Denkweise als beim Lead Implementer: Nachweise, Stichproben, Berichterstattung, Interviewtechnik. ## Was die Qualifikation Lead Auditor zertifiziert Lead Auditor ist die PECB-Zertifizierung für Praktiker, die ein Audit eines Managementsystems planen, leiten und darüber berichten können, sei es ein Zertifizierungsaudit durch eine dritte Partei, ein Lieferantenaudit oder ein umfangreiches internes Audit. Der Kurs erstreckt sich über fünf Tage und baut unmittelbar auf ISO 19011 auf, der Leitnorm für das Auditieren von Managementsystemen. Was Sie am Ende zertifizieren, ist nicht, dass Sie eine Norm wie ISO 27001 abstrakt verstehen, sondern dass Sie ein Auditteam dagegen führen können: den Auftrag abgrenzen, Nachweise stichprobenartig prüfen, Interviews führen, Feststellungen formulieren, die einer Anfechtung standhalten, und das Audit zu einer belastbaren Schlussfolgerung bringen. Die Qualifikation besteht aus einem konkreten beruflichen Grund. Sie ist der anerkannte Einstieg, um akkreditierter Auditor einer Zertifizierungsstelle zu werden, also die Person, die im Auftrag einer Zertifizierungsstelle entscheidet, ob eine Organisation ihr Zertifikat erhält oder behält. Zertifizierungsstellen arbeiten nach ISO/IEC 17021-1 und benötigen Auditoren, die die in ISO 19011 beschriebene Kompetenz nachgewiesen haben. Lead Auditor ist die Art und Weise, wie Sie signalisieren, dass Sie über diese Kompetenz und die Führungsfähigkeiten verfügen, um das Team zu leiten, nicht nur daran teilzunehmen. ## Eine andere Denkweise als beim Lead Implementer Die häufigste Verwechslung besteht darin, Lead Auditor und Lead Implementer als zwei Spielarten derselben Qualifikation zu behandeln. Sie sind entgegengesetzte Haltungen. Der Implementierer baut das Managementsystem auf: Er verfasst die Richtlinien, gestaltet die Maßnahmen, führt die Risikobeurteilung durch und bereitet die Organisation auf die Zertifizierung vor. Der Auditor beurteilt unabhängig, ob das, was aufgebaut wurde, tatsächlich existiert und funktioniert. Dieselbe Person sollte nicht beides am selben System tun, weil der Implementierer seine eigene Arbeit nicht glaubwürdig absichern kann. Diese Unabhängigkeit ist der einzige Grund, weshalb die Rolle des Auditors überhaupt existiert. In der Praxis dreht sich die Denkweise des Auditors um Nachweise, nicht um Beratung. Wo der Implementierer fragt, wie eine Maßnahme wirksam gemacht werden kann, fragt der Auditor, welcher Nachweis belegt, dass die Maßnahme wie beschrieben funktioniert, wie repräsentativ die Stichprobe ist und ob die Feststellung Bestand hat, wenn der Auditierte Widerspruch einlegt. Der Lead-Auditor-Kurs verwendet den Großteil seiner Energie auf diese Fähigkeiten statt auf die Norm selbst: - Stichprobenziehung: Nachweise auswählen, die das Ganze fair abbilden, und nicht die Teile, die zufällig gut aussehen. - Interviewtechnik: herausarbeiten, wie die Arbeit tatsächlich erledigt wird, ohne den Befragten zu beeinflussen. - Feststellungen und Berichterstattung: Nichtkonformitäten einstufen, sie objektiv und nachvollziehbar formulieren und zu einer Schlussfolgerung gelangen. - Auditleitung: ein Auditteam, die Eröffnungs- und Abschlussbesprechungen sowie die Beziehung zum Auditierten steuern. > **Die Normbezeichnung wandert mit dem System** Ein Lead-Auditor-Kurs ist stets an eine bestimmte Norm gebunden, zum Beispiel ISO 27001 Lead Auditor oder ISO 9001 Lead Auditor. Die Auditmethode stammt aus ISO 19011 und ist allen gemeinsam, aber Sie schulen und zertifizieren sich gegen die Anforderungen des Managementsystems, das Sie auditieren wollen. ## Wo der Lead Auditor unter den benachbarten Qualifikationen steht Der Lead Auditor lässt sich am besten neben den Qualifikationen verstehen, mit denen Praktiker ihn vergleichen. Innerhalb der PECB- und ISO-Welt bildet er mit dem Lead Implementer als Assurance-Gegenstück ein Paar. Gegenüber ISACA zertifiziert auch die Qualifikation CISA Auditkompetenz, doch handelt es sich um eine breite IT-Audit-Qualifikation, die an die ISACA-Domänen gebunden ist, und nicht um eine Qualifikation zum Auditieren eines bestimmten benannten Managementsystems nach ISO 19011. **Lead Auditor im Vergleich zu benachbarten Qualifikationen** | Qualifikation | Haltung | Was sie zertifiziert | | --- | --- | --- | | Lead Auditor | Unabhängige Assurance | Ein Audit eines Managementsystems nach ISO 19011 planen und leiten | | Lead Implementer | Aufbauen und betreiben | Ein Managementsystem mit Blick auf die Zertifizierung gestalten und betreiben | | CISA | IT-Audit-Assurance | Breites Audit von Informationssystemen über die ISACA-Domänen hinweg | Die Wahl zwischen beiden richtet sich nach der Arbeit, die Sie ausüben wollen. Wenn Ihre Zukunft im Durchführen von Zertifizierungs- oder Lieferantenaudits oder im Leiten eines strengen internen Auditprogramms liegt, ist Lead Auditor der direkte Weg. Wenn Ihre Aufgabe darin besteht, das Managementsystem selbst aufzubauen und zu verbessern, passt Lead Implementer besser. Viele erfahrene Praktiker halten beide, denn zu verstehen, wie ein System aufgebaut wird, macht Sie zu einem schärferen Auditor, und zu verstehen, wie es auditiert wird, macht Sie zu einem besseren Implementierer. --- ## Lead Ethical Hacker **URL:** https://cyberacademy.net/de/resources/encyclopedia/lead-ethical-hacker **Last reviewed:** 2026-06-24 Lead Ethical Hacker ist die PECB-zertifizierte Qualifikation für Offensive-Security-Fachleute. Sie umfasst Methodik, Scoping, Reconnaissance, Exploitation, Reporting und Ethik. Die Akkreditierungsergänzung zu praxisorientierten Zertifizierungen wie OSCP und CRTO. Ideal kombiniert mit Lead Penetration Testing Professional für die Leitung von Einsätzen. Lead Ethical Hacker ist die PECB-Zertifizierung für Fachleute der offensiven Sicherheit: jene Personen, die autorisiert werden, ein System anzugreifen, damit eine Organisation erfährt, wo sie tatsächlich versagen würde. Sie ist um den gesamten Lebenszyklus eines Auftrags herum aufgebaut und nicht um einen einzelnen Kniff. Von einem Inhaber wird erwartet, dass er einen Auftrag abgrenzt, Aufklärung betreibt, Schwachstellen findet und ausnutzt und diese Arbeit anschließend in einen Bericht überführt, auf dessen Grundlage Entscheidungsträger handeln können, und das alles innerhalb eines klaren ethischen und rechtlichen Rahmens. Wo viele offensive Zertifizierungen belegen, dass man im Labor eine Maschine kompromittieren kann, positioniert sich Lead Ethical Hacker als das Akkreditierungspendant zu dieser praktischen Fähigkeit: ein herstellerneutrales, an ISO ausgerichtetes Signal, dass man einen Ethical-Hacking-Auftrag von Anfang bis Ende durchführen und nicht nur ausnutzen kann. ## Was die Zertifizierung abdeckt Die Zertifizierung folgt dem Bogen eines realen Auftrags, sodass die Kompetenzen, die sie bestätigt, den Phasen entsprechen, die ein Tester im Verlauf einer Bewertung durchläuft. - Abgrenzung und Rules of Engagement: Festlegen von Zielen, Grenzen, Autorisierung und dem, was ausdrücklich außerhalb der Reichweite liegt, bevor auch nur ein einziges Paket gesendet wird. - Aufklärung und Enumeration: Aufbau eines Bildes der Angriffsfläche aus offenen Quellen und aktivem Sondieren. - Ausnutzung: identifizierte Schwachstellen nutzen, um eine konkrete, mit Belegen unterlegte Auswirkung statt eines theoretischen Risikos aufzuzeigen. - Post-Exploitation und Pivoting: zeigen, wie weit ein Angreifer vernünftigerweise gelangen könnte, sobald ein Standbein vorhanden ist. - Berichterstattung: Befunde in priorisierte, reproduzierbare und für das Geschäft verständliche Empfehlungen zur Behebung übersetzen. - Ethik und Recht: innerhalb des Mandats bleiben, sensible Befunde verantwortungsvoll handhaben und den Kunden während des gesamten Auftrags schützen. > **Eine Akkreditierung, kein Ersatz für praktische Labore** Lead Ethical Hacker ist die Methodik- und Urteilsebene. Sie ergänzt sich auf natürliche Weise mit praktischen, im Labor bewerteten Zertifizierungen wie OSCP oder CRTO. Betrachten Sie sie als Beleg dafür, dass Sie einen Auftrag nach einem anerkannten Standard leiten und dokumentieren können, neben praktischen Zertifizierungen, die die reine Ausnutzungsfähigkeit nachweisen. ## Wie sie sich von benachbarten Konzepten unterscheidet Ethical Hacking und Penetrationstest überschneiden sich stark und die Begriffe werden oft austauschbar verwendet, sind aber nicht identisch. Ein Penetrationstest ist eine abgegrenzte, zeitlich begrenzte Übung mit einem definierten Ziel und einem Bericht. Ethical Hacking ist die umfassendere Disziplin und Denkweise, Systeme mit Erlaubnis anzugreifen, um ihre Sicherheit zu verbessern, wovon ein strukturierter Penetrationstest eine Ausprägung ist. Es unterscheidet sich zudem von einem Red-Team-Auftrag, der eine längere, zielgerichtete Simulation ist, die Erkennung und Reaktion ebenso prüft wie die Kontrollen selbst, sowie vom automatisierten Schwachstellen-Scan, der Breite gegenüber der manuellen Ausnutzung und dem Urteilsvermögen bevorzugt, das ein Tester einbringt. **Lead Ethical Hacker unter den Zertifizierungen für offensive Sicherheit** | Zertifizierung | Schwerpunkt | Am besten zu verstehen als | | --- | --- | --- | | Lead Ethical Hacker | Auftragsmethodik, Abgrenzung, Berichterstattung, Ethik | Akkreditierung, dass Sie einen Auftrag durchführen können | | OSCP / CRTO | Praktische Ausnutzung in bewerteten Laboren | Nachweis praktischer Angriffsfähigkeit | | Lead Penetration Testing Professional | Leitung und Steuerung eines Testprogramms | Begleiter für die Auftragsführung | Wie die Kurzdefinition anmerkt, ergänzt sich die Zertifizierung mit Lead Penetration Testing Professional für jene, die sich in Richtung Auftragsführung bewegen: die eine konzentriert sich auf den Akt des Ethical Hacking, die andere auf die Verantwortung für den Testprozess in einer gesamten Organisation. ## Für wen sie geeignet ist Sie passt zu Fachleuten, die bereits offensive Arbeit leisten oder dorthin wechseln: Penetrationstester, Red-Team-Mitglieder und Sicherheitsberater, die eine anerkannte, an Standards ausgerichtete Zertifizierung möchten, die widerspiegelt, wie sie Aufträge durchführen, und nicht nur, dass sie eine Schwachstelle finden können. Da PECB-Zertifizierungen herstellerneutral und an ISO ausgerichtet sind, liegt der Wert in einem strukturierten, international lesbaren Signal der Kompetenz. Wie immer bewerten Arbeitgeber die nachgewiesene Fähigkeit, sodass das stärkste Profil diese Akkreditierung mit praktischen Zertifizierungen und einer Bilanz realer, autorisierter Tests verbindet. --- ## Lead Implementer **URL:** https://cyberacademy.net/de/resources/encyclopedia/lead-implementer **Last reviewed:** 2026-06-24 Lead Implementer ist die PECB-Zertifizierung für Praktiker, die ein Managementsystem auf Basis einer spezifischen ISO-Norm (in der Regel ISO/IEC 27001, ISO/IEC 42001 oder ISO 22301) planen, aufbauen und betreiben können. Fünftägiger Kurs, Prüfung, Zertifikat. Der implementierungsseitige Teil der ISO-Disziplin; ergänzt den Lead Auditor auf der Prüfungsseite. ## Was ein Lead Implementer tatsächlich tut Ein Lead Implementer ist die Person, die eine ISO-Managementsystemnorm nimmt und sie in etwas verwandelt, das eine reale Organisation täglich betreibt. Während die Norm sagt, was vorhanden sein muss, entscheidet der Lead Implementer, wie man dorthin gelangt: den Anwendungsbereich des Systems festlegen, das Engagement der Leitung sichern, die Risikobeurteilung durchführen, die Maßnahmen und Verfahren auswählen und verfassen, die Personen schulen, die sie betreiben werden, und das gesamte Vorhaben bis zu dem Punkt steuern, an dem eine Zertifizierungsstelle es auditieren kann. Die Zertifizierung selbst, von PECB nach einem fünftägigen Kurs und einer Prüfung verliehen, bescheinigt, dass Sie diese Arbeit leiten können und sie nicht nur beschreiben. Im Alltag ist die Rolle teils Projektmanager, teils Fachexperte, teils interner Diplomat. Die meisten ISO-Implementierungen scheitern nicht an den technischen Maßnahmen, sondern an der umgebenden Arbeit: die oberste Leitung dazu zu bewegen, das Projekt zu tragen, sich auf den Anwendungsbereich zu einigen, Rollen zu definieren und die dokumentierte Information so zu verankern, dass sie das erste Audit übersteht und danach weiterlebt. PECB strukturiert seine Lead-Implementer-Schulung um eine phasenweise Implementierungsmethode, sodass die Teilnehmer mit einer wiederholbaren Abfolge herausgehen, der sie folgen können, statt mit einem Stapel auswendig zu lernender Klauseln. ## Lead Implementer im Vergleich zum Lead Auditor Die beiden Flaggschiff-Zertifizierungen von PECB beschreiben die beiden Seiten der ISO-Disziplin. Ein Lead Implementer baut und betreibt das Managementsystem von innerhalb der Organisation. Ein Lead Auditor bewertet ein Managementsystem anhand der Norm, in der Regel von außen, und entscheidet, ob es konform ist. Sie teilen dieselbe zugrunde liegende Norm und einen großen Teil desselben Wissens, doch die Denkweise ist unterschiedlich: Der Implementer ist dafür verantwortlich, das System zum Laufen zu bringen, der Auditor ist dafür verantwortlich, es unparteiisch zu beurteilen. **Lead Implementer verglichen mit Lead Auditor** | Aspekt | Lead Implementer | Lead Auditor | | --- | --- | --- | | Hauptrolle | Das Managementsystem aufbauen, einführen und betreiben | Die Konformität anhand der Norm bewerten | | Blickwinkel | Innerhalb der Organisation | Unabhängig, oft Dritte | | Zentrales Ergebnis | Ein funktionierendes, zertifizierbares Managementsystem | Ein Auditbericht und ein Konformitätsurteil | | Referenz für die Methode | Ein phasenweiser Implementierungsansatz | ISO 19011 Auditleitlinien | In der Praxis ergänzen sich die Zertifizierungen, und viele Praktiker besitzen beide. Zu verstehen, wie ein Auditor das System prüfen wird, macht Sie zu einem schärferen Implementer, und selbst ein System aufgebaut zu haben, macht Sie zu einem glaubwürdigeren Auditor. Wer die Auditseite besser beherrschen möchte, kombiniert oft Lead Implementer mit dem Lead-Auditor-Pfad. > **Zertifiziert die Person, nicht die Organisation** Lead Implementer ist eine persönliche Zertifizierung. Sie besagt, dass Sie wissen, wie man ein Managementsystem nach einer bestimmten ISO-Norm aufbaut. Die Organisation wird weiterhin separat von einer akkreditierten Zertifizierungsstelle anhand der Norm selbst zertifiziert, etwa ISO 27001 für die Informationssicherheit. ## Welche Norm, und wo sie einzuordnen ist Lead Implementer ist nicht an eine einzige Norm gebunden. Dieselbe Kompetenz wird für mehrere ISO-Managementsystemnormen angeboten, am häufigsten ISO 27001 für die Informationssicherheit, ISO 42001 für KI-Managementsysteme und ISO 22301 für Business Continuity, unter anderen. Da diese Normen die gemeinsame übergeordnete Struktur teilen, die ISO über seine Managementsysteme hinweg verwendet, lässt sich die Implementierungsmethode gut übertragen: Anwendungsbereich, Führung, Planung, Unterstützung, Betrieb, Bewertung der Leistung und Verbesserung kehren in jeder wieder. Sobald Sie eine Implementierung geleitet haben, ist die nächste Norm größtenteils neuer Fachinhalt, der auf ein vertrautes Gerüst gelegt wird. Für Praktiker, die entscheiden, wo sie beginnen, lautet die ehrliche Einordnung so: Wenn sich Ihre Arbeit um die Informationssicherheit dreht, ist ISO 27001 Lead Implementer der natürliche Anker und derjenige, der in Stellenausschreibungen am häufigsten genannt wird. Wenn sich Ihre Organisation in Richtung einer gesteuerten KI bewegt, ist ISO 42001 Lead Implementer das aufkommende Gegenstück. So oder so gehen Sie in der Lage daraus hervor, das Projekt zu leiten, und nicht nur die Prüfung abzulegen, was die Rolle verlangt, sobald Sie wieder an Ihrem Schreibtisch vor einer echten Zertifizierungsfrist sitzen. --- ## Least Privilege **URL:** https://cyberacademy.net/de/resources/encyclopedia/least-privilege **Last reviewed:** 2026-06-24 Least Privilege ist das Prinzip, dass jede Identität (Mensch oder Maschine) nur die minimal erforderlichen Berechtigungen für eine Aufgabe erhält, nicht mehr. Klingt selbstverständlich; wird selten konsequent umgesetzt. Die meisten Datenexfiltrationsvorfälle beginnen mit einem übermäßig berechtigten Service-Account, den niemand bei Nachfrage begründen konnte. Kombinieren Sie dieses Prinzip mit regelmäßigen Access Reviews. ## Das Prinzip, und warum es in der Praxis immer wieder scheitert Least Privilege ist leicht zu formulieren und schwer zu leben. Jede Identität, ob eine Person, ein Dienstkonto, ein Automatisierungsskript oder ein API-Schlüssel, sollte genau die Berechtigungen besitzen, die ihre Aufgabe erfordert, und nichts darüber hinaus. Das Versagen ist selten eine bewusste Entscheidung, zu viel zu gewähren. Es ist Anhäufung. Jemand benötigt Administratorrechte für eine einmalige Migration, und die Vergabe wird nie wieder entzogen. Ein Dienstkonto wird mit weiten Berechtigungsbereichen erstellt, weil deren Einschränkung einen Nachmittag voller Tests erfordern würde, für den niemand Zeit hat. Einem Team wird eine Rolle zugewiesen, die für ein anderes Team entworfen wurde, weil sie die am besten passende verfügbare war. Über Monate hinweg sammeln Identitäten Berechtigungen an, wie ein Schreibtisch Papier ansammelt, und niemand kann erklären, warum eine bestimmte überhaupt da ist. Diese Anhäufung ist die Angriffsfläche. Wenn ein überberechtigtes Konto Opfer von Phishing wird, durchsickert oder unbemerkt missbraucht wird, ist der Wirkungsradius alles, was dieses Konto erreichen konnte, was in der Regel weit mehr ist als seine tatsächliche Aufgabe. Die Disziplin des Least Privilege liegt nicht in der anfänglichen Vergabe, die der einfache Teil ist. Sie liegt in der fortlaufenden Arbeit, das Nicht-mehr-Benötigte zu entfernen und das Verbleibende rechtfertigen zu können. ## Wie Praktiker es tatsächlich umsetzen Least Privilege ist eine durch Werkzeuge gestützte betriebliche Gewohnheit, keine einmalige Konfiguration. Die Arbeit gruppiert sich um einige wiederkehrende Aktivitäten: - Rollen- und Berechtigungsdesign: Rollen um Tätigkeitsfunktionen herum aufbauen, sodass die Vergabe von Zugriff eine bewusste Zuordnung ist und nicht eine Kopie dessen, was die vorherige Person hatte. - Just-in-Time- und Just-Enough-Zugriff: erhöhte Rechte für das Zeitfenster gewähren, in dem sie benötigt werden, und sie danach automatisch entziehen, statt dauerhafte Administratorberechtigungen bestehen zu lassen. - Zugriffsüberprüfungen: regelmäßig erneut prüfen, wer was besitzt, und einen Verantwortlichen verpflichten zu bestätigen, dass jede Vergabe weiterhin gerechtfertigt ist. Alles, wofür niemand einstehen will, wird widerrufen. - Funktionstrennung: sensible Aktionen aufteilen, sodass keine einzelne Identität einen Vorgang mit hohem Risiko sowohl initiieren als auch genehmigen kann, was Least Privilege angewendet auf Arbeitsabläufe statt auf Daten bedeutet. - Maschinenidentitäten: Dienstkonten, Token und Pipeline-Anmeldedaten mit derselben Sorgfalt behandeln wie menschliche Benutzer, denn sie sind oft die am stärksten überberechtigten und die am wenigsten überprüften. > **Das nicht zu rechtfertigende Dienstkonto** Wenn eine Zugriffsüberprüfung auf ein Konto stößt und niemand im Raum sagen kann, wofür es da ist oder warum es den Berechtigungsbereich hat, den es hat, dann ist das das Signal, nicht die Ausnahme. Die meisten Vorfälle von Datenexfiltration lassen sich genau auf diese Art vergessener, überberechtigter Identität zurückführen. Die richtige Antwort besteht darin, zu widerrufen und kontrolliert zu beobachten, was kaputtgeht, und es nicht zu belassen, weil die Entfernung riskant erscheint. ## Wo es zwischen Zero Trust, IAM und PAM steht Least Privilege ist ein Prinzip. Die benachbarten Begriffe sind die Maschinerie, die es umsetzt. Identitäts- und Zugriffsverwaltung (IAM) ist das System, das Identitäten und deren Handlungsmöglichkeiten definiert, sodass Least Privilege die Regel ist, die IAM durchsetzen soll. Privileged Access Management (PAM) ist die strengere Disziplin, die auf die risikoreichsten Konten angewendet wird, wo Least Privilege am wichtigsten ist und wo die Just-in-Time-Erhöhung üblicherweise angesiedelt ist. Zero Trust ist die umfassendere Architektur, die davon ausgeht, dass keine Identität standardmäßig vertrauenswürdig ist, und jede Anfrage verifiziert; Least Privilege ist einer ihrer Kernmechanismen, denn das Verifizieren einer Anfrage hilft nur, wenn der gewährte Zugriff bereits minimal ist. Man kann das Prinzip ohne die Werkzeuge vertreten, aber in jeder realen Größenordnung verfällt das Prinzip ohne IAM, PAM und regelmäßige Überprüfungen still und leise wieder zur Überprovisionierung. Der Gedanke zieht sich durch die Standards, selbst dort, wo die genaue Formulierung variiert. ISO/IEC 27001 Annex A behandelt Zugriffskontrolle, privilegierte Zugriffsrechte und die regelmäßige Überprüfung der Zugriffsrechte von Benutzern. Die NIST-Zugriffskontrollfamilie ist um Least Privilege und Funktionstrennung als benannte Prinzipien herum aufgebaut. Die CIS Controls fordern den kontrollierten Einsatz administrativer Berechtigungen und die Kontoverwaltung. Auditoren wollen nicht nur sehen, dass Zugriff einmal korrekt gewährt wurde. Sie erwarten den Nachweis eines fortlaufenden Überprüfungszyklus, und ein dauerhaftes Administratorkonto, das niemand überprüft, wird als Feststellung behandelt, nicht als Bequemlichkeit. --- ## MITRE ATT&CK **URL:** https://cyberacademy.net/de/resources/encyclopedia/mitre-attack **Last reviewed:** 2026-06-24 MITRE ATT&CK ist die offene Wissensdatenbank mit Adversary Tactics, Techniques and Procedures (TTPs), die in der Praxis beobachtet wurden. Sie bildet das Standardvokabular für eine bedrohungsbasierte Verteidigung: Erkennungsregeln, Red-Team-Szenarien, SOC-Analystenschulungen. Kontinuierlich aktualisiert, kostenlos nutzbar. Wenn Ihre SIEM-Regeln keine ATT&CK-Technik-IDs referenzieren, arbeiten Sie unnötig aufwendig. ## Eine gemeinsame Sprache dafür, wie sich Angreifer verhalten MITRE ATT&CK rückt Threat Intelligence rund um Verhalten statt um Indikatoren in den Mittelpunkt. Anstatt die IP-Adressen oder Datei-Hashes zu katalogisieren, die in einer einzigen Kampagne beobachtet wurden und sich ständig ändern, katalogisiert es das, was Angreifer tatsächlich tun, sobald sie in einer Umgebung sind: wie sie sich initialen Zugang verschaffen, Privilegien ausweiten, sich seitlich bewegen, Abwehrmaßnahmen umgehen und Daten exfiltrieren. Jedes dieser Verhaltensweisen wird als Technik mit einer stabilen Kennung erfasst, und Techniken werden unter Taktiken gruppiert, die das Angreiferziel in jedem Schritt beschreiben. Das Ergebnis ist eine strukturierte, evidenzbasierte Karte des gegnerischen Spielbuchs, die aus beobachteten realen Einbrüchen stammt und nicht aus der Theorie. Das Rahmenwerk ist als Matrix aufgebaut. Die Spalten sind die Taktiken, das Warum hinter einem Schritt, und die Zellen unter jeder Spalte sind die Techniken und Sub-Techniken, das Wie. Getrennte Matrizen decken Enterprise-Umgebungen, Mobilgeräte und industrielle Steuerungssysteme ab, weil sich gegnerisches Verhalten über diese Gelände hinweg unterscheidet. Da die Technik-IDs stabil und öffentlich sind, werden sie zu einer gemeinsamen Referenz, auf die ein Threat-Intelligence-Analyst, ein SOC-Ingenieur, der Erkennungen schreibt, und ein Red Teamer, der eine Übung plant, alle ohne Mehrdeutigkeit verweisen können. Dieses gemeinsame Vokabular ist die stille Superkraft von ATT&CK: Es lässt Teams, die nie miteinander sprechen, denselben Angriff auf dieselbe Weise beschreiben. ## Taktiken, Techniken und Verfahren Das TTP-Modell steht im Kern von ATT&CK, und es lohnt sich, die drei Ebenen auseinanderzuhalten. Taktiken sind die Ziele des Gegners, die übergeordneten Absichten wie das Erlangen eines Standbeins oder das Aufrechterhalten von Persistenz. Techniken sind die allgemeinen Methoden, die zum Erreichen einer Taktik eingesetzt werden, und viele Techniken gliedern sich weiter in Sub-Techniken auf, die eine spezifischere Variante beschreiben. Verfahren sind die konkreten, in freier Wildbahn beobachteten Umsetzungen, die eine bestimmte Gruppe zur Durchführung einer Technik genutzt hat. Diese Leiter vom Verfahren über die Technik zur Taktik hinaufzusteigen, ist das, was aus einem Haufen von Vorfallartefakten ein Muster macht, gegen das man sich verteidigen kann. **Die TTP-Ebenen in ATT&CK** | Ebene | Frage, die sie beantwortet | Veranschaulichende Bedeutung | | --- | --- | --- | | Taktik | Warum tut der Gegner dies? | Das Ziel eines Schritts, etwa Persistenz oder seitliche Bewegung | | Technik | Wie erreichen sie es im Allgemeinen? | Eine benannte Methode mit einer stabilen ATT&CK-ID, mitunter in Sub-Techniken aufgeteilt | | Verfahren | Wie genau hat diese Gruppe es getan? | Die spezifische beobachtete Umsetzung in einem realen Einbruch | Der Grund, warum Fachleute diese Struktur schätzen, ist, dass auf Technik-Ebene aufgebaute Abwehrmaßnahmen länger überdauern als auf Indikatoren gestützte. Ein Angreifer kann eine bösartige Domain in Minuten austauschen oder eine Payload neu kompilieren und so signaturbasiertes Blockieren aushebeln, doch das Ändern der zugrunde liegenden Technik erfordert mehr Aufwand und oft mehr Können. An Techniken verankerte Erkennungen altern daher langsamer und fangen Varianten ab, die die erste Signatur nie gesehen hat. ## Wie Teams ATT&CK in die Praxis umsetzen Bedrohungsinformierte Verteidigung ist die Praxis, die ATT&CK ermöglicht, und sie zeigt sich in der gesamten Sicherheitsfunktion. SOC-Teams kennzeichnen Erkennungsregeln mit Technik-IDs, sodass sie auf einen Blick sehen, welche gegnerischen Verhaltensweisen sie erkennen können und für welche sie blind sind. Diese Lückenanalyse, oft als Heatmap über der Matrix visualisiert, steuert, wohin der nächste Erkennungsaufwand geht. Red Teams und Purple Teams nutzen die Matrix, um Übungen zu gestalten und zu bewerten, indem sie Techniken gezielt durchgehen, um zu testen, ob das Blue Team es bemerkt. Threat-Intelligence-Teams beschreiben gegnerische Gruppen in ATT&CK-Begriffen, sodass Berichte vergleichbar sind statt maßgeschneiderter Prosa. Und Schulungsprogramme stützen sich darauf, weil es Analysten ein einziges, gut dokumentiertes Modell des Angreiferverhaltens zum Lernen bietet statt tausend unverbundener Kriegsgeschichten. > **Kartieren Sie Ihre Abdeckung, dann schließen Sie die Lücken** Der wertvollste erste Schritt ist eine Abdeckungskarte: Kennzeichnen Sie Ihre bestehenden Erkennungen und Kontrollen mit ATT&CK-Techniken und sehen Sie, wo die Matrix aufleuchtet und wo sie dunkel bleibt. Die dunklen Zellen sind Ihre blinden Flecken in Angreiferbegriffen, und dieses Bild ist weit handlungsrelevanter als eine Liste der Werkzeuge, die Sie besitzen. ATT&CK ist offen veröffentlicht, kostenlos nutzbar und wird laufend aktualisiert, sobald neues gegnerisches Verhalten beobachtet wird, weshalb es zur De-facto-Referenz geworden ist und nicht zu einem Anbieter-Rahmenwerk unter vielen. Es passt natürlich zu Kontrollkatalogen und Managementsystemen: Wo ISO/IEC 27001, das NIST Cybersecurity Framework oder die CIS Controls Ihnen sagen, welche Schutz- und Erkennungsfähigkeiten Sie aufbauen sollen, sagt ATT&CK Ihnen, welche gegnerischen Verhaltensweisen diese Fähigkeiten adressieren müssen, und es wird zunehmend genutzt, um diese Arbeit zu priorisieren und zu validieren. --- ## Mean Time to Detect / Recover (MTTD / MTTR) **URL:** https://cyberacademy.net/de/resources/encyclopedia/mttd-mttr **Last reviewed:** 2026-06-24 MTTD ist die durchschnittliche Zeitspanne vom Beginn eines Vorfalls bis zu seiner Erkennung. MTTR ist die durchschnittliche Zeitspanne von der Erkennung bis zur Wiederherstellung. Zusammen bilden sie die zentralen operativen Kennzahlen eines SOC und eines Incident-Response-Programms. Branchenbenchmarks liegen im Bereich von Tagen oder Wochen; reife Programme zielen auf Stunden ab. ## Zwei Kennzahlen, eine Zeitleiste MTTD und MTTR beschreiben zwei aufeinanderfolgende Abschnitte derselben Vorfallzeitleiste. MTTD umfasst die stille Phase zwischen dem Moment, in dem ein Angreifer erstmals handelt, und dem Moment, in dem Ihr Team erkennt, dass etwas nicht stimmt. MTTR umfasst alles nach diesem Punkt, von der Triage über die Eindämmung und Wiederherstellung bis zu einer bestätigten Rückkehr zum Normalzustand. Sie gemeinsam zu lesen ist genau der Sinn: ein niedriger MTTD bei hohem MTTR bedeutet, dass Sie Bedrohungen schnell erkennen, aber Schwierigkeiten haben, darauf zu reagieren, während ein hoher MTTD bei niedrigem MTTR bedeutet, dass Sie schnell reagieren, aber erst, wenn der Schaden bereits entstanden ist. Keine der Zahlen ist für sich genommen nützlich, und die eine auf Kosten der anderen zu verbessern hilft selten. In der Praxis sind dies die Spitzenkennzahlen, die ein SOC an die Geschäftsleitung meldet, weil sie technische Aktivität in eine Sprache übersetzen, die das Geschäft versteht: Wie lange waren wir exponiert, und wie lange haben wir gebraucht, um die Tür zu schließen. Es sind auch die Kennzahlen, um die Aufsichtsbehörden und Rahmenwerke kreisen, selbst wenn sie andere Worte verwenden. Eine Frist zur Meldung einer Verletzung ist im Wesentlichen eine gesetzliche Obergrenze für einen Teil Ihres MTTR, und die Pflicht, Vorfälle zeitnah zu erkennen, ist die Pflicht, den MTTD niedrig zu halten. ## Was diese Zahlen tatsächlich bewegt MTTD wird durch Sichtbarkeit und Feinabstimmung bestimmt. Sie können nicht erkennen, was Sie nicht erfassen, daher ist die Protokollabdeckung über Endpunkte, Netzwerk, Identität und Cloud die Grundlage. Darüber hinaus muss der Erkennungsinhalt abgestimmt werden: zu locker und die Analysten ertrinken in Fehlalarmen und übersehen das echte Signal, zu streng und echte Eindringversuche rutschen durch. Deshalb fließen ein SIEM, eine gute Detection Engineering und Threat Intelligence direkt in den MTTD ein. MTTR wird durch Prozess und Befugnis bestimmt: dokumentierte Playbooks, die Befugnis, einen Host zu isolieren oder ein Konto zu deaktivieren, ohne auf ein Gremium zu warten, getestete Backups und eingeübte Kommunikation. Die klassische Verbesserung ist hier die Automatisierung über ein SOAR, das die durch manuelle Übergaben verlorenen Minuten beseitigt. **MTTD im Vergleich zu MTTR auf einen Blick** | Aspekt | MTTD (Erkennen) | MTTR (Wiederherstellen) | | --- | --- | --- | | Zeitfenster | Vom Vorfallbeginn bis zur Erkennung | Von der Erkennung bis zur vollständigen Wiederherstellung | | Leitfrage | Wie lange waren wir blind? | Wie lange bis zur Eindämmung und Wiederherstellung? | | Wichtigste Hebel | Protokollabdeckung, Erkennungsabstimmung, Threat Intelligence | Playbooks, Automatisierung, Handlungsbefugnis, Backups | | Werkzeuge | SIEM, EDR, Bedrohungserkennung | SOAR, IR-Runbooks, Wiederherstellungswerkzeuge | | Schwerpunkt des Verantwortlichen | Detection Engineering und Monitoring | Incident Response und Betrieb | > **Definieren Sie die Uhr, bevor Sie der Zahl vertrauen** MTTD und MTTR sind nur dann vergleichbar, wenn sich alle auf die Start- und Stopppunkte einigen. Endet MTTR bei der Eindämmung, der Beseitigung oder bei einer verifizierten Wiederaufnahme des Dienstes? Beginnt MTTD bei der ersten bösartigen Handlung oder beim ersten Protokollereignis, das Sie zufällig erfasst haben? Solange diese Definitionen nicht schriftlich festgehalten sind, kann eine sinkende Zahl schlicht bedeuten, dass Sie geändert haben, wie Sie messen. ## Wie die Kennzahlen in Standards und Benchmarks auftauchen Rahmenwerke schreiben in der Regel keinen bestimmten MTTD- oder MTTR-Zielwert vor, weil die richtige Zahl von der Organisation und der Bedrohung abhängt. Was sie verlangen, ist die Fähigkeit und die Messung. Die ISO/IEC 27035 legt den Lebenszyklus des Vorfallmanagements fest, den diese Kennzahlen quantifizieren. Die NIST-Leitlinien zur Vorfallbehandlung gliedern Erkennung, Analyse, Eindämmung, Beseitigung und Wiederherstellung in eigenständige Phasen, was genau die Struktur ist, auf der MTTD und MTTR aufsetzen. Die ENISA und nationale Behörden wie die ANSSI vermitteln dieselbe operative Botschaft: früh erkennen, schnell reagieren und in der Lage sein, dies nachzuweisen. Regulatorische Regime fügen harte externe Fristen hinzu, etwa die Meldefenster für Verletzungen nach der DSGVO und die Meldepflichten für Vorfälle nach NIS2 und DORA, die einen Teil Ihrer Reaktionszeit von einem Leistungsziel in eine Compliance-Anforderung verwandeln. Benchmarks für beide Kennzahlen liegen branchenweit tendenziell unangenehm hoch, oft im Bereich von Tagen oder Wochen für die Erkennung, während reife Programme Stunden anstreben. Einem veröffentlichten Benchmark hinterherzujagen ist jedoch der falsche Instinkt. Der Wert von MTTD und MTTR liegt in den Trendlinien, die Ihnen gehören: messen Sie sie konsequent, beobachten Sie die Richtung über Quartale hinweg und verknüpfen Sie die Bewegung mit konkreten Investitionen in Sichtbarkeit, Feinabstimmung und Automatisierung. Eine ehrlich definierte und stetig sinkende Zahl ist weit mehr wert als ein schmeichelhafter Einzelwert. --- ## Multi-Faktor-Authentifizierung (MFA) **URL:** https://cyberacademy.net/de/resources/encyclopedia/mfa **Last reviewed:** 2026-06-24 MFA is the requirement that authentication uses two or more factors from different categories (knowledge, possession, inherence). Not all MFA is equal: SMS and email codes are phishable, push notifications get fatigued, hardware tokens and passkeys are the strong forms. NIS 2 and DORA both mandate "strong" MFA on critical access. ## Was als Faktor zählt, und warum das wichtig ist Die Multi-Faktor-Authentifizierung verlangt zwei oder mehr Identitätsnachweise aus unterschiedlichen Kategorien, sodass die Kompromittierung eines Nachweises das Konto nicht an einen Angreifer ausliefert. Die drei klassischen Kategorien sind Wissen (etwas, das man weiß, etwa ein Passwort oder eine PIN), Besitz (etwas, das man hat, etwa ein Telefon, ein Sicherheitsschlüssel oder eine Smartcard) und Inhärenz (etwas, das man ist, etwa ein Fingerabdruck oder ein Gesicht). Das entscheidende Wort ist hier unterschiedlichen. Zwei Passwörter sind keine Multi-Faktor-Authentifizierung, denn sie gehören zur selben Kategorie und unterliegen denselben Angriffen. Ein Passwort plus ein Code von einem separaten Gerät hingegen schon, denn ein Angreifer muss nun zwei voneinander unabhängige Kontrollen gleichzeitig überwinden. Hier treffen auch MFA und Identitätsmanagement aufeinander. Die MFA stärkt nur den Authentifizierungsschritt, den Moment, in dem ein Nutzer nachweist, wer er ist. Sie sagt nichts darüber aus, was dieser Nutzer anschließend tun darf, was die Autorisierung betrifft, noch über Provisionierung, Deprovisionierung oder Zugriffsüberprüfungen. Betrachten Sie die MFA als eine gehärtete Schicht innerhalb eines umfassenderen IAM-Programms, nicht als Ersatz für das Least-Privilege-Prinzip oder für das Bereinigen verwaister Konten. ## Nicht jede MFA ist gleich Die wichtigste Erkenntnis für die Praxis ist, dass die MFA auf einem Spektrum der Stärke liegt, und der Unterschied ist nicht kosmetisch. Einmalcodes per SMS und E-Mail sind besser als ein Passwort allein, aber sie sind phishbar: Eine überzeugende gefälschte Anmeldeseite fordert das Opfer schlicht auf, den Code einzugeben, und ein Angreifer leitet ihn in Echtzeit weiter. SIM-Swapping verschlimmert die SMS-Variante zusätzlich. Push-Benachrichtigungsfreigaben fügen einen Fingertipp hinzu, laden aber zur MFA-Müdigkeit ein, bei der ein Angreifer, der das Passwort bereits besitzt, den Nutzer mit Freigabeaufforderungen überflutet, bis ein müder Nutzer eine davon akzeptiert. Die starken Formen sind Besitzfaktoren, die an die legitime Website gebunden sind: Hardware-Sicherheitsschlüssel und Passkeys auf Basis von FIDO2 und WebAuthn. Da der Berechtigungsnachweis kryptografisch an die echte Domain gebunden ist, gibt er nichts an eine nachgeahmte Seite preis. Diese Eigenschaft ist gemeint, wenn von phishing-resistenter MFA die Rede ist. **MFA-Methoden nach Widerstandsfähigkeit gegen verbreitete Angriffe** | Methode | Kategorie | Phishing-resistent | Typische Schwäche | | --- | --- | --- | --- | | Code per SMS oder E-Mail | Besitz (schwach) | Nein | Auf gefälschten Seiten weitergeleitet, SIM-Swap | | Authenticator-App TOTP | Besitz | Nein | Code kann in Echtzeit abgephisht werden | | Push-Freigabe | Besitz | Nein | MFA-Müdigkeit und versehentliche Freigabe | | Hardware-Schlüssel (FIDO2) | Besitz | Ja | Kosten und Logistik der Registrierung | | Passkey (WebAuthn) | Besitz plus Inhärenz | Ja | Wiederherstellung und Gerätebindung | > **Starke MFA ist die Aufgabe, kein Häkchen** Regulierungsbehörden sprechen zunehmend von starker statt nur von MFA. SMS-Codes auszurollen, um ein Compliance-Häkchen zu setzen, lässt den Phishing-Weg weit offen. Priorisieren Sie phishing-resistente Methoden für Administratoren, Fernzugriff und alles, was ein Angreifer zuerst ins Visier nehmen würde. ## Regulatorischer und normativer Kontext Die MFA hat sich in der gesamten europäischen Cyberregulierung von einer Empfehlung zu einer Erwartung gewandelt. NIS 2 verpflichtet wesentliche und wichtige Einrichtungen, Maßnahmen der Cyberhygiene und der Zugangskontrolle zu ergreifen, wobei die Multi-Faktor- oder kontinuierliche Authentifizierung ausdrücklich für die Sicherheit des Zugangs genannt wird. DORA stellt vergleichbare Erwartungen an den Finanzsektor, wo die starke Authentifizierung kritische Funktionen und den Fernzugriff schützt. Beide Rahmenwerke neigen zum starken Ende des Spektrums, anstatt jede MFA als ausreichend zu betrachten. Dieselbe Stoßrichtung zeigt sich in den Leitlinien des NIST, die phishing-resistente Authentifikatoren für Zugänge mit hohem Wert bevorzugen, sowie in Referenzrahmen wie ISO/IEC 27001 und den CIS Controls, die die MFA als grundlegende Schutzmaßnahme der Zugangskontrolle behandeln. Was Praktiker tatsächlich tun, ist die Einführung nach Risiko zu staffeln. Sie schützen zuerst privilegierte und administrative Konten, dann den Fern- und internetexponierten Zugang, dann die allgemeine Nutzerschaft, und sie wählen phishing-resistente Methoden überall dort, wo die Auswirkung einer Kompromittierung hoch ist. Sie planen Wiederherstellung und Registrierung sorgfältig, da verlorene Faktoren ein realer betrieblicher Aufwand sind, und sie achten auf Muster von Müdigkeit und Umgehung. Gut umgesetzt nimmt die MFA einem gestohlenen Passwort leise seinen Wert. Als Häkchen umgesetzt, vermittelt sie ein falsches Sicherheitsgefühl, während der phishbare Kanal offen bleibt. --- ## NIS 1 Directive (NIS 1) **URL:** https://cyberacademy.net/de/resources/encyclopedia/nis-1 **Last reviewed:** 2026-06-24 NIS 1 (Directive 2016/1148) was the EU's first cross-sector cybersecurity directive, covering operators of essential services and digital service providers. Replaced by NIS 2 in October 2024 because scope was too narrow, enforcement uneven and incident reporting toothless. Cited here mainly so you know what the "old regime" your colleagues still half-remember actually was. ## Was NIS 1 erreichen wollte Die NIS-1-Richtlinie war der erste Versuch der Europäischen Union, eine gemeinsame Mindestbasis für Cybersicherheit unter die Sektoren zu legen, die ein Land am Laufen halten. Zuvor gingen die Mitgliedstaaten die Sicherheit kritischer Infrastrukturen nach ihren eigenen Vorstellungen an, ohne gemeinsame Grundlage und ohne koordinierte Möglichkeit, grenzüberschreitende Vorfälle zu bewältigen. NIS 1 änderte das, indem es jeden Mitgliedstaat aufforderte, die Betreiber zu identifizieren, deren Störung eine schwerwiegende Kettenwirkung hätte, sie zu Sicherheits- und Meldepflichten zu verpflichten und den nationalen Apparat aufzubauen, der sie beaufsichtigt. In Frankreich war dieser Apparat die ANSSI, und die von ihr benannten Betreiber kannten bereits das schwerere OIV-Regime, das der Richtlinie vorausging. Da es sich um eine Richtlinie und nicht um eine Verordnung handelte, galt NIS 1 nicht unmittelbar. Jeder Mitgliedstaat musste sie in nationales Recht umsetzen, woraus ein Großteil der Ungleichmäßigkeit entstand. Zwei Staaten konnten denselben Text lesen und mit unterschiedlichen Listen regulierter Einrichtungen, unterschiedlichen Meldeschwellen und sehr unterschiedlicher Durchsetzungsbereitschaft enden. Dieser Flickenteppich ist der mit Abstand wichtigste Grund, warum das Regime schließlich neu aufgebaut wurde. ## Zwei Kategorien: wesentliche Dienste und Anbieter digitaler Dienste NIS 1 teilte die regulierte Welt in zwei Gruppen, und die Unterscheidung ist wichtig, weil die Pflichten und die Aufsicht nicht symmetrisch waren. **NIS-1-Kategorien** | Aspekt | Betreiber wesentlicher Dienste | Anbieter digitaler Dienste | | --- | --- | --- | | Wer sie waren | Energie, Verkehr, Bankwesen, Finanzmarktinfrastrukturen, Gesundheit, Trinkwasser, digitale Infrastruktur | Online-Marktplätze, Suchmaschinen, Cloud-Computing-Dienste | | Wie sie erfasst wurden | Einzelfallweise von jedem Mitgliedstaat anhand von Kriterien identifiziert | Automatisch im Anwendungsbereich, mit leichterer Behandlung | | Aufsicht | Proaktiv: Behörden konnten prüfen und Nachweise verlangen | Überwiegend reaktiv: Maßnahmen nach einem Vorfall | | Sicherheitserwartung | Angemessene, verhältnismäßige technische und organisatorische Maßnahmen | Ähnliche Maßnahmen, aber ein leichteres Regulierungsregime | Betreiber wesentlicher Dienste waren das Herzstück der Richtlinie. Die Mitgliedstaaten mussten sie benennen, und einmal benannt trugen sie reale Pflichten, Risiken zu steuern und bedeutende Vorfälle der nationalen Behörde oder dem CSIRT zu melden. Anbieter digitaler Dienste wurden leichter behandelt, nach der Überlegung, dass sie ohnehin grenzüberschreitend tätig waren und über Resilienz konkurrierten, sodass ein harmonisiertes, aber leichteres Regime eine Fragmentierung des Binnenmarkts vermeiden würde. > **Warum man noch von NIS 1 hört** Wenn ein Kollege davon spricht, ein „regulierter Betreiber“ zu sein, oder davon, dass die ANSSI seine Organisation benannt hat, erinnert er sich meist an die NIS-1-Ära. Die Pflichten verschwanden nicht, sie wurden von NIS 2 aufgenommen und erweitert, die im Oktober 2024 in Kraft trat. ## Warum sie ersetzt wurde Das ehrliche Urteil über NIS 1 lautet, dass sie das Konzept bewies, aber hinter den Erwartungen zurückblieb. Drei Schwächen traten immer wieder auf. Der Anwendungsbereich war zu eng und ließ ganze Sektoren und die meisten mittelgroßen Organisationen außerhalb jeder Pflicht, selbst wenn ihr Ausfall geschadet hätte. Die Durchsetzung war ungleichmäßig, weil die Umsetzung es jedem Mitgliedstaat überließ zu entscheiden, wer im Anwendungsbereich lag und wie hart durchzugreifen war, sodass ein Unternehmen in einem Land reguliert und gleich nebenan unbehelligt sein konnte. Und die Vorfallmeldung war faktisch zahnlos, mit Schwellenwerten und Fristen, die so stark variierten, dass die grenzüberschreitende Sichtbarkeit, die die Richtlinie schaffen sollte, nie wirklich zustande kam. NIS 2 war die Antwort auf alle drei. Sie weitete den Anwendungsbereich auf weit mehr Sektoren und auf ein größenbasiertes Kriterium aus, ersetzte die OES/DSP-Aufteilung durch wesentliche und wichtige Einrichtungen, straffte die Vorfallmeldung in klarere Phasen und stellte echte Verantwortlichkeit der Leitung sowie Sanktionen hinter die Pflichten. Für einen Praktiker von heute ist NIS 1 vor allem Kontext: Sie erklärt die Form der Regeln, unter denen Sie nun leben, und die Reflexe, die Ihre Organisation vor dem Neuaufbau entwickelt hat. --- ## NIS 2 Directive (NIS 2) **URL:** https://cyberacademy.net/de/resources/encyclopedia/nis-2 **Last reviewed:** 2026-06-24 NIS 2 ist die EU-Richtlinie, die Vorstände und Geschäftsleitungen persönlich in die Pflicht nimmt. Mittelgroße und größere Unternehmen in einem der 18 aufgeführten Sektoren fallen in den Anwendungsbereich. Die Uhr läuft ab dem ersten erheblichen Vorfall: Frühwarnung innerhalb von 24 Stunden, Meldung innerhalb von 72 Stunden, vollständiger Bericht nach einem Monat. Die Sanktionen sind empfindlich (10 Millionen Euro oder 2 % des weltweiten Jahresumsatzes). Der Umsetzungsstand variiert von Land zu Land. ## Was NIS 2 tatsächlich ändert NIS 2 ist die zweite Fassung der EU-Richtlinie zur Netz- und Informationssicherheit und erweitert den Anwendungsbereich gegenüber der ursprünglichen NIS-Regelung erheblich. Während sich die erste Richtlinie darauf stützte, dass nationale Behörden Betreiber wesentlicher Dienste fallweise identifizieren, legt NIS 2 selbstidentifizierende Kriterien fest: Wer in einem der aufgeführten Sektoren tätig ist und die Größenschwelle überschreitet, fällt in den Anwendungsbereich und wird angehalten, dies zu wissen. Die Richtlinie ordnet die betroffenen Organisationen zwei Stufen zu, "wesentlichen" und "wichtigen" Einrichtungen, was sich vor allem darauf auswirkt, wie Aufsicht und Durchsetzung angewandt werden, und weniger auf die grundlegenden Pflichten selbst. Der zentrale Wandel betrifft die Rechenschaftspflicht. NIS 2 macht die Leitungsorgane für die Genehmigung und Überwachung der Maßnahmen zum Cybersicherheits-Risikomanagement verantwortlich und erwartet von ihnen, an Schulungen teilzunehmen, damit sie diese Aufsicht tatsächlich ausüben können. Sicherheit ist nicht länger etwas, das die IT-Abteilung still und leise verantwortet, sondern wird zu einem Governance-Thema, das die Geschäftsleitung freigeben muss. Das ist der praktische Grund, warum die Richtlinie so oft damit zusammengefasst wird, dass sie "die Leitungsebene in die Pflicht nimmt". ## Anwendungsbereich, Sektoren und der Größentest Der Anwendungsbereich beruht auf zwei Fragen: Sind Sie in einem aufgeführten Sektor tätig, und sind Sie groß genug? Die Richtlinie deckt Sektoren ab, die in die Kategorien "hohe Kritikalität" und "sonstige kritische Sektoren" unterteilt sind, und umfasst Energie, Verkehr, Bankwesen, Gesundheit, Wasser, digitale Infrastruktur, öffentliche Verwaltung, Postdienste, die Herstellung bestimmter Erzeugnisse, Lebensmittel und mehr. Der Größentest erfasst in der Regel mittlere und große Organisationen, wobei kleinere Einrichtungen mitunter einbezogen werden, wenn ihre Rolle unabhängig von der Mitarbeiterzahl kritisch ist. Da die Mitgliedstaaten zusätzliche Einrichtungen benennen können, besteht der einzig sichere Ansatz darin, die eigenen Tätigkeiten anhand der Sektoranhänge abzugleichen, statt anzunehmen, man sei zu klein, um relevant zu sein. > **Eine Richtlinie, keine Verordnung** NIS 2 ist eine Richtlinie, sie gilt also nicht unmittelbar wie DORA oder die DSGVO. Jeder Mitgliedstaat setzt sie in nationales Recht um, was bedeutet, dass die konkrete Behörde, das Registrierungsverfahren und die Details der Aufsicht von Land zu Land variieren. Prüfen Sie stets den Umsetzungstext in den Rechtsordnungen, in denen Sie tätig sind. ## Die Uhr für die Meldung von Sicherheitsvorfällen Was die Praktiker am unmittelbarsten spüren, ist die Meldefrist, die bei einem erheblichen Sicherheitsvorfall greift. Sie läuft in Stufen ab: eine Frühwarnung innerhalb von 24 Stunden, eine umfassendere Meldung innerhalb von 72 Stunden und ein Abschlussbericht nach einem Monat, wobei die zuständige Behörde oder das CSIRT der Empfänger ist. Sinn des gestuften Modells ist es, Vorfälle schnell sichtbar zu machen, ohne bereits am ersten Tag ein vollständiges forensisches Bild zu erzwingen. Um sie einzuhalten, brauchen Sie eine Erkennung, die Erheblichkeit rasch kennzeichnet, einen Entscheidungsverantwortlichen, der einen Vorfall einstufen kann, und vorab erstellte Meldevorlagen, damit die Uhr Sie nicht beim Schreiben von Grund auf erwischt. Untermauert wird die Frist durch Risikomanagementpflichten, die sich wie eine vertraute Grundlage lesen: Behandlung von Vorfällen, Geschäftskontinuität und Backups, Sicherheit der Lieferkette, sichere Entwicklung und Wartung, Umgang mit Schwachstellen, Einsatz von Kryptografie, Zugriffskontrolle und Multi-Faktor-Authentifizierung sowie Richtlinien, um zu testen, wie gut all dies funktioniert. Nichts davon ist exotisch. Eine Organisation mit einem ausgereiften ISMS, etwa ausgerichtet an ISO 27001, deckt bereits den Großteil des Terrains ab; die Arbeit besteht darin, bestehende Kontrollen den Erwartungen von NIS 2 zuzuordnen und die Lücken in Governance und Meldung zu schließen. ## Was es in der Praxis bedeutet, in den Anwendungsbereich zu fallen Wenn Sie zu dem Schluss kommen, dass Sie in den Anwendungsbereich fallen, ist das praktische Programm recht einheitlich: sich bei der zuständigen nationalen Behörde registrieren, soweit erforderlich, die Aufsicht über das Cyberrisiko auf Leitungsebene formalisieren, Ihre Risikomanagementmaßnahmen anhand der Überschriften der Richtlinie dokumentieren, einen Prozess zur Einstufung und Meldung von Vorfällen aufbauen, der die Fenster von 24/72 Stunden und einem Monat einhalten kann, und die Sorgfaltspflicht auf Ihre Lieferkette ausdehnen, da Lieferanten ausdrücklich Teil des Risikobildes sind. Die Durchsetzung hat Zähne, mit Geldbußen, die in die zweistelligen Millionen Euro reichen oder einen Prozentsatz des weltweiten Umsatzes ausmachen, sowie der Möglichkeit einer Verantwortlichkeit der Geschäftsleitung, was genau der Grund ist, warum die Richtlinie die Verantwortung nach oben verlagert. --- ## NIST Cybersecurity Framework (NIST CSF) **URL:** https://cyberacademy.net/de/resources/encyclopedia/nist-csf **Last reviewed:** 2026-06-24 NIST CSF is the cybersecurity framework published by the US National Institute of Standards and Technology. The 2.0 revision (2024) added "Govern" to the existing five functions (Identify, Protect, Detect, Respond, Recover). Not certifiable; used as a maturity reference. Common companion to ISO 27001 in transatlantic organisations. ## Was das NIST CSF ist und was es nicht ist Das NIST Cybersecurity Framework ist eine strukturierte Methode, um ein Cybersicherheitsprogramm um Ergebnisse statt um Produkte herum zu organisieren. Es sagt Ihnen nicht, welche Firewall Sie kaufen oder welche Maßnahme Sie einführen sollen. Stattdessen beschreibt es, wie ein guter Zustand aussieht, indem es die Cybersicherheitsaktivität in eine kleine Gruppe von Funktionen gliedert und jede Funktion in Kategorien und Unterkategorien aufteilt, die sich als Ergebnisse in klarer Sprache lesen: Assets sind inventarisiert, Zugriffe werden verwaltet, Anomalien werden erkannt, Reaktionspläne werden ausgeführt. Diese Ergebnisorientierung ist der Grund, warum es sich so gut über Branchen und Größen hinweg übertragen lässt. Ein Krankenhaus, ein Hersteller und ein Softwareanbieter können alle dasselbe Vokabular nutzen, um zu beschreiben, wo sie stehen und wohin sie wollen. Das Wichtigste, was es zu verstehen gilt, ist, was das Framework nicht ist. Es ist keine zertifizierbare Norm. Es gibt kein NIST-CSF-Zertifikat, keine akkreditierte Stelle, die ein Bestehen ausstellt, und kein Audit, das mit einem eingetragenen Siegel auf Ihrer Website endet. Es ist eine freiwillige Referenz, die Sie nutzen, um die Reife zu bewerten, Ziele festzulegen und die Sicherheitslage zu kommunizieren, sowohl intern gegenüber einem Vorstand als auch extern gegenüber Partnern. Behandeln Sie die Behauptung eines Anbieters, „NIST CSF zertifiziert“ zu sein, als Warnsignal, denn eine solche Zertifizierung existiert nicht. ## Die Funktionen: von fünf auf sechs Das Framework ist um Funktionen herum aufgebaut, die zusammen den gesamten Lebenszyklus des Managements von Cyberrisiken abdecken. Die ursprünglichen fünf waren Identify, Protect, Detect, Respond und Recover. Die 2024 veröffentlichte Revision 2.0 fügte Govern hinzu, womit sich die Gesamtzahl auf sechs erhöhte und die Governance in den Mittelpunkt des Modells gestellt wurde, statt sie als nachträglichen Gedanken zu behandeln. Govern umfasst den organisatorischen Kontext, die Risikomanagementstrategie, Rollen und Verantwortlichkeiten, Richtlinien und Aufsicht, die bestimmen sollten, wie die anderen fünf Funktionen priorisiert und mit Ressourcen ausgestattet werden. Die Aufnahme formalisierte, was reife Programme bereits taten: Technische Maßnahmen funktionieren nur, wenn jemand die dahinterstehenden Risikoentscheidungen verantwortet. **Die sechs Funktionen des NIST CSF 2.0** | Funktion | Was sie abdeckt | | --- | --- | | Govern | Strategie, Rollen, Richtlinien und Aufsicht über das Cyberrisiko | | Identify | Assets, Lieferanten und die damit verbundenen Risiken verstehen | | Protect | Schutzmaßnahmen, die einen Vorfall begrenzen oder eindämmen | | Detect | Ereignisse und Anomalien erkennen, während sie auftreten | | Respond | Auf einen erkannten Vorfall reagieren, um ihn einzudämmen | | Recover | Fähigkeiten und Dienste nach einem Vorfall wiederherstellen | In der Praxis bewertet ein Team seinen aktuellen Zustand anhand jeder Kategorie, definiert ein Zielprofil, das seine Risikobereitschaft und seine Pflichten widerspiegelt, und arbeitet daran, die Lücke zwischen beiden zu schließen. Das Framework überlässt das Wie bewusst Ihnen, weshalb es sich auf natürliche Weise mit präskriptiven Katalogen wie den CIS Controls oder NIST 800-53 kombinieren lässt, die die konkreten Schutzmaßnahmen unter jedem Ergebnis liefern. ## Warum es neben ISO 27001 steht Das NIST CSF und ISO 27001 sind keine Konkurrenten, und viele transatlantische Organisationen nutzen beide. ISO 27001 bescheinigt, dass Sie ein Informationssicherheits-Managementsystem betreiben, mit einer Risikobewertung, einer Erklärung zur Anwendbarkeit und kontinuierlicher Verbesserung, und es erbringt ein auditierbares Zertifikat, das Kunden weltweit anerkennen. Das NIST CSF gibt Ihnen eine flexible Reifesprache und eine Möglichkeit, die Sicherheitslage gegenüber einem US-orientierten Publikum auszudrücken oder sich an US-bundesstaatlichen Erwartungen auszurichten. Ein gängiges Muster besteht darin, das Managementsystem für den Nachweis nach ISO 27001 zu zertifizieren und dann das CSF-Profil zu nutzen, um die Reife zu kommunizieren und sich mit Frameworks und Kunden abzustimmen, die in NIST-Begriffen sprechen. NIST veröffentlicht informative Referenzen, die CSF-Unterkategorien auf ISO 27001 und andere Normen abbilden, sodass die Arbeit selten zweimal erledigt werden muss. > **Kein Zertifikat, von Grund auf so angelegt** Das NIST CSF ist eine freiwillige Reifereferenz, keine zertifizierbare Norm. Wenn Sie ein auditierbares Siegel benötigen, das Kunden anerkennen, ist das ISO 27001. Nutzen Sie das CSF, um zu bewerten, Ziele zu setzen und zu kommunizieren, und kombinieren Sie es mit einem Maßnahmenkatalog, um die Lücken tatsächlich zu schließen. --- ## NIST SP 800-171 **URL:** https://cyberacademy.net/de/resources/encyclopedia/nist-800-171 **Last reviewed:** 2026-06-24 NIST SP 800-171 ist der US-amerikanische Standard, der Sicherheitsanforderungen zum Schutz kontrollierter, nicht klassifizierter Informationen in nicht-bundesstaatlichen Systemen definiert. Er bildet das technische Rückgrat von CMMC für Verteidigungsauftragnehmer. Revision 3 (2024) hat die Controls verschärft. Wer an das US-Verteidigungsministerium verkauft, ist zur Einhaltung verpflichtet; wer ausschließlich in Europa tätig ist, kann den Standard als Referenz nutzen. ## Was NIST SP 800-171 tatsächlich verlangt Wenn die US-Regierung sensible, aber nicht klassifizierte Daten mit einem Auftragnehmer, einer Universität oder einem Dienstleister teilt, benötigt sie die Gewissheit, dass die Daten geschützt werden, obwohl sie nun außerhalb der föderalen Systeme liegen. NIST SP 800-171 ist der Katalog der Sicherheitsanforderungen, der diesem Bedarf gerecht wird. Er sagt jeder nicht föderalen Organisation, die Controlled Unclassified Information verarbeitet, wie sie diese schützen muss: über Zugriffskontrolle, Sensibilisierung und Schulung, Audit und Rechenschaftspflicht, Konfigurationsmanagement, Identifizierung und Authentifizierung, Reaktion auf Vorfälle, Wartung, Datenträgerschutz, physischen Schutz, Personalsicherheit, Risikobewertung, Sicherheitsbewertung, Schutz von Systemen und Kommunikation sowie Integrität von Systemen und Informationen. Das Ziel ist Einheitlichkeit. Anstatt dass jede Behörde ihre eigenen Klauseln erfindet, erfüllen die Auftragnehmer eine einzige, konsistente Grundlinie. Die Anforderungen sind aus dem weitaus umfangreicheren Kontrollkatalog NIST SP 800-53 abgeleitet, der innerhalb der föderalen Systeme verwendet wird, jedoch an die Realität einer privaten Organisation angepasst. Sie sind als Ergebnisse formuliert, die Sie erreichen müssen, nicht als ein einzelnes vorgeschriebenes Produkt oder eine vorgeschriebene Architektur, was einer Organisation Spielraum lässt, sie auf eine zu ihren eigenen Systemen passende Weise umzusetzen. Was Sie nicht erhalten, ist ein Ermessen darüber, ob Sie sie erfüllen. Sobald die Anforderung in Ihrem Vertrag erscheint, ist ihre Umsetzung eine Bedingung für das Halten dieses Vertrags. ## CUI und warum die Frage des Geltungsbereichs am wichtigsten ist Alles in NIST SP 800-171 hängt von einer vorgelagerten Frage ab: Wo liegt Controlled Unclassified Information tatsächlich in Ihrer Umgebung? CUI sind Informationen, die die Regierung erstellt oder besitzt, oder die eine Organisation für die Regierung erstellt, die nach einem Gesetz, einer Verordnung oder einer regierungsweiten Richtlinie geschützt werden müssen, aber nicht klassifiziert sind. Sie umfassen Kategorien wie technische Zeichnungen, ausfuhrkontrollierte Daten, personenbezogene Daten, die im Auftrag einer Behörde gehalten werden, und ähnliches sensibles Material. Die Norm gilt nur für die Systeme, die diese Daten speichern, verarbeiten oder übertragen. Deshalb ist die Festlegung des Geltungsbereichs die Arbeit, die alles Weitere bestimmt. Definieren Sie die Grenze zu weit, erlegen Sie Ihrem gesamten Netzwerk Kontrollen auf föderalem Niveau auf, zu enormen Kosten. Definieren Sie sie zu eng, lassen Sie CUI in einem System ungeschützt, das Sie zu zählen vergessen haben. Der Großteil eines glaubwürdigen 800-171-Programms wird darauf verwendet, CUI zu identifizieren, die Systeme zu isolieren, die damit in Berührung kommen, und diese Grenze zu verkleinern, damit die Kontrollen dort greifen, wo sie tatsächlich benötigt werden, statt überall. > **Der Geltungsbereich vor den Kontrollen** Sie können Controlled Unclassified Information nicht schützen, solange Sie nicht wissen, wo sie sich befindet. Bilden Sie zuerst die CUI-Datenflüsse ab und definieren Sie Ihre Systemgrenze; die Kontrollen sind für eine kleine, gut isolierte Enklave weitaus kostengünstiger umzusetzen als für ein gesamtes Unternehmensnetzwerk. ## Wo 800-171 endet und CMMC beginnt NIST SP 800-171 ist der Kontrollkatalog. Die Cybersecurity Maturity Model Certification (CMMC) ist der Verifizierungsmechanismus, den das US Department of Defense darauf aufgebaut hat. Jahrelang bescheinigten Auftragnehmer selbst, dass sie 800-171 erfüllten, und die Kluft zwischen der Bescheinigung und der Realität trat erst nach einem Vorfall zutage. CMMC Level 2 entspricht unmittelbar NIST SP 800-171, fügt aber eine unabhängige Bewertung hinzu, sodass eine Unterschrift nicht mehr ausreicht. Wenn Sie 800-171 wirklich umsetzen, haben Sie den größten Teil der inhaltlichen Arbeit für CMMC Level 2 geleistet; was bleibt, ist die Erbringung von Nachweisen und das Bestehen einer Bewertung durch jemanden, der nicht Sie selbst ist. Die Revision 3, veröffentlicht 2024, hat die Anforderungen umstrukturiert und verschärft, die Kontrollfamilien neu geordnet und einige Einzelheiten in eine begleitende Bewertungspublikation verlagert. Für einen europäischen Lieferanten ist die Relevanz ausschließlich vertraglicher Natur. Wenn Sie für einen US-Prime als Unterauftragnehmer tätig sind, Verteidigungskomponenten fertigen oder CUI für ein DoD-Programm verarbeiten, bindet Sie 800-171 genauso wie ein amerikanisches Unternehmen. Ist Ihr Markt rein europäisch, ist es ein informativer Kontext, der Ihnen hilft, CMMC und die US-Beschaffungsanforderungen zu verstehen, und es ergänzt sich auf natürliche Weise mit der risikobasierten Disziplin des NIST Cybersecurity Framework, anstatt sie zu ersetzen. --- ## Nichtkonformität (NC) **URL:** https://cyberacademy.net/de/resources/encyclopedia/non-conformity **Last reviewed:** 2026-06-24 Eine Nichtkonformität ist der Befund des Auditors, dass eine Anforderung nicht erfüllt wird. Schwerwiegende NCs gefährden das Zertifikat; geringfügige NCs erfordern einen Korrekturmaßnahmenplan mit einer Frist. Wiederholt auftretende geringfügige NCs im selben Bereich können beim nächsten Überwachungsaudit zu schwerwiegenden NCs eskalieren. Das Ziel ist nicht die Abwesenheit von NCs, sondern eine ehrliche und nachvollziehbare Korrekturmaßnahme. ## Was eine Nichtkonformität tatsächlich ist Eine Nichtkonformität dokumentiert eine Lücke zwischen dem, was eine Anforderung verlangt, und dem, was ein Auditor in der Praxis vorfindet. Die Anforderung kann aus der Norm selbst stammen (zum Beispiel aus einem Abschnitt der ISO/IEC 27001), aus einer Maßnahme, die Sie in Ihrer Erklärung zur Anwendbarkeit als anwendbar erklärt haben, oder aus Ihrer eigenen dokumentierten Richtlinie. Wenn Sie es niedergeschrieben und sich dazu verpflichtet haben, kann ein Auditor Sie daran festhalten. Genau dieser letzte Punkt überrascht Teams: zu viel in einer Richtlinie zu versprechen, schafft Nichtkonformitäten, die die Norm allein nie erzeugt hätte. Eine Nichtkonformität ist nicht dasselbe wie eine Beobachtung oder eine Verbesserungsmöglichkeit. Eine Beobachtung weist auf etwas hin, das der Auditor festhalten möchte, ohne zu behaupten, dass eine Anforderung verletzt wird. Eine Nichtkonformität ist eine eindeutige Feststellung, dass eine Anforderung nicht erfüllt ist, gestützt auf objektive Nachweise wie eine Aufzeichnung, ein Interview oder ein fehlendes Artefakt. Die Unterscheidung ist wichtig, weil nur Nichtkonformitäten eine formale Reaktion erzwingen. ## Schwerwiegend gegenüber geringfügig, und wie geringfügige eskalieren Auditoren bewerten Feststellungen nach ihrer Auswirkung auf das Managementsystem, nicht danach, wie sehr sie sie ärgern. Eine schwerwiegende Nichtkonformität bedeutet, dass eine Anforderung grundlegend fehlt oder dass ein Versagen so weit verbreitet ist, dass es das Vertrauen in das Funktionieren des Systems untergräbt. Schwerwiegende gefährden die Zertifizierungsentscheidung und müssen in der Regel geschlossen werden, bevor die Zertifizierung oder Rezertifizierung fortgesetzt werden kann. Eine geringfügige Nichtkonformität ist ein vereinzelter Lapsus in einem ansonsten funktionierenden Prozess: eine einzelne fehlende Überprüfung, eine Aufzeichnung, die nicht unterschrieben wurde. Die Falle besteht darin, geringfügige als harmlos zu behandeln. Dieselbe geringfügige Feststellung im selben Bereich, Audit für Audit, sagt dem Auditor, dass Ihre Korrekturmaßnahme die Grundursache nie behoben hat. Beim nächsten Überwachungsaudit kann dieses Muster als schwerwiegend neu eingestuft werden, denn eine Maßnahme, die immer wieder auf dieselbe Weise versagt, funktioniert in Wirklichkeit nicht. **Wie Auditoren Nichtkonformitäten typischerweise gewichten** | Aspekt | Geringfügige NC | Schwerwiegende NC | | --- | --- | --- | | Umfang | Vereinzelter, eingegrenzter Lapsus | Systemisches oder vollständiges Fehlen einer Anforderung | | Auswirkung auf das Zertifikat | Das Zertifikat läuft normalerweise weiter | Kann die Zertifizierung blockieren oder aussetzen | | Erforderliche Reaktion | Korrekturmaßnahmenplan mit einer Frist | Oft Korrektur sowie erneute Prüfung vor Ort oder per Nachweis | | Bei Wiederholung | Kann beim nächsten Mal zu schwerwiegend eskalieren | Bereits an der Spitze der Skala | ## Was Praktiker tatsächlich damit machen Eine Nichtkonformität gut zu schließen ist ein Prozess, keine Entschuldigung. Das anerkannte Muster lautet Korrektur, dann Korrekturmaßnahme, dann Wirksamkeitsverifizierung. Die Korrektur ist die unmittelbare Behebung des konkreten Falls, den der Auditor gefunden hat. Die Korrekturmaßnahme ist der tiefergehende Schritt: eine Grundursachenanalyse, die erklärt, warum die Lücke bestand, und eine Änderung, die ihr erneutes Auftreten verhindert. Die Verifizierung bestätigt, mit Nachweisen und nachdem genügend Zeit vergangen ist, dass die Änderung tatsächlich Bestand hatte. Jeder dieser Schritte gehört in einen Korrekturmaßnahmenplan mit einem Verantwortlichen und einer realistischen Frist, der der Auditor zustimmt. Die Nachweise, die Sie einreichen, sollten es jemandem, der nicht im Raum war, ermöglichen, zu rekonstruieren, was geschehen ist, und zu bestätigen, dass es geschlossen ist. Hier zahlt sich Ehrlichkeit aus: ein Auditor sieht lieber eine kleine Anzahl gut nachverfolgter Korrekturmaßnahmen als einen sauber wirkenden Bericht, der einer Prüfung nicht standhält. > **Null ist nicht das Ziel** Ein Überwachungsaudit, das überhaupt keine Nichtkonformitäten findet, kann sich wie ein System lesen, das niemand auf die Probe stellt. Das glaubwürdige Ergebnis ist eine überschaubare Liste von Feststellungen, jede mit einer dokumentierten Grundursache und einer nachverfolgbaren Korrekturmaßnahme, die fristgerecht geschlossen wird. --- ## PCI DSS **URL:** https://cyberacademy.net/de/resources/encyclopedia/pci-dss **Last reviewed:** 2026-06-24 PCI DSS is the Payment Card Industry Data Security Standard. Mandatory for anyone storing, processing or transmitting cardholder data. Version 4.0.1 is the current revision, fully mandatory since 31 March 2025. Scope-reduction (tokenisation, segmentation) is where the smart money goes; "compliant" is binary, but how small you make the scope is everything. ## Was PCI DSS tatsächlich regelt PCI DSS ist die Sicherheitsgrundlage, die von den großen Zahlungskartenmarken jeder Organisation auferlegt wird, die Karteninhaberdaten speichert, verarbeitet oder überträgt. Es ist weder ein Gesetz noch eine staatliche Vorschrift. Es ist eine vertragliche Anforderung, durchgesetzt über die Acquiring-Banken und die darüber stehenden Kartenorganisationen. Wenn Sie eine primäre Kontonummer verarbeiten, gilt der Standard für Sie, egal ob Sie ein globaler Einzelhändler oder ein kleiner E-Commerce-Shop mit einer einzigen Checkout-Seite sind. Der Standard ist um eine Reihe von Kontrollzielen herum aufgebaut, die Menschen, Prozesse und Technologien abdecken, die mit Karteninhaberdaten in Berührung kommen: Aufbau und Pflege eines sicheren Netzwerks, Schutz gespeicherter Kontodaten, Verschlüsselung der Übertragung, Schwachstellenmanagement, Beschränkung des Zugriffs nach dem Need-to-know-Prinzip, Überwachung und Protokollierung sowie die Pflege einer schriftlichen Informationssicherheitsrichtlinie. Jedes Ziel zerfällt in konkrete, prüfbare Anforderungen, weshalb sich PCI DSS eher wie eine Audit-Checkliste liest als wie ein prinzipienbasiertes Rahmenwerk wie ISO 27001. ## Der Geltungsbereich ist das A und O Die wichtigste Entscheidung für den Praktiker ist nicht, wie die Bewertung bestanden wird, sondern wie das zu Bewertende verkleinert wird. Alles, was Karteninhaberdaten speichert, verarbeitet oder überträgt, sowie alles, was damit verbunden ist, fällt in die Karteninhaberdaten-Umgebung (CDE). Je größer die CDE, desto mehr Systeme müssen jede Anforderung erfüllen, und desto mühsamer und teurer wird die Bewertung. Hier zahlen sich Tokenisierung, Netzwerksegmentierung und Auslagerung an konforme Zahlungsdienstleister aus. Indem Sie Kartennummern durch Token ersetzen, die CDE hinter Firewalls isolieren und die eigentliche Kartenerfassung auf eine gehostete Seite oder einen Drittanbieter-Prozessor verlagern, entfernen Sie Systeme vollständig aus dem Geltungsbereich. Eine gut segmentierte Umgebung kann eine ausufernde Landschaft auf eine Handvoll Komponenten reduzieren, die eine vollständige Validierung benötigen. > **Konformität ist binär, der Geltungsbereich nicht** Entweder Sie erfüllen jede anwendbare Anforderung oder nicht; es gibt keine Teilanrechnung. Aber wie klein Sie die Karteninhaberdaten-Umgebung machen, bestimmt, wie viel Aufwand dieses binäre Ergebnis kostet. Die Reduzierung des Geltungsbereichs ist der wirkungsvollste Hebel in jedem PCI-Programm. ## Wie die Validierung in der Praxis funktioniert Wie Sie die Konformität nachweisen, hängt vom Transaktionsvolumen und davon ab, wie Sie Zahlungen annehmen. Kleinere Händler füllen in der Regel einen Self-Assessment Questionnaire (SAQ) aus und wählen die Version, die ihrem Akzeptanzkanal entspricht. Größere Händler und Dienstleister durchlaufen eine formale Bewertung durch einen Qualified Security Assessor (QSA), der einen Report on Compliance erstellt. Netzwerk-Scans durch einen Approved Scanning Vendor und vierteljährliche Nachweise sind über alle Stufen hinweg übliche Verpflichtungen. Die aktuelle Revision, Version 4.0.1, geht über eine reine Checkliste hinaus. Neben dem präskriptiven „definierten Ansatz“ führt sie einen „angepassten Ansatz“ ein, der es reifen Organisationen erlaubt, ein Kontrollziel mit eigenen gestalteten Kontrollen zu erfüllen, sofern sie dokumentieren und nachweisen können, dass das Ziel erreicht ist. Sie formuliert Konformität zudem als kontinuierlichen Zustand statt als jährliche Momentaufnahme um, wobei mehrere Anforderungen ausdrücklich eine in den laufenden Betrieb integrierte Überwachung verlangen. ## Wie es sich neben anderen Standards einordnet Teams verwechseln PCI DSS häufig mit ISO 27001. Sie überschneiden sich, beantworten aber unterschiedliche Fragen. ISO 27001 bescheinigt, dass Sie ein Informationssicherheits-Managementsystem betreiben; PCI DSS validiert, dass ein spezifischer, vorgeschriebener Satz von Kontrollen Karteninhaberdaten schützt. Das eine ist eine Managementsystem-Zertifizierung, deren Geltungsbereich Sie selbst festlegen; das andere ist ein fester Kontrollsatz, der von einem externen Branchengremium auferlegt wird. Der Betrieb eines ISO-27001-ISMS verschafft Ihnen ein Governance-Gerüst, das die Erstellung von PCI-Nachweisen erleichtert, ersetzt aber nicht die kartendatenspezifischen Anforderungen. **PCI DSS im Vergleich zu ISO 27001** | Dimension | PCI DSS | ISO 27001 | | --- | --- | --- | | Wesen | Vertraglicher Branchenstandard | Internationaler zertifizierbarer Standard | | Auferlegt durch | Die Kartenmarken über die Acquiring-Banken | Freiwillig von der Organisation übernommen | | Geltungsbereich | Karteninhaberdaten-Umgebung (fester Fokus) | Was die Organisation festlegt | | Kontrollsatz | Vorgeschrieben und prüfbar | Risikogetrieben, von der Organisation ausgewählt | | Ergebnis | Attestation / Report on Compliance | Akkreditiertes Zertifikat | --- ## Patch-Management **URL:** https://cyberacademy.net/de/resources/encyclopedia/patch-management **Last reviewed:** 2026-06-24 Patch-Management ist der operative Prozess, der einen veröffentlichten Fix entgegennimmt, ihn gemäß einem definierten SLA unternehmensweit einspielt und dessen Wirksamkeit verifiziert. Häufig das schwächste Glied: Notfall-Patches kollidieren mit Change-Windows, Herstellerkompatibilität und Abhängigkeiten von Drittanbietern. Das Audit fragt stets nach dem SLA, der Ausnahmeliste und den Kennzahlen. ## Vom veröffentlichten Fix zum ausgerollten Bestand Patch Management ist die operative Disziplin, die die Lücke zwischen dem Moment schließt, in dem ein Hersteller einen Fix veröffentlicht, und dem Moment, in dem dieser Fix tatsächlich auf jeder betroffenen Maschine läuft, die Sie besitzen. Ein Patch kann ein Sicherheitsupdate, eine Fehlerbehebung oder eine Firmware-Revision sein, und er kann auf Betriebssysteme, Anwendungen, Hypervisoren, Netzwerkgeräte, Container oder industrielle Steuerungen treffen. Beim Prozess geht es selten um den einzelnen Akt, ein Update zu installieren. Es geht darum, dies in großem Maßstab zu tun, in einer kontrollierten Reihenfolge, ohne die Dienste zu beschädigen, die von den geänderten Systemen abhängen. Deshalb behandeln reife Teams ihn als definierten Workflow statt als improvisierte Reaktion auf jeden neuen Hinweis. Ein praktikabler Zyklus hat erkennbare Phasen. Sie inventarisieren den Bestand, damit Sie wissen, wofür Sie verantwortlich sind, Sie erfassen und triagieren Hinweise, um zu erfahren, welche Patches für Sie relevant sind, Sie testen in einer repräsentativen Umgebung, Sie rollen über das Change Management gemäß einem definierten Service-Level-Agreement aus, und Sie überprüfen, dass der Patch vorhanden ist und das System weiterhin funktioniert. Jede Phase erzeugt Nachweise, und diese Nachweise sind es, die eine hoffnungsvolle Absicht in eine auditierbare Kontrolle verwandeln. ## Warum es so oft das schwächste Glied ist Auf dem Papier sieht Patch Management einfach aus. In der Praxis ist es der Punkt, an dem gute Sicherheitsprogramme still scheitern. Die shortDefinition nennt die üblichen Verursacher, und jeder davon ist eine echte operative Spannung. Notfall-Patches kommen außerhalb des Zyklus an und kollidieren mit den Change-Fenstern, die die Produktion stabil halten, sodass der dringende Fix hinter dem Kalender wartet. Herstellerkompatibilität bedeutet, dass ein Patch für eine Komponente eine andere beschädigen kann, was genau der Grund ist, warum Tests existieren und warum Tests Zeit kosten, die Sie während eines aktiven Ausnutzungsereignisses möglicherweise nicht haben. Drittanbieter- und transitive Abhängigkeiten verbergen betroffenen Code in Produkten, die Sie nicht geschrieben haben, sodass Sie eine Bibliothek patchen, nur um festzustellen, dass ein Dutzend Anwendungen die verwundbare Version weiterhin eingebettet ausliefern. Das Ergebnis ist ein Rückstau an Systemen, die nicht sofort gepatcht werden können, und eine Reihe von Entscheidungen darüber, welche Risiken zu tragen sind. Das ist normal. Was ein kontrolliertes Programm von einem exponierten unterscheidet, ist, ob diese Entscheidungen bewusst, dokumentiert und zeitlich begrenzt sind, oder ob es einfach Dinge sind, um die sich niemand gekümmert hat. Die Abdeckung der Assets zählt ebenso wie die Patch-Geschwindigkeit: Ein ungepatchter Server, dessen Besitz Sie vergessen hatten, ist gefährlicher als ein bekannter, dessen Aufschub Sie beschlossen haben. > **Die Ausnahme ist die Kontrolle** Wenn ein System nicht rechtzeitig gepatcht werden kann, lautet die Antwort nicht Schweigen. Sie lautet eine protokollierte Ausnahme mit einer geschäftlichen Begründung, einer kompensierenden Kontrolle, einem Verantwortlichen und einem Ablaufdatum. Eine Ausnahmeliste, die überprüft wird, ist gutes Risikomanagement. Ein Rückstau, den niemand verfolgt, ist nichts weiter als ungesteuerte Exposition mit einer bereits abgelaufenen Frist. ## Patch Management versus Vulnerability Management Diese beiden Begriffe reisen zusammen und werden oft verwechselt, doch sie beantworten unterschiedliche Fragen. Beim Vulnerability Management geht es um das Wissen: Schwachstellen im gesamten Bestand entdecken, sie nach Risiko bewerten und priorisieren und entscheiden, was zu tun ist. Beim Patch Management geht es um das Handeln: Es ist einer der Remediationswege, der eine Schwachstelle schließt, neben Konfigurationsänderungen, Mitigationen und Virtual Patching. Nicht jede Schwachstelle wird durch einen Patch behoben, und nicht jeder Patch schließt eine Sicherheitslücke, sodass sich die beiden Prozesse überschneiden, ohne dasselbe zu sein. **Patch Management vs Vulnerability Management** | Dimension | Patch Management | Vulnerability Management | | --- | --- | --- | | Kernfrage | Ist der Fix überall ausgerollt, wo er sein sollte? | Welche Schwachstellen haben wir und welche zählen am meisten? | | Primäre Eingabe | Hersteller-Patches und -Updates | Scans, Hinweise, Threat Intelligence, Asset-Kontext | | Primäre Ausgabe | Gepatchte, verifizierte Systeme auf einem SLA | Ein priorisierter, nach Risiko geordneter Remediation-Rückstau | | Umfang | Remediation durch das Anwenden von Updates | Entdeckung, Bewertung, Priorisierung und Überwachung der Remediation | In einem gesunden Programm speisen sie einander. Das Vulnerability Management sagt Ihnen, welche Patches es verdienen, die Warteschlange zu überspringen, und das Patch Management meldet zurück, welche Fixes tatsächlich ausgeliefert wurden, sodass der nächste Scan sauber zurückkommen sollte. Wenn sie als getrennte Silos betrieben werden, werden Schwachstellen in Berichte triagiert, die kein Rollout-Prozess je verwendet. ## Was ein Auditor und ein Regulierer verlangen werden Patch Management ist eine der am direktesten geprüften operativen Kontrollen, weil der Nachweis konkret ist. Es unterstützt Kontrollziele im Rahmen eines Informationssicherheits-Managementsystems nach ISO/IEC 27001, insbesondere jene, die technische Schwachstellen und Change Management abdecken, und es untermauert die Erwartungen an sichere Konfiguration und Wartung, die in Frameworks wie dem NIST Cybersecurity Framework und Kontrollsätzen wie den CIS Controls verankert sind. Vorschriften, darunter NIS2 und DORA, setzen voraus, dass eine Organisation eine zeitnahe Remediation bekannter Schwachstellen nachweisen kann, und Patch Management ist die Art und Weise, wie dieser Nachweis erbracht wird. Die Fragen sind vorhersehbar, weshalb die shortDefinition sie auflistet. Rechnen Sie damit, die Patching-Richtlinie und das SLA vorzulegen, das definiert, wie schnell die verschiedenen Schweregrade ausgerollt werden müssen, die Ausnahmeliste mit Begründungen und Verantwortlichen, und die Metriken, die belegen, dass der Prozess funktioniert: Anteil der innerhalb des SLA gepatchten Assets, mittlere Zeit bis zum Patch, Alter der ältesten offenen Ausnahme, und Abdeckung des Asset-Inventars. Wenn Sie diese ohne Hektik vorlegen können, ist Ihr Programm real. Wenn nicht, hat das Audit das schwächste Glied gefunden, bevor es ein Angreifer tut. --- ## Penetration Testing **URL:** https://cyberacademy.net/de/resources/encyclopedia/penetration-testing **Last reviewed:** 2026-06-24 Ein Penetrationstest ist eine autorisierte, im Umfang definierte Angriffssimulation, um ausnutzbare Schwachstellen zu finden, bevor echte Angreifer dies tun. Black Box / Grey Box / White Box, intern / extern, Applikation / Infrastruktur. Abzugrenzen vom Vulnerability Scan (automatisiert, breit angelegt) und vom Red Team (mehrere Monate, zielorientiert). Die Berichte speisen den Remediation-Backlog. ## Was ein Penetrationstest tatsächlich ist Ein Penetrationstest ist ein bewusster, autorisierter Versuch, in ein System einzudringen, so wie es ein echter Angreifer täte, durchgeführt im Rahmen eines schriftlichen Umfangs und festgelegter Einsatzregeln. Es geht nicht darum, theoretische Schwachstellen aufzulisten, sondern zu beweisen, welche sich tatsächlich verketten lassen, um etwas Bedeutsames zu erreichen: eine Datenbank, ein Administratorkonto, einen Kundendatensatz, einen Zahlungsfluss. Ein Tester folgt demselben Weg wie ein Eindringling, aber mit Erlaubnis und einer definierten Grenze, sodass die Organisation erfährt, wo sie versagen würde, bevor es jemand Feindseliges tut. Die Autorisierung ist es, die einen Penetrationstest von einer Straftat trennt; ohne unterzeichneten Umfang sind dieselben Handlungen schlicht ein Eindringen. Aufträge werden entlang einiger Achsen abgesteckt, die der Umfang vorab festlegen muss. Der Kenntnisstand reicht von der Blackbox, bei der der Tester mit nichts als einem Namen oder einem IP-Bereich beginnt, über die Greybox, bei der er ein Konto mit geringen Rechten oder eine teilweise Dokumentation erhält, bis zur Whitebox, bei der er Quellcode, Architekturdiagramme und vollständige Zugangsdaten bekommt. Der Aussichtspunkt ist entweder extern, was einen Angreifer im Internet simuliert, oder intern, was jemanden simuliert, der bereits im Netzwerk gelandet ist, oder einen böswilligen Insider. Der Zieltyp unterscheidet das Anwendungstesten, das eine Web- oder Mobil-App und ihre Logik untersucht, vom Infrastrukturtesten, das sich Hosts, Diensten und Netzwerkkonfiguration widmet. Die meisten realen Programme mischen diese Ansätze, um zu den Bedrohungen zu passen, die ihnen tatsächlich Sorgen bereiten. ## Worin er sich von einem Scan und von einem Red Team unterscheidet Die häufigste Verwechslung besteht zwischen einem Penetrationstest und einem Schwachstellenscan, und die beiden sind nicht dasselbe. Ein Schwachstellenscan ist automatisiert und auf Breite optimiert: Ein Werkzeug durchsucht jeden erreichbaren Vermögenswert, gleicht das Gefundene mit einer Datenbank bekannter Probleme ab und erzeugt eine lange Liste. Er ist schnell, wiederholbar und günstig, aber er kann nicht sagen, ob ein bestimmter Befund in Ihrer Umgebung wirklich ausnutzbar oder ein Fehlalarm ist. Ein Penetrationstest ist menschengeführt und auf Tiefe optimiert: Ein Tester validiert Befunde, indem er sie tatsächlich ausnutzt, verkettet mehrere Probleme geringerer Schwere zu einer echten Kompromittierung und prüft die Geschäftslogik und Vertrauensannahmen, die kein Scanner versteht. Ein Scan sagt Ihnen, was falsch sein könnte; ein Penetrationstest sagt Ihnen, was ein Angreifer wirklich damit anstellen könnte. Am anderen Ende steht das Red Team, das ebenfalls häufig mit dem Penetrationstest verwechselt wird. Ein Red-Team-Auftrag ist länger, läuft oft über Monate, und er ist zielbasiert statt abdeckungsbasiert: Das Ziel ist, ein bestimmtes Ergebnis zu erreichen, etwa einen definierten Datensatz zu exfiltrieren oder ein bestimmtes System zu erreichen, dabei unentdeckt zu bleiben und zu prüfen, ob die Verteidiger es bemerken und reagieren. Ein Penetrationstest strebt Abdeckung innerhalb eines Umfangs an und ist den betreffenden Teams meist bekannt; ein Red Team verfolgt ein einziges tiefes Ziel und prüft Erkennung und Reaktion bewusst ebenso wie die Kontrollen selbst. **Der Penetrationstest im Vergleich zu einem Schwachstellenscan und einem Red Team** | Dimension | Schwachstellenscan | Penetrationstest | Red Team | | --- | --- | --- | --- | | Methode | Automatisierte Werkzeuge | Menschengeführt, praktisch | Menschengeführt, Angreiferemulation | | Ziel | Breite: bekannte Probleme auflisten | Tiefe: Ausnutzbarkeit im Umfang nachweisen | Zielsetzung: ein definiertes Ziel erreichen | | Validierung | Keine Ausnutzung | Befunde ausgenutzt und verkettet | Vollständige Angriffskette bis zum Ziel | | Erkennung getestet | Nein | Üblicherweise nicht | Ja, prüft die Verteidiger direkt | | Typische Dauer | Minuten bis Stunden | Tage bis Wochen | Wochen bis Monate | ## Wo er in einem Sicherheitsprogramm steht Ein Penetrationstest ist eine Momentaufnahme, keine Kontrolle für sich. Sein wahrer Wert entfaltet sich nach dem Auftrag, wenn der Bericht in den Behebungsrückstand einfließt. Ein guter Bericht tut mehr, als Befunde aufzulisten: Er ordnet sie nach Ausnutzbarkeit und geschäftlicher Auswirkung, liefert reproduzierbare Nachweise und empfiehlt Korrekturen. Diese Befunde werden zu Tickets, Verantwortlichen und Fristen innerhalb des umfassenderen Schwachstellenmanagementprozesses, und ein erneuter Test bestätigt, dass die Korrekturen die Lücken tatsächlich geschlossen und nicht nur verlagert haben. Ohne diese Nachverfolgung ist ein Test nur ein teures Dokument. Der Penetrationstest taucht auch ausdrücklich in Normen und Regulierung auf. Ein an ISO/IEC 27001 ausgerichtetes Informationssicherheits-Managementsystem behandelt technische Tests als Mittel, um zu überprüfen, dass Kontrollen in der Praxis funktionieren, und Rahmenwerke für Zahlungsverkehr, kritische Infrastrukturen und Finanzdienstleistungen erwarten zunehmend regelmäßige, abgesteckte Tests internetexponierter und kritischer Systeme. ENISA und nationale Behörden wie ANSSI veröffentlichen Leitlinien zur verantwortungsvollen Beauftragung von Tests, und das offensive Fähigkeitsprofil ist in Zertifizierungen für ethische Hacker formalisiert. Was Praktiker tatsächlich liefern, ist ein wiederkehrender Rhythmus: den Auftrag abstecken, Einsatzregeln und eine schriftliche Autorisierung vereinbaren, testen, berichten, beheben, erneut testen und wiederholen, während sich die Umgebung verändert. > **Ein Test ist der Beginn der Arbeit, nicht das Ende** Das Ergebnis, das zählt, ist nicht der Bericht, sondern was danach geschieht. Eingeordnete, ausnutzbare Befunde werden zu zugewiesenen Tickets im Behebungsrückstand, und ein erneuter Test beweist, dass sie tatsächlich geschlossen wurden. Ein Penetrationstest ohne dahinterliegende Behebungsschleife verleiht ein Vertrauen, das er sich nicht verdient hat. --- ## Phishing **URL:** https://cyberacademy.net/de/resources/encyclopedia/phishing **Last reviewed:** 2026-06-24 Phishing ist der Social-Engineering-Angriff, der einen Benutzer dazu verleitet, auf einen schädlichen Link zu klicken, eine schädliche Datei zu öffnen oder Zugangsdaten preiszugeben. Varianten: Spear-Phishing (gezielt), Whaling (Führungskräfte), Smishing (SMS), Vishing (Sprache), BEC (Business Email Compromise). Schulungen sind wichtig; Phishing-resistente MFA ist noch wichtiger. ## Warum Phishing der dominierende Einstiegspunkt bleibt Phishing besteht fort, weil es die Person angreift, nicht den Perimeter. Jede andere Kontrolle kann perfekt konfiguriert sein, und dennoch braucht der Angreifer nur einen einzigen Mitarbeiter, der auf einen Link klickt, eine Datei öffnet oder ein Passwort in eine überzeugende Fälschung eingibt. Die Nachricht trifft über einen vertrauenswürdigen Kanal ein, meist E-Mail, aber zunehmend auch SMS und Sprache, und übernimmt das Aussehen und den Tonfall einer Marke, eines Kollegen oder eines internen Systems, von dem das Opfer ohnehin etwas erwartet. Da die Nutzlast oft hinter einer frisch registrierten Domain oder einer legitim wirkenden Cloud-Anmeldeseite liegt, kommen signaturbasierte Filter und Reputationslisten häufig zu spät. Auch die Ökonomie begünstigt den Angreifer: Eine einzige Vorlage lässt sich nahezu kostenlos an Tausende Empfänger streuen, und ein einziger Erfolg kann Zugangsdaten liefern, die alles Übrige aufschließen. Worauf Praktiker achten, ist die Verschiebung von Masse zu Präzision. Massen-Phishing ist ein weites Netz, aber die kostspieligen Vorfälle beginnen meist mit einer maßgeschneiderten Nachricht, die ihre Hausaufgaben zu Ziel, Organigramm und Zeitpunkt erkennbar gemacht hat. ## Die in der Praxis relevanten Varianten Phishing ist eine Familie, nicht eine einzelne Technik. Die Logik des Social Engineering bleibt konstant, während Kanal und Ziel sich ändern. - Spear Phishing: eine gezielte Nachricht, die für eine bestimmte Person oder ein bestimmtes Team gestaltet ist und echte Namen, Projekte und Kontext nutzt, um den Argwohn zu senken. - Whaling: Spear Phishing, das auf Führungskräfte und andere hochwertige Freigebende abzielt, bei denen ein einziges kompromittiertes Konto übermäßige Autorität trägt. - Smishing: per SMS zugestelltes Phishing, oft eine gefälschte Liefer-, Bank- oder MFA-Zurücksetzungs-Aufforderung, die den kleineren Bildschirm und die Gewohnheit ausnutzt, Textnachrichten zu vertrauen. - Vishing: Phishing per Sprachanruf, bei dem ein Angreifer das Opfer in Echtzeit unter Druck setzt, zunehmend unterstützt durch gefälschte Rufnummern und synthetische Audioinhalte. - Business email compromise: ein Pretexting-Untertyp, der Zahlungs- und Datenprozesse direkt ins Visier nimmt, in der Regel ganz ohne bösartigen Link oder Anhang. ## Was das Risiko tatsächlich senkt Sensibilisierungsschulungen sind notwendig, aber nicht ausreichend. Menschen werden immer in einem gewissen Anteil der Fälle klicken, daher besteht das Ziel darin, den Wert eines Klicks zu beseitigen, anstatt von den Nutzern Perfektion zu verlangen. Die entscheidende technische Kontrolle ist phishing-resistente Multi-Faktor-Authentifizierung, also Faktoren, die an die legitime Domain gebunden sind, etwa FIDO2-Sicherheitsschlüssel oder Passkeys, die eine gefälschte Anmeldeseite nicht wiedergeben kann. Dahinter liegen in Schichten die Kontrollen, die abfangen, was durchrutscht. - Phishing-resistente MFA auf jedem Konto, das zählt, sodass ein abgegriffenes Passwort allein nicht zur Anmeldung ausreicht. - E-Mail-Authentifizierung mit SPF, DKIM und DMARC, um die Kosten des Domain-Spoofings zu erhöhen, kombiniert mit einem sicheren E-Mail-Gateway und Link-Rewriting oder Sandboxing. - Kontinuierliche, szenariobasierte Sensibilisierungsschulung plus simuliertes Phishing, gemessen, um sich im Laufe der Zeit zu verbessern, statt Einzelne zu bestrafen. - Eine reibungslose Meldeschaltfläche und ein schneller Reaktionsprozess, denn die Menschen, die melden, sind das Frühwarnsystem für jene, die geklickt haben. > **Schule den Menschen, aber gestalte den Klick weg** Sensibilisierung senkt die Klickrate; sie erreicht nie null. Phishing-resistente MFA, die an die echte Domain gebunden ist, verhindert, dass aus gestohlenen Zugangsdaten eine Kontoübernahme wird. Behandle Schulung als eine Schicht, nicht als die Kontrolle. ## Wo Phishing in Normen und Regulierung verortet ist Phishing liegt voll im Anwendungsbereich eines Informationssicherheits-Managementsystems. In einem ISMS nach ISO/IEC 27001 kombiniert die einschlägige Behandlung Sensibilisierungsschulung, Zugriffskontrolle und die technischen E-Mail- und Authentifizierungskontrollen, allesamt durch Risikobeurteilung ausgewählt statt reflexhaft angeheftet. Europäische Leitlinien der ENISA und nationaler Behörden wie der ANSSI ordnen Phishing durchgängig unter die wichtigsten Techniken des Erstzugriffs ein und veröffentlichen praktische Gegenmaßnahmen. Wenn ein erfolgreiches Phishing personenbezogene Daten offenlegt, etwa über ein kompromittiertes Postfach, kann es auch Pflichten zur Meldung einer Verletzung des Schutzes personenbezogener Daten nach der GDPR auslösen, was bedeutet, dass die Rechtsabteilung und die Datenschutzfunktion neben IT und Sicherheit in den Reaktionsplan gehören. Für Praktiker lautet die Lehre, dass die Phishing-Abwehr geschichtet und geteilt ist. Kein einzelnes Werkzeug und keine Sensibilisierungskampagne schließt sie allein. Die belastbare Haltung kombiniert Menschen, Prozesse und Authentifizierungsdesign, sodass ein Klick, der irgendwann erfolgen wird, nicht zu einer Verletzung wird. --- ## Privacy by Design und Privacy by Default **URL:** https://cyberacademy.net/de/resources/encyclopedia/privacy-by-design **Last reviewed:** 2026-06-24 Privacy by Design (GDPR Artikel 25) verpflichtet dazu, Datenschutzmaßnahmen bereits in der Anforderungsphase in Systeme einzubauen. Privacy by Default verpflichtet dazu, die Option mit dem höchsten Schutzniveau zum Standard zu machen. Auditoren suchen nach dokumentierten Nachweisen (DPIA, Design-Review, Aufbewahrungsstandards) und nicht nach einem Slogan in einer Richtlinie. ## Zwei Pflichten, nicht eine Privacy by Design und Privacy by Default sind als eine einzige Pflicht der DSGVO formuliert, verlangen aber zwei verschiedene Dinge, und Praktiker geraten in Schwierigkeiten, wenn sie beide zusammenwerfen. By Design bedeutet, dass Datenschutzvorkehrungen bereits in der Anforderungsphase in ein System eingebaut werden, bevor eine Zeile Code geschrieben oder ein Anbieter ausgewählt wird, statt nachträglich angesetzt zu werden, sobald die Auskunftsersuchen der betroffenen Personen eintreffen. By Default bedeutet, dass das System sich bereits in seiner schützendsten Einstellung befindet, wenn ein Nutzer nichts unternimmt: die engste Datenerhebung, die kürzeste Speicherung, die strikteste Weitergabe. Das eine betrifft, wie Sie bauen; das andere, was das System am ersten Tag ohne jede Konfiguration tut. Die Unterscheidung ist wichtig, weil ein Team die eine Pflicht erfüllen und die andere verfehlen kann. Sie können eine gründliche Designprüfung durchführen, eine DSFA dokumentieren und dennoch ein Produkt ausliefern, dessen Standardschalter allesamt auf maximale Weitergabe gesetzt sind, weil das Wachstumsteam genau das verlangt hat. Dieses Produkt ist Privacy by Design, aber nicht by Default, und es ist nicht konform. Auch der umgekehrte Fall kommt vor: Eine vorsichtige Standardeinstellung, die nachträglich auf ein nie bewertetes System gesetzt wird, lässt den Verantwortlichen außerstande, nachzuweisen, wie die Entscheidung getroffen wurde. ## Was sich dadurch in der Praxis tatsächlich ändert Die praktische Verschiebung besteht darin, den Datenschutz nach vorn zu verlagern. Statt dass die Rechtsabteilung eine fertige Funktion prüft, werden Datenschutzanforderungen zu Designvorgaben, die Entwicklung und Produkt vom ersten Sprint an mittragen. Datenminimierung ist kein Schlagwort mehr, sondern wird zur Frage an jedes Feld jedes Formulars: Brauchen wir das, um den Dienst zu erbringen, und wenn nicht, warum ist es da. Die Zweckbindung wird zu einer Einschränkung dafür, wofür ein Datenbestand später weiterverwendet werden darf. Die Speicherung wird zu einem standardmäßigen Zeitplan, den das System durchsetzt, und nicht zu einer manuellen Bereinigung, an die niemand denkt. - Erheben Sie die minimale Anzahl an Feldern, die der Dienst wirklich benötigt, und begründen Sie jedes einzelne. - Legen Sie Speicherfristen als durchgesetzte Standardwerte fest, mit automatischer Löschung oder Anonymisierung bei deren Ablauf. - Stellen Sie die Standardeinstellungen für Weitergabe, Sichtbarkeit und Profiling auf die am wenigsten freizügige Option ein und überlassen Sie es dem Nutzer, mehr zu erlauben. - Setzen Sie Pseudonymisierung und Verschlüsselung als architektonische Standardentscheidungen ein, nicht als Ausnahmen. - Begrenzen Sie den Zugriff auf personenbezogene Daten nach Zweck, sodass ein System nur das offenlegt, was eine bestimmte Funktion erfordert. > **Prüfer wollen Nachweise, kein Schlagwort** Eine Zeile in einer Datenschutzerklärung, die besagt, dass Sie Privacy by Design praktizieren, beweist nichts. Was einer Prüfung standhält, sind dokumentierte Nachweise, dass die Pflicht erfüllt wurde: eine DSFA für Verarbeitungen mit höherem Risiko, Aufzeichnungen der Designprüfung, die belegen, dass der Datenschutz vor dem Bau berücksichtigt wurde, und die tatsächliche Standardkonfiguration des Live-Systems. Wenn Sie das Artefakt nicht vorweisen können, behandelt der Prüfer die Maßnahme als nicht vorhanden. ## Wie es sich zu benachbarten Konzepten verhält Privacy by Design lässt sich am leichtesten im Kontrast zu dem verstehen, womit man es verwechselt. Es ist nicht dasselbe wie eine DSFA, die ein Nachweisstück dafür ist, dass die umfassendere Pflicht für eine bestimmte Verarbeitungstätigkeit mit höherem Risiko erfüllt wurde. Es ist nicht Security by Design, die Daten vor Angreifern schützt, unabhängig davon, ob diese Daten überhaupt hätten erhoben werden dürfen; Privacy by Design setzt einen Schritt früher an, indem es die Erhebung selbst hinterfragt. Und es ist kein einmaliges Tor. Da Systeme sich weiterentwickeln, ist die Pflicht fortlaufend: Jede neue Funktion, Integration oder jeder neue Datenfluss wirft dieselben Fragen nach Minimierung, Zweck und Standardeinstellungen erneut auf. In einem ausgereiften Programm wird Privacy by Design zu einer im Entwicklungslebenszyklus verankerten Gewohnheit statt zu einem Kontrollpunkt in der Hand der Rechtsabteilung. Produkt und Entwicklung werfen die Fragen selbst auf, die DSFA wird automatisch ausgelöst, wenn die Verarbeitung eine Risikoschwelle überschreitet, und die Standardkonfiguration wird als Teil des Releases überprüft, statt in der Produktion entdeckt zu werden. Das ist der Unterschied zwischen einer Organisation, die das Prinzip nachweisen kann, und einer, die es lediglich behauptet. --- ## Privileged Access Management (PAM) **URL:** https://cyberacademy.net/de/resources/encyclopedia/pam **Last reviewed:** 2026-06-24 PAM ist die Teilmenge von IAM, die sich auf privilegierte Konten konzentriert: Admins, Root, Service-Accounts, Break-Glass. PAM verwahrt Zugangsdaten in einem Vault, vermittelt Sessions und protokolliert Aktivitäten. Es ist das erste Ziel eines Angreifers nach dem initialen Foothold und die Kontrolle, die Auditoren unter NIS 2 und DORA am intensivsten prüfen. ## Warum privilegierte Konten ein eigenständiges Problem darstellen Jedes Identitätsprogramm beginnt mit gewöhnlichen Benutzern: wer sie sind, was sie öffnen können, wie sie sich ausweisen. Privileged Access Management befasst sich mit den Konten, die oberhalb dieser Ebene angesiedelt sind. Domänenadministratoren, Root- und lokale Administratorkonten, Datenbankeigentümer, Hypervisor-Konsolen, Cloud-Root-Identitäten, Dienstkonten, die unbeaufsichtigt laufen, und die Notfallkonten, die für Ausnahmesituationen vorgehalten werden. Diese Identitäten können die Konfiguration ändern, Daten lesen oder zerstören, die Protokollierung deaktivieren und neue Konten anlegen. Der Wirkungsradius eines einzigen kompromittierten Administratorzugangs umfasst die gesamte Umgebung, weshalb PAM als eigenständige Disziplin behandelt wird und nicht als Funktion des allgemeinen IAM. Der entscheidende Schritt von PAM besteht darin, privilegierte Zugangsdaten nicht länger als etwas zu behandeln, das eine Person einfach kennt. Stattdessen liegt das Geheimnis in einem Tresor, der Zugriff wird angefordert und genehmigt, die Sitzung wird über ein kontrolliertes Gateway vermittelt, und alles, was der privilegierte Benutzer tut, wird aufgezeichnet. Der Mensch sieht das Passwort oft überhaupt nicht. Diese Trennung zwischen dem Bediener und dem Geheimnis macht privilegierte Aktivität prüfbar und widerrufbar. ## Was ein PAM-Programm tatsächlich steuert In der Praxis kombiniert eine ausgereifte PAM-Implementierung mehrere Mechanismen, die direkt dem entsprechen, was Auditoren erwarten: - Tresorisierung von Zugangsdaten: privilegierte Passwörter, SSH-Schlüssel und API-Geheimnisse werden zentral gespeichert, automatisch rotiert und niemals in Skripte oder Konfigurationsdateien eingebettet. - Sitzungsvermittlung und -aufzeichnung: Administratoren verbinden sich über einen Proxy, der die Zugangsdaten einschleust, sodass die Sitzung überwacht, aufgezeichnet und beendet werden kann, ohne dass der Bediener das Geheimnis jemals besitzt. - Just-in-time-Rechteerhöhung: Rechte werden für eine definierte Aufgabe und ein definiertes Zeitfenster gewährt und anschließend entzogen, statt dauerhaft am Konto bestehen zu bleiben. - Break-Glass-Verfahren: Notfallkonten sind versiegelt, mit einer Alarmierung versehen und werden nach jeder Verwendung überprüft, sodass sie für echte Ausfälle existieren, ohne zu einer stillen Hintertür zu werden. - Erkennung und Nachvollziehbarkeit: Das Werkzeug findet privilegierte Konten und Dienstkonten im gesamten Bestand und führt jede privilegierte Aktion auf einen namentlich benannten Menschen zurück. > **PAM ist eine Kontrolle, kein Produkt** Der Kauf eines Tresors liefert kein PAM. Die Kontrolle ist die Kombination aus einem sauberen Inventar privilegierter Konten, einem Genehmigungsworkflow, der Rotation, der Sitzungsaufzeichnung und der Überprüfung. Das Werkzeug setzt eine Richtlinie durch, die Sie weiterhin selbst schreiben müssen. **PAM im Vergleich zum allgemeinen IAM** | Dimension | Allgemeines IAM | PAM | | --- | --- | --- | | Geltungsbereich | Alle Identitäten und Zugriffe | Nur privilegierte Konten (Admin, Root, Dienst, Break-Glass) | | Kernfrage | Sollte diese Person Zugriff haben? | Wie wird dieser erhöhte Zugriff tresorisiert, vermittelt und protokolliert? | | Umgang mit Zugangsdaten | Der Benutzer authentifiziert sich mit seinen eigenen Zugangsdaten | Das Geheimnis wird tresorisiert und eingeschleust; der Bediener sieht es möglicherweise nie | | Standardhaltung | Dauerhafte Berechtigungen, die über die Zeit verwaltet werden | Just-in-time, zeitlich begrenzt, nach Gebrauch entzogen | | Audit-Schwerpunkt | Zugriffsüberprüfungen und Eintritt-Wechsel-Austritt | Sitzungsaufzeichnung, Rotation, Überprüfung der Break-Glass-Konten | ## Wo PAM im IAM und im regulatorischen Umfeld angesiedelt ist PAM ist eine Teilmenge des Identitäts- und Zugriffsmanagements, eingegrenzt auf die Konten mit dem höchsten Risiko, und es ist die Speerspitze des Prinzips der geringsten Rechte. Das allgemeine IAM fragt, ob eine Person überhaupt Zugriff haben sollte. PAM geht davon aus, dass der Zugriff legitim ist, besteht aber darauf, dass er temporär, vermittelt, protokolliert und umkehrbar ist. Angreifer verstehen diese Hierarchie: nach einem ersten Standbein durch Phishing oder einen exponierten Dienst besteht das nächste Ziel darin, zu einem privilegierten Konto aufzusteigen, denn das verwandelt einen einzelnen Host in die Kontrolle über die Domäne. Auch die Aufsichtsbehörden wissen das. Nach der NIS-2-Richtlinie fallen die Zugriffskontrolle und der Umgang mit privilegierten Konten eindeutig unter die Risikomanagementmaßnahmen im Bereich der Cybersicherheit, die wesentliche und wichtige Einrichtungen umsetzen müssen. Der Digital Operational Resilience Act (DORA) stellt vergleichbare Anforderungen an den Finanzsektor, in dem eine starke Authentifizierung und eine strenge Kontrolle des privilegierten Zugriffs Teil des Rahmens für das IKT-Risikomanagement sind. Anhang A der ISO/IEC 27001 behandelt privilegierte Zugriffsrechte und die Verwaltung geheimer Authentifizierungsinformationen als benannte Kontrollen. In einem Audit gehört der privilegierte Zugriff durchgängig zu den am härtesten geprüften Bereichen, weil eine schwache Kontrolle an dieser Stelle jede andere Schutzmaßnahme untergräbt. ## Häufige Fehlerbilder PAM-Programme scheitern auf vorhersehbare Weise. Dienstkonten mit nicht ablaufenden Passwörtern, fest in die Automatisierung einkodiert. Gemeinsam genutzte Administratorkonten, bei denen niemand sagen kann, wer gehandelt hat. Dauerhafte lokale Administratorrechte auf jedem Arbeitsplatz. Eine Tresor-Einführung, die die interaktiven Administratoren abdeckt, die Maschinenidentitäten aber unangetastet lässt. Die Disziplin ist nur so gut wie ihre Abdeckung, daher besteht die praktische Arbeit aus kontinuierlicher Erkennung und der stetigen Beseitigung dauerhafter Privilegien statt aus einem einzelnen Rollout. --- ## Professional Evaluation and Certification Board (PECB) **URL:** https://cyberacademy.net/de/resources/encyclopedia/pecb **Last reviewed:** 2026-06-24 PECB ist die in Montreal ansässige akkreditierte Zertifizierungsstelle, die professionelle Zertifikate zu mehr als 30 ISO-Normen in über 150 Ländern ausstellt. Themenbereiche: Informationssicherheit, Risikomanagement, BCM, KI-Governance, Datenschutz, Qualität. Cyber Academy ist PECB Gold Partner. Die Zertifikate tragen das PECB-Branding; die Kurse werden über akkreditierte Partner durchgeführt. ## Was PECB tatsächlich ist PECB (das Professional Evaluation and Certification Board) ist eine Personenzertifizierungsstelle. Es zertifiziert nicht Ihr Unternehmen nach ISO 27001; das ist die Aufgabe einer akkreditierten Zertifizierungsstelle, die Ihr Managementsystem auditiert. PECB zertifiziert Personen. Wenn ein Praktiker einen Kurs abschließt und die Prüfung besteht, stellt PECB einen individuellen Nachweis aus, der bescheinigt, dass diese Person ihre Kompetenz gegenüber einem definierten Schema zu einer bestimmten Norm nachgewiesen hat. Der Katalog ist breit, weil das ISO-Portfolio breit ist. PECB-Schemata umfassen unter anderem Informationssicherheit, Risikomanagement, Business Continuity, Datenschutz und Datenschutz, KI-Governance und Qualität. Diese Breite ist genau der Punkt: Ein Praktiker kann innerhalb einer einzigen ausstellenden Stelle einen kohärenten Nachweispfad aufbauen, statt Abzeichen von einem Dutzend Quellen zu sammeln. > **Stelle gegenüber Partner** PECB besitzt das Schema, die Prüfung und das Zertifikat. Die Schulung wird von akkreditierten Partnern durchgeführt, die die Kohorten leiten. Der Nachweis trägt das PECB-Branding; das Erlebnis im Schulungsraum trägt das des Partners. Cyber Academy ist PECB Gold Partner, also die Durchführungsseite dieser Vereinbarung. ## Wie die Nachweise strukturiert sind PECB-Schemata sind in der Regel an eine benannte Norm und eine benannte Rolle gebunden. Die bekanntesten Paarungen sind Lead Implementer, für die Person, die ein Managementsystem aufbaut und betreibt, und Lead Auditor, für die Person, die es auditiert. Beide gibt es für ISO 27001 sowie für andere zertifizierbare Normen wie ISO 22301 für Business Continuity und ISO 42001 für KI-Managementsysteme. Darunter liegen die Nachweise auf Foundation-Ebene, die Vokabular und Prinzipien etablieren, bevor sich ein Praktiker auf den vollständigen Implementer- oder Auditor-Pfad festlegt. Die Unterscheidung zwischen den beiden Senior-Pfaden ist wichtiger, als das gemeinsame Etikett «Lead» vermuten lässt. Ein Lead Implementer plant den Geltungsbereich, verfasst Richtlinien, treibt die Erklärung zur Anwendbarkeit voran und betreibt die Maßnahmen. Ein Lead Auditor arbeitet auf der anderen Seite: Audits planen, Nachweise stichprobenartig prüfen, Interviews führen und Feststellungen gegenüber einer Norm berichten. Es sind komplementäre Disziplinen, und viele Praktiker besitzen beide, weil ein Managementsystem gut zu betreiben und es zu auditieren unterschiedliche Fähigkeiten erfordern. Ein Nachweis ist nicht dasselbe wie die zugrunde liegende Norm. ISO 27001 ist der Rahmen, gegen den eine Organisation zertifiziert wird. Der PECB-Nachweis ist der Beweis, dass eine benannte Person gegenüber einem Kompetenzschema bewertet wurde, das auf diesem Rahmen aufbaut. Die beiden zu verwechseln ist der häufigste Fehler, den Neulinge machen. ## Wo PECB unter den Zertifizierungsstellen steht Mehrere Organisationen stellen ISO-konforme Personennachweise aus, und ein Arbeitgeber interessiert sich selten für die ausstellende Stelle im Abstrakten. Was Gewicht hat, ist die Norm hinter dem Nachweis und ob das Zertifizierungsschema akkreditiert ist. PECB positioniert sich als akkreditierte, international tätige Stelle, was dem Zertifikat grenzüberschreitende Übertragbarkeit und Anerkennung durch Arbeitgeber verleiht, die den Schulungsanbieter nicht kennen. Für einen Praktiker, der einen Weg wählt, sind die praktischen Fragen: Mit welcher Norm muss ich arbeiten, deckt dieses Schema die Rolle ab, die ich anstrebe, und ist der Nachweis dort anerkannt, wo ich tätig sein will. Die ausstellende Marke ist die Antwort auf die Anerkennung; die Norm und die Rolle beantworten den Rest. --- ## Pseudonymisierung **URL:** https://cyberacademy.net/de/resources/encyclopedia/pseudonymisation **Last reviewed:** 2026-06-24 Pseudonymisierung ist die in GDPR Artikel 4(5) definierte Technik, bei der direkte Identifikatoren durch umkehrbare Token ersetzt werden und der Schlüssel separat gespeichert wird. Sie reduziert das Risiko und schafft Vertrauen bei den Aufsichtsbehörden, doch die Daten gelten weiterhin als personenbezogene Daten. Die Anonymisierung ist die Variante, die vollständig aus dem Anwendungsbereich des GDPR herausfällt; die Pseudonymisierung hingegen nicht. Verwechseln Sie beide Begriffe nicht. ## Was Pseudonymisierung tatsächlich bewirkt Pseudonymisierung ist eine Technik des Datenschutzes, kein Zustand, den die Daten erreichen. Sie nehmen die Felder, die unmittelbar auf eine Person verweisen, den Namen, die E-Mail-Adresse, die nationale Identifikationsnummer, und ersetzen sie durch ein Token: eine zufällige Kennung, eine codierte Referenz, einen verschlüsselten Wert. Die Zuordnung, die das Token wieder in die echte Identität zurückführt, der Schlüssel, wird getrennt aufbewahrt und mit eigenen technischen und organisatorischen Maßnahmen geschützt. Wer mit dem pseudonymisierten Datensatz arbeitet, kann ihn analysieren, weitergeben oder zum Testen nutzen, ohne zu sehen, wem die Datensätze gehören, während die Organisation die Fähigkeit behält, neu zu identifizieren, wenn sie einen berechtigten Grund dafür hat. Die DSGVO benennt diese Technik ausdrücklich und behandelt sie als empfohlene Schutzmaßnahme. Sie erscheint als Weg, Datenschutz durch Technikgestaltung und durch datenschutzfreundliche Voreinstellungen zu erfüllen, als Maßnahme, die das Restrisiko einer Verarbeitungstätigkeit senken kann, und als Faktor, den Aufsichtsbehörden wohlwollend gewichten, wenn sie beurteilen, ob Sie genug getan haben. Sie einzusetzen ist ein Signal, dass Sie Sicherheit und Minimierung ernst genommen haben. Das ist das Wohlwollen, auf das die kurze Definition verweist, und es ist real, doch es ändert nichts an der rechtlichen Natur der Daten. ## Pseudonymisierung ist nicht Anonymisierung Das ist die Verwechslung, die Organisationen in Schwierigkeiten bringt. Weil ein pseudonymisierter Datensatz keinen sichtbaren Namen mehr trägt, wird angenommen, er habe den Geltungsbereich der Verordnung verlassen. Hat er nicht. Pseudonymisierung ist von ihrer Anlage her umkehrbar: Der Schlüssel existiert, also können die Daten wieder einer identifizierbaren Person zugeordnet werden, also bleiben sie personenbezogene Daten und jede Pflicht gilt weiterhin. Anonymisierung ist der gegenteilige Handel. Sie ist irreversibel, die Verbindung zur Person wird so vollständig zerstört, dass eine Neuidentifizierung mit keinem nach allgemeinem Ermessen wahrscheinlich genutzten Mittel mehr vernünftigerweise möglich ist, und erst dann fallen die Daten vollständig aus der DSGVO heraus. **Pseudonymisierung versus Anonymisierung** | Aspekt | Pseudonymisierung | Anonymisierung | | --- | --- | --- | | Umkehrbar | Ja, über den getrennt aufbewahrten Schlüssel | Nein, die Verbindung wird zerstört | | Weiterhin personenbezogene Daten | Ja | Nein | | DSGVO gilt | Ja, in vollem Umfang | Nein | | Typischer Zweck | Risiko senken bei gleichzeitiger Wahrung von Nutzbarkeit und Neuidentifizierung | Daten aus dem Geltungsbereich nehmen, oft zur offenen Veröffentlichung | > **Der Schlüssel ist es, der sie zu personenbezogenen Daten macht** Solange der Schlüssel oder die Methode zur Neuidentifizierung irgendwo in vernünftiger Reichweite existiert, sind die Daten pseudonymisiert, nicht anonymisiert. Das Löschen des Schlüssels, nicht das Maskieren des Namens, überschreitet die Schwelle zur Anonymisierung. Begegnen Sie einer Behauptung der Anonymisierung mit Misstrauen, bis Sie zeigen können, dass es keinen vernünftigen Weg zurück zur Person gibt. ## Was Praktiker tatsächlich tun In der Praxis ist Pseudonymisierung eher eine Disziplin aus Technik und Governance als ein einzelner Schalter. Der Sinn, den Schlüssel zu trennen, ist zunichtegemacht, wenn dasselbe Team, System oder Backup sowohl die Token als auch die Zuordnung hält, sodass die Kontrollen rund um den Schlüssel ebenso sehr zählen wie die Tokenisierung selbst. - Direkte Identifikatoren durch Token ersetzen, mit Methoden wie schlüsselbasiertem Hashing, Verschlüsselung oder einer Nachschlagetabelle aus zufälligen Referenzen. - Den Schlüssel zur Neuidentifizierung getrennt speichern, unter strengerer Zugriffskontrolle als der Arbeitsdatensatz, idealerweise in der Verantwortung eines anderen Teams. - Gegen indirekte Neuidentifizierung absichern, bei der seltene Kombinationen verbleibender Felder (eine Postleitzahl, dazu ein Geburtsdatum, dazu eine Berufsbezeichnung) jemanden auch ohne Namen herausstellen. - Die Technik im Verzeichnis von Verarbeitungstätigkeiten und in der DSFA dokumentieren und die pseudonymisierten Daten für Verletzungsbewertung, Aufbewahrung und Betroffenenrechte als personenbezogene Daten behandeln. Gut umgesetzt lässt Pseudonymisierung Analytik, Forschung und Softwaretests auf realistischen Daten laufen und verkleinert zugleich den Wirkungsradius einer Verletzung, denn ein Angreifer, der die Token ohne den Schlüssel erlangt, hält weit weniger in Händen. Nachlässig umgesetzt, mit erreichbarem Schlüssel oder ignorierten indirekten Identifikatoren, bietet sie den Anschein von Schutz ohne dessen Substanz, und die Organisation trägt weiterhin jede Pflicht, der sie entkommen zu sein glaubte. --- ## Ransomware **URL:** https://cyberacademy.net/de/resources/encyclopedia/ransomware **Last reviewed:** 2026-06-24 Ransomware ist die Malware-Klasse, die Daten verschlüsselt und eine Zahlung für den Schlüssel fordert, häufig kombiniert mit Datendiebstahl und Erpressung (Double Extortion). Angriffsvektoren: Phishing, exponierte Systeme mit Internetzugang, Lieferkette. Versicherungen leisten weniger, Aufsichtsbehörden prüfen genauer. Das Ergebnis hängt von der Vorbereitung ab (Backups, Segmentierung, IR-Plan), nicht von der Verhandlung. ## Was Ransomware wirklich ist und warum die Verschlüsselung der einfache Teil ist Ransomware ist Schadsoftware, die sich etwas aneignet, das Sie brauchen, und Sie zur Zahlung zwingt, um es zurückzubekommen. Der klassische Mechanismus ist die Verschlüsselung: Die Schadsoftware verschlüsselt die Dateien auf den Systemen, die sie erreicht, und bietet den Entschlüsselungsschlüssel im Austausch gegen eine Zahlung an, in der Regel in Kryptowährung. Doch Ransomware als ein Verschlüsselungsproblem zu behandeln, übersieht, was sie so verheerend macht. Die Verschlüsselung ist das sichtbare Symptom eines Eindringens, das oft schon seit Tagen oder Wochen läuft. Bevor eine einzige Datei gesperrt wird, hat ein Angreifer typischerweise einen ersten Zugang erlangt, Privilegien ausgeweitet, sich seitlich durch das Netzwerk bewegt, die wichtigen Systeme lokalisiert und häufig die Daten nach außen kopiert. Die Sperrung am Ende ist schlicht der Moment, in dem der Betreiber beschließt, diesen Zugang in Geld umzuwandeln. Diese Abfolge erklärt, warum es bei den schlimmsten Ransomware-Vorfällen nicht mehr nur um verschlüsselte Dateien geht. Die Betreiber lernten, dass ein Opfer mit guten Backups die Zahlung verweigern und wiederherstellen konnte, also fügten sie einen zweiten Hebel hinzu: zuerst die Daten stehlen, dann mit deren Veröffentlichung drohen. Das ist die doppelte Erpressung, und sie verändert das Kalkül vollständig. Selbst eine Organisation, die sauber aus einem Backup wiederherstellt, steht weiterhin vor der Aussicht, dass vertrauliche Daten, Kundendaten oder Verträge auf einer öffentlichen Seite veröffentlicht werden. Manche Gruppen gehen mit zusätzlichem Druck weiter, indem sie Kunden oder Aufsichtsbehörden direkt kontaktieren oder einen Denial-of-Service-Angriff hinzufügen. Bei der Verhandlung, sofern es eine gibt, geht es nicht wirklich um einen Entschlüsselungsschlüssel. Es geht darum, ob die gestohlenen Daten privat bleiben. ## Wie sie hineingelangt und warum die Aufsichtsbehörde sich nun dafür interessiert Der Weg hinein ist selten exotisch. Die dominierenden Vektoren sind die unspektakulären: eine Phishing-E-Mail, die einen Loader ausliefert oder Anmeldedaten abgreift, ein ins Internet exponierter Dienst, der ungeschützt oder ungepatcht bleibt, ein schwaches oder wiederverwendetes Passwort für den Fernzugriff und die Lieferkette, bei der ein vertrauenswürdiger Anbieter oder eine vertrauenswürdige Software zum Weg in Ihr Netzwerk wird. Nichts davon erfordert einen neuartigen Exploit. Es erfordert eine offene Tür, weshalb Exposure-Management und Identitätshygiene mehr zur Verringerung des Ransomware-Risikos beitragen als jedes einzelne Produkt. Ein Ransomware-Vorfall ist heute ein regulatorisches Ereignis, nicht nur ein technisches. Da der Angriff fast immer einen Datendiebstahl umfasst, löst er in der Regel die Pflichten bei Verletzungen des Schutzes personenbezogener Daten nach der GDPR aus, was eine Bewertung der Meldung an die Aufsichtsbehörde und in schwerwiegenden Fällen an die betroffenen Personen bedeutet. Betreiber wesentlicher und wichtiger Dienste unterliegen sich überschneidenden Meldepflichten für Vorfälle nach der Richtlinie NIS2. Nationale Behörden wie ANSSI und ENISA veröffentlichen Leitlinien gerade deshalb, weil dasselbe Vorgehen immer wieder funktioniert. Die praktische Folge für eine Risikofunktion ist, dass der Reaktionsplan den rechtlichen und meldebezogenen Strang von der ersten Stunde an einschließen muss, parallel zur technischen Wiederherstellung durchgeführt und nicht im Nachhinein angefügt. > **Zahlen schließt den Fall nicht ab** Eine Zahlung kann einen Entschlüsselungsschlüssel hervorbringen, macht aber eine Datenschutzverletzung nicht ungeschehen. Die Meldefrist nach der GDPR läuft weiter, gestohlene Daten können dennoch veröffentlicht werden, und die Aufsichtsbehörden prüfen Zahlungen an sanktionierte Einrichtungen genau. Behandeln Sie jede Zahlungsentscheidung als eine rechtliche und risikobezogene Entscheidung, die mit anwaltlicher Beratung getroffen wird, niemals als die technische Lösung. ## Der Ausgang wird vor dem Angriff entschieden, nicht während der Lösegeldforderung Der wichtigste Gedanke für Praktiker ist, dass das Ergebnis eines Ransomware-Vorfalls weitgehend durch die Arbeit bestimmt wird, die lange vorher geleistet wurde. Eine Organisation, die schnell aus sauberen, getesteten, offline gehaltenen oder unveränderlichen Backups wiederherstellen kann, kann sich weigern, für einen Schlüssel zu zahlen. Eine, deren Backups vom selben Netzwerk aus erreichbar und daher zusammen mit allem anderen verschlüsselt wurden, hat diese Option nicht. Die Netzwerksegmentierung begrenzt, wie weit sich ein Eindringen ausbreiten kann, bevor es die wichtigen Systeme erreicht. Eine starke Authentifizierung beim Fernzugriff und bei der E-Mail schließt die häufigsten Eingangstüren. Eine Erkennung, die Seitwärtsbewegungen erfasst, gewinnt die Stunden, die einen eingedämmten Vorfall von einem unternehmensweiten Verschlüsselungsereignis trennen. Was kompetente Teams also tatsächlich tun, ist, in die Vorab-Aufstellung zu investieren statt in Verhandlungsgeschick. Sie halten Backups, die vom Produktionsdomäne isoliert, im Ruhezustand verschlüsselt und nach einem Zeitplan wiederhergestellt werden, sodass die Wiederherstellung nachgewiesen und nicht nur angenommen wird. Sie segmentieren Netzwerke, damit eine kompromittierte Arbeitsstation den Backup-Server oder die Domänencontroller nicht ungehindert erreichen kann. Sie pflegen einen Vorfallreaktionsplan, der Rollen, Entscheidungsträger, externe Forensik und Rechtsberatung sowie den Meldeweg benennt, und sie üben ihn ein. Hier verbindet sich Ransomware unmittelbar mit dem Business-Continuity-Management und der Notfallwiederherstellung: Die Wiederherstellungszeit und der Wiederherstellungspunkt, die eine Organisation tatsächlich erreichen kann, getestet an einem realistischen Szenario, sind der Unterschied zwischen einer schlimmen Woche und einer existenziellen Krise. --- ## Recovery Time und Recovery Point Objectives (RTO / RPO) **URL:** https://cyberacademy.net/de/resources/encyclopedia/rto-rpo **Last reviewed:** 2026-06-24 RTO ist die maximal tolerierbare Ausfallzeit eines Geschäftsprozesses, bevor ein nicht hinnehmbarer Schaden entsteht. RPO ist der maximal akzeptable Datenverlust, gemessen in Zeit vor dem Ausfall. Beide Werte werden aus der BIA abgeleitet. Die Kennzahlen, die der CIO ohne Rücksprache mit dem Fachbereich in das BCP schreibt, sind genau die Kennzahlen, die im Ernstfall versagen. ## Zwei Uhren, die unterschiedliche Dinge messen RTO und RPO sind die beiden Wiederherstellungsziele, die ein vages Resilienzversprechen in überprüfbare Zahlen verwandeln. Sie sind leicht zu verwechseln, weil beide in Zeiteinheiten ausgedrückt werden, aber sie messen unterschiedliche Dinge und verweisen auf unterschiedliche Lösungen. Das recovery time objective betrifft, wie lange Sie ausfallen können. Das recovery point objective betrifft, wie viele Daten Sie sich leisten können zu verlieren. Verwechseln Sie sie, kaufen Sie die falsche Wiederherstellungsarchitektur. Stellen Sie sich die Störung als einen einzelnen Moment auf einer Zeitachse vor. Das RTO blickt von diesem Moment nach vorn: Es ist das maximale Zeitfenster zwischen dem Ausfall und dem Moment, in dem der Prozess wieder nutzbar ist, bevor der Schaden inakzeptabel wird. Das RPO blickt von diesem Moment zurück: Es ist das maximale Alter der letzten gültigen Datenkopie, auf die Sie wiederherstellen können, was den jüngsten Daten entspricht, die Sie zu verlieren bereit sind. Ein RTO von vier Stunden mit einem RPO von fünfzehn Minuten bedeutet, dass der Dienst innerhalb von vier Stunden wieder verfügbar sein muss und nicht mehr als fünfzehn Minuten an Transaktionen verlieren darf. **RTO im Vergleich zu RPO** | | RTO | RPO | | --- | --- | --- | | Misst | Akzeptable Ausfallzeit | Akzeptabler Datenverlust | | Richtung auf der Zeitachse | Nach vorn ab der Störung | Zurück ab der Störung | | Beantwortete Frage | Wie schnell müssen wir wieder verfügbar sein? | Wie viele Daten dürfen wir verlieren? | | Hauptsächlich bestimmt durch | Wiederherstellungsprozess, Failover, Personal | Häufigkeit von Backup und Replikation | | Quelle | Business-Impact-Analyse | Business-Impact-Analyse | ## Woher die Zahlen kommen und warum Verantwortung zählt Beide Ziele sind Ergebnisse der Business-Impact-Analyse, keine im Serverraum getroffenen Vermutungen. Die BIA untersucht jede kritische Aktivität, misst, wie der Schaden eines Ausfalls im Laufe der Zeit wächst, und erzeugt Wiederherstellungsziele, die der Prozessverantwortliche validiert. Genau diese Verantwortung ist der entscheidende Punkt. Ein RTO und ein RPO, die ein Technikteam isoliert festlegt, beschreiben, was die Infrastruktur leisten kann, nicht, was das Geschäft braucht, und die Lücke zwischen beiden zeigt sich erst während eines echten Vorfalls, dem schlechtesten Zeitpunkt, um sie zu entdecken. Die Ziele müssen auch mit den Kosten abgewogen werden. Ein RPO gegen null zu treiben bedeutet kontinuierliche oder synchrone Replikation. Ein RTO gegen wenige Minuten zu treiben bedeutet Hot-Standby-Kapazität, die ungenutzt bereitsteht. Beides ist teuer, daher erzwingt die BIA ein ehrliches Gespräch darüber, welche Prozesse diese Ausgabe wirklich rechtfertigen und welche ein längeres Zeitfenster tolerieren können. Aktivitäten in Stufen einzuteilen ist normal: Die Zahlungs-Engine und die Marketing-Website verdienen selten dieselben Ziele. > **Das RTO ist nicht dasselbe wie die tatsächliche Dauer der Wiederherstellung** Das RTO ist das Ziel, das das Geschäft tolerieren kann. Die tatsächliche Zeit, die Ihr Team zur Wiederherstellung des Dienstes benötigt, ist die recovery time achieved, gemessen in einem Test. Ist die erreichte Zeit länger als das Ziel, haben Sie eine zu schließende Lücke, keine Zahl, die Sie stillschweigend lockern. ## Wie RTO und RPO in die Standards passen Diese Ziele sind zentrales Vokabular in Kontinuitäts- und Resilienzrahmenwerken. ISO 22301, der internationale Standard für Business-Continuity-Managementsysteme, behandelt recovery time und recovery point objectives als Ergebnisse der Impact-Analyse, die Kontinuitätsstrategie und -lösungen steuern. Sie fließen direkt in das Design der Notfallwiederherstellung, in Backup-Zeitpläne und in die Wahl der Wiederherstellungsstandorte ein. In regulierten Sektoren werden sie zunehmend geprüft statt vorausgesetzt: Die EU-Verordnung DORA legt Kontinuitäts- und Testerwartungen für Finanzunternehmen fest, und die NIS-2-Richtlinie verlangt von wesentlichen und wichtigen Einrichtungen Maßnahmen zur Geschäftskontinuität und zum Backup. Praktiker tun drei Dinge mit diesen Zahlen. Sie leiten sie gemeinsam mit den Geschäftsverantwortlichen aus der BIA ab. Sie gestalten Backup, Replikation und Failover so, dass die Architektur sie tatsächlich erreichen kann. Dann beweisen sie es durch Tests, denn ein ungetestetes RTO ist eine Absichtserklärung. Das Ziel gewinnt erst Vertrauen, wenn eine Wiederherstellungsübung gezeigt hat, dass das Team es unter realistischen Bedingungen erreichen kann. --- ## Risikobehandlung **URL:** https://cyberacademy.net/de/resources/encyclopedia/risk-treatment **Last reviewed:** 2026-06-24 Risikobehandlung ist das, was Sie tun, sobald Sie das Risiko kennen: vermeiden, reduzieren, übertragen, akzeptieren. Jede Entscheidung wird dokumentiert, durch die Risikobereitschaft begründet und über das SoA zu den Kontrollen und den Betriebsnachweisen nachverfolgt. Die meisten gescheiterten Audits lassen sich auf eine Sache zurückführen: Behandlungsplan und Realität haben sich auseinanderentwickelt, und niemand hat das SoA aktualisiert. ## Die vier Optionen der Risikobehandlung Die Risikobehandlung ist der Schritt, in dem aus der Bewertung Handeln wird. Sobald ein Risiko identifiziert, analysiert und an Ihren Kriterien gemessen wurde, müssen Sie entscheiden, wie Sie damit umgehen. Das übliche Vokabular, das ISO 31000 und ISO/IEC 27005 gemeinsam haben, bietet Ihnen vier Familien von Reaktionen. Sie sind nicht von der besten zur schlechtesten geordnet; die richtige Wahl hängt vom Risiko, von den Kosten der Maßnahme und von der Risikobereitschaft ab, die die Leitung freigegeben hat. - Vermeiden: die Aktivität einstellen, die das Risiko erzeugt, oder sie anders ausführen. Sie nehmen den exponierten Dienst außer Betrieb, streichen die Funktion oder verlassen den Markt, der die Exposition auslöst. - Vermindern (verändern): Maßnahmen anwenden, die die Eintrittswahrscheinlichkeit, die Auswirkung oder beides senken. Dies ist der häufigste Weg und derjenige, der unmittelbar an Ihr Maßnahmenset anknüpft. - Übertragen (teilen): einen Teil der finanziellen oder operativen Folge auf einen Dritten verlagern, in der Regel durch eine Versicherung oder eine vertragliche Klausel. Die Übertragung verlagert selten das gesamte Risiko; Ihnen bleibt der reputationsbezogene und regulatorische Rest. - Akzeptieren (beibehalten): entscheiden, dass das Restrisiko tolerierbar ist, und damit leben, nachweislich dokumentiert. Die Akzeptanz ist eine legitime Entscheidung und kein Versäumnis, solange die zuständige Stelle sie zeichnet. > **Akzeptanz ist eine Entscheidung, kein Standardzustand** Ein Risiko, das Sie nie behandelt haben, ist nicht dasselbe wie ein Risiko, das Sie förmlich akzeptiert haben. Die Akzeptanz muss ausdrücklich, datiert und von jemandem unterzeichnet sein, der über die Befugnis verfügt, die Ihre Risikobereitschaft zuweist. Ein unbehandeltes Risiko, das stillschweigend im Register verharrt, ist genau das, was ein Auditor beanstandet. ## Von der Entscheidung zum Nachweis: die Kette, der Auditoren folgen Das Schwierige an der Risikobehandlung ist nicht die Wahl einer Option, sondern die durchgängige Kohärenz des Belegpfads. Jede Entscheidung sollte unter Bezugnahme auf die dokumentierte Risikobereitschaft begründet, in einem Risikobehandlungsplan festgehalten und dann bis zu den Maßnahmen, die sie umsetzen, und den Nachweisen ihres Betriebs nachverfolgt werden. In einem Informationssicherheits-Managementsystem nach ISO/IEC 27001 lebt hier die Erklärung zur Anwendbarkeit (SoA): Sie erfasst, welche Maßnahmen des Annex A gelten, warum und wo der Nachweis liegt. Die mit Abstand häufigste Audit-Feststellung in diesem Bereich ist die Drift. Der Behandlungsplan sagte das eine, die SoA das andere, und der Betrieb vor Ort hatte sich von beidem entfernt. Eine Maßnahme wird ausgemustert, ein Projekt ändert seinen Umfang, ein Lieferant wird ausgetauscht, und niemand aktualisiert die Dokumente. Die Entscheidungen mögen für sich genommen alle vernünftig gewesen sein, doch die Kette stimmt nicht mehr überein, und diese Unstimmigkeit ist es, die eine Nichtkonformität hervorbringt. ### Restrisiko und Neubewertung Die Behandlung lässt ein Risiko nicht verschwinden. Was nach Anwendung der Maßnahmen übrig bleibt, ist das Restrisiko, und das ist der Wert, den der Risikoeigentümer tatsächlich akzeptiert. Gute Praxis ist es, die Analyse für das behandelte Risiko erneut durchzuführen, damit das Restniveau ausdrücklich wird, und es dann wieder über dieselbe Akzeptanzbefugnis zu leiten. ISO/IEC 27005, seit ihrer Überarbeitung von 2022 an den Grundsätzen von ISO 31000 ausgerichtet, fasst dies als iterative Schleife und nicht als einmalige Übung auf: Sie behandeln, Sie messen, was bleibt, Sie akzeptieren oder behandeln erneut. ## Was Praktiker tatsächlich tun In der täglichen GRC-Arbeit wird die Risikobehandlung als lebender Plan und nicht als Projektliefergegenstand geführt. Ein praktikabler Rhythmus sieht so aus: 1. Verknüpfen Sie jede Behandlungsentscheidung mit einem benannten Risiko im Register und mit der Bereitschaftserklärung, die sie rechtfertigt, damit die Begründung den Personalwechsel überdauert. 1. Weisen Sie jeder Maßnahme zum «Vermindern» einen einzigen rechenschaftspflichtigen Verantwortlichen und ein Zieldatum zu und verfolgen Sie sie wie jede andere Verpflichtung. 1. Halten Sie die SoA, den Behandlungsplan und die Maßnahmennachweise in einem festen Takt abgestimmt, nicht erst vor einem Audit. 1. Erfassen Sie das Restrisiko und die Akzeptanzunterschrift für alles, was Sie nicht vollständig mindern, einschließlich der Risiken, die Sie übertragen. So ausgeführt, hört der Behandlungsplan auf, Audit-Theater zu sein, und wird zum Ort, an dem die Organisation ehrlich sagen kann, wem sie ausgesetzt ist und wer entschieden hat, dass dies akzeptabel war. --- ## Risikobereitschaft **URL:** https://cyberacademy.net/de/resources/encyclopedia/risk-appetite **Last reviewed:** 2026-06-24 Risikobereitschaft ist das Ausmaß und die Art von Risiken, die eine Organisation bereit ist einzugehen, um ihre Ziele zu erreichen. Sie wird schriftlich auf Ebene der Geschäftsführung oder des Vorstands festgelegt. Ohne sie ist jede Risikobehandlungsentscheidung ein persönliches Urteil des Risikoteams – und das Audit wird das auseinandernehmen. Ergänzen Sie die Risikobereitschaft durch die Risikoakzeptanzgrenze (die tolerierte Abweichung von der Risikobereitschaft). ## Wozu der Risikoappetit dient Der Risikoappetit existiert, um eine Auseinandersetzung zu klären, bevor sie entsteht. Jede Behandlungsentscheidung, jedes „beheben wir das oder leben wir damit“, ist in Wahrheit eine Frage danach, wie viel Risiko die Organisation gegenüber dem Nutzen der Verfolgung ihrer Ziele zu tragen bereit ist. Wenn diese Grenze nur in den Köpfen derjenigen lebt, die das Programm leiten, dann wird jede Entscheidung zu einem privaten Urteil, das niemand sonst unterzeichnet hat, und genau das ist es, was ein Auditor oder eine Infragestellung durch das Gremium auseinandernehmen wird. Ein schriftlicher Appetit, getragen auf Geschäftsleitungs- oder Aufsichtsebene, verwandelt diese verstreuten Urteile in eine erklärte organisatorische Position. Er ist ein Steuerungsinstrument, kein Papierkram: Er sagt dem Risikoteam, wo es aus eigener Befugnis vorgehen darf und wo ein Risiko eskaliert werden muss. Entscheidend ist, dass der Appetit in der Sprache der Ziele festgelegt wird, nicht als einzelne Zahl. Eine Organisation, die in einem neuen Markt aggressives Wachstum anstrebt, wird rational mehr strategisches und operatives Risiko akzeptieren als eine, deren Auftrag es ist, einen regulierten, lebenskritischen Dienst zu schützen. Das Gremium entscheidet, wie viel Exposition es einzugehen bereit ist, um zu erreichen, was es anstrebt. Deshalb kann der Appetit nicht an die Sicherheits- oder Risikofunktion delegiert werden, damit diese ihn allein erfindet: Er ist eine Absichtserklärung, die nur diejenigen, die für die Ziele verantwortlich sind, rechtmäßig abgeben können. ## Appetit, Toleranz und Kapazität Diese drei werden ständig verwechselt, und die Verwechslung ist teuer. Appetit ist, wie viel Risiko Sie in Verfolgung der Ziele eingehen wollen. Toleranz ist die Abweichung, die Sie um diesen Appetit herum zu akzeptieren bereit sind, bevor Sie handeln, das praktische Band zu beiden Seiten des Ziels. Kapazität ist das absolute Maximum, das die Organisation absorbieren könnte, bevor ihre Lebensfähigkeit bedroht ist, unabhängig davon, was sie will. Sie legen den Appetit absichtlich unterhalb der Kapazität fest und lassen Spielraum, und Sie drücken die Toleranz aus, damit die alltägliche Schwankung nicht jedes Mal eine Krisensitzung auslöst. **Appetit, Toleranz und Kapazität auf einen Blick** | Konzept | Frage, die es beantwortet | Wer trägt die Verantwortung | | --- | --- | --- | | Risikoappetit | Wie viel Risiko wollen wir eingehen, um unsere Ziele zu erreichen? | Gremium / Geschäftsleitung | | Risikotoleranz | Wie viel Abweichung um diesen Appetit akzeptieren wir, bevor wir handeln? | Geschäftsleitung / Risikoeigner | | Risikokapazität | Was ist das Höchste, das wir absorbieren könnten, bevor die Lebensfähigkeit auf dem Spiel steht? | Gremium (eine harte Grenze) | > **Appetit ohne Toleranz ist nicht umsetzbar** Eine nackte Appetit-Erklärung ohne Toleranzband zwingt das Team, jede geringfügige Abweichung als Verstoß zu behandeln. Verbinden Sie den Appetit mit einer erklärten Toleranz, damit normale Schwankungen absorbiert werden und nur echte Abdrift eskaliert wird. Ohne sie wird die Erklärung entweder ignoriert oder sie erzeugt Rauschen. ## Wie es in den Standards auftaucht In ISO 31000 ist der Risikoappetit Teil des Rahmenwerks, das die Führung etabliert, wenn sie sich verpflichtet, Risiko zu steuern: Von der obersten Leitung und den Aufsichtsgremien wird erwartet, dass sie definieren und kommunizieren, wie viel Risiko die Organisation einzugehen bereit ist. ISO 27005 und das Informationssicherheits-Managementsystem ISO 27001 stützen sich über die Risikokriterien auf dieselbe Idee: Bevor Sie ein Risiko bewerten können, brauchen Sie vereinbarte Kriterien dafür, was akzeptabel ist, und diese Kriterien sind der operativ gemachte Appetit. Der Appetit liegt der Bewertung vorgelagert, und die Kriterien sind die Art und Weise, wie er konsistent auf jedes Risiko angewendet wird. Der Appetit ist kein Plakat an der Wand. Er verdient seinen Platz erst, wenn er in den Rest des Zyklus eingebunden ist. Der Schritt der Risikobewertung vergleicht jedes analysierte Risiko mit den vom Appetit abgeleiteten Kriterien, um zu entscheiden, ob Handlung erforderlich ist. Die Risikobehandlungsentscheidung, vermeiden, vermindern, übertragen oder akzeptieren, wird mit Verweis auf ihn begründet: Ein innerhalb des Appetits akzeptiertes Risiko erfordert nur eine dokumentierte, autorisierte Akzeptanz, während ein Risiko oberhalb des Appetits eine Behandlung oder eine formelle, eskalierte Freigabe verlangt. Das Risikoregister hält fest, wo jeder Eintrag relativ zum Appetit steht und wer was akzeptiert hat. Wenn Auditoren Behandlungsentscheidungen finden, die niemand auf einen erklärten Appetit zurückführen kann, ist das die Lücke, die die gesamte Bewertung zum Einsturz bringt. In der Praxis wird der Appetit überprüft, nicht in Stein gemeißelt. Er wird erneut betrachtet, wenn sich Ziele ändern, nach größeren Vorfällen und im Rahmen der Managementbewertung, denn ein für die Strategie des letzten Jahres festgelegter Appetit lenkt die Entscheidungen dieses Jahres still und leise in die Irre. Die Disziplin besteht darin, ihn explizit zu halten, ihn an der Spitze verantwortet zu halten und ihn mit den Kriterien verbunden zu halten, die das Team tatsächlich verwendet. --- ## Risikoregister **URL:** https://cyberacademy.net/de/resources/encyclopedia/risk-register **Last reviewed:** 2026-06-24 Das Risikoregister ist die maßgebliche, fortlaufend gepflegte Liste identifizierter Risiken mit Analyse, Bewertung, Behandlung und Verantwortlichkeit. Kein einmaliges Tabellenblatt. Auditoren erwarten datierte Einträge, namentlich benannte Verantwortliche, nachvollziehbare Änderungen und Überprüfungszyklen, die an das Management Review gekoppelt sind. Die Board-Version ist kürzer; die operative Version enthält alles. ## Was das Register wirklich ist Das Risikoregister ist der einzige Ort, an dem die Organisation nachhält, was ihr Sorgen bereitet und was sie dagegen unternimmt. Man stellt sich eine Tabelle vor, und oft beginnt es auch als solche, doch das Artefakt, auf das es ankommt, ist die Disziplin dahinter : jedes Risiko identifiziert, analysiert, gegen die Risikobereitschaft bewertet, einem Verantwortlichen zugewiesen, mit einer Behandlungsentscheidung versehen und in einem Zyklus erneut betrachtet. Ein Register, das einmal für eine Zertifizierung ausgefüllt und danach nie wieder angefasst wurde, ist kein Risikoregister, sondern ein Museumsstück. Der Test besteht darin, ob Sie sich eine beliebige Zeile ansehen und erkennen können, wann sie zuletzt überprüft wurde, wer dafür verantwortlich ist und was sich seither geändert hat. Jeder Eintrag trägt typischerweise eine Beschreibung des Risikos, den bedrohten Vermögenswert oder das bedrohte Ziel, die Analyse (Eintrittswahrscheinlichkeit und Auswirkung, wie auch immer Sie sie bewerten), die Bewertung anhand Ihrer Kriterien, die gewählte Behandlung, den benannten Verantwortlichen, das Restrisiko nach Behandlung und ein Überprüfungsdatum. Der Detaillierungsgrad ist gewollt : Wenn ein Auditor oder ein Vorfall an einem Faden zieht, muss der Eintrag standhalten. Vage Einträge ohne Verantwortlichen und ohne Datum sind das Erste, was ein kompetenter Auditor findet, und sie untergraben die Glaubwürdigkeit des gesamten Programms. ## Wie es mit allem anderen zusammenhängt Das Register ist kein eigenständiges Dokument, sondern der Knotenpunkt, an den sich der Rest des Risikoprogramms anschließt. Identifikation und Analyse folgen einer Methodik wie ISO 27005 oder EBIOS RM, und deren Ergebnis landet hier. Die Behandlungsspalte ist der Ort, an dem jedes Risiko auf die Entscheidung trifft, zu vermeiden, zu reduzieren, zu übertragen oder zu akzeptieren, und in einem ISO-27001-Kontext setzt sich diese Entscheidung weiter zur Erklärung zur Anwendbarkeit und zu den umsetzenden Maßnahmen fort. Die Bewertungsspalte bedeutet nur dann etwas, wenn es eine schriftliche Risikobereitschaft gibt, anhand derer bewertet wird, sonst ist jede Einstufung nur die Meinung eines einzelnen Analysten. Das Register liegt also stromabwärts von Methodik und Risikobereitschaft und stromaufwärts von Behandlung und Maßnahmennachweis. Auch deshalb ist das Register ein lebendes Dokument, das an die Managementbewertung gekoppelt ist, und kein einmaliges Lieferobjekt. Neue Risiken treten auf, behandelte Risiken ändern ihre Restbewertung, Verantwortliche wechseln, und die Risikobereitschaft selbst kann sich verschieben. Ein reifes Programm überprüft das Register in einem festgelegten Takt und speist die wesentlichen Bewegungen in die Managementbewertung ein, damit die Leitung Entscheidungen auf Basis eines aktuellen Bildes trifft und nicht auf dem des letzten Jahres. > **Zwei Zielgruppen, zwei Versionen** Das operative Register enthält alles : jeden Eintrag, jedes Feld, jeden Verantwortlichen. Die Version, die an den Vorstand geht, ist eine bewusste Zusammenfassung der Risiken, die auf seiner Ebene von Bedeutung sind. Der Versuch, ein einziges Dokument für beide nutzbar zu machen, ist ein häufiger Fehler. Der Vorstand ertrinkt in Details, auf die er nicht reagieren kann, und das operative Team verliert sein Arbeitswerkzeug. Behalten Sie beide bei und halten Sie sie abgestimmt. ## Was Praktiker tatsächlich pflegen In der Praxis ist das Register der Ort, an dem gute Absichten auf Pflege treffen. Das Schwierige ist nicht der erste Durchgang, sondern es über Jahre ehrlich zu halten. Datierte Einträge sind wichtig, weil ein Auditor eine nachvollziehbare Veränderung sehen will : wann ein Risiko erhoben wurde, wann sich seine Einstufung verschob, wann die Behandlung abgeschlossen wurde. Benannte Verantwortliche sind wichtig, weil ein Risiko ohne Verantwortlichen ein Risiko ist, das niemand tatsächlich steuert. Überprüfungszyklen sind wichtig, weil Toleranzen und Abhängigkeiten driften, und ein Register, das zwei Reorganisationen alt ist, wird die falschen Dinge priorisieren. Die Felder lassen sich leicht aufzählen und schwer dauerhaft aufrechterhalten, was genau der Grund ist, warum das Register, nicht die Leitlinie, der Ort ist, an dem man sieht, ob ein Risikoprogramm lebt. Eine häufige Verwechslung besteht zwischen dem Register und dem Behandlungsplan. Das Register ist das Inventar der Risiken und ihres aktuellen Zustands. Der Behandlungsplan ist die Menge der Maßnahmen, zu denen Sie sich verpflichtet haben, mit Fristen und Verantwortlichkeit, um Risiken auf akzeptable Niveaus zu bringen. Sie verweisen aufeinander, sind aber nicht dasselbe Dokument, und wenn sie auseinanderdriften, bemerkt es das Audit. Halten Sie das Register als Quelle der Wahrheit für den Zustand, und lassen Sie den Behandlungsplan die Quelle der Wahrheit für die laufende Arbeit sein. --- ## SOC 2 **URL:** https://cyberacademy.net/de/resources/encyclopedia/soc-2 **Last reviewed:** 2026-06-24 SOC 2 ist der AICPA-Prüfbericht über die Kontrollen einer Serviceorganisation, der fünf Trust-Kriterien abdeckt (Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit, Datenschutz). In Nordamerika der Standardnachweis für SaaS-Anbieter; ISO/IEC 27001 ist das europäische Äquivalent. Typ I = Stichtagsbetrachtung; Typ II = Wirksamkeit über 6–12 Monate. Wird häufig im Enterprise-Einkaufsprozess gefordert. ## Was SOC 2 tatsächlich bescheinigt SOC 2 ist keine Zertifizierung, die man besteht oder nicht besteht. Es ist ein Attestierungsbericht, der von einer lizenzierten CPA-Firma nach den Attestierungsstandards der AICPA erstellt wird und in dem ein unabhängiger Prüfer ein Urteil darüber abgibt, ob die Kontrollen einer Dienstleistungsorganisation angemessen ausgestaltet sind und, beim Typ II, über einen Zeitraum hinweg wirksam funktionieren. Der Geltungsbereich ist um die Trust Services Criteria herum aufgebaut: Sicherheit (die einzige verpflichtende Kategorie, auch common criteria genannt), Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit und Datenschutz. Sie wählen, welche der fünf auf den von Ihnen angebotenen Dienst zutreffen, und der Bericht wird auf diese Wahl zugeschnitten. Da es sich um ein Urteil über eine vom Management verfasste Beschreibung handelt, sind zwei SOC-2-Berichte selten identisch. Ein Anbieter deckt möglicherweise nur die Sicherheit ab; ein anderer ergänzt Verfügbarkeit und Vertraulichkeit. Den Bericht zu lesen bedeutet, die Systembeschreibung, die im Geltungsbereich enthaltenen Kriterien, die durchgeführten Tests und vor allem alle vom Prüfer angemerkten Ausnahmen zu lesen. Ein einwandfreier Bericht mit engem Geltungsbereich kann ein schwächerer Nachweis sein als ein Bericht mit geringfügigen Ausnahmen über einen breiten Geltungsbereich. ## Typ I gegenüber Typ II Die Unterscheidung, die Praktikern am wichtigsten ist, ist die zwischen Typ I und Typ II. Typ I ist eine Momentaufnahme: Der Prüfer urteilt, dass die Kontrollen zu einem einzigen Stichtag angemessen ausgestaltet sind. Er belegt, dass die Kontrollen auf dem Papier existieren und an diesem Tag vorhanden waren. Typ II ist derjenige, den Enterprise-Käufer tatsächlich wollen, weil der Prüfer testet, ob diese Kontrollen über einen Prüfzeitraum hinweg wirksam funktioniert haben, der sich typischerweise über sechs bis zwölf Monate erstreckt, und dabei durchgehend Nachweise stichprobenartig erhebt. Ein Typ II beantwortet die eigentliche Beschaffungsfrage: Hat der Anbieter dies durchgängig getan und nicht nur am Tag der Prüfung? **SOC 2 Typ I vs Typ II** | Dimension | Typ I | Typ II | | --- | --- | --- | | Was geprüft wird | Ausgestaltung der Kontrollen | Ausgestaltung und Wirksamkeit im Betrieb | | Zeitrahmen | Ein einzelner Zeitpunkt | Ein Prüfzeitraum (üblicherweise 6 bis 12 Monate) | | Nachweis | Kontrollen zum Stichtag vorhanden | Stichprobenartig erhobene Nachweise über den Zeitraum | | Typische Verwendung | Erster Bericht, Anbieter in der Frühphase | Was die Enterprise-Beschaffung erwartet | ## SOC 2 neben ISO 27001 SOC 2 und ISO 27001 beantworten dasselbe Anliegen des Käufers aus zwei Traditionen heraus. SOC 2 ist das nordamerikanische kanonische Signal, eine Attestierung des Prüfers, die an die Trust Services Criteria gebunden ist und in einem wiederkehrenden Zeitraum erneuert wird. ISO 27001 ist der internationale, zertifizierbare Standard, der um ein Managementsystem (das ISMS) herum aufgebaut ist, mit einer Zertifizierung, die von einer akkreditierten Stelle ausgestellt und durch Überwachungsaudits aufrechterhalten wird. SOC 2 berichtet über Kontrollen anhand von Kriterien; ISO 27001 bescheinigt, dass Sie ein funktionierendes System mit einer Erklärung zur Anwendbarkeit und kontinuierlicher Verbesserung betreiben. Viele Anbieter, die auf beiden Seiten des Atlantiks verkaufen, halten am Ende beide, und die Kontrollnachweise überschneiden sich stark, auch wenn die Lieferergebnisse sich unterscheiden. In der Praxis behandeln GRC-Teams die beiden als komplementär statt als konkurrierend. Dieselben Zugriffskontrollen, das Änderungsmanagement, die Schwachstellenbehandlung und die Reaktion auf Sicherheitsvorfälle speisen sowohl den Kontrollsatz aus Annex A von ISO 27001 als auch die common criteria von SOC 2. Die Arbeit besteht darin, einmal zuzuordnen und zweimal zu präsentieren. > **Lesen Sie den Bericht, nicht das Logo** Ein SOC-2-Abzeichen sagt für sich genommen fast nichts aus. Fordern Sie stets den vollständigen Bericht an und prüfen Sie die im Geltungsbereich enthaltenen Kriterien, ob es sich um Typ I oder Typ II handelt, den abgedeckten Zeitraum, die ausgeklammerten Subdienstleister und alle angemerkten Ausnahmen. --- ## Schrems II **URL:** https://cyberacademy.net/de/resources/encyclopedia/schrems-ii **Last reviewed:** 2026-06-24 Schrems II ist das EUGH-Urteil von 2020, das das EU-US Privacy Shield aufgehoben und die Anforderung einer Transfer Impact Assessment eingeführt hat. Jede Übermittlung in ein Drittland erfordert nun eine dokumentierte Analyse des lokalen Überwachungsrechts sowie ergänzender Maßnahmen. In der Praxis durch den EU-US Data Privacy Framework (2023) abgelöst, doch die TIA-Disziplin ist geblieben. ## Was das Urteil tatsächlich entschieden hat Schrems II ist das Urteil des Gerichtshofs der Europäischen Union vom Juli 2020 in der Rechtssache Data Protection Commissioner v Facebook Ireland und Maximillian Schrems, das neu geprägt hat, wie personenbezogene Daten den Europäischen Wirtschaftsraum verlassen. Zwei Dinge geschahen gleichzeitig. Erstens erklärte der Gerichtshof den EU-US Privacy Shield für ungültig, die Angemessenheitsregelung, die Tausenden von Unternehmen den Datentransfer an zertifizierte US-Importeure ermöglicht hatte, weil das US-Überwachungsrecht den Personen der Union keinen Schutz bot, der dem innerhalb der Union gewährleisteten der Sache nach gleichwertig war, und ihnen keinen wirksamen gerichtlichen Rechtsbehelf gewährte. Zweitens, und dies ist der Teil, der Bestand hat, hob der Gerichtshof die Standardvertragsklauseln nicht auf. Er ließ sie gültig, fügte jedoch eine Bedingung hinzu: Der Exporteur kann die Klauseln nicht einfach unterzeichnen und sich abwenden. Diese Bedingung ist der Kern der Sache. Der Gerichtshof befand, dass Datenexporteure im Einzelfall prüfen müssen, ob Recht und Praxis des Bestimmungslands es dem Importeur tatsächlich erlauben, die vertraglichen Garantien einzuhalten. Wo dies nicht der Fall ist, muss der Exporteur zusätzliche Maßnahmen ergreifen oder den Transfer einstellen. Der Vertrag allein genügt nicht, wenn eine ausländische Regierung den Zugriff in einer Weise erzwingen kann, die die Klauseln nicht verhindern können. ## Das Transfer Impact Assessment in der Praxis Die Disziplin, die Schrems II geschaffen hat, ist das Transfer Impact Assessment, oder TIA. Es ist die dokumentierte Analyse, die das Urteil in eine wiederholbare Kontrolle überführt. Ein Praktiker, der ein TIA durchführt, arbeitet eine erkennbare Abfolge ab statt eines einmaligen Rechtsgutachtens. - Den Transfer kartieren. Bestimmen, welche Daten wohin gehen, die Kategorien der betroffenen Personen, den Importeur, etwaige Weiterübermittlungen sowie den herangezogenen Rechtsmechanismus, in der Regel die SCC. - Recht und Praxis des Bestimmungslands bewerten. Das Überwachungs- und Behördenzugriffsregime im Importland betrachten und beurteilen, ob es den Schutz untergräbt, den das Transferinstrument bieten soll. Dies ist die Analyse des Überwachungsrechts, die der Gerichtshof verlangt hat. - Zusätzliche Maßnahmen bestimmen. Wo das lokale Recht problematisch ist, entscheiden, welche zusätzlichen technischen, vertraglichen oder organisatorischen Garantien die Lücke schließen. Starke Verschlüsselung mit ausschließlich im EWR gehaltenen Schlüsseln, Pseudonymisierung und aufgeteilte Verarbeitung sind die technischen Maßnahmen, auf die Aufsichtsbehörden am häufigsten verweisen. - Dokumentieren und entscheiden. Die Begründung festhalten, abschließen, ob der Transfer fortgesetzt werden kann, und einen Überprüfungsauslöser festlegen, damit die Bewertung erneut geprüft wird, wenn sich das Recht oder die Regelung ändert. > **Das TIA überdauerte den Fall, der es schuf** Schrems II wird oft als ein Fall über den Privacy Shield beschrieben, doch sein bleibendes Vermächtnis ist die Gewohnheit der Bewertung. Selbst jetzt, da das EU-US Data Privacy Framework einen neuen Angemessenheitsweg für die Vereinigten Staaten bietet, gilt die Pflicht, das Bestimmungsland zu bewerten, einen rechtmäßigen Mechanismus zu wählen und zusätzliche Maßnahmen zu dokumentieren, für jedes Drittland. Das TIA ist heute ein Standardposten in jedem Datenschutzprogramm, keine einmalige Reaktion. ## Wo es heute steht Im Jahr 2023 erließ die Europäische Kommission das EU-US Data Privacy Framework, einen neuen Angemessenheitsbeschluss, der für zertifizierte US-Organisationen einen Weg wiederherstellt, Daten ohne TIA für diesen spezifischen Korridor zu übermitteln. Es wurde geschaffen, um die Bedenken hinsichtlich Rechtsbehelf und Verhältnismäßigkeit auszuräumen, die den Privacy Shield zu Fall gebracht hatten, einschließlich eines unabhängigen Überprüfungsmechanismus für Personen der Union. Im Alltag gesprochen ist die durch Schrems II geöffnete Privacy-Shield-Lücke somit für die Vereinigten Staaten geschlossen worden, sofern der Importeur nach dem neuen Rahmen zertifiziert ist und der Transfer in dessen Anwendungsbereich bleibt. Was nicht verschwunden ist, ist die umfassendere Methode. Übermittlungen in Länder ohne Angemessenheitsbeschluss stützen sich weiterhin auf die SCC oder andere Instrumente des Artikels 46, und jede davon benötigt nach wie vor ein TIA. Die Leitlinien des Europäischen Datenschutzausschusses zu zusätzlichen Maßnahmen bleiben das praktische Handbuch. Die richtige Art, Schrems II im Jahr 2026 zu lesen, ist daher nicht als tote Privacy-Shield-Geschichte, sondern als der Moment, in dem das Transferrisiko zu etwas wurde, das man bewertet und belegt, Transfer für Transfer, statt es durch Abhaken eines Angemessenheitskästchens beiseitezuwischen. Zwei benachbarte Begriffe sollte man auseinanderhalten. Ein Angemessenheitsbeschluss ist die Kommission, die feststellt, dass ein ganzes Land gleichwertigen Schutz bietet, was den Bedarf an zusätzlichen Garantien beseitigt. SCC sind ein vertragsbasiertes Instrument, das man verwendet, wenn es keinen Angemessenheitsbeschluss gibt, und Schrems II ist genau das Urteil, das gesagt hat, dass die SCC mit der angehängten Hausaufgabe eines TIA daherkommen. --- ## Security Information and Event Management (SIEM) **URL:** https://cyberacademy.net/de/resources/encyclopedia/siem **Last reviewed:** 2026-06-24 Ein SIEM aggregiert Logs, normalisiert Events und führt Erkennungsregeln über Ihren gesamten Stack aus. Es bildet die Sichtbarkeitsschicht, auf die das SOC angewiesen ist. Moderne SIEM-Anbieter (Splunk, Sentinel, Elastic, Sumo) bündeln zunehmend SOAR und UEBA. Die eigentliche Arbeit liegt nicht im Kauf des SIEM, sondern im Data Engineering und der anschließenden Detection-as-Code-Pipeline. ## Was ein SIEM tatsächlich leistet Ein SIEM steht im Zentrum der Sicherheitsoperationen als Sammel- und Korrelations-Engine. Es nimmt Protokolle und Ereignisse aus dem gesamten Bestand auf: Firewalls, Endpunkte, Identitätsanbieter, Cloud-Plattformen, Server, Anwendungen und Netzwerkgeräte. Anschließend normalisiert es diese Ereignisse in ein gemeinsames Schema, sodass ein fehlgeschlagener Windows-Authentifizierungsversuch, eine VPN-Anmeldung und ein Cloud-API-Aufruf gemeinsam betrachtet werden können, und es führt Erkennungsregeln auf diesem vereinheitlichten Datenstrom aus, um Warnungen auszulösen. Es geht um Sichtbarkeit. Ohne ein SIEM bleiben Sicherheitssignale in Dutzenden von Konsolen gefangen, die niemand korreliert, und ein Angriff, der fünf Systeme berührt, sieht aus wie fünf zusammenhanglose Ereignisse. Zwei Funktionen machen ein SIEM zu mehr als einem Werkzeug zur Protokollsuche. Die erste ist die Korrelation: Regeln, die nur dann auslösen, wenn eine Abfolge eintritt, zum Beispiel ein Brute-Force-Versuch, gefolgt von einer erfolgreichen Anmeldung und anschließend einer Rechteausweitung, was keine einzelne Quelle für sich allein melden würde. Die zweite ist die Aufbewahrung und Suche, die das SIEM zum maßgeblichen System für Untersuchungen macht und zu dem Ort, an den ein Analyst geht, um den Hergang zu rekonstruieren. Wie die shortDefinition anmerkt, bündeln moderne Plattformen wie Splunk, Microsoft Sentinel, Elastic und Sumo Logic zunehmend SOAR für die automatisierte Reaktion und UEBA für die Verhaltensanalyse, sodass die Grenzen zwischen diesen Kategorien verschwimmen. ## SIEM, SOC, SOAR und EDR: Wer macht was Diese Begriffe treten häufig gemeinsam auf und lassen sich leicht verwechseln, doch sie beschreiben unterschiedliche Dinge: ein Werkzeug, ein Team, eine Automatisierungsschicht und einen Sensor. **Wie die Teile zusammenpassen** | Begriff | Was es ist | Bezug zum SIEM | | --- | --- | --- | | SIEM | Die Plattform für Aggregation, Normalisierung und Erkennung | Die Sichtbarkeitsschicht selbst. | | SOC | Das Team und der Prozess, die überwachen und reagieren | Verarbeitet die Warnungen des SIEM; das SIEM ist seine primäre Konsole. | | SOAR | Orchestrierung und Playbooks für automatisierte Reaktion | Agiert auf den Warnungen des SIEM, um sie anzureichern, zu triagieren und einzudämmen. | | EDR | Endpunktsensor mit tiefgehender Host-Telemetrie | Eine hochpräzise Quelle, die das SIEM speist. | Die praktische Deutung: Das SIEM ist die Technologie, die alles sieht, das SOC sind die Menschen, die die Warnungen bearbeiten, SOAR ist die Automatisierung, die ihre manuelle Mühe verringert, und EDR ist eine der reichhaltigsten Datenquellen, die einfließen. Ein SIEM ohne ein SOC dahinter erzeugt Warnungen, die niemand liest. Ein SOC ohne ein SIEM ist blind. Sie werden getrennt beschafft, liefern aber nur gemeinsam einen Mehrwert. ## Warum das SIEM der schwierige Teil ist Ein SIEM zu kaufen ist eine Beschaffungsaufgabe. Es nützlich zu machen ist Datentechnik. Die Arbeit, die über den Erfolg tatsächlich entscheidet, besteht darin, die richtigen Protokollquellen mit vollständiger Abdeckung anzubinden, jede Quelle korrekt zu parsen, damit die Felder an der richtigen Stelle landen, und die Erkennungsinhalte so abzustimmen, dass Analysten echte Treffer erhalten statt einer Flut von Rauschen, die sie darauf trainiert, Warnungen zu ignorieren. Deshalb behandeln reife Teams Erkennungen wie Code: Die Regeln liegen in einer Versionsverwaltung, werden getestet, im Peer-Review geprüft und über eine Pipeline bereitgestellt, genau wie Anwendungssoftware. Die shortDefinition ist in diesem Punkt unmissverständlich. Die schwierige Arbeit ist nicht der Kauf des SIEM; es ist die anschließende Detection-as-Code-Pipeline. Aus Governance-Sicht ist das SIEM das, was mehrere Kontrollziele aus dem Bereich des Wünschenswerten heraushebt. Im Rahmen eines ISO/IEC 27001 ISMS untermauert es die Kontrollen zu Protokollierung, Überwachung und zur Erkennungsseite des Vorfallmanagements, und es liefert die Nachweise, die ein Auditor erwartet, dass Ereignisse tatsächlich erfasst und überprüft werden. Es operationalisiert zudem die Erkennungs- und Reaktionsfähigkeit, die das NIST Cybersecurity Framework voraussetzt und die Vorschriften wie NIS2 und DORA von Organisationen erwarten, dass sie diese aufrechterhalten und während eines Vorfalls nachweisen können. > **Die Kosten liegen in der Aufnahme** Die meisten SIEM-Plattformen berechnen nach Datenvolumen, sodass das, was Sie zu erfassen wählen, ebenso eine Budget- wie eine Sicherheitsentscheidung ist. Teams, die ohne Datenstrategie alles senden, erhalten eine hohe Rechnung und langsame Suchvorgänge. Zu entscheiden, was es wert ist, aufgenommen zu werden, was zusammengefasst und was verworfen wird, gehört zum guten Betrieb eines SIEM. --- ## Security Operations Center (SOC) **URL:** https://cyberacademy.net/de/resources/encyclopedia/soc **Last reviewed:** 2026-06-24 Ein SOC ist das Team und die Werkzeuge, die Sicherheitsereignisse in Echtzeit überwachen, erkennen, analysieren und darauf reagieren. Gestufte Analysten (T1 Erkennung, T2 Untersuchung, T3 Threat Hunting), 8x5 oder 24x7. Intern, ausgelagert (MSSP) oder hybrid. Ohne SOC ist das SIEM ein Protokollarchiv; mit einem ist es ein Frühwarnsystem. ## Was ein SOC tatsächlich leistet Ein Security Operations Center ist die Funktion, die rohe Telemetrie in Entscheidungen und Maßnahmen überführt. Die shortDefinition beschreibt es als das Team plus den Werkzeugkasten; in der Praxis liegt der Wert im Betriebsmodell, das beide verbindet. Das SIEM sammelt und korreliert Logs, das EDR zeichnet das Verhalten der Endpunkte auf und das SOAR führt Playbooks aus, doch nichts davon erzeugt Sicherheit für sich allein. Das SOC ist das, was um 02:00 die Alarmmeldung liest, entscheidet, ob es sich um einen False Positive oder das erste Anzeichen einer Intrusion handelt, und den richtigen Hebel zieht, um sie einzudämmen. Im Tagesgeschäft durchläuft ein SOC vier Schleifen: überwachen (die Konsolen und Feeds beobachten), erkennen (bestätigen, dass ein Signal echt ist), reagieren (eindämmen, beseitigen, wiederherstellen) und verbessern (Erkennungen feinjustieren, damit dasselbe Rauschen nicht zurückkehrt). Die letzte Schleife ist diejenige, die unreife SOCs auslassen, weshalb sie in Alarmen ertrinken. Ein gesundes SOC misst sich an Ergebnissen wie der mittleren Erkennungszeit und der mittleren Reaktionszeit, nicht daran, wie viele Alarme es geschlossen hat. ## Stufen, Personal und Abdeckung Das klassische Modell teilt die Analysten in Stufen ein. Tier 1 triagiert die Alarmwarteschlange und entscheidet, was eine genauere Betrachtung verdient. Tier 2 untersucht bestätigte Vorfälle, erstellt die Zeitachse und treibt die Eindämmung voran. Tier 3 betreibt proaktives Threat Hunting und entwickelt neue Erkennungsinhalte, anstatt darauf zu warten, dass ein Alarm auslöst. Um sie herum sitzen Detection Engineers, Incident Responder und ein SOC-Manager, der für Prozess und Kennzahlen verantwortlich ist. Abdeckung ist eine bewusste Entscheidung mit realen Kosten. Ein 8x5-SOC überwacht während der Geschäftszeiten; ein 24x7-SOC folgt der Sonne oder fährt Nachtschichten, damit ein Angreifer sich nicht auf ein ruhiges Wochenende verlassen kann. Die richtige Antwort hängt von Ihrer Bedrohungsexposition, Ihren regulatorischen Verpflichtungen und davon ab, was Sie auf Dauer aufrechterhalten können, ohne das Team auszubrennen. > **Ein SIEM ohne SOC ist nur Speicher** Ein SIEM, das niemand beobachtet, ist ein Log-Archiv, dessen Befüllung Sie bezahlen. Das SOC ist das, was dieselbe Plattform zu einem Frühwarnsystem macht. Investieren Sie in die Analysten und den Prozess, bevor Sie weitere Werkzeuge kaufen. ## Aufbauen, auslagern oder kombinieren Es gibt drei Beschaffungsmodelle, und die meisten Organisationen landen irgendwo dazwischen. **Vergleich der SOC-Beschaffungsmodelle** | Modell | Wer es betreibt | Am besten geeignet für | | --- | --- | --- | | Intern | Ihre eigenen Analysten und Ihr eigenes Werkzeug | Hochsensible Umgebungen, die volle Kontrolle und vollen Kontext wünschen | | Ausgelagert (MSSP) | Ein Managed Security Service Provider | Teams, die schnell eine 24x7-Abdeckung benötigen, ohne eine vollständige Mannschaft einzustellen | | Hybrid | Interne Verantwortliche plus ein MSSP oder MDR für die Zeit außerhalb der Geschäftszeiten | Die meisten mittelgroßen Organisationen, die Kosten, Abdeckung und Kontrolle ausbalancieren | Das Auslagern der Überwachung lagert nicht die Verantwortung aus. Ein MSSP kann die Nachtschicht übernehmen, doch Ihr Team bleibt für das Asset-Inventar, die Reaktionsentscheidungen, die Ihr Geschäft berühren, und die Beziehung zum übrigen IT-Bereich verantwortlich. Der häufige Fehlerfall besteht darin, einen MSSP als etwas zu behandeln, das man einrichtet und vergisst, um dann während eines Vorfalls festzustellen, dass niemand Ihre wichtigsten Systeme kartiert oder vereinbart hat, wer einen Host isolieren darf. ## Wo das SOC in der Governance verortet ist Das SOC ist eine operative Fähigkeit, aber es existiert nicht im luftleeren Raum. Es führt den Erkennungs- und Reaktionsteil von Rahmenwerken wie dem Funktionssatz des NIST Cybersecurity Framework aus (identifizieren, schützen, erkennen, reagieren, wiederherstellen) und liefert Nachweise, die die ISO/IEC 27001-Kontrollen für Protokollierung, Überwachung und Vorfallmanagement stützen. Unter Regelwerken wie NIS2 und DORA ist die Fähigkeit, Vorfälle rasch zu erkennen und zu melden, nicht mehr optional, und das SOC ist üblicherweise der Ort, an dem diese Fähigkeit operationalisiert wird. Für Praktiker bedeutet das, dass ein SOC nicht nur an seiner technischen Erkennungsrate gemessen wird, sondern daran, ob es die Zeitachse, die Nachweise und die Meldungen erzeugen kann, die Auditoren und Aufsichtsbehörden erwarten. --- ## Security Orchestration, Automation and Response (SOAR) **URL:** https://cyberacademy.net/de/resources/encyclopedia/soar **Last reviewed:** 2026-06-24 SOAR ist die Schicht, die SIEM-Alerts verarbeitet und Playbooks ausführt: Anreicherung, Triage, Eindämmung, Ticketing. Ziel: MTTR senken und Analysten von Copy-paste-Arbeit entlasten. Vorsicht vor übertriebenen Versprechen der Anbieter: Ein SOAR ist nur so gut wie die Playbooks, die Sie schreiben und pflegen. Die meisten gescheiterten SOAR-Projekte sind an fehlenden Playbook-Autoren zugrunde gegangen. ## Was SOAR zusätzlich zum SIEM bietet Security Orchestration, Automation and Response ist die Aktionsebene, die hinter der Erkennung steht. Ein SIEM ist gut darin, Logs zu sammeln, sie zu korrelieren und Alarme auszulösen, aber beim Alarm hört es auf. Das SOAR übernimmt von dort und erledigt die Arbeit, die ein Analyst andernfalls von Hand erledigen würde: Es reichert den Alarm mit Reputationsabfragen und Asset-Kontext an, entscheidet, wie dringend er ist, eröffnet oder aktualisiert ein Ticket und ergreift, wo die Richtlinie es erlaubt, Eindämmungsmaßnahmen wie das Isolieren eines Hosts, das Deaktivieren eines Kontos oder das Blockieren eines Indikators an der Firewall. Die Arbeitseinheit in einem SOAR ist das Playbook, eine kodifizierte Abfolge von Schritten, die eine wiederholbare Prozedur zur Vorfallbearbeitung in etwas verwandelt, das die Plattform eigenständig ausführen kann. Orchestrierung und Automatisierung sind zwei verschiedene Konzepte, die das Akronym zusammenfasst. Orchestrierung ist die Verdrahtung: das Verbinden von SIEM, EDR, Ticketing-System, Identitätsanbieter, Threat-Intelligence-Feeds und Firewall, damit sie über eine einzige Konsole Daten und Befehle untereinander austauschen können. Automatisierung ist das, was über diese Verdrahtung ohne menschliches Zutun läuft. Die meisten reifen Teams behalten bei den destruktiven Schritten eine menschliche Freigabe bei, sodass die Plattform automatisch anreichert und triagiert, aber wartet, bis ein Analyst bestätigt, bevor sie einen Produktionsserver in Quarantäne nimmt. Diese Mischung, automatisierte Fleißarbeit mit menschlichem Urteil bei den folgenreichen Aktionen, ist das, was Praktiker tatsächlich einsetzen. ## SIEM, SOAR und das SOC Diese drei Begriffe treten gemeinsam auf und lassen sich leicht verwechseln. Sie sind keine konkurrierenden Produkte. Sie beschreiben unterschiedliche Aufgaben innerhalb derselben Erkennungs- und Reaktionsoperation. **SIEM vs SOAR vs SOC** | Begriff | Was es ist | Seine Aufgabe | | --- | --- | --- | | SIEM | Eine Plattform | Sammelt und korreliert Logs und Telemetrie und löst dann Alarme aus, wenn etwas falsch erscheint. | | SOAR | Eine Plattform | Nimmt diese Alarme auf und führt Playbooks aus: Anreicherung, Triage, Eindämmung, Ticketing. | | SOC | Ein Team und eine Funktion | Die Analysten und der Prozess, die beide betreiben, untersuchen, was die Werkzeuge zutage fördern, und entscheiden, was zu tun ist. | Lesen Sie es als eine Pipeline. Das SIEM findet das Signal, das SOAR erledigt die wiederholbare Reaktionsarbeit rund um dieses Signal, und das SOC sind die Menschen, denen der gesamte Kreislauf gehört und die alles bewältigen, was die Playbooks nicht können. Der klarste Nutzen von SOAR liegt im Volumen: Phishing-Meldungen, Alarme zu Massen-Malware, verdächtige Anmeldungen. Alles, was massenhaft eintrifft und einem vorhersehbaren Bearbeitungsmuster folgt, ist ein Kandidat für ein Playbook, und genau daher kommt die Verkürzung der mittleren Reaktionszeit und der Grund, warum Analysten aufhören, ihre Schicht mit Copy-and-paste-Anreicherung zu verbringen. ## Warum SOAR-Projekte gelingen oder scheitern Die shortDefinition benennt die Falle unverblümt, und das deckt sich mit dem, was die Praxis zeigt: Ein SOAR ist nur so gut wie die Playbooks, die Sie schreiben und pflegen, und den meisten gescheiterten SOAR-Projekten gingen die Playbook-Autoren aus. Die Plattform wird mit Konnektoren und einer Workflow-Engine geliefert, aber sie wird ohne jegliches Wissen über Ihre Umgebung geliefert. Jedes Playbook muss entworfen, gebaut, gegen echte Alarme getestet und dann gepflegt werden, während sich Ihre Werkzeuge, Ihr Netzwerk und Ihre Angreifer ändern. Ein Playbook, das eine im letzten Quartal abgekündigte API aufruft, ist schlimmer als gar kein Playbook, weil es mitten in einem Vorfall stillschweigend versagt. Aus der Governance-Perspektive ist SOAR der Weg, auf dem mehrere Kontrollziele aufhören, bloße Absichtserklärungen zu sein. Im Rahmen eines Informationssicherheits-Managementsystems nach ISO/IEC 27001 unterstützt es die technische Seite des Incident-Managements, der Protokollierung und Überwachung, und es erzeugt einen konsistenten, mit Zeitstempel versehenen Nachweis darüber, wie jeder Vorfall behandelt wurde, was genau der Nachweis ist, den ein Auditor sehen möchte. Es untermauert auch die Reaktionsfähigkeit, die das NIST Cybersecurity Framework voraussetzt und die Vorschriften wie NIS2 und DORA von Organisationen erwarten, insbesondere im Hinblick auf die zeitnahe Bearbeitung und Meldung erheblicher Vorfälle. Behandeln Sie SOAR als Kraftverstärker für einen funktionierenden Prozess, nicht als Ersatz dafür, einen zu haben. > **Automatisieren Sie das Verfahren, dem Sie bereits vertrauen** Ein Playbook kodifiziert ein Reaktionsverfahren. Wenn das manuelle Verfahren unklar oder nicht abgestimmt ist, lässt die Automatisierung das Falsche nur schneller geschehen. Schreiben und validieren Sie das Runbook zuerst mit Ihren Analysten, kodieren Sie es dann, und behalten Sie bei jedem Schritt, der ein System oder ein Konto offline nehmen kann, eine menschliche Freigabe bei. --- ## Stage 1 / Stage 2 Audit **URL:** https://cyberacademy.net/de/resources/encyclopedia/stage-1-2-audit **Last reviewed:** 2026-06-24 Initial ISO certification splits into stage 1 (documentation and readiness review, usually 1–2 days) and stage 2 (operational evidence audit, 2–5 days). Stage 1 confirms the management system exists on paper; stage 2 verifies it actually operates. Most "failed" stage 2 audits are stage 1 problems that nobody fixed in between. Eine akkreditierte Zertifizierung gegen eine Managementsystemnorm wie ISO/IEC 27001 ist kein einzelner Besuch. Die Zertifizierungsstelle führt ein Erstaudit in zwei getrennten Stufen durch, die zwei unterschiedliche Fragen beantworten. Stufe 1 fragt, ob das Managementsystem existiert und auditbereit ist. Stufe 2 fragt, ob es in der Praxis tatsächlich funktioniert. Beide als eine einzige fortlaufende Prüfung zu behandeln, ist die häufigste Art, wie Teams überrascht werden, denn die beiden Stufen belohnen völlig unterschiedliche Arten der Vorbereitung. ## Was Stufe 1 tatsächlich prüft Stufe 1 ist eine Bereitschafts- und Dokumentationsprüfung, in der Regel die kürzere der beiden. Der Auditor liest Ihre Kerndokumente, bestätigt, dass der Anwendungsbereich schlüssig ist, und sucht nach den von der Norm geforderten verpflichtenden Nachweisen. Für ein ISMS bedeutet das die Erklärung zur Anwendbarkeit, den Prozess zur Risikobeurteilung und Risikobehandlung, die Sicherheitsleitlinie, die Aufzeichnungen zu internem Audit und Managementbewertung sowie den Nachweis, dass das System lange genug läuft, um Daten zu erzeugen. Das Ergebnis ist kein Zertifikat. Es ist eine schriftliche Zusammenfassung der Feststellungen und etwaiger Bedenkenbereiche, die Sie vor Stufe 2 schließen sollen. In der Praxis ist Stufe 1 Ihr Frühwarnsystem. Der Auditor markiert Lücken, solange noch Zeit bleibt, sie zu beheben. Teams, die diese Feststellungen als Aufgabenliste lesen, kommen vorbereitet zu Stufe 2. Teams, die sie ablegen und weitermachen, sind diejenigen, die später Schwierigkeiten haben. ## Was Stufe 2 überprüft Stufe 2 ist das Audit der operativen Nachweise und in der Regel länger. Der Auditor wechselt von „die Leitlinie sagt das“ zu „zeigen Sie mir, dass es geschehen ist“. Er nimmt Stichproben von Aufzeichnungen, befragt die Personen, die die Maßnahmen betreiben, verfolgt Vorfälle und Zugriffsüberprüfungen bis zum Abschluss und prüft, ob der dokumentierte Prozess der täglichen Realität entspricht. Hier wird die Erklärung zur Anwendbarkeit mit echten Betriebsnachweisen abgeglichen, und hier zerfallen schwache Maßnahmen, die auf dem Papier in Ordnung schienen. > **Das Muster hinter den meisten „nicht bestandenen“ Stufe-2-Audits** Ein schlechtes Ergebnis in Stufe 2 ist meist ein Problem aus Stufe 1, das niemand dazwischen behoben hat. Der Auditor hat es Ihnen in Stufe 1 gesagt, Sie hatten Wochen zum Handeln, und die Lücke war beim zweiten Besuch noch offen. Schließen Sie die Feststellungen aus Stufe 1 gezielt, und Stufe 2 hält weit weniger Überraschungen bereit. ## Stufe 1 und Stufe 2 auf einen Blick **Wie sich die beiden Stufen in Fokus und Ergebnis unterscheiden** | Dimension | Stufe 1 | Stufe 2 | | --- | --- | --- | | Kernfrage | Existiert das System und ist es bereit? | Funktioniert das System tatsächlich? | | Haupteingabe | Dokumentation und Designprüfung | Betriebsaufzeichnungen, Interviews, Stichproben | | Typische Dauer | Kürzer (dokumentationsorientiert) | Länger (nachweisorientiert) | | Hauptergebnis | Zu schließende Feststellungen und Bedenkenbereiche | Nichtkonformitäten und Zertifizierungsentscheidung | | Was es belohnt | Vollständige, schlüssige Dokumentation | Disziplin und über die Zeit nachvollziehbare Nachweise | ## Was Praktiker zwischen den beiden Besuchen tun Das Zeitfenster zwischen Stufe 1 und Stufe 2 ist die eigentliche Arbeit. Feststellungen aus Stufe 1 sind noch keine Nichtkonformitäten, es gibt also keinen formellen Korrekturmaßnahmenplan, aber sie sind der Auditor, der Ihnen genau sagt, wo Stufe 2 nachhaken wird. Starke Teams wandeln jede Beobachtung aus Stufe 1 in einen Verantwortlichen, eine Maßnahme und eine Frist um und stellen dann sicher, dass der Nachweis, der sie schließt, in den Aufzeichnungen liegt, aus denen der Auditor Stichproben zieht. Sie halten das System außerdem im Normalbetrieb, statt eine einmalige Aufräumaktion zu inszenieren, denn Stufe 2 sucht nach einem nachhaltigen Betrieb, nicht nach einer aufgeräumten Momentaufnahme. Wo Stufe 2 tatsächlich eine Nichtkonformität aufwirft, ist die Antwort dieselbe Disziplin, die ein Überwachungsaudit erwartet: sie ehrlich als groß oder gering einstufen, eine Korrekturmaßnahme mit Frist planen und die Grundursache statt des Symptoms angehen. Die Zertifizierungsentscheidung folgt, sobald die Zertifizierungsstelle überzeugt ist, dass diese Maßnahmen tragen. --- ## Standardvertragsklauseln (SCC) **URL:** https://cyberacademy.net/de/resources/encyclopedia/scc **Last reviewed:** 2026-06-24 SCCs sind die von der Europäischen Kommission genehmigten Musterklauseln für die Übermittlung personenbezogener Daten in Drittländer ohne Angemessenheitsbeschluss. Die SCCs von 2021 ersetzten die älteren Versionen und erfordern seit Schrems II eine Transfer Impact Assessment (TIA). Pflichtdokumentation für jeden, der SaaS-Anbieter außerhalb der EU nutzt. ## Was SCCs tatsächlich leisten Standardvertragsklauseln sind ein vorformulierter Vertrag zwischen einem Datenexporteur in der EU und einem Importeur in einem Land ohne Angemessenheitsbeschluss. Mit der Unterzeichnung verpflichtet sich der Importeur zu Pflichten auf GDPR-Niveau: Zweckbindung, Sicherheit, Kontrolle von Weiterübermittlungen, Betroffenenrechte und Zusammenarbeit mit der Aufsichtsbehörde. Da die Europäische Kommission den Wortlaut bereits genehmigt hat, müssen Sie die Klauseln selbst weder aushandeln noch rechtfertigen, weshalb sie der Standardmechanismus für die Übermittlung in nahezu jeder SaaS-, Cloud- oder Unterauftragsverarbeiter-Beziehung außerhalb der EU sind. Die Klauseln sind modular aufgebaut. Sie wählen das Modul, das der tatsächlichen Beziehung entspricht: Verantwortlicher zu Verantwortlichem, Verantwortlicher zu Auftragsverarbeiter, Auftragsverarbeiter zu Auftragsverarbeiter oder Auftragsverarbeiter zu Verantwortlichem. Das falsche Modul zu wählen ist der häufigste Redaktionsfehler, da sich die Pflichten und die Andockpunkte für Unterauftragsverarbeiter zwischen den Modulen unterscheiden. SCCs enthalten zudem eine Andockklausel, die es neuen Parteien ermöglicht, einem bestehenden Klauselwerk beizutreten, wodurch lange Ketten von Unterauftragsverarbeitern beherrschbar bleiben. > **Mit der Unterschrift ist es nicht getan** Die SCCs von 2021 bieten nur dann eine Rechtsgrundlage für die Übermittlung, wenn der von ihnen versprochene Schutz vor Ort tatsächlich wirksam ist. Deshalb hat Schrems II an jedes Klauselwerk, das Sie unterzeichnen, eine Transfer-Folgenabschätzung angebracht. ## Warum die TIA die Spielregeln verändert hat Vor dem Schrems-II-Urteil von 2020 galt die Unterzeichnung von SCCs für sich genommen als ausreichend. Der Gerichtshof hat damit Schluss gemacht. Er entschied, dass vertragliche Zusagen eine ausländische Regierung nicht binden können, weshalb der Exporteur prüfen muss, ob der Importeur die Klauseln angesichts des lokalen Überwachungs- und Zugriffsrechts tatsächlich einhalten kann. Diese Prüfung ist die Transfer-Folgenabschätzung. In der Praxis dokumentieren Sie das Bestimmungsland, die Gesetze, die eine Offenlegung erzwingen könnten, die Art und Sensibilität der Daten sowie die Frage, ob ergänzende Maßnahmen wie starke Verschlüsselung, Pseudonymisierung oder aufgeteilte Verarbeitung eine festgestellte Lücke schließen. Kommt die TIA zu dem Schluss, dass der Importeur die SCC-Verpflichtungen nicht erfüllen kann und keine ergänzende Maßnahme dies behebt, sollte die Übermittlung nicht auf Grundlage der SCCs erfolgen. Hier unterscheiden sich SCCs deutlich von einem Angemessenheitsbeschluss: Die Angemessenheit ist eine Feststellung der Kommission, die die Einzelfallprüfung entfallen lässt, während SCCs diese Last für jede Übermittlung auf Sie verlagern. Das EU-US Data Privacy Framework bietet nun einen Angemessenheitsweg für zertifizierte US-Importeure, doch SCCs bleiben das Arbeitspferd für jedes andere Drittland und für US-Anbieter, die nicht zertifiziert sind. ## Was Praktiker tatsächlich tun Ein funktionierender SCC-Prozess ist wiederholbar und keine einmalige juristische Übung. Das Muster, auf das sich die meisten Teams einigen, sieht so aus. 1. Die Übermittlung kartieren: Exporteur, Importeur, die Datenkategorien und das richtige Modul bestimmen, bevor Sie die Vorlage anfassen. 1. Die Anhänge ausfüllen: die Parteien, die Beschreibung der Verarbeitung sowie die technischen und organisatorischen Sicherheitsmaßnahmen. Vage Anhänge sind der Teil, den Aufsichtsbehörden zuerst hinterfragen. 1. Die TIA durchführen und dokumentieren, einschließlich etwaiger ergänzender Maßnahmen, und sie zusammen mit den unterzeichneten Klauseln aufbewahren. 1. SCCs in Ihr Lieferanten-Onboarding einbinden, damit sie unterzeichnet sind, bevor Daten fließen, und nicht nachträglich ergänzt werden, nachdem ein Audit die Lücke aufgedeckt hat. 1. Erneut prüfen, wenn der Anbieter Unterauftragsverarbeiter wechselt, wenn sich das Bestimmungsland oder dessen Gesetze ändern, oder in einem festen Turnus. SCCs fügen sich in Ihre umfassendere GDPR-Rechenschaftsgeschichte ein. Sie verweisen auf die Verzeichnisse der Verarbeitungstätigkeiten, auf die DPIA, sofern eine erforderlich ist, und auf die Sicherheitsmaßnahmen, zu denen Sie sich bereits verpflichtet haben. Als lebende Dokumente behandelt statt als einmal eingeholte Unterschrift, machen sie den Unterschied zwischen einer Übermittlung, die Sie verteidigen können, und einer, die in dem Moment zusammenbricht, in dem eine Aufsichtsbehörde oder eine betroffene Person fragt, wie Sie die Daten schützen, die die EU verlassen. --- ## Statement of Applicability (SoA) **URL:** https://cyberacademy.net/de/resources/encyclopedia/soa **Last reviewed:** 2026-06-24 Das SoA ist das kontrollierte Dokument, das dem Auditor zeigt, welche Annex-A-Controls auf Sie zutreffen, warum das so ist und wo die Nachweise zu finden sind. Pflichtdokument gemäß ISO 27001. Inkonsistenzen zwischen SoA, Risikobehandlungsplan und dem tatsächlichen Betrieb sind die häufigste Ursache für Nichtkonformitäten im Stage-2-Audit. ## Warum ISO 27001 das SoA verpflichtend macht Die Anwendbarkeitserklärung ist die Brücke zwischen Ihrer Risikoarbeit und den Maßnahmen, die ein Auditor tatsächlich prüfen wird. ISO/IEC 27001 lässt den Normtext bewusst offen, welche Maßnahmen Sie umsetzen müssen, weil die richtige Antwort von Ihrem Kontext und Ihren Risiken abhängt. Im SoA schließen Sie diese Lücke: für jede Referenzmaßnahme aus Anhang A halten Sie fest, ob sie anwendbar ist, die Begründung für Aufnahme oder Ausschluss, ob sie bereits umgesetzt ist und wo die zugehörigen Nachweise liegen. Es ist eines der wenigen Dokumente, die die Norm ausdrücklich als erforderliches Ergebnis benennt, weshalb kein Zertifizierungsaudit ohne es abläuft. Eine hilfreiche Sichtweise ist, dass das SoA einen generischen Maßnahmenkatalog in eine Aussage speziell über Ihre Organisation verwandelt. Der Referenzsatz aus Anhang A ist für alle gleich. Ihr SoA ist es nicht. Zwei zertifizierte Unternehmen ähnlicher Größe können legitim unterschiedliche Maßnahmen ausschließen, weil sich ihre Risikobeurteilungen und ihr Betriebskontext unterscheiden. Das Dokument existiert, um diese Entscheidungen sichtbar und begründbar zu machen, statt sie implizit zu lassen. ## Wie das SoA mit der Risikobeurteilung und der Risikobehandlung zusammenhängt Das SoA steht nicht für sich allein. Es ist das nachgelagerte Ergebnis der Risikobeurteilung und des Risikobehandlungsplans, und die drei müssen übereinstimmen. Die Risikobeurteilung identifiziert, was schiefgehen könnte. Der Risikobehandlungsplan entscheidet, was bei jedem Risiko zu tun ist, einschließlich der anzuwendenden Maßnahmen. Das SoA erklärt dann, Maßnahme für Maßnahme, was diese Entscheidung gegenüber dem Referenzsatz aus Anhang A bedeutet. Wenn ein Auditor das SoA liest, prüft er in Wahrheit, ob die Linie von einem dokumentierten Risiko über eine Behandlungsentscheidung zu einer angewendeten Maßnahme und schließlich zu echten Nachweisen durchgängig hält. > **Drift ist der klassische Befund in Stufe 2** Die häufigste Nichtkonformität beim Audit der Stufe 2 ist die Inkonsistenz zwischen dem SoA, dem Risikobehandlungsplan und dem, was die Organisation tatsächlich tut. Eine im SoA als anwendbar und umgesetzt markierte Maßnahme, hinter der weder Nachweise noch eine betriebliche Realität stehen, ist schlimmer als ein ehrlicher Ausschluss. Bringen Sie die drei in Einklang, bevor der Auditor es für Sie tut. Ausschlüsse verdienen besondere Sorgfalt. Eine Maßnahme als nicht anwendbar zu markieren ist legitim, aber nur mit einer genannten und an Ihren Kontext gebundenen Begründung. «Wir entwickeln keine Software im Haus» ist eine vertretbare Grundlage, um bestimmte Entwicklungsmaßnahmen einzugrenzen. «Wir sind nicht dazu gekommen» ist kein Ausschluss, sondern eine Lücke. Auditoren hinterfragen Ausschlüsse genau deshalb, weil Organisationen dort mitunter unfertige Arbeit verbergen. ## Was Praktiker tatsächlich pflegen Das SoA als lebendes Register statt als einmalige Tabelle zu behandeln, ist das, was ein reibungsloses Überwachungsaudit von einer hektischen Aufholjagd unterscheidet. In der Praxis sieht eine gute Pflege so aus: 1. Führen Sie eine Zeile je Maßnahme aus Anhang A, mit Anwendbarkeit, Begründung, Umsetzungsstatus und einem Nachweisverweis, dem ein Auditor auch ohne Sie im Raum folgen kann. 1. Erstellen Sie das SoA jedes Mal neu, wenn sich die Risikobeurteilung oder der Behandlungsplan ändert, damit die drei Dokumente nie stillschweigend auseinanderlaufen. 1. Knüpfen Sie jeden Nachweisverweis an etwas Reales und Aktuelles: eine Richtlinie, eine Konfiguration, ein Ticket, ein Log, nicht an das Versprechen, ihn später zu erstellen. 1. Überprüfen Sie das Dokument in festem Takt und in der Managementbewertung, nicht erst in den Wochen vor einem Audit. 1. Beim Übergang zwischen Versionen der Norm bilden Sie das SoA auf den überarbeiteten Maßnahmensatz neu ab und stellen sicher, dass bei zusammengeführten oder neu eingeführten Maßnahmen nichts durchgefallen ist. Auf diese Weise gepflegt, hört das SoA auf, Audit-Papierkram zu sein, und wird zum Index Ihres gesamten Informationssicherheits-Managementsystems. Es ist das erste Dokument, nach dem ein erfahrener Auditor fragt, weil es ihm zeigt, wo alles andere liegt. --- ## Tabletop-Übung **URL:** https://cyberacademy.net/de/resources/encyclopedia/tabletop **Last reviewed:** 2026-06-24 Eine Tabletop-Übung ist eine diskussionsbasierte Simulation eines Störungsszenarios mit dem Response-Team am Tisch. Kostengünstig, schnell und deckt Lücken auf, die kein Dokumentenreview aufzeigt. Pflichtpraxis gemäß ISO 22301, NIS 2 und DORA sowie die Maßnahme mit dem höchsten ROI in einem BCM-Programm. Planen Sie sie vierteljährlich ein, nicht jährlich. ## Was eine Tabletop-Übung wirklich ist Eine Tabletop-Übung versammelt die Personen, die auf eine Störung reagieren würden, in einem Raum, führt sie durch ein realistisches Szenario und fordert sie auf, Schritt für Schritt zu schildern, was sie tun würden. Niemand fasst Produktionssysteme an. Niemand schaltet etwas auf einen Ausweichstandort um. Der ganze Sinn liegt im Gespräch: wer entscheidet, wer angerufen wird, was der Plan sagt gegenüber dem, was das Team wirklich tun würde, und wo das Dokument genau in dem Moment schweigt, in dem eine Entscheidung nötig ist. Sie ist konzeptbedingt diskussionsbasiert, weshalb sie günstig und schnell durchzuführen ist. Diese geringen Kosten sind der Grund, weshalb sie die Aktivität mit dem höchsten Ertrag in einem Kontinuitäts- oder Incident-Response-Programm ist. Ein Moderator stellt eine Ausgangssituation vor und spielt dann im Verlauf der Diskussion neue Informationen ein: Das Backup ist ebenfalls verschlüsselt, die Presse hat die Geschichte, die Rufbereitschaft ist nicht erreichbar. Das Team denkt laut nach, und die Lücken treten vor den Personen zutage, die sie beheben können. Eine Dokumentenprüfung bringt das nie hervor. Das Lesen eines Plans bestätigt, dass er existiert. Das Durchspielen eines Szenarios offenbart, ob ihn überhaupt jemand versteht, ob die Kontaktliste aktuell ist und ob zwei Teams jeweils annehmen, das andere erkläre den Vorfall. ## Worin sie sich von anderen Übungsformen unterscheidet Tabletop-Übungen stehen an einem Ende eines Spektrums der Übungsstrenge. Sie sind bewusst das leichteste Format, was sie für eine häufige Durchführung geeignet macht. Schwerere Übungen validieren die Mechanismen, über die eine Tabletop-Übung nur spricht, zu weit höheren Kosten und Beeinträchtigungen. **Vergleich der Übungsarten** | Übungsart | Was sie bewirkt | Kosten und Beeinträchtigung | | --- | --- | --- | | Tabletop | Diskussionsbasiertes Durchspielen eines Szenarios am Tisch; legt Entscheidungs- und Planlücken offen | Gering | | Durchgang / Drill | Schrittweises Einüben eines einzelnen Ablaufs, etwa einer Telefonkette oder einer Wiederherstellung | Gering bis mittel | | Funktionsübung | Reale Aktivierung bestimmter Reaktionsfunktionen ohne Auswirkung auf die Produktion | Mittel bis hoch | | Vollumfänglicher / Live-Test | Reales Failover oder reale Wiederherstellung unter Bedingungen nahe an einem echten Vorfall | Hoch | Der häufige Fehler besteht darin, die Tabletop-Übung als Ersatz für den Live-Test zu behandeln. Das ist sie nicht. Eine Tabletop-Übung belegt, dass die Personen den Plan kennen und Entscheidungen treffen können; nur ein Funktions- oder vollumfänglicher Test belegt, dass die Backups sich tatsächlich wiederherstellen lassen und die Wiederherstellungsziele erreichbar sind. Ein ausgereiftes Programm nutzt beides: häufige Tabletop-Übungen liefern die Erkenntnisse, die die seltenen, teuren Live-Tests lohnenswert machen. > **Planen Sie sie vierteljährlich, nicht jährlich** Pläne driften ab, sobald eine Organisation sich umstrukturiert, einen Lieferanten wechselt oder ein neues System einführt. Eine einmal im Jahr durchgeführte Tabletop-Übung prüft einen bereits veralteten Plan. Eine vierteljährliche Durchführung hält die Kontaktlisten, Entscheidungsrechte und Wiederherstellungsannahmen ehrlich und das Reaktionsteam geübt statt eingerostet. ## Wo Tabletop-Übungen in Normen und Regulierung einzuordnen sind Das Üben ist unter den Rahmenwerken, die Resilienz regeln, nicht optional. ISO 22301, die internationale Norm für Managementsysteme zur betrieblichen Kontinuität, verlangt, dass Kontinuitätsvorkehrungen geübt und getestet werden, und die Tabletop-Übung ist die gängigste Art, wie Organisationen diese Anforderung zwischen Live-Tests erfüllen. In der Europäischen Union erwartet die Richtlinie NIS 2 Maßnahmen zur betrieblichen Kontinuität und zum Krisenmanagement von Betreibern in wesentlichen und wichtigen Sektoren, und der Digital Operational Resilience Act legt ausdrückliche Testerwartungen für Finanzunternehmen fest, bei denen szenariobasierte Übungen Teil des Resilienz-Testprogramms sind. Worauf Prüfer und Regulierungsbehörden achten, ist nicht nur, dass eine Übung stattgefunden hat, sondern dass sie dokumentiert wurde und auf sie reagiert wurde. Eine Tabletop-Übung, die kein Protokoll und keine Korrekturmaßnahmen hervorbringt, ist Theater. Der Wert entsteht im Nachbereitungsbericht: was versagt hat, wer für die Behebung verantwortlich ist und wann erneut getestet wird. Genau diese Schleife, vom Szenario zur Feststellung, dann zur Korrektur und zur nächsten Übung, macht aus einer Tabletop-Übung statt eines Häkchens den Motor, der ein Kontinuitätsprogramm aktuell hält. --- ## Third-Party Risk Management (TPRM) **URL:** https://cyberacademy.net/de/resources/encyclopedia/tprm **Last reviewed:** 2026-06-24 TPRM ist die Disziplin, die das durch Lieferanten, Unterauftragnehmer und Dienstleister eingebrachte Risiko steuert. Onboarding-Due-Diligence, Vertragsklauseln, laufende Überwachung, Offboarding. Vorgeschrieben durch NIS 2 (Supply-Chain-Sicherheit) und DORA (IKT-Drittparteienrisiko). Der Crowdstrike-Ausfall und der SolarWinds-Vorfall haben TPRM zu einem Thema auf Vorstandsebene gemacht. Das Third-Party Risk Management (TPRM) behandelt Ihre Lieferanten, Subunternehmer und Dienstleister als Erweiterung Ihrer eigenen Angriffsfläche. Die Logik ist einfach: Wenn ein Anbieter Ihre Daten verarbeitet, Ihre Infrastruktur betreibt oder Teil Ihrer Lieferkette ist, dann werden seine Schwachstellen zu Ihren Vorfällen. TPRM ist die Disziplin, die diese Exposition sichtbar, vertraglich geregelt und kontinuierlich überwacht macht, statt sie erst im Moment der Kompromittierung zu entdecken. ## Die vier Phasen, die Praktiker tatsächlich durchlaufen TPRM ist kein einmaliger Fragebogen. Es ist ein Lebenszyklus, der vom ersten Kontakt mit einem Anbieter bis zu dem Tag reicht, an dem Sie ihn abschalten. Die meisten ausgereiften Programme gliedern ihn in vier Phasen: - Onboarding-Due-Diligence. Vor der Unterzeichnung bewerten Sie den Lieferanten anhand des Risikos, das er einbringt. Ein SaaS-Anbieter, der personenbezogene Daten verarbeitet, und ein Bürobedarfslieferant erhalten nicht dieselbe Prüfung. Die Einstufung nach Kritikalität ist es, die verhindert, dass das Programm untergeht. - Vertragsklauseln. Der Vertrag ist der Ort, an dem die Zusicherung durchsetzbar wird: Sicherheitspflichten, Auditrechte, Fristen für die Meldung von Verstößen, Offenlegung von Unterauftragsverarbeitern, Datenstandort und Ausstiegsbedingungen. Was nicht im Vertrag steht, können Sie später nicht einfordern. - Laufende Zusicherung. Das Risiko friert bei der Unterzeichnung nicht ein. Die Kadenz der Neubewertung, die Verfolgung von Zertifikaten (ISO 27001, SOC 2), die kontinuierliche Überwachung der Sicherheitslage des Anbieters und die Überprüfung der Abhängigkeiten von Viertparteien halten das Bild aktuell. - Off-Boarding. Wenn die Beziehung endet, fordern Sie die Daten zurück oder bestätigen deren Vernichtung, entziehen Zugänge und schließen die verbleibende Exposition. Es ist die Phase, die Teams am häufigsten überspringen, und diejenige, die verwaiste Zugangsdaten zurücklässt. ## Warum es zum Thema auf Vorstandsebene wurde TPRM war früher im Einkauf angesiedelt. Es ist in den Vorstand gewandert, weil die aufsehenerregenden Ausfälle des letzten Jahrzehnts über die Lieferkette kamen, nicht durch die Vordertür. Der SolarWinds-Vorfall zeigte einen Angreifer, der Tausende von Organisationen erreichte, indem er ein einziges vertrauenswürdiges Software-Update kompromittierte. Der CrowdStrike-Ausfall zeigte, dass ein fehlerhaftes Update eines einzigen kritischen Anbieters den Betrieb ganzer Branchen auf einen Schlag zum Erliegen bringen konnte. Beide rahmten Dritte als systemisches Risiko neu, nicht als ein Häkchen im Einkauf. Die Regulierung folgte. NIS 2 macht die Sicherheit der Lieferkette zu einer ausdrücklichen Pflicht für die erfassten Einrichtungen und nimmt die Leitungsorgane bei Versäumnissen in die Verantwortung. DORA geht für Finanzunternehmen weiter und widmet eine ihrer fünf Säulen dem IKT-Drittparteienrisiko, indem sie spezifische vertragliche Anforderungen auferlegt und kritische IKT-Anbieter selbst unter Aufsicht stellt. Für ein reguliertes Unternehmen ist TPRM keine bewährte Praxis mehr, sondern eine dokumentierte Pflicht. > **Eine Drittpartei ist keine Viertpartei** Ihr direkter Anbieter ist die Drittpartei. Deren Lieferanten sind Ihre Viertparteien, und Sie sehen sie selten. Das Konzentrationsrisiko verbirgt sich hier: Viele Ihrer Anbieter könnten von derselben Cloud-Region oder derselben vorgelagerten Bibliothek abhängen. Diese Abhängigkeitskette abzubilden ist das, was ein Alibi-Programm von einem echten unterscheidet. ## Wie sich TPRM von benachbarten Disziplinen unterscheidet TPRM steht neben dem Lieferantenmanagement und dem allgemeinen Risikomanagement, ist aber enger und schärfer als beide. Das Lieferantenmanagement optimiert Kosten, Leistung und die Geschäftsbeziehung. TPRM kümmert sich speziell um das Sicherheits-, Resilienz-, Datenschutz- und Compliance-Risiko, das eine Drittpartei einbringt. Es unterscheidet sich auch von der internen ISMS-Arbeit: Ihre Kontrollen enden an Ihrem Perimeter, Ihre Rechenschaftspflicht jedoch nicht. Sie können die Tätigkeit auslagern, das Risiko können Sie nicht auslagern. Diese Asymmetrie ist der ganze Grund, warum es die Disziplin gibt. --- ## Threat-Led Penetration Testing (TLPT) **URL:** https://cyberacademy.net/de/resources/encyclopedia/tlpt **Last reviewed:** 2026-06-24 TLPT ist die von der Aufsichtsbehörde beaufsichtigte Red-Team-Übung, die DORA für bedeutende Finanzunternehmen vorschreibt. Sie basiert auf dem TIBER-EU-Framework (Threat Intelligence-Based Ethical Red Teaming). Die Übung erstreckt sich über mehrere Monate, ist geheimdienstlich gesteuert und wird von der nationalen Behörde überwacht. Es ist der anspruchsvollste Test, dem ein CISO sich stellen muss, und derjenige, der das SOC so zeigt, wie es wirklich ist. ## Was ein bedrohungsgeführter Penetrationstest tatsächlich ist Der bedrohungsgeführte Penetrationstest ist eine kontrollierte Red-Team-Übung gegen eine Organisation im laufenden Produktivbetrieb, gesteuert durch reale Bedrohungsaufklärung und beaufsichtigt durch eine Finanzbehörde. Der Digital Operational Resilience Act, DORA, macht ihn zu einer periodischen Pflicht für die Finanzunternehmen, die eine Aufsichtsbehörde für bedeutend genug hält, um dies zu rechtfertigen, und die Übung baut auf TIBER-EU auf, dem Rahmenwerk, das die Europäische Zentralbank für das Threat Intelligence-Based Ethical Red Teaming veröffentlicht hat. Das entscheidende Wort ist geführt: Der Test ist keine generische Liste von Schwachstellen, sondern eine Kampagne, geformt davon, wer dieses Unternehmen realistisch angreifen würde und wie. Ein Anbieter von Bedrohungsaufklärung erstellt ein Profil des Unternehmens, identifiziert plausible Angreifer und ihre Methoden und übergibt dem Red Team eine Reihe von Szenarien. Das Red Team versucht dann, kritische Funktionen im Produktivbetrieb mithilfe dieser Szenarien zu kompromittieren, genau so, wie es ein echter Angreifer täte. Zwei Eigenschaften trennen den TLPT vom gewöhnlichen Penetrationstest. Erstens zielt er auf den produktiven Bestand sowie die ihn umgebenden Menschen und Prozesse ab, nicht auf eine Kopie oder einen abgegrenzten Ausschnitt, weshalb er unter strengen Regeln und mit einem kleinen, vertrauenswürdigen Kontrollteam durchgeführt wird. Zweitens wird er beaufsichtigt. Die zuständige nationale Behörde und, wo relevant, ein dediziertes TIBER-Team sind in den Auftrag eingebunden, validieren den Geltungsbereich, akkreditieren die Tester und überwachen, wie die Übung durchgeführt wird. Diese Aufsicht ist es, die das Ergebnis für eine Aufsichtsbehörde glaubwürdig macht und nicht nur für das Unternehmen, das es in Auftrag gegeben hat. ## Wie ein TLPT-Auftrag abläuft Ein TLPT ist ein über mehrere Monate laufendes Programm, keine einwöchige Bewertung, und es entfaltet sich in definierten Phasen, die das TIBER-EU-Rahmenwerk vorgibt. In der Vorbereitungsphase einigen sich das Unternehmen, das Kontrollteam und die Behörde auf den Geltungsbereich, bestätigen, welche kritischen Funktionen betroffen sind, und beauftragen akkreditierte Anbieter von Bedrohungsaufklärung und Red Team. In der Testphase erstellt der Aufklärungsanbieter einen Targeting-Bericht über das Unternehmen, und das Red Team nutzt ihn, um realistische Angriffsszenarien gegen die produktiven Funktionen durchzuführen, häufig über viele Wochen, mit dem Ziel, definierte Vorgaben zu erreichen, ohne gestoppt zu werden. In der Abschlussphase treffen sich Red Team, Blue Team und Kontrollteam, um zu rekonstruieren, was geschehen ist, die Feststellungen abzustimmen und einen Behebungsplan zu erstellen. Das entscheidende Detail ist, dass fast niemand innerhalb der Organisation weiß, dass der Test stattfindet. Die Verteidiger, das Security Operations Centre und die Incident Responder werden nicht informiert, denn der ganze Sinn besteht darin, zu sehen, wie sie sich gegen eine echte Eindringung verhalten und nicht gegen eine geplante Übung. Nur ein winziges Kontrollteam ist eingeweiht. Das macht den TLPT zur ehrlichsten Messung operativer Resilienz, die ein CISO in Auftrag geben wird, und zu derjenigen, die am zuverlässigsten die Lücke offenlegt zwischen dem, was das SOC vermeintlich leistet, und dem, was es unter Druck tatsächlich erkennt. > **Das SOC ist das eigentliche Prüfobjekt** Weil die Verteidiger nicht vorgewarnt werden, misst ein TLPT Erkennung und Reaktion so, wie sie wirklich sind, und nicht so, wie die Runbooks sie beschreiben. Alarme, die nie justiert wurden, Eskalationspfade, die niemand geprobt hat, und blinde Flecken in der Abdeckung treten hier alle zutage. Behandeln Sie die Purple-Teaming-Abschlussphase, in der Red und Blue die Kampagne gemeinsam rekonstruieren, als das wertvollste Ergebnis, nicht den Einbruch selbst. ## TLPT, TIBER-EU und gewöhnlicher Penetrationstest **Wo der TLPT im Verhältnis zu benachbarten Übungen steht** | Dimension | Standard-Penetrationstest | Bedrohungsgeführter Penetrationstest (TLPT) | | --- | --- | --- | | Treiber | Vordefinierter Geltungsbereich und eine Tester-Checkliste | Maßgeschneiderte Bedrohungsaufklärung zum konkreten Unternehmen | | Ziel | Häufig eine Staging-Kopie oder eine abgegrenzte Anwendung | Kritische Funktionen im Produktivbetrieb und die Menschen darum herum | | Kenntnis der Verteidiger | Üblicherweise informiert, manchmal unterstützend | Nicht informiert, nur ein kleines Kontrollteam weiß Bescheid | | Dauer | Tage bis wenige Wochen | Mehrere Monate über definierte Phasen hinweg | | Aufsicht | Intern, vom Unternehmen beauftragt | Beaufsichtigt durch die nationale Behörde nach TIBER-EU | | Auslöser | Ermessensabhängig oder vertraglich | Eine DORA-Pflicht für benannte bedeutende Unternehmen | Es hilft, das Verhältnis zwischen den Begriffen klar zu halten. TIBER-EU ist das Rahmenwerk, die Methodik und die Phasen. Der TLPT ist die regulatorische Pflicht nach DORA, die dieses Rahmenwerk für die in den Anwendungsbereich fallenden Finanzunternehmen übernimmt und referenziert. Ein Standard-Penetrationstest bleibt eine wertvolle und weit häufigere Tätigkeit, aber er beantwortet eine engere Frage: Gibt es ausnutzbare Schwächen in diesem System? Ein TLPT beantwortet eine schwierigere: Wenn ein realistischer Angreifer heute auf unsere wichtigsten Funktionen losginge, würden wir es überhaupt bemerken, und könnten wir reagieren? Beide ergänzen einander, und eine Organisation, die einen TLPT erwartet, hört nicht auf, gewöhnliche Tests durchzuführen: Sie nutzt sie, um die offensichtlichen Lücken zu schließen, damit die bedrohungsgeführte Übung die subtilen aufspüren kann. Was Praktiker zur Vorbereitung tatsächlich tun, geht selten um den Kauf eines weiteren Werkzeugs. Sie erstellen ein genaues Inventar der kritischen Funktionen und der sie stützenden Systeme, damit der Geltungsbereich ehrlich vereinbart werden kann. Sie stellen sicher, dass die Erkennungs-Use-Cases justiert sind und dass das SOC die Eskalation gegen realistische Szenarien statt gegen Tabletop-Übungen geprobt hat. Sie bestätigen die Struktur des Kontrollteams sowie die rechtlichen und Risiko-Freigaben, die nötig sind, um eine Eindringung gegen die Produktion sicher durchzuführen. Und sie behandeln die Feststellungen als Eingabe für operative Resilienz und Kontinuitätsplanung, denn nach DORA ist die Behebung kein privater Bericht: Sie ist ein Nachweis, von dem die Aufsichtsbehörde erwartet, dass auf ihn hin gehandelt wird. --- ## Verzeichnis von Verarbeitungstätigkeiten (ROPA) **URL:** https://cyberacademy.net/de/resources/encyclopedia/ropa **Last reviewed:** 2026-06-24 Das ROPA ist das dokumentierte Verzeichnis der Verarbeitungstätigkeiten gemäß GDPR Artikel 30. Verantwortliche führen Zweck, Kategorien, Empfänger, Speicherfristen und Übermittlungen auf; Auftragsverarbeiter listen die vertretenen Verantwortlichen, Kategorien und Übermittlungen. Die meisten Organisationen unterschätzen den Pflegeaufwand. Die Aufsichtsbehörde fordert das ROPA als Erstes an, wenn eine Untersuchung beginnt. ## Was das Verzeichnis von Verarbeitungstätigkeiten (ROPA) wirklich ist Das Verzeichnis von Verarbeitungstätigkeiten ist die Landkarte von allem, was eine Organisation mit personenbezogenen Daten tut. Es ist keine Richtlinie und kein Versprechen; es ist ein aktuell gehaltenes Inventar, das es ermöglicht, für jeden einzelnen Verarbeitungsvorgang eine einfache Frage zu beantworten: welche Daten, zu welchem Zweck, auf welcher Rechtsgrundlage, wer hat Zugriff, wohin gehen sie und wie lange werden sie aufbewahrt. Die GDPR macht dieses Verzeichnis nach Artikel 30 zur Pflicht und teilt die Verantwortung nach Rolle auf. Ein Verantwortlicher dokumentiert seine eigenen Verarbeitungstätigkeiten; ein Auftragsverarbeiter dokumentiert die Kategorien von Verarbeitungen, die er im Auftrag der von ihm betreuten Verantwortlichen durchführt. Die beiden Verzeichnisse überschneiden sich, sind aber nicht dasselbe, und eine Organisation, die sowohl als Verantwortlicher als auch als Auftragsverarbeiter handelt, muss beide führen. In der Praxis ist das ROPA das Fundament, auf dem der Rest eines Datenschutzprogramms steht. Sie können keine sinnvolle DSFA durchführen, keinen Antrag einer betroffenen Person beantworten, keine Datenpanne eingrenzen und keinen Auftragsverarbeitungsvertrag verhandeln, ohne zuvor zu wissen, dass die Verarbeitung existiert und wo die Daten liegen. Deshalb verlangt die Aufsichtsbehörde das ROPA als Erstes, wenn eine Untersuchung eröffnet wird. Es ist für eine Aufsichtsbehörde der schnellste Weg, einzuschätzen, ob eine Organisation ihre eigenen Daten tatsächlich versteht, und ein dürftiges oder veraltetes Verzeichnis signalisiert, dass der Rest des Programms wahrscheinlich ebenfalls dürftig ist. ## Was hineingehört: Verantwortlicher gegenüber Auftragsverarbeiter Die beiden Versionen des Verzeichnisses enthalten unterschiedliche Felder, weil die beiden Rollen unterschiedliche Fragen beantworten. Ein Verantwortlicher entscheidet, warum und wie Daten verarbeitet werden, daher muss sein Verzeichnis jeden Zweck rechtfertigen. Ein Auftragsverarbeiter handelt nur auf Weisung, daher beschreibt sein Verzeichnis die erbrachte Dienstleistung, nicht die dahinterstehende Begründung. **Verzeichnis des Verantwortlichen gegenüber Verzeichnis des Auftragsverarbeiters** | Element | Verzeichnis des Verantwortlichen | Verzeichnis des Auftragsverarbeiters | | --- | --- | --- | | Identität und Kontakt | Verantwortlicher, etwaige gemeinsam Verantwortliche, Vertreter, DPO | Auftragsverarbeiter, Vertreter, DPO, und jeder betreute Verantwortliche | | Zwecke | Zweck jeder Verarbeitungstätigkeit | Nicht erforderlich; der Auftragsverarbeiter handelt auf Weisung | | Betroffene Personen und Kategorien | Kategorien von Personen und von personenbezogenen Daten | Kategorien von Verarbeitungen je betreutem Verantwortlichen | | Empfänger | An wen die Daten offengelegt werden | Ebenso, soweit für die Dienstleistung relevant | | Übermittlungen | Übermittlungen außerhalb der EU und die verwendeten Garantien | Übermittlungen außerhalb der EU und die verwendeten Garantien | | Aufbewahrung | Vorgesehene Löschfristen, soweit möglich | Nicht gesondert erforderlich | | Sicherheit | Allgemeine Beschreibung der technischen und organisatorischen Maßnahmen | Allgemeine Beschreibung der technischen und organisatorischen Maßnahmen | Die Felder wirken administrativ, doch jedes einzelne trägt Last. Aufbewahrungsfristen steuern Ihre Löschworkflows. Empfängerlisten speisen Ihr Auftragsverarbeiter-Inventar und Ihre Übermittlungs-Folgenabschätzungen. Die Datenkategorien zeigen an, wo die Verarbeitung besonderer Kategorien eine DPO-Pflicht oder eine DSFA auslöst. Ehrlich ausgefüllt ist das ROPA ein funktionierendes Diagnosewerkzeug; als bloße Pflichtübung zum Abhaken ausgefüllt, ist es schlimmer als nutzlos, weil es eine falsche Sicherheit vermittelt. > **Die Pflege ist der schwierige Teil** Die meisten Organisationen unterschätzen die Pflege. Das erste ROPA aufzubauen ist ein Projekt mit klarem Ende; es aktuell zu halten ist ein Prozess ohne Ende. Neue Tools, neue Dienstleister, neue Marketingkampagnen und Umstrukturierungen verändern allesamt die Verarbeitungslandschaft, und ein Verzeichnis, das beim Audit vollständig war, veraltet binnen Monaten. Die Lösung besteht darin, ROPA-Aktualisierungen an bestehende Änderungsereignisse zu koppeln, das Onboarding eines Dienstleisters, den Start einer Funktion, die Unterzeichnung eines AVV, statt sich auf eine jährliche Überprüfung zu verlassen, für die sich niemand zuständig fühlt. ## Wer eines führen muss und wie es zusammenhängt Die GDPR formuliert die Pflicht aus Artikel 30 mit einer Ausnahme für Organisationen mit weniger als 250 Beschäftigten, doch die Ausnahme ist eng genug, dass die meisten dennoch ein Verzeichnis benötigen. Sie entfällt, sobald die Verarbeitung nicht nur gelegentlich erfolgt, voraussichtlich ein Risiko für Personen mit sich bringt oder besondere Kategorien beziehungsweise strafrechtlich relevante Daten betrifft, was die routinemäßige Verarbeitung nahezu jedes funktionierenden Unternehmens abdeckt. Aufsichtsbehörden, darunter die CNIL, behandeln das ROPA als erwartete Praxis statt als seltene Pflicht, und die CNIL veröffentlicht eine kostenlose Vorlage, um die Einstiegshürde zu senken. Das Verzeichnis steht nicht für sich allein. Es ist das Rückgrat, an das sich die DSFA, die DPO-Funktion und der Prozess der Reaktion auf Datenpannen anschließen. Der DPO nutzt es, um die Einhaltung zu überwachen und zum Risiko zu beraten; eine DSFA beginnt damit, den einschlägigen Eintrag herauszuziehen; eine Pannenbewertung nutzt es, um einzugrenzen, welche Daten und welche Personen betroffen sind. Organisationen, die auf ISO 27701 hinarbeiten, werden im ROPA im Wesentlichen das Datenschutz-Informationsmanagementsystem erkennen, das dasselbe Inventar verlangt, weshalb reife Teams ein einziges Verzeichnis führen und es mehreren Regelwerken dienen lassen, statt parallele Listen zu pflegen. --- ## Vulnerability Management **URL:** https://cyberacademy.net/de/resources/encyclopedia/vulnerability-management **Last reviewed:** 2026-06-24 Vulnerability Management ist der Zyklus aus Erkennung, Priorisierung, Behebung und Verifikation von Schwachstellen in Ihrer Infrastruktur. Scanner melden Tausende von Befunden; die eigentliche Disziplin liegt in der Priorisierung (Asset-Kritikalität, Exploit-Verfügbarkeit und geschäftliche Exposition) und nicht im Scan selbst. CVE, CVSS und KEV bilden dabei das grundlegende Vokabular. ## Ein Zyklus, kein Scan Schwachstellenmanagement wird oft auf das «Starten des Scanners» reduziert, doch der Scan ist der einfache Teil. Die Disziplin ist ein sich wiederholender Zyklus: ein genaues Inventar dessen führen, was man besitzt, die Schwächen auf diesen Assets aufdecken, die wenigen priorisieren, auf die es wirklich ankommt, sie beheben und überprüfen, dass die Korrektur Bestand hatte. Ein moderner Scanner liefert auf einem mittelgroßen Bestand Tausende von Befunden. Diese Liste als Aufgabenwarteschlange zu behandeln, ist der Weg, auf dem Teams ausbrennen, während ihre tatsächliche Exposition offen bleibt. Der Wert liegt im Trichter, von Tausenden roher Befunde bis hin zur kleinen Menge, an der man diese Woche arbeitet. Es hängt auch von etwas ab, das die meisten Teams unterschätzen: den eigenen Bestand zu kennen. Eine Schwachstelle auf einem zum Internet exponierten Server, auf dem eine geschäftskritische Anwendung läuft, ist ein anderes Problem als derselbe Fehler auf einem isolierten Testsystem. Ohne Asset-Inventar und Verantwortlichkeit hat die Priorisierung keine Grundlage, weshalb der Zyklus mit Entdeckung und Identifikation beginnt und nicht mit dem Scan selbst. ## Das Vokabular: CVE, CVSS und KEV Drei Bezugspunkte tragen den Großteil der Priorisierungsdiskussion, und Praktiker nutzen sie in Kombination statt einzeln. **Wie CVE, CVSS und KEV verwendet werden** | Begriff | Was es ist | Was es dir sagt | | --- | --- | --- | | CVE | Ein eindeutiger Bezeichner für eine öffentlich offengelegte Schwachstelle | Ein gemeinsamer Name, damit alle über denselben Fehler über Werkzeuge und Sicherheitshinweise hinweg sprechen. | | CVSS | Ein Bewertungsrahmen, der den Schweregrad einstuft | Wie schwerwiegend der Fehler in der Theorie ist, gemessen an Auswirkung und Ausnutzbarkeitsmerkmalen. Ein Ausgangspunkt, kein Urteil. | | KEV | Ein Katalog von Schwachstellen, die bekanntermaßen in freier Wildbahn ausgenutzt werden | Ob Angreifer sie tatsächlich gerade jetzt nutzen, was die Priorität in der realen Welt deutlich erhöht. | Der häufige Fehler besteht darin, nach CVSS-Wert zu sortieren und von oben nach unten zu arbeiten. Ein hoher CVSS auf einem Asset, das niemand erreichen kann, zählt weniger als ein mittel bewerteter Fehler, der in einem Katalog bekannt ausgenutzter Schwachstellen auf einem exponierten System steht. Reife Programme verbinden den theoretischen Schweregrad mit realen Signalen: gibt es einen funktionierenden Exploit, wird die Schwachstelle aktiv ausgenutzt, und wie exponiert und kritisch ist das betroffene Asset. Diese Kombination, nicht der reine Wert, steuert die Warteschlange. ## Priorisierung ist die ganze Arbeit Die ehrliche Einordnung ist, dass die Priorisierung das Produkt des Schwachstellenmanagements ist. Die Eingaben sind die Kritikalität des Assets, die Verfügbarkeit eines Exploits und die geschäftliche Exposition, und das Ergebnis ist eine vertretbare Entscheidung darüber, was zuerst behoben wird und was wartet. Hier verdient die Funktion ihren Wert, denn kein Team kann oder sollte alles auf einmal beheben. 1. Kritikalität des Assets: was das System für das Geschäft leistet und was es bei einer Kompromittierung erreichen kann. 1. Verfügbarkeit eines Exploits: ob ein funktionierender Exploit existiert und ob der Fehler in freier Wildbahn genutzt wird. 1. Geschäftliche Exposition: ist das Asset zum Internet exponiert, welche Daten enthält es, und welche kompensierenden Kontrollen sind ihm bereits vorgelagert. > **Wo das Schwachstellenmanagement endet und das Patch-Management beginnt** Das Schwachstellenmanagement entscheidet, was behoben wird und in welcher Reihenfolge. Das Patch-Management ist die operative Maschinerie, die eine veröffentlichte Korrektur aufnimmt und sie nach einem SLA über den Bestand ausrollt, mit Überprüfung. Sie sind zwei Hälften eines Ergebnisses: die erste priorisiert, die zweite liefert, und der Überprüfungsschritt schließt den Kreis zurück zum Scanner. ## Wo es in die Governance passt Schwachstellenmanagement ist selten optional, sobald man sich innerhalb eines anerkannten Rahmens befindet. Ein ISO/IEC 27001 ISMS erwartet einen definierten Prozess zur Handhabung technischer Schwachstellen, und Auditoren werden verlangen, den Zyklus in Betrieb zu sehen, nicht nur eine Scanner-Lizenz. Das NIST Cybersecurity Framework behandelt das Identifizieren und Handhaben von Schwachstellen als zentral für die Funktionen Identify und Protect, und Vorschriften wie NIS2 und DORA setzen voraus, dass Organisationen Schwächen aktiv finden und beheben, statt darauf zu warten, dass ein Vorfall sie offenlegt. In jedem Fall hat der Nachweis, den ein Prüfer wünscht, dieselbe Form: wie ihr entdeckt, wie ihr priorisiert, die SLAs, gegen die ihr behebt, und die Kennzahlen, die belegen, dass sich der Zyklus schließt. --- ## Zero Trust **URL:** https://cyberacademy.net/de/resources/encyclopedia/zero-trust **Last reviewed:** 2026-06-24 Zero Trust ist das Sicherheitsmodell, bei dem Sie aufhören, dem Netzwerkperimeter zu vertrauen. Jede Zugriffsentscheidung wird jedes Mal authentifiziert, autorisiert und kontextuell bewertet. Die Identität wird zum Perimeter. Entstanden bei Forrester, popularisiert durch Googles BeyondCorp, kodifiziert durch NIST SP 800-207. Lesen Sie sich durch die Vendoren-Präsentationen hindurch: Es handelt sich um eine Architektur, nicht um ein Produkt. ## Vom Perimetervertrauen zur Verifizierung jeder Anfrage Das traditionelle Modell behandelte das Unternehmensnetzwerk als vertrauenswürdige Zone. War man erst einmal hinter der Firewall, durch das VPN, hinter dem Perimeter, galt man implizit als vertrauenswürdig, um sich lateral zu bewegen. Zero Trust verwirft diese Annahme. Es gibt kein vertrauenswürdiges Inneres. Eine Anfrage von einem Laptop im Büro-LAN wird mit demselben Misstrauen behandelt wie eine Anfrage aus einem Café, denn der Standort verdient kein Vertrauen mehr. Jede Zugriffsentscheidung wird neu getroffen: wer fragt an, von welchem Gerät, mit welcher Sicherheitslage, für welche Ressource, in welchem Kontext, und ist diese Kombination genau jetzt autorisiert. Das ist wichtig, weil sich der Perimeter in der Praxis schon vor Jahren aufgelöst hat. Mitarbeitende arbeiten von zu Hause, Anwendungen liegen im SaaS eines Dritten, und ein einziger per Phishing erbeuteter Zugang bedeutete früher freie Bewegung über den gesamten Bestand. Zero Trust verkleinert diesen Wirkungsradius. Der Angreifer, der ein Passwort stiehlt, stößt weiterhin auf Geräteprüfungen, kontinuierliche Autorisierung und Segmentierung bei jedem Schritt, sodass eine einzelne Kompromittierung nicht mehr zu einer vollständigen Sicherheitsverletzung eskaliert. ## Was Praktiker tatsächlich aufbauen Schau über die Verkaufspräsentationen der Anbieter hinaus. Zero Trust ist eine Architektur und ein Betriebsmodell, keine Box, die man kauft. NIST SP 800-207 beschreibt es anhand einer Policy-Engine, die Entscheidungen trifft, eines Policy-Administrators, der sie durchsetzt, und Policy-Durchsetzungspunkten, die den Ressourcen vorgelagert sind. Die praktische Arbeit besteht darin, Identität zur Steuerungsebene zu machen und jede Anfrage gegen die Richtlinie zu prüfen. Die wiederkehrenden Bausteine sind: - Starke Identität und Authentifizierung, mit MFA als Grundlage statt als Zusatz, damit die Identität hinter einer Anfrage wirklich verifiziert ist. - Gerätestatus und Gesundheitszustand, denn ein verifizierter Nutzer auf einem kompromittierten oder nicht verwalteten Gerät bleibt ein Risiko, das es zu bewerten gilt. - Geringste Rechte und Just-in-Time-Zugriff, indem nur die engsten erforderlichen Rechte gewährt und ständige Zugänge entfernt werden, die Angreifer gern erben. - Mikrosegmentierung, damit ein Standfuß in einer Arbeitslast keinen flachen Pfad zu allem anderen öffnet. - Kontinuierliche Bewertung und Protokollierung, denn Vertrauen wird neu bewertet, sobald sich der Kontext ändert, und nicht einmal bei der Anmeldung gewährt und dann vergessen. > **Es ist eine Reise, kein Schalter** Keine Organisation legt einen einzigen Schalter um und wird zu Zero Trust. Reife entsteht schrittweise: Beginne mit Identität und MFA, verschärfe die Rechte, segmentiere das Netzwerk und füge dann eine Schicht kontinuierlicher Überwachung hinzu. Begegne jedem Produkt, das als Zero Trust aus der Box verkauft wird, mit gesunder Skepsis: Es ist bestenfalls ein Durchsetzungspunkt innerhalb einer weitaus größeren Architektur. ## Wie es sich von benachbarten Konzepten unterscheidet Zero Trust lässt sich leicht mit den Prinzipien verwechseln, auf denen es aufbaut. Geringste Rechte sind eine Zutat: Sie begrenzen, was eine Identität erreichen kann, gehen für sich genommen aber weiterhin davon aus, dass das Netzwerk vertrauenswürdig ist. Defense in Depth ist der ältere, breitere Instinkt, unabhängige Kontrollen zu schichten; Zero Trust ist eine spezifische Art, das weiche, vertrauenswürdige Innere zu entfernen, das klassische geschichtete Verteidigungen oft bestehen ließen. Identitäts- und Zugriffsmanagement liefert die Mechanik, die Verzeichnisse, die Authentifizierung und die Autorisierung, die Zero Trust als Fundament nutzt. Kurz gesagt: IAM, MFA und geringste Rechte sind Komponenten, während Zero Trust die Entwurfsphilosophie ist, die sie zu einer kontinuierlichen, kontextbezogenen Verifizierung orchestriert. In der Standard- und Politiklandschaft ist die Idee inzwischen Mainstream. NIST SP 800-207 ist die Referenzdefinition, und das NIST hat begleitende Umsetzungsleitfäden veröffentlicht. In den Vereinigten Staaten haben staatliche Vorgaben die Behörden zu Zero-Trust-Architekturen gedrängt, und europäische Stellen wie die ENISA verweisen darauf als Stoßrichtung für eine widerstandsfähige, identitätszentrierte Sicherheit. Prüfer erwarten zunehmend, die Prinzipien im Zugriffsdesign widergespiegelt zu sehen, selbst wenn ein Rahmenwerk Zero Trust nicht ausdrücklich benennt. --- ## ePrivacy-Richtlinie (ePrivacy) **URL:** https://cyberacademy.net/de/resources/encyclopedia/eprivacy **Last reviewed:** 2026-06-24 Die ePrivacy-Richtlinie (2002/58/EC, geändert 2009) ist das sogenannte "Cookie-Gesetz", das kaum jemand vollständig umsetzt. Sie regelt die Vertraulichkeit elektronischer Kommunikation sowie Tracking-Technologien auf Nutzergeräten. Älter als die GDPR und nach wie vor in Kraft; die ePrivacy-Verordnung, die sie ersetzen sollte, steckt seit 2017 in den Verhandlungen fest. Nationale Datenschutzbehörden (CNIL, Garante, AEPD) setzen sie jeweils in ihrem Zuständigkeitsbereich durch. ## Was die ePrivacy-Richtlinie tatsächlich regelt Die ePrivacy-Richtlinie (2002/58/EG, geändert durch 2009/136/EG) ist vor allem als «Cookie-Gesetz» bekannt, doch sie auf Cookies zu reduzieren übersieht den größten Teil ihres Gewichts. Ihr eigentlicher Gegenstand ist die Vertraulichkeit der elektronischen Kommunikation und der Schutz des Endgeräts des Nutzers. Sie besagt, dass Kommunikation und die damit verbundenen Verkehrsdaten vertraulich sind, dass Abhören und Überwachung eine Rechtsgrundlage benötigen und dass das Speichern oder Auslesen von Informationen auf dem Gerät einer Person, ob es sich um ein Cookie, ein Tracking-Pixel, einen Fingerprint oder ein SDK handelt, in der Regel eine vorherige Einwilligung erfordert. Den Teil zu Einwilligung und Tracking setzen die meisten Teams um; den Teil zur Vertraulichkeit vergessen die meisten Teams überhaupt. Es handelt sich um eine Richtlinie, nicht um eine Verordnung. Diese Unterscheidung ist die Quelle der Hälfte der Verwirrung in der Praxis. Eine Richtlinie legt das Ziel fest und überlässt es jedem Mitgliedstaat, sie in nationales Recht umzusetzen, sodass der genaue Wortlaut, die Einwilligungsschwelle und der Vollzugsstil von Land zu Land unterschiedlich sind. In Frankreich finden sich die einschlägigen Bestimmungen im Code des postes et des communications électroniques, und die CNIL veröffentlicht eigene Leitlinien und Empfehlungen zu Cookies und Trackern. Es gibt keinen einheitlichen unionsweiten Text, den man so zitieren kann, wie man die GDPR zitiert. ## ePrivacy neben der GDPR Die beiden Rechtsakte sind komplementär, nicht austauschbar. Die ePrivacy-Richtlinie ist lex specialis: Wo sie eine spezifische Regel enthält, geht diese Regel der allgemeineren Bestimmung der GDPR vor. Das klarste Beispiel sind Cookies und die Speicherung auf dem Gerät. Die GDPR regelt, wie Sie die von Ihnen erhobenen personenbezogenen Daten verarbeiten; ePrivacy regelt von vornherein den Akt des Zugriffs auf Informationen auf dem Gerät oder ihrer Speicherung darauf, und sie gilt selbst dann, wenn keine personenbezogenen Daten betroffen sind. So fällt ein Tracker, der eine rein technische Kennung setzt, weiterhin unter ePrivacy, auch wenn Sie argumentieren würden, dass es sich nach der GDPR nicht um ein personenbezogenes Datum handelt. Die Einwilligung nach ePrivacy übernimmt ihre Definition aus der GDPR. Wenn ePrivacy eine Einwilligung verlangt, muss diese dem Standard der GDPR entsprechen: freiwillig, spezifisch, informiert, unmissverständlich und ebenso leicht zu widerrufen wie zu erteilen. Deshalb scheitern vorangekreuzte Kästchen, Banner nach dem Muster «durch die weitere Nutzung erklären Sie sich einverstanden» und Cookie-Walls, die keine echte Wahl bieten, weiterhin an der Prüfung durch die Aufsichtsbehörden. Die beiden Texte werden zusammen gelesen. > **Älter als die GDPR, weiterhin in Kraft** ePrivacy ist deutlich mehr als ein Jahrzehnt älter als die GDPR und bleibt vollständig in Kraft. Die ePrivacy-Verordnung, die sie ersetzen und den Zeitplan an die GDPR angleichen sollte, steckt seit 2017 in den Verhandlungen fest. Bis sie kommt, ist die Richtlinie von 2002 in der 2009 geänderten Fassung, zuzüglich der Umsetzung jedes Landes, das Recht, an das Sie sich halten. ## Was Praktiker tatsächlich tun In der täglichen Arbeit dreht sich die Einhaltung von ePrivacy vor allem um die Einwilligungsebene und das dahinterstehende Inventar. Das praktische Programm sieht so aus: - Jedes Cookie, Tag, Pixel, SDK und Skript inventarisieren, das vom Gerät liest oder auf es schreibt, und jedes als unbedingt erforderlich oder nicht einstufen. Nur die unbedingt erforderlichen sind von der Einwilligung befreit. - Nicht wesentliche Tracker blockieren, bis der Nutzer eingewilligt hat, statt sie beim Laden der Seite auszulösen und hinterher zu fragen. Eine Consent-Management-Plattform setzt dies in der Regel durch. - Das Ablehnen ebenso reibungslos wie das Akzeptieren gestalten, die Einwilligung und ihren Umfang protokollieren und eine einfache Möglichkeit bieten, sie später zu widerrufen. - Auch die Vertraulichkeitspflichten im Blick behalten: Direktmarketing per E-Mail oder SMS benötigt in der Regel eine vorherige Einwilligung (Opt-in), mit einer engen Ausnahme für bestehende Kunden bei ähnlichen Produkten. Der Vollzug erfolgt national. Da es keine zentrale EU-Aufsichtsbehörde für ePrivacy gibt, überwacht jede Datenschutzbehörde ihr eigenes Hoheitsgebiet. Die CNIL in Frankreich, der Garante in Italien und die AEPD in Spanien geben jeweils Leitlinien heraus, führen Prüfungen durch und verhängen Sanktionen nach ihren nationalen Umsetzungen. Das bedeutet, dass eine paneuropäische Website nicht davon ausgehen kann, dass ein einziges Banner allen genügt; der sichere Ansatz besteht darin, die strengste Auslegung unter den von Ihnen bedienten Märkten zu erfüllen und die getroffenen Entscheidungen zu dokumentieren. --- # COURSES CATALOGUE ## CISA: Certified Information Systems Auditor **URL:** https://cyberacademy.net/de/courses/cisa **Issuer:** ISACA **Level:** practitioner **Duration:** 4 days **Price:** Live €2900 · Self-paced €790 Die ISACA-Referenzzertifizierung für IT-Revision. Fünf Domänen, vierstündige Prüfung, die von den Big Four standardmäßig vorausgesetzte Audit-Qualifikation. Viertägiger Kurs mit einer enthaltenen Wiederholungsprüfung. **You will learn how to:** - Risikobasierte IS-Prüfungen gemäß ISACA-Standards planen und durchführen. - Governance und IT-Management anhand von COBIT und ISO 27001 bewerten. - Kontrollen in den Bereichen IS-Beschaffung, -Entwicklung und -Implementierung beurteilen. - IS-Betrieb, Business Resilience und Asset-Schutz auditieren. - Prüfungsberichte erstellen, die einer Big-Four-Überprüfung standhalten. **For:** - IT-Revisoren, die aus der internen Revision in eine spezialisierte IS-Audit-Rolle wechseln. - Compliance-Beauftragte in regulierten Branchen (Banken, Versicherungen, Gesundheitswesen). - Sicherheitsanalysten, die in den Bereich Audit oder GRC wechseln. - Big-Four-Berater, die auf mandantenorientierte Einsätze abzielen. **NOT for (when you should not take this certification):** - Angehende CISOs ohne Interesse an Revision. CISM ist die managementorientierte Alternative. - Risikomanager ohne Bezug zur Revision. CRISC passt besser. - Praktiker mit weniger als drei Jahren Erfahrung. ISACA berücksichtigt nur Erfahrungen, die innerhalb der zehn Jahre vor der Antragstellung erworben wurden. --- ## CISM: Certified Information Security Manager **URL:** https://cyberacademy.net/de/courses/cism **Issuer:** ISACA **Level:** manager **Duration:** 4 days **Price:** Live €2900 · Self-paced €790 Die ISACA-Referenzzertifizierung im Sicherheitsmanagement. Vier Domänen, gefordert in rund 60 % aller CISO-Stellenausschreibungen. Vier-Tage-Kurs mit einem enthaltenen Wiederholungsversuch. **You will learn how to:** - Ein Informationssicherheitsprogramm entwerfen und steuern, das auf die Unternehmensstrategie ausgerichtet ist. - Einen Informationsrisikomanagementprozess betreiben, der Entscheidungen auf Vorstandsebene unterstützt. - Das Sicherheitsprogramm aufbauen und betreiben (Ressourcen, Architektur, Awareness, Lieferantenrisiko). - Das Incident Management leiten, von der Vorbereitung bis zur Nachbereitung. - Die technische Sicherheitslage in eine vorstandstaugliche Darstellung übersetzen, ohne an Präzision zu verlieren. **For:** - Angehende CISOs und stellvertretende CISOs. - Sicherheitsarchitekten, die in Führungsrollen wechseln. - IT-Direktoren, die das Sicherheitsportfolio übernehmen. - Berater, die bei der Gestaltung von Sicherheitsprogrammen unterstützen. **NOT for (when you should not take this certification):** - Security Engineers mit operativem Fokus und ohne Managementambitionen. CISSP oder spezialisierte technische Zertifizierungen passen besser. - IS-Auditoren ohne operatives Interesse. CISA bleibt die primäre Zertifizierung. - Junior Security Analysten mit weniger als drei Jahren Erfahrung. --- ## CRISC: Certified in Risk and Information Systems Control **URL:** https://cyberacademy.net/de/courses/crisc **Issuer:** ISACA **Level:** risk-manager **Duration:** 4 days **Price:** Live €2900 · Self-paced €790 Die ISACA-Referenzzertifizierung für IT-Risiken. Vier Domänen, die Geschäftsrisiken mit IS-Kontrollen verbinden. Die natürliche Ergänzung zu CISA und zu ISO 31000 / 27005 für das ISACA-Vokabular. **You will learn how to:** - IT-Risikomanagement in die Unternehmensgovernance einbetten. - IT-Risiken im Hinblick auf Geschäftsziele identifizieren, bewerten und priorisieren. - Risikobehandlungsoptionen entwickeln, die mit Risikoappetit und Risikotoleranz übereinstimmen. - IT-Risiken überwachen und dem Board in handlungsrelevanter Sprache berichten. - Das CRISC-Vokabular auf ISO 31000 / 27005 / NIST RMF abbilden, wenn gemischte Audits durchgeführt werden. **For:** - IT-Risikomanager, GRC-Analysten und Risikoberater. - Business-Analysten, die in das IT-Risikomanagement wechseln. - IS-Auditoren, die vom Kontrolltest zur Risikoberatung übergehen. - CISOs und stellvertretende CISOs, die das RisikoQuantifizierungsvokabular benötigen, das der Board kennt. **NOT for (when you should not take this certification):** - Rein technische Risikopraktiker (Schwachstellenmanagement, Threat Hunting). Hier empfehlen sich CISSP oder spezialisierte Zertifizierungen. - ISO-geschulte Risikopraktiker, die nicht im IT- oder IS-Umfeld tätig sind. ISO 31000 Lead Risk Manager ist breiter gefasst. - Praktiker mit weniger als drei Jahren einschlägiger Berufserfahrung. --- ## AAIA: Advanced in AI Audit **URL:** https://cyberacademy.net/de/courses/aaia **Issuer:** ISACA **Level:** expert **Duration:** 3 days **Price:** Live €2500 · Self-paced €490 Das fortgeschrittene ISACA-Credential für Auditoren, die in den KI-Bereich wechseln. Prüfungsmethodik für KI-Systeme, KI-Risikobewertung, KI-Governance-Rahmenwerke. Dreitägiges Intensivprogramm; CISA als Grundlage empfohlen. **You will learn how to:** - Planen und Durchführen eines Audits von KI-Systemen anhand der ISO 42001 AIMS und der AI Act-Anforderungen. - Bewerten von Kontrollen im Modell-Lebenszyklus (Daten-Governance, Training, Validierung, Monitoring, Außerbetriebnahme). - Prüfen von Kontrollen für KI-Fairness, Erklärbarkeit und Bias-Monitoring anhand regulatorischer und prüfungsbezogener Anforderungen. - Auditieren von KI-Lieferantenrisiken und Abhängigkeiten von Drittanbietermodellen. - Erstellen von KI-Auditberichten, die einer Überprüfung durch notifizierte Stellen und Aufsichtsbehörden standhalten. **For:** - Erfahrene IT-Auditoren, die in die KI-Prüfung wechseln. - GRC-Manager, die ein KI-Auditprogramm aufbauen. - Compliance-Verantwortliche in regulierten Branchen, die KI einsetzen (Banken, Versicherungen, Gesundheitswesen, öffentlicher Sektor). - Senior Manager und Directors der Big Four, die KI-Mandate übernehmen. **NOT for (when you should not take this certification):** - Praktiker ohne Audit-Hintergrund. Zuerst CISA, dann AAIA. - KI-Ingenieure, die Audit erlernen möchten. Das AAIA setzt Audit-Kompetenz voraus; ISO 42001 Lead Auditor ist der geeignetere Einstiegspunkt. - Nachwuchsauditoren mit weniger als zwei Jahren Berufserfahrung. --- ## AAIR: Advanced in AI Risk **URL:** https://cyberacademy.net/de/courses/aair **Issuer:** ISACA **Level:** expert **Duration:** 3 days **Price:** Live €2500 · Self-paced €490 Die ISACA-Vertiefungszertifizierung für Risk Manager, die ein AI-Risikoprogramm aufbauen. KI-Risikobewertung, Risikobehandlung, AI-Risk-Governance. Dreitägiges Intensivformat; CRISC wird als Grundlage empfohlen. **You will learn how to:** - KI-Risiken in das unternehmensweite Risikomanagement-Framework integrieren, neben Cyber-, operationellen und strategischen Risiken. - KI-Risiken über den gesamten Modell-Lebenszyklus hinweg bewerten (Aufnahme, Design, Deployment, Monitoring, Außerbetriebnahme) anhand einer AIMS-konformen Methodik. - KI-spezifische Risiken quantifizieren (Bias, Halluzination, Model Drift, regulatorische Exposition unter dem AI Act) für das Board-Reporting. - Risikobehandlungsoptionen für KI entwickeln, die Innovationsgeschwindigkeit gegen regulatorische und reputationsbezogene Exposition abwägen. - Monitoring- und Reporting-Telemetrie für KI-Risiken aufbauen, um eine kontinuierliche Überwachung sicherzustellen. **For:** - IT-Risk-Manager, die ihr Portfolio auf KI erweitern. - CROs und stellvertretende CROs, die KI in die unternehmensweite Risikotaxonomie aufnehmen. - GRC-Manager, die den AI-Risk-Workstream aufbauen. - Compliance-Verantwortliche in regulierten Branchen, die KI-Exposition für die Board-Genehmigung quantifizieren. **NOT for (when you should not take this certification):** - Fachleute ohne Risikomanagement-Hintergrund. Zuerst CRISC oder ISO 31000 Lead Risk Manager absolvieren. - KI-Ingenieure, die Risikomanagement erlernen möchten. AAIR setzt Vertrautheit mit der Risikopraktik voraus. - Junior-Risk-Analysten mit weniger als zwei Jahren Erfahrung. --- ## AAISM: Advanced in AI Security Management **URL:** https://cyberacademy.net/de/courses/aaism **Issuer:** ISACA **Level:** expert **Duration:** 3 days **Price:** Live €2500 · Self-paced €490 Das fortgeschrittene ISACA-Credential für Sicherheitsmanager, die ein KI-Sicherheitsprogramm aufbauen. KI-Bedrohungsmodellierung, sicherer Modell-Lebenszyklus, KI-Sicherheitsbetrieb. Dreitägiges Intensivformat; CISM als Grundlage empfohlen. **You will learn how to:** - Ein KI-Sicherheitsprogramm entwerfen und steuern, ausgerichtet an ISO 42001 und dem AI Act. - KI-Bedrohungsmodellierung durchführen (Prompt Injection, Model Poisoning, adversarielle Beispiele, Datenexfiltration über Inferenz). - KI-Sicherheit im Produktivbetrieb betreiben: Monitoring, Incident Response, Model Drift, Supply-Chain-Risiken bei Foundation-Model-Abhängigkeiten. - KI-Sicherheit in die übergeordneten ISMS- (ISO 27001) und AIMS- (ISO 42001) Programme integrieren. - Die KI-Sicherheitslage für Vorstand und Prüfungsausschuss verständlich aufbereiten. **For:** - CISOs und stellvertretende CISOs, die die Aufsicht über KI-Sicherheit übernehmen. - Sicherheitsprogrammmanager, die den KI-Sicherheits-Workstream aufbauen. - Sicherheitsarchitekten, die Sicherheitskontrollen für KI-Systeme konzipieren. - GRC-Manager, die KI-Risiken in das Sicherheitsprogramm integrieren. **NOT for (when you should not take this certification):** - Reine Red-Team- und Offensive-KI-Praktiker. AAISM behandelt Governance und Management, kein Pentesting. - Praktisch arbeitende ML-Ingenieure, die Sicherheit erlernen möchten. CISSP oder ein spezialisierter technischer KI-Sicherheitskurs ist hier besser geeignet. - Sicherheitsmanager ohne vorherige Managementerfahrung (unter drei Jahren). --- ## CGEIT: Certified in the Governance of Enterprise IT **URL:** https://cyberacademy.net/de/courses/cgeit **Issuer:** ISACA **Level:** manager **Duration:** 4 days **Price:** Live €2900 · Self-paced €790 Die ISACA-Referenzzertifizierung für IT-Governance auf Führungsebene. Fünf Domänen decken Framework, strategisches Management, Benefits Realisation, Risikooptimierung und Ressourcenoptimierung ab. Konzipiert für CIOs, Governance-Verantwortliche und IT-Führungskräfte mit Board-Kontakt. **You will learn how to:** - Ein unternehmensweites IT-Governance-Framework entwerfen und betreiben, das an COBIT und der Unternehmensstrategie ausgerichtet ist. - Strategische IT-Management-Zyklen leiten, die vom Board genehmigt und durch Audits validiert werden. - Benefits Realisation von IT-Investitionen quantifizieren und berichten. - IT-Risiken in das unternehmensweite Risikomanagement-Framework integrieren. - IT-Ressourcen (Personal, Technologie, Anbieterpartnerschaften) an Governance-Zielen ausrichten und optimieren. **For:** - CIOs und stellvertretende CIOs mit Verantwortung für das Governance-Portfolio. - IT-Governance-Verantwortliche in regulierten Branchen (Banken, Versicherungen, Versorgungsunternehmen, öffentlicher Sektor). - Senior Manager der Big Four, die Governance-Reviews leiten. - Board-Mitglieder in Technologie- oder Prüfungsausschüssen. **NOT for (when you should not take this certification):** - Operative IT-Manager ohne Erfahrung auf Führungsebene. CISM oder CRISC sind besser geeignet. - IS-Auditoren, die eine Audit-Zertifizierung suchen. CISA bleibt die primäre Zertifizierung. - Fachkräfte mit weniger als fünf Jahren Erfahrung auf Governance-Ebene. --- ## CDPSE: Certified Data Privacy Solutions Engineer **URL:** https://cyberacademy.net/de/courses/cdpse **Issuer:** ISACA **Level:** practitioner **Duration:** 3 days **Price:** Live €2900 · Self-paced €790 Die ISACA-Zertifizierung an der Schnittstelle von Datenschutz und Technologie. Drei Domänen: Privacy Governance, Privacy-Architektur und Data Lifecycle. Die Zertifizierung für Privacy Engineers, die GDPR-konforme Systeme entwickeln, nicht nur Richtlinien. **You will learn how to:** - Entwerfen Sie Datenarchitekturen, die GDPR und vergleichbare Datenschutzregelungen von Grund auf erfüllen. - Implementieren Sie Datenschutzmaßnahmen über den gesamten Data Lifecycle (Erhebung, Verarbeitung, Speicherung, Weitergabe, Löschung). - Führen Sie Datenschutz-Folgenabschätzungen in Verbindung mit technischen Kontrollprüfungen durch. - Übersetzen Sie rechtliche Datenschutzanforderungen in technische Spezifikationen, die Produktteams umsetzen können. - Betreiben Sie Datenschutz-Monitoring und Incident Response speziell im Hinblick auf Betroffenenrechte und Datenpannen. **For:** - Privacy Engineers und DPOs mit technischer Tiefe. - Datenarchitekten und Software-Architekten, die GDPR-konforme Systeme entwickeln. - Security Engineers, die sich in Richtung Privacy-by-Design weiterentwickeln. - CDPOs, die ihre rechtliche Expertise durch technische Glaubwürdigkeit ergänzen. **NOT for (when you should not take this certification):** - Reine Rechts-DPOs ohne technischen Hintergrund. PECB CDPO ist besser geeignet. - Junior Privacy Analysten mit weniger als drei Jahren domänenübergreifender Erfahrung. --- ## CCOA: Certified Cybersecurity Operations Analyst **URL:** https://cyberacademy.net/de/courses/ccoa **Issuer:** ISACA **Level:** practitioner **Duration:** 3 days **Price:** Live €2200 · Self-paced €690 Die praxisorientierte ISACA-Zertifizierung für SOC-Analysten und Cyber-Defence-Operatoren. Fünf Domänen umfassen Monitoring, Incident Response, Threat Hunting und Threat Intelligence. Auf Praktiker-Niveau; die Prüfung kombiniert Szenarien mit Multiple-Choice-Fragen. **You will learn how to:** - Betrieb eines Security-Monitoring-Stacks (SIEM, EDR, Netzwerk-Telemetrie) auf SOC-Tier-2-Niveau. - Durchführung eines vollständigen Incident-Response-Zyklus von der Triage bis zur Lessons-Learned-Phase, inklusive der von Auditoren erwarteten Dokumentation. - Hypothesengestützte Threat Hunts unter Verwendung von MITRE ATT&CK als Navigationsrahmen. - Verwertung und Erstellung verwertbarer Threat Intelligence in Standardformaten (STIX/TAXII). - Verbindung zwischen dem Cyber-Ops-Bereich und dem übergeordneten GRC-Programm herstellen: Incidents in Risiken überführen, Controls in Telemetrie abbilden. **For:** - SOC-Tier-1-Analysten, die auf Tier-2 aufsteigen möchten. - Incident-Response-Praktiker, die eine anerkannte Zertifizierung anstreben. - Threat Hunter, die ihre Methodik formalisieren möchten. - Cyber-Ingenieure, die in eine Defence-Operations-Rolle wechseln. **NOT for (when you should not take this certification):** - GRC-Fachleute ohne operative Erfahrung. CISA oder CISM sind besser geeignet. - Angehende CISOs. Hier empfiehlt sich CISM. - Einsteiger ohne praktische Erfahrung in der defensiven Sicherheit. --- ## COBIT 2019 Foundation **URL:** https://cyberacademy.net/de/courses/cobit-foundation **Issuer:** ISACA **Level:** foundation **Duration:** 2 days **Price:** Live €1250 Der Einstiegskurs für das COBIT 2019 Governance-Framework. Zweitägiger Kurs mit Behandlung von Framework-Struktur, Grundsätzen, Design-Faktoren und Governance-Systemkomponenten. Live-Kurs mit ISACA-Prüfung inklusive. **You will learn how to:** - Navigieren Sie im COBIT 2019 Framework: Governance-Ziele, Management-Ziele, Design-Faktoren. - Wenden Sie den Design-Workflow für Governance-Systeme auf einen realen Unternehmenskontext an. - Ordnen Sie COBIT angrenzenden Frameworks zu (ITIL, ISO 27001, ISO 38500, NIST CSF). - Positionieren Sie COBIT als integrierende Schicht oberhalb operativer Standards in einem Multi-Framework-Programm. **For:** - IT-Manager und GRC-Analysten, die in die Enterprise-IT-Governance einsteigen. - Auditoren, die ihr Framework-Vokabular über ISO 27001 hinaus erweitern möchten. - Berater, die Governance-System-Design-Mandate akquirieren. **NOT for (when you should not take this certification):** - Hands-on-Ingenieure ohne Governance-Erfahrung. - Angehende CISOs auf der Suche nach einem Leadership-Credential. CISM ist hier besser geeignet. --- ## COBIT 2019 Design & Implementation **URL:** https://cyberacademy.net/de/courses/cobit-design-implementation **Issuer:** ISACA **Level:** practitioner **Duration:** 3 days **Price:** Live €1900 Die weiterführende COBIT-Zertifizierung. Dreitägiger Kurs mit Fokus auf die Anwendung der Design-Faktoren zum Aufbau eines maßgeschneiderten Governance-Systems sowie die Entwicklung der Implementierungs-Roadmap. Live-Kurs inklusive ISACA-Prüfung. Foundation ist Voraussetzung. **You will learn how to:** - Den COBIT 2019-Design-Workflow für ein reales Unternehmen vollständig durchführen. - Design-Faktoren bewerten und anwenden, um das Governance-System zu fokussieren. - Die Implementierungs-Roadmap mit priorisierten Goals Cascade und Capability-Zielen aufbauen. - Change Management für die Governance-Einführung in IT- und Business-Teams leiten. **For:** - IT-Governance-Verantwortliche, die das Design-System in ihrer Organisation umsetzen. - GRC-Berater, die Governance-Design-Projekte anbieten. - Interne Auditoren, die die Design-Entscheidungen des Governance-Systems validieren. **NOT for (when you should not take this certification):** - Praktiker ohne COBIT Foundation. Belegen Sie zuerst die Foundation. --- ## Cybersecurity Audit Certificate (ISACA) **URL:** https://cyberacademy.net/de/courses/cybersecurity-audit-certificate **Issuer:** ISACA **Level:** practitioner **Duration:** 2 days **Price:** Live €1450 Das ISACA-Zertifikat für Cybersecurity-Audits. Zweitägiger Kurs im Kohorten-Format, szenariobasiert, konzipiert als Brücke zwischen klassischem IS-Audit (CISA) und modernem Cyber-Defence-Betrieb. Empfehlenswert für Auditoren, die SOC-, IR- und Threat-Intelligence-Programme bewerten. **You will learn how to:** - Einen Cybersecurity-Audit planen und durchführen, der Monitoring, Incident Response und Threat Intelligence umfasst. - Cyber-Defence-Kontrollen anhand von Branchenframeworks bewerten (NIST CSF, ISO 27001, CIS Controls). - Einen SOC auditieren: Rollen, Runbooks, Telemetrie, Incident-Metriken. - Breach-Readiness-Übungen und Tabletop-Ergebnisse gegen das Playbook prüfen. **For:** - IS-Auditoren, die ihr Tätigkeitsfeld auf Cybersecurity-Assessments ausweiten. - Interne Auditteams, die Cyber in die Audit-Universe-Taxonomie integrieren. - Big-Four-Auditoren, die Cyber-Kontrollen im Rahmen umfassenderer Assurance-Engagements prüfen. **NOT for (when you should not take this certification):** - Operative SOC-Mitarbeitende. Für diese eignet sich CCOA besser. --- ## IT Audit Fundamentals (ISACA) **URL:** https://cyberacademy.net/de/courses/it-audit-fundamentals **Issuer:** ISACA **Level:** foundation **Duration:** 2 days **Price:** Live €1100 Das Einstiegszertifikat von ISACA im Bereich IT-Audit. Zweitägiges Kohortenprogramm mit den Schwerpunkten Auditplanung, Durchführung, Beweissicherung und Berichterstattung auf Basis des ISACA-Vokabulars. Eine solide Vorbereitung vor dem CISA. **You will learn how to:** - Einen Audit-Lebenszyklus auf IT-bezogene Kontrollen anwenden. - Prüfungsaufträge planen, Nachweise erheben und Feststellungen formulieren, die einer Überprüfung standhalten. - First-, Second- und Third-Line-Aktivitäten in einem typischen Unternehmen voneinander abgrenzen. - Das IT-Audit im übergeordneten Assurance-Programm verorten. **For:** - IT-Fachleute, die eine Laufbahn im Audit-Bereich anstreben. - GRC-Analysten zu Beginn ihrer Audit-Spezialisierung. - Berater, die sich auf den CISA vorbereiten und ein strukturiertes Aufwärmprogramm wünschen. **NOT for (when you should not take this certification):** - Fachleute, die bereits Auditprogramme betreiben. Steigen Sie direkt auf CISA um. --- ## IT Risk Fundamentals (ISACA) **URL:** https://cyberacademy.net/de/courses/it-risk-fundamentals **Issuer:** ISACA **Level:** foundation **Duration:** 2 days **Price:** Live €1100 Das ISACA-Einsteigerzertifikat im IT-Risikomanagement. Ein zweitägiger Kurs, der Risikoidentifikation, -bewertung, -behandlung und -überwachung anhand der ISACA-Terminologie einführt. Ein solider Einstieg vor CRISC. **You will learn how to:** - Einen Risikomanagement-Lebenszyklus auf IT-Risiken anwenden. - Ein Risikoregister aufbauen, das auf Geschäftsauswirkungen ausgerichtet ist, nicht nur auf technische Befunde. - Risikoidentifikation, -bewertung, -behandlung und -überwachung voneinander abgrenzen. - IT-Risiken im Kontext des übergeordneten unternehmensweiten Risikoprogramms einordnen. **For:** - IT-Fachleute, die neu im Risikomanagement sind. - GRC-Analysten am Beginn ihrer Spezialisierung im Risikobereich. - Auditoren, die sich auf CRISC vorbereiten und einen strukturierten Einstieg wünschen. **NOT for (when you should not take this certification):** - Fachleute, die bereits ein unternehmensweites Risikoprogramm betreiben. Steigen Sie direkt bei CRISC ein. --- ## ISO27001 - Foundation **URL:** https://cyberacademy.net/de/courses/iso27001-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Offizielles PECB-akkreditiertes ISO27001 - Foundation Zertifizierungstraining. Live-Online-Kurs mit erfahrenen Dozenten und Zertifizierung-oder-Geld-zurück-Garantie. Jetzt anmelden... --- ## AI Risk Manager **URL:** https://cyberacademy.net/de/courses/ai-risk-manager **Issuer:** PECB **Level:** risk-manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte AI Risk Manager Zertifizierung. Live-Online-Schulung mit Zertifizierungs- oder Rückgeldgarantie. --- ## Certified Artificial Intelligence Professional (CAIP) **URL:** https://cyberacademy.net/de/courses/certified-artificial-intelligence-professional-caip **Issuer:** PECB **Level:** expert **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte Certified Artificial Intelligence Professional (CAIP)-Zertifizierung. Live-Online-Training mit Bestehen-oder-Geld-zurück-Garantie. --- ## Certified CISO by PECB **URL:** https://cyberacademy.net/de/courses/certified-ciso-by-pecb **Issuer:** PECB **Level:** expert **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Offizielle, von PECB akkreditierte Zertifizierungsschulung zum Certified CISO by PECB. Live-Online-Kurs mit erfahrenen Dozenten und Zertifizierung-oder-Rückerstattung-Garantie. Jetzt anmelden... --- ## Certified Lead Crisis Manager **URL:** https://cyberacademy.net/de/courses/certified-lead-crisis-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte Certified Lead Crisis Manager Zertifizierung. Live-Online-Schulung mit Zertifizierungsgarantie oder Geld-zurück-Garantie. --- ## PECB CMMC Foundations **URL:** https://cyberacademy.net/de/courses/cmmc-foundations **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Offiziell PECB-akkreditiertes PECB CMMC Foundations Zertifizierungstraining. Live-Online-Kurs mit erfahrenen Dozenten und Zertifizierungsgarantie oder Rückerstattung. Jetzt anmelden... --- ## Cyber Threat Analyst **URL:** https://cyberacademy.net/de/courses/cyber-threat-analyst **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte Cyber Threat Analyst-Zertifizierung. Live-Online-Training mit Zertifizierungs- oder Rückgeldgarantie. --- ## Cybersecurity Foundation **URL:** https://cyberacademy.net/de/courses/cybersecurity-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 PECB-akkreditierte Cybersecurity Foundation Zertifizierung. Live-Online-Training mit Bestehen-oder-Geld-zurück-Garantie. --- ## DORA Foundation **URL:** https://cyberacademy.net/de/courses/dora-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 DORA Foundation für den Finanzsektor. IKT-Risikomanagement und Meldung von Vorfällen. PECB-akkreditiert. --- ## DORA Lead Manager **URL:** https://cyberacademy.net/de/courses/dora-lead-manager **Issuer:** PECB **Level:** manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Werden Sie zertifizierter DORA Lead Manager. Implementieren Sie digitale operative Resilienz für Finanzinstitute. PECB-akkreditierter Kurs inklusive Prüfung. --- ## EBIOS Risk Manager **URL:** https://cyberacademy.net/de/courses/ebios-risk-manager **Issuer:** PECB **Level:** risk-manager **Duration:** 3 days **Price:** Live €1699 · Self-paced €599 Offizielle EBIOS RM-Zertifizierungsschulung. Lernen Sie die ANSSI-Risikoanalysemethodik mit 5 Workshops. PECB-akkreditierter Kurs mit praktischen Übungen und Prüfung. --- ## GDPR - Certified Data Protection Officer **URL:** https://cyberacademy.net/de/courses/gdpr-certified-data-protection-officer **Issuer:** PECB **Level:** expert **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte GDPR - Certified Data Protection Officer Zertifizierung. Live-Online-Training mit Zertifizierungs- oder Rückgeldgarantie. --- ## GDPR Foundation **URL:** https://cyberacademy.net/de/courses/gdpr-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 PECB-akkreditierte GDPR Foundation Zertifizierung. Live-Online-Training mit Zertifizierungs- oder Rückgeldgarantie. --- ## ISO 22301 Foundation **URL:** https://cyberacademy.net/de/courses/iso-22301-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 PECB-akkreditierte ISO 22301 Foundation Zertifizierung. Live-Online-Training mit Zertifizierungs- oder Rückgeldgarantie. --- ## ISO 22301 Lead Auditor **URL:** https://cyberacademy.net/de/courses/iso-22301-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte ISO 22301 Lead Auditor Zertifizierung. Live-Online-Schulung mit Zertifiziert-oder-Geld-zurück-Garantie. --- ## ISO 22301 Lead Implementer **URL:** https://cyberacademy.net/de/courses/iso-22301-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte ISO 22301 Lead Implementer Zertifizierung. Live-Online-Training mit Zertifizierungs- oder Rückgeldgarantie. --- ## ISO 27005 Foundation **URL:** https://cyberacademy.net/de/courses/iso-27005-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Offizielle PECB-akkreditierte ISO 27005 Foundation Zertifizierungsschulung. Live-Online-Kurs mit erfahrenen Fachdozenten und Zertifizierung-oder-Rückerstattung-Garantie. Jetzt anmelden ... --- ## ISO 27005 Lead Risk Manager **URL:** https://cyberacademy.net/de/courses/iso-27005-lead-risk-manager **Issuer:** PECB **Level:** lead-risk-manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Offizielle PECB-akkreditierte ISO 27005 Lead Risk Manager Zertifizierungsschulung. Live-Online-Kurs mit erfahrenen Dozenten und Zertifizierungs- oder Rückgeldgarantie. ... --- ## ISO 27005 Risk Manager **URL:** https://cyberacademy.net/de/courses/iso-27005-risk-manager **Issuer:** PECB **Level:** risk-manager **Duration:** 3 days **Price:** Live €1699 · Self-paced €599 PECB-zertifizierte ISO 27005 Risk Manager Schulung. Meistern Sie Bewertung, Behandlung und Überwachung von Informationssicherheitsrisiken. Praxisnahe Methodik mit Prüfung inkl... --- ## ISO 27033 Lead Network Security Manager **URL:** https://cyberacademy.net/de/courses/iso-27033-lead-network-security-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte ISO 27033 Lead Network Security Manager Zertifizierung. Live-Online-Training mit Zertifizierungs- oder Rückgeldgarantie. --- ## ISO 27034 Lead Application Security Auditor **URL:** https://cyberacademy.net/de/courses/iso-27034-lead-application-security-auditor **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte ISO 27034 Lead Application Security Auditor Zertifizierung. Live-Online-Training mit Zertifizierungs- oder Rückgeldgarantie. --- ## ISO 27034 Lead Application Security Implementer **URL:** https://cyberacademy.net/de/courses/iso-27034-lead-application-security-implementer **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte ISO 27034 Lead Application Security Implementer Zertifizierung. Live-Online-Training mit Zertifizierungs- oder Rückgeld-Garantie. --- ## ISO 27035 Foundation **URL:** https://cyberacademy.net/de/courses/iso-27035-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Offizielle PECB-akkreditierte ISO 27035 Foundation Zertifizierungsschulung. Live-Online-Kurs mit erfahrenen Trainern und Zertifizierungsgarantie oder Geld-zurück. Jetzt anmelden ... --- ## ISO 27035 Lead Incident Manager **URL:** https://cyberacademy.net/de/courses/iso-27035-lead-incident-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte ISO 27035 Lead Incident Manager Zertifizierung. Live-Online-Training mit Zertifiziert-oder-Geld-zurück-Garantie. --- ## ISO 27701 Foundation **URL:** https://cyberacademy.net/de/courses/iso-27701-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 PECB-akkreditierte ISO 27701 Foundation Zertifizierung. Live-Online-Schulung mit Bestanden-oder-Geld-zurück-Garantie. --- ## ISO 27701 Lead Auditor **URL:** https://cyberacademy.net/de/courses/iso-27701-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte ISO 27701 Lead Auditor Zertifizierung. Live-Online-Training mit Bestehen-oder-Geld-zurück-Garantie. --- ## ISO 27701 Lead Implementer **URL:** https://cyberacademy.net/de/courses/iso-27701-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte ISO 27701 Lead Implementer Zertifizierung. Live-Online-Schulung mit Zertifizierungs- oder Rückgeldgarantie. --- ## ISO 31000 Foundation **URL:** https://cyberacademy.net/de/courses/iso-31000-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 PECB-akkreditierte ISO 31000 Foundation Zertifizierung. Live-Online-Training mit Zertifizierungs- oder Rückgeldgarantie. --- ## ISO 31000 Lead Risk Manager **URL:** https://cyberacademy.net/de/courses/iso-31000-lead-risk-manager **Issuer:** PECB **Level:** lead-risk-manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte ISO 31000 Lead Risk Manager Zertifizierung. Live-Online-Training mit Bestehen-oder-Geld-zurück-Garantie. --- ## ISO 31000 Risk Manager **URL:** https://cyberacademy.net/de/courses/iso-31000-risk-manager **Issuer:** PECB **Level:** risk-manager **Duration:** 3 days **Price:** Live €1699 · Self-paced €599 PECB-akkreditierte ISO 31000 Risk Manager Zertifizierung. Live-Online-Training mit Zertifiziert-oder-Geld-zurück-Garantie. --- ## ISO 42001 Foundation **URL:** https://cyberacademy.net/de/courses/iso-42001-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 PECB-akkreditierte ISO 42001 Foundation Zertifizierung. Live-Online-Training mit Zertifizierungs- oder Rückerstattungsgarantie. --- ## ISO 42001 Lead Auditor **URL:** https://cyberacademy.net/de/courses/iso-42001-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte ISO 42001 Lead Auditor Zertifizierung. Live-Online-Training mit Bestanden-oder-Geld-zurück-Garantie. --- ## ISO 42001 Lead Implementer **URL:** https://cyberacademy.net/de/courses/iso-42001-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte ISO 42001 Lead Implementer Zertifizierung. Live-Online-Training mit Bestanden-oder-Geld-zurück-Garantie. --- ## ISO 9001 Foundation **URL:** https://cyberacademy.net/de/courses/iso-9001-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 PECB-akkreditierte ISO 9001 Foundation Zertifizierung. Live-Online-Training mit Bestehen-oder-Geld-zurück-Garantie. --- ## ISO 9001 Lead Auditor **URL:** https://cyberacademy.net/de/courses/iso-9001-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte ISO 9001 Lead Auditor Zertifizierung. Live-Online-Training mit Zertifizierungs- oder Rückgeldgarantie. --- ## ISO 9001 Lead Implementer **URL:** https://cyberacademy.net/de/courses/iso-9001-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte ISO 9001 Lead Implementer Zertifizierung. Live-Online-Training mit Zertifizierungs- oder Rückgeldgarantie. --- ## ISO27001 - Lead Auditor **URL:** https://cyberacademy.net/de/courses/iso27001-lead-auditor **Issuer:** PECB **Level:** lead-auditor **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Offizielle PECB-akkreditierte ISO27001 - Lead Auditor Zertifizierungsschulung. Live-Online-Kurs mit erfahrenen Trainern und Zertifizierung-oder-Rückerstattung-Garantie. Jetzt anmelden... --- ## ISO27001 - Lead Implementer **URL:** https://cyberacademy.net/de/courses/iso27001-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Offizielle PECB-akkreditierte ISO27001 - Lead Implementer Zertifizierungsschulung. Live-Online-Kurs mit erfahrenen Trainern und Zertifizierungs-oder-Geld-zurück-Garantie. ... --- ## ISO27002 Foundation **URL:** https://cyberacademy.net/de/courses/iso27002-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 Offizielle PECB-akkreditierte ISO27002 Foundation Zertifizierungsschulung. Live-Online-Kurs mit erfahrenen Trainern und Zertifizierungs-oder-Rückerstattungs-Garantie. Jetzt einschreiben... --- ## ISO27002 Lead Manager **URL:** https://cyberacademy.net/de/courses/iso27002-lead-manager **Issuer:** PECB **Level:** manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 Offizielle PECB-akkreditierte ISO27002 Lead Manager Zertifizierungsschulung. Live-Online-Kurs mit erfahrenen Dozenten und Zertifizierungsgarantie oder Rückerstattung. Jetzt anmelden... --- ## ISO27002 Manager **URL:** https://cyberacademy.net/de/courses/iso27002-manager **Issuer:** PECB **Level:** manager **Duration:** 3 days **Price:** Live €1699 · Self-paced €599 Offizielle PECB-akkreditierte ISO27002 Manager Zertifizierungsschulung. Live-Online-Kurs mit erfahrenen Dozenten und Zertifizierungs- oder Rückgeldgarantie. Jetzt anmelden. --- ## Lead Cloud Security Manager **URL:** https://cyberacademy.net/de/courses/lead-cloud-security-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte Lead Cloud Security Manager Zertifizierung. Live-Online-Training mit Zertifizierungs- oder Rückgeldgarantie. --- ## Lead Cybersecurity Manager **URL:** https://cyberacademy.net/de/courses/lead-cybersecurity-manager **Issuer:** PECB **Level:** manager **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte Lead Cybersecurity Manager Zertifizierung. Live-Online-Training mit Zertifiziert-oder-Geld-zurück-Garantie. --- ## Lead Disaster Recovery Manager **URL:** https://cyberacademy.net/de/courses/lead-disaster-recovery-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte Lead Disaster Recovery Manager Zertifizierung. Live-Online-Training mit Zertifizierungs- oder Rückgeldgarantie. --- ## Lead Ethical Hacker **URL:** https://cyberacademy.net/de/courses/lead-ethical-hacker **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte Lead Ethical Hacker Zertifizierung. Live-Online-Training mit Zertifiziert-oder-Geld-zurück-Garantie. --- ## Lead Operational Resilience Manager **URL:** https://cyberacademy.net/de/courses/lead-operational-resilience-manager **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte Lead Operational Resilience Manager Zertifizierung. Live-Online-Training mit Zertifiziert-oder-Geld-zurück-Garantie. --- ## Lead SOC 2 Analyst **URL:** https://cyberacademy.net/de/courses/lead-soc-2-analyst **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte Lead SOC 2 Analyst Zertifizierung. Live-Online-Training mit Zertifizierungs- oder Rückerstattungsgarantie. --- ## NIS 2 Directive Foundation **URL:** https://cyberacademy.net/de/courses/nis-2-directive-foundation **Issuer:** PECB **Level:** foundation **Duration:** 2 days **Price:** Live €1099 · Self-paced €499 PECB-akkreditierte NIS 2 Directive Foundation Zertifizierung. Live-Online-Training mit Zertifiziert-oder-Geld-zurück-Garantie. --- ## NIS 2 Directive Lead Implementer **URL:** https://cyberacademy.net/de/courses/nis-2-directive-lead-implementer **Issuer:** PECB **Level:** lead-implementer **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte NIS 2 Directive Lead Implementer Zertifizierung. Live-Online-Training mit Zertifizierungs- oder Rückgeldgarantie. --- ## NIST Cybersecurity Consultant **URL:** https://cyberacademy.net/de/courses/nist-cybersecurity-consultant **Issuer:** PECB **Level:** lead **Duration:** 5 days **Price:** Live €2499 · Self-paced €899 PECB-akkreditierte NIST Cybersecurity Consultant Zertifizierung. Live-Online-Training mit Zertifizierungs- oder Rückgeld-Garantie. ---