ISMS-Ratgeber WiKi - Benutzerbeiträge [de]

Grundschutz++ Einführung und Aufbau

2026-04-05T09:00:54Z

Dirk: /* Glossar */

[[Datei:Teamwork-2198961.png|alternativtext=Zahnrad|rechts|240x240px]]{{#seo:
|title=Grundschutz++ Einführung und Anleitung
|keywords=ISMS, Wiki, BSI Grundschutz++, IT-Grundschutz, BSI-Standard 200-2, Bausteine, OSCAL, JSON, Informationssicherheit, Risikomanagement, Anforderungen
|description=Überblick über den neuen BSI Grundschutz++. Startseite zur Navigation durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.
}}{{SHORTDESC:Grundschutz++ Überblick und Anleitung}}''Dieser Artikel bietet einen schrittweisen Überblick über BSI '''Grundschutz++''' und navigiert durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.''

== Einführung in Grundschutz++ ==
'''Grundschutz++''' ist die 2026 vom BSI eingeführte Weiterentwicklung des IT-Grundschutz-Kompendiums. Es transformiert das bewährte Grundschutz-Konzept in ein vollständig digitales, maschinenlesbares Format mit JSON-basierten Bausteinen und OSCAL-kompatibler Struktur.<blockquote>
''Der aktuelle Stand von Grundschutz++ ist bisher nur sehr eingeschränkt praktisch anwendbar, da einige wesentliche Definitionen und Teile der Methodik noch fehlen. Dazu gehören beispielsweise die Nutzung von Kennzahlen, Blaupausen, Stufen, Schutzbedarf vs. Schutzniveau und die Modellierung.''

''Der Anforderungskatalog liegt zwar im OSCAL- und Excel-Format vor, ist ohne eine abgeschlossene und nachvollziehbare Methodik aber nicht sinnvoll anwendbar.''
</blockquote>
=== Wesentliche Neuerungen===
*'''OSCAL/JSON-basiertes Regelwerk''': Der IT-Grundschutz wird in ein maschinenlesbares '''JSON-Format''' überführt, das teilweise automatisierte Compliance-Prüfungen und Integrationen in bestehende IT-Systeme ermöglicht. Dies ersetzt die bisherigen textbasierten PDFs und Listen.
*'''Prozessorientierte Struktur''': Die neue Version ist modular und objektorientiert aufgebaut, um Redundanzen zu reduzieren und die Dokumentationslast zu verringern.
*'''Leistungskennzahlen''': Kennzahlen sollen die Informationssicherheit messbar und den Sicherheitsgewinn einzelner Anforderungen transparenter machen.
* '''Harmonisierung mit ISO 27001''': Die Anforderungen werden stärker mit internationalen Standards wie '''ISO 27001:2022''' abgestimmt, um Doppelzertifizierungen zu vereinfachen.
*'''Erweiterung um moderne Technologien''': Geplant sind auch spezifische Module für '''Cloud-Security, KI und IoT''', die aktuelle Bedrohungsszenarien abdecken.
===Ziele der Reform===
*'''Schlankere Prozesse''': Durch Automatisierung soll der administrative Aufwand sinken.
*'''Dynamische Anpassung''': JSON ermöglicht schnellere, ggf. automatisierte Updates bei neuen Cyberbedrohungen.
*'''Praxisorientierte Vereinfachung''': Der BSI will die Dokumentationslast reduzieren und den Fokus auf risikobasierte Ansätze legen, insbesondere für KMU.
*'''Priorisierung und Messbarkeit''': Durch eine stufenweise Priorisierung von Anforderungen und Leistungskennzahlen soll ein zielgerichteteres Vorgehen und die bessere Messbarkeit der Sicherheit gefördert werden.
Die Änderungen reagieren auf Kritik an der bisherigen Komplexität und sollen besonders KMU entlasten, während die ganzheitliche Sicherheitsmethodik (technisch, organisatorisch, personell) erhalten bleibt.

''Hinweis'': Details zur finalen Struktur werden schrittweise im Jahr 2026 veröffentlicht. Unternehmen sollten sich frühzeitig mit den geplanten Schnittstellen (z.B. für Security-Tools) vertraut machen.

Offizieller '''Starttermin''' für den Grundschutz++ war der '''1.1.2026'''. Danach ist allerdings eine längere Übergangsphase (bis 2029) geplant, in der beide Standards parallel genutzt werden können, so wie bei der letzten Modernisierung auch. Da jedoch zu erwarten ist, dass eine automatisierte Migration auch diesmal nicht oder nur eingeschränkt möglich sein wird, sollte speziell in größeren Verbünden rechtzeitig begonnen werden! Der jeweils aktuellen Grundschutz++ Katalog wird auf [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek GitHub] veröffentlicht.
=== Bedeutung von OSCAL im Grundschutz++ ===
Das zugrundeliegende Format für Grundschutz++ ist [[OSCAL]].

[[OSCAL]] ist ein '''Framework''' bzw. eine '''Datenmodellierungssprache''', die vom NIST speziell für Sicherheitsanforderungen und Compliance-Dokumentation entwickelt wurde. OSCAL definiert dabei nur ein festes Schema für Sicherheits- und Compliance-Daten und lässt das zugrundeliegende Datenformat (JSON, XML oder YAML) offen.

Das BSI hat sich beim Grundschutz++ für das Datenformat '''JSON''' entschieden.

Dies ermöglicht es mit entsprechenden Tools Sicherheitsanforderungen automatisiert einzulesen und zu bearbeiten. D.h.

* Anforderungen können (teil-)automatisiert von entsprechenden Tools bearbeitet und dokumentiert werden, sofern entsprechende Tools zur Verfügung stehen oder vom Anwender (ggf. Dienstleister) programmiert werden.
* Kataloge und Sicherheitskonzepte (SSPs) können zwischen ISMS-Tools herstellerunabhängig ausgetauscht werden (sofern Toolhersteller sich an den Standard halten und entsprechende Im- und Exportfonktionen in ihren Tools zur Verfügung stellen).

Das heißt aber nicht:

* Das Anwender, Sicherheitsmanager oder Sicherheitsbeauftragte OSCAL lernen müssen oder OSCAL Formate lesen können müssen. (Dafür gibt es Tools, die die Inhalte lesbar und bearbeitbar zur Verfügung stellen)
* Das alle Anforderungen automatisiert erfüllt und dokumentiert werden (viele Anforderungen sind nach wie vor organisatorische Anforderungen die nur von Menschen durch Erstellung und Beachtung entsprechenden Regelungen erfüllt werden können).
* Das überhaupt irgendwelche Anforderungen automatisiert erfüllt und dokumentiert werden (Hierzu müssten die Systeme an ein ISMS-Tool angebunden sein und diese über entsprechende Schnittstellen mit Informationen bedienen). Sowohl die Tools als auch die Schnittstellen werden absehbar nicht vom Himmel fallen.
===Satzschablonen===
Anforderungen werden im Grundschutz++ zukünftig mit Satzschablonen erstellt, die wie folgt aussehen:<blockquote><big>'''<span style="color:green">{Praktik} [für {Zielobjektkategorie}]</span> <span style="color:red">{MODALVERB}</span> <span style="color:blue"><Ergebnis></span> <span style="color:purple">{Handlungswort}</span>''' ''<span style="color:grey">(TAGs) (Hinweise)</span>''</big></blockquote>'''Praktik''': Ein Prozess im Rahmen des ISMS, eine konkrete Sicherheitsmaßnahme oder eine allgemeine Vorgehensweise zur Erreichung eines Sicherheitsziels (z.B. IT-Betrieb, Personal, Konfiguration) - Im weitesten Sinne vergleichbar mit den bisherigen Bausteinen. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/practices.csv Liste der gültigen Praktiken.]

'''Zielobjektkategorie''': Wie bisher, das Objekt oder die Entität, auf die sich die Sicherheitsanforderungen beziehen (z.B. Daten, Personen, Endgeräte, Hostsysteme). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/target_object_categories.csv Liste der Gültigen Zielobjektkategorien.]

'''Modalverb''': Gibt die Verbindlichkeit einer Anforderung an (MUSS, SOLLTE, KANN). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/modal_verbs.csv Liste der gültigen Modalverben.]

'''Ereignis''': Der sicherheitsrelevante Zustand oder Auslöser, der zu einer bestimmten Handlung führt - Entspricht in Verbindung mit dem Handlungswort dem wesentliche Inhalt der Anforderung.

'''Handlungswort''': Das Verb, das die konkrete Sicherheitsmaßnahme oder Art der Tätigkeit beschreibt (regeln, zuweisen, konfigurieren). Handlungsworte können auch zur besseren Filterung genutzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/action_words.csv Liste der gültigen Handlungsworte.]

Das ganze kann noch mit '''TAG'''s für eine bessere Gruppierung und mit einem '''Hinweis''' zu weiterführenden Informationen ergänzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/tags.csv Liste der gültigen TAGs.]

Die bisherigen Anforderungen des Kompendium werden aktuell in ihre Teilanforderungen zerlegt und jede Teilanforderung wird zukünftig eine eigene Anforderung. D.h. jedes Modalverb (SOLL, MUSS, KANN) der bisherigen Anforderungen stellt zukünftig i.d.R. eine eigene Anforderung dar. Die Gesamtanzahl der Anforderungen soll dabei durch die Vermeidung von Redundanzen dennoch sinken.

'''Beispiel'''

Die Anforderung:<blockquote>'''ISMS.1.A4 Benennung eines oder einer Informationssicherheitsbeauftragten (B) [Institutionsleitung]'''

Die Institutionsleitung MUSS einen oder eine ISB benennen. '''. . .'''

Die Institutionsleitung MUSS den oder die ISB mit angemessenen Ressourcen ausstatten.

Die Institutionsleitung MUSS dem oder der ISB die Möglichkeit einräumen, bei Bedarf direkt an sie selbst zu berichten. '''. . .'''</blockquote>Wird jetzt zu den Anforderungen:<blockquote>'''GOV.4.2''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">einer Person die Rolle ISB</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.2.3''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">für das ISMS erforderliche personelle, finanzielle und zeitliche Ressourcen</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.4.4''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">dem ISB das direkte und jederzeitige Vorspracherecht bei der Institutionsleitung</span> '''<span style="color:purple">ermöglichen</span>.'''</blockquote>Da dies übergreifende Anforderungen sind, ist hier kein spezifisches Zielobjekt benannt.

Einzelne Teilanforderungen können auch in anderen Praktiken beschrieben sein.
===Priorisierung===
Alle Anforderungen werden einer Prioritätsstufe zugeordnet, um die Umsetzung effizient zu gestalten:
*'''Stufe 0''': Zwingend (sofort) umzusetzende Anforderungen zur Sicherstellung der ISO-Kompatibilität (MUSS-Anforderungen).
Die Stufen 1-4 geben den Umsetzungsaufwand der Anforderungen wieder:
*'''Stufe 1''': Schnell und mit geringem Aufwand (~1 Tag) realisierbare Maßnahmen (QuickWin) / keine laufenden Aufwände.
*'''Stufe 2''': Mit eigenen Mitteln leicht umsetzbare Anforderung (~1 Woche) / geringe laufende Aufwände.
*'''Stufe 3''': Mit normalem Aufwand (mehrere Wochen) und ggf. externer Unterstützung umsetzbar / normale laufende Aufwände.
*'''Stufe 4''': Höherer Umsetzungsaufwand, häufig in längerfristigen Projekten mit externen Experten.
Die nächste Stufe sind optionale Anforderungen als Vorschläge bei erhöhtem Schutzbedarf.
*'''Stufe 5''': Umfassende/zusätzliche Anforderungen für höheren Schutzbedarf.
Diese Einstufung ermöglicht eine schnelle Einschätzung des Umsetzungsaufwands und hilft bei der effizienten Ressourcenplanung.
===Leistungskennzahlen===
Leistungskennzahlen dienen der '''Messung und Bewertung''' der Umsetzung von Sicherheitsanforderungen im Grundschutz++. Sie ermöglichen eine objektive Einschätzung des Sicherheitsniveaus und unterstützen die kontinuierliche Verbesserung. Wie diese Leistungskennzahlen genutzt werden sollen ist nach wie vor unklar und viele Anforderungen sind bislang noch nicht bewertet.
====Bewertungskriterien====
Jede Anforderung wird in Bezug auf die drei Schutzziele bewertet:
*'''Vertraulichkeit (C)'''
*'''Integrität (I)'''
*'''Verfügbarkeit (A)'''
Anforderungen erhalten Punktwerte in diesen Kategorien, die zur Bestimmung des Schutzgrades genutzt werden (z.B. C=6, I=2, A=0 ist eine Anforderung die im Wesentlichen die Vetraulichkeit stärkt, in Teilen die Intgrität aber nicht die Verfügbarkeit).

Die einzelen Kennzahlen werden je Schutzziel, Praktik und/oder Zielobjekt aufsummiert und ergeben so den Erfüllungsgrad.
====Schwellwerte und Erfüllungsgrad====
*'''Schwellwerte''' definieren das angestrebte Sicherheitsniveau basierend auf der Summe der Punktwerte aller umgesetzten Anforderungen je Schutzziel, Zielobjekt und Schutzstufe.
*'''Der Erfüllungsgrad''' zeigt, welche Anforderungen bereits umgesetzt wurden.
Die Leistungskennzahlen bieten damit eine fundierte Entscheidungsgrundlage für Organisationen, um ihren Sicherheitsstatus gezielt zu verbessern, wenn sie wie ursprünglich geplant eingeführt werden.
==Was bleibt erhalten?==
===Standards und Vorgehen===
Trotz eines deutlich anderen Formats und einer anderen Gruppierung der Anforderungen bleibt das grundsätzliche Vorgehen weitgehend gleich.

D.h. die Standards 200-1 bis 200-4 sollen erst einmal weiter Verwendung finden. Die bisher üblichen Arbeitsschritte:
#Festlegung des Geltungsbereichs
#Strukturanalyse
#Schutzbedarfsfeststellung
#Modellierung
#IT-Grundschutzcheck (GSC)
#Risikoanalyse
bleiben grundsätzlich erhalten, ändern sich jedoch in der praktischen Anwendung und Priorität (insbesondere in der '''Modellierung''' und den '''Grundschutzchecks'''). Parallel zur Einführung sollen die Standards weiter entwickelt werden.

'''MUSS'''-Anforderungen sind weiterhin '''verpflichtend''' für eine Zertifizierung, sollen aber deutlich rediziert werden.

'''SOLLTE'''-Anforderungen bleiben auch weiter '''grundsätzlich verpflichtend''', können aber ggf. mit angemessener Begründung oder Ersatzmaßnahmen wegdiskutiert werden.

Lediglich '''KANN'''-Anforderungen sind optional.
===Tool-Einsatz===
Auch der Einsatz von ISMS-Tools wird weiterhin Bestand haben. Alle größeren Tool-Hersteller arbeiten mit Hochdruck an der Integration von Grundschutz++ in ihre Tools. Hier wird es perspektivisch Erleichterungen durch einen leichteren Datenaustausch zwischen den Tools und mehr Automatisierungspotential geben.
==Gegenüberstellung Grundschutz Kompendium vs. Grundschutz++==
Das IT-Grundschutz-Kompendium 2023 und der zukünftige Grundschutz++ bieten unterschiedliche Konzepte für die Umsetzung von Informationssicherheit: Während das Kompendium auf feste Bausteine in thematisch gegliederten Schichten setzt, verwendet Grundschutz++ modulare, flexibel einsetzbare Praktiken.

Die folgende Tabelle stellt die wesentlichen Unterschiede und Gemeinsamkeiten zwischen beiden Ansätzen (nach aktuell verfügbaren Kenntnissen) gegenüber:
{| class="wikitable"
|+
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Fester verbindlicher Katalog''' von Anforderungen (PDF, Excel und XML), die je nach Reifegrad erfüllt werden müssen.
|Der '''variable''' und erweiterbare '''[[OSCAL]]'''-Datenbestand kann beliebig an die Bedürfnisse der Organisation angepasst werden. Zusätzliche Kataloge/Erweiterungen (C5, Datenschutz, KRITIS/NIS2) können je nach Verfügbarkeit ergänzt werden. Durch die Beseitigung vermeintlicher Redundanzen soll die Anzahl der Anforderungen erheblich reduziert werden (~10–20 % verbleibende Anforderungen gegenüber dem Grundschutz Kompendium).
|-
|
|Järliche '''Aktualisierung''' zum Stichtag '''1. Februar'''.
(bis 2023)
|Die '''Aktualisierung''' erfolgt '''fortlaufend''' nach Bedarf und Verfügbarkeit. Die Regelungen zur Relevanz für Zertifizierungen sind bislang noch nicht bekannt.
|-
|
|Das Kompendium ist (Stand 2023) in 10 '''Schichten''' mit insgesamt 111 '''Bausteine''' gegliedert, die statisch die jeweiligen Anforderungen enthalten.
|'''Praktiken''' und '''''Zielobjektkategorien''''' (Achtung abweichende Bedeutung in GS++) sind allgemeinere und wiederverwendbare, sicherheitsrelevante Verfahren oder Anforderungen. Sie können modular und situationsabhängig einzelnen Assets zugeordnet werden.
Die voraussichtlich ca. 20 Praktiken liegen irgendwo zwischen Schichten und Bausteinen. Sie sind prozessorientierter, adressieren eher Zielgruppen oder Handlungstypen und sind nicht mehr starr bestimmten Zielobjektkategorien zugeordnet. Zielobjektkategorien entsprechen zukünftig eher den Bausteinen im alten Grundschutz. Die Definitionen der Begriffe sind nach wie vor im Fluß!
|-
|
|'''Drei Stufen''' (Vorgehensweisen): Basis, Standard, erhöhter Schutzbedarf bilden den Reifegrad der Organisation ab.
|Es sind zukünftig '''sechs Stufen''' (0–5) geplant, die sich weitgehend am Umsetzungsaufwand der jeweiligen Anforderung orientieren: Je kleiner die Stufe, desto schneller bzw. leichter ist die Anforderung umsetzbar (Quick Win). Eine qualitative Bewertung des Reifegrads muss zukünftig anders erfolgen (z.B. über Leistungskennzahlen).
Das '''Sicherheitsniveau''' gibt zukünftig an, in welchem Maß die definierten Sicherheitsziele erreicht sind. Es ergibt sich aus der wirksamen Umsetzung organisatorischer, technischer und personeller Anforderungen.

Unterschieden werden:
*'''Normales Sicherheitsniveau''': entspricht dem Stand der Technik
*'''Erhöhtes Sicherheitsniveau''': für besonders schutzbedürftige Informationen oder Systeme
|-
|
|'''Zielobjekte''' als gruppierte Sammlung von gleichartigen Assets die zur späteren '''Modellierung''' (Zuordnung der Bausteine und Abhängigkeiten) genutzt werden.
|'''Zielobjekte''' werden auch in Zukunft eine ähnliche Funktion zur Gruppierung und '''Modellierung''' haben, entsprechend dabei aber eher den klassischen Bausteinen. Die konkreten Vorgaben zur Modellierung sind jedoch noch nicht detailliert genug. In der Modellierung werden die Praktiken nicht mehr statisch bestimmten Zielobjekttypen zugewiesen. Klassische Zielobjekte werden zukünftig als Assets oder Assetgruppen bezeichnet.
|-
|
|Modalverben '''MUSS''', '''SOLLTE''', '''KANN''' bestimmen die Verbindlichkeit von Anforderungen.
|Die Bedeutung der Modalverben ('''MUSS, SOLLTE, KANN''') bleibt unverändert. Ein Ziel von Grundschutz++ ist es jedoch, die Anzahl der Muss-Anforderungen auf das Nötigste zu reduzieren (unter 10 %). Dadurch soll der Grundschutz flexibler werden. Die Verbindlichkeit von Anforderungen, die über MUSS-Anforderungen hinausgehen, ist noch unklar.
|-
|
| -
|Neu sind '''Leistungskennzahlen''', die eine qualitative Bewertung der Anforderungen in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit darstellen. Sie sollen als Zahlenwert darstellbar sein und so den Reifegrad abbilden können. Bisher ist noch nicht bekannt, ob und wann diese eingeführt werden und wie die konkreten Regelungen aussehen werden.
|-
|
|Gültigkeit voraussichtlich bis 2029
|Gültig ab 1.1.2026. Zertifizierbar geplant ab 2027.
|}Teilweise werden Begrifflichkeiten neu (oder anders) definiert:
{| class="wikitable"
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Zielobjekt''' als gruppierte Sammlung von gleichartigen Assets als Grundlage für die spätere Modellierung
|'''Asset''' und gruppierte Assets. Die Gruppierung gleichartiger Assets kann weiterhin erfolgen es bleiben jedoch auch dann '''Assets'''. Der Begriff ''Zielobjekt'' wird hierfür nicht mehr genutzt.
|-
|
|'''Baustein''' als Sammlung von Anforderungen für bestimmte Zielobjekttypen.
|'''Zielobjektkategorien''' sind zukünftig das was bislang die ''Bausteine'' waren, bestimmte Typen von Assets für die spezische Anforderungen gelten. Die Assets werden den Zielobjektkategorien zugewisen und erhalten über diese ihre Anforderungen. Eine klare Definition der Begriffe ist noch im Fluß.
|-
|
|
|
|}
==Blaupausen==
Blaupausen sind vorgefertigte Musterlösungen (wie die bisherigen IT-Grundschutz-Profile), die als Vorlage (Referenzmodell) für die Erstellung und Umsetzung von branchenspezifischen oder organisationsspezifischen Sicherheitskonzepten dienen.
===Funktion der Blaupausen===
Solche Blaupausen erfassen typische Strukturen, Risiken, Anforderungen und Maßnahmen für bestimmte Anwendungsszenarien, etwa die Nutzung der E-Akte oder den sicheren Betrieb von 5G-Infrastrukturen. Sie ermöglichen es, ein ISMS deutlich effizienter und strukturierter aufzubauen, weil die grundlegenden Überlegungen (Schutzbedarfsermittlung, Zuordnung von Praktiken, Zielobjekten und Maßnahmen, etc.) bereits allgemein gültig vorformuliert sind und nur noch organisationsspezifisch angepasst werden müssen.
===Ziel und Nutzen===
*Blaupausen helfen, den Implementierungsaufwand für ISMS nach Grundschutz++ zu reduzieren.
*Sie fördern die Standardisierung und Wiederverwendbarkeit von Sicherheitskonzepten für ähnliche Organisationen oder Branchen.
*Besonders für kleinere Organisationen und typische Anwendungsfälle bieten sie einen niederschwelligen, strukturierten und praxiserprobten Einstieg in die Absicherung.
Damit sind Blaupausen im Grundschutz++ zentrale Instrumente, um bewährte Sicherheitsmethoden als Vorlage für den schnellen und einheitlichen Aufbau eines branchenspezifischen ISMS bereitzustellen.
===Umsetzung===
Umgesetzt werden Blaupausen technische als '''OSCAL-Profile''' mit zusätzlichen Erläuterungen in Textform, zukünftig sollen Blaupausen zu einem '''System Security Plan (SSP)''' weiter entwickelt werden.
== Grundlagen und Standards ==

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_1.html BSI-Standard 200-1: Anforderungen an ein ISMS].
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_2.html BSI-Standard 200-2: IT-Grundschutz Methodik] ( <- Wird neu erstellt )
** [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html Methodik zum Grundschutz++] (Aktuell in Erstellung, ersetzt zukünftig 200-2)
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_3.html BSI-Standard 200-3: Risikomanagement mit Grundschutz].
* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/BSI-Standards/BSI-Standard-200-4-Business-Continuity-Management/bsi-standard-200-4_Business_Continuity_Management_node.html BSI-Standard 200-4: Business Continuity Management].
* [[OSCAL|OSCAL (Open Security Controls Assessment Language)]].

== Schritt-für-Schritt-Methodik ==
Die Methodik von Grundschutz++ folgt einem fünfstufigen, PDCA-basierten Prozess mit Fokus auf '''Anforderungsmodellierung''' und, wenn möglich, maschinenlesbarer Verarbeitung. Hier eine Kurzbeschreibung des praktischen Vorgehens:

=== Schritt 1: Erhebung und Planung (PLAN - Governance/Compliance) ===
Du legst hier die '''strategische Basis''' für Dein ISMS, indem du den '''Kontext deiner Organisation''' analysierst, '''Compliance-Pflichten''' (z.B. DSGVO, BDSG, brachenspezifische Gesetze und Regelungen) und '''Erwartungen interessierter Parteien''' (Kunden, Geschäftspartner, Behörden, Mitarbeitende) feststellst. Anschließend entwickelst du eine '''Informationssicherheitsleitlinie''' mit SMART-Zielen und einer '''Strategie''', definierst den '''Geltungsbereich des ISMS''' (Scope: welche Prozesse, Standorte, Systeme), klassifizierst den '''Schutzbedarf''' kritischer Geschäftsprozesse ("normal" oder "hoch"), richtest Rollen wie den '''unabhängigen ISB''' ein und initiierst '''Risikomanagement''' sowie '''Dokumentationspflichten''' – alles '''freigegeben von der Leitung'''.

'''Unterschied zu BSI-Standard 200-2:''' Während 200-2 mit Bausteinen und Risikoanalyse startet, integriert Grundschutz++ Governance und Compliance früher und stärker in den PDCA-Planungszyklus, mit Fokus auf maschinenlesbare Strukturen und Organisationsleitungspflicht – weniger asset-zentriert, mehr prozess- und rolleorientiert ab Schritt 1.
# '''Kontextanalyse''' (intern/extern) durchführen
# '''Interessierte Parteien''' identifizieren und Anforderungen erfassen
# '''Geltungsbereich''' (Scope) durch Organisationsleitung festlegen und freigeben
# '''Geschäftsprozesse''' priorisieren → Schutzbedarf "normal" oder "hoch" einstufen
# '''Sicherheitsleitlinie''' erstellen (Ziele, Strategie, Verpflichtung Leitung)
# '''Sicherheitsorganisation''' etablieren (Rollen: ISB, Asset-Owner, etc.)
# '''Compliance-Management''' initialisieren (Rechts-/Vertragskatalog)

'''Ergebnis''': Organisatorischer Rahmen, Sicherheitsleitlinie, priorisierte Prozesse

'''Weiterführende Informationen:'''

* [[Informationssicherheitsleitlinie]]
* [[IS-Strategie]]
* [[Geschäftsprozesse]]

=== Schritt 2: Anforderungsanalyse (PLAN - Strukturmodellierung) ===
Starte mit der '''Abgrenzung des Informationsverbunds''' (technische, organisatorische Einheit innerhalb des Geltungsbereichs), '''erfasse Assets''' (z.B. Server, Daten, Rollen) pro priorisiertem '''Geschäftsprozess''' und ordne sie '''Zielobjektkategorien''' zu (z.B. „Anwendung“ mit Vererbung übergeordneter Kategorien). Modelliere dann '''Anforderungen''' aus '''GS++-Praktiken''' ('''ISMS-weit''' plus assetbezogen), ergänze bei Bedarf '''externe Pflichten''' oder risikobasierte Anforderungen (nach Risikobetrachtung), prüfe das '''Sicherheitsniveau''' ("normal SdT" oder "erhöht") und treffe '''Gestaltungsentscheidungen''' (z.B. Parameter wie Zuständigkeiten) – Ergebnis: '''individuelles Anforderungspaket'''.

'''Unterschied zu BSI-Standard 200-2:''' Statt starrer Baustein-Zuordnung und manueller Risikoanalyse nutzt Grundschutz++ eine modellbasierte, hierarchische Anforderungsableitung via Assets und Zielobjektkategorien (OSCAL-fähig, maschinenlesbar), mit automatisierbarer Vererbung und klarer Trennung von Standard- (SdT) und ergänzenden Anforderungen – skalierbarer und zyklischer als die lineare 200-2-Methodik.
# '''Informationsverbund''' definieren (techn./org. Abgrenzung)
# '''Assets''' für wichtigsten Geschäftsprozess erfassen
# '''Asset → Zielobjektkategorien''' mapping (Hierarchie + Vererbung)
# '''Anforderungspaket''' generieren:
#* ISMS-Praktiken (vollständig)
#* Zielobjekt-Anforderungen (Sicherheitsniveau: normal/erhöht)
#* Zielobjektlose Anforderungen prüfen
# '''Ergänzungen''': Externe Verpflichtungen, anforderungslose Assets
# '''Risikobetrachtung''' bei hohem Schutzbedarf oder Niveauerhöhung
# '''Parameter setzen''' (Zuständigkeiten, Werte)

'''Ergebnis''': Individuelles Anforderungspaket pro Informationsverbund

'''Weiterführende Informationen:'''

* [[Strukturanalyse]]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das OSCAL-basierte Grundschutz++ Kompendium auf Github.]

=== Schritt 3: Realisierung (DO - Umsetzung) ===
In diesem Schritt '''setzt''' du das '''Anforderungspaket''' aus Schritt 2 '''um''', indem du den '''Ist-Zustand''' aller Anforderungen bewertest ('''Umsetzungsstatus''' ermittelst), fehlende Umsetzungen '''priorisierst''' (nach Risiko und Aufwand), einen '''Umsetzungsplan''' mit Zuständigkeiten und Fristen erstellst, '''Ausnahmen''' dokumentierst und freigibst sowie den Fortschritt verfolgst – inklusive '''Compliance-Sicherstellung''' durch regelmäßige '''Checks'''.

'''Unterschied zu BSI-Standard 200-2:''' Während 200-2 Maßnahmen aus Bausteinen direkt umsetzt und manuell dokumentiert, strukturiert Grundschutz++ die Realisierung zentral über das modellierte Anforderungspaket mit automatisierbarer Priorisierung und Nachverfolgung, stärker in den PDCA-Do-Zyklus eingebettet und skalierbar für große Verbünde.
# '''Umsetzungsstatus''' aller Anforderungen prüfen (ja/nein)
# '''Nicht-umgesetzte MUSS/SOLLTE''' → Risikobetrachtung
# '''Umsetzungsplan''' erstellen:
#* Priorisierung (Risiko, Aufwand, Synergien)
#* Zuständigkeiten + Fristen zuweisen
# '''Freigabe''' durch Institutionsleitung
# '''Fortschritt tracken''' (Ticketsystem/Projektmanagement)
# '''Ausnahmen dokumentieren''' (Begründung + Leitungsfreigabe)

'''Ergebnis''': Umsetzungsplan + Status-Dokumentation

'''Weiterführende Informationen:'''

* [[LF-Grundschutzcheck|Leitfaden Grundschutzcheck]]
* [[RiLi-Freigabe]]
* [[RiLi-Ausnahmemanagement|Richtlinie zum Management von Ausnahmen und Abweichungen]]

=== Schritt 4: Überwachung (CHECK - Monitoring/Evaluation) ===
Hier überprüfst du die '''Wirksamkeit''' des ISMS durch '''Leistungsbewertung''' (z.B. KPIs), '''Compliance-Monitoring''', '''Audits''' (mit Bewertungsschemata und Berichten), '''Management-Reviews''' und Validierung der Anforderungen gegen aktuelle Bedrohungen – Tools wie Monitoring-Software unterstützen die kontinuierliche Erfassung.

'''Unterschied zu BSI-Standard 200-2:''' Grundschutz++ erweitert die Überwachung (PDCA-Check) um maschinenlesbare Audit-Modelle und Validierung des Anforderungspakets, statt isolierter Baustein-Checks; es integriert dynamische Monitoring-Tools und Managementbewertungen enger, für zyklische Anpassung statt einmaliger Prüfung.
# '''Leistungsbewertung''' (KPIs, Umsetzungsfortschritt, Vorfälle)
# '''Compliance-Überwachung''' (gesetzlich/vertraglich)
# '''Auditprogramm''' risikobasiert durchführen
# '''Managementbewertung''' → Managementbericht erstellen
# '''Monitoring-Tools''' einsetzen (SIEM, Vulnerability Scanner)
# '''Anforderungspaket validieren''' (Aktualität prüfen)

'''Ergebnis''': Auditberichte, Managementbericht

'''Weiterführende Informationen:'''

* [[Reifegradmodell]]
* [[KPIs|Key Performance Indicators (KPIs)]]
* [[Managementbericht|Erstellen eines Managementberichts]]

=== Schritt 5: Kontinuierliche Verbesserung (ACT - Verbesserung) ===
Du behandelst hier deine '''Erkenntnisse''' aus Schritt 4, indem du Nicht-Konformitäten '''analysierst''', '''Verbesserungspotenziale''' '''identifizierst''', Korrektur- und Verbesserungspläne erstellst, deren '''Wirksamkeit prüfst''' und '''Compliance-Verstöße behebst''' – so bleibt das ISMS dynamisch und anpassbar an neue Risiken.

'''Unterschied zu BSI-Standard 200-2:''' Im Gegensatz zur reaktiven 200-2-Verbesserung (nach Risikoanalyse) schließt Grundschutz++ den PDCA-Act-Zyklus modellbasiert ab, mit systematischer Integration von Audit-Ergebnissen ins Anforderungspaket und automatisierbarer Wirksamkeitsprüfung – prozessorientierter und weniger manuell.
# '''Nicht-Konformitäten''' analysieren
# '''Verbesserungspotenziale''' identifizieren
# '''Korrektur-/Verbesserungsplan''' → in Umsetzungsplan integrieren
# '''Wirksamkeit prüfen''' nach Umsetzung
# '''Sicherheitsniveau''' bewerten (Trendanalyse)
# '''Compliance-Verstöße''' behandeln

'''Ergebnis''': Aktualisiertes Anforderungspaket → neuer PDCA-Zyklus

'''Weiterführende Informationen:'''

*

=== Praktische Hinweise ===
* '''Tool-gestützt''': JSON/OSCAL-Bausteine, Zur Nutzung sind ISMS-Tools empfohlen.
* '''Iteration''': Wichtigster Geschäftsprozess zuerst, dann schrittweise erweitern
* '''Risikobetrachtung''': Bei Sicherheitsniveau "hoch" oder Nicht-Umsetzung
* '''Dokumentation''': bevorzugt Maschinenlesbar (OSCAL) für besseren Austausch

'''Zyklusdauer''': Jährlich oder ereignisgesteuert (Änderungen, Vorfälle, Audits)

== Migration bestehender Sicherheitskonzepte ==
...

'''Weiterführende Informationen:'''

[[Grundschutz++ Migration]]

== Offenen Punkte und Kritiken ==

=== Zu viele Beteiligte, unklare Zuständigkeiten ===
Die Weiterentwicklung des Grundschutzes wird inzwischen nicht mehr ausschließlich vom Grundschutz-Referat des BSI verantwortet. Mit dem Einstieg des Referats „Stand der Technik“ und der verstärkten Einbindung der „Community“ sind die Zuständigkeiten und Verantwortlichkeiten unklarer geworden. In Präsentationen und Veröffentlichungen werden die Rollen und Aufgaben der verschiedenen Beteiligten unterschiedlich dargestellt. Es fehlt eine klare, kommunizierte Schnittstelle, wer für welche Aspekte der Entwicklung, Pflege und Kommunikation des neuen Standards verantwortlich ist. Das erschwert für Anwendende die Orientierung und die Planung der eigenen Umsetzungsstrategie.

=== Unklare Umsetzung einiger Ziele ===
Einige der im Grundschutz++ adressierten Ziele und Neuerungen sind nach wie vor nicht ausreichend konkretisiert. Besonders die Einführung von Leistungskennzahlen und die Priorisierung der Anforderungen (Stufen) werfen noch viele Fragen auf. Die konkrete Bedeutung, Messung und praktische Umsetzung dieser Leistungskennzahlen werden von verschiedenen BSI-Vertretern unterschiedlich dargestellt. Auch die Stufenmodelle werden teils als Priorisierung, als Entwicklungsstufen oder als reiner Umsetzungaufwand der Anforderungen definiert und sind in ihrer praktischen Anwendung noch nicht abschließend geklärt. Das führt zu Unsicherheiten, wie diese neuen Instrumente im einem ISMS umgesetzt und nachgewiesen werden sollen.

=== Geringer Mehrwert im Vergleich zu ISO 27001 ===
Die Anforderungen im Grundschutz++ werden zunehmend an die Formulierungen und Strukturen der ISO 27001 angeglichen. Während der klassische IT-Grundschutz durch seine konkreten, praxisnahen Maßnahmen einen klaren Mehrwert gegenüber der eher abstrakten ISO 27001 bot, verliert er durch die Harmonisierung mit internationalen Standards zunehmend diesen Vorteil. Die Anforderungen werden stärker abstrakt modularisiert formuliert, wodurch der spezifische Bezug zu typischen Umsetzungsbeispielen und die Detailtiefe abnehmen. Für viele Organisationen wird sich daher die Frage stellen, warum sie den immer noch aufwändigeren Weg über den Grundschutz wählen sollten, wenn sie mit ähnlichem oder geringeren Aufwand direkt eine ISO 27001-Zertifizierung anstreben können.

=== Zu ambitionierter Zeitplan ===
Der Grundschutz++ sollte ab dem 1.1.2026 grundsätzlich gültig und anwedbar sein, wobei eine Übergangsphase bis 2029 vorgesehen war. Bisher ist nur ein erster Entwurf veröffentlicht. Angesichts der Vielzahl an noch offenen Fragen, der fehlenden Migrationsstrategie und der Komplexität der Änderungen erscheint der Zeitplan sehr ambitioniert. Ausarbeitung und Dokumentation liegen bisher nur als Entwurf vor. Eine Pilotierung und Einführung 2026 und eine Übergangsphase bis 2029 ist vorgesehen. Die Gefahr besteht, dass größere Organisationen unter Zeitdruck unzureichend vorbereitet in die neue Methodik wechseln und mit variablen Definitionen und Zielen arbeiten müssen, was die Akzeptanz und Qualität der Umsetzung gefährdet.

=== Zunehmende (Sicherheits-)Lücke zwischen Grundschutz und Grundschutz++ ===
Mit der Entscheidung des BSI, den bisherigen IT-Grundschutz (Edition 2023) nicht mehr weiterzuentwickeln und stattdessen auf das neue Grundschutz++-Modell zu setzen, entsteht eine wachsende Lücke in der Informationssicherheit. Diese Übergangsphase bis 2029 ist sicherheitstechnisch kritisch, da sich die Bedrohungslage in der IT nicht an Entwicklungszyklen von Sicherheitsstandards orientiert. Neue Angriffsvektoren, insbesondere durch den zunehmenden Einsatz von KI in der Cyberkriminalität (z.B. KI-gestützte Malware, Deepfakes, automatisierte Phishing-Kampagnen), entstehen kontinuierlich und erfordern zeitnahe, wirksame Gegenmaßnahmen. Der bisherige Grundschutz bildet diese aktuellen Bedrohungen und technologische Entwicklungen jedoch nicht mehr ab, während die spezifischen Module und Maßnahmen im Grundschutz++ noch nicht produktiv verfügbar oder praxistauglich sind.

=== Fehlende Migration vom Grundschutz-Kompendium zu Grundschutz++ ===
Aktuell existiert weder ein konkreter Plan noch ein Konzept für eine (teil-)automatisierte Migration bestehender Sicherheitskonzepte aus dem bisherigen Grundschutz-Kompendium in das neue Grundschutz++-Modell. Die Umstellung auf ein maschinenlesbares JSON/OSCAL-Format und die objektorientierte, prozessorientierte Struktur bedeuten einen fundamentalen Bruch mit bisherigen Strukturen. Die Unterschiede zwischen Grundschutz-Kompendium und Grundschutz++ sind gravierender als beim letzten Wechsel von den Grundschutz-Katalogen zum Kompendium, bei dem bereits alle Ansätze für eine automatisierte Migration weitgehend gescheitert sind. Auch diesmal ist absehbar, dass Organisationen ihre bestehenden Dokumentationen und Umsetzungen weitgehend manuell neu abbilden müssen, was insbesondere für größere Verbünde einen erheblichen Zusatzaufwand bedeutet. Es gibt zwar Ansätze dies mittels KI zu lösen, was aber sicher nicht für jede Organisation praktikabel sein wird.

=== Überholte Satzschablonen ===
Satzschablonen waren vor OSCAL ein erster Versuch, Anforderungen durch eine feste Syntax maschinenlesbar vorzubereiten. OSCAL macht sie jedoch überflüssig, da Praktiken und Zielobjektkategorien flexibel in Metadaten (props, groups, links) abgebildet und gefiltert werden können. So lassen sich Anforderungstexte natürlich formulieren. Das verbessert die Lesbarkeit für Mitarbeitende und Tools gleichermaßen. GS++ verwendet dennoch weiterhin diese sperrige Satzschablonen-Syntax für Anforderungen, was umfangreiche Erläuterungstexte zu den Anforderungen erfordert.

== Fazit ==
Ein abschließendes Bild zum Grundschutz++ lässt sich aktuell noch nicht zeichnen – viele Details sind noch in der Entwicklung.

Die grundlegende Modernisierung des IT-Grundschutzes durch das Grundschutz++-Projekt ist zwar fachlich und technologisch nachvollziehbar und adressiert viele Schwächen des bisherigen Systems. Die Umsetzung ist jedoch nach jetzigem Entwicklungsstand mit erheblichen Risiken und Unsicherheiten verbunden. Ohne klare Migrationspfade, eindeutige Zuständigkeiten und praxistaugliche Konkretisierungen der neuen Instrumente besteht die Gefahr, dass die Akzeptanz des Grundschutzes sinkt und Organisationen sich vermehrt alternativen Standards wie der ISO 27001 zuwenden. Ein realistischer Zeitplan und ein echter Mehrwert des neuen Standards sind daher essenziell für den Erfolg der Reform.

Der Artikel wird fortlaufend aktualisiert, sobald neue Informationen vom BSI veröffentlicht oder freigegeben werden.
===Ausblick und ToDos aus Anwendersicht===
Stichtag für die Einführung von Grundschutz++ war der '''1.1.2026'''. Das Datum wurde vom BSI in offiziellen Ankündigungen, Präsentationen und Fachveranstaltungen als verbindlicher Startpunkt kommuniziert. Ab diesem Zeitpunkt sollte das neue, digitale und prozessorientierte Regelwerk den bisherigen IT-Grundschutz ablösen. Bisher fehlt es jedoch an vielen Stellen an klaren Definitionen und konkreten Vorgaben zur Methodik.

Auch wenn abzuwarten bleibt, wann praxistaugliche Methoden verfügbar sind und wie lange die Übergangsfristen für die Umstellung sein werden (aktuelle Planung bis 2029). Abzusehen ist jedoch, dass der Aufwand und der Zeitdruck, insbesondere für größere und zertifizierte Verbünde, erheblich sein werden. Auch wenn es aktuell noch keine konkreten Beschreibungen zur Methodik und Modellierung gibt, können und sollten sich Anwender bereits jetzt vorbereiten. Dazu können die folgenden Maßnahmen dienen:
*Laufende Information über den aktuellen Stand (Internetseiten des BSI, Vorträge und Veröffentlichungen).
*Konsolidierung der bestehenden Verbünde (Reduzierung der Komplexität, konsistente Dokumentation der Gruppierung und Modellierung).
**Ein guter Tip ist es, in aktuellen GSC jede Teilanforderung (jedes Modalverb wie MUSS oder SOLLTE) in der Umsetzung einzeln zu dokumentieren, da diese zukünftig eigenständige Anforderungen darstellen und so eine Übernahme leichter werden könnte.
*Kontakt zu Toolherstellern aufnehmen und eine zügige Umsetzung in den verwendeten ISMS-Tools einfordern.
*Frühzeitige Planung der Bereitstellung entsprechender personeller Ressourcen für die Umstellung auf Grundschutz++ ab Mitte 2026.
*Gegebenenfalls frühzeitige Reservierung externer (personeller) Ressourcen zur Unterstützung.
*Es muss eine klare interne Kommunikation über die bevorstehenden, durch die Umstellung bedingten erhöhten Aufwände (Schulungen, neue (Erst-)GSCs und Anpassung der Dokumentation) geben, damit Mitarbeitende und Verantwortliche wissen, was auf sie zukommt.

== Weiterführende Ressourcen ==
*[https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html BSI IT-Grundschutz]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html BSI Leitfaden zur Grundschutz++-Methodik (1.4.2026)]
*[https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/Grundschutz/1GS_Tag_2025/Aktuelle_Entwicklungen_Ausblick_IT-GS.pdf Aktuelle Entwicklungen und Ausblick zum IT-Grundschutz - 1. Grundschutztag 2025]
*[https://www.youtube.com/watch?v=_AeWJ_Z8S-4 Keynote: Fortentwicklung des IT-Grundschutzes zu IT-Grundschutz++ (verinice.XP 2025)]
*[https://www.youtube.com/watch?v=fBXuhELODGA Vortrag: "Keynote und Vision Grundschutz++" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.youtube.com/watch?v=PxOjkV6oUwU Vortrag "Grundschutz++ Methodik und Einstieg ins BCM" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.bsi.bund.de/dok/it-sa Am Mittwoch, 08.10.2025 werden auf der it-sa die von den Arbeitsgruppen aus der Community erarbeiteten Ergebnisse präsentiert.]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]
*[[Grundschutz++ Migration|Migrationsstrategie für den Umstieg von BSI IT-Grundschutz auf Grundschutz++]]

[[Kategorie:Artikel]]
[[Kategorie:Grundschutz]]
[[Kategorie:++]]

Grundschutz++ Einführung und Aufbau

2026-04-05T08:50:35Z

Dirk:

[[Datei:Teamwork-2198961.png|alternativtext=Zahnrad|rechts|240x240px]]{{#seo:
|title=Grundschutz++ Einführung und Anleitung
|keywords=ISMS, Wiki, BSI Grundschutz++, IT-Grundschutz, BSI-Standard 200-2, Bausteine, OSCAL, JSON, Informationssicherheit, Risikomanagement, Anforderungen
|description=Überblick über den neuen BSI Grundschutz++. Startseite zur Navigation durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.
}}{{SHORTDESC:Grundschutz++ Überblick und Anleitung}}''Dieser Artikel bietet einen schrittweisen Überblick über BSI '''Grundschutz++''' und navigiert durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.''

== Einführung in Grundschutz++ ==
'''Grundschutz++''' ist die 2026 vom BSI eingeführte Weiterentwicklung des IT-Grundschutz-Kompendiums. Es transformiert das bewährte Grundschutz-Konzept in ein vollständig digitales, maschinenlesbares Format mit JSON-basierten Bausteinen und OSCAL-kompatibler Struktur.<blockquote>
''Der aktuelle Stand von Grundschutz++ ist bisher nur sehr eingeschränkt praktisch anwendbar, da einige wesentliche Definitionen und Teile der Methodik noch fehlen. Dazu gehören beispielsweise die Nutzung von Kennzahlen, Blaupausen, Stufen, Schutzbedarf vs. Schutzniveau und die Modellierung.''

''Der Anforderungskatalog liegt zwar im OSCAL- und Excel-Format vor, ist ohne eine abgeschlossene und nachvollziehbare Methodik aber nicht sinnvoll anwendbar.''
</blockquote>
=== Wesentliche Neuerungen===
*'''OSCAL/JSON-basiertes Regelwerk''': Der IT-Grundschutz wird in ein maschinenlesbares '''JSON-Format''' überführt, das teilweise automatisierte Compliance-Prüfungen und Integrationen in bestehende IT-Systeme ermöglicht. Dies ersetzt die bisherigen textbasierten PDFs und Listen.
*'''Prozessorientierte Struktur''': Die neue Version ist modular und objektorientiert aufgebaut, um Redundanzen zu reduzieren und die Dokumentationslast zu verringern.
*'''Leistungskennzahlen''': Kennzahlen sollen die Informationssicherheit messbar und den Sicherheitsgewinn einzelner Anforderungen transparenter machen.
* '''Harmonisierung mit ISO 27001''': Die Anforderungen werden stärker mit internationalen Standards wie '''ISO 27001:2022''' abgestimmt, um Doppelzertifizierungen zu vereinfachen.
*'''Erweiterung um moderne Technologien''': Geplant sind auch spezifische Module für '''Cloud-Security, KI und IoT''', die aktuelle Bedrohungsszenarien abdecken.
===Ziele der Reform===
*'''Schlankere Prozesse''': Durch Automatisierung soll der administrative Aufwand sinken.
*'''Dynamische Anpassung''': JSON ermöglicht schnellere, ggf. automatisierte Updates bei neuen Cyberbedrohungen.
*'''Praxisorientierte Vereinfachung''': Der BSI will die Dokumentationslast reduzieren und den Fokus auf risikobasierte Ansätze legen, insbesondere für KMU.
*'''Priorisierung und Messbarkeit''': Durch eine stufenweise Priorisierung von Anforderungen und Leistungskennzahlen soll ein zielgerichteteres Vorgehen und die bessere Messbarkeit der Sicherheit gefördert werden.
Die Änderungen reagieren auf Kritik an der bisherigen Komplexität und sollen besonders KMU entlasten, während die ganzheitliche Sicherheitsmethodik (technisch, organisatorisch, personell) erhalten bleibt.

''Hinweis'': Details zur finalen Struktur werden schrittweise im Jahr 2026 veröffentlicht. Unternehmen sollten sich frühzeitig mit den geplanten Schnittstellen (z.B. für Security-Tools) vertraut machen.

Offizieller '''Starttermin''' für den Grundschutz++ war der '''1.1.2026'''. Danach ist allerdings eine längere Übergangsphase (bis 2029) geplant, in der beide Standards parallel genutzt werden können, so wie bei der letzten Modernisierung auch. Da jedoch zu erwarten ist, dass eine automatisierte Migration auch diesmal nicht oder nur eingeschränkt möglich sein wird, sollte speziell in größeren Verbünden rechtzeitig begonnen werden! Der jeweils aktuellen Grundschutz++ Katalog wird auf [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek GitHub] veröffentlicht.
=== Bedeutung von OSCAL im Grundschutz++ ===
Das zugrundeliegende Format für Grundschutz++ ist [[OSCAL]].

[[OSCAL]] ist ein '''Framework''' bzw. eine '''Datenmodellierungssprache''', die vom NIST speziell für Sicherheitsanforderungen und Compliance-Dokumentation entwickelt wurde. OSCAL definiert dabei nur ein festes Schema für Sicherheits- und Compliance-Daten und lässt das zugrundeliegende Datenformat (JSON, XML oder YAML) offen.

Das BSI hat sich beim Grundschutz++ für das Datenformat '''JSON''' entschieden.

Dies ermöglicht es mit entsprechenden Tools Sicherheitsanforderungen automatisiert einzulesen und zu bearbeiten. D.h.

* Anforderungen können (teil-)automatisiert von entsprechenden Tools bearbeitet und dokumentiert werden, sofern entsprechende Tools zur Verfügung stehen oder vom Anwender (ggf. Dienstleister) programmiert werden.
* Kataloge und Sicherheitskonzepte (SSPs) können zwischen ISMS-Tools herstellerunabhängig ausgetauscht werden (sofern Toolhersteller sich an den Standard halten und entsprechende Im- und Exportfonktionen in ihren Tools zur Verfügung stellen).

Das heißt aber nicht:

* Das Anwender, Sicherheitsmanager oder Sicherheitsbeauftragte OSCAL lernen müssen oder OSCAL Formate lesen können müssen. (Dafür gibt es Tools, die die Inhalte lesbar und bearbeitbar zur Verfügung stellen)
* Das alle Anforderungen automatisiert erfüllt und dokumentiert werden (viele Anforderungen sind nach wie vor organisatorische Anforderungen die nur von Menschen durch Erstellung und Beachtung entsprechenden Regelungen erfüllt werden können).
* Das überhaupt irgendwelche Anforderungen automatisiert erfüllt und dokumentiert werden (Hierzu müssten die Systeme an ein ISMS-Tool angebunden sein und diese über entsprechende Schnittstellen mit Informationen bedienen). Sowohl die Tools als auch die Schnittstellen werden absehbar nicht vom Himmel fallen.
===Satzschablonen===
Anforderungen werden im Grundschutz++ zukünftig mit Satzschablonen erstellt, die wie folgt aussehen:<blockquote><big>'''<span style="color:green">{Praktik} [für {Zielobjektkategorie}]</span> <span style="color:red">{MODALVERB}</span> <span style="color:blue"><Ergebnis></span> <span style="color:purple">{Handlungswort}</span>''' ''<span style="color:grey">(TAGs) (Hinweise)</span>''</big></blockquote>'''Praktik''': Ein Prozess im Rahmen des ISMS, eine konkrete Sicherheitsmaßnahme oder eine allgemeine Vorgehensweise zur Erreichung eines Sicherheitsziels (z.B. IT-Betrieb, Personal, Konfiguration) - Im weitesten Sinne vergleichbar mit den bisherigen Bausteinen. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/practices.csv Liste der gültigen Praktiken.]

'''Zielobjektkategorie''': Wie bisher, das Objekt oder die Entität, auf die sich die Sicherheitsanforderungen beziehen (z.B. Daten, Personen, Endgeräte, Hostsysteme). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/target_object_categories.csv Liste der Gültigen Zielobjektkategorien.]

'''Modalverb''': Gibt die Verbindlichkeit einer Anforderung an (MUSS, SOLLTE, KANN). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/modal_verbs.csv Liste der gültigen Modalverben.]

'''Ereignis''': Der sicherheitsrelevante Zustand oder Auslöser, der zu einer bestimmten Handlung führt - Entspricht in Verbindung mit dem Handlungswort dem wesentliche Inhalt der Anforderung.

'''Handlungswort''': Das Verb, das die konkrete Sicherheitsmaßnahme oder Art der Tätigkeit beschreibt (regeln, zuweisen, konfigurieren). Handlungsworte können auch zur besseren Filterung genutzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/action_words.csv Liste der gültigen Handlungsworte.]

Das ganze kann noch mit '''TAG'''s für eine bessere Gruppierung und mit einem '''Hinweis''' zu weiterführenden Informationen ergänzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/tags.csv Liste der gültigen TAGs.]

Die bisherigen Anforderungen des Kompendium werden aktuell in ihre Teilanforderungen zerlegt und jede Teilanforderung wird zukünftig eine eigene Anforderung. D.h. jedes Modalverb (SOLL, MUSS, KANN) der bisherigen Anforderungen stellt zukünftig i.d.R. eine eigene Anforderung dar. Die Gesamtanzahl der Anforderungen soll dabei durch die Vermeidung von Redundanzen dennoch sinken.

'''Beispiel'''

Die Anforderung:<blockquote>'''ISMS.1.A4 Benennung eines oder einer Informationssicherheitsbeauftragten (B) [Institutionsleitung]'''

Die Institutionsleitung MUSS einen oder eine ISB benennen. '''. . .'''

Die Institutionsleitung MUSS den oder die ISB mit angemessenen Ressourcen ausstatten.

Die Institutionsleitung MUSS dem oder der ISB die Möglichkeit einräumen, bei Bedarf direkt an sie selbst zu berichten. '''. . .'''</blockquote>Wird jetzt zu den Anforderungen:<blockquote>'''GOV.4.2''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">einer Person die Rolle ISB</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.2.3''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">für das ISMS erforderliche personelle, finanzielle und zeitliche Ressourcen</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.4.4''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">dem ISB das direkte und jederzeitige Vorspracherecht bei der Institutionsleitung</span> '''<span style="color:purple">ermöglichen</span>.'''</blockquote>Da dies übergreifende Anforderungen sind, ist hier kein spezifisches Zielobjekt benannt.

Einzelne Teilanforderungen können auch in anderen Praktiken beschrieben sein.
===Priorisierung===
Alle Anforderungen werden einer Prioritätsstufe zugeordnet, um die Umsetzung effizient zu gestalten:
*'''Stufe 0''': Zwingend (sofort) umzusetzende Anforderungen zur Sicherstellung der ISO-Kompatibilität (MUSS-Anforderungen).
Die Stufen 1-4 geben den Umsetzungsaufwand der Anforderungen wieder:
*'''Stufe 1''': Schnell und mit geringem Aufwand (~1 Tag) realisierbare Maßnahmen (QuickWin) / keine laufenden Aufwände.
*'''Stufe 2''': Mit eigenen Mitteln leicht umsetzbare Anforderung (~1 Woche) / geringe laufende Aufwände.
*'''Stufe 3''': Mit normalem Aufwand (mehrere Wochen) und ggf. externer Unterstützung umsetzbar / normale laufende Aufwände.
*'''Stufe 4''': Höherer Umsetzungsaufwand, häufig in längerfristigen Projekten mit externen Experten.
Die nächste Stufe sind optionale Anforderungen als Vorschläge bei erhöhtem Schutzbedarf.
*'''Stufe 5''': Umfassende/zusätzliche Anforderungen für höheren Schutzbedarf.
Diese Einstufung ermöglicht eine schnelle Einschätzung des Umsetzungsaufwands und hilft bei der effizienten Ressourcenplanung.
===Leistungskennzahlen===
Leistungskennzahlen dienen der '''Messung und Bewertung''' der Umsetzung von Sicherheitsanforderungen im Grundschutz++. Sie ermöglichen eine objektive Einschätzung des Sicherheitsniveaus und unterstützen die kontinuierliche Verbesserung. Wie diese Leistungskennzahlen genutzt werden sollen ist nach wie vor unklar und viele Anforderungen sind bislang noch nicht bewertet.
====Bewertungskriterien====
Jede Anforderung wird in Bezug auf die drei Schutzziele bewertet:
*'''Vertraulichkeit (C)'''
*'''Integrität (I)'''
*'''Verfügbarkeit (A)'''
Anforderungen erhalten Punktwerte in diesen Kategorien, die zur Bestimmung des Schutzgrades genutzt werden (z.B. C=6, I=2, A=0 ist eine Anforderung die im Wesentlichen die Vetraulichkeit stärkt, in Teilen die Intgrität aber nicht die Verfügbarkeit).

Die einzelen Kennzahlen werden je Schutzziel, Praktik und/oder Zielobjekt aufsummiert und ergeben so den Erfüllungsgrad.
====Schwellwerte und Erfüllungsgrad====
*'''Schwellwerte''' definieren das angestrebte Sicherheitsniveau basierend auf der Summe der Punktwerte aller umgesetzten Anforderungen je Schutzziel, Zielobjekt und Schutzstufe.
*'''Der Erfüllungsgrad''' zeigt, welche Anforderungen bereits umgesetzt wurden.
Die Leistungskennzahlen bieten damit eine fundierte Entscheidungsgrundlage für Organisationen, um ihren Sicherheitsstatus gezielt zu verbessern, wenn sie wie ursprünglich geplant eingeführt werden.
==Was bleibt erhalten?==
===Standards und Vorgehen===
Trotz eines deutlich anderen Formats und einer anderen Gruppierung der Anforderungen bleibt das grundsätzliche Vorgehen weitgehend gleich.

D.h. die Standards 200-1 bis 200-4 sollen erst einmal weiter Verwendung finden. Die bisher üblichen Arbeitsschritte:
#Festlegung des Geltungsbereichs
#Strukturanalyse
#Schutzbedarfsfeststellung
#Modellierung
#IT-Grundschutzcheck (GSC)
#Risikoanalyse
bleiben grundsätzlich erhalten, ändern sich jedoch in der praktischen Anwendung und Priorität (insbesondere in der '''Modellierung''' und den '''Grundschutzchecks'''). Parallel zur Einführung sollen die Standards weiter entwickelt werden.

'''MUSS'''-Anforderungen sind weiterhin '''verpflichtend''' für eine Zertifizierung, sollen aber deutlich rediziert werden.

'''SOLLTE'''-Anforderungen bleiben auch weiter '''grundsätzlich verpflichtend''', können aber ggf. mit angemessener Begründung oder Ersatzmaßnahmen wegdiskutiert werden.

Lediglich '''KANN'''-Anforderungen sind optional.
===Tool-Einsatz===
Auch der Einsatz von ISMS-Tools wird weiterhin Bestand haben. Alle größeren Tool-Hersteller arbeiten mit Hochdruck an der Integration von Grundschutz++ in ihre Tools. Hier wird es perspektivisch Erleichterungen durch einen leichteren Datenaustausch zwischen den Tools und mehr Automatisierungspotential geben.
==Gegenüberstellung Grundschutz Kompendium vs. Grundschutz++==
Das IT-Grundschutz-Kompendium 2023 und der zukünftige Grundschutz++ bieten unterschiedliche Konzepte für die Umsetzung von Informationssicherheit: Während das Kompendium auf feste Bausteine in thematisch gegliederten Schichten setzt, verwendet Grundschutz++ modulare, flexibel einsetzbare Praktiken.

Die folgende Tabelle stellt die wesentlichen Unterschiede und Gemeinsamkeiten zwischen beiden Ansätzen (nach aktuell verfügbaren Kenntnissen) gegenüber:
{| class="wikitable"
|+
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Fester verbindlicher Katalog''' von Anforderungen (PDF, Excel und XML), die je nach Reifegrad erfüllt werden müssen.
|Der '''variable''' und erweiterbare '''[[OSCAL]]'''-Datenbestand kann beliebig an die Bedürfnisse der Organisation angepasst werden. Zusätzliche Kataloge/Erweiterungen (C5, Datenschutz, KRITIS/NIS2) können je nach Verfügbarkeit ergänzt werden. Durch die Beseitigung vermeintlicher Redundanzen soll die Anzahl der Anforderungen erheblich reduziert werden (~10–20 % verbleibende Anforderungen gegenüber dem Grundschutz Kompendium).
|-
|
|Järliche '''Aktualisierung''' zum Stichtag '''1. Februar'''.
(bis 2023)
|Die '''Aktualisierung''' erfolgt '''fortlaufend''' nach Bedarf und Verfügbarkeit. Die Regelungen zur Relevanz für Zertifizierungen sind bislang noch nicht bekannt.
|-
|
|Das Kompendium ist (Stand 2023) in 10 '''Schichten''' mit insgesamt 111 '''Bausteine''' gegliedert, die statisch die jeweiligen Anforderungen enthalten.
|'''Praktiken''' und '''''Zielobjektkategorien''''' (Achtung abweichende Bedeutung in GS++) sind allgemeinere und wiederverwendbare, sicherheitsrelevante Verfahren oder Anforderungen. Sie können modular und situationsabhängig einzelnen Assets zugeordnet werden.
Die voraussichtlich ca. 20 Praktiken liegen irgendwo zwischen Schichten und Bausteinen. Sie sind prozessorientierter, adressieren eher Zielgruppen oder Handlungstypen und sind nicht mehr starr bestimmten Zielobjektkategorien zugeordnet. Zielobjektkategorien entsprechen zukünftig eher den Bausteinen im alten Grundschutz. Die Definitionen der Begriffe sind nach wie vor im Fluß!
|-
|
|'''Drei Stufen''' (Vorgehensweisen): Basis, Standard, erhöhter Schutzbedarf bilden den Reifegrad der Organisation ab.
|Es sind zukünftig '''sechs Stufen''' (0–5) geplant, die sich weitgehend am Umsetzungsaufwand der jeweiligen Anforderung orientieren: Je kleiner die Stufe, desto schneller bzw. leichter ist die Anforderung umsetzbar (Quick Win). Eine qualitative Bewertung des Reifegrads muss zukünftig anders erfolgen (z.B. über Leistungskennzahlen).
Das '''Sicherheitsniveau''' gibt zukünftig an, in welchem Maß die definierten Sicherheitsziele erreicht sind. Es ergibt sich aus der wirksamen Umsetzung organisatorischer, technischer und personeller Anforderungen.

Unterschieden werden:
*'''Normales Sicherheitsniveau''': entspricht dem Stand der Technik
*'''Erhöhtes Sicherheitsniveau''': für besonders schutzbedürftige Informationen oder Systeme
|-
|
|'''Zielobjekte''' als gruppierte Sammlung von gleichartigen Assets die zur späteren '''Modellierung''' (Zuordnung der Bausteine und Abhängigkeiten) genutzt werden.
|'''Zielobjekte''' werden auch in Zukunft eine ähnliche Funktion zur Gruppierung und '''Modellierung''' haben, entsprechend dabei aber eher den klassischen Bausteinen. Die konkreten Vorgaben zur Modellierung sind jedoch noch nicht detailliert genug. In der Modellierung werden die Praktiken nicht mehr statisch bestimmten Zielobjekttypen zugewiesen. Klassische Zielobjekte werden zukünftig als Assets oder Assetgruppen bezeichnet.
|-
|
|Modalverben '''MUSS''', '''SOLLTE''', '''KANN''' bestimmen die Verbindlichkeit von Anforderungen.
|Die Bedeutung der Modalverben ('''MUSS, SOLLTE, KANN''') bleibt unverändert. Ein Ziel von Grundschutz++ ist es jedoch, die Anzahl der Muss-Anforderungen auf das Nötigste zu reduzieren (unter 10 %). Dadurch soll der Grundschutz flexibler werden. Die Verbindlichkeit von Anforderungen, die über MUSS-Anforderungen hinausgehen, ist noch unklar.
|-
|
| -
|Neu sind '''Leistungskennzahlen''', die eine qualitative Bewertung der Anforderungen in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit darstellen. Sie sollen als Zahlenwert darstellbar sein und so den Reifegrad abbilden können. Bisher ist noch nicht bekannt, ob und wann diese eingeführt werden und wie die konkreten Regelungen aussehen werden.
|-
|
|Gültigkeit voraussichtlich bis 2029
|Gültig ab 1.1.2026. Zertifizierbar geplant ab 2027.
|}Teilweise werden Begrifflichkeiten neu (oder anders) definiert:
{| class="wikitable"
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Zielobjekt''' als gruppierte Sammlung von gleichartigen Assets als Grundlage für die spätere Modellierung
|'''Asset''' und gruppierte Assets. Die Gruppierung gleichartiger Assets kann weiterhin erfolgen es bleiben jedoch auch dann '''Assets'''. Der Begriff ''Zielobjekt'' wird hierfür nicht mehr genutzt.
|-
|
|'''Baustein''' als Sammlung von Anforderungen für bestimmte Zielobjekttypen.
|'''Zielobjektkategorien''' sind zukünftig das was bislang die ''Bausteine'' waren, bestimmte Typen von Assets für die spezische Anforderungen gelten. Die Assets werden den Zielobjektkategorien zugewisen und erhalten über diese ihre Anforderungen. Eine klare Definition der Begriffe ist noch im Fluß.
|-
|
|
|
|}
==Blaupausen==
Blaupausen sind vorgefertigte Musterlösungen (wie die bisherigen IT-Grundschutz-Profile), die als Vorlage (Referenzmodell) für die Erstellung und Umsetzung von branchenspezifischen oder organisationsspezifischen Sicherheitskonzepten dienen.
===Funktion der Blaupausen===
Solche Blaupausen erfassen typische Strukturen, Risiken, Anforderungen und Maßnahmen für bestimmte Anwendungsszenarien, etwa die Nutzung der E-Akte oder den sicheren Betrieb von 5G-Infrastrukturen. Sie ermöglichen es, ein ISMS deutlich effizienter und strukturierter aufzubauen, weil die grundlegenden Überlegungen (Schutzbedarfsermittlung, Zuordnung von Praktiken, Zielobjekten und Maßnahmen, etc.) bereits allgemein gültig vorformuliert sind und nur noch organisationsspezifisch angepasst werden müssen.
===Ziel und Nutzen===
*Blaupausen helfen, den Implementierungsaufwand für ISMS nach Grundschutz++ zu reduzieren.
*Sie fördern die Standardisierung und Wiederverwendbarkeit von Sicherheitskonzepten für ähnliche Organisationen oder Branchen.
*Besonders für kleinere Organisationen und typische Anwendungsfälle bieten sie einen niederschwelligen, strukturierten und praxiserprobten Einstieg in die Absicherung.
Damit sind Blaupausen im Grundschutz++ zentrale Instrumente, um bewährte Sicherheitsmethoden als Vorlage für den schnellen und einheitlichen Aufbau eines branchenspezifischen ISMS bereitzustellen.
===Umsetzung===
Umgesetzt werden Blaupausen technische als '''OSCAL-Profile''' mit zusätzlichen Erläuterungen in Textform, zukünftig sollen Blaupausen zu einem '''System Security Plan (SSP)''' weiter entwickelt werden.
== Grundlagen und Standards ==

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_1.html BSI-Standard 200-1: Anforderungen an ein ISMS].
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_2.html BSI-Standard 200-2: IT-Grundschutz Methodik] ( <- Wird neu erstellt )
** [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html Methodik zum Grundschutz++] (Aktuell in Erstellung, ersetzt zukünftig 200-2)
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_3.html BSI-Standard 200-3: Risikomanagement mit Grundschutz].
* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/BSI-Standards/BSI-Standard-200-4-Business-Continuity-Management/bsi-standard-200-4_Business_Continuity_Management_node.html BSI-Standard 200-4: Business Continuity Management].
* [[OSCAL|OSCAL (Open Security Controls Assessment Language)]].

== Schritt-für-Schritt-Methodik ==
Die Methodik von Grundschutz++ folgt einem fünfstufigen, PDCA-basierten Prozess mit Fokus auf '''Anforderungsmodellierung''' und, wenn möglich, maschinenlesbarer Verarbeitung. Hier eine Kurzbeschreibung des praktischen Vorgehens:

=== Schritt 1: Erhebung und Planung (PLAN - Governance/Compliance) ===
Du legst hier die '''strategische Basis''' für Dein ISMS, indem du den '''Kontext deiner Organisation''' analysierst, '''Compliance-Pflichten''' (z.B. DSGVO, BDSG, brachenspezifische Gesetze und Regelungen) und '''Erwartungen interessierter Parteien''' (Kunden, Geschäftspartner, Behörden, Mitarbeitende) feststellst. Anschließend entwickelst du eine '''Informationssicherheitsleitlinie''' mit SMART-Zielen und einer '''Strategie''', definierst den '''Geltungsbereich des ISMS''' (Scope: welche Prozesse, Standorte, Systeme), klassifizierst den '''Schutzbedarf''' kritischer Geschäftsprozesse ("normal" oder "hoch"), richtest Rollen wie den '''unabhängigen ISB''' ein und initiierst '''Risikomanagement''' sowie '''Dokumentationspflichten''' – alles '''freigegeben von der Leitung'''.

'''Unterschied zu BSI-Standard 200-2:''' Während 200-2 mit Bausteinen und Risikoanalyse startet, integriert Grundschutz++ Governance und Compliance früher und stärker in den PDCA-Planungszyklus, mit Fokus auf maschinenlesbare Strukturen und Organisationsleitungspflicht – weniger asset-zentriert, mehr prozess- und rolleorientiert ab Schritt 1.
# '''Kontextanalyse''' (intern/extern) durchführen
# '''Interessierte Parteien''' identifizieren und Anforderungen erfassen
# '''Geltungsbereich''' (Scope) durch Organisationsleitung festlegen und freigeben
# '''Geschäftsprozesse''' priorisieren → Schutzbedarf "normal" oder "hoch" einstufen
# '''Sicherheitsleitlinie''' erstellen (Ziele, Strategie, Verpflichtung Leitung)
# '''Sicherheitsorganisation''' etablieren (Rollen: ISB, Asset-Owner, etc.)
# '''Compliance-Management''' initialisieren (Rechts-/Vertragskatalog)

'''Ergebnis''': Organisatorischer Rahmen, Sicherheitsleitlinie, priorisierte Prozesse

'''Weiterführende Informationen:'''

* [[Informationssicherheitsleitlinie]]
* [[IS-Strategie]]
* [[Geschäftsprozesse]]

=== Schritt 2: Anforderungsanalyse (PLAN - Strukturmodellierung) ===
Starte mit der '''Abgrenzung des Informationsverbunds''' (technische, organisatorische Einheit innerhalb des Geltungsbereichs), '''erfasse Assets''' (z.B. Server, Daten, Rollen) pro priorisiertem '''Geschäftsprozess''' und ordne sie '''Zielobjektkategorien''' zu (z.B. „Anwendung“ mit Vererbung übergeordneter Kategorien). Modelliere dann '''Anforderungen''' aus '''GS++-Praktiken''' ('''ISMS-weit''' plus assetbezogen), ergänze bei Bedarf '''externe Pflichten''' oder risikobasierte Anforderungen (nach Risikobetrachtung), prüfe das '''Sicherheitsniveau''' ("normal SdT" oder "erhöht") und treffe '''Gestaltungsentscheidungen''' (z.B. Parameter wie Zuständigkeiten) – Ergebnis: '''individuelles Anforderungspaket'''.

'''Unterschied zu BSI-Standard 200-2:''' Statt starrer Baustein-Zuordnung und manueller Risikoanalyse nutzt Grundschutz++ eine modellbasierte, hierarchische Anforderungsableitung via Assets und Zielobjektkategorien (OSCAL-fähig, maschinenlesbar), mit automatisierbarer Vererbung und klarer Trennung von Standard- (SdT) und ergänzenden Anforderungen – skalierbarer und zyklischer als die lineare 200-2-Methodik.
# '''Informationsverbund''' definieren (techn./org. Abgrenzung)
# '''Assets''' für wichtigsten Geschäftsprozess erfassen
# '''Asset → Zielobjektkategorien''' mapping (Hierarchie + Vererbung)
# '''Anforderungspaket''' generieren:
#* ISMS-Praktiken (vollständig)
#* Zielobjekt-Anforderungen (Sicherheitsniveau: normal/erhöht)
#* Zielobjektlose Anforderungen prüfen
# '''Ergänzungen''': Externe Verpflichtungen, anforderungslose Assets
# '''Risikobetrachtung''' bei hohem Schutzbedarf oder Niveauerhöhung
# '''Parameter setzen''' (Zuständigkeiten, Werte)

'''Ergebnis''': Individuelles Anforderungspaket pro Informationsverbund

'''Weiterführende Informationen:'''

* [[Strukturanalyse]]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das OSCAL-basierte Grundschutz++ Kompendium auf Github.]

=== Schritt 3: Realisierung (DO - Umsetzung) ===
In diesem Schritt '''setzt''' du das '''Anforderungspaket''' aus Schritt 2 '''um''', indem du den '''Ist-Zustand''' aller Anforderungen bewertest ('''Umsetzungsstatus''' ermittelst), fehlende Umsetzungen '''priorisierst''' (nach Risiko und Aufwand), einen '''Umsetzungsplan''' mit Zuständigkeiten und Fristen erstellst, '''Ausnahmen''' dokumentierst und freigibst sowie den Fortschritt verfolgst – inklusive '''Compliance-Sicherstellung''' durch regelmäßige '''Checks'''.

'''Unterschied zu BSI-Standard 200-2:''' Während 200-2 Maßnahmen aus Bausteinen direkt umsetzt und manuell dokumentiert, strukturiert Grundschutz++ die Realisierung zentral über das modellierte Anforderungspaket mit automatisierbarer Priorisierung und Nachverfolgung, stärker in den PDCA-Do-Zyklus eingebettet und skalierbar für große Verbünde.
# '''Umsetzungsstatus''' aller Anforderungen prüfen (ja/nein)
# '''Nicht-umgesetzte MUSS/SOLLTE''' → Risikobetrachtung
# '''Umsetzungsplan''' erstellen:
#* Priorisierung (Risiko, Aufwand, Synergien)
#* Zuständigkeiten + Fristen zuweisen
# '''Freigabe''' durch Institutionsleitung
# '''Fortschritt tracken''' (Ticketsystem/Projektmanagement)
# '''Ausnahmen dokumentieren''' (Begründung + Leitungsfreigabe)

'''Ergebnis''': Umsetzungsplan + Status-Dokumentation

'''Weiterführende Informationen:'''

* [[LF-Grundschutzcheck|Leitfaden Grundschutzcheck]]
* [[RiLi-Freigabe]]
* [[RiLi-Ausnahmemanagement|Richtlinie zum Management von Ausnahmen und Abweichungen]]

=== Schritt 4: Überwachung (CHECK - Monitoring/Evaluation) ===
Hier überprüfst du die '''Wirksamkeit''' des ISMS durch '''Leistungsbewertung''' (z.B. KPIs), '''Compliance-Monitoring''', '''Audits''' (mit Bewertungsschemata und Berichten), '''Management-Reviews''' und Validierung der Anforderungen gegen aktuelle Bedrohungen – Tools wie Monitoring-Software unterstützen die kontinuierliche Erfassung.

'''Unterschied zu BSI-Standard 200-2:''' Grundschutz++ erweitert die Überwachung (PDCA-Check) um maschinenlesbare Audit-Modelle und Validierung des Anforderungspakets, statt isolierter Baustein-Checks; es integriert dynamische Monitoring-Tools und Managementbewertungen enger, für zyklische Anpassung statt einmaliger Prüfung.
# '''Leistungsbewertung''' (KPIs, Umsetzungsfortschritt, Vorfälle)
# '''Compliance-Überwachung''' (gesetzlich/vertraglich)
# '''Auditprogramm''' risikobasiert durchführen
# '''Managementbewertung''' → Managementbericht erstellen
# '''Monitoring-Tools''' einsetzen (SIEM, Vulnerability Scanner)
# '''Anforderungspaket validieren''' (Aktualität prüfen)

'''Ergebnis''': Auditberichte, Managementbericht

'''Weiterführende Informationen:'''

* [[Reifegradmodell]]
* [[KPIs|Key Performance Indicators (KPIs)]]
* [[Managementbericht|Erstellen eines Managementberichts]]

=== Schritt 5: Kontinuierliche Verbesserung (ACT - Verbesserung) ===
Du behandelst hier deine '''Erkenntnisse''' aus Schritt 4, indem du Nicht-Konformitäten '''analysierst''', '''Verbesserungspotenziale''' '''identifizierst''', Korrektur- und Verbesserungspläne erstellst, deren '''Wirksamkeit prüfst''' und '''Compliance-Verstöße behebst''' – so bleibt das ISMS dynamisch und anpassbar an neue Risiken.

'''Unterschied zu BSI-Standard 200-2:''' Im Gegensatz zur reaktiven 200-2-Verbesserung (nach Risikoanalyse) schließt Grundschutz++ den PDCA-Act-Zyklus modellbasiert ab, mit systematischer Integration von Audit-Ergebnissen ins Anforderungspaket und automatisierbarer Wirksamkeitsprüfung – prozessorientierter und weniger manuell.
# '''Nicht-Konformitäten''' analysieren
# '''Verbesserungspotenziale''' identifizieren
# '''Korrektur-/Verbesserungsplan''' → in Umsetzungsplan integrieren
# '''Wirksamkeit prüfen''' nach Umsetzung
# '''Sicherheitsniveau''' bewerten (Trendanalyse)
# '''Compliance-Verstöße''' behandeln

'''Ergebnis''': Aktualisiertes Anforderungspaket → neuer PDCA-Zyklus

'''Weiterführende Informationen:'''

*

=== Praktische Hinweise ===
* '''Tool-gestützt''': JSON/OSCAL-Bausteine, Zur Nutzung sind ISMS-Tools empfohlen.
* '''Iteration''': Wichtigster Geschäftsprozess zuerst, dann schrittweise erweitern
* '''Risikobetrachtung''': Bei Sicherheitsniveau "hoch" oder Nicht-Umsetzung
* '''Dokumentation''': bevorzugt Maschinenlesbar (OSCAL) für besseren Austausch

'''Zyklusdauer''': Jährlich oder ereignisgesteuert (Änderungen, Vorfälle, Audits)

== Migration bestehender Sicherheitskonzepte ==
...

'''Weiterführende Informationen:'''

[[Grundschutz++ Migration]]

== Offenen Punkte und Kritiken ==

=== Zu viele Beteiligte, unklare Zuständigkeiten ===
Die Weiterentwicklung des Grundschutzes wird inzwischen nicht mehr ausschließlich vom Grundschutz-Referat des BSI verantwortet. Mit dem Einstieg des Referats „Stand der Technik“ und der verstärkten Einbindung der „Community“ sind die Zuständigkeiten und Verantwortlichkeiten unklarer geworden. In Präsentationen und Veröffentlichungen werden die Rollen und Aufgaben der verschiedenen Beteiligten unterschiedlich dargestellt. Es fehlt eine klare, kommunizierte Schnittstelle, wer für welche Aspekte der Entwicklung, Pflege und Kommunikation des neuen Standards verantwortlich ist. Das erschwert für Anwendende die Orientierung und die Planung der eigenen Umsetzungsstrategie.

=== Unklare Umsetzung einiger Ziele ===
Einige der im Grundschutz++ adressierten Ziele und Neuerungen sind nach wie vor nicht ausreichend konkretisiert. Besonders die Einführung von Leistungskennzahlen und die Priorisierung der Anforderungen (Stufen) werfen noch viele Fragen auf. Die konkrete Bedeutung, Messung und praktische Umsetzung dieser Leistungskennzahlen werden von verschiedenen BSI-Vertretern unterschiedlich dargestellt. Auch die Stufenmodelle werden teils als Priorisierung, als Entwicklungsstufen oder als reiner Umsetzungaufwand der Anforderungen definiert und sind in ihrer praktischen Anwendung noch nicht abschließend geklärt. Das führt zu Unsicherheiten, wie diese neuen Instrumente im einem ISMS umgesetzt und nachgewiesen werden sollen.

=== Geringer Mehrwert im Vergleich zu ISO 27001 ===
Die Anforderungen im Grundschutz++ werden zunehmend an die Formulierungen und Strukturen der ISO 27001 angeglichen. Während der klassische IT-Grundschutz durch seine konkreten, praxisnahen Maßnahmen einen klaren Mehrwert gegenüber der eher abstrakten ISO 27001 bot, verliert er durch die Harmonisierung mit internationalen Standards zunehmend diesen Vorteil. Die Anforderungen werden stärker abstrakt modularisiert formuliert, wodurch der spezifische Bezug zu typischen Umsetzungsbeispielen und die Detailtiefe abnehmen. Für viele Organisationen wird sich daher die Frage stellen, warum sie den immer noch aufwändigeren Weg über den Grundschutz wählen sollten, wenn sie mit ähnlichem oder geringeren Aufwand direkt eine ISO 27001-Zertifizierung anstreben können.

=== Zu ambitionierter Zeitplan ===
Der Grundschutz++ sollte ab dem 1.1.2026 grundsätzlich gültig und anwedbar sein, wobei eine Übergangsphase bis 2029 vorgesehen war. Bisher ist nur ein erster Entwurf veröffentlicht. Angesichts der Vielzahl an noch offenen Fragen, der fehlenden Migrationsstrategie und der Komplexität der Änderungen erscheint der Zeitplan sehr ambitioniert. Ausarbeitung und Dokumentation liegen bisher nur als Entwurf vor. Eine Pilotierung und Einführung 2026 und eine Übergangsphase bis 2029 ist vorgesehen. Die Gefahr besteht, dass größere Organisationen unter Zeitdruck unzureichend vorbereitet in die neue Methodik wechseln und mit variablen Definitionen und Zielen arbeiten müssen, was die Akzeptanz und Qualität der Umsetzung gefährdet.

=== Zunehmende (Sicherheits-)Lücke zwischen Grundschutz und Grundschutz++ ===
Mit der Entscheidung des BSI, den bisherigen IT-Grundschutz (Edition 2023) nicht mehr weiterzuentwickeln und stattdessen auf das neue Grundschutz++-Modell zu setzen, entsteht eine wachsende Lücke in der Informationssicherheit. Diese Übergangsphase bis 2029 ist sicherheitstechnisch kritisch, da sich die Bedrohungslage in der IT nicht an Entwicklungszyklen von Sicherheitsstandards orientiert. Neue Angriffsvektoren, insbesondere durch den zunehmenden Einsatz von KI in der Cyberkriminalität (z.B. KI-gestützte Malware, Deepfakes, automatisierte Phishing-Kampagnen), entstehen kontinuierlich und erfordern zeitnahe, wirksame Gegenmaßnahmen. Der bisherige Grundschutz bildet diese aktuellen Bedrohungen und technologische Entwicklungen jedoch nicht mehr ab, während die spezifischen Module und Maßnahmen im Grundschutz++ noch nicht produktiv verfügbar oder praxistauglich sind.

=== Fehlende Migration vom Grundschutz-Kompendium zu Grundschutz++ ===
Aktuell existiert weder ein konkreter Plan noch ein Konzept für eine (teil-)automatisierte Migration bestehender Sicherheitskonzepte aus dem bisherigen Grundschutz-Kompendium in das neue Grundschutz++-Modell. Die Umstellung auf ein maschinenlesbares JSON/OSCAL-Format und die objektorientierte, prozessorientierte Struktur bedeuten einen fundamentalen Bruch mit bisherigen Strukturen. Die Unterschiede zwischen Grundschutz-Kompendium und Grundschutz++ sind gravierender als beim letzten Wechsel von den Grundschutz-Katalogen zum Kompendium, bei dem bereits alle Ansätze für eine automatisierte Migration weitgehend gescheitert sind. Auch diesmal ist absehbar, dass Organisationen ihre bestehenden Dokumentationen und Umsetzungen weitgehend manuell neu abbilden müssen, was insbesondere für größere Verbünde einen erheblichen Zusatzaufwand bedeutet. Es gibt zwar Ansätze dies mittels KI zu lösen, was aber sicher nicht für jede Organisation praktikabel sein wird.

=== Überholte Satzschablonen ===
Satzschablonen waren vor OSCAL ein erster Versuch, Anforderungen durch eine feste Syntax maschinenlesbar vorzubereiten. OSCAL macht sie jedoch überflüssig, da Praktiken und Zielobjektkategorien flexibel in Metadaten (props, groups, links) abgebildet und gefiltert werden können. So lassen sich Anforderungstexte natürlich formulieren. Das verbessert die Lesbarkeit für Mitarbeitende und Tools gleichermaßen. GS++ verwendet dennoch weiterhin diese sperrige Satzschablonen-Syntax für Anforderungen, was umfangreiche Erläuterungstexte zu den Anforderungen erfordert.

== Fazit ==
Ein abschließendes Bild zum Grundschutz++ lässt sich aktuell noch nicht zeichnen – viele Details sind noch in der Entwicklung.

Die grundlegende Modernisierung des IT-Grundschutzes durch das Grundschutz++-Projekt ist zwar fachlich und technologisch nachvollziehbar und adressiert viele Schwächen des bisherigen Systems. Die Umsetzung ist jedoch nach jetzigem Entwicklungsstand mit erheblichen Risiken und Unsicherheiten verbunden. Ohne klare Migrationspfade, eindeutige Zuständigkeiten und praxistaugliche Konkretisierungen der neuen Instrumente besteht die Gefahr, dass die Akzeptanz des Grundschutzes sinkt und Organisationen sich vermehrt alternativen Standards wie der ISO 27001 zuwenden. Ein realistischer Zeitplan und ein echter Mehrwert des neuen Standards sind daher essenziell für den Erfolg der Reform.

Der Artikel wird fortlaufend aktualisiert, sobald neue Informationen vom BSI veröffentlicht oder freigegeben werden.
===Ausblick und ToDos aus Anwendersicht===
Stichtag für die Einführung von Grundschutz++ war der '''1.1.2026'''. Das Datum wurde vom BSI in offiziellen Ankündigungen, Präsentationen und Fachveranstaltungen als verbindlicher Startpunkt kommuniziert. Ab diesem Zeitpunkt sollte das neue, digitale und prozessorientierte Regelwerk den bisherigen IT-Grundschutz ablösen. Bisher fehlt es jedoch an vielen Stellen an klaren Definitionen und konkreten Vorgaben zur Methodik.

Auch wenn abzuwarten bleibt, wann praxistaugliche Methoden verfügbar sind und wie lange die Übergangsfristen für die Umstellung sein werden (aktuelle Planung bis 2029). Abzusehen ist jedoch, dass der Aufwand und der Zeitdruck, insbesondere für größere und zertifizierte Verbünde, erheblich sein werden. Auch wenn es aktuell noch keine konkreten Beschreibungen zur Methodik und Modellierung gibt, können und sollten sich Anwender bereits jetzt vorbereiten. Dazu können die folgenden Maßnahmen dienen:
*Laufende Information über den aktuellen Stand (Internetseiten des BSI, Vorträge und Veröffentlichungen).
*Konsolidierung der bestehenden Verbünde (Reduzierung der Komplexität, konsistente Dokumentation der Gruppierung und Modellierung).
**Ein guter Tip ist es, in aktuellen GSC jede Teilanforderung (jedes Modalverb wie MUSS oder SOLLTE) in der Umsetzung einzeln zu dokumentieren, da diese zukünftig eigenständige Anforderungen darstellen und so eine Übernahme leichter werden könnte.
*Kontakt zu Toolherstellern aufnehmen und eine zügige Umsetzung in den verwendeten ISMS-Tools einfordern.
*Frühzeitige Planung der Bereitstellung entsprechender personeller Ressourcen für die Umstellung auf Grundschutz++ ab Mitte 2026.
*Gegebenenfalls frühzeitige Reservierung externer (personeller) Ressourcen zur Unterstützung.
*Es muss eine klare interne Kommunikation über die bevorstehenden, durch die Umstellung bedingten erhöhten Aufwände (Schulungen, neue (Erst-)GSCs und Anpassung der Dokumentation) geben, damit Mitarbeitende und Verantwortliche wissen, was auf sie zukommt.

== Glossar ==
{{Begriffsdefinition GS++}}

== Weiterführende Ressourcen ==
*[https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html BSI IT-Grundschutz]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html BSI Leitfaden zur Grundschutz++-Methodik (1.4.2026)]
*[https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/Grundschutz/1GS_Tag_2025/Aktuelle_Entwicklungen_Ausblick_IT-GS.pdf Aktuelle Entwicklungen und Ausblick zum IT-Grundschutz - 1. Grundschutztag 2025]
*[https://www.youtube.com/watch?v=_AeWJ_Z8S-4 Keynote: Fortentwicklung des IT-Grundschutzes zu IT-Grundschutz++ (verinice.XP 2025)]
*[https://www.youtube.com/watch?v=fBXuhELODGA Vortrag: "Keynote und Vision Grundschutz++" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.youtube.com/watch?v=PxOjkV6oUwU Vortrag "Grundschutz++ Methodik und Einstieg ins BCM" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.bsi.bund.de/dok/it-sa Am Mittwoch, 08.10.2025 werden auf der it-sa die von den Arbeitsgruppen aus der Community erarbeiteten Ergebnisse präsentiert.]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]
*[[Grundschutz++ Migration|Migrationsstrategie für den Umstieg von BSI IT-Grundschutz auf Grundschutz++]]

[[Kategorie:Artikel]]
[[Kategorie:Grundschutz]]
[[Kategorie:++]]

Grundschutz++ Einführung und Aufbau

2026-04-05T08:18:43Z

Dirk: /* Überholte Satzschablonen */

Grundschutz++ Einführung und Aufbau

2026-04-05T08:16:00Z

Dirk: /* Fehlende Migration vom Grundschutz-Kompendium zu Grundschutz++ */

[[Datei:Teamwork-2198961.png|alternativtext=Zahnrad|rechts|240x240px]]{{#seo:
|title=Grundschutz++ Einführung und Anleitung
|keywords=ISMS, Wiki, BSI Grundschutz++, IT-Grundschutz, BSI-Standard 200-2, Bausteine, OSCAL, JSON, Informationssicherheit, Risikomanagement, Anforderungen
|description=Überblick über den neuen BSI Grundschutz++. Startseite zur Navigation durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.
}}{{SHORTDESC:Grundschutz++ Überblick und Anleitung}}''Dieser Artikel bietet einen schrittweisen Überblick über BSI '''Grundschutz++''' und navigiert durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.''

== Einführung in Grundschutz++ ==
'''Grundschutz++''' ist die 2026 vom BSI eingeführte Weiterentwicklung des IT-Grundschutz-Kompendiums. Es transformiert das bewährte Grundschutz-Konzept in ein vollständig digitales, maschinenlesbares Format mit JSON-basierten Bausteinen und OSCAL-kompatibler Struktur.<blockquote>
''Der aktuelle Stand von Grundschutz++ ist bisher nur sehr eingeschränkt praktisch anwendbar, da einige wesentliche Definitionen und Teile der Methodik noch fehlen. Dazu gehören beispielsweise die Nutzung von Kennzahlen, Blaupausen, Stufen, Schutzbedarf vs. Schutzniveau und die Modellierung.''

''Der Anforderungskatalog liegt zwar im OSCAL- und Excel-Format vor, ist ohne eine abgeschlossene und nachvollziehbare Methodik aber nicht sinnvoll anwendbar.''
</blockquote>
=== Wesentliche Neuerungen===
*'''OSCAL/JSON-basiertes Regelwerk''': Der IT-Grundschutz wird in ein maschinenlesbares '''JSON-Format''' überführt, das teilweise automatisierte Compliance-Prüfungen und Integrationen in bestehende IT-Systeme ermöglicht. Dies ersetzt die bisherigen textbasierten PDFs und Listen.
*'''Prozessorientierte Struktur''': Die neue Version ist modular und objektorientiert aufgebaut, um Redundanzen zu reduzieren und die Dokumentationslast zu verringern.
*'''Leistungskennzahlen''': Kennzahlen sollen die Informationssicherheit messbar und den Sicherheitsgewinn einzelner Anforderungen transparenter machen.
* '''Harmonisierung mit ISO 27001''': Die Anforderungen werden stärker mit internationalen Standards wie '''ISO 27001:2022''' abgestimmt, um Doppelzertifizierungen zu vereinfachen.
*'''Erweiterung um moderne Technologien''': Geplant sind auch spezifische Module für '''Cloud-Security, KI und IoT''', die aktuelle Bedrohungsszenarien abdecken.
===Ziele der Reform===
*'''Schlankere Prozesse''': Durch Automatisierung soll der administrative Aufwand sinken.
*'''Dynamische Anpassung''': JSON ermöglicht schnellere, ggf. automatisierte Updates bei neuen Cyberbedrohungen.
*'''Praxisorientierte Vereinfachung''': Der BSI will die Dokumentationslast reduzieren und den Fokus auf risikobasierte Ansätze legen, insbesondere für KMU.
*'''Priorisierung und Messbarkeit''': Durch eine stufenweise Priorisierung von Anforderungen und Leistungskennzahlen soll ein zielgerichteteres Vorgehen und die bessere Messbarkeit der Sicherheit gefördert werden.
Die Änderungen reagieren auf Kritik an der bisherigen Komplexität und sollen besonders KMU entlasten, während die ganzheitliche Sicherheitsmethodik (technisch, organisatorisch, personell) erhalten bleibt.

''Hinweis'': Details zur finalen Struktur werden schrittweise im Jahr 2026 veröffentlicht. Unternehmen sollten sich frühzeitig mit den geplanten Schnittstellen (z.B. für Security-Tools) vertraut machen.

Offizieller '''Starttermin''' für den Grundschutz++ war der '''1.1.2026'''. Danach ist allerdings eine längere Übergangsphase (bis 2029) geplant, in der beide Standards parallel genutzt werden können, so wie bei der letzten Modernisierung auch. Da jedoch zu erwarten ist, dass eine automatisierte Migration auch diesmal nicht oder nur eingeschränkt möglich sein wird, sollte speziell in größeren Verbünden rechtzeitig begonnen werden! Der jeweils aktuellen Grundschutz++ Katalog wird auf [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek GitHub] veröffentlicht.
=== Bedeutung von OSCAL im Grundschutz++ ===
Das zugrundeliegende Format für Grundschutz++ ist [[OSCAL]].

[[OSCAL]] ist ein '''Framework''' bzw. eine '''Datenmodellierungssprache''', die vom NIST speziell für Sicherheitsanforderungen und Compliance-Dokumentation entwickelt wurde. OSCAL definiert dabei nur ein festes Schema für Sicherheits- und Compliance-Daten und lässt das zugrundeliegende Datenformat (JSON, XML oder YAML) offen.

Das BSI hat sich beim Grundschutz++ für das Datenformat '''JSON''' entschieden.

Dies ermöglicht es mit entsprechenden Tools Sicherheitsanforderungen automatisiert einzulesen und zu bearbeiten. D.h.

* Anforderungen können (teil-)automatisiert von entsprechenden Tools bearbeitet und dokumentiert werden, sofern entsprechende Tools zur Verfügung stehen oder vom Anwender (ggf. Dienstleister) programmiert werden.
* Kataloge und Sicherheitskonzepte (SSPs) können zwischen ISMS-Tools herstellerunabhängig ausgetauscht werden (sofern Toolhersteller sich an den Standard halten und entsprechende Im- und Exportfonktionen in ihren Tools zur Verfügung stellen).

Das heißt aber nicht:

* Das Anwender, Sicherheitsmanager oder Sicherheitsbeauftragte OSCAL lernen müssen oder OSCAL Formate lesen können müssen. (Dafür gibt es Tools, die die Inhalte lesbar und bearbeitbar zur Verfügung stellen)
* Das alle Anforderungen automatisiert erfüllt und dokumentiert werden (viele Anforderungen sind nach wie vor organisatorische Anforderungen die nur von Menschen durch Erstellung und Beachtung entsprechenden Regelungen erfüllt werden können).
* Das überhaupt irgendwelche Anforderungen automatisiert erfüllt und dokumentiert werden (Hierzu müssten die Systeme an ein ISMS-Tool angebunden sein und diese über entsprechende Schnittstellen mit Informationen bedienen). Sowohl die Tools als auch die Schnittstellen werden absehbar nicht vom Himmel fallen.
===Satzschablonen===
Anforderungen werden im Grundschutz++ zukünftig mit Satzschablonen erstellt, die wie folgt aussehen:<blockquote><big>'''<span style="color:green">{Praktik} [für {Zielobjektkategorie}]</span> <span style="color:red">{MODALVERB}</span> <span style="color:blue"><Ergebnis></span> <span style="color:purple">{Handlungswort}</span>''' ''<span style="color:grey">(TAGs) (Hinweise)</span>''</big></blockquote>'''Praktik''': Ein Prozess im Rahmen des ISMS, eine konkrete Sicherheitsmaßnahme oder eine allgemeine Vorgehensweise zur Erreichung eines Sicherheitsziels (z.B. IT-Betrieb, Personal, Konfiguration) - Im weitesten Sinne vergleichbar mit den bisherigen Bausteinen. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/practices.csv Liste der gültigen Praktiken.]

'''Zielobjektkategorie''': Wie bisher, das Objekt oder die Entität, auf die sich die Sicherheitsanforderungen beziehen (z.B. Daten, Personen, Endgeräte, Hostsysteme). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/target_object_categories.csv Liste der Gültigen Zielobjektkategorien.]

'''Modalverb''': Gibt die Verbindlichkeit einer Anforderung an (MUSS, SOLLTE, KANN). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/modal_verbs.csv Liste der gültigen Modalverben.]

'''Ereignis''': Der sicherheitsrelevante Zustand oder Auslöser, der zu einer bestimmten Handlung führt - Entspricht in Verbindung mit dem Handlungswort dem wesentliche Inhalt der Anforderung.

'''Handlungswort''': Das Verb, das die konkrete Sicherheitsmaßnahme oder Art der Tätigkeit beschreibt (regeln, zuweisen, konfigurieren). Handlungsworte können auch zur besseren Filterung genutzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/action_words.csv Liste der gültigen Handlungsworte.]

Das ganze kann noch mit '''TAG'''s für eine bessere Gruppierung und mit einem '''Hinweis''' zu weiterführenden Informationen ergänzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/tags.csv Liste der gültigen TAGs.]

Die bisherigen Anforderungen des Kompendium werden aktuell in ihre Teilanforderungen zerlegt und jede Teilanforderung wird zukünftig eine eigene Anforderung. D.h. jedes Modalverb (SOLL, MUSS, KANN) der bisherigen Anforderungen stellt zukünftig i.d.R. eine eigene Anforderung dar. Die Gesamtanzahl der Anforderungen soll dabei durch die Vermeidung von Redundanzen dennoch sinken.

'''Beispiel'''

Die Anforderung:<blockquote>'''ISMS.1.A4 Benennung eines oder einer Informationssicherheitsbeauftragten (B) [Institutionsleitung]'''

Die Institutionsleitung MUSS einen oder eine ISB benennen. '''. . .'''

Die Institutionsleitung MUSS den oder die ISB mit angemessenen Ressourcen ausstatten.

Die Institutionsleitung MUSS dem oder der ISB die Möglichkeit einräumen, bei Bedarf direkt an sie selbst zu berichten. '''. . .'''</blockquote>Wird jetzt zu den Anforderungen:<blockquote>'''GOV.4.2''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">einer Person die Rolle ISB</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.2.3''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">für das ISMS erforderliche personelle, finanzielle und zeitliche Ressourcen</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.4.4''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">dem ISB das direkte und jederzeitige Vorspracherecht bei der Institutionsleitung</span> '''<span style="color:purple">ermöglichen</span>.'''</blockquote>Da dies übergreifende Anforderungen sind, ist hier kein spezifisches Zielobjekt benannt.

Einzelne Teilanforderungen können auch in anderen Praktiken beschrieben sein.
===Priorisierung===
Alle Anforderungen werden einer Prioritätsstufe zugeordnet, um die Umsetzung effizient zu gestalten:
*'''Stufe 0''': Zwingend (sofort) umzusetzende Anforderungen zur Sicherstellung der ISO-Kompatibilität (MUSS-Anforderungen).
Die Stufen 1-4 geben den Umsetzungsaufwand der Anforderungen wieder:
*'''Stufe 1''': Schnell und mit geringem Aufwand (~1 Tag) realisierbare Maßnahmen (QuickWin) / keine laufenden Aufwände.
*'''Stufe 2''': Mit eigenen Mitteln leicht umsetzbare Anforderung (~1 Woche) / geringe laufende Aufwände.
*'''Stufe 3''': Mit normalem Aufwand (mehrere Wochen) und ggf. externer Unterstützung umsetzbar / normale laufende Aufwände.
*'''Stufe 4''': Höherer Umsetzungsaufwand, häufig in längerfristigen Projekten mit externen Experten.
Die nächste Stufe sind optionale Anforderungen als Vorschläge bei erhöhtem Schutzbedarf.
*'''Stufe 5''': Umfassende/zusätzliche Anforderungen für höheren Schutzbedarf.
Diese Einstufung ermöglicht eine schnelle Einschätzung des Umsetzungsaufwands und hilft bei der effizienten Ressourcenplanung.
===Leistungskennzahlen===
Leistungskennzahlen dienen der '''Messung und Bewertung''' der Umsetzung von Sicherheitsanforderungen im Grundschutz++. Sie ermöglichen eine objektive Einschätzung des Sicherheitsniveaus und unterstützen die kontinuierliche Verbesserung. Wie diese Leistungskennzahlen genutzt werden sollen ist nach wie vor unklar und viele Anforderungen sind bislang noch nicht bewertet.
====Bewertungskriterien====
Jede Anforderung wird in Bezug auf die drei Schutzziele bewertet:
*'''Vertraulichkeit (C)'''
*'''Integrität (I)'''
*'''Verfügbarkeit (A)'''
Anforderungen erhalten Punktwerte in diesen Kategorien, die zur Bestimmung des Schutzgrades genutzt werden (z.B. C=6, I=2, A=0 ist eine Anforderung die im Wesentlichen die Vetraulichkeit stärkt, in Teilen die Intgrität aber nicht die Verfügbarkeit).

Die einzelen Kennzahlen werden je Schutzziel, Praktik und/oder Zielobjekt aufsummiert und ergeben so den Erfüllungsgrad.
====Schwellwerte und Erfüllungsgrad====
*'''Schwellwerte''' definieren das angestrebte Sicherheitsniveau basierend auf der Summe der Punktwerte aller umgesetzten Anforderungen je Schutzziel, Zielobjekt und Schutzstufe.
*'''Der Erfüllungsgrad''' zeigt, welche Anforderungen bereits umgesetzt wurden.
Die Leistungskennzahlen bieten damit eine fundierte Entscheidungsgrundlage für Organisationen, um ihren Sicherheitsstatus gezielt zu verbessern, wenn sie wie ursprünglich geplant eingeführt werden.
==Was bleibt erhalten?==
===Standards und Vorgehen===
Trotz eines deutlich anderen Formats und einer anderen Gruppierung der Anforderungen bleibt das grundsätzliche Vorgehen weitgehend gleich.

D.h. die Standards 200-1 bis 200-4 sollen erst einmal weiter Verwendung finden. Die bisher üblichen Arbeitsschritte:
#Festlegung des Geltungsbereichs
#Strukturanalyse
#Schutzbedarfsfeststellung
#Modellierung
#IT-Grundschutzcheck (GSC)
#Risikoanalyse
bleiben grundsätzlich erhalten, ändern sich jedoch in der praktischen Anwendung und Priorität (insbesondere in der '''Modellierung''' und den '''Grundschutzchecks'''). Parallel zur Einführung sollen die Standards weiter entwickelt werden.

'''MUSS'''-Anforderungen sind weiterhin '''verpflichtend''' für eine Zertifizierung, sollen aber deutlich rediziert werden.

'''SOLLTE'''-Anforderungen bleiben auch weiter '''grundsätzlich verpflichtend''', können aber ggf. mit angemessener Begründung oder Ersatzmaßnahmen wegdiskutiert werden.

Lediglich '''KANN'''-Anforderungen sind optional.
===Tool-Einsatz===
Auch der Einsatz von ISMS-Tools wird weiterhin Bestand haben. Alle größeren Tool-Hersteller arbeiten mit Hochdruck an der Integration von Grundschutz++ in ihre Tools. Hier wird es perspektivisch Erleichterungen durch einen leichteren Datenaustausch zwischen den Tools und mehr Automatisierungspotential geben.
==Gegenüberstellung Grundschutz Kompendium vs. Grundschutz++==
Das IT-Grundschutz-Kompendium 2023 und der zukünftige Grundschutz++ bieten unterschiedliche Konzepte für die Umsetzung von Informationssicherheit: Während das Kompendium auf feste Bausteine in thematisch gegliederten Schichten setzt, verwendet Grundschutz++ modulare, flexibel einsetzbare Praktiken.

Die folgende Tabelle stellt die wesentlichen Unterschiede und Gemeinsamkeiten zwischen beiden Ansätzen (nach aktuell verfügbaren Kenntnissen) gegenüber:
{| class="wikitable"
|+
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Fester verbindlicher Katalog''' von Anforderungen (PDF, Excel und XML), die je nach Reifegrad erfüllt werden müssen.
|Der '''variable''' und erweiterbare '''[[OSCAL]]'''-Datenbestand kann beliebig an die Bedürfnisse der Organisation angepasst werden. Zusätzliche Kataloge/Erweiterungen (C5, Datenschutz, KRITIS/NIS2) können je nach Verfügbarkeit ergänzt werden. Durch die Beseitigung vermeintlicher Redundanzen soll die Anzahl der Anforderungen erheblich reduziert werden (~10–20 % verbleibende Anforderungen gegenüber dem Grundschutz Kompendium).
|-
|
|Järliche '''Aktualisierung''' zum Stichtag '''1. Februar'''.
(bis 2023)
|Die '''Aktualisierung''' erfolgt '''fortlaufend''' nach Bedarf und Verfügbarkeit. Die Regelungen zur Relevanz für Zertifizierungen sind bislang noch nicht bekannt.
|-
|
|Das Kompendium ist (Stand 2023) in 10 '''Schichten''' mit insgesamt 111 '''Bausteine''' gegliedert, die statisch die jeweiligen Anforderungen enthalten.
|'''Praktiken''' und '''''Zielobjektkategorien''''' (Achtung abweichende Bedeutung in GS++) sind allgemeinere und wiederverwendbare, sicherheitsrelevante Verfahren oder Anforderungen. Sie können modular und situationsabhängig einzelnen Assets zugeordnet werden.
Die voraussichtlich ca. 20 Praktiken liegen irgendwo zwischen Schichten und Bausteinen. Sie sind prozessorientierter, adressieren eher Zielgruppen oder Handlungstypen und sind nicht mehr starr bestimmten Zielobjektkategorien zugeordnet. Zielobjektkategorien entsprechen zukünftig eher den Bausteinen im alten Grundschutz. Die Definitionen der Begriffe sind nach wie vor im Fluß!
|-
|
|'''Drei Stufen''' (Vorgehensweisen): Basis, Standard, erhöhter Schutzbedarf bilden den Reifegrad der Organisation ab.
|Es sind zukünftig '''sechs Stufen''' (0–5) geplant, die sich weitgehend am Umsetzungsaufwand der jeweiligen Anforderung orientieren: Je kleiner die Stufe, desto schneller bzw. leichter ist die Anforderung umsetzbar (Quick Win). Eine qualitative Bewertung des Reifegrads muss zukünftig anders erfolgen (z.B. über Leistungskennzahlen).
Das '''Sicherheitsniveau''' gibt zukünftig an, in welchem Maß die definierten Sicherheitsziele erreicht sind. Es ergibt sich aus der wirksamen Umsetzung organisatorischer, technischer und personeller Anforderungen.

Unterschieden werden:
*'''Normales Sicherheitsniveau''': entspricht dem Stand der Technik
*'''Erhöhtes Sicherheitsniveau''': für besonders schutzbedürftige Informationen oder Systeme
|-
|
|'''Zielobjekte''' als gruppierte Sammlung von gleichartigen Assets die zur späteren '''Modellierung''' (Zuordnung der Bausteine und Abhängigkeiten) genutzt werden.
|'''Zielobjekte''' werden auch in Zukunft eine ähnliche Funktion zur Gruppierung und '''Modellierung''' haben, entsprechend dabei aber eher den klassischen Bausteinen. Die konkreten Vorgaben zur Modellierung sind jedoch noch nicht detailliert genug. In der Modellierung werden die Praktiken nicht mehr statisch bestimmten Zielobjekttypen zugewiesen. Klassische Zielobjekte werden zukünftig als Assets oder Assetgruppen bezeichnet.
|-
|
|Modalverben '''MUSS''', '''SOLLTE''', '''KANN''' bestimmen die Verbindlichkeit von Anforderungen.
|Die Bedeutung der Modalverben ('''MUSS, SOLLTE, KANN''') bleibt unverändert. Ein Ziel von Grundschutz++ ist es jedoch, die Anzahl der Muss-Anforderungen auf das Nötigste zu reduzieren (unter 10 %). Dadurch soll der Grundschutz flexibler werden. Die Verbindlichkeit von Anforderungen, die über MUSS-Anforderungen hinausgehen, ist noch unklar.
|-
|
| -
|Neu sind '''Leistungskennzahlen''', die eine qualitative Bewertung der Anforderungen in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit darstellen. Sie sollen als Zahlenwert darstellbar sein und so den Reifegrad abbilden können. Bisher ist noch nicht bekannt, ob und wann diese eingeführt werden und wie die konkreten Regelungen aussehen werden.
|-
|
|Gültigkeit voraussichtlich bis 2029
|Gültig ab 1.1.2026. Zertifizierbar geplant ab 2027.
|}Teilweise werden Begrifflichkeiten neu (oder anders) definiert:
{| class="wikitable"
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Zielobjekt''' als gruppierte Sammlung von gleichartigen Assets als Grundlage für die spätere Modellierung
|'''Asset''' und gruppierte Assets. Die Gruppierung gleichartiger Assets kann weiterhin erfolgen es bleiben jedoch auch dann '''Assets'''. Der Begriff ''Zielobjekt'' wird hierfür nicht mehr genutzt.
|-
|
|'''Baustein''' als Sammlung von Anforderungen für bestimmte Zielobjekttypen.
|'''Zielobjektkategorien''' sind zukünftig das was bislang die ''Bausteine'' waren, bestimmte Typen von Assets für die spezische Anforderungen gelten. Die Assets werden den Zielobjektkategorien zugewisen und erhalten über diese ihre Anforderungen. Eine klare Definition der Begriffe ist noch im Fluß.
|-
|
|
|
|}
==Blaupausen==
Blaupausen sind vorgefertigte Musterlösungen (wie die bisherigen IT-Grundschutz-Profile), die als Vorlage (Referenzmodell) für die Erstellung und Umsetzung von branchenspezifischen oder organisationsspezifischen Sicherheitskonzepten dienen.
===Funktion der Blaupausen===
Solche Blaupausen erfassen typische Strukturen, Risiken, Anforderungen und Maßnahmen für bestimmte Anwendungsszenarien, etwa die Nutzung der E-Akte oder den sicheren Betrieb von 5G-Infrastrukturen. Sie ermöglichen es, ein ISMS deutlich effizienter und strukturierter aufzubauen, weil die grundlegenden Überlegungen (Schutzbedarfsermittlung, Zuordnung von Praktiken, Zielobjekten und Maßnahmen, etc.) bereits allgemein gültig vorformuliert sind und nur noch organisationsspezifisch angepasst werden müssen.
===Ziel und Nutzen===
*Blaupausen helfen, den Implementierungsaufwand für ISMS nach Grundschutz++ zu reduzieren.
*Sie fördern die Standardisierung und Wiederverwendbarkeit von Sicherheitskonzepten für ähnliche Organisationen oder Branchen.
*Besonders für kleinere Organisationen und typische Anwendungsfälle bieten sie einen niederschwelligen, strukturierten und praxiserprobten Einstieg in die Absicherung.
Damit sind Blaupausen im Grundschutz++ zentrale Instrumente, um bewährte Sicherheitsmethoden als Vorlage für den schnellen und einheitlichen Aufbau eines branchenspezifischen ISMS bereitzustellen.
===Umsetzung===
Umgesetzt werden Blaupausen technische als '''OSCAL-Profile''' mit zusätzlichen Erläuterungen in Textform, zukünftig sollen Blaupausen zu einem '''System Security Plan (SSP)''' weiter entwickelt werden.
== Grundlagen und Standards ==

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_1.html BSI-Standard 200-1: Anforderungen an ein ISMS].
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_2.html BSI-Standard 200-2: IT-Grundschutz Methodik] ( <- Wird neu erstellt )
** [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html Methodik zum Grundschutz++] (Aktuell in Erstellung, ersetzt zukünftig 200-2)
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_3.html BSI-Standard 200-3: Risikomanagement mit Grundschutz].
* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/BSI-Standards/BSI-Standard-200-4-Business-Continuity-Management/bsi-standard-200-4_Business_Continuity_Management_node.html BSI-Standard 200-4: Business Continuity Management].
* [[OSCAL|OSCAL (Open Security Controls Assessment Language)]].

== Schritt-für-Schritt-Methodik ==
Die Methodik von Grundschutz++ folgt einem fünfstufigen, PDCA-basierten Prozess mit Fokus auf '''Anforderungsmodellierung''' und, wenn möglich, maschinenlesbarer Verarbeitung. Hier eine Kurzbeschreibung des praktischen Vorgehens:

=== Schritt 1: Erhebung und Planung (PLAN - Governance/Compliance) ===
Du legst hier die '''strategische Basis''' für Dein ISMS, indem du den '''Kontext deiner Organisation''' analysierst, '''Compliance-Pflichten''' (z.B. DSGVO, BDSG, brachenspezifische Gesetze und Regelungen) und '''Erwartungen interessierter Parteien''' (Kunden, Geschäftspartner, Behörden, Mitarbeitende) feststellst. Anschließend entwickelst du eine '''Informationssicherheitsleitlinie''' mit SMART-Zielen und einer '''Strategie''', definierst den '''Geltungsbereich des ISMS''' (Scope: welche Prozesse, Standorte, Systeme), klassifizierst den '''Schutzbedarf''' kritischer Geschäftsprozesse ("normal" oder "hoch"), richtest Rollen wie den '''unabhängigen ISB''' ein und initiierst '''Risikomanagement''' sowie '''Dokumentationspflichten''' – alles '''freigegeben von der Leitung'''.

'''Unterschied zu BSI-Standard 200-2:''' Während 200-2 mit Bausteinen und Risikoanalyse startet, integriert Grundschutz++ Governance und Compliance früher und stärker in den PDCA-Planungszyklus, mit Fokus auf maschinenlesbare Strukturen und Organisationsleitungspflicht – weniger asset-zentriert, mehr prozess- und rolleorientiert ab Schritt 1.
# '''Kontextanalyse''' (intern/extern) durchführen
# '''Interessierte Parteien''' identifizieren und Anforderungen erfassen
# '''Geltungsbereich''' (Scope) durch Organisationsleitung festlegen und freigeben
# '''Geschäftsprozesse''' priorisieren → Schutzbedarf "normal" oder "hoch" einstufen
# '''Sicherheitsleitlinie''' erstellen (Ziele, Strategie, Verpflichtung Leitung)
# '''Sicherheitsorganisation''' etablieren (Rollen: ISB, Asset-Owner, etc.)
# '''Compliance-Management''' initialisieren (Rechts-/Vertragskatalog)

'''Ergebnis''': Organisatorischer Rahmen, Sicherheitsleitlinie, priorisierte Prozesse

'''Weiterführende Informationen:'''

* [[Informationssicherheitsleitlinie]]
* [[IS-Strategie]]
* [[Geschäftsprozesse]]

=== Schritt 2: Anforderungsanalyse (PLAN - Strukturmodellierung) ===
Starte mit der '''Abgrenzung des Informationsverbunds''' (technische, organisatorische Einheit innerhalb des Geltungsbereichs), '''erfasse Assets''' (z.B. Server, Daten, Rollen) pro priorisiertem '''Geschäftsprozess''' und ordne sie '''Zielobjektkategorien''' zu (z.B. „Anwendung“ mit Vererbung übergeordneter Kategorien). Modelliere dann '''Anforderungen''' aus '''GS++-Praktiken''' ('''ISMS-weit''' plus assetbezogen), ergänze bei Bedarf '''externe Pflichten''' oder risikobasierte Anforderungen (nach Risikobetrachtung), prüfe das '''Sicherheitsniveau''' ("normal SdT" oder "erhöht") und treffe '''Gestaltungsentscheidungen''' (z.B. Parameter wie Zuständigkeiten) – Ergebnis: '''individuelles Anforderungspaket'''.

'''Unterschied zu BSI-Standard 200-2:''' Statt starrer Baustein-Zuordnung und manueller Risikoanalyse nutzt Grundschutz++ eine modellbasierte, hierarchische Anforderungsableitung via Assets und Zielobjektkategorien (OSCAL-fähig, maschinenlesbar), mit automatisierbarer Vererbung und klarer Trennung von Standard- (SdT) und ergänzenden Anforderungen – skalierbarer und zyklischer als die lineare 200-2-Methodik.
# '''Informationsverbund''' definieren (techn./org. Abgrenzung)
# '''Assets''' für wichtigsten Geschäftsprozess erfassen
# '''Asset → Zielobjektkategorien''' mapping (Hierarchie + Vererbung)
# '''Anforderungspaket''' generieren:
#* ISMS-Praktiken (vollständig)
#* Zielobjekt-Anforderungen (Sicherheitsniveau: normal/erhöht)
#* Zielobjektlose Anforderungen prüfen
# '''Ergänzungen''': Externe Verpflichtungen, anforderungslose Assets
# '''Risikobetrachtung''' bei hohem Schutzbedarf oder Niveauerhöhung
# '''Parameter setzen''' (Zuständigkeiten, Werte)

'''Ergebnis''': Individuelles Anforderungspaket pro Informationsverbund

'''Weiterführende Informationen:'''

* [[Strukturanalyse]]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das OSCAL-basierte Grundschutz++ Kompendium auf Github.]

=== Schritt 3: Realisierung (DO - Umsetzung) ===
In diesem Schritt '''setzt''' du das '''Anforderungspaket''' aus Schritt 2 '''um''', indem du den '''Ist-Zustand''' aller Anforderungen bewertest ('''Umsetzungsstatus''' ermittelst), fehlende Umsetzungen '''priorisierst''' (nach Risiko und Aufwand), einen '''Umsetzungsplan''' mit Zuständigkeiten und Fristen erstellst, '''Ausnahmen''' dokumentierst und freigibst sowie den Fortschritt verfolgst – inklusive '''Compliance-Sicherstellung''' durch regelmäßige '''Checks'''.

'''Unterschied zu BSI-Standard 200-2:''' Während 200-2 Maßnahmen aus Bausteinen direkt umsetzt und manuell dokumentiert, strukturiert Grundschutz++ die Realisierung zentral über das modellierte Anforderungspaket mit automatisierbarer Priorisierung und Nachverfolgung, stärker in den PDCA-Do-Zyklus eingebettet und skalierbar für große Verbünde.
# '''Umsetzungsstatus''' aller Anforderungen prüfen (ja/nein)
# '''Nicht-umgesetzte MUSS/SOLLTE''' → Risikobetrachtung
# '''Umsetzungsplan''' erstellen:
#* Priorisierung (Risiko, Aufwand, Synergien)
#* Zuständigkeiten + Fristen zuweisen
# '''Freigabe''' durch Institutionsleitung
# '''Fortschritt tracken''' (Ticketsystem/Projektmanagement)
# '''Ausnahmen dokumentieren''' (Begründung + Leitungsfreigabe)

'''Ergebnis''': Umsetzungsplan + Status-Dokumentation

'''Weiterführende Informationen:'''

* [[LF-Grundschutzcheck|Leitfaden Grundschutzcheck]]
* [[RiLi-Freigabe]]
* [[RiLi-Ausnahmemanagement|Richtlinie zum Management von Ausnahmen und Abweichungen]]

=== Schritt 4: Überwachung (CHECK - Monitoring/Evaluation) ===
Hier überprüfst du die '''Wirksamkeit''' des ISMS durch '''Leistungsbewertung''' (z.B. KPIs), '''Compliance-Monitoring''', '''Audits''' (mit Bewertungsschemata und Berichten), '''Management-Reviews''' und Validierung der Anforderungen gegen aktuelle Bedrohungen – Tools wie Monitoring-Software unterstützen die kontinuierliche Erfassung.

'''Unterschied zu BSI-Standard 200-2:''' Grundschutz++ erweitert die Überwachung (PDCA-Check) um maschinenlesbare Audit-Modelle und Validierung des Anforderungspakets, statt isolierter Baustein-Checks; es integriert dynamische Monitoring-Tools und Managementbewertungen enger, für zyklische Anpassung statt einmaliger Prüfung.
# '''Leistungsbewertung''' (KPIs, Umsetzungsfortschritt, Vorfälle)
# '''Compliance-Überwachung''' (gesetzlich/vertraglich)
# '''Auditprogramm''' risikobasiert durchführen
# '''Managementbewertung''' → Managementbericht erstellen
# '''Monitoring-Tools''' einsetzen (SIEM, Vulnerability Scanner)
# '''Anforderungspaket validieren''' (Aktualität prüfen)

'''Ergebnis''': Auditberichte, Managementbericht

'''Weiterführende Informationen:'''

* [[Reifegradmodell]]
* [[KPIs|Key Performance Indicators (KPIs)]]
* [[Managementbericht|Erstellen eines Managementberichts]]

=== Schritt 5: Kontinuierliche Verbesserung (ACT - Verbesserung) ===
Du behandelst hier deine '''Erkenntnisse''' aus Schritt 4, indem du Nicht-Konformitäten '''analysierst''', '''Verbesserungspotenziale''' '''identifizierst''', Korrektur- und Verbesserungspläne erstellst, deren '''Wirksamkeit prüfst''' und '''Compliance-Verstöße behebst''' – so bleibt das ISMS dynamisch und anpassbar an neue Risiken.

'''Unterschied zu BSI-Standard 200-2:''' Im Gegensatz zur reaktiven 200-2-Verbesserung (nach Risikoanalyse) schließt Grundschutz++ den PDCA-Act-Zyklus modellbasiert ab, mit systematischer Integration von Audit-Ergebnissen ins Anforderungspaket und automatisierbarer Wirksamkeitsprüfung – prozessorientierter und weniger manuell.
# '''Nicht-Konformitäten''' analysieren
# '''Verbesserungspotenziale''' identifizieren
# '''Korrektur-/Verbesserungsplan''' → in Umsetzungsplan integrieren
# '''Wirksamkeit prüfen''' nach Umsetzung
# '''Sicherheitsniveau''' bewerten (Trendanalyse)
# '''Compliance-Verstöße''' behandeln

'''Ergebnis''': Aktualisiertes Anforderungspaket → neuer PDCA-Zyklus

'''Weiterführende Informationen:'''

*

=== Praktische Hinweise ===
* '''Tool-gestützt''': JSON/OSCAL-Bausteine, Zur Nutzung sind ISMS-Tools empfohlen.
* '''Iteration''': Wichtigster Geschäftsprozess zuerst, dann schrittweise erweitern
* '''Risikobetrachtung''': Bei Sicherheitsniveau "hoch" oder Nicht-Umsetzung
* '''Dokumentation''': bevorzugt Maschinenlesbar (OSCAL) für besseren Austausch

'''Zyklusdauer''': Jährlich oder ereignisgesteuert (Änderungen, Vorfälle, Audits)

== Migration bestehender Sicherheitskonzepte ==
...

'''Weiterführende Informationen:'''

[[Grundschutz++ Migration]]

== Offenen Punkte und Kritiken ==

=== Zu viele Beteiligte, unklare Zuständigkeiten ===
Die Weiterentwicklung des Grundschutzes wird inzwischen nicht mehr ausschließlich vom Grundschutz-Referat des BSI verantwortet. Mit dem Einstieg des Referats „Stand der Technik“ und der verstärkten Einbindung der „Community“ sind die Zuständigkeiten und Verantwortlichkeiten unklarer geworden. In Präsentationen und Veröffentlichungen werden die Rollen und Aufgaben der verschiedenen Beteiligten unterschiedlich dargestellt. Es fehlt eine klare, kommunizierte Schnittstelle, wer für welche Aspekte der Entwicklung, Pflege und Kommunikation des neuen Standards verantwortlich ist. Das erschwert für Anwendende die Orientierung und die Planung der eigenen Umsetzungsstrategie.

=== Unklare Umsetzung einiger Ziele ===
Einige der im Grundschutz++ adressierten Ziele und Neuerungen sind nach wie vor nicht ausreichend konkretisiert. Besonders die Einführung von Leistungskennzahlen und die Priorisierung der Anforderungen (Stufen) werfen noch viele Fragen auf. Die konkrete Bedeutung, Messung und praktische Umsetzung dieser Leistungskennzahlen werden von verschiedenen BSI-Vertretern unterschiedlich dargestellt. Auch die Stufenmodelle werden teils als Priorisierung, als Entwicklungsstufen oder als reiner Umsetzungaufwand der Anforderungen definiert und sind in ihrer praktischen Anwendung noch nicht abschließend geklärt. Das führt zu Unsicherheiten, wie diese neuen Instrumente im einem ISMS umgesetzt und nachgewiesen werden sollen.

=== Geringer Mehrwert im Vergleich zu ISO 27001 ===
Die Anforderungen im Grundschutz++ werden zunehmend an die Formulierungen und Strukturen der ISO 27001 angeglichen. Während der klassische IT-Grundschutz durch seine konkreten, praxisnahen Maßnahmen einen klaren Mehrwert gegenüber der eher abstrakten ISO 27001 bot, verliert er durch die Harmonisierung mit internationalen Standards zunehmend diesen Vorteil. Die Anforderungen werden stärker abstrakt modularisiert formuliert, wodurch der spezifische Bezug zu typischen Umsetzungsbeispielen und die Detailtiefe abnehmen. Für viele Organisationen wird sich daher die Frage stellen, warum sie den immer noch aufwändigeren Weg über den Grundschutz wählen sollten, wenn sie mit ähnlichem oder geringeren Aufwand direkt eine ISO 27001-Zertifizierung anstreben können.

=== Zu ambitionierter Zeitplan ===
Der Grundschutz++ sollte ab dem 1.1.2026 grundsätzlich gültig und anwedbar sein, wobei eine Übergangsphase bis 2029 vorgesehen war. Bisher ist nur ein erster Entwurf veröffentlicht. Angesichts der Vielzahl an noch offenen Fragen, der fehlenden Migrationsstrategie und der Komplexität der Änderungen erscheint der Zeitplan sehr ambitioniert. Ausarbeitung und Dokumentation liegen bisher nur als Entwurf vor. Eine Pilotierung und Einführung 2026 und eine Übergangsphase bis 2029 ist vorgesehen. Die Gefahr besteht, dass größere Organisationen unter Zeitdruck unzureichend vorbereitet in die neue Methodik wechseln und mit variablen Definitionen und Zielen arbeiten müssen, was die Akzeptanz und Qualität der Umsetzung gefährdet.

=== Zunehmende (Sicherheits-)Lücke zwischen Grundschutz und Grundschutz++ ===
Mit der Entscheidung des BSI, den bisherigen IT-Grundschutz (Edition 2023) nicht mehr weiterzuentwickeln und stattdessen auf das neue Grundschutz++-Modell zu setzen, entsteht eine wachsende Lücke in der Informationssicherheit. Diese Übergangsphase bis 2029 ist sicherheitstechnisch kritisch, da sich die Bedrohungslage in der IT nicht an Entwicklungszyklen von Sicherheitsstandards orientiert. Neue Angriffsvektoren, insbesondere durch den zunehmenden Einsatz von KI in der Cyberkriminalität (z.B. KI-gestützte Malware, Deepfakes, automatisierte Phishing-Kampagnen), entstehen kontinuierlich und erfordern zeitnahe, wirksame Gegenmaßnahmen. Der bisherige Grundschutz bildet diese aktuellen Bedrohungen und technologische Entwicklungen jedoch nicht mehr ab, während die spezifischen Module und Maßnahmen im Grundschutz++ noch nicht produktiv verfügbar oder praxistauglich sind.

=== Fehlende Migration vom Grundschutz-Kompendium zu Grundschutz++ ===
Aktuell existiert weder ein konkreter Plan noch ein Konzept für eine (teil-)automatisierte Migration bestehender Sicherheitskonzepte aus dem bisherigen Grundschutz-Kompendium in das neue Grundschutz++-Modell. Die Umstellung auf ein maschinenlesbares JSON/OSCAL-Format und die objektorientierte, prozessorientierte Struktur bedeuten einen fundamentalen Bruch mit bisherigen Strukturen. Die Unterschiede zwischen Grundschutz-Kompendium und Grundschutz++ sind gravierender als beim letzten Wechsel von den Grundschutz-Katalogen zum Kompendium, bei dem bereits alle Ansätze für eine automatisierte Migration weitgehend gescheitert sind. Auch diesmal ist absehbar, dass Organisationen ihre bestehenden Dokumentationen und Umsetzungen weitgehend manuell neu abbilden müssen, was insbesondere für größere Verbünde einen erheblichen Zusatzaufwand bedeutet. Es gibt zwar Ansätze dies mittels KI zu lösen, was aber sicher nicht für jede Organisation praktikabel sein wird.

=== Überholte Satzschablonen ===
Satzschablonen waren vor OSCAL ein erster Versuch, Anforderungen durch eine feste Syntax maschinenlesbar vorzubereiten. OSCAL macht sie jedoch überflüssig, da Praktiken und Zielobjektkategorien flexibel in Metadaten (props, groups, links) abgebildet und gefiltert werden können. So lassen sich Anforderungstexte natürlich formulieren. Das verbessert die Lesbarkeit für Mitarbeitende und Tools gleichermaßen. GS++ verwendet dennoch weiterhin diese sperrige Satzschablonen-Syntax für Anforderungen, was umfangreiche Erläuterungstexte erfordert.

== Fazit ==
Ein abschließendes Bild zum Grundschutz++ lässt sich aktuell noch nicht zeichnen – viele Details sind noch in der Entwicklung.

Die grundlegende Modernisierung des IT-Grundschutzes durch das Grundschutz++-Projekt ist zwar fachlich und technologisch nachvollziehbar und adressiert viele Schwächen des bisherigen Systems. Die Umsetzung ist jedoch nach jetzigem Entwicklungsstand mit erheblichen Risiken und Unsicherheiten verbunden. Ohne klare Migrationspfade, eindeutige Zuständigkeiten und praxistaugliche Konkretisierungen der neuen Instrumente besteht die Gefahr, dass die Akzeptanz des Grundschutzes sinkt und Organisationen sich vermehrt alternativen Standards wie der ISO 27001 zuwenden. Ein realistischer Zeitplan und ein echter Mehrwert des neuen Standards sind daher essenziell für den Erfolg der Reform.

Der Artikel wird fortlaufend aktualisiert, sobald neue Informationen vom BSI veröffentlicht oder freigegeben werden.
===Ausblick und ToDos aus Anwendersicht===
Stichtag für die Einführung von Grundschutz++ war der '''1.1.2026'''. Das Datum wurde vom BSI in offiziellen Ankündigungen, Präsentationen und Fachveranstaltungen als verbindlicher Startpunkt kommuniziert. Ab diesem Zeitpunkt sollte das neue, digitale und prozessorientierte Regelwerk den bisherigen IT-Grundschutz ablösen. Bisher fehlt es jedoch an vielen Stellen an klaren Definitionen und konkreten Vorgaben zur Methodik.

Auch wenn abzuwarten bleibt, wann praxistaugliche Methoden verfügbar sind und wie lange die Übergangsfristen für die Umstellung sein werden (aktuelle Planung bis 2029). Abzusehen ist jedoch, dass der Aufwand und der Zeitdruck, insbesondere für größere und zertifizierte Verbünde, erheblich sein werden. Auch wenn es aktuell noch keine konkreten Beschreibungen zur Methodik und Modellierung gibt, können und sollten sich Anwender bereits jetzt vorbereiten. Dazu können die folgenden Maßnahmen dienen:
*Laufende Information über den aktuellen Stand (Internetseiten des BSI, Vorträge und Veröffentlichungen).
*Konsolidierung der bestehenden Verbünde (Reduzierung der Komplexität, konsistente Dokumentation der Gruppierung und Modellierung).
**Ein guter Tip ist es, in aktuellen GSC jede Teilanforderung (jedes Modalverb wie MUSS oder SOLLTE) in der Umsetzung einzeln zu dokumentieren, da diese zukünftig eigenständige Anforderungen darstellen und so eine Übernahme leichter werden könnte.
*Kontakt zu Toolherstellern aufnehmen und eine zügige Umsetzung in den verwendeten ISMS-Tools einfordern.
*Frühzeitige Planung der Bereitstellung entsprechender personeller Ressourcen für die Umstellung auf Grundschutz++ ab Mitte 2026.
*Gegebenenfalls frühzeitige Reservierung externer (personeller) Ressourcen zur Unterstützung.
*Es muss eine klare interne Kommunikation über die bevorstehenden, durch die Umstellung bedingten erhöhten Aufwände (Schulungen, neue (Erst-)GSCs und Anpassung der Dokumentation) geben, damit Mitarbeitende und Verantwortliche wissen, was auf sie zukommt.

== Weiterführende Ressourcen ==
*[https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html BSI IT-Grundschutz]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html BSI Leitfaden zur Grundschutz++-Methodik (1.4.2026)]
*[https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/Grundschutz/1GS_Tag_2025/Aktuelle_Entwicklungen_Ausblick_IT-GS.pdf Aktuelle Entwicklungen und Ausblick zum IT-Grundschutz - 1. Grundschutztag 2025]
*[https://www.youtube.com/watch?v=_AeWJ_Z8S-4 Keynote: Fortentwicklung des IT-Grundschutzes zu IT-Grundschutz++ (verinice.XP 2025)]
*[https://www.youtube.com/watch?v=fBXuhELODGA Vortrag: "Keynote und Vision Grundschutz++" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.youtube.com/watch?v=PxOjkV6oUwU Vortrag "Grundschutz++ Methodik und Einstieg ins BCM" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.bsi.bund.de/dok/it-sa Am Mittwoch, 08.10.2025 werden auf der it-sa die von den Arbeitsgruppen aus der Community erarbeiteten Ergebnisse präsentiert.]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]
*[[Grundschutz++ Migration|Migrationsstrategie für den Umstieg von BSI IT-Grundschutz auf Grundschutz++]]

[[Kategorie:Artikel]]
[[Kategorie:Grundschutz]]
[[Kategorie:++]]

Grundschutz++ Einführung und Aufbau

2026-04-04T18:10:54Z

Dirk: /* Schritt 1: Erhebung und Planung (PLAN - Governance/Compliance) */

[[Datei:Teamwork-2198961.png|alternativtext=Zahnrad|rechts|240x240px]]{{#seo:
|title=Grundschutz++ Einführung und Anleitung
|keywords=ISMS, Wiki, BSI Grundschutz++, IT-Grundschutz, BSI-Standard 200-2, Bausteine, OSCAL, JSON, Informationssicherheit, Risikomanagement, Anforderungen
|description=Überblick über den neuen BSI Grundschutz++. Startseite zur Navigation durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.
}}{{SHORTDESC:Grundschutz++ Überblick und Anleitung}}''Dieser Artikel bietet einen schrittweisen Überblick über BSI '''Grundschutz++''' und navigiert durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.''

== Einführung in Grundschutz++ ==
'''Grundschutz++''' ist die 2026 vom BSI eingeführte Weiterentwicklung des IT-Grundschutz-Kompendiums. Es transformiert das bewährte Grundschutz-Konzept in ein vollständig digitales, maschinenlesbares Format mit JSON-basierten Bausteinen und OSCAL-kompatibler Struktur.<blockquote>
''Der aktuelle Stand von Grundschutz++ ist bisher nur sehr eingeschränkt praktisch anwendbar, da einige wesentliche Definitionen und Teile der Methodik noch fehlen. Dazu gehören beispielsweise die Nutzung von Kennzahlen, Blaupausen, Stufen, Schutzbedarf vs. Schutzniveau und die Modellierung.''

''Der Anforderungskatalog liegt zwar im OSCAL- und Excel-Format vor, ist ohne eine abgeschlossene und nachvollziehbare Methodik aber nicht sinnvoll anwendbar.''
</blockquote>
=== Wesentliche Neuerungen===
*'''OSCAL/JSON-basiertes Regelwerk''': Der IT-Grundschutz wird in ein maschinenlesbares '''JSON-Format''' überführt, das teilweise automatisierte Compliance-Prüfungen und Integrationen in bestehende IT-Systeme ermöglicht. Dies ersetzt die bisherigen textbasierten PDFs und Listen.
*'''Prozessorientierte Struktur''': Die neue Version ist modular und objektorientiert aufgebaut, um Redundanzen zu reduzieren und die Dokumentationslast zu verringern.
*'''Leistungskennzahlen''': Kennzahlen sollen die Informationssicherheit messbar und den Sicherheitsgewinn einzelner Anforderungen transparenter machen.
* '''Harmonisierung mit ISO 27001''': Die Anforderungen werden stärker mit internationalen Standards wie '''ISO 27001:2022''' abgestimmt, um Doppelzertifizierungen zu vereinfachen.
*'''Erweiterung um moderne Technologien''': Geplant sind auch spezifische Module für '''Cloud-Security, KI und IoT''', die aktuelle Bedrohungsszenarien abdecken.
===Ziele der Reform===
*'''Schlankere Prozesse''': Durch Automatisierung soll der administrative Aufwand sinken.
*'''Dynamische Anpassung''': JSON ermöglicht schnellere, ggf. automatisierte Updates bei neuen Cyberbedrohungen.
*'''Praxisorientierte Vereinfachung''': Der BSI will die Dokumentationslast reduzieren und den Fokus auf risikobasierte Ansätze legen, insbesondere für KMU.
*'''Priorisierung und Messbarkeit''': Durch eine stufenweise Priorisierung von Anforderungen und Leistungskennzahlen soll ein zielgerichteteres Vorgehen und die bessere Messbarkeit der Sicherheit gefördert werden.
Die Änderungen reagieren auf Kritik an der bisherigen Komplexität und sollen besonders KMU entlasten, während die ganzheitliche Sicherheitsmethodik (technisch, organisatorisch, personell) erhalten bleibt.

''Hinweis'': Details zur finalen Struktur werden schrittweise im Jahr 2026 veröffentlicht. Unternehmen sollten sich frühzeitig mit den geplanten Schnittstellen (z.B. für Security-Tools) vertraut machen.

Offizieller '''Starttermin''' für den Grundschutz++ war der '''1.1.2026'''. Danach ist allerdings eine längere Übergangsphase (bis 2029) geplant, in der beide Standards parallel genutzt werden können, so wie bei der letzten Modernisierung auch. Da jedoch zu erwarten ist, dass eine automatisierte Migration auch diesmal nicht oder nur eingeschränkt möglich sein wird, sollte speziell in größeren Verbünden rechtzeitig begonnen werden! Der jeweils aktuellen Grundschutz++ Katalog wird auf [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek GitHub] veröffentlicht.
=== Bedeutung von OSCAL im Grundschutz++ ===
Das zugrundeliegende Format für Grundschutz++ ist [[OSCAL]].

[[OSCAL]] ist ein '''Framework''' bzw. eine '''Datenmodellierungssprache''', die vom NIST speziell für Sicherheitsanforderungen und Compliance-Dokumentation entwickelt wurde. OSCAL definiert dabei nur ein festes Schema für Sicherheits- und Compliance-Daten und lässt das zugrundeliegende Datenformat (JSON, XML oder YAML) offen.

Das BSI hat sich beim Grundschutz++ für das Datenformat '''JSON''' entschieden.

Dies ermöglicht es mit entsprechenden Tools Sicherheitsanforderungen automatisiert einzulesen und zu bearbeiten. D.h.

* Anforderungen können (teil-)automatisiert von entsprechenden Tools bearbeitet und dokumentiert werden, sofern entsprechende Tools zur Verfügung stehen oder vom Anwender (ggf. Dienstleister) programmiert werden.
* Kataloge und Sicherheitskonzepte (SSPs) können zwischen ISMS-Tools herstellerunabhängig ausgetauscht werden (sofern Toolhersteller sich an den Standard halten und entsprechende Im- und Exportfonktionen in ihren Tools zur Verfügung stellen).

Das heißt aber nicht:

* Das Anwender, Sicherheitsmanager oder Sicherheitsbeauftragte OSCAL lernen müssen oder OSCAL Formate lesen können müssen. (Dafür gibt es Tools, die die Inhalte lesbar und bearbeitbar zur Verfügung stellen)
* Das alle Anforderungen automatisiert erfüllt und dokumentiert werden (viele Anforderungen sind nach wie vor organisatorische Anforderungen die nur von Menschen durch Erstellung und Beachtung entsprechenden Regelungen erfüllt werden können).
* Das überhaupt irgendwelche Anforderungen automatisiert erfüllt und dokumentiert werden (Hierzu müssten die Systeme an ein ISMS-Tool angebunden sein und diese über entsprechende Schnittstellen mit Informationen bedienen). Sowohl die Tools als auch die Schnittstellen werden absehbar nicht vom Himmel fallen.
===Satzschablonen===
Anforderungen werden im Grundschutz++ zukünftig mit Satzschablonen erstellt, die wie folgt aussehen:<blockquote><big>'''<span style="color:green">{Praktik} [für {Zielobjektkategorie}]</span> <span style="color:red">{MODALVERB}</span> <span style="color:blue"><Ergebnis></span> <span style="color:purple">{Handlungswort}</span>''' ''<span style="color:grey">(TAGs) (Hinweise)</span>''</big></blockquote>'''Praktik''': Ein Prozess im Rahmen des ISMS, eine konkrete Sicherheitsmaßnahme oder eine allgemeine Vorgehensweise zur Erreichung eines Sicherheitsziels (z.B. IT-Betrieb, Personal, Konfiguration) - Im weitesten Sinne vergleichbar mit den bisherigen Bausteinen. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/practices.csv Liste der gültigen Praktiken.]

'''Zielobjektkategorie''': Wie bisher, das Objekt oder die Entität, auf die sich die Sicherheitsanforderungen beziehen (z.B. Daten, Personen, Endgeräte, Hostsysteme). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/target_object_categories.csv Liste der Gültigen Zielobjektkategorien.]

'''Modalverb''': Gibt die Verbindlichkeit einer Anforderung an (MUSS, SOLLTE, KANN). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/modal_verbs.csv Liste der gültigen Modalverben.]

'''Ereignis''': Der sicherheitsrelevante Zustand oder Auslöser, der zu einer bestimmten Handlung führt - Entspricht in Verbindung mit dem Handlungswort dem wesentliche Inhalt der Anforderung.

'''Handlungswort''': Das Verb, das die konkrete Sicherheitsmaßnahme oder Art der Tätigkeit beschreibt (regeln, zuweisen, konfigurieren). Handlungsworte können auch zur besseren Filterung genutzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/action_words.csv Liste der gültigen Handlungsworte.]

Das ganze kann noch mit '''TAG'''s für eine bessere Gruppierung und mit einem '''Hinweis''' zu weiterführenden Informationen ergänzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/tags.csv Liste der gültigen TAGs.]

Die bisherigen Anforderungen des Kompendium werden aktuell in ihre Teilanforderungen zerlegt und jede Teilanforderung wird zukünftig eine eigene Anforderung. D.h. jedes Modalverb (SOLL, MUSS, KANN) der bisherigen Anforderungen stellt zukünftig i.d.R. eine eigene Anforderung dar. Die Gesamtanzahl der Anforderungen soll dabei durch die Vermeidung von Redundanzen dennoch sinken.

'''Beispiel'''

Die Anforderung:<blockquote>'''ISMS.1.A4 Benennung eines oder einer Informationssicherheitsbeauftragten (B) [Institutionsleitung]'''

Die Institutionsleitung MUSS einen oder eine ISB benennen. '''. . .'''

Die Institutionsleitung MUSS den oder die ISB mit angemessenen Ressourcen ausstatten.

Die Institutionsleitung MUSS dem oder der ISB die Möglichkeit einräumen, bei Bedarf direkt an sie selbst zu berichten. '''. . .'''</blockquote>Wird jetzt zu den Anforderungen:<blockquote>'''GOV.4.2''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">einer Person die Rolle ISB</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.2.3''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">für das ISMS erforderliche personelle, finanzielle und zeitliche Ressourcen</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.4.4''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">dem ISB das direkte und jederzeitige Vorspracherecht bei der Institutionsleitung</span> '''<span style="color:purple">ermöglichen</span>.'''</blockquote>Da dies übergreifende Anforderungen sind, ist hier kein spezifisches Zielobjekt benannt.

Einzelne Teilanforderungen können auch in anderen Praktiken beschrieben sein.
===Priorisierung===
Alle Anforderungen werden einer Prioritätsstufe zugeordnet, um die Umsetzung effizient zu gestalten:
*'''Stufe 0''': Zwingend (sofort) umzusetzende Anforderungen zur Sicherstellung der ISO-Kompatibilität (MUSS-Anforderungen).
Die Stufen 1-4 geben den Umsetzungsaufwand der Anforderungen wieder:
*'''Stufe 1''': Schnell und mit geringem Aufwand (~1 Tag) realisierbare Maßnahmen (QuickWin) / keine laufenden Aufwände.
*'''Stufe 2''': Mit eigenen Mitteln leicht umsetzbare Anforderung (~1 Woche) / geringe laufende Aufwände.
*'''Stufe 3''': Mit normalem Aufwand (mehrere Wochen) und ggf. externer Unterstützung umsetzbar / normale laufende Aufwände.
*'''Stufe 4''': Höherer Umsetzungsaufwand, häufig in längerfristigen Projekten mit externen Experten.
Die nächste Stufe sind optionale Anforderungen als Vorschläge bei erhöhtem Schutzbedarf.
*'''Stufe 5''': Umfassende/zusätzliche Anforderungen für höheren Schutzbedarf.
Diese Einstufung ermöglicht eine schnelle Einschätzung des Umsetzungsaufwands und hilft bei der effizienten Ressourcenplanung.
===Leistungskennzahlen===
Leistungskennzahlen dienen der '''Messung und Bewertung''' der Umsetzung von Sicherheitsanforderungen im Grundschutz++. Sie ermöglichen eine objektive Einschätzung des Sicherheitsniveaus und unterstützen die kontinuierliche Verbesserung. Wie diese Leistungskennzahlen genutzt werden sollen ist nach wie vor unklar und viele Anforderungen sind bislang noch nicht bewertet.
====Bewertungskriterien====
Jede Anforderung wird in Bezug auf die drei Schutzziele bewertet:
*'''Vertraulichkeit (C)'''
*'''Integrität (I)'''
*'''Verfügbarkeit (A)'''
Anforderungen erhalten Punktwerte in diesen Kategorien, die zur Bestimmung des Schutzgrades genutzt werden (z.B. C=6, I=2, A=0 ist eine Anforderung die im Wesentlichen die Vetraulichkeit stärkt, in Teilen die Intgrität aber nicht die Verfügbarkeit).

Die einzelen Kennzahlen werden je Schutzziel, Praktik und/oder Zielobjekt aufsummiert und ergeben so den Erfüllungsgrad.
====Schwellwerte und Erfüllungsgrad====
*'''Schwellwerte''' definieren das angestrebte Sicherheitsniveau basierend auf der Summe der Punktwerte aller umgesetzten Anforderungen je Schutzziel, Zielobjekt und Schutzstufe.
*'''Der Erfüllungsgrad''' zeigt, welche Anforderungen bereits umgesetzt wurden.
Die Leistungskennzahlen bieten damit eine fundierte Entscheidungsgrundlage für Organisationen, um ihren Sicherheitsstatus gezielt zu verbessern, wenn sie wie ursprünglich geplant eingeführt werden.
==Was bleibt erhalten?==
===Standards und Vorgehen===
Trotz eines deutlich anderen Formats und einer anderen Gruppierung der Anforderungen bleibt das grundsätzliche Vorgehen weitgehend gleich.

D.h. die Standards 200-1 bis 200-4 sollen erst einmal weiter Verwendung finden. Die bisher üblichen Arbeitsschritte:
#Festlegung des Geltungsbereichs
#Strukturanalyse
#Schutzbedarfsfeststellung
#Modellierung
#IT-Grundschutzcheck (GSC)
#Risikoanalyse
bleiben grundsätzlich erhalten, ändern sich jedoch in der praktischen Anwendung und Priorität (insbesondere in der '''Modellierung''' und den '''Grundschutzchecks'''). Parallel zur Einführung sollen die Standards weiter entwickelt werden.

'''MUSS'''-Anforderungen sind weiterhin '''verpflichtend''' für eine Zertifizierung, sollen aber deutlich rediziert werden.

'''SOLLTE'''-Anforderungen bleiben auch weiter '''grundsätzlich verpflichtend''', können aber ggf. mit angemessener Begründung oder Ersatzmaßnahmen wegdiskutiert werden.

Lediglich '''KANN'''-Anforderungen sind optional.
===Tool-Einsatz===
Auch der Einsatz von ISMS-Tools wird weiterhin Bestand haben. Alle größeren Tool-Hersteller arbeiten mit Hochdruck an der Integration von Grundschutz++ in ihre Tools. Hier wird es perspektivisch Erleichterungen durch einen leichteren Datenaustausch zwischen den Tools und mehr Automatisierungspotential geben.
==Gegenüberstellung Grundschutz Kompendium vs. Grundschutz++==
Das IT-Grundschutz-Kompendium 2023 und der zukünftige Grundschutz++ bieten unterschiedliche Konzepte für die Umsetzung von Informationssicherheit: Während das Kompendium auf feste Bausteine in thematisch gegliederten Schichten setzt, verwendet Grundschutz++ modulare, flexibel einsetzbare Praktiken.

Die folgende Tabelle stellt die wesentlichen Unterschiede und Gemeinsamkeiten zwischen beiden Ansätzen (nach aktuell verfügbaren Kenntnissen) gegenüber:
{| class="wikitable"
|+
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Fester verbindlicher Katalog''' von Anforderungen (PDF, Excel und XML), die je nach Reifegrad erfüllt werden müssen.
|Der '''variable''' und erweiterbare '''[[OSCAL]]'''-Datenbestand kann beliebig an die Bedürfnisse der Organisation angepasst werden. Zusätzliche Kataloge/Erweiterungen (C5, Datenschutz, KRITIS/NIS2) können je nach Verfügbarkeit ergänzt werden. Durch die Beseitigung vermeintlicher Redundanzen soll die Anzahl der Anforderungen erheblich reduziert werden (~10–20 % verbleibende Anforderungen gegenüber dem Grundschutz Kompendium).
|-
|
|Järliche '''Aktualisierung''' zum Stichtag '''1. Februar'''.
(bis 2023)
|Die '''Aktualisierung''' erfolgt '''fortlaufend''' nach Bedarf und Verfügbarkeit. Die Regelungen zur Relevanz für Zertifizierungen sind bislang noch nicht bekannt.
|-
|
|Das Kompendium ist (Stand 2023) in 10 '''Schichten''' mit insgesamt 111 '''Bausteine''' gegliedert, die statisch die jeweiligen Anforderungen enthalten.
|'''Praktiken''' und '''''Zielobjektkategorien''''' (Achtung abweichende Bedeutung in GS++) sind allgemeinere und wiederverwendbare, sicherheitsrelevante Verfahren oder Anforderungen. Sie können modular und situationsabhängig einzelnen Assets zugeordnet werden.
Die voraussichtlich ca. 20 Praktiken liegen irgendwo zwischen Schichten und Bausteinen. Sie sind prozessorientierter, adressieren eher Zielgruppen oder Handlungstypen und sind nicht mehr starr bestimmten Zielobjektkategorien zugeordnet. Zielobjektkategorien entsprechen zukünftig eher den Bausteinen im alten Grundschutz. Die Definitionen der Begriffe sind nach wie vor im Fluß!
|-
|
|'''Drei Stufen''' (Vorgehensweisen): Basis, Standard, erhöhter Schutzbedarf bilden den Reifegrad der Organisation ab.
|Es sind zukünftig '''sechs Stufen''' (0–5) geplant, die sich weitgehend am Umsetzungsaufwand der jeweiligen Anforderung orientieren: Je kleiner die Stufe, desto schneller bzw. leichter ist die Anforderung umsetzbar (Quick Win). Eine qualitative Bewertung des Reifegrads muss zukünftig anders erfolgen (z.B. über Leistungskennzahlen).
Das '''Sicherheitsniveau''' gibt zukünftig an, in welchem Maß die definierten Sicherheitsziele erreicht sind. Es ergibt sich aus der wirksamen Umsetzung organisatorischer, technischer und personeller Anforderungen.

Unterschieden werden:
*'''Normales Sicherheitsniveau''': entspricht dem Stand der Technik
*'''Erhöhtes Sicherheitsniveau''': für besonders schutzbedürftige Informationen oder Systeme
|-
|
|'''Zielobjekte''' als gruppierte Sammlung von gleichartigen Assets die zur späteren '''Modellierung''' (Zuordnung der Bausteine und Abhängigkeiten) genutzt werden.
|'''Zielobjekte''' werden auch in Zukunft eine ähnliche Funktion zur Gruppierung und '''Modellierung''' haben, entsprechend dabei aber eher den klassischen Bausteinen. Die konkreten Vorgaben zur Modellierung sind jedoch noch nicht detailliert genug. In der Modellierung werden die Praktiken nicht mehr statisch bestimmten Zielobjekttypen zugewiesen. Klassische Zielobjekte werden zukünftig als Assets oder Assetgruppen bezeichnet.
|-
|
|Modalverben '''MUSS''', '''SOLLTE''', '''KANN''' bestimmen die Verbindlichkeit von Anforderungen.
|Die Bedeutung der Modalverben ('''MUSS, SOLLTE, KANN''') bleibt unverändert. Ein Ziel von Grundschutz++ ist es jedoch, die Anzahl der Muss-Anforderungen auf das Nötigste zu reduzieren (unter 10 %). Dadurch soll der Grundschutz flexibler werden. Die Verbindlichkeit von Anforderungen, die über MUSS-Anforderungen hinausgehen, ist noch unklar.
|-
|
| -
|Neu sind '''Leistungskennzahlen''', die eine qualitative Bewertung der Anforderungen in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit darstellen. Sie sollen als Zahlenwert darstellbar sein und so den Reifegrad abbilden können. Bisher ist noch nicht bekannt, ob und wann diese eingeführt werden und wie die konkreten Regelungen aussehen werden.
|-
|
|Gültigkeit voraussichtlich bis 2029
|Gültig ab 1.1.2026. Zertifizierbar geplant ab 2027.
|}Teilweise werden Begrifflichkeiten neu (oder anders) definiert:
{| class="wikitable"
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Zielobjekt''' als gruppierte Sammlung von gleichartigen Assets als Grundlage für die spätere Modellierung
|'''Asset''' und gruppierte Assets. Die Gruppierung gleichartiger Assets kann weiterhin erfolgen es bleiben jedoch auch dann '''Assets'''. Der Begriff ''Zielobjekt'' wird hierfür nicht mehr genutzt.
|-
|
|'''Baustein''' als Sammlung von Anforderungen für bestimmte Zielobjekttypen.
|'''Zielobjektkategorien''' sind zukünftig das was bislang die ''Bausteine'' waren, bestimmte Typen von Assets für die spezische Anforderungen gelten. Die Assets werden den Zielobjektkategorien zugewisen und erhalten über diese ihre Anforderungen. Eine klare Definition der Begriffe ist noch im Fluß.
|-
|
|
|
|}
==Blaupausen==
Blaupausen sind vorgefertigte Musterlösungen (wie die bisherigen IT-Grundschutz-Profile), die als Vorlage (Referenzmodell) für die Erstellung und Umsetzung von branchenspezifischen oder organisationsspezifischen Sicherheitskonzepten dienen.
===Funktion der Blaupausen===
Solche Blaupausen erfassen typische Strukturen, Risiken, Anforderungen und Maßnahmen für bestimmte Anwendungsszenarien, etwa die Nutzung der E-Akte oder den sicheren Betrieb von 5G-Infrastrukturen. Sie ermöglichen es, ein ISMS deutlich effizienter und strukturierter aufzubauen, weil die grundlegenden Überlegungen (Schutzbedarfsermittlung, Zuordnung von Praktiken, Zielobjekten und Maßnahmen, etc.) bereits allgemein gültig vorformuliert sind und nur noch organisationsspezifisch angepasst werden müssen.
===Ziel und Nutzen===
*Blaupausen helfen, den Implementierungsaufwand für ISMS nach Grundschutz++ zu reduzieren.
*Sie fördern die Standardisierung und Wiederverwendbarkeit von Sicherheitskonzepten für ähnliche Organisationen oder Branchen.
*Besonders für kleinere Organisationen und typische Anwendungsfälle bieten sie einen niederschwelligen, strukturierten und praxiserprobten Einstieg in die Absicherung.
Damit sind Blaupausen im Grundschutz++ zentrale Instrumente, um bewährte Sicherheitsmethoden als Vorlage für den schnellen und einheitlichen Aufbau eines branchenspezifischen ISMS bereitzustellen.
===Umsetzung===
Umgesetzt werden Blaupausen technische als '''OSCAL-Profile''' mit zusätzlichen Erläuterungen in Textform, zukünftig sollen Blaupausen zu einem '''System Security Plan (SSP)''' weiter entwickelt werden.
== Grundlagen und Standards ==

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_1.html BSI-Standard 200-1: Anforderungen an ein ISMS].
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_2.html BSI-Standard 200-2: IT-Grundschutz Methodik] ( <- Wird neu erstellt )
** [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html Methodik zum Grundschutz++] (Aktuell in Erstellung, ersetzt zukünftig 200-2)
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_3.html BSI-Standard 200-3: Risikomanagement mit Grundschutz].
* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/BSI-Standards/BSI-Standard-200-4-Business-Continuity-Management/bsi-standard-200-4_Business_Continuity_Management_node.html BSI-Standard 200-4: Business Continuity Management].
* [[OSCAL|OSCAL (Open Security Controls Assessment Language)]].

== Schritt-für-Schritt-Methodik ==
Die Methodik von Grundschutz++ folgt einem fünfstufigen, PDCA-basierten Prozess mit Fokus auf '''Anforderungsmodellierung''' und, wenn möglich, maschinenlesbarer Verarbeitung. Hier eine Kurzbeschreibung des praktischen Vorgehens:

=== Schritt 1: Erhebung und Planung (PLAN - Governance/Compliance) ===
Du legst hier die '''strategische Basis''' für Dein ISMS, indem du den '''Kontext deiner Organisation''' analysierst, '''Compliance-Pflichten''' (z.B. DSGVO, BDSG, brachenspezifische Gesetze und Regelungen) und '''Erwartungen interessierter Parteien''' (Kunden, Geschäftspartner, Behörden, Mitarbeitende) feststellst. Anschließend entwickelst du eine '''Informationssicherheitsleitlinie''' mit SMART-Zielen und einer '''Strategie''', definierst den '''Geltungsbereich des ISMS''' (Scope: welche Prozesse, Standorte, Systeme), klassifizierst den '''Schutzbedarf''' kritischer Geschäftsprozesse ("normal" oder "hoch"), richtest Rollen wie den '''unabhängigen ISB''' ein und initiierst '''Risikomanagement''' sowie '''Dokumentationspflichten''' – alles '''freigegeben von der Leitung'''.

'''Unterschied zu BSI-Standard 200-2:''' Während 200-2 mit Bausteinen und Risikoanalyse startet, integriert Grundschutz++ Governance und Compliance früher und stärker in den PDCA-Planungszyklus, mit Fokus auf maschinenlesbare Strukturen und Organisationsleitungspflicht – weniger asset-zentriert, mehr prozess- und rolleorientiert ab Schritt 1.
# '''Kontextanalyse''' (intern/extern) durchführen
# '''Interessierte Parteien''' identifizieren und Anforderungen erfassen
# '''Geltungsbereich''' (Scope) durch Organisationsleitung festlegen und freigeben
# '''Geschäftsprozesse''' priorisieren → Schutzbedarf "normal" oder "hoch" einstufen
# '''Sicherheitsleitlinie''' erstellen (Ziele, Strategie, Verpflichtung Leitung)
# '''Sicherheitsorganisation''' etablieren (Rollen: ISB, Asset-Owner, etc.)
# '''Compliance-Management''' initialisieren (Rechts-/Vertragskatalog)

'''Ergebnis''': Organisatorischer Rahmen, Sicherheitsleitlinie, priorisierte Prozesse

'''Weiterführende Informationen:'''

* [[Informationssicherheitsleitlinie]]
* [[IS-Strategie]]
* [[Geschäftsprozesse]]

=== Schritt 2: Anforderungsanalyse (PLAN - Strukturmodellierung) ===
Starte mit der '''Abgrenzung des Informationsverbunds''' (technische, organisatorische Einheit innerhalb des Geltungsbereichs), '''erfasse Assets''' (z.B. Server, Daten, Rollen) pro priorisiertem '''Geschäftsprozess''' und ordne sie '''Zielobjektkategorien''' zu (z.B. „Anwendung“ mit Vererbung übergeordneter Kategorien). Modelliere dann '''Anforderungen''' aus '''GS++-Praktiken''' ('''ISMS-weit''' plus assetbezogen), ergänze bei Bedarf '''externe Pflichten''' oder risikobasierte Anforderungen (nach Risikobetrachtung), prüfe das '''Sicherheitsniveau''' ("normal SdT" oder "erhöht") und treffe '''Gestaltungsentscheidungen''' (z.B. Parameter wie Zuständigkeiten) – Ergebnis: '''individuelles Anforderungspaket'''.

'''Unterschied zu BSI-Standard 200-2:''' Statt starrer Baustein-Zuordnung und manueller Risikoanalyse nutzt Grundschutz++ eine modellbasierte, hierarchische Anforderungsableitung via Assets und Zielobjektkategorien (OSCAL-fähig, maschinenlesbar), mit automatisierbarer Vererbung und klarer Trennung von Standard- (SdT) und ergänzenden Anforderungen – skalierbarer und zyklischer als die lineare 200-2-Methodik.
# '''Informationsverbund''' definieren (techn./org. Abgrenzung)
# '''Assets''' für wichtigsten Geschäftsprozess erfassen
# '''Asset → Zielobjektkategorien''' mapping (Hierarchie + Vererbung)
# '''Anforderungspaket''' generieren:
#* ISMS-Praktiken (vollständig)
#* Zielobjekt-Anforderungen (Sicherheitsniveau: normal/erhöht)
#* Zielobjektlose Anforderungen prüfen
# '''Ergänzungen''': Externe Verpflichtungen, anforderungslose Assets
# '''Risikobetrachtung''' bei hohem Schutzbedarf oder Niveauerhöhung
# '''Parameter setzen''' (Zuständigkeiten, Werte)

'''Ergebnis''': Individuelles Anforderungspaket pro Informationsverbund

'''Weiterführende Informationen:'''

* [[Strukturanalyse]]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das OSCAL-basierte Grundschutz++ Kompendium auf Github.]

=== Schritt 3: Realisierung (DO - Umsetzung) ===
In diesem Schritt '''setzt''' du das '''Anforderungspaket''' aus Schritt 2 '''um''', indem du den '''Ist-Zustand''' aller Anforderungen bewertest ('''Umsetzungsstatus''' ermittelst), fehlende Umsetzungen '''priorisierst''' (nach Risiko und Aufwand), einen '''Umsetzungsplan''' mit Zuständigkeiten und Fristen erstellst, '''Ausnahmen''' dokumentierst und freigibst sowie den Fortschritt verfolgst – inklusive '''Compliance-Sicherstellung''' durch regelmäßige '''Checks'''.

'''Unterschied zu BSI-Standard 200-2:''' Während 200-2 Maßnahmen aus Bausteinen direkt umsetzt und manuell dokumentiert, strukturiert Grundschutz++ die Realisierung zentral über das modellierte Anforderungspaket mit automatisierbarer Priorisierung und Nachverfolgung, stärker in den PDCA-Do-Zyklus eingebettet und skalierbar für große Verbünde.
# '''Umsetzungsstatus''' aller Anforderungen prüfen (ja/nein)
# '''Nicht-umgesetzte MUSS/SOLLTE''' → Risikobetrachtung
# '''Umsetzungsplan''' erstellen:
#* Priorisierung (Risiko, Aufwand, Synergien)
#* Zuständigkeiten + Fristen zuweisen
# '''Freigabe''' durch Institutionsleitung
# '''Fortschritt tracken''' (Ticketsystem/Projektmanagement)
# '''Ausnahmen dokumentieren''' (Begründung + Leitungsfreigabe)

'''Ergebnis''': Umsetzungsplan + Status-Dokumentation

'''Weiterführende Informationen:'''

* [[LF-Grundschutzcheck|Leitfaden Grundschutzcheck]]
* [[RiLi-Freigabe]]
* [[RiLi-Ausnahmemanagement|Richtlinie zum Management von Ausnahmen und Abweichungen]]

=== Schritt 4: Überwachung (CHECK - Monitoring/Evaluation) ===
Hier überprüfst du die '''Wirksamkeit''' des ISMS durch '''Leistungsbewertung''' (z.B. KPIs), '''Compliance-Monitoring''', '''Audits''' (mit Bewertungsschemata und Berichten), '''Management-Reviews''' und Validierung der Anforderungen gegen aktuelle Bedrohungen – Tools wie Monitoring-Software unterstützen die kontinuierliche Erfassung.

'''Unterschied zu BSI-Standard 200-2:''' Grundschutz++ erweitert die Überwachung (PDCA-Check) um maschinenlesbare Audit-Modelle und Validierung des Anforderungspakets, statt isolierter Baustein-Checks; es integriert dynamische Monitoring-Tools und Managementbewertungen enger, für zyklische Anpassung statt einmaliger Prüfung.
# '''Leistungsbewertung''' (KPIs, Umsetzungsfortschritt, Vorfälle)
# '''Compliance-Überwachung''' (gesetzlich/vertraglich)
# '''Auditprogramm''' risikobasiert durchführen
# '''Managementbewertung''' → Managementbericht erstellen
# '''Monitoring-Tools''' einsetzen (SIEM, Vulnerability Scanner)
# '''Anforderungspaket validieren''' (Aktualität prüfen)

'''Ergebnis''': Auditberichte, Managementbericht

'''Weiterführende Informationen:'''

* [[Reifegradmodell]]
* [[KPIs|Key Performance Indicators (KPIs)]]
* [[Managementbericht|Erstellen eines Managementberichts]]

=== Schritt 5: Kontinuierliche Verbesserung (ACT - Verbesserung) ===
Du behandelst hier deine '''Erkenntnisse''' aus Schritt 4, indem du Nicht-Konformitäten '''analysierst''', '''Verbesserungspotenziale''' '''identifizierst''', Korrektur- und Verbesserungspläne erstellst, deren '''Wirksamkeit prüfst''' und '''Compliance-Verstöße behebst''' – so bleibt das ISMS dynamisch und anpassbar an neue Risiken.

'''Unterschied zu BSI-Standard 200-2:''' Im Gegensatz zur reaktiven 200-2-Verbesserung (nach Risikoanalyse) schließt Grundschutz++ den PDCA-Act-Zyklus modellbasiert ab, mit systematischer Integration von Audit-Ergebnissen ins Anforderungspaket und automatisierbarer Wirksamkeitsprüfung – prozessorientierter und weniger manuell.
# '''Nicht-Konformitäten''' analysieren
# '''Verbesserungspotenziale''' identifizieren
# '''Korrektur-/Verbesserungsplan''' → in Umsetzungsplan integrieren
# '''Wirksamkeit prüfen''' nach Umsetzung
# '''Sicherheitsniveau''' bewerten (Trendanalyse)
# '''Compliance-Verstöße''' behandeln

'''Ergebnis''': Aktualisiertes Anforderungspaket → neuer PDCA-Zyklus

'''Weiterführende Informationen:'''

*

=== Praktische Hinweise ===
* '''Tool-gestützt''': JSON/OSCAL-Bausteine, Zur Nutzung sind ISMS-Tools empfohlen.
* '''Iteration''': Wichtigster Geschäftsprozess zuerst, dann schrittweise erweitern
* '''Risikobetrachtung''': Bei Sicherheitsniveau "hoch" oder Nicht-Umsetzung
* '''Dokumentation''': bevorzugt Maschinenlesbar (OSCAL) für besseren Austausch

'''Zyklusdauer''': Jährlich oder ereignisgesteuert (Änderungen, Vorfälle, Audits)

== Migration bestehender Sicherheitskonzepte ==
...

'''Weiterführende Informationen:'''

[[Grundschutz++ Migration]]

== Offenen Punkte und Kritiken ==

=== Zu viele Beteiligte, unklare Zuständigkeiten ===
Die Weiterentwicklung des Grundschutzes wird inzwischen nicht mehr ausschließlich vom Grundschutz-Referat des BSI verantwortet. Mit dem Einstieg des Referats „Stand der Technik“ und der verstärkten Einbindung der „Community“ sind die Zuständigkeiten und Verantwortlichkeiten unklarer geworden. In Präsentationen und Veröffentlichungen werden die Rollen und Aufgaben der verschiedenen Beteiligten unterschiedlich dargestellt. Es fehlt eine klare, kommunizierte Schnittstelle, wer für welche Aspekte der Entwicklung, Pflege und Kommunikation des neuen Standards verantwortlich ist. Das erschwert für Anwendende die Orientierung und die Planung der eigenen Umsetzungsstrategie.

=== Unklare Umsetzung einiger Ziele ===
Einige der im Grundschutz++ adressierten Ziele und Neuerungen sind nach wie vor nicht ausreichend konkretisiert. Besonders die Einführung von Leistungskennzahlen und die Priorisierung der Anforderungen (Stufen) werfen noch viele Fragen auf. Die konkrete Bedeutung, Messung und praktische Umsetzung dieser Leistungskennzahlen werden von verschiedenen BSI-Vertretern unterschiedlich dargestellt. Auch die Stufenmodelle werden teils als Priorisierung, als Entwicklungsstufen oder als reiner Umsetzungaufwand der Anforderungen definiert und sind in ihrer praktischen Anwendung noch nicht abschließend geklärt. Das führt zu Unsicherheiten, wie diese neuen Instrumente im einem ISMS umgesetzt und nachgewiesen werden sollen.

=== Geringer Mehrwert im Vergleich zu ISO 27001 ===
Die Anforderungen im Grundschutz++ werden zunehmend an die Formulierungen und Strukturen der ISO 27001 angeglichen. Während der klassische IT-Grundschutz durch seine konkreten, praxisnahen Maßnahmen einen klaren Mehrwert gegenüber der eher abstrakten ISO 27001 bot, verliert er durch die Harmonisierung mit internationalen Standards zunehmend diesen Vorteil. Die Anforderungen werden stärker abstrakt modularisiert formuliert, wodurch der spezifische Bezug zu typischen Umsetzungsbeispielen und die Detailtiefe abnehmen. Für viele Organisationen wird sich daher die Frage stellen, warum sie den immer noch aufwändigeren Weg über den Grundschutz wählen sollten, wenn sie mit ähnlichem oder geringeren Aufwand direkt eine ISO 27001-Zertifizierung anstreben können.

=== Zu ambitionierter Zeitplan ===
Der Grundschutz++ sollte ab dem 1.1.2026 grundsätzlich gültig und anwedbar sein, wobei eine Übergangsphase bis 2029 vorgesehen war. Bisher ist nur ein erster Entwurf veröffentlicht. Angesichts der Vielzahl an noch offenen Fragen, der fehlenden Migrationsstrategie und der Komplexität der Änderungen erscheint der Zeitplan sehr ambitioniert. Ausarbeitung und Dokumentation liegen bisher nur als Entwurf vor. Eine Pilotierung und Einführung 2026 und eine Übergangsphase bis 2029 ist vorgesehen. Die Gefahr besteht, dass größere Organisationen unter Zeitdruck unzureichend vorbereitet in die neue Methodik wechseln und mit variablen Definitionen und Zielen arbeiten müssen, was die Akzeptanz und Qualität der Umsetzung gefährdet.

=== Zunehmende (Sicherheits-)Lücke zwischen Grundschutz und Grundschutz++ ===
Mit der Entscheidung des BSI, den bisherigen IT-Grundschutz (Edition 2023) nicht mehr weiterzuentwickeln und stattdessen auf das neue Grundschutz++-Modell zu setzen, entsteht eine wachsende Lücke in der Informationssicherheit. Diese Übergangsphase bis 2029 ist sicherheitstechnisch kritisch, da sich die Bedrohungslage in der IT nicht an Entwicklungszyklen von Sicherheitsstandards orientiert. Neue Angriffsvektoren, insbesondere durch den zunehmenden Einsatz von KI in der Cyberkriminalität (z.B. KI-gestützte Malware, Deepfakes, automatisierte Phishing-Kampagnen), entstehen kontinuierlich und erfordern zeitnahe, wirksame Gegenmaßnahmen. Der bisherige Grundschutz bildet diese aktuellen Bedrohungen und technologische Entwicklungen jedoch nicht mehr ab, während die spezifischen Module und Maßnahmen im Grundschutz++ noch nicht produktiv verfügbar oder praxistauglich sind.

=== Fehlende Migration vom Grundschutz-Kompendium zu Grundschutz++ ===
Aktuell existiert weder ein konkreter Plan noch ein Konzept für eine (teil-)automatisierte Migration bestehender Sicherheitskonzepte aus dem bisherigen Grundschutz-Kompendium in das neue Grundschutz++-Modell. Die Umstellung auf ein maschinenlesbares JSON/OSCAL-Format und die objektorientierte, prozessorientierte Struktur bedeuten einen fundamentalen Bruch mit bisherigen Strukturen. Die Unterschiede zwischen Grundschutz-Kompendium und Grundschutz++ sind gravierender als beim letzten Wechsel von den Grundschutz-Katalogen zum Kompendium, bei dem bereits alle Ansätze für eine automatisierte Migration weitgehend gescheitert sind. Auch diesmal ist absehbar, dass Organisationen ihre bestehenden Dokumentationen und Umsetzungen weitgehend manuell neu abbilden müssen, was insbesondere für größere Verbünde einen erheblichen Zusatzaufwand bedeutet. Es gibt zwar Ansätze dies mittels KI zu lösen, was aber sicher nicht für jede Organisation praktikabel sein wird.

== Fazit ==
Ein abschließendes Bild zum Grundschutz++ lässt sich aktuell noch nicht zeichnen – viele Details sind noch in der Entwicklung.

Die grundlegende Modernisierung des IT-Grundschutzes durch das Grundschutz++-Projekt ist zwar fachlich und technologisch nachvollziehbar und adressiert viele Schwächen des bisherigen Systems. Die Umsetzung ist jedoch nach jetzigem Entwicklungsstand mit erheblichen Risiken und Unsicherheiten verbunden. Ohne klare Migrationspfade, eindeutige Zuständigkeiten und praxistaugliche Konkretisierungen der neuen Instrumente besteht die Gefahr, dass die Akzeptanz des Grundschutzes sinkt und Organisationen sich vermehrt alternativen Standards wie der ISO 27001 zuwenden. Ein realistischer Zeitplan und ein echter Mehrwert des neuen Standards sind daher essenziell für den Erfolg der Reform.

Der Artikel wird fortlaufend aktualisiert, sobald neue Informationen vom BSI veröffentlicht oder freigegeben werden.
===Ausblick und ToDos aus Anwendersicht===
Stichtag für die Einführung von Grundschutz++ war der '''1.1.2026'''. Das Datum wurde vom BSI in offiziellen Ankündigungen, Präsentationen und Fachveranstaltungen als verbindlicher Startpunkt kommuniziert. Ab diesem Zeitpunkt sollte das neue, digitale und prozessorientierte Regelwerk den bisherigen IT-Grundschutz ablösen. Bisher fehlt es jedoch an vielen Stellen an klaren Definitionen und konkreten Vorgaben zur Methodik.

Auch wenn abzuwarten bleibt, wann praxistaugliche Methoden verfügbar sind und wie lange die Übergangsfristen für die Umstellung sein werden (aktuelle Planung bis 2029). Abzusehen ist jedoch, dass der Aufwand und der Zeitdruck, insbesondere für größere und zertifizierte Verbünde, erheblich sein werden. Auch wenn es aktuell noch keine konkreten Beschreibungen zur Methodik und Modellierung gibt, können und sollten sich Anwender bereits jetzt vorbereiten. Dazu können die folgenden Maßnahmen dienen:
*Laufende Information über den aktuellen Stand (Internetseiten des BSI, Vorträge und Veröffentlichungen).
*Konsolidierung der bestehenden Verbünde (Reduzierung der Komplexität, konsistente Dokumentation der Gruppierung und Modellierung).
**Ein guter Tip ist es, in aktuellen GSC jede Teilanforderung (jedes Modalverb wie MUSS oder SOLLTE) in der Umsetzung einzeln zu dokumentieren, da diese zukünftig eigenständige Anforderungen darstellen und so eine Übernahme leichter werden könnte.
*Kontakt zu Toolherstellern aufnehmen und eine zügige Umsetzung in den verwendeten ISMS-Tools einfordern.
*Frühzeitige Planung der Bereitstellung entsprechender personeller Ressourcen für die Umstellung auf Grundschutz++ ab Mitte 2026.
*Gegebenenfalls frühzeitige Reservierung externer (personeller) Ressourcen zur Unterstützung.
*Es muss eine klare interne Kommunikation über die bevorstehenden, durch die Umstellung bedingten erhöhten Aufwände (Schulungen, neue (Erst-)GSCs und Anpassung der Dokumentation) geben, damit Mitarbeitende und Verantwortliche wissen, was auf sie zukommt.

== Weiterführende Ressourcen ==
*[https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html BSI IT-Grundschutz]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html BSI Leitfaden zur Grundschutz++-Methodik (1.4.2026)]
*[https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/Grundschutz/1GS_Tag_2025/Aktuelle_Entwicklungen_Ausblick_IT-GS.pdf Aktuelle Entwicklungen und Ausblick zum IT-Grundschutz - 1. Grundschutztag 2025]
*[https://www.youtube.com/watch?v=_AeWJ_Z8S-4 Keynote: Fortentwicklung des IT-Grundschutzes zu IT-Grundschutz++ (verinice.XP 2025)]
*[https://www.youtube.com/watch?v=fBXuhELODGA Vortrag: "Keynote und Vision Grundschutz++" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.youtube.com/watch?v=PxOjkV6oUwU Vortrag "Grundschutz++ Methodik und Einstieg ins BCM" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.bsi.bund.de/dok/it-sa Am Mittwoch, 08.10.2025 werden auf der it-sa die von den Arbeitsgruppen aus der Community erarbeiteten Ergebnisse präsentiert.]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]
*[[Grundschutz++ Migration|Migrationsstrategie für den Umstieg von BSI IT-Grundschutz auf Grundschutz++]]

[[Kategorie:Artikel]]
[[Kategorie:Grundschutz]]
[[Kategorie:++]]

Grundschutz++ Einführung und Aufbau

2026-04-04T18:08:51Z

Dirk: /* Schritt 1: Erhebung und Planung (PLAN - Governance/Compliance) */

[[Datei:Teamwork-2198961.png|alternativtext=Zahnrad|rechts|240x240px]]{{#seo:
|title=Grundschutz++ Einführung und Anleitung
|keywords=ISMS, Wiki, BSI Grundschutz++, IT-Grundschutz, BSI-Standard 200-2, Bausteine, OSCAL, JSON, Informationssicherheit, Risikomanagement, Anforderungen
|description=Überblick über den neuen BSI Grundschutz++. Startseite zur Navigation durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.
}}{{SHORTDESC:Grundschutz++ Überblick und Anleitung}}''Dieser Artikel bietet einen schrittweisen Überblick über BSI '''Grundschutz++''' und navigiert durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.''

== Einführung in Grundschutz++ ==
'''Grundschutz++''' ist die 2026 vom BSI eingeführte Weiterentwicklung des IT-Grundschutz-Kompendiums. Es transformiert das bewährte Grundschutz-Konzept in ein vollständig digitales, maschinenlesbares Format mit JSON-basierten Bausteinen und OSCAL-kompatibler Struktur.<blockquote>
''Der aktuelle Stand von Grundschutz++ ist bisher nur sehr eingeschränkt praktisch anwendbar, da einige wesentliche Definitionen und Teile der Methodik noch fehlen. Dazu gehören beispielsweise die Nutzung von Kennzahlen, Blaupausen, Stufen, Schutzbedarf vs. Schutzniveau und die Modellierung.''

''Der Anforderungskatalog liegt zwar im OSCAL- und Excel-Format vor, ist ohne eine abgeschlossene und nachvollziehbare Methodik aber nicht sinnvoll anwendbar.''
</blockquote>
=== Wesentliche Neuerungen===
*'''OSCAL/JSON-basiertes Regelwerk''': Der IT-Grundschutz wird in ein maschinenlesbares '''JSON-Format''' überführt, das teilweise automatisierte Compliance-Prüfungen und Integrationen in bestehende IT-Systeme ermöglicht. Dies ersetzt die bisherigen textbasierten PDFs und Listen.
*'''Prozessorientierte Struktur''': Die neue Version ist modular und objektorientiert aufgebaut, um Redundanzen zu reduzieren und die Dokumentationslast zu verringern.
*'''Leistungskennzahlen''': Kennzahlen sollen die Informationssicherheit messbar und den Sicherheitsgewinn einzelner Anforderungen transparenter machen.
* '''Harmonisierung mit ISO 27001''': Die Anforderungen werden stärker mit internationalen Standards wie '''ISO 27001:2022''' abgestimmt, um Doppelzertifizierungen zu vereinfachen.
*'''Erweiterung um moderne Technologien''': Geplant sind auch spezifische Module für '''Cloud-Security, KI und IoT''', die aktuelle Bedrohungsszenarien abdecken.
===Ziele der Reform===
*'''Schlankere Prozesse''': Durch Automatisierung soll der administrative Aufwand sinken.
*'''Dynamische Anpassung''': JSON ermöglicht schnellere, ggf. automatisierte Updates bei neuen Cyberbedrohungen.
*'''Praxisorientierte Vereinfachung''': Der BSI will die Dokumentationslast reduzieren und den Fokus auf risikobasierte Ansätze legen, insbesondere für KMU.
*'''Priorisierung und Messbarkeit''': Durch eine stufenweise Priorisierung von Anforderungen und Leistungskennzahlen soll ein zielgerichteteres Vorgehen und die bessere Messbarkeit der Sicherheit gefördert werden.
Die Änderungen reagieren auf Kritik an der bisherigen Komplexität und sollen besonders KMU entlasten, während die ganzheitliche Sicherheitsmethodik (technisch, organisatorisch, personell) erhalten bleibt.

''Hinweis'': Details zur finalen Struktur werden schrittweise im Jahr 2026 veröffentlicht. Unternehmen sollten sich frühzeitig mit den geplanten Schnittstellen (z.B. für Security-Tools) vertraut machen.

Offizieller '''Starttermin''' für den Grundschutz++ war der '''1.1.2026'''. Danach ist allerdings eine längere Übergangsphase (bis 2029) geplant, in der beide Standards parallel genutzt werden können, so wie bei der letzten Modernisierung auch. Da jedoch zu erwarten ist, dass eine automatisierte Migration auch diesmal nicht oder nur eingeschränkt möglich sein wird, sollte speziell in größeren Verbünden rechtzeitig begonnen werden! Der jeweils aktuellen Grundschutz++ Katalog wird auf [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek GitHub] veröffentlicht.
=== Bedeutung von OSCAL im Grundschutz++ ===
Das zugrundeliegende Format für Grundschutz++ ist [[OSCAL]].

[[OSCAL]] ist ein '''Framework''' bzw. eine '''Datenmodellierungssprache''', die vom NIST speziell für Sicherheitsanforderungen und Compliance-Dokumentation entwickelt wurde. OSCAL definiert dabei nur ein festes Schema für Sicherheits- und Compliance-Daten und lässt das zugrundeliegende Datenformat (JSON, XML oder YAML) offen.

Das BSI hat sich beim Grundschutz++ für das Datenformat '''JSON''' entschieden.

Dies ermöglicht es mit entsprechenden Tools Sicherheitsanforderungen automatisiert einzulesen und zu bearbeiten. D.h.

* Anforderungen können (teil-)automatisiert von entsprechenden Tools bearbeitet und dokumentiert werden, sofern entsprechende Tools zur Verfügung stehen oder vom Anwender (ggf. Dienstleister) programmiert werden.
* Kataloge und Sicherheitskonzepte (SSPs) können zwischen ISMS-Tools herstellerunabhängig ausgetauscht werden (sofern Toolhersteller sich an den Standard halten und entsprechende Im- und Exportfonktionen in ihren Tools zur Verfügung stellen).

Das heißt aber nicht:

* Das Anwender, Sicherheitsmanager oder Sicherheitsbeauftragte OSCAL lernen müssen oder OSCAL Formate lesen können müssen. (Dafür gibt es Tools, die die Inhalte lesbar und bearbeitbar zur Verfügung stellen)
* Das alle Anforderungen automatisiert erfüllt und dokumentiert werden (viele Anforderungen sind nach wie vor organisatorische Anforderungen die nur von Menschen durch Erstellung und Beachtung entsprechenden Regelungen erfüllt werden können).
* Das überhaupt irgendwelche Anforderungen automatisiert erfüllt und dokumentiert werden (Hierzu müssten die Systeme an ein ISMS-Tool angebunden sein und diese über entsprechende Schnittstellen mit Informationen bedienen). Sowohl die Tools als auch die Schnittstellen werden absehbar nicht vom Himmel fallen.
===Satzschablonen===
Anforderungen werden im Grundschutz++ zukünftig mit Satzschablonen erstellt, die wie folgt aussehen:<blockquote><big>'''<span style="color:green">{Praktik} [für {Zielobjektkategorie}]</span> <span style="color:red">{MODALVERB}</span> <span style="color:blue"><Ergebnis></span> <span style="color:purple">{Handlungswort}</span>''' ''<span style="color:grey">(TAGs) (Hinweise)</span>''</big></blockquote>'''Praktik''': Ein Prozess im Rahmen des ISMS, eine konkrete Sicherheitsmaßnahme oder eine allgemeine Vorgehensweise zur Erreichung eines Sicherheitsziels (z.B. IT-Betrieb, Personal, Konfiguration) - Im weitesten Sinne vergleichbar mit den bisherigen Bausteinen. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/practices.csv Liste der gültigen Praktiken.]

'''Zielobjektkategorie''': Wie bisher, das Objekt oder die Entität, auf die sich die Sicherheitsanforderungen beziehen (z.B. Daten, Personen, Endgeräte, Hostsysteme). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/target_object_categories.csv Liste der Gültigen Zielobjektkategorien.]

'''Modalverb''': Gibt die Verbindlichkeit einer Anforderung an (MUSS, SOLLTE, KANN). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/modal_verbs.csv Liste der gültigen Modalverben.]

'''Ereignis''': Der sicherheitsrelevante Zustand oder Auslöser, der zu einer bestimmten Handlung führt - Entspricht in Verbindung mit dem Handlungswort dem wesentliche Inhalt der Anforderung.

'''Handlungswort''': Das Verb, das die konkrete Sicherheitsmaßnahme oder Art der Tätigkeit beschreibt (regeln, zuweisen, konfigurieren). Handlungsworte können auch zur besseren Filterung genutzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/action_words.csv Liste der gültigen Handlungsworte.]

Das ganze kann noch mit '''TAG'''s für eine bessere Gruppierung und mit einem '''Hinweis''' zu weiterführenden Informationen ergänzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/tags.csv Liste der gültigen TAGs.]

Die bisherigen Anforderungen des Kompendium werden aktuell in ihre Teilanforderungen zerlegt und jede Teilanforderung wird zukünftig eine eigene Anforderung. D.h. jedes Modalverb (SOLL, MUSS, KANN) der bisherigen Anforderungen stellt zukünftig i.d.R. eine eigene Anforderung dar. Die Gesamtanzahl der Anforderungen soll dabei durch die Vermeidung von Redundanzen dennoch sinken.

'''Beispiel'''

Die Anforderung:<blockquote>'''ISMS.1.A4 Benennung eines oder einer Informationssicherheitsbeauftragten (B) [Institutionsleitung]'''

Die Institutionsleitung MUSS einen oder eine ISB benennen. '''. . .'''

Die Institutionsleitung MUSS den oder die ISB mit angemessenen Ressourcen ausstatten.

Die Institutionsleitung MUSS dem oder der ISB die Möglichkeit einräumen, bei Bedarf direkt an sie selbst zu berichten. '''. . .'''</blockquote>Wird jetzt zu den Anforderungen:<blockquote>'''GOV.4.2''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">einer Person die Rolle ISB</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.2.3''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">für das ISMS erforderliche personelle, finanzielle und zeitliche Ressourcen</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.4.4''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">dem ISB das direkte und jederzeitige Vorspracherecht bei der Institutionsleitung</span> '''<span style="color:purple">ermöglichen</span>.'''</blockquote>Da dies übergreifende Anforderungen sind, ist hier kein spezifisches Zielobjekt benannt.

Einzelne Teilanforderungen können auch in anderen Praktiken beschrieben sein.
===Priorisierung===
Alle Anforderungen werden einer Prioritätsstufe zugeordnet, um die Umsetzung effizient zu gestalten:
*'''Stufe 0''': Zwingend (sofort) umzusetzende Anforderungen zur Sicherstellung der ISO-Kompatibilität (MUSS-Anforderungen).
Die Stufen 1-4 geben den Umsetzungsaufwand der Anforderungen wieder:
*'''Stufe 1''': Schnell und mit geringem Aufwand (~1 Tag) realisierbare Maßnahmen (QuickWin) / keine laufenden Aufwände.
*'''Stufe 2''': Mit eigenen Mitteln leicht umsetzbare Anforderung (~1 Woche) / geringe laufende Aufwände.
*'''Stufe 3''': Mit normalem Aufwand (mehrere Wochen) und ggf. externer Unterstützung umsetzbar / normale laufende Aufwände.
*'''Stufe 4''': Höherer Umsetzungsaufwand, häufig in längerfristigen Projekten mit externen Experten.
Die nächste Stufe sind optionale Anforderungen als Vorschläge bei erhöhtem Schutzbedarf.
*'''Stufe 5''': Umfassende/zusätzliche Anforderungen für höheren Schutzbedarf.
Diese Einstufung ermöglicht eine schnelle Einschätzung des Umsetzungsaufwands und hilft bei der effizienten Ressourcenplanung.
===Leistungskennzahlen===
Leistungskennzahlen dienen der '''Messung und Bewertung''' der Umsetzung von Sicherheitsanforderungen im Grundschutz++. Sie ermöglichen eine objektive Einschätzung des Sicherheitsniveaus und unterstützen die kontinuierliche Verbesserung. Wie diese Leistungskennzahlen genutzt werden sollen ist nach wie vor unklar und viele Anforderungen sind bislang noch nicht bewertet.
====Bewertungskriterien====
Jede Anforderung wird in Bezug auf die drei Schutzziele bewertet:
*'''Vertraulichkeit (C)'''
*'''Integrität (I)'''
*'''Verfügbarkeit (A)'''
Anforderungen erhalten Punktwerte in diesen Kategorien, die zur Bestimmung des Schutzgrades genutzt werden (z.B. C=6, I=2, A=0 ist eine Anforderung die im Wesentlichen die Vetraulichkeit stärkt, in Teilen die Intgrität aber nicht die Verfügbarkeit).

Die einzelen Kennzahlen werden je Schutzziel, Praktik und/oder Zielobjekt aufsummiert und ergeben so den Erfüllungsgrad.
====Schwellwerte und Erfüllungsgrad====
*'''Schwellwerte''' definieren das angestrebte Sicherheitsniveau basierend auf der Summe der Punktwerte aller umgesetzten Anforderungen je Schutzziel, Zielobjekt und Schutzstufe.
*'''Der Erfüllungsgrad''' zeigt, welche Anforderungen bereits umgesetzt wurden.
Die Leistungskennzahlen bieten damit eine fundierte Entscheidungsgrundlage für Organisationen, um ihren Sicherheitsstatus gezielt zu verbessern, wenn sie wie ursprünglich geplant eingeführt werden.
==Was bleibt erhalten?==
===Standards und Vorgehen===
Trotz eines deutlich anderen Formats und einer anderen Gruppierung der Anforderungen bleibt das grundsätzliche Vorgehen weitgehend gleich.

D.h. die Standards 200-1 bis 200-4 sollen erst einmal weiter Verwendung finden. Die bisher üblichen Arbeitsschritte:
#Festlegung des Geltungsbereichs
#Strukturanalyse
#Schutzbedarfsfeststellung
#Modellierung
#IT-Grundschutzcheck (GSC)
#Risikoanalyse
bleiben grundsätzlich erhalten, ändern sich jedoch in der praktischen Anwendung und Priorität (insbesondere in der '''Modellierung''' und den '''Grundschutzchecks'''). Parallel zur Einführung sollen die Standards weiter entwickelt werden.

'''MUSS'''-Anforderungen sind weiterhin '''verpflichtend''' für eine Zertifizierung, sollen aber deutlich rediziert werden.

'''SOLLTE'''-Anforderungen bleiben auch weiter '''grundsätzlich verpflichtend''', können aber ggf. mit angemessener Begründung oder Ersatzmaßnahmen wegdiskutiert werden.

Lediglich '''KANN'''-Anforderungen sind optional.
===Tool-Einsatz===
Auch der Einsatz von ISMS-Tools wird weiterhin Bestand haben. Alle größeren Tool-Hersteller arbeiten mit Hochdruck an der Integration von Grundschutz++ in ihre Tools. Hier wird es perspektivisch Erleichterungen durch einen leichteren Datenaustausch zwischen den Tools und mehr Automatisierungspotential geben.
==Gegenüberstellung Grundschutz Kompendium vs. Grundschutz++==
Das IT-Grundschutz-Kompendium 2023 und der zukünftige Grundschutz++ bieten unterschiedliche Konzepte für die Umsetzung von Informationssicherheit: Während das Kompendium auf feste Bausteine in thematisch gegliederten Schichten setzt, verwendet Grundschutz++ modulare, flexibel einsetzbare Praktiken.

Die folgende Tabelle stellt die wesentlichen Unterschiede und Gemeinsamkeiten zwischen beiden Ansätzen (nach aktuell verfügbaren Kenntnissen) gegenüber:
{| class="wikitable"
|+
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Fester verbindlicher Katalog''' von Anforderungen (PDF, Excel und XML), die je nach Reifegrad erfüllt werden müssen.
|Der '''variable''' und erweiterbare '''[[OSCAL]]'''-Datenbestand kann beliebig an die Bedürfnisse der Organisation angepasst werden. Zusätzliche Kataloge/Erweiterungen (C5, Datenschutz, KRITIS/NIS2) können je nach Verfügbarkeit ergänzt werden. Durch die Beseitigung vermeintlicher Redundanzen soll die Anzahl der Anforderungen erheblich reduziert werden (~10–20 % verbleibende Anforderungen gegenüber dem Grundschutz Kompendium).
|-
|
|Järliche '''Aktualisierung''' zum Stichtag '''1. Februar'''.
(bis 2023)
|Die '''Aktualisierung''' erfolgt '''fortlaufend''' nach Bedarf und Verfügbarkeit. Die Regelungen zur Relevanz für Zertifizierungen sind bislang noch nicht bekannt.
|-
|
|Das Kompendium ist (Stand 2023) in 10 '''Schichten''' mit insgesamt 111 '''Bausteine''' gegliedert, die statisch die jeweiligen Anforderungen enthalten.
|'''Praktiken''' und '''''Zielobjektkategorien''''' (Achtung abweichende Bedeutung in GS++) sind allgemeinere und wiederverwendbare, sicherheitsrelevante Verfahren oder Anforderungen. Sie können modular und situationsabhängig einzelnen Assets zugeordnet werden.
Die voraussichtlich ca. 20 Praktiken liegen irgendwo zwischen Schichten und Bausteinen. Sie sind prozessorientierter, adressieren eher Zielgruppen oder Handlungstypen und sind nicht mehr starr bestimmten Zielobjektkategorien zugeordnet. Zielobjektkategorien entsprechen zukünftig eher den Bausteinen im alten Grundschutz. Die Definitionen der Begriffe sind nach wie vor im Fluß!
|-
|
|'''Drei Stufen''' (Vorgehensweisen): Basis, Standard, erhöhter Schutzbedarf bilden den Reifegrad der Organisation ab.
|Es sind zukünftig '''sechs Stufen''' (0–5) geplant, die sich weitgehend am Umsetzungsaufwand der jeweiligen Anforderung orientieren: Je kleiner die Stufe, desto schneller bzw. leichter ist die Anforderung umsetzbar (Quick Win). Eine qualitative Bewertung des Reifegrads muss zukünftig anders erfolgen (z. B. über Leistungskennzahlen).
Das '''Sicherheitsniveau''' gibt zukünftig an, in welchem Maß die definierten Sicherheitsziele erreicht sind. Es ergibt sich aus der wirksamen Umsetzung organisatorischer, technischer und personeller Anforderungen.

Unterschieden werden:
*'''Normales Sicherheitsniveau''': entspricht dem Stand der Technik
*'''Erhöhtes Sicherheitsniveau''': für besonders schutzbedürftige Informationen oder Systeme
|-
|
|'''Zielobjekte''' als gruppierte Sammlung von gleichartigen Assets die zur späteren '''Modellierung''' (Zuordnung der Bausteine und Abhängigkeiten) genutzt werden.
|'''Zielobjekte''' werden auch in Zukunft eine ähnliche Funktion zur Gruppierung und '''Modellierung''' haben, entsprechend dabei aber eher den klassischen Bausteinen. Die konkreten Vorgaben zur Modellierung sind jedoch noch nicht detailliert genug. In der Modellierung werden die Praktiken nicht mehr statisch bestimmten Zielobjekttypen zugewiesen. Klassische Zielobjekte werden zukünftig als Assets oder Assetgruppen bezeichnet.
|-
|
|Modalverben '''MUSS''', '''SOLLTE''', '''KANN''' bestimmen die Verbindlichkeit von Anforderungen.
|Die Bedeutung der Modalverben ('''MUSS, SOLLTE, KANN''') bleibt unverändert. Ein Ziel von Grundschutz++ ist es jedoch, die Anzahl der Muss-Anforderungen auf das Nötigste zu reduzieren (unter 10 %). Dadurch soll der Grundschutz flexibler werden. Die Verbindlichkeit von Anforderungen, die über MUSS-Anforderungen hinausgehen, ist noch unklar.
|-
|
| -
|Neu sind '''Leistungskennzahlen''', die eine qualitative Bewertung der Anforderungen in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit darstellen. Sie sollen als Zahlenwert darstellbar sein und so den Reifegrad abbilden können. Bisher ist noch nicht bekannt, ob und wann diese eingeführt werden und wie die konkreten Regelungen aussehen werden.
|-
|
|Gültigkeit voraussichtlich bis 2029
|Gültig ab 1.1.2026. Zertifizierbar geplant ab 2027.
|}Teilweise werden Begrifflichkeiten neu (oder anders) definiert:
{| class="wikitable"
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Zielobjekt''' als gruppierte Sammlung von gleichartigen Assets als Grundlage für die spätere Modellierung
|'''Asset''' und gruppierte Assets. Die Gruppierung gleichartiger Assets kann weiterhin erfolgen es bleiben jedoch auch dann '''Assets'''. Der Begriff ''Zielobjekt'' wird hierfür nicht mehr genutzt.
|-
|
|'''Baustein''' als Sammlung von Anforderungen für bestimmte Zielobjekttypen.
|'''Zielobjektkategorien''' sind zukünftig das was bislang die ''Bausteine'' waren, bestimmte Typen von Assets für die spezische Anforderungen gelten. Die Assets werden den Zielobjektkategorien zugewisen und erhalten über diese ihre Anforderungen. Eine klare Definition der Begriffe ist noch im Fluß.
|-
|
|
|
|}
==Blaupausen==
Blaupausen sind vorgefertigte Musterlösungen (wie die bisherigen IT-Grundschutz-Profile), die als Vorlage (Referenzmodell) für die Erstellung und Umsetzung von branchenspezifischen oder organisationsspezifischen Sicherheitskonzepten dienen.
===Funktion der Blaupausen===
Solche Blaupausen erfassen typische Strukturen, Risiken, Anforderungen und Maßnahmen für bestimmte Anwendungsszenarien, etwa die Nutzung der E-Akte oder den sicheren Betrieb von 5G-Infrastrukturen. Sie ermöglichen es, ein ISMS deutlich effizienter und strukturierter aufzubauen, weil die grundlegenden Überlegungen (Schutzbedarfsermittlung, Zuordnung von Praktiken, Zielobjekten und Maßnahmen, etc.) bereits allgemein gültig vorformuliert sind und nur noch organisationsspezifisch angepasst werden müssen.
===Ziel und Nutzen===
*Blaupausen helfen, den Implementierungsaufwand für ISMS nach Grundschutz++ zu reduzieren.
*Sie fördern die Standardisierung und Wiederverwendbarkeit von Sicherheitskonzepten für ähnliche Organisationen oder Branchen.
*Besonders für kleinere Organisationen und typische Anwendungsfälle bieten sie einen niederschwelligen, strukturierten und praxiserprobten Einstieg in die Absicherung.
Damit sind Blaupausen im Grundschutz++ zentrale Instrumente, um bewährte Sicherheitsmethoden als Vorlage für den schnellen und einheitlichen Aufbau eines branchenspezifischen ISMS bereitzustellen.
===Umsetzung===
Umgesetzt werden Blaupausen technische als '''OSCAL-Profile''' mit zusätzlichen Erläuterungen in Textform, zukünftig sollen Blaupausen zu einem '''System Security Plan (SSP)''' weiter entwickelt werden.
== Grundlagen und Standards ==

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_1.html BSI-Standard 200-1: Anforderungen an ein ISMS].
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_2.html BSI-Standard 200-2: IT-Grundschutz Methodik] ( <- Wird neu erstellt )
** [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html Methodik zum Grundschutz++] (Aktuell in Erstellung, ersetzt zukünftig 200-2)
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_3.html BSI-Standard 200-3: Risikomanagement mit Grundschutz].
* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/BSI-Standards/BSI-Standard-200-4-Business-Continuity-Management/bsi-standard-200-4_Business_Continuity_Management_node.html BSI-Standard 200-4: Business Continuity Management].
* [[OSCAL|OSCAL (Open Security Controls Assessment Language)]].

== Schritt-für-Schritt-Methodik ==
Die Methodik von Grundschutz++ folgt einem fünfstufigen, PDCA-basierten Prozess mit Fokus auf '''Anforderungsmodellierung''' und, wenn möglich, maschinenlesbarer Verarbeitung. Hier eine Kurzbeschreibung des praktischen Vorgehens:

=== Schritt 1: Erhebung und Planung (PLAN - Governance/Compliance) ===
Du legst hier die '''strategische Basis''' für Dein ISMS, indem Du den '''Kontext deiner Organisation''' analysierst, '''Compliance-Pflichten''' (z.B. DSGVO, BDSG, brachenspezifische Gesetze und Regelungen) und '''Erwartungen interessierter Parteien''' (Kunden, Geschäftspartner, Behörden, Mitarbeitende) feststellst. Anschließend entwickelst Du eine '''Informationssicherheitsleitlinie''' mit SMART-Zielen und einer '''Strategie''', definierst den '''Geltungsbereich des ISMS''' (Scope: welche Prozesse, Standorte, Systeme), klassifizierst den '''Schutzbedarf''' kritischer Geschäftsprozesse ("normal" oder "hoch"), richtest Rollen wie den '''unabhängigen ISB''' ein und initiierst '''Risikomanagement''' sowie '''Dokumentationspflichten''' – alles '''freigegeben von der Leitung'''.

'''Unterschied zu BSI-Standard 200-2:''' Während 200-2 mit Bausteinen und Risikoanalyse startet, integriert Grundschutz++ Governance und Compliance früher und stärker in den PDCA-Planungszyklus, mit Fokus auf maschinenlesbare Strukturen und Organisationsleitungspflicht – weniger asset-zentriert, mehr prozess- und rolleorientiert ab Schritt 1.
# '''Kontextanalyse''' (intern/extern) durchführen
# '''Interessierte Parteien''' identifizieren und Anforderungen erfassen
# '''Geltungsbereich''' (Scope) durch Organisationsleitung festlegen und freigeben
# '''Geschäftsprozesse''' priorisieren → Schutzbedarf "normal" oder "hoch" einstufen
# '''Sicherheitsleitlinie''' erstellen (Ziele, Strategie, Verpflichtung Leitung)
# '''Sicherheitsorganisation''' etablieren (Rollen: ISB, Asset-Owner, etc.)
# '''Compliance-Management''' initialisieren (Rechts-/Vertragskatalog)

'''Ergebnis''': Organisatorischer Rahmen, Sicherheitsleitlinie, priorisierte Prozesse

'''Weiterführende Informationen:'''

* [[Informationssicherheitsleitlinie]]
* [[IS-Strategie]]
* [[Geschäftsprozesse]]

=== Schritt 2: Anforderungsanalyse (PLAN - Strukturmodellierung) ===
Starte mit der '''Abgrenzung des Informationsverbunds''' (technische, organisatorische Einheit innerhalb des Geltungsbereichs), '''erfasse Assets''' (z.B. Server, Daten, Rollen) pro priorisiertem '''Geschäftsprozess''' und ordne sie '''Zielobjektkategorien''' zu (z.B. „Anwendung“ mit Vererbung übergeordneter Kategorien). Modelliere dann '''Anforderungen''' aus '''GS++-Praktiken''' ('''ISMS-weit''' plus assetbezogen), ergänze bei Bedarf '''externe Pflichten''' oder risikobasierte Anforderungen (nach Risikobetrachtung), prüfe das '''Sicherheitsniveau''' ("normal SdT" oder "erhöht") und treffe '''Gestaltungsentscheidungen''' (z.B. Parameter wie Zuständigkeiten) – Ergebnis: '''individuelles Anforderungspaket'''.

'''Unterschied zu BSI-Standard 200-2:''' Statt starrer Baustein-Zuordnung und manueller Risikoanalyse nutzt Grundschutz++ eine modellbasierte, hierarchische Anforderungsableitung via Assets und Zielobjektkategorien (OSCAL-fähig, maschinenlesbar), mit automatisierbarer Vererbung und klarer Trennung von Standard- (SdT) und ergänzenden Anforderungen – skalierbarer und zyklischer als die lineare 200-2-Methodik.
# '''Informationsverbund''' definieren (techn./org. Abgrenzung)
# '''Assets''' für wichtigsten Geschäftsprozess erfassen
# '''Asset → Zielobjektkategorien''' mapping (Hierarchie + Vererbung)
# '''Anforderungspaket''' generieren:
#* ISMS-Praktiken (vollständig)
#* Zielobjekt-Anforderungen (Sicherheitsniveau: normal/erhöht)
#* Zielobjektlose Anforderungen prüfen
# '''Ergänzungen''': Externe Verpflichtungen, anforderungslose Assets
# '''Risikobetrachtung''' bei hohem Schutzbedarf oder Niveauerhöhung
# '''Parameter setzen''' (Zuständigkeiten, Werte)

'''Ergebnis''': Individuelles Anforderungspaket pro Informationsverbund

'''Weiterführende Informationen:'''

* [[Strukturanalyse]]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das OSCAL-basierte Grundschutz++ Kompendium auf Github.]

=== Schritt 3: Realisierung (DO - Umsetzung) ===
In diesem Schritt '''setzt''' du das '''Anforderungspaket''' aus Schritt 2 '''um''', indem Du den '''Ist-Zustand''' aller Anforderungen bewertest ('''Umsetzungsstatus''' ermittelst), fehlende Umsetzungen '''priorisierst''' (nach Risiko und Aufwand), einen '''Umsetzungsplan''' mit Zuständigkeiten und Fristen erstellst, '''Ausnahmen''' dokumentierst und freigibst sowie den Fortschritt verfolgst – inklusive '''Compliance-Sicherstellung''' durch regelmäßige '''Checks'''.

'''Unterschied zu BSI-Standard 200-2:''' Während 200-2 Maßnahmen aus Bausteinen direkt umsetzt und manuell dokumentiert, strukturiert Grundschutz++ die Realisierung zentral über das modellierte Anforderungspaket mit automatisierbarer Priorisierung und Nachverfolgung, stärker in den PDCA-Do-Zyklus eingebettet und skalierbar für große Verbünde.
# '''Umsetzungsstatus''' aller Anforderungen prüfen (ja/nein)
# '''Nicht-umgesetzte MUSS/SOLLTE''' → Risikobetrachtung
# '''Umsetzungsplan''' erstellen:
#* Priorisierung (Risiko, Aufwand, Synergien)
#* Zuständigkeiten + Fristen zuweisen
# '''Freigabe''' durch Institutionsleitung
# '''Fortschritt tracken''' (Ticketsystem/Projektmanagement)
# '''Ausnahmen dokumentieren''' (Begründung + Leitungsfreigabe)

'''Ergebnis''': Umsetzungsplan + Status-Dokumentation

'''Weiterführende Informationen:'''

* [[LF-Grundschutzcheck|Leitfaden Grundschutzcheck]]
* [[RiLi-Freigabe]]
* [[RiLi-Ausnahmemanagement|Richtlinie zum Management von Ausnahmen und Abweichungen]]

=== Schritt 4: Überwachung (CHECK - Monitoring/Evaluation) ===
Hier überprüfst du die '''Wirksamkeit''' des ISMS durch '''Leistungsbewertung''' (z.B. KPIs), '''Compliance-Monitoring''', '''Audits''' (mit Bewertungsschemata und Berichten), '''Management-Reviews''' und Validierung der Anforderungen gegen aktuelle Bedrohungen – Tools wie Monitoring-Software unterstützen die kontinuierliche Erfassung.

'''Unterschied zu BSI-Standard 200-2:''' Grundschutz++ erweitert die Überwachung (PDCA-Check) um maschinenlesbare Audit-Modelle und Validierung des Anforderungspakets, statt isolierter Baustein-Checks; es integriert dynamische Monitoring-Tools und Managementbewertungen enger, für zyklische Anpassung statt einmaliger Prüfung.
# '''Leistungsbewertung''' (KPIs, Umsetzungsfortschritt, Vorfälle)
# '''Compliance-Überwachung''' (gesetzlich/vertraglich)
# '''Auditprogramm''' risikobasiert durchführen
# '''Managementbewertung''' → Managementbericht erstellen
# '''Monitoring-Tools''' einsetzen (SIEM, Vulnerability Scanner)
# '''Anforderungspaket validieren''' (Aktualität prüfen)

'''Ergebnis''': Auditberichte, Managementbericht

'''Weiterführende Informationen:'''

* [[Reifegradmodell]]
* [[KPIs|Key Performance Indicators (KPIs)]]
* [[Managementbericht|Erstellen eines Managementberichts]]

=== Schritt 5: Kontinuierliche Verbesserung (ACT - Verbesserung) ===
Du behandelst hier deine '''Erkenntnisse''' aus Schritt 4, indem du Nicht-Konformitäten '''analysierst''', '''Verbesserungspotenziale''' '''identifizierst''', Korrektur- und Verbesserungspläne erstellst, deren '''Wirksamkeit prüfst''' und '''Compliance-Verstöße behebst''' – so bleibt das ISMS dynamisch und anpassbar an neue Risiken.

'''Unterschied zu BSI-Standard 200-2:''' Im Gegensatz zur reaktiven 200-2-Verbesserung (nach Risikoanalyse) schließt Grundschutz++ den PDCA-Act-Zyklus modellbasiert ab, mit systematischer Integration von Audit-Ergebnissen ins Anforderungspaket und automatisierbarer Wirksamkeitsprüfung – prozessorientierter und weniger manuell.
# '''Nicht-Konformitäten''' analysieren
# '''Verbesserungspotenziale''' identifizieren
# '''Korrektur-/Verbesserungsplan''' → in Umsetzungsplan integrieren
# '''Wirksamkeit prüfen''' nach Umsetzung
# '''Sicherheitsniveau''' bewerten (Trendanalyse)
# '''Compliance-Verstöße''' behandeln

'''Ergebnis''': Aktualisiertes Anforderungspaket → neuer PDCA-Zyklus

'''Weiterführende Informationen:'''

*

=== Praktische Hinweise ===
* '''Tool-gestützt''': JSON/OSCAL-Bausteine, Zur Nutzung sind ISMS-Tools empfohlen.
* '''Iteration''': Wichtigster Geschäftsprozess zuerst, dann schrittweise erweitern
* '''Risikobetrachtung''': Bei Sicherheitsniveau "hoch" oder Nicht-Umsetzung
* '''Dokumentation''': bevorzugt Maschinenlesbar (OSCAL) für besseren Austausch

'''Zyklusdauer''': Jährlich oder ereignisgesteuert (Änderungen, Vorfälle, Audits)

== Migration bestehender Sicherheitskonzepte ==
...

'''Weiterführende Informationen:'''

[[Grundschutz++ Migration]]

== Offenen Punkte und Kritiken ==

=== Zu viele Beteiligte, unklare Zuständigkeiten ===
Die Weiterentwicklung des Grundschutzes wird inzwischen nicht mehr ausschließlich vom Grundschutz-Referat des BSI verantwortet. Mit dem Einstieg des Referats „Stand der Technik“ und der verstärkten Einbindung der „Community“ sind die Zuständigkeiten und Verantwortlichkeiten unklarer geworden. In Präsentationen und Veröffentlichungen werden die Rollen und Aufgaben der verschiedenen Beteiligten unterschiedlich dargestellt. Es fehlt eine klare, kommunizierte Schnittstelle, wer für welche Aspekte der Entwicklung, Pflege und Kommunikation des neuen Standards verantwortlich ist. Das erschwert für Anwendende die Orientierung und die Planung der eigenen Umsetzungsstrategie.

=== Unklare Umsetzung einiger Ziele ===
Einige der im Grundschutz++ adressierten Ziele und Neuerungen sind nach wie vor nicht ausreichend konkretisiert. Besonders die Einführung von Leistungskennzahlen und die Priorisierung der Anforderungen (Stufen) werfen noch viele Fragen auf. Die konkrete Bedeutung, Messung und praktische Umsetzung dieser Leistungskennzahlen werden von verschiedenen BSI-Vertretern unterschiedlich dargestellt. Auch die Stufenmodelle werden teils als Priorisierung, als Entwicklungsstufen oder als reiner Umsetzungaufwand der Anforderungen definiert und sind in ihrer praktischen Anwendung noch nicht abschließend geklärt. Das führt zu Unsicherheiten, wie diese neuen Instrumente im einem ISMS umgesetzt und nachgewiesen werden sollen.

=== Geringer Mehrwert im Vergleich zu ISO 27001 ===
Die Anforderungen im Grundschutz++ werden zunehmend an die Formulierungen und Strukturen der ISO 27001 angeglichen. Während der klassische IT-Grundschutz durch seine konkreten, praxisnahen Maßnahmen einen klaren Mehrwert gegenüber der eher abstrakten ISO 27001 bot, verliert er durch die Harmonisierung mit internationalen Standards zunehmend diesen Vorteil. Die Anforderungen werden stärker abstrakt modularisiert formuliert, wodurch der spezifische Bezug zu typischen Umsetzungsbeispielen und die Detailtiefe abnehmen. Für viele Organisationen wird sich daher die Frage stellen, warum sie den immer noch aufwändigeren Weg über den Grundschutz wählen sollten, wenn sie mit ähnlichem oder geringeren Aufwand direkt eine ISO 27001-Zertifizierung anstreben können.

=== Zu ambitionierter Zeitplan ===
Der Grundschutz++ sollte ab dem 1.1.2026 grundsätzlich gültig und anwedbar sein, wobei eine Übergangsphase bis 2029 vorgesehen war. Bisher ist nur ein erster Entwurf veröffentlicht. Angesichts der Vielzahl an noch offenen Fragen, der fehlenden Migrationsstrategie und der Komplexität der Änderungen erscheint der Zeitplan sehr ambitioniert. Ausarbeitung und Dokumentation liegen bisher nur als Entwurf vor. Eine Pilotierung und Einführung 2026 und eine Übergangsphase bis 2029 ist vorgesehen. Die Gefahr besteht, dass größere Organisationen unter Zeitdruck unzureichend vorbereitet in die neue Methodik wechseln und mit variablen Definitionen und Zielen arbeiten müssen, was die Akzeptanz und Qualität der Umsetzung gefährdet.

=== Zunehmende (Sicherheits-)Lücke zwischen Grundschutz und Grundschutz++ ===
Mit der Entscheidung des BSI, den bisherigen IT-Grundschutz (Edition 2023) nicht mehr weiterzuentwickeln und stattdessen auf das neue Grundschutz++-Modell zu setzen, entsteht eine wachsende Lücke in der Informationssicherheit. Diese Übergangsphase bis 2029 ist sicherheitstechnisch kritisch, da sich die Bedrohungslage in der IT nicht an Entwicklungszyklen von Sicherheitsstandards orientiert. Neue Angriffsvektoren, insbesondere durch den zunehmenden Einsatz von KI in der Cyberkriminalität (z.B. KI-gestützte Malware, Deepfakes, automatisierte Phishing-Kampagnen), entstehen kontinuierlich und erfordern zeitnahe, wirksame Gegenmaßnahmen. Der bisherige Grundschutz bildet diese aktuellen Bedrohungen und technologische Entwicklungen jedoch nicht mehr ab, während die spezifischen Module und Maßnahmen im Grundschutz++ noch nicht produktiv verfügbar oder praxistauglich sind.

=== Fehlende Migration vom Grundschutz-Kompendium zu Grundschutz++ ===
Aktuell existiert weder ein konkreter Plan noch ein Konzept für eine (teil-)automatisierte Migration bestehender Sicherheitskonzepte aus dem bisherigen Grundschutz-Kompendium in das neue Grundschutz++-Modell. Die Umstellung auf ein maschinenlesbares JSON/OSCAL-Format und die objektorientierte, prozessorientierte Struktur bedeuten einen fundamentalen Bruch mit bisherigen Strukturen. Die Unterschiede zwischen Grundschutz-Kompendium und Grundschutz++ sind gravierender als beim letzten Wechsel von den Grundschutz-Katalogen zum Kompendium, bei dem bereits alle Ansätze für eine automatisierte Migration weitgehend gescheitert sind. Auch diesmal ist absehbar, dass Organisationen ihre bestehenden Dokumentationen und Umsetzungen weitgehend manuell neu abbilden müssen, was insbesondere für größere Verbünde einen erheblichen Zusatzaufwand bedeutet. Es gibt zwar Ansätze dies mittels KI zu lösen, was aber sicher nicht für jede Organisation praktikabel sein wird.

== Fazit ==
Ein abschließendes Bild zum Grundschutz++ lässt sich aktuell noch nicht zeichnen – viele Details sind noch in der Entwicklung.

Die grundlegende Modernisierung des IT-Grundschutzes durch das Grundschutz++-Projekt ist zwar fachlich und technologisch nachvollziehbar und adressiert viele Schwächen des bisherigen Systems. Die Umsetzung ist jedoch nach jetzigem Entwicklungsstand mit erheblichen Risiken und Unsicherheiten verbunden. Ohne klare Migrationspfade, eindeutige Zuständigkeiten und praxistaugliche Konkretisierungen der neuen Instrumente besteht die Gefahr, dass die Akzeptanz des Grundschutzes sinkt und Organisationen sich vermehrt alternativen Standards wie der ISO 27001 zuwenden. Ein realistischer Zeitplan und ein echter Mehrwert des neuen Standards sind daher essenziell für den Erfolg der Reform.

Der Artikel wird fortlaufend aktualisiert, sobald neue Informationen vom BSI veröffentlicht oder freigegeben werden.
===Ausblick und ToDos aus Anwendersicht===
Stichtag für die Einführung von Grundschutz++ war der '''1.1.2026'''. Das Datum wurde vom BSI in offiziellen Ankündigungen, Präsentationen und Fachveranstaltungen als verbindlicher Startpunkt kommuniziert. Ab diesem Zeitpunkt sollte das neue, digitale und prozessorientierte Regelwerk den bisherigen IT-Grundschutz ablösen. Bisher fehlt es jedoch an vielen Stellen an klaren Definitionen und konkreten Vorgaben zur Methodik.

Auch wenn abzuwarten bleibt, wann praxistaugliche Methoden verfügbar sind und wie lange die Übergangsfristen für die Umstellung sein werden (aktuelle Planung bis 2029). Abzusehen ist jedoch, dass der Aufwand und der Zeitdruck, insbesondere für größere und zertifizierte Verbünde, erheblich sein werden. Auch wenn es aktuell noch keine konkreten Beschreibungen zur Methodik und Modellierung gibt, können und sollten sich Anwender bereits jetzt vorbereiten. Dazu können die folgenden Maßnahmen dienen:
*Laufende Information über den aktuellen Stand (Internetseiten des BSI, Vorträge und Veröffentlichungen).
*Konsolidierung der bestehenden Verbünde (Reduzierung der Komplexität, konsistente Dokumentation der Gruppierung und Modellierung).
**Ein guter Tip ist es, in aktuellen GSC jede Teilanforderung (jedes Modalverb wie MUSS oder SOLLTE) in der Umsetzung einzeln zu dokumentieren, da diese zukünftig eigenständige Anforderungen darstellen und so eine Übernahme leichter werden könnte.
*Kontakt zu Toolherstellern aufnehmen und eine zügige Umsetzung in den verwendeten ISMS-Tools einfordern.
*Frühzeitige Planung der Bereitstellung entsprechender personeller Ressourcen für die Umstellung auf Grundschutz++ ab Mitte 2026.
*Gegebenenfalls frühzeitige Reservierung externer (personeller) Ressourcen zur Unterstützung.
*Es muss eine klare interne Kommunikation über die bevorstehenden, durch die Umstellung bedingten erhöhten Aufwände (Schulungen, neue (Erst-)GSCs und Anpassung der Dokumentation) geben, damit Mitarbeitende und Verantwortliche wissen, was auf sie zukommt.

== Weiterführende Ressourcen ==
*[https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html BSI IT-Grundschutz]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html BSI Leitfaden zur Grundschutz++-Methodik (1.4.2026)]
*[https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/Grundschutz/1GS_Tag_2025/Aktuelle_Entwicklungen_Ausblick_IT-GS.pdf Aktuelle Entwicklungen und Ausblick zum IT-Grundschutz - 1. Grundschutztag 2025]
*[https://www.youtube.com/watch?v=_AeWJ_Z8S-4 Keynote: Fortentwicklung des IT-Grundschutzes zu IT-Grundschutz++ (verinice.XP 2025)]
*[https://www.youtube.com/watch?v=fBXuhELODGA Vortrag: "Keynote und Vision Grundschutz++" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.youtube.com/watch?v=PxOjkV6oUwU Vortrag "Grundschutz++ Methodik und Einstieg ins BCM" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.bsi.bund.de/dok/it-sa Am Mittwoch, 08.10.2025 werden auf der it-sa die von den Arbeitsgruppen aus der Community erarbeiteten Ergebnisse präsentiert.]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]
*[[Grundschutz++ Migration|Migrationsstrategie für den Umstieg von BSI IT-Grundschutz auf Grundschutz++]]

[[Kategorie:Artikel]]
[[Kategorie:Grundschutz]]
[[Kategorie:++]]

Grundschutz++ Einführung und Aufbau

2026-04-04T17:46:26Z

Dirk: /* Schritt-für-Schritt-Methodik */

[[Datei:Teamwork-2198961.png|alternativtext=Zahnrad|rechts|240x240px]]{{#seo:
|title=Grundschutz++ Einführung und Anleitung
|keywords=ISMS, Wiki, BSI Grundschutz++, IT-Grundschutz, BSI-Standard 200-2, Bausteine, OSCAL, JSON, Informationssicherheit, Risikomanagement, Anforderungen
|description=Überblick über den neuen BSI Grundschutz++. Startseite zur Navigation durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.
}}{{SHORTDESC:Grundschutz++ Überblick und Anleitung}}''Dieser Artikel bietet einen schrittweisen Überblick über BSI '''Grundschutz++''' und navigiert durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.''

== Einführung in Grundschutz++ ==
'''Grundschutz++''' ist die 2026 vom BSI eingeführte Weiterentwicklung des IT-Grundschutz-Kompendiums. Es transformiert das bewährte Grundschutz-Konzept in ein vollständig digitales, maschinenlesbares Format mit JSON-basierten Bausteinen und OSCAL-kompatibler Struktur.<blockquote>
''Der aktuelle Stand von Grundschutz++ ist bisher nur sehr eingeschränkt praktisch anwendbar, da einige wesentliche Definitionen und Teile der Methodik noch fehlen. Dazu gehören beispielsweise die Nutzung von Kennzahlen, Blaupausen, Stufen, Schutzbedarf vs. Schutzniveau und die Modellierung.''

''Der Anforderungskatalog liegt zwar im OSCAL- und Excel-Format vor, ist ohne eine abgeschlossene und nachvollziehbare Methodik aber nicht sinnvoll anwendbar.''
</blockquote>
=== Wesentliche Neuerungen===
*'''OSCAL/JSON-basiertes Regelwerk''': Der IT-Grundschutz wird in ein maschinenlesbares '''JSON-Format''' überführt, das teilweise automatisierte Compliance-Prüfungen und Integrationen in bestehende IT-Systeme ermöglicht. Dies ersetzt die bisherigen textbasierten PDFs und Listen.
*'''Prozessorientierte Struktur''': Die neue Version ist modular und objektorientiert aufgebaut, um Redundanzen zu reduzieren und die Dokumentationslast zu verringern.
*'''Leistungskennzahlen''': Kennzahlen sollen die Informationssicherheit messbar und den Sicherheitsgewinn einzelner Anforderungen transparenter machen.
* '''Harmonisierung mit ISO 27001''': Die Anforderungen werden stärker mit internationalen Standards wie '''ISO 27001:2022''' abgestimmt, um Doppelzertifizierungen zu vereinfachen.
*'''Erweiterung um moderne Technologien''': Geplant sind auch spezifische Module für '''Cloud-Security, KI und IoT''', die aktuelle Bedrohungsszenarien abdecken.
===Ziele der Reform===
*'''Schlankere Prozesse''': Durch Automatisierung soll der administrative Aufwand sinken.
*'''Dynamische Anpassung''': JSON ermöglicht schnellere, ggf. automatisierte Updates bei neuen Cyberbedrohungen.
*'''Praxisorientierte Vereinfachung''': Der BSI will die Dokumentationslast reduzieren und den Fokus auf risikobasierte Ansätze legen, insbesondere für KMU.
*'''Priorisierung und Messbarkeit''': Durch eine stufenweise Priorisierung von Anforderungen und Leistungskennzahlen soll ein zielgerichteteres Vorgehen und die bessere Messbarkeit der Sicherheit gefördert werden.
Die Änderungen reagieren auf Kritik an der bisherigen Komplexität und sollen besonders KMU entlasten, während die ganzheitliche Sicherheitsmethodik (technisch, organisatorisch, personell) erhalten bleibt.

''Hinweis'': Details zur finalen Struktur werden schrittweise im Jahr 2026 veröffentlicht. Unternehmen sollten sich frühzeitig mit den geplanten Schnittstellen (z.B. für Security-Tools) vertraut machen.

Offizieller '''Starttermin''' für den Grundschutz++ war der '''1.1.2026'''. Danach ist allerdings eine längere Übergangsphase (bis 2029) geplant, in der beide Standards parallel genutzt werden können, so wie bei der letzten Modernisierung auch. Da jedoch zu erwarten ist, dass eine automatisierte Migration auch diesmal nicht oder nur eingeschränkt möglich sein wird, sollte speziell in größeren Verbünden rechtzeitig begonnen werden! Der jeweils aktuellen Grundschutz++ Katalog wird auf [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek GitHub] veröffentlicht.
=== Bedeutung von OSCAL im Grundschutz++ ===
Das zugrundeliegende Format für Grundschutz++ ist [[OSCAL]].

[[OSCAL]] ist ein '''Framework''' bzw. eine '''Datenmodellierungssprache''', die vom NIST speziell für Sicherheitsanforderungen und Compliance-Dokumentation entwickelt wurde. OSCAL definiert dabei nur ein festes Schema für Sicherheits- und Compliance-Daten und lässt das zugrundeliegende Datenformat (JSON, XML oder YAML) offen.

Das BSI hat sich beim Grundschutz++ für das Datenformat '''JSON''' entschieden.

Dies ermöglicht es mit entsprechenden Tools Sicherheitsanforderungen automatisiert einzulesen und zu bearbeiten. D.h.

* Anforderungen können (teil-)automatisiert von entsprechenden Tools bearbeitet und dokumentiert werden, sofern entsprechende Tools zur Verfügung stehen oder vom Anwender (ggf. Dienstleister) programmiert werden.
* Kataloge und Sicherheitskonzepte (SSPs) können zwischen ISMS-Tools herstellerunabhängig ausgetauscht werden (sofern Toolhersteller sich an den Standard halten und entsprechende Im- und Exportfonktionen in ihren Tools zur Verfügung stellen).

Das heißt aber nicht:

* Das Anwender, Sicherheitsmanager oder Sicherheitsbeauftragte OSCAL lernen müssen oder OSCAL Formate lesen können müssen. (Dafür gibt es Tools, die die Inhalte lesbar und bearbeitbar zur Verfügung stellen)
* Das alle Anforderungen automatisiert erfüllt und dokumentiert werden (viele Anforderungen sind nach wie vor organisatorische Anforderungen die nur von Menschen durch Erstellung und Beachtung entsprechenden Regelungen erfüllt werden können).
* Das überhaupt irgendwelche Anforderungen automatisiert erfüllt und dokumentiert werden (Hierzu müssten die Systeme an ein ISMS-Tool angebunden sein und diese über entsprechende Schnittstellen mit Informationen bedienen). Sowohl die Tools als auch die Schnittstellen werden absehbar nicht vom Himmel fallen.
===Satzschablonen===
Anforderungen werden im Grundschutz++ zukünftig mit Satzschablonen erstellt, die wie folgt aussehen:<blockquote><big>'''<span style="color:green">{Praktik} [für {Zielobjektkategorie}]</span> <span style="color:red">{MODALVERB}</span> <span style="color:blue"><Ergebnis></span> <span style="color:purple">{Handlungswort}</span>''' ''<span style="color:grey">(TAGs) (Hinweise)</span>''</big></blockquote>'''Praktik''': Ein Prozess im Rahmen des ISMS, eine konkrete Sicherheitsmaßnahme oder eine allgemeine Vorgehensweise zur Erreichung eines Sicherheitsziels (z.B. IT-Betrieb, Personal, Konfiguration) - Im weitesten Sinne vergleichbar mit den bisherigen Bausteinen. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/practices.csv Liste der gültigen Praktiken.]

'''Zielobjektkategorie''': Wie bisher, das Objekt oder die Entität, auf die sich die Sicherheitsanforderungen beziehen (z.B. Daten, Personen, Endgeräte, Hostsysteme). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/target_object_categories.csv Liste der Gültigen Zielobjektkategorien.]

'''Modalverb''': Gibt die Verbindlichkeit einer Anforderung an (MUSS, SOLLTE, KANN). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/modal_verbs.csv Liste der gültigen Modalverben.]

'''Ereignis''': Der sicherheitsrelevante Zustand oder Auslöser, der zu einer bestimmten Handlung führt - Entspricht in Verbindung mit dem Handlungswort dem wesentliche Inhalt der Anforderung.

'''Handlungswort''': Das Verb, das die konkrete Sicherheitsmaßnahme oder Art der Tätigkeit beschreibt (regeln, zuweisen, konfigurieren). Handlungsworte können auch zur besseren Filterung genutzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/action_words.csv Liste der gültigen Handlungsworte.]

Das ganze kann noch mit '''TAG'''s für eine bessere Gruppierung und mit einem '''Hinweis''' zu weiterführenden Informationen ergänzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/tags.csv Liste der gültigen TAGs.]

Die bisherigen Anforderungen des Kompendium werden aktuell in ihre Teilanforderungen zerlegt und jede Teilanforderung wird zukünftig eine eigene Anforderung. D.h. jedes Modalverb (SOLL, MUSS, KANN) der bisherigen Anforderungen stellt zukünftig i.d.R. eine eigene Anforderung dar. Die Gesamtanzahl der Anforderungen soll dabei durch die Vermeidung von Redundanzen dennoch sinken.

'''Beispiel'''

Die Anforderung:<blockquote>'''ISMS.1.A4 Benennung eines oder einer Informationssicherheitsbeauftragten (B) [Institutionsleitung]'''

Die Institutionsleitung MUSS einen oder eine ISB benennen. '''. . .'''

Die Institutionsleitung MUSS den oder die ISB mit angemessenen Ressourcen ausstatten.

Die Institutionsleitung MUSS dem oder der ISB die Möglichkeit einräumen, bei Bedarf direkt an sie selbst zu berichten. '''. . .'''</blockquote>Wird jetzt zu den Anforderungen:<blockquote>'''GOV.4.2''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">einer Person die Rolle ISB</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.2.3''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">für das ISMS erforderliche personelle, finanzielle und zeitliche Ressourcen</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.4.4''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">dem ISB das direkte und jederzeitige Vorspracherecht bei der Institutionsleitung</span> '''<span style="color:purple">ermöglichen</span>.'''</blockquote>Da dies übergreifende Anforderungen sind, ist hier kein spezifisches Zielobjekt benannt.

Einzelne Teilanforderungen können auch in anderen Praktiken beschrieben sein.
===Priorisierung===
Alle Anforderungen werden einer Prioritätsstufe zugeordnet, um die Umsetzung effizient zu gestalten:
*'''Stufe 0''': Zwingend (sofort) umzusetzende Anforderungen zur Sicherstellung der ISO-Kompatibilität (MUSS-Anforderungen).
Die Stufen 1-4 geben den Umsetzungsaufwand der Anforderungen wieder:
*'''Stufe 1''': Schnell und mit geringem Aufwand (~1 Tag) realisierbare Maßnahmen (QuickWin) / keine laufenden Aufwände.
*'''Stufe 2''': Mit eigenen Mitteln leicht umsetzbare Anforderung (~1 Woche) / geringe laufende Aufwände.
*'''Stufe 3''': Mit normalem Aufwand (mehrere Wochen) und ggf. externer Unterstützung umsetzbar / normale laufende Aufwände.
*'''Stufe 4''': Höherer Umsetzungsaufwand, häufig in längerfristigen Projekten mit externen Experten.
Die nächste Stufe sind optionale Anforderungen als Vorschläge bei erhöhtem Schutzbedarf.
*'''Stufe 5''': Umfassende/zusätzliche Anforderungen für höheren Schutzbedarf.
Diese Einstufung ermöglicht eine schnelle Einschätzung des Umsetzungsaufwands und hilft bei der effizienten Ressourcenplanung.
===Leistungskennzahlen===
Leistungskennzahlen dienen der '''Messung und Bewertung''' der Umsetzung von Sicherheitsanforderungen im Grundschutz++. Sie ermöglichen eine objektive Einschätzung des Sicherheitsniveaus und unterstützen die kontinuierliche Verbesserung. Wie diese Leistungskennzahlen genutzt werden sollen ist nach wie vor unklar und viele Anforderungen sind bislang noch nicht bewertet.
====Bewertungskriterien====
Jede Anforderung wird in Bezug auf die drei Schutzziele bewertet:
*'''Vertraulichkeit (C)'''
*'''Integrität (I)'''
*'''Verfügbarkeit (A)'''
Anforderungen erhalten Punktwerte in diesen Kategorien, die zur Bestimmung des Schutzgrades genutzt werden (z.B. C=6, I=2, A=0 ist eine Anforderung die im Wesentlichen die Vetraulichkeit stärkt, in Teilen die Intgrität aber nicht die Verfügbarkeit).

Die einzelen Kennzahlen werden je Schutzziel, Praktik und/oder Zielobjekt aufsummiert und ergeben so den Erfüllungsgrad.
====Schwellwerte und Erfüllungsgrad====
*'''Schwellwerte''' definieren das angestrebte Sicherheitsniveau basierend auf der Summe der Punktwerte aller umgesetzten Anforderungen je Schutzziel, Zielobjekt und Schutzstufe.
*'''Der Erfüllungsgrad''' zeigt, welche Anforderungen bereits umgesetzt wurden.
Die Leistungskennzahlen bieten damit eine fundierte Entscheidungsgrundlage für Organisationen, um ihren Sicherheitsstatus gezielt zu verbessern, wenn sie wie ursprünglich geplant eingeführt werden.
==Was bleibt erhalten?==
===Standards und Vorgehen===
Trotz eines deutlich anderen Formats und einer anderen Gruppierung der Anforderungen bleibt das grundsätzliche Vorgehen weitgehend gleich.

D.h. die Standards 200-1 bis 200-4 sollen erst einmal weiter Verwendung finden. Die bisher üblichen Arbeitsschritte:
#Festlegung des Geltungsbereichs
#Strukturanalyse
#Schutzbedarfsfeststellung
#Modellierung
#IT-Grundschutzcheck (GSC)
#Risikoanalyse
bleiben grundsätzlich erhalten, ändern sich jedoch in der praktischen Anwendung und Priorität (insbesondere in der '''Modellierung''' und den '''Grundschutzchecks'''). Parallel zur Einführung sollen die Standards weiter entwickelt werden.

'''MUSS'''-Anforderungen sind weiterhin '''verpflichtend''' für eine Zertifizierung, sollen aber deutlich rediziert werden.

'''SOLLTE'''-Anforderungen bleiben auch weiter '''grundsätzlich verpflichtend''', können aber ggf. mit angemessener Begründung oder Ersatzmaßnahmen wegdiskutiert werden.

Lediglich '''KANN'''-Anforderungen sind optional.
===Tool-Einsatz===
Auch der Einsatz von ISMS-Tools wird weiterhin Bestand haben. Alle größeren Tool-Hersteller arbeiten mit Hochdruck an der Integration von Grundschutz++ in ihre Tools. Hier wird es perspektivisch Erleichterungen durch einen leichteren Datenaustausch zwischen den Tools und mehr Automatisierungspotential geben.
==Gegenüberstellung Grundschutz Kompendium vs. Grundschutz++==
Das IT-Grundschutz-Kompendium 2023 und der zukünftige Grundschutz++ bieten unterschiedliche Konzepte für die Umsetzung von Informationssicherheit: Während das Kompendium auf feste Bausteine in thematisch gegliederten Schichten setzt, verwendet Grundschutz++ modulare, flexibel einsetzbare Praktiken.

Die folgende Tabelle stellt die wesentlichen Unterschiede und Gemeinsamkeiten zwischen beiden Ansätzen (nach aktuell verfügbaren Kenntnissen) gegenüber:
{| class="wikitable"
|+
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Fester verbindlicher Katalog''' von Anforderungen (PDF, Excel und XML), die je nach Reifegrad erfüllt werden müssen.
|Der '''variable''' und erweiterbare '''[[OSCAL]]'''-Datenbestand kann beliebig an die Bedürfnisse der Organisation angepasst werden. Zusätzliche Kataloge/Erweiterungen (C5, Datenschutz, KRITIS/NIS2) können je nach Verfügbarkeit ergänzt werden. Durch die Beseitigung vermeintlicher Redundanzen soll die Anzahl der Anforderungen erheblich reduziert werden (~10–20 % verbleibende Anforderungen gegenüber dem Grundschutz Kompendium).
|-
|
|Järliche '''Aktualisierung''' zum Stichtag '''1. Februar'''.
(bis 2023)
|Die '''Aktualisierung''' erfolgt '''fortlaufend''' nach Bedarf und Verfügbarkeit. Die Regelungen zur Relevanz für Zertifizierungen sind bislang noch nicht bekannt.
|-
|
|Das Kompendium ist (Stand 2023) in 10 '''Schichten''' mit insgesamt 111 '''Bausteine''' gegliedert, die statisch die jeweiligen Anforderungen enthalten.
|'''Praktiken''' und '''''Zielobjektkategorien''''' (Achtung abweichende Bedeutung in GS++) sind allgemeinere und wiederverwendbare, sicherheitsrelevante Verfahren oder Anforderungen. Sie können modular und situationsabhängig einzelnen Assets zugeordnet werden.
Die voraussichtlich ca. 20 Praktiken liegen irgendwo zwischen Schichten und Bausteinen. Sie sind prozessorientierter, adressieren eher Zielgruppen oder Handlungstypen und sind nicht mehr starr bestimmten Zielobjektkategorien zugeordnet. Zielobjektkategorien entsprechen zukünftig eher den Bausteinen im alten Grundschutz. Die Definitionen der Begriffe sind nach wie vor im Fluß!
|-
|
|'''Drei Stufen''' (Vorgehensweisen): Basis, Standard, erhöhter Schutzbedarf bilden den Reifegrad der Organisation ab.
|Es sind zukünftig '''sechs Stufen''' (0–5) geplant, die sich weitgehend am Umsetzungsaufwand der jeweiligen Anforderung orientieren: Je kleiner die Stufe, desto schneller bzw. leichter ist die Anforderung umsetzbar (Quick Win). Eine qualitative Bewertung des Reifegrads muss zukünftig anders erfolgen (z. B. über Leistungskennzahlen).
Das '''Sicherheitsniveau''' gibt zukünftig an, in welchem Maß die definierten Sicherheitsziele erreicht sind. Es ergibt sich aus der wirksamen Umsetzung organisatorischer, technischer und personeller Anforderungen.

Unterschieden werden:
*'''Normales Sicherheitsniveau''': entspricht dem Stand der Technik
*'''Erhöhtes Sicherheitsniveau''': für besonders schutzbedürftige Informationen oder Systeme
|-
|
|'''Zielobjekte''' als gruppierte Sammlung von gleichartigen Assets die zur späteren '''Modellierung''' (Zuordnung der Bausteine und Abhängigkeiten) genutzt werden.
|'''Zielobjekte''' werden auch in Zukunft eine ähnliche Funktion zur Gruppierung und '''Modellierung''' haben, entsprechend dabei aber eher den klassischen Bausteinen. Die konkreten Vorgaben zur Modellierung sind jedoch noch nicht detailliert genug. In der Modellierung werden die Praktiken nicht mehr statisch bestimmten Zielobjekttypen zugewiesen. Klassische Zielobjekte werden zukünftig als Assets oder Assetgruppen bezeichnet.
|-
|
|Modalverben '''MUSS''', '''SOLLTE''', '''KANN''' bestimmen die Verbindlichkeit von Anforderungen.
|Die Bedeutung der Modalverben ('''MUSS, SOLLTE, KANN''') bleibt unverändert. Ein Ziel von Grundschutz++ ist es jedoch, die Anzahl der Muss-Anforderungen auf das Nötigste zu reduzieren (unter 10 %). Dadurch soll der Grundschutz flexibler werden. Die Verbindlichkeit von Anforderungen, die über MUSS-Anforderungen hinausgehen, ist noch unklar.
|-
|
| -
|Neu sind '''Leistungskennzahlen''', die eine qualitative Bewertung der Anforderungen in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit darstellen. Sie sollen als Zahlenwert darstellbar sein und so den Reifegrad abbilden können. Bisher ist noch nicht bekannt, ob und wann diese eingeführt werden und wie die konkreten Regelungen aussehen werden.
|-
|
|Gültigkeit voraussichtlich bis 2029
|Gültig ab 1.1.2026. Zertifizierbar geplant ab 2027.
|}Teilweise werden Begrifflichkeiten neu (oder anders) definiert:
{| class="wikitable"
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Zielobjekt''' als gruppierte Sammlung von gleichartigen Assets als Grundlage für die spätere Modellierung
|'''Asset''' und gruppierte Assets. Die Gruppierung gleichartiger Assets kann weiterhin erfolgen es bleiben jedoch auch dann '''Assets'''. Der Begriff ''Zielobjekt'' wird hierfür nicht mehr genutzt.
|-
|
|'''Baustein''' als Sammlung von Anforderungen für bestimmte Zielobjekttypen.
|'''Zielobjektkategorien''' sind zukünftig das was bislang die ''Bausteine'' waren, bestimmte Typen von Assets für die spezische Anforderungen gelten. Die Assets werden den Zielobjektkategorien zugewisen und erhalten über diese ihre Anforderungen. Eine klare Definition der Begriffe ist noch im Fluß.
|-
|
|
|
|}
==Blaupausen==
Blaupausen sind vorgefertigte Musterlösungen (wie die bisherigen IT-Grundschutz-Profile), die als Vorlage (Referenzmodell) für die Erstellung und Umsetzung von branchenspezifischen oder organisationsspezifischen Sicherheitskonzepten dienen.
===Funktion der Blaupausen===
Solche Blaupausen erfassen typische Strukturen, Risiken, Anforderungen und Maßnahmen für bestimmte Anwendungsszenarien, etwa die Nutzung der E-Akte oder den sicheren Betrieb von 5G-Infrastrukturen. Sie ermöglichen es, ein ISMS deutlich effizienter und strukturierter aufzubauen, weil die grundlegenden Überlegungen (Schutzbedarfsermittlung, Zuordnung von Praktiken, Zielobjekten und Maßnahmen, etc.) bereits allgemein gültig vorformuliert sind und nur noch organisationsspezifisch angepasst werden müssen.
===Ziel und Nutzen===
*Blaupausen helfen, den Implementierungsaufwand für ISMS nach Grundschutz++ zu reduzieren.
*Sie fördern die Standardisierung und Wiederverwendbarkeit von Sicherheitskonzepten für ähnliche Organisationen oder Branchen.
*Besonders für kleinere Organisationen und typische Anwendungsfälle bieten sie einen niederschwelligen, strukturierten und praxiserprobten Einstieg in die Absicherung.
Damit sind Blaupausen im Grundschutz++ zentrale Instrumente, um bewährte Sicherheitsmethoden als Vorlage für den schnellen und einheitlichen Aufbau eines branchenspezifischen ISMS bereitzustellen.
===Umsetzung===
Umgesetzt werden Blaupausen technische als '''OSCAL-Profile''' mit zusätzlichen Erläuterungen in Textform, zukünftig sollen Blaupausen zu einem '''System Security Plan (SSP)''' weiter entwickelt werden.
== Grundlagen und Standards ==

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_1.html BSI-Standard 200-1: Anforderungen an ein ISMS].
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_2.html BSI-Standard 200-2: IT-Grundschutz Methodik] ( <- Wird neu erstellt )
** [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html Methodik zum Grundschutz++] (Aktuell in Erstellung, ersetzt zukünftig 200-2)
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_3.html BSI-Standard 200-3: Risikomanagement mit Grundschutz].
* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/BSI-Standards/BSI-Standard-200-4-Business-Continuity-Management/bsi-standard-200-4_Business_Continuity_Management_node.html BSI-Standard 200-4: Business Continuity Management].
* [[OSCAL|OSCAL (Open Security Controls Assessment Language)]].

== Schritt-für-Schritt-Methodik ==
Die Methodik von Grundschutz++ folgt einem fünfstufigen, PDCA-basierten Prozess mit Fokus auf '''Anforderungsmodellierung''' und, wenn möglich, maschinenlesbarer Verarbeitung. Hier eine Kurzbeschreibung des praktischen Vorgehens:

=== Schritt 1: Erhebung und Planung (PLAN - Governance/Compliance) ===
Du legst hier die strategische Basis für Dein ISMS, indem Du den Kontext Deiner Institution analysierst, Compliance-Pflichten (z. B. DSGVO, BDSG) und Erwartungen interessierter Parteien (Kunden, Behörden, Mitarbeitende) feststellst. Anschließend entwickelst Du eine Informationssicherheitsleitlinie mit SMART-Zielen und einer Strategie, definierst den Geltungsbereich (Scope: welche Prozesse, Standorte, Systeme), klassifizierst den Schutzbedarf kritischer Geschäftsprozesse (normal oder hoch), richtest Rollen wie den unabhängigen ISB ein und initiierst Risikomanagement sowie Dokumentationspflichten – alles freigegeben von der Leitung.

'''Unterschied zu BSI-Standard 200-2:''' Während 200-2 mit Bausteinen und Risikoanalyse startet, integriert Grundschutz++ Governance und Compliance früher und stärker in den PDCA-Planungszyklus, mit Fokus auf maschinenlesbare Strukturen und Institutionsleitungspflicht – weniger asset-zentriert, mehr prozess- und rolleorientiert ab Schritt 1.
# '''Kontextanalyse''' (intern/extern) durchführen
# '''Interessierte Parteien''' identifizieren und Anforderungen erfassen
# '''Geltungsbereich''' (Scope) durch Institutionsleitung festlegen und freigeben
# '''Geschäftsprozesse''' priorisieren → Schutzbedarf "normal" oder "hoch" einstufen
# '''Sicherheitsleitlinie''' erstellen (Ziele, Strategie, Verpflichtung Leitung)
# '''Sicherheitsorganisation''' etablieren (Rollen: ISB, Asset-Owner, etc.)
# '''Compliance-Management''' initialisieren (Rechts-/Vertragskatalog)

'''Ergebnis''': Organisatorischer Rahmen, Sicherheitsleitlinie, priorisierte Prozesse

'''Weiterführende Informationen:'''

* [[Informationssicherheitsleitlinie]]
* [[IS-Strategie]]
* [[Geschäftsprozesse]]

=== Schritt 2: Anforderungsanalyse (PLAN - Strukturmodellierung) ===
Starte mit der Abgrenzung des Informationsverbunds (technische, organisatorische Einheit innerhalb des Geltungsbereichs), erfasse Assets (z.B. Server, Daten, Rollen) pro priorisiertem Geschäftsprozess und ordne sie Zielobjektkategorien zu (z.B. „Anwendung“ mit Vererbung übergeordneter Kategorien). Modelliere dann Anforderungen aus GS++-Praktiken (ISMS-weit plus assetbezogen), ergänze bei Bedarf externe Pflichten oder risikobasierte (nach Risikobetrachtung), prüfe das Sicherheitsniveau ("normal SdT" oder "erhöht") und treffe Gestaltungsentscheidungen (z.B. Parameter wie Zuständigkeiten) – Ergebnis: individuelles Anforderungspaket.

'''Unterschied zu BSI-Standard 200-2:''' Statt starrer Baustein-Zuordnung und manueller Risikoanalyse nutzt Grundschutz++ eine modellbasierte, hierarchische Anforderungsableitung via Assets und Zielobjektkategorien (OSCAL-fähig, maschinenlesbar), mit automatisierbarer Vererbung und klarer Trennung von Standard- (SdT) und ergänzenden Anforderungen – skalierbarer und zyklischer als die lineare 200-2-Methodik.
# '''Informationsverbund''' definieren (techn./org. Abgrenzung)
# '''Assets''' für wichtigsten Geschäftsprozess erfassen
# '''Asset → Zielobjektkategorien''' mapping (Hierarchie + Vererbung)
# '''Anforderungspaket''' generieren:
#* ISMS-Praktiken (vollständig)
#* Zielobjekt-Anforderungen (Sicherheitsniveau: normal/erhöht)
#* Zielobjektlose Anforderungen prüfen
# '''Ergänzungen''': Externe Verpflichtungen, anforderungslose Assets
# '''Risikobetrachtung''' bei hohem Schutzbedarf oder Niveauerhöhung
# '''Parameter setzen''' (Zuständigkeiten, Werte)

'''Ergebnis''': Individuelles Anforderungspaket pro Informationsverbund

'''Weiterführende Informationen:'''

* [[Strukturanalyse]]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das OSCAL-basierte Grundschutz++ Kompendium auf Github.]

=== Schritt 3: Realisierung (DO - Umsetzung) ===
In diesem Schritt setzt Du das Anforderungspaket aus Schritt 2 um, indem Du den Ist-Zustand aller Anforderungen bewertest (Umsetzungsstatus ermittelst), fehlende Umsetzungen priorisierst (nach Risiko und Aufwand), einen Umsetzungsplan mit Zuständigkeiten und Fristen erstellst, Ausnahmen dokumentierst und freigibst sowie den Fortschritt verfolgst – inklusive Compliance-Sicherstellung durch regelmäßige Checks.

'''Unterschied zu BSI-Standard 200-2:''' Während 200-2 Maßnahmen aus Bausteinen direkt umsetzt und manuell dokumentiert, strukturiert Grundschutz++ die Realisierung zentral über das modellierte Anforderungspaket mit automatisierbarer Priorisierung und Nachverfolgung, stärker in den PDCA-Do-Zyklus eingebettet und skalierbar für große Verbünde.
# '''Umsetzungsstatus''' aller Anforderungen prüfen (ja/nein)
# '''Nicht-umgesetzte MUSS/SOLLTE''' → Risikobetrachtung
# '''Umsetzungsplan''' erstellen:
#* Priorisierung (Risiko, Aufwand, Synergien)
#* Zuständigkeiten + Fristen zuweisen
# '''Freigabe''' durch Institutionsleitung
# '''Fortschritt tracken''' (Ticketsystem/Projektmanagement)
# '''Ausnahmen dokumentieren''' (Begründung + Leitungsfreigabe)

'''Ergebnis''': Umsetzungsplan + Status-Dokumentation

'''Weiterführende Informationen:'''

* [[LF-Grundschutzcheck|Leitfaden Grundschutzcheck]]
* [[RiLi-Freigabe]]
* [[RiLi-Ausnahmemanagement|Richtlinie zum Management von Ausnahmen und Abweichungen]]

=== Schritt 4: Überwachung (CHECK - Monitoring/Evaluation) ===
Hier überprüfst Du die Wirksamkeit des ISMS durch Leistungsbewertung (z. B. KPIs), Compliance-Monitoring, Audits (mit Bewertungsschemata und Berichten), Management-Reviews und Validierung der Anforderungen gegen aktuelle Bedrohungen – Tools wie Monitoring-Software unterstützen die kontinuierliche Erfassung.

'''Unterschied zu BSI-Standard 200-2:''' Grundschutz++ erweitert die Überwachung (PDCA-Check) um maschinenlesbare Audit-Modelle und Validierung des Anforderungspakets, statt isolierter Baustein-Checks; es integriert dynamische Monitoring-Tools und Managementbewertungen enger, für zyklische Anpassung statt einmaliger Prüfung.
# '''Leistungsbewertung''' (KPIs, Umsetzungsfortschritt, Vorfälle)
# '''Compliance-Überwachung''' (gesetzlich/vertraglich)
# '''Auditprogramm''' risikobasiert durchführen
# '''Managementbewertung''' → Managementbericht erstellen
# '''Monitoring-Tools''' einsetzen (SIEM, Vulnerability Scanner)
# '''Anforderungspaket validieren''' (Aktualität prüfen)

'''Ergebnis''': Auditberichte, Managementbericht

'''Weiterführende Informationen:'''

* [[Reifegradmodell]]
* [[KPIs|Key Performance Indicators (KPIs)]]
* [[Managementbericht|Erstellen eines Managementberichts]]

=== Schritt 5: Kontinuierliche Verbesserung (ACT - Verbesserung) ===
Du behandelst hier deine Erkenntnisse aus Schritt 4, indem du Nicht-Konformitäten analysierst, Verbesserungspotenziale identifizierst, Korrektur- und Verbesserungspläne erstellst, deren Wirksamkeit prüfst und Compliance-Verstöße behebst – so bleibt das ISMS dynamisch und anpassbar an neue Risiken.

'''Unterschied zu BSI-Standard 200-2:''' Im Gegensatz zur reaktiven 200-2-Verbesserung (nach Risikoanalyse) schließt Grundschutz++ den PDCA-Act-Zyklus modellbasiert ab, mit systematischer Integration von Audit-Ergebnissen ins Anforderungspaket und automatisierbarer Wirksamkeitsprüfung – prozessorientierter und weniger manuell.
# '''Nicht-Konformitäten''' analysieren
# '''Verbesserungspotenziale''' identifizieren
# '''Korrektur-/Verbesserungsplan''' → in Umsetzungsplan integrieren
# '''Wirksamkeit prüfen''' nach Umsetzung
# '''Sicherheitsniveau''' bewerten (Trendanalyse)
# '''Compliance-Verstöße''' behandeln

'''Ergebnis''': Aktualisiertes Anforderungspaket → neuer PDCA-Zyklus

'''Weiterführende Informationen:'''

*

=== Praktische Hinweise ===
* '''Tool-gestützt''': JSON/OSCAL-Bausteine, Zur Nutzung sind ISMS-Tools empfohlen.
* '''Iteration''': Wichtigster Geschäftsprozess zuerst, dann schrittweise erweitern
* '''Risikobetrachtung''': Bei Sicherheitsniveau "hoch" oder Nicht-Umsetzung
* '''Dokumentation''': bevorzugt Maschinenlesbar (OSCAL) für besseren Austausch

'''Zyklusdauer''': Jährlich oder ereignisgesteuert (Änderungen, Vorfälle, Audits)

== Migration bestehender Sicherheitskonzepte ==
...

'''Weiterführende Informationen:'''

[[Grundschutz++ Migration]]

== Offenen Punkte und Kritiken ==

=== Zu viele Beteiligte, unklare Zuständigkeiten ===
Die Weiterentwicklung des Grundschutzes wird inzwischen nicht mehr ausschließlich vom Grundschutz-Referat des BSI verantwortet. Mit dem Einstieg des Referats „Stand der Technik“ und der verstärkten Einbindung der „Community“ sind die Zuständigkeiten und Verantwortlichkeiten unklarer geworden. In Präsentationen und Veröffentlichungen werden die Rollen und Aufgaben der verschiedenen Beteiligten unterschiedlich dargestellt. Es fehlt eine klare, kommunizierte Schnittstelle, wer für welche Aspekte der Entwicklung, Pflege und Kommunikation des neuen Standards verantwortlich ist. Das erschwert für Anwendende die Orientierung und die Planung der eigenen Umsetzungsstrategie.

=== Unklare Umsetzung einiger Ziele ===
Einige der im Grundschutz++ adressierten Ziele und Neuerungen sind nach wie vor nicht ausreichend konkretisiert. Besonders die Einführung von Leistungskennzahlen und die Priorisierung der Anforderungen (Stufen) werfen noch viele Fragen auf. Die konkrete Bedeutung, Messung und praktische Umsetzung dieser Leistungskennzahlen werden von verschiedenen BSI-Vertretern unterschiedlich dargestellt. Auch die Stufenmodelle werden teils als Priorisierung, als Entwicklungsstufen oder als reiner Umsetzungaufwand der Anforderungen definiert und sind in ihrer praktischen Anwendung noch nicht abschließend geklärt. Das führt zu Unsicherheiten, wie diese neuen Instrumente im einem ISMS umgesetzt und nachgewiesen werden sollen.

=== Geringer Mehrwert im Vergleich zu ISO 27001 ===
Die Anforderungen im Grundschutz++ werden zunehmend an die Formulierungen und Strukturen der ISO 27001 angeglichen. Während der klassische IT-Grundschutz durch seine konkreten, praxisnahen Maßnahmen einen klaren Mehrwert gegenüber der eher abstrakten ISO 27001 bot, verliert er durch die Harmonisierung mit internationalen Standards zunehmend diesen Vorteil. Die Anforderungen werden stärker abstrakt modularisiert formuliert, wodurch der spezifische Bezug zu typischen Umsetzungsbeispielen und die Detailtiefe abnehmen. Für viele Organisationen wird sich daher die Frage stellen, warum sie den immer noch aufwändigeren Weg über den Grundschutz wählen sollten, wenn sie mit ähnlichem oder geringeren Aufwand direkt eine ISO 27001-Zertifizierung anstreben können.

=== Zu ambitionierter Zeitplan ===
Der Grundschutz++ sollte ab dem 1.1.2026 grundsätzlich gültig und anwedbar sein, wobei eine Übergangsphase bis 2029 vorgesehen war. Bisher ist nur ein erster Entwurf veröffentlicht. Angesichts der Vielzahl an noch offenen Fragen, der fehlenden Migrationsstrategie und der Komplexität der Änderungen erscheint der Zeitplan sehr ambitioniert. Ausarbeitung und Dokumentation liegen bisher nur als Entwurf vor. Eine Pilotierung und Einführung 2026 und eine Übergangsphase bis 2029 ist vorgesehen. Die Gefahr besteht, dass größere Organisationen unter Zeitdruck unzureichend vorbereitet in die neue Methodik wechseln und mit variablen Definitionen und Zielen arbeiten müssen, was die Akzeptanz und Qualität der Umsetzung gefährdet.

=== Zunehmende (Sicherheits-)Lücke zwischen Grundschutz und Grundschutz++ ===
Mit der Entscheidung des BSI, den bisherigen IT-Grundschutz (Edition 2023) nicht mehr weiterzuentwickeln und stattdessen auf das neue Grundschutz++-Modell zu setzen, entsteht eine wachsende Lücke in der Informationssicherheit. Diese Übergangsphase bis 2029 ist sicherheitstechnisch kritisch, da sich die Bedrohungslage in der IT nicht an Entwicklungszyklen von Sicherheitsstandards orientiert. Neue Angriffsvektoren, insbesondere durch den zunehmenden Einsatz von KI in der Cyberkriminalität (z.B. KI-gestützte Malware, Deepfakes, automatisierte Phishing-Kampagnen), entstehen kontinuierlich und erfordern zeitnahe, wirksame Gegenmaßnahmen. Der bisherige Grundschutz bildet diese aktuellen Bedrohungen und technologische Entwicklungen jedoch nicht mehr ab, während die spezifischen Module und Maßnahmen im Grundschutz++ noch nicht produktiv verfügbar oder praxistauglich sind.

=== Fehlende Migration vom Grundschutz-Kompendium zu Grundschutz++ ===
Aktuell existiert weder ein konkreter Plan noch ein Konzept für eine (teil-)automatisierte Migration bestehender Sicherheitskonzepte aus dem bisherigen Grundschutz-Kompendium in das neue Grundschutz++-Modell. Die Umstellung auf ein maschinenlesbares JSON/OSCAL-Format und die objektorientierte, prozessorientierte Struktur bedeuten einen fundamentalen Bruch mit bisherigen Strukturen. Die Unterschiede zwischen Grundschutz-Kompendium und Grundschutz++ sind gravierender als beim letzten Wechsel von den Grundschutz-Katalogen zum Kompendium, bei dem bereits alle Ansätze für eine automatisierte Migration weitgehend gescheitert sind. Auch diesmal ist absehbar, dass Organisationen ihre bestehenden Dokumentationen und Umsetzungen weitgehend manuell neu abbilden müssen, was insbesondere für größere Verbünde einen erheblichen Zusatzaufwand bedeutet. Es gibt zwar Ansätze dies mittels KI zu lösen, was aber sicher nicht für jede Organisation praktikabel sein wird.

== Fazit ==
Ein abschließendes Bild zum Grundschutz++ lässt sich aktuell noch nicht zeichnen – viele Details sind noch in der Entwicklung.

Die grundlegende Modernisierung des IT-Grundschutzes durch das Grundschutz++-Projekt ist zwar fachlich und technologisch nachvollziehbar und adressiert viele Schwächen des bisherigen Systems. Die Umsetzung ist jedoch nach jetzigem Entwicklungsstand mit erheblichen Risiken und Unsicherheiten verbunden. Ohne klare Migrationspfade, eindeutige Zuständigkeiten und praxistaugliche Konkretisierungen der neuen Instrumente besteht die Gefahr, dass die Akzeptanz des Grundschutzes sinkt und Organisationen sich vermehrt alternativen Standards wie der ISO 27001 zuwenden. Ein realistischer Zeitplan und ein echter Mehrwert des neuen Standards sind daher essenziell für den Erfolg der Reform.

Der Artikel wird fortlaufend aktualisiert, sobald neue Informationen vom BSI veröffentlicht oder freigegeben werden.
===Ausblick und ToDos aus Anwendersicht===
Stichtag für die Einführung von Grundschutz++ war der '''1.1.2026'''. Das Datum wurde vom BSI in offiziellen Ankündigungen, Präsentationen und Fachveranstaltungen als verbindlicher Startpunkt kommuniziert. Ab diesem Zeitpunkt sollte das neue, digitale und prozessorientierte Regelwerk den bisherigen IT-Grundschutz ablösen. Bisher fehlt es jedoch an vielen Stellen an klaren Definitionen und konkreten Vorgaben zur Methodik.

Auch wenn abzuwarten bleibt, wann praxistaugliche Methoden verfügbar sind und wie lange die Übergangsfristen für die Umstellung sein werden (aktuelle Planung bis 2029). Abzusehen ist jedoch, dass der Aufwand und der Zeitdruck, insbesondere für größere und zertifizierte Verbünde, erheblich sein werden. Auch wenn es aktuell noch keine konkreten Beschreibungen zur Methodik und Modellierung gibt, können und sollten sich Anwender bereits jetzt vorbereiten. Dazu können die folgenden Maßnahmen dienen:
*Laufende Information über den aktuellen Stand (Internetseiten des BSI, Vorträge und Veröffentlichungen).
*Konsolidierung der bestehenden Verbünde (Reduzierung der Komplexität, konsistente Dokumentation der Gruppierung und Modellierung).
**Ein guter Tip ist es, in aktuellen GSC jede Teilanforderung (jedes Modalverb wie MUSS oder SOLLTE) in der Umsetzung einzeln zu dokumentieren, da diese zukünftig eigenständige Anforderungen darstellen und so eine Übernahme leichter werden könnte.
*Kontakt zu Toolherstellern aufnehmen und eine zügige Umsetzung in den verwendeten ISMS-Tools einfordern.
*Frühzeitige Planung der Bereitstellung entsprechender personeller Ressourcen für die Umstellung auf Grundschutz++ ab Mitte 2026.
*Gegebenenfalls frühzeitige Reservierung externer (personeller) Ressourcen zur Unterstützung.
*Es muss eine klare interne Kommunikation über die bevorstehenden, durch die Umstellung bedingten erhöhten Aufwände (Schulungen, neue (Erst-)GSCs und Anpassung der Dokumentation) geben, damit Mitarbeitende und Verantwortliche wissen, was auf sie zukommt.

== Weiterführende Ressourcen ==
*[https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html BSI IT-Grundschutz]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html BSI Leitfaden zur Grundschutz++-Methodik (1.4.2026)]
*[https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/Grundschutz/1GS_Tag_2025/Aktuelle_Entwicklungen_Ausblick_IT-GS.pdf Aktuelle Entwicklungen und Ausblick zum IT-Grundschutz - 1. Grundschutztag 2025]
*[https://www.youtube.com/watch?v=_AeWJ_Z8S-4 Keynote: Fortentwicklung des IT-Grundschutzes zu IT-Grundschutz++ (verinice.XP 2025)]
*[https://www.youtube.com/watch?v=fBXuhELODGA Vortrag: "Keynote und Vision Grundschutz++" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.youtube.com/watch?v=PxOjkV6oUwU Vortrag "Grundschutz++ Methodik und Einstieg ins BCM" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.bsi.bund.de/dok/it-sa Am Mittwoch, 08.10.2025 werden auf der it-sa die von den Arbeitsgruppen aus der Community erarbeiteten Ergebnisse präsentiert.]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]
*[[Grundschutz++ Migration|Migrationsstrategie für den Umstieg von BSI IT-Grundschutz auf Grundschutz++]]

[[Kategorie:Artikel]]
[[Kategorie:Grundschutz]]
[[Kategorie:++]]

Grundschutz++ Einführung und Aufbau

2026-04-04T17:40:53Z

Dirk: /* Schritt 1: Erhebung und Planung (PLAN - Governance/Compliance) */

[[Datei:Teamwork-2198961.png|alternativtext=Zahnrad|rechts|240x240px]]{{#seo:
|title=Grundschutz++ Einführung und Anleitung
|keywords=ISMS, Wiki, BSI Grundschutz++, IT-Grundschutz, BSI-Standard 200-2, Bausteine, OSCAL, JSON, Informationssicherheit, Risikomanagement, Anforderungen
|description=Überblick über den neuen BSI Grundschutz++. Startseite zur Navigation durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.
}}{{SHORTDESC:Grundschutz++ Überblick und Anleitung}}''Dieser Artikel bietet einen schrittweisen Überblick über BSI '''Grundschutz++''' und navigiert durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.''

== Einführung in Grundschutz++ ==
'''Grundschutz++''' ist die 2026 vom BSI eingeführte Weiterentwicklung des IT-Grundschutz-Kompendiums. Es transformiert das bewährte Grundschutz-Konzept in ein vollständig digitales, maschinenlesbares Format mit JSON-basierten Bausteinen und OSCAL-kompatibler Struktur.<blockquote>
''Der aktuelle Stand von Grundschutz++ ist bisher nur sehr eingeschränkt praktisch anwendbar, da einige wesentliche Definitionen und Teile der Methodik noch fehlen. Dazu gehören beispielsweise die Nutzung von Kennzahlen, Blaupausen, Stufen, Schutzbedarf vs. Schutzniveau und die Modellierung.''

''Der Anforderungskatalog liegt zwar im OSCAL- und Excel-Format vor, ist ohne eine abgeschlossene und nachvollziehbare Methodik aber nicht sinnvoll anwendbar.''
</blockquote>
=== Wesentliche Neuerungen===
*'''OSCAL/JSON-basiertes Regelwerk''': Der IT-Grundschutz wird in ein maschinenlesbares '''JSON-Format''' überführt, das teilweise automatisierte Compliance-Prüfungen und Integrationen in bestehende IT-Systeme ermöglicht. Dies ersetzt die bisherigen textbasierten PDFs und Listen.
*'''Prozessorientierte Struktur''': Die neue Version ist modular und objektorientiert aufgebaut, um Redundanzen zu reduzieren und die Dokumentationslast zu verringern.
*'''Leistungskennzahlen''': Kennzahlen sollen die Informationssicherheit messbar und den Sicherheitsgewinn einzelner Anforderungen transparenter machen.
* '''Harmonisierung mit ISO 27001''': Die Anforderungen werden stärker mit internationalen Standards wie '''ISO 27001:2022''' abgestimmt, um Doppelzertifizierungen zu vereinfachen.
*'''Erweiterung um moderne Technologien''': Geplant sind auch spezifische Module für '''Cloud-Security, KI und IoT''', die aktuelle Bedrohungsszenarien abdecken.
===Ziele der Reform===
*'''Schlankere Prozesse''': Durch Automatisierung soll der administrative Aufwand sinken.
*'''Dynamische Anpassung''': JSON ermöglicht schnellere, ggf. automatisierte Updates bei neuen Cyberbedrohungen.
*'''Praxisorientierte Vereinfachung''': Der BSI will die Dokumentationslast reduzieren und den Fokus auf risikobasierte Ansätze legen, insbesondere für KMU.
*'''Priorisierung und Messbarkeit''': Durch eine stufenweise Priorisierung von Anforderungen und Leistungskennzahlen soll ein zielgerichteteres Vorgehen und die bessere Messbarkeit der Sicherheit gefördert werden.
Die Änderungen reagieren auf Kritik an der bisherigen Komplexität und sollen besonders KMU entlasten, während die ganzheitliche Sicherheitsmethodik (technisch, organisatorisch, personell) erhalten bleibt.

''Hinweis'': Details zur finalen Struktur werden schrittweise im Jahr 2026 veröffentlicht. Unternehmen sollten sich frühzeitig mit den geplanten Schnittstellen (z.B. für Security-Tools) vertraut machen.

Offizieller '''Starttermin''' für den Grundschutz++ war der '''1.1.2026'''. Danach ist allerdings eine längere Übergangsphase (bis 2029) geplant, in der beide Standards parallel genutzt werden können, so wie bei der letzten Modernisierung auch. Da jedoch zu erwarten ist, dass eine automatisierte Migration auch diesmal nicht oder nur eingeschränkt möglich sein wird, sollte speziell in größeren Verbünden rechtzeitig begonnen werden! Der jeweils aktuellen Grundschutz++ Katalog wird auf [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek GitHub] veröffentlicht.
=== Bedeutung von OSCAL im Grundschutz++ ===
Das zugrundeliegende Format für Grundschutz++ ist [[OSCAL]].

[[OSCAL]] ist ein '''Framework''' bzw. eine '''Datenmodellierungssprache''', die vom NIST speziell für Sicherheitsanforderungen und Compliance-Dokumentation entwickelt wurde. OSCAL definiert dabei nur ein festes Schema für Sicherheits- und Compliance-Daten und lässt das zugrundeliegende Datenformat (JSON, XML oder YAML) offen.

Das BSI hat sich beim Grundschutz++ für das Datenformat '''JSON''' entschieden.

Dies ermöglicht es mit entsprechenden Tools Sicherheitsanforderungen automatisiert einzulesen und zu bearbeiten. D.h.

* Anforderungen können (teil-)automatisiert von entsprechenden Tools bearbeitet und dokumentiert werden, sofern entsprechende Tools zur Verfügung stehen oder vom Anwender (ggf. Dienstleister) programmiert werden.
* Kataloge und Sicherheitskonzepte (SSPs) können zwischen ISMS-Tools herstellerunabhängig ausgetauscht werden (sofern Toolhersteller sich an den Standard halten und entsprechende Im- und Exportfonktionen in ihren Tools zur Verfügung stellen).

Das heißt aber nicht:

* Das Anwender, Sicherheitsmanager oder Sicherheitsbeauftragte OSCAL lernen müssen oder OSCAL Formate lesen können müssen. (Dafür gibt es Tools, die die Inhalte lesbar und bearbeitbar zur Verfügung stellen)
* Das alle Anforderungen automatisiert erfüllt und dokumentiert werden (viele Anforderungen sind nach wie vor organisatorische Anforderungen die nur von Menschen durch Erstellung und Beachtung entsprechenden Regelungen erfüllt werden können).
* Das überhaupt irgendwelche Anforderungen automatisiert erfüllt und dokumentiert werden (Hierzu müssten die Systeme an ein ISMS-Tool angebunden sein und diese über entsprechende Schnittstellen mit Informationen bedienen). Sowohl die Tools als auch die Schnittstellen werden absehbar nicht vom Himmel fallen.
===Satzschablonen===
Anforderungen werden im Grundschutz++ zukünftig mit Satzschablonen erstellt, die wie folgt aussehen:<blockquote><big>'''<span style="color:green">{Praktik} [für {Zielobjektkategorie}]</span> <span style="color:red">{MODALVERB}</span> <span style="color:blue"><Ergebnis></span> <span style="color:purple">{Handlungswort}</span>''' ''<span style="color:grey">(TAGs) (Hinweise)</span>''</big></blockquote>'''Praktik''': Ein Prozess im Rahmen des ISMS, eine konkrete Sicherheitsmaßnahme oder eine allgemeine Vorgehensweise zur Erreichung eines Sicherheitsziels (z.B. IT-Betrieb, Personal, Konfiguration) - Im weitesten Sinne vergleichbar mit den bisherigen Bausteinen. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/practices.csv Liste der gültigen Praktiken.]

'''Zielobjektkategorie''': Wie bisher, das Objekt oder die Entität, auf die sich die Sicherheitsanforderungen beziehen (z.B. Daten, Personen, Endgeräte, Hostsysteme). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/target_object_categories.csv Liste der Gültigen Zielobjektkategorien.]

'''Modalverb''': Gibt die Verbindlichkeit einer Anforderung an (MUSS, SOLLTE, KANN). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/modal_verbs.csv Liste der gültigen Modalverben.]

'''Ereignis''': Der sicherheitsrelevante Zustand oder Auslöser, der zu einer bestimmten Handlung führt - Entspricht in Verbindung mit dem Handlungswort dem wesentliche Inhalt der Anforderung.

'''Handlungswort''': Das Verb, das die konkrete Sicherheitsmaßnahme oder Art der Tätigkeit beschreibt (regeln, zuweisen, konfigurieren). Handlungsworte können auch zur besseren Filterung genutzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/action_words.csv Liste der gültigen Handlungsworte.]

Das ganze kann noch mit '''TAG'''s für eine bessere Gruppierung und mit einem '''Hinweis''' zu weiterführenden Informationen ergänzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/tags.csv Liste der gültigen TAGs.]

Die bisherigen Anforderungen des Kompendium werden aktuell in ihre Teilanforderungen zerlegt und jede Teilanforderung wird zukünftig eine eigene Anforderung. D.h. jedes Modalverb (SOLL, MUSS, KANN) der bisherigen Anforderungen stellt zukünftig i.d.R. eine eigene Anforderung dar. Die Gesamtanzahl der Anforderungen soll dabei durch die Vermeidung von Redundanzen dennoch sinken.

'''Beispiel'''

Die Anforderung:<blockquote>'''ISMS.1.A4 Benennung eines oder einer Informationssicherheitsbeauftragten (B) [Institutionsleitung]'''

Die Institutionsleitung MUSS einen oder eine ISB benennen. '''. . .'''

Die Institutionsleitung MUSS den oder die ISB mit angemessenen Ressourcen ausstatten.

Die Institutionsleitung MUSS dem oder der ISB die Möglichkeit einräumen, bei Bedarf direkt an sie selbst zu berichten. '''. . .'''</blockquote>Wird jetzt zu den Anforderungen:<blockquote>'''GOV.4.2''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">einer Person die Rolle ISB</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.2.3''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">für das ISMS erforderliche personelle, finanzielle und zeitliche Ressourcen</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.4.4''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">dem ISB das direkte und jederzeitige Vorspracherecht bei der Institutionsleitung</span> '''<span style="color:purple">ermöglichen</span>.'''</blockquote>Da dies übergreifende Anforderungen sind, ist hier kein spezifisches Zielobjekt benannt.

Einzelne Teilanforderungen können auch in anderen Praktiken beschrieben sein.
===Priorisierung===
Alle Anforderungen werden einer Prioritätsstufe zugeordnet, um die Umsetzung effizient zu gestalten:
*'''Stufe 0''': Zwingend (sofort) umzusetzende Anforderungen zur Sicherstellung der ISO-Kompatibilität (MUSS-Anforderungen).
Die Stufen 1-4 geben den Umsetzungsaufwand der Anforderungen wieder:
*'''Stufe 1''': Schnell und mit geringem Aufwand (~1 Tag) realisierbare Maßnahmen (QuickWin) / keine laufenden Aufwände.
*'''Stufe 2''': Mit eigenen Mitteln leicht umsetzbare Anforderung (~1 Woche) / geringe laufende Aufwände.
*'''Stufe 3''': Mit normalem Aufwand (mehrere Wochen) und ggf. externer Unterstützung umsetzbar / normale laufende Aufwände.
*'''Stufe 4''': Höherer Umsetzungsaufwand, häufig in längerfristigen Projekten mit externen Experten.
Die nächste Stufe sind optionale Anforderungen als Vorschläge bei erhöhtem Schutzbedarf.
*'''Stufe 5''': Umfassende/zusätzliche Anforderungen für höheren Schutzbedarf.
Diese Einstufung ermöglicht eine schnelle Einschätzung des Umsetzungsaufwands und hilft bei der effizienten Ressourcenplanung.
===Leistungskennzahlen===
Leistungskennzahlen dienen der '''Messung und Bewertung''' der Umsetzung von Sicherheitsanforderungen im Grundschutz++. Sie ermöglichen eine objektive Einschätzung des Sicherheitsniveaus und unterstützen die kontinuierliche Verbesserung. Wie diese Leistungskennzahlen genutzt werden sollen ist nach wie vor unklar und viele Anforderungen sind bislang noch nicht bewertet.
====Bewertungskriterien====
Jede Anforderung wird in Bezug auf die drei Schutzziele bewertet:
*'''Vertraulichkeit (C)'''
*'''Integrität (I)'''
*'''Verfügbarkeit (A)'''
Anforderungen erhalten Punktwerte in diesen Kategorien, die zur Bestimmung des Schutzgrades genutzt werden (z.B. C=6, I=2, A=0 ist eine Anforderung die im Wesentlichen die Vetraulichkeit stärkt, in Teilen die Intgrität aber nicht die Verfügbarkeit).

Die einzelen Kennzahlen werden je Schutzziel, Praktik und/oder Zielobjekt aufsummiert und ergeben so den Erfüllungsgrad.
====Schwellwerte und Erfüllungsgrad====
*'''Schwellwerte''' definieren das angestrebte Sicherheitsniveau basierend auf der Summe der Punktwerte aller umgesetzten Anforderungen je Schutzziel, Zielobjekt und Schutzstufe.
*'''Der Erfüllungsgrad''' zeigt, welche Anforderungen bereits umgesetzt wurden.
Die Leistungskennzahlen bieten damit eine fundierte Entscheidungsgrundlage für Organisationen, um ihren Sicherheitsstatus gezielt zu verbessern, wenn sie wie ursprünglich geplant eingeführt werden.
==Was bleibt erhalten?==
===Standards und Vorgehen===
Trotz eines deutlich anderen Formats und einer anderen Gruppierung der Anforderungen bleibt das grundsätzliche Vorgehen weitgehend gleich.

D.h. die Standards 200-1 bis 200-4 sollen erst einmal weiter Verwendung finden. Die bisher üblichen Arbeitsschritte:
#Festlegung des Geltungsbereichs
#Strukturanalyse
#Schutzbedarfsfeststellung
#Modellierung
#IT-Grundschutzcheck (GSC)
#Risikoanalyse
bleiben grundsätzlich erhalten, ändern sich jedoch in der praktischen Anwendung und Priorität (insbesondere in der '''Modellierung''' und den '''Grundschutzchecks'''). Parallel zur Einführung sollen die Standards weiter entwickelt werden.

'''MUSS'''-Anforderungen sind weiterhin '''verpflichtend''' für eine Zertifizierung, sollen aber deutlich rediziert werden.

'''SOLLTE'''-Anforderungen bleiben auch weiter '''grundsätzlich verpflichtend''', können aber ggf. mit angemessener Begründung oder Ersatzmaßnahmen wegdiskutiert werden.

Lediglich '''KANN'''-Anforderungen sind optional.
===Tool-Einsatz===
Auch der Einsatz von ISMS-Tools wird weiterhin Bestand haben. Alle größeren Tool-Hersteller arbeiten mit Hochdruck an der Integration von Grundschutz++ in ihre Tools. Hier wird es perspektivisch Erleichterungen durch einen leichteren Datenaustausch zwischen den Tools und mehr Automatisierungspotential geben.
==Gegenüberstellung Grundschutz Kompendium vs. Grundschutz++==
Das IT-Grundschutz-Kompendium 2023 und der zukünftige Grundschutz++ bieten unterschiedliche Konzepte für die Umsetzung von Informationssicherheit: Während das Kompendium auf feste Bausteine in thematisch gegliederten Schichten setzt, verwendet Grundschutz++ modulare, flexibel einsetzbare Praktiken.

Die folgende Tabelle stellt die wesentlichen Unterschiede und Gemeinsamkeiten zwischen beiden Ansätzen (nach aktuell verfügbaren Kenntnissen) gegenüber:
{| class="wikitable"
|+
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Fester verbindlicher Katalog''' von Anforderungen (PDF, Excel und XML), die je nach Reifegrad erfüllt werden müssen.
|Der '''variable''' und erweiterbare '''[[OSCAL]]'''-Datenbestand kann beliebig an die Bedürfnisse der Organisation angepasst werden. Zusätzliche Kataloge/Erweiterungen (C5, Datenschutz, KRITIS/NIS2) können je nach Verfügbarkeit ergänzt werden. Durch die Beseitigung vermeintlicher Redundanzen soll die Anzahl der Anforderungen erheblich reduziert werden (~10–20 % verbleibende Anforderungen gegenüber dem Grundschutz Kompendium).
|-
|
|Järliche '''Aktualisierung''' zum Stichtag '''1. Februar'''.
(bis 2023)
|Die '''Aktualisierung''' erfolgt '''fortlaufend''' nach Bedarf und Verfügbarkeit. Die Regelungen zur Relevanz für Zertifizierungen sind bislang noch nicht bekannt.
|-
|
|Das Kompendium ist (Stand 2023) in 10 '''Schichten''' mit insgesamt 111 '''Bausteine''' gegliedert, die statisch die jeweiligen Anforderungen enthalten.
|'''Praktiken''' und '''''Zielobjektkategorien''''' (Achtung abweichende Bedeutung in GS++) sind allgemeinere und wiederverwendbare, sicherheitsrelevante Verfahren oder Anforderungen. Sie können modular und situationsabhängig einzelnen Assets zugeordnet werden.
Die voraussichtlich ca. 20 Praktiken liegen irgendwo zwischen Schichten und Bausteinen. Sie sind prozessorientierter, adressieren eher Zielgruppen oder Handlungstypen und sind nicht mehr starr bestimmten Zielobjektkategorien zugeordnet. Zielobjektkategorien entsprechen zukünftig eher den Bausteinen im alten Grundschutz. Die Definitionen der Begriffe sind nach wie vor im Fluß!
|-
|
|'''Drei Stufen''' (Vorgehensweisen): Basis, Standard, erhöhter Schutzbedarf bilden den Reifegrad der Organisation ab.
|Es sind zukünftig '''sechs Stufen''' (0–5) geplant, die sich weitgehend am Umsetzungsaufwand der jeweiligen Anforderung orientieren: Je kleiner die Stufe, desto schneller bzw. leichter ist die Anforderung umsetzbar (Quick Win). Eine qualitative Bewertung des Reifegrads muss zukünftig anders erfolgen (z. B. über Leistungskennzahlen).
Das '''Sicherheitsniveau''' gibt zukünftig an, in welchem Maß die definierten Sicherheitsziele erreicht sind. Es ergibt sich aus der wirksamen Umsetzung organisatorischer, technischer und personeller Anforderungen.

Unterschieden werden:
*'''Normales Sicherheitsniveau''': entspricht dem Stand der Technik
*'''Erhöhtes Sicherheitsniveau''': für besonders schutzbedürftige Informationen oder Systeme
|-
|
|'''Zielobjekte''' als gruppierte Sammlung von gleichartigen Assets die zur späteren '''Modellierung''' (Zuordnung der Bausteine und Abhängigkeiten) genutzt werden.
|'''Zielobjekte''' werden auch in Zukunft eine ähnliche Funktion zur Gruppierung und '''Modellierung''' haben, entsprechend dabei aber eher den klassischen Bausteinen. Die konkreten Vorgaben zur Modellierung sind jedoch noch nicht detailliert genug. In der Modellierung werden die Praktiken nicht mehr statisch bestimmten Zielobjekttypen zugewiesen. Klassische Zielobjekte werden zukünftig als Assets oder Assetgruppen bezeichnet.
|-
|
|Modalverben '''MUSS''', '''SOLLTE''', '''KANN''' bestimmen die Verbindlichkeit von Anforderungen.
|Die Bedeutung der Modalverben ('''MUSS, SOLLTE, KANN''') bleibt unverändert. Ein Ziel von Grundschutz++ ist es jedoch, die Anzahl der Muss-Anforderungen auf das Nötigste zu reduzieren (unter 10 %). Dadurch soll der Grundschutz flexibler werden. Die Verbindlichkeit von Anforderungen, die über MUSS-Anforderungen hinausgehen, ist noch unklar.
|-
|
| -
|Neu sind '''Leistungskennzahlen''', die eine qualitative Bewertung der Anforderungen in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit darstellen. Sie sollen als Zahlenwert darstellbar sein und so den Reifegrad abbilden können. Bisher ist noch nicht bekannt, ob und wann diese eingeführt werden und wie die konkreten Regelungen aussehen werden.
|-
|
|Gültigkeit voraussichtlich bis 2029
|Gültig ab 1.1.2026. Zertifizierbar geplant ab 2027.
|}Teilweise werden Begrifflichkeiten neu (oder anders) definiert:
{| class="wikitable"
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Zielobjekt''' als gruppierte Sammlung von gleichartigen Assets als Grundlage für die spätere Modellierung
|'''Asset''' und gruppierte Assets. Die Gruppierung gleichartiger Assets kann weiterhin erfolgen es bleiben jedoch auch dann '''Assets'''. Der Begriff ''Zielobjekt'' wird hierfür nicht mehr genutzt.
|-
|
|'''Baustein''' als Sammlung von Anforderungen für bestimmte Zielobjekttypen.
|'''Zielobjektkategorien''' sind zukünftig das was bislang die ''Bausteine'' waren, bestimmte Typen von Assets für die spezische Anforderungen gelten. Die Assets werden den Zielobjektkategorien zugewisen und erhalten über diese ihre Anforderungen. Eine klare Definition der Begriffe ist noch im Fluß.
|-
|
|
|
|}
==Blaupausen==
Blaupausen sind vorgefertigte Musterlösungen (wie die bisherigen IT-Grundschutz-Profile), die als Vorlage (Referenzmodell) für die Erstellung und Umsetzung von branchenspezifischen oder organisationsspezifischen Sicherheitskonzepten dienen.
===Funktion der Blaupausen===
Solche Blaupausen erfassen typische Strukturen, Risiken, Anforderungen und Maßnahmen für bestimmte Anwendungsszenarien, etwa die Nutzung der E-Akte oder den sicheren Betrieb von 5G-Infrastrukturen. Sie ermöglichen es, ein ISMS deutlich effizienter und strukturierter aufzubauen, weil die grundlegenden Überlegungen (Schutzbedarfsermittlung, Zuordnung von Praktiken, Zielobjekten und Maßnahmen, etc.) bereits allgemein gültig vorformuliert sind und nur noch organisationsspezifisch angepasst werden müssen.
===Ziel und Nutzen===
*Blaupausen helfen, den Implementierungsaufwand für ISMS nach Grundschutz++ zu reduzieren.
*Sie fördern die Standardisierung und Wiederverwendbarkeit von Sicherheitskonzepten für ähnliche Organisationen oder Branchen.
*Besonders für kleinere Organisationen und typische Anwendungsfälle bieten sie einen niederschwelligen, strukturierten und praxiserprobten Einstieg in die Absicherung.
Damit sind Blaupausen im Grundschutz++ zentrale Instrumente, um bewährte Sicherheitsmethoden als Vorlage für den schnellen und einheitlichen Aufbau eines branchenspezifischen ISMS bereitzustellen.
===Umsetzung===
Umgesetzt werden Blaupausen technische als '''OSCAL-Profile''' mit zusätzlichen Erläuterungen in Textform, zukünftig sollen Blaupausen zu einem '''System Security Plan (SSP)''' weiter entwickelt werden.
== Grundlagen und Standards ==

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_1.html BSI-Standard 200-1: Anforderungen an ein ISMS].
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_2.html BSI-Standard 200-2: IT-Grundschutz Methodik] ( <- Wird neu erstellt )
** [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html Methodik zum Grundschutz++] (Aktuell in Erstellung, ersetzt zukünftig 200-2)
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_3.html BSI-Standard 200-3: Risikomanagement mit Grundschutz].
* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/BSI-Standards/BSI-Standard-200-4-Business-Continuity-Management/bsi-standard-200-4_Business_Continuity_Management_node.html BSI-Standard 200-4: Business Continuity Management].
* [[OSCAL|OSCAL (Open Security Controls Assessment Language)]].

== Schritt-für-Schritt-Methodik ==
Die Methodik zum Grundschutz++ folgt einem '''5-stufigem PDCA-basierten Prozess''' mit Fokus auf '''Anforderungsmodellierung''' und '''maschinenlesbarer Verarbeitung'''. Hier das praktische Vorgehen:

=== Schritt 1: Erhebung und Planung (PLAN - Governance/Compliance) ===
Du legst hier die strategische Basis für Dein ISMS, indem Du den Kontext Deiner Institution analysierst, Compliance-Pflichten (z. B. DSGVO, BDSG) und Erwartungen interessierter Parteien (Kunden, Behörden, Mitarbeitende) feststellst. Anschließend entwickelst Du eine Informationssicherheitsleitlinie mit SMART-Zielen und einer Strategie, definierst den Geltungsbereich (Scope: welche Prozesse, Standorte, Systeme), klassifizierst den Schutzbedarf kritischer Geschäftsprozesse (normal oder hoch), richtest Rollen wie den unabhängigen ISB ein und initiierst Risikomanagement sowie Dokumentationspflichten – alles freigegeben von der Leitung.

'''Unterschied zu BSI-Standard 200-2:''' Während 200-2 mit Bausteinen und Risikoanalyse startet, integriert Grundschutz++ Governance und Compliance früher und stärker in den PDCA-Planungszyklus, mit Fokus auf maschinenlesbare Strukturen und Institutionsleitungspflicht – weniger asset-zentriert, mehr prozess- und rolleorientiert ab Schritt 1.
# '''Kontextanalyse''' (intern/extern) durchführen
# '''Interessierte Parteien''' identifizieren und Anforderungen erfassen
# '''Geltungsbereich''' (Scope) durch Institutionsleitung festlegen und freigeben
# '''Geschäftsprozesse''' priorisieren → Schutzbedarf "normal" oder "hoch" einstufen
# '''Sicherheitsleitlinie''' erstellen (Ziele, Strategie, Verpflichtung Leitung)
# '''Sicherheitsorganisation''' etablieren (Rollen: ISB, Asset-Owner, etc.)
# '''Compliance-Management''' initialisieren (Rechts-/Vertragskatalog)

'''Ergebnis''': Organisatorischer Rahmen, Sicherheitsleitlinie, priorisierte Prozesse

'''Weiterführende Informationen:'''

* [[Informationssicherheitsleitlinie]]
* [[IS-Strategie]]
* [[Geschäftsprozesse]]

=== Schritt 2: Anforderungsanalyse (PLAN - Strukturmodellierung) ===
Starte mit der Abgrenzung des Informationsverbunds (technische, organisatorische Einheit innerhalb des Geltungsbereichs), erfasse Assets (z.B. Server, Daten, Rollen) pro priorisiertem Geschäftsprozess und ordne sie Zielobjektkategorien zu (z.B. „Anwendung“ mit Vererbung übergeordneter Kategorien). Modelliere dann Anforderungen aus GS++-Praktiken (ISMS-weit plus assetbezogen), ergänze bei Bedarf externe Pflichten oder risikobasierte (nach Risikobetrachtung), prüfe das Sicherheitsniveau ("normal SdT" oder "erhöht") und treffe Gestaltungsentscheidungen (z.B. Parameter wie Zuständigkeiten) – Ergebnis: individuelles Anforderungspaket.

'''Unterschied zu BSI-Standard 200-2:''' Statt starrer Baustein-Zuordnung und manueller Risikoanalyse nutzt Grundschutz++ eine modellbasierte, hierarchische Anforderungsableitung via Assets und Zielobjektkategorien (OSCAL-fähig, maschinenlesbar), mit automatisierbarer Vererbung und klarer Trennung von Standard- (SdT) und ergänzenden Anforderungen – skalierbarer und zyklischer als die lineare 200-2-Methodik.
# '''Informationsverbund''' definieren (techn./org. Abgrenzung)
# '''Assets''' für wichtigsten Geschäftsprozess erfassen
# '''Asset → Zielobjektkategorien''' mapping (Hierarchie + Vererbung)
# '''Anforderungspaket''' generieren:
#* ISMS-Praktiken (vollständig)
#* Zielobjekt-Anforderungen (Sicherheitsniveau: normal/erhöht)
#* Zielobjektlose Anforderungen prüfen
# '''Ergänzungen''': Externe Verpflichtungen, anforderungslose Assets
# '''Risikobetrachtung''' bei hohem Schutzbedarf oder Niveauerhöhung
# '''Parameter setzen''' (Zuständigkeiten, Werte)

'''Ergebnis''': Individuelles Anforderungspaket pro Informationsverbund

'''Weiterführende Informationen:'''

* [[Strukturanalyse]]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das OSCAL-basierte Grundschutz++ Kompendium auf Github.]

=== Schritt 3: Realisierung (DO - Umsetzung) ===
In diesem Schritt setzt Du das Anforderungspaket aus Schritt 2 um, indem Du den Ist-Zustand aller Anforderungen bewertest (Umsetzungsstatus ermittelst), fehlende Umsetzungen priorisierst (nach Risiko und Aufwand), einen Umsetzungsplan mit Zuständigkeiten und Fristen erstellst, Ausnahmen dokumentierst und freigibst sowie den Fortschritt verfolgst – inklusive Compliance-Sicherstellung durch regelmäßige Checks.

'''Unterschied zu BSI-Standard 200-2:''' Während 200-2 Maßnahmen aus Bausteinen direkt umsetzt und manuell dokumentiert, strukturiert Grundschutz++ die Realisierung zentral über das modellierte Anforderungspaket mit automatisierbarer Priorisierung und Nachverfolgung, stärker in den PDCA-Do-Zyklus eingebettet und skalierbar für große Verbünde.
# '''Umsetzungsstatus''' aller Anforderungen prüfen (ja/nein)
# '''Nicht-umgesetzte MUSS/SOLLTE''' → Risikobetrachtung
# '''Umsetzungsplan''' erstellen:
#* Priorisierung (Risiko, Aufwand, Synergien)
#* Zuständigkeiten + Fristen zuweisen
# '''Freigabe''' durch Institutionsleitung
# '''Fortschritt tracken''' (Ticketsystem/Projektmanagement)
# '''Ausnahmen dokumentieren''' (Begründung + Leitungsfreigabe)

'''Ergebnis''': Umsetzungsplan + Status-Dokumentation

'''Weiterführende Informationen:'''

* [[LF-Grundschutzcheck|Leitfaden Grundschutzcheck]]
* [[RiLi-Freigabe]]
* [[RiLi-Ausnahmemanagement|Richtlinie zum Management von Ausnahmen und Abweichungen]]

=== Schritt 4: Überwachung (CHECK - Monitoring/Evaluation) ===
Hier überprüfst Du die Wirksamkeit des ISMS durch Leistungsbewertung (z. B. KPIs), Compliance-Monitoring, Audits (mit Bewertungsschemata und Berichten), Management-Reviews und Validierung der Anforderungen gegen aktuelle Bedrohungen – Tools wie Monitoring-Software unterstützen die kontinuierliche Erfassung.

'''Unterschied zu BSI-Standard 200-2:''' Grundschutz++ erweitert die Überwachung (PDCA-Check) um maschinenlesbare Audit-Modelle und Validierung des Anforderungspakets, statt isolierter Baustein-Checks; es integriert dynamische Monitoring-Tools und Managementbewertungen enger, für zyklische Anpassung statt einmaliger Prüfung.
# '''Leistungsbewertung''' (KPIs, Umsetzungsfortschritt, Vorfälle)
# '''Compliance-Überwachung''' (gesetzlich/vertraglich)
# '''Auditprogramm''' risikobasiert durchführen
# '''Managementbewertung''' → Managementbericht erstellen
# '''Monitoring-Tools''' einsetzen (SIEM, Vulnerability Scanner)
# '''Anforderungspaket validieren''' (Aktualität prüfen)

'''Ergebnis''': Auditberichte, Managementbericht

'''Weiterführende Informationen:'''

* [[Reifegradmodell]]
* [[KPIs|Key Performance Indicators (KPIs)]]
* [[Managementbericht|Erstellen eines Managementberichts]]

=== Schritt 5: Kontinuierliche Verbesserung (ACT - Verbesserung) ===
Du handelst Erkenntnisse aus Schritt 4 ab, indem Du Nicht-Konformitäten analysierst, Verbesserungspotenziale identifizierst, Korrektur- und Verbesserungspläne erstellst, deren Wirksamkeit prüfst und Compliance-Verstöße behebst – so bleibt das ISMS dynamisch und anpassbar an neue Risiken.

'''Unterschied zu BSI-Standard 200-2:''' Im Gegensatz zur reaktiven 200-2-Verbesserung (nach Risikoanalyse) schließt Grundschutz++ den PDCA-Act-Zyklus modellbasiert ab, mit systematischer Integration von Audit-Ergebnissen ins Anforderungspaket und automatisierbarer Wirksamkeitsprüfung – prozessorientierter und weniger manuell.
# '''Nicht-Konformitäten''' analysieren
# '''Verbesserungspotenziale''' identifizieren
# '''Korrektur-/Verbesserungsplan''' → in Umsetzungsplan integrieren
# '''Wirksamkeit prüfen''' nach Umsetzung
# '''Sicherheitsniveau''' bewerten (Trendanalyse)
# '''Compliance-Verstöße''' behandeln

'''Ergebnis''': Aktualisiertes Anforderungspaket → neuer PDCA-Zyklus

'''Weiterführende Informationen:'''

*

=== Praktische Hinweise ===
* '''Tool-gestützt''': JSON/OSCAL-Bausteine, Zur Nutzung sind ISMS-Tools empfohlen.
* '''Iteration''': Wichtigster Geschäftsprozess zuerst, dann schrittweise erweitern
* '''Risikobetrachtung''': Bei Sicherheitsniveau "hoch" oder Nicht-Umsetzung
* '''Dokumentation''': bevorzugt Maschinenlesbar (OSCAL) für besseren Austausch

'''Zyklusdauer''': Jährlich oder ereignisgesteuert (Änderungen, Vorfälle, Audits)

== Migration bestehender Sicherheitskonzepte ==
...

'''Weiterführende Informationen:'''

[[Grundschutz++ Migration]]

== Offenen Punkte und Kritiken ==

=== Zu viele Beteiligte, unklare Zuständigkeiten ===
Die Weiterentwicklung des Grundschutzes wird inzwischen nicht mehr ausschließlich vom Grundschutz-Referat des BSI verantwortet. Mit dem Einstieg des Referats „Stand der Technik“ und der verstärkten Einbindung der „Community“ sind die Zuständigkeiten und Verantwortlichkeiten unklarer geworden. In Präsentationen und Veröffentlichungen werden die Rollen und Aufgaben der verschiedenen Beteiligten unterschiedlich dargestellt. Es fehlt eine klare, kommunizierte Schnittstelle, wer für welche Aspekte der Entwicklung, Pflege und Kommunikation des neuen Standards verantwortlich ist. Das erschwert für Anwendende die Orientierung und die Planung der eigenen Umsetzungsstrategie.

=== Unklare Umsetzung einiger Ziele ===
Einige der im Grundschutz++ adressierten Ziele und Neuerungen sind nach wie vor nicht ausreichend konkretisiert. Besonders die Einführung von Leistungskennzahlen und die Priorisierung der Anforderungen (Stufen) werfen noch viele Fragen auf. Die konkrete Bedeutung, Messung und praktische Umsetzung dieser Leistungskennzahlen werden von verschiedenen BSI-Vertretern unterschiedlich dargestellt. Auch die Stufenmodelle werden teils als Priorisierung, als Entwicklungsstufen oder als reiner Umsetzungaufwand der Anforderungen definiert und sind in ihrer praktischen Anwendung noch nicht abschließend geklärt. Das führt zu Unsicherheiten, wie diese neuen Instrumente im einem ISMS umgesetzt und nachgewiesen werden sollen.

=== Geringer Mehrwert im Vergleich zu ISO 27001 ===
Die Anforderungen im Grundschutz++ werden zunehmend an die Formulierungen und Strukturen der ISO 27001 angeglichen. Während der klassische IT-Grundschutz durch seine konkreten, praxisnahen Maßnahmen einen klaren Mehrwert gegenüber der eher abstrakten ISO 27001 bot, verliert er durch die Harmonisierung mit internationalen Standards zunehmend diesen Vorteil. Die Anforderungen werden stärker abstrakt modularisiert formuliert, wodurch der spezifische Bezug zu typischen Umsetzungsbeispielen und die Detailtiefe abnehmen. Für viele Organisationen wird sich daher die Frage stellen, warum sie den immer noch aufwändigeren Weg über den Grundschutz wählen sollten, wenn sie mit ähnlichem oder geringeren Aufwand direkt eine ISO 27001-Zertifizierung anstreben können.

=== Zu ambitionierter Zeitplan ===
Der Grundschutz++ sollte ab dem 1.1.2026 grundsätzlich gültig und anwedbar sein, wobei eine Übergangsphase bis 2029 vorgesehen war. Bisher ist nur ein erster Entwurf veröffentlicht. Angesichts der Vielzahl an noch offenen Fragen, der fehlenden Migrationsstrategie und der Komplexität der Änderungen erscheint der Zeitplan sehr ambitioniert. Ausarbeitung und Dokumentation liegen bisher nur als Entwurf vor. Eine Pilotierung und Einführung 2026 und eine Übergangsphase bis 2029 ist vorgesehen. Die Gefahr besteht, dass größere Organisationen unter Zeitdruck unzureichend vorbereitet in die neue Methodik wechseln und mit variablen Definitionen und Zielen arbeiten müssen, was die Akzeptanz und Qualität der Umsetzung gefährdet.

=== Zunehmende (Sicherheits-)Lücke zwischen Grundschutz und Grundschutz++ ===
Mit der Entscheidung des BSI, den bisherigen IT-Grundschutz (Edition 2023) nicht mehr weiterzuentwickeln und stattdessen auf das neue Grundschutz++-Modell zu setzen, entsteht eine wachsende Lücke in der Informationssicherheit. Diese Übergangsphase bis 2029 ist sicherheitstechnisch kritisch, da sich die Bedrohungslage in der IT nicht an Entwicklungszyklen von Sicherheitsstandards orientiert. Neue Angriffsvektoren, insbesondere durch den zunehmenden Einsatz von KI in der Cyberkriminalität (z.B. KI-gestützte Malware, Deepfakes, automatisierte Phishing-Kampagnen), entstehen kontinuierlich und erfordern zeitnahe, wirksame Gegenmaßnahmen. Der bisherige Grundschutz bildet diese aktuellen Bedrohungen und technologische Entwicklungen jedoch nicht mehr ab, während die spezifischen Module und Maßnahmen im Grundschutz++ noch nicht produktiv verfügbar oder praxistauglich sind.

=== Fehlende Migration vom Grundschutz-Kompendium zu Grundschutz++ ===
Aktuell existiert weder ein konkreter Plan noch ein Konzept für eine (teil-)automatisierte Migration bestehender Sicherheitskonzepte aus dem bisherigen Grundschutz-Kompendium in das neue Grundschutz++-Modell. Die Umstellung auf ein maschinenlesbares JSON/OSCAL-Format und die objektorientierte, prozessorientierte Struktur bedeuten einen fundamentalen Bruch mit bisherigen Strukturen. Die Unterschiede zwischen Grundschutz-Kompendium und Grundschutz++ sind gravierender als beim letzten Wechsel von den Grundschutz-Katalogen zum Kompendium, bei dem bereits alle Ansätze für eine automatisierte Migration weitgehend gescheitert sind. Auch diesmal ist absehbar, dass Organisationen ihre bestehenden Dokumentationen und Umsetzungen weitgehend manuell neu abbilden müssen, was insbesondere für größere Verbünde einen erheblichen Zusatzaufwand bedeutet. Es gibt zwar Ansätze dies mittels KI zu lösen, was aber sicher nicht für jede Organisation praktikabel sein wird.

== Fazit ==
Ein abschließendes Bild zum Grundschutz++ lässt sich aktuell noch nicht zeichnen – viele Details sind noch in der Entwicklung.

Die grundlegende Modernisierung des IT-Grundschutzes durch das Grundschutz++-Projekt ist zwar fachlich und technologisch nachvollziehbar und adressiert viele Schwächen des bisherigen Systems. Die Umsetzung ist jedoch nach jetzigem Entwicklungsstand mit erheblichen Risiken und Unsicherheiten verbunden. Ohne klare Migrationspfade, eindeutige Zuständigkeiten und praxistaugliche Konkretisierungen der neuen Instrumente besteht die Gefahr, dass die Akzeptanz des Grundschutzes sinkt und Organisationen sich vermehrt alternativen Standards wie der ISO 27001 zuwenden. Ein realistischer Zeitplan und ein echter Mehrwert des neuen Standards sind daher essenziell für den Erfolg der Reform.

Der Artikel wird fortlaufend aktualisiert, sobald neue Informationen vom BSI veröffentlicht oder freigegeben werden.
===Ausblick und ToDos aus Anwendersicht===
Stichtag für die Einführung von Grundschutz++ war der '''1.1.2026'''. Das Datum wurde vom BSI in offiziellen Ankündigungen, Präsentationen und Fachveranstaltungen als verbindlicher Startpunkt kommuniziert. Ab diesem Zeitpunkt sollte das neue, digitale und prozessorientierte Regelwerk den bisherigen IT-Grundschutz ablösen. Bisher fehlt es jedoch an vielen Stellen an klaren Definitionen und konkreten Vorgaben zur Methodik.

Auch wenn abzuwarten bleibt, wann praxistaugliche Methoden verfügbar sind und wie lange die Übergangsfristen für die Umstellung sein werden (aktuelle Planung bis 2029). Abzusehen ist jedoch, dass der Aufwand und der Zeitdruck, insbesondere für größere und zertifizierte Verbünde, erheblich sein werden. Auch wenn es aktuell noch keine konkreten Beschreibungen zur Methodik und Modellierung gibt, können und sollten sich Anwender bereits jetzt vorbereiten. Dazu können die folgenden Maßnahmen dienen:
*Laufende Information über den aktuellen Stand (Internetseiten des BSI, Vorträge und Veröffentlichungen).
*Konsolidierung der bestehenden Verbünde (Reduzierung der Komplexität, konsistente Dokumentation der Gruppierung und Modellierung).
**Ein guter Tip ist es, in aktuellen GSC jede Teilanforderung (jedes Modalverb wie MUSS oder SOLLTE) in der Umsetzung einzeln zu dokumentieren, da diese zukünftig eigenständige Anforderungen darstellen und so eine Übernahme leichter werden könnte.
*Kontakt zu Toolherstellern aufnehmen und eine zügige Umsetzung in den verwendeten ISMS-Tools einfordern.
*Frühzeitige Planung der Bereitstellung entsprechender personeller Ressourcen für die Umstellung auf Grundschutz++ ab Mitte 2026.
*Gegebenenfalls frühzeitige Reservierung externer (personeller) Ressourcen zur Unterstützung.
*Es muss eine klare interne Kommunikation über die bevorstehenden, durch die Umstellung bedingten erhöhten Aufwände (Schulungen, neue (Erst-)GSCs und Anpassung der Dokumentation) geben, damit Mitarbeitende und Verantwortliche wissen, was auf sie zukommt.

== Weiterführende Ressourcen ==
*[https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html BSI IT-Grundschutz]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html BSI Leitfaden zur Grundschutz++-Methodik (1.4.2026)]
*[https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/Grundschutz/1GS_Tag_2025/Aktuelle_Entwicklungen_Ausblick_IT-GS.pdf Aktuelle Entwicklungen und Ausblick zum IT-Grundschutz - 1. Grundschutztag 2025]
*[https://www.youtube.com/watch?v=_AeWJ_Z8S-4 Keynote: Fortentwicklung des IT-Grundschutzes zu IT-Grundschutz++ (verinice.XP 2025)]
*[https://www.youtube.com/watch?v=fBXuhELODGA Vortrag: "Keynote und Vision Grundschutz++" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.youtube.com/watch?v=PxOjkV6oUwU Vortrag "Grundschutz++ Methodik und Einstieg ins BCM" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.bsi.bund.de/dok/it-sa Am Mittwoch, 08.10.2025 werden auf der it-sa die von den Arbeitsgruppen aus der Community erarbeiteten Ergebnisse präsentiert.]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]
*[[Grundschutz++ Migration|Migrationsstrategie für den Umstieg von BSI IT-Grundschutz auf Grundschutz++]]

[[Kategorie:Artikel]]
[[Kategorie:Grundschutz]]
[[Kategorie:++]]

Grundschutz++ Einführung und Aufbau

2026-04-04T11:04:54Z

Dirk:

[[Datei:Teamwork-2198961.png|alternativtext=Zahnrad|rechts|240x240px]]{{#seo:
|title=Grundschutz++ Einführung und Anleitung
|keywords=ISMS, Wiki, BSI Grundschutz++, IT-Grundschutz, BSI-Standard 200-2, Bausteine, OSCAL, JSON, Informationssicherheit, Risikomanagement, Anforderungen
|description=Überblick über den neuen BSI Grundschutz++. Startseite zur Navigation durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.
}}{{SHORTDESC:Grundschutz++ Überblick und Anleitung}}''Dieser Artikel bietet einen schrittweisen Überblick über BSI '''Grundschutz++''' und navigiert durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.''

== Einführung in Grundschutz++ ==
'''Grundschutz++''' ist die 2026 vom BSI eingeführte Weiterentwicklung des IT-Grundschutz-Kompendiums. Es transformiert das bewährte Grundschutz-Konzept in ein vollständig digitales, maschinenlesbares Format mit JSON-basierten Bausteinen und OSCAL-kompatibler Struktur.<blockquote>
''Der aktuelle Stand von Grundschutz++ ist bisher nur sehr eingeschränkt praktisch anwendbar, da einige wesentliche Definitionen und Teile der Methodik noch fehlen. Dazu gehören beispielsweise die Nutzung von Kennzahlen, Blaupausen, Stufen, Schutzbedarf vs. Schutzniveau und die Modellierung.''

''Der Anforderungskatalog liegt zwar im OSCAL- und Excel-Format vor, ist ohne eine abgeschlossene und nachvollziehbare Methodik aber nicht sinnvoll anwendbar.''
</blockquote>
=== Wesentliche Neuerungen===
*'''OSCAL/JSON-basiertes Regelwerk''': Der IT-Grundschutz wird in ein maschinenlesbares '''JSON-Format''' überführt, das teilweise automatisierte Compliance-Prüfungen und Integrationen in bestehende IT-Systeme ermöglicht. Dies ersetzt die bisherigen textbasierten PDFs und Listen.
*'''Prozessorientierte Struktur''': Die neue Version ist modular und objektorientiert aufgebaut, um Redundanzen zu reduzieren und die Dokumentationslast zu verringern.
*'''Leistungskennzahlen''': Kennzahlen sollen die Informationssicherheit messbar und den Sicherheitsgewinn einzelner Anforderungen transparenter machen.
* '''Harmonisierung mit ISO 27001''': Die Anforderungen werden stärker mit internationalen Standards wie '''ISO 27001:2022''' abgestimmt, um Doppelzertifizierungen zu vereinfachen.
*'''Erweiterung um moderne Technologien''': Geplant sind auch spezifische Module für '''Cloud-Security, KI und IoT''', die aktuelle Bedrohungsszenarien abdecken.
===Ziele der Reform===
*'''Schlankere Prozesse''': Durch Automatisierung soll der administrative Aufwand sinken.
*'''Dynamische Anpassung''': JSON ermöglicht schnellere, ggf. automatisierte Updates bei neuen Cyberbedrohungen.
*'''Praxisorientierte Vereinfachung''': Der BSI will die Dokumentationslast reduzieren und den Fokus auf risikobasierte Ansätze legen, insbesondere für KMU.
*'''Priorisierung und Messbarkeit''': Durch eine stufenweise Priorisierung von Anforderungen und Leistungskennzahlen soll ein zielgerichteteres Vorgehen und die bessere Messbarkeit der Sicherheit gefördert werden.
Die Änderungen reagieren auf Kritik an der bisherigen Komplexität und sollen besonders KMU entlasten, während die ganzheitliche Sicherheitsmethodik (technisch, organisatorisch, personell) erhalten bleibt.

''Hinweis'': Details zur finalen Struktur werden schrittweise im Jahr 2026 veröffentlicht. Unternehmen sollten sich frühzeitig mit den geplanten Schnittstellen (z.B. für Security-Tools) vertraut machen.

Offizieller '''Starttermin''' für den Grundschutz++ war der '''1.1.2026'''. Danach ist allerdings eine längere Übergangsphase (bis 2029) geplant, in der beide Standards parallel genutzt werden können, so wie bei der letzten Modernisierung auch. Da jedoch zu erwarten ist, dass eine automatisierte Migration auch diesmal nicht oder nur eingeschränkt möglich sein wird, sollte speziell in größeren Verbünden rechtzeitig begonnen werden! Der jeweils aktuellen Grundschutz++ Katalog wird auf [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek GitHub] veröffentlicht.
=== Bedeutung von OSCAL im Grundschutz++ ===
Das zugrundeliegende Format für Grundschutz++ ist [[OSCAL]].

[[OSCAL]] ist ein '''Framework''' bzw. eine '''Datenmodellierungssprache''', die vom NIST speziell für Sicherheitsanforderungen und Compliance-Dokumentation entwickelt wurde. OSCAL definiert dabei nur ein festes Schema für Sicherheits- und Compliance-Daten und lässt das zugrundeliegende Datenformat (JSON, XML oder YAML) offen.

Das BSI hat sich beim Grundschutz++ für das Datenformat '''JSON''' entschieden.

Dies ermöglicht es mit entsprechenden Tools Sicherheitsanforderungen automatisiert einzulesen und zu bearbeiten. D.h.

* Anforderungen können (teil-)automatisiert von entsprechenden Tools bearbeitet und dokumentiert werden, sofern entsprechende Tools zur Verfügung stehen oder vom Anwender (ggf. Dienstleister) programmiert werden.
* Kataloge und Sicherheitskonzepte (SSPs) können zwischen ISMS-Tools herstellerunabhängig ausgetauscht werden (sofern Toolhersteller sich an den Standard halten und entsprechende Im- und Exportfonktionen in ihren Tools zur Verfügung stellen).

Das heißt aber nicht:

* Das Anwender, Sicherheitsmanager oder Sicherheitsbeauftragte OSCAL lernen müssen oder OSCAL Formate lesen können müssen. (Dafür gibt es Tools, die die Inhalte lesbar und bearbeitbar zur Verfügung stellen)
* Das alle Anforderungen automatisiert erfüllt und dokumentiert werden (viele Anforderungen sind nach wie vor organisatorische Anforderungen die nur von Menschen durch Erstellung und Beachtung entsprechenden Regelungen erfüllt werden können).
* Das überhaupt irgendwelche Anforderungen automatisiert erfüllt und dokumentiert werden (Hierzu müssten die Systeme an ein ISMS-Tool angebunden sein und diese über entsprechende Schnittstellen mit Informationen bedienen). Sowohl die Tools als auch die Schnittstellen werden absehbar nicht vom Himmel fallen.
===Satzschablonen===
Anforderungen werden im Grundschutz++ zukünftig mit Satzschablonen erstellt, die wie folgt aussehen:<blockquote><big>'''<span style="color:green">{Praktik} [für {Zielobjektkategorie}]</span> <span style="color:red">{MODALVERB}</span> <span style="color:blue"><Ergebnis></span> <span style="color:purple">{Handlungswort}</span>''' ''<span style="color:grey">(TAGs) (Hinweise)</span>''</big></blockquote>'''Praktik''': Ein Prozess im Rahmen des ISMS, eine konkrete Sicherheitsmaßnahme oder eine allgemeine Vorgehensweise zur Erreichung eines Sicherheitsziels (z.B. IT-Betrieb, Personal, Konfiguration) - Im weitesten Sinne vergleichbar mit den bisherigen Bausteinen. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/practices.csv Liste der gültigen Praktiken.]

'''Zielobjektkategorie''': Wie bisher, das Objekt oder die Entität, auf die sich die Sicherheitsanforderungen beziehen (z.B. Daten, Personen, Endgeräte, Hostsysteme). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/target_object_categories.csv Liste der Gültigen Zielobjektkategorien.]

'''Modalverb''': Gibt die Verbindlichkeit einer Anforderung an (MUSS, SOLLTE, KANN). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/modal_verbs.csv Liste der gültigen Modalverben.]

'''Ereignis''': Der sicherheitsrelevante Zustand oder Auslöser, der zu einer bestimmten Handlung führt - Entspricht in Verbindung mit dem Handlungswort dem wesentliche Inhalt der Anforderung.

'''Handlungswort''': Das Verb, das die konkrete Sicherheitsmaßnahme oder Art der Tätigkeit beschreibt (regeln, zuweisen, konfigurieren). Handlungsworte können auch zur besseren Filterung genutzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/action_words.csv Liste der gültigen Handlungsworte.]

Das ganze kann noch mit '''TAG'''s für eine bessere Gruppierung und mit einem '''Hinweis''' zu weiterführenden Informationen ergänzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/tags.csv Liste der gültigen TAGs.]

Die bisherigen Anforderungen des Kompendium werden aktuell in ihre Teilanforderungen zerlegt und jede Teilanforderung wird zukünftig eine eigene Anforderung. D.h. jedes Modalverb (SOLL, MUSS, KANN) der bisherigen Anforderungen stellt zukünftig i.d.R. eine eigene Anforderung dar. Die Gesamtanzahl der Anforderungen soll dabei durch die Vermeidung von Redundanzen dennoch sinken.

'''Beispiel'''

Die Anforderung:<blockquote>'''ISMS.1.A4 Benennung eines oder einer Informationssicherheitsbeauftragten (B) [Institutionsleitung]'''

Die Institutionsleitung MUSS einen oder eine ISB benennen. '''. . .'''

Die Institutionsleitung MUSS den oder die ISB mit angemessenen Ressourcen ausstatten.

Die Institutionsleitung MUSS dem oder der ISB die Möglichkeit einräumen, bei Bedarf direkt an sie selbst zu berichten. '''. . .'''</blockquote>Wird jetzt zu den Anforderungen:<blockquote>'''GOV.4.2''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">einer Person die Rolle ISB</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.2.3''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">für das ISMS erforderliche personelle, finanzielle und zeitliche Ressourcen</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.4.4''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">dem ISB das direkte und jederzeitige Vorspracherecht bei der Institutionsleitung</span> '''<span style="color:purple">ermöglichen</span>.'''</blockquote>Da dies übergreifende Anforderungen sind, ist hier kein spezifisches Zielobjekt benannt.

Einzelne Teilanforderungen können auch in anderen Praktiken beschrieben sein.
===Priorisierung===
Alle Anforderungen werden einer Prioritätsstufe zugeordnet, um die Umsetzung effizient zu gestalten:
*'''Stufe 0''': Zwingend (sofort) umzusetzende Anforderungen zur Sicherstellung der ISO-Kompatibilität (MUSS-Anforderungen).
Die Stufen 1-4 geben den Umsetzungsaufwand der Anforderungen wieder:
*'''Stufe 1''': Schnell und mit geringem Aufwand (~1 Tag) realisierbare Maßnahmen (QuickWin) / keine laufenden Aufwände.
*'''Stufe 2''': Mit eigenen Mitteln leicht umsetzbare Anforderung (~1 Woche) / geringe laufende Aufwände.
*'''Stufe 3''': Mit normalem Aufwand (mehrere Wochen) und ggf. externer Unterstützung umsetzbar / normale laufende Aufwände.
*'''Stufe 4''': Höherer Umsetzungsaufwand, häufig in längerfristigen Projekten mit externen Experten.
Die nächste Stufe sind optionale Anforderungen als Vorschläge bei erhöhtem Schutzbedarf.
*'''Stufe 5''': Umfassende/zusätzliche Anforderungen für höheren Schutzbedarf.
Diese Einstufung ermöglicht eine schnelle Einschätzung des Umsetzungsaufwands und hilft bei der effizienten Ressourcenplanung.
===Leistungskennzahlen===
Leistungskennzahlen dienen der '''Messung und Bewertung''' der Umsetzung von Sicherheitsanforderungen im Grundschutz++. Sie ermöglichen eine objektive Einschätzung des Sicherheitsniveaus und unterstützen die kontinuierliche Verbesserung. Wie diese Leistungskennzahlen genutzt werden sollen ist nach wie vor unklar und viele Anforderungen sind bislang noch nicht bewertet.
====Bewertungskriterien====
Jede Anforderung wird in Bezug auf die drei Schutzziele bewertet:
*'''Vertraulichkeit (C)'''
*'''Integrität (I)'''
*'''Verfügbarkeit (A)'''
Anforderungen erhalten Punktwerte in diesen Kategorien, die zur Bestimmung des Schutzgrades genutzt werden (z.B. C=6, I=2, A=0 ist eine Anforderung die im Wesentlichen die Vetraulichkeit stärkt, in Teilen die Intgrität aber nicht die Verfügbarkeit).

Die einzelen Kennzahlen werden je Schutzziel, Praktik und/oder Zielobjekt aufsummiert und ergeben so den Erfüllungsgrad.
====Schwellwerte und Erfüllungsgrad====
*'''Schwellwerte''' definieren das angestrebte Sicherheitsniveau basierend auf der Summe der Punktwerte aller umgesetzten Anforderungen je Schutzziel, Zielobjekt und Schutzstufe.
*'''Der Erfüllungsgrad''' zeigt, welche Anforderungen bereits umgesetzt wurden.
Die Leistungskennzahlen bieten damit eine fundierte Entscheidungsgrundlage für Organisationen, um ihren Sicherheitsstatus gezielt zu verbessern, wenn sie wie ursprünglich geplant eingeführt werden.
==Was bleibt erhalten?==
===Standards und Vorgehen===
Trotz eines deutlich anderen Formats und einer anderen Gruppierung der Anforderungen bleibt das grundsätzliche Vorgehen weitgehend gleich.

D.h. die Standards 200-1 bis 200-4 sollen erst einmal weiter Verwendung finden. Die bisher üblichen Arbeitsschritte:
#Festlegung des Geltungsbereichs
#Strukturanalyse
#Schutzbedarfsfeststellung
#Modellierung
#IT-Grundschutzcheck (GSC)
#Risikoanalyse
bleiben grundsätzlich erhalten, ändern sich jedoch in der praktischen Anwendung und Priorität (insbesondere in der '''Modellierung''' und den '''Grundschutzchecks'''). Parallel zur Einführung sollen die Standards weiter entwickelt werden.

'''MUSS'''-Anforderungen sind weiterhin '''verpflichtend''' für eine Zertifizierung, sollen aber deutlich rediziert werden.

'''SOLLTE'''-Anforderungen bleiben auch weiter '''grundsätzlich verpflichtend''', können aber ggf. mit angemessener Begründung oder Ersatzmaßnahmen wegdiskutiert werden.

Lediglich '''KANN'''-Anforderungen sind optional.
===Tool-Einsatz===
Auch der Einsatz von ISMS-Tools wird weiterhin Bestand haben. Alle größeren Tool-Hersteller arbeiten mit Hochdruck an der Integration von Grundschutz++ in ihre Tools. Hier wird es perspektivisch Erleichterungen durch einen leichteren Datenaustausch zwischen den Tools und mehr Automatisierungspotential geben.
==Gegenüberstellung Grundschutz Kompendium vs. Grundschutz++==
Das IT-Grundschutz-Kompendium 2023 und der zukünftige Grundschutz++ bieten unterschiedliche Konzepte für die Umsetzung von Informationssicherheit: Während das Kompendium auf feste Bausteine in thematisch gegliederten Schichten setzt, verwendet Grundschutz++ modulare, flexibel einsetzbare Praktiken.

Die folgende Tabelle stellt die wesentlichen Unterschiede und Gemeinsamkeiten zwischen beiden Ansätzen (nach aktuell verfügbaren Kenntnissen) gegenüber:
{| class="wikitable"
|+
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Fester verbindlicher Katalog''' von Anforderungen (PDF, Excel und XML), die je nach Reifegrad erfüllt werden müssen.
|Der '''variable''' und erweiterbare '''[[OSCAL]]'''-Datenbestand kann beliebig an die Bedürfnisse der Organisation angepasst werden. Zusätzliche Kataloge/Erweiterungen (C5, Datenschutz, KRITIS/NIS2) können je nach Verfügbarkeit ergänzt werden. Durch die Beseitigung vermeintlicher Redundanzen soll die Anzahl der Anforderungen erheblich reduziert werden (~10–20 % verbleibende Anforderungen gegenüber dem Grundschutz Kompendium).
|-
|
|Järliche '''Aktualisierung''' zum Stichtag '''1. Februar'''.
(bis 2023)
|Die '''Aktualisierung''' erfolgt '''fortlaufend''' nach Bedarf und Verfügbarkeit. Die Regelungen zur Relevanz für Zertifizierungen sind bislang noch nicht bekannt.
|-
|
|Das Kompendium ist (Stand 2023) in 10 '''Schichten''' mit insgesamt 111 '''Bausteine''' gegliedert, die statisch die jeweiligen Anforderungen enthalten.
|'''Praktiken''' und '''''Zielobjektkategorien''''' (Achtung abweichende Bedeutung in GS++) sind allgemeinere und wiederverwendbare, sicherheitsrelevante Verfahren oder Anforderungen. Sie können modular und situationsabhängig einzelnen Assets zugeordnet werden.
Die voraussichtlich ca. 20 Praktiken liegen irgendwo zwischen Schichten und Bausteinen. Sie sind prozessorientierter, adressieren eher Zielgruppen oder Handlungstypen und sind nicht mehr starr bestimmten Zielobjektkategorien zugeordnet. Zielobjektkategorien entsprechen zukünftig eher den Bausteinen im alten Grundschutz. Die Definitionen der Begriffe sind nach wie vor im Fluß!
|-
|
|'''Drei Stufen''' (Vorgehensweisen): Basis, Standard, erhöhter Schutzbedarf bilden den Reifegrad der Organisation ab.
|Es sind zukünftig '''sechs Stufen''' (0–5) geplant, die sich weitgehend am Umsetzungsaufwand der jeweiligen Anforderung orientieren: Je kleiner die Stufe, desto schneller bzw. leichter ist die Anforderung umsetzbar (Quick Win). Eine qualitative Bewertung des Reifegrads muss zukünftig anders erfolgen (z. B. über Leistungskennzahlen).
Das '''Sicherheitsniveau''' gibt zukünftig an, in welchem Maß die definierten Sicherheitsziele erreicht sind. Es ergibt sich aus der wirksamen Umsetzung organisatorischer, technischer und personeller Anforderungen.

Unterschieden werden:
*'''Normales Sicherheitsniveau''': entspricht dem Stand der Technik
*'''Erhöhtes Sicherheitsniveau''': für besonders schutzbedürftige Informationen oder Systeme
|-
|
|'''Zielobjekte''' als gruppierte Sammlung von gleichartigen Assets die zur späteren '''Modellierung''' (Zuordnung der Bausteine und Abhängigkeiten) genutzt werden.
|'''Zielobjekte''' werden auch in Zukunft eine ähnliche Funktion zur Gruppierung und '''Modellierung''' haben, entsprechend dabei aber eher den klassischen Bausteinen. Die konkreten Vorgaben zur Modellierung sind jedoch noch nicht detailliert genug. In der Modellierung werden die Praktiken nicht mehr statisch bestimmten Zielobjekttypen zugewiesen. Klassische Zielobjekte werden zukünftig als Assets oder Assetgruppen bezeichnet.
|-
|
|Modalverben '''MUSS''', '''SOLLTE''', '''KANN''' bestimmen die Verbindlichkeit von Anforderungen.
|Die Bedeutung der Modalverben ('''MUSS, SOLLTE, KANN''') bleibt unverändert. Ein Ziel von Grundschutz++ ist es jedoch, die Anzahl der Muss-Anforderungen auf das Nötigste zu reduzieren (unter 10 %). Dadurch soll der Grundschutz flexibler werden. Die Verbindlichkeit von Anforderungen, die über MUSS-Anforderungen hinausgehen, ist noch unklar.
|-
|
| -
|Neu sind '''Leistungskennzahlen''', die eine qualitative Bewertung der Anforderungen in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit darstellen. Sie sollen als Zahlenwert darstellbar sein und so den Reifegrad abbilden können. Bisher ist noch nicht bekannt, ob und wann diese eingeführt werden und wie die konkreten Regelungen aussehen werden.
|-
|
|Gültigkeit voraussichtlich bis 2029
|Gültig ab 1.1.2026. Zertifizierbar geplant ab 2027.
|}Teilweise werden Begrifflichkeiten neu (oder anders) definiert:
{| class="wikitable"
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Zielobjekt''' als gruppierte Sammlung von gleichartigen Assets als Grundlage für die spätere Modellierung
|'''Asset''' und gruppierte Assets. Die Gruppierung gleichartiger Assets kann weiterhin erfolgen es bleiben jedoch auch dann '''Assets'''. Der Begriff ''Zielobjekt'' wird hierfür nicht mehr genutzt.
|-
|
|'''Baustein''' als Sammlung von Anforderungen für bestimmte Zielobjekttypen.
|'''Zielobjektkategorien''' sind zukünftig das was bislang die ''Bausteine'' waren, bestimmte Typen von Assets für die spezische Anforderungen gelten. Die Assets werden den Zielobjektkategorien zugewisen und erhalten über diese ihre Anforderungen. Eine klare Definition der Begriffe ist noch im Fluß.
|-
|
|
|
|}
==Blaupausen==
Blaupausen sind vorgefertigte Musterlösungen (wie die bisherigen IT-Grundschutz-Profile), die als Vorlage (Referenzmodell) für die Erstellung und Umsetzung von branchenspezifischen oder organisationsspezifischen Sicherheitskonzepten dienen.
===Funktion der Blaupausen===
Solche Blaupausen erfassen typische Strukturen, Risiken, Anforderungen und Maßnahmen für bestimmte Anwendungsszenarien, etwa die Nutzung der E-Akte oder den sicheren Betrieb von 5G-Infrastrukturen. Sie ermöglichen es, ein ISMS deutlich effizienter und strukturierter aufzubauen, weil die grundlegenden Überlegungen (Schutzbedarfsermittlung, Zuordnung von Praktiken, Zielobjekten und Maßnahmen, etc.) bereits allgemein gültig vorformuliert sind und nur noch organisationsspezifisch angepasst werden müssen.
===Ziel und Nutzen===
*Blaupausen helfen, den Implementierungsaufwand für ISMS nach Grundschutz++ zu reduzieren.
*Sie fördern die Standardisierung und Wiederverwendbarkeit von Sicherheitskonzepten für ähnliche Organisationen oder Branchen.
*Besonders für kleinere Organisationen und typische Anwendungsfälle bieten sie einen niederschwelligen, strukturierten und praxiserprobten Einstieg in die Absicherung.
Damit sind Blaupausen im Grundschutz++ zentrale Instrumente, um bewährte Sicherheitsmethoden als Vorlage für den schnellen und einheitlichen Aufbau eines branchenspezifischen ISMS bereitzustellen.
===Umsetzung===
Umgesetzt werden Blaupausen technische als '''OSCAL-Profile''' mit zusätzlichen Erläuterungen in Textform, zukünftig sollen Blaupausen zu einem '''System Security Plan (SSP)''' weiter entwickelt werden.
== Grundlagen und Standards ==

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_1.html BSI-Standard 200-1: Anforderungen an ein ISMS].
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_2.html BSI-Standard 200-2: IT-Grundschutz Methodik] ( <- Wird neu erstellt )
** [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html Methodik zum Grundschutz++] (Aktuell in Erstellung, ersetzt zukünftig 200-2)
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_3.html BSI-Standard 200-3: Risikomanagement mit Grundschutz].
* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/BSI-Standards/BSI-Standard-200-4-Business-Continuity-Management/bsi-standard-200-4_Business_Continuity_Management_node.html BSI-Standard 200-4: Business Continuity Management].
* [[OSCAL|OSCAL (Open Security Controls Assessment Language)]].

== Schritt-für-Schritt-Methodik ==
Die Methodik zum Grundschutz++ folgt einem '''5-stufigem PDCA-basierten Prozess''' mit Fokus auf '''Anforderungsmodellierung''' und '''maschinenlesbarer Verarbeitung'''. Hier das praktische Vorgehen:

=== Schritt 1: Erhebung und Planung (PLAN - Governance/Compliance) ===
# '''Kontextanalyse''' (intern/extern) durchführen
# '''Interessierte Parteien''' identifizieren und Anforderungen erfassen
# '''Geltungsbereich''' (Scope) durch Institutionsleitung festlegen und freigeben
# '''Geschäftsprozesse''' priorisieren → Schutzbedarf "normal" oder "hoch" einstufen
# '''Sicherheitsleitlinie''' erstellen (Ziele, Strategie, Verpflichtung Leitung)
# '''Sicherheitsorganisation''' etablieren (Rollen: ISB, Asset-Owner, etc.)
# '''Compliance-Management''' initialisieren (Rechts-/Vertragskatalog)

'''Ergebnis''': Organisatorischer Rahmen, Sicherheitsleitlinie, priorisierte Prozesse

'''Weiterführende Informationen:'''

* [[Informationssicherheitsleitlinie]]
* [[IS-Strategie]]
* [[Geschäftsprozesse]]

=== Schritt 2: Anforderungsanalyse (PLAN - Strukturmodellierung) ===
# '''Informationsverbund''' definieren (techn./org. Abgrenzung)
# '''Assets''' für wichtigsten Geschäftsprozess erfassen
# '''Asset → Zielobjektkategorien''' mapping (Hierarchie + Vererbung)
# '''Anforderungspaket''' generieren:
#* ISMS-Praktiken (vollständig)
#* Zielobjekt-Anforderungen (Sicherheitsniveau: normal/erhöht)
#* Zielobjektlose Anforderungen prüfen
# '''Ergänzungen''': Externe Verpflichtungen, anforderungslose Assets
# '''Risikobetrachtung''' bei hohem Schutzbedarf oder Niveauerhöhung
# '''Parameter setzen''' (Zuständigkeiten, Werte)

'''Ergebnis''': Individuelles Anforderungspaket pro Informationsverbund

'''Weiterführende Informationen:'''

* [[Strukturanalyse]]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das OSCAL-basierte Grundschutz++ Kompendium auf Github.]

=== Schritt 3: Realisierung (DO - Umsetzung) ===
# '''Umsetzungsstatus''' aller Anforderungen prüfen (ja/nein)
# '''Nicht-umgesetzte MUSS/SOLLTE''' → Risikobetrachtung
# '''Umsetzungsplan''' erstellen:
#* Priorisierung (Risiko, Aufwand, Synergien)
#* Zuständigkeiten + Fristen zuweisen
# '''Freigabe''' durch Institutionsleitung
# '''Fortschritt tracken''' (Ticketsystem/Projektmanagement)
# '''Ausnahmen dokumentieren''' (Begründung + Leitungsfreigabe)

'''Ergebnis''': Umsetzungsplan + Status-Dokumentation

'''Weiterführende Informationen:'''

* [[LF-Grundschutzcheck|Leitfaden Grundschutzcheck]]
* [[RiLi-Freigabe]]
* [[RiLi-Ausnahmemanagement|Richtlinie zum Management von Ausnahmen und Abweichungen]]

=== Schritt 4: Überwachung (CHECK - Monitoring/Evaluation) ===
# '''Leistungsbewertung''' (KPIs, Umsetzungsfortschritt, Vorfälle)
# '''Compliance-Überwachung''' (gesetzlich/vertraglich)
# '''Auditprogramm''' risikobasiert durchführen
# '''Managementbewertung''' → Managementbericht erstellen
# '''Monitoring-Tools''' einsetzen (SIEM, Vulnerability Scanner)
# '''Anforderungspaket validieren''' (Aktualität prüfen)

'''Ergebnis''': Auditberichte, Managementbericht

'''Weiterführende Informationen:'''

* [[Reifegradmodell]]
* [[KPIs|Key Performance Indicators (KPIs)]]
* [[Managementbericht|Erstellen eines Managementberichts]]

=== Schritt 5: Kontinuierliche Verbesserung (ACT - Verbesserung) ===
# '''Nicht-Konformitäten''' analysieren
# '''Verbesserungspotenziale''' identifizieren
# '''Korrektur-/Verbesserungsplan''' → in Umsetzungsplan integrieren
# '''Wirksamkeit prüfen''' nach Umsetzung
# '''Sicherheitsniveau''' bewerten (Trendanalyse)
# '''Compliance-Verstöße''' behandeln

'''Ergebnis''': Aktualisiertes Anforderungspaket → neuer PDCA-Zyklus

'''Weiterführende Informationen:'''

*

=== Praktische Hinweise ===
* '''Tool-gestützt''': JSON/OSCAL-Bausteine, Zur Nutzung sind ISMS-Tools empfohlen.
* '''Iteration''': Wichtigster Geschäftsprozess zuerst, dann schrittweise erweitern
* '''Risikobetrachtung''': Bei Sicherheitsniveau "hoch" oder Nicht-Umsetzung
* '''Dokumentation''': bevorzugt Maschinenlesbar (OSCAL) für besseren Austausch

'''Zyklusdauer''': Jährlich oder ereignisgesteuert (Änderungen, Vorfälle, Audits)

== Migration bestehender Sicherheitskonzepte ==
...

'''Weiterführende Informationen:'''

[[Grundschutz++ Migration]]

== Offenen Punkte und Kritiken ==

=== Zu viele Beteiligte, unklare Zuständigkeiten ===
Die Weiterentwicklung des Grundschutzes wird inzwischen nicht mehr ausschließlich vom Grundschutz-Referat des BSI verantwortet. Mit dem Einstieg des Referats „Stand der Technik“ und der verstärkten Einbindung der „Community“ sind die Zuständigkeiten und Verantwortlichkeiten unklarer geworden. In Präsentationen und Veröffentlichungen werden die Rollen und Aufgaben der verschiedenen Beteiligten unterschiedlich dargestellt. Es fehlt eine klare, kommunizierte Schnittstelle, wer für welche Aspekte der Entwicklung, Pflege und Kommunikation des neuen Standards verantwortlich ist. Das erschwert für Anwendende die Orientierung und die Planung der eigenen Umsetzungsstrategie.

=== Unklare Umsetzung einiger Ziele ===
Einige der im Grundschutz++ adressierten Ziele und Neuerungen sind nach wie vor nicht ausreichend konkretisiert. Besonders die Einführung von Leistungskennzahlen und die Priorisierung der Anforderungen (Stufen) werfen noch viele Fragen auf. Die konkrete Bedeutung, Messung und praktische Umsetzung dieser Leistungskennzahlen werden von verschiedenen BSI-Vertretern unterschiedlich dargestellt. Auch die Stufenmodelle werden teils als Priorisierung, als Entwicklungsstufen oder als reiner Umsetzungaufwand der Anforderungen definiert und sind in ihrer praktischen Anwendung noch nicht abschließend geklärt. Das führt zu Unsicherheiten, wie diese neuen Instrumente im einem ISMS umgesetzt und nachgewiesen werden sollen.

=== Geringer Mehrwert im Vergleich zu ISO 27001 ===
Die Anforderungen im Grundschutz++ werden zunehmend an die Formulierungen und Strukturen der ISO 27001 angeglichen. Während der klassische IT-Grundschutz durch seine konkreten, praxisnahen Maßnahmen einen klaren Mehrwert gegenüber der eher abstrakten ISO 27001 bot, verliert er durch die Harmonisierung mit internationalen Standards zunehmend diesen Vorteil. Die Anforderungen werden stärker abstrakt modularisiert formuliert, wodurch der spezifische Bezug zu typischen Umsetzungsbeispielen und die Detailtiefe abnehmen. Für viele Organisationen wird sich daher die Frage stellen, warum sie den immer noch aufwändigeren Weg über den Grundschutz wählen sollten, wenn sie mit ähnlichem oder geringeren Aufwand direkt eine ISO 27001-Zertifizierung anstreben können.

=== Zu ambitionierter Zeitplan ===
Der Grundschutz++ sollte ab dem 1.1.2026 grundsätzlich gültig und anwedbar sein, wobei eine Übergangsphase bis 2029 vorgesehen war. Bisher ist nur ein erster Entwurf veröffentlicht. Angesichts der Vielzahl an noch offenen Fragen, der fehlenden Migrationsstrategie und der Komplexität der Änderungen erscheint der Zeitplan sehr ambitioniert. Ausarbeitung und Dokumentation liegen bisher nur als Entwurf vor. Eine Pilotierung und Einführung 2026 und eine Übergangsphase bis 2029 ist vorgesehen. Die Gefahr besteht, dass größere Organisationen unter Zeitdruck unzureichend vorbereitet in die neue Methodik wechseln und mit variablen Definitionen und Zielen arbeiten müssen, was die Akzeptanz und Qualität der Umsetzung gefährdet.

=== Zunehmende (Sicherheits-)Lücke zwischen Grundschutz und Grundschutz++ ===
Mit der Entscheidung des BSI, den bisherigen IT-Grundschutz (Edition 2023) nicht mehr weiterzuentwickeln und stattdessen auf das neue Grundschutz++-Modell zu setzen, entsteht eine wachsende Lücke in der Informationssicherheit. Diese Übergangsphase bis 2029 ist sicherheitstechnisch kritisch, da sich die Bedrohungslage in der IT nicht an Entwicklungszyklen von Sicherheitsstandards orientiert. Neue Angriffsvektoren, insbesondere durch den zunehmenden Einsatz von KI in der Cyberkriminalität (z.B. KI-gestützte Malware, Deepfakes, automatisierte Phishing-Kampagnen), entstehen kontinuierlich und erfordern zeitnahe, wirksame Gegenmaßnahmen. Der bisherige Grundschutz bildet diese aktuellen Bedrohungen und technologische Entwicklungen jedoch nicht mehr ab, während die spezifischen Module und Maßnahmen im Grundschutz++ noch nicht produktiv verfügbar oder praxistauglich sind.

=== Fehlende Migration vom Grundschutz-Kompendium zu Grundschutz++ ===
Aktuell existiert weder ein konkreter Plan noch ein Konzept für eine (teil-)automatisierte Migration bestehender Sicherheitskonzepte aus dem bisherigen Grundschutz-Kompendium in das neue Grundschutz++-Modell. Die Umstellung auf ein maschinenlesbares JSON/OSCAL-Format und die objektorientierte, prozessorientierte Struktur bedeuten einen fundamentalen Bruch mit bisherigen Strukturen. Die Unterschiede zwischen Grundschutz-Kompendium und Grundschutz++ sind gravierender als beim letzten Wechsel von den Grundschutz-Katalogen zum Kompendium, bei dem bereits alle Ansätze für eine automatisierte Migration weitgehend gescheitert sind. Auch diesmal ist absehbar, dass Organisationen ihre bestehenden Dokumentationen und Umsetzungen weitgehend manuell neu abbilden müssen, was insbesondere für größere Verbünde einen erheblichen Zusatzaufwand bedeutet. Es gibt zwar Ansätze dies mittels KI zu lösen, was aber sicher nicht für jede Organisation praktikabel sein wird.

== Fazit ==
Ein abschließendes Bild zum Grundschutz++ lässt sich aktuell noch nicht zeichnen – viele Details sind noch in der Entwicklung.

Die grundlegende Modernisierung des IT-Grundschutzes durch das Grundschutz++-Projekt ist zwar fachlich und technologisch nachvollziehbar und adressiert viele Schwächen des bisherigen Systems. Die Umsetzung ist jedoch nach jetzigem Entwicklungsstand mit erheblichen Risiken und Unsicherheiten verbunden. Ohne klare Migrationspfade, eindeutige Zuständigkeiten und praxistaugliche Konkretisierungen der neuen Instrumente besteht die Gefahr, dass die Akzeptanz des Grundschutzes sinkt und Organisationen sich vermehrt alternativen Standards wie der ISO 27001 zuwenden. Ein realistischer Zeitplan und ein echter Mehrwert des neuen Standards sind daher essenziell für den Erfolg der Reform.

Der Artikel wird fortlaufend aktualisiert, sobald neue Informationen vom BSI veröffentlicht oder freigegeben werden.
===Ausblick und ToDos aus Anwendersicht===
Stichtag für die Einführung von Grundschutz++ war der '''1.1.2026'''. Das Datum wurde vom BSI in offiziellen Ankündigungen, Präsentationen und Fachveranstaltungen als verbindlicher Startpunkt kommuniziert. Ab diesem Zeitpunkt sollte das neue, digitale und prozessorientierte Regelwerk den bisherigen IT-Grundschutz ablösen. Bisher fehlt es jedoch an vielen Stellen an klaren Definitionen und konkreten Vorgaben zur Methodik.

Auch wenn abzuwarten bleibt, wann praxistaugliche Methoden verfügbar sind und wie lange die Übergangsfristen für die Umstellung sein werden (aktuelle Planung bis 2029). Abzusehen ist jedoch, dass der Aufwand und der Zeitdruck, insbesondere für größere und zertifizierte Verbünde, erheblich sein werden. Auch wenn es aktuell noch keine konkreten Beschreibungen zur Methodik und Modellierung gibt, können und sollten sich Anwender bereits jetzt vorbereiten. Dazu können die folgenden Maßnahmen dienen:
*Laufende Information über den aktuellen Stand (Internetseiten des BSI, Vorträge und Veröffentlichungen).
*Konsolidierung der bestehenden Verbünde (Reduzierung der Komplexität, konsistente Dokumentation der Gruppierung und Modellierung).
**Ein guter Tip ist es, in aktuellen GSC jede Teilanforderung (jedes Modalverb wie MUSS oder SOLLTE) in der Umsetzung einzeln zu dokumentieren, da diese zukünftig eigenständige Anforderungen darstellen und so eine Übernahme leichter werden könnte.
*Kontakt zu Toolherstellern aufnehmen und eine zügige Umsetzung in den verwendeten ISMS-Tools einfordern.
*Frühzeitige Planung der Bereitstellung entsprechender personeller Ressourcen für die Umstellung auf Grundschutz++ ab Mitte 2026.
*Gegebenenfalls frühzeitige Reservierung externer (personeller) Ressourcen zur Unterstützung.
*Es muss eine klare interne Kommunikation über die bevorstehenden, durch die Umstellung bedingten erhöhten Aufwände (Schulungen, neue (Erst-)GSCs und Anpassung der Dokumentation) geben, damit Mitarbeitende und Verantwortliche wissen, was auf sie zukommt.

== Weiterführende Ressourcen ==
*[https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html BSI IT-Grundschutz]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html BSI Leitfaden zur Grundschutz++-Methodik (1.4.2026)]
*[https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/Grundschutz/1GS_Tag_2025/Aktuelle_Entwicklungen_Ausblick_IT-GS.pdf Aktuelle Entwicklungen und Ausblick zum IT-Grundschutz - 1. Grundschutztag 2025]
*[https://www.youtube.com/watch?v=_AeWJ_Z8S-4 Keynote: Fortentwicklung des IT-Grundschutzes zu IT-Grundschutz++ (verinice.XP 2025)]
*[https://www.youtube.com/watch?v=fBXuhELODGA Vortrag: "Keynote und Vision Grundschutz++" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.youtube.com/watch?v=PxOjkV6oUwU Vortrag "Grundschutz++ Methodik und Einstieg ins BCM" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.bsi.bund.de/dok/it-sa Am Mittwoch, 08.10.2025 werden auf der it-sa die von den Arbeitsgruppen aus der Community erarbeiteten Ergebnisse präsentiert.]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]
*[[Grundschutz++ Migration|Migrationsstrategie für den Umstieg von BSI IT-Grundschutz auf Grundschutz++]]

[[Kategorie:Artikel]]
[[Kategorie:Grundschutz]]
[[Kategorie:++]]

Grundschutz++

2026-04-04T03:07:50Z

Dirk: /* Weiterführende Informationen */

[[Datei:Teamwork-2198961.png|alternativtext=Zahnrad|rechts|240x240px]]{{#seo:
|title=Grundschutz++ Digitale Reform & OSCAL-basierte Sicherheit
|keywords=ISMS, IT-Grundschutz++, BSI Reform 2026, JSON-basierte Cybersicherheit, ISO 27001 Harmonisierung, Cloud-Security Module, NIS-2 Richtlinie, ISMS Automatisierung
|description=Das BSI modernisierte den IT-Grundschutz 2026 mit OSCAL/JSON-Regelwerk und Automatisierung.
}}{{SHORTDESC:Grundschutz++: Digitale Reform & OSCAL-basierte Sicherheit}}
''Grundschutz++ ist die 2026 vom BSI eingeführte Weiterentwicklung des IT-Grundschutz-Kompendiums.''<blockquote>
=== Diese Seite ist umgezogen! ===
Da die Planungs- und Entwicklingsphase offiziell beendet ist und Grundschutz++ laut BSI nun gültig ist (auch wenn es praktisch noch nicht anwendbar ist) wurde diese Seite durch eine [[Grundschutz++ Einführung und Aufbau|'''Einführungs- und Anleitungsseite''']] ersetzt.

Die wesentlichen Inhalte dieser Seite wurde dort übernommen und ergänzt.

Diese Seite wird zukünftig nur noch eine Kurzbeschreibung zum Grundschutz++ enthalten.</blockquote>

=== Grund für Weiterentwicklung ===
Kritik an Komplexität, Redundanzen und fehlender Aktualität des alten Kompendiums; Ziel: Digitalisierung, Automatisierung und Anpassung an moderne Bedrohungen (Cloud, KI, IoT) sowie bessere ISO 27001-Harmonisierung.

=== Kernmerkmale ===

* '''OSCAL/JSON-Format''': Maschinenlesbares Regelwerk für automatisierte Prüfungen.
* '''Modulare Praktiken''': Prozessorientierte Struktur statt starrer Bausteine, Reduktion der Anforderungen um 80%.
* '''Priorisierungsstufen''' (0–5): Nach Umsetzungsaufwand (Quick Wins bis komplexe Projekte).
* '''Leistungskennzahlen''': Messbarkeit nach Schutzziele (C/I/A).
* '''Blaupausen''': Vorlagen für branchenspezifische ISMS.
* '''Übergangsphase''': Bis 2029 parallel zum alten Kompendium nutzbar.

=== Kritik am Grundschutz++ ===

* '''Zu viele Beteiligte''': Unklare Zuständigkeiten zwischen BSI-Referaten und Community.
* '''Unklare Ziele''': Leistungskennzahlen und Stufenmodelle nicht konkretisiert.
* '''Wenig Mehrwert vs. ISO 27001''': Verliert Praxisnähe durch Abstraktion.
* '''Ambitionierter Zeitplan''': Entwurfsphase verzögert, seit 2026 gültig aber nicht anwendbar. Übergang bis 2029 riskant.
* '''Sicherheitslücke''': Alter Grundschutz wird nicht weiterentwickelt bleibt aber bis 2029 anwendbar.
* '''Keine Migrationsstrategie''': Manuelle Neuausarbeitung erforderlich.

=== Weiterführende Informationen ===
* [[Grundschutz++ Einführung und Aufbau|'''Grundschutz++ Einführung und Vorgehen''']]
* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html '''BSI IT-Grundschutz''']
* '''[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html BSI Leitfaden zur Grundschutz++-Methodik (1.4.2026)]'''
* [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]
* [https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/Grundschutz/1GS_Tag_2025/Aktuelle_Entwicklungen_Ausblick_IT-GS.pdf Aktuelle Entwicklungen und Ausblick zum IT-Grundschutz - 1. Grundschutztag 2025]
* [https://www.youtube.com/watch?v=_AeWJ_Z8S-4 Keynote: Fortentwicklung des IT-Grundschutzes zu IT-Grundschutz++ (verinice.XP 2025)]
* [https://www.youtube.com/watch?v=fBXuhELODGA Vortrag: "Keynote und Vision Grundschutz++" vom 2. IT-Grundschutztag am 7.7.2025]
* [https://www.youtube.com/watch?v=PxOjkV6oUwU Vortrag "Grundschutz++ Methodik und Einstieg ins BCM" vom 2. IT-Grundschutztag am 7.7.2025]
* [[Grundschutz++ Migration|Migrationsstrategie für den Umstieg von BSI IT-Grundschutz auf Grundschutz++]]

[[Kategorie:Kurzartikel]]
[[Kategorie:Grundschutz]]
[[Kategorie:++]]
__KEIN_INHALTSVERZEICHNIS__

Grundschutz++ Einführung und Aufbau

2026-04-04T03:06:46Z

Dirk: /* Weiterführende Ressourcen */

[[Datei:Teamwork-2198961.png|alternativtext=Zahnrad|rechts|240x240px]]{{#seo:
|title=Grundschutz++ Einführung und Anleitung
|keywords=ISMS, Wiki, BSI Grundschutz++, IT-Grundschutz, BSI-Standard 200-2, Bausteine, OSCAL, JSON, Informationssicherheit, Risikomanagement, Anforderungen
|description=Überblick über den neuen BSI Grundschutz++. Startseite zur Navigation durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.
}}{{SHORTDESC:Grundschutz++ Überblick und Anleitung}}''Dieser Artikel bietet einen schrittweisen Überblick über BSI '''Grundschutz++''' und navigiert durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.''

== Einführung in Grundschutz++ ==
'''Grundschutz++''' ist die 2026 vom BSI eingeführte Weiterentwicklung des IT-Grundschutz-Kompendiums. Es transformiert das bewährte Grundschutz-Konzept in ein vollständig digitales, maschinenlesbares Format mit JSON-basierten Bausteinen und OSCAL-kompatibler Struktur.<blockquote>
''Der aktuelle Stand von Grundschutz++ ist bisher nur sehr eingeschränkt praktisch anwendbar, da einige wesentliche Definitionen und Teile der Methodik noch fehlen. Dazu gehören beispielsweise die Nutzung von Kennzahlen, Blaupausen, Stufen, Schutzbedarf vs. Schutzniveau und die Modellierung.''

''Der Anforderungskatalog liegt zwar im OSCAL- und Excel-Format vor, ist ohne eine abgeschlossene und nachvollziehbare Methodik aber nicht sinnvoll anwendbar.''
</blockquote>
=== Wesentliche Neuerungen===
*'''OSCAL/JSON-basiertes Regelwerk''': Der IT-Grundschutz wird in ein maschinenlesbares '''JSON-Format''' überführt, das teilweise automatisierte Compliance-Prüfungen und Integrationen in bestehende IT-Systeme ermöglicht. Dies ersetzt die bisherigen textbasierten PDFs und Listen.
*'''Prozessorientierte Struktur''': Die neue Version ist modular und objektorientiert aufgebaut, um Redundanzen zu reduzieren und die Dokumentationslast zu verringern.
*'''Leistungskennzahlen''': Kennzahlen sollen die Informationssicherheit messbar und den Sicherheitsgewinn einzelner Anforderungen transparenter machen.
* '''Harmonisierung mit ISO 27001''': Die Anforderungen werden stärker mit internationalen Standards wie '''ISO 27001:2022''' abgestimmt, um Doppelzertifizierungen zu vereinfachen.
*'''Erweiterung um moderne Technologien''': Geplant sind auch spezifische Module für '''Cloud-Security, KI und IoT''', die aktuelle Bedrohungsszenarien abdecken.
===Ziele der Reform===
*'''Schlankere Prozesse''': Durch Automatisierung soll der administrative Aufwand sinken.
*'''Dynamische Anpassung''': JSON ermöglicht schnellere, ggf. automatisierte Updates bei neuen Cyberbedrohungen.
*'''Praxisorientierte Vereinfachung''': Der BSI will die Dokumentationslast reduzieren und den Fokus auf risikobasierte Ansätze legen, insbesondere für KMU.
*'''Priorisierung und Messbarkeit''': Durch eine stufenweise Priorisierung von Anforderungen und Leistungskennzahlen soll ein zielgerichteteres Vorgehen und die bessere Messbarkeit der Sicherheit gefördert werden.
Die Änderungen reagieren auf Kritik an der bisherigen Komplexität und sollen besonders KMU entlasten, während die ganzheitliche Sicherheitsmethodik (technisch, organisatorisch, personell) erhalten bleibt.

''Hinweis'': Details zur finalen Struktur werden schrittweise im Jahr 2026 veröffentlicht. Unternehmen sollten sich frühzeitig mit den geplanten Schnittstellen (z.B. für Security-Tools) vertraut machen.

Offizieller '''Starttermin''' für den Grundschutz++ war der '''1.1.2026'''. Danach ist allerdings eine längere Übergangsphase (bis 2029) geplant, in der beide Standards parallel genutzt werden können, so wie bei der letzten Modernisierung auch. Da jedoch zu erwarten ist, dass eine automatisierte Migration auch diesmal nicht oder nur eingeschränkt möglich sein wird, sollte speziell in größeren Verbünden rechtzeitig begonnen werden! Der jeweils aktuellen Grundschutz++ Katalog wird auf [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek GitHub] veröffentlicht.
=== Bedeutung von OSCAL im Grundschutz++ ===
Das zugrundeliegende Format für Grundschutz++ ist [[OSCAL]].

[[OSCAL]] ist ein '''Framework''' bzw. eine '''Datenmodellierungssprache''', die vom NIST speziell für Sicherheitsanforderungen und Compliance-Dokumentation entwickelt wurde. OSCAL definiert dabei nur ein festes Schema für Sicherheits- und Compliance-Daten und lässt das zugrundeliegende Datenformat (JSON, XML oder YAML) offen.

Das BSI hat sich beim Grundschutz++ für das Datenformat '''JSON''' entschieden.

Dies ermöglicht es mit entsprechenden Tools Sicherheitsanforderungen automatisiert einzulesen und zu bearbeiten. D.h.

* Anforderungen können (teil-)automatisiert von entsprechenden Tools bearbeitet und dokumentiert werden, sofern entsprechende Tools zur Verfügung stehen oder vom Anwender (ggf. Dienstleister) programmiert werden.
* Kataloge und Sicherheitskonzepte (SSPs) können zwischen ISMS-Tools herstellerunabhängig ausgetauscht werden (sofern Toolhersteller sich an den Standard halten und entsprechende Im- und Exportfonktionen in ihren Tools zur Verfügung stellen).

Das heißt aber nicht:

* Das Anwender, Sicherheitsmanager oder Sicherheitsbeauftragte OSCAL lernen müssen oder OSCAL Formate lesen können müssen. (Dafür gibt es Tools, die die Inhalte lesbar und bearbeitbar zur Verfügung stellen)
* Das alle Anforderungen automatisiert erfüllt und dokumentiert werden (viele Anforderungen sind nach wie vor organisatorische Anforderungen die nur von Menschen durch Erstellung und Beachtung entsprechenden Regelungen erfüllt werden können).
* Das überhaupt irgendwelche Anforderungen automatisiert erfüllt und dokumentiert werden (Hierzu müssten die Systeme an ein ISMS-Tool angebunden sein und diese über entsprechende Schnittstellen mit Informationen bedienen). Sowohl die Tools als auch die Schnittstellen werden absehbar nicht vom Himmel fallen.
===Satzschablonen===
Anforderungen werden im Grundschutz++ zukünftig mit Satzschablonen erstellt, die wie folgt aussehen:<blockquote><big>'''<span style="color:green">{Praktik} [für {Zielobjekt}]</span> <span style="color:red">{MODALVERB}</span> <span style="color:blue"><Ergebnis></span> <span style="color:purple">{Handlungswort}</span>''' ''<span style="color:grey">(TAGs) (Hinweise)</span>''</big></blockquote>'''Praktik''': Ein Prozess im Rahmen des ISMS, eine konkrete Sicherheitsmaßnahme oder eine allgemeine Vorgehensweise zur Erreichung eines Sicherheitsziels (z.B. IT-Betrieb, Personal, Konfiguration) - Im weitesten Sinne vergleichbar mit den bisherigen Bausteinen. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/praktiken.csv Liste der gültigen Praktiken.]

'''Zielobjekt''': Wie bisher, das Objekt oder die Entität, auf die sich die Sicherheitsanforderungen beziehen (z.B. Daten, Personen, Endgeräte, Hostsysteme). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/zielobjektkategorien.csv Liste der Gültigen Zielobjekte.]

'''Modalverb''': Gibt die Verbindlichkeit einer Anforderung an (MUSS, SOLLTE, KANN).

'''Ereignis''': Der sicherheitsrelevante Zustand oder Auslöser, der zu einer bestimmten Handlung führt - Entspricht in Verbindung mit dem Handlungswort dem wesentliche Inhalt der Anforderung.

'''Handlungswort''': Das Verb, das die konkrete Sicherheitsmaßnahme oder Art der Tätigkeit beschreibt (regeln, zuweisen, konfigurieren). Handlungsworte können auch zur besseren Filterung genutzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/handlungsworte.csv Liste der gültigen Handlungsworte.]

Das ganze kann noch mit '''TAG'''s für eine bessere Gruppierung und mit einem '''Hinweis''' zu weiterführenden Informationen ergänzt werden.

Die bisherigen Anforderungen des Kompendium werden aktuell in ihre Teilanforderungen zerlegt und jede Teilanforderung wird zukünftig eine eigene Anforderung. D.h. jedes Modalverb (SOLL, MUSS, KANN) der bisherigen Anforderungen stellt zukünftig i.d.R. eine eigene Anforderung dar. Die Gesamtanzahl der Anforderungen soll dabei durch die Vermeidung von Redundanzen dennoch sinken.

'''Beispiel'''

Die Anforderung:<blockquote>'''ISMS.1.A4 Benennung eines oder einer Informationssicherheitsbeauftragten (B) [Institutionsleitung]'''

Die Institutionsleitung MUSS einen oder eine ISB benennen. '''. . .'''

Die Institutionsleitung MUSS den oder die ISB mit angemessenen Ressourcen ausstatten.

Die Institutionsleitung MUSS dem oder der ISB die Möglichkeit einräumen, bei Bedarf direkt an sie selbst zu berichten. '''. . .'''</blockquote>Wird jetzt zu den Anforderungen:<blockquote>'''GOV.4.2''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">einer Person die Rolle ISB</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.2.3''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">für das ISMS erforderliche personelle, finanzielle und zeitliche Ressourcen</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.4.4''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">dem ISB das direkte und jederzeitige Vorspracherecht bei der Institutionsleitung</span> '''<span style="color:purple">ermöglichen</span>.'''</blockquote>Da dies übergreifende Anforderungen sind, ist hier kein spezifisches Zielobjekt benannt.

Einzelne Teilanforderungen können auch in anderen Praktiken beschrieben sein.
===Priorisierung===
Alle Anforderungen werden einer Prioritätsstufe zugeordnet, um die Umsetzung effizient zu gestalten:
*'''Stufe 0''': Zwingend (sofort) umzusetzende Anforderungen zur Sicherstellung der ISO-Kompatibilität (MUSS-Anforderungen).
Die Stufen 1-4 geben den Umsetzungsaufwand der Anforderungen wieder:
*'''Stufe 1''': Schnell und mit geringem Aufwand (~1 Tag) realisierbare Maßnahmen (QuickWin) / keine laufenden Aufwände.
*'''Stufe 2''': Mit eigenen Mitteln leicht umsetzbare Anforderung (~1 Woche) / geringe laufende Aufwände.
*'''Stufe 3''': Mit normalem Aufwand (mehrere Wochen) und ggf. externer Unterstützung umsetzbar / normale laufende Aufwände.
*'''Stufe 4''': Höherer Umsetzungsaufwand, häufig in längerfristigen Projekten mit externen Experten.
Die nächste Stufe sind optionale Anforderungen als Vorschläge bei erhöhtem Schutzbedarf.
*'''Stufe 5''': Umfassende/zusätzliche Anforderungen für höheren Schutzbedarf.
Diese Einstufung ermöglicht eine schnelle Einschätzung des Umsetzungsaufwands und hilft bei der effizienten Ressourcenplanung.
===Leistungskennzahlen===
Leistungskennzahlen dienen der '''Messung und Bewertung''' der Umsetzung von Sicherheitsanforderungen im Grundschutz++. Sie ermöglichen eine objektive Einschätzung des Sicherheitsniveaus und unterstützen die kontinuierliche Verbesserung. Wie diese Leistungskennzahlen genutzt werden sollen ist nach wie vor unklar und viele Anforderungen sind bislang noch nicht bewertet.
====Bewertungskriterien====
Jede Anforderung wird in Bezug auf die drei Schutzziele bewertet:
*'''Vertraulichkeit (C)'''
*'''Integrität (I)'''
*'''Verfügbarkeit (A)'''
Anforderungen erhalten Punktwerte in diesen Kategorien, die zur Bestimmung des Schutzgrades genutzt werden (z.B. C=6, I=2, A=0 ist eine Anforderung die im Wesentlichen die Vetraulichkeit stärkt, in Teilen die Intgrität aber nicht die Verfügbarkeit).

Die einzelen Kennzahlen werden je Schutzziel, Praktik und/oder Zielobjekt aufsummiert und ergeben so den Erfüllungsgrad.
====Schwellwerte und Erfüllungsgrad====
*'''Schwellwerte''' definieren das angestrebte Sicherheitsniveau basierend auf der Summe der Punktwerte aller umgesetzten Anforderungen je Schutzziel, Zielobjekt und Schutzstufe.
*'''Der Erfüllungsgrad''' zeigt, welche Anforderungen bereits umgesetzt wurden.
Die Leistungskennzahlen bieten damit eine fundierte Entscheidungsgrundlage für Organisationen, um ihren Sicherheitsstatus gezielt zu verbessern, wenn sie wie ursprünglich geplant eingeführt werden.
==Was bleibt erhalten?==
===Standards und Vorgehen===
Trotz eines deutlich anderen Formats und einer anderen Gruppierung der Anforderungen bleibt das grundsätzliche Vorgehen weitgehend gleich.

D.h. die Standards 200-1 bis 200-4 sollen erst einmal weiter Verwendung finden. Die bisher üblichen Arbeitsschritte:
#Festlegung des Geltungsbereichs
#Strukturanalyse
#Schutzbedarfsfeststellung
#Modellierung
#IT-Grundschutzcheck (GSC)
#Risikoanalyse
bleiben grundsätzlich erhalten, ändern sich jedoch in der praktischen Anwendung und Priorität (insbesondere in der '''Modellierung''' und den '''Grundschutzchecks'''). Parallel zur Einführung sollen die Standards weiter entwickelt werden.

'''MUSS'''-Anforderungen sind weiterhin '''verpflichtend''' für eine Zertifizierung, sollen aber deutlich rediziert werden.

'''SOLLTE'''-Anforderungen bleiben auch weiter '''grundsätzlich verpflichtend''', können aber ggf. mit angemessener Begründung oder Ersatzmaßnahmen wegdiskutiert werden.

Lediglich '''KANN'''-Anforderungen sind optional.
===Tool-Einsatz===
Auch der Einsatz von ISMS-Tools wird weiterhin Bestand haben. Alle größeren Tool-Hersteller arbeiten mit Hochdruck an der Integration von Grundschutz++ in ihre Tools. Hier wird es perspektivisch Erleichterungen durch einen leichteren Datenaustausch zwischen den Tools und mehr Automatisierungspotential geben.
==Gegenüberstellung Grundschutz Kompendium vs. Grundschutz++==
Das IT-Grundschutz-Kompendium 2023 und der zukünftige Grundschutz++ bieten unterschiedliche Konzepte für die Umsetzung von Informationssicherheit: Während das Kompendium auf feste Bausteine in thematisch gegliederten Schichten setzt, verwendet Grundschutz++ modulare, flexibel einsetzbare Praktiken.

Die folgende Tabelle stellt die wesentlichen Unterschiede und Gemeinsamkeiten zwischen beiden Ansätzen (nach aktuell verfügbaren Kenntnissen) gegenüber:
{| class="wikitable"
|+
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Fester verbindlicher Katalog''' von Anforderungen (PDF, Excel und XML), die je nach Reifegrad erfüllt werden müssen.
|Der '''variable''' und erweiterbare '''[[OSCAL]]'''-Datenbestand kann beliebig an die Bedürfnisse der Organisation angepasst werden. Zusätzliche Kataloge/Erweiterungen (C5, Datenschutz, KRITIS/NIS2) können je nach Verfügbarkeit ergänzt werden. Durch die Beseitigung vermeintlicher Redundanzen soll die Anzahl der Anforderungen erheblich reduziert werden (~10–20 % verbleibende Anforderungen gegenüber dem Grundschutz Kompendium).
|-
|
|Järliche '''Aktualisierung''' zum Stichtag '''1. Februar'''.
(bis 2023)
|Die '''Aktualisierung''' erfolgt '''fortlaufend''' nach Bedarf und Verfügbarkeit. Die Regelungen zur Relevanz für Zertifizierungen sind bislang noch nicht bekannt.
|-
|
|Das Kompendium ist (Stand 2023) in 10 '''Schichten''' mit insgesamt 111 '''Bausteine''' gegliedert, die statisch die jeweiligen Anforderungen enthalten.
|'''Praktiken''' und '''''Zielobjekte/Zielobjektkategorien''''' (Achtung abweichende Bedeutung in GS++) sind allgemeinere und wiederverwendbare, sicherheitsrelevante Verfahren oder Maßnahmen. Sie können modular und situationsabhängig einzelnen Assets zugeordnet werden.
Die voraussichtlich ca. 20 Praktiken liegen irgendwo zwischen Schichten und Bausteinen. Sie sind prozessorientierter, adressieren eher Zielgruppen oder Handlungstypen und sind nicht mehr starr bestimmten Zielobjekten zugeordnet. Zielobjekte entsprechen zukünftig eher den Bausteinen im alten Grundschutz. Die Definitionen der Begriffe sind nach wie vor unklar!
|-
|
|'''Drei Stufen''' (Vorgehensweisen): Basis, Standard, erhöhter Schutzbedarf bilden den Reifegrad der Organisation ab.
|Es sind zukünftig '''sechs Stufen''' (0–5) geplant, die sich weitgehend am Umsetzungsaufwand der jeweiligen Anforderung orientieren: Je kleiner die Stufe, desto schneller bzw. leichter ist die Anforderung umsetzbar (Quick Win). Eine qualitative Bewertung des Reifegrads muss zukünftig anders erfolgen (z. B. über Leistungskennzahlen).
Das '''Sicherheitsniveau''' gibt zukünftig an, in welchem Maß die definierten Sicherheitsziele erreicht sind. Es ergibt sich aus der wirksamen Umsetzung organisatorischer, technischer und personeller Anforderungen.

Unterschieden werden:
*'''Normales Sicherheitsniveau''': entspricht dem Stand der Technik
*'''Erhöhtes Sicherheitsniveau''': für besonders schutzbedürftige Informationen oder Systeme
|-
|
|'''Zielobjekte''' als gruppierte Sammlung von gleichartigen Assets die zur späteren '''Modellierung''' (Zuordnung der Bausteine und Abhängigkeiten) genutzt werden.
|'''Zielobjekte''' werden auch in Zukunft eine ähnliche Funktion zur Gruppierung und '''Modellierung''' haben, entsprechend dabei aber eher den klassischen Bausteinen. Die konkreten Vorgaben zur Modellierung sind jedoch noch nicht detailliert genug. In der Modellierung werden die Praktiken nicht mehr statisch bestimmten Zielobjekttypen zugewiesen. Klassische Zielobjekte werden zukünftig als Assets oder Assetgruppen bezeichnet.
|-
|
|Modalverben '''MUSS''', '''SOLLTE''', '''KANN''' bestimmen die Verbindlichkeit von Anforderungen.
|Die Bedeutung der Modalverben ('''MUSS, SOLLTE, KANN''') bleibt unverändert. Ein Ziel von Grundschutz++ ist es jedoch, die Anzahl der Muss-Anforderungen auf das Nötigste zu reduzieren (unter 10 %). Dadurch soll der Grundschutz flexibler werden. Die Verbindlichkeit von Anforderungen, die über MUSS-Anforderungen hinausgehen, ist noch unklar.
|-
|
| -
|Neu sind '''Leistungskennzahlen''', die eine qualitative Bewertung der Anforderungen in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit darstellen. Sie sollen als Zahlenwert darstellbar sein und so den Reifegrad abbilden können. Bisher ist noch nicht bekannt, ob und wann diese eingeführt werden und wie die konkreten Regelungen aussehen werden.
|-
|
|Gültigkeit voraussichtlich bis 2029
|Gültig ab 1.1.2026. Zertifizierbar geplant ab 2027.
|}Teilweise werden Begrifflichkeiten neu (oder anders) definiert:
{| class="wikitable"
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Zielobjekt''' als gruppierte Sammlung von gleichartigen Assets als Grundlage für die spätere Modellierung
|'''Asset''' und gruppierte Assets. Die Gruppierung gleichartiger Assets kann weiterhin erfolgen es bleiben jedoch auch dann '''Assets'''. Der Begriff ''Zielobjekt'' wird hierfür nicht mehr genutzt.
|-
|
|'''Baustein''' als Sammlung von Anforderungen für bestimmte Zielobjekttypen.
|'''Zielobjekt''' sind zukünftig das was bislang die ''Bausteine'' waren, bestimmte Typen von Assets für die spezische Anforderungen gelten. Die Assets werden den Zielobjekten zugewisen und erhalten über diese ihre Anforderungen. Eine klare Definition der Begriffe steht noch aus.
|-
|
|
|
|}
==Blaupausen==
Blaupausen sind vorgefertigte Musterlösungen (wie die bisherigen IT-Grundschutz-Profile), die als Vorlage (Referenzmodell) für die Erstellung und Umsetzung von branchenspezifischen oder organisationsspezifischen Sicherheitskonzepten dienen.
===Funktion der Blaupausen===
Solche Blaupausen erfassen typische Strukturen, Risiken, Anforderungen und Maßnahmen für bestimmte Anwendungsszenarien, etwa die Nutzung der E-Akte oder den sicheren Betrieb von 5G-Infrastrukturen. Sie ermöglichen es, ein ISMS deutlich effizienter und strukturierter aufzubauen, weil die grundlegenden Überlegungen (Schutzbedarfsermittlung, Zuordnung von Praktiken, Zielobjekten und Maßnahmen, etc.) bereits allgemein gültig vorformuliert sind und nur noch organisationsspezifisch angepasst werden müssen.
===Ziel und Nutzen===
*Blaupausen helfen, den Implementierungsaufwand für ISMS nach Grundschutz++ zu reduzieren.
*Sie fördern die Standardisierung und Wiederverwendbarkeit von Sicherheitskonzepten für ähnliche Organisationen oder Branchen.
*Besonders für kleinere Organisationen und typische Anwendungsfälle bieten sie einen niederschwelligen, strukturierten und praxiserprobten Einstieg in die Absicherung.
Damit sind Blaupausen im Grundschutz++ zentrale Instrumente, um bewährte Sicherheitsmethoden als Vorlage für den schnellen und einheitlichen Aufbau eines branchenspezifischen ISMS bereitzustellen.
===Umsetzung===
Umgesetzt werden Blaupausen technische als '''OSCAL-Profile''' mit zusätzlichen Erläuterungen in Textform, zukünftig sollen Blaupausen zu einem '''System Security Plan (SSP)''' weiter entwickelt werden.
== Grundlagen und Standards ==

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_1.html BSI-Standard 200-1: Anforderungen an ein ISMS].
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_2.html BSI-Standard 200-2: IT-Grundschutz Methodik] ( <- Wird neu erstellt )
** Methodik zum Grundschutz++ (Aktuell in Erstellung, ersetzt 200-2)
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_3.html BSI-Standard 200-3: Risikomanagement mit Grundschutz].
* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/BSI-Standards/BSI-Standard-200-4-Business-Continuity-Management/bsi-standard-200-4_Business_Continuity_Management_node.html BSI-Standard 200-4: Business Continuity Management].
* [[OSCAL|OSCAL (Open Security Controls Assessment Language)]].

== Schritt-für-Schritt-Methodik ==
Die Methodik zum Grundschutz++ folgt einem '''5-stufigem PDCA-basierten Prozess''' mit Fokus auf '''Anforderungsmodellierung''' und '''maschinenlesbarer Verarbeitung'''. Hier das praktische Vorgehen:

=== Schritt 1: Erhebung und Planung (PLAN - Governance/Compliance) ===
# '''Kontextanalyse''' (intern/extern) durchführen
# '''Interessierte Parteien''' identifizieren und Anforderungen erfassen
# '''Geltungsbereich''' (Scope) durch Institutionsleitung festlegen und freigeben
# '''Geschäftsprozesse''' priorisieren → Schutzbedarf "normal" oder "hoch" einstufen
# '''Sicherheitsleitlinie''' erstellen (Ziele, Strategie, Verpflichtung Leitung)
# '''Sicherheitsorganisation''' etablieren (Rollen: ISB, Asset-Owner, etc.)
# '''Compliance-Management''' initialisieren (Rechts-/Vertragskatalog)

'''Ergebnis''': Organisatorischer Rahmen, Sicherheitsleitlinie, priorisierte Prozesse

'''Weiterführende Informationen:'''

* [[Informationssicherheitsleitlinie]]
* [[IS-Strategie]]
* [[Geschäftsprozesse]]

=== Schritt 2: Anforderungsanalyse (PLAN - Strukturmodellierung) ===
# '''Informationsverbund''' definieren (techn./org. Abgrenzung)
# '''Assets''' für wichtigsten Geschäftsprozess erfassen
# '''Asset → Zielobjektkategorien''' mapping (Hierarchie + Vererbung)
# '''Anforderungspaket''' generieren:
#* ISMS-Praktiken (vollständig)
#* Zielobjekt-Anforderungen (Sicherheitsniveau: normal/erhöht)
#* Zielobjektlose Anforderungen prüfen
# '''Ergänzungen''': Externe Verpflichtungen, anforderungslose Assets
# '''Risikobetrachtung''' bei hohem Schutzbedarf oder Niveauerhöhung
# '''Parameter setzen''' (Zuständigkeiten, Werte)

'''Ergebnis''': Individuelles Anforderungspaket pro Informationsverbund

'''Weiterführende Informationen:'''

* [[Strukturanalyse]]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das OSCAL-basierte Grundschutz++ Kompendium auf Github.]

=== Schritt 3: Realisierung (DO - Umsetzung) ===
# '''Umsetzungsstatus''' aller Anforderungen prüfen (ja/nein)
# '''Nicht-umgesetzte MUSS/SOLLTE''' → Risikobetrachtung
# '''Umsetzungsplan''' erstellen:
#* Priorisierung (Risiko, Aufwand, Synergien)
#* Zuständigkeiten + Fristen zuweisen
# '''Freigabe''' durch Institutionsleitung
# '''Fortschritt tracken''' (Ticketsystem/Projektmanagement)
# '''Ausnahmen dokumentieren''' (Begründung + Leitungsfreigabe)

'''Ergebnis''': Umsetzungsplan + Status-Dokumentation

'''Weiterführende Informationen:'''

* [[LF-Grundschutzcheck|Leitfaden Grundschutzcheck]]
* [[RiLi-Freigabe]]
* [[RiLi-Ausnahmemanagement|Richtlinie zum Management von Ausnahmen und Abweichungen]]

=== Schritt 4: Überwachung (CHECK - Monitoring/Evaluation) ===
# '''Leistungsbewertung''' (KPIs, Umsetzungsfortschritt, Vorfälle)
# '''Compliance-Überwachung''' (gesetzlich/vertraglich)
# '''Auditprogramm''' risikobasiert durchführen
# '''Managementbewertung''' → Managementbericht erstellen
# '''Monitoring-Tools''' einsetzen (SIEM, Vulnerability Scanner)
# '''Anforderungspaket validieren''' (Aktualität prüfen)

'''Ergebnis''': Auditberichte, Managementbericht

'''Weiterführende Informationen:'''

* [[Reifegradmodell]]
* [[KPIs|Key Performance Indicators (KPIs)]]
* [[Managementbericht|Erstellen eines Managementberichts]]

=== Schritt 5: Kontinuierliche Verbesserung (ACT - Verbesserung) ===
# '''Nicht-Konformitäten''' analysieren
# '''Verbesserungspotenziale''' identifizieren
# '''Korrektur-/Verbesserungsplan''' → in Umsetzungsplan integrieren
# '''Wirksamkeit prüfen''' nach Umsetzung
# '''Sicherheitsniveau''' bewerten (Trendanalyse)
# '''Compliance-Verstöße''' behandeln

'''Ergebnis''': Aktualisiertes Anforderungspaket → neuer PDCA-Zyklus

'''Weiterführende Informationen:'''

*

=== Praktische Hinweise ===
* '''Tool-gestützt''': JSON/OSCAL-Bausteine, Zur Nutzung sind ISMS-Tools empfohlen.
* '''Iteration''': Wichtigster Geschäftsprozess zuerst, dann schrittweise erweitern
* '''Risikobetrachtung''': Bei Sicherheitsniveau "hoch" oder Nicht-Umsetzung
* '''Dokumentation''': bevorzugt Maschinenlesbar (OSCAL) für besseren Austausch

'''Zyklusdauer''': Jährlich oder ereignisgesteuert (Änderungen, Vorfälle, Audits)

== Migration bestehender Sicherheitskonzepte ==
...

'''Weiterführende Informationen:'''

[[Grundschutz++ Migration]]

== Offenen Punkte und Kritiken ==

=== Zu viele Beteiligte, unklare Zuständigkeiten ===
Die Weiterentwicklung des Grundschutzes wird inzwischen nicht mehr ausschließlich vom Grundschutz-Referat des BSI verantwortet. Mit dem Einstieg des Referats „Stand der Technik“ und der verstärkten Einbindung der „Community“ sind die Zuständigkeiten und Verantwortlichkeiten unklarer geworden. In Präsentationen und Veröffentlichungen werden die Rollen und Aufgaben der verschiedenen Beteiligten unterschiedlich dargestellt. Es fehlt eine klare, kommunizierte Schnittstelle, wer für welche Aspekte der Entwicklung, Pflege und Kommunikation des neuen Standards verantwortlich ist. Das erschwert für Anwendende die Orientierung und die Planung der eigenen Umsetzungsstrategie.

=== Unklare Umsetzung einiger Ziele ===
Einige der im Grundschutz++ adressierten Ziele und Neuerungen sind nach wie vor nicht ausreichend konkretisiert. Besonders die Einführung von Leistungskennzahlen und die Priorisierung der Anforderungen (Stufen) werfen noch viele Fragen auf. Die konkrete Bedeutung, Messung und praktische Umsetzung dieser Leistungskennzahlen werden von verschiedenen BSI-Vertretern unterschiedlich dargestellt. Auch die Stufenmodelle werden teils als Priorisierung, als Entwicklungsstufen oder als reiner Umsetzungaufwand der Anforderungen definiert und sind in ihrer praktischen Anwendung noch nicht abschließend geklärt. Das führt zu Unsicherheiten, wie diese neuen Instrumente im einem ISMS umgesetzt und nachgewiesen werden sollen.

=== Geringer Mehrwert im Vergleich zu ISO 27001 ===
Die Anforderungen im Grundschutz++ werden zunehmend an die Formulierungen und Strukturen der ISO 27001 angeglichen. Während der klassische IT-Grundschutz durch seine konkreten, praxisnahen Maßnahmen einen klaren Mehrwert gegenüber der eher abstrakten ISO 27001 bot, verliert er durch die Harmonisierung mit internationalen Standards zunehmend diesen Vorteil. Die Anforderungen werden stärker abstrakt modularisiert formuliert, wodurch der spezifische Bezug zu typischen Umsetzungsbeispielen und die Detailtiefe abnehmen. Für viele Organisationen wird sich daher die Frage stellen, warum sie den immer noch aufwändigeren Weg über den Grundschutz wählen sollten, wenn sie mit ähnlichem oder geringeren Aufwand direkt eine ISO 27001-Zertifizierung anstreben können.

=== Zu ambitionierter Zeitplan ===
Der Grundschutz++ sollte ab dem 1.1.2026 grundsätzlich gültig und anwedbar sein, wobei eine Übergangsphase bis 2029 vorgesehen war. Bisher ist nur ein erster Entwurf veröffentlicht. Angesichts der Vielzahl an noch offenen Fragen, der fehlenden Migrationsstrategie und der Komplexität der Änderungen erscheint der Zeitplan sehr ambitioniert. Ausarbeitung und Dokumentation liegen bisher nur als Entwurf vor. Eine Pilotierung und Einführung 2026 und eine Übergangsphase bis 2029 ist vorgesehen. Die Gefahr besteht, dass größere Organisationen unter Zeitdruck unzureichend vorbereitet in die neue Methodik wechseln und mit variablen Definitionen und Zielen arbeiten müssen, was die Akzeptanz und Qualität der Umsetzung gefährdet.

=== Zunehmende (Sicherheits-)Lücke zwischen Grundschutz und Grundschutz++ ===
Mit der Entscheidung des BSI, den bisherigen IT-Grundschutz (Edition 2023) nicht mehr weiterzuentwickeln und stattdessen auf das neue Grundschutz++-Modell zu setzen, entsteht eine wachsende Lücke in der Informationssicherheit. Diese Übergangsphase bis 2029 ist sicherheitstechnisch kritisch, da sich die Bedrohungslage in der IT nicht an Entwicklungszyklen von Sicherheitsstandards orientiert. Neue Angriffsvektoren, insbesondere durch den zunehmenden Einsatz von KI in der Cyberkriminalität (z.B. KI-gestützte Malware, Deepfakes, automatisierte Phishing-Kampagnen), entstehen kontinuierlich und erfordern zeitnahe, wirksame Gegenmaßnahmen. Der bisherige Grundschutz bildet diese aktuellen Bedrohungen und technologische Entwicklungen jedoch nicht mehr ab, während die spezifischen Module und Maßnahmen im Grundschutz++ noch nicht produktiv verfügbar oder praxistauglich sind.

=== Fehlende Migration vom Grundschutz-Kompendium zu Grundschutz++ ===
Aktuell existiert weder ein konkreter Plan noch ein Konzept für eine (teil-)automatisierte Migration bestehender Sicherheitskonzepte aus dem bisherigen Grundschutz-Kompendium in das neue Grundschutz++-Modell. Die Umstellung auf ein maschinenlesbares JSON/OSCAL-Format und die objektorientierte, prozessorientierte Struktur bedeuten einen fundamentalen Bruch mit bisherigen Strukturen. Die Unterschiede zwischen Grundschutz-Kompendium und Grundschutz++ sind gravierender als beim letzten Wechsel von den Grundschutz-Katalogen zum Kompendium, bei dem bereits alle Ansätze für eine automatisierte Migration weitgehend gescheitert sind. Auch diesmal ist absehbar, dass Organisationen ihre bestehenden Dokumentationen und Umsetzungen weitgehend manuell neu abbilden müssen, was insbesondere für größere Verbünde einen erheblichen Zusatzaufwand bedeutet. Es gibt zwar Ansätze dies mittels KI zu lösen, was aber sicher nicht für jede Organisation praktikabel sein wird.

== Fazit ==
Ein abschließendes Bild zum Grundschutz++ lässt sich aktuell noch nicht zeichnen – viele Details sind noch in der Entwicklung.

Die grundlegende Modernisierung des IT-Grundschutzes durch das Grundschutz++-Projekt ist zwar fachlich und technologisch nachvollziehbar und adressiert viele Schwächen des bisherigen Systems. Die Umsetzung ist jedoch nach jetzigem Entwicklungsstand mit erheblichen Risiken und Unsicherheiten verbunden. Ohne klare Migrationspfade, eindeutige Zuständigkeiten und praxistaugliche Konkretisierungen der neuen Instrumente besteht die Gefahr, dass die Akzeptanz des Grundschutzes sinkt und Organisationen sich vermehrt alternativen Standards wie der ISO 27001 zuwenden. Ein realistischer Zeitplan und ein echter Mehrwert des neuen Standards sind daher essenziell für den Erfolg der Reform.

Der Artikel wird fortlaufend aktualisiert, sobald neue Informationen vom BSI veröffentlicht oder freigegeben werden.
===Ausblick und ToDos aus Anwendersicht===
Stichtag für die Einführung von Grundschutz++ war der '''1.1.2026'''. Das Datum wurde vom BSI in offiziellen Ankündigungen, Präsentationen und Fachveranstaltungen als verbindlicher Startpunkt kommuniziert. Ab diesem Zeitpunkt sollte das neue, digitale und prozessorientierte Regelwerk den bisherigen IT-Grundschutz ablösen. Bisher fehlt es jedoch an vielen Stellen an klaren Definitionen und konkreten Vorgaben zur Methodik.

Auch wenn abzuwarten bleibt, wann praxistaugliche Methoden verfügbar sind und wie lange die Übergangsfristen für die Umstellung sein werden (aktuelle Planung bis 2029). Abzusehen ist jedoch, dass der Aufwand und der Zeitdruck, insbesondere für größere und zertifizierte Verbünde, erheblich sein werden. Auch wenn es aktuell noch keine konkreten Beschreibungen zur Methodik und Modellierung gibt, können und sollten sich Anwender bereits jetzt vorbereiten. Dazu können die folgenden Maßnahmen dienen:
*Laufende Information über den aktuellen Stand (Internetseiten des BSI, Vorträge und Veröffentlichungen).
*Konsolidierung der bestehenden Verbünde (Reduzierung der Komplexität, konsistente Dokumentation der Gruppierung und Modellierung).
**Ein guter Tip ist es, in aktuellen GSC jede Teilanforderung (jedes Modalverb wie MUSS oder SOLLTE) in der Umsetzung einzeln zu dokumentieren, da diese zukünftig eigenständige Anforderungen darstellen und so eine Übernahme leichter werden könnte.
*Kontakt zu Toolherstellern aufnehmen und eine zügige Umsetzung in den verwendeten ISMS-Tools einfordern.
*Frühzeitige Planung der Bereitstellung entsprechender personeller Ressourcen für die Umstellung auf Grundschutz++ ab Mitte 2026.
*Gegebenenfalls frühzeitige Reservierung externer (personeller) Ressourcen zur Unterstützung.
*Es muss eine klare interne Kommunikation über die bevorstehenden, durch die Umstellung bedingten erhöhten Aufwände (Schulungen, neue (Erst-)GSCs und Anpassung der Dokumentation) geben, damit Mitarbeitende und Verantwortliche wissen, was auf sie zukommt.

== Weiterführende Ressourcen ==
*[https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html BSI IT-Grundschutz]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html BSI Leitfaden zur Grundschutz++-Methodik (1.4.2026)]
*[https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/Grundschutz/1GS_Tag_2025/Aktuelle_Entwicklungen_Ausblick_IT-GS.pdf Aktuelle Entwicklungen und Ausblick zum IT-Grundschutz - 1. Grundschutztag 2025]
*[https://www.youtube.com/watch?v=_AeWJ_Z8S-4 Keynote: Fortentwicklung des IT-Grundschutzes zu IT-Grundschutz++ (verinice.XP 2025)]
*[https://www.youtube.com/watch?v=fBXuhELODGA Vortrag: "Keynote und Vision Grundschutz++" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.youtube.com/watch?v=PxOjkV6oUwU Vortrag "Grundschutz++ Methodik und Einstieg ins BCM" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.bsi.bund.de/dok/it-sa Am Mittwoch, 08.10.2025 werden auf der it-sa die von den Arbeitsgruppen aus der Community erarbeiteten Ergebnisse präsentiert.]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]
*[[Grundschutz++ Migration|Migrationsstrategie für den Umstieg von BSI IT-Grundschutz auf Grundschutz++]]
[[Kategorie:Artikel]]
[[Kategorie:Grundschutz]]
[[Kategorie:++]]

Grundschutz++ Einführung und Aufbau

2026-04-04T03:06:00Z

Dirk: /* Weiterführende Ressourcen */

[[Datei:Teamwork-2198961.png|alternativtext=Zahnrad|rechts|240x240px]]{{#seo:
|title=Grundschutz++ Einführung und Anleitung
|keywords=ISMS, Wiki, BSI Grundschutz++, IT-Grundschutz, BSI-Standard 200-2, Bausteine, OSCAL, JSON, Informationssicherheit, Risikomanagement, Anforderungen
|description=Überblick über den neuen BSI Grundschutz++. Startseite zur Navigation durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.
}}{{SHORTDESC:Grundschutz++ Überblick und Anleitung}}''Dieser Artikel bietet einen schrittweisen Überblick über BSI '''Grundschutz++''' und navigiert durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.''

== Einführung in Grundschutz++ ==
'''Grundschutz++''' ist die 2026 vom BSI eingeführte Weiterentwicklung des IT-Grundschutz-Kompendiums. Es transformiert das bewährte Grundschutz-Konzept in ein vollständig digitales, maschinenlesbares Format mit JSON-basierten Bausteinen und OSCAL-kompatibler Struktur.<blockquote>
''Der aktuelle Stand von Grundschutz++ ist bisher nur sehr eingeschränkt praktisch anwendbar, da einige wesentliche Definitionen und Teile der Methodik noch fehlen. Dazu gehören beispielsweise die Nutzung von Kennzahlen, Blaupausen, Stufen, Schutzbedarf vs. Schutzniveau und die Modellierung.''

''Der Anforderungskatalog liegt zwar im OSCAL- und Excel-Format vor, ist ohne eine abgeschlossene und nachvollziehbare Methodik aber nicht sinnvoll anwendbar.''
</blockquote>
=== Wesentliche Neuerungen===
*'''OSCAL/JSON-basiertes Regelwerk''': Der IT-Grundschutz wird in ein maschinenlesbares '''JSON-Format''' überführt, das teilweise automatisierte Compliance-Prüfungen und Integrationen in bestehende IT-Systeme ermöglicht. Dies ersetzt die bisherigen textbasierten PDFs und Listen.
*'''Prozessorientierte Struktur''': Die neue Version ist modular und objektorientiert aufgebaut, um Redundanzen zu reduzieren und die Dokumentationslast zu verringern.
*'''Leistungskennzahlen''': Kennzahlen sollen die Informationssicherheit messbar und den Sicherheitsgewinn einzelner Anforderungen transparenter machen.
* '''Harmonisierung mit ISO 27001''': Die Anforderungen werden stärker mit internationalen Standards wie '''ISO 27001:2022''' abgestimmt, um Doppelzertifizierungen zu vereinfachen.
*'''Erweiterung um moderne Technologien''': Geplant sind auch spezifische Module für '''Cloud-Security, KI und IoT''', die aktuelle Bedrohungsszenarien abdecken.
===Ziele der Reform===
*'''Schlankere Prozesse''': Durch Automatisierung soll der administrative Aufwand sinken.
*'''Dynamische Anpassung''': JSON ermöglicht schnellere, ggf. automatisierte Updates bei neuen Cyberbedrohungen.
*'''Praxisorientierte Vereinfachung''': Der BSI will die Dokumentationslast reduzieren und den Fokus auf risikobasierte Ansätze legen, insbesondere für KMU.
*'''Priorisierung und Messbarkeit''': Durch eine stufenweise Priorisierung von Anforderungen und Leistungskennzahlen soll ein zielgerichteteres Vorgehen und die bessere Messbarkeit der Sicherheit gefördert werden.
Die Änderungen reagieren auf Kritik an der bisherigen Komplexität und sollen besonders KMU entlasten, während die ganzheitliche Sicherheitsmethodik (technisch, organisatorisch, personell) erhalten bleibt.

''Hinweis'': Details zur finalen Struktur werden schrittweise im Jahr 2026 veröffentlicht. Unternehmen sollten sich frühzeitig mit den geplanten Schnittstellen (z.B. für Security-Tools) vertraut machen.

Offizieller '''Starttermin''' für den Grundschutz++ war der '''1.1.2026'''. Danach ist allerdings eine längere Übergangsphase (bis 2029) geplant, in der beide Standards parallel genutzt werden können, so wie bei der letzten Modernisierung auch. Da jedoch zu erwarten ist, dass eine automatisierte Migration auch diesmal nicht oder nur eingeschränkt möglich sein wird, sollte speziell in größeren Verbünden rechtzeitig begonnen werden! Der jeweils aktuellen Grundschutz++ Katalog wird auf [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek GitHub] veröffentlicht.
=== Bedeutung von OSCAL im Grundschutz++ ===
Das zugrundeliegende Format für Grundschutz++ ist [[OSCAL]].

[[OSCAL]] ist ein '''Framework''' bzw. eine '''Datenmodellierungssprache''', die vom NIST speziell für Sicherheitsanforderungen und Compliance-Dokumentation entwickelt wurde. OSCAL definiert dabei nur ein festes Schema für Sicherheits- und Compliance-Daten und lässt das zugrundeliegende Datenformat (JSON, XML oder YAML) offen.

Das BSI hat sich beim Grundschutz++ für das Datenformat '''JSON''' entschieden.

Dies ermöglicht es mit entsprechenden Tools Sicherheitsanforderungen automatisiert einzulesen und zu bearbeiten. D.h.

* Anforderungen können (teil-)automatisiert von entsprechenden Tools bearbeitet und dokumentiert werden, sofern entsprechende Tools zur Verfügung stehen oder vom Anwender (ggf. Dienstleister) programmiert werden.
* Kataloge und Sicherheitskonzepte (SSPs) können zwischen ISMS-Tools herstellerunabhängig ausgetauscht werden (sofern Toolhersteller sich an den Standard halten und entsprechende Im- und Exportfonktionen in ihren Tools zur Verfügung stellen).

Das heißt aber nicht:

* Das Anwender, Sicherheitsmanager oder Sicherheitsbeauftragte OSCAL lernen müssen oder OSCAL Formate lesen können müssen. (Dafür gibt es Tools, die die Inhalte lesbar und bearbeitbar zur Verfügung stellen)
* Das alle Anforderungen automatisiert erfüllt und dokumentiert werden (viele Anforderungen sind nach wie vor organisatorische Anforderungen die nur von Menschen durch Erstellung und Beachtung entsprechenden Regelungen erfüllt werden können).
* Das überhaupt irgendwelche Anforderungen automatisiert erfüllt und dokumentiert werden (Hierzu müssten die Systeme an ein ISMS-Tool angebunden sein und diese über entsprechende Schnittstellen mit Informationen bedienen). Sowohl die Tools als auch die Schnittstellen werden absehbar nicht vom Himmel fallen.
===Satzschablonen===
Anforderungen werden im Grundschutz++ zukünftig mit Satzschablonen erstellt, die wie folgt aussehen:<blockquote><big>'''<span style="color:green">{Praktik} [für {Zielobjekt}]</span> <span style="color:red">{MODALVERB}</span> <span style="color:blue"><Ergebnis></span> <span style="color:purple">{Handlungswort}</span>''' ''<span style="color:grey">(TAGs) (Hinweise)</span>''</big></blockquote>'''Praktik''': Ein Prozess im Rahmen des ISMS, eine konkrete Sicherheitsmaßnahme oder eine allgemeine Vorgehensweise zur Erreichung eines Sicherheitsziels (z.B. IT-Betrieb, Personal, Konfiguration) - Im weitesten Sinne vergleichbar mit den bisherigen Bausteinen. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/praktiken.csv Liste der gültigen Praktiken.]

'''Zielobjekt''': Wie bisher, das Objekt oder die Entität, auf die sich die Sicherheitsanforderungen beziehen (z.B. Daten, Personen, Endgeräte, Hostsysteme). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/zielobjektkategorien.csv Liste der Gültigen Zielobjekte.]

'''Modalverb''': Gibt die Verbindlichkeit einer Anforderung an (MUSS, SOLLTE, KANN).

'''Ereignis''': Der sicherheitsrelevante Zustand oder Auslöser, der zu einer bestimmten Handlung führt - Entspricht in Verbindung mit dem Handlungswort dem wesentliche Inhalt der Anforderung.

'''Handlungswort''': Das Verb, das die konkrete Sicherheitsmaßnahme oder Art der Tätigkeit beschreibt (regeln, zuweisen, konfigurieren). Handlungsworte können auch zur besseren Filterung genutzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/handlungsworte.csv Liste der gültigen Handlungsworte.]

Das ganze kann noch mit '''TAG'''s für eine bessere Gruppierung und mit einem '''Hinweis''' zu weiterführenden Informationen ergänzt werden.

Die bisherigen Anforderungen des Kompendium werden aktuell in ihre Teilanforderungen zerlegt und jede Teilanforderung wird zukünftig eine eigene Anforderung. D.h. jedes Modalverb (SOLL, MUSS, KANN) der bisherigen Anforderungen stellt zukünftig i.d.R. eine eigene Anforderung dar. Die Gesamtanzahl der Anforderungen soll dabei durch die Vermeidung von Redundanzen dennoch sinken.

'''Beispiel'''

Die Anforderung:<blockquote>'''ISMS.1.A4 Benennung eines oder einer Informationssicherheitsbeauftragten (B) [Institutionsleitung]'''

Die Institutionsleitung MUSS einen oder eine ISB benennen. '''. . .'''

Die Institutionsleitung MUSS den oder die ISB mit angemessenen Ressourcen ausstatten.

Die Institutionsleitung MUSS dem oder der ISB die Möglichkeit einräumen, bei Bedarf direkt an sie selbst zu berichten. '''. . .'''</blockquote>Wird jetzt zu den Anforderungen:<blockquote>'''GOV.4.2''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">einer Person die Rolle ISB</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.2.3''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">für das ISMS erforderliche personelle, finanzielle und zeitliche Ressourcen</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.4.4''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">dem ISB das direkte und jederzeitige Vorspracherecht bei der Institutionsleitung</span> '''<span style="color:purple">ermöglichen</span>.'''</blockquote>Da dies übergreifende Anforderungen sind, ist hier kein spezifisches Zielobjekt benannt.

Einzelne Teilanforderungen können auch in anderen Praktiken beschrieben sein.
===Priorisierung===
Alle Anforderungen werden einer Prioritätsstufe zugeordnet, um die Umsetzung effizient zu gestalten:
*'''Stufe 0''': Zwingend (sofort) umzusetzende Anforderungen zur Sicherstellung der ISO-Kompatibilität (MUSS-Anforderungen).
Die Stufen 1-4 geben den Umsetzungsaufwand der Anforderungen wieder:
*'''Stufe 1''': Schnell und mit geringem Aufwand (~1 Tag) realisierbare Maßnahmen (QuickWin) / keine laufenden Aufwände.
*'''Stufe 2''': Mit eigenen Mitteln leicht umsetzbare Anforderung (~1 Woche) / geringe laufende Aufwände.
*'''Stufe 3''': Mit normalem Aufwand (mehrere Wochen) und ggf. externer Unterstützung umsetzbar / normale laufende Aufwände.
*'''Stufe 4''': Höherer Umsetzungsaufwand, häufig in längerfristigen Projekten mit externen Experten.
Die nächste Stufe sind optionale Anforderungen als Vorschläge bei erhöhtem Schutzbedarf.
*'''Stufe 5''': Umfassende/zusätzliche Anforderungen für höheren Schutzbedarf.
Diese Einstufung ermöglicht eine schnelle Einschätzung des Umsetzungsaufwands und hilft bei der effizienten Ressourcenplanung.
===Leistungskennzahlen===
Leistungskennzahlen dienen der '''Messung und Bewertung''' der Umsetzung von Sicherheitsanforderungen im Grundschutz++. Sie ermöglichen eine objektive Einschätzung des Sicherheitsniveaus und unterstützen die kontinuierliche Verbesserung. Wie diese Leistungskennzahlen genutzt werden sollen ist nach wie vor unklar und viele Anforderungen sind bislang noch nicht bewertet.
====Bewertungskriterien====
Jede Anforderung wird in Bezug auf die drei Schutzziele bewertet:
*'''Vertraulichkeit (C)'''
*'''Integrität (I)'''
*'''Verfügbarkeit (A)'''
Anforderungen erhalten Punktwerte in diesen Kategorien, die zur Bestimmung des Schutzgrades genutzt werden (z.B. C=6, I=2, A=0 ist eine Anforderung die im Wesentlichen die Vetraulichkeit stärkt, in Teilen die Intgrität aber nicht die Verfügbarkeit).

Die einzelen Kennzahlen werden je Schutzziel, Praktik und/oder Zielobjekt aufsummiert und ergeben so den Erfüllungsgrad.
====Schwellwerte und Erfüllungsgrad====
*'''Schwellwerte''' definieren das angestrebte Sicherheitsniveau basierend auf der Summe der Punktwerte aller umgesetzten Anforderungen je Schutzziel, Zielobjekt und Schutzstufe.
*'''Der Erfüllungsgrad''' zeigt, welche Anforderungen bereits umgesetzt wurden.
Die Leistungskennzahlen bieten damit eine fundierte Entscheidungsgrundlage für Organisationen, um ihren Sicherheitsstatus gezielt zu verbessern, wenn sie wie ursprünglich geplant eingeführt werden.
==Was bleibt erhalten?==
===Standards und Vorgehen===
Trotz eines deutlich anderen Formats und einer anderen Gruppierung der Anforderungen bleibt das grundsätzliche Vorgehen weitgehend gleich.

D.h. die Standards 200-1 bis 200-4 sollen erst einmal weiter Verwendung finden. Die bisher üblichen Arbeitsschritte:
#Festlegung des Geltungsbereichs
#Strukturanalyse
#Schutzbedarfsfeststellung
#Modellierung
#IT-Grundschutzcheck (GSC)
#Risikoanalyse
bleiben grundsätzlich erhalten, ändern sich jedoch in der praktischen Anwendung und Priorität (insbesondere in der '''Modellierung''' und den '''Grundschutzchecks'''). Parallel zur Einführung sollen die Standards weiter entwickelt werden.

'''MUSS'''-Anforderungen sind weiterhin '''verpflichtend''' für eine Zertifizierung, sollen aber deutlich rediziert werden.

'''SOLLTE'''-Anforderungen bleiben auch weiter '''grundsätzlich verpflichtend''', können aber ggf. mit angemessener Begründung oder Ersatzmaßnahmen wegdiskutiert werden.

Lediglich '''KANN'''-Anforderungen sind optional.
===Tool-Einsatz===
Auch der Einsatz von ISMS-Tools wird weiterhin Bestand haben. Alle größeren Tool-Hersteller arbeiten mit Hochdruck an der Integration von Grundschutz++ in ihre Tools. Hier wird es perspektivisch Erleichterungen durch einen leichteren Datenaustausch zwischen den Tools und mehr Automatisierungspotential geben.
==Gegenüberstellung Grundschutz Kompendium vs. Grundschutz++==
Das IT-Grundschutz-Kompendium 2023 und der zukünftige Grundschutz++ bieten unterschiedliche Konzepte für die Umsetzung von Informationssicherheit: Während das Kompendium auf feste Bausteine in thematisch gegliederten Schichten setzt, verwendet Grundschutz++ modulare, flexibel einsetzbare Praktiken.

Die folgende Tabelle stellt die wesentlichen Unterschiede und Gemeinsamkeiten zwischen beiden Ansätzen (nach aktuell verfügbaren Kenntnissen) gegenüber:
{| class="wikitable"
|+
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Fester verbindlicher Katalog''' von Anforderungen (PDF, Excel und XML), die je nach Reifegrad erfüllt werden müssen.
|Der '''variable''' und erweiterbare '''[[OSCAL]]'''-Datenbestand kann beliebig an die Bedürfnisse der Organisation angepasst werden. Zusätzliche Kataloge/Erweiterungen (C5, Datenschutz, KRITIS/NIS2) können je nach Verfügbarkeit ergänzt werden. Durch die Beseitigung vermeintlicher Redundanzen soll die Anzahl der Anforderungen erheblich reduziert werden (~10–20 % verbleibende Anforderungen gegenüber dem Grundschutz Kompendium).
|-
|
|Järliche '''Aktualisierung''' zum Stichtag '''1. Februar'''.
(bis 2023)
|Die '''Aktualisierung''' erfolgt '''fortlaufend''' nach Bedarf und Verfügbarkeit. Die Regelungen zur Relevanz für Zertifizierungen sind bislang noch nicht bekannt.
|-
|
|Das Kompendium ist (Stand 2023) in 10 '''Schichten''' mit insgesamt 111 '''Bausteine''' gegliedert, die statisch die jeweiligen Anforderungen enthalten.
|'''Praktiken''' und '''''Zielobjekte/Zielobjektkategorien''''' (Achtung abweichende Bedeutung in GS++) sind allgemeinere und wiederverwendbare, sicherheitsrelevante Verfahren oder Maßnahmen. Sie können modular und situationsabhängig einzelnen Assets zugeordnet werden.
Die voraussichtlich ca. 20 Praktiken liegen irgendwo zwischen Schichten und Bausteinen. Sie sind prozessorientierter, adressieren eher Zielgruppen oder Handlungstypen und sind nicht mehr starr bestimmten Zielobjekten zugeordnet. Zielobjekte entsprechen zukünftig eher den Bausteinen im alten Grundschutz. Die Definitionen der Begriffe sind nach wie vor unklar!
|-
|
|'''Drei Stufen''' (Vorgehensweisen): Basis, Standard, erhöhter Schutzbedarf bilden den Reifegrad der Organisation ab.
|Es sind zukünftig '''sechs Stufen''' (0–5) geplant, die sich weitgehend am Umsetzungsaufwand der jeweiligen Anforderung orientieren: Je kleiner die Stufe, desto schneller bzw. leichter ist die Anforderung umsetzbar (Quick Win). Eine qualitative Bewertung des Reifegrads muss zukünftig anders erfolgen (z. B. über Leistungskennzahlen).
Das '''Sicherheitsniveau''' gibt zukünftig an, in welchem Maß die definierten Sicherheitsziele erreicht sind. Es ergibt sich aus der wirksamen Umsetzung organisatorischer, technischer und personeller Anforderungen.

Unterschieden werden:
*'''Normales Sicherheitsniveau''': entspricht dem Stand der Technik
*'''Erhöhtes Sicherheitsniveau''': für besonders schutzbedürftige Informationen oder Systeme
|-
|
|'''Zielobjekte''' als gruppierte Sammlung von gleichartigen Assets die zur späteren '''Modellierung''' (Zuordnung der Bausteine und Abhängigkeiten) genutzt werden.
|'''Zielobjekte''' werden auch in Zukunft eine ähnliche Funktion zur Gruppierung und '''Modellierung''' haben, entsprechend dabei aber eher den klassischen Bausteinen. Die konkreten Vorgaben zur Modellierung sind jedoch noch nicht detailliert genug. In der Modellierung werden die Praktiken nicht mehr statisch bestimmten Zielobjekttypen zugewiesen. Klassische Zielobjekte werden zukünftig als Assets oder Assetgruppen bezeichnet.
|-
|
|Modalverben '''MUSS''', '''SOLLTE''', '''KANN''' bestimmen die Verbindlichkeit von Anforderungen.
|Die Bedeutung der Modalverben ('''MUSS, SOLLTE, KANN''') bleibt unverändert. Ein Ziel von Grundschutz++ ist es jedoch, die Anzahl der Muss-Anforderungen auf das Nötigste zu reduzieren (unter 10 %). Dadurch soll der Grundschutz flexibler werden. Die Verbindlichkeit von Anforderungen, die über MUSS-Anforderungen hinausgehen, ist noch unklar.
|-
|
| -
|Neu sind '''Leistungskennzahlen''', die eine qualitative Bewertung der Anforderungen in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit darstellen. Sie sollen als Zahlenwert darstellbar sein und so den Reifegrad abbilden können. Bisher ist noch nicht bekannt, ob und wann diese eingeführt werden und wie die konkreten Regelungen aussehen werden.
|-
|
|Gültigkeit voraussichtlich bis 2029
|Gültig ab 1.1.2026. Zertifizierbar geplant ab 2027.
|}Teilweise werden Begrifflichkeiten neu (oder anders) definiert:
{| class="wikitable"
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Zielobjekt''' als gruppierte Sammlung von gleichartigen Assets als Grundlage für die spätere Modellierung
|'''Asset''' und gruppierte Assets. Die Gruppierung gleichartiger Assets kann weiterhin erfolgen es bleiben jedoch auch dann '''Assets'''. Der Begriff ''Zielobjekt'' wird hierfür nicht mehr genutzt.
|-
|
|'''Baustein''' als Sammlung von Anforderungen für bestimmte Zielobjekttypen.
|'''Zielobjekt''' sind zukünftig das was bislang die ''Bausteine'' waren, bestimmte Typen von Assets für die spezische Anforderungen gelten. Die Assets werden den Zielobjekten zugewisen und erhalten über diese ihre Anforderungen. Eine klare Definition der Begriffe steht noch aus.
|-
|
|
|
|}
==Blaupausen==
Blaupausen sind vorgefertigte Musterlösungen (wie die bisherigen IT-Grundschutz-Profile), die als Vorlage (Referenzmodell) für die Erstellung und Umsetzung von branchenspezifischen oder organisationsspezifischen Sicherheitskonzepten dienen.
===Funktion der Blaupausen===
Solche Blaupausen erfassen typische Strukturen, Risiken, Anforderungen und Maßnahmen für bestimmte Anwendungsszenarien, etwa die Nutzung der E-Akte oder den sicheren Betrieb von 5G-Infrastrukturen. Sie ermöglichen es, ein ISMS deutlich effizienter und strukturierter aufzubauen, weil die grundlegenden Überlegungen (Schutzbedarfsermittlung, Zuordnung von Praktiken, Zielobjekten und Maßnahmen, etc.) bereits allgemein gültig vorformuliert sind und nur noch organisationsspezifisch angepasst werden müssen.
===Ziel und Nutzen===
*Blaupausen helfen, den Implementierungsaufwand für ISMS nach Grundschutz++ zu reduzieren.
*Sie fördern die Standardisierung und Wiederverwendbarkeit von Sicherheitskonzepten für ähnliche Organisationen oder Branchen.
*Besonders für kleinere Organisationen und typische Anwendungsfälle bieten sie einen niederschwelligen, strukturierten und praxiserprobten Einstieg in die Absicherung.
Damit sind Blaupausen im Grundschutz++ zentrale Instrumente, um bewährte Sicherheitsmethoden als Vorlage für den schnellen und einheitlichen Aufbau eines branchenspezifischen ISMS bereitzustellen.
===Umsetzung===
Umgesetzt werden Blaupausen technische als '''OSCAL-Profile''' mit zusätzlichen Erläuterungen in Textform, zukünftig sollen Blaupausen zu einem '''System Security Plan (SSP)''' weiter entwickelt werden.
== Grundlagen und Standards ==

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_1.html BSI-Standard 200-1: Anforderungen an ein ISMS].
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_2.html BSI-Standard 200-2: IT-Grundschutz Methodik] ( <- Wird neu erstellt )
** Methodik zum Grundschutz++ (Aktuell in Erstellung, ersetzt 200-2)
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_3.html BSI-Standard 200-3: Risikomanagement mit Grundschutz].
* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/BSI-Standards/BSI-Standard-200-4-Business-Continuity-Management/bsi-standard-200-4_Business_Continuity_Management_node.html BSI-Standard 200-4: Business Continuity Management].
* [[OSCAL|OSCAL (Open Security Controls Assessment Language)]].

== Schritt-für-Schritt-Methodik ==
Die Methodik zum Grundschutz++ folgt einem '''5-stufigem PDCA-basierten Prozess''' mit Fokus auf '''Anforderungsmodellierung''' und '''maschinenlesbarer Verarbeitung'''. Hier das praktische Vorgehen:

=== Schritt 1: Erhebung und Planung (PLAN - Governance/Compliance) ===
# '''Kontextanalyse''' (intern/extern) durchführen
# '''Interessierte Parteien''' identifizieren und Anforderungen erfassen
# '''Geltungsbereich''' (Scope) durch Institutionsleitung festlegen und freigeben
# '''Geschäftsprozesse''' priorisieren → Schutzbedarf "normal" oder "hoch" einstufen
# '''Sicherheitsleitlinie''' erstellen (Ziele, Strategie, Verpflichtung Leitung)
# '''Sicherheitsorganisation''' etablieren (Rollen: ISB, Asset-Owner, etc.)
# '''Compliance-Management''' initialisieren (Rechts-/Vertragskatalog)

'''Ergebnis''': Organisatorischer Rahmen, Sicherheitsleitlinie, priorisierte Prozesse

'''Weiterführende Informationen:'''

* [[Informationssicherheitsleitlinie]]
* [[IS-Strategie]]
* [[Geschäftsprozesse]]

=== Schritt 2: Anforderungsanalyse (PLAN - Strukturmodellierung) ===
# '''Informationsverbund''' definieren (techn./org. Abgrenzung)
# '''Assets''' für wichtigsten Geschäftsprozess erfassen
# '''Asset → Zielobjektkategorien''' mapping (Hierarchie + Vererbung)
# '''Anforderungspaket''' generieren:
#* ISMS-Praktiken (vollständig)
#* Zielobjekt-Anforderungen (Sicherheitsniveau: normal/erhöht)
#* Zielobjektlose Anforderungen prüfen
# '''Ergänzungen''': Externe Verpflichtungen, anforderungslose Assets
# '''Risikobetrachtung''' bei hohem Schutzbedarf oder Niveauerhöhung
# '''Parameter setzen''' (Zuständigkeiten, Werte)

'''Ergebnis''': Individuelles Anforderungspaket pro Informationsverbund

'''Weiterführende Informationen:'''

* [[Strukturanalyse]]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das OSCAL-basierte Grundschutz++ Kompendium auf Github.]

=== Schritt 3: Realisierung (DO - Umsetzung) ===
# '''Umsetzungsstatus''' aller Anforderungen prüfen (ja/nein)
# '''Nicht-umgesetzte MUSS/SOLLTE''' → Risikobetrachtung
# '''Umsetzungsplan''' erstellen:
#* Priorisierung (Risiko, Aufwand, Synergien)
#* Zuständigkeiten + Fristen zuweisen
# '''Freigabe''' durch Institutionsleitung
# '''Fortschritt tracken''' (Ticketsystem/Projektmanagement)
# '''Ausnahmen dokumentieren''' (Begründung + Leitungsfreigabe)

'''Ergebnis''': Umsetzungsplan + Status-Dokumentation

'''Weiterführende Informationen:'''

* [[LF-Grundschutzcheck|Leitfaden Grundschutzcheck]]
* [[RiLi-Freigabe]]
* [[RiLi-Ausnahmemanagement|Richtlinie zum Management von Ausnahmen und Abweichungen]]

=== Schritt 4: Überwachung (CHECK - Monitoring/Evaluation) ===
# '''Leistungsbewertung''' (KPIs, Umsetzungsfortschritt, Vorfälle)
# '''Compliance-Überwachung''' (gesetzlich/vertraglich)
# '''Auditprogramm''' risikobasiert durchführen
# '''Managementbewertung''' → Managementbericht erstellen
# '''Monitoring-Tools''' einsetzen (SIEM, Vulnerability Scanner)
# '''Anforderungspaket validieren''' (Aktualität prüfen)

'''Ergebnis''': Auditberichte, Managementbericht

'''Weiterführende Informationen:'''

* [[Reifegradmodell]]
* [[KPIs|Key Performance Indicators (KPIs)]]
* [[Managementbericht|Erstellen eines Managementberichts]]

=== Schritt 5: Kontinuierliche Verbesserung (ACT - Verbesserung) ===
# '''Nicht-Konformitäten''' analysieren
# '''Verbesserungspotenziale''' identifizieren
# '''Korrektur-/Verbesserungsplan''' → in Umsetzungsplan integrieren
# '''Wirksamkeit prüfen''' nach Umsetzung
# '''Sicherheitsniveau''' bewerten (Trendanalyse)
# '''Compliance-Verstöße''' behandeln

'''Ergebnis''': Aktualisiertes Anforderungspaket → neuer PDCA-Zyklus

'''Weiterführende Informationen:'''

*

=== Praktische Hinweise ===
* '''Tool-gestützt''': JSON/OSCAL-Bausteine, Zur Nutzung sind ISMS-Tools empfohlen.
* '''Iteration''': Wichtigster Geschäftsprozess zuerst, dann schrittweise erweitern
* '''Risikobetrachtung''': Bei Sicherheitsniveau "hoch" oder Nicht-Umsetzung
* '''Dokumentation''': bevorzugt Maschinenlesbar (OSCAL) für besseren Austausch

'''Zyklusdauer''': Jährlich oder ereignisgesteuert (Änderungen, Vorfälle, Audits)

== Migration bestehender Sicherheitskonzepte ==
...

'''Weiterführende Informationen:'''

[[Grundschutz++ Migration]]

== Offenen Punkte und Kritiken ==

=== Zu viele Beteiligte, unklare Zuständigkeiten ===
Die Weiterentwicklung des Grundschutzes wird inzwischen nicht mehr ausschließlich vom Grundschutz-Referat des BSI verantwortet. Mit dem Einstieg des Referats „Stand der Technik“ und der verstärkten Einbindung der „Community“ sind die Zuständigkeiten und Verantwortlichkeiten unklarer geworden. In Präsentationen und Veröffentlichungen werden die Rollen und Aufgaben der verschiedenen Beteiligten unterschiedlich dargestellt. Es fehlt eine klare, kommunizierte Schnittstelle, wer für welche Aspekte der Entwicklung, Pflege und Kommunikation des neuen Standards verantwortlich ist. Das erschwert für Anwendende die Orientierung und die Planung der eigenen Umsetzungsstrategie.

=== Unklare Umsetzung einiger Ziele ===
Einige der im Grundschutz++ adressierten Ziele und Neuerungen sind nach wie vor nicht ausreichend konkretisiert. Besonders die Einführung von Leistungskennzahlen und die Priorisierung der Anforderungen (Stufen) werfen noch viele Fragen auf. Die konkrete Bedeutung, Messung und praktische Umsetzung dieser Leistungskennzahlen werden von verschiedenen BSI-Vertretern unterschiedlich dargestellt. Auch die Stufenmodelle werden teils als Priorisierung, als Entwicklungsstufen oder als reiner Umsetzungaufwand der Anforderungen definiert und sind in ihrer praktischen Anwendung noch nicht abschließend geklärt. Das führt zu Unsicherheiten, wie diese neuen Instrumente im einem ISMS umgesetzt und nachgewiesen werden sollen.

=== Geringer Mehrwert im Vergleich zu ISO 27001 ===
Die Anforderungen im Grundschutz++ werden zunehmend an die Formulierungen und Strukturen der ISO 27001 angeglichen. Während der klassische IT-Grundschutz durch seine konkreten, praxisnahen Maßnahmen einen klaren Mehrwert gegenüber der eher abstrakten ISO 27001 bot, verliert er durch die Harmonisierung mit internationalen Standards zunehmend diesen Vorteil. Die Anforderungen werden stärker abstrakt modularisiert formuliert, wodurch der spezifische Bezug zu typischen Umsetzungsbeispielen und die Detailtiefe abnehmen. Für viele Organisationen wird sich daher die Frage stellen, warum sie den immer noch aufwändigeren Weg über den Grundschutz wählen sollten, wenn sie mit ähnlichem oder geringeren Aufwand direkt eine ISO 27001-Zertifizierung anstreben können.

=== Zu ambitionierter Zeitplan ===
Der Grundschutz++ sollte ab dem 1.1.2026 grundsätzlich gültig und anwedbar sein, wobei eine Übergangsphase bis 2029 vorgesehen war. Bisher ist nur ein erster Entwurf veröffentlicht. Angesichts der Vielzahl an noch offenen Fragen, der fehlenden Migrationsstrategie und der Komplexität der Änderungen erscheint der Zeitplan sehr ambitioniert. Ausarbeitung und Dokumentation liegen bisher nur als Entwurf vor. Eine Pilotierung und Einführung 2026 und eine Übergangsphase bis 2029 ist vorgesehen. Die Gefahr besteht, dass größere Organisationen unter Zeitdruck unzureichend vorbereitet in die neue Methodik wechseln und mit variablen Definitionen und Zielen arbeiten müssen, was die Akzeptanz und Qualität der Umsetzung gefährdet.

=== Zunehmende (Sicherheits-)Lücke zwischen Grundschutz und Grundschutz++ ===
Mit der Entscheidung des BSI, den bisherigen IT-Grundschutz (Edition 2023) nicht mehr weiterzuentwickeln und stattdessen auf das neue Grundschutz++-Modell zu setzen, entsteht eine wachsende Lücke in der Informationssicherheit. Diese Übergangsphase bis 2029 ist sicherheitstechnisch kritisch, da sich die Bedrohungslage in der IT nicht an Entwicklungszyklen von Sicherheitsstandards orientiert. Neue Angriffsvektoren, insbesondere durch den zunehmenden Einsatz von KI in der Cyberkriminalität (z.B. KI-gestützte Malware, Deepfakes, automatisierte Phishing-Kampagnen), entstehen kontinuierlich und erfordern zeitnahe, wirksame Gegenmaßnahmen. Der bisherige Grundschutz bildet diese aktuellen Bedrohungen und technologische Entwicklungen jedoch nicht mehr ab, während die spezifischen Module und Maßnahmen im Grundschutz++ noch nicht produktiv verfügbar oder praxistauglich sind.

=== Fehlende Migration vom Grundschutz-Kompendium zu Grundschutz++ ===
Aktuell existiert weder ein konkreter Plan noch ein Konzept für eine (teil-)automatisierte Migration bestehender Sicherheitskonzepte aus dem bisherigen Grundschutz-Kompendium in das neue Grundschutz++-Modell. Die Umstellung auf ein maschinenlesbares JSON/OSCAL-Format und die objektorientierte, prozessorientierte Struktur bedeuten einen fundamentalen Bruch mit bisherigen Strukturen. Die Unterschiede zwischen Grundschutz-Kompendium und Grundschutz++ sind gravierender als beim letzten Wechsel von den Grundschutz-Katalogen zum Kompendium, bei dem bereits alle Ansätze für eine automatisierte Migration weitgehend gescheitert sind. Auch diesmal ist absehbar, dass Organisationen ihre bestehenden Dokumentationen und Umsetzungen weitgehend manuell neu abbilden müssen, was insbesondere für größere Verbünde einen erheblichen Zusatzaufwand bedeutet. Es gibt zwar Ansätze dies mittels KI zu lösen, was aber sicher nicht für jede Organisation praktikabel sein wird.

== Fazit ==
Ein abschließendes Bild zum Grundschutz++ lässt sich aktuell noch nicht zeichnen – viele Details sind noch in der Entwicklung.

Die grundlegende Modernisierung des IT-Grundschutzes durch das Grundschutz++-Projekt ist zwar fachlich und technologisch nachvollziehbar und adressiert viele Schwächen des bisherigen Systems. Die Umsetzung ist jedoch nach jetzigem Entwicklungsstand mit erheblichen Risiken und Unsicherheiten verbunden. Ohne klare Migrationspfade, eindeutige Zuständigkeiten und praxistaugliche Konkretisierungen der neuen Instrumente besteht die Gefahr, dass die Akzeptanz des Grundschutzes sinkt und Organisationen sich vermehrt alternativen Standards wie der ISO 27001 zuwenden. Ein realistischer Zeitplan und ein echter Mehrwert des neuen Standards sind daher essenziell für den Erfolg der Reform.

Der Artikel wird fortlaufend aktualisiert, sobald neue Informationen vom BSI veröffentlicht oder freigegeben werden.
===Ausblick und ToDos aus Anwendersicht===
Stichtag für die Einführung von Grundschutz++ war der '''1.1.2026'''. Das Datum wurde vom BSI in offiziellen Ankündigungen, Präsentationen und Fachveranstaltungen als verbindlicher Startpunkt kommuniziert. Ab diesem Zeitpunkt sollte das neue, digitale und prozessorientierte Regelwerk den bisherigen IT-Grundschutz ablösen. Bisher fehlt es jedoch an vielen Stellen an klaren Definitionen und konkreten Vorgaben zur Methodik.

Auch wenn abzuwarten bleibt, wann praxistaugliche Methoden verfügbar sind und wie lange die Übergangsfristen für die Umstellung sein werden (aktuelle Planung bis 2029). Abzusehen ist jedoch, dass der Aufwand und der Zeitdruck, insbesondere für größere und zertifizierte Verbünde, erheblich sein werden. Auch wenn es aktuell noch keine konkreten Beschreibungen zur Methodik und Modellierung gibt, können und sollten sich Anwender bereits jetzt vorbereiten. Dazu können die folgenden Maßnahmen dienen:
*Laufende Information über den aktuellen Stand (Internetseiten des BSI, Vorträge und Veröffentlichungen).
*Konsolidierung der bestehenden Verbünde (Reduzierung der Komplexität, konsistente Dokumentation der Gruppierung und Modellierung).
**Ein guter Tip ist es, in aktuellen GSC jede Teilanforderung (jedes Modalverb wie MUSS oder SOLLTE) in der Umsetzung einzeln zu dokumentieren, da diese zukünftig eigenständige Anforderungen darstellen und so eine Übernahme leichter werden könnte.
*Kontakt zu Toolherstellern aufnehmen und eine zügige Umsetzung in den verwendeten ISMS-Tools einfordern.
*Frühzeitige Planung der Bereitstellung entsprechender personeller Ressourcen für die Umstellung auf Grundschutz++ ab Mitte 2026.
*Gegebenenfalls frühzeitige Reservierung externer (personeller) Ressourcen zur Unterstützung.
*Es muss eine klare interne Kommunikation über die bevorstehenden, durch die Umstellung bedingten erhöhten Aufwände (Schulungen, neue (Erst-)GSCs und Anpassung der Dokumentation) geben, damit Mitarbeitende und Verantwortliche wissen, was auf sie zukommt.

== Weiterführende Ressourcen ==
*[https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html BSI IT-Grundschutz]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html BSI Leitfaden zur Grundschutz++-Methodik]
*[https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/Grundschutz/1GS_Tag_2025/Aktuelle_Entwicklungen_Ausblick_IT-GS.pdf Aktuelle Entwicklungen und Ausblick zum IT-Grundschutz - 1. Grundschutztag 2025]
*[https://www.youtube.com/watch?v=_AeWJ_Z8S-4 Keynote: Fortentwicklung des IT-Grundschutzes zu IT-Grundschutz++ (verinice.XP 2025)]
*[https://www.youtube.com/watch?v=fBXuhELODGA Vortrag: "Keynote und Vision Grundschutz++" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.youtube.com/watch?v=PxOjkV6oUwU Vortrag "Grundschutz++ Methodik und Einstieg ins BCM" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.bsi.bund.de/dok/it-sa Am Mittwoch, 08.10.2025 werden auf der it-sa die von den Arbeitsgruppen aus der Community erarbeiteten Ergebnisse präsentiert.]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]
*[[Grundschutz++ Migration|Migrationsstrategie für den Umstieg von BSI IT-Grundschutz auf Grundschutz++]]
[[Kategorie:Artikel]]
[[Kategorie:Grundschutz]]
[[Kategorie:++]]

Grundschutz++

2026-04-04T03:05:40Z

Dirk:

[[Datei:Teamwork-2198961.png|alternativtext=Zahnrad|rechts|240x240px]]{{#seo:
|title=Grundschutz++ Digitale Reform & OSCAL-basierte Sicherheit
|keywords=ISMS, IT-Grundschutz++, BSI Reform 2026, JSON-basierte Cybersicherheit, ISO 27001 Harmonisierung, Cloud-Security Module, NIS-2 Richtlinie, ISMS Automatisierung
|description=Das BSI modernisierte den IT-Grundschutz 2026 mit OSCAL/JSON-Regelwerk und Automatisierung.
}}{{SHORTDESC:Grundschutz++: Digitale Reform & OSCAL-basierte Sicherheit}}
''Grundschutz++ ist die 2026 vom BSI eingeführte Weiterentwicklung des IT-Grundschutz-Kompendiums.''<blockquote>
=== Diese Seite ist umgezogen! ===
Da die Planungs- und Entwicklingsphase offiziell beendet ist und Grundschutz++ laut BSI nun gültig ist (auch wenn es praktisch noch nicht anwendbar ist) wurde diese Seite durch eine [[Grundschutz++ Einführung und Aufbau|'''Einführungs- und Anleitungsseite''']] ersetzt.

Die wesentlichen Inhalte dieser Seite wurde dort übernommen und ergänzt.

Diese Seite wird zukünftig nur noch eine Kurzbeschreibung zum Grundschutz++ enthalten.</blockquote>

=== Grund für Weiterentwicklung ===
Kritik an Komplexität, Redundanzen und fehlender Aktualität des alten Kompendiums; Ziel: Digitalisierung, Automatisierung und Anpassung an moderne Bedrohungen (Cloud, KI, IoT) sowie bessere ISO 27001-Harmonisierung.

=== Kernmerkmale ===

* '''OSCAL/JSON-Format''': Maschinenlesbares Regelwerk für automatisierte Prüfungen.
* '''Modulare Praktiken''': Prozessorientierte Struktur statt starrer Bausteine, Reduktion der Anforderungen um 80%.
* '''Priorisierungsstufen''' (0–5): Nach Umsetzungsaufwand (Quick Wins bis komplexe Projekte).
* '''Leistungskennzahlen''': Messbarkeit nach Schutzziele (C/I/A).
* '''Blaupausen''': Vorlagen für branchenspezifische ISMS.
* '''Übergangsphase''': Bis 2029 parallel zum alten Kompendium nutzbar.

=== Kritik am Grundschutz++ ===

* '''Zu viele Beteiligte''': Unklare Zuständigkeiten zwischen BSI-Referaten und Community.
* '''Unklare Ziele''': Leistungskennzahlen und Stufenmodelle nicht konkretisiert.
* '''Wenig Mehrwert vs. ISO 27001''': Verliert Praxisnähe durch Abstraktion.
* '''Ambitionierter Zeitplan''': Entwurfsphase verzögert, seit 2026 gültig aber nicht anwendbar. Übergang bis 2029 riskant.
* '''Sicherheitslücke''': Alter Grundschutz wird nicht weiterentwickelt bleibt aber bis 2029 anwendbar.
* '''Keine Migrationsstrategie''': Manuelle Neuausarbeitung erforderlich.

=== Weiterführende Informationen ===
* [[Grundschutz++ Einführung und Aufbau|'''Grundschutz++ Einführung und Vorgehen''']]
* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html '''BSI IT-Grundschutz''']
* '''[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/sonstiges/Methodik_Grundschutz_PlusPlus.html BSI Leitfaden zur Grundschutz++-Methodik]'''
* [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]
* [https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/Grundschutz/1GS_Tag_2025/Aktuelle_Entwicklungen_Ausblick_IT-GS.pdf Aktuelle Entwicklungen und Ausblick zum IT-Grundschutz - 1. Grundschutztag 2025]
* [https://www.youtube.com/watch?v=_AeWJ_Z8S-4 Keynote: Fortentwicklung des IT-Grundschutzes zu IT-Grundschutz++ (verinice.XP 2025)]
* [https://www.youtube.com/watch?v=fBXuhELODGA Vortrag: "Keynote und Vision Grundschutz++" vom 2. IT-Grundschutztag am 7.7.2025]
* [https://www.youtube.com/watch?v=PxOjkV6oUwU Vortrag "Grundschutz++ Methodik und Einstieg ins BCM" vom 2. IT-Grundschutztag am 7.7.2025]
* [[Grundschutz++ Migration|Migrationsstrategie für den Umstieg von BSI IT-Grundschutz auf Grundschutz++]]

[[Kategorie:Kurzartikel]]
[[Kategorie:Grundschutz]]
[[Kategorie:++]]
__KEIN_INHALTSVERZEICHNIS__

KI Startseite

2026-04-03T11:43:22Z

Dirk: /* Wiki-interne Verweise */

[[Datei:Brain-8764400.png|alternativtext=KI|rechts|160x160px]]
{{#seo:
|title=KI-Einsatz: ISMS-integration, EU AI Act, DSGVO, BSI Grundschutz
|keywords=KI-Einsatz, EU AI Act, ISO 27001, BSI IT-Grundschutz, DSGVO KI, KI-Risikomanagement, Informationssicherheit KI, Datenschutz KI
|description=KI in Unternehmen & Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.}}
{{SHORTDESC:Einführung zu sinnvollen Regelungen für den KI-Einsatz}}''KI-Einsatz in Unternehmen und Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.''

== Einleitung ==
Der Einsatz von Künstlicher Intelligenz (KI) in Unternehmen und Behörden gewinnt rasant an Bedeutung und stellt Informationssicherheits-Managementsysteme (ISMS) vor neue Herausforderungen. KI-Systeme verarbeiten oft personenbezogene Daten, treffen automatisierte Entscheidungen und erfordern eine nahtlose Integration in bestehende Standards wie ISO/IEC 27001 sowie BSI Grundschutz. Der EU AI Act (seit August 2024 rechtskräftig) etabliert einen risikobasierten Ansatz, der mit DSGVO und BDSG kompatibel ist und spezifische Anforderungen an Transparenz, Robustheit und Nachvollziehbarkeit stellt.

Für Behörden gelten zusätzlich öffentlich-rechtliche Bindungen (z.B. Grundrechte Art. 1–3 GG), während Unternehmen wirtschaftliche Risiken wie Vendor Lock-in oder Haftungsstreitigkeiten prüfen müssen. Dieser Artikel fasst rechtliche, datenschutzrechtliche, sicherheitstechnische und organisatorische Belange zusammen und verweist auf vertiefende Inhalte im Wiki sowie externe Quellen.

'''Relevanz für ISMS'''

KI-Einsatz beeinflusst die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) und erfordert [[Zusätzliche Gefährdungen|Ergänzungen]] der verwendeten Risikokataloge wie z.B. den BSI G0-Katalog. Ziel ist eine risikobasierte Implementierung des KI-Einsatzes.

== Rechtlicher Rahmen ==

* '''EU AI Act''': Risikobasierte Klassifikation (verboten, hochrisiko, geringes Risiko, GPAI). Zeitlicher Fahrplan (Verbote ab 2025, Hochrisiko ab 2026/2027). Anforderungen an Dokumentation, Konformität und Bußgelder.
* '''Nationale Regelungen''': DSGVO-Integration (Art. 10 KI-VO für biometrische Daten), BDSG, öffentlich-rechtliche Sonderbindungen (GG Art. 1–3) für Behörden.
* '''Sektorale Vorgaben''': Verwaltungsrecht, hessische/länderspezifische Initiativen für öffentlichen Sektor.

=== EU AI Act ===
Der EU AI Act klassifiziert KI-Systeme in vier Risikostufen:

* '''Unzulässig''' (z. B. Social Scoring, biometrische Echtzeit-Identifikation in öffentlichen Räumen) – Verbot ab Februar 2025.
* '''Hochrisiko''' (z. B. HR, Kreditvergabe, kritische Infrastruktur) – Konformitätsbewertung, Dokumentationspflichten und menschliche Aufsicht ab 2026/2027.
* '''Geringes Risiko''' – Transparenzpflichten (z. B. Chatbots).
* '''GPAI (General Purpose AI)''' – Risikoanalyse und technische Dokumentation für Modelle wie GPT-Varianten.

Bußgelder bis 35 Mio. € oder 7% Umsatz. Verantwortung liegt primär beim Provider, sekundär beim Deployer.

'''Weiterführende Informationen:'''

* [[EU AI Act|Wiki: EU AI Act]]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32024R1689 EU AI Act Volltext]

=== Nationale Regelungen ===

* '''Deutschland''': Ergänzungen durch BDSG (§ 37 Automatisierte Entscheidungen im Einzelfall einschließlich Profiling), KI-Strategie der Bundesregierung (2020/aktualisiert 2025). Behörden müssen öffentlich-rechtliche Prinzipien (Rechtsstaatlichkeit, Verhältnismäßigkeit) wahren.
* '''Länderspezifisch''': Hessische KI-Verordnung, bayrische Orientierungshilfen für öffentliche Verwaltung.
* '''Sektoral''': Finanzsektor (BaFin-Marco), Gesundheitswesen (DiGA-Verordnung).

'''Weiterführende Informationen:'''

* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Kuenstliche-Intelligenz/AIC4/aic4.html Kriterienkatalog für <abbr>KI</abbr>-Cloud-Dienste – <abbr>AIC4</abbr>]
* [https://www.gesetze-im-internet.de/bdsg_2018/__37.html BDSG: §37 Automatisierte Entscheidungen im Einzelfall einschließlich Profiling]

=== Übergangsregelungen und Neuklassifizierung ===
KI-Systeme müssen bei wesentlichen Änderungen neu klassifiziert werden. Bestehende Systeme bis 2027.

== Datenschutzrechtliche Aspekte ==

=== DSGVO-Konformität ===
KI-Trainingsdaten unterliegen Art. 5 DSGVO (Rechtsmäßigkeit, Zweckbindung). Bei biometrischen Daten: Art. 10 KI-VO (Verbot biometrische Kategorisierung). Datenschutz-Folgenabschätzung (DSFA, Art. 35) obligatorisch für Hochrisiko-Anwendungen.

'''Kernpflichten'''

* '''Trainingsdaten''': Bereinigung sensibler Daten, Pseudonymisierung, Löschung nach Zweck (Art. 17).
* '''Outputs''': Transparenz bei automatisierter Entscheidungsfindung (Art. 22), Recht auf Erklärung.
* '''AVV (Auftragsverarbeitung)''': Cloud-KI-Provider als Auftragsverarbeiter prüfen.

=== Orientierungshilfen ===

* '''Datenschutzkonferenz (DSK)''': Leitfaden „Künstliche Intelligenz und Datenschutz“ – Checkliste für Datensparsamkeit und Rechenschaftspflicht.
* '''BayLDA/LfDI''': Praktische Hinweise zu Shadow-KI und ChatGPT-Nutzung in Behörden.

=== Betroffenenrechte und Transparenz ===
Benutzende müssen über KI-Einsatz informiert werden (Art. 13/14). Erweiterte Informationspflichten bei GPAI: Modellkarte offenlegen. Bias-Tests dokumentieren, um Diskriminierungsverbot (Art. 21 GG) zu wahren.

'''Praktische Umsetzung'''
{| class="wikitable"
!Aspekt
!Maßnahme
!Rechtsgrundlage
|-
|DSFA
|Vor KI-Einsatz durchführen
|Art. 35 DSGVO
|-
|Rechteauskunft
|KI-spezifische Vorlage
|Art. 15 DSGVO
|-
|Löschung
|Trainingsdaten entfernen
|Art. 17 DSGVO
|}
'''Weiterführende Informationen:'''

* [https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf DSK: Orientierungshilfe zu datenschutzrechtlichen Besonderheiten generativer KI-Systeme mit RAG-Methode]
* [https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf DSK: Orientierungshilfe zu empfohlenen technischen und organisatorischen Maßnahmen bei der Entwicklung und beim Betrieb von KI-Systemen]
* [[KI Datenschutz|Wiki: Datenschutz in KI-Anwendungen.]]

== Sicherheitsaspekte (ISMS-Integration) ==
KI-Einsatz erfordert eine Erweiterung des ISMS um spezifische Gefährdungen, die die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) bedrohen und über den BSI IT-Grundschutz G0-Katalog hinausgehen. Nach BSI Standard 200-3 müssen diese in der Risikoanalyse bewertet und mit Maßnahmen aus ISO 27001 Anhang A (z. B. A.8.25 für sichere Entwicklung) kontrolliert werden.

=== Gefährdungskatalog-Ergänzungen ===
KI-spezifische Risiken wie folgt klassifiziert (CIA-Analyse):

* '''Prompt Injections''': Manipulation von Eingaben zu Large Language Models (hoch I/C).
* '''Data Poisoning''': Vergiftung von Trainingsdaten (hoch I, mittel A).
* '''Modelllecks''': Training Data Leakage oder IP-Exfiltration (hoch C).
* '''Unkontrollierte Nutzung von Schatten-KI''': Unkontrollierte Nutzung privater Tools (mittel C/I).
* '''Black-Box-Effekte''': Mangelnde Nachvollziehbarkeit (hoch I/A).

'''Integration in BSI-Module'''
{| class="wikitable"
!Gefährdung
!BSI G0-Modul
!Ergänzungsmaßnahme
|-
|Data Poisoning
|SYS.1.2 Datenintegrität
|Daten-Sanitization, Validierung
|-
|Modelllecks
|NET.4.1 Zugriffssteuerung
|API-Rate-Limiting, Differential Privacy
|-
|Shadow-KI
|ORG.2.1 Sicherheitsrichtlinien
|KI-Nutzungsrichtlinie (ISO A.5.1)
|}

=== ISMS-Maßnahmen und Standards ===
* '''BSI KI-Kriterienkatalog ([[RiLi-KI-Einsatz|2025]])''': Sicherheitsniveaus (Low/Medium/High) für generative KI, mit Tests auf Jailbreaks und Bias.
* '''ISO 27001 Anhang A''': A.14.2.7 Sichere Entwicklung von KI, A.12.6 Vulnerability-Management für Modelle.
* '''Risikobewertung''': Erweiterte Gefährdungsanalyse nach BSI 200-3, inklusive Supply-Chain-Risiken bei Cloud-KI-Providern.

'''Weiterführende Informationen:'''

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KI/Kriterienkatalog_KI-Modelle_Bundesverwaltung.html BSI KI-Kriterienkatalog 2025.]
* [[Zusätzliche Gefährdungen|Wiki: Zusätzliche Gefährdungen (ergänzt und spezifische KI-Gefährdungen)]]
* [[RiLi-KI-Einsatz|Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)]]
* [[LF-KI-Chatbots|Leitfaden für Mitarbeitende zur Nutzung von KI-Systemen.]]

== Technische Aspekte ==
Technische Umsetzung von KI muss Robustheit, Nachvollziehbarkeit und Datensicherheit gewährleisten, um EU AI Act-Anforderungen (z. B. Art. 15 für Hochrisiko) und ISMS-Ziele zu erfüllen. Der Fokus liegt auf dem gesamten KI-Lebenszyklus.

=== Implementierungsprinzipien ===

* '''Daten-Governance''': Saubere Trainingsdaten (Preprocessing, Anonymisierung), RAG (Retrieval-Augmented Generation) statt reinem Fine-Tuning zur Vermeidung von Halluzinationen.
* '''Modellsicherheit''': Hardening-Techniken wie Adversarial Training, Modellkardinalität (Input/Output-Beschränkungen).
* '''Nachvollziehbarkeit (XAI)''': SHAP für globale Feature-Importance, LIME für lokale Erklärungen einzelner Vorhersagen – essenziell für Art. 22 DSGVO.

=== Lebenszyklus-Management ===
'''KI-System-Phasen und Sicherheitskontrollen'''
{| class="wikitable"
!Phase
!Technische Maßnahmen
!ISMS-Verknüpfung
|-
|Auswahl/Training
|Datenvalidierung, Secure MPC
|A.8.25 Entwicklung
|-
|Deployment
|Sandboxing, Human-in-the-Loop
|A.12.4 Monitoring
|-
|Betrieb
|Continuous Model Monitoring (Drift/Bias)
|A.12.6 Vulnerabilities
|-
|Decommissioning
|Modelllöschung, Audit-Logs
|A.18.1 Compliance
|}

=== Hochrisiko-Anwendungen ===

* '''Sektoren''': HR (Bias-Prüfung), Gesundheitswesen (FDA/DiGA-konform), kritische Infrastruktur (real-time Robustheit).
* '''Technische Standards''': ONNX für Modell-Portabilität, TensorFlow Privacy für Federated Learning.

'''Praktische Umsetzung'''

* '''Tools''': MLflow für Lifecycle-Tracking, Adversarial Robustness Toolbox (ART) für Angriffstests.
* '''Cloud-KI''': AWS SageMaker oder Azure ML mit integrierten Security-Features prüfen (AVV-pflichtig).

'''Weiterführende Informationen:'''

* [https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R1689#art_11 EU AI Act Artikel 11 - Technische Dokumentation]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R1689#anx_IV EU AI Act Anhang IV - Technische Dokumentation]
* [https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/Leitfaden_KI-Systeme_230124.html BSI Secure AI Guidelines.]
* [[KI-Register|Wiki: KI-Register]]
* [[KI Cybersicherheit|KI als Fluch und Segen in der Cybersicherheit.]]

== Governance und Organisation ==
Eine effektive KI-Governance stellt sicher, dass KI-Einsatz mit ISMS-Zielen (ISO 27001, BSI Grundschutz) übereinstimmt und EU AI Act-Anforderungen erfüllt. Sie umfasst organisatorische Strukturen, Prozesse und Verantwortlichkeiten, um Risiken wie Shadow-KI oder Bias zu minimieren. Die Geschäftsleitung trägt gemäß ISO 27001 Abschnitt 5.1 die oberste Verantwortung und muss KI-spezifische Richtlinien (A.5.1) etablieren.

=== KI-Governancestruktur ===

* '''KI-Steuerungsgremium''': Interdisziplinäres Gremium (IT-Sicherheit, Datenschutzbeauftragte, Rechtsabteilung, Fachabteilungen) für Risikobewertungen, Modellfreigaben und Audits. Regelmäßige Meetings (vierteljährlich) zur Überprüfung von KI-Projekten.

* '''Rollen und Verantwortlichkeiten''':<br>
{| class="wikitable"
!Rolle
!Aufgaben
!Rechtsgrundlage
|-
|KI-Provider (extern)
|Technische Dokumentation, Konformitätserklärung
|EU AI Act Art. 13
|-
|KI-Deployer (intern)
|Risikoanalyse, menschliche Aufsicht
|EU AI Act Art. 29
|-
|Datenschutzbeauftragte
|DSFA, Betroffenenrechte
|DSGVO Art. 39
|-
|ISMS-Leitung
|Integration in Risikomanagement
|ISO 27001 A.5.1
|}

* '''KI-Nutzungsrichtlinie''': Verbot privater KI-Tools (Shadow-KI), Pflicht zu genehmigten Modellen, Sanktionen bei Verstößen. Schulungspflicht für Mitarbeitende (KI-Literacy).

=== Prozesse und Workflows ===

* '''Risikobewertungsvorlage''': Vorlage für neue KI-Projekte mit CIA-Analyse, EU AI Act-Risikostufe und DSFA-Trigger. Workflow: Antrag → Gremium → Freigabe → Monitoring.
* '''Audit und Reporting''': Jährliche KI-Inventar (alle Systeme auflisten), Incident-Reporting für Bias-Vorfälle oder Modell-Drift. Integration in ISO 27001 Management Review (Abschnitt 9.3).
* '''Schulungen''': Obligatorische Einstiegsschulung zu KI-Risiken (~2h), vertiefte für Entwickler (XAI, Secure Coding). Nachweis via LMS.

=== Besonderheiten für Behörden ===

* '''Grundrechtsschutz''': Zusätzliche Prüfung auf Verhältnismäßigkeit (GG Art. 1–3), Transparenz gegenüber Bürger:innen. Beliehene Unternehmen (z. B. Zeugnisstellen) fallen unter öffentlich-rechtliche Standards.
* '''Öffentliche Unternehmen''': Anpassung an Verwaltungsrecht (VwVfG § 35), Archivierungspflicht für KI-Entscheidungen.

'''Praktische Umsetzung'''

* '''Checkliste für KI-Projekte''':
*# Risikostufe bestimmen,
*# Provider prüfen,
*# DSFA durchführen,
*# Technische Dokumentation anlegen,
*# Monitoring einrichten.
* '''Vorlage''': KI-Risikobewertungstabelle (Excel) mit Spalten für Gefährdung, Wahrscheinlichkeit, Schaden, Maßnahmen.

'''Weiterführende Informationen:'''

* Wiki: ISMS-Organisation
* ISO 27001:2022 Abschnitt 5 (Führung).

== Weiterführende Quellen ==

=== Primärquellen (Gesetze und Verordnungen) ===

* '''EU AI Act''': Volltext – Offizielle Übersetzung, Anhang mit Hochrisiko-Listen.
* '''DSGVO''': Art. 22, 35 – Automatisierte Entscheidungen, DSFA.
* '''BDSG''': § 22 – Automatisierte Entscheidungen im öffentlichen Recht.

=== Behörden und Standardisierungsgremien ===

* '''BSI''':
** KI-Kriterienkatalog 2025 – Testszenarien für generative KI.
** IT-Grundschutz Compendium – G0-Module.
* '''Datenschutzkonferenz (DSK)''': Leitfaden KI und Datenschutz – Praktische Checkliste.
* '''BayLDA''': KI & Datenschutz – Orientierung für Behörden.

=== Branchenverbände und Ratgeber ===

* '''IHK München''': Datenschutz & KI – Praktische Hinweise für KMU.
* '''Bitkom''': KI-Guide für Unternehmen – Best Practices.
* '''BaFin''': Marco für KI im Finanzsektor.

=== Technische Ressourcen ===

* '''XAI-Tools''': SHAP-Dokumentation, LIME – Open Source für Erklärbarkeit.
* '''Secure AI Frameworks''': Adversarial Robustness Toolbox – Tests auf Angriffe.

=== Wiki-interne Verweise ===

* [[EU AI Act]]
* [[KI Cybersicherheit]]
* [[KI Datenschutz]]
* [[KI-Nutzung]]
* [[KI-Register]]
* [[LF-KI-Sicherheit]]
* [[LF-KI-Chatbots]]
* [[RiLi-KI-Einsatz]]
* [[Zusätzliche Gefährdungen]]

[[Kategorie:Artikel]]
[[Kategorie:KI]]

KI Startseite

2026-04-03T11:38:38Z

Dirk:

[[Datei:Brain-8764400.png|alternativtext=KI|rechts|160x160px]]
{{#seo:
|title=KI-Einsatz: ISMS-integration, EU AI Act, DSGVO, BSI Grundschutz
|keywords=KI-Einsatz, EU AI Act, ISO 27001, BSI IT-Grundschutz, DSGVO KI, KI-Risikomanagement, Informationssicherheit KI, Datenschutz KI
|description=KI in Unternehmen & Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.}}
{{SHORTDESC:Einführung zu sinnvollen Regelungen für den KI-Einsatz}}''KI-Einsatz in Unternehmen und Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.''

== Einleitung ==
Der Einsatz von Künstlicher Intelligenz (KI) in Unternehmen und Behörden gewinnt rasant an Bedeutung und stellt Informationssicherheits-Managementsysteme (ISMS) vor neue Herausforderungen. KI-Systeme verarbeiten oft personenbezogene Daten, treffen automatisierte Entscheidungen und erfordern eine nahtlose Integration in bestehende Standards wie ISO/IEC 27001 sowie BSI Grundschutz. Der EU AI Act (seit August 2024 rechtskräftig) etabliert einen risikobasierten Ansatz, der mit DSGVO und BDSG kompatibel ist und spezifische Anforderungen an Transparenz, Robustheit und Nachvollziehbarkeit stellt.

Für Behörden gelten zusätzlich öffentlich-rechtliche Bindungen (z.B. Grundrechte Art. 1–3 GG), während Unternehmen wirtschaftliche Risiken wie Vendor Lock-in oder Haftungsstreitigkeiten prüfen müssen. Dieser Artikel fasst rechtliche, datenschutzrechtliche, sicherheitstechnische und organisatorische Belange zusammen und verweist auf vertiefende Inhalte im Wiki sowie externe Quellen.

'''Relevanz für ISMS'''

KI-Einsatz beeinflusst die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) und erfordert [[Zusätzliche Gefährdungen|Ergänzungen]] der verwendeten Risikokataloge wie z.B. den BSI G0-Katalog. Ziel ist eine risikobasierte Implementierung des KI-Einsatzes.

== Rechtlicher Rahmen ==

* '''EU AI Act''': Risikobasierte Klassifikation (verboten, hochrisiko, geringes Risiko, GPAI). Zeitlicher Fahrplan (Verbote ab 2025, Hochrisiko ab 2026/2027). Anforderungen an Dokumentation, Konformität und Bußgelder.
* '''Nationale Regelungen''': DSGVO-Integration (Art. 10 KI-VO für biometrische Daten), BDSG, öffentlich-rechtliche Sonderbindungen (GG Art. 1–3) für Behörden.
* '''Sektorale Vorgaben''': Verwaltungsrecht, hessische/länderspezifische Initiativen für öffentlichen Sektor.

=== EU AI Act ===
Der EU AI Act klassifiziert KI-Systeme in vier Risikostufen:

* '''Unzulässig''' (z. B. Social Scoring, biometrische Echtzeit-Identifikation in öffentlichen Räumen) – Verbot ab Februar 2025.
* '''Hochrisiko''' (z. B. HR, Kreditvergabe, kritische Infrastruktur) – Konformitätsbewertung, Dokumentationspflichten und menschliche Aufsicht ab 2026/2027.
* '''Geringes Risiko''' – Transparenzpflichten (z. B. Chatbots).
* '''GPAI (General Purpose AI)''' – Risikoanalyse und technische Dokumentation für Modelle wie GPT-Varianten.

Bußgelder bis 35 Mio. € oder 7% Umsatz. Verantwortung liegt primär beim Provider, sekundär beim Deployer.

'''Weiterführende Informationen:'''

* [[EU AI Act|Wiki: EU AI Act]]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32024R1689 EU AI Act Volltext]

=== Nationale Regelungen ===

* '''Deutschland''': Ergänzungen durch BDSG (§ 37 Automatisierte Entscheidungen im Einzelfall einschließlich Profiling), KI-Strategie der Bundesregierung (2020/aktualisiert 2025). Behörden müssen öffentlich-rechtliche Prinzipien (Rechtsstaatlichkeit, Verhältnismäßigkeit) wahren.
* '''Länderspezifisch''': Hessische KI-Verordnung, bayrische Orientierungshilfen für öffentliche Verwaltung.
* '''Sektoral''': Finanzsektor (BaFin-Marco), Gesundheitswesen (DiGA-Verordnung).

'''Weiterführende Informationen:'''

* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Kuenstliche-Intelligenz/AIC4/aic4.html Kriterienkatalog für <abbr>KI</abbr>-Cloud-Dienste – <abbr>AIC4</abbr>]
* [https://www.gesetze-im-internet.de/bdsg_2018/__37.html BDSG: §37 Automatisierte Entscheidungen im Einzelfall einschließlich Profiling]

=== Übergangsregelungen und Neuklassifizierung ===
KI-Systeme müssen bei wesentlichen Änderungen neu klassifiziert werden. Bestehende Systeme bis 2027.

== Datenschutzrechtliche Aspekte ==

=== DSGVO-Konformität ===
KI-Trainingsdaten unterliegen Art. 5 DSGVO (Rechtsmäßigkeit, Zweckbindung). Bei biometrischen Daten: Art. 10 KI-VO (Verbot biometrische Kategorisierung). Datenschutz-Folgenabschätzung (DSFA, Art. 35) obligatorisch für Hochrisiko-Anwendungen.

'''Kernpflichten'''

* '''Trainingsdaten''': Bereinigung sensibler Daten, Pseudonymisierung, Löschung nach Zweck (Art. 17).
* '''Outputs''': Transparenz bei automatisierter Entscheidungsfindung (Art. 22), Recht auf Erklärung.
* '''AVV (Auftragsverarbeitung)''': Cloud-KI-Provider als Auftragsverarbeiter prüfen.

=== Orientierungshilfen ===

* '''Datenschutzkonferenz (DSK)''': Leitfaden „Künstliche Intelligenz und Datenschutz“ – Checkliste für Datensparsamkeit und Rechenschaftspflicht.
* '''BayLDA/LfDI''': Praktische Hinweise zu Shadow-KI und ChatGPT-Nutzung in Behörden.

=== Betroffenenrechte und Transparenz ===
Benutzende müssen über KI-Einsatz informiert werden (Art. 13/14). Erweiterte Informationspflichten bei GPAI: Modellkarte offenlegen. Bias-Tests dokumentieren, um Diskriminierungsverbot (Art. 21 GG) zu wahren.

'''Praktische Umsetzung'''
{| class="wikitable"
!Aspekt
!Maßnahme
!Rechtsgrundlage
|-
|DSFA
|Vor KI-Einsatz durchführen
|Art. 35 DSGVO
|-
|Rechteauskunft
|KI-spezifische Vorlage
|Art. 15 DSGVO
|-
|Löschung
|Trainingsdaten entfernen
|Art. 17 DSGVO
|}
'''Weiterführende Informationen:'''

* [https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf DSK: Orientierungshilfe zu datenschutzrechtlichen Besonderheiten generativer KI-Systeme mit RAG-Methode]
* [https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf DSK: Orientierungshilfe zu empfohlenen technischen und organisatorischen Maßnahmen bei der Entwicklung und beim Betrieb von KI-Systemen]
* [[KI Datenschutz|Wiki: Datenschutz in KI-Anwendungen.]]

== Sicherheitsaspekte (ISMS-Integration) ==
KI-Einsatz erfordert eine Erweiterung des ISMS um spezifische Gefährdungen, die die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) bedrohen und über den BSI IT-Grundschutz G0-Katalog hinausgehen. Nach BSI Standard 200-3 müssen diese in der Risikoanalyse bewertet und mit Maßnahmen aus ISO 27001 Anhang A (z. B. A.8.25 für sichere Entwicklung) kontrolliert werden.

=== Gefährdungskatalog-Ergänzungen ===
KI-spezifische Risiken wie folgt klassifiziert (CIA-Analyse):

* '''Prompt Injections''': Manipulation von Eingaben zu Large Language Models (hoch I/C).
* '''Data Poisoning''': Vergiftung von Trainingsdaten (hoch I, mittel A).
* '''Modelllecks''': Training Data Leakage oder IP-Exfiltration (hoch C).
* '''Unkontrollierte Nutzung von Schatten-KI''': Unkontrollierte Nutzung privater Tools (mittel C/I).
* '''Black-Box-Effekte''': Mangelnde Nachvollziehbarkeit (hoch I/A).

'''Integration in BSI-Module'''
{| class="wikitable"
!Gefährdung
!BSI G0-Modul
!Ergänzungsmaßnahme
|-
|Data Poisoning
|SYS.1.2 Datenintegrität
|Daten-Sanitization, Validierung
|-
|Modelllecks
|NET.4.1 Zugriffssteuerung
|API-Rate-Limiting, Differential Privacy
|-
|Shadow-KI
|ORG.2.1 Sicherheitsrichtlinien
|KI-Nutzungsrichtlinie (ISO A.5.1)
|}

=== ISMS-Maßnahmen und Standards ===
* '''BSI KI-Kriterienkatalog ([[RiLi-KI-Einsatz|2025]])''': Sicherheitsniveaus (Low/Medium/High) für generative KI, mit Tests auf Jailbreaks und Bias.
* '''ISO 27001 Anhang A''': A.14.2.7 Sichere Entwicklung von KI, A.12.6 Vulnerability-Management für Modelle.
* '''Risikobewertung''': Erweiterte Gefährdungsanalyse nach BSI 200-3, inklusive Supply-Chain-Risiken bei Cloud-KI-Providern.

'''Weiterführende Informationen:'''

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KI/Kriterienkatalog_KI-Modelle_Bundesverwaltung.html BSI KI-Kriterienkatalog 2025.]
* [[Zusätzliche Gefährdungen|Wiki: Zusätzliche Gefährdungen (ergänzt und spezifische KI-Gefährdungen)]]
* [[RiLi-KI-Einsatz|Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)]]
* [[LF-KI-Chatbots|Leitfaden für Mitarbeitende zur Nutzung von KI-Systemen.]]

== Technische Aspekte ==
Technische Umsetzung von KI muss Robustheit, Nachvollziehbarkeit und Datensicherheit gewährleisten, um EU AI Act-Anforderungen (z. B. Art. 15 für Hochrisiko) und ISMS-Ziele zu erfüllen. Der Fokus liegt auf dem gesamten KI-Lebenszyklus.

=== Implementierungsprinzipien ===

* '''Daten-Governance''': Saubere Trainingsdaten (Preprocessing, Anonymisierung), RAG (Retrieval-Augmented Generation) statt reinem Fine-Tuning zur Vermeidung von Halluzinationen.
* '''Modellsicherheit''': Hardening-Techniken wie Adversarial Training, Modellkardinalität (Input/Output-Beschränkungen).
* '''Nachvollziehbarkeit (XAI)''': SHAP für globale Feature-Importance, LIME für lokale Erklärungen einzelner Vorhersagen – essenziell für Art. 22 DSGVO.

=== Lebenszyklus-Management ===
'''KI-System-Phasen und Sicherheitskontrollen'''
{| class="wikitable"
!Phase
!Technische Maßnahmen
!ISMS-Verknüpfung
|-
|Auswahl/Training
|Datenvalidierung, Secure MPC
|A.8.25 Entwicklung
|-
|Deployment
|Sandboxing, Human-in-the-Loop
|A.12.4 Monitoring
|-
|Betrieb
|Continuous Model Monitoring (Drift/Bias)
|A.12.6 Vulnerabilities
|-
|Decommissioning
|Modelllöschung, Audit-Logs
|A.18.1 Compliance
|}

=== Hochrisiko-Anwendungen ===

* '''Sektoren''': HR (Bias-Prüfung), Gesundheitswesen (FDA/DiGA-konform), kritische Infrastruktur (real-time Robustheit).
* '''Technische Standards''': ONNX für Modell-Portabilität, TensorFlow Privacy für Federated Learning.

'''Praktische Umsetzung'''

* '''Tools''': MLflow für Lifecycle-Tracking, Adversarial Robustness Toolbox (ART) für Angriffstests.
* '''Cloud-KI''': AWS SageMaker oder Azure ML mit integrierten Security-Features prüfen (AVV-pflichtig).

'''Weiterführende Informationen:'''

* [https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R1689#art_11 EU AI Act Artikel 11 - Technische Dokumentation]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R1689#anx_IV EU AI Act Anhang IV - Technische Dokumentation]
* [https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/Leitfaden_KI-Systeme_230124.html BSI Secure AI Guidelines.]
* [[KI-Register|Wiki: KI-Register]]
* [[KI Cybersicherheit|KI als Fluch und Segen in der Cybersicherheit.]]

== Governance und Organisation ==
Eine effektive KI-Governance stellt sicher, dass KI-Einsatz mit ISMS-Zielen (ISO 27001, BSI Grundschutz) übereinstimmt und EU AI Act-Anforderungen erfüllt. Sie umfasst organisatorische Strukturen, Prozesse und Verantwortlichkeiten, um Risiken wie Shadow-KI oder Bias zu minimieren. Die Geschäftsleitung trägt gemäß ISO 27001 Abschnitt 5.1 die oberste Verantwortung und muss KI-spezifische Richtlinien (A.5.1) etablieren.

=== KI-Governancestruktur ===

* '''KI-Steuerungsgremium''': Interdisziplinäres Gremium (IT-Sicherheit, Datenschutzbeauftragte, Rechtsabteilung, Fachabteilungen) für Risikobewertungen, Modellfreigaben und Audits. Regelmäßige Meetings (vierteljährlich) zur Überprüfung von KI-Projekten.

* '''Rollen und Verantwortlichkeiten''':<br>
{| class="wikitable"
!Rolle
!Aufgaben
!Rechtsgrundlage
|-
|KI-Provider (extern)
|Technische Dokumentation, Konformitätserklärung
|EU AI Act Art. 13
|-
|KI-Deployer (intern)
|Risikoanalyse, menschliche Aufsicht
|EU AI Act Art. 29
|-
|Datenschutzbeauftragte
|DSFA, Betroffenenrechte
|DSGVO Art. 39
|-
|ISMS-Leitung
|Integration in Risikomanagement
|ISO 27001 A.5.1
|}

* '''KI-Nutzungsrichtlinie''': Verbot privater KI-Tools (Shadow-KI), Pflicht zu genehmigten Modellen, Sanktionen bei Verstößen. Schulungspflicht für Mitarbeitende (KI-Literacy).

=== Prozesse und Workflows ===

* '''Risikobewertungsvorlage''': Vorlage für neue KI-Projekte mit CIA-Analyse, EU AI Act-Risikostufe und DSFA-Trigger. Workflow: Antrag → Gremium → Freigabe → Monitoring.
* '''Audit und Reporting''': Jährliche KI-Inventar (alle Systeme auflisten), Incident-Reporting für Bias-Vorfälle oder Modell-Drift. Integration in ISO 27001 Management Review (Abschnitt 9.3).
* '''Schulungen''': Obligatorische Einstiegsschulung zu KI-Risiken (~2h), vertiefte für Entwickler (XAI, Secure Coding). Nachweis via LMS.

=== Besonderheiten für Behörden ===

* '''Grundrechtsschutz''': Zusätzliche Prüfung auf Verhältnismäßigkeit (GG Art. 1–3), Transparenz gegenüber Bürger:innen. Beliehene Unternehmen (z. B. Zeugnisstellen) fallen unter öffentlich-rechtliche Standards.
* '''Öffentliche Unternehmen''': Anpassung an Verwaltungsrecht (VwVfG § 35), Archivierungspflicht für KI-Entscheidungen.

'''Praktische Umsetzung'''

* '''Checkliste für KI-Projekte''':
*# Risikostufe bestimmen,
*# Provider prüfen,
*# DSFA durchführen,
*# Technische Dokumentation anlegen,
*# Monitoring einrichten.
* '''Vorlage''': KI-Risikobewertungstabelle (Excel) mit Spalten für Gefährdung, Wahrscheinlichkeit, Schaden, Maßnahmen.

'''Weiterführende Informationen:'''

* Wiki: ISMS-Organisation
* ISO 27001:2022 Abschnitt 5 (Führung).

== Weiterführende Quellen ==

=== Primärquellen (Gesetze und Verordnungen) ===

* '''EU AI Act''': Volltext – Offizielle Übersetzung, Anhang mit Hochrisiko-Listen.
* '''DSGVO''': Art. 22, 35 – Automatisierte Entscheidungen, DSFA.
* '''BDSG''': § 22 – Automatisierte Entscheidungen im öffentlichen Recht.

=== Behörden und Standardisierungsgremien ===

* '''BSI''':
** KI-Kriterienkatalog 2025 – Testszenarien für generative KI.
** IT-Grundschutz Compendium – G0-Module.
* '''Datenschutzkonferenz (DSK)''': Leitfaden KI und Datenschutz – Praktische Checkliste.
* '''BayLDA''': KI & Datenschutz – Orientierung für Behörden.

=== Branchenverbände und Ratgeber ===

* '''IHK München''': Datenschutz & KI – Praktische Hinweise für KMU.
* '''Bitkom''': KI-Guide für Unternehmen – Best Practices.
* '''BaFin''': Marco für KI im Finanzsektor.

=== Technische Ressourcen ===

* '''XAI-Tools''': SHAP-Dokumentation, LIME – Open Source für Erklärbarkeit.
* '''Secure AI Frameworks''': Adversarial Robustness Toolbox – Tests auf Angriffe.

=== Wiki-interne Verweise ===

* [[EU AI Act]]
* [[KI Cybersicherheit]]
* [[KI Datenschutz]]
* [[KI-Nutzung]]
* [[KI-Register]]
* [[LF-KI-Chatbots]]
* [[RiLi-KI-Einsatz]]
* [[Zusätzliche Gefährdungen]]

[[Kategorie:Artikel]]
[[Kategorie:KI]]

KI-Nutzung

2026-04-03T11:37:47Z

Dirk: /* Weitere Infomationen */

{{#seo:
|title=Chancen und Risiken von KI im Unternehmen: Ein umfassender Überblick
|keywords=ISMS, KI im Unternehmen, Chancen und Risiken, Künstliche Intelligenz, IT-Sicherheit, Datenschutz, EU-KI-Verordnung, KI-Einsatzszenarien
|description=Chancen und Risiken von KI in Unternehmen und Behörden. Von Effizienzsteigerung bis Datenschutz: Ein umfassender Leitfaden zu rechtlichen, technischen und ethischen Aspekten.
}}{{SHORTDESC:Chancen und Risiken von KI in Unternehmen und Behörden.}}
[[Datei:Brain-8764400.png|alternativtext=KI|rechts|160x160px]]
''Chancen und Risiken von KI in Unternehmen und Behörden. Von Effizienzsteigerung bis Datenschutz: Ein umfassender Leitfaden zu rechtlichen, technischen und ethischen Aspekten.''

== Einleitung ==

Künstliche Intelligenz (KI) hat sich in den letzten Jahren zu einer Schlüsseltechnologie entwickelt, die nahezu alle Bereiche der Wirtschaft und Verwaltung beeinflusst. Dieser Artikel beleuchtet die vielfältigen Aspekte des KI-Einsatzes in Unternehmen und Behörden, von technischen Möglichkeiten über rechtliche Rahmenbedingungen bis hin zu ethischen Überlegungen.

== Was ist KI? ==
Künstliche Intelligenz (KI) bezeichnet Computersysteme, die menschenähnliche kognitive Fähigkeiten wie Lernen, Schlussfolgern und Problemlösen '''nachahmen'''. Inzwischen hat sich KI zu einer Schlüsseltechnologie entwickelt, die in vielen Bereichen von Wirtschaft und Gesellschaft zum Einsatz kommt.

Allerdings haben alle aktuellen Systeme auch klare Grenzen:

# Sie verfügen nicht über echtes Verständnis oder Bewusstsein.
# Ihre Fähigkeiten sind auf spezifische Bereiche beschränkt, für die sie trainiert wurden.
# Sie können keine eigenständigen ethischen Entscheidungen treffen.

=== Kategorien von KI ===
Die Definition von Künstlicher Intelligenz umfasst ein breites Spektrum an Technologien und Konzepten. Während schwache KI bereits weit verbreitet ist und spezialisierte Aufgaben löst, bleibt starke KI ein theoretisches Ziel. Maschinelles Lernen und Deep Learning bilden die Grundlage moderner KI-Anwendungen und treiben Innovationen in vielen Bereichen voran.

==== Schwache KI (Weak AI) ====
'''Definition''': Schwache KI, auch bekannt als "spezialisierte KI", ist darauf ausgelegt, spezifische Aufgaben auszuführen. Sie simuliert intelligentes Verhalten, hat jedoch kein eigenes Bewusstsein oder Verständnis.

'''Beispiele''':

* Sprachassistenten wie Siri oder Alexa
* Empfehlungsalgorithmen bei Netflix oder Amazon
* Bilderkennungssysteme in der Medizin

'''Merkmale''':

* Fokus auf eng definierte Anwendungen
* Keine Fähigkeit zur Generalisierung über den programmierten Bereich hinaus

==== Starke KI (Strong AI) ====
'''Definition''': Starke KI bezeichnet hypothetische Systeme, die menschenähnliche allgemeine Intelligenz besitzen. Sie können nicht nur spezifische Aufgaben lösen, sondern auch eigenständig lernen und Probleme in unterschiedlichen Kontexten verstehen.

'''Merkmale''':

* Allgemeine Problemlösungsfähigkeit
* Eigenes Bewusstsein und Verständnis
* Fähigkeit zur kreativen Entscheidungsfindung

'''Status''': Starke KI existiert derzeit nicht; sie bleibt ein Forschungsziel und eine philosophische Debatte. Konzepte wie "Künstliche Allgemeine Intelligenz" (Artificial General Intelligence, AGI) beziehen sich auf diese Vision.

=== Konzepte innerhalb der KI ===

==== Maschinelles Lernen (ML) ====
'''Definition''': Maschinelles Lernen ist ein Teilgebiet der KI, das Systeme entwickelt, die aus Daten lernen und ihre Leistung ohne explizite Programmierung verbessern können.

'''Ansätze''':

* '''Überwachtes Lernen (Supervised Learning)''': Modelle werden mit gekennzeichneten Daten trainiert.
** Beispiel: Vorhersage von Immobilienpreisen basierend auf historischen Daten.
* '''Unüberwachtes Lernen (Unsupervised Learning)''': Modelle identifizieren Muster in unmarkierten Daten.
** Beispiel: Clustering von Kundengruppen für Marketingstrategien.
* '''Bestärkendes Lernen (Reinforcement Learning)''': Systeme lernen durch Belohnung und Bestrafung in einer Umgebung.
** Beispiel: Training eines Roboters zur Navigation durch Versuch und Irrtum.

==== Deep Learning ====
'''Definition''': Deep Learning ist eine Unterkategorie des Maschinellen Lernens, die künstliche neuronale Netze verwendet, um komplexe Muster in großen Datenmengen zu erkennen.

'''Anwendungen''':

* Bildverarbeitung (z. B. Gesichtserkennung)
* Sprachverarbeitung (z. B. Übersetzungsdienste)
* Autonome Fahrzeuge

==== Natural Language Processing (NLP) ====
'''Definition''': NLP befasst sich mit der Verarbeitung und Analyse natürlicher Sprache durch Maschinen.

'''Beispiele''':

* Chatbots wie ChatGPT
* Automatische Übersetzungstools wie DeepL
* Textanalyse für Sentiment-Erkennung

=== Weitere Begriffe im Kontext von KI ===
'''Künstliche Allgemeine Intelligenz (AGI)'''

AGI beschreibt eine starke Form der KI mit umfassendem Verständnis und Problemlösungsfähigkeiten in verschiedenen Domänen. Sie wird oft als langfristiges Ziel der KI-Forschung angesehen.

'''Künstliche Superintelligenz (ASI)'''

ASI geht über menschliche Intelligenz hinaus und beschreibt eine hypothetische Zukunftsvision von Maschinenintelligenz, die Menschen in nahezu allen Bereichen übertrifft.

'''Neurale Netze'''

Ein Modell inspiriert vom menschlichen Gehirn, das aus Schichten von Knoten ("Neuronen") besteht und für viele Deep-Learning-Anwendungen verwendet wird.

== Einsatzszenarien von KI ==

=== KI-Chatbots für Kunden und Partner ===

KI-gestützte Chatbots haben sich seit ihrer Einführung vor einigen Jahren erheblich weiterentwickelt. Moderne Systeme nutzen fortschrittliche Natural Language Processing (NLP) Technologien, um komplexe Kundenanfragen zu verstehen und zu beantworten. Ein Beispiel ist der Einsatz von Large Language Models (LLMs) wie GPT-4, die es Chatbots ermöglichen, kontextbezogene und nuancierte Antworten zu generieren.

Vorteile:
* Erhöhte Verfügbarkeit: 24/7-Service ohne Wartezeiten
* Kosteneffizienz: Reduzierung des Personalaufwands für Routineanfragen
* Skalierbarkeit: Bewältigung von Anfragespitzen ohne Qualitätsverlust
* Mehrsprachigkeit: Unterstützung globaler Kundschaft ohne Sprachbarrieren

Herausforderungen:
* Datenschutz: Sicherstellung der DSGVO-Konformität bei der Verarbeitung personenbezogener Daten
* Qualitätssicherung: Kontinuierliche Überwachung und Verbesserung der Antwortqualität
* Integration: Nahtlose Einbindung in bestehende Customer-Relationship-Management (CRM) Systeme

=== KI in Produktion und Dienstleistung ===

Der Einsatz von KI in der Produktion hat das Potenzial, die Industrie 4.0 auf ein neues Niveau zu heben. Predictive Maintenance, ein Kernbereich des KI-Einsatzes in der Produktion, nutzt Maschinelles Lernen, um Ausfälle vorherzusagen und ungeplante Stillstandzeiten zu minimieren.

Weitere Anwendungsbereiche:
* Qualitätskontrolle durch KI-gestützte Bildverarbeitung
* Optimierung von Lieferketten durch intelligente Bedarfsprognosen
* Energieeffizienzsteigerung durch KI-gesteuerte Prozessoptimierung

=== KI zur Stärkung der IT-Sicherheit ===

Angesichts der zunehmenden Komplexität von Cyberangriffen spielt KI eine immer wichtigere Rolle in der IT-Sicherheit. Moderne Security Information and Event Management (SIEM) Systeme nutzen KI-Algorithmen, um Anomalien im Netzwerkverkehr zu erkennen und potenzielle Bedrohungen in Echtzeit zu identifizieren.

Herausforderungen:
* Datenschutz: Balancierung zwischen Sicherheitsanforderungen und Privatsphäre der Mitarbeitenden
* Fachkräftemangel: Bedarf an Spezialisten mit Expertise in KI und Cybersicherheit
* Ethische Fragen: Abwägung zwischen automatisierten Entscheidungen und menschlicher Kontrolle
===KI als eigenständiges Produkt===
Unternehmen entwickeln zunehmend KI-basierte Produkte und Dienstleistungen wie:
* Personalisierte Empfehlungssysteme
*Automatisierte Analysewerkzeuge für Daten
*Entscheidungsunterstützungssysteme
== Rechtliche Aspekte ==

=== EU-KI-Verordnung ===

Die EU-KI-Verordnung, die seit Februar 2025 schrittweise in Kraft tritt, stellt Unternehmen vor neue Herausforderungen. Sie kategorisiert KI-Systeme nach ihrem Risikoniveau und stellt entsprechende Anforderungen an deren Entwicklung und Einsatz.

Kernpunkte:
* Verbot bestimmter KI-Praktiken, wie z.B. Social Scoring durch Behörden
* Strenge Auflagen für Hochrisiko-KI-Systeme, einschließlich Transparenzpflichten und Konformitätsbewertungen
* Spezielle Anforderungen an KI-Systeme in sensiblen Bereichen wie Gesundheitswesen oder Strafverfolgung

Unternehmen müssen ihre KI-Strategien an diese neuen Regularien anpassen. Dies erfordert oft erhebliche Investitionen in Compliance-Maßnahmen und kann die Markteinführung neuer KI-Produkte verzögern.

=== Vertragsrechtliche Herausforderungen ===

Der Einsatz von KI wirft komplexe vertragsrechtliche Fragen auf, insbesondere im Bereich der Haftung und des geistigen Eigentums.

Weitere Herausforderungen:
* Eigentum an KI-generierten Daten und Ergebnissen
* Datenschutzrechtliche Aspekte bei der Nutzung personenbezogener Daten für KI-Training
* Vertragsgestaltung bei KI-as-a-Service Angeboten

== Ethische und gesellschaftliche Aspekte ==

Der Einsatz von KI in Unternehmen und Behörden wirft wichtige ethische Fragen auf, die über rein technische oder rechtliche Aspekte hinausgehen.

=== Fairness und Nicht-Diskriminierung ===

KI-Systeme können unbeabsichtigt diskriminierende Entscheidungen treffen, wenn sie mit verzerrten Datensätzen trainiert wurden. Ein bekanntes Beispiel ist ein KI-basiertes Rekrutierungstool eines großen Technologieunternehmens, das 2018 aufgrund von Gender-Bias eingestellt wurde.

Lösungsansätze:
* Diversität in KI-Entwicklungsteams fördern
* Regelmäßige Audits von KI-Systemen auf Fairness und Bias
* Transparenz und Erklärbarkeit von KI-Entscheidungen erhöhen

=== Auswirkungen auf den Arbeitsmarkt ===

Die zunehmende Automatisierung durch KI führt zu Veränderungen auf dem Arbeitsmarkt. Während einige Berufsbilder verschwinden, entstehen neue Tätigkeitsfelder.

Herausforderungen:
* Umschulung und Weiterbildung von Arbeitnehmenden
* Soziale Absicherung in Zeiten des Wandels
* Förderung von Kreativität und sozialen Kompetenzen, die schwer durch KI zu ersetzen sind

== Risiken der KI ==
Der Einsatz von Künstlicher Intelligenz (KI) birgt neben den vielfältigen Chancen auch erhebliche Risiken, die einer sorgfältigen Betrachtung und Bewertung bedürfen. Im Folgenden werden die wesentlichen Risikobereiche detailliert beleuchtet.

=== Datenschutz und Privatsphäre ===
Ein zentrales Risiko beim Einsatz von KI-Systemen betrifft den Schutz personenbezogener Daten und die Wahrung der Privatsphäre. KI-Modelle, insbesondere Large Language Models (LLMs), benötigen enorme Datenmengen für ihr Training, was Fragen zur rechtmäßigen Datenerhebung und -verarbeitung aufwirft. Die EU-Datenschutz-Grundverordnung (DSGVO) stellt hier strenge Anforderungen, die Unternehmen beim KI-Einsatz berücksichtigen müssen.

Herausforderungen:

* Sicherstellung der DSGVO-Konformität bei der Verarbeitung personenbezogener Daten
* Schutz vor unbeabsichtigter Offenlegung sensibler Informationen durch KI-Systeme
* Gewährleistung der Datensicherheit bei der Übertragung und Speicherung von Trainingsdaten

=== Bias und Diskriminierung ===
KI-Systeme können unbeabsichtigt diskriminierende Entscheidungen treffen, wenn sie mit verzerrten Datensätzen trainiert wurden. Dies kann zu unfairen Behandlungen bestimmter Personengruppen führen, beispielsweise bei Einstellungsprozessen oder Kreditvergaben.
Maßnahmen zur Risikominimierung:

* Regelmäßige Audits von KI-Systemen auf Fairness und Bias
* Diversität in KI-Entwicklungsteams fördern
* Implementierung von Methoden zur Erkennung und Korrektur von Verzerrungen in Trainingsdaten

=== Mangelnde Transparenz und Erklärbarkeit ===
Viele KI-Systeme, insbesondere komplexe neuronale Netze, agieren als "Black Boxes", deren Entscheidungsprozesse für Menschen schwer nachvollziehbar sind. Dies kann zu Problemen führen, wenn KI-Systeme in kritischen Bereichen wie Medizin oder Justiz eingesetzt werden.

Lösungsansätze:

* Entwicklung und Einsatz von Explainable AI (XAI) Techniken
* Transparente Dokumentation von KI-Entscheidungsprozessen
* Schulung von Anwendern im Umgang mit KI-generierten Ergebnissen

=== Abhängigkeit und Kontrollverlust ===
Mit zunehmender Integration von KI in kritische Infrastrukturen und Entscheidungsprozesse wächst das Risiko einer übermäßigen Abhängigkeit. Ein Ausfall oder eine Fehlfunktion von KI-Systemen kann schwerwiegende Folgen haben.

Präventive Maßnahmen:

* Implementierung robuster Backup-Systeme und Notfallpläne
* Regelmäßige Überprüfung und Wartung von KI-Systemen
* Beibehaltung menschlicher Kontroll- und Eingriffsmöglichkeiten

=== Rechtliche und ethische Herausforderungen ===
Der Einsatz von KI wirft komplexe rechtliche und ethische Fragen auf, insbesondere im Bereich der Haftung und Verantwortlichkeit. Wer haftet beispielsweise bei Fehlentscheidungen autonomer Systeme?

Notwendige Schritte:

* Entwicklung klarer rechtlicher Rahmenbedingungen für den KI-Einsatz
* Etablierung ethischer Richtlinien und Governance-Strukturen in Unternehmen
* Förderung des gesellschaftlichen Diskurses über die ethischen Implikationen von KI

=== Sicherheitsrisiken und Missbrauchspotenzial ===
KI-Systeme können auch für böswillige Zwecke missbraucht werden, etwa zur Erstellung von Deepfakes oder für automatisierte Cyberangriffe. Zudem besteht die Gefahr, dass KI-Systeme selbst zum Ziel von Angriffen werden.

Schutzmaßnahmen:

* Implementierung robuster Sicherheitsarchitekturen für KI-Systeme
* Entwicklung von KI-basierten Abwehrmechanismen gegen Cyberangriffe
* Internationale Zusammenarbeit zur Bekämpfung des Missbrauchs von KI-Technologien

=== Auswirkungen auf den Arbeitsmarkt ===
Die zunehmende Automatisierung durch KI führt zu Veränderungen auf dem Arbeitsmarkt. Während einige Berufsbilder verschwinden, entstehen neue Tätigkeitsfelder.

Handlungsempfehlungen:

* Förderung von Umschulungs- und Weiterbildungsprogrammen
* Entwicklung neuer Bildungskonzepte zur Vorbereitung auf eine KI-geprägte Arbeitswelt
* Soziale Absicherung für von Automatisierung betroffene Arbeitnehmende

=== Ressourcenverbrauch und Umweltauswirkungen ===
Der Betrieb von KI-Systemen, insbesondere das Training großer Sprachmodelle, ist extrem energie- und ressourcenintensiv. Dies führt zu erheblichen Umweltauswirkungen und hohen Betriebskosten.

Lösungsansätze:

* Entwicklung energieeffizienterer KI-Architekturen und Trainingsmethoden
* Nutzung erneuerbarer Energien für Rechenzentren
* Berücksichtigung der Umweltauswirkungen bei der Kosten-Nutzen-Analyse von KI-Projekten

Die genannten Risiken verdeutlichen die Notwendigkeit eines verantwortungsvollen und durchdachten Einsatzes von KI. Unternehmen und Behörden sind gefordert, umfassende Strategien zu entwickeln, die technologische Innovationen mit ethischen Prinzipien und rechtlichen Anforderungen in Einklang bringen. Nur so kann das volle Potenzial von KI ausgeschöpft werden, ohne dabei grundlegende Werte und Rechte zu gefährden.

== Fazit ==

Der Einsatz von KI in Unternehmen und Behörden bietet enorme Chancen zur Effizienzsteigerung und Innovation. Gleichzeitig stellt er Organisationen vor komplexe technische, rechtliche und ethische Herausforderungen. Ein verantwortungsvoller und durchdachter Einsatz von KI, der rechtliche Rahmenbedingungen beachtet und ethische Aspekte berücksichtigt, ist entscheidend für den langfristigen Erfolg und die gesellschaftliche Akzeptanz dieser Technologie.

Unternehmen und Behörden sind gefordert, KI-Strategien zu entwickeln, die nicht nur technologische Aspekte berücksichtigen, sondern auch rechtliche Compliance, ethische Verantwortung und gesellschaftliche Auswirkungen einbeziehen. Nur so kann das volle Potenzial von KI ausgeschöpft werden, ohne dabei grundlegende Werte und Rechte zu gefährden.

== Weitere Infomationen ==

* [[KI Startseite|Einführung zu sinnvollen Regelungen für den KI-Einsatz]]
* [[Datenbias|Was ist Daten-Bias?]]
* [[KI Datenschutz|Datenschutz in KI-Anwendungen]]
* [[RiLi-KI-Einsatz|Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)]]
* [[LF-KI-Sicherheit|Leitfaden zur KI-Sicherheit]]
* [[KI-Register|Mustervorlage für ein KI-Register]]
* [[LF-KI-Chatbots|Leitfaden für Mitarbeitende zur Nutzung von KI-Systemen]]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=OJ:L_202401689 EU-Verordnung über künstliche Intelligenz]
* [https://www.bfdi.bund.de/DE/Fachthemen/Inhalte/Technik/KI-Verordnung.html Die KI-Verordnung der EU (BfDI)]

[[Kategorie:Artikel]]
[[Kategorie:KI]]

LF-KI-Sicherheit

2026-04-02T12:34:37Z

Dirk:

{{#seo:
|title=Leitfaden KI-Sicherheit: Härtung, Modellsicherheit und Nachvollziehbarkeit
|keywords=KI-Härtung, Modellsicherheit, Nachvollziehbarkeit, AI-Hardening, KI-Risiken, KI-Logging, KI-Audit, EU AI Act, ISMS, ISO 27001
|description=Fachlicher Leitfaden zur KI-Sicherheit mit Maßnahmen für Härtung, Modellsicherheit und Nachvollziehbarkeit. Mit Anforderungen, Prüfkriterien und Best Practices für Unternehmen.
}}{{SHORTDESC:Härtung, Modellsicherheit und Nachvollziehbarkeit}}''Dieses Leitfaden beschreibt technische Maßnahmen zur Absicherung von KI-Systemen im ISMS-Kontext. Es adressiert Lücken in der Umsetzung von EU AI Act (Art. 15, 13), BSI Grundschutz und ISO 27001 A.8.25ff. Die Maßnahmen gewährleisten Robustheit gegen Angriffe, Modellschutz und prüfbare Nachverfolgbarkeit. Sie sind für Hochrisiko-KI-Systeme zwingend erforderlich, um Haftungsrisiken zu minimieren und Audits zu bestehen.''

== Einleitung ==
Künstliche Intelligenz (KI) birgt erhebliche Sicherheitsrisiken, die durch den EU AI Act und nationale Standards wie BSI Grundschutz adressiert werden müssen. Dieser Leitfaden beschreibt die technischen Maßnahmen zu '''KI-Härtung''', '''Modellsicherheit''' und '''Nachvollziehbarkeit''', die für den sicheren Einsatz von KI-Systemen im Unternehmen zwingend erforderlich sind.

'''Zielgruppe:''' IT-Sicherheitsverantwortliche, Data Scientists und ISMS-Beauftragte.

'''Sinn und Zweck:''' Bereitstellung implementierbarer und prüfbarer Maßnahmen zur Erfüllung von EU AI Act Art. 12-15, Konformität mit ISO 27001 und Vermeidung von Haftungsrisiken. Die Maßnahmen ermöglichen Audits, schützen vor Angriffen und gewährleisten die Nachverfolgbarkeit kritischer Entscheidungen.

Die nachfolgenden Kapitel leiten direkt aus den gesetzlichen Pflichten ab und enthalten konkrete Umsetzungsschritte mit Prüfkriterien.

== Rechtliche Grundlagen und Pflichten ==
Die Maßnahmen basieren auf zwingenden Anforderungen des '''EU AI Act''' und nationaler Standards:

* '''EU AI Act Art. 15''' (Hochrisiko-KI): Robustheit gegen Angriffe, Cybersicherheit, Härte-Maßnahmen.
* '''EU AI Act Art. 13''': Transparenzpflichten inklusive technischer Dokumentation und Nachvollziehbarkeit.
* '''EU AI Act Art. 12''': Qualitätsmanagement mit Risikobewertung und Auditfähigkeit (10-Jahre-Dokumentation).

'''Ziel:''' Haftungsminimierung, Audits bestand, Konformität mit NIS2 und DSGVO.

== KI-Härtung (Robustheit gegen Angriffe) ==
KI-Härtung schützt KI-Systeme vor manipulierenden Angriffen durch Erhöhung der Robustheit. Sie verhindert, dass Angreifer Modelle durch gezielte Eingaben (Prompt Injection, Adversarial Examples) umgehen oder gefährliche Ausgaben provozieren.

=== Input-Sanitization ===
Input-Sanitization filtert bösartige Eingaben vor der Modellverarbeitung. Sie blockiert Jailbreak-Versuche, SQL-Injection und Prompt Injections, die Modelle zu unzulässigen Antworten zwingen. Erforderlich durch EU AI Act Art. 15 (Robustheit).

'''Best-Practice-Umsetzung:'''

* Bibliothek <code>llm-guard</code> oder <code>neural-classifier</code> für Input-Vorfilterung.
* Regex-Regeln für bekannte Angriffsmuster (<code>ignore previous instructions</code>, <code>sudo</code>, Base64-Payloads).
* Whitelisting erlaubter Zeichenmengen (alphanumerisch + begrenzte Sonderzeichen).
* Implementierung als Middleware (FastAPI/Flask): <code>request.input = sanitize(request.input)</code>.

=== Rate Limiting ===
Begrenzt API-Aufrufe pro Benutzer/IP, um Denial-of-Service (DoS) und Brute-Force-Angriffe zu verhindern. Schützt Rechenressourcen und ermöglicht Anomalie-Erkennung.

'''Best-Practice-Umsetzung:'''

* Redis-basiertes Sliding-Window-Limiting: 100 Requests/Stunde pro User-ID/IP.
* Framework-Integration: FastAPI-Limiter (<code>slowapi</code>), Django-RateLimit.
* Headers setzen: <code>X-RateLimit-Remaining</code>, <code>Retry-After</code>.
* Monitoring: Prometheus-Metriken für Rate-Limit-Hits.

=== Output-Moderation ===
Prüft Modell-Ausgaben auf Toxizität, Hate Speech oder sensible Datenlecks vor Auslieferung. Verhindert rechtliche Haftung durch schädliche Inhalte.

'''Best-Practice-Umsetzung:'''

* OpenAI Moderation API oder HuggingFace <code>unitary/toxic-bert</code>.
* Kategorien: Hate, Violence, Self-Harm, PII (Personendaten).
* Block-Regel: Score > 0.7 → Antwort verweigern mit "Inhalt nicht zulässig".
* Fallback: Statische Regex für Kreditkarten/SVNr.

=== Adversarial Training ===
Trainiert Modelle mit feindlichen Beispielen, sodass sie Angriffe erkennen und abwehren. Erhöht Robustheit gegen OWASP LLM Top 10-Attacken.

'''Best-Practice-Umsetzung:'''

* Dataset: OWASP LLM Top 10 + Anthropic Red-Team-Dataset.
* Fine-Tuning: LoRA-Adapter auf bestehendem Modell (1-2% zusätzlicher VRAM).
* Metriken: Attack Success Rate (ASR) nach Training (kontinuierliche Reduktion).
* Tools: <code>trl</code> (Transformers Reinforcement Learning), <code>adversarial-robustness-toolbox</code>.

=== Container-Härtung ===
Sichert den KI-Deploy-Container gegen Privilege Escalation und Side-Channel-Angriffe. Entspricht CIS Docker Benchmarks.

'''Best-Practice-Umsetzung:'''

* Non-root User (<code>USER 1000:1000</code> im Dockerfile).
* AppArmor/SELinux-Profil für KI-Prozess.
* Read-only Root-Filesystem (<code>--read-only</code> bei <code>docker run</code>).
* Seccomp-Filter: Nur <code>read/write/socket</code> erlauben.
* Image-Scan: Trivy vor Deploy.

=== Prüfkriterien und Prüfungsmodalitäten für KI-Härtung ===
'''Übergeordnetes Kriterium:''' Sicherheits-Test durch externe Experten mit weniger als 5% Angriffserfolg über alle Maßnahmen.

==== Input-Sanitization – Prüfkriterium und Umsetzung ====
'''Kriterium:''' 95% der bekannten gefährlichen Eingaben werden erkannt und blockiert.

'''Prüfungsmodalitäten:'''

1. Test-Suite: 500+ Angriffsvektoren (DAN-Jailbreaks, Base64-Payloads, Unicode-Exploits)
2. Tool: llm-attacks oder garak (automatisierte Tests)
3. Erfolg: Blockquote ≥95%, False-Positive-Rate <1%
4. Dokumentation: Test-Report mit Pass/Fail pro Vektor

'''Umsetzung:''' Wöchentlicher Test mit bekannten Angriffsmustern → Bericht per E-Mail.

==== Rate Limiting – Prüfkriterium und Umsetzung ====
'''Kriterium:''' Kein Benutzer kann mehr als 100 Anfragen pro Stunde stellen.

'''Prüfungsmodalitäten:'''
1. Load-Test: Apache Bench (ab -n 200 -c 10)
2. Überprüfung: Redis-Keys `ratelimit:ip:X` TTL ≤3600s
3. Response: HTTP 429 mit Retry-After Header bei Überschreitung
4. Metriken: Prometheus `ratelimit_hits_total > 0`

'''Umsetzung:''' Monatliche Lasttests mit Tools wie Apache Bench.

==== Output-Moderation – Prüfkriterium und Umsetzung ====
'''Kriterium:''' 98% der gefährlichen Antworten werden erkannt.

'''Prüfungsmodalitäten:'''
1. Dataset: HuggingFace "unitary/toxic-bert" Testset (10.000 Samples)
2. Threshold: F1-Score soll stabil bleiben oder sich verbessern bei Hate/Violence/Self-Harm
3. Audit: 100% manuelle Stichprobe kritischer Outputs
4. Log: Moderation-Ergebnisse 90 Tage auffindbar

'''Umsetzung:''' Vierteljährliche Tests mit öffentlichen Test-Datensätzen.

==== Adversarial Training – Prüfkriterium und Umsetzung ====
'''Kriterium:''' Angriffe gelingen in weniger als 5% der Fälle nach Training.

'''Prüfungsmodalitäten:'''
1. Benchmark: OWASP LLM Top 10 + Anthropic Red-Team (1.000 Angriffe)
2. Metrik: ASR = erfolgreiche Angriffe / Gesamtangriffe
3. Baseline-Vergleich: Vorher/Nachher ASR-Differenz ≥80%
4. Periodisch: Quartalsweise Re-Test nach Modell-Updates

'''Umsetzung:''' Automatisierte Tests nach jedem Modell-Update.

==== Container-Härtung – Prüfkriterium und Umsetzung ====
'''Kriterium:''' Container erfüllt 30+ Sicherheitsregeln (Docker-Standard).

'''Prüfungsmodalitäten:'''
1. Scan: Trivy `trivy image ki-app:latest` → 0 Criticals
2. Runtime: `docker-bench-security` → ≥95% Compliance
3. Prozess: `ps aux | grep ki-app` → non-root User
4. Netzwerk: `docker inspect` → No privileged ports (<1024)

'''Umsetzung:''' Wöchentliche automatische Scans aller Container.

==== Übergeordnete Sicherheitsprüfung ====
Empfehlenswert ist ein regelmäßiger Prüf- und Auditzyklus z.B.: interne monatliche oder quartalsmäßige Prüfung und jährliche externe Prüfung

'''Alle jährlichen Auditergebnisse 10 Jahre aufbewahren''' (gesetzliche Pflicht EU AI Act).

== Modellsicherheit (Integritätsschutz) ==
Modellsicherheit schützt das trainierte KI-Modell vor Diebstahl, Manipulation und unbefugter Nutzung während des gesamten Lebenszyklus.

=== Model Cards ===
Model Cards sind standardisierte Dokumente, die Architektur, Trainingsdaten, Leistung und Risiken des Modells beschreiben. Sie ermöglichen Transparenz und sind für Audits erforderlich (EU AI Act Art. 13).

'''Best-Practice-Umsetzung:'''

* Vorlage nach HuggingFace-Standard verwenden
* Inhalte: Modelltyp, Parameteranzahl, Trainingsdatenmenge, Bias-Metriken
* Automatische Generierung mit Tools wie <code>model-card-toolkit</code>
* Im Versionskontrollsystem (Git) als Markdown-Datei speichern

=== Integritätsprüfung ===
Überprüft vor jeder Nutzung, ob das Modell manipuliert wurde. Verhindert Einsatz beschädigter oder vergifteter Modelle.

'''Best-Practice-Umsetzung:'''

* SHA-256-Hash des Originalmodells berechnen und signieren
* Vor Inference: Hash vergleichen → bei Abweichung Notfall-Stopp
* Digitale Signatur mit GPG oder Hardware Security Module (HSM)
* Automatisierte Prüfung als Docker-Entry-Point-Script

=== Output-Watermarking ===
Fügt unsichtbare Markierungen in KI-Ausgaben ein, um deren Herkunft nachzuweisen. Schützt vor Missbrauch und Plagiat.

Optional - sinnvoll für bestimmte Szenarien.

'''Best-Practice-Umsetzung:'''

* Token-basierte Watermarks (OpenAI-Methode): Spezielle Token-Wahrscheinlichkeiten
* Text-Watermarking: Synonyme-Ersetzung nach festem Muster
* Bild-Watermarking: LSB-Steganographie (Least Significant Bit)
* Detektions-Tool parallel bereitstellen

=== Differential Privacy ===
Verhindert, dass einzelne Trainingsdaten aus Modell-Ausgaben rekonstruiert werden können. Schützt personenbezogene Daten (DSGVO).

'''Best-Practice-Umsetzung:'''

* Training mit DP-SGD (Differential Privacy Stochastic Gradient Descent)
* Privacy Budget ε=1.0 (empfohlener Richtwert)
* Bibliothek: Opacus (PyTorch) oder TensorFlow Privacy
* Privacy-Audit: Membership Inference Attack Tests

=== SBOM (Software Bill of Materials) ===
Vollständige Liste aller Komponenten des KI-Systems für Supply-Chain-Sicherheit. Ermöglicht Schwachstellen-Management.

'''Best-Practice-Umsetzung:'''

* CycloneDX-Format für Python/ML-Umgebungen
* Automatische Generierung: <code>cyclonedx-py</code> oder GitHub Dependency Graph
* Dependency-Scan: Snyk/Trivy vor Deploy
* Versionspflicht: Jede Komponente mit exakter Versionsnummer

=== Prüfkriterien und Prüfungsmodalitäten für Modellsicherheit ===
'''Übergeordnetes Kriterium:''' 100% der Modelle sind vollständig dokumentiert und integritätsgesichert.

==== Model Cards – Prüfkriterium und Umsetzung ====
'''Kriterium:''' Jede Modellversion hat vollständige Model Card (10+ Kategorien).

'''Prüfungsmodalitäten:'''
1. Vollständigkeits-Check: Checkliste mit Pflichtfeldern
2. Aktualität: Model Card ≤ 3 Monate alt
3. Qualität: Techniker können Modell aus Card reproduzieren
4. Audit: Jährliche Stichprobe 20% aller Model Cards

'''Umsetzung:''' Git-Hook blockiert Commits ohne Model Card.

==== Integritätsprüfung – Prüfkriterium und Umsetzung ====
'''Kriterium:''' 100% Integritätsprüfung vor jeder Modellnutzung.

'''Prüfungsmodalitäten:'''
1. Log-Analyse: Alle Inference-Starts mit Hash-Check
2. Fehlerrate: nahe 0 (Integritätsfehler werden innerhalb von 24 Stunden erkannt und behoben.)
3. Recovery-Test: Manipuliertes Modell wird erkannt
4. Signatur-Validierung: GPG-Key korrekt

'''Umsetzung:''' Monatliche Log-Auswertung und Alarm bei Fehlern.

==== Output-Watermarking – Prüfkriterium und Umsetzung ====
'''Kriterium:''' 95% Detektionsrate bei Watermark-Prüfung (optional).

'''Prüfungsmodalitäten:'''
1. Test-Suite: 1.000 Ausgaben mit/ohne Watermark
2. False-Positive-Rate: <1%
3. Robustheit: Watermark übersteht Copy-Paste/OCR
4. Dokumentation: Detektions-Tool verfügbar

'''Umsetzung:''' Wöchentliche Batch-Tests mit Testausgaben.

==== Differential Privacy – Prüfkriterium und Umsetzung ====
'''Kriterium:''' Privacy Budget ε ≤ 1.0 nach Training.

'''Prüfungsmodalitäten:'''
1. Privacy-Audit: Membership Inference Attack <5% Erfolg
2. ε-Berechnung: Auditor bestätigt korrekte Berechnung
3. Dokumentation: Training-Logs mit Privacy-Metriken
4. Zertifikat: Privacy-Bericht verfügbar

'''Umsetzung:''' Audit nach jedem Training.

==== SBOM – Prüfkriterium und Umsetzung ====
'''Kriterium:''' Vollständiger, aktueller SBOM für jedes KI-System.

'''Prüfungsmodalitäten:'''
1. Vollständigkeit: 100% aller Dependencies erfasst
2. Aktualität: SBOM ≤ 30 Tage alt
3. Schwachstellen: Keine Critical Vulnerabilities
4. Validierung: CycloneDX-Schema-Check

'''Umsetzung:''' CI/CD-Pipeline generiert SBOM automatisch.

== Nachvollziehbarkeit (Traceability) ==
Nachvollziehbarkeit ermöglicht die Rekonstruktion jeder KI-Entscheidung für Audits und Vorfälle (EU AI Act Art. 12-13, 10-Jahre-Pflicht).

=== Vollständiges Inference-Logging ===
Protokolliert alle KI-Anfragen und Antworten vollständig. Ermöglicht Nachverfolgung von Fehlentscheidungen oder Missbrauch.

'''Best-Practice-Umsetzung:'''

* Log-Einträge: User-ID, Timestamp, Input, Output, Modell-Version, Rechenzeit
* JSON-Format mit strukturierten Feldern
* Speicherung in Elasticsearch oder PostgreSQL (append-only)
* Enpfehlung: min. 1 Jahr aufbewahren (zur Verfügbarkeit für Audits)

=== End-to-End-Audit-Trails ===
Verknüpft alle Schritte einer KI-Entscheidung von der Eingabe bis zur finalen Ausgabe. Notwendig für Haftungsfragen.

'''Best-Practice-Umsetzung:'''

* MLflow oder Weights&Biases für Experiment-Tracking
* Jeder Inference-Request erhält eindeutige Request-ID
* Rationale Logging (Begründungsfragmente ohne vollständige Chain‑of‑Thought)
* API: <code>/audit/{request_id}</code> für Nachverfolgung

=== Explainability für kritische Entscheidungen ===
Zeigt auf, warum das Modell eine bestimmte Entscheidung getroffen hat. Erforderlich bei Hochrisiko-Anwendungen.

'''Best-Practice-Umsetzung:'''

* SHAP/LIME für Feature Importance (wichtigste Einflussfaktoren)
* Bei Bild-KI: Grad-CAM Heatmaps
* Erklärung als Text + Grafik im Log speichern
* Nur für kritische Entscheidungen (Schwellenwert-basiert)

=== Versionskontrolle Modelle/Daten ===
Jede Entscheidung ist exakt einer Modell-/Daten-Version zuzuordnen. Verhindert "Wer hat welches Modell verwendet?"-Probleme.

'''Best-Practice-Umsetzung:'''

* DVC (Data Version Control) für Datasets und Modelle
* Git-Tags für Modell-Releases (v1.2.3)
* Jeder Log-Eintrag enthält <code>model_hash</code> und <code>data_version</code>
* Container-Images mit Digest (SHA-256)

=== SIEM-Integration und Anomalie-Erkennung ===
Erkennt ungewöhnliches KI-Verhalten automatisch und leitet Alarme ein. Erfüllt ISO 27001 Überwachungspflichten.

'''Best-Practice-Umsetzung:'''

* Logs in Splunk/ELK-Stack einspielen
* Anomalie-Detektoren: Zu viele Token, ungewöhnliche Anfragen, Spitzenzeiten
* Alerting: Slack/PagerDuty bei >10x normalem Verbrauch
* Dashboard mit KI-spezifischen Metriken

=== Prüfkriterien und Prüfungsmodalitäten für Nachvollziehbarkeit ===
'''Übergeordnetes Kriterium:''' Jede KI-Entscheidung vollständig nachvollziehbar innerhalb 24 Stunden.

==== Inference-Logging – Prüfkriterium und Umsetzung ====
'''Kriterium:''' vollständig protokolliert (keine Lücken, Abweichungen dokumentiert und begründet).

'''Prüfungsmodalitäten:'''
1. Log-Vollständigkeit: Request-Count vs. Log-Count = 100%
2. Format-Check: JSON-Schema-Validierung
3. Retention-Test: Daten aus Vorjahr abrufbar
4. Performance: Logging <50ms Overhead pro Request

'''Umsetzung:''' Täglicher Log-Completeness-Check per Cron-Job.

==== Audit-Trails – Prüfkriterium und Umsetzung ====
'''Kriterium:''' Request-ID Nachverfolgung von Input zu Output in <5 Sekunden.

'''Prüfungsmodalitäten:'''
1. End-to-End-Test: 100 zufällige Request-IDs prüfen
2. Rationale Logging Zwischenschritte vollständig
3. Suchzeit: Elasticsearch Query <2s für 1 Jahr Daten
4. API-Test: /audit/{id} liefert vollständige Spur

'''Umsetzung:''' Monatliche Stichproben mit Zufalls-Request-IDs.

==== Explainability – Prüfkriterium und Umsetzung ====
'''Kriterium:''' 95% der kritischen Entscheidungen mit Erklärung versehen.

'''Prüfungsmodalitäten:'''
1. Abdeckung: Kritische Entscheidungen = Erklärungen
2. Qualität: Erklärung verständlich für Nicht-Experten
3. Performance: SHAP-Berechnung <2s pro Anfrage
4. Speicherung: Erklärungen 10 Jahre haltbar

'''Umsetzung:''' Wöchentliche Prüfung kritischer Logs.

==== Versionskontrolle – Prüfkriterium und Umsetzung ====
'''Kriterium:''' 100% der Logs enthalten korrekte Modell-/Daten-Version.

'''Prüfungsmodalitäten:'''
1. Hash-Validierung: model_hash existiert in Registry
2. Reproduzierbarkeit: Gleiches Modell = gleiche Ausgabe
3. Versions-Historie: 12 Monate rückverfolgbar
4. Daten-Integrität: DVC-Status clean

'''Umsetzung:''' Tägliche Validierung neuer Logs.

==== SIEM-Integration – Prüfkriterium und Umsetzung ====
'''Kriterium:''' Anomalien innerhalb 15 Minuten erkannt und eskaliert.

'''Prüfungsmodalitäten:'''
1. Alert-Test: Simulierte Anomalie → Alarm in <15min
2. False-Positive-Rate: <5 pro Woche
3. Dashboard: Alle KI-Metriken real-time sichtbar
4. Incident-Response: 95% Alarme innerhalb SLA bearbeitet

'''Umsetzung:''' Wöchentliche Anomalie-Simulationstests.

== Verantwortlichkeiten ==
Die Maßnahmen erfordern eine klare Rollenverteilung über IT-Sicherheit, Entwicklung und Nutzung hinaus.

Auch '''Mitarbeitende''' tragen Mitverantwortung durch korrekte Bedienung und Meldung von Anomalien.
{| class="wikitable"
! Rolle !! Aufgaben !! KPIs
|-
| '''CISO''' || ISMS-Integration, Audit-Planung || 100% Konformität
|-
| '''Data Scientists''' || Model Cards, Training-Sicherheit || 100% Modelle dokumentiert
|-
| '''IT-Admin''' || Logging, Container-Härtung || 99,9% Logging-Verfügbarkeit
|-
| '''Datenschutzbeauftragte''' || DSGVO-Privacy (ε=1.0) || Privacy-Audits bestanden
|-
|'''Mitarbeitende'''
|Nur erlaubte Nutzung, richtige Bedienung, Anomalien melden
|95% korrekte Nutzung, 100% Incident-Meldung
|}

'''Nächste Schritte:''' Integration in ISMS-Prozesse, erste Red-Team-Tests.

== Umsetzung ==
Die Umsetzung erfolgt in '''vier Phasen''' mit klarer Priorisierung. Jede Phase baut auf der vorherigen auf und kann parallel mit begrenzten Ressourcen begonnen werden.

=== Phase 1: Sofortmaßnahmen (Grundschutz) ===
Diese Maßnahmen schützen innerhalb von Tagen vor den häufigsten Angriffen:

# '''Input/Output-Filter''' aktivieren (llm-guard, Moderation API)
# '''Logging-Infrastruktur''' aufsetzen (ELK/PostgreSQL, JSON-Format)
# '''Rate Limiting''' implementieren (Redis, 100 Requests/Stunde)
# '''Wartungsmodus''' für Tests definieren

=== Phase 2: Dokumentationspflicht ===
Erstellt die Audit-Grundlage für EU AI Act Konformität:

# '''Model Cards''' für alle produktiven Modelle erstellen
# '''SBOMs''' für KI-Systeme generieren (cyclonedx-py)
# '''Versionskontrolle''' einrichten (DVC/Git für Modelle/Daten)
# '''Integritätsprüfungen''' automatisieren (SHA-256 vor Inference)

=== Phase 3: Erweiterte Härte-Maßnahmen ===
Erhöht die Robustheit gegen komplexe Angriffe:

# '''Adversarial Training''' für kritische Modelle (LoRA, OWASP Dataset)
# '''Container-Härtung''' (non-root, AppArmor, Trivy Scans)
# '''Differential Privacy''' bei neuen Trainings (Differential Privacy mit Richtwert ε=1.0)
# '''Watermarking''' für Text/Bild-Outputs implementieren

=== Phase 4: Laufende Prüfung und Optimierung ===
Stellt dauerhafte Konformität sicher:

# '''Automatisierte Tests''' einrichten (garak, docker-bench-security)
# '''SIEM-Integration''' mit Anomalie-Erkennung (ELK + Alerts)
# '''Erste interne Prüfung''' aller Maßnahmen durchführen
# '''Externe Red-Team-Prüfung''' beauftragen (jährlich)

'''Monitoring:'''
* Wöchentliche Automatiktests mit Berichten
* Monatliche Stichproben der Logs
* Jährliche externe Validierung
* Alle jährlichen Vaidierungen 10 Jahre archivieren (EU AI Act)

== Fazit ==
Die beschriebenen Maßnahmen zu '''KI-Härtung''', '''Modellsicherheit''' und '''Nachvollziehbarkeit''' bilden die technische Grundlage für konforme KI-Nutzung in Behörden oder Unternehmen. Sie erfüllen die zwingenden Anforderungen des EU AI Act (Art. 12-15) und des BSI Grundschutz, minimieren Haftungsrisiken und gewährleisten Auditfähigkeit.

'''Sofortige Umsetzung priorisieren:'''

# Logging-Infrastruktur – schnellste Wirkung, geringer Aufwand
# Input/Output-Filter – sofortiger Angriffsschutz
# Model Cards für bestehende Modelle – Audit-Vorbereitung

'''Langfristig:''' Jährliche Red-Team-Tests und kontinuierliche Weiterentwicklung der Maßnahmen entsprechend neuer Bedrohungen ([https://genai.owasp.org/llm-top-10/ OWASP LLM Top 10 Updates]).

Die Integration in bestehende ISMS-Prozesse schafft Wettbewerbsvorteile durch '''vertrauenswürdige KI''' und erfüllt regulatorische Pflichten gleichzeitig. Beginne mit dem Umsetzungsplan – die rechtlichen Fristen laufen.

== Glossar – KI‑Sicherheit ==
Dieses Glossar erläutert zentrale Fachbegriffe aus dem Bereich der KI‑Sicherheit, die im Leitfaden verwendet werden und für ein einheitliches Verständnis wichtig sind.
{| class="wikitable sortable"
! Begriff
! Erklärung
|-
| Adversarial Attack / Adversarial Examples
| Manipulierte Eingaben, die ein KI‑Modell zu falschen Ausgaben verleiten sollen.
|-
| Adversarial Success Rate (ASR)
| Anteil erfolgreicher adversarialer Angriffe auf ein Modell.
|-
| API‑Gateway
| Zentrale Schnittstelle zur Kontrolle, Authentifizierung und Überwachung von KI‑Anfragen.
|-
| Audit‑Trail
| Lückenlose Protokollkette aller relevanten Aktionen, Modellversionen und Änderungen.
|-
| Chain‑of‑Thought (CoT)
| Interne Zwischenschritte eines Modells; oft sensibel und nicht deterministisch.
|-
| Container‑Härtung
| Sicherheitsmaßnahmen zur Absicherung von Containern (z. B. Docker).
|-
| Data Poisoning
| Manipulation von Trainingsdaten, um ein Modell zu sabotieren oder zu beeinflussen.
|-
| Differential Privacy (DP)
| Technik, die verhindert, dass einzelne Trainingsdaten aus dem Modell rekonstruiert werden können.
|-
| DP‑SGD
| Trainingsverfahren, das Differential Privacy direkt in den Lernprozess integriert.
|-
| DVC (Data Version Control)
| Tool zur Versionierung von Trainingsdaten, Modellen und ML‑Experimenten.
|-
| Explainability / Erklärbarkeit
| Methoden zur Nachvollziehbarkeit von Modellentscheidungen (z. B. SHAP, LIME).
|-
| F1‑Score
| Kennzahl zur Bewertung der Klassifikationsqualität (Harmonic Mean aus Precision & Recall).
|-
| Halluzination (KI)
| Falsche oder erfundene Aussagen eines Modells ohne reale Grundlage.
|-
| Inference
| Ausführung eines Modells zur Beantwortung einer Anfrage (Prompt → Antwort).
|-
| Inference‑Logging
| Protokollierung aller Modellaufrufe, Eingaben, Ausgaben und Metadaten.
|-
| LSB‑Steganographie
| Verstecken von Informationen in den unauffälligen Bits von Dateien oder Bildern.
|-
| Model Card
| Dokumentation eines Modells mit Angaben zu Training, Risiken, Einsatzgrenzen und Performance.
|-
| Model Drift
| Leistungsabfall eines Modells über die Zeit durch veränderte Daten oder Umgebungen.
|-
| Model Integrity Check
| Prüfung, ob ein Modell unverändert, vollständig und authentisch ist (z. B. Hash‑Vergleich).
|-
| Prompt Injection
| Angriff, bei dem manipulierte Eingaben das Modell zu unerwünschten Aktionen bringen sollen.
|-
| Rate Limiting
| Begrenzung der Anzahl von Anfragen pro Nutzer oder Zeitfenster zur Missbrauchsvermeidung.
|-
| Red‑Teaming (KI)
| Gezielte Tests durch Teams, die Schwachstellen der KI aktiv ausnutzen sollen.
|-
| SBOM (Software Bill of Materials)
| Liste aller Software‑Komponenten und Abhängigkeiten eines Systems.
|-
| Shadow‑KI
| Nicht genehmigte oder nicht dokumentierte Nutzung von KI‑Tools durch Mitarbeitende.
|-
| SHAP / LIME
| Explainability‑Methoden zur Analyse der Bedeutung einzelner Merkmale.
|-
| Supply‑Chain‑Risiken (KI)
| Risiken durch externe Modelle, Trainingsdaten, Bibliotheken oder Cloud‑Dienste.
|-
| Watermarking (KI‑Output)
| Unsichtbare Markierung KI‑generierter Inhalte; noch nicht standardisiert.
|}

== Weiterführende Quellen ==

* [https://www.allianz-fuer-cybersicherheit.de/SharedDocs/Downloads/Webs/ACS/DE/Kreise/Expertenkreis_KI_LLMs.pdf BSI/ACS Leitfaden für Penetrationstests von Large-Language-Modellen (LLMs)]
* [https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf NIST AI Risk Management Framework (RMF 1.0)]
* [https://genai.owasp.org/download/46119/?tmstv=1741814262|OWASP OWASP Top 10 für LLM-Applikationen (v 2025 de)]

[[Kategorie:Artikel]]
[[Kategorie:KI]]
[[Kategorie:Leitfaden]]

OSCAL

2026-04-02T06:21:28Z

Dirk: /* OSCAL-Layers im Überblick */

{{#seo:
|title=OSCAL: Die Zukunft der Sicherheitsdokumentation und -automatisierung
|description=Erfahre wie OSCAL Organisationen hilft, Sicherheitsanforderungen zu dokumentieren und zu bewerten. Erfahre mehr über die Einsatzmöglichkeiten im ISMS.
}}{{SHORTDESC:OSCAL: Eine Revolution in der Sicherheitsdokumentation und -automatisierung}}
''OSCAL (Open Security Controls Assessment Language) ist eine vom National Institute of Standards and Technology (NIST) entwickelte maschinenlesbare Sprache, die darauf abzielt, die Dokumentation, Implementierung und Bewertung von Sicherheitsanforderungen zu standardisieren und zu vereinfachen. Seit seiner Einführung hat OSCAL zunehmend an Bedeutung gewonnen, insbesondere im Bereich der Informationssicherheit und des Compliance-Managements.

=== Grundlagen von OSCAL ===
OSCAL unterstützt drei Hauptformate zur Darstellung von Sicherheitsinformationen:

* XML: Für komplexe, hierarchische Datenstrukturen
* JSON: Für leichtgewichtige, webfreundliche Anwendungen
* YAML: Für menschenlesbare Konfigurationen und einfache Datenstrukturen

Diese Vielseitigkeit ermöglicht eine nahtlose Integration in verschiedene Systeme und Werkzeuge, was die Automatisierung von Sicherheitsprozessen erheblich erleichtert.

=== Einsatzmöglichkeiten im ISMS ===
Im Kontext eines Informationssicherheits-Managementsystems (ISMS) bietet OSCAL vielfältige Anwendungsmöglichkeiten:

# '''Standardisierte Dokumentation''': OSCAL ermöglicht eine einheitliche, maschinenlesbare Darstellung von Sicherheitsanforderungen, was die Konsistenz und Vergleichbarkeit über verschiedene Systeme hinweg verbessert.
# '''Automatisierte Compliance-Prüfungen''': Durch die Verwendung von OSCAL können Compliance-Anforderungen als Code definiert werden, was automatisierte Überprüfungen und eine effizientere Einhaltung verschiedener regulatorischer Standards ermöglicht.
# '''Kontinuierliche Bewertung''': OSCAL unterstützt die kontinuierliche Überwachung und Bewertung von Sicherheitsanforderungen, was zu einem agileren und reaktionsfähigeren ISMS führt.
# '''Verbessertes Risikomanagement''': Durch die Bereitstellung eines genauen, aktuellen Bildes der Sicherheitslage verbessert OSCAL die Entscheidungsfindung, insbesondere bei der Reaktion auf Vorfälle.
# '''Skalierbare Compliance-Verwaltung''': OSCAL bietet einen modularen und erweiterbaren Ansatz für Compliance, der mit dem Unternehmenswachstum skalieren kann.
# '''Interoperabilität''': OSCAL ermöglicht den Austausch von Sicherheitsinformationen zwischen Tools, Auditoren und Organisationen ohne Medienbrüche.

=== Konzept und Layout von OSCAL ===
OSCAL basiert auf einer schichtweisen Architektur (Layers), die vom NIST definiert ist und den gesamten Lebenszyklus der Sicherheitsanforderungen abdeckt – von der Definition bis zur Bewertung und Nachverfolgung. Diese Layer-Architektur ermöglicht eine modulare, maschinenlesbare Darstellung und fördert die Automatisierung im ISMS.

==== OSCAL-Layers im Überblick ====
Die Kernstruktur gliedert sich in fünf Haupt-Layers, die aufeinander aufbauen:
[[Datei:Oscal-layers-models-traceability.jpg|alternativtext=OSCAL Layer|zentriert|rahmenlos|640x640px|Quelle: NIST]]
# '''Control Layer''' Dieser Layer enthält Catalogs mit standardisierten Sicherheitskontrollen, z. B. aus NIST SP 800-53 oder anderen Quellen. Controls werden hier definiert, gruppiert (in Classes und Groups), parametrisiert und mit Props versehen. Er bildet die stabile, versionierte Basis; Parameter erlauben Flexibilität, z. B. für Passwortlängen oder Retention-Zeiten.
# '''Profile Layer''' Profiles wählen, modifizieren und erweitern Controls aus Catalogs. Typische Anpassungen: Ausschlüsse (modify remove), Hinzufügungen (modify add) oder Parameter-Setzungen. Ein Profile kann „aufgelöst“ (resolve) werden, um ein maßgeschneidertes Control-Set zu erzeugen, z. B. „FedRAMP Moderate Baseline“ oder ISO 27001-mappings.
# '''Implementation Layer''' Beschreibt die konkrete Umsetzung im System:
#* '''System Security Plan (SSP)''': Detaillierte Systembeschreibung (System Information, Objectives, Security Sensitivity), Komponenten, Inventory und Implementierungen pro Control (implementation, responsible roles, remarks).
#* '''Component Definition''': Wiederverwendbare Modelle für Assets (Software, Hardware, Services) mit Capabilities und Interfaces. Hier dokumentierst Du „wie wird jede Control umgesetzt?“ inklusive Evidenz-Referenzen.
# '''Assessment Layer''' Plant und protokolliert Bewertungen:
#* '''Assessment Plan (AP)''': Aufgaben (Tasks), Verantwortliche (Roles), Termine, Methoden und Checklists basierend auf Profiles.
#* '''Assessment Results (AR)''': Findings (Observations, Status: compliant/non-compliant), Evidenz (Artifacts), Checklists und Risikobewertungen. Unterstützt wiederholbare Audits und kontinuierliche Überwachung.
# '''Assessment Results Layer''' '''Plan of Action and Milestones (POA&M)''': Verfolgt Abhilfemaßnahmen für offene Findings. Enthält Tasks mit Fristen, Verantwortlichen, Status (executed, cancelled) und Ressourcen. Verknüpft mit SSP und AR für RMF-Schleifen (Risk Management Framework).

==== Layout und Identifier ====

* '''Well-formed Data Formats''': Alle Modelle verwenden UUIDs als eindeutige Identifier, URIs für Referenzen (z. B. Control-IDs als <code><nowiki>urn:uuid</nowiki>:...</code>) und Links zu externen Ressourcen. Dies gewährleistet Interoperabilität zwischen Tools.
* '''Profile Resolution''': Automatischer Prozess, der Profiles in vollständige Catalogs umwandelt – zentral für Tooling.
* '''Bezug zu Standards''': OSCAL integriert NIST SP 800-53, OSCAL-basierte Mappings zu ISO 27001, BSI IT-Grundschutz und unterstützt RMF-Phasen.

Diese Architektur erleichtert die Erstellung automatisierter SSPs, POA&Ms und Audit-Reports.

=== Praktisches Beispiel: Implementierung eines Systemsicherheitsplans ===
Ein konkretes Beispiel für die Anwendung von OSCAL ist die Erstellung eines Systemsicherheitsplans (SSP) für eine Bundesbehörde. Hier ein vereinfachtes XML-Beispiel:

<<?xml version="1.0" encoding="UTF-8"?>
<system-security-plan xmlns="http://csrc.nist.gov/ns/oscal/1.0">
<metadata>
<title>Beispiel-Systemsicherheitsplan</title>
<last-modified>2025-03-21T13:59:00+01:00</last-modified>
<version>1.0</version>
</metadata>
<import-profile href="https://example.com/fedramp-moderate-profile.xml"/>
<system-characteristics>
<system-id identifier-type="https://fedramp.gov">F00000000</system-id>
<system-name>Beispielsystem</system-name>
<description>
Dies ist eine Beschreibung des Beispielsystems.
</description>
<security-sensitivity-level>moderate</security-sensitivity-level>
</system-characteristics>
<system-implementation>
<component-definition>
<component uuid="11111111-2222-4000-8000-000000000000" type="software">
<title>Beispielkomponente</title>
<description>
Dies ist eine Beschreibung der Beispielkomponente.
</description>
</component>
</component-definition>
</system-implementation>
</system-security-plan>

Dieses Beispiel zeigt, wie OSCAL verwendet werden kann, um Systemcharakteristiken, Sicherheitseinstufungen und Komponenten in einem standardisierten, maschinenlesbaren Format zu dokumentieren. In der Praxis würde ein vollständiger SSP deutlich umfangreicher sein und detaillierte Informationen zu Sicherheitsanforderungen, deren Implementierung und Bewertung enthalten.

=== Glossar zu OSCAL-Abkürzungen ===
{| class="wikitable"
!Abkürzung
!Auflösung
!Beschreibung/Synonyme
|-
|OSCAL
|Open Security Controls Assessment Language
|Maschinenlesbare Sprache für Sicherheitskontrollen, Dokumentation und Bewertung (Syn.: OSCAL-Format) [page:<nowiki>https://wiki.isms-ratgeber.info/wiki/OSCAL</nowiki>]
|-
|SSP
|System Security Plan
|Plan zur Beschreibung der Systemumsetzung von Sicherheitskontrollen (Syn.: System-Sicherheitsplan)
|-
|AP
|Assessment Plan
|Bewertungsplan für Audits und Tests (Syn.: Assessment-Plan)
|-
|AR
|Assessment Results
|Bewertungsergebnisse mit Findings und Evidenz (Syn.: Assessment-Results)
|-
|POA&M
|Plan of Action and Milestones
|Maßnahmen- und Meilensteinplan zur Risikobehebung (Syn.: POAM)
|-
|RMF
|Risk Management Framework
|NIST-Rahmenwerk für Risikomanagement
|-
|NIST
|National Institute of Standards and Technology
|US-Behörde für Standards, Entwickler von OSCAL
|-
|ISMS
|Information Security Management System
|Managementsystem für Informationssicherheit (z. B. ISO 27001)
|-
|XML
|Extensible Markup Language
|Datenaustauschformat (OSCAL-kompatibel)
|-
|JSON
|JavaScript Object Notation
|Leichtgewichtiges Datenaustauschformat (OSCAL-kompatibel)
|-
|YAML
|YAML Ain’t Markup Language
|Menschenlesbares Datenaustauschformat (OSCAL-kompatibel)
|-
|FedRAMP
|Federal Risk and Authorization Management Program
|US-Cloud-Compliance-Programm mit OSCAL
|}

=== Quellen ===
[https://pages.nist.gov/OSCAL/ NIST: OSCAL the Open Security Controls Assessment Language]

[https://github.com/usnistgov/OSCAL NIST: Offizielles GitHub OSCAL-Repo]

[https://oscalfoundation.org/ OSCAL Fondation: Non-Profit-Organisation zur Förderung der Entwicklung, Adoption und Internationalisierung von OSCAL-Standards]

[https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Grundschutz-in-der-Informationssicherheit/Stand-der-Technik/OSCAL/oscal_node.html BSI: OSCAL Ein standardisiertes und maschinenlesbares Framework, das von <abbr>NIST</abbr> entwickelt wurde]

=== Fazit ===
OSCAL revolutioniert die Art und Weise, wie Organisationen Sicherheitsanforderungen dokumentieren, implementieren und bewerten. Durch die Standardisierung und Automatisierung dieser Prozesse ermöglicht OSCAL eine effizientere, genauere und skalierbarere Verwaltung von Informationssicherheit und Compliance. Mit der zunehmenden Komplexität von IT-Umgebungen und der wachsenden Zahl von Compliance-Anforderungen wird OSCAL zu einem unverzichtbaren Werkzeug für moderne Informationssicherheits-Managementsysteme.
[[Kategorie:Kurzartikel]]
__KEIN_INHALTSVERZEICHNIS__

RiLi-KI-Einsatz

2026-04-01T13:17:10Z

Dirk:

{{#seo:
|title=KI-Einsatz: ISMS-integration, EU AI Act, DSGVO, BSI Grundschutz
|keywords=KI-Einsatz, EU AI Act, ISO 27001, BSI IT-Grundschutz, DSGVO KI, KI-Risikomanagement, Informationssicherheit KI, Datenschutz KI
|description=KI in Unternehmen & Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.}}
{{SHORTDESC:Einführung zu sinnvollen Regelungen für den KI-Einsatz}}''KI-Einsatz in Unternehmen und Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.''

== Einleitung ==
Der Einsatz von Künstlicher Intelligenz (KI) in Unternehmen und Behörden gewinnt rasant an Bedeutung und stellt Informationssicherheits-Managementsysteme (ISMS) vor neue Herausforderungen. KI-Systeme verarbeiten oft personenbezogene Daten, treffen automatisierte Entscheidungen und erfordern eine nahtlose Integration in bestehende Standards wie ISO/IEC 27001 sowie BSI Grundschutz. Der EU AI Act (seit August 2024 rechtskräftig) etabliert einen risikobasierten Ansatz, der mit DSGVO und BDSG kompatibel ist und spezifische Anforderungen an Transparenz, Robustheit und Nachvollziehbarkeit stellt.

Für Behörden gelten zusätzlich öffentlich-rechtliche Bindungen (z.B. Grundrechte Art. 1–3 GG), während Unternehmen wirtschaftliche Risiken wie Vendor Lock-in oder Haftungsstreitigkeiten prüfen müssen. Dieser Artikel fasst rechtliche, datenschutzrechtliche, sicherheitstechnische und organisatorische Belange zusammen und verweist auf vertiefende Inhalte im Wiki sowie externe Quellen.

'''Relevanz für ISMS'''

KI-Einsatz beeinflusst die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) und erfordert [[Zusätzliche Gefährdungen|Ergänzungen]] der verwendeten Risikokataloge wie z.B. den BSI G0-Katalog. Ziel ist eine risikobasierte Implementierung des KI-Einsatzes.

== Rechtlicher Rahmen ==

* '''EU AI Act''': Risikobasierte Klassifikation (verboten, hochrisiko, geringes Risiko, GPAI). Zeitlicher Fahrplan (Verbote ab 2025, Hochrisiko ab 2026/2027). Anforderungen an Dokumentation, Konformität und Bußgelder.
* '''Nationale Regelungen''': DSGVO-Integration (Art. 10 KI-VO für biometrische Daten), BDSG, öffentlich-rechtliche Sonderbindungen (GG Art. 1–3) für Behörden.
* '''Sektorale Vorgaben''': Verwaltungsrecht, hessische/länderspezifische Initiativen für öffentlichen Sektor.

=== EU AI Act ===
Der EU AI Act klassifiziert KI-Systeme in vier Risikostufen:

* '''Unzulässig''' (z. B. Social Scoring, biometrische Echtzeit-Identifikation in öffentlichen Räumen) – Verbot ab Februar 2025.
* '''Hochrisiko''' (z. B. HR, Kreditvergabe, kritische Infrastruktur) – Konformitätsbewertung, Dokumentationspflichten und menschliche Aufsicht ab 2026/2027.
* '''Geringes Risiko''' – Transparenzpflichten (z. B. Chatbots).
* '''GPAI (General Purpose AI)''' – Risikoanalyse und technische Dokumentation für Modelle wie GPT-Varianten.

Bußgelder bis 35 Mio. € oder 7% Umsatz. Verantwortung liegt primär beim Provider, sekundär beim Deployer.

'''Weiterführende Informationen:'''

* [[EU AI Act|Wiki: EU AI Act]]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32024R1689 EU AI Act Volltext]

=== Nationale Regelungen ===

* '''Deutschland''': Ergänzungen durch BDSG (§ 35 Automatisierte Entscheidungen im Einzelfall einschließlich Profiling), KI-Strategie der Bundesregierung (2020/aktualisiert 2025). Behörden müssen öffentlich-rechtliche Prinzipien (Rechtsstaatlichkeit, Verhältnismäßigkeit) wahren.
* '''Länderspezifisch''': Hessische KI-Verordnung, bayrische Orientierungshilfen für öffentliche Verwaltung.
* '''Sektoral''': Finanzsektor (BaFin-MaRisk), Gesundheitswesen (DiGA-Verordnung).

'''Weiterführende Informationen:'''

* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Kuenstliche-Intelligenz/AIC4/aic4.html Kriterienkatalog für <abbr>KI</abbr>-Cloud-Dienste – <abbr>AIC4</abbr>]
* [https://www.gesetze-im-internet.de/bdsg_2018/__37.html BDSG: §37 Automatisierte Entscheidungen im Einzelfall einschließlich Profiling]

=== Übergangsregelungen und Neuklassifizierung ===
KI-Systeme müssen bei wesentlichen Änderungen neu klassifiziert werden. Bestehende Systeme bis 2027.

== Datenschutzrechtliche Aspekte ==

=== DSGVO-Konformität ===
KI-Trainingsdaten unterliegen Art. 5 DSGVO (Rechtsmäßigkeit, Zweckbindung). Bei biometrischen Daten: Art. 10 KI-VO (Verbot biometrische Kategorisierung). Datenschutz-Folgenabschätzung (DSFA, Art. 35) obligatorisch für Hochrisiko-Anwendungen.

'''Kernpflichten'''

* '''Trainingsdaten''': Bereinigung sensibler Daten, Pseudonymisierung, Löschung nach Zweck (Art. 17).
* '''Outputs''': Transparenz bei automatisierter Entscheidungsfindung (Art. 22), Recht auf Erklärung.
* '''AVV (Auftragsverarbeitung)''': Cloud-KI-Provider als Auftragsverarbeiter prüfen.

=== Orientierungshilfen ===

* '''Datenschutzkonferenz (DSK)''': Leitfaden „Künstliche Intelligenz und Datenschutz“ – Checkliste für Datensparsamkeit und Rechenschaftspflicht.
* '''BayLDA/LfDI''': Praktische Hinweise zu Shadow-KI und ChatGPT-Nutzung in Behörden.

=== Betroffenenrechte und Transparenz ===
Benutzende müssen über KI-Einsatz informiert werden (Art. 13/14). Erweiterte Informationspflichten bei GPAI: Modellkarte offenlegen. Bias-Tests dokumentieren, um Diskriminierungsverbot (Art. 21 GG) zu wahren.

'''Praktische Umsetzung'''
{| class="wikitable"
!Aspekt
!Maßnahme
!Rechtsgrundlage
|-
|DSFA
|Vor KI-Einsatz durchführen
|Art. 35 DSGVO
|-
|Rechteauskunft
|KI-spezifische Vorlage
|Art. 15 DSGVO
|-
|Löschung
|Trainingsdaten entfernen
|Art. 17 DSGVO
|}
'''Weiterführende Informationen:'''

* [https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf DSK: Orientierungshilfe zu datenschutzrechtlichen Besonderheiten generativer KI-Systeme mit RAG-Methode]
* [https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf DSK: Orientierungshilfe zu empfohlenen technischen und organisatorischen Maßnahmen bei der Entwicklung und beim Betrieb von KI-Systemen]
* [[KI Datenschutz|Wiki: Datenschutz in KI-Anwendungen.]]

== Sicherheitsaspekte (ISMS-Integration) ==
KI-Einsatz erfordert eine Erweiterung des ISMS um spezifische Gefährdungen, die die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) bedrohen und über den BSI IT-Grundschutz G0-Katalog hinausgehen. Nach BSI Standard 200-3 müssen diese in der Risikoanalyse bewertet und mit Maßnahmen aus ISO 27001 Anhang A (z. B. A.8.25 für sichere Entwicklung) kontrolliert werden.

=== Gefährdungskatalog-Ergänzungen ===
KI-spezifische Risiken wie folgt klassifiziert (CIA-Analyse):

* '''Prompt Injections''': Manipulation von Eingaben zu Large Language Models (hoch I/C).
* '''Data Poisoning''': Vergiftung von Trainingsdaten (hoch I, mittel A).
* '''Modelllecks''': Training Data Leakage oder IP-Exfiltration (hoch C).
* '''Unkontrollierte Nutzung von Schatten-KI''': Unkontrollierte Nutzung privater Tools (mittel C/I).
* '''Black-Box-Effekte''': Mangelnde Nachvollziehbarkeit (hoch I/A).

=== ISMS-Maßnahmen und Standards ===
* '''BSI KI-Kriterienkatalog (2025)''': Sicherheitsniveaus (Low/Medium/High) für generative KI, mit Tests auf Jailbreaks und Bias.
* '''ISO 27001 Anhang A''': A.8.25 Sichere Entwicklung, A.12.6 Vulnerability-Management.
* '''Risikobewertung''': Erweiterte Gefährdungsanalyse nach BSI 200-3, inklusive Supply-Chain-Risiken bei Cloud-KI-Providern.

'''Weiterführende Informationen:'''

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KI/Kriterienkatalog_KI-Modelle_Bundesverwaltung.html BSI KI-Kriterienkatalog 2025.]
* [[Zusätzliche Gefährdungen|Wiki: Zusätzliche Gefährdungen (ergänzt und spezifische KI-Gefährdungen)]]
* [[RiLi-KI-Einsatz|Wiki: Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)]]
* [[LF-KI-Sicherheit|Wiki: Leitfaden zur KI-Sicherheit]]
* [[LF-KI-Chatbots|Wiki: Leitfaden für Mitarbeitende zur Nutzung von KI-Systemen.]]

== Technische Aspekte ==
Technische Umsetzung von KI muss Robustheit, Nachvollziehbarkeit und Datensicherheit gewährleisten, um EU AI Act-Anforderungen (z. B. Art. 15 für Hochrisiko) und ISMS-Ziele zu erfüllen. Der Fokus liegt auf dem gesamten KI-Lebenszyklus.

=== Implementierungsprinzipien ===

* '''Daten-Governance''': Saubere Trainingsdaten (Preprocessing, Anonymisierung), RAG (Retrieval-Augmented Generation) statt reinem Fine-Tuning zur Vermeidung von Halluzinationen.
* '''Modellsicherheit''': Hardening-Techniken wie Adversarial Training, Modellkardinalität (Input/Output-Beschränkungen).
* '''Nachvollziehbarkeit (XAI)''': SHAP für globale Feature-Importance, LIME für lokale Erklärungen einzelner Vorhersagen – essenziell für Art. 22 DSGVO.

=== Lebenszyklus-Management ===
'''KI-System-Phasen und Sicherheitskontrollen'''
{| class="wikitable"
!Phase
!Technische Maßnahmen
!ISMS-Verknüpfung
|-
|Auswahl/Training
|Datenvalidierung, Secure MPC
|A.8.25 Entwicklung
|-
|Deployment
|Sandboxing, Human-in-the-Loop
|A.12.4 Monitoring
|-
|Betrieb
|Continuous Model Monitoring (Drift/Bias)
|A.12.6 Vulnerabilities
|-
|Decommissioning
|Modelllöschung, Audit-Logs
|A.18.1 Compliance
|}

=== Hochrisiko-Anwendungen ===

* '''Sektoren''': HR (Bias-Prüfung), Gesundheitswesen (FDA/DiGA-konform), kritische Infrastruktur (real-time Robustheit).
* '''Technische Standards''': ONNX für Modell-Portabilität, TensorFlow Privacy für Federated Learning.

'''Praktische Umsetzung'''

* '''Tools''': MLflow für Lifecycle-Tracking, Adversarial Robustness Toolbox (ART) für Angriffstests.
* '''Cloud-KI''': AWS SageMaker oder Azure ML mit integrierten Security-Features prüfen (AVV-pflichtig).

'''Weiterführende Informationen:'''

* [https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R1689#art_11 EU AI Act Artikel 11 - Technische Dokumentation]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R1689#anx_IV EU AI Act Anhang IV - Technische Dokumentation]
* [https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/Leitfaden_KI-Systeme_230124.html BSI Secure AI Guidelines.]
* [[KI-Register|Wiki: KI-Register]]
* [[KI Cybersicherheit|KI als Fluch und Segen in der Cybersicherheit.]]

== Governance und Organisation ==
Eine effektive KI-Governance stellt sicher, dass KI-Einsatz mit ISMS-Zielen (ISO 27001, BSI Grundschutz) übereinstimmt und EU AI Act-Anforderungen erfüllt. Sie umfasst organisatorische Strukturen, Prozesse und Verantwortlichkeiten, um Risiken wie Shadow-KI oder Bias zu minimieren. Die Geschäftsleitung trägt gemäß ISO 27001 Abschnitt 5.1 die oberste Verantwortung und muss KI-spezifische Richtlinien (A.5.1) etablieren.

=== KI-Governancestruktur ===

* '''KI-Steuerungsgremium''': Interdisziplinäres Gremium (IT-Sicherheit, Datenschutzbeauftragte, Rechtsabteilung, Fachabteilungen) für Risikobewertungen, Modellfreigaben und Audits. Regelmäßige Meetings (vierteljährlich) zur Überprüfung von KI-Projekten.

* '''Rollen und Verantwortlichkeiten''':<br>
{| class="wikitable"
!Rolle
!Aufgaben
!Rechtsgrundlage
|-
|KI-Provider (extern)
|Technische Dokumentation, Konformitätserklärung
|EU AI Act Art. 13
|-
|KI-Deployer (intern)
|Risikoanalyse, menschliche Aufsicht
|EU AI Act Art. 29
|-
|Datenschutzbeauftragte
|DSFA, Betroffenenrechte
|DSGVO Art. 39
|-
|ISMS-Leitung
|Integration in Risikomanagement
|ISO 27001 A.5.1
|}

* '''KI-Nutzungsrichtlinie''': Verbot privater KI-Tools (Shadow-KI), Pflicht zu genehmigten Modellen, Sanktionen bei Verstößen. Schulungspflicht für Mitarbeitende (KI-Literacy).

=== Prozesse und Workflows ===

* '''Risikobewertungsvorlage''': Vorlage für neue KI-Projekte mit CIA-Analyse, EU AI Act-Risikostufe und DSFA-Trigger. Workflow: Antrag → Gremium → Freigabe → Monitoring.
* '''Audit und Reporting''': Jährliche KI-Inventar (alle Systeme auflisten), Incident-Reporting für Bias-Vorfälle oder Modell-Drift. Integration in ISO 27001 Management Review (Abschnitt 9.3).
* '''Schulungen''': Obligatorische Einstiegsschulung zu KI-Risiken (~2h), vertiefte für Entwickler (XAI, Secure Coding). Nachweis via LMS.

=== Besonderheiten für Behörden ===

* '''Grundrechtsschutz''': Zusätzliche Prüfung auf Verhältnismäßigkeit (GG Art. 1–3), Transparenz gegenüber Bürger:innen. Beliehene Unternehmen (z. B. Zeugnisstellen) fallen unter öffentlich-rechtliche Standards.
* '''Öffentliche Unternehmen''': Archivierungspflicht für KI-Entscheidungen.

'''Praktische Umsetzung'''

* '''Checkliste für KI-Projekte''':
*# Risikostufe bestimmen,
*# Provider prüfen,
*# DSFA durchführen,
*# Technische Dokumentation anlegen,
*# Monitoring einrichten.
* '''Vorlage''': KI-Risikobewertungstabelle (Excel) mit Spalten für Gefährdung, Wahrscheinlichkeit, Schaden, Maßnahmen.

'''Weiterführende Informationen:'''

* Wiki: ISMS-Organisation
* ISO 27001:2022 Abschnitt 5 (Führung).

== Weiterführende Quellen ==

=== Primärquellen (Gesetze und Verordnungen) ===

* '''EU AI Act''': Volltext – Offizielle Übersetzung, Anhang mit Hochrisiko-Listen.
* '''DSGVO''': Art. 22, 35 – Automatisierte Entscheidungen, DSFA.
* '''BDSG''': § 35 – Automatisierte Entscheidungen im öffentlichen Recht.

=== Behörden und Standardisierungsgremien ===

* '''BSI''':
** KI-Kriterienkatalog 2025 – Testszenarien für generative KI.
** IT-Grundschutz Compendium – G0-Module.
* '''Datenschutzkonferenz (DSK)''': Leitfaden KI und Datenschutz – Praktische Checkliste.
* '''BayLDA''': KI & Datenschutz – Orientierung für Behörden.

=== Branchenverbände und Ratgeber ===

* '''IHK München''': Datenschutz & KI – Praktische Hinweise für KMU.
* '''Bitkom''': KI-Guide für Unternehmen – Best Practices.
* '''BaFin''': MaRisk für KI im Finanzsektor.

=== Technische Ressourcen ===

* '''XAI-Tools''': SHAP-Dokumentation, LIME – Open Source für Erklärbarkeit.
* '''Secure AI Frameworks''': Adversarial Robustness Toolbox – Tests auf Angriffe.

=== Wiki-interne Verweise ===

* [[EU AI Act]]
* [[KI Cybersicherheit]]
* [[KI Datenschutz]]
* [[KI-Nutzung]]
* [[KI-Register]]
* [[LF-KI-Chatbots]]
* [[RiLi-KI-Einsatz]]
* [[Zusätzliche Gefährdungen]]

[[Kategorie:Artikel]]
[[Kategorie:KI]]

LF-KI-Sicherheit

2026-04-01T13:16:20Z

Dirk: Die Seite wurde neu angelegt: „{{#seo: |title=Leitfaden KI-Sicherheit: Härtung, Modellsicherheit und Nachvollziehbarkeit |keywords=KI-Härtung, Modellsicherheit, Nachvollziehbarkeit, AI-Hardening, KI-Risiken, KI-Logging, KI-Audit, EU AI Act, ISMS, ISO 27001 |description=Fachlicher Leitfaden zur KI-Sicherheit mit Maßnahmen für Härtung, Modellsicherheit und Nachvollziehbarkeit. Mit Anforderungen, Prüfkriterien und Best Practices für Unternehmen. }}{{SHORTDESC:Härtung, Modellsiche…“

{{#seo:
|title=Leitfaden KI-Sicherheit: Härtung, Modellsicherheit und Nachvollziehbarkeit
|keywords=KI-Härtung, Modellsicherheit, Nachvollziehbarkeit, AI-Hardening, KI-Risiken, KI-Logging, KI-Audit, EU AI Act, ISMS, ISO 27001
|description=Fachlicher Leitfaden zur KI-Sicherheit mit Maßnahmen für Härtung, Modellsicherheit und Nachvollziehbarkeit. Mit Anforderungen, Prüfkriterien und Best Practices für Unternehmen.
}}{{SHORTDESC:Härtung, Modellsicherheit und Nachvollziehbarkeit}}''Dieses Leitfaden beschreibt technische Maßnahmen zur Absicherung von KI-Systemen im ISMS-Kontext. Es adressiert Lücken in der Umsetzung von EU AI Act (Art. 15, 13), BSI Grundschutz und ISO 27001 A.8.25ff. Die Maßnahmen gewährleisten Robustheit gegen Angriffe, Modellschutz und prüfbare Nachverfolgbarkeit. Sie sind für Hochrisiko-KI-Systeme zwingend erforderlich, um Haftungsrisiken zu minimieren und Audits zu bestehen.''

== Einleitung ==
Künstliche Intelligenz (KI) birgt erhebliche Sicherheitsrisiken, die durch den EU AI Act und nationale Standards wie BSI Grundschutz adressiert werden müssen. Dieser Leitfaden beschreibt die technischen Maßnahmen zu '''KI-Härtung''', '''Modellsicherheit''' und '''Nachvollziehbarkeit''', die für den sicheren Einsatz von KI-Systemen im Unternehmen zwingend erforderlich sind.

'''Zielgruppe:''' IT-Sicherheitsverantwortliche, Data Scientists und ISMS-Beauftragte.

'''Sinn und Zweck:''' Bereitstellung implementierbarer und prüfbarer Maßnahmen zur Erfüllung von EU AI Act Art. 12-15, Konformität mit ISO 27001 und Vermeidung von Haftungsrisiken. Die Maßnahmen ermöglichen Audits, schützen vor Angriffen und gewährleisten die Nachverfolgbarkeit kritischer Entscheidungen.

Die nachfolgenden Kapitel leiten direkt aus den gesetzlichen Pflichten ab und enthalten konkrete Umsetzungsschritte mit Prüfkriterien.

== Rechtliche Grundlagen und Pflichten ==
Die Maßnahmen basieren auf zwingenden Anforderungen des '''EU AI Act''' und nationaler Standards:

* '''EU AI Act Art. 15''' (Hochrisiko-KI): Robustheit gegen Angriffe, Cybersicherheit, Härte-Maßnahmen.
* '''EU AI Act Art. 13''': Transparenzpflichten inklusive technischer Dokumentation und Nachvollziehbarkeit.
* '''EU AI Act Art. 12''': Qualitätsmanagement mit Risikobewertung und Auditfähigkeit (10-Jahre-Dokumentation).

'''Ziel:''' Haftungsminimierung, Audits bestand, Konformität mit NIS2 und DSGVO.

== KI-Härtung (Robustheit gegen Angriffe) ==
KI-Härtung schützt KI-Systeme vor manipulierenden Angriffen durch Erhöhung der Robustheit. Sie verhindert, dass Angreifer Modelle durch gezielte Eingaben (Prompt Injection, Adversarial Examples) umgehen oder gefährliche Ausgaben provozieren.

=== Input-Sanitization ===
Input-Sanitization filtert bösartige Eingaben vor der Modellverarbeitung. Sie blockiert Jailbreak-Versuche, SQL-Injection und Prompt Injections, die Modelle zu unzulässigen Antworten zwingen. Erforderlich durch EU AI Act Art. 15 (Robustheit).

'''Best-Practice-Umsetzung:'''

* Bibliothek <code>llm-guard</code> oder <code>neural-classifier</code> für Input-Vorfilterung.
* Regex-Regeln für bekannte Angriffsmuster (<code>ignore previous instructions</code>, <code>sudo</code>, Base64-Payloads).
* Whitelisting erlaubter Zeichenmengen (alphanumerisch + begrenzte Sonderzeichen).
* Implementierung als Middleware (FastAPI/Flask): <code>request.input = sanitize(request.input)</code>.

=== Rate Limiting ===
Begrenzt API-Aufrufe pro Benutzer/IP, um Denial-of-Service (DoS) und Brute-Force-Angriffe zu verhindern. Schützt Rechenressourcen und ermöglicht Anomalie-Erkennung.

'''Best-Practice-Umsetzung:'''

* Redis-basiertes Sliding-Window-Limiting: 100 Requests/Stunde pro User-ID/IP.
* Framework-Integration: FastAPI-Limiter (<code>slowapi</code>), Django-RateLimit.
* Headers setzen: <code>X-RateLimit-Remaining</code>, <code>Retry-After</code>.
* Monitoring: Prometheus-Metriken für Rate-Limit-Hits.

=== Output-Moderation ===
Prüft Modell-Ausgaben auf Toxizität, Hate Speech oder sensible Datenlecks vor Auslieferung. Verhindert rechtliche Haftung durch schädliche Inhalte.

'''Best-Practice-Umsetzung:'''

* OpenAI Moderation API oder HuggingFace <code>unitary/toxic-bert</code>.
* Kategorien: Hate, Violence, Self-Harm, PII (Personendaten).
* Block-Regel: Score > 0.7 → Antwort verweigern mit "Inhalt nicht zulässig".
* Fallback: Statische Regex für Kreditkarten/SVNr.

=== Adversarial Training ===
Trainiert Modelle mit feindlichen Beispielen, sodass sie Angriffe erkennen und abwehren. Erhöht Robustheit gegen OWASP LLM Top 10-Attacken.

'''Best-Practice-Umsetzung:'''

* Dataset: OWASP LLM Top 10 + Anthropic Red-Team-Dataset.
* Fine-Tuning: LoRA-Adapter auf bestehendem Modell (1-2% zusätzlicher VRAM).
* Metriken: Attack Success Rate (ASR) <5% nach Training.
* Tools: <code>trl</code> (Transformers Reinforcement Learning), <code>adversarial-robustness-toolbox</code>.

=== Container-Härtung ===
Sichert den KI-Deploy-Container gegen Privilege Escalation und Side-Channel-Angriffe. Entspricht CIS Docker Benchmarks.

'''Best-Practice-Umsetzung:'''

* Non-root User (<code>USER 1000:1000</code> im Dockerfile).
* AppArmor/SELinux-Profil für KI-Prozess.
* Read-only Root-Filesystem (<code>--read-only</code> bei <code>docker run</code>).
* Seccomp-Filter: Nur <code>read/write/socket</code> erlauben.
* Image-Scan: Trivy vor Deploy.

=== Prüfkriterien und Prüfungsmodalitäten für KI-Härtung ===
'''Übergeordnetes Kriterium:''' Sicherheits-Test durch externe Experten mit weniger als 5% Angriffserfolg über alle Maßnahmen.

==== Input-Sanitization – Prüfkriterium und Umsetzung ====
'''Kriterium:''' 95% der bekannten gefährlichen Eingaben werden erkannt und blockiert.

'''Prüfungsmodalitäten:'''

1. Test-Suite: 500+ Angriffsvektoren (DAN-Jailbreaks, Base64-Payloads, Unicode-Exploits)
2. Tool: llm-attacks oder garak (automatisierte Tests)
3. Erfolg: Blockquote ≥95%, False-Positive-Rate <1%
4. Dokumentation: Test-Report mit Pass/Fail pro Vektor

'''Umsetzung:''' Wöchentlicher Test mit bekannten Angriffsmustern → Bericht per E-Mail.

==== Rate Limiting – Prüfkriterium und Umsetzung ====
'''Kriterium:''' Kein Benutzer kann mehr als 100 Anfragen pro Stunde stellen.

'''Prüfungsmodalitäten:'''
1. Load-Test: Apache Bench (ab -n 200 -c 10)
2. Überprüfung: Redis-Keys `ratelimit:ip:X` TTL ≤3600s
3. Response: HTTP 429 mit Retry-After Header bei Überschreitung
4. Metriken: Prometheus `ratelimit_hits_total > 0`

'''Umsetzung:''' Monatliche Lasttests mit Tools wie Apache Bench.

==== Output-Moderation – Prüfkriterium und Umsetzung ====
'''Kriterium:''' 98% der gefährlichen Antworten werden erkannt.

'''Prüfungsmodalitäten:'''
1. Dataset: HuggingFace "unitary/toxic-bert" Testset (10.000 Samples)
2. Threshold: F1-Score ≥0.95 bei Hate/Violence/Self-Harm
3. Audit: 100% manuelle Stichprobe kritischer Outputs
4. Log: Moderation-Ergebnisse 90 Tage auffindbar

'''Umsetzung:''' Vierteljährliche Tests mit öffentlichen Test-Datensätzen.

==== Adversarial Training – Prüfkriterium und Umsetzung ====
'''Kriterium:''' Angriffe gelingen in weniger als 5% der Fälle nach Training.

'''Prüfungsmodalitäten:'''
1. Benchmark: OWASP LLM Top 10 + Anthropic Red-Team (1.000 Angriffe)
2. Metrik: ASR = erfolgreiche Angriffe / Gesamtangriffe
3. Baseline-Vergleich: Vorher/Nachher ASR-Differenz ≥80%
4. Periodisch: Quartalsweise Re-Test nach Modell-Updates

'''Umsetzung:''' Automatisierte Tests nach jedem Modell-Update.

==== Container-Härtung – Prüfkriterium und Umsetzung ====
'''Kriterium:''' Container erfüllt 30+ Sicherheitsregeln (Docker-Standard).

'''Prüfungsmodalitäten:'''
1. Scan: Trivy `trivy image ki-app:latest` → 0 Criticals
2. Runtime: `docker-bench-security` → ≥95% Compliance
3. Prozess: `ps aux | grep ki-app` → non-root User
4. Netzwerk: `docker inspect` → No privileged ports (<1024)

'''Umsetzung:''' Wöchentliche automatische Scans aller Container.

==== Übergeordnete Sicherheitsprüfung ====
Empfehlenswert ist ein regelmäßiger Prüf- und Auditzyklus z.B.: interne monatliche oder quartalsmäßige Prüfung und jährliche externe Prüfung

'''Alle Testergebnisse 10 Jahre aufbewahren''' (gesetzliche Pflicht EU AI Act).

== Modellsicherheit (Integritätsschutz) ==
Modellsicherheit schützt das trainierte KI-Modell vor Diebstahl, Manipulation und unbefugter Nutzung während des gesamten Lebenszyklus.

=== Model Cards ===
Model Cards sind standardisierte Dokumente, die Architektur, Trainingsdaten, Leistung und Risiken des Modells beschreiben. Sie ermöglichen Transparenz und sind für Audits erforderlich (EU AI Act Art. 13).

'''Best-Practice-Umsetzung:'''

* Vorlage nach HuggingFace-Standard verwenden
* Inhalte: Modelltyp, Parameteranzahl, Trainingsdatenmenge, Bias-Metriken
* Automatische Generierung mit Tools wie <code>model-card-toolkit</code>
* Im Versionskontrollsystem (Git) als Markdown-Datei speichern

=== Integritätsprüfung ===
Überprüft vor jeder Nutzung, ob das Modell manipuliert wurde. Verhindert Einsatz beschädigter oder vergifteter Modelle.

'''Best-Practice-Umsetzung:'''

* SHA-256-Hash des Originalmodells berechnen und signieren
* Vor Inference: Hash vergleichen → bei Abweichung Notfall-Stopp
* Digitale Signatur mit GPG oder Hardware Security Module (HSM)
* Automatisierte Prüfung als Docker-Entry-Point-Script

=== Output-Watermarking ===
Fügt unsichtbare Markierungen in KI-Ausgaben ein, um deren Herkunft nachzuweisen. Schützt vor Missbrauch und Plagiat.

'''Best-Practice-Umsetzung:'''

* Token-basierte Watermarks (OpenAI-Methode): Spezielle Token-Wahrscheinlichkeiten
* Text-Watermarking: Synonyme-Ersetzung nach festem Muster
* Bild-Watermarking: LSB-Steganographie (Least Significant Bit)
* Detektions-Tool parallel bereitstellen

=== Differential Privacy ===
Verhindert, dass einzelne Trainingsdaten aus Modell-Ausgaben rekonstruiert werden können. Schützt personenbezogene Daten (DSGVO).

'''Best-Practice-Umsetzung:'''

* Training mit DP-SGD (Differential Privacy Stochastic Gradient Descent)
* Privacy Budget ε=1.0 (Branchenstandard)
* Bibliothek: Opacus (PyTorch) oder TensorFlow Privacy
* Privacy-Audit: Membership Inference Attack Tests

=== SBOM (Software Bill of Materials) ===
Vollständige Liste aller Komponenten des KI-Systems für Supply-Chain-Sicherheit. Ermöglicht Schwachstellen-Management.

'''Best-Practice-Umsetzung:'''

* CycloneDX-Format für Python/ML-Umgebungen
* Automatische Generierung: <code>cyclonedx-py</code> oder GitHub Dependency Graph
* Dependency-Scan: Snyk/Trivy vor Deploy
* Versionspflicht: Jede Komponente mit exakter Versionsnummer

=== Prüfkriterien und Prüfungsmodalitäten für Modellsicherheit ===
'''Übergeordnetes Kriterium:''' 100% der Modelle sind vollständig dokumentiert und integritätsgesichert.

==== Model Cards – Prüfkriterium und Umsetzung ====
'''Kriterium:''' Jede Modellversion hat vollständige Model Card (10+ Kategorien).

'''Prüfungsmodalitäten:'''
1. Vollständigkeits-Check: Checkliste mit Pflichtfeldern
2. Aktualität: Model Card ≤ 3 Monate alt
3. Qualität: Techniker können Modell aus Card reproduzieren
4. Audit: Jährliche Stichprobe 20% aller Model Cards

'''Umsetzung:''' Git-Hook blockiert Commits ohne Model Card.

==== Integritätsprüfung – Prüfkriterium und Umsetzung ====
'''Kriterium:''' 100% Integritätsprüfung vor jeder Modellnutzung.

'''Prüfungsmodalitäten:'''
1. Log-Analyse: Alle Inference-Starts mit Hash-Check
2. Fehlerrate: 0 Integritätsfehler pro Monat
3. Recovery-Test: Manipuliertes Modell wird erkannt
4. Signatur-Validierung: GPG-Key korrekt

'''Umsetzung:''' Monatliche Log-Auswertung und Alarm bei Fehlern.

==== Output-Watermarking – Prüfkriterium und Umsetzung ====
'''Kriterium:''' 95% Detektionsrate bei Watermark-Prüfung.

'''Prüfungsmodalitäten:'''
1. Test-Suite: 1.000 Ausgaben mit/ohne Watermark
2. False-Positive-Rate: <1%
3. Robustheit: Watermark übersteht Copy-Paste/OCR
4. Dokumentation: Detektions-Tool verfügbar

'''Umsetzung:''' Wöchentliche Batch-Tests mit Testausgaben.

==== Differential Privacy – Prüfkriterium und Umsetzung ====
'''Kriterium:''' Privacy Budget ε ≤ 1.0 nach Training.

'''Prüfungsmodalitäten:'''
1. Privacy-Audit: Membership Inference Attack <5% Erfolg
2. ε-Berechnung: Auditor bestätigt korrekte Berechnung
3. Dokumentation: Training-Logs mit Privacy-Metriken
4. Zertifikat: Privacy-Bericht verfügbar

'''Umsetzung:''' Audit nach jedem Training.

==== SBOM – Prüfkriterium und Umsetzung ====
'''Kriterium:''' Vollständiger, aktueller SBOM für jedes KI-System.

'''Prüfungsmodalitäten:'''
1. Vollständigkeit: 100% aller Dependencies erfasst
2. Aktualität: SBOM ≤ 30 Tage alt
3. Schwachstellen: Keine Critical Vulnerabilities
4. Validierung: CycloneDX-Schema-Check

'''Umsetzung:''' CI/CD-Pipeline generiert SBOM automatisch.

== Nachvollziehbarkeit (Traceability) ==
Nachvollziehbarkeit ermöglicht die Rekonstruktion jeder KI-Entscheidung für Audits und Vorfälle (EU AI Act Art. 12-13, 10-Jahre-Pflicht).

=== Vollständiges Inference-Logging ===
Protokolliert alle KI-Anfragen und Antworten vollständig. Ermöglicht Nachverfolgung von Fehlentscheidungen oder Missbrauch.

'''Best-Practice-Umsetzung:'''

* Log-Einträge: User-ID, Timestamp, Input, Output, Modell-Version, Rechenzeit
* JSON-Format mit strukturierten Feldern
* Speicherung in Elasticsearch oder PostgreSQL (append-only)
* Retention: 10 Jahre (gesetzlich vorgeschrieben)

=== End-to-End-Audit-Trails ===
Verknüpft alle Schritte einer KI-Entscheidung von der Eingabe bis zur finalen Ausgabe. Notwendig für Haftungsfragen.

'''Best-Practice-Umsetzung:'''

* MLflow oder Weights&Biases für Experiment-Tracking
* Jeder Inference-Request erhält eindeutige Request-ID
* Chain-of-Thought-Logging (Zwischenschritte des Modells)
* API: <code>/audit/{request_id}</code> für Nachverfolgung

=== Explainability für kritische Entscheidungen ===
Zeigt auf, warum das Modell eine bestimmte Entscheidung getroffen hat. Erforderlich bei Hochrisiko-Anwendungen.

'''Best-Practice-Umsetzung:'''

* SHAP/LIME für Feature Importance (wichtigste Einflussfaktoren)
* Bei Bild-KI: Grad-CAM Heatmaps
* Erklärung als Text + Grafik im Log speichern
* Nur für kritische Entscheidungen (Schwellenwert-basiert)

=== Versionskontrolle Modelle/Daten ===
Jede Entscheidung ist exakt einer Modell-/Daten-Version zuzuordnen. Verhindert "Wer hat welches Modell verwendet?"-Probleme.

'''Best-Practice-Umsetzung:'''

* DVC (Data Version Control) für Datasets und Modelle
* Git-Tags für Modell-Releases (v1.2.3)
* Jeder Log-Eintrag enthält <code>model_hash</code> und <code>data_version</code>
* Container-Images mit Digest (SHA-256)

=== SIEM-Integration und Anomalie-Erkennung ===
Erkennt ungewöhnliches KI-Verhalten automatisch und leitet Alarme ein. Erfüllt ISO 27001 Überwachungspflichten.

'''Best-Practice-Umsetzung:'''

* Logs in Splunk/ELK-Stack einspielen
* Anomalie-Detektoren: Zu viele Token, ungewöhnliche Anfragen, Spitzenzeiten
* Alerting: Slack/PagerDuty bei >10x normalem Verbrauch
* Dashboard mit KI-spezifischen Metriken

=== Prüfkriterien und Prüfungsmodalitäten für Nachvollziehbarkeit ===
'''Übergeordnetes Kriterium:''' Jede KI-Entscheidung vollständig nachvollziehbar innerhalb 24 Stunden.

==== Inference-Logging – Prüfkriterium und Umsetzung ====
'''Kriterium:''' 100% aller KI-Anfragen protokolliert (keine Lücken).

'''Prüfungsmodalitäten:'''
1. Log-Vollständigkeit: Request-Count vs. Log-Count = 100%
2. Format-Check: JSON-Schema-Validierung
3. Retention-Test: Daten aus 2025 abrufbar
4. Performance: Logging <50ms Overhead pro Request

'''Umsetzung:''' Täglicher Log-Completeness-Check per Cron-Job.

==== Audit-Trails – Prüfkriterium und Umsetzung ====
'''Kriterium:''' Request-ID Nachverfolgung von Input zu Output in <5 Sekunden.

'''Prüfungsmodalitäten:'''
1. End-to-End-Test: 100 zufällige Request-IDs prüfen
2. Chain-of-Thought: Zwischenschritte vollständig
3. Suchzeit: Elasticsearch Query <2s für 1 Jahr Daten
4. API-Test: /audit/{id} liefert vollständige Spur

'''Umsetzung:''' Monatliche Stichproben mit Zufalls-Request-IDs.

==== Explainability – Prüfkriterium und Umsetzung ====
'''Kriterium:''' 95% der kritischen Entscheidungen mit Erklärung versehen.

'''Prüfungsmodalitäten:'''
1. Abdeckung: Kritische Entscheidungen = Erklärungen
2. Qualität: Erklärung verständlich für Nicht-Experten
3. Performance: SHAP-Berechnung <2s pro Anfrage
4. Speicherung: Erklärungen 10 Jahre haltbar

'''Umsetzung:''' Wöchentliche Prüfung kritischer Logs.

==== Versionskontrolle – Prüfkriterium und Umsetzung ====
'''Kriterium:''' 100% der Logs enthalten korrekte Modell-/Daten-Version.

'''Prüfungsmodalitäten:'''
1. Hash-Validierung: model_hash existiert in Registry
2. Reproduzierbarkeit: Gleiches Modell = gleiche Ausgabe
3. Versions-Historie: 12 Monate rückverfolgbar
4. Daten-Integrität: DVC-Status clean

'''Umsetzung:''' Tägliche Validierung neuer Logs.

==== SIEM-Integration – Prüfkriterium und Umsetzung ====
'''Kriterium:''' Anomalien innerhalb 15 Minuten erkannt und eskaliert.

'''Prüfungsmodalitäten:'''
1. Alert-Test: Simulierte Anomalie → Alarm in <15min
2. False-Positive-Rate: <5 pro Woche
3. Dashboard: Alle KI-Metriken real-time sichtbar
4. Incident-Response: 95% Alarme innerhalb SLA bearbeitet

'''Umsetzung:''' Wöchentliche Anomalie-Simulationstests.

== Verantwortlichkeiten ==
Die Maßnahmen erfordern eine klare Rollenverteilung über IT-Sicherheit, Entwicklung und Nutzung hinaus.

Auch '''Mitarbeitende''' tragen Mitverantwortung durch korrekte Bedienung und Meldung von Anomalien.
{| class="wikitable"
! Rolle !! Aufgaben !! KPIs
|-
| '''CISO''' || ISMS-Integration, Audit-Planung || 100% Konformität
|-
| '''Data Scientists''' || Model Cards, Training-Sicherheit || 100% Modelle dokumentiert
|-
| '''IT-Admin''' || Logging, Container-Härtung || 99,9% Logging-Verfügbarkeit
|-
| '''Datenschutzbeauftragte''' || DSGVO-Privacy (ε=1.0) || Privacy-Audits bestanden
|-
|'''Mitarbeitende'''
|Nur erlaubte Nutzung, richtige Bedienung, Anomalien melden
|95% korrekte Nutzung, 100% Incident-Meldung
|}

'''Nächste Schritte:''' Integration in ISMS-Prozesse, erste Red-Team-Tests.

== Umsetzung ==
Die Umsetzung erfolgt in '''vier Phasen''' mit klarer Priorisierung. Jede Phase baut auf der vorherigen auf und kann parallel mit begrenzten Ressourcen begonnen werden.

=== Phase 1: Sofortmaßnahmen (Grundschutz) ===
Diese Maßnahmen schützen innerhalb von Tagen vor den häufigsten Angriffen:

# '''Input/Output-Filter''' aktivieren (llm-guard, Moderation API)
# '''Logging-Infrastruktur''' aufsetzen (ELK/PostgreSQL, JSON-Format)
# '''Rate Limiting''' implementieren (Redis, 100 Requests/Stunde)
# '''Wartungsmodus''' für Tests definieren

=== Phase 2: Dokumentationspflicht ===
Erstellt die Audit-Grundlage für EU AI Act Konformität:

# '''Model Cards''' für alle produktiven Modelle erstellen
# '''SBOMs''' für KI-Systeme generieren (cyclonedx-py)
# '''Versionskontrolle''' einrichten (DVC/Git für Modelle/Daten)
# '''Integritätsprüfungen''' automatisieren (SHA-256 vor Inference)

=== Phase 3: Erweiterte Härte-Maßnahmen ===
Erhöht die Robustheit gegen komplexe Angriffe:

# '''Adversarial Training''' für kritische Modelle (LoRA, OWASP Dataset)
# '''Container-Härtung''' (non-root, AppArmor, Trivy Scans)
# '''Differential Privacy''' bei neuen Trainings (Differential Privacy mit Branchenstandard ε=1.0)
# '''Watermarking''' für Text/Bild-Outputs implementieren

=== Phase 4: Laufende Prüfung und Optimierung ===
Stellt dauerhafte Konformität sicher:

# '''Automatisierte Tests''' einrichten (garak, docker-bench-security)
# '''SIEM-Integration''' mit Anomalie-Erkennung (ELK + Alerts)
# '''Erste interne Prüfung''' aller Maßnahmen durchführen
# '''Externe Red-Team-Prüfung''' beauftragen (jährlich)

'''Monitoring:'''
* Wöchentliche Automatiktests mit Berichten
* Monatliche Stichproben der Logs
* Jährliche externe Validierung
* Alle Testergebnisse 10 Jahre archivieren (EU AI Act)

== Fazit ==
Die beschriebenen Maßnahmen zu '''KI-Härtung''', '''Modellsicherheit''' und '''Nachvollziehbarkeit''' bilden die technische Grundlage für konforme KI-Nutzung in Behörden oder Unternehmen. Sie erfüllen die zwingenden Anforderungen des EU AI Act (Art. 12-15) und des BSI Grundschutz, minimieren Haftungsrisiken und gewährleisten Auditfähigkeit.

'''Sofortige Umsetzung priorisieren:'''

# Logging-Infrastruktur – schnellste Wirkung, geringer Aufwand
# Input/Output-Filter – sofortiger Angriffsschutz
# Model Cards für bestehende Modelle – Audit-Vorbereitung

'''Langfristig:''' Jährliche Red-Team-Tests und kontinuierliche Weiterentwicklung der Maßnahmen entsprechend neuer Bedrohungen ([https://genai.owasp.org/llm-top-10/ OWASP LLM Top 10 Updates]).

Die Integration in bestehende ISMS-Prozesse schafft Wettbewerbsvorteile durch '''vertrauenswürdige KI''' und erfüllt regulatorische Pflichten gleichzeitig. Beginne mit dem Umsetzungsplan – die rechtlichen Fristen laufen.

== Weiterführende Quellen ==

* [https://www.allianz-fuer-cybersicherheit.de/SharedDocs/Downloads/Webs/ACS/DE/Kreise/Expertenkreis_KI_LLMs.pdf BSI/ACS Leitfaden für Penetrationstests von Large-Language-Modellen (LLMs)]
* [https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf NIST AI Risk Management Framework (RMF 1.0)]
* [https://genai.owasp.org/download/46119/?tmstv=1741814262|OWASP OWASP Top 10 für LLM-Applikationen (v 2025 de)]

[[Kategorie:Artikel]]
[[Kategorie:KI]]
[[Kategorie:Leitfaden]]

Willkommen im ISMS-Ratgeber WiKi

2026-04-01T13:15:04Z

Dirk:

{{#seo:
|title=ISMS-Ratgeber WiKi - Leitfaden für Informationssicherheit und Datenschutz
|description=Das ISMS-Ratgeber-Wiki bietet umfassende Informationen, Tools und Anleitungen zu Informationssicherheit, Datenschutz, BSI IT-Grundschutz ISO 27001 und anderen Standards.
}}{{SHORTDESC:Das freie ISMS-Ratgeber Wiki für Informationssicherheit und Datenschutz}}
Das ISMS-Ratgeber Wiki bietet umfassende Informationen und Ressourcen für den Aufbau eines Informationssicherheits-Managementsystems (ISMS). Es hilft, die Anforderungen von ISMS-Standards wie dem BSI IT-Grundschutz oder ISO/IEC 27001 zu erfüllen. Das Wiki stellt praxisnahe Informationen, Vorlagen und Leitfäden zur Verfügung, die die tägliche Arbeit unterstützen und den Einführungsprozess effizienter gestalten, da auf erprobte Methoden und dokumentierte Best Practices zugegriffen werden kann. Dies erleichtert die Erstellung, Verwaltung und kontinuierliche Verbesserung der Sicherheitsprozesse in der Organisation.

Das WiKi richtet sich an IT-Sicherheitsbeauftragte, Sicherheitsmanager und IT-Verantwortliche. Das WiKi ist öffentlich lesbar, die Inhalte sind frei nutzbar. Das Erstellen und Bearbeiten von Artikeln erfordert jedoch eine Registrierung als Benutzer. Jeder ist eingeladen, aktiv an den Inhalten mitzuarbeiten, eine gewisse Fachkompetenz sollte jedoch vorhanden sein, um die Qualität der Inhalte zu gewährleisten.

Für die organisationsübergreifende Zusammenarbeit und den gemeinsamen Austausch gibt es ein Forum auf Basis von HumHub. Unter [https://humhub.isms-ratgeber.info humhub.isms-ratgeber.info] stehen Foren/Workspaces zu verschiedenen Themen zum Austausch zur Verfügung. Die Registrierung ist wie hier im WiKi kostenlos.<br>
{| width="100%"
|-

|style="vertical-align:top" |

<h2 {{MainpageTopBox}}>
Für Einsteiger
</h2>
<div {{MainpageMidBox}}>
Informationen für Einsteiger und Anfänger.
*[[ISMS-Einführung|Einführung: Was ist ein ISMS?]]
*[[ISMS-Ratgeber-WiKi|Über das ISMS-Ratgeber Wiki]]
*[[ISMS-Ratgeber Anleitung|Anleitung zur Nutzung des ISMS-Ratgeber Wiki]]
*[[Mustervorlagen|Nutzung der Mustervorlagen]]
*[[Sicherheitsprojekte|Durchführung eines Sicherheitsprojekts]]
*[[QuickCheck|Ein QuickCheck zum Stand der Informationssicherheit]]
*[[Abkürzungen|Glossar]]
*[[Hilfe|allgemeine Wiki Hilfe]]
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>

<h2 {{MainpageTopBox}}>
Grundlagenartikel
</h2>
<div {{MainpageMidBox}}>
Grundlagenartikel mit ausführlichen Hintergrundinformationen zu bestimmten Themen und allgemeine Artikel.
*[[ISMS_Step_by_Step|Aufbau eines ISMS Step by Step (KMU)]]
*[[Geschäftsprozesse]]
*[[Dokumentenerstellung|Hilfen zur Dokumentenerstellung]]
*[[Managementbericht|Erstellen eines Managementberichts]]
*[[Betriebsdokumentation|Hilfen für Betriebsdokumentation]]
*[[Reifegradmodell|Erstellen eines Reifegradmodells]]
*[[KPIs|Key Performance Indicators (KPIs)]]
*[[Authentisierung|Methoden zur Authentisierung]]
*[[Klassifizierung|Klassifizierung von Informationen (Schutzstufen)]]
*[[Normen und Standards|Normen und Standards rund um das ISMS]]
*[[Bildkampagne|Sensibilisierung mit Bildkampagnen]]
*[[Online Prüftools|Liste von Online-Prüftools]]
*[[Referenzdokumente|Erforderliche Referenzdokument für Zertifizierungen]]
*[[ISO27001 vs. IT-Grundschutz|Vergleich ISO27001 und IT-Grundschutz]]
*[[Geheimschutz|Was ist Geheimschutz?]]
*[[Datenvernichtung|Übersicht und Normen zur Datenvernichtung]]
*[[Datenlöschung|Übersicht zur sicheren Datenlöschung]]
*[[Schutzbedarf|Vorgehen zur Schutzbedarfsfeststellung]]
*[[Dokumentenmanagement|Einführung in das Dokumentenmanagement]]
*[[Protokollierung|Einführung in die Protokollierung (Logging)]]
*[[Benutzer und Rechteverwaltung|Benutzer und Rechteverwaltung]]
*[[Cloudnutzung|Grundlagen zur Cloudnutzung]]
*[[VoIP|Voice over IP - Grundlagen, Risiken & Best Practices]]
*[[Container|Sicherheitsaspekte der Containerisierung]]
*[[Homeoffice und mobiles Arbeiten|Homeoffice und mobiles Arbeiten]]
*[[Risikomanagement|Einführung in das Risikomanagement]]
*[[Gebäudeinfrastruktur|Grundlagen sicherer Gebäudinfrastruktur]]
*[[Notfallmanagement]]
*[[Datensicherung SaaS|Datensicherung bei SaaS-Anwendungen]]
*[[Lieferkettensicherheit|Sicherheit von Lieferketten]]
*[[BSI Standard 200-3|''Risikomanagement nach BSI Standard 200-3'']]⚠️
*[[GS-Zertifizierungsaudit|Vorbereitung einer Zertifizierung auf Basis von IT-Grundschutz]]
*[[Social Media|Einsatz von Social Media im Unternehmen]]
*[[EU AI Act|EU AI Act: ISMS-Integration, Risiken & Umsetzung]]
*[[KI-Nutzung|Chancen und Risiken von KI]]
*[[Industrielle IT|Grundlagen & Sicherheitsaspekte Industrieller IT]]
*[[Bücher und Links|Informative Bücher und Links]]
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>

<h2 {{MainpageTopBox}}>
Kurzartikel
</h2>
<div {{MainpageMidBox}}>
Kurze Artikel und Beschreibungen zu nur einem Stichwort.
*[[ISO 27001]]
*[[IT-Grundschutz]]
*[[Grundschutz++]]
*[[Grundschutz ToDo MindMap|IT-Grundschutz ToDo MindMap]]⚠️
*[[Cybersecurity]]
*[[Security by Design]]
*[[Threat Intelligence]]
*[[APT|Advanced Persistent Threat (APT)]]
*[[Awareness|Was ist mit Awareness?]]
*[[Rechtsgrundlagen]]
*[[Datenschutz]]
*[[Datenschutzbeauftragte]]
*[[TOMs]]
*[[VVT|Verzeichnis von Verarbeitungstätigkeiten (VVT)]]
*[[AVV|Auftragsverarbeitungsvertrag (AVV)]]
*[[DSFA|Datenschutz-Folgenabschätzung (DSFA)]]
*[[Informationssicherheitsbeauftragte]]
*[[IS-Management-Team]]
*[[Krisenkommunikation]]
*[[Krisenprävention]]
*[[Krisenstab]]
*[[Notfallbeauftragte]]
*[[Verfügbarkeit]]
*[[Zero Trust]]
*[[Threat Intelligence Ansatz|Umsetzung von Threat Intelligence]]
*[[Riskoanalyse]]
*[[BYOD|Bring Your Own Device (BYOD)]]
*[[SOC|Security Operations Center (SOC)]]
*[[Common_Criteria|Common Criteria oder (CC)]]
*[[IT-Forensik]]
*[[Zusätzliche Gefährdungen|Zusätzliche/spezifische Gefährdungen]]
*[[Nebenwirkungen|Risiken und Nebenwirkungen]]
*[[ISMS-Tools|ISMS-Tool Vergleich]]
*[[Quantenresistente Verschlüsselung]]
*[[Automatisierung|Automatisierung in der IT-Sicherheit]]
*[[Datenbias|Datenbias - Datenverzerrung managen]]
*[[KI Cybersicherheit|KI in der Cybersicherheit]]
*[[Webservices]]
*[[Multi-Cloud|Herausforderungen in Multi-Cloud-Umgebungen]]
*[[Shared Responsibility Model|Shared Responsibility Model]]
*[[Sicherheitsframework]]
*[[Passkey]]
*[[SOAR|Security Orchestration, Automation, and Response (SOAR)]]
*[[Meldepflichten|''Meldepflichten bei IT-Sicherheitsvorfällen'']]⚠️
*[[Schulungskonzepte|''Schulungskonzepte'']]⚠️
*[[DIN SPEC 27076|DIN SPEC 27076: Beratungsnorm zum Cyber-Risiko für KKU]]
*[[CRC|Cyber-Risiko-Check (CRC)]]
*[[C5|C5 (Cloud Computing Compliance Criteria Catalogue)]]
*[[CIS|CIS Controls (Center for Internet Security Controls)]]
*[[TISAX|TISAX / VDA-ISA]]
*[[OSCAL|OSCAL (Open Security Controls Assessment Language)]]
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>


| width="50%" style="vertical-align:top" |
<h2 {{MainpageTopBox}}>
Erweiterte Suche
</h2>
<div {{MainpageMidBox}}>
Gib deine Suchbegriffe ein. Auf der folgenden Ergebnisseite kann die Suche weiter spezifiziert und eingegrenzt werden.
<inputbox>
type=search
placeholder=Suche...
width=27
break=yes
buttonlabel= Exakte Suche
searchbuttonlabel= Volltextsuche
</inputbox>
</div>

<h2 {{MainpageTopBox}}>
Mustervorlagen für Richtlinien
</h2>
<div {{MainpageMidBox}}>
Die generischen [[Mustervorlagen]] können als Grundlage für die Erstellung eigener Dokumente verwendet werden. Inhalte und Formulierungen müssen an die eigene Organisation angepasst oder ergänzt werden. Beachte hierzu auch den Artikel zur [[Mustervorlagen|Nutzung der Mustervorlagen]].
*[[Informationssicherheitsleitlinie|Leitlinie zur Informationssicherheit]]
*[[IS-Strategie‎‎|Strategie zur Informatinssicherheit]]
*[[Datenschutzleitlinie|Leitlinie zum Datenschutz]]
*[[RiLi-Dokumentenlenkung|Richtlinie zur Lenkung von Dokumenten]]
*[[RiLi-InterneAuditierung|Richtlinie zur internen ISMS-Auditierung]]
*[[RiLi-KVP|Richtlinie zur Lenkung von Korrektur- und Vorbeugungsmaßnahmen]]
*[[RiLi-Sicherheitsvorfallmanagement|Richtlinie Sicherheitsvorfallmanagement]]
*[[RiLi-Ausnahmemanagement|Richtlinie zum Management von Ausnahmen und Abweichungen]]
*[[RiLi-Risikoanalyse|Richtlinie zur Risikoanalyse]]
*[[RiLi-Mitarbeitende|Richtlinien zur Sensibilisierung der Mitarbeitenden]]
*[[RiLi-Sensibilisierung|Richtlinie Sensibilisierung zur Informationssicherheit]]
*[[RiLi-Passworte|Passwort Richtlinie]]
*[[RiLi-Authentifizierung|Richtlinie Authentisierung (passkey-Richtlinie)]]
*[[RiLi-Freigabe|Freigaberichtlinie für Hard- und Software]]
*[[RiLi-Protokollierung|Protokollierungsrichtlinie]]
*[[RiLi-Cloudnutzung|Richtlinie zur Nutzung von Cloud-Diensten]]
*[[RiLi-BYOD|BYOD-Richtlinie – Sichere private Geräte im Unternehmensnetz]]
*[[RiLi-Schadsoftware|Richtlinie Schadsoftware]]
*[[RiLi-Schwachstellenmanagement|Richtlinie Schwachstellenmanagement]]
*[[RiLi-Notfallmanagement (BCM)|Richtlinie Notfallmanagement (BCM)]]
*[[RiLi-Gebäude und Räume|''Richtlinie zu Gebäuden und Räumen'']]⚠️
*[[RiLi-Netzwerkmanagement|''Richtlinie Netzwerkmanagement'']]⚠️
*[[RiLi-Netzwerkmanagement (ZT)|''Richtlinie Netzwerkmanagement für Zero Trust'']]⚠️
*[[RiLi-Servermanagement|''Richtlinie Servermanagement'']]⚠️
*[[RiLi-Webservices|Richtlinie sicherer Betrieb von Webservices]]
*[[RiLi-Clientmanagement|Richtlinie zum Client-Management]]
*[[RiLi-VoIP-Einsatz|Richtlinie zum VoIP-Einsatz]]
*[[RiLi-Fernzugriff|Richtlinie Fernzugriff und Fernwartung]]
*[[RiLi-KI-Einsatz|Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)]]
*[[RiLi-Industrielle_IT|''Richtlinie für industrielle Steuerungs- und Automatisierungssysteme'']]⚠️
*[[RiLi-Lieferkettensicherheit|Richtlinie zur Lieferkettensicherheit]]⚠️
*[[RiLi-Informationssicherheit KKU|Richtlinie zur Informationssicherheit für KKU (nach DIN SPEC 27076)]]
<hr>
*[[Strukturanalyse|Muster für eine IT-Strukturanalyse]]
*[[Betriebshandbuch|Muster für ein Betriebshandbuch]]
*[[Notfallhandbuch|Muster für ein Notfallhandbuch]]
*[[Vertraulichkeitserklärung|Muster für eine Vertraulichkeitserklärung]]
*[[Fernzugriffsvereinbarung‎‎|Muster für eine Fernzugriffsvereinbarung]]
*[[Erklärung für mobiles Arbeiten|Muster Erklärung für mobiles Arbeiten]]
*[[BYOD-Vereinbarung|Muster-Vereinbarung für BYOD]]
*[[KI-Register|Vorlage für ein rechtskonformes KI-Register]]
*[[Business Impact Analyse (BIA)|''Muster einer Business Impact Analyse (BIA)'']]⚠️
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>

<h2 {{MainpageTopBox}}>
Leitfäden
</h2>
<div {{MainpageMidBox}}>
Leitfäden als Anleitungen für Anwender, zur sensibilisieren für bestimmte Themen und praktische Handlungsempfehlungen.
*[[LF-Homeoffice|Leitfaden sicher im Homeoffice]]
*[[LF-Basistestat Hochschulen|Leitfaden Basistestat Hochschulen]]
*[[LF-Arbeiten im Ausland|Leitfaden Arbeiten im Ausland]]
*[[LF-Sicher_arbeiten|Leitfaden sicheres Arbeiten]]
*[[LF-Sicher_unterwegs|Leitfaden sicher unterwegs]]
*[[LF-KI-Sicherheit|Leitfaden KI-Sicherheit]]
*[[LF-KI-Chatbots|Leitfaden zur Nutzung von KI-Systemen]]
*[[LF-Modellierung|Leitfaden Gruppierung und Modellierung]]
*[[LF-Grundschutzcheck|Leitfaden Grundschutzcheck]]
*[[LF-Realisierungsplan|Leitfaden Realisierungsplan/Risikobehandlungsplan]]
</div>

<h2 {{MainpageTopBox}}>
Muster-Betriebskonzepte
</h2>
<div {{MainpageMidBox}}>
Mustervorlagen für Betriebskonzepte zu Standardthemen.
*[[BK-Verinice|Betriebskonzept verinice (Einzelplatz)]]
*[[BK-Missbrauchskontakt|Betriebskonzept Missbrauchskontakt]]
*[[BK-Windows Server|''Betriebskonzept Windows-Server'']]⚠️
*[[BK-Linux Server|''Betriebskonzept Linux-Server'']]⚠️
*[[BK-Windows Client|''Betriebskonzept für Windows-Clients'']]⚠️
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>

<h2 {{MainpageTopBox}}>
Templates und Vorlagen
</h2>
<div {{MainpageMidBox}}>
Templates sind Dokumentvorlagen (in den Formaten Word, Write(LibreOffice) und MediaWiki), die für eigene Dokumente verwendet werden können. Sie enthalten eine grobe, generische Inhaltsstruktur für den jeweiligen Dokumententyp sowie Felder für die notwendigen Metadaten zur Steuerung des Dokuments.
*[[WikiTemplateArtikel]]
*[[WikiTemplateKurzartikel]]
*[[WikiTemplateRichtlinie]]⚠️
*[[WikiTemplateBetriebskonzept]]⚠️
*[[WordTemplateRichtlinie]]⚠️
*[[WordTemplateBetriebskonzept]]⚠️
</div>
<small>⚠️''Artikel noch im Entwurf /unvollständig''</small>

<h2 {{MainpageTopBox}}>
Themenschwerpunkte und Pfade
</h2>
<div {{MainpageMidBox}}>
Die folgenden Seiten dienen als Einstieg in die Themenschwerpunkte und bieten geführte Wege durch die Themen. (Noch nicht aktiv!)
*[[Dummy|''Einführung und Aufbau eines ISMS'']]⚠️
*[[KMU_Startseite|''Startseite für KMU, Handwerk und Freiberufler'']]⚠️
*[[Dummy|''Durchführung einer Risikoanalyse'']]⚠️
*[[Dummy|''Einführung und Aufbau eines Notfallmanagements'']]⚠️
*[[Dummy|''Weg zur Zertifizierung (BSI IT-Grundschutz)'']]⚠️
*[[Dummy|''Weg zur Zertifizierung (ISO 27001 nativ)'']]⚠️
*[[Datenschutz Umsetzung|Praktische Umsetzung von Datenschutz]]
*[[KI_Startseite|Einführung zu Regelungen für den KI-Einsatz]]
*[[Grundschutz++ Einführung und Aufbau|'''Einführung und Anleitung zum BSI Grundschutz++''']]
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>
|}


{| width="100%"
|-
|style="vertical-align:top" |
<h2 {{MainpageTopBox}}>
<center>Allgemeine Hinweise</center>
</h2>
<div {{MainpageMidBox}}>
Artikel, die der Kategorie "[[:Kategorie:Entwurf|Entwurf]]" (siehe Fußzeile des Dokuments) zugeordnet sind, sind noch unvollständig oder können noch Fehler enthalten.
Auch vollständig ausgearbeitete Dokumente sind nur Formulierungsvorschläge. Alle Musterdokumente müssen an die individuellen Gegebenheiten der Organisation angepasst werden.
</div>
|}
__KEIN_INHALTSVERZEICHNIS__
__ABSCHNITTE_NICHT_BEARBEITEN__
__INDEXIEREN__

Willkommen im ISMS-Ratgeber WiKi

2026-03-30T03:31:48Z

Dirk:

{{#seo:
|title=ISMS-Ratgeber WiKi - Leitfaden für Informationssicherheit und Datenschutz
|description=Das ISMS-Ratgeber-Wiki bietet umfassende Informationen, Tools und Anleitungen zu Informationssicherheit, Datenschutz, BSI IT-Grundschutz ISO 27001 und anderen Standards.
}}{{SHORTDESC:Das freie ISMS-Ratgeber Wiki für Informationssicherheit und Datenschutz}}
Das ISMS-Ratgeber Wiki bietet umfassende Informationen und Ressourcen für den Aufbau eines Informationssicherheits-Managementsystems (ISMS). Es hilft, die Anforderungen von ISMS-Standards wie dem BSI IT-Grundschutz oder ISO/IEC 27001 zu erfüllen. Das Wiki stellt praxisnahe Informationen, Vorlagen und Leitfäden zur Verfügung, die die tägliche Arbeit unterstützen und den Einführungsprozess effizienter gestalten, da auf erprobte Methoden und dokumentierte Best Practices zugegriffen werden kann. Dies erleichtert die Erstellung, Verwaltung und kontinuierliche Verbesserung der Sicherheitsprozesse in der Organisation.

Das WiKi richtet sich an IT-Sicherheitsbeauftragte, Sicherheitsmanager und IT-Verantwortliche. Das WiKi ist öffentlich lesbar, die Inhalte sind frei nutzbar. Das Erstellen und Bearbeiten von Artikeln erfordert jedoch eine Registrierung als Benutzer. Jeder ist eingeladen, aktiv an den Inhalten mitzuarbeiten, eine gewisse Fachkompetenz sollte jedoch vorhanden sein, um die Qualität der Inhalte zu gewährleisten.

Für die organisationsübergreifende Zusammenarbeit und den gemeinsamen Austausch gibt es ein Forum auf Basis von HumHub. Unter [https://humhub.isms-ratgeber.info humhub.isms-ratgeber.info] stehen Foren/Workspaces zu verschiedenen Themen zum Austausch zur Verfügung. Die Registrierung ist wie hier im WiKi kostenlos.<br>
{| width="100%"
|-

|style="vertical-align:top" |

<h2 {{MainpageTopBox}}>
Für Einsteiger
</h2>
<div {{MainpageMidBox}}>
Informationen für Einsteiger und Anfänger.
*[[ISMS-Einführung|Einführung: Was ist ein ISMS?]]
*[[ISMS-Ratgeber-WiKi|Über das ISMS-Ratgeber Wiki]]
*[[ISMS-Ratgeber Anleitung|Anleitung zur Nutzung des ISMS-Ratgeber Wiki]]
*[[Mustervorlagen|Nutzung der Mustervorlagen]]
*[[Sicherheitsprojekte|Durchführung eines Sicherheitsprojekts]]
*[[QuickCheck|Ein QuickCheck zum Stand der Informationssicherheit]]
*[[Abkürzungen|Glossar]]
*[[Hilfe|allgemeine Wiki Hilfe]]
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>

<h2 {{MainpageTopBox}}>
Grundlagenartikel
</h2>
<div {{MainpageMidBox}}>
Grundlagenartikel mit ausführlichen Hintergrundinformationen zu bestimmten Themen und allgemeine Artikel.
*[[ISMS_Step_by_Step|Aufbau eines ISMS Step by Step (KMU)]]
*[[Geschäftsprozesse]]
*[[Dokumentenerstellung|Hilfen zur Dokumentenerstellung]]
*[[Managementbericht|Erstellen eines Managementberichts]]
*[[Betriebsdokumentation|Hilfen für Betriebsdokumentation]]
*[[Reifegradmodell|Erstellen eines Reifegradmodells]]
*[[KPIs|Key Performance Indicators (KPIs)]]
*[[Authentisierung|Methoden zur Authentisierung]]
*[[Klassifizierung|Klassifizierung von Informationen (Schutzstufen)]]
*[[Normen und Standards|Normen und Standards rund um das ISMS]]
*[[Bildkampagne|Sensibilisierung mit Bildkampagnen]]
*[[Online Prüftools|Liste von Online-Prüftools]]
*[[Referenzdokumente|Erforderliche Referenzdokument für Zertifizierungen]]
*[[ISO27001 vs. IT-Grundschutz|Vergleich ISO27001 und IT-Grundschutz]]
*[[Geheimschutz|Was ist Geheimschutz?]]
*[[Datenvernichtung|Übersicht und Normen zur Datenvernichtung]]
*[[Datenlöschung|Übersicht zur sicheren Datenlöschung]]
*[[Schutzbedarf|Vorgehen zur Schutzbedarfsfeststellung]]
*[[Dokumentenmanagement|Einführung in das Dokumentenmanagement]]
*[[Protokollierung|Einführung in die Protokollierung (Logging)]]
*[[Benutzer und Rechteverwaltung|Benutzer und Rechteverwaltung]]
*[[Cloudnutzung|Grundlagen zur Cloudnutzung]]
*[[VoIP|Voice over IP - Grundlagen, Risiken & Best Practices]]
*[[Container|Sicherheitsaspekte der Containerisierung]]
*[[Homeoffice und mobiles Arbeiten|Homeoffice und mobiles Arbeiten]]
*[[Risikomanagement|Einführung in das Risikomanagement]]
*[[Gebäudeinfrastruktur|Grundlagen sicherer Gebäudinfrastruktur]]
*[[Notfallmanagement]]
*[[Datensicherung SaaS|Datensicherung bei SaaS-Anwendungen]]
*[[Lieferkettensicherheit|Sicherheit von Lieferketten]]
*[[BSI Standard 200-3|''Risikomanagement nach BSI Standard 200-3'']]⚠️
*[[GS-Zertifizierungsaudit|Vorbereitung einer Zertifizierung auf Basis von IT-Grundschutz]]
*[[Social Media|Einsatz von Social Media im Unternehmen]]
*[[EU AI Act|EU AI Act: ISMS-Integration, Risiken & Umsetzung]]
*[[KI-Nutzung|Chancen und Risiken von KI]]
*[[Industrielle IT|Grundlagen & Sicherheitsaspekte Industrieller IT]]
*[[Bücher und Links|Informative Bücher und Links]]
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>

<h2 {{MainpageTopBox}}>
Kurzartikel
</h2>
<div {{MainpageMidBox}}>
Kurze Artikel und Beschreibungen zu nur einem Stichwort.
*[[ISO 27001]]
*[[IT-Grundschutz]]
*[[Grundschutz++]]
*[[Grundschutz ToDo MindMap|IT-Grundschutz ToDo MindMap]]⚠️
*[[Cybersecurity]]
*[[Security by Design]]
*[[Threat Intelligence]]
*[[APT|Advanced Persistent Threat (APT)]]
*[[Awareness|Was ist mit Awareness?]]
*[[Rechtsgrundlagen]]
*[[Datenschutz]]
*[[Datenschutzbeauftragte]]
*[[TOMs]]
*[[VVT|Verzeichnis von Verarbeitungstätigkeiten (VVT)]]
*[[AVV|Auftragsverarbeitungsvertrag (AVV)]]
*[[DSFA|Datenschutz-Folgenabschätzung (DSFA)]]
*[[Informationssicherheitsbeauftragte]]
*[[IS-Management-Team]]
*[[Krisenkommunikation]]
*[[Krisenprävention]]
*[[Krisenstab]]
*[[Notfallbeauftragte]]
*[[Verfügbarkeit]]
*[[Zero Trust]]
*[[Threat Intelligence Ansatz|Umsetzung von Threat Intelligence]]
*[[Riskoanalyse]]
*[[BYOD|Bring Your Own Device (BYOD)]]
*[[SOC|Security Operations Center (SOC)]]
*[[Common_Criteria|Common Criteria oder (CC)]]
*[[IT-Forensik]]
*[[Zusätzliche Gefährdungen|Zusätzliche/spezifische Gefährdungen]]
*[[Nebenwirkungen|Risiken und Nebenwirkungen]]
*[[ISMS-Tools|ISMS-Tool Vergleich]]
*[[Quantenresistente Verschlüsselung]]
*[[Automatisierung|Automatisierung in der IT-Sicherheit]]
*[[Datenbias|Datenbias - Datenverzerrung managen]]
*[[KI Cybersicherheit|KI in der Cybersicherheit]]
*[[Webservices]]
*[[Multi-Cloud|Herausforderungen in Multi-Cloud-Umgebungen]]
*[[Shared Responsibility Model|Shared Responsibility Model]]
*[[Sicherheitsframework]]
*[[Passkey]]
*[[SOAR|Security Orchestration, Automation, and Response (SOAR)]]
*[[Meldepflichten|''Meldepflichten bei IT-Sicherheitsvorfällen'']]⚠️
*[[Schulungskonzepte|''Schulungskonzepte'']]⚠️
*[[DIN SPEC 27076|DIN SPEC 27076: Beratungsnorm zum Cyber-Risiko für KKU]]
*[[CRC|Cyber-Risiko-Check (CRC)]]
*[[C5|C5 (Cloud Computing Compliance Criteria Catalogue)]]
*[[CIS|CIS Controls (Center for Internet Security Controls)]]
*[[TISAX|TISAX / VDA-ISA]]
*[[OSCAL|OSCAL (Open Security Controls Assessment Language)]]
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>


| width="50%" style="vertical-align:top" |
<h2 {{MainpageTopBox}}>
Erweiterte Suche
</h2>
<div {{MainpageMidBox}}>
Gib deine Suchbegriffe ein. Auf der folgenden Ergebnisseite kann die Suche weiter spezifiziert und eingegrenzt werden.
<inputbox>
type=search
placeholder=Suche...
width=27
break=yes
buttonlabel= Exakte Suche
searchbuttonlabel= Volltextsuche
</inputbox>
</div>

<h2 {{MainpageTopBox}}>
Mustervorlagen für Richtlinien
</h2>
<div {{MainpageMidBox}}>
Die generischen [[Mustervorlagen]] können als Grundlage für die Erstellung eigener Dokumente verwendet werden. Inhalte und Formulierungen müssen an die eigene Organisation angepasst oder ergänzt werden. Beachte hierzu auch den Artikel zur [[Mustervorlagen|Nutzung der Mustervorlagen]].
*[[Informationssicherheitsleitlinie|Leitlinie zur Informationssicherheit]]
*[[IS-Strategie‎‎|Strategie zur Informatinssicherheit]]
*[[Datenschutzleitlinie|Leitlinie zum Datenschutz]]
*[[RiLi-Dokumentenlenkung|Richtlinie zur Lenkung von Dokumenten]]
*[[RiLi-InterneAuditierung|Richtlinie zur internen ISMS-Auditierung]]
*[[RiLi-KVP|Richtlinie zur Lenkung von Korrektur- und Vorbeugungsmaßnahmen]]
*[[RiLi-Sicherheitsvorfallmanagement|Richtlinie Sicherheitsvorfallmanagement]]
*[[RiLi-Ausnahmemanagement|Richtlinie zum Management von Ausnahmen und Abweichungen]]
*[[RiLi-Risikoanalyse|Richtlinie zur Risikoanalyse]]
*[[RiLi-Mitarbeitende|Richtlinien zur Sensibilisierung der Mitarbeitenden]]
*[[RiLi-Sensibilisierung|Richtlinie Sensibilisierung zur Informationssicherheit]]
*[[RiLi-Passworte|Passwort Richtlinie]]
*[[RiLi-Authentifizierung|Richtlinie Authentisierung (passkey-Richtlinie)]]
*[[RiLi-Freigabe|Freigaberichtlinie für Hard- und Software]]
*[[RiLi-Protokollierung|Protokollierungsrichtlinie]]
*[[RiLi-Cloudnutzung|Richtlinie zur Nutzung von Cloud-Diensten]]
*[[RiLi-BYOD|BYOD-Richtlinie – Sichere private Geräte im Unternehmensnetz]]
*[[RiLi-Schadsoftware|Richtlinie Schadsoftware]]
*[[RiLi-Schwachstellenmanagement|Richtlinie Schwachstellenmanagement]]
*[[RiLi-Notfallmanagement (BCM)|Richtlinie Notfallmanagement (BCM)]]
*[[RiLi-Gebäude und Räume|''Richtlinie zu Gebäuden und Räumen'']]⚠️
*[[RiLi-Netzwerkmanagement|''Richtlinie Netzwerkmanagement'']]⚠️
*[[RiLi-Netzwerkmanagement (ZT)|''Richtlinie Netzwerkmanagement für Zero Trust'']]⚠️
*[[RiLi-Servermanagement|''Richtlinie Servermanagement'']]⚠️
*[[RiLi-Webservices|Richtlinie sicherer Betrieb von Webservices]]
*[[RiLi-Clientmanagement|Richtlinie zum Client-Management]]
*[[RiLi-VoIP-Einsatz|Richtlinie zum VoIP-Einsatz]]
*[[RiLi-Fernzugriff|Richtlinie Fernzugriff und Fernwartung]]
*[[RiLi-KI-Einsatz|Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)]]
*[[RiLi-Industrielle_IT|''Richtlinie für industrielle Steuerungs- und Automatisierungssysteme'']]⚠️
*[[RiLi-Lieferkettensicherheit|Richtlinie zur Lieferkettensicherheit]]⚠️
*[[RiLi-Informationssicherheit KKU|Richtlinie zur Informationssicherheit für KKU (nach DIN SPEC 27076)]]
<hr>
*[[Strukturanalyse|Muster für eine IT-Strukturanalyse]]
*[[Betriebshandbuch|Muster für ein Betriebshandbuch]]
*[[Notfallhandbuch|Muster für ein Notfallhandbuch]]
*[[Vertraulichkeitserklärung|Muster für eine Vertraulichkeitserklärung]]
*[[Fernzugriffsvereinbarung‎‎|Muster für eine Fernzugriffsvereinbarung]]
*[[Erklärung für mobiles Arbeiten|Muster Erklärung für mobiles Arbeiten]]
*[[BYOD-Vereinbarung|Muster-Vereinbarung für BYOD]]
*[[KI-Register|Vorlage für ein rechtskonformes KI-Register]]
*[[Business Impact Analyse (BIA)|''Muster einer Business Impact Analyse (BIA)'']]⚠️
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>

<h2 {{MainpageTopBox}}>
Leitfäden
</h2>
<div {{MainpageMidBox}}>
Leitfäden als Anleitungen für Anwender, zur sensibilisieren für bestimmte Themen und praktische Handlungsempfehlungen.
*[[LF-Homeoffice|Leitfaden sicher im Homeoffice]]
*[[LF-Basistestat Hochschulen|Leitfaden Basistestat Hochschulen]]
*[[LF-Arbeiten im Ausland|Leitfaden Arbeiten im Ausland]]
*[[LF-Sicher_arbeiten|Leitfaden sicheres Arbeiten]]
*[[LF-Sicher_unterwegs|Leitfaden sicher unterwegs]]
*[[LF-KI-Chatbots|Leitfaden zur Nutzung von KI-Systemen]]
*[[LF-Modellierung|Leitfaden Gruppierung und Modellierung]]
*[[LF-Grundschutzcheck|Leitfaden Grundschutzcheck]]
*[[LF-Realisierungsplan|Leitfaden Realisierungsplan/Risikobehandlungsplan]]
</div>

<h2 {{MainpageTopBox}}>
Muster-Betriebskonzepte
</h2>
<div {{MainpageMidBox}}>
Mustervorlagen für Betriebskonzepte zu Standardthemen.
*[[BK-Verinice|Betriebskonzept verinice (Einzelplatz)]]
*[[BK-Missbrauchskontakt|Betriebskonzept Missbrauchskontakt]]
*[[BK-Windows Server|''Betriebskonzept Windows-Server'']]⚠️
*[[BK-Linux Server|''Betriebskonzept Linux-Server'']]⚠️
*[[BK-Windows Client|''Betriebskonzept für Windows-Clients'']]⚠️
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>

<h2 {{MainpageTopBox}}>
Templates und Vorlagen
</h2>
<div {{MainpageMidBox}}>
Templates sind Dokumentvorlagen (in den Formaten Word, Write(LibreOffice) und MediaWiki), die für eigene Dokumente verwendet werden können. Sie enthalten eine grobe, generische Inhaltsstruktur für den jeweiligen Dokumententyp sowie Felder für die notwendigen Metadaten zur Steuerung des Dokuments.
*[[WikiTemplateArtikel]]
*[[WikiTemplateKurzartikel]]
*[[WikiTemplateRichtlinie]]⚠️
*[[WikiTemplateBetriebskonzept]]⚠️
*[[WordTemplateRichtlinie]]⚠️
*[[WordTemplateBetriebskonzept]]⚠️
</div>
<small>⚠️''Artikel noch im Entwurf /unvollständig''</small>

<h2 {{MainpageTopBox}}>
Themenschwerpunkte und Pfade
</h2>
<div {{MainpageMidBox}}>
Die folgenden Seiten dienen als Einstieg in die Themenschwerpunkte und bieten geführte Wege durch die Themen. (Noch nicht aktiv!)
*[[Dummy|''Einführung und Aufbau eines ISMS'']]⚠️
*[[KMU_Startseite|''Startseite für KMU, Handwerk und Freiberufler'']]⚠️
*[[Dummy|''Durchführung einer Risikoanalyse'']]⚠️
*[[Dummy|''Einführung und Aufbau eines Notfallmanagements'']]⚠️
*[[Dummy|''Weg zur Zertifizierung (BSI IT-Grundschutz)'']]⚠️
*[[Dummy|''Weg zur Zertifizierung (ISO 27001 nativ)'']]⚠️
*[[Datenschutz Umsetzung|Praktische Umsetzung von Datenschutz]]
*[[KI_Startseite|Einführung zu Regelungen für den KI-Einsatz]]
*[[Grundschutz++ Einführung und Aufbau|'''Einführung und Anleitung zum BSI Grundschutz++''']]
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>
|}


{| width="100%"
|-
|style="vertical-align:top" |
<h2 {{MainpageTopBox}}>
<center>Allgemeine Hinweise</center>
</h2>
<div {{MainpageMidBox}}>
Artikel, die der Kategorie "[[:Kategorie:Entwurf|Entwurf]]" (siehe Fußzeile des Dokuments) zugeordnet sind, sind noch unvollständig oder können noch Fehler enthalten.
Auch vollständig ausgearbeitete Dokumente sind nur Formulierungsvorschläge. Alle Musterdokumente müssen an die individuellen Gegebenheiten der Organisation angepasst werden.
</div>
|}
__KEIN_INHALTSVERZEICHNIS__
__ABSCHNITTE_NICHT_BEARBEITEN__
__INDEXIEREN__

KI Startseite

2026-03-30T03:30:28Z

Dirk:

{{#seo:
|title=KI-Einsatz: ISMS-integration, EU AI Act, DSGVO, BSI Grundschutz
|keywords=KI-Einsatz, EU AI Act, ISO 27001, BSI IT-Grundschutz, DSGVO KI, KI-Risikomanagement, Informationssicherheit KI, Datenschutz KI
|description=KI in Unternehmen & Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.}}
{{SHORTDESC:Einführung zu sinnvollen Regelungen für den KI-Einsatz}}''KI-Einsatz in Unternehmen und Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.''

== Einleitung ==
Der Einsatz von Künstlicher Intelligenz (KI) in Unternehmen und Behörden gewinnt rasant an Bedeutung und stellt Informationssicherheits-Managementsysteme (ISMS) vor neue Herausforderungen. KI-Systeme verarbeiten oft personenbezogene Daten, treffen automatisierte Entscheidungen und erfordern eine nahtlose Integration in bestehende Standards wie ISO/IEC 27001 sowie BSI Grundschutz. Der EU AI Act (seit August 2024 rechtskräftig) etabliert einen risikobasierten Ansatz, der mit DSGVO und BDSG kompatibel ist und spezifische Anforderungen an Transparenz, Robustheit und Nachvollziehbarkeit stellt.

Für Behörden gelten zusätzlich öffentlich-rechtliche Bindungen (z.B. Grundrechte Art. 1–3 GG), während Unternehmen wirtschaftliche Risiken wie Vendor Lock-in oder Haftungsstreitigkeiten prüfen müssen. Dieser Artikel fasst rechtliche, datenschutzrechtliche, sicherheitstechnische und organisatorische Belange zusammen und verweist auf vertiefende Inhalte im Wiki sowie externe Quellen.

'''Relevanz für ISMS'''

KI-Einsatz beeinflusst die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) und erfordert [[Zusätzliche Gefährdungen|Ergänzungen]] der verwendeten Risikokataloge wie z.B. den BSI G0-Katalog. Ziel ist eine risikobasierte Implementierung des KI-Einsatzes.

== Rechtlicher Rahmen ==

* '''EU AI Act''': Risikobasierte Klassifikation (verboten, hochrisiko, geringes Risiko, GPAI). Zeitlicher Fahrplan (Verbote ab 2025, Hochrisiko ab 2026/2027). Anforderungen an Dokumentation, Konformität und Bußgelder.
* '''Nationale Regelungen''': DSGVO-Integration (Art. 10 KI-VO für biometrische Daten), BDSG, öffentlich-rechtliche Sonderbindungen (GG Art. 1–3) für Behörden.
* '''Sektorale Vorgaben''': Verwaltungsrecht, hessische/länderspezifische Initiativen für öffentlichen Sektor.

=== EU AI Act ===
Der EU AI Act klassifiziert KI-Systeme in vier Risikostufen:

* '''Unzulässig''' (z. B. Social Scoring, biometrische Echtzeit-Identifikation in öffentlichen Räumen) – Verbot ab Februar 2025.
* '''Hochrisiko''' (z. B. HR, Kreditvergabe, kritische Infrastruktur) – Konformitätsbewertung, Dokumentationspflichten und menschliche Aufsicht ab 2026/2027.
* '''Geringes Risiko''' – Transparenzpflichten (z. B. Chatbots).
* '''GPAI (General Purpose AI)''' – Risikoanalyse und technische Dokumentation für Modelle wie GPT-Varianten.

Bußgelder bis 35 Mio. € oder 7% Umsatz. Verantwortung liegt primär beim Provider, sekundär beim Deployer.

'''Weiterführende Informationen:'''

* [[EU AI Act|Wiki: EU AI Act]]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32024R1689 EU AI Act Volltext]

=== Nationale Regelungen ===

* '''Deutschland''': Ergänzungen durch BDSG (§ 37 Automatisierte Entscheidungen im Einzelfall einschließlich Profiling), KI-Strategie der Bundesregierung (2020/aktualisiert 2025). Behörden müssen öffentlich-rechtliche Prinzipien (Rechtsstaatlichkeit, Verhältnismäßigkeit) wahren.
* '''Länderspezifisch''': Hessische KI-Verordnung, bayrische Orientierungshilfen für öffentliche Verwaltung.
* '''Sektoral''': Finanzsektor (BaFin-Marco), Gesundheitswesen (DiGA-Verordnung).

'''Weiterführende Informationen:'''

* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Kuenstliche-Intelligenz/AIC4/aic4.html Kriterienkatalog für <abbr>KI</abbr>-Cloud-Dienste – <abbr>AIC4</abbr>]
* [https://www.gesetze-im-internet.de/bdsg_2018/__37.html BDSG: §37 Automatisierte Entscheidungen im Einzelfall einschließlich Profiling]

=== Übergangsregelungen und Neuklassifizierung ===
KI-Systeme müssen bei wesentlichen Änderungen neu klassifiziert werden. Bestehende Systeme bis 2027.

== Datenschutzrechtliche Aspekte ==

=== DSGVO-Konformität ===
KI-Trainingsdaten unterliegen Art. 5 DSGVO (Rechtsmäßigkeit, Zweckbindung). Bei biometrischen Daten: Art. 10 KI-VO (Verbot biometrische Kategorisierung). Datenschutz-Folgenabschätzung (DSFA, Art. 35) obligatorisch für Hochrisiko-Anwendungen.

'''Kernpflichten'''

* '''Trainingsdaten''': Bereinigung sensibler Daten, Pseudonymisierung, Löschung nach Zweck (Art. 17).
* '''Outputs''': Transparenz bei automatisierter Entscheidungsfindung (Art. 22), Recht auf Erklärung.
* '''AVV (Auftragsverarbeitung)''': Cloud-KI-Provider als Auftragsverarbeiter prüfen.

=== Orientierungshilfen ===

* '''Datenschutzkonferenz (DSK)''': Leitfaden „Künstliche Intelligenz und Datenschutz“ – Checkliste für Datensparsamkeit und Rechenschaftspflicht.
* '''BayLDA/LfDI''': Praktische Hinweise zu Shadow-KI und ChatGPT-Nutzung in Behörden.

=== Betroffenenrechte und Transparenz ===
Benutzende müssen über KI-Einsatz informiert werden (Art. 13/14). Erweiterte Informationspflichten bei GPAI: Modellkarte offenlegen. Bias-Tests dokumentieren, um Diskriminierungsverbot (Art. 21 GG) zu wahren.

'''Praktische Umsetzung'''
{| class="wikitable"
!Aspekt
!Maßnahme
!Rechtsgrundlage
|-
|DSFA
|Vor KI-Einsatz durchführen
|Art. 35 DSGVO
|-
|Rechteauskunft
|KI-spezifische Vorlage
|Art. 15 DSGVO
|-
|Löschung
|Trainingsdaten entfernen
|Art. 17 DSGVO
|}
'''Weiterführende Informationen:'''

* [https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf DSK: Orientierungshilfe zu datenschutzrechtlichen Besonderheiten generativer KI-Systeme mit RAG-Methode]
* [https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf DSK: Orientierungshilfe zu empfohlenen technischen und organisatorischen Maßnahmen bei der Entwicklung und beim Betrieb von KI-Systemen]
* [[KI Datenschutz|Wiki: Datenschutz in KI-Anwendungen.]]

== Sicherheitsaspekte (ISMS-Integration) ==
KI-Einsatz erfordert eine Erweiterung des ISMS um spezifische Gefährdungen, die die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) bedrohen und über den BSI IT-Grundschutz G0-Katalog hinausgehen. Nach BSI Standard 200-3 müssen diese in der Risikoanalyse bewertet und mit Maßnahmen aus ISO 27001 Anhang A (z. B. A.8.25 für sichere Entwicklung) kontrolliert werden.

=== Gefährdungskatalog-Ergänzungen ===
KI-spezifische Risiken wie folgt klassifiziert (CIA-Analyse):

* '''Prompt Injections''': Manipulation von Eingaben zu Large Language Models (hoch I/C).
* '''Data Poisoning''': Vergiftung von Trainingsdaten (hoch I, mittel A).
* '''Modelllecks''': Training Data Leakage oder IP-Exfiltration (hoch C).
* '''Unkontrollierte Nutzung von Schatten-KI''': Unkontrollierte Nutzung privater Tools (mittel C/I).
* '''Black-Box-Effekte''': Mangelnde Nachvollziehbarkeit (hoch I/A).

'''Integration in BSI-Module'''
{| class="wikitable"
!Gefährdung
!BSI G0-Modul
!Ergänzungsmaßnahme
|-
|Data Poisoning
|SYS.1.2 Datenintegrität
|Daten-Sanitization, Validierung
|-
|Modelllecks
|NET.4.1 Zugriffssteuerung
|API-Rate-Limiting, Differential Privacy
|-
|Shadow-KI
|ORG.2.1 Sicherheitsrichtlinien
|KI-Nutzungsrichtlinie (ISO A.5.1)
|}

=== ISMS-Maßnahmen und Standards ===
* '''BSI KI-Kriterienkatalog ([[RiLi-KI-Einsatz|2025]])''': Sicherheitsniveaus (Low/Medium/High) für generative KI, mit Tests auf Jailbreaks und Bias.
* '''ISO 27001 Anhang A''': A.14.2.7 Sichere Entwicklung von KI, A.12.6 Vulnerability-Management für Modelle.
* '''Risikobewertung''': Erweiterte Gefährdungsanalyse nach BSI 200-3, inklusive Supply-Chain-Risiken bei Cloud-KI-Providern.

'''Weiterführende Informationen:'''

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KI/Kriterienkatalog_KI-Modelle_Bundesverwaltung.html BSI KI-Kriterienkatalog 2025.]
* [[Zusätzliche Gefährdungen|Wiki: Zusätzliche Gefährdungen (ergänzt und spezifische KI-Gefährdungen)]]
* [[RiLi-KI-Einsatz|Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)]]
* [[LF-KI-Chatbots|Leitfaden für Mitarbeitende zur Nutzung von KI-Systemen.]]

== Technische Aspekte ==
Technische Umsetzung von KI muss Robustheit, Nachvollziehbarkeit und Datensicherheit gewährleisten, um EU AI Act-Anforderungen (z. B. Art. 15 für Hochrisiko) und ISMS-Ziele zu erfüllen. Der Fokus liegt auf dem gesamten KI-Lebenszyklus.

=== Implementierungsprinzipien ===

* '''Daten-Governance''': Saubere Trainingsdaten (Preprocessing, Anonymisierung), RAG (Retrieval-Augmented Generation) statt reinem Fine-Tuning zur Vermeidung von Halluzinationen.
* '''Modellsicherheit''': Hardening-Techniken wie Adversarial Training, Modellkardinalität (Input/Output-Beschränkungen).
* '''Nachvollziehbarkeit (XAI)''': SHAP für globale Feature-Importance, LIME für lokale Erklärungen einzelner Vorhersagen – essenziell für Art. 22 DSGVO.

=== Lebenszyklus-Management ===
'''KI-System-Phasen und Sicherheitskontrollen'''
{| class="wikitable"
!Phase
!Technische Maßnahmen
!ISMS-Verknüpfung
|-
|Auswahl/Training
|Datenvalidierung, Secure MPC
|A.8.25 Entwicklung
|-
|Deployment
|Sandboxing, Human-in-the-Loop
|A.12.4 Monitoring
|-
|Betrieb
|Continuous Model Monitoring (Drift/Bias)
|A.12.6 Vulnerabilities
|-
|Decommissioning
|Modelllöschung, Audit-Logs
|A.18.1 Compliance
|}

=== Hochrisiko-Anwendungen ===

* '''Sektoren''': HR (Bias-Prüfung), Gesundheitswesen (FDA/DiGA-konform), kritische Infrastruktur (real-time Robustheit).
* '''Technische Standards''': ONNX für Modell-Portabilität, TensorFlow Privacy für Federated Learning.

'''Praktische Umsetzung'''

* '''Tools''': MLflow für Lifecycle-Tracking, Adversarial Robustness Toolbox (ART) für Angriffstests.
* '''Cloud-KI''': AWS SageMaker oder Azure ML mit integrierten Security-Features prüfen (AVV-pflichtig).

'''Weiterführende Informationen:'''

* [https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R1689#art_11 EU AI Act Artikel 11 - Technische Dokumentation]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R1689#anx_IV EU AI Act Anhang IV - Technische Dokumentation]
* [https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/Leitfaden_KI-Systeme_230124.html BSI Secure AI Guidelines.]
* [[KI-Register|Wiki: KI-Register]]
* [[KI Cybersicherheit|KI als Fluch und Segen in der Cybersicherheit.]]

== Governance und Organisation ==
Eine effektive KI-Governance stellt sicher, dass KI-Einsatz mit ISMS-Zielen (ISO 27001, BSI Grundschutz) übereinstimmt und EU AI Act-Anforderungen erfüllt. Sie umfasst organisatorische Strukturen, Prozesse und Verantwortlichkeiten, um Risiken wie Shadow-KI oder Bias zu minimieren. Die Geschäftsleitung trägt gemäß ISO 27001 Abschnitt 5.1 die oberste Verantwortung und muss KI-spezifische Richtlinien (A.5.1) etablieren.

=== KI-Governancestruktur ===

* '''KI-Steuerungsgremium''': Interdisziplinäres Gremium (IT-Sicherheit, Datenschutzbeauftragte, Rechtsabteilung, Fachabteilungen) für Risikobewertungen, Modellfreigaben und Audits. Regelmäßige Meetings (vierteljährlich) zur Überprüfung von KI-Projekten.

* '''Rollen und Verantwortlichkeiten''':<br>
{| class="wikitable"
!Rolle
!Aufgaben
!Rechtsgrundlage
|-
|KI-Provider (extern)
|Technische Dokumentation, Konformitätserklärung
|EU AI Act Art. 13
|-
|KI-Deployer (intern)
|Risikoanalyse, menschliche Aufsicht
|EU AI Act Art. 29
|-
|Datenschutzbeauftragte
|DSFA, Betroffenenrechte
|DSGVO Art. 39
|-
|ISMS-Leitung
|Integration in Risikomanagement
|ISO 27001 A.5.1
|}

* '''KI-Nutzungsrichtlinie''': Verbot privater KI-Tools (Shadow-KI), Pflicht zu genehmigten Modellen, Sanktionen bei Verstößen. Schulungspflicht für Mitarbeitende (KI-Literacy).

=== Prozesse und Workflows ===

* '''Risikobewertungsvorlage''': Vorlage für neue KI-Projekte mit CIA-Analyse, EU AI Act-Risikostufe und DSFA-Trigger. Workflow: Antrag → Gremium → Freigabe → Monitoring.
* '''Audit und Reporting''': Jährliche KI-Inventar (alle Systeme auflisten), Incident-Reporting für Bias-Vorfälle oder Modell-Drift. Integration in ISO 27001 Management Review (Abschnitt 9.3).
* '''Schulungen''': Obligatorische Einstiegsschulung zu KI-Risiken (~2h), vertiefte für Entwickler (XAI, Secure Coding). Nachweis via LMS.

=== Besonderheiten für Behörden ===

* '''Grundrechtsschutz''': Zusätzliche Prüfung auf Verhältnismäßigkeit (GG Art. 1–3), Transparenz gegenüber Bürger:innen. Beliehene Unternehmen (z. B. Zeugnisstellen) fallen unter öffentlich-rechtliche Standards.
* '''Öffentliche Unternehmen''': Anpassung an Verwaltungsrecht (VwVfG § 35), Archivierungspflicht für KI-Entscheidungen.

'''Praktische Umsetzung'''

* '''Checkliste für KI-Projekte''':
*# Risikostufe bestimmen,
*# Provider prüfen,
*# DSFA durchführen,
*# Technische Dokumentation anlegen,
*# Monitoring einrichten.
* '''Vorlage''': KI-Risikobewertungstabelle (Excel) mit Spalten für Gefährdung, Wahrscheinlichkeit, Schaden, Maßnahmen.

'''Weiterführende Informationen:'''

* Wiki: ISMS-Organisation
* ISO 27001:2022 Abschnitt 5 (Führung).

== Weiterführende Quellen ==

=== Primärquellen (Gesetze und Verordnungen) ===

* '''EU AI Act''': Volltext – Offizielle Übersetzung, Anhang mit Hochrisiko-Listen.
* '''DSGVO''': Art. 22, 35 – Automatisierte Entscheidungen, DSFA.
* '''BDSG''': § 22 – Automatisierte Entscheidungen im öffentlichen Recht.

=== Behörden und Standardisierungsgremien ===

* '''BSI''':
** KI-Kriterienkatalog 2025 – Testszenarien für generative KI.
** IT-Grundschutz Compendium – G0-Module.
* '''Datenschutzkonferenz (DSK)''': Leitfaden KI und Datenschutz – Praktische Checkliste.
* '''BayLDA''': KI & Datenschutz – Orientierung für Behörden.

=== Branchenverbände und Ratgeber ===

* '''IHK München''': Datenschutz & KI – Praktische Hinweise für KMU.
* '''Bitkom''': KI-Guide für Unternehmen – Best Practices.
* '''BaFin''': Marco für KI im Finanzsektor.

=== Technische Ressourcen ===

* '''XAI-Tools''': SHAP-Dokumentation, LIME – Open Source für Erklärbarkeit.
* '''Secure AI Frameworks''': Adversarial Robustness Toolbox – Tests auf Angriffe.

=== Wiki-interne Verweise ===

* [[EU AI Act]]
* [[KI Cybersicherheit]]
* [[KI Datenschutz]]
* [[KI-Nutzung]]
* [[KI-Register]]
* [[LF-KI-Chatbots]]
* [[RiLi-KI-Einsatz]]
* [[Zusätzliche Gefährdungen]]

[[Kategorie:Artikel]]
[[Kategorie:KI]]

KI Startseite

2026-03-30T03:28:53Z

Dirk: /* ISMS-Maßnahmen und Standards */

{{Vorlage:Entwurf}}
{{#seo:
|title=KI-Einsatz: ISMS-integration, EU AI Act, DSGVO, BSI Grundschutz
|keywords=KI-Einsatz, EU AI Act, ISO 27001, BSI IT-Grundschutz, DSGVO KI, KI-Risikomanagement, Informationssicherheit KI, Datenschutz KI
|description=KI in Unternehmen & Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.}}
{{SHORTDESC:Einführung zu sinnvollen Regelungen für den KI-Einsatz}}''KI-Einsatz in Unternehmen und Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.''

== Einleitung ==
Der Einsatz von Künstlicher Intelligenz (KI) in Unternehmen und Behörden gewinnt rasant an Bedeutung und stellt Informationssicherheits-Managementsysteme (ISMS) vor neue Herausforderungen. KI-Systeme verarbeiten oft personenbezogene Daten, treffen automatisierte Entscheidungen und erfordern eine nahtlose Integration in bestehende Standards wie ISO/IEC 27001 sowie BSI Grundschutz. Der EU AI Act (seit August 2024 rechtskräftig) etabliert einen risikobasierten Ansatz, der mit DSGVO und BDSG kompatibel ist und spezifische Anforderungen an Transparenz, Robustheit und Nachvollziehbarkeit stellt.

Für Behörden gelten zusätzlich öffentlich-rechtliche Bindungen (z.B. Grundrechte Art. 1–3 GG), während Unternehmen wirtschaftliche Risiken wie Vendor Lock-in oder Haftungsstreitigkeiten prüfen müssen. Dieser Artikel fasst rechtliche, datenschutzrechtliche, sicherheitstechnische und organisatorische Belange zusammen und verweist auf vertiefende Inhalte im Wiki sowie externe Quellen.

'''Relevanz für ISMS'''

KI-Einsatz beeinflusst die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) und erfordert [[Zusätzliche Gefährdungen|Ergänzungen]] der verwendeten Risikokataloge wie z.B. den BSI G0-Katalog. Ziel ist eine risikobasierte Implementierung des KI-Einsatzes.

== Rechtlicher Rahmen ==

* '''EU AI Act''': Risikobasierte Klassifikation (verboten, hochrisiko, geringes Risiko, GPAI). Zeitlicher Fahrplan (Verbote ab 2025, Hochrisiko ab 2026/2027). Anforderungen an Dokumentation, Konformität und Bußgelder.
* '''Nationale Regelungen''': DSGVO-Integration (Art. 10 KI-VO für biometrische Daten), BDSG, öffentlich-rechtliche Sonderbindungen (GG Art. 1–3) für Behörden.
* '''Sektorale Vorgaben''': Verwaltungsrecht, hessische/länderspezifische Initiativen für öffentlichen Sektor.

=== EU AI Act ===
Der EU AI Act klassifiziert KI-Systeme in vier Risikostufen:

* '''Unzulässig''' (z. B. Social Scoring, biometrische Echtzeit-Identifikation in öffentlichen Räumen) – Verbot ab Februar 2025.
* '''Hochrisiko''' (z. B. HR, Kreditvergabe, kritische Infrastruktur) – Konformitätsbewertung, Dokumentationspflichten und menschliche Aufsicht ab 2026/2027.
* '''Geringes Risiko''' – Transparenzpflichten (z. B. Chatbots).
* '''GPAI (General Purpose AI)''' – Risikoanalyse und technische Dokumentation für Modelle wie GPT-Varianten.

Bußgelder bis 35 Mio. € oder 7% Umsatz. Verantwortung liegt primär beim Provider, sekundär beim Deployer.

'''Weiterführende Informationen:'''

* [[EU AI Act|Wiki: EU AI Act]]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32024R1689 EU AI Act Volltext]

=== Nationale Regelungen ===

* '''Deutschland''': Ergänzungen durch BDSG (§ 37 Automatisierte Entscheidungen im Einzelfall einschließlich Profiling), KI-Strategie der Bundesregierung (2020/aktualisiert 2025). Behörden müssen öffentlich-rechtliche Prinzipien (Rechtsstaatlichkeit, Verhältnismäßigkeit) wahren.
* '''Länderspezifisch''': Hessische KI-Verordnung, bayrische Orientierungshilfen für öffentliche Verwaltung.
* '''Sektoral''': Finanzsektor (BaFin-Marco), Gesundheitswesen (DiGA-Verordnung).

'''Weiterführende Informationen:'''

* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Kuenstliche-Intelligenz/AIC4/aic4.html Kriterienkatalog für <abbr>KI</abbr>-Cloud-Dienste – <abbr>AIC4</abbr>]
* [https://www.gesetze-im-internet.de/bdsg_2018/__37.html BDSG: §37 Automatisierte Entscheidungen im Einzelfall einschließlich Profiling]

=== Übergangsregelungen und Neuklassifizierung ===
KI-Systeme müssen bei wesentlichen Änderungen neu klassifiziert werden. Bestehende Systeme bis 2027.

== Datenschutzrechtliche Aspekte ==

=== DSGVO-Konformität ===
KI-Trainingsdaten unterliegen Art. 5 DSGVO (Rechtsmäßigkeit, Zweckbindung). Bei biometrischen Daten: Art. 10 KI-VO (Verbot biometrische Kategorisierung). Datenschutz-Folgenabschätzung (DSFA, Art. 35) obligatorisch für Hochrisiko-Anwendungen.

'''Kernpflichten'''

* '''Trainingsdaten''': Bereinigung sensibler Daten, Pseudonymisierung, Löschung nach Zweck (Art. 17).
* '''Outputs''': Transparenz bei automatisierter Entscheidungsfindung (Art. 22), Recht auf Erklärung.
* '''AVV (Auftragsverarbeitung)''': Cloud-KI-Provider als Auftragsverarbeiter prüfen.

=== Orientierungshilfen ===

* '''Datenschutzkonferenz (DSK)''': Leitfaden „Künstliche Intelligenz und Datenschutz“ – Checkliste für Datensparsamkeit und Rechenschaftspflicht.
* '''BayLDA/LfDI''': Praktische Hinweise zu Shadow-KI und ChatGPT-Nutzung in Behörden.

=== Betroffenenrechte und Transparenz ===
Benutzende müssen über KI-Einsatz informiert werden (Art. 13/14). Erweiterte Informationspflichten bei GPAI: Modellkarte offenlegen. Bias-Tests dokumentieren, um Diskriminierungsverbot (Art. 21 GG) zu wahren.

'''Praktische Umsetzung'''
{| class="wikitable"
!Aspekt
!Maßnahme
!Rechtsgrundlage
|-
|DSFA
|Vor KI-Einsatz durchführen
|Art. 35 DSGVO
|-
|Rechteauskunft
|KI-spezifische Vorlage
|Art. 15 DSGVO
|-
|Löschung
|Trainingsdaten entfernen
|Art. 17 DSGVO
|}
'''Weiterführende Informationen:'''

* [https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf DSK: Orientierungshilfe zu datenschutzrechtlichen Besonderheiten generativer KI-Systeme mit RAG-Methode]
* [https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf DSK: Orientierungshilfe zu empfohlenen technischen und organisatorischen Maßnahmen bei der Entwicklung und beim Betrieb von KI-Systemen]
* [[KI Datenschutz|Wiki: Datenschutz in KI-Anwendungen.]]

== Sicherheitsaspekte (ISMS-Integration) ==
KI-Einsatz erfordert eine Erweiterung des ISMS um spezifische Gefährdungen, die die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) bedrohen und über den BSI IT-Grundschutz G0-Katalog hinausgehen. Nach BSI Standard 200-3 müssen diese in der Risikoanalyse bewertet und mit Maßnahmen aus ISO 27001 Anhang A (z. B. A.8.25 für sichere Entwicklung) kontrolliert werden.

=== Gefährdungskatalog-Ergänzungen ===
KI-spezifische Risiken wie folgt klassifiziert (CIA-Analyse):

* '''Prompt Injections''': Manipulation von Eingaben zu Large Language Models (hoch I/C).
* '''Data Poisoning''': Vergiftung von Trainingsdaten (hoch I, mittel A).
* '''Modelllecks''': Training Data Leakage oder IP-Exfiltration (hoch C).
* '''Unkontrollierte Nutzung von Schatten-KI''': Unkontrollierte Nutzung privater Tools (mittel C/I).
* '''Black-Box-Effekte''': Mangelnde Nachvollziehbarkeit (hoch I/A).

'''Integration in BSI-Module'''
{| class="wikitable"
!Gefährdung
!BSI G0-Modul
!Ergänzungsmaßnahme
|-
|Data Poisoning
|SYS.1.2 Datenintegrität
|Daten-Sanitization, Validierung
|-
|Modelllecks
|NET.4.1 Zugriffssteuerung
|API-Rate-Limiting, Differential Privacy
|-
|Shadow-KI
|ORG.2.1 Sicherheitsrichtlinien
|KI-Nutzungsrichtlinie (ISO A.5.1)
|}

=== ISMS-Maßnahmen und Standards ===
* '''BSI KI-Kriterienkatalog ([[RiLi-KI-Einsatz|2025]])''': Sicherheitsniveaus (Low/Medium/High) für generative KI, mit Tests auf Jailbreaks und Bias.
* '''ISO 27001 Anhang A''': A.14.2.7 Sichere Entwicklung von KI, A.12.6 Vulnerability-Management für Modelle.
* '''Risikobewertung''': Erweiterte Gefährdungsanalyse nach BSI 200-3, inklusive Supply-Chain-Risiken bei Cloud-KI-Providern.

'''Weiterführende Informationen:'''

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KI/Kriterienkatalog_KI-Modelle_Bundesverwaltung.html BSI KI-Kriterienkatalog 2025.]
* [[Zusätzliche Gefährdungen|Wiki: Zusätzliche Gefährdungen (ergänzt und spezifische KI-Gefährdungen)]]
* [[RiLi-KI-Einsatz|Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)]]
* [[LF-KI-Chatbots|Leitfaden für Mitarbeitende zur Nutzung von KI-Systemen.]]

== Technische Aspekte ==
Technische Umsetzung von KI muss Robustheit, Nachvollziehbarkeit und Datensicherheit gewährleisten, um EU AI Act-Anforderungen (z. B. Art. 15 für Hochrisiko) und ISMS-Ziele zu erfüllen. Der Fokus liegt auf dem gesamten KI-Lebenszyklus.

=== Implementierungsprinzipien ===

* '''Daten-Governance''': Saubere Trainingsdaten (Preprocessing, Anonymisierung), RAG (Retrieval-Augmented Generation) statt reinem Fine-Tuning zur Vermeidung von Halluzinationen.
* '''Modellsicherheit''': Hardening-Techniken wie Adversarial Training, Modellkardinalität (Input/Output-Beschränkungen).
* '''Nachvollziehbarkeit (XAI)''': SHAP für globale Feature-Importance, LIME für lokale Erklärungen einzelner Vorhersagen – essenziell für Art. 22 DSGVO.

=== Lebenszyklus-Management ===
'''KI-System-Phasen und Sicherheitskontrollen'''
{| class="wikitable"
!Phase
!Technische Maßnahmen
!ISMS-Verknüpfung
|-
|Auswahl/Training
|Datenvalidierung, Secure MPC
|A.8.25 Entwicklung
|-
|Deployment
|Sandboxing, Human-in-the-Loop
|A.12.4 Monitoring
|-
|Betrieb
|Continuous Model Monitoring (Drift/Bias)
|A.12.6 Vulnerabilities
|-
|Decommissioning
|Modelllöschung, Audit-Logs
|A.18.1 Compliance
|}

=== Hochrisiko-Anwendungen ===

* '''Sektoren''': HR (Bias-Prüfung), Gesundheitswesen (FDA/DiGA-konform), kritische Infrastruktur (real-time Robustheit).
* '''Technische Standards''': ONNX für Modell-Portabilität, TensorFlow Privacy für Federated Learning.

'''Praktische Umsetzung'''

* '''Tools''': MLflow für Lifecycle-Tracking, Adversarial Robustness Toolbox (ART) für Angriffstests.
* '''Cloud-KI''': AWS SageMaker oder Azure ML mit integrierten Security-Features prüfen (AVV-pflichtig).

'''Weiterführende Informationen:'''

* [https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R1689#art_11 EU AI Act Artikel 11 - Technische Dokumentation]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R1689#anx_IV EU AI Act Anhang IV - Technische Dokumentation]
* [https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/Leitfaden_KI-Systeme_230124.html BSI Secure AI Guidelines.]
* [[KI-Register|Wiki: KI-Register]]
* [[KI Cybersicherheit|KI als Fluch und Segen in der Cybersicherheit.]]

== Governance und Organisation ==
Eine effektive KI-Governance stellt sicher, dass KI-Einsatz mit ISMS-Zielen (ISO 27001, BSI Grundschutz) übereinstimmt und EU AI Act-Anforderungen erfüllt. Sie umfasst organisatorische Strukturen, Prozesse und Verantwortlichkeiten, um Risiken wie Shadow-KI oder Bias zu minimieren. Die Geschäftsleitung trägt gemäß ISO 27001 Abschnitt 5.1 die oberste Verantwortung und muss KI-spezifische Richtlinien (A.5.1) etablieren.

=== KI-Governancestruktur ===

* '''KI-Steuerungsgremium''': Interdisziplinäres Gremium (IT-Sicherheit, Datenschutzbeauftragte, Rechtsabteilung, Fachabteilungen) für Risikobewertungen, Modellfreigaben und Audits. Regelmäßige Meetings (vierteljährlich) zur Überprüfung von KI-Projekten.

* '''Rollen und Verantwortlichkeiten''':<br>
{| class="wikitable"
!Rolle
!Aufgaben
!Rechtsgrundlage
|-
|KI-Provider (extern)
|Technische Dokumentation, Konformitätserklärung
|EU AI Act Art. 13
|-
|KI-Deployer (intern)
|Risikoanalyse, menschliche Aufsicht
|EU AI Act Art. 29
|-
|Datenschutzbeauftragte
|DSFA, Betroffenenrechte
|DSGVO Art. 39
|-
|ISMS-Leitung
|Integration in Risikomanagement
|ISO 27001 A.5.1
|}

* '''KI-Nutzungsrichtlinie''': Verbot privater KI-Tools (Shadow-KI), Pflicht zu genehmigten Modellen, Sanktionen bei Verstößen. Schulungspflicht für Mitarbeitende (KI-Literacy).

=== Prozesse und Workflows ===

* '''Risikobewertungsvorlage''': Vorlage für neue KI-Projekte mit CIA-Analyse, EU AI Act-Risikostufe und DSFA-Trigger. Workflow: Antrag → Gremium → Freigabe → Monitoring.
* '''Audit und Reporting''': Jährliche KI-Inventar (alle Systeme auflisten), Incident-Reporting für Bias-Vorfälle oder Modell-Drift. Integration in ISO 27001 Management Review (Abschnitt 9.3).
* '''Schulungen''': Obligatorische Einstiegsschulung zu KI-Risiken (~2h), vertiefte für Entwickler (XAI, Secure Coding). Nachweis via LMS.

=== Besonderheiten für Behörden ===

* '''Grundrechtsschutz''': Zusätzliche Prüfung auf Verhältnismäßigkeit (GG Art. 1–3), Transparenz gegenüber Bürger:innen. Beliehene Unternehmen (z. B. Zeugnisstellen) fallen unter öffentlich-rechtliche Standards.
* '''Öffentliche Unternehmen''': Anpassung an Verwaltungsrecht (VwVfG § 35), Archivierungspflicht für KI-Entscheidungen.

'''Praktische Umsetzung'''

* '''Checkliste für KI-Projekte''':
*# Risikostufe bestimmen,
*# Provider prüfen,
*# DSFA durchführen,
*# Technische Dokumentation anlegen,
*# Monitoring einrichten.
* '''Vorlage''': KI-Risikobewertungstabelle (Excel) mit Spalten für Gefährdung, Wahrscheinlichkeit, Schaden, Maßnahmen.

'''Weiterführende Informationen:'''

* Wiki: ISMS-Organisation
* ISO 27001:2022 Abschnitt 5 (Führung).

== Weiterführende Quellen ==

=== Primärquellen (Gesetze und Verordnungen) ===

* '''EU AI Act''': Volltext – Offizielle Übersetzung, Anhang mit Hochrisiko-Listen.
* '''DSGVO''': Art. 22, 35 – Automatisierte Entscheidungen, DSFA.
* '''BDSG''': § 22 – Automatisierte Entscheidungen im öffentlichen Recht.

=== Behörden und Standardisierungsgremien ===

* '''BSI''':
** KI-Kriterienkatalog 2025 – Testszenarien für generative KI.
** IT-Grundschutz Compendium – G0-Module.
* '''Datenschutzkonferenz (DSK)''': Leitfaden KI und Datenschutz – Praktische Checkliste.
* '''BayLDA''': KI & Datenschutz – Orientierung für Behörden.

=== Branchenverbände und Ratgeber ===

* '''IHK München''': Datenschutz & KI – Praktische Hinweise für KMU.
* '''Bitkom''': KI-Guide für Unternehmen – Best Practices.
* '''BaFin''': Marco für KI im Finanzsektor.

=== Technische Ressourcen ===

* '''XAI-Tools''': SHAP-Dokumentation, LIME – Open Source für Erklärbarkeit.
* '''Secure AI Frameworks''': Adversarial Robustness Toolbox – Tests auf Angriffe.

=== Wiki-interne Verweise ===

* [[EU AI Act]]
* [[KI Cybersicherheit]]
* [[KI Datenschutz]]
* [[KI-Nutzung]]
* [[KI-Register]]
* [[LF-KI-Chatbots]]
* [[RiLi-KI-Einsatz]]
* [[Zusätzliche Gefährdungen]]

[[Kategorie:Artikel]]
[[Kategorie:KI]]

RiLi-KI-Einsatz

2026-03-29T19:07:35Z

Dirk: /* Ethische Leitplanken und Innovation */

{{#seo:
|title=Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)
|keywords=ISMS, KI-Sicherheit, KI-Richtlinie, Compliance, Datenschutz, Ethik, KI-Einsatz, Unternehmen, Informationssicherheit, Risikomanagement
|description=Diese Richtlinie hilft die Vorteile von KI zu nutzen und dabei Risiken zu minimieren und Compliance sicherzustellen.
}}{{SHORTDESC:Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)}}
Mustervorlage: '''"Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)"'''

''Muster-Richtlinie für den sicheren Einsatz von KI in der Organisation. Diese Richtlinie hilft die Vorteile von KI zu nutzen und dabei Risiken zu minimieren und Compliance sicherzustellen.''

== Einleitung ==
Künstliche Intelligenz (KI) bietet der Organisation erhebliche Chancen zur Effizienzsteigerung, Innovation und Verbesserung von Dienstleistungen. Angesichts der rasanten Entwicklung von KI-Technologien und der damit verbundenen Risiken ist es unerlässlich, klare Richtlinien für den sicheren und verantwortungsvollen Einsatz von KI-Systemen festzulegen.

Diese Richtlinie soll einen Rahmen schaffen, um die Vorteile von KI zu nutzen und gleichzeitig potenzielle Risiken zu minimieren und die Einhaltung relevanter Gesetze und Vorschriften zu gewährleisten, einschließlich der EU-KI-Verordnung.

== Begriffsklärung ==
Dieses Kapitel erläutert Fachbegriffe im Zusammenhang mit Künstlicher Intelligenz (KI), die in dieser Richtlinie verwendet werden und nicht als allgemeine IT-Ausdrücke vorausgesetzt werden können. Diese Begriffsklärung soll dazu beitragen, ein gemeinsames Verständnis der in dieser Richtlinie verwendeten KI-bezogenen Terminologie zu schaffen und sicherzustellen, dass alle Beteiligten die Richtlinie effektiv umsetzen können.

'''Bias (Verzerrung):''' Systematische Fehler in KI-Modellen, die zu ungerechten oder diskriminierenden Ergebnissen führen können. Bias kann in den Trainingsdaten, im Modell selbst oder in der Art und Weise, wie das Modell eingesetzt wird, entstehen.

'''CV-Screening-Tool:''' Ein KI-basiertes System, das Lebensläufe (CVs) automatisch analysiert und bewertet, um den Rekrutierungsprozess zu unterstützen.

'''Deepfakes:''' KI-generierte, überzeugend gefälschte Audio- oder Videoinhalte, die oft dazu verwendet werden, Einzelpersonen in kompromittierenden Situationen darzustellen oder Falschinformationen zu verbreiten.

'''Differential Privacy:''' Eine Technik, die verwendet wird, um die Privatsphäre von Datensätzen zu schützen, indem zufälliges Rauschen zu den Daten hinzugefügt wird. Dies ermöglicht es, Erkenntnisse aus den Daten zu gewinnen, ohne die Identität einzelner Personen preiszugeben.

'''Explainable AI (XAI):''' Ansätze und Methoden, die darauf abzielen, die Entscheidungen von KI-Systemen für den Menschen verständlicher und nachvollziehbarer zu machen. Dies ist besonders wichtig in Bereichen, in denen Transparenz und Rechenschaftspflicht erforderlich sind.

'''Generative KI:''' Eine Art von KI, die in der Lage ist, neue Inhalte zu erstellen, wie z.B. Texte, Bilder, Musik oder Code. Beispiele hierfür sind Large Language Models (LLMs) und Bildgenerierungsmodelle.

'''KI-Register:''' Ein Verzeichnis, das alle in der Organisation eingesetzten KI-Systeme dokumentiert. Das Register enthält Informationen über den Zweck des Systems, die Risikoklasse, die verwendeten Daten und die Verantwortlichkeiten.

'''Large Language Models (LLMs):''' Sehr große KI-Modelle, die auf riesigen Mengen an Textdaten trainiert wurden und in der Lage sind, menschenähnlichen Text zu generieren, zu übersetzen und zusammenzufassen.

'''Machine Learning (ML):''' Ein Teilbereich der KI, der sich mit der Entwicklung von Algorithmen befasst, die es Computern ermöglichen, aus Daten zu lernen, ohne explizit programmiert zu werden.

'''Modell-Drift:''' Eine Verschlechterung der Leistung eines Machine-Learning-Modells im Laufe der Zeit, die durch Veränderungen in den Eingabedaten oder der Umgebung verursacht wird.

'''Overfitting:''' Ein Zustand, in dem ein Machine-Learning-Modell die Trainingsdaten zu gut lernt und dadurch Schwierigkeiten hat, auf neue, unbekannte Daten zu generalisieren.

'''Prompt-Injection:''' Eine Art von Sicherheitslücke, bei der ein Angreifer bösartige Eingaben (Prompts) verwendet, um die Ausgabe eines KI-Systems zu manipulieren oder sensible Informationen zu extrahieren.

'''Synthetic Data Generation:''' Die Erzeugung von künstlichen Daten, die reale Daten simulieren, aber keine personenbezogenen Informationen enthalten. Synthetic Data kann verwendet werden, um KI-Modelle zu trainieren, ohne die Privatsphäre zu gefährden.

== Geltungsbereich ==
Diese Richtlinie gilt für alle Mitarbeitenden, Auftragnehmenden und Dritte, die KI-Systeme im Auftrag der Organisation entwickeln, implementieren, nutzen oder verwalten. Sie umfasst alle Arten von KI-Systemen, einschließlich, aber nicht beschränkt auf:

* Generative KI (z.B. Large Language Models – LLMs)
* Maschinelles Lernen (ML)
* Robotik
* Künstliche neuronale Netze

== Zielsetzung ==
Diese Richtlinie zielt darauf ab:

* Die Integration von Sicherheitsaspekten in den gesamten Lebenszyklus von KI-Systemen zu gewährleisten.
* Risiken im Zusammenhang mit KI-Technologien zu identifizieren, zu bewerten und zu minimieren.
* Die Einhaltung von Datenschutzbestimmungen, ethischen Grundsätzen und relevanten Gesetzen, einschließlich der EU-KI-Verordnung, sicherzustellen.
* Transparenz und Verantwortlichkeit im Umgang mit KI-Systemen zu fördern.
* Das Bewusstsein für die potenziellen Risiken und Chancen von KI bei den Mitarbeitenden zu schärfen.
* Innovation und Wettbewerbsfähigkeit im Einklang mit ethischen Grundsätzen und regulatorischen Anforderungen zu fördern.

== Verantwortlichkeiten ==
* '''Organisationsleitung:''' Verantwortlich für die Genehmigung dieser Richtlinie und die Bereitstellung der notwendigen Ressourcen für deren Umsetzung.
* '''Informationssicherheitsbeauftragte (ISB):''' Verantwortlich für die Überwachung der Einhaltung dieser Richtlinie und die Integration von KI-Sicherheit in das ISMS.
* '''Datenschutzbeauftragte (DSB):''' Verantwortlich für die Überwachung der Einhaltung der Datenschutzbestimmungen im Zusammenhang mit KI-Systemen.
* '''KI-Projektverantwortliche:''' Verantwortlich für die Einhaltung dieser Richtlinie bei der Entwicklung, Implementierung und Nutzung von KI-Systemen in ihren Projekten.
* '''Alle Mitarbeitenden:''' Verantwortlich für die Einhaltung dieser Richtlinie bei der Nutzung von KI-Systemen im Rahmen ihrer Tätigkeit für die Organisation.

== Richtlinien und Verfahren ==
Der sichere und verantwortungsvolle Einsatz von KI-Systemen erfordert einen ganzheitlichen Ansatz, der technische, organisatorische und ethische Aspekte berücksichtigt. Die folgenden Richtlinien und Verfahren bilden das Fundament für eine robuste KI-Governance in unserer Organisation.

Sie adressieren die Integration von KI-Sicherheit in bestehende Strukturen, die systematische Risikobewertung, die Einhaltung rechtlicher und ethischer Standards sowie die Gewährleistung von Transparenz und Verantwortlichkeit.

Diese Maßnahmen sollen sicherstellen, dass wir die Chancen der KI-Technologie nutzen können, während wir gleichzeitig potenzielle Risiken minimieren und das Vertrauen unserer Stakeholder in unsere KI-Anwendungen stärken.

=== Integration von KI-Sicherheit in das ISMS ===
KI-Systeme stellen durch ihre Komplexität und Lernfähigkeit einzigartige Sicherheitsherausforderungen dar. Um diese systematisch zu adressieren, werden KI-Komponenten vollständig in das ISMS integriert. Dies bedeutet konkret:

* Alle KI-Systeme unterliegen den allgemeinen Sicherheitsrichtlinien der Organisation.
* Spezifische Schutzmaßnahmen gegen KI-spezifische Angriffsvektoren wie Prompt-Injection sind zu implementieren, da ungefilterte Eingaben zu manipulierten Ergebnissen oder Datenlecks führen können.
* Für LLMs (Large Language Models) sind zusätzliche Content-Filter und Input-Validierungen vorzusehen, um die Generierung von Fehlinformationen oder urheberrechtlich problematischen Inhalten zu verhindern.

=== Risikobewertung von KI-Systemen ===
Aufgrund der dynamischen Entwicklungen im KI-Bereich erfordert jede KI-Anwendung eine initiale und jährliche Risikoanalyse. Dieser Prozess dient dazu:

* Kritische Einsatzbereiche (z.B. personalisierte Kundeninteraktionen) zu identifizieren, wo Fehlentscheidungen rechtliche oder reputative Schäden verursachen könnten.
* Technische Risiken wie Modell-Drift (unbemerkte Leistungsverschlechterung) zu berücksichtigen, die durch kontinuierliches Monitoring aufgefangen werden müssen.
* Ethische Risikofaktoren (Bias in Trainingsdaten) zu analysieren, die etwa zu diskriminierenden Entscheidungen führen könnten – ein Aspekt, der zentral für die Akzeptanz von KI-Systemen ist.

=== Compliance-konformer KI-Einsatz ===
Die EU-KI-Verordnung (AI Act) klassifiziert KI-Systeme in vier Risikoklassen – diese Einstufung bildet die Basis für unsere Compliance-Maßnahmen:

* Verbot bestimmter KI-Praktiken, wie z.B. Social Scoring durch Behörden (AI Act, Art. 5).
* Hochrisiko-KI-Systeme (z.B. CV-Screening-Tools) erfordern eine Konformitätserklärung, technische Dokumentation und menschliche Aufsichtspflicht.
* Transparenzpflichten gemäß Art. 52 AI Act: Bei KI-gesteuerten Chatbots muss für Nutzende klar erkennbar sein, dass sie mit einem KI-System interagieren.
* Datenherkunftsnachweise sind für Trainingsdatensätze zu führen, um Urheberrechtsverletzungen und Compliance-Risiken bei generativer KI (z.B. Text-/Bildgenerierung) zu minimieren.

=== Datensicherheit und Datenschutz ===
KI-Systeme sind datenhungrig – dieser Abschnitt stellt sicher, dass Datenflüsse rechtssicher gestaltet werden:

* Bei der Verarbeitung personenbezogener Daten ist das Prinzip "Privacy by Design" umzusetzen, z.B. durch Synthetic Data Generation oder Differential Privacy bei sensiblen Datensätzen.
* Datenminimierung ist besonders kritisch: Trainingsdatensätze dürfen nur notwendige Attribute enthalten, um das "Overfitting"-Risiko (unbeabsichtigtes Speichern sensitiver Muster) zu reduzieren.

=== Transparenz und Rechenschaftspflicht ===
Nachvollziehbarkeit ist Voraussetzung für Vertrauen in KI-Entscheidungen. Hierfür wird festgelegt:

* Entscheidungsprotokolle müssen so dokumentiert werden, dass eine Nachvollziehbarkeit ohne Fachwissen in Machine Learning möglich ist (Explainable AI-Prinzipien).
* Eine Eskalationsmatrix definiert Verantwortlichkeiten – z.B. ob der KI-Entwickler, Fachbereich oder die Organisationsleitung bei Fehlentscheidungen haftet.

=== Ethische Leitplanken und Innovation ===
Um Innovationspotenziale verantwortungsvoll zu nutzen, gilt:

* Ethische Review-Boards begleiten KI-Projekte ab der Konzeptphase, analog zu Medizintechnik-Entwicklungen.
* Open-Source-KI-Komponenten sind generell zu bevorzugen, sofern sie die Sicherheitsanforderungen erfüllen – dies fördert Reproduzierbarkeit und unabhängige Sicherheitsaudits.

=== Führen eines KI-Register ===
In der Organisation ist ein [[KI-Register]] zu führen. Das [[KI-Register]] ist ein Verzeichnis aller in der Organisation eingesetzten KI-Anwendungen. Ziel des Registers ist es, Transparenz über den Einsatz von Künstlicher Intelligenz zu schaffen und zentrale Informationen wie den Zweck, die Funktionsweise, die Verantwortlichkeiten, die eingesetzten Datenarten, die Risikokategorie sowie Maßnahmen zu Datenschutz und IT-Sicherheit zu erfassen.

== Freigabeprozess für KI-Anwendungen ==

=== Ziel des Freigabeprozesses ===
Der Freigabeprozess stellt sicher, dass ausschließlich sichere, rechtskonforme und zweckgebundene KI-Anwendungen im Unternehmen eingesetzt werden. Er integriert EU AI Act-Anforderungen (Art. 5, 6, 11), DSGVO (Art. 35 DSFA) und BSI Grundschutz in das bestehende Software-Freigabeverfahren.

=== Verantwortlichkeiten ===
{| class="wikitable"
!Rolle
!Aufgabe
|-
|'''Antragsteller'''
|Fachbereich/Funktionsträger mit Bedarf an KI-Anwendung
|-
|'''KI-Compliance-Team'''
|Prüfung Rechtmäßigkeit, Sicherheit, Datenschutz (IT-Sicherheit, Datenschutzbeauftragte, Rechtsabteilung)
|-
|'''Unternehmensleitung'''
|Finale Freigabe (oder Beauftragte)
|-
|'''IT-Abteilung'''
|Technische Integration, Monitoring
|}

=== Freigabestufen (gemäß EU AI Act-Risikoklassen) ===
{| class="wikitable"
!Risikostufe
!Prüfungstiefe
!Genehmigung
|-
|'''Unzulässig''' (Art. 5)
|Sofortiges Verbot (Social Scoring, etc.)
|Nie
|-
|'''Hochrisiko''' (Art. 6)
|DSFA, Technische Dokumentation (Anhang IV), XAI
|Geschäftsführung
|-
|'''GPAI'''
|Modellkarte, Copyright-Check
|Geschäftsführung
|-
|'''Gering'''
|Transparenzpflicht, Shadow-KI-Check
|KI-Compliance-Team
|}

=== Ablauf des Freigabeprozesses ===
Der Freigabeprozess erfolgt entsprechend der [[RiLi-Freigabe|Freigaberichtlinie für Hard- und Software]].

=== Verbotene Praktiken ===
Die folgenden KI-Praktiken sind gemäß Art. 5 AI Act grundsätzlich verboten und dürfen nicht freigegeben werden:

* Social Scoring durch Behörden
* Biometrische Kategorisierung (außer medizinisch)
* Echtzeit-Biometrie in öffentlichen Räumen
* Emotionserkennung Arbeitsplatz

== Schulung und Sensibilisierung ==
KI-Kompetenz ist kein IT-Spezialthema mehr. Unser Schulungskonzept umfasst daher:

* Pflichttrainings für Führungskräfte zur Risikoeinschätzung von KI-Projekten (Analog: DSGVO-Schulungen).
* Praxisworkshops für Entwicklerteams zu Secure-Coding-Praktiken für KI-Modelle, inklusive OWASP-Top-10 für Machine Learning.
* Awareness-Kampagnen für alle Mitarbeitenden zur Erkennung von Deepfakes und KI-generierten Phishing-Angriffen.

== Überwachung und kontinuierliche Verbesserung ==
KI-Systeme sind keine "Fire-and-Forget"-Lösungen. Unser Kontrollsystem sieht vor:

* Quartalsweise Performance-Audits mit Bias-Checks mittels Tools wie z.B. IBM AI Fairness 360.
* Einrichtung eines KI-Registers zur Dokumentation aller produktiven KI-Anwendungen inkl. ihrer Risikoklassifizierung.
* Bug-Bounty-Programme, die explizit Schwachstellen in KI-Komponenten adressieren.

== Anlage ==

* [[KI-Register|KI-Register der Organisation]]

== Schlussbemerkung ==

=== Behandlung von Ausnahmen ===
Ausnahmen von den Regelungen dieser Richtlinie sind nur mit einem begründeten Ausnahmeantrag im Rahmen des [[RiLi-Ausnahmemanagement|Ausnahmemanagements]] möglich.

=== Revision ===
Diese Richtlinie wird regelmäßig, jedoch mindestens einmal pro Jahr, durch den Regelungsverantwortlichen auf Aktualität und Konformität geprüft und bei Bedarf angepasst.

== Inkrafttreten ==
Diese Richtlinie tritt zum 01.01.2222 in Kraft.

Freigegeben durch: Organisationsleitung

Ort, 01.12.2220,

Unterschrift, Name der Leitung
[[Kategorie:Mustervorlage]]
[[Kategorie:Richtlinie]]
[[Kategorie:KI]]

KI Startseite

2026-03-29T09:02:05Z

Dirk:

{{Vorlage:Entwurf}}
{{#seo:
|title=KI-Einsatz: ISMS-integration, EU AI Act, DSGVO, BSI Grundschutz
|keywords=KI-Einsatz, EU AI Act, ISO 27001, BSI IT-Grundschutz, DSGVO KI, KI-Risikomanagement, Informationssicherheit KI, Datenschutz KI
|description=KI in Unternehmen & Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.}}
{{SHORTDESC:Einführung zu sinnvollen Regelungen für den KI-Einsatz}}''KI-Einsatz in Unternehmen und Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.''

== Einleitung ==
Der Einsatz von Künstlicher Intelligenz (KI) in Unternehmen und Behörden gewinnt rasant an Bedeutung und stellt Informationssicherheits-Managementsysteme (ISMS) vor neue Herausforderungen. KI-Systeme verarbeiten oft personenbezogene Daten, treffen automatisierte Entscheidungen und erfordern eine nahtlose Integration in bestehende Standards wie ISO/IEC 27001 sowie BSI Grundschutz. Der EU AI Act (seit August 2024 rechtskräftig) etabliert einen risikobasierten Ansatz, der mit DSGVO und BDSG kompatibel ist und spezifische Anforderungen an Transparenz, Robustheit und Nachvollziehbarkeit stellt.

Für Behörden gelten zusätzlich öffentlich-rechtliche Bindungen (z.B. Grundrechte Art. 1–3 GG), während Unternehmen wirtschaftliche Risiken wie Vendor Lock-in oder Haftungsstreitigkeiten prüfen müssen. Dieser Artikel fasst rechtliche, datenschutzrechtliche, sicherheitstechnische und organisatorische Belange zusammen und verweist auf vertiefende Inhalte im Wiki sowie externe Quellen.

'''Relevanz für ISMS'''

KI-Einsatz beeinflusst die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) und erfordert [[Zusätzliche Gefährdungen|Ergänzungen]] der verwendeten Risikokataloge wie z.B. den BSI G0-Katalog. Ziel ist eine risikobasierte Implementierung des KI-Einsatzes.

== Rechtlicher Rahmen ==

* '''EU AI Act''': Risikobasierte Klassifikation (verboten, hochrisiko, geringes Risiko, GPAI). Zeitlicher Fahrplan (Verbote ab 2025, Hochrisiko ab 2026/2027). Anforderungen an Dokumentation, Konformität und Bußgelder.
* '''Nationale Regelungen''': DSGVO-Integration (Art. 10 KI-VO für biometrische Daten), BDSG, öffentlich-rechtliche Sonderbindungen (GG Art. 1–3) für Behörden.
* '''Sektorale Vorgaben''': Verwaltungsrecht, hessische/länderspezifische Initiativen für öffentlichen Sektor.

=== EU AI Act ===
Der EU AI Act klassifiziert KI-Systeme in vier Risikostufen:

* '''Unzulässig''' (z. B. Social Scoring, biometrische Echtzeit-Identifikation in öffentlichen Räumen) – Verbot ab Februar 2025.
* '''Hochrisiko''' (z. B. HR, Kreditvergabe, kritische Infrastruktur) – Konformitätsbewertung, Dokumentationspflichten und menschliche Aufsicht ab 2026/2027.
* '''Geringes Risiko''' – Transparenzpflichten (z. B. Chatbots).
* '''GPAI (General Purpose AI)''' – Risikoanalyse und technische Dokumentation für Modelle wie GPT-Varianten.

Bußgelder bis 35 Mio. € oder 7% Umsatz. Verantwortung liegt primär beim Provider, sekundär beim Deployer.

'''Weiterführende Informationen:'''

* [[EU AI Act|Wiki: EU AI Act]]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32024R1689 EU AI Act Volltext]

=== Nationale Regelungen ===

* '''Deutschland''': Ergänzungen durch BDSG (§ 37 Automatisierte Entscheidungen im Einzelfall einschließlich Profiling), KI-Strategie der Bundesregierung (2020/aktualisiert 2025). Behörden müssen öffentlich-rechtliche Prinzipien (Rechtsstaatlichkeit, Verhältnismäßigkeit) wahren.
* '''Länderspezifisch''': Hessische KI-Verordnung, bayrische Orientierungshilfen für öffentliche Verwaltung.
* '''Sektoral''': Finanzsektor (BaFin-Marco), Gesundheitswesen (DiGA-Verordnung).

'''Weiterführende Informationen:'''

* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Kuenstliche-Intelligenz/AIC4/aic4.html Kriterienkatalog für <abbr>KI</abbr>-Cloud-Dienste – <abbr>AIC4</abbr>]
* [https://www.gesetze-im-internet.de/bdsg_2018/__37.html BDSG: §37 Automatisierte Entscheidungen im Einzelfall einschließlich Profiling]

=== Übergangsregelungen und Neuklassifizierung ===
KI-Systeme müssen bei wesentlichen Änderungen neu klassifiziert werden. Bestehende Systeme bis 2027.

== Datenschutzrechtliche Aspekte ==

=== DSGVO-Konformität ===
KI-Trainingsdaten unterliegen Art. 5 DSGVO (Rechtsmäßigkeit, Zweckbindung). Bei biometrischen Daten: Art. 10 KI-VO (Verbot biometrische Kategorisierung). Datenschutz-Folgenabschätzung (DSFA, Art. 35) obligatorisch für Hochrisiko-Anwendungen.

'''Kernpflichten'''

* '''Trainingsdaten''': Bereinigung sensibler Daten, Pseudonymisierung, Löschung nach Zweck (Art. 17).
* '''Outputs''': Transparenz bei automatisierter Entscheidungsfindung (Art. 22), Recht auf Erklärung.
* '''AVV (Auftragsverarbeitung)''': Cloud-KI-Provider als Auftragsverarbeiter prüfen.

=== Orientierungshilfen ===

* '''Datenschutzkonferenz (DSK)''': Leitfaden „Künstliche Intelligenz und Datenschutz“ – Checkliste für Datensparsamkeit und Rechenschaftspflicht.
* '''BayLDA/LfDI''': Praktische Hinweise zu Shadow-KI und ChatGPT-Nutzung in Behörden.

=== Betroffenenrechte und Transparenz ===
Benutzende müssen über KI-Einsatz informiert werden (Art. 13/14). Erweiterte Informationspflichten bei GPAI: Modellkarte offenlegen. Bias-Tests dokumentieren, um Diskriminierungsverbot (Art. 21 GG) zu wahren.

'''Praktische Umsetzung'''
{| class="wikitable"
!Aspekt
!Maßnahme
!Rechtsgrundlage
|-
|DSFA
|Vor KI-Einsatz durchführen
|Art. 35 DSGVO
|-
|Rechteauskunft
|KI-spezifische Vorlage
|Art. 15 DSGVO
|-
|Löschung
|Trainingsdaten entfernen
|Art. 17 DSGVO
|}
'''Weiterführende Informationen:'''

* [https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf DSK: Orientierungshilfe zu datenschutzrechtlichen Besonderheiten generativer KI-Systeme mit RAG-Methode]
* [https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf DSK: Orientierungshilfe zu empfohlenen technischen und organisatorischen Maßnahmen bei der Entwicklung und beim Betrieb von KI-Systemen]

== Sicherheitsaspekte (ISMS-Integration) ==
KI-Einsatz erfordert eine Erweiterung des ISMS um spezifische Gefährdungen, die die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) bedrohen und über den BSI IT-Grundschutz G0-Katalog hinausgehen. Nach BSI Standard 200-3 müssen diese in der Risikoanalyse bewertet und mit Maßnahmen aus ISO 27001 Anhang A (z. B. A.8.25 für sichere Entwicklung) kontrolliert werden.

=== Gefährdungskatalog-Ergänzungen ===
KI-spezifische Risiken wie folgt klassifiziert (CIA-Analyse):

* '''Prompt Injections''': Manipulation von Eingaben zu Large Language Models (hoch I/C).
* '''Data Poisoning''': Vergiftung von Trainingsdaten (hoch I, mittel A).
* '''Modelllecks''': Training Data Leakage oder IP-Exfiltration (hoch C).
* '''Unkontrollierte Nutzung von Schatten-KI''': Unkontrollierte Nutzung privater Tools (mittel C/I).
* '''Black-Box-Effekte''': Mangelnde Nachvollziehbarkeit (hoch I/A).

'''Integration in BSI-Module'''
{| class="wikitable"
!Gefährdung
!BSI G0-Modul
!Ergänzungsmaßnahme
|-
|Data Poisoning
|SYS.1.2 Datenintegrität
|Daten-Sanitization, Validierung
|-
|Modelllecks
|NET.4.1 Zugriffssteuerung
|API-Rate-Limiting, Differential Privacy
|-
|Shadow-KI
|ORG.2.1 Sicherheitsrichtlinien
|KI-Nutzungsrichtlinie (ISO A.5.1)
|}

=== ISMS-Maßnahmen und Standards ===
* '''BSI KI-Kriterienkatalog (2025)''': Sicherheitsniveaus (Low/Medium/High) für generative KI, mit Tests auf Jailbreaks und Bias.
* '''ISO 27001 Anhang A''': A.14.2.7 Sichere Entwicklung von KI, A.12.6 Vulnerability-Management für Modelle.
* '''Risikobewertung''': Erweiterte Gefährdungsanalyse nach BSI 200-3, inklusive Supply-Chain-Risiken bei Cloud-KI-Providern.

'''Weiterführende Informationen:'''

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KI/Kriterienkatalog_KI-Modelle_Bundesverwaltung.html BSI KI-Kriterienkatalog 2025.]
* [[Zusätzliche Gefährdungen|Wiki: Zusätzliche Gefährdungen (ergänzt und spezifische KI-Gefährdungen)]]

== Technische Aspekte ==
Technische Umsetzung von KI muss Robustheit, Nachvollziehbarkeit und Datensicherheit gewährleisten, um EU AI Act-Anforderungen (z. B. Art. 15 für Hochrisiko) und ISMS-Ziele zu erfüllen. Der Fokus liegt auf dem gesamten KI-Lebenszyklus.

=== Implementierungsprinzipien ===

* '''Daten-Governance''': Saubere Trainingsdaten (Preprocessing, Anonymisierung), RAG (Retrieval-Augmented Generation) statt reinem Fine-Tuning zur Vermeidung von Halluzinationen.
* '''Modellsicherheit''': Hardening-Techniken wie Adversarial Training, Modellkardinalität (Input/Output-Beschränkungen).
* '''Nachvollziehbarkeit (XAI)''': SHAP für globale Feature-Importance, LIME für lokale Erklärungen einzelner Vorhersagen – essenziell für Art. 22 DSGVO.

=== Lebenszyklus-Management ===
'''KI-System-Phasen und Sicherheitskontrollen'''
{| class="wikitable"
!Phase
!Technische Maßnahmen
!ISMS-Verknüpfung
|-
|Auswahl/Training
|Datenvalidierung, Secure MPC
|A.8.25 Entwicklung
|-
|Deployment
|Sandboxing, Human-in-the-Loop
|A.12.4 Monitoring
|-
|Betrieb
|Continuous Model Monitoring (Drift/Bias)
|A.12.6 Vulnerabilities
|-
|Decommissioning
|Modelllöschung, Audit-Logs
|A.18.1 Compliance
|}

=== Hochrisiko-Anwendungen ===

* '''Sektoren''': HR (Bias-Prüfung), Gesundheitswesen (FDA/DiGA-konform), kritische Infrastruktur (real-time Robustheit).
* '''Technische Standards''': ONNX für Modell-Portabilität, TensorFlow Privacy für Federated Learning.

'''Praktische Umsetzung'''

* '''Tools''': MLflow für Lifecycle-Tracking, Adversarial Robustness Toolbox (ART) für Angriffstests.
* '''Cloud-KI''': AWS SageMaker oder Azure ML mit integrierten Security-Features prüfen (AVV-pflichtig).

'''Weiterführende Informationen:'''

* [https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R1689#art_11 EU AI Act Artikel 11 - Technische Dokumentation]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R1689#anx_IV EU AI Act Anhang IV - Technische Dokumentation]
* [https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/Leitfaden_KI-Systeme_230124.html BSI Secure AI Guidelines.]
* [[KI-Register|Wiki: KI-Register]]

== Governance und Organisation ==
Eine effektive KI-Governance stellt sicher, dass KI-Einsatz mit ISMS-Zielen (ISO 27001, BSI Grundschutz) übereinstimmt und EU AI Act-Anforderungen erfüllt. Sie umfasst organisatorische Strukturen, Prozesse und Verantwortlichkeiten, um Risiken wie Shadow-KI oder Bias zu minimieren. Die Geschäftsleitung trägt gemäß ISO 27001 Abschnitt 5.1 die oberste Verantwortung und muss KI-spezifische Richtlinien (A.5.1) etablieren.

=== KI-Governancestruktur ===

* '''KI-Steuerungsgremium''': Interdisziplinäres Gremium (IT-Sicherheit, Datenschutzbeauftragte, Rechtsabteilung, Fachabteilungen) für Risikobewertungen, Modellfreigaben und Audits. Regelmäßige Meetings (vierteljährlich) zur Überprüfung von KI-Projekten.

* '''Rollen und Verantwortlichkeiten''':<br>
{| class="wikitable"
!Rolle
!Aufgaben
!Rechtsgrundlage
|-
|KI-Provider (extern)
|Technische Dokumentation, Konformitätserklärung
|EU AI Act Art. 13
|-
|KI-Deployer (intern)
|Risikoanalyse, menschliche Aufsicht
|EU AI Act Art. 29
|-
|Datenschutzbeauftragte
|DSFA, Betroffenenrechte
|DSGVO Art. 39
|-
|ISMS-Leitung
|Integration in Risikomanagement
|ISO 27001 A.5.1
|}

* '''KI-Nutzungsrichtlinie''': Verbot privater KI-Tools (Shadow-KI), Pflicht zu genehmigten Modellen, Sanktionen bei Verstößen. Schulungspflicht für Mitarbeitende (KI-Literacy).

=== Prozesse und Workflows ===

* '''Risikobewertungsvorlage''': Vorlage für neue KI-Projekte mit CIA-Analyse, EU AI Act-Risikostufe und DSFA-Trigger. Workflow: Antrag → Gremium → Freigabe → Monitoring.
* '''Audit und Reporting''': Jährliche KI-Inventar (alle Systeme auflisten), Incident-Reporting für Bias-Vorfälle oder Modell-Drift. Integration in ISO 27001 Management Review (Abschnitt 9.3).
* '''Schulungen''': Obligatorische Einstiegsschulung zu KI-Risiken (~2h), vertiefte für Entwickler (XAI, Secure Coding). Nachweis via LMS.

=== Besonderheiten für Behörden ===

* '''Grundrechtsschutz''': Zusätzliche Prüfung auf Verhältnismäßigkeit (GG Art. 1–3), Transparenz gegenüber Bürger:innen. Beliehene Unternehmen (z. B. Zeugnisstellen) fallen unter öffentlich-rechtliche Standards.
* '''Öffentliche Unternehmen''': Anpassung an Verwaltungsrecht (VwVfG § 35), Archivierungspflicht für KI-Entscheidungen.

'''Praktische Umsetzung'''

* '''Checkliste für KI-Projekte''':
*# Risikostufe bestimmen,
*# Provider prüfen,
*# DSFA durchführen,
*# Technische Dokumentation anlegen,
*# Monitoring einrichten.
* '''Vorlage''': KI-Risikobewertungstabelle (Excel) mit Spalten für Gefährdung, Wahrscheinlichkeit, Schaden, Maßnahmen.

'''Weiterführende Informationen:'''

* Wiki: ISMS-Organisation
* ISO 27001:2022 Abschnitt 5 (Führung).

== Weiterführende Quellen ==

=== Primärquellen (Gesetze und Verordnungen) ===

* '''EU AI Act''': Volltext – Offizielle Übersetzung, Anhang mit Hochrisiko-Listen.
* '''DSGVO''': Art. 22, 35 – Automatisierte Entscheidungen, DSFA.
* '''BDSG''': § 22 – Automatisierte Entscheidungen im öffentlichen Recht.

=== Behörden und Standardisierungsgremien ===

* '''BSI''':
** KI-Kriterienkatalog 2025 – Testszenarien für generative KI.
** IT-Grundschutz Compendium – G0-Module.
* '''Datenschutzkonferenz (DSK)''': Leitfaden KI und Datenschutz – Praktische Checkliste.
* '''BayLDA''': KI & Datenschutz – Orientierung für Behörden.

=== Branchenverbände und Ratgeber ===

* '''IHK München''': Datenschutz & KI – Praktische Hinweise für KMU.
* '''Bitkom''': KI-Guide für Unternehmen – Best Practices.
* '''BaFin''': Marco für KI im Finanzsektor.

=== Technische Ressourcen ===

* '''XAI-Tools''': SHAP-Dokumentation, LIME – Open Source für Erklärbarkeit.
* '''Secure AI Frameworks''': Adversarial Robustness Toolbox – Tests auf Angriffe.

=== Wiki-interne Verweise ===

* [[EU AI Act]]
* [[KI Cybersicherheit]]
* [[KI Datenschutz]]
* [[KI-Nutzung]]
* [[KI-Register]]
* [[LF-KI-Chatbots]]
* [[RiLi-KI-Einsatz]]
* [[Zusätzliche Gefährdungen]]

[[Kategorie:Artikel]]
[[Kategorie:KI]]

KI Startseite

2026-03-29T08:59:50Z

Dirk:

{{Vorlage:Entwurf}}
{{#seo:
|title=KI-Einsatz: ISMS-integration, EU AI Act, DSGVO, BSI Grundschutz
|keywords=KI-Einsatz, EU AI Act, ISO 27001, BSI IT-Grundschutz, DSGVO KI, KI-Risikomanagement, Informationssicherheit KI, Datenschutz KI
|description=KI in Unternehmen & Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.}}
{{SHORTDESC:Einführung zu sinnvollen Regelungen für den KI-Einsatz}}'''KI-Einsatz in Unternehmen und Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.'''

== Einleitung ==
Der Einsatz von Künstlicher Intelligenz (KI) in Unternehmen und Behörden gewinnt rasant an Bedeutung und stellt Informationssicherheits-Managementsysteme (ISMS) vor neue Herausforderungen. KI-Systeme verarbeiten oft personenbezogene Daten, treffen automatisierte Entscheidungen und erfordern eine nahtlose Integration in bestehende Standards wie ISO/IEC 27001 sowie BSI Grundschutz. Der EU AI Act (seit August 2024 rechtskräftig) etabliert einen risikobasierten Ansatz, der mit DSGVO und BDSG kompatibel ist und spezifische Anforderungen an Transparenz, Robustheit und Nachvollziehbarkeit stellt.

Für Behörden gelten zusätzlich öffentlich-rechtliche Bindungen (z.B. Grundrechte Art. 1–3 GG), während Unternehmen wirtschaftliche Risiken wie Vendor Lock-in oder Haftungsstreitigkeiten prüfen müssen. Dieser Artikel fasst rechtliche, datenschutzrechtliche, sicherheitstechnische und organisatorische Belange zusammen und verweist auf vertiefende Inhalte im Wiki sowie externe Quellen.

'''Relevanz für ISMS'''

KI-Einsatz beeinflusst die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) und erfordert [[Zusätzliche Gefährdungen|Ergänzungen]] der verwendeten Risikokataloge wie z.B. den BSI G0-Katalog. Ziel ist eine risikobasierte Implementierung des KI-Einsatzes.

== Rechtlicher Rahmen ==

* '''EU AI Act''': Risikobasierte Klassifikation (verboten, hochrisiko, geringes Risiko, GPAI). Zeitlicher Fahrplan (Verbote ab 2025, Hochrisiko ab 2026/2027). Anforderungen an Dokumentation, Konformität und Bußgelder.
* '''Nationale Regelungen''': DSGVO-Integration (Art. 10 KI-VO für biometrische Daten), BDSG, öffentlich-rechtliche Sonderbindungen (GG Art. 1–3) für Behörden.
* '''Sektorale Vorgaben''': Verwaltungsrecht, hessische/länderspezifische Initiativen für öffentlichen Sektor.

=== EU AI Act ===
Der EU AI Act klassifiziert KI-Systeme in vier Risikostufen:

* '''Unzulässig''' (z. B. Social Scoring, biometrische Echtzeit-Identifikation in öffentlichen Räumen) – Verbot ab Februar 2025.
* '''Hochrisiko''' (z. B. HR, Kreditvergabe, kritische Infrastruktur) – Konformitätsbewertung, Dokumentationspflichten und menschliche Aufsicht ab 2026/2027.
* '''Geringes Risiko''' – Transparenzpflichten (z. B. Chatbots).
* '''GPAI (General Purpose AI)''' – Risikoanalyse und technische Dokumentation für Modelle wie GPT-Varianten.

Bußgelder bis 35 Mio. € oder 7% Umsatz. Verantwortung liegt primär beim Provider, sekundär beim Deployer.

'''Weiterführende Informationen:'''

* [[EU AI Act|Wiki: EU AI Act]]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32024R1689 EU AI Act Volltext]

=== Nationale Regelungen ===

* '''Deutschland''': Ergänzungen durch BDSG (§ 37 Automatisierte Entscheidungen im Einzelfall einschließlich Profiling), KI-Strategie der Bundesregierung (2020/aktualisiert 2025). Behörden müssen öffentlich-rechtliche Prinzipien (Rechtsstaatlichkeit, Verhältnismäßigkeit) wahren.
* '''Länderspezifisch''': Hessische KI-Verordnung, bayrische Orientierungshilfen für öffentliche Verwaltung.
* '''Sektoral''': Finanzsektor (BaFin-Marco), Gesundheitswesen (DiGA-Verordnung).

'''Weiterführende Informationen:'''

* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Informationen-und-Empfehlungen/Kuenstliche-Intelligenz/AIC4/aic4.html Kriterienkatalog für <abbr>KI</abbr>-Cloud-Dienste – <abbr>AIC4</abbr>]
* [https://www.gesetze-im-internet.de/bdsg_2018/__37.html BDSG: §37 Automatisierte Entscheidungen im Einzelfall einschließlich Profiling]

=== Übergangsregelungen und Neuklassifizierung ===
KI-Systeme müssen bei wesentlichen Änderungen neu klassifiziert werden. Bestehende Systeme bis 2027.

== Datenschutzrechtliche Aspekte ==

=== DSGVO-Konformität ===
KI-Trainingsdaten unterliegen Art. 5 DSGVO (Rechtsmäßigkeit, Zweckbindung). Bei biometrischen Daten: Art. 10 KI-VO (Verbot biometrische Kategorisierung). Datenschutz-Folgenabschätzung (DSFA, Art. 35) obligatorisch für Hochrisiko-Anwendungen.

'''Kernpflichten'''

* '''Trainingsdaten''': Bereinigung sensibler Daten, Pseudonymisierung, Löschung nach Zweck (Art. 17).
* '''Outputs''': Transparenz bei automatisierter Entscheidungsfindung (Art. 22), Recht auf Erklärung.
* '''AVV (Auftragsverarbeitung)''': Cloud-KI-Provider als Auftragsverarbeiter prüfen.

=== Orientierungshilfen ===

* '''Datenschutzkonferenz (DSK)''': Leitfaden „Künstliche Intelligenz und Datenschutz“ – Checkliste für Datensparsamkeit und Rechenschaftspflicht.
* '''BayLDA/LfDI''': Praktische Hinweise zu Shadow-KI und ChatGPT-Nutzung in Behörden.

=== Betroffenenrechte und Transparenz ===
Benutzende müssen über KI-Einsatz informiert werden (Art. 13/14). Erweiterte Informationspflichten bei GPAI: Modellkarte offenlegen. Bias-Tests dokumentieren, um Diskriminierungsverbot (Art. 21 GG) zu wahren.

'''Praktische Umsetzung'''
{| class="wikitable"
!Aspekt
!Maßnahme
!Rechtsgrundlage
|-
|DSFA
|Vor KI-Einsatz durchführen
|Art. 35 DSGVO
|-
|Rechteauskunft
|KI-spezifische Vorlage
|Art. 15 DSGVO
|-
|Löschung
|Trainingsdaten entfernen
|Art. 17 DSGVO
|}
'''Weiterführende Informationen:'''

* [https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf DSK: Orientierungshilfe zu datenschutzrechtlichen Besonderheiten generativer KI-Systeme mit RAG-Methode]
* [https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf DSK: Orientierungshilfe zu empfohlenen technischen und organisatorischen Maßnahmen bei der Entwicklung und beim Betrieb von KI-Systemen]

== Sicherheitsaspekte (ISMS-Integration) ==
KI-Einsatz erfordert eine Erweiterung des ISMS um spezifische Gefährdungen, die die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) bedrohen und über den BSI IT-Grundschutz G0-Katalog hinausgehen. Nach BSI Standard 200-3 müssen diese in der Risikoanalyse bewertet und mit Maßnahmen aus ISO 27001 Anhang A (z. B. A.8.25 für sichere Entwicklung) kontrolliert werden.

=== Gefährdungskatalog-Ergänzungen ===
KI-spezifische Risiken wie folgt klassifiziert (CIA-Analyse):

* '''Prompt Injections''': Manipulation von Eingaben zu Large Language Models (hoch I/C).
* '''Data Poisoning''': Vergiftung von Trainingsdaten (hoch I, mittel A).
* '''Modelllecks''': Training Data Leakage oder IP-Exfiltration (hoch C).
* '''Unkontrollierte Nutzung von Schatten-KI''': Unkontrollierte Nutzung privater Tools (mittel C/I).
* '''Black-Box-Effekte''': Mangelnde Nachvollziehbarkeit (hoch I/A).

'''Integration in BSI-Module'''
{| class="wikitable"
!Gefährdung
!BSI G0-Modul
!Ergänzungsmaßnahme
|-
|Data Poisoning
|SYS.1.2 Datenintegrität
|Daten-Sanitization, Validierung
|-
|Modelllecks
|NET.4.1 Zugriffssteuerung
|API-Rate-Limiting, Differential Privacy
|-
|Shadow-KI
|ORG.2.1 Sicherheitsrichtlinien
|KI-Nutzungsrichtlinie (ISO A.5.1)
|}

=== ISMS-Maßnahmen und Standards ===
* '''BSI KI-Kriterienkatalog (2025)''': Sicherheitsniveaus (Low/Medium/High) für generative KI, mit Tests auf Jailbreaks und Bias.
* '''ISO 27001 Anhang A''': A.14.2.7 Sichere Entwicklung von KI, A.12.6 Vulnerability-Management für Modelle.
* '''Risikobewertung''': Erweiterte Gefährdungsanalyse nach BSI 200-3, inklusive Supply-Chain-Risiken bei Cloud-KI-Providern.

'''Weiterführende Informationen:'''

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KI/Kriterienkatalog_KI-Modelle_Bundesverwaltung.html BSI KI-Kriterienkatalog 2025.]
* [[Zusätzliche Gefährdungen|Wiki: Zusätzliche Gefährdungen (ergänzt und spezifische KI-Gefährdungen)]]

== Technische Aspekte ==
Technische Umsetzung von KI muss Robustheit, Nachvollziehbarkeit und Datensicherheit gewährleisten, um EU AI Act-Anforderungen (z. B. Art. 15 für Hochrisiko) und ISMS-Ziele zu erfüllen. Der Fokus liegt auf dem gesamten KI-Lebenszyklus.

=== Implementierungsprinzipien ===

* '''Daten-Governance''': Saubere Trainingsdaten (Preprocessing, Anonymisierung), RAG (Retrieval-Augmented Generation) statt reinem Fine-Tuning zur Vermeidung von Halluzinationen.
* '''Modellsicherheit''': Hardening-Techniken wie Adversarial Training, Modellkardinalität (Input/Output-Beschränkungen).
* '''Nachvollziehbarkeit (XAI)''': SHAP für globale Feature-Importance, LIME für lokale Erklärungen einzelner Vorhersagen – essenziell für Art. 22 DSGVO.

=== Lebenszyklus-Management ===
'''KI-System-Phasen und Sicherheitskontrollen'''
{| class="wikitable"
!Phase
!Technische Maßnahmen
!ISMS-Verknüpfung
|-
|Auswahl/Training
|Datenvalidierung, Secure MPC
|A.8.25 Entwicklung
|-
|Deployment
|Sandboxing, Human-in-the-Loop
|A.12.4 Monitoring
|-
|Betrieb
|Continuous Model Monitoring (Drift/Bias)
|A.12.6 Vulnerabilities
|-
|Decommissioning
|Modelllöschung, Audit-Logs
|A.18.1 Compliance
|}

=== Hochrisiko-Anwendungen ===

* '''Sektoren''': HR (Bias-Prüfung), Gesundheitswesen (FDA/DiGA-konform), kritische Infrastruktur (real-time Robustheit).
* '''Technische Standards''': ONNX für Modell-Portabilität, TensorFlow Privacy für Federated Learning.

'''Praktische Umsetzung'''

* '''Tools''': MLflow für Lifecycle-Tracking, Adversarial Robustness Toolbox (ART) für Angriffstests.
* '''Cloud-KI''': AWS SageMaker oder Azure ML mit integrierten Security-Features prüfen (AVV-pflichtig).

'''Weiterführende Informationen:'''

* [https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R1689#art_11 EU AI Act Artikel 11 - Technische Dokumentation]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:32024R1689#anx_IV EU AI Act Anhang IV - Technische Dokumentation]
* [https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/Leitfaden_KI-Systeme_230124.html BSI Secure AI Guidelines.]
* [[KI-Register|Wiki: KI-Register]]

== Governance und Organisation ==
Eine effektive KI-Governance stellt sicher, dass KI-Einsatz mit ISMS-Zielen (ISO 27001, BSI Grundschutz) übereinstimmt und EU AI Act-Anforderungen erfüllt. Sie umfasst organisatorische Strukturen, Prozesse und Verantwortlichkeiten, um Risiken wie Shadow-KI oder Bias zu minimieren. Die Geschäftsleitung trägt gemäß ISO 27001 Abschnitt 5.1 die oberste Verantwortung und muss KI-spezifische Richtlinien (A.5.1) etablieren.

=== KI-Governancestruktur ===

* '''KI-Steuerungsgremium''': Interdisziplinäres Gremium (IT-Sicherheit, Datenschutzbeauftragte, Rechtsabteilung, Fachabteilungen) für Risikobewertungen, Modellfreigaben und Audits. Regelmäßige Meetings (vierteljährlich) zur Überprüfung von KI-Projekten.

* '''Rollen und Verantwortlichkeiten''':<br>
{| class="wikitable"
!Rolle
!Aufgaben
!Rechtsgrundlage
|-
|KI-Provider (extern)
|Technische Dokumentation, Konformitätserklärung
|EU AI Act Art. 13
|-
|KI-Deployer (intern)
|Risikoanalyse, menschliche Aufsicht
|EU AI Act Art. 29
|-
|Datenschutzbeauftragte
|DSFA, Betroffenenrechte
|DSGVO Art. 39
|-
|ISMS-Leitung
|Integration in Risikomanagement
|ISO 27001 A.5.1
|}

* '''KI-Nutzungsrichtlinie''': Verbot privater KI-Tools (Shadow-KI), Pflicht zu genehmigten Modellen, Sanktionen bei Verstößen. Schulungspflicht für Mitarbeitende (KI-Literacy).

=== Prozesse und Workflows ===

* '''Risikobewertungsvorlage''': Vorlage für neue KI-Projekte mit CIA-Analyse, EU AI Act-Risikostufe und DSFA-Trigger. Workflow: Antrag → Gremium → Freigabe → Monitoring.
* '''Audit und Reporting''': Jährliche KI-Inventar (alle Systeme auflisten), Incident-Reporting für Bias-Vorfälle oder Modell-Drift. Integration in ISO 27001 Management Review (Abschnitt 9.3).
* '''Schulungen''': Obligatorische Einstiegsschulung zu KI-Risiken (~2h), vertiefte für Entwickler (XAI, Secure Coding). Nachweis via LMS.

=== Besonderheiten für Behörden ===

* '''Grundrechtsschutz''': Zusätzliche Prüfung auf Verhältnismäßigkeit (GG Art. 1–3), Transparenz gegenüber Bürger:innen. Beliehene Unternehmen (z. B. Zeugnisstellen) fallen unter öffentlich-rechtliche Standards.
* '''Öffentliche Unternehmen''': Anpassung an Verwaltungsrecht (VwVfG § 35), Archivierungspflicht für KI-Entscheidungen.

'''Praktische Umsetzung'''

* '''Checkliste für KI-Projekte''':
*# Risikostufe bestimmen,
*# Provider prüfen,
*# DSFA durchführen,
*# Technische Dokumentation anlegen,
*# Monitoring einrichten.
* '''Vorlage''': KI-Risikobewertungstabelle (Excel) mit Spalten für Gefährdung, Wahrscheinlichkeit, Schaden, Maßnahmen.

'''Verweise'''

* Wiki: ISMS-Organisation
* ISO 27001:2022 Abschnitt 5 (Führung).

== Weiterführende Quellen ==

=== Primärquellen (Gesetze und Verordnungen) ===

* '''EU AI Act''': Volltext – Offizielle Übersetzung, Anhang mit Hochrisiko-Listen.
* '''DSGVO''': Art. 22, 35 – Automatisierte Entscheidungen, DSFA.
* '''BDSG''': § 22 – Automatisierte Entscheidungen im öffentlichen Recht.

=== Behörden und Standardisierungsgremien ===

* '''BSI''':
** KI-Kriterienkatalog 2025 – Testszenarien für generative KI.
** IT-Grundschutz Compendium – G0-Module.
* '''Datenschutzkonferenz (DSK)''': Leitfaden KI und Datenschutz – Praktische Checkliste.
* '''BayLDA''': KI & Datenschutz – Orientierung für Behörden.

=== Branchenverbände und Ratgeber ===

* '''IHK München''': Datenschutz & KI – Praktische Hinweise für KMU.
* '''Bitkom''': KI-Guide für Unternehmen – Best Practices.
* '''BaFin''': Marco für KI im Finanzsektor.

=== Technische Ressourcen ===

* '''XAI-Tools''': SHAP-Dokumentation, LIME – Open Source für Erklärbarkeit.
* '''Secure AI Frameworks''': Adversarial Robustness Toolbox – Tests auf Angriffe.

=== Wiki-interne Verweise ===

* [[EU AI Act]]
* [[KI Cybersicherheit]]
* [[KI Datenschutz]]
* [[KI-Nutzung]]
* [[KI-Register]]
* [[LF-KI-Chatbots]]
* [[RiLi-KI-Einsatz]]
* [[Zusätzliche Gefährdungen]]

'''Hinweis''': Alle Links zum Stand März 2026 prüfen; bei Updates im Wiki protokollieren. Für Implementierungsvorlagen (Checklisten, Excel) ein separates Unterkapitel „Vorlagen" anlegen.
[[Kategorie:Artikel]]
[[Kategorie:KI]]

EU AI Act

2026-03-28T13:27:36Z

Dirk:

[[Datei:Generated-image.png|alternativtext=|rechts|200x200px]]
{{#seo:
|title=EU AI Act: ISMS-Integration, Risiken & Umsetzung
|keywords=EU AI Act, KI-Verordnung, ISMS, ISO 27001, BSI IT-Grundschutz, Hochrisiko-KI, GPAI, Risikomanagement, NIS-2, DSGVO
|description=Leitfaden zum EU AI Act (2024/1689): Risikoklassen, Pflichten für Anbieter/Betreiber, ISMS-Integration nach ISO 27001/BSI-Grundschutz. Fristen, Vorlagen}}
{{SHORTDESC:Das EU-Gesetz zur künstlichen Intelligenz}}''Leitfaden zum EU AI Act (2024/1689): Risikoklassen, Pflichten für Anbieter/Betreiber, ISMS-Integration nach ISO 27001/BSI-Grundschutz. Fristen, Vorlagen''

== Einleitung ==
Der EU AI Act (Verordnung (EU) 2024/1689) stellt das weltweit erste umfassende Regelwerk für den sicheren und menschenrechtskonformen Einsatz von Künstlicher Intelligenz (KI) dar. Er verfolgt einen risikobasierten Ansatz, der KI-Systeme je nach potenzieller Gefährdung mit gestaffelten Pflichten belegt und so Innovationen fördert, während fundamentale Rechte geschützt werden.

=== Historie ===

* '''2021:''' EU-Kommission legt Entwurf vor (21. April).
* '''2022–2023:''' Verhandlungen; EU-Rat nimmt Ausrichtung an (Dez. 2022), Einigung der Verhandlungsführer (Dez. 2023).
* '''2024:''' Vom Rat gebilligt (21. Mai 2024), Veröffentlichung im Amtsblatt (12. Juli), Inkrafttreten (1./2. August).
* '''Status 2026:''' Vollanwendbarkeit größtenteils (August 2026), Hochrisiko-KI bis August 2027.

=== Zweck und Relevanz ===
Der Act schafft rechtliche Klarheit für Unternehmen, Behörden und Entwickler in der EU und darüber hinaus. Er adressiert Risiken wie Diskriminierung durch Bias, Manipulation oder Verlust der menschlichen Kontrolle und verhindert ein regulatorisches Vakuum angesichts der rasanten KI-Diffusion (z.B. generative Modelle wie ChatGPT). Relevanz ergibt sich aus hohen Bußgeldern (bis 7% globalen Umsatzes) und extraterritorialer Geltung: Jede KI, die in der EU vermarktet oder eingesetzt wird, fällt darunter.

=== Regelungsschwerpunkte ===
Der Act klassifiziert KI-Systeme in vier Risikostufen mit gestaffelten Pflichten:

* '''Unannehmbares Risiko (Art. 5):''' Verboten seit Feb. 2025, z.B. Echtzeit-Biometrie in öffentlichen Räumen (Ausnahmen: Strafverfolgung), Emotionserkennung am Arbeitsplatz, soziale Scoring-Systeme.
* '''Hohes Risiko (Art. 6, Anhang III):''' Strenge Anforderungen (z.B. Bildgebung in Medizin, kritische Infrastruktur, Bildung); Konformitätsbewertung, Risikomanagement, Datenqualität, Transparenz, menschliche Aufsicht.
* '''General-Purpose AI (GPAI, Kap. V):''' Seit Aug. 2025: Technische Dokumentation, Trainingsdaten-Summary, Risikominimierung (systemisches Risiko: Tests, Meldungen).
* '''Geringes Risiko:''' Transparenzpflichten (z.B. Deepfakes kennzeichnen).

=== Risikobasierter Ansatz ===
Im Gegensatz zu technologie-neutralen Regelwerken wie der DSGVO wendet der AI Act eine proportionale Regulierung an: Von Verboten bei unannehmbarem Risiko (Art. 5) über strenge Anforderungen bei hohem Risiko (Art. 6 ff.) bis hin zu Transparenzpflichten bei geringem Risiko. Dies ermöglicht Flexibilität – z. B. Open-Source-GPAI mit Ausnahmen – und integriert sich nahtlos in bestehende Managementansätze.

=== Geltungsbereich ===

* '''KI-Systeme:''' Software, die autonom Inhalte erzeugt, Vorhersagen trifft oder Entscheidungen fällt (Art. 3).
* '''Geografisch:''' EU-weit sowie extraterritorial bei EU-Betroffenen oder -Marktzugang.
* '''Akteure:''' Anbieter, Betreiber (Deployer), Importeure, Nutzer; Ausnahmen für Militär/Medizin (bereits anderweitig reguliert).

=== Bezug zu ISMS ===
Der AI Act ergänzt Informationssicherheits-Managementsysteme (ISMS) nach [[ISO 27001]] oder [[IT-Grundschutz|BSI Grundschutz]]. KI-Risiken (z.B. Modellklau, Datenvergiftung) fließen in Risikoanalysen ein, Controls wie A.5.7 (Bedrohungserkennung) decken Cybersicherheit ab. Synergien zu NIS-2 (kritische Infrastruktur) und DSGVO (Datenverarbeitung) erleichtern die Umsetzung; eine [[RiLi-KI-Einsatz|KI-Richtlinie]] passt in den [[PDCA-Zyklus]].

* Zweck und Relevanz des EU AI Act (Verordnung (EU) 2024/1689)
* Risikobasierter Ansatz: Von Technologie-neutral zu KI-spezifisch
* Geltungsbereich: KI-Systeme in der EU, extraterritoriale Wirkung
* Bezug zu ISMS (ISO 27001, BSI IT-Grundschutz, NIS-2)

== Definitionen und Begriffe ==
Dieses Kapitel schafft ein einheitliches Begriffsverständnis, das für die rechtssichere Anwendung des EU AI Act und seine Einbettung in ein ISMS unerlässlich ist.

=== KI-System ===
Der EU AI Act definiert ein KI-System als ein durch Menschen entwickeltes System, das mit einem gewissen Grad an Autonomie auf Basis von Machine-Learning-, logik- oder wissensbasierten Methoden arbeitet und dazu bestimmt ist, aus Eingabedaten einen Output wie Vorhersagen, Entscheidungen, Empfehlungen oder Inhalte zu erzeugen, die Einfluss auf physische oder virtuelle Umgebungen haben.

Wesentliche Punkte dabei:

* Es geht ausdrücklich um '''Software'''; reine Hardware fällt nur mittelbar über das integrierte KI-System darunter.
* „Autonomie“ bedeutet nicht völlige Unabhängigkeit, sondern dass das System ohne jede einzelne Entscheidung eines Menschen operiert.
* Generative KI (z.B. Text-, Bild-, Code-Modelle) ist explizit eingeschlossen.

Für ein ISMS ist entscheidend: KI-Systeme sind als eigene '''Informations‑ und Geschäftsassets''' zu erfassen (Modell, Trainingsdaten, Runtime-Umgebung, Schnittstellen).

=== General-Purpose AI (GPAI) ===
GPAI-Modelle (general purpose AI) sind KI-Modelle, die für sehr unterschiedliche Zwecke eingesetzt werden können und nicht von vornherein auf ein enges Einsatzfeld begrenzt sind (z.B. große Sprachmodelle, multimodale Foundation Models).

Wesentliche Merkmale:

* Sie können in zahlreichen Branchen und Anwendungsfällen wiederverwendet werden (z.B. Kundenservice, Entwicklung, Office-Automation).
* Sie werden oft als '''Basis-Komponente''' in anderen KI-Systemen genutzt („downstream use“).
* Der EU AI Act sieht dafür eigene Pflichten vor (u.a. Dokumentation, Transparenz zu Trainingsdaten, Unterstützung nachgelagerter Anwendende).

Im ISMS-Kontext müssen GPAI-Modelle getrennt von spezifischen Fachanwendungen betrachtet werden: Ein Modell kann unterschiedlichen Risikoklassen unterliegen, je nachdem, wofür es eingesetzt wird.

=== Rollen: Anbieter, Betreiber und weitere Akteure ===
Der EU AI Act unterscheidet mehrere Rollen, die für Governance, Haftung und ISMS-Abgrenzung wichtig sind:

* '''Anbieter (Provider):''' Die natürliche oder juristische Person, die ein KI-System erstmalig unter eigenem Namen oder Marke in Verkehr bringt oder in Betrieb nimmt. Für diese Rolle gelten u.a. die Pflichten zur Konformitätsbewertung, technischen Dokumentation, CE‑Kennzeichnung und Überwachung des Systems im Feld.
* '''Betreiber (Deployer/User):''' Die Stelle, die ein KI-System in eigener Verantwortung einsetzt. Im Unternehmenskontext ist das typischerweise die Organisation, die ein KI-Produkt im Fachbereich produktiv nutzt (z.B. ein Krankenhaus, das ein KI-Diagnosesystem betreibt).
* '''Importeur / Händler / Bevollmächtigte:''' Parteien, die KI-Systeme aus Drittstaaten in die EU bringen oder unter fremder Marke vertreiben, übernehmen bestimmte Teile der Anbieterpflichten.

Für das ISMS ist zentral: Die eigene Rolle muss pro KI-System klar bestimmt und dokumentiert werden, da sich daraus unterschiedliche Pflichten, Risiken und Kontrollanforderungen ableiten.

=== Risikostufen nach dem EU AI Act ===
Der AI Act arbeitet mit mehreren Risikoklassen, die das Schutzniveau und den Aufwand der Compliance unmittelbar steuern:

* '''Unannehmbares Risiko:''' KI-Praktiken, die grundsätzlich verboten sind, weil sie Grundrechte oder menschliche Würde in nicht vertretbarer Weise verletzen (z.B. bestimmte Formen von Sozialscoring oder manipulative Systeme, die gezielt Schwächen besonders schutzbedürftiger Gruppen ausnutzen).
* '''Hohes Risiko:''' KI-Systeme, die in besonders sensiblen Bereichen eingesetzt werden (z.B. kritische Infrastruktur, Medizin, Bildung, Beschäftigung, Strafverfolgung) oder über die im Ergebnis Menschen stark beeinflussende Entscheidungen getroffen werden. Hier gelten umfangreiche Anforderungen an Risikomanagement, Datenqualität, Transparenz, Dokumentation, Sicherheit und menschliche Aufsicht.
* '''Sonstige/geringere Risiken:''' KI-Anwendungen, bei denen primär Transparenzpflichten greifen (z.B. Kennzeichnung von Deepfakes, Hinweis auf Nutzung eines KI Chatbots).

Diese Risikostufen sind direkt in die '''Risikomethodik''' eines ISMS zu integrieren: Die Risikobeurteilung für KI muss sowohl die technischen als auch grundrechtlichen und regulatorischen Aspekte berücksichtigen.

=== Abgrenzung zu anderen Rechtsrahmen ===
Im ISMS-Umfeld ist es wichtig, die Schnittstellen zu anderen Regelwerken sauber zu trennen und gleichzeitig angemessen zu integrieren:

* '''DSGVO:''' Regelt die Verarbeitung personenbezogener Daten, unabhängig davon, ob KI genutzt wird. KI-spezifische Risiken (Profiling, automatisierte Entscheidungen) sind im Zusammenspiel mit DSGVO-Anforderungen (z. B. Transparenz, Betroffenenrechte, Data Protection Impact Assessment) zu betrachten.
* '''NIS-2 / KRITIS-Regime:''' Fokussiert auf Verfügbarkeit, Vertraulichkeit und Integrität von Diensten in kritischen Sektoren. Der AI Act ergänzt dies um KI-spezifische Anforderungen, insbesondere wenn kritische Funktionen KI-gestützt sind.
* '''Produktsicherheits- und Medizinprodukte-Recht:''' In manchen Bereichen (z.B. Medizin) gelten zusätzliche sektorale Anforderungen; der EU AI Act wirkt hier komplementär und darf nicht isoliert betrachtet werden.

Für ein ganzheitliches ISMS bedeutet das: KI-Compliance ist kein separates „KI-Silo“, sondern eine Querschnittsaufgabe, die an Datenschutz, Informationssicherheit und ggf. Sektorrecht gekoppelt ist.

== Risikobasierte Klassifizierung (Art. 6–13) ==
Dieses Kapitel erläutert, wie die risikobasierte Systematik des EU AI Act funktioniert und welche inhaltlichen Schwerpunkte sich daraus für Governance und ISMS ergeben.

=== Unannehmbares Risiko (verbotene Praktiken) ===
Der EU AI Act verbietet bestimmte KI-Anwendungen vollständig, weil sie mit den Werten der EU nicht vereinbar sind. Typische Beispiele (aus Vereinfachungsgründen abstrakt formuliert):

* Systeme, die '''Verhalten in manipulativer Weise beeinflussen''', um Menschen zu Entscheidungen zu drängen, die sie sonst nicht treffen würden, insbesondere, wenn schutzbedürftige Gruppen betroffen sind.
* Bestimmte Formen von '''sozialem Scoring''', bei denen Menschen systematisch anhand ihres Verhaltens oder persönlicher Merkmale bewertet werden und diese Bewertungen weitreichende negative Konsequenzen haben.
* Bestimmte Einsatzformen '''biometrischer Echtzeit-Überwachung im öffentlichen Raum''', mit eng begrenzten Ausnahmen (z.B. schwere Straftaten, Terrorabwehr) und strengen Voraussetzungen.

Für das ISMS heißt das:

* Solche Szenarien müssen bereits in der '''Konzeptionsphase''' ausgeschlossen werden.
* In Risikoanalysen sind sie als '''nicht zulässige Risikobehandlung''' zu dokumentieren.
* Architekturen und Prozesse sollten eine technische und organisatorische „Verbots-Compliance“ sicherstellen (z.B. durch Design-Reviews, Ethik- und Rechtsfreigaben).

=== Hohes Risiko (High-Risk-KI) ===
Hochrisiko-KI steht im Mittelpunkt des EU AI Act. Ein KI-System gilt als hochriskant, wenn es:

* in bestimmten sensiblen Sektoren eingesetzt wird (z.B. Medizin, kritische Infrastruktur, Bildung, Justiz, Migration), oder
* Funktionen erfüllt, die erhebliche Auswirkungen auf Rechte, Gesundheit, Sicherheit oder Lebensführung von Personen haben.

Für diese Systeme gelten unter anderem:

* Verpflichtendes '''Risikomanagement''' über den gesamten Lebenszyklus (Identifikation, Bewertung, Behandlung und Monitoring von Risiken).
* Anforderungen an '''Datenqualität''' und -repräsentativität, um systematische Diskriminierungen ([[Datenbias|Bias]]) zu vermeiden.
* Pflichten zur '''Transparenz und Nachvollziehbarkeit''', inklusive technischer Dokumentation, Logging und Aufzeichnungsanforderungen.
* Sicherstellung '''menschlicher Aufsicht''': Menschen müssen in der Lage sein, Entscheidungen nachzuvollziehen, zu hinterfragen und ggf. zu übersteuern.
* Anforderungen an '''Robustheit, Cybersicherheit und Genauigkeit''' des Systems.

Im ISMS sind Hochrisiko-KI-Systeme regelmäßig:

* als '''Assets mit hohem Schutzbedarf''' zu klassifizieren,
* Gegenstand '''vertiefter Risikoanalysen''' (inkl. Grundrechte-Aspekten),
* mit '''strengen''' technischen und organisatorischen '''Maßnahmen''' (Zugriffsmanagement, Monitoring, Incident-Handling) zu hinterlegen.

=== General-Purpose AI (GPAI) und systemische Risiken ===
GPAI-Modelle können selbst oder in ihrer Integration in Hochrisiko-Kontexte zu '''systemischen Risiken''' führen, etwa wenn sie in kritischer Infrastruktur, öffentlichen Verwaltungsprozessen oder weitverbreiteten Plattformen eingesetzt werden.

Für GPAI und insbesondere „systemische GPAI“ (Modelle mit besonders weitreichendem Einfluss) gelten zusätzliche Anforderungen, wie z.B.:

* Erstellung und Bereitstellung umfassender '''technischer Dokumentation''' für nachgelagerte Nutzende (Entwickelnde und betreibende Organisationen).
* Offenlegung einer '''allgemeinen Beschreibung der Trainingsdatenquellen''', um Transparenz über Herkunft, Typ und mögliche Risiken der Daten zu schaffen.
* Durchführung von '''Risikoanalysen und -tests''', bevor Modelle in großem Maßstab bereitgestellt werden.
* Verpflichtung, bekannte '''schwerwiegende Vorfälle''' zu überwachen und zu melden.

Für ein ISMS ist entscheidend:

* Werden GPAI-Modelle als Basis für eigene Produkte genutzt, muss die Organisation die vom Modell-Anbieter gelieferten Informationen systematisch in ihre eigene '''Risikobewertung, Dokumentation und Sicherheitsmaßnahmen''' integrieren.
* Es reicht nicht, auf den Anbieter zu verweisen – der eigene Einsatzkontext kann aus einem vermeintlich „allgemeinen“ Modell eine Hochrisiko-Anwendung machen.

=== Geringeres Risiko und Transparenzpflichten ===
Nicht jede KI-Anwendung fällt in die Kategorie „hohes Risiko“. Für zahlreiche KI-Systeme sind vor allem '''Transparenzanforderungen''' relevant, etwa:

* '''Kennzeichnung''', dass Nutzende mit einem KI-System (z.B. Chatbot) interagieren und nicht mit einer natürlichen Person, sofern dies für das Verständnis erforderlich ist.
* '''Kennzeichnung''' von synthetischen oder manipulierten Inhalten (Deepfakes), damit Empfängerinnen und Empfänger erkennen können, dass Inhalte nicht authentisch sind.
* Gegebenenfalls '''Hinweise''' auf automatisierte Entscheidungsunterstützung, damit die Rolle der KI im Entscheidungsprozess nachvollziehbar ist.

Im ISMS sollten solche Systeme typischerweise:

* in der '''Asset-Liste''' mit moderatem Schutzbedarf geführt werden,
* mit klar definierten '''Informationspflichten''' und UX-Vorgaben verbunden sein,
* in Awareness- und Schulungskonzepten berücksichtigt werden (um z.B. Missverständnisse und Fehlinterpretationen zu vermeiden).

=== Auswirkungen auf das ISMS-Risikomanagement ===
Die risikobasierte Klassifizierung des EU AI Act sollte im ISMS konkret abgebildet werden, u.a. durch:

* Anpassung der '''Risikomethodik''': Einbezug der AI-Risikokategorien (unannehmbar, hoch, sonstige) in die bestehenden Bewertungsraster für Eintrittswahrscheinlichkeit und Schadensausmaß.
* Ergänzung des '''Risikoregisters''' um KI-spezifische Risiken wie:
** Verzerrte oder diskriminierende Outputs,
** Datenvergiftung und Modellmanipulation,
** unerwünschte Modelllecks (Training Data Leakage, IP-Verletzungen),
** Verlust menschlicher Kontrolle und mangelnde Nachvollziehbarkeit.
* Verzahnung mit '''Compliance- und Datenschutz-Risiken''' (insbesondere DSGVO, NIS-2, branchenspezifische Vorgaben).
* Festlegung von '''Akzeptanzkriterien''': Wann ist ein KI-Risiko tolerierbar, wann muss das Design geändert oder der Einsatz untersagt werden?

Damit wird der EU AI Act nicht nur als rechtliche „Schicht“ aufgesetzt, sondern integraler Bestandteil des bestehenden Managementsystems für Informationssicherheit und Compliance.

== Rechte und Pflichten der Akteure ==
Der EU AI Act definiert klare Rollen und damit verbundene Pflichten, um Verantwortlichkeiten zuzuweisen und Haftungen abzugrenzen. Diese müssen im ISMS als organisatorische Rollen (z. B. RACI-Matrix) abgebildet werden.alexanderthamm+1

=== Anbieter ===
Anbieter sind primär verantwortlich für die Entwicklung und Markteinführung von KI-Systemen. Pflichten umfassen:

* Erstellung einer umfassenden '''technischen Dokumentation''' (Art. 11), die Design, Trainingsdaten, Tests und Risiken beschreibt; Haltbarkeit: 10 Jahre nach Markteinführung.
* Durchführung der '''Konformitätsbewertung''' (Art. 19, 43): Intern oder durch benannte Stelle, gefolgt von EU-Konformitätserklärung und CE-Kennzeichnung.
* '''Nachmarktüberwachung''' (Post-Market-Monitoring, PMM - Art. 29): Kontinuierliches Monitoring, Incident-Reporting innerhalb 15 Tagen (schwerwiegend: 72 Stunden an AI Office).
* Für GPAI: Offenlegung von Trainingsdaten-Zusammenfassungen und Unterstützung für Betreibende (Art. 52–55).

Im ISMS: Anbieter-Risiken in Lieferantenmanagement (ISO 27001 A.15) integrieren; Verträge müssen Dokumentationspflichten und Audit-Rechte regeln.

=== Betreiber ===
Betreiber setzen KI-Systeme ein und tragen operative Verantwortung:

* '''Risikobewertung vor Einsatz''' (Art. 29): Speziell bei Hochrisiko-KI; berücksichtigt Einsatzkontext, Grundrechte und Cybersicherheit.
* '''Menschliche Aufsicht''' sicherstellen (Art. 14): Schulungen für Überwachungspersonal, Prozesse zur Intervention.
* '''Transparenz gegenüber Betroffenen''' (Art. 50): Informieren über KI-Nutzung, wo relevant (z.B. automatisierte Entscheidungen).
* Incident-Meldung und Logging; bei Grundrechtsverletzungen: Impact-Assessment.

Im ISMS: Betreiber-Pflichten in Prozessen wie Asset-Management (A.8) und Incident-Management (A.16) verankern; KPIs für Einsatzüberwachung definieren.

=== Weitere Parteien ===

* '''Nachgelagerte Anbieter''': Übernehmen Teilanbieterpflichten bei Modifikationen (Art. 28).
* '''Importeure/Händler''': Prüfen Konformität Drittländer-Produkte; Haftung bei Markteinführung (Art. 22–25).
* '''Bevollmächtigte Vertreter''': Für Nicht-EU-Anbieter; vergleichbar mit DSGVO (Art. 26).

Im ISMS: Alle Rollen in der Lieferkette risikobasiert bewerten; Verträge klären Haftungsverteilung.

=== Sanktionen ===
Bußgelder (Art. 99): Bis 35 Mio. € / 7% Umsatz bei Verboten; 15 Mio. € / 3% bei anderen Pflichtverletzungen. Durchsetzung durch nationale Marktüberwachungsbehörden und EU AI Office. Im ISMS: In Risikobewertung als regulatorisches Risiko einplanen (Cl. 6.1.2 ISO 27001).

== Konkrete Regelungen nach Risikostufe ==
Hier werden die operativen Anforderungen detailliert, mit Fokus auf Umsetzung in ISMS-Prozessen.

=== Verbotene KI-Anwendungen (Art. 5) ===
Vollständig verboten seit 2. Februar 2025:

* Manipulative Subliminaltechniken, die vulnerable Gruppen schädigen.
* Sozialscoring durch öffentliche Behörden.
* Echtzeit-Biometrie im öffentlichen Raum (Ausnahmen: schwere Kriminalität, mit gerichtlicher Genehmigung >24 Std.).
* Emotionserkennung am Arbeitsplatz/Bildungseinrichtungen.
* Biometrische Kategorisierung sensibler Merkmale (z.B. politische/rassische Orientierung).

ISMS-Umsetzung: Design-Phase-Checks (Security by Design, A.14 ISO 27001); Incident-Response auf unbewusste Nutzung.

=== Hochrisiko-Pflichten (Art. 6–15, Anhang III) ===
Pflichten für gelistete Sektoren (z.B. Medizinprodukte, Wasser-/Energieversorgung, Kreditscoring, Risikobewertung Straftäter):

* '''Risikomanagement (Art. 9):''' Lebenszyklus-Risiken identifizieren, bewerten, mindern; kontinuierlich aktualisieren.
* '''Datenqualität (Art. 10):''' Relevanz, Repräsentativität, Genauigkeit; Bias-Tests.
* '''Technische Dokumentation (Art. 11):''' Detaillierte Aufzeichnungen für Audits.
* '''Transparenz (Art. 13):''' Nachvollziehbarkeit für Betroffene.
* '''Menschliche Aufsicht (Art. 14):''' Vermeidung von Risiken durch Automatisierung.
* '''Robustheit/Cybersicherheit (Art. 15):''' Resilienz gegen Angriffe, Fallback-Mechanismen.

ISMS-Mapping: Direkt in Risikobehandlung (Cl. 8), Vulnerability-Management (A.12.6), Logging (A.12.4).

=== GPAI-spezifisch (Kap. V) ===
Seit 2. August 2025:

* Technische Dokumentation und Trainingsdaten-Summary (Art. 53).
* Risikobewertung für systemische Risiken (Art. 55): Bei Modellen >10^25 FLOPs (z. B. GPT-4-Nachfolger).
* Copyright-Hinweise und Incident-Reporting.

ISMS: Als Cloud-/API-Dienste behandeln (A.14.2); Modell-Updates in Change-Management.

=== Dokumentations- und Nachweispflichten ===

* Alle Dokumente 10 Jahre aufbewahren; Vorlagen im Amtsblatt.
* Audits durch benannte Stellen oder interne Checks.
* ISMS: In Records-Management (A.18.1) und Audit-Prozessen (Cl. 9.2) integrieren.

== Governance und Aufsicht (Kap. VII) ==
Das Governance-System des EU AI Act gewährleistet einheitliche Umsetzung und Durchsetzung EU-weit. Es kombiniert zentrale EU-Institutionen mit nationaler Flexibilität und bindet sich eng an ISMS-Audit- und Überwachungsprozesse (Cl. 9 ISO 27001).

=== EU AI Office ===

* '''Rolle:''' Zentrale EU-Behörde (neben EBA, ESMA etc.) für Koordination, Richtlinienentwicklung und Überwachung GPAI/systemischer Risiken (Art. 64).
* '''Zuständigkeiten:''' Entwicklung von Codes of Practice, Harmonisierungsstandards (CEN/CENELEC), Marktanalyse, Sanktionsaufsicht bei grenzüberschreitenden Fällen.
* '''ISMS-Bezug:''' Als externe Stakeholder in Lieferanten- und Compliance-Monitoring (A.15/A.18) einbinden; AI Office-Richtlinien in interne Standards übernehmen.

=== Nationale Behörden und KI-Boards ===

* '''Nationale Marktüberwachungsbehörden:''' Durchsetzen lokaler Pflichten, Untersuchungen, Bußgelder; Kooperation über EU-Ausschuss (Art. 66).
* '''Nationale KI-Boards:''' Beratung, Risikobewertungshilfe für Unternehmen; koordinieren Hochrisiko-Konformität.
* '''ISMS-Integration:''' Nationale Ansprechpartner in Incident-Response (A.16) und Audit-Planung definieren; lokale Meldepflichten (72 Std.) in Prozesse einfließen lassen.

=== Harmonisierte Standards und Sandboxes ===

* '''Standards:''' Freiwillige, aber compliance-vermutende Normen (z.B. EN ISO/IEC 42001); beschleunigte Entwicklung durch EU AI Office.
* '''Regulatorische Sandboxes:''' Testumgebungen für innovative KI (Art. 57); nationale Umsetzung bis 2026.
* '''ISMS-Nutzen:''' Standards in Control-Sets (Anhang A ISO 27001) referenzieren; Sandboxes für Proof-of-Concepts vor Produktiveinsatz nutzen.

=== Meldepflichten ===

* '''Incidents:''' Schwere Vorfälle innerhalb 72 Std. an nationale Behörde/AI Office (Art. 73); GPAI: 15 Tage (Art. 55).
* '''Retraining/Update-Meldungen:''' Bei wesentlichen Modelländerungen.
* '''ISMS:''' Erweitere Incident-Management (A.16.1) um AI-spezifische Kategorien und Fristen; automatisiertes Reporting-Tool einplanen.

== Integration in ein ISMS (ISO 27001/BSI-Grundschutz) ==
Der EU AI Act lässt sich nahtlos in bestehende ISMS nach ISO 27001:2022 oder BSI IT-Grundschutz integrieren, indem KI-Risiken risikobasiert behandelt werden (PDCA-Zyklus).

=== Plan ===

* '''Asset-Inventarisierung:''' Alle KI-Systeme (inkl. GPAI-APIs) als Assets erfassen (A.8.1–A.8.4); Risikostufe per EU AI Act-Kriterien klassifizieren.
* '''Risikobewertung:''' KI-Risiken (Bias, Adversarial Attacks, Halluzinationen) in Matrix eintragen (Cl. 6/8); Grundrechte-Impact ergänzen.
* '''ISMS-Erweiterung:''' Statement of Applicability um AI Act-Controls anpassen.

=== Do ===

* '''KI-Richtlinie:''' Neue Policy mit Risikostufen, Rollenverteilung (Anbieter/Betreiber), Verboten und Transparenzpflichten erstellen.
* '''Controls:'''
** A.5.7 Bedrohungserkennung auf KI-spezifische Angriffe (Prompt Injection) erweitern.
** A.14 Lieferantenmanagement: AI-Anbieter-Verträge mit Dokumentationsrechten und SLAs.
** A.18.1 Compliance: Konformitätserklärungen und Audits dokumentieren.
* '''Technische Maßnahmen:''' Model Governance (Versionierung, Red-Teaming), Secure-by-Design.

=== Check ===

* '''Interne Audits:''' Regelmäßige Reviews von KI-Risiken und Controls (Cl. 9.2); KPIs: Incident-Rate, Konformitätsrate, Bias-Tests.
* '''Management Review:''' AI Act-Änderungen besprechen (Cl. 9.3).
* '''Externe Audits:''' Vorbereitung auf Zertifizierer (hohe Risiken); ISO 42001 als Ergänzung.

=== Act ===

* '''Schulungen:''' KI-Literacy für alle Mitarbeitenden; spezifisch für Betreiber (menschliche Aufsicht).
* '''Kontinuierliche Verbesserung:''' Lessons Learned aus Incidents; Lieferantenfeedback-Loops.
* '''Mapping-Tabelle:'''

{| class="wikitable"
!EU AI Act
!ISO 27001 Control
!BSI IT-Grundschutz
|-
|Risikomanagement (Art. 9)
|Cl. 8, A.12.6
|CON.4 Risikomanagement
|-
|Cybersicherheit (Art. 15)
|A.12.4–A.12.7
|SYS.4 Netzwerksicherheit
|-
|Incident-Meldung
|A.16.1
|INC.2 Incident Response
|-
|Transparenz (Art. 13)
|A.18.1
|ORP.3 Organisation
|}
Diese Integration minimiert Redundanzen und stärkt die Zertifizierbarkeit; starte mit Gap-Analyse basierend auf AI Act-Checklisten (BSI-Standard 200-3).

== Praktische Umsetzungsempfehlungen ==
Dieses Kapitel liefert konkrete, umsetzbare Schritte für Unternehmen mit bestehendem ISMS, um den EU AI Act bis zur Vollanwendbarkeit 2026/27 einzubinden.

=== Gap-Analyse und Roadmap (2026-Fokus) ===

* '''Schritt 1:''' Bestehendes KI-Inventar erstellen (alle Systeme, GPAI-Nutzung, Cloud-APIs); Risikostufen nach Art. 6–13 prüfen.
* '''Schritt 2:''' Gegen EU AI Act-Checklist (EU-Kommission, BSI) abgleichen; Lücken in Risikomanagement, Dokumentation, Controls identifizieren.
* '''Roadmap:''' Q1/2026: Policy/Schulung; Q2: Hochrisiko-Konformität; Q3: Audits; Q4: Betriebsfähigkeit. Fristen beachten (GPAI ab Aug. 2025).

=== Vorlagen und Dokumentation ===

* '''Risikomatrix:''' Erweitere ISMS-Matrix um AI-spezifische Achsen (Bias-Wahrscheinlichkeit/Grundrechts-Schaden).
* '''Konformitätserklärung:''' Standardvorlage (Art. 19, 43) mit technischer Dokumentation (10-Jahres-Archiv).
* '''Incident-Reporting:''' Vorlage für 72/15-Std.-Meldungen (AI Office/nationale Behörde).

=== Tools und Unterstützung ===

* '''BSI-Trassen:''' IT-Grundschutz++ (ab 2026) für zukünftige KI-Module (CON.4, SYS.4).
* '''ISO 42001-Zertifizierung:''' Ergänzung zu ISO 27001 für KI-Management-Systeme.
* '''Software:''' Tools für Bias-Tests (Fairlearn), Modell-Monitoring (WhyLabs), automatisierte Compliance-Checks.

=== Häufige Fallstricke ===

* '''Open Source-GPAI:''' Keine Anbieterpflichten, aber Betreiber-Risiken bei downstream Hochrisiko-Einsatz.
* '''Cloud-Training:''' Extraterritoriale Geltung; US-Provider brauchen bevollmächtigten Vertreter.
* '''Legacy-Systeme:''' Retrospective Risikobewertung für bestehende KI.

=== Übergangsfristen und Priorisierung ===
{| class="wikitable"
!Pflicht
!Frist
!Priorität
|-
|Verbotene Praktiken
|Feb. 2025
|Sofort
|-
|GPAI-Dokumentation
|Aug. 2025
|Hoch
|-
|Hochrisiko-CE
|Aug. 2026/27
|Mittel
|}

== Ausblick und Synergien ==

=== EU AI Act und NIS-2/DSGVO-Integration ===

* '''NIS-2:''' KI in kritischen Sektoren (CII) verstärkt Cybersicherheitspflichten (Art. 21 NIS-2 + Art. 15 AI Act).
* '''DSGVO:''' Automatisierte Entscheidungen (Art. 22) + DPIA für Hochrisiko-KI; einheitliches Risikoregister nutzen.

=== Globale Vergleiche ===

* '''USA:''' Executive Order (2023) risikobasiert, aber freiwillig; State Laws (z.B. Colorado AI Act).
* '''China:''' PIPL + Algorithmus-Registrierung; staatliche Kontrolle vs. EU-Rechtsstaatlichkeit.
* '''Vereinheitlichung:''' EU AI Act als globaler Standard (ähnlich GDPR-Effekt).

=== Zukünftige Entwicklungen ===

* '''Delegierte Rechtsakte:''' AI Office veröffentlicht Codes of Practice (2026), Sektorregulierungen.
* '''Technische Standards:''' CEN/CENELEC-Normen für Hochrisiko-Tests (2026/27).
* '''ISMS-Trends:''' KI-gestützte ISMS (automatisierte Risikoanalysen) unterliegen selbst AI Act-Pflichten.

Die Integration schafft Wettbewerbsvorteile durch Vertrauen und Compliance-Vorsprung.

== Anhang ==

* [https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32024R1689 '''EUR-Lex''' - Verordnung (EU) 2024/1689 (Amtsblatt L, 2024/1689, 12.7.2024)]
* [https://digital-strategy.ec.europa.eu/de/policies/regulatory-framework-ai '''Hauptseite AI Act''': Digital Strategy - AI Act – Enthält Erklärungen, Zeitpläne und Ressourcen.]
* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Kuenstliche-Intelligenz/kuenstliche-intelligenz_node.html '''BSI AI Act-Seite''': BSI - Künstliche Intelligenz (KI) – Leitfäden zu Risikoklassifizierung und Compliance.]

[[Kategorie:Artikel]]
[[Kategorie:KI]]

Zusätzliche Gefährdungen

2026-03-28T13:27:07Z

Dirk:

{{#seo:
|title=Beispiele für zusätzliche Gefährdungen gem. BSI Standard 200-3
|description=Kurzartikel mit Beispielen für zusätzliche Gefährdungen für eine Risikoanalyse nach BSI Standard 200-3.
}}{{SHORTDESC:Beispiele für zusätzliche/spezifische Gefährdungen gem. BSI Standard 200-3}}
[[Datei:Caution-152926.png|alternativtext=Gefahr|rechts|130x130px]]
Zusätzliche oder spezifische Gefährdungen im BSI Standard 200-3 sind Risiken, die über die elementaren Gefährdungen hinausgehen und besondere Szenarien betreffen.

Die hier aufgelisteten Beispiele für zusätzliche Gefährdungen berücksichtigen aktuelle Entwicklungen und Herausforderungen im Bereich der Informationssicherheit und des Datenschutzes in modernen Arbeitsumgebungen.

Bei Bedarf können relevante zusätzliche Gefährdungen in den eigenen Gefährdungskatalog aufgenommen werden.

=== Nutzung von Homeoffice [CIA] ===
'''Beschreibung:''' Homeoffice ermöglicht Flexibilität und verbessert die Work-Life-Balance der Mitarbeitenden, was zu höherer Zufriedenheit und Produktivität führen kann. Darüber hinaus ist es in Krisensituationen wie Pandemien vorteilhaft, um den Geschäftsbetrieb aufrechtzuerhalten und die Gesundheit der Mitarbeitenden zu schützen. Es gibt jedoch auch mögliche Nachteile, die nicht außer Acht gelassen werden dürfen.

Die Nutzung von Homeoffice-Arbeitsplätzen kann auch zu weniger sozialer Kontrolle, Isolation und psychischem Stress führen. Dies birgt verschiedene Risiken, wie z.B. den unerkannten Konsum von Alkohol oder Drogen während der Arbeitszeit, was die Qualität und Sicherheit der Arbeit beeinträchtigen kann. Darüber hinaus besteht die Gefahr, dass Beschäftigte ohne Absprache aus dem Ausland arbeiten, was rechtliche und sicherheitstechnische Herausforderungen mit sich bringt.

'''Beispiele:'''

* Vertrauliche Unterlagen liegen im Homeoffice offen und können von Besuchern eingesehen werden.
* Eine Mitarbeitende arbeitet unerlaubt aus einem Land mit hohem Cyberrisiko, wodurch sensible Unternehmensdaten gefährdet werden.
* Ein Mitarbeitender arbeitet unter Einfluss von Alkohol, was zu Fehlern in der Datenverarbeitung führt und sicherheitskritische Systeme gefährdet.
* Eine Mitarbeitende überarbeitet sich im Homeoffice durch die Dopppelbelastung und fehlende Trennnung von Familie und Arbeit und macht aufgrund von Erschöpfung sicherheitskritische Fehler bei der Bedienung von IT-Systemen.
* Ein Mitarbeitender leidet unter sozialer Isolation und depressiven Verstimmungen, was seine Konzentration und Entscheidungsfähigkeit beeinträchtigt.

=== Fehlende digitale Kompetenz [CIA] ===
'''Beschreibung:''' Die zunehmende Digitalisierung erfordert von den Mitarbeitenden spezifische digitale Kompetenzen. Fehlende Kenntnisse im Umgang mit neuen Technologien und digitalen Tools können zu ineffizienten Arbeitsabläufen, Fehlbedienungen und Sicherheitslücken führen.

'''Beispiele:'''

* Ein Mitarbeitender öffnet versehentlich Phishing-E-Mails, weil ihm das Wissen über solche Bedrohungen fehlt.
* Eine Mitarbeitende speichert vertrauliche Dokumente unsicher auf einer Cloud-Plattform, die nicht den Organisationsrichtlinien entspricht.

=== Vertraulichkeitsverlust durch smarte Geräte [C] ===
'''Beschreibung:''' Smarte Geräte, wie Sprachassistenten, intelligente Lautsprecher, Wearables und IoT-Geräte, bieten zahlreiche Vorteile. Sie erhöhen den Komfort und die Effizienz im Alltag und im Beruf, indem sie Routineaufgaben automatisieren, Energie sparen und Echtzeitinformationen liefern. Darüber hinaus ermöglichen sie eine nahtlose Integration verschiedener Dienste und verbessern die Konnektivität und Kommunikation.

Smarte Geräte können aber auch ungewollt Informationen sammeln und übertragen, was zu einem Verlust der Vertraulichkeit führen kann. Diese Geräte sind oft nicht ausreichend gesichert und können leicht Ziel von Angriffen werden.

* Smarte Geräte sammeln und übertragen kontinuierlich Daten. Ohne ausreichende Verschlüsselung können diese Daten während der Übertragung abgefangen werden.
* Gespeicherte Daten auf den Geräten oder in der Cloud sind ebenfalls anfällig für unbefugten Zugriff, wenn keine angemessenen Sicherheitsmaßnahmen implementiert sind.
* Viele smarte Geräte weisen schwache oder gar keine Sicherheitsstandards auf, was sie zu attraktiven Zielen für Angreifer macht.
* Firmware-Updates und Sicherheitspatches werden oft vernachlässigt oder nicht zeitnah durchgeführt, wodurch bekannte Schwachstellen bestehen bleiben.
* Schwache oder voreingestellte Passwörter und fehlende Zwei-Faktor-Authentifizierung erhöhen das Risiko, dass Unbefugte Zugriff auf die Geräte und die darauf gespeicherten Daten erhalten.

* Wenn smarte Geräte in ein Unternehmensnetzwerk integriert sind, können sie als Einfallstor für Angriffe dienen, die das gesamte Netzwerk kompromittieren.
* Unzureichende Segmentierung und Kontrolle der Netzwerkzugriffe erhöhen das Risiko eines Vertraulichkeitsverlusts.

'''Beispiele:'''

* Ein Sprachassistent zeichnet vertrauliche Gespräche im Homeoffice auf und überträgt diese unverschlüsselt an einen externen Server.
* Ein IoT-Gerät im Büro wird gehackt und dient als Einfallstor für weitere Angriffe auf das Unternehmensnetzwerk.
* Eine smarte Überwachungskamera, im Wohnhaus eines Mitarbeitenden, senden Live-Videos über das Internet an einen Cloud-Server. Wenn diese Kamera nicht richtig gesichert ist, können Angreifende auf die Video-Feeds zugreifen und sensible Informationen über die Aktivitäten des Mitarbeitenden erlangen.

=== Unzureichende physische Sicherheitsmaßnahmen [CA] ===
'''Beschreibung:''' Durch die Verlagerung von Arbeitsplätzen ins Homeoffice oder angemieteten Co-Working Space kann es zu unzureichenden physischen Sicherheitsmaßnahmen kommen. Dies betrifft insbesondere den Schutz von IT-Geräten und vertraulichen Dokumenten vor Diebstahl oder unberechtigtem Zugriff.

'''Beispiele:'''

* Bei einem Einbruch in die unzureichend gesicherte Wohnung eines Mitarbeitenden wird ein Laptop und Unterlagen mit sensiblen Unternehmensdaten gestohlen.
* Vertrauliche Dokumente werden im Co-Working Space offen herumliegen gelassen und können von Besuchenden eingesehen werden.

=== Nutzung von IPv6 im Dual Stack [CIA] ===
'''Beschreibung:''' Die Nutzung von IPv6 in einem Dual-Stack-Betrieb (parallel mit IPv4) kann zu erhöhten Sicherheitsrisiken führen, da beide Protokolle gleichzeitig verwaltet werden müssen. Dies erhöht die Komplexität der Netzwerkkonfiguration und kann zu Fehlkonfigurationen und Sicherheitslücken führen.

'''Mögliche Ursachen:'''

* Unzureichende Kenntnisse über IPv6 bei den IT-Mitarbeitenden.
* Fehlende oder unzureichende Sicherheitsrichtlinien und -maßnahmen für IPv6.
* Unvollständige oder fehlerhafte Netzwerksegmentierung.

'''Auswirkungen:'''

* Erhöhte Angriffsfläche durch zusätzliche offene Ports und Dienste.
* Höhere Wahrscheinlichkeit von Fehlkonfigurationen und Sicherheitslücken.
* Schwierigkeiten bei der Überwachung und dem Management des Netzwerks.

'''Beispiele:'''

* Ein Unternehmen implementiert IPv6 im Dual-Stack-Betrieb und übersieht eine fehlerhafte Konfiguration, die es Angreifern ermöglicht, unautorisierten Zugriff auf interne Systeme zu erhalten.
* Sicherheitsmaßnahmen wie Firewalls und Intrusion-Detection-Systeme sind nur für IPv4 konfiguriert, wodurch IPv6-Traffic ungeschützt bleibt.

=== Unabgesprochener Einsatz zusätzlicher Sicherheitsprogramme [CIA] ===
'''Beschreibung:''' Der (unabgesprochene) Einsatz zusätzlicher (lokaler) Sicherheitsprogramme wie Virenscannern und Schwachstellenscannern kann zu einer erhöhten Komplexität und zusätzlichen Sicherheitsrisiken führen. Diese Tools müssen korrekt konfiguriert und regelmäßig aktualisiert werden, um effektiv zu sein. Eine falsche Konfiguration oder veraltete Signaturen können Sicherheitslücken schaffen oder Fehlalarme auslösen.

Das können Mitarbeitende sein, die solche Software auf ihren Clients installieren (insbesodere bei BYOD), weil sie glauben, damit die Sicherheit zu erhöhen, das können lokale Server sein, die dezentral z.B. in Labors betrieben werden, oder Appliances, die vom Hersteller installiert und vorkonfiguriert mit solchen Sicherheitstools ausgeliefert werden.

'''Mögliche Ursachen:'''

* Fehlende Kenntnisse und Schulungen der IT-Mitarbeitenden im Umgang mit den Tools.
* Unzureichende Integration der Tools in die bestehende IT-Infrastruktur.
* Vernachlässigung regelmäßiger Updates und Wartungen der Sicherheitssoftware.

'''Auswirkungen:'''

* Falsche Alarme und unnötige Ressourcenbelastung durch schlecht konfigurierte Scanner.
* Sicherheitslücken durch veraltete Signaturen oder falsch konfigurierte Tools.
* Beeinträchtigung der Systemleistung durch hohe Ressourcenbeanspruchung der Sicherheitssoftware.

'''Beispiele:'''

* Ein eigener lokaler Virenscanner wird falsch konfiguriert, wodurch legitime Anwendungen blockiert und Sicherheitslücken übersehen werden.
* Ein Schwachstellenscanner wird nicht regelmäßig aktualisiert, wodurch bekannte Sicherheitslücken unentdeckt bleiben und ausgenutzt werden können.
* Ein unabgesprochen installierter Schwachstellenscanner scannt das Netz und wird von den zentralen Systemen als Angreifer erkannt oder er beeiträchtigt die Funktion anderer Systeme.

=== Nutzung von BYOD (Bring Your Own Device) [CIA] ===
'''Beschreibung:''' BYOD (Bring Your Own Device) bietet Flexibilität und Komfort, da Mitarbeitende ihre eigenen, vertrauten Geräte nutzen können, was die Produktivität und Zufriedenheit steigern kann. Zudem reduziert BYOD die Anschaffungskosten für Unternehmen, da keine zusätzlichen Geräte bereitgestellt werden müssen. Die Nutzung von privaten Geräten der Mitarbeitenden für dienstliche Zwecke birgt jedoch auch erhebliche Sicherheitsrisiken. Diese Geräte sind oft nicht ausreichend gesichert und können unautorisierten Zugriff auf Unternehmensdaten und -systeme ermöglichen.

'''Beispiele:'''

* Ein Mitarbeitender verliert sein ungeschütztes privates Smartphone, das Zugang zu Unternehmensdaten hat, wodurch sensible Informationen in falsche Hände geraten.
* Ein BYOD-Gerät wird mit Malware infiziert, die sich anschließend im Unternehmensnetzwerk verbreitet und Schäden verursacht.

=== Verteilte Zuständigkeiten in sehr großen Organisationen [CIA] ===
'''Beschreibung''': Verteilte Zuständigkeiten in sehr großen Organisationen führen zu komplexen Koordinations- und Kommunikationsprozessen. Dies kann zu einer erhöhten Anfälligkeit für Informationsverluste, Missverständnisse und ineffiziente Entscheidungsfindung führen. Die Vielzahl von Schnittstellen und die fehlende zentrale Kontrolle verstärken das Risiko von Sicherheitslücken und Verzögerungen in der Reaktion auf sicherheitsrelevante Vorfälle.

'''Beispiele''':

* In einem multinationalen Unternehmen sind IT-Sicherheitsaufgaben auf verschiedene Länder und Abteilungen verteilt. Durch fehlende zentrale Steuerung kommt es zu Verzögerungen und Lücken bei der Implementierung von Sicherheitsrichtlinien.
* Eine große Behörde hat verschiedene Abteilungen mit eigenen IT-Systemen und Sicherheitsverantwortlichen. Die mangelnde Abstimmung führt dazu, dass Sicherheitsvorfälle nicht rechtzeitig gemeldet und bearbeitet werden.
* In einem Konzern werden Sicherheitsmaßnahmen von verschiedenen Tochtergesellschaften unabhängig voneinander umgesetzt. Dadurch entstehen Inkonsistenzen und Sicherheitslücken, die Angreifende ausnutzen können.

=== Unzureichende Betriebsdokumentation [IA] ===
Die Pflege der Betriebsdokumentation ist von entscheidender Bedeutung für die Aufrechterhaltung der Informationssicherheit und den effizienten Betrieb einer Organisation. Durch regelmäßige Aktualisierung und sorgfältige Pflege der Dokumentation können Sicherheitslücken geschlossen, Ausfallzeiten minimiert und gesetzliche Anforderungen erfüllt werden.

Unzureichende Pflege der Betriebsdokumentation stellt eine erhebliche Gefährdung für die Informationssicherheit und den reibungslosen Betrieb einer Organisation dar. Betriebsdokumentationen enthalten wichtige Informationen über IT-Systeme, Netzwerkinfrastrukturen, Sicherheitsmaßnahmen und betriebliche Abläufe. Wenn diese Dokumentationen nicht regelmäßig aktualisiert und korrekt geführt werden, kann dies zu gravierenden Problemen führen.

Viele Anforderungen an die Betriebsdokumentation werden in der Praxis häufig nicht erfüllt, da sie im betrieblichen Alltag untergehen und die personellen Ressourcen nicht vorhanden sind.

'''Beispiele:'''

* Wenn Dokumentationen zu Sicherheitskonfigurationen und -richtlinien nicht aktuell gehalten werden, besteht die Gefahr, dass veraltete und unsichere Einstellungen bestehen bleiben. Beispielsweise könnten Firewall-Regeln oder Zugangskontrollen nicht mehr den aktuellen Bedrohungen entsprechen, was das Risiko von Sicherheitsvorfällen erhöht.

* Unzureichend gepflegte Dokumentationen können dazu führen, dass bei Störungen und Ausfällen die Fehlerbehebung verzögert wird. Fehlende oder veraltete Anleitungen und Protokolle machen es schwieriger, Probleme schnell zu identifizieren und zu beheben. Dies kann zu längeren Ausfallzeiten und erhöhten Betriebskosten führen.

* Wenn neue Mitarbeitende keine vollständige und aktuelle Betriebsdokumentation vorfinden, sind sie auf das Wissen ihrer Vorgänger/innen angewiesen, das oft nicht vollständig übermittelt wird. Dies kann zu Verständnislücken und Fehlern führen. Beispielsweise könnten wichtige Systemupdates oder Wartungsaufgaben übersehen werden, was die Systemsicherheit beeinträchtigt.

* In vielen Branchen sind Unternehmen verpflichtet, umfassende und aktuelle Dokumentationen zu führen, um gesetzlichen und regulatorischen Anforderungen gerecht zu werden. Unzureichende Dokumentation kann dazu führen, dass diese Anforderungen nicht erfüllt werden, was rechtliche Konsequenzen und Bußgelder nach sich ziehen kann.

=== Automatisierte, skalierbare Angriffe durch KI-Einsatz [CIA] ===
'''Beschreibung:'''

Durch die Nutzung von Künstlicher Intelligenz können Angreifende Cyberattacken in hoher Geschwindigkeit und mit großer Vielfalt automatisieren. KI-gestützte Systeme sind in der Lage, gezielt Schwachstellen zu suchen, Angriffsmuster dynamisch zu variieren und Schutzmechanismen zu umgehen. Dadurch entsteht eine neue Angriffsdynamik, die klassische Schutz- und Reaktionsmaßnahmen deutlich erschwert.

'''Auswirkung:'''
* Erhöhte Bedrohungslage durch massenhaft automatisierte und gleichzeitig personalisierte Angriffe
* Steigende Wahrscheinlichkeit von erfolgreichen Angriffen auf Vertraulichkeit, Integrität und Verfügbarkeit von Informationswerten
* Geringere Vorwarnzeiten bei Angriffen und potenziell höhere Erfolgsquoten der Angreifenden

'''Beispiel:'''

Eine KI-gestützte Schadsoftware durchsucht vollautomatisch Unternehmensnetzwerke nach Schwachstellen und startet zeitgleich personalisierte Phishing-Mails an hunderte Benutzende, um deren Zugangsdaten zu erlangen.

=== Manipulation und Kontrollverlust durch KI-Einsatz [IA] ===
'''Beschreibung:'''

KI-basierte Anwendungen und Systeme können Ziele, Entscheidungen oder Prozesse eigenständig steuern. Wird eine KI von außen manipuliert, mit fehlerhaften oder absichtlich verfälschten Daten gespeist oder ist die Entscheidungsfindung intransparent, droht ein Kontrollverlust über geschäftskritische Prozesse. Betroffene Organisationen merken Manipulationen oft zeitverzögert oder gar nicht.

'''Auswirkung:'''
* Unbeabsichtigte oder schädliche Handlungen automatisierter Systeme
* Beeinträchtigung oder Verlust der Integrität zentraler Daten und Prozesse
* Schwierigkeiten bei der Erkennung, Aufklärung und nachträglichen Beherrschung von Zwischenfällen

'''Beispiel:'''

Ein Angreifer beeinflusst über manipulierte Trainingsdaten die Prognosefunktion einer KI-basierten Zugriffskontrolle, sodass berechtigten Benutzenden der Zugang verwehrt und Unbefugten gewährt wird.

=== Unkontrollierte Nutzung von Schatten-KI [CI] ===
'''Beschreibung:'''

Mitarbeitende nutzen externe KI-basierte Dienste (z. B. Übersetzung, Textgenerierung, Chatbots) ohne Einbindung in die zentrale IT, ohne Freigabe durch das Unternehmen oder ohne Sicherstellung von Datenschutz und Informationssicherheit. Oft geschieht dies aus Effizienzgründen, mangels Alternativen oder aus Unkenntnis möglicher Gefahren.

'''Auswirkung:'''
* Abfluss von sensiblen oder vertraulichen Unternehmensinformationen an unsichere Dritte
* Verstoß gegen Datenschutzvorgaben, Vertragsbedingungen oder regulatorische Anforderungen
* Erhöhtes Risiko fehlerhafter Ergebnisse bei geschäftskritischen Aufgaben durch unkontrollierte Verwendung von KI

'''Beispiel:'''

Ein Mitarbeitender kopiert vertrauliche Produktinformationen aus einem Entwicklungsprojekt in einen öffentlichen KI-Textgenerator, dessen Betreiber die Daten speichert und für Trainingszwecke verwendet.

=== KI-gesteuerte Phishing-Angriffe [CIA] ===
'''Beschreibung:''' Generative KI ermöglicht hochpersonalisiert personalisierte und skalierbare Phishing-Kampagnen mit Deepfakes oder maßgeschneiderten Prompt-basierten Angriffen, die menschliche Überprüfung umgehen.

'''Mögliche Ursachen:'''

* Fehlende Schulungen zu KI-generierten Inhalten bei Mitarbeitern.
* Unzureichende KI-spezifische Filter in E-Mail-Systemen oder Endgeräten.
* Integration ungetesteter KI-Tools ohne Sicherheitsüberprüfung.

'''Auswirkungen:'''

* Schneller Verlust von Zugangsdaten und Ausbreitung von Malware.
* Erhöhte Erfolgsquote von Angriffen durch geringe Erkennbarkeit (bis zu 90% realistisch).
* Systemweiter Kompromiss durch automatisierte [[Lateralbewegung]].

'''Beispiele:'''

* Ein Deepfake-Video eines CEOs fordert per Videoanruf eine dringende Überweisung, was zu Millionenverlusten führt.
* KI-generierte Phishing-Mails imitieren interne Systeme perfekt und installieren Ransomware in hybriden Arbeitsumgebungen.

=== Supply-Chain-Kompromittierung [CIA] ===
'''Beschreibung:''' Angriffe auf Drittanbieter-Software oder -Dienste (z. B. via Updates oder APIs) infiltrieren Unternehmensnetzwerke unbemerkt und ermöglichen persistente Zugriffe.

'''Mögliche Ursachen:'''

* Fehlende Vertragsklauseln zu Sicherheitsaudits bei Lieferanten.
* Automatisierte Updates ohne Integritätsprüfung (z. B. SBOM-Mangel).
* Unvollständige Netzwerksegmentierung gegenüber Cloud-Diensten.

'''Auswirkungen:'''

* Kaskadierende Ausfälle in abhängigen Systemen und Datenexfiltration.
* Langfristige Präsenz von Angreifern (Dwell-Time > 100 Tage).
* Regulatorische Strafen durch NIS2-Meldepflichtverstöße.

'''Beispiele:'''

* Ein kompromittiertes Update eines gängigen CRM-Tools verteilt Malware an alle Kunden.
* API-Schnittstellen eines Logistikpartners werden genutzt, um sensible Lieferdaten zu stehlen.

=== Ransomware mit KI-Optimierung [CA] ===
'''Beschreibung:''' KI-gestützte Ransomware wählt Ziele dynamisch aus, verschlüsselt selektiv kritische Daten und kombiniert Erpressung mit Datenlecks und DDoS-Drohungen.

'''Mögliche Ursachen:'''

* Veraltete Backup-Strategien ohne Luftlücken oder Unveränderbarkeit.
* Schwache Endpoint-Detection bei hybriden Arbeitsplätzen.
* Fehlende Incident-Response-Pläne für KI-adaptive Bedrohungen.

'''Auswirkungen:'''

* Doppelte/Dreifach-Erpressung mit höheren Lösegeldforderungen.
* Produktionsausfälle von Wochen mit Fokus auf KMU und OT-Systeme.
* Rufschäden durch öffentliche Datenveröffentlichung.

'''Beispiele:'''

* KI analysiert Netzwerkverkehr und verschlüsselt nur high-value Assets wie Patientendaten in Kliniken.
* Ein Mittelstandsunternehmen erleidet parallele Angriffe auf Server und Cloud, mit Drohung auf Lieferantenbekanntgabe.

=== KI-Datenvergiftung (Data Poisoning) [IA] ===
'''Beschreibung:''' Manipulative Verunreinigung von Trainingsdaten für KI-Modelle, um Verzerrungen, Backdoors oder Fehlverhalten einzubauen, das erst zur Laufzeit aktiviert wird. Dies stellt einen Angriff auf die Integrität von maschinellem Lernen dar und umgeht konventionelle Sicherheitskontrollen.

'''Mögliche Ursachen:'''

* Unkontrollierte Nutzung öffentlicher oder crowdsourced Trainingsdaten ohne Validierung.
* Insider-Angriffe durch Mitarbeitende mit Zugriff auf ML-Pipelines.

'''Auswirkungen:'''

* Diskriminierende Entscheidungen in HR- oder Kreditvergabe-Systemen mit rechtlichen Folgen nach DSGVO Art. 22.
* Latente Backdoors, die bei Bedarf aktiviert werden und zu Systemausfällen oder Datenlecks führen.

'''Beispiele:'''

* Hinzufügen gezielter Fehlbeispiele in öffentliche Datensätze (z. B. ImageNet), die ein Modell dazu bringen, bestimmte Objekte falsch zu klassifizieren.
* Vergiftung von Kundendaten in CRM-Systemen, sodass KI-gestützte Empfehlungen diskriminierend ausfallen.

=== KI-Modelllecks (Training Data Leakage und IP-Verletzungen) [CI] ===
'''Beschreibung:''' Ungewollte Offenlegung sensibler Trainingsdaten oder proprietärer Modellgewichte durch Inference-Angriffe oder Fehlkonfigurationen, was geistiges Eigentum gefährdet und Wettbewerbsvorteile preisgibt.

'''Mögliche Ursachen:'''

* Fehlende Differential Privacy in Modellen oder ungesicherte Cloud-APIs.
* Übermäßige Freigabe von Modell-Outputs ohne Rate-Limiting.

'''Auswirkungen:'''

* Verlust von Know-how und IP-Rechten mit wirtschaftlichen Schäden.
* Verletzung des BDSG durch Rekonstruktion personenbezogener Daten aus Trainingslecks.

'''Beispiele:'''

* Model Inversion Attacks, bei denen Angreifer Trainingsdaten aus Black-Box-Queries rekonstruieren (z.B. Gesichter aus Gesichtserkennungsmodellen).
* Extraktion von API-Modellen (z.B. GPT-Varianten) durch Query-Sequenzen, die Source-Code oder Kundendaten wiedergeben.

=== Verlust menschlicher Kontrolle und mangelnde Nachvollziehbarkeit (KI Black Box) [CIA] ===
'''Beschreibung:''' Eingeschränkte menschliche Übersicht über KI-Entscheidungen durch fehlende Erklärbarkeit (Explainable AI), was zu unkontrollierbaren Automatisierungen und Verantwortungslücken führt. Dies ergänzt bestehende Kontrollverlust-Risiken um spezifische ML-Herausforderungen.

'''Mögliche Ursachen:'''

* Einsatz undurchsichtiger neuronale Netze ohne XAI-Techniken wie SHAP oder LIME.
* Automatisierte Hyperparameter-Optimierung ohne Audit-Trails.

'''Auswirkungen:'''

* Haftungsunsicherheiten bei Fehlentscheidungen gemäß ISO 27001 A.5.1.
* Regulatorische Sanktionen nach EU AI Act für Hochrisiko-Anwendungen ohne Transparenz.

'''Beispiele:'''

* Autonome Drohnen- oder Handelsysteme, die ohne nachvollziehbare Logik handeln und Eskalationen verursachen.
* Deep-Learning-Modelle in Diagnosesystemen, deren Vorhersagen nicht reproduzierbar sind.
<hr>
Weitere diskutierbare Gefährdungen:

# '''Konzentrationsrisiken durch Cloud- und Dienstleisterabhängigkeiten''' Moderne IT-Infrastrukturen basieren zunehmend auf wenigen großen Cloud- und Serviceanbietern. Fällt einer dieser zentralen Dienstleister aus oder wird kompromittiert, kann das ganze Unternehmen oder Branchen schwer betroffen sein, was eine bislang unterschätzte Bedrohung für Verfügbarkeit und Vertraulichkeit darstellt.
# '''Risiken durch Social-Engineering bei Digitalisierung und Remote-Arbeit''' Durch die starke Verbreitung von Homeoffice, mobilen Arbeitsplätzen und digitalen Kollaborationswerkzeugen sind Mitarbeitende verstärkt Ziel von gezielten manipulativen Angriffen, die weit über klassisches Phishing hinausgehen. Dies erzeugt neue Herausforderungen für Awareness und technisches Abwehrmanagement.
# '''Insiderrisiken durch neue Arbeitsmodelle und hybride Teams''' Flexible Arbeitsformen, verteilte Zuständigkeiten und wechselnde Teams erhöhen die Gefahr von unbeabsichtigtem oder bewusstem Datenmissbrauch sowie Fehlverhalten, das schwer überwacht und kontrolliert werden kann.
# '''Nachlässigkeiten bei der Sicherheitskonfiguration komplexer Technologien''' Zunehmend komplexe Infrastrukturen mit vielen Schnittstellen, Cloud-Services, APIs und Automatisierungen führen oft zu Fehlkonfigurationen, übersehenen Schwachstellen und Konfigurationsabweichungen, die unentdeckt bleiben und weitreichende Sicherheitsprobleme verursachen.
# '''Langfristige Risiken durch fehlende Nachhaltigkeit und Wartbarkeit von Sicherheitssystemen''' Unzureichende Pflege, Dokumentation und Ressourcen für Sicherheitsmaßnahmen (z. B. veraltete Technologien, fehlende Updates, Personalengpässe) können im Zeitverlauf zu erheblichen Sicherheitslücken führen und sind oft unterschätzt.

[[Kategorie:Kurzartikel]]
[[Kategorie:Grundschutz]]
[[Kategorie:KI]]

Lateralbewegung

2026-03-28T13:26:43Z

Dirk:

{{#seo:
|title=Lateralbewegung Cybersecurity: Definition & Prävention
|description=Lateralbewegung ist die seitliche Navigation von Angreifern durch Netzwerke nach initialem Zugriff (z.B. Phishing). Techniken: Pass-the-Hash, RDP. Risiken & Schutz via Zero-Trust und EDR – Erklärung mit Beispielen.}}
{{SHORTDESC:Definition & Prävention}}''Lateralbewegung ist eine zentrale Phase in fortgeschrittenen Cyberangriffen, bei der Angreifer nach dem initialen Kompromiss eines Systems (z. B. durch Phishing) seitwärts durch das Netzwerk navigieren, um weitere Systeme zu infiltrieren, Berechtigungen zu eskalieren und wertvolle Ziele wie Server oder Datenbanken zu erreichen.''

=== Wie funktioniert sie? ===
Angreifer nutzen Techniken wie das Stehlen von Credentials (Pass-The-Hash, RDP, PowerShell), Schwachstellen-Ausnutzung oder legitime Admin-Tools (Living-off-the-Land), um sich unauffällig von Host zu Host zu bewegen, oft über Wochen unbemerkt. Dies verlängert die Verweildauer (Dwell-Time) und maximiert den Schaden, z.B. vor Ransomware-Aktivierung. Im Kontext unserer vorherigen Diskussion zu KI-Phishing ermöglicht sie systemweite Ausbreitung nach dem ersten Zugriff.

=== Häufige Techniken ===

* '''Pass-the-Ticket/Hash''': Wiederverwendung gestohlener Anmeldeinformationen für Seitwärtszugriffe.
* '''Remote Services''': RDP, SMB, WMI für Fernzugriff ohne neue Exploits.
* '''Privilege Escalation''': Von User- zu Admin-Rechten via Kernel-Exploits oder Misconfigurations.

=== Abgrenzung und Prävention ===
Im Gegensatz zu vertikaler Bewegung (Tieferes Eindringen in ein System) ist Lateralbewegung horizontal (Zwischen Systemen). Schutzmaßnahmen umfassen Zero-Trust-Architektur, Netzwerksegmentierung (Mikrosegmentierung) und EDR-Tools zur Verhaltensanalyse.
[[Kategorie:Kurzartikel]]
__KEIN_INHALTSVERZEICHNIS__
[[Kategorie:KI]]

RiLi-KI-Einsatz

2026-03-28T13:25:54Z

Dirk:

{{#seo:
|title=Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)
|keywords=ISMS, KI-Sicherheit, KI-Richtlinie, Compliance, Datenschutz, Ethik, KI-Einsatz, Unternehmen, Informationssicherheit, Risikomanagement
|description=Diese Richtlinie hilft die Vorteile von KI zu nutzen und dabei Risiken zu minimieren und Compliance sicherzustellen.
}}{{SHORTDESC:Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)}}
Mustervorlage: '''"Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)"'''

''Muster-Richtlinie für den sicheren Einsatz von KI in der Organisation. Diese Richtlinie hilft die Vorteile von KI zu nutzen und dabei Risiken zu minimieren und Compliance sicherzustellen.''

== Einleitung ==
Künstliche Intelligenz (KI) bietet der Organisation erhebliche Chancen zur Effizienzsteigerung, Innovation und Verbesserung von Dienstleistungen. Angesichts der rasanten Entwicklung von KI-Technologien und der damit verbundenen Risiken ist es unerlässlich, klare Richtlinien für den sicheren und verantwortungsvollen Einsatz von KI-Systemen festzulegen.

Diese Richtlinie soll einen Rahmen schaffen, um die Vorteile von KI zu nutzen und gleichzeitig potenzielle Risiken zu minimieren und die Einhaltung relevanter Gesetze und Vorschriften zu gewährleisten, einschließlich der EU-KI-Verordnung.

== Begriffsklärung ==
Dieses Kapitel erläutert Fachbegriffe im Zusammenhang mit Künstlicher Intelligenz (KI), die in dieser Richtlinie verwendet werden und nicht als allgemeine IT-Ausdrücke vorausgesetzt werden können. Diese Begriffsklärung soll dazu beitragen, ein gemeinsames Verständnis der in dieser Richtlinie verwendeten KI-bezogenen Terminologie zu schaffen und sicherzustellen, dass alle Beteiligten die Richtlinie effektiv umsetzen können.

'''Bias (Verzerrung):''' Systematische Fehler in KI-Modellen, die zu ungerechten oder diskriminierenden Ergebnissen führen können. Bias kann in den Trainingsdaten, im Modell selbst oder in der Art und Weise, wie das Modell eingesetzt wird, entstehen.

'''CV-Screening-Tool:''' Ein KI-basiertes System, das Lebensläufe (CVs) automatisch analysiert und bewertet, um den Rekrutierungsprozess zu unterstützen.

'''Deepfakes:''' KI-generierte, überzeugend gefälschte Audio- oder Videoinhalte, die oft dazu verwendet werden, Einzelpersonen in kompromittierenden Situationen darzustellen oder Falschinformationen zu verbreiten.

'''Differential Privacy:''' Eine Technik, die verwendet wird, um die Privatsphäre von Datensätzen zu schützen, indem zufälliges Rauschen zu den Daten hinzugefügt wird. Dies ermöglicht es, Erkenntnisse aus den Daten zu gewinnen, ohne die Identität einzelner Personen preiszugeben.

'''Explainable AI (XAI):''' Ansätze und Methoden, die darauf abzielen, die Entscheidungen von KI-Systemen für den Menschen verständlicher und nachvollziehbarer zu machen. Dies ist besonders wichtig in Bereichen, in denen Transparenz und Rechenschaftspflicht erforderlich sind.

'''Generative KI:''' Eine Art von KI, die in der Lage ist, neue Inhalte zu erstellen, wie z.B. Texte, Bilder, Musik oder Code. Beispiele hierfür sind Large Language Models (LLMs) und Bildgenerierungsmodelle.

'''KI-Register:''' Ein Verzeichnis, das alle in der Organisation eingesetzten KI-Systeme dokumentiert. Das Register enthält Informationen über den Zweck des Systems, die Risikoklasse, die verwendeten Daten und die Verantwortlichkeiten.

'''Large Language Models (LLMs):''' Sehr große KI-Modelle, die auf riesigen Mengen an Textdaten trainiert wurden und in der Lage sind, menschenähnlichen Text zu generieren, zu übersetzen und zusammenzufassen.

'''Machine Learning (ML):''' Ein Teilbereich der KI, der sich mit der Entwicklung von Algorithmen befasst, die es Computern ermöglichen, aus Daten zu lernen, ohne explizit programmiert zu werden.

'''Modell-Drift:''' Eine Verschlechterung der Leistung eines Machine-Learning-Modells im Laufe der Zeit, die durch Veränderungen in den Eingabedaten oder der Umgebung verursacht wird.

'''Overfitting:''' Ein Zustand, in dem ein Machine-Learning-Modell die Trainingsdaten zu gut lernt und dadurch Schwierigkeiten hat, auf neue, unbekannte Daten zu generalisieren.

'''Prompt-Injection:''' Eine Art von Sicherheitslücke, bei der ein Angreifer bösartige Eingaben (Prompts) verwendet, um die Ausgabe eines KI-Systems zu manipulieren oder sensible Informationen zu extrahieren.

'''Synthetic Data Generation:''' Die Erzeugung von künstlichen Daten, die reale Daten simulieren, aber keine personenbezogenen Informationen enthalten. Synthetic Data kann verwendet werden, um KI-Modelle zu trainieren, ohne die Privatsphäre zu gefährden.

== Geltungsbereich ==
Diese Richtlinie gilt für alle Mitarbeitenden, Auftragnehmenden und Dritte, die KI-Systeme im Auftrag der Organisation entwickeln, implementieren, nutzen oder verwalten. Sie umfasst alle Arten von KI-Systemen, einschließlich, aber nicht beschränkt auf:

* Generative KI (z.B. Large Language Models – LLMs)
* Maschinelles Lernen (ML)
* Robotik
* Künstliche neuronale Netze

== Zielsetzung ==
Diese Richtlinie zielt darauf ab:

* Die Integration von Sicherheitsaspekten in den gesamten Lebenszyklus von KI-Systemen zu gewährleisten.
* Risiken im Zusammenhang mit KI-Technologien zu identifizieren, zu bewerten und zu minimieren.
* Die Einhaltung von Datenschutzbestimmungen, ethischen Grundsätzen und relevanten Gesetzen, einschließlich der EU-KI-Verordnung, sicherzustellen.
* Transparenz und Verantwortlichkeit im Umgang mit KI-Systemen zu fördern.
* Das Bewusstsein für die potenziellen Risiken und Chancen von KI bei den Mitarbeitenden zu schärfen.
* Innovation und Wettbewerbsfähigkeit im Einklang mit ethischen Grundsätzen und regulatorischen Anforderungen zu fördern.

== Verantwortlichkeiten ==
* '''Organisationsleitung:''' Verantwortlich für die Genehmigung dieser Richtlinie und die Bereitstellung der notwendigen Ressourcen für deren Umsetzung.
* '''Informationssicherheitsbeauftragte (ISB):''' Verantwortlich für die Überwachung der Einhaltung dieser Richtlinie und die Integration von KI-Sicherheit in das ISMS.
* '''Datenschutzbeauftragte (DSB):''' Verantwortlich für die Überwachung der Einhaltung der Datenschutzbestimmungen im Zusammenhang mit KI-Systemen.
* '''KI-Projektverantwortliche:''' Verantwortlich für die Einhaltung dieser Richtlinie bei der Entwicklung, Implementierung und Nutzung von KI-Systemen in ihren Projekten.
* '''Alle Mitarbeitenden:''' Verantwortlich für die Einhaltung dieser Richtlinie bei der Nutzung von KI-Systemen im Rahmen ihrer Tätigkeit für die Organisation.

== Richtlinien und Verfahren ==
Der sichere und verantwortungsvolle Einsatz von KI-Systemen erfordert einen ganzheitlichen Ansatz, der technische, organisatorische und ethische Aspekte berücksichtigt. Die folgenden Richtlinien und Verfahren bilden das Fundament für eine robuste KI-Governance in unserer Organisation.

Sie adressieren die Integration von KI-Sicherheit in bestehende Strukturen, die systematische Risikobewertung, die Einhaltung rechtlicher und ethischer Standards sowie die Gewährleistung von Transparenz und Verantwortlichkeit.

Diese Maßnahmen sollen sicherstellen, dass wir die Chancen der KI-Technologie nutzen können, während wir gleichzeitig potenzielle Risiken minimieren und das Vertrauen unserer Stakeholder in unsere KI-Anwendungen stärken.

=== Integration von KI-Sicherheit in das ISMS ===
KI-Systeme stellen durch ihre Komplexität und Lernfähigkeit einzigartige Sicherheitsherausforderungen dar. Um diese systematisch zu adressieren, werden KI-Komponenten vollständig in das ISMS integriert. Dies bedeutet konkret:

* Alle KI-Systeme unterliegen den allgemeinen Sicherheitsrichtlinien der Organisation.
* Spezifische Schutzmaßnahmen gegen KI-spezifische Angriffsvektoren wie Prompt-Injection sind zu implementieren, da ungefilterte Eingaben zu manipulierten Ergebnissen oder Datenlecks führen können.
* Für LLMs (Large Language Models) sind zusätzliche Content-Filter und Input-Validierungen vorzusehen, um die Generierung von Fehlinformationen oder urheberrechtlich problematischen Inhalten zu verhindern.

=== Risikobewertung von KI-Systemen ===
Aufgrund der dynamischen Entwicklungen im KI-Bereich erfordert jede KI-Anwendung eine initiale und jährliche Risikoanalyse. Dieser Prozess dient dazu:

* Kritische Einsatzbereiche (z.B. personalisierte Kundeninteraktionen) zu identifizieren, wo Fehlentscheidungen rechtliche oder reputative Schäden verursachen könnten.
* Technische Risiken wie Modell-Drift (unbemerkte Leistungsverschlechterung) zu berücksichtigen, die durch kontinuierliches Monitoring aufgefangen werden müssen.
* Ethische Risikofaktoren (Bias in Trainingsdaten) zu analysieren, die etwa zu diskriminierenden Entscheidungen führen könnten – ein Aspekt, der zentral für die Akzeptanz von KI-Systemen ist.

=== Compliance-konformer KI-Einsatz ===
Die EU-KI-Verordnung (AI Act) klassifiziert KI-Systeme in vier Risikoklassen – diese Einstufung bildet die Basis für unsere Compliance-Maßnahmen:

* Verbot bestimmter KI-Praktiken, wie z.B. Social Scoring durch Behörden (AI Act, Art. 5).
* Hochrisiko-KI-Systeme (z.B. CV-Screening-Tools) erfordern eine Konformitätserklärung, technische Dokumentation und menschliche Aufsichtspflicht.
* Transparenzpflichten gemäß Art. 52 AI Act: Bei KI-gesteuerten Chatbots muss für Nutzende klar erkennbar sein, dass sie mit einem KI-System interagieren.
* Datenherkunftsnachweise sind für Trainingsdatensätze zu führen, um Urheberrechtsverletzungen und Compliance-Risiken bei generativer KI (z.B. Text-/Bildgenerierung) zu minimieren.

=== Datensicherheit und Datenschutz ===
KI-Systeme sind datenhungrig – dieser Abschnitt stellt sicher, dass Datenflüsse rechtssicher gestaltet werden:

* Bei der Verarbeitung personenbezogener Daten ist das Prinzip "Privacy by Design" umzusetzen, z.B. durch Synthetic Data Generation oder Differential Privacy bei sensiblen Datensätzen.
* Datenminimierung ist besonders kritisch: Trainingsdatensätze dürfen nur notwendige Attribute enthalten, um das "Overfitting"-Risiko (unbeabsichtigtes Speichern sensitiver Muster) zu reduzieren.

=== Transparenz und Rechenschaftspflicht ===
Nachvollziehbarkeit ist Voraussetzung für Vertrauen in KI-Entscheidungen. Hierfür wird festgelegt:

* Entscheidungsprotokolle müssen so dokumentiert werden, dass eine Nachvollziehbarkeit ohne Fachwissen in Machine Learning möglich ist (Explainable AI-Prinzipien).
* Eine Eskalationsmatrix definiert Verantwortlichkeiten – z.B. ob der KI-Entwickler, Fachbereich oder die Organisationsleitung bei Fehlentscheidungen haftet.

=== Ethische Leitplanken und Innovation ===
Um Innovationspotenziale verantwortungsvoll zu nutzen, gilt:

* Ethische Review-Boards begleiten KI-Projekte ab der Konzeptphase, analog zu Medizintechnik-Entwicklungen.
* Open-Source-KI-Komponenten sind generell zu bevorzugen, sofern sie die Sicherheitsanforderungen erfüllen – dies fördert Reproduzierbarkeit und unabhängige Sicherheitsaudits.

== Schulung und Sensibilisierung ==
KI-Kompetenz ist kein IT-Spezialthema mehr. Unser Schulungskonzept umfasst daher:

* Pflichttrainings für Führungskräfte zur Risikoeinschätzung von KI-Projekten (Analog: DSGVO-Schulungen).
* Praxisworkshops für Entwicklerteams zu Secure-Coding-Praktiken für KI-Modelle, inklusive OWASP-Top-10 für Machine Learning.
* Awareness-Kampagnen für alle Mitarbeitenden zur Erkennung von Deepfakes und KI-generierten Phishing-Angriffen.

== Überwachung und kontinuierliche Verbesserung ==
KI-Systeme sind keine "Fire-and-Forget"-Lösungen. Unser Kontrollsystem sieht vor:

* Quartalsweise Performance-Audits mit Bias-Checks mittels Tools wie z.B. IBM AI Fairness 360.
* Einrichtung eines KI-Registers zur Dokumentation aller produktiven KI-Anwendungen inkl. ihrer Risikoklassifizierung.
* Bug-Bounty-Programme, die explizit Schwachstellen in KI-Komponenten adressieren.

== Anlage ==

* [[KI-Register|KI-Register der Organisation]]

== Schlussbemerkung ==

=== Behandlung von Ausnahmen ===
Ausnahmen von den Regelungen dieser Richtlinie sind nur mit einem begründeten Ausnahmeantrag im Rahmen des [[RiLi-Ausnahmemanagement|Ausnahmemanagements]] möglich.

=== Revision ===
Diese Richtlinie wird regelmäßig, jedoch mindestens einmal pro Jahr, durch den Regelungsverantwortlichen auf Aktualität und Konformität geprüft und bei Bedarf angepasst.

== Inkrafttreten ==
Diese Richtlinie tritt zum 01.01.2222 in Kraft.

Freigegeben durch: Organisationsleitung

Ort, 01.12.2220,

Unterschrift, Name der Leitung
[[Kategorie:Mustervorlage]]
[[Kategorie:Richtlinie]]
[[Kategorie:KI]]

LF-KI-Chatbots

2026-03-28T13:25:30Z

Dirk:

{{#seo:
|title=Leitfaden für Mitarbeitende zur Nutzung von KI-Systemen
|description=Dieser Leitfaden legt fest, wie Mitarbeitende externe KI-Systeme sicher und verantwortungsvoll nutzen können. Ziel ist es, Chancen zu nutzen, Risiken zu minimieren und die Einhaltung rechtlicher sowie unternehmensinterner Vorgaben sicherzustellen.
}}{{SHORTDESC:Leitfaden für Mitarbeitende zur Nutzung von KI-Systemen.}}
''Dieser Leitfaden legt fest, wie Mitarbeitende externe KI-Systeme sicher und verantwortungsvoll nutzen können. Ziel ist es, Chancen zu nutzen, Risiken zu minimieren und die Einhaltung rechtlicher sowie unternehmensinterner Vorgaben sicherzustellen.''

=== Zielsetzung ===
Dieser Leitfaden soll sicherstellen, dass der Einsatz von Künstlicher Intelligenz (KI) verantwortungsvoll, sicher und regelkonform erfolgt. Bei Fragen oder Unsicherheiten stehen die IT-Abteilung, Datenschutzbeauftragte oder die Organisationsleitung zur Verfügung.

'''Gültig für die Nutzung externer KI-Systeme wie ChatGPT, Copilot, Gemini und ähnliche Dienste'''

=== Grundsätze der KI-Nutzung ===
'''Erlaubte Nutzung:''' KI kann unterstützend bei der Recherche, Texterstellung, Code-Generierung oder Übersetzungen genutzt werden.

'''Verbotene Nutzung:''' KI darf nicht für Entscheidungen mit rechtlichen oder finanziellen Auswirkungen genutzt werden, insbesondere nicht zur Bewertung von Mitarbeitenden oder zum Social Scoring.

'''Verantwortung:''' Die Nutzung von KI entbindet nicht von der persönlichen Verantwortung für die erstellten Inhalte.

Die [[RiLi-KI-Einsatz|Richtlinie zum KI-Einsatz]] der Organisation ist einzuhalten.

=== Datenschutz und Vertraulichkeit ===
Es dürfen '''keine vertraulichen, personenbezogenen oder sensiblen Unternehmensdaten''' in externe KI-Systeme eingegeben werden.

Es ist darauf zu achten, dass '''keine Geschäftsgeheimnisse oder Kundendaten''' in die KI eingegeben werden.

Falls KI-generierte Inhalte verarbeitet werden, ist eine '''Prüfung''' erforderlich, um Datenschutzverstöße zu vermeiden.

=== Qualitätskontrolle und Verlässlichkeit ===
KI-generierte Inhalte müssen '''kritisch überprüft und verifiziert''' werden, bevor sie weiterverwendet werden.

Automatisch generierte Texte, Code oder Analysen sollten auf '''Faktenfehler, Verzerrungen oder Fehlinformationen''' geprüft werden.

Bei Unsicherheiten ist Rücksprache mit einer zuständigen Person (z.B. IT-Sicherheit, Datenschutz, Fachabteilungen) erforderlich.

=== Transparenz und Kennzeichnung ===
Falls KI-generierte Inhalte genutzt werden, muss dies kenntlich gemacht werden (z.B. „Erstellt mit Unterstützung von KI“).

Die Verwendung von KI für Kommunikation mit Kunden oder externen Partnern ist nur erlaubt, wenn dies mit den Unternehmensrichtlinien übereinstimmt.

Alle eingesetzten KI-Systeme müssen im [[KI-Register]] der Organisation eingetragen sein.

=== Compliance und ethische Nutzung ===
Die Nutzung von KI muss '''ethisch vertretbar und rechtlich zulässig''' sein.

Diskriminierende, irreführende oder täuschende Inhalte dürfen nicht erstellt oder verbreitet werden.

Das Umgehen von Sicherheitsmaßnahmen oder die Manipulation von Informationen mit KI ist untersagt.

=== Nutzung interner und zugelassener KI-Lösungen ===
Falls die Organisation eigene KI-Systeme oder zugelassene Plattformen bereitstellt, sind '''diese ''vorrangig oder ausschließlich'' zu nutzen'''.

Falls externe KI-Systeme genutzt werden müssen, sind diese vorab mit der IT-Abteilung oder Datenschutzbeauftragten abzustimmen.

=== Verstöße und Konsequenzen ===
Verstöße gegen diese Richtlinien können zu disziplinarischen Maßnahmen führen.

Alle Mitarbeitenden sind verpflichtet, Verdachtsfälle von Missbrauch oder Sicherheitsrisiken zu melden.

=== Schulung und Sensibilisierung ===
Mitarbeitende erhalten regelmäßige Schulungen zur sicheren und verantwortungsvollen Nutzung von KI.

Die KI-Richtlinien werden regelmäßig überprüft und aktualisiert, um neue Entwicklungen zu berücksichtigen.
[[Kategorie:Mustervorlage]]
[[Kategorie:Leitfaden]]
[[Kategorie:KI]]

KI-Nutzung

2026-03-28T13:25:04Z

Dirk:

{{#seo:
|title=Chancen und Risiken von KI im Unternehmen: Ein umfassender Überblick
|keywords=ISMS, KI im Unternehmen, Chancen und Risiken, Künstliche Intelligenz, IT-Sicherheit, Datenschutz, EU-KI-Verordnung, KI-Einsatzszenarien
|description=Chancen und Risiken von KI in Unternehmen und Behörden. Von Effizienzsteigerung bis Datenschutz: Ein umfassender Leitfaden zu rechtlichen, technischen und ethischen Aspekten.
}}{{SHORTDESC:Chancen und Risiken von KI in Unternehmen und Behörden.}}
[[Datei:Brain-8764400.png|alternativtext=KI|rechts|160x160px]]
''Chancen und Risiken von KI in Unternehmen und Behörden. Von Effizienzsteigerung bis Datenschutz: Ein umfassender Leitfaden zu rechtlichen, technischen und ethischen Aspekten.''

== Einleitung ==

Künstliche Intelligenz (KI) hat sich in den letzten Jahren zu einer Schlüsseltechnologie entwickelt, die nahezu alle Bereiche der Wirtschaft und Verwaltung beeinflusst. Dieser Artikel beleuchtet die vielfältigen Aspekte des KI-Einsatzes in Unternehmen und Behörden, von technischen Möglichkeiten über rechtliche Rahmenbedingungen bis hin zu ethischen Überlegungen.

== Was ist KI? ==
Künstliche Intelligenz (KI) bezeichnet Computersysteme, die menschenähnliche kognitive Fähigkeiten wie Lernen, Schlussfolgern und Problemlösen '''nachahmen'''. Inzwischen hat sich KI zu einer Schlüsseltechnologie entwickelt, die in vielen Bereichen von Wirtschaft und Gesellschaft zum Einsatz kommt.

Allerdings haben alle aktuellen Systeme auch klare Grenzen:

# Sie verfügen nicht über echtes Verständnis oder Bewusstsein.
# Ihre Fähigkeiten sind auf spezifische Bereiche beschränkt, für die sie trainiert wurden.
# Sie können keine eigenständigen ethischen Entscheidungen treffen.

=== Kategorien von KI ===
Die Definition von Künstlicher Intelligenz umfasst ein breites Spektrum an Technologien und Konzepten. Während schwache KI bereits weit verbreitet ist und spezialisierte Aufgaben löst, bleibt starke KI ein theoretisches Ziel. Maschinelles Lernen und Deep Learning bilden die Grundlage moderner KI-Anwendungen und treiben Innovationen in vielen Bereichen voran.

==== Schwache KI (Weak AI) ====
'''Definition''': Schwache KI, auch bekannt als "spezialisierte KI", ist darauf ausgelegt, spezifische Aufgaben auszuführen. Sie simuliert intelligentes Verhalten, hat jedoch kein eigenes Bewusstsein oder Verständnis.

'''Beispiele''':

* Sprachassistenten wie Siri oder Alexa
* Empfehlungsalgorithmen bei Netflix oder Amazon
* Bilderkennungssysteme in der Medizin

'''Merkmale''':

* Fokus auf eng definierte Anwendungen
* Keine Fähigkeit zur Generalisierung über den programmierten Bereich hinaus

==== Starke KI (Strong AI) ====
'''Definition''': Starke KI bezeichnet hypothetische Systeme, die menschenähnliche allgemeine Intelligenz besitzen. Sie können nicht nur spezifische Aufgaben lösen, sondern auch eigenständig lernen und Probleme in unterschiedlichen Kontexten verstehen.

'''Merkmale''':

* Allgemeine Problemlösungsfähigkeit
* Eigenes Bewusstsein und Verständnis
* Fähigkeit zur kreativen Entscheidungsfindung

'''Status''': Starke KI existiert derzeit nicht; sie bleibt ein Forschungsziel und eine philosophische Debatte. Konzepte wie "Künstliche Allgemeine Intelligenz" (Artificial General Intelligence, AGI) beziehen sich auf diese Vision.

=== Konzepte innerhalb der KI ===

==== Maschinelles Lernen (ML) ====
'''Definition''': Maschinelles Lernen ist ein Teilgebiet der KI, das Systeme entwickelt, die aus Daten lernen und ihre Leistung ohne explizite Programmierung verbessern können.

'''Ansätze''':

* '''Überwachtes Lernen (Supervised Learning)''': Modelle werden mit gekennzeichneten Daten trainiert.
** Beispiel: Vorhersage von Immobilienpreisen basierend auf historischen Daten.
* '''Unüberwachtes Lernen (Unsupervised Learning)''': Modelle identifizieren Muster in unmarkierten Daten.
** Beispiel: Clustering von Kundengruppen für Marketingstrategien.
* '''Bestärkendes Lernen (Reinforcement Learning)''': Systeme lernen durch Belohnung und Bestrafung in einer Umgebung.
** Beispiel: Training eines Roboters zur Navigation durch Versuch und Irrtum.

==== Deep Learning ====
'''Definition''': Deep Learning ist eine Unterkategorie des Maschinellen Lernens, die künstliche neuronale Netze verwendet, um komplexe Muster in großen Datenmengen zu erkennen.

'''Anwendungen''':

* Bildverarbeitung (z. B. Gesichtserkennung)
* Sprachverarbeitung (z. B. Übersetzungsdienste)
* Autonome Fahrzeuge

==== Natural Language Processing (NLP) ====
'''Definition''': NLP befasst sich mit der Verarbeitung und Analyse natürlicher Sprache durch Maschinen.

'''Beispiele''':

* Chatbots wie ChatGPT
* Automatische Übersetzungstools wie DeepL
* Textanalyse für Sentiment-Erkennung

=== Weitere Begriffe im Kontext von KI ===
'''Künstliche Allgemeine Intelligenz (AGI)'''

AGI beschreibt eine starke Form der KI mit umfassendem Verständnis und Problemlösungsfähigkeiten in verschiedenen Domänen. Sie wird oft als langfristiges Ziel der KI-Forschung angesehen.

'''Künstliche Superintelligenz (ASI)'''

ASI geht über menschliche Intelligenz hinaus und beschreibt eine hypothetische Zukunftsvision von Maschinenintelligenz, die Menschen in nahezu allen Bereichen übertrifft.

'''Neurale Netze'''

Ein Modell inspiriert vom menschlichen Gehirn, das aus Schichten von Knoten ("Neuronen") besteht und für viele Deep-Learning-Anwendungen verwendet wird.

== Einsatzszenarien von KI ==

=== KI-Chatbots für Kunden und Partner ===

KI-gestützte Chatbots haben sich seit ihrer Einführung vor einigen Jahren erheblich weiterentwickelt. Moderne Systeme nutzen fortschrittliche Natural Language Processing (NLP) Technologien, um komplexe Kundenanfragen zu verstehen und zu beantworten. Ein Beispiel ist der Einsatz von Large Language Models (LLMs) wie GPT-4, die es Chatbots ermöglichen, kontextbezogene und nuancierte Antworten zu generieren.

Vorteile:
* Erhöhte Verfügbarkeit: 24/7-Service ohne Wartezeiten
* Kosteneffizienz: Reduzierung des Personalaufwands für Routineanfragen
* Skalierbarkeit: Bewältigung von Anfragespitzen ohne Qualitätsverlust
* Mehrsprachigkeit: Unterstützung globaler Kundschaft ohne Sprachbarrieren

Herausforderungen:
* Datenschutz: Sicherstellung der DSGVO-Konformität bei der Verarbeitung personenbezogener Daten
* Qualitätssicherung: Kontinuierliche Überwachung und Verbesserung der Antwortqualität
* Integration: Nahtlose Einbindung in bestehende Customer-Relationship-Management (CRM) Systeme

=== KI in Produktion und Dienstleistung ===

Der Einsatz von KI in der Produktion hat das Potenzial, die Industrie 4.0 auf ein neues Niveau zu heben. Predictive Maintenance, ein Kernbereich des KI-Einsatzes in der Produktion, nutzt Maschinelles Lernen, um Ausfälle vorherzusagen und ungeplante Stillstandzeiten zu minimieren.

Weitere Anwendungsbereiche:
* Qualitätskontrolle durch KI-gestützte Bildverarbeitung
* Optimierung von Lieferketten durch intelligente Bedarfsprognosen
* Energieeffizienzsteigerung durch KI-gesteuerte Prozessoptimierung

=== KI zur Stärkung der IT-Sicherheit ===

Angesichts der zunehmenden Komplexität von Cyberangriffen spielt KI eine immer wichtigere Rolle in der IT-Sicherheit. Moderne Security Information and Event Management (SIEM) Systeme nutzen KI-Algorithmen, um Anomalien im Netzwerkverkehr zu erkennen und potenzielle Bedrohungen in Echtzeit zu identifizieren.

Herausforderungen:
* Datenschutz: Balancierung zwischen Sicherheitsanforderungen und Privatsphäre der Mitarbeitenden
* Fachkräftemangel: Bedarf an Spezialisten mit Expertise in KI und Cybersicherheit
* Ethische Fragen: Abwägung zwischen automatisierten Entscheidungen und menschlicher Kontrolle
===KI als eigenständiges Produkt===
Unternehmen entwickeln zunehmend KI-basierte Produkte und Dienstleistungen wie:
* Personalisierte Empfehlungssysteme
*Automatisierte Analysewerkzeuge für Daten
*Entscheidungsunterstützungssysteme
== Rechtliche Aspekte ==

=== EU-KI-Verordnung ===

Die EU-KI-Verordnung, die seit Februar 2025 schrittweise in Kraft tritt, stellt Unternehmen vor neue Herausforderungen. Sie kategorisiert KI-Systeme nach ihrem Risikoniveau und stellt entsprechende Anforderungen an deren Entwicklung und Einsatz.

Kernpunkte:
* Verbot bestimmter KI-Praktiken, wie z.B. Social Scoring durch Behörden
* Strenge Auflagen für Hochrisiko-KI-Systeme, einschließlich Transparenzpflichten und Konformitätsbewertungen
* Spezielle Anforderungen an KI-Systeme in sensiblen Bereichen wie Gesundheitswesen oder Strafverfolgung

Unternehmen müssen ihre KI-Strategien an diese neuen Regularien anpassen. Dies erfordert oft erhebliche Investitionen in Compliance-Maßnahmen und kann die Markteinführung neuer KI-Produkte verzögern.

=== Vertragsrechtliche Herausforderungen ===

Der Einsatz von KI wirft komplexe vertragsrechtliche Fragen auf, insbesondere im Bereich der Haftung und des geistigen Eigentums.

Weitere Herausforderungen:
* Eigentum an KI-generierten Daten und Ergebnissen
* Datenschutzrechtliche Aspekte bei der Nutzung personenbezogener Daten für KI-Training
* Vertragsgestaltung bei KI-as-a-Service Angeboten

== Ethische und gesellschaftliche Aspekte ==

Der Einsatz von KI in Unternehmen und Behörden wirft wichtige ethische Fragen auf, die über rein technische oder rechtliche Aspekte hinausgehen.

=== Fairness und Nicht-Diskriminierung ===

KI-Systeme können unbeabsichtigt diskriminierende Entscheidungen treffen, wenn sie mit verzerrten Datensätzen trainiert wurden. Ein bekanntes Beispiel ist ein KI-basiertes Rekrutierungstool eines großen Technologieunternehmens, das 2018 aufgrund von Gender-Bias eingestellt wurde.

Lösungsansätze:
* Diversität in KI-Entwicklungsteams fördern
* Regelmäßige Audits von KI-Systemen auf Fairness und Bias
* Transparenz und Erklärbarkeit von KI-Entscheidungen erhöhen

=== Auswirkungen auf den Arbeitsmarkt ===

Die zunehmende Automatisierung durch KI führt zu Veränderungen auf dem Arbeitsmarkt. Während einige Berufsbilder verschwinden, entstehen neue Tätigkeitsfelder.

Herausforderungen:
* Umschulung und Weiterbildung von Arbeitnehmenden
* Soziale Absicherung in Zeiten des Wandels
* Förderung von Kreativität und sozialen Kompetenzen, die schwer durch KI zu ersetzen sind

== Risiken der KI ==
Der Einsatz von Künstlicher Intelligenz (KI) birgt neben den vielfältigen Chancen auch erhebliche Risiken, die einer sorgfältigen Betrachtung und Bewertung bedürfen. Im Folgenden werden die wesentlichen Risikobereiche detailliert beleuchtet.

=== Datenschutz und Privatsphäre ===
Ein zentrales Risiko beim Einsatz von KI-Systemen betrifft den Schutz personenbezogener Daten und die Wahrung der Privatsphäre. KI-Modelle, insbesondere Large Language Models (LLMs), benötigen enorme Datenmengen für ihr Training, was Fragen zur rechtmäßigen Datenerhebung und -verarbeitung aufwirft. Die EU-Datenschutz-Grundverordnung (DSGVO) stellt hier strenge Anforderungen, die Unternehmen beim KI-Einsatz berücksichtigen müssen.

Herausforderungen:

* Sicherstellung der DSGVO-Konformität bei der Verarbeitung personenbezogener Daten
* Schutz vor unbeabsichtigter Offenlegung sensibler Informationen durch KI-Systeme
* Gewährleistung der Datensicherheit bei der Übertragung und Speicherung von Trainingsdaten

=== Bias und Diskriminierung ===
KI-Systeme können unbeabsichtigt diskriminierende Entscheidungen treffen, wenn sie mit verzerrten Datensätzen trainiert wurden. Dies kann zu unfairen Behandlungen bestimmter Personengruppen führen, beispielsweise bei Einstellungsprozessen oder Kreditvergaben.
Maßnahmen zur Risikominimierung:

* Regelmäßige Audits von KI-Systemen auf Fairness und Bias
* Diversität in KI-Entwicklungsteams fördern
* Implementierung von Methoden zur Erkennung und Korrektur von Verzerrungen in Trainingsdaten

=== Mangelnde Transparenz und Erklärbarkeit ===
Viele KI-Systeme, insbesondere komplexe neuronale Netze, agieren als "Black Boxes", deren Entscheidungsprozesse für Menschen schwer nachvollziehbar sind. Dies kann zu Problemen führen, wenn KI-Systeme in kritischen Bereichen wie Medizin oder Justiz eingesetzt werden.

Lösungsansätze:

* Entwicklung und Einsatz von Explainable AI (XAI) Techniken
* Transparente Dokumentation von KI-Entscheidungsprozessen
* Schulung von Anwendern im Umgang mit KI-generierten Ergebnissen

=== Abhängigkeit und Kontrollverlust ===
Mit zunehmender Integration von KI in kritische Infrastrukturen und Entscheidungsprozesse wächst das Risiko einer übermäßigen Abhängigkeit. Ein Ausfall oder eine Fehlfunktion von KI-Systemen kann schwerwiegende Folgen haben.

Präventive Maßnahmen:

* Implementierung robuster Backup-Systeme und Notfallpläne
* Regelmäßige Überprüfung und Wartung von KI-Systemen
* Beibehaltung menschlicher Kontroll- und Eingriffsmöglichkeiten

=== Rechtliche und ethische Herausforderungen ===
Der Einsatz von KI wirft komplexe rechtliche und ethische Fragen auf, insbesondere im Bereich der Haftung und Verantwortlichkeit. Wer haftet beispielsweise bei Fehlentscheidungen autonomer Systeme?

Notwendige Schritte:

* Entwicklung klarer rechtlicher Rahmenbedingungen für den KI-Einsatz
* Etablierung ethischer Richtlinien und Governance-Strukturen in Unternehmen
* Förderung des gesellschaftlichen Diskurses über die ethischen Implikationen von KI

=== Sicherheitsrisiken und Missbrauchspotenzial ===
KI-Systeme können auch für böswillige Zwecke missbraucht werden, etwa zur Erstellung von Deepfakes oder für automatisierte Cyberangriffe. Zudem besteht die Gefahr, dass KI-Systeme selbst zum Ziel von Angriffen werden.

Schutzmaßnahmen:

* Implementierung robuster Sicherheitsarchitekturen für KI-Systeme
* Entwicklung von KI-basierten Abwehrmechanismen gegen Cyberangriffe
* Internationale Zusammenarbeit zur Bekämpfung des Missbrauchs von KI-Technologien

=== Auswirkungen auf den Arbeitsmarkt ===
Die zunehmende Automatisierung durch KI führt zu Veränderungen auf dem Arbeitsmarkt. Während einige Berufsbilder verschwinden, entstehen neue Tätigkeitsfelder.

Handlungsempfehlungen:

* Förderung von Umschulungs- und Weiterbildungsprogrammen
* Entwicklung neuer Bildungskonzepte zur Vorbereitung auf eine KI-geprägte Arbeitswelt
* Soziale Absicherung für von Automatisierung betroffene Arbeitnehmende

=== Ressourcenverbrauch und Umweltauswirkungen ===
Der Betrieb von KI-Systemen, insbesondere das Training großer Sprachmodelle, ist extrem energie- und ressourcenintensiv. Dies führt zu erheblichen Umweltauswirkungen und hohen Betriebskosten.

Lösungsansätze:

* Entwicklung energieeffizienterer KI-Architekturen und Trainingsmethoden
* Nutzung erneuerbarer Energien für Rechenzentren
* Berücksichtigung der Umweltauswirkungen bei der Kosten-Nutzen-Analyse von KI-Projekten

Die genannten Risiken verdeutlichen die Notwendigkeit eines verantwortungsvollen und durchdachten Einsatzes von KI. Unternehmen und Behörden sind gefordert, umfassende Strategien zu entwickeln, die technologische Innovationen mit ethischen Prinzipien und rechtlichen Anforderungen in Einklang bringen. Nur so kann das volle Potenzial von KI ausgeschöpft werden, ohne dabei grundlegende Werte und Rechte zu gefährden.

== Fazit ==

Der Einsatz von KI in Unternehmen und Behörden bietet enorme Chancen zur Effizienzsteigerung und Innovation. Gleichzeitig stellt er Organisationen vor komplexe technische, rechtliche und ethische Herausforderungen. Ein verantwortungsvoller und durchdachter Einsatz von KI, der rechtliche Rahmenbedingungen beachtet und ethische Aspekte berücksichtigt, ist entscheidend für den langfristigen Erfolg und die gesellschaftliche Akzeptanz dieser Technologie.

Unternehmen und Behörden sind gefordert, KI-Strategien zu entwickeln, die nicht nur technologische Aspekte berücksichtigen, sondern auch rechtliche Compliance, ethische Verantwortung und gesellschaftliche Auswirkungen einbeziehen. Nur so kann das volle Potenzial von KI ausgeschöpft werden, ohne dabei grundlegende Werte und Rechte zu gefährden.

== Weitere Infomationen ==

* [[Datenbias|Was ist Daten-Bias?]]
* [[KI Datenschutz|Datenschutz in KI-Anwendungen]]
* [[RiLi-KI-Einsatz|Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)]]
* [[KI-Register|Mustervorlage für ein KI-Register]]
* [[LF-KI-Chatbots|Leitfaden für Mitarbeitende zur Nutzung von KI-Systemen]]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=OJ:L_202401689 EU-Verordnung über künstliche Intelligenz]
* [https://www.bfdi.bund.de/DE/Fachthemen/Inhalte/Technik/KI-Verordnung.html Die KI-Verordnung der EU (BfDI)]

[[Kategorie:Artikel]]
[[Kategorie:KI]]

KI Cybersicherheit

2026-03-28T13:24:37Z

Dirk:

{{#seo:
|title=KI als Fluch und Segen in der Cybersicherheit
|description=Die Entwicklung und Nutzung von künstlicher Intelligenz (KI) in der Cybersicherheit bringt sowohl neue Möglichkeiten als auch neue Risiken mit sich. Sie kann für Angriffe genauso genutzt werden wie für die Abwehr.
}}{{SHORTDESC:KI als Fluch und Segen in der Cybersicherheit.}}
Die Entwicklung und Nutzung von '''künstlicher Intelligenz (KI)''' in der Cybersicherheit bringt sowohl neue Möglichkeiten als auch neue Risiken mit sich. '''KI-gestützte Bedrohungen''' sind fortschrittliche Angriffstechniken, die künstliche Intelligenz nutzen, um effektiver und effizienter zu sein als herkömmliche Methoden. Es gibt jedoch auch spezifische Abwehrstrategien, die mithilfe von KI-Technologien implementiert werden können, um solchen Bedrohungen entgegenzuwirken.

=== KI-gestützte Bedrohungen ===

==== Deepfake-Angriffe ====
* '''Beschreibung''': Deepfakes sind manipulierte Medien (Bilder, Videos oder Audiodateien), die durch KI-Algorithmen wie '''Generative Adversarial Networks (GANs)''' erstellt wurden. Deepfakes können verwendet werden, um Fake-Identitäten zu erstellen, Social Engineering zu unterstützen oder das Vertrauen in Kommunikation zu untergraben.
* '''Risiken''': Fake-Identitäten können in Social-Engineering-Angriffen verwendet werden, um Zugang zu vertraulichen Informationen zu erhalten oder zu Desinformationszwecken eingesetzt werden.

==== KI-gesteuerte Phishing-Kampagnen ====
* '''Beschreibung''': KI-Modelle können genutzt werden, um personalisierte Phishing-E-Mails zu erstellen, die täuschend echt wirken. KI kann große Mengen an Informationen über potenzielle Opfer verarbeiten und maßgeschneiderte Inhalte generieren.
* '''Risiken''': Erhöhte Erfolgsquote solcher Angriffe durch die gezielte Ansprache und Kontextualisierung.

==== Malware mit KI-Steuerung ====
* '''Beschreibung''': Moderne Malware kann KI nutzen, um sich dynamisch an die Umgebung anzupassen, zum Beispiel indem sie das Verhalten eines infizierten Systems analysiert und ihre eigene Aktivität darauf abstimmt.
* '''Risiken''': Solche Malware kann besser unentdeckt bleiben, indem sie Antivirenprogramme umgeht oder Sandboxen erkennt.

==== KI-basierte Passwort-Cracking ====
* '''Beschreibung''': KI und maschinelles Lernen können die Effektivität von Passwort-Cracking-Methoden wie '''Brute-Force''' oder '''Dictionary Attacks''' erhöhen. KI kann zum Beispiel lernen, welche Passwörter üblicherweise genutzt werden oder wie Passwortmuster aussehen.
* '''Risiken''': Erhöhte Geschwindigkeit und Präzision beim Brechen von Passwörtern.

==== Adversarial Attacks gegen ML-Modelle ====
* '''Beschreibung''': Angriffe, bei denen kleine, gezielte Änderungen an den Eingabedaten eines ML-Modells vorgenommen werden, um das Modell zu täuschen. Solche Angriffe können ein Modell dazu bringen, Fehlklassifikationen vorzunehmen.
* '''Risiken''': Systeme, die maschinelles Lernen verwenden, könnten manipuliert werden, zum Beispiel autonome Fahrzeuge, Bilderkennungssoftware oder Sicherheitsüberwachungssysteme.

=== Abwehrstrategien gegen KI-gestützte Bedrohungen ===

==== KI-gestützte Bedrohungserkennung ====
* KI kann selbst zur Erkennung von Bedrohungen eingesetzt werden. Moderne '''Intrusion Detection Systeme (IDS)''' nutzen maschinelles Lernen, um anomales Verhalten im Netzwerk zu erkennen.
* '''Verhaltenserkennung''': KI-Modelle können trainiert werden, normales Benutzerverhalten zu lernen und Abweichungen zu erkennen, die auf potenzielle Angriffe hindeuten.

==== Adversarial Training ====
* Um Angriffe gegen maschinelle Lernmodelle abzuwehren, können die Modelle durch '''adversarial training''' robuster gemacht werden. Das bedeutet, dass man die Modelle mit manipulierten Daten trainiert, damit sie lernen, solche Angriffe zu erkennen und zu verhindern.
* '''Robustheit der Modelle''': Durch kontinuierliches Training mit potenziell gefährlichen Eingaben werden ML-Modelle widerstandsfähiger gegen Adversarial Attacks.

==== Deepfake-Erkennung ====
* '''KI-basierte Erkennungstools''' können eingesetzt werden, um Deepfakes zu identifizieren. Diese Tools analysieren spezifische Merkmale von Videos oder Audiodateien (wie Gesichtsausdrücke oder die Synchronisation von Sprache und Lippenbewegungen), um Manipulationen zu erkennen.
* '''Blockchain-Technologie''': Die Authentizität von Video- und Bildmaterial kann durch Blockchain-basierte Lösungen validiert werden, um sicherzustellen, dass die Inhalte nicht manipuliert wurden.

==== Phishing-Schutz mit KI ====
* KI kann eingesetzt werden, um Phishing-E-Mails zu erkennen und abzufangen. '''Natural Language Processing (NLP)''' wird verwendet, um den Inhalt von E-Mails zu analysieren und mögliche Anzeichen für Phishing zu identifizieren.
* '''Benutzerbewusstsein''': KI-gestützte Schulungen können genutzt werden, um Mitarbeitende gezielt auf Phishing-Versuche vorzubereiten und deren Sensibilisierung zu verbessern.

==== Netzwerksegmentierung und Zero Trust ====
* Durch '''Netzwerksegmentierung''' wird das Netzwerk in kleinere, isolierte Zonen aufgeteilt, um den Schaden eines erfolgreichen Angriffs zu begrenzen. Wenn KI-basierte Malware eindringt, ist der Zugriff auf andere Netzwerkbereiche stark eingeschränkt.
* Das '''Zero-Trust-Modell''' geht davon aus, dass jede Anfrage verifiziert werden muss, unabhängig davon, ob sie aus dem internen oder externen Netzwerk stammt. Dadurch wird das Risiko minimiert, dass KI-basierte Malware auf weitere Systeme zugreifen kann.

==== Verwendung von starken Passwort-Management-Tools ====
* Passwortmanager können verwendet werden, um sicherzustellen, dass komplexe und zufällige Passwörter verwendet werden, die schwerer durch KI-basierte Cracking-Methoden zu brechen sind.
* Zusätzlich können '''Multi-Faktor-Authentifizierung (MFA)''' und '''Passwordless Authentication''' die Sicherheit deutlich erhöhen.

==== Threat Intelligence und Automatisierung ====
* KI kann zur Sammlung und Analyse von '''Threat Intelligence''' verwendet werden. Sie kann Bedrohungen frühzeitig erkennen und automatisch darauf reagieren, indem zum Beispiel bestimmte Zugriffsrechte entzogen werden.
* '''Security Orchestration, Automation, and Response (SOAR)'''-Plattformen nutzen KI, um Vorfälle zu erkennen und automatisierte Abwehrmaßnahmen durchzuführen.

=== Fazit ===
KI-gestützte Bedrohungen stellen eine neue Dimension in der Cyber-Bedrohungslandschaft dar. Die gleichen Technologien, die für Angriffe genutzt werden können, können jedoch auch zur Verteidigung eingesetzt werden.

Mithilfe von KI-gestützten Abwehrstrategien und einem tiefen Verständnis der Gefahren durch KI ist es möglich, die Sicherheitsinfrastruktur eines Unternehmens resilienter zu machen. Wichtig ist, proaktiv zu agieren, Bedrohungen frühzeitig zu erkennen und Maßnahmen zu ergreifen, um die eigenen Systeme und Daten effektiv zu schützen.

[[Kategorie:Kurzartikel]]
__KEIN_INHALTSVERZEICHNIS__
[[Kategorie:KI]]

KI Datenschutz

2026-03-28T13:23:56Z

Dirk:

{{#seo:
|title=Datenschutz in KI-Anwendungen
|description=Unternehmen müssen sicherstellen, dass der Datenschutz in allen Phasen der Entwicklung und Nutzung von KI-Anwendungen berücksichtigt wird.
}}{{SHORTDESC:Datenschutz in KI-Anwendungen.}}
''Der Einsatz von Künstlicher Intelligenz (KI) bringt erhebliche Vorteile für viele Branchen, aber auch erhebliche Herausforderungen im Bereich des Datenschutzes. KI-Systeme verarbeiten oft große Mengen personenbezogener Daten, was strenge datenschutzrechtliche Anforderungen nach der Datenschutz-Grundverordnung (DSGVO) und anderen Gesetzen notwendig macht. Unternehmen müssen sicherstellen, dass der Datenschutz in allen Phasen der Entwicklung und Nutzung von KI-Anwendungen berücksichtigt wird.

== Spezifische Herausforderungen im Datenschutz bei KI ==

=== Datensammlung und -minimierung ===
KI-Systeme erfordern oft große Mengen an Daten für das Training. Dabei besteht das Risiko, dass personenbezogene Daten ohne klare Notwendigkeit gesammelt und verarbeitet werden, was gegen die DSGVO verstößt. Die Grundsätze der <u>Datenminimierung</u> und <u>Zweckbindung</u> fordern, dass nur die Daten gesammelt werden, die unbedingt erforderlich sind.

'''Lösung''': Unternehmen sollten einen klaren Zweck für die Datennutzung definieren und eine [[DSFA|Datenschutz-Folgenabschätzung]] (Art. 35 DSGVO) durchführen, um potenzielle Risiken zu identifizieren. Zusätzlich sollte die Datensammlung auf das absolute Minimum beschränkt werden, indem beispielsweise Anonymisierungs- oder Pseudonymisierungstechniken genutzt werden.

=== Anonymisierung und Pseudonymisierung ===
KI-Anwendungen können personenbezogene Daten für Analysen oder Prognosen verwenden. Um den Datenschutz zu gewährleisten, sollten Unternehmen Daten anonymisieren oder pseudonymisieren, wann immer möglich. Anonymisierte Daten sind von den strengen Anforderungen der DSGVO ausgenommen, wohingegen pseudonymisierte Daten weiterhin unter den Datenschutz fallen, aber ein geringeres Risiko darstellen.

'''Lösung''': Implementierung robuster Anonymisierungstechniken wie k-Anonymität oder Differential Privacy, die sicherstellen, dass Einzelpersonen nicht über indirekte Informationen identifizierbar sind. Wenn Anonymisierung nicht praktikabel ist, sollten Pseudonymisierungstechniken eingesetzt werden, um den direkten Bezug zu identifizierbaren Personen zu vermeiden.

=== Erklärbarkeit und Transparenz ===
Die DSGVO fordert, dass betroffene Personen das Recht haben, zu verstehen, wie ihre Daten verarbeitet werden (Art. 15 DSGVO). Bei komplexen KI-Modellen kann dies problematisch sein, da viele KI-Systeme, insbesondere neuronale Netze, als "Black Box" angesehen werden, deren Entscheidungsfindungen schwer nachvollziehbar sind.

'''Lösung''': Unternehmen sollten Erklärbarkeits- und Transparenzmechanismen einführen, die es ermöglichen, Entscheidungen von KI-Systemen nachvollziehbar zu machen. Dies kann durch die Nutzung von Explainable AI (XAI) erreicht werden, um sicherzustellen, dass den Betroffenen verständlich erklärt werden kann, wie ihre Daten in die Entscheidungsfindung eingeflossen sind.

=== Einwilligung und Rechtsgrundlagen der Datenverarbeitung ===
Die Verarbeitung personenbezogener Daten durch KI muss auf einer Rechtsgrundlage gemäß Art. 6 DSGVO beruhen, wobei die Einwilligung eine der gängigsten Grundlagen ist. In der Praxis ist es jedoch oft schwierig, eine informierte und spezifische Einwilligung von den Betroffenen einzuholen, insbesondere bei KI-Anwendungen, deren Verarbeitungszwecke sich ändern können.

'''Lösung''': Unternehmen sollten alternative Rechtsgrundlagen prüfen, wie die <u>Vertragserfüllung</u> oder das <u>berechtigte Interesse</u>. Falls die Einwilligung verwendet wird, muss sie klar und einfach formuliert werden, und die Betroffenen müssen die Möglichkeit haben, ihre Einwilligung jederzeit zu widerrufen. Dies setzt voraus, dass die KI-Anwendung transparent macht, wie die Daten verwendet werden.

=== Bias und Diskriminierung ===
Ein wesentliches Risiko bei KI-Anwendungen ist der [[Datenbias]]. Wenn KI-Systeme auf fehlerhaften oder voreingenommenen Daten trainiert werden, können sie diskriminierende Entscheidungen treffen, die bestimmte Gruppen benachteiligen. Dies verstößt nicht nur gegen die Grundsätze der Fairness, sondern auch gegen den Gleichbehandlungsgrundsatz im Datenschutzrecht.

'''Lösung''': Unternehmen müssen sicherstellen, dass ihre Datensätze repräsentativ sind und keine verzerrten oder diskriminierenden Daten enthalten. Zudem sollten Bias-Kontrollen und regelmäßige Überprüfungen der KI-Modelle implementiert werden, um sicherzustellen, dass keine benachteiligenden Entscheidungen getroffen werden.

=== Rechte der betroffenen Personen ===
Gemäß der DSGVO haben betroffene Personen umfangreiche Rechte, wie das Recht auf Auskunft (Art. 15), Berichtigung (Art. 16) oder Löschung (Art. 17). Diese Rechte müssen auch bei der Verarbeitung durch KI-Anwendungen beachtet werden, was jedoch aufgrund der Art und Weise, wie KI-Systeme Daten verarbeiten, eine Herausforderung darstellen kann.

'''Lösung''': Unternehmen sollten sicherstellen, dass ihre KI-Systeme die Rechte der betroffenen Personen technisch unterstützen, insbesondere das Recht auf Löschung und das Recht auf Datenübertragbarkeit (Art. 20 DSGVO). KI-Systeme müssen so gestaltet sein, dass personenbezogene Daten auf Anfrage gelöscht oder exportiert werden können, ohne den Betrieb des Systems zu beeinträchtigen.

== Fazit ==
Der Datenschutz in KI-Anwendungen stellt aufgrund der Menge und der Art der verarbeiteten Daten eine erhebliche Herausforderung dar. Unternehmen müssen proaktive Maßnahmen ergreifen, um sicherzustellen, dass die Datenschutzanforderungen der DSGVO und anderer Gesetze eingehalten werden. Dies erfordert eine durchdachte Planung in Bezug auf Datenminimierung, Anonymisierung, Transparenz und den Schutz der Rechte der Betroffenen. Nur durch die Berücksichtigung dieser Aspekte kann KI verantwortungsvoll und datenschutzkonform eingesetzt werden.

[[Kategorie:Kurzartikel]]
[[Kategorie:Datenschutz]]
__KEIN_INHALTSVERZEICHNIS__
[[Kategorie:KI]]

KI-Register

2026-03-28T13:22:22Z

Dirk:

{{#seo:
|title=KI-Register Muster: Vorlage für den sicheren und rechtskonformen KI-Einsatz
|keywords=ISMS, KI-Register, Künstliche Intelligenz, Muster, Vorlage, EU-KI-Verordnung, DSGVO, ISMS, Compliance, Dokumentation, Risikoklassifizierung, Datenschutz, Audit
|description=Mustervorlage für ein vollständiges KI-Register für dein Unternehmen – inklusive aller Pflichtangaben nach EU-KI-Verordnung, DSGVO und ISMS.
}}{{SHORTDESC:KI-Register Muster: Vorlage für den sicheren und rechtskonformen KI-Einsatz}}''Ein praxisorientiertes Musterdokument für ein KI-Register, das alle wesentlichen Angaben gemäß aktuellen regulatorischen Anforderungen (z.B. EU-KI-Verordnung, DSGVO, ISMS-Standards) enthält. Das Register kann als Tabelle geführt werden und sollte regelmäßig aktualisiert werden.''

== KI-Register der Organisation ==
Verzeichnis aller in der Organisation eingesetzten KI-Anwendungen. Ziel des Registers ist es, Transparenz über den Einsatz von Künstlicher Intelligenz zu schaffen und zentrale Informationen wie den Zweck, die Funktionsweise, die Verantwortlichkeiten, die eingesetzten Datenarten, die Risikokategorie sowie Maßnahmen zu Datenschutz und IT-Sicherheit zu erfassen:
{| class="wikitable"
!<small>Nr.</small>
!<small>Bezeichnung des KI-Systems</small>
!<small>Verantwortliche Person/Abteilung</small>
!<small>Zweck und Einsatzbereich</small>
!<small>Risikokategorie (nach EU-KI-VO)</small>
!<small>Hersteller/ Anbieter</small>
!<small>Technische Beschreibung</small>
!<small>Verwendete Datenarten</small>
!<small>Personenbezug der Daten</small>
!<small>Datenschutzfolgeabschätzung erforderlich (ja/nein)</small>
!<small>Schnittstellen zu anderen Systemen</small>
!<small>Maßnahmen zur Transparenz und Nachvollziehbarkeit</small>
!<small>Maßnahmen zur IT-Sicherheit</small>
!<small>Status (Pilot/Betrieb/Stillgelegt)</small>
!<small>Letzte Überprüfung</small>
|-
|1
|Beispiel: CV-Screening-Tool
|HR / Max Mustermann
|Automatisierte Vorauswahl von Bewerbungen
|Hochrisiko
|KI Solutions GmbH
|ML-Modell zur Textanalyse, Cloud-basiert
|Bewerbungsdaten, Lebensläufe, Kontaktdaten
|Ja
|Ja
|HR-Software, E-Mail
|Information der Bewerbenden, Dokumentation der Entscheidungslogik
|Zugriffskontrolle, Verschlüsselung, Monitoring
|Betrieb
|01.03.2025
|-
|2
|...
|...
|...
|...
|...
|...
|...
|...
|...
|...
|...
|...
|...
|...
|}

== Erläuterungen zu den Spalten ==

* '''Nr.''': Laufende Nummer zur eindeutigen Identifikation.
* '''Bezeichnung des KI-Systems''': Name oder Bezeichnung des eingesetzten KI-Systems.
* '''Verantwortliche Person/Abteilung''': Zuständige Ansprechperson oder Organisationseinheit.
* '''Zweck und Einsatzbereich''': Beschreibung, wofür und in welchem Kontext das KI-System eingesetzt wird.
* '''Risikokategorie (nach EU-KI-VO)''': Einordnung als „minimales Risiko“, „begrenztes Risiko“, „hohes Risiko“ oder „verboten“.
* '''Hersteller/Anbieter''': Name des Herstellers oder Anbieters des KI-Systems.
* '''Technische Beschreibung''': Kurze technische Übersicht (z.B. ML-Modelltyp, Cloud/On-Premises, verwendete Frameworks).
* '''Verwendete Datenarten''': Übersicht der für das Training und den Betrieb genutzten Daten (z.B. personenbezogene Daten, Bilddaten, Textdaten).
* '''Personenbezug der Daten''': Gibt an, ob personenbezogene Daten verarbeitet werden.
* '''Datenschutzfolgeabschätzung erforderlich (ja/nein)''': Angabe, ob eine DSFA nach DSGVO notwendig ist.
* '''Schnittstellen zu anderen Systemen''': Beschreibung der angebundenen IT-Systeme oder externen Schnittstellen.
* '''Maßnahmen zur Transparenz und Nachvollziehbarkeit''': Dokumentierte Maßnahmen zur Erfüllung von Transparenzpflichten (z.B. Nutzerinformation, Protokollierung, Erklärbarkeit).
* '''Maßnahmen zur IT-Sicherheit''': Übersicht der implementierten Sicherheitsmaßnahmen (z.B. Zugriffskontrolle, Verschlüsselung, Monitoring).
* '''Status (Pilot/Betrieb/Stillgelegt)''': Aktueller Lebenszyklusstatus des KI-Systems.
* '''Letzte Überprüfung''': Datum der letzten Überprüfung/Aktualisierung der Angaben.

'''Hinweis:'''

Das KI-Register sollte regelmäßig gepflegt, bei Änderungen aktualisiert und im Rahmen von Audits oder auf Anforderung der Aufsichtsbehörden vorgelegt werden können. Bei Systemen mit hohem Risiko empfiehlt sich eine engmaschige Überprüfung und Dokumentation.
Bei Bedarf kann das Register um weitere Spalten, z.B. für ethische Bewertungen, Lieferantenbewertungen oder spezifische Compliance-Anforderungen, erweitert werden.
[[Kategorie:Mustervorlage]]
[[Kategorie:KI]]

Willkommen im ISMS-Ratgeber WiKi

2026-03-28T13:20:26Z

Dirk:

{{#seo:
|title=ISMS-Ratgeber WiKi - Leitfaden für Informationssicherheit und Datenschutz
|description=Das ISMS-Ratgeber-Wiki bietet umfassende Informationen, Tools und Anleitungen zu Informationssicherheit, Datenschutz, BSI IT-Grundschutz ISO 27001 und anderen Standards.
}}{{SHORTDESC:Das freie ISMS-Ratgeber Wiki für Informationssicherheit und Datenschutz}}
Das ISMS-Ratgeber Wiki bietet umfassende Informationen und Ressourcen für den Aufbau eines Informationssicherheits-Managementsystems (ISMS). Es hilft, die Anforderungen von ISMS-Standards wie dem BSI IT-Grundschutz oder ISO/IEC 27001 zu erfüllen. Das Wiki stellt praxisnahe Informationen, Vorlagen und Leitfäden zur Verfügung, die die tägliche Arbeit unterstützen und den Einführungsprozess effizienter gestalten, da auf erprobte Methoden und dokumentierte Best Practices zugegriffen werden kann. Dies erleichtert die Erstellung, Verwaltung und kontinuierliche Verbesserung der Sicherheitsprozesse in der Organisation.

Das WiKi richtet sich an IT-Sicherheitsbeauftragte, Sicherheitsmanager und IT-Verantwortliche. Das WiKi ist öffentlich lesbar, die Inhalte sind frei nutzbar. Das Erstellen und Bearbeiten von Artikeln erfordert jedoch eine Registrierung als Benutzer. Jeder ist eingeladen, aktiv an den Inhalten mitzuarbeiten, eine gewisse Fachkompetenz sollte jedoch vorhanden sein, um die Qualität der Inhalte zu gewährleisten.

Für die organisationsübergreifende Zusammenarbeit und den gemeinsamen Austausch gibt es ein Forum auf Basis von HumHub. Unter [https://humhub.isms-ratgeber.info humhub.isms-ratgeber.info] stehen Foren/Workspaces zu verschiedenen Themen zum Austausch zur Verfügung. Die Registrierung ist wie hier im WiKi kostenlos.<br>
{| width="100%"
|-

|style="vertical-align:top" |

<h2 {{MainpageTopBox}}>
Für Einsteiger
</h2>
<div {{MainpageMidBox}}>
Informationen für Einsteiger und Anfänger.
*[[ISMS-Einführung|Einführung: Was ist ein ISMS?]]
*[[ISMS-Ratgeber-WiKi|Über das ISMS-Ratgeber Wiki]]
*[[ISMS-Ratgeber Anleitung|Anleitung zur Nutzung des ISMS-Ratgeber Wiki]]
*[[Mustervorlagen|Nutzung der Mustervorlagen]]
*[[Sicherheitsprojekte|Durchführung eines Sicherheitsprojekts]]
*[[QuickCheck|Ein QuickCheck zum Stand der Informationssicherheit]]
*[[Abkürzungen|Glossar]]
*[[Hilfe|allgemeine Wiki Hilfe]]
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>

<h2 {{MainpageTopBox}}>
Grundlagenartikel
</h2>
<div {{MainpageMidBox}}>
Grundlagenartikel mit ausführlichen Hintergrundinformationen zu bestimmten Themen und allgemeine Artikel.
*[[ISMS_Step_by_Step|Aufbau eines ISMS Step by Step (KMU)]]
*[[Geschäftsprozesse]]
*[[Dokumentenerstellung|Hilfen zur Dokumentenerstellung]]
*[[Managementbericht|Erstellen eines Managementberichts]]
*[[Betriebsdokumentation|Hilfen für Betriebsdokumentation]]
*[[Reifegradmodell|Erstellen eines Reifegradmodells]]
*[[KPIs|Key Performance Indicators (KPIs)]]
*[[Authentisierung|Methoden zur Authentisierung]]
*[[Klassifizierung|Klassifizierung von Informationen (Schutzstufen)]]
*[[Normen und Standards|Normen und Standards rund um das ISMS]]
*[[Bildkampagne|Sensibilisierung mit Bildkampagnen]]
*[[Online Prüftools|Liste von Online-Prüftools]]
*[[Referenzdokumente|Erforderliche Referenzdokument für Zertifizierungen]]
*[[ISO27001 vs. IT-Grundschutz|Vergleich ISO27001 und IT-Grundschutz]]
*[[Geheimschutz|Was ist Geheimschutz?]]
*[[Datenvernichtung|Übersicht und Normen zur Datenvernichtung]]
*[[Datenlöschung|Übersicht zur sicheren Datenlöschung]]
*[[Schutzbedarf|Vorgehen zur Schutzbedarfsfeststellung]]
*[[Dokumentenmanagement|Einführung in das Dokumentenmanagement]]
*[[Protokollierung|Einführung in die Protokollierung (Logging)]]
*[[Benutzer und Rechteverwaltung|Benutzer und Rechteverwaltung]]
*[[Cloudnutzung|Grundlagen zur Cloudnutzung]]
*[[VoIP|Voice over IP - Grundlagen, Risiken & Best Practices]]
*[[Container|Sicherheitsaspekte der Containerisierung]]
*[[Homeoffice und mobiles Arbeiten|Homeoffice und mobiles Arbeiten]]
*[[Risikomanagement|Einführung in das Risikomanagement]]
*[[Gebäudeinfrastruktur|Grundlagen sicherer Gebäudinfrastruktur]]
*[[Notfallmanagement]]
*[[Datensicherung SaaS|Datensicherung bei SaaS-Anwendungen]]
*[[Lieferkettensicherheit|Sicherheit von Lieferketten]]
*[[BSI Standard 200-3|''Risikomanagement nach BSI Standard 200-3'']]⚠️
*[[GS-Zertifizierungsaudit|Vorbereitung einer Zertifizierung auf Basis von IT-Grundschutz]]
*[[Social Media|Einsatz von Social Media im Unternehmen]]
*[[EU AI Act|EU AI Act: ISMS-Integration, Risiken & Umsetzung]]
*[[KI-Nutzung|Chancen und Risiken von KI]]
*[[Industrielle IT|Grundlagen & Sicherheitsaspekte Industrieller IT]]
*[[Bücher und Links|Informative Bücher und Links]]
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>

<h2 {{MainpageTopBox}}>
Kurzartikel
</h2>
<div {{MainpageMidBox}}>
Kurze Artikel und Beschreibungen zu nur einem Stichwort.
*[[ISO 27001]]
*[[IT-Grundschutz]]
*[[Grundschutz++]]
*[[Grundschutz ToDo MindMap|IT-Grundschutz ToDo MindMap]]⚠️
*[[Cybersecurity]]
*[[Security by Design]]
*[[Threat Intelligence]]
*[[APT|Advanced Persistent Threat (APT)]]
*[[Awareness|Was ist mit Awareness?]]
*[[Rechtsgrundlagen]]
*[[Datenschutz]]
*[[Datenschutzbeauftragte]]
*[[TOMs]]
*[[VVT|Verzeichnis von Verarbeitungstätigkeiten (VVT)]]
*[[AVV|Auftragsverarbeitungsvertrag (AVV)]]
*[[DSFA|Datenschutz-Folgenabschätzung (DSFA)]]
*[[Informationssicherheitsbeauftragte]]
*[[IS-Management-Team]]
*[[Krisenkommunikation]]
*[[Krisenprävention]]
*[[Krisenstab]]
*[[Notfallbeauftragte]]
*[[Verfügbarkeit]]
*[[Zero Trust]]
*[[Threat Intelligence Ansatz|Umsetzung von Threat Intelligence]]
*[[Riskoanalyse]]
*[[BYOD|Bring Your Own Device (BYOD)]]
*[[SOC|Security Operations Center (SOC)]]
*[[Common_Criteria|Common Criteria oder (CC)]]
*[[IT-Forensik]]
*[[Zusätzliche Gefährdungen|Zusätzliche/spezifische Gefährdungen]]
*[[Nebenwirkungen|Risiken und Nebenwirkungen]]
*[[ISMS-Tools|ISMS-Tool Vergleich]]
*[[Quantenresistente Verschlüsselung]]
*[[Automatisierung|Automatisierung in der IT-Sicherheit]]
*[[Datenbias|Datenbias - Datenverzerrung managen]]
*[[KI Cybersicherheit|KI in der Cybersicherheit]]
*[[Webservices]]
*[[Multi-Cloud|Herausforderungen in Multi-Cloud-Umgebungen]]
*[[Shared Responsibility Model|Shared Responsibility Model]]
*[[Sicherheitsframework]]
*[[Passkey]]
*[[SOAR|Security Orchestration, Automation, and Response (SOAR)]]
*[[Meldepflichten|''Meldepflichten bei IT-Sicherheitsvorfällen'']]⚠️
*[[Schulungskonzepte|''Schulungskonzepte'']]⚠️
*[[DIN SPEC 27076|DIN SPEC 27076: Beratungsnorm zum Cyber-Risiko für KKU]]
*[[CRC|Cyber-Risiko-Check (CRC)]]
*[[C5|C5 (Cloud Computing Compliance Criteria Catalogue)]]
*[[CIS|CIS Controls (Center for Internet Security Controls)]]
*[[TISAX|TISAX / VDA-ISA]]
*[[OSCAL|OSCAL (Open Security Controls Assessment Language)]]
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>


| width="50%" style="vertical-align:top" |
<h2 {{MainpageTopBox}}>
Erweiterte Suche
</h2>
<div {{MainpageMidBox}}>
Gib deine Suchbegriffe ein. Auf der folgenden Ergebnisseite kann die Suche weiter spezifiziert und eingegrenzt werden.
<inputbox>
type=search
placeholder=Suche...
width=27
break=yes
buttonlabel= Exakte Suche
searchbuttonlabel= Volltextsuche
</inputbox>
</div>

<h2 {{MainpageTopBox}}>
Mustervorlagen für Richtlinien
</h2>
<div {{MainpageMidBox}}>
Die generischen [[Mustervorlagen]] können als Grundlage für die Erstellung eigener Dokumente verwendet werden. Inhalte und Formulierungen müssen an die eigene Organisation angepasst oder ergänzt werden. Beachte hierzu auch den Artikel zur [[Mustervorlagen|Nutzung der Mustervorlagen]].
*[[Informationssicherheitsleitlinie|Leitlinie zur Informationssicherheit]]
*[[IS-Strategie‎‎|Strategie zur Informatinssicherheit]]
*[[Datenschutzleitlinie|Leitlinie zum Datenschutz]]
*[[RiLi-Dokumentenlenkung|Richtlinie zur Lenkung von Dokumenten]]
*[[RiLi-InterneAuditierung|Richtlinie zur internen ISMS-Auditierung]]
*[[RiLi-KVP|Richtlinie zur Lenkung von Korrektur- und Vorbeugungsmaßnahmen]]
*[[RiLi-Sicherheitsvorfallmanagement|Richtlinie Sicherheitsvorfallmanagement]]
*[[RiLi-Ausnahmemanagement|Richtlinie zum Management von Ausnahmen und Abweichungen]]
*[[RiLi-Risikoanalyse|Richtlinie zur Risikoanalyse]]
*[[RiLi-Mitarbeitende|Richtlinien zur Sensibilisierung der Mitarbeitenden]]
*[[RiLi-Sensibilisierung|Richtlinie Sensibilisierung zur Informationssicherheit]]
*[[RiLi-Passworte|Passwort Richtlinie]]
*[[RiLi-Authentifizierung|Richtlinie Authentisierung (passkey-Richtlinie)]]
*[[RiLi-Freigabe|Freigaberichtlinie für Hard- und Software]]
*[[RiLi-Protokollierung|Protokollierungsrichtlinie]]
*[[RiLi-Cloudnutzung|Richtlinie zur Nutzung von Cloud-Diensten]]
*[[RiLi-BYOD|BYOD-Richtlinie – Sichere private Geräte im Unternehmensnetz]]
*[[RiLi-Schadsoftware|Richtlinie Schadsoftware]]
*[[RiLi-Schwachstellenmanagement|Richtlinie Schwachstellenmanagement]]
*[[RiLi-Notfallmanagement (BCM)|Richtlinie Notfallmanagement (BCM)]]
*[[RiLi-Gebäude und Räume|''Richtlinie zu Gebäuden und Räumen'']]⚠️
*[[RiLi-Netzwerkmanagement|''Richtlinie Netzwerkmanagement'']]⚠️
*[[RiLi-Netzwerkmanagement (ZT)|''Richtlinie Netzwerkmanagement für Zero Trust'']]⚠️
*[[RiLi-Servermanagement|''Richtlinie Servermanagement'']]⚠️
*[[RiLi-Webservices|Richtlinie sicherer Betrieb von Webservices]]
*[[RiLi-Clientmanagement|Richtlinie zum Client-Management]]
*[[RiLi-VoIP-Einsatz|Richtlinie zum VoIP-Einsatz]]
*[[RiLi-Fernzugriff|Richtlinie Fernzugriff und Fernwartung]]
*[[RiLi-KI-Einsatz|Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)]]
*[[RiLi-Industrielle_IT|''Richtlinie für industrielle Steuerungs- und Automatisierungssysteme'']]⚠️
*[[RiLi-Lieferkettensicherheit|Richtlinie zur Lieferkettensicherheit]]⚠️
*[[RiLi-Informationssicherheit KKU|Richtlinie zur Informationssicherheit für KKU (nach DIN SPEC 27076)]]
<hr>
*[[Strukturanalyse|Muster für eine IT-Strukturanalyse]]
*[[Betriebshandbuch|Muster für ein Betriebshandbuch]]
*[[Notfallhandbuch|Muster für ein Notfallhandbuch]]
*[[Vertraulichkeitserklärung|Muster für eine Vertraulichkeitserklärung]]
*[[Fernzugriffsvereinbarung‎‎|Muster für eine Fernzugriffsvereinbarung]]
*[[Erklärung für mobiles Arbeiten|Muster Erklärung für mobiles Arbeiten]]
*[[BYOD-Vereinbarung|Muster-Vereinbarung für BYOD]]
*[[KI-Register|Vorlage für ein rechtskonformes KI-Register]]
*[[Business Impact Analyse (BIA)|''Muster einer Business Impact Analyse (BIA)'']]⚠️
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>

<h2 {{MainpageTopBox}}>
Leitfäden
</h2>
<div {{MainpageMidBox}}>
Leitfäden als Anleitungen für Anwender, zur sensibilisieren für bestimmte Themen und praktische Handlungsempfehlungen.
*[[LF-Homeoffice|Leitfaden sicher im Homeoffice]]
*[[LF-Basistestat Hochschulen|Leitfaden Basistestat Hochschulen]]
*[[LF-Arbeiten im Ausland|Leitfaden Arbeiten im Ausland]]
*[[LF-Sicher_arbeiten|Leitfaden sicheres Arbeiten]]
*[[LF-Sicher_unterwegs|Leitfaden sicher unterwegs]]
*[[LF-KI-Chatbots|Leitfaden zur Nutzung von KI-Systemen]]
*[[LF-Modellierung|Leitfaden Gruppierung und Modellierung]]
*[[LF-Grundschutzcheck|Leitfaden Grundschutzcheck]]
*[[LF-Realisierungsplan|Leitfaden Realisierungsplan/Risikobehandlungsplan]]
</div>

<h2 {{MainpageTopBox}}>
Muster-Betriebskonzepte
</h2>
<div {{MainpageMidBox}}>
Mustervorlagen für Betriebskonzepte zu Standardthemen.
*[[BK-Verinice|Betriebskonzept verinice (Einzelplatz)]]
*[[BK-Missbrauchskontakt|Betriebskonzept Missbrauchskontakt]]
*[[BK-Windows Server|''Betriebskonzept Windows-Server'']]⚠️
*[[BK-Linux Server|''Betriebskonzept Linux-Server'']]⚠️
*[[BK-Windows Client|''Betriebskonzept für Windows-Clients'']]⚠️
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>

<h2 {{MainpageTopBox}}>
Templates und Vorlagen
</h2>
<div {{MainpageMidBox}}>
Templates sind Dokumentvorlagen (in den Formaten Word, Write(LibreOffice) und MediaWiki), die für eigene Dokumente verwendet werden können. Sie enthalten eine grobe, generische Inhaltsstruktur für den jeweiligen Dokumententyp sowie Felder für die notwendigen Metadaten zur Steuerung des Dokuments.
*[[WikiTemplateArtikel]]
*[[WikiTemplateKurzartikel]]
*[[WikiTemplateRichtlinie]]⚠️
*[[WikiTemplateBetriebskonzept]]⚠️
*[[WordTemplateRichtlinie]]⚠️
*[[WordTemplateBetriebskonzept]]⚠️
</div>
<small>⚠️''Artikel noch im Entwurf /unvollständig''</small>

<h2 {{MainpageTopBox}}>
Themenschwerpunkte und Pfade
</h2>
<div {{MainpageMidBox}}>
Die folgenden Seiten dienen als Einstieg in die Themenschwerpunkte und bieten geführte Wege durch die Themen. (Noch nicht aktiv!)
*[[Dummy|''Einführung und Aufbau eines ISMS'']]⚠️
*[[KMU_Startseite|''Startseite für KMU, Handwerk und Freiberufler'']]⚠️
*[[Dummy|''Durchführung einer Risikoanalyse'']]⚠️
*[[Dummy|''Einführung und Aufbau eines Notfallmanagements'']]⚠️
*[[Dummy|''Weg zur Zertifizierung (BSI IT-Grundschutz)'']]⚠️
*[[Dummy|''Weg zur Zertifizierung (ISO 27001 nativ)'']]⚠️
*[[Datenschutz Umsetzung|Praktische Umsetzung von Datenschutz]]
*[[KI_Startseite|Einführung zu sinnvollen Regelungen für den KI-Einsatz]]
*[[Grundschutz++ Einführung und Aufbau|'''Einführung und Anleitung zum BSI Grundschutz++''']]
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>
|}


{| width="100%"
|-
|style="vertical-align:top" |
<h2 {{MainpageTopBox}}>
<center>Allgemeine Hinweise</center>
</h2>
<div {{MainpageMidBox}}>
Artikel, die der Kategorie "[[:Kategorie:Entwurf|Entwurf]]" (siehe Fußzeile des Dokuments) zugeordnet sind, sind noch unvollständig oder können noch Fehler enthalten.
Auch vollständig ausgearbeitete Dokumente sind nur Formulierungsvorschläge. Alle Musterdokumente müssen an die individuellen Gegebenheiten der Organisation angepasst werden.
</div>
|}
__KEIN_INHALTSVERZEICHNIS__
__ABSCHNITTE_NICHT_BEARBEITEN__
__INDEXIEREN__

KI Startseite

2026-03-28T12:15:47Z

Dirk:

{{Vorlage:Entwurf}}
{{#seo:
|title=KI-Einsatz: ISMS-integration, EU AI Act, DSGVO, BSI Grundschutz
|keywords=KI-Einsatz, EU AI Act, ISO 27001, BSI IT-Grundschutz, DSGVO KI, KI-Risikomanagement, Informationssicherheit KI, Datenschutz KI
|description=KI in Unternehmen & Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.}}
{{SHORTDESC:Einführung zu sinnvollen Regelungen für den KI-Einsatz}}''KI-Einsatz in Unternehmen und Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.''

== Einleitung ==
Der Einsatz von Künstlicher Intelligenz (KI) in Unternehmen und Behörden gewinnt rasant an Bedeutung und stellt Informationssicherheits-Managementsysteme (ISMS) vor neue Herausforderungen. KI-Systeme verarbeiten oft personenbezogene Daten, treffen automatisierte Entscheidungen und erfordern eine nahtlose Integration in bestehende Standards wie ISO/IEC 27001 sowie BSI Grundschutz. Der EU AI Act (seit August 2024 rechtskräftig) etabliert einen risikobasierten Ansatz, der mit DSGVO und BDSG kompatibel ist und spezifische Anforderungen an Transparenz, Robustheit und Nachvollziehbarkeit stellt.

Für Behörden gelten zusätzlich öffentlich-rechtliche Bindungen (z.B. Grundrechte Art. 1–3 GG), während Unternehmen wirtschaftliche Risiken wie Vendor Lock-in oder Haftungsstreitigkeiten prüfen müssen. Dieser Artikel fasst rechtliche, datenschutzrechtliche, sicherheitstechnische und organisatorische Belange zusammen und verweist auf vertiefende Inhalte im Wiki sowie externe Quellen.

'''Relevanz für ISMS'''

KI-Einsatz beeinflusst die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) und erfordert [[Zusätzliche Gefährdungen|Ergänzungen]] der verwendeten Risikokataloge wie z.B. den BSI G0-Katalog. Ziel ist eine risikobasierte Implementierung des KI-Einsatzes.

== Rechtlicher Rahmen ==

* '''EU AI Act''': Risikobasierte Klassifikation (verboten, hochrisiko, geringes Risiko, GPAI). Zeitlicher Fahrplan (Verbote ab 2025, Hochrisiko ab 2026/2027). Anforderungen an Dokumentation, Konformität und Bußgelder.
* '''Nationale Regelungen''': DSGVO-Integration (Art. 10 KI-VO für biometrische Daten), BDSG, öffentlich-rechtliche Sonderbindungen (GG Art. 1–3) für Behörden.
* '''Sektorale Vorgaben''': Verwaltungsrecht, hessische/länderspezifische Initiativen für öffentlichen Sektor.

=== EU AI Act ===
Der EU AI Act klassifiziert KI-Systeme in vier Risikostufen:

* '''Unzulässig''' (z. B. Social Scoring, biometrische Echtzeit-Identifikation in öffentlichen Räumen) – Verbot ab Februar 2025.
* '''Hochrisiko''' (z. B. HR, Kreditvergabe, kritische Infrastruktur) – Konformitätsbewertung, Dokumentationspflichten und menschliche Aufsicht ab 2026/2027.
* '''Geringes Risiko''' – Transparenzpflichten (z. B. Chatbots).
* '''GPAI (General Purpose AI)''' – Risikoanalyse und technische Dokumentation für Modelle wie GPT-Varianten.

Bußgelder bis 35 Mio. € oder 7% Umsatz. Verantwortung liegt primär beim Provider, sekundär beim Deployer.

'''Weiterführende Informationen:'''

* [[EU AI Act|Wiki: EU AI Act]]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32024R1689 EU AI Act Volltext]

=== Nationale Regelungen ===

* '''Deutschland''': Ergänzungen durch BDSG (§ 22 automatisierte Entscheidungen), KI-Strategie der Bundesregierung (2020/aktualisiert 2025). Behörden müssen öffentlich-rechtliche Prinzipien (Rechtsstaatlichkeit, Verhältnismäßigkeit) wahren.
* '''Länderspezifisch''': Hessische KI-Verordnung, bayrische Orientierungshilfen für öffentliche Verwaltung.
* '''Sektoral''': Finanzsektor (BaFin-Marco), Gesundheitswesen (DiGA-Verordnung).

'''Weiterführende Informationen:'''

=== Übergangsregelungen und Neuklassifizierung ===
KI-Systeme müssen bei wesentlichen Änderungen neu klassifiziert werden. Bestehende Systeme bis 2027.

== Datenschutzrechtliche Aspekte ==

=== DSGVO-Konformität ===
KI-Trainingsdaten unterliegen Art. 5 DSGVO (Rechtsmäßigkeit, Zweckbindung). Bei biometrischen Daten: Art. 10 KI-VO (Verbot biometrische Kategorisierung). Datenschutz-Folgenabschätzung (DSFA, Art. 35) obligatorisch für Hochrisiko-Anwendungen.

'''Kernpflichten'''

* '''Trainingsdaten''': Bereinigung sensibler Daten, Pseudonymisierung, Löschung nach Zweck (Art. 17).
* '''Outputs''': Transparenz bei automatisierter Entscheidungsfindung (Art. 22), Recht auf Erklärung.
* '''AVV (Auftragsverarbeitung)''': Cloud-KI-Provider als Auftragsverarbeiter prüfen.

=== Orientierungshilfen ===

* '''Datenschutzkonferenz (DSK)''': Leitfaden „Künstliche Intelligenz und Datenschutz“ – Checkliste für Datensparsamkeit und Rechenschaftspflicht.
* '''BayLDA/LfDI''': Praktische Hinweise zu Shadow-KI und ChatGPT-Nutzung in Behörden.

=== Betroffenenrechte und Transparenz ===
Benutzende müssen über KI-Einsatz informiert werden (Art. 13/14). Erweiterte Informationspflichten bei GPAI: Modellkarte offenlegen. Bias-Tests dokumentieren, um Diskriminierungsverbot (Art. 21 GG) zu wahren.

'''Praktische Umsetzung'''
{| class="wikitable"
!Aspekt
!Maßnahme
!Rechtsgrundlage
|-
|DSFA
|Vor KI-Einsatz durchführen
|Art. 35 DSGVO
|-
|Rechteauskunft
|KI-spezifische Vorlage
|Art. 15 DSGVO
|-
|Löschung
|Trainingsdaten entfernen
|Art. 17 DSGVO
|}
'''Weiterführende Informationen:'''

* [https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf DSK: Orientierungshilfe zu datenschutzrechtlichen Besonderheiten generativer KI-Systeme mit RAG-Methode]
* [https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf DSK: Orientierungshilfe zu empfohlenen technischen und organisatorischen Maßnahmen bei der Entwicklung und beim Betrieb von KI-Systemen]

== Sicherheitsaspekte (ISMS-Integration) ==
KI-Einsatz erfordert eine Erweiterung des ISMS um spezifische Gefährdungen, die die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) bedrohen und über den BSI IT-Grundschutz G0-Katalog hinausgehen. Nach BSI Standard 200-3 müssen diese in der Risikoanalyse bewertet und mit Maßnahmen aus ISO 27001 Anhang A (z. B. A.8.25 für sichere Entwicklung) kontrolliert werden.

=== Gefährdungskatalog-Ergänzungen ===
KI-spezifische Risiken wie folgt klassifiziert (CIA-Analyse):

* '''Prompt Injections''': Manipulation von Eingaben zu Large Language Models (hoch I/C).
* '''Data Poisoning''': Vergiftung von Trainingsdaten (hoch I, mittel A).
* '''Modelllecks''': Training Data Leakage oder IP-Exfiltration (hoch C).
* '''Shadow-KI''': Unkontrollierte Nutzung privater Tools (mittel C/I/A).
* '''Black-Box-Effekte''': Mangelnde Nachvollziehbarkeit (hoch I/A).

'''Integration in BSI-Module'''
{| class="wikitable"
!Gefährdung
!BSI G0-Modul
!Ergänzungsmaßnahme
|-
|Data Poisoning
|SYS.1.2 Datenintegrität
|Daten-Sanitization, Validierung
|-
|Modelllecks
|NET.4.1 Zugriffssteuerung
|API-Rate-Limiting, Differential Privacy
|-
|Shadow-KI
|ORG.2.1 Sicherheitsrichtlinien
|KI-Nutzungsrichtlinie (ISO A.5.1)
|}

=== ISMS-Maßnahmen und Standards ===
* '''BSI KI-Kriterienkatalog (2025)''': Sicherheitsniveaus (Low/Medium/High) für generative KI, mit Tests auf Jailbreaks und Bias.
* '''ISO 27001 Anhang A''': A.14.2.7 Sichere Entwicklung von KI, A.12.6 Vulnerability-Management für Modelle.
* '''Risikobewertung''': Erweiterte Gefährdungsanalyse nach BSI 200-3, inklusive Supply-Chain-Risiken bei Cloud-KI-Providern.

'''Weiterführende Informationen:'''

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KI/Kriterienkatalog_KI-Modelle_Bundesverwaltung.html BSI KI-Kriterienkatalog 2025.]
* [[Zusätzliche Gefährdungen|Wiki: Zusätzliche Gefährdungen]]

== Technische Aspekte ==
Technische Umsetzung von KI muss Robustheit, Nachvollziehbarkeit und Datensicherheit gewährleisten, um EU AI Act-Anforderungen (z. B. Art. 15 für Hochrisiko) und ISMS-Ziele zu erfüllen. Der Fokus liegt auf dem gesamten KI-Lebenszyklus.

=== Implementierungsprinzipien ===

* '''Daten-Governance''': Saubere Trainingsdaten (Preprocessing, Anonymisierung), RAG (Retrieval-Augmented Generation) statt reinem Fine-Tuning zur Vermeidung von Halluzinationen.
* '''Modellsicherheit''': Hardening-Techniken wie Adversarial Training, Modellkardinalität (Input/Output-Beschränkungen).
* '''Nachvollziehbarkeit (XAI)''': SHAP für globale Feature-Importance, LIME für lokale Erklärungen einzelner Vorhersagen – essenziell für Art. 22 DSGVO.

=== Lebenszyklus-Management ===
'''KI-System-Phasen und Sicherheitskontrollen'''
{| class="wikitable"
!Phase
!Technische Maßnahmen
!ISMS-Verknüpfung
|-
|Auswahl/Training
|Datenvalidierung, Secure MPC
|A.8.25 Entwicklung
|-
|Deployment
|Sandboxing, Human-in-the-Loop
|A.12.4 Monitoring
|-
|Betrieb
|Continuous Model Monitoring (Drift/Bias)
|A.12.6 Vulnerabilities
|-
|Decommissioning
|Modelllöschung, Audit-Logs
|A.18.1 Compliance
|}

=== Hochrisiko-Anwendungen ===

* '''Sektoren''': HR (Bias-Prüfung), Gesundheitswesen (FDA/DiGA-konform), kritische Infrastruktur (real-time Robustheit).
* '''Technische Standards''': ONNX für Modell-Portabilität, TensorFlow Privacy für Federated Learning.

'''Praktische Umsetzung'''

* '''Tools''': MLflow für Lifecycle-Tracking, Adversarial Robustness Toolbox (ART) für Angriffstests.
* '''Cloud-KI''': AWS SageMaker oder Azure ML mit integrierten Security-Features prüfen (AVV-pflichtig).

'''Verweise'''

* EU AI Act Technische Dokumentation
* BSI Secure AI Guidelines.

== Governance und Organisation ==
Eine effektive KI-Governance stellt sicher, dass KI-Einsatz mit ISMS-Zielen (ISO 27001, BSI IT-Grundschutz) übereinstimmt und EU AI Act-Anforderungen erfüllt. Sie umfasst organisatorische Strukturen, Prozesse und Verantwortlichkeiten, um Risiken wie Shadow-KI oder Bias zu minimieren. Die Geschäftsleitung trägt gemäß ISO 27001 Abschnitt 5.1 die oberste Verantwortung und muss KI-spezifische Richtlinien (A.5.1) etablieren.

=== KI-Governancestruktur ===

* '''KI-Steuerungsgremium''': Interdisziplinäres Gremium (IT-Sicherheit, Datenschutzbeauftragte, Rechtsabteilung, Fachabteilungen) für Risikobewertungen, Modellfreigaben und Audits. Regelmäßige Meetings (vierteljährlich) zur Überprüfung von KI-Projekten.

* '''Rollen und Verantwortlichkeiten''':<br>
{| class="wikitable"
!Rolle
!Aufgaben
!Rechtsgrundlage
|-
|KI-Provider (extern)
|Technische Dokumentation, Konformitätserklärung
|EU AI Act Art. 13
|-
|KI-Deployer (intern)
|Risikoanalyse, menschliche Aufsicht
|EU AI Act Art. 29
|-
|Datenschutzbeauftragte
|DSFA, Betroffenenrechte
|DSGVO Art. 39
|-
|ISMS-Leitung
|Integration in Risikomanagement
|ISO 27001 A.5.1
|}

* '''KI-Nutzungsrichtlinie''': Verbot privater KI-Tools (Shadow-KI), Pflicht zu genehmigten Modellen, Sanktionen bei Verstößen. Schulungspflicht für Mitarbeitende (KI-Literacy).

=== Prozesse und Workflows ===

* '''Risikobewertungsvorlage''': Vorlage für neue KI-Projekte mit CIA-Analyse, EU AI Act-Risikostufe und DSFA-Trigger. Workflow: Antrag → Gremium → Freigabe → Monitoring.
* '''Audit und Reporting''': Jährliche KI-Inventar (alle Systeme auflisten), Incident-Reporting für Bias-Vorfälle oder Modell-Drift. Integration in ISO 27001 Management Review (Abschnitt 9.3).
* '''Schulungen''': Obligatorische Einstiegsschulung zu KI-Risiken (2h), vertiefte für Entwickler (XAI, Secure Coding). Nachweis via LMS.

=== Besonderheiten für Behörden ===

* '''Grundrechtsschutz''': Zusätzliche Prüfung auf Verhältnismäßigkeit (GG Art. 1–3), Transparenz gegenüber Bürger:innen. Beliehene Unternehmen (z. B. Zeugnisstellen) fallen unter öffentlich-rechtliche Standards.
* '''Öffentliche Unternehmen''': Anpassung an Verwaltungsrecht (VwVfG § 35), Archivierungspflicht für KI-Entscheidungen.

'''Praktische Umsetzung'''

* '''Checkliste für KI-Projekte''':
*# Risikostufe bestimmen,
*# Provider prüfen,
*# DSFA durchführen,
*# Technische Dokumentation anlegen,
*# Monitoring einrichten.
* '''Vorlage''': KI-Risikobewertungstabelle (Excel) mit Spalten für Gefährdung, Wahrscheinlichkeit, Schaden, Maßnahmen.

'''Verweise'''

* Wiki: ISMS-Organisation
* ISO 27001:2022 Abschnitt 5 (Führung).

== Weiterführende Quellen ==

=== Primärquellen (Gesetze und Verordnungen) ===

* '''EU AI Act''': Volltext – Offizielle Übersetzung, Anhang mit Hochrisiko-Listen.
* '''DSGVO''': Art. 22, 35 – Automatisierte Entscheidungen, DSFA.
* '''BDSG''': § 22 – Automatisierte Entscheidungen im öffentlichen Recht.

=== Behörden und Standardisierungsgremien ===

* '''BSI''':
** KI-Kriterienkatalog 2025 – Testszenarien für generative KI.
** IT-Grundschutz Compendium – G0-Module.
* '''Datenschutzkonferenz (DSK)''': Leitfaden KI und Datenschutz – Praktische Checkliste.
* '''BayLDA''': KI & Datenschutz – Orientierung für Behörden.

=== Branchenverbände und Ratgeber ===

* '''IHK München''': Datenschutz & KI – Praktische Hinweise für KMU.
* '''Bitkom''': KI-Guide für Unternehmen – Best Practices.
* '''BaFin''': Marco für KI im Finanzsektor.

=== Technische Ressourcen ===

* '''XAI-Tools''': SHAP-Dokumentation, LIME – Open Source für Erklärbarkeit.
* '''Secure AI Frameworks''': Adversarial Robustness Toolbox – Tests auf Angriffe.

=== Wiki-interne Verweise ===

* [/wiki/Zusätzliche_Gefährdungen] – KI-spezifische Risiken.
* [/wiki/DSGVO_im_ISMS] – Datenschutz-Integration.
* [/wiki/BSI_Standard_200-3] – Risikoanalyse.

'''Hinweis''': Alle Links zum Stand März 2026 prüfen; bei Updates im Wiki protokollieren. Für Implementierungsvorlagen (Checklisten, Excel) ein separates Unterkapitel „Vorlagen" anlegen.
[[Kategorie:Artikel]]
[[Kategorie:KI]]

KI Startseite

2026-03-28T12:15:09Z

Dirk:

{{Vorlage:Entwurf}}
{{#seo:
|title=KI-Einsatz: ISMS-integration, EU AI Act, DSGVO, BSI Grundschutz
|keywords=KI-Einsatz, EU AI Act, ISO 27001, BSI IT-Grundschutz, DSGVO KI, KI-Risikomanagement, Informationssicherheit KI, Datenschutz KI
|description=KI in Unternehmen & Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.}}
{{SHORTDESC:Einführung zu sinnvollen Regelungen für den KI-Einsatz}}'''KI-Einsatz in Unternehmen und Behörden: Rechtliche, datenschutzrechtliche, sicherheitstechnische Leitfäden für ISO 27001, EU AI Act, BSI IT-Grundschutz. Risiken, Governance, Maßnahmen.'''

== Einleitung ==
Der Einsatz von Künstlicher Intelligenz (KI) in Unternehmen und Behörden gewinnt rasant an Bedeutung und stellt Informationssicherheits-Managementsysteme (ISMS) vor neue Herausforderungen. KI-Systeme verarbeiten oft personenbezogene Daten, treffen automatisierte Entscheidungen und erfordern eine nahtlose Integration in bestehende Standards wie ISO/IEC 27001 sowie BSI Grundschutz. Der EU AI Act (seit August 2024 rechtskräftig) etabliert einen risikobasierten Ansatz, der mit DSGVO und BDSG kompatibel ist und spezifische Anforderungen an Transparenz, Robustheit und Nachvollziehbarkeit stellt.

Für Behörden gelten zusätzlich öffentlich-rechtliche Bindungen (z.B. Grundrechte Art. 1–3 GG), während Unternehmen wirtschaftliche Risiken wie Vendor Lock-in oder Haftungsstreitigkeiten prüfen müssen. Dieser Artikel fasst rechtliche, datenschutzrechtliche, sicherheitstechnische und organisatorische Belange zusammen und verweist auf vertiefende Inhalte im Wiki sowie externe Quellen.

'''Relevanz für ISMS'''

KI-Einsatz beeinflusst die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) und erfordert [[Zusätzliche Gefährdungen|Ergänzungen]] der verwendeten Risikokataloge wie z.B. den BSI G0-Katalog. Ziel ist eine risikobasierte Implementierung des KI-Einsatzes.

== Rechtlicher Rahmen ==

* '''EU AI Act''': Risikobasierte Klassifikation (verboten, hochrisiko, geringes Risiko, GPAI). Zeitlicher Fahrplan (Verbote ab 2025, Hochrisiko ab 2026/2027). Anforderungen an Dokumentation, Konformität und Bußgelder.
* '''Nationale Regelungen''': DSGVO-Integration (Art. 10 KI-VO für biometrische Daten), BDSG, öffentlich-rechtliche Sonderbindungen (GG Art. 1–3) für Behörden.
* '''Sektorale Vorgaben''': Verwaltungsrecht, hessische/länderspezifische Initiativen für öffentlichen Sektor.

=== EU AI Act ===
Der EU AI Act klassifiziert KI-Systeme in vier Risikostufen:

* '''Unzulässig''' (z. B. Social Scoring, biometrische Echtzeit-Identifikation in öffentlichen Räumen) – Verbot ab Februar 2025.
* '''Hochrisiko''' (z. B. HR, Kreditvergabe, kritische Infrastruktur) – Konformitätsbewertung, Dokumentationspflichten und menschliche Aufsicht ab 2026/2027.
* '''Geringes Risiko''' – Transparenzpflichten (z. B. Chatbots).
* '''GPAI (General Purpose AI)''' – Risikoanalyse und technische Dokumentation für Modelle wie GPT-Varianten.

Bußgelder bis 35 Mio. € oder 7% Umsatz. Verantwortung liegt primär beim Provider, sekundär beim Deployer.

'''Weiterführende Informationen:'''

* [[EU AI Act|Wiki: EU AI Act]]
* [https://eur-lex.europa.eu/legal-content/DE/TXT/PDF/?uri=CELEX:32024R1689 EU AI Act Volltext]

=== Nationale Regelungen ===

* '''Deutschland''': Ergänzungen durch BDSG (§ 22 automatisierte Entscheidungen), KI-Strategie der Bundesregierung (2020/aktualisiert 2025). Behörden müssen öffentlich-rechtliche Prinzipien (Rechtsstaatlichkeit, Verhältnismäßigkeit) wahren.
* '''Länderspezifisch''': Hessische KI-Verordnung, bayrische Orientierungshilfen für öffentliche Verwaltung.
* '''Sektoral''': Finanzsektor (BaFin-Marco), Gesundheitswesen (DiGA-Verordnung).

'''Weiterführende Informationen:'''

=== Übergangsregelungen und Neuklassifizierung ===
KI-Systeme müssen bei wesentlichen Änderungen neu klassifiziert werden. Bestehende Systeme bis 2027.

== Datenschutzrechtliche Aspekte ==

=== DSGVO-Konformität ===
KI-Trainingsdaten unterliegen Art. 5 DSGVO (Rechtsmäßigkeit, Zweckbindung). Bei biometrischen Daten: Art. 10 KI-VO (Verbot biometrische Kategorisierung). Datenschutz-Folgenabschätzung (DSFA, Art. 35) obligatorisch für Hochrisiko-Anwendungen.

'''Kernpflichten'''

* '''Trainingsdaten''': Bereinigung sensibler Daten, Pseudonymisierung, Löschung nach Zweck (Art. 17).
* '''Outputs''': Transparenz bei automatisierter Entscheidungsfindung (Art. 22), Recht auf Erklärung.
* '''AVV (Auftragsverarbeitung)''': Cloud-KI-Provider als Auftragsverarbeiter prüfen.

=== Orientierungshilfen ===

* '''Datenschutzkonferenz (DSK)''': Leitfaden „Künstliche Intelligenz und Datenschutz“ – Checkliste für Datensparsamkeit und Rechenschaftspflicht.
* '''BayLDA/LfDI''': Praktische Hinweise zu Shadow-KI und ChatGPT-Nutzung in Behörden.

=== Betroffenenrechte und Transparenz ===
Benutzende müssen über KI-Einsatz informiert werden (Art. 13/14). Erweiterte Informationspflichten bei GPAI: Modellkarte offenlegen. Bias-Tests dokumentieren, um Diskriminierungsverbot (Art. 21 GG) zu wahren.

'''Praktische Umsetzung'''
{| class="wikitable"
!Aspekt
!Maßnahme
!Rechtsgrundlage
|-
|DSFA
|Vor KI-Einsatz durchführen
|Art. 35 DSGVO
|-
|Rechteauskunft
|KI-spezifische Vorlage
|Art. 15 DSGVO
|-
|Löschung
|Trainingsdaten entfernen
|Art. 17 DSGVO
|}
'''Weiterführende Informationen:'''

* [https://www.datenschutzkonferenz-online.de/media/oh/DSK_OH_RAG.pdf DSK: Orientierungshilfe zu datenschutzrechtlichen Besonderheiten generativer KI-Systeme mit RAG-Methode]
* [https://www.datenschutzkonferenz-online.de/media/oh/DSK-OH_KI-Systeme.pdf DSK: Orientierungshilfe zu empfohlenen technischen und organisatorischen Maßnahmen bei der Entwicklung und beim Betrieb von KI-Systemen]

== Sicherheitsaspekte (ISMS-Integration) ==
KI-Einsatz erfordert eine Erweiterung des ISMS um spezifische Gefährdungen, die die CIA-Triade (Vertraulichkeit, Integrität, Verfügbarkeit) bedrohen und über den BSI IT-Grundschutz G0-Katalog hinausgehen. Nach BSI Standard 200-3 müssen diese in der Risikoanalyse bewertet und mit Maßnahmen aus ISO 27001 Anhang A (z. B. A.8.25 für sichere Entwicklung) kontrolliert werden.

=== Gefährdungskatalog-Ergänzungen ===
KI-spezifische Risiken wie folgt klassifiziert (CIA-Analyse):

* '''Prompt Injections''': Manipulation von Eingaben zu Large Language Models (hoch I/C).
* '''Data Poisoning''': Vergiftung von Trainingsdaten (hoch I, mittel A).
* '''Modelllecks''': Training Data Leakage oder IP-Exfiltration (hoch C).
* '''Shadow-KI''': Unkontrollierte Nutzung privater Tools (mittel C/I/A).
* '''Black-Box-Effekte''': Mangelnde Nachvollziehbarkeit (hoch I/A).

'''Integration in BSI-Module'''
{| class="wikitable"
!Gefährdung
!BSI G0-Modul
!Ergänzungsmaßnahme
|-
|Data Poisoning
|SYS.1.2 Datenintegrität
|Daten-Sanitization, Validierung
|-
|Modelllecks
|NET.4.1 Zugriffssteuerung
|API-Rate-Limiting, Differential Privacy
|-
|Shadow-KI
|ORG.2.1 Sicherheitsrichtlinien
|KI-Nutzungsrichtlinie (ISO A.5.1)
|}

=== ISMS-Maßnahmen und Standards ===
* '''BSI KI-Kriterienkatalog (2025)''': Sicherheitsniveaus (Low/Medium/High) für generative KI, mit Tests auf Jailbreaks und Bias.
* '''ISO 27001 Anhang A''': A.14.2.7 Sichere Entwicklung von KI, A.12.6 Vulnerability-Management für Modelle.
* '''Risikobewertung''': Erweiterte Gefährdungsanalyse nach BSI 200-3, inklusive Supply-Chain-Risiken bei Cloud-KI-Providern.

'''Weiterführende Informationen:'''

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/KI/Kriterienkatalog_KI-Modelle_Bundesverwaltung.html BSI KI-Kriterienkatalog 2025.]
* [[Zusätzliche Gefährdungen|Wiki: Zusätzliche Gefährdungen]]

== Technische Aspekte ==
Technische Umsetzung von KI muss Robustheit, Nachvollziehbarkeit und Datensicherheit gewährleisten, um EU AI Act-Anforderungen (z. B. Art. 15 für Hochrisiko) und ISMS-Ziele zu erfüllen. Der Fokus liegt auf dem gesamten KI-Lebenszyklus.

=== Implementierungsprinzipien ===

* '''Daten-Governance''': Saubere Trainingsdaten (Preprocessing, Anonymisierung), RAG (Retrieval-Augmented Generation) statt reinem Fine-Tuning zur Vermeidung von Halluzinationen.
* '''Modellsicherheit''': Hardening-Techniken wie Adversarial Training, Modellkardinalität (Input/Output-Beschränkungen).
* '''Nachvollziehbarkeit (XAI)''': SHAP für globale Feature-Importance, LIME für lokale Erklärungen einzelner Vorhersagen – essenziell für Art. 22 DSGVO.

=== Lebenszyklus-Management ===
'''KI-System-Phasen und Sicherheitskontrollen'''
{| class="wikitable"
!Phase
!Technische Maßnahmen
!ISMS-Verknüpfung
|-
|Auswahl/Training
|Datenvalidierung, Secure MPC
|A.8.25 Entwicklung
|-
|Deployment
|Sandboxing, Human-in-the-Loop
|A.12.4 Monitoring
|-
|Betrieb
|Continuous Model Monitoring (Drift/Bias)
|A.12.6 Vulnerabilities
|-
|Decommissioning
|Modelllöschung, Audit-Logs
|A.18.1 Compliance
|}

=== Hochrisiko-Anwendungen ===

* '''Sektoren''': HR (Bias-Prüfung), Gesundheitswesen (FDA/DiGA-konform), kritische Infrastruktur (real-time Robustheit).
* '''Technische Standards''': ONNX für Modell-Portabilität, TensorFlow Privacy für Federated Learning.

'''Praktische Umsetzung'''

* '''Tools''': MLflow für Lifecycle-Tracking, Adversarial Robustness Toolbox (ART) für Angriffstests.
* '''Cloud-KI''': AWS SageMaker oder Azure ML mit integrierten Security-Features prüfen (AVV-pflichtig).

'''Verweise'''

* EU AI Act Technische Dokumentation
* BSI Secure AI Guidelines.

== Governance und Organisation ==
Eine effektive KI-Governance stellt sicher, dass KI-Einsatz mit ISMS-Zielen (ISO 27001, BSI IT-Grundschutz) übereinstimmt und EU AI Act-Anforderungen erfüllt. Sie umfasst organisatorische Strukturen, Prozesse und Verantwortlichkeiten, um Risiken wie Shadow-KI oder Bias zu minimieren. Die Geschäftsleitung trägt gemäß ISO 27001 Abschnitt 5.1 die oberste Verantwortung und muss KI-spezifische Richtlinien (A.5.1) etablieren.

=== KI-Governancestruktur ===

* '''KI-Steuerungsgremium''': Interdisziplinäres Gremium (IT-Sicherheit, Datenschutzbeauftragte, Rechtsabteilung, Fachabteilungen) für Risikobewertungen, Modellfreigaben und Audits. Regelmäßige Meetings (vierteljährlich) zur Überprüfung von KI-Projekten.

* '''Rollen und Verantwortlichkeiten''':<br>
{| class="wikitable"
!Rolle
!Aufgaben
!Rechtsgrundlage
|-
|KI-Provider (extern)
|Technische Dokumentation, Konformitätserklärung
|EU AI Act Art. 13
|-
|KI-Deployer (intern)
|Risikoanalyse, menschliche Aufsicht
|EU AI Act Art. 29
|-
|Datenschutzbeauftragte
|DSFA, Betroffenenrechte
|DSGVO Art. 39
|-
|ISMS-Leitung
|Integration in Risikomanagement
|ISO 27001 A.5.1
|}

* '''KI-Nutzungsrichtlinie''': Verbot privater KI-Tools (Shadow-KI), Pflicht zu genehmigten Modellen, Sanktionen bei Verstößen. Schulungspflicht für Mitarbeitende (KI-Literacy).

=== Prozesse und Workflows ===

* '''Risikobewertungsvorlage''': Vorlage für neue KI-Projekte mit CIA-Analyse, EU AI Act-Risikostufe und DSFA-Trigger. Workflow: Antrag → Gremium → Freigabe → Monitoring.
* '''Audit und Reporting''': Jährliche KI-Inventar (alle Systeme auflisten), Incident-Reporting für Bias-Vorfälle oder Modell-Drift. Integration in ISO 27001 Management Review (Abschnitt 9.3).
* '''Schulungen''': Obligatorische Einstiegsschulung zu KI-Risiken (2h), vertiefte für Entwickler (XAI, Secure Coding). Nachweis via LMS.

=== Besonderheiten für Behörden ===

* '''Grundrechtsschutz''': Zusätzliche Prüfung auf Verhältnismäßigkeit (GG Art. 1–3), Transparenz gegenüber Bürger:innen. Beliehene Unternehmen (z. B. Zeugnisstellen) fallen unter öffentlich-rechtliche Standards.
* '''Öffentliche Unternehmen''': Anpassung an Verwaltungsrecht (VwVfG § 35), Archivierungspflicht für KI-Entscheidungen.

'''Praktische Umsetzung'''

* '''Checkliste für KI-Projekte''':
*# Risikostufe bestimmen,
*# Provider prüfen,
*# DSFA durchführen,
*# Technische Dokumentation anlegen,
*# Monitoring einrichten.
* '''Vorlage''': KI-Risikobewertungstabelle (Excel) mit Spalten für Gefährdung, Wahrscheinlichkeit, Schaden, Maßnahmen.

'''Verweise'''

* Wiki: ISMS-Organisation
* ISO 27001:2022 Abschnitt 5 (Führung).

== Weiterführende Quellen ==

=== Primärquellen (Gesetze und Verordnungen) ===

* '''EU AI Act''': Volltext – Offizielle Übersetzung, Anhang mit Hochrisiko-Listen.
* '''DSGVO''': Art. 22, 35 – Automatisierte Entscheidungen, DSFA.
* '''BDSG''': § 22 – Automatisierte Entscheidungen im öffentlichen Recht.

=== Behörden und Standardisierungsgremien ===

* '''BSI''':
** KI-Kriterienkatalog 2025 – Testszenarien für generative KI.
** IT-Grundschutz Compendium – G0-Module.
* '''Datenschutzkonferenz (DSK)''': Leitfaden KI und Datenschutz – Praktische Checkliste.
* '''BayLDA''': KI & Datenschutz – Orientierung für Behörden.

=== Branchenverbände und Ratgeber ===

* '''IHK München''': Datenschutz & KI – Praktische Hinweise für KMU.
* '''Bitkom''': KI-Guide für Unternehmen – Best Practices.
* '''BaFin''': Marco für KI im Finanzsektor.

=== Technische Ressourcen ===

* '''XAI-Tools''': SHAP-Dokumentation, LIME – Open Source für Erklärbarkeit.
* '''Secure AI Frameworks''': Adversarial Robustness Toolbox – Tests auf Angriffe.

=== Wiki-interne Verweise ===

* [/wiki/Zusätzliche_Gefährdungen] – KI-spezifische Risiken.
* [/wiki/DSGVO_im_ISMS] – Datenschutz-Integration.
* [/wiki/BSI_Standard_200-3] – Risikoanalyse.

'''Hinweis''': Alle Links zum Stand März 2026 prüfen; bei Updates im Wiki protokollieren. Für Implementierungsvorlagen (Checklisten, Excel) ein separates Unterkapitel „Vorlagen" anlegen.
[[Kategorie:Artikel]]
[[Kategorie:KI]]

Kategorie:KI

2026-03-28T09:48:49Z

Dirk: Die Seite wurde neu angelegt: „Artikel und Mustervorlagen rund um das Thema KI-Einsatz“

Artikel und Mustervorlagen rund um das Thema KI-Einsatz

KI Startseite

2026-03-28T09:47:58Z

Dirk: Die Seite wurde neu angelegt: „{{Vorlage:Entwurf}} {{#seo: |title=Einführung zu sinnvollen Regelungen für den KI-Einsatz |keywords=word1,word2 |description=Kurzartikel zu ... }} {{SHORTDESC:Einführung zu sinnvollen Regelungen für den KI-Einsatz}} == Einleitung == == Überschrift 1 == == Überschrift 2 == == Fazit == Kategorie:Artikel Kategorie:KI“

{{Vorlage:Entwurf}}
{{#seo:
|title=Einführung zu sinnvollen Regelungen für den KI-Einsatz
|keywords=word1,word2
|description=Kurzartikel zu ...
}}
{{SHORTDESC:Einführung zu sinnvollen Regelungen für den KI-Einsatz}}

== Einleitung ==

== Überschrift 1 ==

== Überschrift 2 ==

== Fazit ==

[[Kategorie:Artikel]]
[[Kategorie:KI]]

Willkommen im ISMS-Ratgeber WiKi

2026-03-28T09:45:19Z

Dirk:

{{#seo:
|title=ISMS-Ratgeber WiKi - Leitfaden für Informationssicherheit und Datenschutz
|description=Das ISMS-Ratgeber-Wiki bietet umfassende Informationen, Tools und Anleitungen zu Informationssicherheit, Datenschutz, BSI IT-Grundschutz ISO 27001 und anderen Standards.
}}{{SHORTDESC:Das freie ISMS-Ratgeber Wiki für Informationssicherheit und Datenschutz}}
Das ISMS-Ratgeber Wiki bietet umfassende Informationen und Ressourcen für den Aufbau eines Informationssicherheits-Managementsystems (ISMS). Es hilft, die Anforderungen von ISMS-Standards wie dem BSI IT-Grundschutz oder ISO/IEC 27001 zu erfüllen. Das Wiki stellt praxisnahe Informationen, Vorlagen und Leitfäden zur Verfügung, die die tägliche Arbeit unterstützen und den Einführungsprozess effizienter gestalten, da auf erprobte Methoden und dokumentierte Best Practices zugegriffen werden kann. Dies erleichtert die Erstellung, Verwaltung und kontinuierliche Verbesserung der Sicherheitsprozesse in der Organisation.

Das WiKi richtet sich an IT-Sicherheitsbeauftragte, Sicherheitsmanager und IT-Verantwortliche. Das WiKi ist öffentlich lesbar, die Inhalte sind frei nutzbar. Das Erstellen und Bearbeiten von Artikeln erfordert jedoch eine Registrierung als Benutzer. Jeder ist eingeladen, aktiv an den Inhalten mitzuarbeiten, eine gewisse Fachkompetenz sollte jedoch vorhanden sein, um die Qualität der Inhalte zu gewährleisten.

Für die organisationsübergreifende Zusammenarbeit und den gemeinsamen Austausch gibt es ein Forum auf Basis von HumHub. Unter [https://humhub.isms-ratgeber.info humhub.isms-ratgeber.info] stehen Foren/Workspaces zu verschiedenen Themen zum Austausch zur Verfügung. Die Registrierung ist wie hier im WiKi kostenlos.<br>
{| width="100%"
|-

|style="vertical-align:top" |

<h2 {{MainpageTopBox}}>
Für Einsteiger
</h2>
<div {{MainpageMidBox}}>
Informationen für Einsteiger und Anfänger.
*[[ISMS-Einführung|Einführung: Was ist ein ISMS?]]
*[[ISMS-Ratgeber-WiKi|Über das ISMS-Ratgeber Wiki]]
*[[ISMS-Ratgeber Anleitung|Anleitung zur Nutzung des ISMS-Ratgeber Wiki]]
*[[Mustervorlagen|Nutzung der Mustervorlagen]]
*[[Sicherheitsprojekte|Durchführung eines Sicherheitsprojekts]]
*[[QuickCheck|Ein QuickCheck zum Stand der Informationssicherheit]]
*[[Abkürzungen|Glossar]]
*[[Hilfe|allgemeine Wiki Hilfe]]
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>

<h2 {{MainpageTopBox}}>
Grundlagenartikel
</h2>
<div {{MainpageMidBox}}>
Grundlagenartikel mit ausführlichen Hintergrundinformationen zu bestimmten Themen und allgemeine Artikel.
*[[ISMS_Step_by_Step|Aufbau eines ISMS Step by Step (KMU)]]
*[[Geschäftsprozesse]]
*[[Dokumentenerstellung|Hilfen zur Dokumentenerstellung]]
*[[Managementbericht|Erstellen eines Managementberichts]]
*[[Betriebsdokumentation|Hilfen für Betriebsdokumentation]]
*[[Reifegradmodell|Erstellen eines Reifegradmodells]]
*[[KPIs|Key Performance Indicators (KPIs)]]
*[[Authentisierung|Methoden zur Authentisierung]]
*[[Klassifizierung|Klassifizierung von Informationen (Schutzstufen)]]
*[[Normen und Standards|Normen und Standards rund um das ISMS]]
*[[Bildkampagne|Sensibilisierung mit Bildkampagnen]]
*[[Online Prüftools|Liste von Online-Prüftools]]
*[[Referenzdokumente|Erforderliche Referenzdokument für Zertifizierungen]]
*[[ISO27001 vs. IT-Grundschutz|Vergleich ISO27001 und IT-Grundschutz]]
*[[Geheimschutz|Was ist Geheimschutz?]]
*[[Datenvernichtung|Übersicht und Normen zur Datenvernichtung]]
*[[Datenlöschung|Übersicht zur sicheren Datenlöschung]]
*[[Schutzbedarf|Vorgehen zur Schutzbedarfsfeststellung]]
*[[Dokumentenmanagement|Einführung in das Dokumentenmanagement]]
*[[Protokollierung|Einführung in die Protokollierung (Logging)]]
*[[Benutzer und Rechteverwaltung|Benutzer und Rechteverwaltung]]
*[[Cloudnutzung|Grundlagen zur Cloudnutzung]]
*[[VoIP|Voice over IP - Grundlagen, Risiken & Best Practices]]
*[[Container|Sicherheitsaspekte der Containerisierung]]
*[[Homeoffice und mobiles Arbeiten|Homeoffice und mobiles Arbeiten]]
*[[Risikomanagement|Einführung in das Risikomanagement]]
*[[Gebäudeinfrastruktur|Grundlagen sicherer Gebäudinfrastruktur]]
*[[Notfallmanagement]]
*[[Datensicherung SaaS|Datensicherung bei SaaS-Anwendungen]]
*[[Lieferkettensicherheit|Sicherheit von Lieferketten]]
*[[BSI Standard 200-3|''Risikomanagement nach BSI Standard 200-3'']]⚠️
*[[GS-Zertifizierungsaudit|Vorbereitung einer Zertifizierung auf Basis von IT-Grundschutz]]
*[[Social Media|Einsatz von Social Media im Unternehmen]]
*[[EU AI Act|EU AI Act: ISMS-Integration, Risiken & Umsetzung]]
*[[KI-Nutzung|Chancen und Risiken von KI]]
*[[Industrielle IT|Grundlagen & Sicherheitsaspekte Industrieller IT]]
*[[Bücher und Links|Informative Bücher und Links]]
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>

<h2 {{MainpageTopBox}}>
Kurzartikel
</h2>
<div {{MainpageMidBox}}>
Kurze Artikel und Beschreibungen zu nur einem Stichwort.
*[[ISO 27001]]
*[[IT-Grundschutz]]
*[[Grundschutz++]]
*[[Grundschutz ToDo MindMap|IT-Grundschutz ToDo MindMap]]⚠️
*[[Cybersecurity]]
*[[Security by Design]]
*[[Threat Intelligence]]
*[[APT|Advanced Persistent Threat (APT)]]
*[[Awareness|Was ist mit Awareness?]]
*[[Rechtsgrundlagen]]
*[[Datenschutz]]
*[[Datenschutzbeauftragte]]
*[[TOMs]]
*[[VVT|Verzeichnis von Verarbeitungstätigkeiten (VVT)]]
*[[AVV|Auftragsverarbeitungsvertrag (AVV)]]
*[[DSFA|Datenschutz-Folgenabschätzung (DSFA)]]
*[[Informationssicherheitsbeauftragte]]
*[[IS-Management-Team]]
*[[Krisenkommunikation]]
*[[Krisenprävention]]
*[[Krisenstab]]
*[[Notfallbeauftragte]]
*[[Verfügbarkeit]]
*[[Zero Trust]]
*[[Threat Intelligence Ansatz|Umsetzung von Threat Intelligence]]
*[[Riskoanalyse]]
*[[BYOD|Bring Your Own Device (BYOD)]]
*[[SOC|Security Operations Center (SOC)]]
*[[Common_Criteria|Common Criteria oder (CC)]]
*[[IT-Forensik]]
*[[Zusätzliche Gefährdungen|Zusätzliche/spezifische Gefährdungen]]
*[[Nebenwirkungen|Risiken und Nebenwirkungen]]
*[[ISMS-Tools|ISMS-Tool Vergleich]]
*[[Quantenresistente Verschlüsselung]]
*[[Automatisierung|Automatisierung in der IT-Sicherheit]]
*[[Datenbias|Datenbias - Datenverzerrung managen]]
*[[KI Cybersicherheit|KI in der Cybersicherheit]]
*[[Webservices]]
*[[Multi-Cloud|Herausforderungen in Multi-Cloud-Umgebungen]]
*[[Shared Responsibility Model|Shared Responsibility Model]]
*[[Sicherheitsframework]]
*[[Passkey]]
*[[SOAR|Security Orchestration, Automation, and Response (SOAR)]]
*[[Meldepflichten|''Meldepflichten bei IT-Sicherheitsvorfällen'']]⚠️
*[[Schulungskonzepte|''Schulungskonzepte'']]⚠️
*[[DIN SPEC 27076|DIN SPEC 27076: Beratungsnorm zum Cyber-Risiko für KKU]]
*[[CRC|Cyber-Risiko-Check (CRC)]]
*[[C5|C5 (Cloud Computing Compliance Criteria Catalogue)]]
*[[CIS|CIS Controls (Center for Internet Security Controls)]]
*[[TISAX|TISAX / VDA-ISA]]
*[[OSCAL|OSCAL (Open Security Controls Assessment Language)]]
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>


| width="50%" style="vertical-align:top" |
<h2 {{MainpageTopBox}}>
Erweiterte Suche
</h2>
<div {{MainpageMidBox}}>
Gib deine Suchbegriffe ein. Auf der folgenden Ergebnisseite kann die Suche weiter spezifiziert und eingegrenzt werden.
<inputbox>
type=search
placeholder=Suche...
width=27
break=yes
buttonlabel= Exakte Suche
searchbuttonlabel= Volltextsuche
</inputbox>
</div>

<h2 {{MainpageTopBox}}>
Mustervorlagen für Richtlinien
</h2>
<div {{MainpageMidBox}}>
Die generischen [[Mustervorlagen]] können als Grundlage für die Erstellung eigener Dokumente verwendet werden. Inhalte und Formulierungen müssen an die eigene Organisation angepasst oder ergänzt werden. Beachte hierzu auch den Artikel zur [[Mustervorlagen|Nutzung der Mustervorlagen]].
*[[Informationssicherheitsleitlinie|Leitlinie zur Informationssicherheit]]
*[[IS-Strategie‎‎|Strategie zur Informatinssicherheit]]
*[[Datenschutzleitlinie|Leitlinie zum Datenschutz]]
*[[RiLi-Dokumentenlenkung|Richtlinie zur Lenkung von Dokumenten]]
*[[RiLi-InterneAuditierung|Richtlinie zur internen ISMS-Auditierung]]
*[[RiLi-KVP|Richtlinie zur Lenkung von Korrektur- und Vorbeugungsmaßnahmen]]
*[[RiLi-Sicherheitsvorfallmanagement|Richtlinie Sicherheitsvorfallmanagement]]
*[[RiLi-Ausnahmemanagement|Richtlinie zum Management von Ausnahmen und Abweichungen]]
*[[RiLi-Risikoanalyse|Richtlinie zur Risikoanalyse]]
*[[RiLi-Mitarbeitende|Richtlinien zur Sensibilisierung der Mitarbeitenden]]
*[[RiLi-Sensibilisierung|Richtlinie Sensibilisierung zur Informationssicherheit]]
*[[RiLi-Passworte|Passwort Richtlinie]]
*[[RiLi-Authentifizierung|Richtlinie Authentisierung (passkey-Richtlinie)]]
*[[RiLi-Freigabe|Freigaberichtlinie für Hard- und Software]]
*[[RiLi-Protokollierung|Protokollierungsrichtlinie]]
*[[RiLi-Cloudnutzung|Richtlinie zur Nutzung von Cloud-Diensten]]
*[[RiLi-BYOD|BYOD-Richtlinie – Sichere private Geräte im Unternehmensnetz]]
*[[RiLi-Schadsoftware|Richtlinie Schadsoftware]]
*[[RiLi-Schwachstellenmanagement|Richtlinie Schwachstellenmanagement]]
*[[RiLi-Notfallmanagement (BCM)|Richtlinie Notfallmanagement (BCM)]]
*[[RiLi-Gebäude und Räume|''Richtlinie zu Gebäuden und Räumen'']]⚠️
*[[RiLi-Netzwerkmanagement|''Richtlinie Netzwerkmanagement'']]⚠️
*[[RiLi-Netzwerkmanagement (ZT)|''Richtlinie Netzwerkmanagement für Zero Trust'']]⚠️
*[[RiLi-Servermanagement|''Richtlinie Servermanagement'']]⚠️
*[[RiLi-Webservices|Richtlinie sicherer Betrieb von Webservices]]
*[[RiLi-Clientmanagement|Richtlinie zum Client-Management]]
*[[RiLi-VoIP-Einsatz|Richtlinie zum VoIP-Einsatz]]
*[[RiLi-Fernzugriff|Richtlinie Fernzugriff und Fernwartung]]
*[[RiLi-KI-Einsatz|Richtlinie für den sicheren Einsatz von Künstlicher Intelligenz (KI)]]
*[[RiLi-Industrielle_IT|''Richtlinie für industrielle Steuerungs- und Automatisierungssysteme'']]⚠️
*[[RiLi-Lieferkettensicherheit|Richtlinie zur Lieferkettensicherheit]]⚠️
*[[RiLi-Informationssicherheit KKU|Richtlinie zur Informationssicherheit für KKU (nach DIN SPEC 27076)]]
<hr>
*[[Strukturanalyse|Muster für eine IT-Strukturanalyse]]
*[[Betriebshandbuch|Muster für ein Betriebshandbuch]]
*[[Notfallhandbuch|Muster für ein Notfallhandbuch]]
*[[Vertraulichkeitserklärung|Muster für eine Vertraulichkeitserklärung]]
*[[Fernzugriffsvereinbarung‎‎|Muster für eine Fernzugriffsvereinbarung]]
*[[Erklärung für mobiles Arbeiten|Muster Erklärung für mobiles Arbeiten]]
*[[BYOD-Vereinbarung|Muster-Vereinbarung für BYOD]]
*[[KI-Register|Vorlage für ein rechtskonformes KI-Register]]
*[[Business Impact Analyse (BIA)|''Muster einer Business Impact Analyse (BIA)'']]⚠️
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>

<h2 {{MainpageTopBox}}>
Leitfäden
</h2>
<div {{MainpageMidBox}}>
Leitfäden als Anleitungen für Anwender, zur sensibilisieren für bestimmte Themen und praktische Handlungsempfehlungen.
*[[LF-Homeoffice|Leitfaden sicher im Homeoffice]]
*[[LF-Basistestat Hochschulen|Leitfaden Basistestat Hochschulen]]
*[[LF-Arbeiten im Ausland|Leitfaden Arbeiten im Ausland]]
*[[LF-Sicher_arbeiten|Leitfaden sicheres Arbeiten]]
*[[LF-Sicher_unterwegs|Leitfaden sicher unterwegs]]
*[[LF-KI-Chatbots|Leitfaden zur Nutzung von KI-Systemen]]
*[[LF-Modellierung|Leitfaden Gruppierung und Modellierung]]
*[[LF-Grundschutzcheck|Leitfaden Grundschutzcheck]]
*[[LF-Realisierungsplan|Leitfaden Realisierungsplan/Risikobehandlungsplan]]
</div>

<h2 {{MainpageTopBox}}>
Muster-Betriebskonzepte
</h2>
<div {{MainpageMidBox}}>
Mustervorlagen für Betriebskonzepte zu Standardthemen.
*[[BK-Verinice|Betriebskonzept verinice (Einzelplatz)]]
*[[BK-Missbrauchskontakt|Betriebskonzept Missbrauchskontakt]]
*[[BK-Windows Server|''Betriebskonzept Windows-Server'']]⚠️
*[[BK-Linux Server|''Betriebskonzept Linux-Server'']]⚠️
*[[BK-Windows Client|''Betriebskonzept für Windows-Clients'']]⚠️
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>

<h2 {{MainpageTopBox}}>
Templates und Vorlagen
</h2>
<div {{MainpageMidBox}}>
Templates sind Dokumentvorlagen (in den Formaten Word, Write(LibreOffice) und MediaWiki), die für eigene Dokumente verwendet werden können. Sie enthalten eine grobe, generische Inhaltsstruktur für den jeweiligen Dokumententyp sowie Felder für die notwendigen Metadaten zur Steuerung des Dokuments.
*[[WikiTemplateArtikel]]
*[[WikiTemplateKurzartikel]]
*[[WikiTemplateRichtlinie]]⚠️
*[[WikiTemplateBetriebskonzept]]⚠️
*[[WordTemplateRichtlinie]]⚠️
*[[WordTemplateBetriebskonzept]]⚠️
</div>
<small>⚠️''Artikel noch im Entwurf /unvollständig''</small>

<h2 {{MainpageTopBox}}>
Themenschwerpunkte und Pfade
</h2>
<div {{MainpageMidBox}}>
Die folgenden Seiten dienen als Einstieg in die Themenschwerpunkte und bieten geführte Wege durch die Themen. (Noch nicht aktiv!)
*[[Dummy|''Einführung und Aufbau eines ISMS'']]⚠️
*[[KMU_Startseite|''Startseite für KMU, Handwerk und Freiberufler'']]⚠️
*[[Dummy|''Durchführung einer Risikoanalyse'']]⚠️
*[[Dummy|''Einführung und Aufbau eines Notfallmanagements'']]⚠️
*[[Dummy|''Weg zur Zertifizierung (BSI IT-Grundschutz)'']]⚠️
*[[Dummy|''Weg zur Zertifizierung (ISO 27001 nativ)'']]⚠️
*[[Datenschutz Umsetzung|Praktische Umsetzung von Datenschutz]]
*[[KI_Startseite|Einführung zu sinnvollen Regelungen für den KI-Einsatz]]
*[[Grundschutz++ Einführung und Aufbau|''Einführung und Anleitung zum BSI Grundschutz++'']]
</div>
<small>⚠️''Artikel noch im Entwurf/unvollständig''</small>
|}


{| width="100%"
|-
|style="vertical-align:top" |
<h2 {{MainpageTopBox}}>
<center>Allgemeine Hinweise</center>
</h2>
<div {{MainpageMidBox}}>
Artikel, die der Kategorie "[[:Kategorie:Entwurf|Entwurf]]" (siehe Fußzeile des Dokuments) zugeordnet sind, sind noch unvollständig oder können noch Fehler enthalten.
Auch vollständig ausgearbeitete Dokumente sind nur Formulierungsvorschläge. Alle Musterdokumente müssen an die individuellen Gegebenheiten der Organisation angepasst werden.
</div>
|}
__KEIN_INHALTSVERZEICHNIS__
__ABSCHNITTE_NICHT_BEARBEITEN__
__INDEXIEREN__

Kategorie:ISO27001

2026-03-27T12:12:48Z

Dirk: Die Seite wurde neu angelegt: „Artikel zu IEC/ISO 27001.“

Artikel zu IEC/ISO 27001.

Zusätzliche Gefährdungen

2026-03-27T11:49:34Z

Dirk:

Abkürzungen

2026-03-27T11:45:15Z

Dirk:

<nowiki>:</nowiki>{{#seo:
|title=Glossar zur Informationssicherheit
|keywords= ISMS,Glossar,Abkürzungsverzeichnis,Synonyme,Informationssicherheit,BCM,Datenschutz,Risikomanagement
|description=Verzeichnis von Abkürzungen und Synonymen zur Informationssicherheit, Notfallmanagement (BCM) und Datenschutz.
}}{{SHORTDESC:Verzeichnis der Abkürzungen und Synonyme zur Informationssicherheit}}
[[Datei:File-cabinet-146156.png|alternativtext=Akten|rechts|160x160px|Image by OpenClipart-Vectors from Pixabay]]
Das Glossar zur Informationssicherheit ist eine Sammlung von etwa 400 Begriffen und Definitionen, die häufig in der Informationssicherheit verwendet werden. Es dient als Nachschlagewerk, um Fachleuten und Interessierten klare und einheitliche Erklärungen zu bieten, was die Verständigung und Schulung in diesem komplexen Bereich erleichtert.

== Verzeichnis der Abkürzungen und Synonyme ==

Zur Suche innerhalb des Verzeichnisses bitte die Suchfunktion des Browsers verwenden. ([STRG] + F).

Die Spalten können durch einen Klick auf die Überschrift auf- und absteigend sortiert werden.

Die letzte Spalte definiert die Bereiche in denen die Abkürzung oder der Begriff Anwendung findet wie folgt:

'''IS'''=Informationssicherheit (organisatorisch); '''IT'''=Informationstechnik; '''DS'''=Datenschutz; '''ID'''=Industrielle IT; '''BC'''=Notfallmanagement (BCM); '''KI'''=Künstliche Intelligenz.

{| class="wikitable sortable"
|+
!Abkürzung/Begriff!!Erklärung!!Bereich
|-
|2FA
|Zwei-Faktor-Authentisierung. Ein Authentifizierungsverfahren, das zwei verschiedene Faktoren zur Verifizierung der Identität eines Benutzers erfordert.
|IS, IT
|-
|Advisory
|Sicherheitswarnung von Herstellern oder CERTs, die auf eine Schwachstelle oder Angriffsmöglichkeit bei einer Hard- oder Software hinweist.
|IS, IT
|-
|Adware
|Adware zeigt unerwünschte Werbung an und kann das Benutzererlebnis beeinträchtigen sowie potenziell schädliche Anzeigen einblenden.
|IT
|-
|AGV
|Automated Guided Vehicle: Automatisierte, führerlose Transportfahrzeuge in der Produktion
|ID, IT
|-
|AI KI
|Künstliche Intelligenz (KI) bezieht sich auf die Simulation menschlicher Intelligenzprozesse …
|KI, IT
|-
|ALG
|Application Level Gateway – trennt eine Verbindung netztechnisch und filtert auf Anwendungsebene
|IS, IT
|-
|ANSI
|American National Standards Institute – ein privatwirtschaftliches Standardisierungsorgan der USA
|IT
|-
|API
|Application Programming Interface – dokumentierte Software-Schnittstelle
|IT
|-
|APT
|Advanced Persistent Threat – langandauernde, zielgerichtete Cyberangriffskampagne
|IS, IT
|-
|Authentifizierung
|Vorgang zur Überprüfung der Identität einer Person oder eines Systems
|IS, IT
|-
|Authentizität
|Nachweis über die Echtheit elektronischer Daten und deren Zuordnung zum Verfasser
|IS, IT
|-
|Autorisierung
|Prüfung, ob eine Person, IT-Komponente oder Anwendung zur Durchführung einer Aktion berechtigt ist
|IS, IT
|-
|AVV
|Auftragsverarbeitungsvertrag, der den Umgang mit personenbezogenen Daten im Einklang mit der DSGVO regelt
|DS
|-
|Backdoor
|Versteckte Möglichkeit, Zugang zu einem Computersystem zu erhalten, oft für böswillige Zwecke
|IS, IT
|-
|BCM BCMS
|Business Continuity Management – Maßnahmen zur Fortführung der Geschäftsprozesse nach einem Notfall
|BC
|-
|BDBOS
|"Bundesanstalt für den Digitalfunk der Behörden und Organisationen" – koordiniert den Digitalfunk im Bereich öffentliche Sicherheit
|IS
|-
|BIA
|Business Impact Analyse – Analyse zur Ermittlung potentieller Folgeschäden durch Ausfall von Geschäftsprozessen
|BC, IS
|-
|Bias
|Bias (Daten-Bias) bezeichnet eine systematische Verzerrung oder Voreingenommenheit in statistischen oder KI-Daten, die zu einer fehlerhaften Wahrnehmung, Bewertung oder Entscheidungsfindung führt.
|KI, IT
|-
|Big Data
|Verarbeitung und Analyse extrem großer, komplexer Datenmengen
|IT
|-
|Biometrie
|Automatisierte Erkennung von Personen anhand körperlicher Merkmale
|IS, IT
|-
|Block Storage
|Speichersystem, bei dem Daten in Blöcken organisiert werden
|IT
|-
|Blockchain
|Dezentrale und verteilte digitale Ledger-Technologie
|IT
|-
|Blue Teaming
|Sicherheitskräfte, die ein Unternehmen gegen Cyberangriffe verteidigen
|IS, IT
|-
|BNetzA
|Bundesnetzagentur – Regulierungsbehörde u. Zertifizierungsstelle
|IS
|-
|BO
|Buffer Overflow – Sicherheitslücke durch Überschreiben von Speicherbereichen
|IS, IT
|-
|BOS
|Behörden und Organisationen mit Sicherheitsaufgaben
|IS
|-
|Bot/Botnet/Bot-Netz
|Ein Bot-Netz aus vielen infizierten PCs (Bot), die ferngesteuert werden
|IS, IT
|-
|Brute-Force-Angriff
|Angriff durch massives Ausprobieren von Möglichkeiten zum Erraten von Passwörtern
|IS, IT
|-
|BSC
|Basis-Sicherheits-Check – Überprüfung der Umsetzung von IT-Grundschutz-Maßnahmen
|IS
|-
|BSI
|Bundesamt für Sicherheit in der Informationstechnik – nationale Cyber-Sicherheitsbehörde
|IS
|-
|BYOD
|Bring Your Own Device – Nutzung eigener mobiler Geräte im beruflichen Kontext
|IS, IT
|-
|CA
|Certification Authority – Zertifizierungsinstanz für digitale Zertifikate
|IS, IT
|-
|CC
|Common Criteria – internationaler Standard für IT-Sicherheitsbewertungen
|IS
|-
|CERT
CSIRT
|Computer Emergency Response Team / Computer Security Incident Response Team – Team zur Koordination bei Sicherheitsvorfällen
|IS
|-
|CIA
|Steht für Confidentiality, Integrity und Availability – Grundwerte der Informationssicherheit
|IS
|-
|CICD
CI/CD
|Continuous Integration/Continuous Deployment – Methode der kontinuierlichen Integration und Bereitstellung von Codeänderungen
|IT
|-
|CISO
CSO
|Chief Information Security Officer
Chief Security Officer
|IS
|-
|Cloud
|Cloud Computing – Bereitstellung von IT-Ressourcen über das Internet
|IT
|-
|CNAPP
|Cloud-Native Application Protection Platform – Lösung zum Schutz von cloud-nativen Anwendungen
|IS, IT
|-
|Compliance
|Einhaltung von Gesetzen, Vorschriften, Standards und internen Richtlinien
|IS
|-
|CRL
|Certificate Revocation List – Liste gesperrter und widerrufener Zertifikate
|IS, IT
|-
|CSP
|Cloud Service Provider – Anbieter von Cloud-Diensten
|IT
|-
|CVE
|Common Vulnerabilities and Exposures – Verzeichnis öffentlich zugänglicher Sicherheitslücken
|IS, IT
|-
|CWPP
|Cloud Workload Protection Platform – Sicherheitsplattform für Workloads in Cloud-Umgebungen
|IS, IT
|-
|Cyber-Risiko-Check (CRC)
|Systematisches Verfahren zur Identifikation und Bewertung von IT-bezogenen Risiken
|IS
|-
|Cybersecurity
|Umfasst Maßnahmen, Technologien und Prozesse zum Schutz von Netzwerken, Systemen und Daten
|IS, IT
|-
|Degaussing
|Methode zur Unlesbarmachung von Daten auf magnetischen Speichermedien durch starke Magnetfelder
|IT
|-
|DevSecOps
|Ansatz zur Integration von Sicherheitspraktiken in den Softwareentwicklungs- und Betriebsprozess
|IS, IT
|-
|Digitale Zwillinge
|Virtuelle Abbilder physischer Anlagen zur Simulation und Optimierung
|ID, IT
|-
|DIN
|Deutsches Institut für Normung – nationale Normungsorganisation
|IT
|-
|Disaster Recovery
|Strategien und Prozesse zur Wiederherstellung eines IT-Systems nach einem Ausfall oder Angriff
|BC
|-
|DKIM
|DomainKeys Identified Mail – E-Mail-Authentifizierungsstandard
|IS, IT
|-
|DLP
|Data Loss Prevention – Maßnahmen zur Verhinderung des Verlusts oder der unbefugten Weitergabe sensibler Daten
|DS, IS
|-
|DMARC
|Domain-based Message Authentication, Reporting, and Conformance – E-Mail-Authentifizierungsprotokoll
|IS, IT
|-
|DMZ
|Demilitarisierte Zone – Netzsegment mit kontrolliertem Zugriff
|IS, IT
|-
|DN
|Distinguished Name – Eindeutige Adressierung in Verzeichnisdiensten
|IT
|-
|DoS/DDoS
|Denial-of-Service / Distributed Denial-of-Service – Angriffe zur Lahegung von IT-Systemen
|IS, IT
|-
|DPIA
|Data Protection Impact Assessment – Datenschutz-Folgenabschätzung gemäß DSGVO
|DS
|-
|Drive-by-Download
|Methode, bei der Malware automatisch beim Besuch einer infizierten Website heruntergeladen wird
|IS, IT
|-
|DSB/bDSB
|Datenschutzbeauftragter bzw. betrieblicher/behördlicher Datenschutzbeauftragter
|DS, IS
|-
|DSFA
|Datenschutz-Folgenabschätzung – Prozess zur Bewertung der Risiken bei der Verarbeitung personenbezogener Daten
|DS
|-
|Edge Computing
|Dezentrale Datenverarbeitung am Netzwerkrand zur Reduzierung von Latenz und Bandbreitenbedarf
|IT
|-
|EPP
|Endpoint Protection Platform – Lösung zum Schutz von Endgeräten
|IS, IT
|-
|ERP
|Enterprise-Ressource-Planning – Optimierung betrieblicher Abläufe durch Planung vorhandener Ressourcen
|IT
|-
|Exploit
|Methode oder Software, die Schwachstellen in einem System ausnutzt
|IS, IT
|-
|FaaS
|Function as a Service – Cloud-Computing-Modell zur Ausführung von Code ohne Infrastrukturmanagement
|IT
|-
|FIDO2
|Fast Identity Online 2 – Authentifizierungsstandard, oft unter Einsatz biometrischer Daten
|IS, IT
|-
|File Storage
|Methode zur Speicherung von Daten in einem hierarchischen Dateisystem
|IT
|-
|Gefährdung
|Bedrohung, die konkret über eine Schwachstelle auf ein Objekt einwirkt (BSI-Definition)
|IS
|-
|GSC
|GrundSchutz-Check – Überprüfung der Umsetzung von IT-Grundschutz-Anforderungen
|IS
|-
|Hashwert
Hashfunktion
|Mathematische Prüfsumme, erzeugt durch Anwendung einer Hashfunktion
|IS, IT
|-
|HIPAA
|Health Insurance Portability and Accountability Act – US-Gesetz zum Schutz sensibler Patientendaten
|DS, IT
|-
|Honeypot
|Nicht produktiv genutztes, speziell aufgestelltes System, um Angriffe zu erkennen
|IS, IT
|-
|HSM
|Hardware Security Modul – speziell gehärtete Appliance zur Handhabung kryptographischer Schlüssel
|IS, IT
|-
|HTTP
|Hypertext Transport Protocol – Protokoll für die Datenübertragung im WWW
|IT
|-
|HTTPS
|Hypertext Transfer Protocol Secure – Verschlüsselte und authentifizierte Version von HTTP
|IS, IT
|-
|IaaS
|Infrastructure as a Service – Bereitstellung von IT-Ressourcen wie virtuellen Maschinen
|IT
|-
|IAM
|Identity and Access Management – Verwaltung von Benutzeridentitäten und Zugriffsrechten
|IS, IT
|-
|IDS
|Intrusion Detection System – Überwachungssystem zur Erkennung von Angriffen
|IS, IT
|-
|IETF
|Internet Engineering Task Force – internationale Gemeinschaft zur Weiterentwicklung der Internet-Architektur
|IT
|-
|IIoT
|Industrial Internet of Things – Vernetzung industrieller Geräte und Maschinen
|ID, IT
|-
|Integrität
|Sicherstellung der Korrektheit und Unversehrtheit von Daten
|IS
|-
|IoT
|Internet of Things – Netzwerk physischer Geräte, die über das Internet verbunden sind
|IT
|-
|IPS
|Intrusion Prevention System – System zur Erkennung und automatischen Abwehr von Angriffen
|IS, IT
|-
|IPSec
|Internet Protocol Security – Protokoll für gesicherte IP-Kommunikation
|IS, IT
|-
|ISB<br>InSiBe<br>ITSB
|Informationssicherheitsbeauftragter bzw. IT-Sicherheitsbeauftragter
|IS
|-
|ISMS
|Informations-Sicherheits-Management-System – Definition, Steuerung und fortlaufende Verbesserung der Informationssicherheit
|IS
|-
|ISO
|International Organization for Standardization – internationale Normungsorganisation
|IT
|-
|IT-Forensik
|Untersuchung und Analyse von IT-Systemen zur Gewinnung von Beweismitteln
|IS, IT
|-
|IT-Grundschutz
|Methodik des BSI zum Aufbau eines Sicherheitsmanagementsystems
|IS
|-
|ITSCM
|Information Technology Service Continuity Management – IT-Notfallmanagement, z.T. synonym zu BCM
|BC
|-
|ITSEC
|Information Technology Security Evaluation Criteria – europäischer Standard für Sicherheitsbewertungen
|IS, IT
|-
|IT-Verbund<br>Informationsverbund<br>Scope
|Gesamtheit von Infrastruktur, Zusammenfassung von Organisation und Technik zur Erfüllung eines bestimmten IT-Auftrags
|IT
|-
|JSON
|JavaScript Object Notation – leichtgewichtiges, textbasiertes Datenformat
|IT
|-
|JWT
|JSON Web Token – kompaktes, URL-sicheres Mittel zur Übertragung von Ansprüchen zwischen Parteien
|IS, IT
|-
|K8s
|Kubernetes – Open-Source-System zur Verwaltung containerisierter Anwendungen
|IT
|-
|Keylogger
|Hard- oder Software zum Mitschneiden von Tastatureingaben
|IS, IT
|-
|KPI
|Key Performance Indicators – Leistungskennzahlen zur Messung der Informationssicherheit
|IS
|-
|Krise
|Schadensereignis, das massive negative Auswirkungen auf eine Organisation hat
|BC
|-
|Krisenbewältigung
|Tätigkeiten zur Bewältigung einer eingetretenen Krise
|BC
|-
|KRITIS
|Kritische Infrastrukturen – Organisationen mit besonders hohem Versorgungs- und Sicherheitsbedarf
|IS
|-
|Krypto-Schreddern
|Methode zum sicheren Löschen von Daten durch Entfernen kryptographischer Schlüssel
|IS
|-
|Kumulationseffekt
|Erhöhter Schutzbedarf eines IT-Systems durch kumulative Schäden oder Anwendungen
|IS
|-
|KVP
|Kontinuierlicher Verbesserungsprozess – Grundprinzip des Qualitätsmanagements (z. B. ISO 9001)
|IS
|-
|Lage
|Sachliche Momentaufnahme des aktuellen Standes einer Krise
|BC
|-
|Lagebild
|Zusammenfassung relevanter Informationen zu einer Situation zur Entscheidungsfindung
|BC
|-
|LDAP
|Lightweight Directory Access Protocol – Protokoll zur Abfrage und Änderung von Einträgen in einem Verzeichnisdienst
|IT
|-
|LÜKEX
|Ressort- und Länderübergreifende Krisenmanagementübung
|BC
|-
|MAC
|Message Authentication Code – zur Sicherung der Integrität und Authentizität von Nachrichten
|IS, IT
|-
|Maleware
|(Malicious Software) – Software, die entwickelt wurde, um Schaden zu verursachen
|IS, IT
|-
|MBCO
|Minimum Business Continuity Objective – Notbetriebsniveau
|BC
|-
|MES
|Manufacturing Execution System – Fertigungsmanagementsystem, speziell in der Produktion, häufig im industriellen Kontext
|ID, IT
|-
|MFA
|Multi-Factor Authentication – Authentifizierungsverfahren mit mehreren Faktoren
|IS, IT
|-
|MIME
|Multipurpose Internet Mail Extensions – Standard für den Aufbau von E-Mails
|IT
|-
|MTA / MTPD
|Maximal tolerierbare Ausfallzeit / Maximal Tolerable Period of Disruption – Kennzahlen im Notfallmanagement
|BC
|-
|NdB
|"Netze des Bundes" – IT-Infrastrukturen und Kommunikationsnetze deutscher Bundesbehörden
|IT, IS
|-
|Nichtabstreitbarkeit
|Gewährleistung der Urheberschaft bei der Übertragung von Daten
|IS
|-
|NIS / NIS2
|EU-Richtlinie zur Verbesserung der Cybersicherheit
|IS, IT
|-
|NIST
|National Institute for Standards and Technology – US-Standardisierungsinstitut
|IT
|-
|NIST CSF
|National Institute of Standards and Technology Cybersecurity Framework – Rahmenwerk zur Verbesserung der Cybersicherheit
|IS, IT
|-
|Normalbetrieb
|Planmäßiger Geschäftsbetrieb einer Organisation
|BC
|-
|Notbetrieb
|Eingeschränkter Betrieb nach einem Schadensereignis
|BC
|-
|Notfall
|Unterbrechung eines kritischen Geschäftsprozesses, der nicht innerhalb der tolerierbaren Ausfallzeit behoben werden kann
|BC
|-
|Notfallbeauftragter
|Verantwortliche Person für den Notfall- und Business Continuity Management Prozess
|BC
|-
|Notfallhandbuch
Notfallkonzept
Notfallvorsorgekonzept
|Dokumentation aller für die Notfallbewältigung erforderlichen Informationen
|BC
|-
|Notfallplanung
Notfallvorsorge
Vorsorgemaßnahme
|Geplante Maßnahmen zur Prävention und Bewältigung von Notfällen
|BC
|-
|OAuth
|Open Authorization – Protokoll, das Drittanbietern den Zugriff auf Ressourcen im Namen eines Benutzers ermöglicht
|IS, IT
|-
|Object Storage
|Methode zur Speicherung von Daten als Objekte mit Metadaten
|IT
|-
|OCR
|Optical Character Recognition – optische Zeichenerkennung in Bildern
|IT
|-
|OE
|Organisationseinheit – administrative oder organisatorische Gliederung innerhalb eines Unternehmens
|IS
|-
|OIDC
|OpenID Connect – Authentifizierungsprotokoll basierend auf OAuth 2.0
|IS, IT
|-
|OPC UA
|Open Platform Communications Unified Architecture – plattformunabhängiges Industriekommunikationsprotokoll
|ID, IT
|-
|OSCAL
|Open Security Controls Assessment Language – Rahmenwerk zur Darstellung von Sicherheitsinformationen in maschinenlesbarer Form
|IS, IT
|-
|OTP
|One Time Password – temporäres Passwort, das nur einmal genutzt wird
|IS, IT
|-
|OWASP
|Open Web Application Security Project – Organisation zur Verbesserung der Softwaresicherheit
|IS, IT
|-
|PaaS
|Platform as a Service – Cloud-Computing-Modell, das Entwicklungsplattformen bereitstellt
|IT
|-
|PAM
|Privileged Access Management – Verwaltung und Überwachung privilegierter Benutzerzugriffe
|IS, IT
|-
|PCI DSS
|Payment Card Industry Data Security Standard – Sicherheitsstandard zum Schutz von Kreditkartendaten
|IS, IT
|-
|PDCA
|Plan Do Check Act – Regelkreis des kontinuierlichen Verbesserungsprozesses
|IS
|-
|PGP
|Pretty Good Privacy – Programm zur asymmetrischen Verschlüsselung und Signatur von Daten
|IS, IT
|-
|PIN
|Personal Identification Number – persönliche Geheimzahl zur Identifikation
|IS, IT
|-
|PKCS
|Public Key Cryptography Standards – Standards für asymmetrische Kryptographie
|IS, IT
|-
|PKI
|Public-Key-Infrastruktur – System zum Ausstellen, Verteilen und Verwalten digitaler Zertifikate
|IS, IT
|-
|Predictive Maintenance
|Vorausschauende Wartung durch Datenanalyse zur Vermeidung ungeplanter Ausfälle
|ID, IT
|-
|Proxy
|Trennt netztechnisch die Verbindung zwischen Kommunikationspartnern
|IS, IT
|-
|PSE
|Personal Security Environment – Aufbewahrungsmedium für private Schlüssel und Zertifikate
|IS, IT
|-
|Quantensichere Kryptografie
|Verschlüsselungsmethoden, die gegen Angriffe durch zukünftige Quantencomputer resistent sind
|IS, IT
|-
|RAMI 4.0
|Reference Architectural Model Industrie 4.0 – Referenzarchitekturmodell für Industrie-4.0-Systeme
|ID, IT
|-
|Ransomware
|Verschlüsselt Dateien und fordert Lösegeld für die Entschlüsselung
|IS, IT
|-
|RBAC
|Role-Based Access Control – Zugriffskontrollmodell basierend auf definierten Rollen
|IS, IT
|-
|Red Teaming
|Sicherheitstest, bei dem Expert*innen als Angreifer agieren, um Schwachstellen aufzudecken
|IS
|-
|Reifegrad
Reifegradmodell
|Instrument zur Bewertung und Verbesserung der Informationssicherheit
|IS
|-
|Risiko
|Kombination aus Eintrittswahrscheinlichkeit und Schadensausmaß – grundlegender Begriff im Risikomanagement
|IS
|-
|Rootkit
|Sammlung von Tools, die nach einem Einbruch installiert werden, um spätere Aktivitäten zu verbergen
|IS, IT
|-
|RPA
RPO
RTA
RTO
|Recovery point actual (RPA), Recovery point objective (RPO), Recovery time actual (RTA), Recovery time objective (RTO)
Kennzahlen im Zusammenhang mit Datenverlust und Wiederanlaufzeiten im Notfallmanagement
|BC
|-
|S/MIME
|Secure Multipurpose Internet Mail Extensions – Standard zur Verschlüsselung und Signatur von E-Mails
|IS, IT
|-
|SaaS
|Software as a Service – Bereitstellung von Software über das Internet
|IT
|-
|SAML
|Security Assertion Markup Language – offener Standard für den Austausch von Authentifizierungs- und Autorisierungsdaten
|IS, IT
|-
|SASE
|Secure Access Service Edge – Integration von Netzwerk- und Sicherheitsfunktionen in einer Cloud-basierten Plattform
|IS, IT
|-
|SD-WAN
|Software-Defined Wide Area Network – Virtualisierung und Verwaltung von Weitverkehrsnetzen
|IT
|-
|Security by Design
|Prinzip, Sicherheitsaspekte von Beginn an in Entwicklungsprozesse zu integrieren
|IS, IT
|-
|SHA-1
SHA-2
SHA-3
SHAKE
|Secure Hash Algorithms – kryptographische Hashfunktionen
|IT
|-
|SIEM
|Security Information and Event Management – System zur Echtzeit-Überwachung und Analyse von Sicherheitsereignissen
|IS, IT
|-
|SLA
|Service Level Agreement – vertragliche Vereinbarung über IT-Dienstleistungsqualität
|IT
|-
|SOAR
|Security Orchestration, Automation, and Response – Kombination von Workflows und Automatisierung zur Bedrohungsabwehr
|IS, IT
|-
|SOC
|Security Operations Center – zentrale Einheit zur Überwachung und Reaktion auf Sicherheitsvorfälle
|IS
|-
|SOC 2
|Prüfungsstandard zur Überprüfung von Sicherheits-, Verfügbarkeits- und Datenschutzanforderungen
|IS, IT
|-
|Social Engineering
|Manipulationstechnik zur Erlangung sensibler Informationen
|IS, IT
|-
|SPC
|Software Publishing Certificate – Datenstruktur bei der Signierung von Programm-Code
|IT
|-
|Spear Phishing
|Gezielte Phishing-Attacke auf einzelne Personen oder Organisationen
|IS, IT
|-
|SPF
|Sender Policy Framework – verhindert E-Mail-Spoofing durch Überprüfung autorisierter Mailserver
|IS, IT
|-
|SPoF
|Single Point of Failure – einzelner Ausfallpunkt in einem System
|IT
|-
|Spyware
|Software, die unbemerkt Daten an Dritte überträgt
|IS, IT
|-
|SSH
|Secure Shell – verschlüsseltes Protokoll für den Fernzugriff
|IS, IT
|-
|SSL
|Secure Socket Layer – Protokoll zur verschlüsselten Datenübertragung
|IS, IT
|-
|SSO
|Single Sign-On – Authentifizierungsmethode für den Zugriff auf mehrere Systeme mit einem Satz Anmeldedaten
|IS, IT
|-
|Störung
|Schadensereignis, das im Normalbetrieb behoben werden kann – typischerweise im Rahmen des Notfallmanagements
|BC
|-
|Supply-Chain/Lieferkette
|Gesamtheit aller Prozesse und Akteure in der Herstellung und Distribution von Produkten, hier im Kontext der Informationssicherheit
|IT, IS
|-
|TESTA
|Trans-European Services for Telematics between Administrations
Ein sicheres, europaweites Kommunikationsnetzwerk für Behörden und öffentliche Institutionen innerhalb der EU
|IT, IS
|-
|Threat Intelligence
|Sammlung und Analyse von Informationen zu aktuellen und potenziellen Sicherheitsbedrohungen
|IS, IT
|-
|TISAX
|Trusted Information Security Assessment Exchange – branchenspezifisches Prüfverfahren in der Automobilindustrie
|IS
|-
|T.I.S.P.
|TeleTrusT Information Security Professional - Eine europäische Zertifizierung für IT-Sicherheitsfachleute
|IS
|-
|TISP
|Trusted Internet Service Provider - Ein Konzept für vertrauenswürdige Internetdienstanbieter, die hohe Sicherheits- und Datenschutzanforderungen erfüllen.
|IS
|-
|TLS
|Transport Layer Security – Protokoll für Datenschutz und Integrität in der Internetkommunikation
|IS, IT
|-
|TOM
|Technische und organisatorische Maßnahmen – Maßnahmen zum Schutz personenbezogener Daten im Einklang mit der DSGVO
|DS, IS
|-
|TOTP
|Time-Based One-Time Password – zeitbasiertes Einmal-Passwort
|IS, IT
|-
|Trojaner
|Tarnen sich als legitime Software, um Benutzer zur Installation zu verleiten und Hintertüren zu öffnen
|IS, IT
|-
|Trust-Center
|Bezeichnet Infrastrukturen von Zertifizierungsdiensteanbietern im Umfeld der elektronischen Signatur
|IS, IT
|-
|TSN
|Time-Sensitive Networking – zeitkritische Netzwerktechnologie, vor allem in industriellen Anwendungen
|ID, IT
|-
|TTS
|Trouble-Ticket-System – computergestütztes System zur Erfassung und Bearbeitung von Vorfällen
|IT
|-
|Traffic Light Protocol (TLP)
|Eine standardisierte Vereinbarung zum Austausch von schutzwürdigen Informationen.
|IS
|-
|VDA-ISA
|VDA Information Security Assessment – branchenspezifisches Rahmenwerk der Automobilindustrie zur Sicherheitsbewertung
|IS, IT
|-
|Verbindlichkeit
|Rechtliche Bindung eines Geschäfts, oft abhängig von der Einhaltung formaler Anforderungen
|IS
|-
|Verteilungseffekt
|Effekt, bei dem der Schutzbedarf einzelner Systeme durch redundante Auslegung reduziert wird
|IS
|-
|Vertraulichkeit
|Schutz vor unbefugter Kenntnisnahme von Informationen
|IS
|-
|Viren / Virus
|Schadsoftware, die sich an Dateien anhängt und sich selbst repliziert
|IS, IT
|-
|Virtuelle Inbetriebnahme
|Simulation von Anlagen vor physischem Aufbau zur Optimierung und Fehlervermeidung
|ID, IT
|-
|VLAN
|Virtual Local Area Network – logisch separiertes Netzwerksegment innerhalb eines physischen Netzwerks
|IT
|-
|VPN
|Virtuelles Privates Netz – Aufbau eines privaten Netzwerks innerhalb eines öffentlichen Netzes
|IS, IT
|-
|VVT
|Verzeichnis von Verarbeitungstätigkeiten – Dokumentation gemäß DSGVO
|DS
|-
|W3C
|World Wide Web Consortium – Entwickler von Web-Standards
|IT
|-
|WAF
|Web Application Firewall – speziell für Webanwendungen entwickelte Firewall
|IS, IT
|-
|WAP
WAZ

WHP
|Wiederanlaufplan, Wiederanlaufzeit, Wiederherstellungsplan – Pläne und Kennzahlen im Notfallmanagement
|BC
|-
|Web of Trust
|Konzept zur Authentizitätsüberprüfung öffentlicher Schlüssel durch gegenseitige Beglaubigung
|IS, IT
|-
|Wiederanlauf
|Maßnahmen, um in einen Notbetrieb überzugehen
|BC
|-
|Wiederherstellung
|Geordnete Rückkehr in den Normalbetrieb nach einem Notfall
|BC
|-
|Wurm / Würmer
|Selbstreplizierende Malware, die sich ohne Benutzerinteraktion verbreitet
|IS, IT
|-
|WWW
|World Wide Web – Teil des Internets, der über HTTP zugänglich ist
|IT
|-
|X.500
|Empfehlung für einen globalen Verzeichnisdienst
|IT
|-
|X.509
|Rahmenwerk zur Authentifizierung mittels asymmetrischer Kryptographie
|IS, IT
|-
|XDR
|Extended Detection and Response – integrierte Sicherheitslösung zur Erkennung und Reaktion auf Bedrohungen
|IS, IT
|-
|XML
|Extensible Markup Language – Standard zur strukturierten Darstellung von Daten
|IT
|-
|YAML
|YAML Ain't Markup Language – menschenlesbares Datenformat, häufig für Konfigurationsdateien
|IT
|-
|Yellow Teaming
|Zusammenarbeit zwischen Red Team und Blue Team zur Verbesserung der Sicherheitslage
|IS
|-
|Zeitstempel
|Digitale Daten zur Beweisführung des Existenzzeitpunkts von Informationen
|IS, IT
|-
|Zero Trust
|Sicherheitskonzept, bei dem grundsätzlich keinem Gerät oder Benutzer vertraut wird
|IS, IT
|-
|Zero-Day-Exploit
|Ausnutzung einer Software-Schwachstelle, bevor ein Patch verfügbar ist
|IS, IT
|-
|ZTA
|Zero Trust Architecture – Implementierung des Zero Trust Prinzips in der IT-Infrastruktur
|IS, IT
|-
|Zugang
|Nutzung von IT-Ressourcen zur Informationsgewinnung
|IT
|-
|Zugriff
|Zugriff auf Informationen oder Daten
|IT
|-
|Zutritt
|Betreten abgegrenzter Bereiche (z. B. Gebäude)
|IT
|-
| ZTNA || Zero Trust Network Access – Sicherheitskonzept, das kontinuierliche Verifikation statt implizitem Vertrauen fordert || IS, IT
|-
| XDR || Extended Detection and Response – Erweiterte Plattform zur Bedrohungserkennung über verschiedene Sicherheitsebenen hinweg || IS, IT
|-
| Purple Teaming || Kombination aus Red Team (Angreifer) und Blue Team (Verteidiger) für kollaboratives Sicherheitstraining || IS, IT
|-
| CSPM || Cloud Security Posture Management – Überwachung und Korrektur von Fehlkonfigurationen in Cloud-Umgebungen || IS, IT
|-
| Privacy by Design || Integration von Datenschutz in die Entwicklung und Gestaltung von Systemen und Prozessen gemäß DSGVO-Anforderungen || DS, IS
|-
| Federated Learning || Verteiltes maschinelles Lernen, bei dem Daten lokal verbleiben und nicht zentralisiert werden müssen. || KI, IT, DS
|-
| XAI || Explainable AI – Ansätze zur Erklärbarkeit von Entscheidungen künstlicher Intelligenzsysteme. || KI, IT
|-
| OT || Operational Technology – Technologien zur Steuerung und Überwachung industrieller Anlagen und Prozesse || ID, IT
|-
| SCADA || Supervisory Control and Data Acquisition – System zur Überwachung und Steuerung technischer Prozesse || ID, IT
|-
| HMI || Human Machine Interface – Schnittstelle zwischen Mensch und Maschine in industriellen Systemen || ID, IT
|-
| PLC || Programmable Logic Controller – Programmierbare Steuerung für industrielle Automatisierungsprozesse || ID, IT
|-
| MES || Manufacturing Execution System – Produktionsmanagementsystem zur Steuerung und Überwachung von Fertigungsprozessen || ID, IT
|-
| DCS || Distributed Control System – Verteiltes Steuerungssystem für industrielle Anlagen || ID, IT
|-
| ICS || Industrial Control System – Oberbegriff für Steuerungssysteme in industriellen Umgebungen || ID, IT
|-
| Industry 4.0 || Industrie 4.0 – Konzept der umfassenden Digitalisierung industrieller Produktionsprozesse || ID, IT
|-
| CPS || Cyber-Physical Systems – Integration von Informatik, Netzwerktechnik und physikalischen Prozessen || ID, IT
|-
| Purdue Model || Referenzmodell für die Segmentierung und Sicherheit industrieller Netzwerke || ID, IS
|-
| Modbus || Industrielles Kommunikationsprotokoll für Steuerungssysteme || ID, IT
|-
| ML || Machine Learning – Teilbereich der KI, der Algorithmen und Methoden zur automatischen Mustererkennung und Lernen umfasst. || KI, IT
|-
| DL || Deep Learning – Unterkategorie des maschinellen Lernens, basierend auf künstlichen neuronalen Netzen mit mehreren Schichten. || KI, IT
|-
| NLP || Natural Language Processing – Teilgebiet der KI zur Verarbeitung und Analyse natürlicher Sprache. || KI, IT
|-
| CNN || Convolutional Neural Network – Neuronales Netz, das besonders für die Bildverarbeitung geeignet ist. || KI, IT
|-
| RNN || Recurrent Neural Network – Neuronales Netz mit Rückkopplungsverbindungen für sequentielle Daten. || KI, IT
|-
| GAN || Generative Adversarial Network – KI-Architektur, bei der zwei neuronale Netze gegeneinander arbeiten. || KI, IT
|-
| LLM || Large Language Model – Umfangreiches Sprachmodell, das auf riesigen Textmengen trainiert wurde. || KI, IT
|-
| Neuronales Netz || Mathematisches Modell, das vom Aufbau biologischer neuronaler Netzwerke inspiriert ist. || KI, IT
|-
| Computer Vision || Teilgebiet der KI, das sich mit der automatischen Bildanalyse und -verarbeitung befasst. || KI, IT
|-
| BDSG || Bundesdatenschutzgesetz, regelt Datenschutz national in Deutschland und ergänzt die DSGVO. || DS
|-
| DSGVO || Datenschutz-Grundverordnung der EU, einheitliche Rechtsgrundlage für Datenschutz seit 2018 in der EU. || DS
|-
| GDPR || General Data Protection Regulation, englische Bezeichnung für die DSGVO. || DS
|-
| Personenbezogene Daten || Alle Informationen, die sich auf eine identifizierte oder identifizierbare natürliche Person beziehen. || DS
|-
| Einwilligung || Freiwillige, informierte Zustimmung der betroffenen Person zur Verarbeitung ihrer Daten. || DS
|-
| Verantwortlicher || Person oder Organisation, die über den Zweck und die Mittel der Datenverarbeitung entscheidet. || DS
|-
| Auftragsverarbeiter || Dritter, der personenbezogene Daten im Auftrag des Verantwortlichen verarbeitet. || DS
|-
| Betroffene Person || Natürliche Person, deren Daten verarbeitet werden. || DS
|-
| Aufsichtsbehörde || Staatliche Datenschutzbehörde zur Überwachung der Einhaltung und Durchsetzung von Datenschutzvorschriften. || DS
|-
| Anonymisierung || Veränderung von Daten, sodass eine Identifizierung der Person nicht mehr möglich ist. || DS
|-
| Pseudonymisierung || Verarbeitung von Daten, so dass die Identität der Person ohne Zusatzinformationen nicht erkennbar ist. || DS
|-
| Datenschutzverletzung || Verstoß gegen Datenschutzvorschriften oder unbefugter Zugriff auf personenbezogene Daten. || DS
|-
| Zweckbindung || Daten dürfen nur für festgelegte, legitime Zwecke verarbeitet werden. || DS
|-
| Datenminimierung || Verarbeitung nur der notwendigen personenbezogenen Daten. || DS
|-
| Datensicherheit || Maßnahmen zum Schutz der Daten vor unbefugtem Zugriff, Verlust oder Zerstörung. || DS
|-
| Betroffenenrechte || Rechte der betroffenen Personen (Auskunft, Berichtigung, Löschung, Widerspruch). || DS
|-
| Verarbeitungsverzeichnis || Dokumentation aller Datenverarbeitungstätigkeiten gemäß DSGVO. || DS
|-
| Meldepflicht || Verpflichtung zur Meldung von Datenschutzvorfällen an die Aufsicht. || DS
|-
| Recht auf Vergessenwerden || Recht auf Löschung der personenbezogenen Daten unter bestimmten Voraussetzungen. || DS
|-
| Datenübermittlung || Weitergabe personenbezogener Daten an Dritte oder in Drittstaaten. || DS
|-
| Drittland || Staat außerhalb der EU oder des EWR mit abweichenden Datenschutzregeln. || DS
|-
| Datentransparenz || Information der Betroffenen über die Datenverarbeitung. || DS
|-
| Data Protection Officer (DPO) || Englischer Begriff für Datenschutzbeauftragte (DSB). || DS
|-
| Verarbeitung || Jede Handlung mit personenbezogenen Daten, z.B. Erhebung, Speicherung, Nutzung. || DS
|-
| Speicherbegrenzung || Daten dürfen nur so lange gespeichert werden, wie es für den Zweck notwendig ist. || DS
|-
| Datenschutz-Impact-Assessment (DPIA) || Dokumentierte Risikoanalyse der Datenverarbeitung. Synonym für DSFA. || DS
|-
| Privacy by Default || Datenschutzfreundliche Voreinstellungen bereits beim Systemstart. || DS
|-
| Profiling || Automatisierte Auswertung von Daten zur Bewertung von Personen. || DS
|-
| Datenportabilität || Recht der Betroffenen, Daten in maschinenlesbarer Form zu erhalten. || DS
|-
| Verschlüsselung || Technische Maßnahme zur Sicherung der Vertraulichkeit von Dateninhalten. || IS, IT, DS
|-
| Audit || Prüfung der Einhaltung von Standards, Richtlinien und Regelungen. || IS, IT, DS
|-
| Datenschutzrichtlinie || Interne oder externe Vorgabe für den Datenschutz. || DS
|-
| Einwilligungserklärung || Schriftliche Zustimmung der betroffenen Person. || DS
|-
| Informationspflicht || Pflicht, Betroffene über Datenverarbeitung zu informieren. || DS
|-
| Datenschutzrisiko || Gefahr für Rechte und Freiheiten der Betroffenen durch Datenverarbeitung. || DS
|-
| Datenleck || Unbeabsichtigte Offenlegung von personenbezogenen Daten. || DS, IS
|-
| Direktmarketing || Werbung, die direkt an Betroffene gerichtet ist. || DS
|-
| Datenschutzorganisation || Struktur in Unternehmen zur Umsetzung der Datenschutzvorgaben. || DS
|-
| Löschkonzept || Strategie zur zeitgerechten Löschung von Daten. || DS
|-
| Rechtsgrundlage || Gesetzliche Erlaubnis z.B. zur Datenverarbeitung. || DS, IS
|-
| Übermittlungsvorbehalt || Erlaubnisvorbehalt für grenzüberschreitende Datenübermittlung. || DS
|-
| Datenschutzmanagement || Steuerung aller Datenschutzmaßnahmen in einer Organisation. || DS
|-
| Einwilligungswiderruf || Recht der Betroffenen, ihre Zustimmung zu widerrufen. || DS
|-
| Mitarbeiterdatenschutz || Schutz personenbezogener Daten von Beschäftigten. || DS
|-
| Personenstand || Daten zur Person wie Geburtsdatum, Familienstand, etc. || DS
|-
| Datenschutzgrundsätze || Prinzipien der DSGVO wie Rechtmäßigkeit, Zweckbindung und Transparenz. || DS
|-
|Lateralbewegung
|Technik, mit der Angreifer innerhalb eines Netzwerks seitwärts zu weiteren Hosts oder Ressourcen fortschreiten.
|IS, IT
|-
|XAI-Techniken
Explainable AI
|Erhöhung der Nachvollziehbarkeit und Transparenz von KI-Modellentscheidungen, insbesondere bei Black-Box-Modellen wie neuronalen Netzen.
|IS, DS
|-
|SHAP
|SHapley Additive exPlanations
Basierend auf der Spieltheorie (Shapley-Werte) quantifiziert SHAP den durchschnittlichen Beitrag jedes Features zu einer Vorhersage – lokal für Einzelfälle oder global für das gesamte Modell. Es gewährleistet Konsistenz und Lokale Genauigkeit, ist jedoch rechenintensiv.
|IS, DS
|-
|LIME
|Local Interpretable Model-agnostic Explanations
Erstellt lokal um eine spezifische Vorhersage ein einfaches, interpretierbares Ersatzmodell (z.B. lineare Regression), indem Eingabedaten perturbierend verändert werden. Modell-agnostisch, schnell einsetzbar, aber potenziell instabil je nach Perturbation.
|IS DS
|-
|SSP
|System Security Plan: Plan zur Beschreibung der Systemumsetzung von Sicherheitskontrollen (Syn.: System-Sicherheitsplan)
|IS
|-
|AP
|Assessment Plan: Bewertungsplan für Audits und Tests (Syn.: Assessment-Plan)
|IS
|-
|AR
|Assessment Results: Bewertungsergebnisse mit Findings und Evidenz (Syn.: Assessment-Results)
|IS
|-
|POA&M
|Plan of Action and Milestones: Maßnahmen- und Meilensteinplan zur Risikobehebung (Syn.: POAM)
|IS
|-
|RMF
|Risk Management Framework: NIST-Rahmenwerk für Risikomanagement
|IS
|-
|FedRAMP
|Federal Risk and Authorization Management Program: US-Cloud-Compliance-Programm mit OSCAL
|IS
|-
|
|
|
|}

[[Kategorie:Artikel]]
[[Kategorie:KMU]]
[[Kategorie:Datenschutz]]

Grundschutz++ Einführung und Aufbau

2026-03-25T06:18:37Z

Dirk: /* Migration bestehender Sicherheitskonzepte */

[[Datei:Teamwork-2198961.png|alternativtext=Zahnrad|rechts|240x240px]]{{#seo:
|title=Grundschutz++ Einführung und Anleitung
|keywords=ISMS, Wiki, BSI Grundschutz++, IT-Grundschutz, BSI-Standard 200-2, Bausteine, OSCAL, JSON, Informationssicherheit, Risikomanagement, Anforderungen
|description=Überblick über den neuen BSI Grundschutz++. Startseite zur Navigation durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.
}}{{SHORTDESC:Grundschutz++ Überblick und Anleitung}}''Dieser Artikel bietet einen schrittweisen Überblick über BSI '''Grundschutz++''' und navigiert durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.''

== Einführung in Grundschutz++ ==
'''Grundschutz++''' ist die 2026 vom BSI eingeführte Weiterentwicklung des IT-Grundschutz-Kompendiums. Es transformiert das bewährte Grundschutz-Konzept in ein vollständig digitales, maschinenlesbares Format mit JSON-basierten Bausteinen und OSCAL-kompatibler Struktur.<blockquote>
''Der aktuelle Stand von Grundschutz++ ist bisher nur sehr eingeschränkt praktisch anwendbar, da einige wesentliche Definitionen und Teile der Methodik noch fehlen. Dazu gehören beispielsweise die Nutzung von Kennzahlen, Blaupausen, Stufen, Schutzbedarf vs. Schutzniveau und die Modellierung.''

''Der Anforderungskatalog liegt zwar im OSCAL- und Excel-Format vor, ist ohne eine abgeschlossene und nachvollziehbare Methodik aber nicht sinnvoll anwendbar.''
</blockquote>
=== Wesentliche Neuerungen===
*'''OSCAL/JSON-basiertes Regelwerk''': Der IT-Grundschutz wird in ein maschinenlesbares '''JSON-Format''' überführt, das teilweise automatisierte Compliance-Prüfungen und Integrationen in bestehende IT-Systeme ermöglicht. Dies ersetzt die bisherigen textbasierten PDFs und Listen.
*'''Prozessorientierte Struktur''': Die neue Version ist modular und objektorientiert aufgebaut, um Redundanzen zu reduzieren und die Dokumentationslast zu verringern.
*'''Leistungskennzahlen''': Kennzahlen sollen die Informationssicherheit messbar und den Sicherheitsgewinn einzelner Anforderungen transparenter machen.
* '''Harmonisierung mit ISO 27001''': Die Anforderungen werden stärker mit internationalen Standards wie '''ISO 27001:2022''' abgestimmt, um Doppelzertifizierungen zu vereinfachen.
*'''Erweiterung um moderne Technologien''': Geplant sind auch spezifische Module für '''Cloud-Security, KI und IoT''', die aktuelle Bedrohungsszenarien abdecken.
===Ziele der Reform===
*'''Schlankere Prozesse''': Durch Automatisierung soll der administrative Aufwand sinken.
*'''Dynamische Anpassung''': JSON ermöglicht schnellere, ggf. automatisierte Updates bei neuen Cyberbedrohungen.
*'''Praxisorientierte Vereinfachung''': Der BSI will die Dokumentationslast reduzieren und den Fokus auf risikobasierte Ansätze legen, insbesondere für KMU.
*'''Priorisierung und Messbarkeit''': Durch eine stufenweise Priorisierung von Anforderungen und Leistungskennzahlen soll ein zielgerichteteres Vorgehen und die bessere Messbarkeit der Sicherheit gefördert werden.
Die Änderungen reagieren auf Kritik an der bisherigen Komplexität und sollen besonders KMU entlasten, während die ganzheitliche Sicherheitsmethodik (technisch, organisatorisch, personell) erhalten bleibt.

''Hinweis'': Details zur finalen Struktur werden schrittweise im Jahr 2026 veröffentlicht. Unternehmen sollten sich frühzeitig mit den geplanten Schnittstellen (z.B. für Security-Tools) vertraut machen.

Offizieller '''Starttermin''' für den Grundschutz++ war der '''1.1.2026'''. Danach ist allerdings eine längere Übergangsphase (bis 2029) geplant, in der beide Standards parallel genutzt werden können, so wie bei der letzten Modernisierung auch. Da jedoch zu erwarten ist, dass eine automatisierte Migration auch diesmal nicht oder nur eingeschränkt möglich sein wird, sollte speziell in größeren Verbünden rechtzeitig begonnen werden! Der jeweils aktuellen Grundschutz++ Katalog wird auf [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek GitHub] veröffentlicht.
=== Bedeutung von OSCAL im Grundschutz++ ===
Das zugrundeliegende Format für Grundschutz++ ist [[OSCAL]].

[[OSCAL]] ist ein '''Framework''' bzw. eine '''Datenmodellierungssprache''', die vom NIST speziell für Sicherheitsanforderungen und Compliance-Dokumentation entwickelt wurde. OSCAL definiert dabei nur ein festes Schema für Sicherheits- und Compliance-Daten und lässt das zugrundeliegende Datenformat (JSON, XML oder YAML) offen.

Das BSI hat sich beim Grundschutz++ für das Datenformat '''JSON''' entschieden.

Dies ermöglicht es mit entsprechenden Tools Sicherheitsanforderungen automatisiert einzulesen und zu bearbeiten. D.h.

* Anforderungen können (teil-)automatisiert von entsprechenden Tools bearbeitet und dokumentiert werden, sofern entsprechende Tools zur Verfügung stehen oder vom Anwender (ggf. Dienstleister) programmiert werden.
* Kataloge und Sicherheitskonzepte (SSPs) können zwischen ISMS-Tools herstellerunabhängig ausgetauscht werden (sofern Toolhersteller sich an den Standard halten und entsprechende Im- und Exportfonktionen in ihren Tools zur Verfügung stellen).

Das heißt aber nicht:

* Das Anwender, Sicherheitsmanager oder Sicherheitsbeauftragte OSCAL lernen müssen oder OSCAL Formate lesen können müssen. (Dafür gibt es Tools, die die Inhalte lesbar und bearbeitbar zur Verfügung stellen)
* Das alle Anforderungen automatisiert erfüllt und dokumentiert werden (viele Anforderungen sind nach wie vor organisatorische Anforderungen die nur von Menschen durch Erstellung und Beachtung entsprechenden Regelungen erfüllt werden können).
* Das überhaupt irgendwelche Anforderungen automatisiert erfüllt und dokumentiert werden (Hierzu müssten die Systeme an ein ISMS-Tool angebunden sein und diese über entsprechende Schnittstellen mit Informationen bedienen). Sowohl die Tools als auch die Schnittstellen werden absehbar nicht vom Himmel fallen.
===Satzschablonen===
Anforderungen werden im Grundschutz++ zukünftig mit Satzschablonen erstellt, die wie folgt aussehen:<blockquote><big>'''<span style="color:green">{Praktik} [für {Zielobjekt}]</span> <span style="color:red">{MODALVERB}</span> <span style="color:blue"><Ergebnis></span> <span style="color:purple">{Handlungswort}</span>''' ''<span style="color:grey">(TAGs) (Hinweise)</span>''</big></blockquote>'''Praktik''': Ein Prozess im Rahmen des ISMS, eine konkrete Sicherheitsmaßnahme oder eine allgemeine Vorgehensweise zur Erreichung eines Sicherheitsziels (z.B. IT-Betrieb, Personal, Konfiguration) - Im weitesten Sinne vergleichbar mit den bisherigen Bausteinen. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/praktiken.csv Liste der gültigen Praktiken.]

'''Zielobjekt''': Wie bisher, das Objekt oder die Entität, auf die sich die Sicherheitsanforderungen beziehen (z.B. Daten, Personen, Endgeräte, Hostsysteme). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/zielobjektkategorien.csv Liste der Gültigen Zielobjekte.]

'''Modalverb''': Gibt die Verbindlichkeit einer Anforderung an (MUSS, SOLLTE, KANN).

'''Ereignis''': Der sicherheitsrelevante Zustand oder Auslöser, der zu einer bestimmten Handlung führt - Entspricht in Verbindung mit dem Handlungswort dem wesentliche Inhalt der Anforderung.

'''Handlungswort''': Das Verb, das die konkrete Sicherheitsmaßnahme oder Art der Tätigkeit beschreibt (regeln, zuweisen, konfigurieren). Handlungsworte können auch zur besseren Filterung genutzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/handlungsworte.csv Liste der gültigen Handlungsworte.]

Das ganze kann noch mit '''TAG'''s für eine bessere Gruppierung und mit einem '''Hinweis''' zu weiterführenden Informationen ergänzt werden.

Die bisherigen Anforderungen des Kompendium werden aktuell in ihre Teilanforderungen zerlegt und jede Teilanforderung wird zukünftig eine eigene Anforderung. D.h. jedes Modalverb (SOLL, MUSS, KANN) der bisherigen Anforderungen stellt zukünftig i.d.R. eine eigene Anforderung dar. Die Gesamtanzahl der Anforderungen soll dabei durch die Vermeidung von Redundanzen dennoch sinken.

'''Beispiel'''

Die Anforderung:<blockquote>'''ISMS.1.A4 Benennung eines oder einer Informationssicherheitsbeauftragten (B) [Institutionsleitung]'''

Die Institutionsleitung MUSS einen oder eine ISB benennen. '''. . .'''

Die Institutionsleitung MUSS den oder die ISB mit angemessenen Ressourcen ausstatten.

Die Institutionsleitung MUSS dem oder der ISB die Möglichkeit einräumen, bei Bedarf direkt an sie selbst zu berichten. '''. . .'''</blockquote>Wird jetzt zu den Anforderungen:<blockquote>'''GOV.4.2''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">einer Person die Rolle ISB</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.2.3''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">für das ISMS erforderliche personelle, finanzielle und zeitliche Ressourcen</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.4.4''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">dem ISB das direkte und jederzeitige Vorspracherecht bei der Institutionsleitung</span> '''<span style="color:purple">ermöglichen</span>.'''</blockquote>Da dies übergreifende Anforderungen sind, ist hier kein spezifisches Zielobjekt benannt.

Einzelne Teilanforderungen können auch in anderen Praktiken beschrieben sein.
===Priorisierung===
Alle Anforderungen werden einer Prioritätsstufe zugeordnet, um die Umsetzung effizient zu gestalten:
*'''Stufe 0''': Zwingend (sofort) umzusetzende Anforderungen zur Sicherstellung der ISO-Kompatibilität (MUSS-Anforderungen).
Die Stufen 1-4 geben den Umsetzungsaufwand der Anforderungen wieder:
*'''Stufe 1''': Schnell und mit geringem Aufwand (~1 Tag) realisierbare Maßnahmen (QuickWin) / keine laufenden Aufwände.
*'''Stufe 2''': Mit eigenen Mitteln leicht umsetzbare Anforderung (~1 Woche) / geringe laufende Aufwände.
*'''Stufe 3''': Mit normalem Aufwand (mehrere Wochen) und ggf. externer Unterstützung umsetzbar / normale laufende Aufwände.
*'''Stufe 4''': Höherer Umsetzungsaufwand, häufig in längerfristigen Projekten mit externen Experten.
Die nächste Stufe sind optionale Anforderungen als Vorschläge bei erhöhtem Schutzbedarf.
*'''Stufe 5''': Umfassende/zusätzliche Anforderungen für höheren Schutzbedarf.
Diese Einstufung ermöglicht eine schnelle Einschätzung des Umsetzungsaufwands und hilft bei der effizienten Ressourcenplanung.
===Leistungskennzahlen===
Leistungskennzahlen dienen der '''Messung und Bewertung''' der Umsetzung von Sicherheitsanforderungen im Grundschutz++. Sie ermöglichen eine objektive Einschätzung des Sicherheitsniveaus und unterstützen die kontinuierliche Verbesserung. Wie diese Leistungskennzahlen genutzt werden sollen ist nach wie vor unklar und viele Anforderungen sind bislang noch nicht bewertet.
====Bewertungskriterien====
Jede Anforderung wird in Bezug auf die drei Schutzziele bewertet:
*'''Vertraulichkeit (C)'''
*'''Integrität (I)'''
*'''Verfügbarkeit (A)'''
Anforderungen erhalten Punktwerte in diesen Kategorien, die zur Bestimmung des Schutzgrades genutzt werden (z.B. C=6, I=2, A=0 ist eine Anforderung die im Wesentlichen die Vetraulichkeit stärkt, in Teilen die Intgrität aber nicht die Verfügbarkeit).

Die einzelen Kennzahlen werden je Schutzziel, Praktik und/oder Zielobjekt aufsummiert und ergeben so den Erfüllungsgrad.
====Schwellwerte und Erfüllungsgrad====
*'''Schwellwerte''' definieren das angestrebte Sicherheitsniveau basierend auf der Summe der Punktwerte aller umgesetzten Anforderungen je Schutzziel, Zielobjekt und Schutzstufe.
*'''Der Erfüllungsgrad''' zeigt, welche Anforderungen bereits umgesetzt wurden.
Die Leistungskennzahlen bieten damit eine fundierte Entscheidungsgrundlage für Organisationen, um ihren Sicherheitsstatus gezielt zu verbessern, wenn sie wie ursprünglich geplant eingeführt werden.
==Was bleibt erhalten?==
===Standards und Vorgehen===
Trotz eines deutlich anderen Formats und einer anderen Gruppierung der Anforderungen bleibt das grundsätzliche Vorgehen weitgehend gleich.

D.h. die Standards 200-1 bis 200-4 sollen erst einmal weiter Verwendung finden. Die bisher üblichen Arbeitsschritte:
#Festlegung des Geltungsbereichs
#Strukturanalyse
#Schutzbedarfsfeststellung
#Modellierung
#IT-Grundschutzcheck (GSC)
#Risikoanalyse
bleiben grundsätzlich erhalten, ändern sich jedoch in der praktischen Anwendung und Priorität (insbesondere in der '''Modellierung''' und den '''Grundschutzchecks'''). Parallel zur Einführung sollen die Standards weiter entwickelt werden.

'''MUSS'''-Anforderungen sind weiterhin '''verpflichtend''' für eine Zertifizierung, sollen aber deutlich rediziert werden.

'''SOLLTE'''-Anforderungen bleiben auch weiter '''grundsätzlich verpflichtend''', können aber ggf. mit angemessener Begründung oder Ersatzmaßnahmen wegdiskutiert werden.

Lediglich '''KANN'''-Anforderungen sind optional.
===Tool-Einsatz===
Auch der Einsatz von ISMS-Tools wird weiterhin Bestand haben. Alle größeren Tool-Hersteller arbeiten mit Hochdruck an der Integration von Grundschutz++ in ihre Tools. Hier wird es perspektivisch Erleichterungen durch einen leichteren Datenaustausch zwischen den Tools und mehr Automatisierungspotential geben.
==Gegenüberstellung Grundschutz Kompendium vs. Grundschutz++==
Das IT-Grundschutz-Kompendium 2023 und der zukünftige Grundschutz++ bieten unterschiedliche Konzepte für die Umsetzung von Informationssicherheit: Während das Kompendium auf feste Bausteine in thematisch gegliederten Schichten setzt, verwendet Grundschutz++ modulare, flexibel einsetzbare Praktiken.

Die folgende Tabelle stellt die wesentlichen Unterschiede und Gemeinsamkeiten zwischen beiden Ansätzen (nach aktuell verfügbaren Kenntnissen) gegenüber:
{| class="wikitable"
|+
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Fester verbindlicher Katalog''' von Anforderungen (PDF, Excel und XML), die je nach Reifegrad erfüllt werden müssen.
|Der '''variable''' und erweiterbare '''[[OSCAL]]'''-Datenbestand kann beliebig an die Bedürfnisse der Organisation angepasst werden. Zusätzliche Kataloge/Erweiterungen (C5, Datenschutz, KRITIS/NIS2) können je nach Verfügbarkeit ergänzt werden. Durch die Beseitigung vermeintlicher Redundanzen soll die Anzahl der Anforderungen erheblich reduziert werden (~10–20 % verbleibende Anforderungen gegenüber dem Grundschutz Kompendium).
|-
|
|Järliche '''Aktualisierung''' zum Stichtag '''1. Februar'''.
(bis 2023)
|Die '''Aktualisierung''' erfolgt '''fortlaufend''' nach Bedarf und Verfügbarkeit. Die Regelungen zur Relevanz für Zertifizierungen sind bislang noch nicht bekannt.
|-
|
|Das Kompendium ist (Stand 2023) in 10 '''Schichten''' mit insgesamt 111 '''Bausteine''' gegliedert, die statisch die jeweiligen Anforderungen enthalten.
|'''Praktiken''' und '''''Zielobjekte/Zielobjektkategorien''''' (Achtung abweichende Bedeutung in GS++) sind allgemeinere und wiederverwendbare, sicherheitsrelevante Verfahren oder Maßnahmen. Sie können modular und situationsabhängig einzelnen Assets zugeordnet werden.
Die voraussichtlich ca. 20 Praktiken liegen irgendwo zwischen Schichten und Bausteinen. Sie sind prozessorientierter, adressieren eher Zielgruppen oder Handlungstypen und sind nicht mehr starr bestimmten Zielobjekten zugeordnet. Zielobjekte entsprechen zukünftig eher den Bausteinen im alten Grundschutz. Die Definitionen der Begriffe sind nach wie vor unklar!
|-
|
|'''Drei Stufen''' (Vorgehensweisen): Basis, Standard, erhöhter Schutzbedarf bilden den Reifegrad der Organisation ab.
|Es sind zukünftig '''sechs Stufen''' (0–5) geplant, die sich weitgehend am Umsetzungsaufwand der jeweiligen Anforderung orientieren: Je kleiner die Stufe, desto schneller bzw. leichter ist die Anforderung umsetzbar (Quick Win). Eine qualitative Bewertung des Reifegrads muss zukünftig anders erfolgen (z. B. über Leistungskennzahlen).
Das '''Sicherheitsniveau''' gibt zukünftig an, in welchem Maß die definierten Sicherheitsziele erreicht sind. Es ergibt sich aus der wirksamen Umsetzung organisatorischer, technischer und personeller Anforderungen.

Unterschieden werden:
*'''Normales Sicherheitsniveau''': entspricht dem Stand der Technik
*'''Erhöhtes Sicherheitsniveau''': für besonders schutzbedürftige Informationen oder Systeme
|-
|
|'''Zielobjekte''' als gruppierte Sammlung von gleichartigen Assets die zur späteren '''Modellierung''' (Zuordnung der Bausteine und Abhängigkeiten) genutzt werden.
|'''Zielobjekte''' werden auch in Zukunft eine ähnliche Funktion zur Gruppierung und '''Modellierung''' haben, entsprechend dabei aber eher den klassischen Bausteinen. Die konkreten Vorgaben zur Modellierung sind jedoch noch nicht detailliert genug. In der Modellierung werden die Praktiken nicht mehr statisch bestimmten Zielobjekttypen zugewiesen. Klassische Zielobjekte werden zukünftig als Assets oder Assetgruppen bezeichnet.
|-
|
|Modalverben '''MUSS''', '''SOLLTE''', '''KANN''' bestimmen die Verbindlichkeit von Anforderungen.
|Die Bedeutung der Modalverben ('''MUSS, SOLLTE, KANN''') bleibt unverändert. Ein Ziel von Grundschutz++ ist es jedoch, die Anzahl der Muss-Anforderungen auf das Nötigste zu reduzieren (unter 10 %). Dadurch soll der Grundschutz flexibler werden. Die Verbindlichkeit von Anforderungen, die über MUSS-Anforderungen hinausgehen, ist noch unklar.
|-
|
| -
|Neu sind '''Leistungskennzahlen''', die eine qualitative Bewertung der Anforderungen in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit darstellen. Sie sollen als Zahlenwert darstellbar sein und so den Reifegrad abbilden können. Bisher ist noch nicht bekannt, ob und wann diese eingeführt werden und wie die konkreten Regelungen aussehen werden.
|-
|
|Gültigkeit voraussichtlich bis 2029
|Gültig ab 1.1.2026. Zertifizierbar geplant ab 2027.
|}Teilweise werden Begrifflichkeiten neu (oder anders) definiert:
{| class="wikitable"
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Zielobjekt''' als gruppierte Sammlung von gleichartigen Assets als Grundlage für die spätere Modellierung
|'''Asset''' und gruppierte Assets. Die Gruppierung gleichartiger Assets kann weiterhin erfolgen es bleiben jedoch auch dann '''Assets'''. Der Begriff ''Zielobjekt'' wird hierfür nicht mehr genutzt.
|-
|
|'''Baustein''' als Sammlung von Anforderungen für bestimmte Zielobjekttypen.
|'''Zielobjekt''' sind zukünftig das was bislang die ''Bausteine'' waren, bestimmte Typen von Assets für die spezische Anforderungen gelten. Die Assets werden den Zielobjekten zugewisen und erhalten über diese ihre Anforderungen. Eine klare Definition der Begriffe steht noch aus.
|-
|
|
|
|}
==Blaupausen==
Blaupausen sind vorgefertigte Musterlösungen (wie die bisherigen IT-Grundschutz-Profile), die als Vorlage (Referenzmodell) für die Erstellung und Umsetzung von branchenspezifischen oder organisationsspezifischen Sicherheitskonzepten dienen.
===Funktion der Blaupausen===
Solche Blaupausen erfassen typische Strukturen, Risiken, Anforderungen und Maßnahmen für bestimmte Anwendungsszenarien, etwa die Nutzung der E-Akte oder den sicheren Betrieb von 5G-Infrastrukturen. Sie ermöglichen es, ein ISMS deutlich effizienter und strukturierter aufzubauen, weil die grundlegenden Überlegungen (Schutzbedarfsermittlung, Zuordnung von Praktiken, Zielobjekten und Maßnahmen, etc.) bereits allgemein gültig vorformuliert sind und nur noch organisationsspezifisch angepasst werden müssen.
===Ziel und Nutzen===
*Blaupausen helfen, den Implementierungsaufwand für ISMS nach Grundschutz++ zu reduzieren.
*Sie fördern die Standardisierung und Wiederverwendbarkeit von Sicherheitskonzepten für ähnliche Organisationen oder Branchen.
*Besonders für kleinere Organisationen und typische Anwendungsfälle bieten sie einen niederschwelligen, strukturierten und praxiserprobten Einstieg in die Absicherung.
Damit sind Blaupausen im Grundschutz++ zentrale Instrumente, um bewährte Sicherheitsmethoden als Vorlage für den schnellen und einheitlichen Aufbau eines branchenspezifischen ISMS bereitzustellen.
===Umsetzung===
Umgesetzt werden Blaupausen technische als '''OSCAL-Profile''' mit zusätzlichen Erläuterungen in Textform, zukünftig sollen Blaupausen zu einem '''System Security Plan (SSP)''' weiter entwickelt werden.
== Grundlagen und Standards ==

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_1.html BSI-Standard 200-1: Anforderungen an ein ISMS].
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_2.html BSI-Standard 200-2: IT-Grundschutz Methodik] ( <- Wird neu erstellt )
** Methodik zum Grundschutz++ (Aktuell in Erstellung, ersetzt 200-2)
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_3.html BSI-Standard 200-3: Risikomanagement mit Grundschutz].
* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/BSI-Standards/BSI-Standard-200-4-Business-Continuity-Management/bsi-standard-200-4_Business_Continuity_Management_node.html BSI-Standard 200-4: Business Continuity Management].
* [[OSCAL|OSCAL (Open Security Controls Assessment Language)]].

== Schritt-für-Schritt-Methodik ==
Die Methodik zum Grundschutz++ folgt einem '''5-stufigem PDCA-basierten Prozess''' mit Fokus auf '''Anforderungsmodellierung''' und '''maschinenlesbarer Verarbeitung'''. Hier das praktische Vorgehen:

=== Schritt 1: Erhebung und Planung (PLAN - Governance/Compliance) ===
# '''Kontextanalyse''' (intern/extern) durchführen
# '''Interessierte Parteien''' identifizieren und Anforderungen erfassen
# '''Geltungsbereich''' (Scope) durch Institutionsleitung festlegen und freigeben
# '''Geschäftsprozesse''' priorisieren → Schutzbedarf "normal" oder "hoch" einstufen
# '''Sicherheitsleitlinie''' erstellen (Ziele, Strategie, Verpflichtung Leitung)
# '''Sicherheitsorganisation''' etablieren (Rollen: ISB, Asset-Owner, etc.)
# '''Compliance-Management''' initialisieren (Rechts-/Vertragskatalog)

'''Ergebnis''': Organisatorischer Rahmen, Sicherheitsleitlinie, priorisierte Prozesse

'''Weiterführende Informationen:'''

* [[Informationssicherheitsleitlinie]]
* [[IS-Strategie]]
* [[Geschäftsprozesse]]

=== Schritt 2: Anforderungsanalyse (PLAN - Strukturmodellierung) ===
# '''Informationsverbund''' definieren (techn./org. Abgrenzung)
# '''Assets''' für wichtigsten Geschäftsprozess erfassen
# '''Asset → Zielobjektkategorien''' mapping (Hierarchie + Vererbung)
# '''Anforderungspaket''' generieren:
#* ISMS-Praktiken (vollständig)
#* Zielobjekt-Anforderungen (Sicherheitsniveau: normal/erhöht)
#* Zielobjektlose Anforderungen prüfen
# '''Ergänzungen''': Externe Verpflichtungen, anforderungslose Assets
# '''Risikobetrachtung''' bei hohem Schutzbedarf oder Niveauerhöhung
# '''Parameter setzen''' (Zuständigkeiten, Werte)

'''Ergebnis''': Individuelles Anforderungspaket pro Informationsverbund

'''Weiterführende Informationen:'''

* [[Strukturanalyse]]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das OSCAL-basierte Grundschutz++ Kompendium auf Github.]

=== Schritt 3: Realisierung (DO - Umsetzung) ===
# '''Umsetzungsstatus''' aller Anforderungen prüfen (ja/nein)
# '''Nicht-umgesetzte MUSS/SOLLTE''' → Risikobetrachtung
# '''Umsetzungsplan''' erstellen:
#* Priorisierung (Risiko, Aufwand, Synergien)
#* Zuständigkeiten + Fristen zuweisen
# '''Freigabe''' durch Institutionsleitung
# '''Fortschritt tracken''' (Ticketsystem/Projektmanagement)
# '''Ausnahmen dokumentieren''' (Begründung + Leitungsfreigabe)

'''Ergebnis''': Umsetzungsplan + Status-Dokumentation

'''Weiterführende Informationen:'''

* [[LF-Grundschutzcheck|Leitfaden Grundschutzcheck]]
* [[RiLi-Freigabe]]
* [[RiLi-Ausnahmemanagement|Richtlinie zum Management von Ausnahmen und Abweichungen]]

=== Schritt 4: Überwachung (CHECK - Monitoring/Evaluation) ===
# '''Leistungsbewertung''' (KPIs, Umsetzungsfortschritt, Vorfälle)
# '''Compliance-Überwachung''' (gesetzlich/vertraglich)
# '''Auditprogramm''' risikobasiert durchführen
# '''Managementbewertung''' → Managementbericht erstellen
# '''Monitoring-Tools''' einsetzen (SIEM, Vulnerability Scanner)
# '''Anforderungspaket validieren''' (Aktualität prüfen)

'''Ergebnis''': Auditberichte, Managementbericht

'''Weiterführende Informationen:'''

* [[Reifegradmodell]]
* [[KPIs|Key Performance Indicators (KPIs)]]
* [[Managementbericht|Erstellen eines Managementberichts]]

=== Schritt 5: Kontinuierliche Verbesserung (ACT - Verbesserung) ===
# '''Nicht-Konformitäten''' analysieren
# '''Verbesserungspotenziale''' identifizieren
# '''Korrektur-/Verbesserungsplan''' → in Umsetzungsplan integrieren
# '''Wirksamkeit prüfen''' nach Umsetzung
# '''Sicherheitsniveau''' bewerten (Trendanalyse)
# '''Compliance-Verstöße''' behandeln

'''Ergebnis''': Aktualisiertes Anforderungspaket → neuer PDCA-Zyklus

'''Weiterführende Informationen:'''

*

=== Praktische Hinweise ===
* '''Tool-gestützt''': JSON/OSCAL-Bausteine, Zur Nutzung sind ISMS-Tools empfohlen.
* '''Iteration''': Wichtigster Geschäftsprozess zuerst, dann schrittweise erweitern
* '''Risikobetrachtung''': Bei Sicherheitsniveau "hoch" oder Nicht-Umsetzung
* '''Dokumentation''': bevorzugt Maschinenlesbar (OSCAL) für besseren Austausch

'''Zyklusdauer''': Jährlich oder ereignisgesteuert (Änderungen, Vorfälle, Audits)

== Migration bestehender Sicherheitskonzepte ==
...

'''Weiterführende Informationen:'''

[[Grundschutz++ Migration]]

== Offenen Punkte und Kritiken ==

=== Zu viele Beteiligte, unklare Zuständigkeiten ===
Die Weiterentwicklung des Grundschutzes wird inzwischen nicht mehr ausschließlich vom Grundschutz-Referat des BSI verantwortet. Mit dem Einstieg des Referats „Stand der Technik“ und der verstärkten Einbindung der „Community“ sind die Zuständigkeiten und Verantwortlichkeiten unklarer geworden. In Präsentationen und Veröffentlichungen werden die Rollen und Aufgaben der verschiedenen Beteiligten unterschiedlich dargestellt. Es fehlt eine klare, kommunizierte Schnittstelle, wer für welche Aspekte der Entwicklung, Pflege und Kommunikation des neuen Standards verantwortlich ist. Das erschwert für Anwendende die Orientierung und die Planung der eigenen Umsetzungsstrategie.

=== Unklare Umsetzung einiger Ziele ===
Einige der im Grundschutz++ adressierten Ziele und Neuerungen sind nach wie vor nicht ausreichend konkretisiert. Besonders die Einführung von Leistungskennzahlen und die Priorisierung der Anforderungen (Stufen) werfen noch viele Fragen auf. Die konkrete Bedeutung, Messung und praktische Umsetzung dieser Leistungskennzahlen werden von verschiedenen BSI-Vertretern unterschiedlich dargestellt. Auch die Stufenmodelle werden teils als Priorisierung, als Entwicklungsstufen oder als reiner Umsetzungaufwand der Anforderungen definiert und sind in ihrer praktischen Anwendung noch nicht abschließend geklärt. Das führt zu Unsicherheiten, wie diese neuen Instrumente im einem ISMS umgesetzt und nachgewiesen werden sollen.

=== Geringer Mehrwert im Vergleich zu ISO 27001 ===
Die Anforderungen im Grundschutz++ werden zunehmend an die Formulierungen und Strukturen der ISO 27001 angeglichen. Während der klassische IT-Grundschutz durch seine konkreten, praxisnahen Maßnahmen einen klaren Mehrwert gegenüber der eher abstrakten ISO 27001 bot, verliert er durch die Harmonisierung mit internationalen Standards zunehmend diesen Vorteil. Die Anforderungen werden stärker abstrakt modularisiert formuliert, wodurch der spezifische Bezug zu typischen Umsetzungsbeispielen und die Detailtiefe abnehmen. Für viele Organisationen wird sich daher die Frage stellen, warum sie den immer noch aufwändigeren Weg über den Grundschutz wählen sollten, wenn sie mit ähnlichem oder geringeren Aufwand direkt eine ISO 27001-Zertifizierung anstreben können.

=== Zu ambitionierter Zeitplan ===
Der Grundschutz++ sollte ab dem 1.1.2026 grundsätzlich gültig und anwedbar sein, wobei eine Übergangsphase bis 2029 vorgesehen war. Bisher ist nur ein erster Entwurf veröffentlicht. Angesichts der Vielzahl an noch offenen Fragen, der fehlenden Migrationsstrategie und der Komplexität der Änderungen erscheint der Zeitplan sehr ambitioniert. Ausarbeitung und Dokumentation liegen bisher nur als Entwurf vor. Eine Pilotierung und Einführung 2026 und eine Übergangsphase bis 2029 ist vorgesehen. Die Gefahr besteht, dass größere Organisationen unter Zeitdruck unzureichend vorbereitet in die neue Methodik wechseln und mit variablen Definitionen und Zielen arbeiten müssen, was die Akzeptanz und Qualität der Umsetzung gefährdet.

=== Zunehmende (Sicherheits-)Lücke zwischen Grundschutz und Grundschutz++ ===
Mit der Entscheidung des BSI, den bisherigen IT-Grundschutz (Edition 2023) nicht mehr weiterzuentwickeln und stattdessen auf das neue Grundschutz++-Modell zu setzen, entsteht eine wachsende Lücke in der Informationssicherheit. Diese Übergangsphase bis 2029 ist sicherheitstechnisch kritisch, da sich die Bedrohungslage in der IT nicht an Entwicklungszyklen von Sicherheitsstandards orientiert. Neue Angriffsvektoren, insbesondere durch den zunehmenden Einsatz von KI in der Cyberkriminalität (z.B. KI-gestützte Malware, Deepfakes, automatisierte Phishing-Kampagnen), entstehen kontinuierlich und erfordern zeitnahe, wirksame Gegenmaßnahmen. Der bisherige Grundschutz bildet diese aktuellen Bedrohungen und technologische Entwicklungen jedoch nicht mehr ab, während die spezifischen Module und Maßnahmen im Grundschutz++ noch nicht produktiv verfügbar oder praxistauglich sind.

=== Fehlende Migration vom Grundschutz-Kompendium zu Grundschutz++ ===
Aktuell existiert weder ein konkreter Plan noch ein Konzept für eine (teil-)automatisierte Migration bestehender Sicherheitskonzepte aus dem bisherigen Grundschutz-Kompendium in das neue Grundschutz++-Modell. Die Umstellung auf ein maschinenlesbares JSON/OSCAL-Format und die objektorientierte, prozessorientierte Struktur bedeuten einen fundamentalen Bruch mit bisherigen Strukturen. Die Unterschiede zwischen Grundschutz-Kompendium und Grundschutz++ sind gravierender als beim letzten Wechsel von den Grundschutz-Katalogen zum Kompendium, bei dem bereits alle Ansätze für eine automatisierte Migration weitgehend gescheitert sind. Auch diesmal ist absehbar, dass Organisationen ihre bestehenden Dokumentationen und Umsetzungen weitgehend manuell neu abbilden müssen, was insbesondere für größere Verbünde einen erheblichen Zusatzaufwand bedeutet. Es gibt zwar Ansätze dies mittels KI zu lösen, was aber sicher nicht für jede Organisation praktikabel sein wird.

== Fazit ==
Ein abschließendes Bild zum Grundschutz++ lässt sich aktuell noch nicht zeichnen – viele Details sind noch in der Entwicklung.

Die grundlegende Modernisierung des IT-Grundschutzes durch das Grundschutz++-Projekt ist zwar fachlich und technologisch nachvollziehbar und adressiert viele Schwächen des bisherigen Systems. Die Umsetzung ist jedoch nach jetzigem Entwicklungsstand mit erheblichen Risiken und Unsicherheiten verbunden. Ohne klare Migrationspfade, eindeutige Zuständigkeiten und praxistaugliche Konkretisierungen der neuen Instrumente besteht die Gefahr, dass die Akzeptanz des Grundschutzes sinkt und Organisationen sich vermehrt alternativen Standards wie der ISO 27001 zuwenden. Ein realistischer Zeitplan und ein echter Mehrwert des neuen Standards sind daher essenziell für den Erfolg der Reform.

Der Artikel wird fortlaufend aktualisiert, sobald neue Informationen vom BSI veröffentlicht oder freigegeben werden.
===Ausblick und ToDos aus Anwendersicht===
Stichtag für die Einführung von Grundschutz++ war der '''1.1.2026'''. Das Datum wurde vom BSI in offiziellen Ankündigungen, Präsentationen und Fachveranstaltungen als verbindlicher Startpunkt kommuniziert. Ab diesem Zeitpunkt sollte das neue, digitale und prozessorientierte Regelwerk den bisherigen IT-Grundschutz ablösen. Bisher fehlt es jedoch an vielen Stellen an klaren Definitionen und konkreten Vorgaben zur Methodik.

Auch wenn abzuwarten bleibt, wann praxistaugliche Methoden verfügbar sind und wie lange die Übergangsfristen für die Umstellung sein werden (aktuelle Planung bis 2029). Abzusehen ist jedoch, dass der Aufwand und der Zeitdruck, insbesondere für größere und zertifizierte Verbünde, erheblich sein werden. Auch wenn es aktuell noch keine konkreten Beschreibungen zur Methodik und Modellierung gibt, können und sollten sich Anwender bereits jetzt vorbereiten. Dazu können die folgenden Maßnahmen dienen:
*Laufende Information über den aktuellen Stand (Internetseiten des BSI, Vorträge und Veröffentlichungen).
*Konsolidierung der bestehenden Verbünde (Reduzierung der Komplexität, konsistente Dokumentation der Gruppierung und Modellierung).
**Ein guter Tip ist es, in aktuellen GSC jede Teilanforderung (jedes Modalverb wie MUSS oder SOLLTE) in der Umsetzung einzeln zu dokumentieren, da diese zukünftig eigenständige Anforderungen darstellen und so eine Übernahme leichter werden könnte.
*Kontakt zu Toolherstellern aufnehmen und eine zügige Umsetzung in den verwendeten ISMS-Tools einfordern.
*Frühzeitige Planung der Bereitstellung entsprechender personeller Ressourcen für die Umstellung auf Grundschutz++ ab Mitte 2026.
*Gegebenenfalls frühzeitige Reservierung externer (personeller) Ressourcen zur Unterstützung.
*Es muss eine klare interne Kommunikation über die bevorstehenden, durch die Umstellung bedingten erhöhten Aufwände (Schulungen, neue (Erst-)GSCs und Anpassung der Dokumentation) geben, damit Mitarbeitende und Verantwortliche wissen, was auf sie zukommt.

== Weiterführende Ressourcen ==
*[https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html BSI IT-Grundschutz]
*[https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/Grundschutz/1GS_Tag_2025/Aktuelle_Entwicklungen_Ausblick_IT-GS.pdf Aktuelle Entwicklungen und Ausblick zum IT-Grundschutz - 1. Grundschutztag 2025]
*[https://www.youtube.com/watch?v=_AeWJ_Z8S-4 Keynote: Fortentwicklung des IT-Grundschutzes zu IT-Grundschutz++ (verinice.XP 2025)]
*[https://www.youtube.com/watch?v=fBXuhELODGA Vortrag: "Keynote und Vision Grundschutz++" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.youtube.com/watch?v=PxOjkV6oUwU Vortrag "Grundschutz++ Methodik und Einstieg ins BCM" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.bsi.bund.de/dok/it-sa Am Mittwoch, 08.10.2025 werden auf der it-sa die von den Arbeitsgruppen aus der Community erarbeiteten Ergebnisse präsentiert.]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]
*[[Grundschutz++ Migration|Migrationsstrategie für den Umstieg von BSI IT-Grundschutz auf Grundschutz++]]
[[Kategorie:Artikel]]
[[Kategorie:Grundschutz]]
[[Kategorie:++]]

Grundschutz++ Schutzbedarf

2026-03-24T17:21:05Z

Dirk:

{{Entwurf}}
[[Datei:Teamwork-2198961.png|alternativtext=Zahnrad|rechts|240x240px]]{{#seo:
|title=Durchführung einer Schutzbedarfsfeststellung
|keywords=Schutzbedarfsfeststellung, BSI Standard 200-2, ISMS, Vertraulichkeit, Integrität, Verfügbarkeit, Schutzbedarfskategorien, Vererbungsprinzipien, Risikoanalyse, IT-Grundschutz, WiKi
|description=Durchführung einer Schutzbedarfsfeststellung nach BSI IT-Grundschutz, basierend auf Schutzzielen und Schutzbedarfskategorien für Informationen.}}{{SHORTDESC:Durchführung einer Schutzbedarfsfeststellung nach BSI IT-Grundschutz.}}
Ein zentraler Bestandteil bei der Erstellung einer Sicherheitskonzeption nach der Methodik des BSI Grundschutz++ und dem damit verbunden Aufbau eines ISMS ist u.a. die Durchführung einer Schutzbedarfsfeststellung für die zu verarbeitenden Informationen (Prozesse).

Die Schutzbedarfsfeststellung muss für jede(n) Geschäftsprozess und/oder Anwendung getrennt durchgeführt werden und der festgestellte Schutzbedarf vererbt sich auf die folgenden Assets (Anwendungen, IT-Systeme, Netze, Räume) die von dem jeweiligen Geschäftsprozess oder der Anwendung genutzt werden.
Der Artikel bezieht sich auf die '''Methodik zum Grundschutz++''' ! Diese Methodik wurde zum 1.1.2026 eingeführt und unterliegt noch einem dynamischen Entwicklungsprozess. Viele Details werden sich voraussichtlich im Laufe des Jahres noch ändern.

== Einleitung und Vorbereitung ==
Die Schutzbedarfsfeststellung bildet einen zentralen Bestandteil des Prozessschritts 1 „Erhebung und Planung“ in der Grundschutz++ Methodik. Sie dient der systematischen Identifikation und Einstufung des Schutzbedarfs relevanter Geschäftsprozesse und darin verarbeiteter Informationen und stellt damit die prozessorientierte Verbindung zwischen betrieblichen Zielen und Informationssicherheitsanforderungen her. Dieser initiale Schritt erfolgt unmittelbar nach der Festlegung des Geltungsbereichs und liefert wesentliche Priorisierungsgrundlagen für die nachgelagerten Schritte der Anforderungsanalyse und Realisierung.

Du identifizierst zunächst alle für den Geltungsbereich maßgeblichen Geschäftsprozesse, indem Du auf bestehende Prozesslandkarten oder Managementsysteme zurückgreifst. Bei fehlender Übersicht greifst du auf organisatorische und technische Praktiken zurück, um Kern- und Hilfsprozesse vollständig zu erfassen.

Im nächsten Teilschritt bewertest Du den Schutzbedarf prozessbezogen anhand der potenziellen Kritikalität von Auswirkungen auf Geschäftsziele oder den gesetzlichen Auftrag Deiner Organisation. Die Einstufung erfolgt zweistufig in „'''normal'''“ (begrenzte Schadensauswirkungen) oder „'''hoch'''“ (erhebliche, potenziell existenzbedrohende Schäden). Diese Einstufung muss später durch die Organisationsleitung freigegeben werden.

Besondere Priorität erhält der geschäftsentscheidende Prozess, dessen Informationsschutz den Fortbestand Deiner Organisation sichert; hier trifft die Organisationsleitung die finale Bewertung. Bei hohem Schutzbedarf ist eine Risikobetrachtung zwingend erforderlich, die externe Vorgaben (z.B. VS-Klassifizierung) einbezieht und als Übersicht über Relevanzstufen dokumentiert wird. Dieser Ansatz gewährleistet eine risikoorientierte Fokussierung auf kritische Bereiche, minimiert Ressourcenaufwand und integriert sich nahtlos in den PDCA-Zyklus des Grundschutz++.

Die Schutzbedarfsfeststellung schafft so Transparenz über Schutzziele und priorisiert nachfolgende Modellierungen effektiv.

== Grundwerte ==
Die Schutzbedarfsfeststellung erfolgt getrennt für die drei Grundwerte:

* '''Vertraulichkeit''': Keine unbefugte Kentnisnahme oder Weitergabe von Informationen.
* '''Integrität''': Die Korrektheit von Informationen und der korrekte Funktionsweise von Systemen.
* '''Verfügbarkeit''': Unbeeinträchtigter Zugriff auf Systeme und Informationen.

Die drei Grundwerte müssen durchgängig getrennt betrachtet werden, da sich diese auch in den Maßnahmen grundlegend unterscheiden.

== Schutzbedarfskategorien ==
Der Grundschutz++ unterscheidet nur noch zwei Schutzbedarfskategorien:

* '''normal''': Der Schutzbedarf „normal“ gilt grundsätzlich für alle Geschäftsprozesse und Informationen.
* '''hoch''': Erhebliche, potenziell existenzbedrohende Auswirkungen (z.B. auf Geschäftsziel oder gesetzlichen Auftrag).
Ein hoher Schutzbedarf liegt z.B. dann vor, wenn:

* Gefahr für Leib und Leben besteht,
* die Existenz der Institution bedroht ist (finanzieller oder Reputationsschaden),
* Der Geschäftsprozess als (VS-)Vertraulich oder höher eingestuft ist.

Der Grundschutz++ orientiert sich damit wieder verstärkt an der ursprünglichen Definition von '''Grund'''schutz, also ein Standard Schutzniveau, das die wesentlichen und üblichen Geschäftsprozesse abdeckt.

== Schadensszenarien ==
Zur besseren Bewertbarkeit können die Schutzbedarfe in verschiedenen Schadensszenarien betrachtet werden. Für jedes Schadensszenario werden die Schutzbedarfskategorien einzeln definiert:
{| class="wikitable"
|+
!
!Schadensszenario
!normal
!hoch
|-
|'''1.'''
|Verstoß gegen Gesetze, Vorschriften, Verträge
|Verstöße gegen Vorschriften und Gesetze mit geringfügigen oder mäßigen Konsequenzen. Geringfügige Vertragsverletzungen mit maximal mäßigen Konventionalstrafen.
|Verstöße gegen Vorschriften und Gesetze mit erheblichen Konsequenzen. Vertragsverletzungen mit hohen Konventionalstrafen bin hin zur Existenzbedrohung.
|-
|'''2.'''
|Beeinträchtigung des informationellen Selbstbestimmungsrechts (personenbezogene Daten)
|Es handelt sich um personenbezogene Daten, durch deren Verarbeitung der Betroffene in seiner gesellschaftlichen Stellung oder in seinen wirtschaftlichen Verhältnissen nur gering beeinträchtigt werden kann.
|Es handelt sich um personenbezogene Daten, bei deren Verarbeitung der Betroffene in seiner gesellschaftlichen Stellung oder in seinen wirtschaftlichen Verhältnissen erheblich beeinträchtigt werden kann.
|-
|'''3.'''
|Beeinträchtigung der persönlichen Unversehrtheit
|Eine Beeinträchtigung erscheint nicht möglich oder ist unwahrscheinlich.
|Eine Beeinträchtigung der persönlichen Unversehrtheit kann nicht ausgeschlossen werden bis hin zu Gefahr für Leib und Leben.
|-
|'''4.'''
|Beeinträchtigung der Aufgabenerfüllung
|Die Beeinträchtigung würde von den Betroffenen als tolerabel eingeschätzt werden und verstößt gegen externen Verträge, Fristen oder Gesetze sind nur in vertretbarem Umfang zu erwarten.
|Die Beeinträchtigung würde von den Betroffenen als nicht tolerabel eingeschätzt. Es werden Verträge, Fristen oder Gesetze in erheblichem Umfang verletzt.
|-
|'''5.'''
|Negative Innen- oder Außenwirkung
|Eine geringe bis mäßige Ansehens- oder Vertrauensbeeinträchtigung ist zu erwarten.
|Eine landesweite Ansehens- oder Vertrauensbeeinträchtigung, die für die Organisation, die möglicherweise existenzgefährdend sein kann.
|-
|'''6.'''
|Finanzielle Auswirkungen
|Der finanzielle Schaden bleibt für die Organisation tolerabel oder kann noch innerhalb der Organisation aufgefangen werden.
|Der finanzielle Schaden ist für die Institution existenzbedrohend.
|}
Je nach Art der Organisation sind die Grenzen zwischen den beiden Schutzbedarfskategorien "normal" ⇔ "hoch" weiter zu konkretisieren. Z.B. bei den finanziellen Auswirkungen mit konkreten Euro-Beträgen.

== Schutzbedarfsfeststellung ==

In der eigentlichen Schutzbedarfsfeststellung wird der Schutzbedarf für die Grundwerte Vertraulichkeit, Integrität und Verfügbarkeit gemäß den zuvor getroffenen Definitionen für alle Prozesse (alternativ Anwendungen) einzeln ermittelt und die Einstufung kurz begründet. Die Begründung ist zwingend erforderlich um eine Nachvollziehbarkeit der Einstufung zu gewährleisten.

=== Einzelbewertung ===
'''Beispiel:''' Prozess "P1 - Personalverwaltung" Anhand der definierten Schadenscenarien und der o.g. Bewertungstabelle ergibt sich folgendes Bild:
{| class="wikitable"
|
|'''<small>Schadensszenario</small>'''
|'''<small>Vertraulicheit</small>'''
|'''<small>Integrität</small>'''
|'''<small>Verfügbarkeit</small>'''
|'''<small>Begründung</small>'''
|-
|'''1.'''
|Verstoß gegen Gesetze, Vorschriften, Verträge
| style="background-color:#ffdbb6;" |hoch
| style="background-color:#afd095;" |normal
| style="background-color:#afd095;" |normal
|Verarbeitung besonderer personenbezogene Daten nach BDSG/DSGVO.
|-
|'''2.'''
|Beeinträchtigung des informationellen Selbstbestimmungsrechts (personenbezogene Daten)
| style="background-color:#ffdbb6;" |hoch
| style="background-color:#afd095;" |normal
| style="background-color:#afd095;" |normal
|Verarbeitung besonderer personenbezogene Daten nach BDSG/DSGVO.
|-
|'''3.'''
|Beeinträchtigung der persönlichen Unversehrtheit
| style="background-color:#afd095;" |normal
| style="background-color:#afd095;" |normal
| style="background-color:#afd095;" |normal
|Eine höhere Beinträchtigung ist nicht zu erwarten.
|-
|'''4.'''
|Beeinträchtigung der Aufgabenerfüllung
| style="background-color:#afd095;" |normal
| style="background-color:#afd095;" |normal
| style="background-color:#afd095;" |normal
|Eine höhere Beinträchtigung ist nicht zu erwarten.
|-
|'''5.'''
|Negative Innen- oder Außenwirkung
| style="background-color:#ffdbb6;" |hoch
| style="background-color:#afd095;" |normal
| style="background-color:#afd095;" |normal
|Hohe Außenwirkung, insbesondere auf zukünftige Bewerber.
|-
|'''6.'''
|Finanzielle Auswirkungen
| style="background-color:#afd095;" |normal
| style="background-color:#afd095;" |normal
| style="background-color:#afd095;" |normal
|Eine höhere Beinträchtigung ist nicht zu erwarten.
|-
|'''='''
|'''Gesamtschutzbedarf (Maximunprinzip je Spalte):'''
| style="background-color:#ffdbb6;" |'''hoch'''
| style="background-color:#afd095;" |'''normal'''
| style="background-color:#afd095;" |'''normal'''
|
|}

=== Gesamtbewertung ===
In der Übersicht über alle Prozesse / Anwendungen reicht es jeweils das Ergebnis für die drei Grundwerte mit kurzer Begründung zu benennen:

'''Beispiel:'''
{| class="wikitable"
|-
| colspan="2" |'''P1 - Personalverwaltung'''
|Begründung:
|-
|Vertraulichkeit:
|'''hoch'''
|In der Personalverwaltung werden besondere personenbezogene Daten verarbeitet, die einem besonderen gesetzlichen Schutz unterliegen. Hohe Außenwirkung bei Bekanntwerden und beeinträchtigung der Betroffenen.
|-
|Integrität:
|normal
|Personaldaten werden u.a. zur Gehaltsabrechnung genutzt. Fehlerhafte Daten können zu fehlerhaften Abrechnungen führen, diese sind jedoch korrigierbar.
|-
|Verfügbarkeit:
|normal
|Personalangelegenheiten sind i.d.R. nicht besonders zeitkritisch. Ausfälle von mehr als 24 Stunden sind vertretbar. Die Daten werden täglich gesichert, stehen bei Bedarf auch in Papierform zur Verfügung und können teilweise noch auf Papier bearbeitet werden.
|}
{| class="wikitable"
|-
| colspan="2" |'''P2 - Produktionssteuerung'''
|Begründung:
|-
|Vertraulichkeit:
|normal
|In der Produktionssteuerung werden keine personenbezogenen Daten und keine besonders schützenswerten Betriebsgeheimnisse verarbeitet.
|-
|Integrität:
|'''hoch'''
|Fehlerhafte Daten können zu Produktionsausfällen oder zu erheblichen Schäden an Maschinen führen.
|-
|Verfügbarkeit:
|'''hoch'''
|Ohne Produktionsdaten kann nicht prodiziert werden, jeder Ausfall führt direkt zu erheblichen finanziellem Schaden.
|}
... und ggf. weiter.

== Vererbungsprinzipen ==
Da einzelne IT-Komponenten in der Regel nicht zum Selbstzweck betrieben werden, leitet sich ihr Schutzbedarf nicht vom reinen Wert der Komponente ab, sondern von den Informationen/Geschäftsprozessen, deren Verarbeitung sie dienen. Der Schutzbedarf vererbt sich somit von den Kerngeschäftsprozessen über die Anwendungen, die einzelnen IT-Komponenten bis hin zu den Gebäuden und Räumen.

Die folgenden Vererbungsprinzipen des Schutzbedarfs können je nach Bedarf angewendet werden:

====== Maximalprinzip ======
Im Maximumprizip (Standard) wird der jeweils höchste Einzelwert betrachtet, d.h. wenn mehrere unterschiedliche Schutzstufen gemeinsam betrachtet werden, zählt nur die höchste Einzel-Stufe für das Gesamtsystem. Z.B. Nutzen drei Systeme unterschiedlichen Schutzbedarfs im Grundwert Verfügbarkeit eine Netzkomponente, erhält diese gemeinsame Netzkomponente die höchste Schutzbedarfsstufe der drei einzelnen Systeme.

====== Verteilungseffekt ======
Der Verteilungseffekt bedeutet das sich das Risiko über mehrere Systeme verteilen kann und daher die Schutzstufe des einzelnen Systems sinkt.

Z.B.: Wenn der Schutzbedarf eines Systems im Grundwert Verfügbarkeit "hoch" ist, davon aber mehrere Systeme vorhanden sind, die sich gegenseitig ersetzen können (z.B. bei einer Lastverteilung), kann der Schutzbedarf für das einzelne System auf "normal" sinken, da der Ausfall eines einzelnen System im Gesamtsystem kompensiert werden kann.

====== Kumulationseffekt ======
Der Kumulationseffekt ist das Gegenteil vom Verteilungseffekt, hier kann die Kumulation mehrerer Systeme zu einer Erhöhung des Schutzbedarfs des Gesamtsystems führen. Z.B.: Auf einem Server laufen viele Anwendungen mit dem Schutzbedarf "normal", Der Ausfall einer einzelnen Anwendung ist unkritisch. Fällt dagegen der Server aus, fallen damit auch alle Anwendungen auf dem Server aus, was für das Gesamtsystem kritisch ist, daher bekommt der Server aufgrund des Kumulationseffekts den Schutzbedarf "hoch" auch wenn jede einzelne Anwendung nur einen normalen Schutzbedarf vererbt.

==== Vererbungsprinzipien in der Praxis ====
[[Datei:Vererbung.png|alternativtext=Vererbungsprinzipien|mini|Vererbungsprinzipien]]
Im Beispiel rechts sind die Vererbungsprinzipien grafisch dargestellt.

Der Prozess (P1) benötigt die Anwendungen (A1) und (A2) und vererbt seinen Schutzbedarf 1:1 an beide Anwendungen.

Die Anwendung (A2) läuft auf dem Server (S4) und vererbt ihren Schutzbedarf 1:1 an den Server (S4).

Die Anwendung (A1) läuft lastverteilt auf den Servern (S1, S2, S3). Alle drei Server können sich gegenseitig ersetzen. Der Schutzbedarf für den Grundwert <u>Verfügbarkeit</u> verteilt sich auf alle drei Server Da der Ausfall eines Servers nicht zum Ausfall der Anwendung führt, sind die Anforderungen an die Verfügbarkeit jedes einzelnen Servers also geringer als die der Anwendung ('''Verteilungseffekt'''). Die Grundwerte Vertraulichkeit und Integrität bleiben unverändert und vererben sich 1:1 auf jeden der drei Server.

Alle vier Server (S1 bis S4) verwenden den Storage (ST1). Das Storage erbt den Schutzbedarf aller vier Server nach dem '''Maximalprizip'''. D.h. der jeweils höchste einzelne Schutzbedarf der vier Server (S1 bis S4) gilt für das gesamte Storage.

Da der Ausfall des Storage (ST1) zum Ausfall aller vier Server (S1 bis S4) führt (und damit zum Ausfall beider Anwendungen (A1) und (A2)), kommt hier ggf. auch der '''Kumulationseffekt''' zum Tragen. D.h. die einzelnen Schutzbedarfe kumulieren im Storage (ST1) und können hier in Summe zu einem höheren Schutzbedarf für den Grundwert Verfügbarkeit führen.

''(In diesem kleinen Beispiel wäre der Kumulationseffekt in der Praxis nicht relevant, da es nur eine Quelle für den Schutzbedarf gibt, den Prozess (P1) und es keinen Sinn machen würde, dass eine einzelne Komponente einen höheren Schutzbedarf erhält als der zugrunde liegende Prozess).''

== Auswirkungen auf weitere Schritte ==
Bei einem Schutzbedarf über "normal" muss im Rahmen einer [[RiLi-Risikoanalyse|Riskoanalyse]] festgestellt werden, ob die Standardanforderungen des IT-Grundschutz ausreichen oder ob (und wo) zusätzliche Maßnahmen erforderlich sind.

[[Kategorie:Artikel]]
[[Kategorie:KMU]]
[[Kategorie:++]]
[[Kategorie:Grundschutz]]

Grundschutz++ Einführung und Aufbau

2026-03-24T17:18:05Z

Dirk:

[[Datei:Teamwork-2198961.png|alternativtext=Zahnrad|rechts|240x240px]]{{#seo:
|title=Grundschutz++ Einführung und Anleitung
|keywords=ISMS, Wiki, BSI Grundschutz++, IT-Grundschutz, BSI-Standard 200-2, Bausteine, OSCAL, JSON, Informationssicherheit, Risikomanagement, Anforderungen
|description=Überblick über den neuen BSI Grundschutz++. Startseite zur Navigation durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.
}}{{SHORTDESC:Grundschutz++ Überblick und Anleitung}}''Dieser Artikel bietet einen schrittweisen Überblick über BSI '''Grundschutz++''' und navigiert durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.''

== Einführung in Grundschutz++ ==
'''Grundschutz++''' ist die 2026 vom BSI eingeführte Weiterentwicklung des IT-Grundschutz-Kompendiums. Es transformiert das bewährte Grundschutz-Konzept in ein vollständig digitales, maschinenlesbares Format mit JSON-basierten Bausteinen und OSCAL-kompatibler Struktur.<blockquote>
''Der aktuelle Stand von Grundschutz++ ist bisher nur sehr eingeschränkt praktisch anwendbar, da einige wesentliche Definitionen und Teile der Methodik noch fehlen. Dazu gehören beispielsweise die Nutzung von Kennzahlen, Blaupausen, Stufen, Schutzbedarf vs. Schutzniveau und die Modellierung.''

''Der Anforderungskatalog liegt zwar im OSCAL- und Excel-Format vor, ist ohne eine abgeschlossene und nachvollziehbare Methodik aber nicht sinnvoll anwendbar.''
</blockquote>
=== Wesentliche Neuerungen===
*'''OSCAL/JSON-basiertes Regelwerk''': Der IT-Grundschutz wird in ein maschinenlesbares '''JSON-Format''' überführt, das teilweise automatisierte Compliance-Prüfungen und Integrationen in bestehende IT-Systeme ermöglicht. Dies ersetzt die bisherigen textbasierten PDFs und Listen.
*'''Prozessorientierte Struktur''': Die neue Version ist modular und objektorientiert aufgebaut, um Redundanzen zu reduzieren und die Dokumentationslast zu verringern.
*'''Leistungskennzahlen''': Kennzahlen sollen die Informationssicherheit messbar und den Sicherheitsgewinn einzelner Anforderungen transparenter machen.
* '''Harmonisierung mit ISO 27001''': Die Anforderungen werden stärker mit internationalen Standards wie '''ISO 27001:2022''' abgestimmt, um Doppelzertifizierungen zu vereinfachen.
*'''Erweiterung um moderne Technologien''': Geplant sind auch spezifische Module für '''Cloud-Security, KI und IoT''', die aktuelle Bedrohungsszenarien abdecken.
===Ziele der Reform===
*'''Schlankere Prozesse''': Durch Automatisierung soll der administrative Aufwand sinken.
*'''Dynamische Anpassung''': JSON ermöglicht schnellere, ggf. automatisierte Updates bei neuen Cyberbedrohungen.
*'''Praxisorientierte Vereinfachung''': Der BSI will die Dokumentationslast reduzieren und den Fokus auf risikobasierte Ansätze legen, insbesondere für KMU.
*'''Priorisierung und Messbarkeit''': Durch eine stufenweise Priorisierung von Anforderungen und Leistungskennzahlen soll ein zielgerichteteres Vorgehen und die bessere Messbarkeit der Sicherheit gefördert werden.
Die Änderungen reagieren auf Kritik an der bisherigen Komplexität und sollen besonders KMU entlasten, während die ganzheitliche Sicherheitsmethodik (technisch, organisatorisch, personell) erhalten bleibt.

''Hinweis'': Details zur finalen Struktur werden schrittweise im Jahr 2026 veröffentlicht. Unternehmen sollten sich frühzeitig mit den geplanten Schnittstellen (z.B. für Security-Tools) vertraut machen.

Offizieller '''Starttermin''' für den Grundschutz++ war der '''1.1.2026'''. Danach ist allerdings eine längere Übergangsphase (bis 2029) geplant, in der beide Standards parallel genutzt werden können, so wie bei der letzten Modernisierung auch. Da jedoch zu erwarten ist, dass eine automatisierte Migration auch diesmal nicht oder nur eingeschränkt möglich sein wird, sollte speziell in größeren Verbünden rechtzeitig begonnen werden! Der jeweils aktuellen Grundschutz++ Katalog wird auf [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek GitHub] veröffentlicht.
=== Bedeutung von OSCAL im Grundschutz++ ===
Das zugrundeliegende Format für Grundschutz++ ist [[OSCAL]].

[[OSCAL]] ist ein '''Framework''' bzw. eine '''Datenmodellierungssprache''', die vom NIST speziell für Sicherheitsanforderungen und Compliance-Dokumentation entwickelt wurde. OSCAL definiert dabei nur ein festes Schema für Sicherheits- und Compliance-Daten und lässt das zugrundeliegende Datenformat (JSON, XML oder YAML) offen.

Das BSI hat sich beim Grundschutz++ für das Datenformat '''JSON''' entschieden.

Dies ermöglicht es mit entsprechenden Tools Sicherheitsanforderungen automatisiert einzulesen und zu bearbeiten. D.h.

* Anforderungen können (teil-)automatisiert von entsprechenden Tools bearbeitet und dokumentiert werden, sofern entsprechende Tools zur Verfügung stehen oder vom Anwender (ggf. Dienstleister) programmiert werden.
* Kataloge und Sicherheitskonzepte (SSPs) können zwischen ISMS-Tools herstellerunabhängig ausgetauscht werden (sofern Toolhersteller sich an den Standard halten und entsprechende Im- und Exportfonktionen in ihren Tools zur Verfügung stellen).

Das heißt aber nicht:

* Das Anwender, Sicherheitsmanager oder Sicherheitsbeauftragte OSCAL lernen müssen oder OSCAL Formate lesen können müssen. (Dafür gibt es Tools, die die Inhalte lesbar und bearbeitbar zur Verfügung stellen)
* Das alle Anforderungen automatisiert erfüllt und dokumentiert werden (viele Anforderungen sind nach wie vor organisatorische Anforderungen die nur von Menschen durch Erstellung und Beachtung entsprechenden Regelungen erfüllt werden können).
* Das überhaupt irgendwelche Anforderungen automatisiert erfüllt und dokumentiert werden (Hierzu müssten die Systeme an ein ISMS-Tool angebunden sein und diese über entsprechende Schnittstellen mit Informationen bedienen). Sowohl die Tools als auch die Schnittstellen werden absehbar nicht vom Himmel fallen.
===Satzschablonen===
Anforderungen werden im Grundschutz++ zukünftig mit Satzschablonen erstellt, die wie folgt aussehen:<blockquote><big>'''<span style="color:green">{Praktik} [für {Zielobjekt}]</span> <span style="color:red">{MODALVERB}</span> <span style="color:blue"><Ergebnis></span> <span style="color:purple">{Handlungswort}</span>''' ''<span style="color:grey">(TAGs) (Hinweise)</span>''</big></blockquote>'''Praktik''': Ein Prozess im Rahmen des ISMS, eine konkrete Sicherheitsmaßnahme oder eine allgemeine Vorgehensweise zur Erreichung eines Sicherheitsziels (z.B. IT-Betrieb, Personal, Konfiguration) - Im weitesten Sinne vergleichbar mit den bisherigen Bausteinen. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/praktiken.csv Liste der gültigen Praktiken.]

'''Zielobjekt''': Wie bisher, das Objekt oder die Entität, auf die sich die Sicherheitsanforderungen beziehen (z.B. Daten, Personen, Endgeräte, Hostsysteme). [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/zielobjektkategorien.csv Liste der Gültigen Zielobjekte.]

'''Modalverb''': Gibt die Verbindlichkeit einer Anforderung an (MUSS, SOLLTE, KANN).

'''Ereignis''': Der sicherheitsrelevante Zustand oder Auslöser, der zu einer bestimmten Handlung führt - Entspricht in Verbindung mit dem Handlungswort dem wesentliche Inhalt der Anforderung.

'''Handlungswort''': Das Verb, das die konkrete Sicherheitsmaßnahme oder Art der Tätigkeit beschreibt (regeln, zuweisen, konfigurieren). Handlungsworte können auch zur besseren Filterung genutzt werden. [https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek/blob/main/Dokumentation/namespaces/handlungsworte.csv Liste der gültigen Handlungsworte.]

Das ganze kann noch mit '''TAG'''s für eine bessere Gruppierung und mit einem '''Hinweis''' zu weiterführenden Informationen ergänzt werden.

Die bisherigen Anforderungen des Kompendium werden aktuell in ihre Teilanforderungen zerlegt und jede Teilanforderung wird zukünftig eine eigene Anforderung. D.h. jedes Modalverb (SOLL, MUSS, KANN) der bisherigen Anforderungen stellt zukünftig i.d.R. eine eigene Anforderung dar. Die Gesamtanzahl der Anforderungen soll dabei durch die Vermeidung von Redundanzen dennoch sinken.

'''Beispiel'''

Die Anforderung:<blockquote>'''ISMS.1.A4 Benennung eines oder einer Informationssicherheitsbeauftragten (B) [Institutionsleitung]'''

Die Institutionsleitung MUSS einen oder eine ISB benennen. '''. . .'''

Die Institutionsleitung MUSS den oder die ISB mit angemessenen Ressourcen ausstatten.

Die Institutionsleitung MUSS dem oder der ISB die Möglichkeit einräumen, bei Bedarf direkt an sie selbst zu berichten. '''. . .'''</blockquote>Wird jetzt zu den Anforderungen:<blockquote>'''GOV.4.2''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">einer Person die Rolle ISB</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.2.3''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">für das ISMS erforderliche personelle, finanzielle und zeitliche Ressourcen</span> '''<span style="color:purple">zuweisen</span>.'''

'''GOV.4.4''': '''<span style="color:green">Die Governance</span> <span style="color:red">MUSS</span>''' <span style="color:blue">dem ISB das direkte und jederzeitige Vorspracherecht bei der Institutionsleitung</span> '''<span style="color:purple">ermöglichen</span>.'''</blockquote>Da dies übergreifende Anforderungen sind, ist hier kein spezifisches Zielobjekt benannt.

Einzelne Teilanforderungen können auch in anderen Praktiken beschrieben sein.
===Priorisierung===
Alle Anforderungen werden einer Prioritätsstufe zugeordnet, um die Umsetzung effizient zu gestalten:
*'''Stufe 0''': Zwingend (sofort) umzusetzende Anforderungen zur Sicherstellung der ISO-Kompatibilität (MUSS-Anforderungen).
Die Stufen 1-4 geben den Umsetzungsaufwand der Anforderungen wieder:
*'''Stufe 1''': Schnell und mit geringem Aufwand (~1 Tag) realisierbare Maßnahmen (QuickWin) / keine laufenden Aufwände.
*'''Stufe 2''': Mit eigenen Mitteln leicht umsetzbare Anforderung (~1 Woche) / geringe laufende Aufwände.
*'''Stufe 3''': Mit normalem Aufwand (mehrere Wochen) und ggf. externer Unterstützung umsetzbar / normale laufende Aufwände.
*'''Stufe 4''': Höherer Umsetzungsaufwand, häufig in längerfristigen Projekten mit externen Experten.
Die nächste Stufe sind optionale Anforderungen als Vorschläge bei erhöhtem Schutzbedarf.
*'''Stufe 5''': Umfassende/zusätzliche Anforderungen für höheren Schutzbedarf.
Diese Einstufung ermöglicht eine schnelle Einschätzung des Umsetzungsaufwands und hilft bei der effizienten Ressourcenplanung.
===Leistungskennzahlen===
Leistungskennzahlen dienen der '''Messung und Bewertung''' der Umsetzung von Sicherheitsanforderungen im Grundschutz++. Sie ermöglichen eine objektive Einschätzung des Sicherheitsniveaus und unterstützen die kontinuierliche Verbesserung. Wie diese Leistungskennzahlen genutzt werden sollen ist nach wie vor unklar und viele Anforderungen sind bislang noch nicht bewertet.
====Bewertungskriterien====
Jede Anforderung wird in Bezug auf die drei Schutzziele bewertet:
*'''Vertraulichkeit (C)'''
*'''Integrität (I)'''
*'''Verfügbarkeit (A)'''
Anforderungen erhalten Punktwerte in diesen Kategorien, die zur Bestimmung des Schutzgrades genutzt werden (z.B. C=6, I=2, A=0 ist eine Anforderung die im Wesentlichen die Vetraulichkeit stärkt, in Teilen die Intgrität aber nicht die Verfügbarkeit).

Die einzelen Kennzahlen werden je Schutzziel, Praktik und/oder Zielobjekt aufsummiert und ergeben so den Erfüllungsgrad.
====Schwellwerte und Erfüllungsgrad====
*'''Schwellwerte''' definieren das angestrebte Sicherheitsniveau basierend auf der Summe der Punktwerte aller umgesetzten Anforderungen je Schutzziel, Zielobjekt und Schutzstufe.
*'''Der Erfüllungsgrad''' zeigt, welche Anforderungen bereits umgesetzt wurden.
Die Leistungskennzahlen bieten damit eine fundierte Entscheidungsgrundlage für Organisationen, um ihren Sicherheitsstatus gezielt zu verbessern, wenn sie wie ursprünglich geplant eingeführt werden.
==Was bleibt erhalten?==
===Standards und Vorgehen===
Trotz eines deutlich anderen Formats und einer anderen Gruppierung der Anforderungen bleibt das grundsätzliche Vorgehen weitgehend gleich.

D.h. die Standards 200-1 bis 200-4 sollen erst einmal weiter Verwendung finden. Die bisher üblichen Arbeitsschritte:
#Festlegung des Geltungsbereichs
#Strukturanalyse
#Schutzbedarfsfeststellung
#Modellierung
#IT-Grundschutzcheck (GSC)
#Risikoanalyse
bleiben grundsätzlich erhalten, ändern sich jedoch in der praktischen Anwendung und Priorität (insbesondere in der '''Modellierung''' und den '''Grundschutzchecks'''). Parallel zur Einführung sollen die Standards weiter entwickelt werden.

'''MUSS'''-Anforderungen sind weiterhin '''verpflichtend''' für eine Zertifizierung, sollen aber deutlich rediziert werden.

'''SOLLTE'''-Anforderungen bleiben auch weiter '''grundsätzlich verpflichtend''', können aber ggf. mit angemessener Begründung oder Ersatzmaßnahmen wegdiskutiert werden.

Lediglich '''KANN'''-Anforderungen sind optional.
===Tool-Einsatz===
Auch der Einsatz von ISMS-Tools wird weiterhin Bestand haben. Alle größeren Tool-Hersteller arbeiten mit Hochdruck an der Integration von Grundschutz++ in ihre Tools. Hier wird es perspektivisch Erleichterungen durch einen leichteren Datenaustausch zwischen den Tools und mehr Automatisierungspotential geben.
==Gegenüberstellung Grundschutz Kompendium vs. Grundschutz++==
Das IT-Grundschutz-Kompendium 2023 und der zukünftige Grundschutz++ bieten unterschiedliche Konzepte für die Umsetzung von Informationssicherheit: Während das Kompendium auf feste Bausteine in thematisch gegliederten Schichten setzt, verwendet Grundschutz++ modulare, flexibel einsetzbare Praktiken.

Die folgende Tabelle stellt die wesentlichen Unterschiede und Gemeinsamkeiten zwischen beiden Ansätzen (nach aktuell verfügbaren Kenntnissen) gegenüber:
{| class="wikitable"
|+
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Fester verbindlicher Katalog''' von Anforderungen (PDF, Excel und XML), die je nach Reifegrad erfüllt werden müssen.
|Der '''variable''' und erweiterbare '''[[OSCAL]]'''-Datenbestand kann beliebig an die Bedürfnisse der Organisation angepasst werden. Zusätzliche Kataloge/Erweiterungen (C5, Datenschutz, KRITIS/NIS2) können je nach Verfügbarkeit ergänzt werden. Durch die Beseitigung vermeintlicher Redundanzen soll die Anzahl der Anforderungen erheblich reduziert werden (~10–20 % verbleibende Anforderungen gegenüber dem Grundschutz Kompendium).
|-
|
|Järliche '''Aktualisierung''' zum Stichtag '''1. Februar'''.
(bis 2023)
|Die '''Aktualisierung''' erfolgt '''fortlaufend''' nach Bedarf und Verfügbarkeit. Die Regelungen zur Relevanz für Zertifizierungen sind bislang noch nicht bekannt.
|-
|
|Das Kompendium ist (Stand 2023) in 10 '''Schichten''' mit insgesamt 111 '''Bausteine''' gegliedert, die statisch die jeweiligen Anforderungen enthalten.
|'''Praktiken''' und '''''Zielobjekte/Zielobjektkategorien''''' (Achtung abweichende Bedeutung in GS++) sind allgemeinere und wiederverwendbare, sicherheitsrelevante Verfahren oder Maßnahmen. Sie können modular und situationsabhängig einzelnen Assets zugeordnet werden.
Die voraussichtlich ca. 20 Praktiken liegen irgendwo zwischen Schichten und Bausteinen. Sie sind prozessorientierter, adressieren eher Zielgruppen oder Handlungstypen und sind nicht mehr starr bestimmten Zielobjekten zugeordnet. Zielobjekte entsprechen zukünftig eher den Bausteinen im alten Grundschutz. Die Definitionen der Begriffe sind nach wie vor unklar!
|-
|
|'''Drei Stufen''' (Vorgehensweisen): Basis, Standard, erhöhter Schutzbedarf bilden den Reifegrad der Organisation ab.
|Es sind zukünftig '''sechs Stufen''' (0–5) geplant, die sich weitgehend am Umsetzungsaufwand der jeweiligen Anforderung orientieren: Je kleiner die Stufe, desto schneller bzw. leichter ist die Anforderung umsetzbar (Quick Win). Eine qualitative Bewertung des Reifegrads muss zukünftig anders erfolgen (z. B. über Leistungskennzahlen).
Das '''Sicherheitsniveau''' gibt zukünftig an, in welchem Maß die definierten Sicherheitsziele erreicht sind. Es ergibt sich aus der wirksamen Umsetzung organisatorischer, technischer und personeller Anforderungen.

Unterschieden werden:
*'''Normales Sicherheitsniveau''': entspricht dem Stand der Technik
*'''Erhöhtes Sicherheitsniveau''': für besonders schutzbedürftige Informationen oder Systeme
|-
|
|'''Zielobjekte''' als gruppierte Sammlung von gleichartigen Assets die zur späteren '''Modellierung''' (Zuordnung der Bausteine und Abhängigkeiten) genutzt werden.
|'''Zielobjekte''' werden auch in Zukunft eine ähnliche Funktion zur Gruppierung und '''Modellierung''' haben, entsprechend dabei aber eher den klassischen Bausteinen. Die konkreten Vorgaben zur Modellierung sind jedoch noch nicht detailliert genug. In der Modellierung werden die Praktiken nicht mehr statisch bestimmten Zielobjekttypen zugewiesen. Klassische Zielobjekte werden zukünftig als Assets oder Assetgruppen bezeichnet.
|-
|
|Modalverben '''MUSS''', '''SOLLTE''', '''KANN''' bestimmen die Verbindlichkeit von Anforderungen.
|Die Bedeutung der Modalverben ('''MUSS, SOLLTE, KANN''') bleibt unverändert. Ein Ziel von Grundschutz++ ist es jedoch, die Anzahl der Muss-Anforderungen auf das Nötigste zu reduzieren (unter 10 %). Dadurch soll der Grundschutz flexibler werden. Die Verbindlichkeit von Anforderungen, die über MUSS-Anforderungen hinausgehen, ist noch unklar.
|-
|
| -
|Neu sind '''Leistungskennzahlen''', die eine qualitative Bewertung der Anforderungen in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit darstellen. Sie sollen als Zahlenwert darstellbar sein und so den Reifegrad abbilden können. Bisher ist noch nicht bekannt, ob und wann diese eingeführt werden und wie die konkreten Regelungen aussehen werden.
|-
|
|Gültigkeit voraussichtlich bis 2029
|Gültig ab 1.1.2026. Zertifizierbar geplant ab 2027.
|}Teilweise werden Begrifflichkeiten neu (oder anders) definiert:
{| class="wikitable"
!
!Grundschutz Kompendium
!Grundschutz++
|-
|
|'''Zielobjekt''' als gruppierte Sammlung von gleichartigen Assets als Grundlage für die spätere Modellierung
|'''Asset''' und gruppierte Assets. Die Gruppierung gleichartiger Assets kann weiterhin erfolgen es bleiben jedoch auch dann '''Assets'''. Der Begriff ''Zielobjekt'' wird hierfür nicht mehr genutzt.
|-
|
|'''Baustein''' als Sammlung von Anforderungen für bestimmte Zielobjekttypen.
|'''Zielobjekt''' sind zukünftig das was bislang die ''Bausteine'' waren, bestimmte Typen von Assets für die spezische Anforderungen gelten. Die Assets werden den Zielobjekten zugewisen und erhalten über diese ihre Anforderungen. Eine klare Definition der Begriffe steht noch aus.
|-
|
|
|
|}
==Blaupausen==
Blaupausen sind vorgefertigte Musterlösungen (wie die bisherigen IT-Grundschutz-Profile), die als Vorlage (Referenzmodell) für die Erstellung und Umsetzung von branchenspezifischen oder organisationsspezifischen Sicherheitskonzepten dienen.
===Funktion der Blaupausen===
Solche Blaupausen erfassen typische Strukturen, Risiken, Anforderungen und Maßnahmen für bestimmte Anwendungsszenarien, etwa die Nutzung der E-Akte oder den sicheren Betrieb von 5G-Infrastrukturen. Sie ermöglichen es, ein ISMS deutlich effizienter und strukturierter aufzubauen, weil die grundlegenden Überlegungen (Schutzbedarfsermittlung, Zuordnung von Praktiken, Zielobjekten und Maßnahmen, etc.) bereits allgemein gültig vorformuliert sind und nur noch organisationsspezifisch angepasst werden müssen.
===Ziel und Nutzen===
*Blaupausen helfen, den Implementierungsaufwand für ISMS nach Grundschutz++ zu reduzieren.
*Sie fördern die Standardisierung und Wiederverwendbarkeit von Sicherheitskonzepten für ähnliche Organisationen oder Branchen.
*Besonders für kleinere Organisationen und typische Anwendungsfälle bieten sie einen niederschwelligen, strukturierten und praxiserprobten Einstieg in die Absicherung.
Damit sind Blaupausen im Grundschutz++ zentrale Instrumente, um bewährte Sicherheitsmethoden als Vorlage für den schnellen und einheitlichen Aufbau eines branchenspezifischen ISMS bereitzustellen.
===Umsetzung===
Umgesetzt werden Blaupausen technische als '''OSCAL-Profile''' mit zusätzlichen Erläuterungen in Textform, zukünftig sollen Blaupausen zu einem '''System Security Plan (SSP)''' weiter entwickelt werden.
== Grundlagen und Standards ==

* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_1.html BSI-Standard 200-1: Anforderungen an ein ISMS].
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_2.html BSI-Standard 200-2: IT-Grundschutz Methodik] ( <- Wird neu erstellt )
** Methodik zum Grundschutz++ (Aktuell in Erstellung, ersetzt 200-2)
* [https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_3.html BSI-Standard 200-3: Risikomanagement mit Grundschutz].
* [https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/BSI-Standards/BSI-Standard-200-4-Business-Continuity-Management/bsi-standard-200-4_Business_Continuity_Management_node.html BSI-Standard 200-4: Business Continuity Management].
* [[OSCAL|OSCAL (Open Security Controls Assessment Language)]].

== Schritt-für-Schritt-Methodik ==
Die Methodik zum Grundschutz++ folgt einem '''5-stufigem PDCA-basierten Prozess''' mit Fokus auf '''Anforderungsmodellierung''' und '''maschinenlesbarer Verarbeitung'''. Hier das praktische Vorgehen:

=== Schritt 1: Erhebung und Planung (PLAN - Governance/Compliance) ===
# '''Kontextanalyse''' (intern/extern) durchführen
# '''Interessierte Parteien''' identifizieren und Anforderungen erfassen
# '''Geltungsbereich''' (Scope) durch Institutionsleitung festlegen und freigeben
# '''Geschäftsprozesse''' priorisieren → Schutzbedarf "normal" oder "hoch" einstufen
# '''Sicherheitsleitlinie''' erstellen (Ziele, Strategie, Verpflichtung Leitung)
# '''Sicherheitsorganisation''' etablieren (Rollen: ISB, Asset-Owner, etc.)
# '''Compliance-Management''' initialisieren (Rechts-/Vertragskatalog)

'''Ergebnis''': Organisatorischer Rahmen, Sicherheitsleitlinie, priorisierte Prozesse

'''Weiterführende Informationen:'''

* [[Informationssicherheitsleitlinie]]
* [[IS-Strategie]]
* [[Geschäftsprozesse]]

=== Schritt 2: Anforderungsanalyse (PLAN - Strukturmodellierung) ===
# '''Informationsverbund''' definieren (techn./org. Abgrenzung)
# '''Assets''' für wichtigsten Geschäftsprozess erfassen
# '''Asset → Zielobjektkategorien''' mapping (Hierarchie + Vererbung)
# '''Anforderungspaket''' generieren:
#* ISMS-Praktiken (vollständig)
#* Zielobjekt-Anforderungen (Sicherheitsniveau: normal/erhöht)
#* Zielobjektlose Anforderungen prüfen
# '''Ergänzungen''': Externe Verpflichtungen, anforderungslose Assets
# '''Risikobetrachtung''' bei hohem Schutzbedarf oder Niveauerhöhung
# '''Parameter setzen''' (Zuständigkeiten, Werte)

'''Ergebnis''': Individuelles Anforderungspaket pro Informationsverbund

'''Weiterführende Informationen:'''

* [[Strukturanalyse]]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das OSCAL-basierte Grundschutz++ Kompendium auf Github.]

=== Schritt 3: Realisierung (DO - Umsetzung) ===
# '''Umsetzungsstatus''' aller Anforderungen prüfen (ja/nein)
# '''Nicht-umgesetzte MUSS/SOLLTE''' → Risikobetrachtung
# '''Umsetzungsplan''' erstellen:
#* Priorisierung (Risiko, Aufwand, Synergien)
#* Zuständigkeiten + Fristen zuweisen
# '''Freigabe''' durch Institutionsleitung
# '''Fortschritt tracken''' (Ticketsystem/Projektmanagement)
# '''Ausnahmen dokumentieren''' (Begründung + Leitungsfreigabe)

'''Ergebnis''': Umsetzungsplan + Status-Dokumentation

'''Weiterführende Informationen:'''

* [[LF-Grundschutzcheck|Leitfaden Grundschutzcheck]]
* [[RiLi-Freigabe]]
* [[RiLi-Ausnahmemanagement|Richtlinie zum Management von Ausnahmen und Abweichungen]]

=== Schritt 4: Überwachung (CHECK - Monitoring/Evaluation) ===
# '''Leistungsbewertung''' (KPIs, Umsetzungsfortschritt, Vorfälle)
# '''Compliance-Überwachung''' (gesetzlich/vertraglich)
# '''Auditprogramm''' risikobasiert durchführen
# '''Managementbewertung''' → Managementbericht erstellen
# '''Monitoring-Tools''' einsetzen (SIEM, Vulnerability Scanner)
# '''Anforderungspaket validieren''' (Aktualität prüfen)

'''Ergebnis''': Auditberichte, Managementbericht

'''Weiterführende Informationen:'''

* [[Reifegradmodell]]
* [[KPIs|Key Performance Indicators (KPIs)]]
* [[Managementbericht|Erstellen eines Managementberichts]]

=== Schritt 5: Kontinuierliche Verbesserung (ACT - Verbesserung) ===
# '''Nicht-Konformitäten''' analysieren
# '''Verbesserungspotenziale''' identifizieren
# '''Korrektur-/Verbesserungsplan''' → in Umsetzungsplan integrieren
# '''Wirksamkeit prüfen''' nach Umsetzung
# '''Sicherheitsniveau''' bewerten (Trendanalyse)
# '''Compliance-Verstöße''' behandeln

'''Ergebnis''': Aktualisiertes Anforderungspaket → neuer PDCA-Zyklus

'''Weiterführende Informationen:'''

*

=== Praktische Hinweise ===
* '''Tool-gestützt''': JSON/OSCAL-Bausteine, Zur Nutzung sind ISMS-Tools empfohlen.
* '''Iteration''': Wichtigster Geschäftsprozess zuerst, dann schrittweise erweitern
* '''Risikobetrachtung''': Bei Sicherheitsniveau "hoch" oder Nicht-Umsetzung
* '''Dokumentation''': bevorzugt Maschinenlesbar (OSCAL) für besseren Austausch

'''Zyklusdauer''': Jährlich oder ereignisgesteuert (Änderungen, Vorfälle, Audits)

== Migration bestehender Sicherheitskonzepte ==
...

'''Weiterführende Informationen:'''

[[Grundschutz++Migration]]

== Offenen Punkte und Kritiken ==

=== Zu viele Beteiligte, unklare Zuständigkeiten ===
Die Weiterentwicklung des Grundschutzes wird inzwischen nicht mehr ausschließlich vom Grundschutz-Referat des BSI verantwortet. Mit dem Einstieg des Referats „Stand der Technik“ und der verstärkten Einbindung der „Community“ sind die Zuständigkeiten und Verantwortlichkeiten unklarer geworden. In Präsentationen und Veröffentlichungen werden die Rollen und Aufgaben der verschiedenen Beteiligten unterschiedlich dargestellt. Es fehlt eine klare, kommunizierte Schnittstelle, wer für welche Aspekte der Entwicklung, Pflege und Kommunikation des neuen Standards verantwortlich ist. Das erschwert für Anwendende die Orientierung und die Planung der eigenen Umsetzungsstrategie.

=== Unklare Umsetzung einiger Ziele ===
Einige der im Grundschutz++ adressierten Ziele und Neuerungen sind nach wie vor nicht ausreichend konkretisiert. Besonders die Einführung von Leistungskennzahlen und die Priorisierung der Anforderungen (Stufen) werfen noch viele Fragen auf. Die konkrete Bedeutung, Messung und praktische Umsetzung dieser Leistungskennzahlen werden von verschiedenen BSI-Vertretern unterschiedlich dargestellt. Auch die Stufenmodelle werden teils als Priorisierung, als Entwicklungsstufen oder als reiner Umsetzungaufwand der Anforderungen definiert und sind in ihrer praktischen Anwendung noch nicht abschließend geklärt. Das führt zu Unsicherheiten, wie diese neuen Instrumente im einem ISMS umgesetzt und nachgewiesen werden sollen.

=== Geringer Mehrwert im Vergleich zu ISO 27001 ===
Die Anforderungen im Grundschutz++ werden zunehmend an die Formulierungen und Strukturen der ISO 27001 angeglichen. Während der klassische IT-Grundschutz durch seine konkreten, praxisnahen Maßnahmen einen klaren Mehrwert gegenüber der eher abstrakten ISO 27001 bot, verliert er durch die Harmonisierung mit internationalen Standards zunehmend diesen Vorteil. Die Anforderungen werden stärker abstrakt modularisiert formuliert, wodurch der spezifische Bezug zu typischen Umsetzungsbeispielen und die Detailtiefe abnehmen. Für viele Organisationen wird sich daher die Frage stellen, warum sie den immer noch aufwändigeren Weg über den Grundschutz wählen sollten, wenn sie mit ähnlichem oder geringeren Aufwand direkt eine ISO 27001-Zertifizierung anstreben können.

=== Zu ambitionierter Zeitplan ===
Der Grundschutz++ sollte ab dem 1.1.2026 grundsätzlich gültig und anwedbar sein, wobei eine Übergangsphase bis 2029 vorgesehen war. Bisher ist nur ein erster Entwurf veröffentlicht. Angesichts der Vielzahl an noch offenen Fragen, der fehlenden Migrationsstrategie und der Komplexität der Änderungen erscheint der Zeitplan sehr ambitioniert. Ausarbeitung und Dokumentation liegen bisher nur als Entwurf vor. Eine Pilotierung und Einführung 2026 und eine Übergangsphase bis 2029 ist vorgesehen. Die Gefahr besteht, dass größere Organisationen unter Zeitdruck unzureichend vorbereitet in die neue Methodik wechseln und mit variablen Definitionen und Zielen arbeiten müssen, was die Akzeptanz und Qualität der Umsetzung gefährdet.

=== Zunehmende (Sicherheits-)Lücke zwischen Grundschutz und Grundschutz++ ===
Mit der Entscheidung des BSI, den bisherigen IT-Grundschutz (Edition 2023) nicht mehr weiterzuentwickeln und stattdessen auf das neue Grundschutz++-Modell zu setzen, entsteht eine wachsende Lücke in der Informationssicherheit. Diese Übergangsphase bis 2029 ist sicherheitstechnisch kritisch, da sich die Bedrohungslage in der IT nicht an Entwicklungszyklen von Sicherheitsstandards orientiert. Neue Angriffsvektoren, insbesondere durch den zunehmenden Einsatz von KI in der Cyberkriminalität (z.B. KI-gestützte Malware, Deepfakes, automatisierte Phishing-Kampagnen), entstehen kontinuierlich und erfordern zeitnahe, wirksame Gegenmaßnahmen. Der bisherige Grundschutz bildet diese aktuellen Bedrohungen und technologische Entwicklungen jedoch nicht mehr ab, während die spezifischen Module und Maßnahmen im Grundschutz++ noch nicht produktiv verfügbar oder praxistauglich sind.

=== Fehlende Migration vom Grundschutz-Kompendium zu Grundschutz++ ===
Aktuell existiert weder ein konkreter Plan noch ein Konzept für eine (teil-)automatisierte Migration bestehender Sicherheitskonzepte aus dem bisherigen Grundschutz-Kompendium in das neue Grundschutz++-Modell. Die Umstellung auf ein maschinenlesbares JSON/OSCAL-Format und die objektorientierte, prozessorientierte Struktur bedeuten einen fundamentalen Bruch mit bisherigen Strukturen. Die Unterschiede zwischen Grundschutz-Kompendium und Grundschutz++ sind gravierender als beim letzten Wechsel von den Grundschutz-Katalogen zum Kompendium, bei dem bereits alle Ansätze für eine automatisierte Migration weitgehend gescheitert sind. Auch diesmal ist absehbar, dass Organisationen ihre bestehenden Dokumentationen und Umsetzungen weitgehend manuell neu abbilden müssen, was insbesondere für größere Verbünde einen erheblichen Zusatzaufwand bedeutet. Es gibt zwar Ansätze dies mittels KI zu lösen, was aber sicher nicht für jede Organisation praktikabel sein wird.

== Fazit ==
Ein abschließendes Bild zum Grundschutz++ lässt sich aktuell noch nicht zeichnen – viele Details sind noch in der Entwicklung.

Die grundlegende Modernisierung des IT-Grundschutzes durch das Grundschutz++-Projekt ist zwar fachlich und technologisch nachvollziehbar und adressiert viele Schwächen des bisherigen Systems. Die Umsetzung ist jedoch nach jetzigem Entwicklungsstand mit erheblichen Risiken und Unsicherheiten verbunden. Ohne klare Migrationspfade, eindeutige Zuständigkeiten und praxistaugliche Konkretisierungen der neuen Instrumente besteht die Gefahr, dass die Akzeptanz des Grundschutzes sinkt und Organisationen sich vermehrt alternativen Standards wie der ISO 27001 zuwenden. Ein realistischer Zeitplan und ein echter Mehrwert des neuen Standards sind daher essenziell für den Erfolg der Reform.

Der Artikel wird fortlaufend aktualisiert, sobald neue Informationen vom BSI veröffentlicht oder freigegeben werden.
===Ausblick und ToDos aus Anwendersicht===
Stichtag für die Einführung von Grundschutz++ war der '''1.1.2026'''. Das Datum wurde vom BSI in offiziellen Ankündigungen, Präsentationen und Fachveranstaltungen als verbindlicher Startpunkt kommuniziert. Ab diesem Zeitpunkt sollte das neue, digitale und prozessorientierte Regelwerk den bisherigen IT-Grundschutz ablösen. Bisher fehlt es jedoch an vielen Stellen an klaren Definitionen und konkreten Vorgaben zur Methodik.

Auch wenn abzuwarten bleibt, wann praxistaugliche Methoden verfügbar sind und wie lange die Übergangsfristen für die Umstellung sein werden (aktuelle Planung bis 2029). Abzusehen ist jedoch, dass der Aufwand und der Zeitdruck, insbesondere für größere und zertifizierte Verbünde, erheblich sein werden. Auch wenn es aktuell noch keine konkreten Beschreibungen zur Methodik und Modellierung gibt, können und sollten sich Anwender bereits jetzt vorbereiten. Dazu können die folgenden Maßnahmen dienen:
*Laufende Information über den aktuellen Stand (Internetseiten des BSI, Vorträge und Veröffentlichungen).
*Konsolidierung der bestehenden Verbünde (Reduzierung der Komplexität, konsistente Dokumentation der Gruppierung und Modellierung).
**Ein guter Tip ist es, in aktuellen GSC jede Teilanforderung (jedes Modalverb wie MUSS oder SOLLTE) in der Umsetzung einzeln zu dokumentieren, da diese zukünftig eigenständige Anforderungen darstellen und so eine Übernahme leichter werden könnte.
*Kontakt zu Toolherstellern aufnehmen und eine zügige Umsetzung in den verwendeten ISMS-Tools einfordern.
*Frühzeitige Planung der Bereitstellung entsprechender personeller Ressourcen für die Umstellung auf Grundschutz++ ab Mitte 2026.
*Gegebenenfalls frühzeitige Reservierung externer (personeller) Ressourcen zur Unterstützung.
*Es muss eine klare interne Kommunikation über die bevorstehenden, durch die Umstellung bedingten erhöhten Aufwände (Schulungen, neue (Erst-)GSCs und Anpassung der Dokumentation) geben, damit Mitarbeitende und Verantwortliche wissen, was auf sie zukommt.

== Weiterführende Ressourcen ==
*[https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html BSI IT-Grundschutz]
*[https://www.bsi.bund.de/SharedDocs/Termine/DE/2024/IT_Grundschutzveranstaltung_2024.html 30 Jahre <abbr>IT</abbr>-Grundschutz: Gestern, heute, morgen (Folien und Aufzeichnung des Vortrags) - itsa 2024]
*[https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Veranstaltungen/Grundschutz/1GS_Tag_2025/Aktuelle_Entwicklungen_Ausblick_IT-GS.pdf Aktuelle Entwicklungen und Ausblick zum IT-Grundschutz - 1. Grundschutztag 2025]
*[https://www.youtube.com/watch?v=_AeWJ_Z8S-4 Keynote: Fortentwicklung des IT-Grundschutzes zu IT-Grundschutz++ (verinice.XP 2025)]
*[https://www.youtube.com/watch?v=fBXuhELODGA Vortrag: "Keynote und Vision Grundschutz++" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.youtube.com/watch?v=PxOjkV6oUwU Vortrag "Grundschutz++ Methodik und Einstieg ins BCM" vom 2. IT-Grundschutztag am 7.7.2025]
*[https://www.bsi.bund.de/dok/it-sa Am Mittwoch, 08.10.2025 werden auf der it-sa die von den Arbeitsgruppen aus der Community erarbeiteten Ergebnisse präsentiert.]
*[https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek Das aktuelle OSCAL-basierte Grundschutz++ Kompendium auf Github.]
*[[Grundschutz++ Migration|Migrationsstrategie für den Umstieg von BSI IT-Grundschutz auf Grundschutz++]]
[[Kategorie:Artikel]]
[[Kategorie:Grundschutz]]
[[Kategorie:++]]

Grundschutz++ QS-Checkliste

2026-03-24T12:36:34Z

Dirk:

{{Vorlage:Entwurf}}
[[Datei:Teamwork-2198961.png|alternativtext=Zahnrad|rechts|240x240px]]
{{#seo:
|title=Checkliste zur Qualitätssicherung von Praktiken und Anforderungen im BSI Grundschutz++
|description=Strukturierte Checkliste zur QS von Praktiken und Anforderungen im Grundschutz++ – unterstützt formale, inhaltliche und prüfbare Bewertung aller Sicherheitsmaßnahmen.
}}
{{SHORTDESC:Checkliste zur Qualitätssicherung von Praktiken und Anforderungen im BSI Grundschutz++}}
''Hier ist eine detaillierte Checkliste für die Qualitätssicherung (QS) einer Praktik und ihrer einzelnen Anforderungen im Grundschutz++. Sie orientiert sich an den spezifischen Merkmalen des neuen Ansatzes und ist so gestaltet, dass sie sowohl für die QS der gesamten Praktik als auch für jede einzelne Anforderung anwendbar ist.''

=== Einleitung ===
Diese Checkliste bildet einen vollständigen QS-Prozess für Praktiken und deren Anforderungen im Grundschutz++ ab – von der konzeptionellen Überprüfung bis zur technischen/formalen Dokumentation und Nachverfolgbarkeit.

Die Checkliste kann sowohl für eine Community-QS des Grundschutzes++ als auch für eigene/ergänzende Praktiken und Anforderungen einer Organisation oder anderer Standards in der Informationssicherheit verwendet werden, sofern diese im [[OSCAL|OSCAL-Format]] mit den zukünftigen ISMS-Tools verarbeitet werden sollen.

=== Überprüfung der Praktik als Ganzes ===
'''1. Vollständigkeitsprüfung'''

* Ist sichergestellt, dass alle relevanten Aspekte der Praktik in expliziten Anforderungen abgebildet werden (Prozesse, Zielobjekte, Modalverben, Ereignisse, Maßnahmen)?
* Wurden aktuelle Technologien oder Bedrohungslagen (z.B. Cloud, KI, IoT) sowie organisatorische, technische und personelle Aspekte berücksichtigt?
* Decken die Anforderungen verschiedene Schutzbedarfsszenarien (Basis, Standard, erhöhter Bedarf) ab?

'''2. Redundanz- und Konsistenzprüfung'''

* Gibt es Dopplungen oder widersprüchliche Anforderungen innerhalb der Praktik oder im Vergleich zu anderen Praktiken?
* Ist die Zuordnung der Anforderungen zu Praktik und Zielobjekt logisch und konsistent?

'''3. Abdeckung der Schutzziele'''

* Sind Vertraulichkeit, Integrität und Verfügbarkeit durch die Anforderungen angemessen adressiert?
* Sind die jeweiligen Leistungskennzahlen plausibel und nachvollziehbar verteilt?

=== QS der einzelnen Anforderungen der Praktik ===
'''1. Formale Prüfung nach Satzschablone'''

* Entspricht die Beschreibung der Anforderung der Vorgabe (Praktik, Zielobjekt, Modalverb, Ereignis, Handlungswort, Tags, Hinweise)?
* Ist das Modalverb korrekt gesetzt und spiegelt die gewünschte Verbindlichkeit (MUSS/SOLLTE/KANN) angemessen wider?
* Sind alle Pflichtfelder (z.B. Zielobjekt, Handlungswort) eindeutig ausgefüllt?
* Sind Tags und Hinweise sinnvoll und helfen sie bei der Einordnung?

'''2. Inhaltsprüfung'''

* Ist die Anforderung klar, prägnant und widerspruchsfrei formuliert?
* Ist deren Sinnhaftigkeit für die jeweilige Praktik nachvollziehbar begründet?
* Spiegelt sie aktuelle regulatorische/technische Anforderungen und bekannte gute Praxis wider?
* Wurde bei der Erstellung auf die Community-Reviews und gängige Umsetzungsbeispiele Bezug genommen?

'''3. Plausibilitätsprüfung'''

* Ist die Anforderung generell umsetzbar, auch für Organisationen unterschiedlicher Größe/Komplexität?
* Passt das ausgewählte Modalverb zur tatsächlichen Kritikalität und zum Risiko?
* Sind die Leistungskennzahlen in Bezug auf die Schutzziele angemessen gesetzt?

'''4. Verständlichkeit und Nachvollziehbarkeit'''

* Ist die Anforderung für Dritte eindeutig verständlich (kein Interpretationsspielraum, keine Mehrdeutigkeiten)?
* Wird die Zielgruppe adressatengerecht angesprochen?
* Unterstützen Tags und Hinweise die Anwendung?

'''5. Prüfbarkeit und Nachweisbarkeit'''

* Ist objektiv überprüfbar, ob die Anforderung erfüllt ist (z.B. durch Dokumentation, Test, Audit, Kontrollmechanismus)?
* Ist erkennbar, wie der Erfüllungsgrad anhand von Leistungskennzahlen ermittelt werden kann?
* Gibt es klare Abgrenzungskriterien zu benachbarten Anforderungen?

'''6. Sinnhaftigkeit und Zweckmäßigkeit'''

* Trägt die Anforderung messbar zur Erreichung der Schutzziele und Praktikziele bei?
* Gibt es einen erkennbaren Mehrwert der Anforderung außerhalb reiner Regelerfüllung?
* Vermeidet die Anforderung einen unnötigen Mehraufwand („Overengineering“)?

=== Nachbearbeitung und Monitoring ===

* Sind die Reviews und Korrekturen der Community dokumentiert und eingepflegt?
* Wurde für die Anforderung ein Änderungs- und Versionsverlauf festgehalten?
* Ist die Anforderung mit einer QSV-Freigabe versehen (inkl. Autor/in, Prüfer/in, Datum der letzten Prüfung)?

[[Kategorie:Kurzartikel]]
[[Kategorie:Grundschutz]]
[[Kategorie:++]]
__KEIN_INHALTSVERZEICHNIS__

Grundschutz++ QS-Checkliste

2026-03-24T12:36:10Z

Dirk: