ISMS-Ratgeber WiKi - Letzte Änderungen [de]

Benutzer:Mage

Dirk — Mon, 08 Jun 2026 13:47:49 GMT

Benutzerkonto Mage wurde von Dirk erstellt und das Passwort wurde per E-Mail zugesandt

Inhalt-Übersicht

Dirk — Mon, 08 Jun 2026 04:00:05 GMT

Automatisch erzeugte Inhaltsübersicht aktualisiert

← Nächstältere Version		Version vom 8. Juni 2026, 06:00 Uhr
Zeile 3:		Zeile 3:
	{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}		{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}
	;Stand		;Stand
	:2026-06-07 04:00 (UTC)		:2026-06-08 04:00 (UTC)

	;Anzahl Seiten gesamt		;Anzahl Seiten gesamt
	:~~214~~		:215

	== Hauptnamensraum ==		== Hauptnamensraum ==
Zeile 116:		Zeile 116:
	\| [[Grundschutz ToDo MindMap\|Grundschutz ToDo MindMap]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz_ToDo_MindMap Link] \|\| 618 \|\| 2025-02-08 14:34:45 UTC \|\| Dirk \|\| Mindmap zur Umsetzung von BSI IT-Grundschutz.		\| [[Grundschutz ToDo MindMap\|Grundschutz ToDo MindMap]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz_ToDo_MindMap Link] \|\| 618 \|\| 2025-02-08 14:34:45 UTC \|\| Dirk \|\| Mindmap zur Umsetzung von BSI IT-Grundschutz.
	\|-		\|-
	\| [[Grundschutz++\|Grundschutz++]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz%2B%2B Link] \|\| ~~7180~~ \|\| 2026-05-~~06 18~~:03:15 UTC \|\| Dirk \|\| Grundschutz++: Digitale Reform & OSCAL-basierte Sicherheit		\| [[Grundschutz++\|Grundschutz++]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz%2B%2B Link] \|\| 7284 \|\| 2026-06-07 10:51:10 UTC \|\| Dirk \|\| Grundschutz++: Digitale Reform & OSCAL-basierte Sicherheit
	\|-		\|-
	\| [[Hauptseite\|Hauptseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/Hauptseite Link] \|\| 13691 \|\| 2026-06-05 08:19:48 UTC \|\| Dirk \|\| Das freie ISMS-Ratgeber Wiki für Informationssicherheit und Datenschutz		\| [[Hauptseite\|Hauptseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/Hauptseite Link] \|\| 13691 \|\| 2026-06-05 08:19:48 UTC \|\| Dirk \|\| Das freie ISMS-Ratgeber Wiki für Informationssicherheit und Datenschutz
Zeile 164:		Zeile 164:
	\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.		\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.
	\|-		\|-
	\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| 47633 \|\| 2026-06-06 04:00:05 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.		\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| 47633 \|\| 2026-06-07 04:00:09 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.
	\|-		\|-
	\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.		\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.
Zeile 378:		Zeile 378:

	;Anzahl Seiten		;Anzahl Seiten
	11		12

	{\| class="wikitable sortable"		{\| class="wikitable sortable"
Zeile 404:		Zeile 404:
	\|-		\|-
	\| [[Grundschutz:Umsetzungsleitfaden\|Umsetzungsleitfaden]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:Umsetzungsleitfaden Link] \|\| 75931 \|\| 2026-05-01 01:29:53 UTC \|\| Dirk \|\| Praxisleitfaden zur Umsetzung von Grundschutz++		\| [[Grundschutz:Umsetzungsleitfaden\|Umsetzungsleitfaden]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:Umsetzungsleitfaden Link] \|\| 75931 \|\| 2026-05-01 01:29:53 UTC \|\| Dirk \|\| Praxisleitfaden zur Umsetzung von Grundschutz++
			\|-
			\| [[Grundschutz:Überwachung und Audits\|Überwachung und Audits]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:%C3%9Cberwachung_und_Audits Link] \|\| 25197 \|\| 2026-06-07 10:58:14 UTC \|\| Dirk \|\| Grundschutz++ Leitfaden: Überwachung, interne Audits & kontinuierliche Bewertung. (ehem. Grundschutzcheck)
	\|}		\|}

Grundschutz:Überwachung und Audits

Dirk — Sun, 07 Jun 2026 10:58:14 GMT

← Nächstältere Version		Version vom 7. Juni 2026, 12:58 Uhr
(2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1:		Zeile 1:
	{{#seo:		{{Entwurf}}{{#seo:
	\|title=Grundschutz++: Überwachung, interne Audits & kontinuierliche Bewertung		\|title=Grundschutz++: Überwachung, interne Audits & kontinuierliche Bewertung
	\|keywords=ISMS, BSI, Grundschutz++, Grundschutzcheck, Durchführung, Leitfaden, Überwachung, Monitoring, interne Audits		\|keywords=ISMS, BSI, Grundschutz++, Grundschutzcheck, Durchführung, Leitfaden, Überwachung, Monitoring, interne Audits
	\|description=Praxisleitfaden für Grundschutz++: kontinuierliche Überwachung, teilautomatisierte Nachweise und interne Audits als Ersatz für den klassischen Grundschutzcheck.}}{{SHORTDESC:Grundschutz++ Leitfaden: Überwachung, interne Audits & kontinuierliche Bewertung.}}''Der Artikel beschreibt, wie der klassische Grundschutzcheck im Grundschutz++ durch ein kontinuierliches, teilautomatisiertes Verfahren ersetzt wird. Im Zentrum stehen laufende Statusermittlung je Anforderung, Monitoring als Evidenzquelle und risikoorientierte interne Audits. Ergänzend wird gezeigt, wie Feststellungen standardisiert bewertet und konsequent in Maßnahmen, Risikobetrachtungen, Ausnahmen und Managementberichte überführt werden. Ziel ist ein wiederholbarer, auditierbarer Regelbetrieb, der den PDCA‑Zyklus der Methodik Grundschutz++ praktisch füllt.''		\|description=Praxisleitfaden für Grundschutz++: kontinuierliche Überwachung, teilautomatisierte Nachweise und interne Audits als Ersatz für den klassischen Grundschutzcheck.}}{{SHORTDESC:Grundschutz++ Leitfaden: Überwachung, interne Audits & kontinuierliche Bewertung. (ehem. Grundschutzcheck)}}{{DISPLAYTITLE:Überwachung, interne Audits & kontinuierliche Bewertung}}''Der Artikel beschreibt, wie der klassische Grundschutzcheck im Grundschutz++ durch ein kontinuierliches, teilautomatisiertes Verfahren ersetzt wird. Im Zentrum stehen laufende Statusermittlung je Anforderung, Monitoring als Evidenzquelle und risikoorientierte interne Audits. Ergänzend wird gezeigt, wie Feststellungen standardisiert bewertet und konsequent in Maßnahmen, Risikobetrachtungen, Ausnahmen und Managementberichte überführt werden. Ziel ist ein wiederholbarer, auditierbarer Regelbetrieb, der den PDCA‑Zyklus der Methodik Grundschutz++ praktisch füllt.''

	== Überwachung, interne Audits und kontinuierliche Bewertung ==		== Überwachung, interne Audits und kontinuierliche Bewertung ==

Grundschutz:Überwachung und Audits

Dirk — Sun, 07 Jun 2026 10:52:00 GMT

Die Seite wurde neu angelegt: „{{#seo: |title=Grundschutz++: Überwachung, interne Audits & kontinuierliche Bewertung |keywords=ISMS, BSI, Grundschutz++, Grundschutzcheck, Durchführung, Leitfaden, Überwachung, Monitoring, interne Audits |description=Praxisleitfaden für Grundschutz++: kontinuierliche Überwachung, teilautomatisierte Nachweise und interne Audits als Ersatz für den klassischen Grundschutzcheck.}}{{SHORTDESC:Grundschutz++ Leitfaden: Überwachung, interne Audits & kont…“

Neue Seite

{{#seo:
|title=Grundschutz++: Überwachung, interne Audits & kontinuierliche Bewertung
|keywords=ISMS, BSI, Grundschutz++, Grundschutzcheck, Durchführung, Leitfaden, Überwachung, Monitoring, interne Audits
|description=Praxisleitfaden für Grundschutz++: kontinuierliche Überwachung, teilautomatisierte Nachweise und interne Audits als Ersatz für den klassischen Grundschutzcheck.}}{{SHORTDESC:Grundschutz++ Leitfaden: Überwachung, interne Audits & kontinuierliche Bewertung.}}''Der Artikel beschreibt, wie der klassische Grundschutzcheck im Grundschutz++ durch ein kontinuierliches, teilautomatisiertes Verfahren ersetzt wird. Im Zentrum stehen laufende Statusermittlung je Anforderung, Monitoring als Evidenzquelle und risikoorientierte interne Audits. Ergänzend wird gezeigt, wie Feststellungen standardisiert bewertet und konsequent in Maßnahmen, Risikobetrachtungen, Ausnahmen und Managementberichte überführt werden. Ziel ist ein wiederholbarer, auditierbarer Regelbetrieb, der den PDCA‑Zyklus der Methodik Grundschutz++ praktisch füllt.''

== Überwachung, interne Audits und kontinuierliche Bewertung ==
Dieser Leitfaden beschreibt ein praxistaugliches Vorgehen für Grundschutz++, das die Funktion des klassischen Grundschutzchecks in eine kontinuierliche, teilautomatisierte Überwachung mit internen Audits überführt. Er orientiert sich an der Methodik Grundschutz++ und konkretisiert insbesondere den Prozessschritt 4 „Überwachung“ sowie die Schnittstellen zu Realisierung und kontinuierlicher Verbesserung.<blockquote>''Da die Methodik an einigen Stellen noch nicht konkretisiert wurde, orientiert sich der Leitfaden an den bisher bekannten Inhalten zur Überwachung. Durch die Konkretisierung der Methodik und die Ausarbeitung der Audit-Kriterien durch das BSI kann sich das hier beschriebene Vorgehen jedoch noch ändern.''</blockquote>

== Ziel und Einordnung ==
Im klassischen IT-Grundschutz diente der Grundschutzcheck dazu, den Umsetzungsstatus von Anforderungen strukturiert festzustellen und Abweichungen für die weitere Behandlung zu dokumentieren. In Grundschutz++ tritt an diese Stelle kein einmaliger Check mehr, sondern ein Regelkreis aus laufender Statusermittlung, risikoorientierter Überwachung, internen Audits, Managementbewertung und Wirksamkeitsprüfung.

Die Methodik Grundschutz++ definiert dafür fünf Prozessschritte im PDCA-Zyklus: Erhebung und Planung, Anforderungsanalyse, Realisierung, Überwachung sowie kontinuierliche Verbesserung. Der hier beschriebene Leitfaden fokussiert auf den operativen Ablauf, mit dem Organisationen den Nachweis des Sicherheitsniveaus fortlaufend führen und Abweichungen systematisch in Umsetzungsplanung, Risikobetrachtung und Verbesserungsmaßnahmen zurückspielen.

== Grundprinzip ==
Das funktionale Äquivalent zum Grundschutzcheck im Grundschutz++ besteht aus drei verzahnten Prozessschritten: laufende Ermittlung des Umsetzungsstatus je Anforderung, kontinuierliches Monitoring sicherheitsrelevanter Sachverhalte und risikoorientierte interne Audits. Erst die Kombination dieser Schritte liefert ein belastbares Bild darüber, ob Anforderungen formal vorhanden, tatsächlich wirksam und für den aktuellen Informationsverbund noch angemessen sind.

Für die Praxis bedeutet das: Der Umsetzungsstatus wird nicht nur periodisch manuell erhoben, sondern soweit möglich aus vorhandenen Systemen, Tickets, Konfigurationen, Nachweisen und Monitoringdaten gespeist. Interne Audits prüfen ergänzend stichprobenartig, themenbezogen oder anlassbezogen, ob diese Informationen zutreffend sind und ob Verfahren tatsächlich gelebt werden.

== Abgrenzung zum klassischen Grundschutzcheck ==
{| class="wikitable"
!Aspekt
!Klassischer Grundschutzcheck
!Grundschutz++-Vorgehen
|-
|Zweck
|Periodische Feststellung des Umsetzungsstatus
|Fortlaufende Bewertung von Status, Wirksamkeit und Angemessenheit
|-
|Taktung
|Jährliche oder anlassbezogene Erhebung
|Kontinuierlich plus geplante Audits
|-
|Datenbasis
|Interviews, Sichtung, manuelle Checklisten
|Nachweise, Systemdaten, Monitoring, Audits, Managementbewertung
|-
|Ergebnis
|Umsetzungsgrad und offene Maßnahmen
|Aktueller Status, Feststellungen, Risiken, Maßnahmen, Trends
|-
|Steuerung
|Maßnahmenverfolgung nach Check
|Integrierter PDCA-Regelkreis
|}
Der Grundschutz++ ersetzt den Check also nicht ersatzlos, sondern verteilt dessen Funktionen auf mehrere wiederkehrende/kontinuierliche Verfahren. Für Anwendende ist deshalb entscheidend, ein verbindliches Betriebsmodell für diese Verfahren zu definieren.

== Voraussetzungen ==
Vor dem operativen Betrieb müssen einige Grundlagen aus Prozessschritt 1 und 2 belastbar vorliegen. Ohne diese Grundlagen entsteht zwar Monitoring, aber kein methodisch belastbarer Nachweis im Sinne von Grundschutz++.

Erforderlich sind insbesondere:

* festgelegter Geltungsbereich des ISMS und definierte Informationsverbünde,
* dokumentierte Geschäftsprozesse, relevante Assets und deren Zuordnung zu Zielobjektkategorien,
* ein konsolidiertes Anforderungspaket je Informationsverbund einschließlich Ergänzungen aus externen Verpflichtungen und Risikobetrachtungen,
* definierte Rollen, Zuständigkeiten, Freigaben und Dokumentationswege,
* ein Verfahren für Risikobetrachtungen bei Nicht-Umsetzung, Sicherheitsniveau-Absenkung, hohem Schutzbedarf oder ergänzenden Anforderungen.

== Leitbild für den laufenden Betrieb ==
Für den laufenden Betrieb empfiehlt sich ein mehrstufiges Modell. Nicht jede Anforderung wird mit derselben Prüftiefe und derselben Frequenz bewertet; stattdessen werden Anforderungen nach Nachweisart, Kritikalität und Automatisierbarkeit behandelt. Dieses Vorgehen schließt eine wesentliche methodische Lücke zwischen abstrakter Überwachung und praktischer Umsetzbarkeit.

Sinnvoll könnte folgende Einteilung sein:

* '''Typ A – automatisiert prüfbar:''' technische Konfigurationen, Patchstände, Verschlüsselungsparameter, Logging-Aktivierung, Backup-Status, Schwachstellenbefunde, zentrale Identitäts- und Berechtigungsmerkmale.
* '''Typ B – teilautomatisiert prüfbar:''' Workflows mit Systembezug, etwa Ticketstatus, Genehmigungen, Fristen, dokumentierte Ausnahmen, Schulungsstände, Wiederholungsprüfungen.
* '''Typ C – manuell bzw. auditiv prüfbar:''' Governance, Rollenwahrnehmung, Wirksamkeit organisatorischer Verfahren, Angemessenheit von Entscheidungen, Vollständigkeit von Managementbewertungen.

Diese Zuordnung sollte je Anforderung oder Anforderungsgruppe dokumentiert werden. Sie bildet die Basis für Prüffrequenz, Datenquelle, Verantwortlichkeit und Eskalationsweg.

== Verfahrensmodell ==

=== 1. Prüfeinheiten festlegen ===
Die kleinste steuerbare Einheit ist nicht der gesamte Informationsverbund, sondern eine Anforderung in Bezug auf einen Verbund, ein Asset, einen Geschäftsprozess oder eine verbundweite Zuständigkeit. Für jede Prüfeinheit sollten mindestens folgende Metadaten gepflegt werden:

* eindeutige Anforderungs-ID,
* Bezug auf Informationsverbund, Asset oder Geschäftsprozess,
* federführend zuständige Rolle,
* Nachweisart,
* Prüfmethode,
* Prüffrequenz,
* Datenquelle bzw. Nachweisquelle,
* Status der letzten Bewertung,
* Datum der letzten Prüfung,
* Verweis auf Feststellungen, Risiken oder Maßnahmen.

Damit wird aus dem Anforderungspaket ein steuerbares Kontrollobjekt. Ohne diese Operationalisierung bleibt die Methodik in der Praxis zu grob.

=== 2. Umsetzungsstatus laufend ermitteln ===
Die Methodik verlangt, den Umsetzungsstatus aller Anforderungen systematisch zu überprüfen. Der Status ist grundsätzlich nur „umgesetzt“ oder „nicht umgesetzt“; eine Anforderung gilt nur dann als umgesetzt, wenn auch abhängige Anforderungen umgesetzt sind.

Für die Praxis ist eine Vorstufe sinnvoll, die intern mit Arbeitswerten arbeitet, etwa „Nachweis ausstehend“, „in Prüfung“ oder „Abweichung erkannt“. Formal in die Methodik zurückgeschrieben werden aber nur die beiden Ergebnisse „umgesetzt“ oder „nicht umgesetzt“, damit die Nachvollziehbarkeit zum GS++ gewahrt bleibt.

=== 3. Nachweise beschaffen und bewerten ===
Für jede Prüfeinheit ist festzulegen, welche Nachweise akzeptiert werden. Geeignete Nachweise können unter anderem sein:

* Systemkonfigurationen und automatisierte Prüfergebnisse,
* Tickets, Freigaben, Changes und Ausnahmegenehmigungen,
* Protokolle aus Schwachstellenmanagement, Incident Handling oder Notfallübungen,
* Schulungs- und Sensibilisierungsnachweise,
* Richtlinien, Leitlinien und freigegebene Verfahrensdokumente,
* Auditnachweise aus Interviews, Beobachtungen und Stichproben.

Ein Nachweis ist nur belastbar, wenn Aktualität, Geltungsbezug und Verantwortlichkeit erkennbar sind. Reine Dokumentenexistenz genügt nicht, wenn die tatsächliche Anwendung nicht plausibel belegt ist.

=== 4. Monitoring etablieren ===
Prozessschritt 4 verlangt geeignete Monitoringmethoden und -tools zur Erkennung von Sicherheitsvorfällen, Schwachstellen, neuen Bedrohungen und relevanten Veränderungen. Genannt werden unter anderem SIEM, IDS/IPS, Vulnerability-Management und Configuration-Monitoring; die konkrete Ausprägung ist an Größe und Komplexität der Institution anzupassen.

Für den Leitfaden bedeutet das: Monitoring dient nicht nur der Incident Detection, sondern auch als fortlaufende Evidenzquelle für den Umsetzungsstatus und für die Leistungsbewertung des ISMS. Jede Monitoringquelle sollte deshalb einem oder mehreren Anforderungen, Risiken oder Kennzahlen zuordenbar sein.

=== 5. Interne Audits risikoorientiert planen ===
Grundschutz++ fordert ein strukturiertes Auditprogramm mit risikoorientierter Planung, dokumentierten Auditplänen, geeigneten und unabhängigen Auditoren sowie nachvollziehbarer Nachverfolgung. Alle angewandten Praktiken sollen mindestens einmal sinnvoll geprüft werden.

Ein praxistaugliches Auditprogramm kombiniert daher mehrere Auditarten:

* turnusmäßige Systemaudits für definierte Informationsverbünde,
* themenbezogene Audits, etwa Identitätsmanagement, Protokollierung, Notfallmanagement oder Lieferantensteuerung,
* anlassbezogene Audits nach Sicherheitsvorfällen, wesentlichen Änderungen, neuen regulatorischen Anforderungen oder wiederholten Abweichungen,
* Follow-up-Audits zur Wirksamkeitskontrolle umgesetzter Maßnahmen.

=== 6. Feststellungen bewerten ===
Die Methodik verlangt ein einheitliches Bewertungsschema und strukturierte Auditberichte. Sie fordert außerdem, identifizierte Schwachstellen, positive Feststellungen und empfohlene Maßnahmen nachvollziehbar zu dokumentieren.

Für die Praxis empfiehlt sich mindestens folgende Klassifikation:

* Nichtkonformität,
* Teilnachweis bzw. unzureichender Nachweis,
* Verbesserungspotenzial,
* positive Feststellung,
* Beobachtung ohne unmittelbaren Maßnahmenbedarf.

Wichtig ist die methodische Trennung zwischen Feststellung und Risiko: Nicht jede Feststellung ist automatisch ein hohes Risiko, aber jede Nicht-Umsetzung relevanter Anforderungen muss in die Risikobetrachtung oder Maßnahmenplanung überführt werden, soweit die Methodik dies verlangt.

=== 7. In Maßnahmen und Risiken überführen ===
Fehlende Umsetzungen, relevante Auditfeststellungen, Compliance-Lücken, neue Bedrohungen oder erkannte Schwachstellen müssen in Umsetzungsplanung, Risikobetrachtung und Verbesserungsprozess übernommen werden. Die Methodik beschreibt dafür die Schnittstellen von Prozessschritt 4 zu Realisierung und kontinuierlicher Verbesserung ausdrücklich.

In der Praxis sollte jede relevante Feststellung genau einen primären Folgemechanismus erhalten:

* Umsetzungsmaßnahme,
* Risikobetrachtung,
* Ausnahmeentscheidung,
* Korrekturmaßnahme,
* Verbesserungsmaßnahme,
* reine Beobachtung mit Termin zur erneuten Prüfung.

Dadurch werden Doppelbearbeitung und methodische Leerstellen vermieden.

== Empfohlener Betriebszyklus ==
Ein sinnvoller Regelbetrieb kann in vier Takte gegliedert werden. Die konkrete Frequenz hängt von Größe, Schutzbedarf, Regulatorik und Automatisierungsgrad ab; die Methodik nennt für die Validierung des Anforderungspakets als Orientierungswert im Allgemeinen jährlich, abhängig von Organisationsgröße, Parametern und Prüftiefe.
{| class="wikitable"
!Takt
!Inhalt
!Ziel
|-
|laufend
|Monitoring, Schwachstellenbehandlung, Incident-Erkennung, Nachweisaktualisierung
|Früherkennung und aktuelle Evidenzbasis
|-
|monatlich oder quartalsweise
|Review offener Feststellungen, Maßnahmenstatus, Fristen, Ausnahmen, Kennzahlen
|operative Steuerung
|-
|quartalsweise oder halbjährlich
|risikoorientierte interne Audits und thematische Prüfungen
|unabhängige Wirksamkeitskontrolle
|-
|mindestens jährlich
|Managementbewertung und Validierung des Anforderungspakets
|strategische Neubewertung und PDCA-Abschluss
|}
Für kleinere Institutionen kann dieser Zyklus schlanker ausgestaltet werden. Wesentlich ist nicht maximale Formalisierung, sondern die verlässliche Wiederholbarkeit und Dokumentation.

== Rollenmodell ==
Die Methodik fordert klare Rollen, unabhängige Auditierung und dokumentierte Zuständigkeiten. Für den Leitfaden ist folgende Mindestverteilung zweckmäßig:
{| class="wikitable"
!Rolle
!Kernaufgaben im Leitfaden
|-
|Institutionsleitung
|Freigaben, Prioritäten, Behandlung wesentlicher Risiken, Managementbewertung
|-
|ISB
|Steuerung des Verfahrens, Auditprogramm, Konsolidierung der Ergebnisse, Eskalation
|-
|Prozess- oder Asset-Owner
|Nachweise liefern, Status bestätigen, Maßnahmen umsetzen
|-
|Auditierende
|unabhängige Prüfung, Feststellungen, Berichte
|-
|Compliance-/Datenschutz-/Fachstellen
|Einbringung externer Verpflichtungen und Fachanforderungen
|-
|Betrieb/Administration/SOC
|technische Evidenz, Monitoring, Incident- und Schwachstelleninformationen
|}
Die Rollen sollten nicht nur textlich beschrieben, sondern in einem konkreten RACI oder vergleichbaren Zuständigkeitsmodell hinterlegt werden. Gerade im GS++ mit verteilten Zuständigkeiten ist das für die Auditierbarkeit entscheidend.

== Mindestinhalte eines Auditplans ==
Für jedes interne Audit sollte mindestens dokumentiert werden:

* Auditgegenstand und Bezug auf Informationsverbund oder Thema,
* Auditziele,
* Auditkriterien, insbesondere relevante Anforderungen, interne Vorgaben und externe Verpflichtungen,
* Auditumfang und Abgrenzung,
* Methoden, zum Beispiel Interview, Dokumentensichtung, technische Stichprobe, Beobachtung,
* Audittermin und Zeitraum,
* Auditierende und geprüfte Rollen,
* Unabhängigkeit der Auditierenden,
* Berichtsempfänger,
* Frist und Verfahren für Maßnahmenrückmeldung.

Diese Inhalte leiten sich direkt aus den methodischen Vorgaben zum Auditprogramm und zu Auditplänen ab und schließen die in der Methodik offen gelassene operative Ausgestaltung.

== Mindestinhalte eines Auditberichts ==
Ein Auditbericht sollte mindestens enthalten:

* Zusammenfassung von Ziel, Umfang und Methode,
* geprüfte Anforderungen oder Themenbereiche,
* verwendete Nachweise,
* Feststellungen je Anforderung oder Themenblock,
* Bewertung nach einheitlichem Schema,
* Begründung der Bewertung,
* positive Feststellungen,
* empfohlene Maßnahmen,
* Fristen, Zuständigkeiten und Verweise auf Tickets oder Maßnahmenobjekte,
* Entscheidung, ob eine Risikobetrachtung erforderlich ist.

Damit ist der Bericht nicht nur Revisionsdokument, sondern unmittelbar als Input für Prozessschritt 3 und 5 nutzbar.

== Bewertungslogik für Anforderungen ==
Für eine einzelne Anforderung empfiehlt sich folgende Entscheidungslogik:

# Ist die Anforderung für den betrachteten Informationsverbund, das Asset oder den Geschäftsprozess relevant?
# Liegt ein belastbarer, aktueller und dem Geltungsbereich zuordenbarer Nachweis vor?
# Ist die Anforderung inhaltlich vollständig erfüllt, einschließlich relevanter Abhängigkeiten?
# Gibt es Hinweise aus Monitoring, Vorfällen, Schwachstellen oder Audits, dass die Anforderung zwar formal vorhanden, aber nicht wirksam ist?
# Ist eine Ausnahme dokumentiert und durch die zuständige Rolle freigegeben?
# Muss die Nicht-Umsetzung oder Abweichung in eine Risikobetrachtung überführt werden?

Erst wenn die Punkte 2 bis 4 positiv beantwortet werden können, sollte der formale Status „umgesetzt“ gesetzt werden. Andernfalls ist „nicht umgesetzt“ methodisch sauberer, ergänzt um eine differenzierte interne Feststellung.

== Kennzahlen und Berichte ==
Die Methodik fordert eine Leistungsbewertung des ISMS, Managementbewertungen und eine transparente Darstellung des Sicherheitsniveaus einschließlich Trends. Sie nennt ausdrücklich Kennzahlen, grafische Darstellungen und Trendanalysen als geeignete Instrumente.

Für einen praxistauglichen Managementbericht eignen sich mindestens folgende Kennzahlen:

* Anteil umgesetzter Anforderungen je Informationsverbund,
* Anzahl offener Nichtkonformitäten nach Schweregrad,
* Fristverletzungen bei Maßnahmen,
* Anzahl und Alter offener Ausnahmen,
* Schwachstellenbestand und Behebungszeiten,
* Auditabdeckung nach Praktiken und Verbünden,
* Anzahl relevanter Sicherheitsvorfälle,
* Trend des Sicherheitsniveaus über Berichtszeiträume.

Wichtig ist, dass Kennzahlen nicht isoliert betrachtet werden. Sie müssen mit Feststellungen, Risiken und getroffenen Entscheidungen verknüpft werden, sonst bleiben sie steuerungsarm.

== Behandlung typischer Fälle ==

=== Fall 1: Nachweis fehlt, Umsetzung wahrscheinlich vorhanden ===
Ohne belastbaren Nachweis sollte die Anforderung nicht als umgesetzt gewertet werden. Praktisch kann eine kurzfristige Nachweiserbringung mit enger Frist vorgesehen werden; bleibt sie aus, ist die Feststellung wie jede andere Nicht-Umsetzung zu behandeln.

=== Fall 2: Dokument vorhanden, gelebter Prozess fehlt ===
Das ist kein Dokumentationsmangel, sondern eine Nichtkonformität in der Wirksamkeit. Der Fall gehört regelmäßig in Auditfeststellung, Maßnahme und gegebenenfalls Risikobetrachtung.

=== Fall 3: Technische Abweichung durch bewusste Ausnahme ===
Dann muss die Ausnahme begründet, freigegeben, befristet und nachverfolgbar dokumentiert sein. Fehlt eines dieser Elemente, liegt keine tragfähige Ausnahme im Sinne eines kontrollierten Ausnahmemanagements vor.

=== Fall 4: Neue Assets oder Änderungen im Verbund ===
Dann ist nicht nur eine Einzelmaßnahme nötig; vielmehr muss das Anforderungspaket validiert und bei Bedarf neu modelliert oder ergänzt werden. Die Methodik sieht hierfür ausdrücklich die regelmäßige Validierung der Anforderungen und die Berücksichtigung veränderter Geschäftsprozesse, IT-Komponenten und externer Faktoren vor.

== Empfehlungen zur Teilautomatisierung ==
Die Methodik empfiehlt bei mittleren und großen Institutionen ausdrücklich einen teilautomatisierten oder weitgehend automatisierten Betrieb des ISMS und betont die Maschinenlesbarkeit der Anforderungen sowie die Möglichkeit toolgestützter Modellierung und Vererbung.

Für den Leitfaden folgen daraus diese Mindestanforderungen an eine praxistaugliche Toolunterstützung:

* zentrales Register der Anforderungen mit Statushistorie,
* Verknüpfung von Anforderungen, Assets, Verbünden, Risiken, Maßnahmen und Nachweisen,
* Import oder Anbindung technischer Evidenzquellen,
* Workflow für Feststellungen, Freigaben, Ausnahmen und Fristen,
* revisionsfeste Historisierung,
* auswertbare Kennzahlen und Trendberichte,
* Schnittstelle zum Auditprogramm und Managementbericht.

Ohne solche Strukturen skaliert Grundschutz++ nur begrenzt. Für kleinere Umgebungen kann dies zunächst auch mit Wiki, Ticketsystem und wenigen technischen Datenquellen umgesetzt werden, solange Eindeutigkeit, Aktualität und Nachvollziehbarkeit gewahrt bleiben.

Für mittlere und große Informationsverbünde lässt sich das nur mit einem ausgereiften ISMS-Tool und der Integration entsprechender Sensoren und Schnittstellen an eine CMDB oder ein SIEM praktikabel umsetzen.

== Mindestverfahren als Dokumentationsstruktur ==
Für eine Dokumentation des Vorgehens in Form eines Umsetzungsleitfadens bietet sich die folgende Gliederung an:

# Zweck und Abgrenzung des Verfahrens.
# Begriffe: Überwachung, interne Audits, Feststellung, Nichtkonformität, Ausnahme, Wirksamkeitsprüfung.
# Voraussetzungen aus Geltungsbereich, Informationsverbund und Anforderungspaket.
# Rollen und Zuständigkeiten.
# Prüfeinheiten und Nachweisarten.
# Laufende Statusermittlung.
# Monitoring als Evidenzquelle.
# Auditprogramm und Auditplanung.
# Durchführung interner Audits.
# Bewertungsschema und Berichtswesen.
# Übergabe an Risikobetrachtung, Maßnahmenmanagement und Verbesserung.
# Managementbewertung und Trendanalyse.
# Vorlagen und Beispieltabellen.

== Beispieltabellen für die Dokumentation ==

=== Tabelle: Register für Prüfeinheiten ===
{| class="wikitable"
!Feld
!Beschreibung
|-
|Anforderung
|eindeutige Kennung der Anforderung
|-
|Verbund/Asset/Prozess
|Bezugsobjekt der Prüfung
|-
|Prüftyp
|automatisiert, teilautomatisiert, manuell
|-
|Nachweisquelle
|System, Ticket, Dokument, Audit, Monitoring
|-
|Prüffrequenz
|laufend, monatlich, quartalsweise, jährlich, anlassbezogen
|-
|Verantwortliche Rolle
|fachlich führende Zuständigkeit
|-
|Letztes Ergebnis
|umgesetzt oder nicht umgesetzt
|-
|Letzte Prüfung
|Datum
|-
|Folgemaßnahme
|Ticket, Risiko, Ausnahme oder Verbesserung
|}

=== Tabelle: Bewertung von Feststellungen ===
{| class="wikitable"
!Kategorie
!Bedeutung
!Folge
|-
|Nichtkonformität
|Anforderung nicht erfüllt oder nicht wirksam
|Maßnahme, ggf. Risikobetrachtung
|-
|Unzureichender Nachweis
|Nachweis für Erfüllung nicht belastbar
|Nachweiserbringung oder Neubewertung
|-
|Verbesserungspotenzial
|keine Pflichtverletzung, aber Optimierung sinnvoll
|Verbesserungsmaßnahme
|-
|Positive Feststellung
|wirksame, gute Praxis
|dokumentieren, ggf. multiplizieren
|-
|Beobachtung
|Hinweis ohne unmittelbare Abweichung
|Wiedervorlage
|}

=== Tabelle: Taktung des Verfahrens ===
{| class="wikitable"
!Aktivität
!Mindesttakt
!Anlassbezogene Auslöser
|-
|Aktualisierung technischer Evidenzen
|laufend
|Änderungen, neue Systeme, Vorfälle
|-
|Review offener Maßnahmen
|monatlich oder quartalsweise
|Fristüberschreitung, Eskalation
|-
|interne Audits
|risikoorientiert, mindestens nach Auditprogramm
|Vorfall, wesentliche Änderung, Compliance-Hinweis
|-
|Validierung des Anforderungspakets
|im Allgemeinen jährlich
|neue Assets, neue Verpflichtungen, neue Bedrohungen
|-
|Managementbewertung
|mindestens jährlich
|schwerwiegende Feststellungen, strategische Änderungen
|}

== Methodische Lücken und ihre Schließung ==
Die Methodik beschreibt die Zielrichtung der Überwachung, lässt aber mehrere operative Fragen offen. Für einen belastbaren Umsetzungsleitfaden sollten diese Punkte verbindlich ergänzt werden:

* '''Prüfobjekt festlegen:''' Nicht pauschal „Informationsverbund prüfen“, sondern Anforderungen als kleinste Prüfeinheit definieren.
* '''Nachweislogik definieren:''' Welche Evidenzen zulässig sind, wie aktuell sie sein müssen und wann sie als unzureichend gelten.
* '''Zwischenstatus nur intern verwenden:''' Methodisch bleibt der Endstatus binär; operative Zwischenstände dürfen die formale Bewertung nicht verwässern.
* '''Feststellungen standardisieren:''' Einheitliches Schema für Nichtkonformität, Nachweislücke, Verbesserungspotenzial und positive Feststellung.
* '''Folgeprozess erzwingen:''' Jede relevante Feststellung muss eindeutig in Maßnahme, Risiko, Ausnahme oder Beobachtung überführt werden.
* '''Auditabdeckung regeln:''' Alle angewandten Praktiken müssen über den Auditzyklus sinnvoll geprüft werden; risikoorientiert, aber nicht beliebig.
* '''Wirksamkeit separat prüfen:''' Umsetzung allein reicht nicht; Wirksamkeit muss gesondert bewertet werden.
* '''Änderungen rückkoppeln:''' Neue Assets, neue Pflichten oder neue Bedrohungen müssen zur Validierung des Anforderungspakets führen.

== Kurzverfahren für kleine Institutionen ==
Für kleine Institutionen kann das Verfahren reduziert werden, ohne den methodischen Kern zu verlieren:

* ein gemeinsames Register für Anforderungen, Nachweise, Feststellungen und Maßnahmen,
* quartalsweiser Review durch ISB und Verantwortliche,
* wenige, klar fokussierte interne Audits pro Jahr,
* Nutzung vorhandener Tickets, Checklisten und Systemberichte statt separater Spezialwerkzeuge,
* jährliche Managementbewertung und Validierung des Anforderungspakets.

Entscheidend ist auch hier, dass Nachweise aktuell sind, Ausnahmen dokumentiert werden und Nicht-Umsetzungen in Maßnahmen oder Risiken münden.

== Ergebnis des Verfahrens ==
Das Ergebnis dieses Leitfadens ist kein einmaliger Prüfbericht, sondern ein dauerhaft betriebenes Nachweis- und Steuerungsverfahren. Es ersetzt den klassischen Grundschutzcheck funktional durch einen wiederholbaren, auditierbaren und teilautomatisierbaren Mechanismus zur Feststellung von Umsetzungsstatus, Wirksamkeit, Sicherheitsniveau und Verbesserungsbedarf im Grundschutz++.

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

Grundschutz++

Dirk — Sun, 07 Jun 2026 10:51:10 GMT

← Nächstältere Version		Version vom 7. Juni 2026, 12:51 Uhr
Zeile 50:		Zeile 50:
	*[[Managementbericht\|Erstellen eines Managementberichts]]		*[[Managementbericht\|Erstellen eines Managementberichts]]
	*[[Reifegradmodell\|Erstellen eines Reifegradmodells]]		*[[Reifegradmodell\|Erstellen eines Reifegradmodells]]
			*[[Grundschutz:Überwachung und Audits\|Überwachung, interne Audits & kontinuierliche Bewertung]]⚠️
	*[[Dokumentenmanagement\|Einführung in das Dokumentenmanagement]]		*[[Dokumentenmanagement\|Einführung in das Dokumentenmanagement]]
	*[[Risikomanagement\|Einführung in das Risikomanagement]]		*[[Risikomanagement\|Einführung in das Risikomanagement]]

Inhalt-Übersicht

Dirk — Sun, 07 Jun 2026 04:00:09 GMT

Automatisch erzeugte Inhaltsübersicht aktualisiert

Grundschutz:Begriffsdefinition

Dirk — Sat, 06 Jun 2026 10:18:46 GMT

Zielobjektkategorien

← Nächstältere Version		Version vom 6. Juni 2026, 12:18 Uhr
Zeile 210:		Zeile 210:
	==== Zielobjektkategorien ====		==== Zielobjektkategorien ====
	[[Datei:Zielobjektkategorien.png\|alternativtext=Zielobjektkategorien\|mini\|286x286px\|Zielobjektkategorien]]		[[Datei:Zielobjektkategorien.png\|alternativtext=Zielobjektkategorien\|mini\|286x286px\|Zielobjektkategorien]]
	Zielobjektkategorien und sind Bestandteile eines Informationsverbunds, denen spezifische Anforderungen zugeordnet sind. Das können sowohl physische Objekte (z.B. Server, Räume) als auch logische Objekte (z.B. Anwendungen, Daten) sein. Die ~~Zielobjekte~~ entsprechen damit ansatzweise den "'''''Bausteinen'''''" im klassischen IT-Grundschutz. In der Modellierung werden Assets den Zielobjektkategorien zugeordnet und erben über diese ihre Anforderungen.		Zielobjektkategorien und sind Bestandteile eines Informationsverbunds, denen spezifische Anforderungen zugeordnet sind. Das können sowohl physische Objekte (z.B. Server, Räume) als auch logische Objekte (z.B. Anwendungen, Daten) sein. Die Zielobjektkategorien entsprechen damit ansatzweise den "'''''Bausteinen'''''" im klassischen IT-Grundschutz. In der Modellierung werden Assets den Zielobjektkategorien zugeordnet und erben über diese ihre Anforderungen.

	Zielobjektkategorien bilden einen hierarchischen Kategoriebaum. Assets erben Anforderungen aus ihrer Kategorie und allen übergeordneten Kategorien bis zur Wurzel. Es sind also auch stets alle übergeordneten Zielobjektkategorien bis zur Wurzel des Kategoriebaums mit zu modellieren, um so eine lückenlose Abbildung zu gewährleisten.		Zielobjektkategorien bilden einen hierarchischen Kategoriebaum. Assets erben Anforderungen aus ihrer Kategorie und allen übergeordneten Kategorien bis zur Wurzel. Es sind also auch stets alle übergeordneten Zielobjektkategorien bis zur Wurzel des Kategoriebaums mit zu modellieren, um so eine lückenlose Abbildung zu gewährleisten.

Grundschutz:Migration

Dirk — Sat, 06 Jun 2026 09:21:00 GMT

Zielsetzung dies Leitfadens

State Level Actor

Dirk — Sat, 06 Jun 2026 08:44:54 GMT

← Nächstältere Version		Version vom 6. Juni 2026, 10:44 Uhr
Zeile 55:		Zeile 55:
	* ENISA Threat‑Landscape‑Berichte mit detaillierten Analysen zu Kampagnen und Taktiken staatlich unterstützter Akteure, z.B. Kapitel zu „State‑Sponsored Actors“ in den jährlichen Reports (verlinkt von der Übersichtsseite): https://www.enisa.europa.eu/topics/cyber-threats/threat-landscape		* ENISA Threat‑Landscape‑Berichte mit detaillierten Analysen zu Kampagnen und Taktiken staatlich unterstützter Akteure, z.B. Kapitel zu „State‑Sponsored Actors“ in den jährlichen Reports (verlinkt von der Übersichtsseite): https://www.enisa.europa.eu/topics/cyber-threats/threat-landscape

	[[Kategorie:~~Bedrohungsakteur~~]]		[[Kategorie:Kurzartikel]]
	__KEIN_INHALTSVERZEICHNIS__		__KEIN_INHALTSVERZEICHNIS__

Grundschutz:Einführung und Aufbau

Dirk — Sat, 06 Jun 2026 08:43:28 GMT

Inhalt-Übersicht

Dirk — Sat, 06 Jun 2026 04:00:05 GMT

Automatisch erzeugte Inhaltsübersicht aktualisiert

← Nächstältere Version		Version vom 6. Juni 2026, 06:00 Uhr
Zeile 3:		Zeile 3:
	{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}		{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}
	;Stand		;Stand
	:2026-06-05 04:00 (UTC)		:2026-06-06 04:00 (UTC)

	;Anzahl Seiten gesamt		;Anzahl Seiten gesamt
Zeile 118:		Zeile 118:
	\| [[Grundschutz++\|Grundschutz++]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz%2B%2B Link] \|\| 7180 \|\| 2026-05-06 18:03:15 UTC \|\| Dirk \|\| Grundschutz++: Digitale Reform & OSCAL-basierte Sicherheit		\| [[Grundschutz++\|Grundschutz++]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz%2B%2B Link] \|\| 7180 \|\| 2026-05-06 18:03:15 UTC \|\| Dirk \|\| Grundschutz++: Digitale Reform & OSCAL-basierte Sicherheit
	\|-		\|-
	\| [[Hauptseite\|Hauptseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/Hauptseite Link] \|\| ~~13603~~ \|\| 2026-05~~-09 15~~:18:13 UTC \|\| Dirk \|\| Das freie ISMS-Ratgeber Wiki für Informationssicherheit und Datenschutz		\| [[Hauptseite\|Hauptseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/Hauptseite Link] \|\| 13691 \|\| 2026-06-05 08:19:48 UTC \|\| Dirk \|\| Das freie ISMS-Ratgeber Wiki für Informationssicherheit und Datenschutz
	\|-		\|-
	\| [[Hilfe\|Hilfe]] \|\| [https://wiki.isms-ratgeber.info/wiki/Hilfe Link] \|\| 817 \|\| 2025-02-07 17:17:52 UTC \|\| Dirk \|\| Hilfen zur Beabeitung von MediaWiki Seiten.		\| [[Hilfe\|Hilfe]] \|\| [https://wiki.isms-ratgeber.info/wiki/Hilfe Link] \|\| 817 \|\| 2025-02-07 17:17:52 UTC \|\| Dirk \|\| Hilfen zur Beabeitung von MediaWiki Seiten.
Zeile 164:		Zeile 164:
	\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.		\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.
	\|-		\|-
	\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| ~~47643~~ \|\| 2026-06-04 04:00:04 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.		\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| 47633 \|\| 2026-06-05 04:00:06 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.
	\|-		\|-
	\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.		\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.

Hauptseite

Dirk — Fri, 05 Jun 2026 08:19:48 GMT

← Nächstältere Version		Version vom 5. Juni 2026, 10:19 Uhr
Zeile 73:		Zeile 73:
	*[[KI:EU AI Act\|EU AI Act: ISMS-Integration, Risiken & Umsetzung]]		*[[KI:EU AI Act\|EU AI Act: ISMS-Integration, Risiken & Umsetzung]]
	*[[KI-Nutzung\|Chancen und Risiken von KI]]		*[[KI-Nutzung\|Chancen und Risiken von KI]]
			*[[NIS2_Überblick_und_Anforderungen\|NIS2: Überblick & Anforderungen im ISMS-Kontext]]
	*[[Industrielle IT\|Grundlagen & Sicherheitsaspekte Industrieller IT]]		*[[Industrielle IT\|Grundlagen & Sicherheitsaspekte Industrieller IT]]
	*[[Bücher und Links\|Informative Bücher und Links]]		*[[Bücher und Links\|Informative Bücher und Links]]

Inhalt-Übersicht

Dirk — Fri, 05 Jun 2026 04:00:06 GMT

Automatisch erzeugte Inhaltsübersicht aktualisiert

← Nächstältere Version		Version vom 5. Juni 2026, 06:00 Uhr
Zeile 3:		Zeile 3:
	{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}		{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}
	;Stand		;Stand
	:2026-06-04 04:00 (UTC)		:2026-06-05 04:00 (UTC)

	;Anzahl Seiten gesamt		;Anzahl Seiten gesamt
Zeile 164:		Zeile 164:
	\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.		\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.
	\|-		\|-
	\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| 47643 \|\| 2026-06-03 04:00:04 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.		\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| 47643 \|\| 2026-06-04 04:00:04 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.
	\|-		\|-
	\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.		\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.
Zeile 218:		Zeile 218:
	\| [[NIS2\|NIS2]] \|\| [https://wiki.isms-ratgeber.info/wiki/NIS2 Link] \|\| 3335 \|\| 2026-05-30 15:05:26 UTC \|\| Dirk \|\| NIS2-Richtlinie (Network and Information Security Directive 2) der EU.		\| [[NIS2\|NIS2]] \|\| [https://wiki.isms-ratgeber.info/wiki/NIS2 Link] \|\| 3335 \|\| 2026-05-30 15:05:26 UTC \|\| Dirk \|\| NIS2-Richtlinie (Network and Information Security Directive 2) der EU.
	\|-		\|-
	\| [[NIS2 Überblick und Anforderungen\|NIS2 Überblick und Anforderungen]] \|\| [https://wiki.isms-ratgeber.info/wiki/NIS2_%C3%9Cberblick_und_Anforderungen Link] \|\| ~~30977~~ \|\| 2026-05-~~30 11~~:36:19 UTC \|\| Dirk \|\| NIS2-Richtlinie ~~(Network and Information Security Directive 2) der EU~~.		\| [[NIS2 Überblick und Anforderungen\|NIS2 Überblick und Anforderungen]] \|\| [https://wiki.isms-ratgeber.info/wiki/NIS2_%C3%9Cberblick_und_Anforderungen Link] \|\| 37107 \|\| 2026-06-04 13:07:27 UTC \|\| Dirk \|\| NIS2-Richtlinie: Überblick & Anforderungen im ISMS-Kontext.
	\|-		\|-
	\| [[Nebenwirkungen\|Nebenwirkungen]] \|\| [https://wiki.isms-ratgeber.info/wiki/Nebenwirkungen Link] \|\| 4533 \|\| 2024-08-03 05:59:56 UTC \|\| Dirk \|\| Zu Risiken und Nebewirkungen lesen sie die Packungsbeilage		\| [[Nebenwirkungen\|Nebenwirkungen]] \|\| [https://wiki.isms-ratgeber.info/wiki/Nebenwirkungen Link] \|\| 4533 \|\| 2024-08-03 05:59:56 UTC \|\| Dirk \|\| Zu Risiken und Nebewirkungen lesen sie die Packungsbeilage

NIS2 Überblick und Anforderungen

Dirk — Thu, 04 Jun 2026 13:07:27 GMT

Änderungen zeigen

Inhalt-Übersicht

Dirk — Thu, 04 Jun 2026 04:00:04 GMT

Automatisch erzeugte Inhaltsübersicht aktualisiert

← Nächstältere Version		Version vom 4. Juni 2026, 06:00 Uhr
(4 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 3:		Zeile 3:
	{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}		{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}
	;Stand		;Stand
	:2026-05-30 04:00 (UTC)		:2026-06-04 04:00 (UTC)

	;Anzahl Seiten gesamt		;Anzahl Seiten gesamt
	:~~213~~		:214

	== Hauptnamensraum ==		== Hauptnamensraum ==

	;Anzahl Seiten		;Anzahl Seiten
	~~178~~		179

	{\| class="wikitable sortable"		{\| class="wikitable sortable"
Zeile 164:		Zeile 164:
	\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.		\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.
	\|-		\|-
	\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| ~~47363~~ \|\| 2026-05-29 04:00:04 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.		\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| 47643 \|\| 2026-06-03 04:00:04 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.
	\|-		\|-
	\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.		\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.
Zeile 216:		Zeile 216:
	\| [[NEUPLAST-Demoverbund\|NEUPLAST-Demoverbund]] \|\| [https://wiki.isms-ratgeber.info/wiki/NEUPLAST-Demoverbund Link] \|\| 7620 \|\| 2025-07-26 14:40:42 UTC \|\| Dirk \|\| '''ACHTUNG: Seite wird nicht mehr weiter gepflegt und zukünftig ersetzt!'''		\| [[NEUPLAST-Demoverbund\|NEUPLAST-Demoverbund]] \|\| [https://wiki.isms-ratgeber.info/wiki/NEUPLAST-Demoverbund Link] \|\| 7620 \|\| 2025-07-26 14:40:42 UTC \|\| Dirk \|\| '''ACHTUNG: Seite wird nicht mehr weiter gepflegt und zukünftig ersetzt!'''
	\|-		\|-
	\| [[NIS2\|NIS2]] \|\| [https://wiki.isms-ratgeber.info/wiki/NIS2 Link] \|\| ~~3296~~ \|\| ~~2024~~-08-~~22 17~~:45:28 UTC \|\| Dirk \|\| NIS2-Richtlinie (Network and Information Security Directive 2) der EU.		\| [[NIS2\|NIS2]] \|\| [https://wiki.isms-ratgeber.info/wiki/NIS2 Link] \|\| 3335 \|\| 2026-05-30 15:05:26 UTC \|\| Dirk \|\| NIS2-Richtlinie (Network and Information Security Directive 2) der EU.
			\|-
			\| [[NIS2 Überblick und Anforderungen\|NIS2 Überblick und Anforderungen]] \|\| [https://wiki.isms-ratgeber.info/wiki/NIS2_%C3%9Cberblick_und_Anforderungen Link] \|\| 30977 \|\| 2026-05-30 11:36:19 UTC \|\| Dirk \|\| NIS2-Richtlinie (Network and Information Security Directive 2) der EU.
	\|-		\|-
	\| [[Nebenwirkungen\|Nebenwirkungen]] \|\| [https://wiki.isms-ratgeber.info/wiki/Nebenwirkungen Link] \|\| 4533 \|\| 2024-08-03 05:59:56 UTC \|\| Dirk \|\| Zu Risiken und Nebewirkungen lesen sie die Packungsbeilage		\| [[Nebenwirkungen\|Nebenwirkungen]] \|\| [https://wiki.isms-ratgeber.info/wiki/Nebenwirkungen Link] \|\| 4533 \|\| 2024-08-03 05:59:56 UTC \|\| Dirk \|\| Zu Risiken und Nebewirkungen lesen sie die Packungsbeilage

NIS2

Dirk — Sat, 30 May 2026 15:05:26 GMT

← Nächstältere Version		Version vom 30. Mai 2026, 17:05 Uhr
Zeile 25:		Zeile 25:

	=== Weiterführende Quellen ===		=== Weiterführende Quellen ===
			[[NIS2 Überblick und Anforderungen]]

	[https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:02022L2555-20221227 RICHTLINIE (EU) 2022/2555 DES EUROPÄISCHEN PARLAMENTS UND DES RATES]		[https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:02022L2555-20221227 RICHTLINIE (EU) 2022/2555 DES EUROPÄISCHEN PARLAMENTS UND DES RATES]

	[https://www.bsi.bund.de/dok/nis-2 BSI: Umsetzung der <abbr>NIS-2-Richtlinie</abbr> für die regulierte Wirtschaft]		[https://www.bsi.bund.de/dok/nis-2 BSI: Umsetzung der <abbr>NIS-2-Richtlinie</abbr> für die regulierte Wirtschaft]
	[[Kategorie:Kurzartikel]]		[[Kategorie:Kurzartikel]]

NIS2 Überblick und Anforderungen

Dirk — Sat, 30 May 2026 11:36:19 GMT

← Nächstältere Version		Version vom 30. Mai 2026, 13:36 Uhr
Zeile 2:		Zeile 2:
	\|title=NIS2-Richtlinie (Network and Information Security Directive 2)		\|title=NIS2-Richtlinie (Network and Information Security Directive 2)
	\|description=Kurzartikel zur NIS2-Richtlinie (Network and Information Security Directive 2).		\|description=Kurzartikel zur NIS2-Richtlinie (Network and Information Security Directive 2).
	}}{{~~SHORTDEC~~:NIS2-Richtlinie (Network and Information Security Directive 2) der EU.}}		}}{{SHORTDESC:NIS2-Richtlinie (Network and Information Security Directive 2) der EU.}}
	Die NIS2-Richtlinie (Network and Information Systems Directive 2) ist eine Weiterentwicklung der ursprünglichen NIS-Richtlinie (Richtlinie (EU) 2016/1148) der Europäischen Union, die 2016 in Kraft trat. Sie zielt darauf ab, die Cybersicherheitsstandards und -praktiken in der EU weiter zu verbessern und auszuweiten, insbesondere in Bezug auf kritische Infrastrukturen und essenzielle Dienste.		''Die NIS2-Richtlinie (Network and Information Systems Directive 2) ist eine Weiterentwicklung der ursprünglichen NIS-Richtlinie (Richtlinie (EU) 2016/1148) der Europäischen Union, die 2016 in Kraft trat. Sie zielt darauf ab, die Cybersicherheitsstandards und -praktiken in der EU weiter zu verbessern und auszuweiten, insbesondere in Bezug auf kritische Infrastrukturen und essenzielle Dienste.''

	== Einordnung und Zielsetzung ==		== Einordnung und Zielsetzung ==

NIS2 Überblick und Anforderungen

Dirk — Sat, 30 May 2026 11:34:48 GMT

Die Seite wurde neu angelegt: „{{#seo: |title=NIS2-Richtlinie (Network and Information Security Directive 2) |description=Kurzartikel zur NIS2-Richtlinie (Network and Information Security Directive 2). }}{{SHORTDEC:NIS2-Richtlinie (Network and Information Security Directive 2) der EU.}} Die NIS2-Richtlinie (Network and Information Systems Directive 2) ist eine Weiterentwicklung der ursprünglichen NIS-Richtlinie (Richtlinie (EU) 2016/1148) der Europäischen Union, die 2016 in Kraft tr…“

Neue Seite

{{#seo:
|title=NIS2-Richtlinie (Network and Information Security Directive 2)
|description=Kurzartikel zur NIS2-Richtlinie (Network and Information Security Directive 2).
}}{{SHORTDEC:NIS2-Richtlinie (Network and Information Security Directive 2) der EU.}}
Die NIS2-Richtlinie (Network and Information Systems Directive 2) ist eine Weiterentwicklung der ursprünglichen NIS-Richtlinie (Richtlinie (EU) 2016/1148) der Europäischen Union, die 2016 in Kraft trat. Sie zielt darauf ab, die Cybersicherheitsstandards und -praktiken in der EU weiter zu verbessern und auszuweiten, insbesondere in Bezug auf kritische Infrastrukturen und essenzielle Dienste.

== Einordnung und Zielsetzung ==
Die NIS2-Richtlinie ist die „Richtlinie (EU) 2022/2555 über Maßnahmen für ein hohes gemeinsames Cybersicherheitsniveau in der Union“ und bildet seit 2022 den zentralen EU‑Rechtsrahmen für Netz- und Informationssicherheit in kritischen und wichtigen Sektoren. Sie ersetzt die ursprüngliche NIS‑Richtlinie von 2016 und hebt das gemeinsame Ambitionsniveau der EU im Bereich Cybersicherheit deutlich an.

Ziel von NIS2 ist es, ein einheitliches und hohes Schutzniveau für Netz- und Informationssysteme in 18 kritischen Sektoren in allen Mitgliedstaaten zu etablieren. Dazu verpflichtet die Richtlinie sowohl die Mitgliedstaaten als auch betroffene Unternehmen, ihre Cybersicherheitskapazitäten zu verbessern, systematische Risikomanagementmaßnahmen einzuführen und Sicherheitsvorfälle nach einheitlichen Grundsätzen zu melden. Sie stärkt zudem die grenzüberschreitende Zusammenarbeit und den Informationsaustausch, um Cyberangriffe wirksamer erkennen, bewerten und bewältigen zu können.

Für Organisationen, die bereits ein ISMS nach ISO 27001 oder BSI Grundschutz betreiben, ist NIS2 kein vollständig neues Thema, sondern eine regulatorische Verschärfung und Erweiterung bestehender Anforderungen. Viele NIS2‑Pflichten (Risikomanagement, technische und organisatorische Maßnahmen, Incident Management, Business Continuity, Schulungen) lassen sich durch ein systematisch implementiertes ISMS effizient erfüllen. Gleichzeitig führt NIS2 zusätzliche Anforderungen ein, etwa erweiterte Meldepflichten, strengere Governance‑ und Haftungsregeln für die Leitungsebene und einen deutlich erweiterten Anwendungsbereich.

Dieser Artikel verfolgt folgende Zwecke:

* Management, ISB, IT und Fachbereiche über Inhalt und Bedeutung von NIS2 zu informieren.
* Die Verbindung zwischen NIS2‑Pflichten und einem eigenen/vorhandenen ISMS transparent zu machen.
* Grundlagen für die interne NIS2‑Betroffenheitsanalyse und die Ableitung von Maßnahmen zu legen.

== Rechtlicher Rahmen ==
Kern des Rechtsrahmens ist die Richtlinie (EU) 2022/2555 („NIS2“), die am 16. Januar 2023 in Kraft getreten ist und von allen Mitgliedstaaten bis zum 17. Oktober 2024 in nationales Recht umzusetzen war. Die Richtlinie legt harmonisierte Mindestanforderungen an das Cybersicherheitsniveau in allen EU‑Staaten fest, einschließlich Risikomanagement, Incident‑Reporting, Aufsicht und Durchsetzung.

NIS2 definiert:

* einen erweiterten Anwendungsbereich mit 18 kritischen Sektoren (u. a. Energie, Verkehr, Finanzwesen, Gesundheit, digitale Infrastruktur, öffentliche Verwaltung, Post‑ und Kurierdienste, Abfallwirtschaft, Herstellung bestimmter Produkte, Lebensmittel, Forschung),
* Kategorien betroffener Einrichtungen („wesentliche“ und „wichtige“ Einrichtungen) mit unterschiedlichen Aufsichts- und Sanktionsregimen,
* konkrete Sicherheits- und Meldepflichten sowie erhöhte Anforderungen an Governance und Verantwortlichkeit der Leitungsebene.

Die NIS2‑Richtlinie unterscheidet auf EU‑Ebene zwischen '''wesentlichen''' und '''wichtigen''' Einrichtungen. Das deutsche NIS2‑Umsetzungsgesetz übernimmt diese Kategorien, ergänzt sie jedoch um die nationale Bezeichnung '''‚besonders wichtige Einrichtungen‘''' für bestimmte Einrichtungen mit besonders hoher Kritikalität.

Die Zuordnung erfolgt auf Basis von Sektor, Unternehmensgröße und kritischer Bedeutung. Die konkrete Einstufung ergibt sich aus den Regelungen des BSI‑Gesetzes und den dazugehörigen Rechtsverordnungen.

Wesentliche zeitliche Eckpunkte:

* 14.12.2022: Verabschiedung der NIS2‑Richtlinie auf EU‑Ebene.
* 16.01.2023: Inkrafttreten der Richtlinie.
* 17.10.2024: Frist zur Umsetzung in nationales Recht.
Die nationalen Pflichten gelten '''mit Inkrafttreten der jeweiligen Regelungen des NIS2‑Umsetzungsgesetzes'''. Für viele Einrichtungen bedeutet dies, dass '''ab 2025''' konkrete Melde‑, Sicherheits‑ und Nachweispflichten greifen. Maßgeblich sind die im BSI‑Gesetz festgelegten Übergangs‑ und Anwendungsfristen.

== Anwendungsbereich und Betroffenheit ==
NIS2 gilt für eine deutlich größere Zahl von Sektoren und Unternehmen als die ursprüngliche NIS‑Richtlinie. Sie unterscheidet zwischen „Sektoren hoher Kritikalität“ (z.B. Energie, Verkehr, Bankwesen und Finanzmarktinfrastruktur, Gesundheit, Trinkwasserversorgung und Abwasser, digitale Infrastruktur, IKT‑Dienstleistungsmanagement, öffentliche Verwaltung, Raumfahrt) und „sonstigen kritischen Sektoren“ (z.B. Post- und Kurierdienste, Abfallwirtschaft, Lebensmittel, Herstellung ausgewählter Produkte, digitale Anbieter, Forschung).

Die Richtlinie verwendet grundsätzlich eine größenbasierte Schwellenlogik: Betroffen sind in der Regel mittlere und große Unternehmen in den genannten Sektoren, d.h. Einrichtungen mit mindestens 50 Mitarbeitenden und einem Jahresumsatz bzw. einer Jahresbilanzsumme von mindestens 10 Mio. Euro. „Wesentliche Einrichtungen“ sind typischerweise große Unternehmen mit mindestens 250 Beschäftigten und über 50 Mio. Euro Jahresumsatz bzw. über 43 Mio. Euro Jahresbilanzsumme in Sektoren hoher Kritikalität, während „wichtige Einrichtungen“ mittlere Unternehmen in den relevanten Sektoren umfassen.

Gleichzeitig sehen NIS2 und seine nationale Umsetzung Ausnahmen von der reinen Größenlogik vor: Auch kleinere Unternehmen können einbezogen werden, wenn sie in einem besonders kritischen Bereich tätig sind oder eine besondere Bedeutung für die Gesellschaft oder Wirtschaft haben (z. B. Monopolstellungen, zentrale Knotenpunkte). Die konkrete Einstufung (z.B. durch Rechtsverordnungen oder Verwaltungsakte) erfolgt auf nationaler Ebene, in Deutschland u.a. durch Regelungen im BSI‑Gesetz und auf Basis von Unterstützungsangeboten wie dem offenen KRITIS‑Leitfaden.

Für Unternehmen ist eine strukturierte Betroffenheitsanalyse erforderlich. Typischerweise umfasst sie:

* Abgleich der eigenen Tätigkeiten mit den in NIS2 genannten Sektoren und Teilsektoren (inkl. Anhang I und II).
* Bewertung der Unternehmensgröße (Beschäftigtenzahl, Umsatz, Bilanzsumme) gegenüber den Schwellenwerten.
* Prüfung, ob eine besondere kritische Rolle (z.B. zentrale Dienstleistende, kritische Zulieferer, Betreiber zentraler Infrastruktur) eine Einstufung unabhängig von der Größe nahelegt.

Das Ergebnis dieser Analyse bestimmt, ob und in welcher Kategorie (wesentliche oder wichtige Einrichtung) das Unternehmen unter NIS2 fällt und welche Pflichten sich daraus ergeben. Diese Betroffenheitsanalyse sollte nachvollziehbar dokumentiert und regelmäßig überprüft werden, insbesondere bei Veränderungen von Geschäftsmodell, Größe oder Regulierung.

== Rollen, Verantwortlichkeiten, Governance ==
NIS2 stärkt die Verantwortung der Unternehmensleitung für Cybersicherheit und Informationssicherheit deutlich. Die Leitungsorgane (z.B. Geschäftsführung, Vorstand) müssen nach der Richtlinie die Umsetzung der Risikomanagementmaßnahmen überwachen, entsprechende Entscheidungen billigen und erhalten eine explizite Verantwortung für die Einhaltung der NIS2‑Pflichten. Sie sind zudem verpflichtet, regelmäßig an Schulungen zu Cybersicherheitsthemen teilzunehmen, um fundierte Entscheidungen treffen zu können.

Auf operativer Ebene werden typischerweise folgende Rollen benötigt:

* Informationssicherheitsbeauftragte bzw. CISO als zentrale verantwortliche Rolle für Aufbau, Betrieb und Weiterentwicklung des ISMS und die Umsetzung der NIS2‑Anforderungen.
* Verantwortliche für Risikomanagement, Compliance und Datenschutz, um die Verzahnung zwischen NIS2, DSGVO, anderen regulatorischen Pflichten und dem unternehmensweiten Risikomanagement sicherzustellen.
* IT‑Leitung und Fachverantwortliche für die Umsetzung technischer und organisatorischer Maßnahmen (z.B. Netzwerksicherheit, Identity & Access Management, Backup‑ und Recovery‑Konzepte).

Extern spielen insbesondere die nationalen zuständigen Behörden, in Deutschland vor allem das BSI, sowie die nationalen CSIRTs eine zentrale Rolle. Sie sind verantwortlich für Aufsicht, Meldeentgegennahme, Koordination im Incident‑Fall und teilweise Beratung der betroffenen Einrichtungen. NIS2 fördert zudem die Einrichtung nationaler und europäischer Kooperationsmechanismen, um Informationen über Bedrohungen, Schwachstellen und Vorfälle auszutauschen.

Für das ISMS bedeutet das:

* Die Rolle der Unternehmensleitung in der Informationssicherheit muss in Richtlinien, Organigrammen und Gremienstrukturen klar verankert sein (z.B. ISMS‑Lenkungskreis, regelmäßige Management‑Reviews).
* Rollen und Verantwortlichkeiten im Bereich NIS2 sollten eindeutig beschrieben, mit Vertretungsregelungen versehen und mit den bestehenden ISMS‑Rollen abgestimmt werden.
* Die Governance‑Struktur muss sicherstellen, dass Entscheidungen zu Risikobereitschaft, Sicherheitsmaßnahmen und Ressourcen transparent vorbereitet und auf Leitungsebene getroffen werden.

== Anforderungen an das Risikomanagement ==
NIS2 verpflichtet betroffene Einrichtungen, ein systematisches und dokumentiertes Risikomanagement für Netz- und Informationssicherheit zu etablieren. Dieses Risikomanagement muss sowohl technische als auch organisatorische Risiken abdecken und sich an der Bedeutung der angebotenen Dienste für Gesellschaft und Wirtschaft orientieren.

Typische Anforderungen sind:

* Durchführung regelmäßiger Risikoanalysen für IT‑Systeme, Netzwerke, Anwendungen und unterstützende Prozesse, unter Berücksichtigung aktueller Bedrohungen und Schwachstellen.
* Bewertung der potenziellen Auswirkungen von Sicherheitsvorfällen auf die Aufrechterhaltung der kritischen oder wichtigen Dienste, einschließlich Betriebsunterbrechungen, finanzieller Schäden und Auswirkungen auf Dritte.
* Ableitung und Umsetzung geeigneter technischer und organisatorischer Maßnahmen (z. B. Härtung, Zugangskontrollen, Netzwerksicherheitsmaßnahmen, Backup, Notfallmanagement) auf Basis der Risikobewertung.

Das Risikomanagement nach NIS2 ist eng mit Business Continuity Management und Notfallplanung verzahnt: Unternehmen müssen planen, wie sie bei Sicherheitsvorfällen ihre wesentlichen Dienste aufrechterhalten oder schnell wiederherstellen. Dazu gehören u. a. Notfallpläne, Wiederanlauf- und Wiederherstellungsstrategien sowie regelmäßige Tests (z.B. Übungen, Szenario‑basierte Tests).

Für ein bestehendes ISMS bedeutet dies:

* Die Risikomanagement‑Methodik (z.B. nach ISO 27005 oder BSI‑Standard 200‑3) sollte explizit auf NIS2‑relevante Aspekte ausgerichtet werden, etwa kritische Geschäftsprozesse, NIS2‑Sektoren und meldepflichtige Vorfallsszenarien.
* Risikoakzeptanzkriterien und Risikobehandlungskonzepte müssen mit den Zielen der NIS2‑Regulierung vereinbar sein, insbesondere hinsichtlich der Vermeidung von Systemausfällen wesentlicher Dienste und gravierenden Beeinträchtigungen.
* Die Ergebnisse der Risikoanalysen sollten systematisch dokumentiert werden und als Grundlage für Management‑Entscheidungen, Sicherheitskonzepte, Kontinuitätsplanung und die Priorisierung der Maßnahmen im NIS2‑Umsetzungsprojekt dienen.

== Informationssicherheits-Managementsystem (ISMS) ==
NIS2 verlangt nicht ausdrücklich die Zertifizierung nach ISO/IEC 27001 oder die Anwendung des BSI Grundschutzes, fordert aber ein systematisches Management von Cybersicherheitsrisiken, klare Governance, Meldeprozesse und angemessene technische und organisatorische Maßnahmen. Damit ist ein wirksam betriebenes ISMS der naheliegende organisatorische Rahmen, um NIS2‑Pflichten strukturiert, nachweisbar und dauerhaft zu erfüllen.

Für das ISMS bedeutet NIS2 vor allem, dass regulatorische Anforderungen als bindende Verpflichtungen erfasst, bewertet und in die bestehenden Steuerungsmechanismen übersetzt werden müssen. Dazu gehören insbesondere Geltungsbereich, Rollen und Verantwortlichkeiten, Risikoakzeptanz, Maßnahmensteuerung, Vorfallmanagement, Lieferantensteuerung, Business Continuity und Nachweisführung gegenüber Aufsichtsbehörden.

Ein NIS2‑fähiges ISMS sollte mindestens folgende Elemente abdecken:

* einen nachvollziehbar definierten Scope, der die von NIS2 erfassten Dienste, Prozesse, Standorte, Systeme und Dienstleistenden umfasst,
* ein dokumentiertes Governance‑Modell mit Einbindung der Leitungsebene, da Leitungsorgane die Risikomanagementmaßnahmen billigen und ihre Umsetzung überwachen müssen,
* ein belastbares Risiko- und Maßnahmenmanagement, das Cyberrisiken bewertet, priorisiert und in kontrollierte Umsetzungsmaßnahmen überführt,
* ein etabliertes Incident‑Management mit Meldewegen, Eskalationslogik und Fristensteuerung,
* ein Dokumentations- und Nachweissystem, das Entscheidungen, Bewertungen, Maßnahmenstatus, Tests, Vorfälle und Reviews prüffähig festhält.

Für Organisationen mit bestehendem ISMS ist NIS2 in der Praxis vor allem eine Frage des Mappings und der Nachschärfung. Bestehende Richtlinien, Prozesse und Kontrollen sollten daraufhin überprüft werden, ob sie die in NIS2 geforderten Inhalte vollständig abdecken, ob die Leitungsebene formal eingebunden ist und ob Melde- und Reaktionsprozesse die regulatorischen Fristen tatsächlich einhalten können.

== Sicherheitsmaßnahmen ==
Der Kern der materiellen NIS2‑Pflichten liegt in den Cybersicherheits-Risikomanagementmaßnahmen nach Artikel 21. Die Richtlinie verlangt, dass wesentliche und wichtige Einrichtungen „geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen“ treffen, um Risiken für Netz- und Informationssysteme zu beherrschen und die Auswirkungen von Sicherheitsvorfällen auf die Dienstleistungserbringung zu verhindern oder zu minimieren.

Diese Maßnahmen müssen risikobasiert sein und sich am Stand der Technik, an einschlägigen europäischen und internationalen Normen sowie an Größe, Exposition, Eintrittswahrscheinlichkeit und möglicher Schwere von Vorfällen orientieren. NIS2 fordert damit keinen starren Einheitskatalog, sondern einen begründeten, dokumentierten und angemessenen Maßnahmenmix.

Artikel 21 nennt Mindestthemen, die von betroffenen Einrichtungen abzudecken sind:

* '''Risikoanalyse und Sicherheit von Informationssystemen:''' Sicherheitsmaßnahmen müssen aus einer belastbaren Risikobewertung abgeleitet werden und die betroffenen Systeme, Prozesse und Dienste wirksam schützen.
* '''Bewältigung von Sicherheitsvorfällen:''' Es müssen Verfahren und Mittel vorhanden sein, um Vorfälle zu erkennen, zu analysieren, einzudämmen, zu beseitigen und strukturiert nachzubereiten.
* '''Aufrechterhaltung des Betriebs:''' NIS2 verlangt Vorkehrungen für Resilienz, Wiederanlauf und Krisenbewältigung incl. Backup‑Management und Wiederherstellung nach einem Notfall.
* '''Sicherheit der Lieferkette:''' Lieferantenrisiken sind ausdrücklich Teil des Pflichtenprogramms einschließlich sicherheitsbezogener Aspekte in den Beziehungen zwischen einer Einrichtung und ihren unmittelbaren Anbietenden oder Dienstleistenden.
* '''Sicherheit bei Erwerb, Entwicklung und Wartung von Netz- und Informationssystemen:''' Secure Development, Patch- und Vulnerability‑Management sind ausdrücklich adressiert einschließlich Schwachstellenmanagement und Offenlegung von Schwachstellen.
* '''Konzepte und Verfahren zur Bewertung der Wirksamkeit von Cybersicherheitsmaßnahmen:''' Kontrollen müssen nicht nur bestehen, sondern auch regelmäßig überprüft und bewertet werden.
* '''Grundlegende Cyberhygiene und Schulungen im Bereich Cybersicherheit:''' Sensibilisierung und Befähigung der Mitarbeitenden sind Mindestbestandteil der Compliance.
* '''Konzepte und Verfahren für Kryptografie und gegebenenfalls Verschlüsselung:''' Kryptografische Schutzmaßnahmen sind ausdrücklich genannt.
* '''Sicherheit des Personals, Konzepte für die Zugriffskontrolle und das Management von Anlagen:''' NIS2 adressiert sowohl personelle als auch organisatorische und technische Grundkontrollen.
* '''Verwendung von Multi-Faktor-Authentifizierung oder kontinuierlicher Authentifizierung:''' NIS2 verlangt gesicherter Sprach-, Video- und Textkommunikation sowie gesicherter Notfallkommunikationssysteme, soweit angemessen. Identitäts- und Kommunikationssicherheit wird ausdrücklich hervorgehoben.

Für das ISMS ist entscheidend, diese Themen nicht isoliert als Einzelliste zu behandeln, sondern in bestehende Domänen und Prozesse zu integrieren. Ein praktikabler Ansatz ist, NIS2‑Mindestmaßnahmen auf vorhandene Control‑Strukturen abzubilden, etwa auf ISO/IEC 27001:2022 Annex A oder auf Bausteine des BSI Grundschutzes, und daraus eine nachvollziehbare Compliance‑Matrix abzuleiten.

In der praktischen Umsetzung ist besonders relevant, dass NIS2 die Lieferkettensicherheit deutlich aufwertet. Organisationen sollten daher Sicherheitsanforderungen an Dienstleistende, Auslagerungen, Cloud‑Nutzung, externe Administration, Supportzugänge und Softwarelieferketten nachvollziehbar definieren, vertraglich verankern und regelmäßig bewerten.

Ebenfalls wichtig ist die Wirksamkeitsprüfung der Maßnahmen. Ein NIS2‑konformes Sicherheitsniveau lässt sich nicht allein durch Policies belegen, sondern durch operative Evidenz wie Schwachstellenmanagement, Patchzyklen, Protokollierung, Monitoring, Übungen, Wiederherstellungstests, Lieferantenbewertungen und Management‑Reviews.

== Meldepflichten und Incident Management ==
NIS2 verpflichtet wesentliche und wichtige Einrichtungen zur Meldung erheblicher Sicherheitsvorfälle an die zuständigen Behörden oder CSIRTs. Laut der EU‑Kommission betrifft dies Vorfälle, die erhebliche Betriebsstörungen oder erhebliche finanzielle Verluste verursachen können oder anderen natürlichen oder juristischen Personen erheblichen materiellen oder immateriellen Schaden zufügen können.

Die Richtlinie sieht ein mehrstufiges Melderegime vor. Nach Artikel 23 ist grundsätzlich vorgesehen:

* eine '''Frühwarnung innerhalb von 24 Stunden''' nach Kenntnis eines erheblichen Sicherheitsvorfalls, einschließlich der Angabe, ob ein Verdacht auf rechtswidrige oder böswillige Handlungen besteht und ob grenzüberschreitende Auswirkungen möglich sind,
* eine '''Meldung des Sicherheitsvorfalls innerhalb von 72 Stunden''' mit einer ersten Bewertung von Schwere, Auswirkungen und gegebenenfalls Kompromittierungsindikatoren,
* ein '''Abschlussbericht spätestens einen Monat nach der Meldung''', mit detaillierter Beschreibung des Vorfalls, seiner Ursache, der Auswirkungen und der ergriffenen bzw. laufenden Abhilfemaßnahmen.

Soweit der Vorfall andauert, kann an die Stelle des Abschlussberichts zunächst ein Zwischenbericht treten; der Abschlussbericht folgt dann innerhalb eines Monats nach Bewältigung des Vorfalls. Diese Fristen machen deutlich, dass Incident‑Management unter NIS2 nicht nur eine technische, sondern auch eine organisatorisch-regulatorische Disziplin ist.

Für das ISMS sollte Incident Management deshalb mindestens folgende Bausteine umfassen:

* eindeutige Kriterien zur Einstufung, wann ein Vorfall als erheblich im Sinne von NIS2 gilt,
* festgelegte Meldewege an interne Entscheidende, Rechts-/Compliance‑Funktionen und externe Behörden,
* eine Fristensteuerung mit 24‑Stunden‑, 72‑Stunden‑ und Monatsfrist,
* Vorlagen für Frühwarnung, Erstmeldung, Zwischenbericht und Abschlussbericht,
* dokumentierte Verfahren für Analyse, Eindämmung, Wiederherstellung, Beweissicherung und Lessons Learned.

NIS2 verlangt zudem, dass Einrichtungen ihre Nutzenden oder Empfänger ihrer Dienste informieren können, wenn ein erheblicher Cyberangriff wahrscheinlich nachteilige Auswirkungen für diese Personen oder Organisationen hat. Damit reicht Incident Management nicht bis zur technischen Wiederherstellung, sondern umfasst auch Krisenkommunikation, Stakeholder‑Management und gegebenenfalls die Abstimmung mit Datenschutz‑, Kommunikations- und Rechtsfunktionen.

Im deutschen Umsetzungskontext ist davon auszugehen, dass das BSI die zentrale Rolle bei Entgegennahme, Bewertung und weiteren Bearbeitung der Meldungen einnimmt und die Meldewege technisch sowie organisatorisch konkretisiert werden.

Als praktische Konsequenz sollte jede NIS2‑betroffene Organisation ihre Incident‑Response‑Prozesse mindestens durch Tabletop‑Übungen, Meldeübungen und Wiederherstellungstests validieren. Erst wenn Erkennung, Bewertung, Freigabe und externe Meldung unter Zeitdruck tatsächlich funktionieren, ist die regulatorische Anforderung belastbar umgesetzt.

== Überwachung, Aufsicht und Sanktionen ==
NIS2 unterscheidet bei der Aufsicht zwischen wesentlichen und wichtigen Einrichtungen. Für wesentliche Einrichtungen sieht die Richtlinie eine strengere, auch proaktive Aufsicht vor, während wichtige Einrichtungen überwiegend ex post beaufsichtigt werden, also insbesondere dann, wenn Hinweise auf Verstöße, Vorfälle oder andere Anhaltspunkte vorliegen.

Artikel 32 der Richtlinie gibt den zuständigen Behörden weitreichende Aufsichts- und Durchsetzungsbefugnisse gegenüber wesentlichen Einrichtungen. Dazu gehören unter anderem Vor-Ort-Kontrollen, gezielte Sicherheitsprüfungen, Anforderung von Informationen und Nachweisen, Zugang zu Daten, die Anweisung zur Abhilfe bei festgestellten Mängeln sowie die Möglichkeit, bestimmte Verstöße veröffentlichen zu lassen. Für wichtige Einrichtungen gelten vergleichbare, aber in der Regel anlassbezogene Durchsetzungsinstrumente.

Für das ISMS ist daraus unmittelbar abzuleiten, dass Nachweisfähigkeit ein zentrales Steuerungsziel sein muss. Es reicht nicht aus, Sicherheitsmaßnahmen informell oder nur technisch umzusetzen; erforderlich sind belastbare Nachweise über Governance, Risikoanalysen, Entscheidungen, Maßnahmenumsetzung, Testdurchführungen, Vorfallbearbeitung und Management‑Einbindung.

NIS2 verpflichtet die Mitgliedstaaten außerdem dazu, wirksame, verhältnismäßige und abschreckende Sanktionen vorzusehen. Nach Artikel 34 müssen bei Verstößen wesentlicher Einrichtungen gegen zentrale Pflichten, insbesondere aus Artikel 21 und 23, Geldbußen mit einem Höchstbetrag von mindestens 10 Mio. Euro oder mindestens 2 Prozent des weltweiten Jahresumsatzes vorgesehen werden, je nachdem, welcher Betrag höher ist. Für wichtige Einrichtungen liegt die Schwelle bei mindestens 7 Mio. Euro oder mindestens 1,4 Prozent des weltweiten Jahresumsatzes.

Über Geldbußen hinaus kann die Aufsicht weitere Maßnahmen anordnen, etwa Fristen zur Mängelbeseitigung, verbindliche Anweisungen oder andere Abhilfemaßnahmen. In der praktischen Governance-Perspektive ist besonders relevant, dass NIS2 die Verantwortung der Leitungsebene eng mit der Compliance verknüpft und damit den Druck auf eine dokumentierte und wirksame Sicherheitssteuerung deutlich erhöht.

== Schnittstellen zu anderen Regelwerken ==
NIS2 ist kein isoliertes Regelwerk, sondern steht in einem systematischen Verhältnis zu anderen unionsrechtlichen und nationalen Vorschriften. Besonders wichtig ist Artikel 4 der Richtlinie: Wenn sektorspezifische Unionsrechtsakte für bestimmte Einrichtungen gleichwertige Anforderungen an Cybersicherheitsmaßnahmen oder Vorfallmeldungen enthalten, gehen diese speziellen Regelungen den entsprechenden NIS2‑Vorschriften vor.

Dieses Vorrangprinzip betrifft vor allem stark regulierte Bereiche, in denen unionsrechtliche Sonderregime bereits detaillierte Cyber- oder Resilienzpflichten vorsehen. NIS2 bleibt jedoch für alle Einrichtungen und Anforderungen relevant, die nicht von solchen gleichwertigen sektoralen Regelungen erfasst werden.

Im Unternehmensalltag sind vor allem folgende Schnittstellen wesentlich:

* Datenschutzrecht, insbesondere DSGVO, wenn Sicherheitsvorfälle zugleich personenbezogene Daten betreffen; dann können parallel Meldepflichten aus NIS2 und der DSGVO bestehen.
* Nationale Cybersicherheits- und KRITIS-Regelungen, insbesondere das BSI‑Gesetz und weitere deutsche Umsetzungsnormen, die bestimmen, welche Einrichtungen konkret erfasst sind und wie Aufsicht und Sanktionen organisiert werden.
* Anerkannte Sicherheitsstandards wie ISO/IEC 27001 oder BSI IT‑Grundschutz, die zwar nicht automatisch NIS2‑Compliance bedeuten, aber ein geeignetes Organisations- und Kontrollgerüst für deren Umsetzung bereitstellen.

Praktisch empfiehlt sich dafür ein Regelwerks‑Mapping. Dabei werden NIS2‑Pflichten auf interne Richtlinien, ISMS‑Prozesse, Controls, Nachweise und gegebenenfalls andere externe Anforderungen wie DSGVO, DORA oder sektorale Spezialvorgaben abgebildet. Das erhöht Transparenz, reduziert Doppelarbeit und erleichtert sowohl interne Audits als auch externe Prüfungen.

== Praktische Umsetzung im Unternehmen ==
Die Umsetzung von NIS2 sollte nicht mit Einzelmaßnahmen beginnen, sondern mit einer strukturierten Betroffenheits- und Gap‑Analyse. Zunächst ist zu klären, ob und in welcher Kategorie die Organisation unter den Anwendungsbereich fällt; darauf aufbauend wird der Soll‑Zustand aus den regulatorischen Anforderungen abgeleitet und mit den bestehenden Strukturen, Prozessen und Kontrollen verglichen.

Ein praktikables Vorgehensmodell umfasst typischerweise fünf Phasen:

# '''Betroffenheitsanalyse''' und Scope‑Festlegung, einschließlich Sektorzurodnung, Größenkriterien, kritischer Dienstleistungen, Standorte, Systeme und Dienstleistender.
# '''Gap‑Analyse''' gegen NIS2‑Pflichten, insbesondere Governance, Risikomanagement, Sicherheitsmaßnahmen, Meldeprozesse, Lieferkettensicherheit und Nachweisführung.
# '''Priorisierung und Umsetzungsplanung''' auf Basis von Risiko, regulatorischer Relevanz, Umsetzungsaufwand und Abhängigkeiten.
# Umsetzung technischer, organisatorischer und prozessualer Maßnahmen einschließlich Richtlinien, Rollen, Kontrollmechanismen, Schulungen und Incident‑Playbooks.
# '''Validierung''' durch Übungen, Tests, interne Reviews und Management‑Bewertungen.

Ein besonders kritischer Erfolgsfaktor ist die frühzeitige Einbindung der Leitungsebene. Da NIS2 die Verantwortlichkeit von Leitungsorganen ausdrücklich betont, müssen Budget, Prioritäten, Risikoentscheidungen und Restrisikoakzeptanzen auf einer belastbaren Governance‑Grundlage getroffen und dokumentiert werden.

Ebenfalls zentral ist die Lieferkette. NIS2 verlangt nicht nur eine interne Sicherheitsorganisation, sondern auch die angemessene Steuerung unmittelbarer Anbietender und Dienstleistender, insbesondere dort, wo privilegierte Zugriffe, Cloud‑Abhängigkeiten, zentrale Plattformen oder Single‑Points‑of‑Failure bestehen. In der Praxis bedeutet das unter anderem Kritikalitätsklassifizierung, Mindestanforderungen in Verträgen, geeignete Sicherheitsnachweise, Re‑Assessments und Eskalationsmechanismen bei Schwachstellen oder Vorfällen.

Für viele Organisationen ist außerdem relevant, dass NIS2‑Umsetzung ohne Übung und Test nicht belastbar ist. Tabletop‑Übungen, Wiederherstellungstests, Lieferantenvorfallszenarien und Meldeübungen sind notwendig, um festzustellen, ob Rollen, Kommunikationswege und Entscheidungsprozesse im Ernstfall tatsächlich funktionieren.

== Dokumentation ==
Dokumentation ist nicht bloße einmalige Ablage von Dokumenten und Nachweisen, sondern ein zentrales fortlaufendes Steuerungs- und Nachweismedium. Da die Richtlinie auf nachweisbare Governance, dokumentierte Risikomanagementmaßnahmen und belastbare Incident‑ und Kontrollprozesse abstellt, sollte die Dokumentation die maßgeblichen Inhalte strukturiert, versioniert und reviewfähig abbilden.

Mindestens folgende Dokumentationsobjekte sind für NIS2 besonders relevant:

* Grundlagen- und Übersicht zu NIS2, Anwendungsbereich, Rollen und Pflichten.
* Richtlinien und Leitlinien, etwa Sicherheitsleitlinie, Incident‑Handling‑Policy, Lieferantenmanagement‑Vorgaben, BCM‑Rahmenvorgaben und Kryptografie‑Regeln.
* Prozessbeschreibungen für Risikoanalyse, Maßnahmenverfolgung, Vorfallmeldung, Eskalation, externe Kommunikation, Wiederherstellung und Lessons Learned.
* Rollenbeschreibungen und Gremienstrukturen, insbesondere zur Einbindung der Leitungsebene.
* Nachweisdokumente wie Risikoübersichten, Maßnahmenpläne, Audit‑Ergebnisse, Testprotokolle, Übungsberichte, Lieferantenbewertungen und Management‑Reviews.

Wichtig ist dabei eine klare Verknüpfung zwischen Grundlagendokumentation, normativen Vorgaben und operativen Nachweisen. Eine NIS2‑Dokumentation sollte deshalb nicht isoliert stehen, sondern auf verwandte Dokumentionen verweisen, etwa zu Asset‑Management, Risikomanagement, Business Continuity, Incident Management, Lieferantenmanagement, Berechtigungsmanagement und Awareness.

Sinnvoll ist außerdem ein definierter Pflegeprozess. Für NIS2‑relevante Inhalte sollten Verantwortliche, Review‑Intervalle, Freigaberegeln, Versionierung und Änderungsanlässe festgelegt sein, damit regulatorische Änderungen, neue Behördenvorgaben oder interne Organisationsänderungen zeitnah in der Dokumentation nachvollzogen werden können.

== Checklisten, Vorlagen, weiterführende Quellen ==
Für die praktische Anwendbarkeit sollten Arbeitsmittel zur Verfügung gestellt werden.

Geeignete interne Arbeitshilfen sind insbesondere:

* eine Checkliste zur Betroffenheitsanalyse mit Sektor, Größenkriterien, Dienstleistungen, Standorten, Systemen und kritischen Dienstleistenden,
* eine NIS2‑Gap‑Analyse‑Vorlage entlang der Themen Governance, Risikomanagement, Sicherheitsmaßnahmen, Meldepflichten, Lieferkette, BCM und Nachweisführung,
* Vorlagen für Incident‑Erstbewertung, 24‑Stunden‑Frühwarnung, 72‑Stunden‑Meldung, Zwischenbericht und Abschlussbericht,
* Bewertungsbögen für Dienstleistende und Auslagerungen mit NIS2‑relevanten Sicherheitsanforderungen,
* Vorlagen für Management‑Berichte, Umsetzungsroadmaps, Maßnahmenregister und Review‑Protokolle.

== Weiterführende Quellen ==
[https://eur-lex.europa.eu/legal-content/DE/TXT/HTML/?uri=CELEX:02022L2555-20221227 RICHTLINIE (EU) 2022/2555 DES EUROPÄISCHEN PARLAMENTS UND DES RATES]

[https://www.bsi.bund.de/dok/nis-2 BSI: Umsetzung der <abbr>NIS-2-Richtlinie</abbr> für die regulierte Wirtschaft]
[[Kategorie:Kurzartikel]]

Inhalt-Übersicht

Dirk — Sat, 30 May 2026 04:00:06 GMT

Automatisch erzeugte Inhaltsübersicht aktualisiert

← Nächstältere Version		Version vom 30. Mai 2026, 06:00 Uhr
Zeile 3:		Zeile 3:
	{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}		{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}
	;Stand		;Stand
	:2026-05-29 04:00 (UTC)		:2026-05-30 04:00 (UTC)

	;Anzahl Seiten gesamt		;Anzahl Seiten gesamt
Zeile 164:		Zeile 164:
	\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.		\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.
	\|-		\|-
	\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| 47363 \|\| 2026-05-28 04:00:05 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.		\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| 47363 \|\| 2026-05-29 04:00:04 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.
	\|-		\|-
	\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.		\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.

Benutzer:Al2990

Dirk — Fri, 29 May 2026 08:52:43 GMT

Benutzerkonto Al2990 wurde von Dirk erstellt und das Passwort wurde per E-Mail zugesandt

Inhalt-Übersicht

Dirk — Fri, 29 May 2026 04:00:04 GMT

Automatisch erzeugte Inhaltsübersicht aktualisiert

← Nächstältere Version		Version vom 29. Mai 2026, 06:00 Uhr
(16 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 3:		Zeile 3:
	{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}		{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}
	;Stand		;Stand
	:2026-05-12 04:00 (UTC)		:2026-05-29 04:00 (UTC)

	;Anzahl Seiten gesamt		;Anzahl Seiten gesamt
Zeile 16:		Zeile 16:
	! Seite !! Web URL !! Länge !! Letzte Änderung !! Letzter Autor !! Kurzbeschreibung		! Seite !! Web URL !! Länge !! Letzte Änderung !! Letzter Autor !! Kurzbeschreibung
	\|-		\|-
	\| [[2FA best practice\|2FA best practice]] \|\| [https://wiki.isms-ratgeber.info/wiki/2FA_best_practice Link] \|\| ~~4909~~ \|\| ~~2024~~-10-~~02 18~~:05:46 UTC \|\| Dirk \|\| Best ~~practice einer~~ Zwei-Faktor-Authentifizierung (2FA)		\| [[2FA best practice\|2FA best practice]] \|\| [https://wiki.isms-ratgeber.info/wiki/2FA_best_practice Link] \|\| 4308 \|\| 2026-05-12 14:19:37 UTC \|\| Dirk \|\| Best Practices für Zwei-Faktor-Authentifizierung (2FA)
	\|-		\|-
	\| [[APT\|APT]] \|\| [https://wiki.isms-ratgeber.info/wiki/APT Link] \|\| 5749 \|\| 2024-08-23 14:45:43 UTC \|\| Dirk \|\| Advanced Persistent Threat (APT)		\| [[APT\|APT]] \|\| [https://wiki.isms-ratgeber.info/wiki/APT Link] \|\| 5749 \|\| 2024-08-23 14:45:43 UTC \|\| Dirk \|\| Advanced Persistent Threat (APT)
	\|-		\|-
	\| [[Authentisierung\|Authentisierung]] \|\| [https://wiki.isms-ratgeber.info/wiki/Authentisierung Link] \|\| ~~17762~~ \|\| ~~2024~~-10-~~13 16~~:43:32 UTC \|\| Dirk \|\| Grundlagenartikel zu Methoden der Authentisierung.		\| [[Authentisierung\|Authentisierung]] \|\| [https://wiki.isms-ratgeber.info/wiki/Authentisierung Link] \|\| 19121 \|\| 2026-05-12 14:18:52 UTC \|\| Dirk \|\| Grundlagenartikel zu Methoden der Authentisierung.
	\|-		\|-
	\| [[Automatisierung\|Automatisierung]] \|\| [https://wiki.isms-ratgeber.info/wiki/Automatisierung Link] \|\| 8195 \|\| 2025-02-19 15:41:39 UTC \|\| Dirk \|\| Automatisierung in der IT-Sicherheit.		\| [[Automatisierung\|Automatisierung]] \|\| [https://wiki.isms-ratgeber.info/wiki/Automatisierung Link] \|\| 8195 \|\| 2025-02-19 15:41:39 UTC \|\| Dirk \|\| Automatisierung in der IT-Sicherheit.
Zeile 164:		Zeile 164:
	\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.		\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.
	\|-		\|-
	\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| ~~47351~~ \|\| 2026-05-11 04:00:05 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.		\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| 47363 \|\| 2026-05-28 04:00:05 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.
	\|-		\|-
	\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.		\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.

2FA best practice

Dirk — Tue, 12 May 2026 14:19:37 GMT

Änderungen zeigen

Authentisierung

Dirk — Tue, 12 May 2026 14:18:52 GMT

← Nächstältere Version		Version vom 12. Mai 2026, 16:18 Uhr
Zeile 1:		Zeile 1:
	{{#seo:		{{#seo:
	\|title= ~~Grundlagenartikel zur~~ Authentisierung		\|title=Authentisierung – Grundlagen und Methoden
	\|keywords= ISMS,Authentisierung,~~Grundlagen~~,~~Artikel~~		\|keywords=ISMS,Authentisierung,Authentifizierung,Autorisierung,Passwort,Token,Zertifikate,Biometrie
	\|description=Die Begriffe Authentisierung, Authentifizierung und Autorisierung werden ~~oft verwechselt oder synonym verwendet. Dieser Artikel~~ erläutert ~~die Unterscheide~~ und ~~die verschiedenen Möglichkeiten einer Authentisierung~~.		\|description=Die Begriffe Authentisierung, Authentifizierung und Autorisierung werden erläutert sowie verschiedene Authentisierungsmethoden wie Passwörter, Zertifikate, Token und biometrische Verfahren im ISMS-Kontext dargestellt.
	}}{{SHORTDESC:Grundlagenartikel zu Methoden der Authentisierung.}}		}}{{SHORTDESC:Grundlagenartikel zu Methoden der Authentisierung.}}
	[[Datei:Fingerprint 640.png\|alternativtext=Fingerprint\|rechts\|150x150px\|Bild von DreamDigitalArtist auf Pixabay]]		[[Datei:Fingerprint 640.png\|alternativtext=Fingerprint\|rechts\|150x150px\|Bild von DreamDigitalArtist auf Pixabay]]''Der Artikel behandelt verschiedene Authentisierungsmethoden, darunter Passwörter, Zertifikate, Token und biometrische Verfahren, und betont die Notwendigkeit sicherer Praktiken zur Verbesserung der IT-Sicherheit.''
	Der Artikel behandelt verschiedene Authentisierungsmethoden, darunter Passwörter, Zertifikate, Token und biometrische Verfahren, und betont die Notwendigkeit sicherer Praktiken zur Verbesserung der IT-Sicherheit.

	== Einleitung ==		== Einleitung ==
Zeile 35:		Zeile 34:
	\|}		\|}

	==Authentisierungsmethoden ==		== Authentisierungsmethoden ==

	=== Passworte ===		=== Passworte ===
Zeile 180:		Zeile 179:
	* '''Handgeometrie''': Verwendet die Form der Hand einer Person, um die Identität zu bestätigen.		* '''Handgeometrie''': Verwendet die Form der Hand einer Person, um die Identität zu bestätigen.
	* '''Signaturerkennung''': Verwendet die Art und Weise, wie eine Person unterschreibt, um die Identität zu bestätigen.		* '''Signaturerkennung''': Verwendet die Art und Weise, wie eine Person unterschreibt, um die Identität zu bestätigen.
	* '''Vein Recognition''': Verwendet das Muster von Blutgefäßen in der Hand ~~einer Person~~, um die Identität zu bestätigen.		* '''Vein Recognition''': Verwendet das Muster von Blutgefäßen (z.B. in der Hand oder im Finger), um die Identität zu bestätigen.
	* '''Behavioral Biometrics''': Verwendet die Art und Weise, wie eine Person ein Gerät verwendet, um die Identität zu bestätigen.		* '''Behavioral Biometrics''': Verwendet die Art und Weise, wie eine Person ein Gerät verwendet, um die Identität zu bestätigen.

	~~Es gibt auch Kombinationen~~ von ~~Biometrie, wie~~ z.B. ~~die~~ Kombination ~~von Fingerabdruck~~ und ~~Gesichtserkennung~~, ~~die sich gegenseitig ergänzen~~ und ~~die Sicherheit erhöhen können~~.		Biometrische Verfahren gelten als komfortabel, müssen aber wegen der Sensibilität der Merkmale (Datenschutz, fehlende „Zurücksetzung“ bei Kompromittierung) besonders sorgfältig bewertet werden. In vielen ISMS-Kontexten werden sie daher eher als ergänzender Faktor und weniger als alleinige Authentisierungsmethode betrachtet.

			== Empfohlene Policy im Unternehmen ==

			Für die praktische Umsetzung in einem ISMS empfiehlt es sich, aus den beschriebenen Verfahren klare Vorgaben abzuleiten, z.B.:

			* Für '''normale Benutzerkonten''' (normaler Schutzbedarf): Passwörter mit sinnvollen Mindestanforderungen (Länge, begrenzte Komplexität), keine erzwungene häufige Änderung ohne Anlass, dafür ergänzende technische Schutzmaßnahmen (Throttling, Sperrungen, Monitoring).
			* Für '''Konten mit erhöhtem Schutzbedarf''' (z.B. Administratoren, besonders schützenswerte Anwendungen): Verpflichtender Einsatz von Mehr-Faktor-Authentisierung (z.B. Passwort + Token oder Zertifikat).
			* Für '''Fernzugriffe''' (z.B. VPN, Remote-Access): Grundsätzlich Mehr-Faktor-Authentisierung mit mindestens einem Besitzfaktor.
			* '''Biometrische Verfahren''' nur nach sorgfältiger Risiko- und Datenschutzbewertung einsetzen und möglichst in Kombination mit weiteren Faktoren nutzen.
			* Zuständigkeiten und Prozesse für Vergabe, Änderung, Sperrung und Entzug von Authentisierungsmitteln in Richtlinien festlegen (z.B. in einer Zugriffs- bzw. Berechtigungsrichtlinie).

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

Inhalt-Übersicht

Dirk — Tue, 12 May 2026 04:00:04 GMT

Automatisch erzeugte Inhaltsübersicht aktualisiert

← Nächstältere Version		Version vom 12. Mai 2026, 06:00 Uhr
Zeile 3:		Zeile 3:
	{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}		{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}
	;Stand		;Stand
	:2026-05-11 04:00 (UTC)		:2026-05-12 04:00 (UTC)

	;Anzahl Seiten gesamt		;Anzahl Seiten gesamt
Zeile 140:		Zeile 140:
	\| [[ISMS-Ratgeber-WiKi\|ISMS-Ratgeber-WiKi]] \|\| [https://wiki.isms-ratgeber.info/wiki/ISMS-Ratgeber-WiKi Link] \|\| 3310 \|\| 2024-10-25 17:19:58 UTC \|\| Dirk \|\| ISMS-Ratgeber - In eigener Sache		\| [[ISMS-Ratgeber-WiKi\|ISMS-Ratgeber-WiKi]] \|\| [https://wiki.isms-ratgeber.info/wiki/ISMS-Ratgeber-WiKi Link] \|\| 3310 \|\| 2024-10-25 17:19:58 UTC \|\| Dirk \|\| ISMS-Ratgeber - In eigener Sache
	\|-		\|-
	\| [[ISMS-Tools\|ISMS-Tools]] \|\| [https://wiki.isms-ratgeber.info/wiki/ISMS-Tools Link] \|\| ~~23025~~ \|\| 2026-04-~~28 08~~:16:04 UTC \|\| ~~NicoDD~~ \|\| Verschiedene ISMS-Tools im Vergleich.		\| [[ISMS-Tools\|ISMS-Tools]] \|\| [https://wiki.isms-ratgeber.info/wiki/ISMS-Tools Link] \|\| 23624 \|\| 2026-05-11 07:23:02 UTC \|\| Evergreen Media MP \|\| Verschiedene ISMS-Tools im Vergleich.
	\|-		\|-
	\| [[ISO 27001\|ISO 27001]] \|\| [https://wiki.isms-ratgeber.info/wiki/ISO_27001 Link] \|\| 6060 \|\| 2026-03-04 20:08:12 UTC \|\| Dirk \|\| ISO 27001: Grundlagen, Geschichte & Aktuelle Trends		\| [[ISO 27001\|ISO 27001]] \|\| [https://wiki.isms-ratgeber.info/wiki/ISO_27001 Link] \|\| 6060 \|\| 2026-03-04 20:08:12 UTC \|\| Dirk \|\| ISO 27001: Grundlagen, Geschichte & Aktuelle Trends
Zeile 164:		Zeile 164:
	\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.		\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.
	\|-		\|-
	\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| 47351 \|\| 2026-05-10 04:00:05 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.		\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| 47351 \|\| 2026-05-11 04:00:05 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.
	\|-		\|-
	\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.		\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.
Zeile 395:		Zeile 395:
	\| [[Grundschutz:LF-Überwachung\|LF-Überwachung]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:LF-%C3%9Cberwachung Link] \|\| 442 \|\| 2026-04-30 19:24:49 UTC \|\| Dirk \|\| Leitfaden zu Grundschutz++ Grundschutzchecks		\| [[Grundschutz:LF-Überwachung\|LF-Überwachung]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:LF-%C3%9Cberwachung Link] \|\| 442 \|\| 2026-04-30 19:24:49 UTC \|\| Dirk \|\| Leitfaden zu Grundschutz++ Grundschutzchecks
	\|-		\|-
	\| [[Grundschutz:Migration\|Migration]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:Migration Link] \|\| ~~31457~~ \|\| 2026-05-~~06 19~~:11:47 UTC \|\| Dirk \|\| Migration von IT-Grundschutz zu Grundschutz++ – Herausforderungen und Praxistipps		\| [[Grundschutz:Migration\|Migration]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:Migration Link] \|\| 34260 \|\| 2026-05-11 12:59:47 UTC \|\| Dirk \|\| Migration von IT-Grundschutz zu Grundschutz++ – Herausforderungen und Praxistipps
	\|-		\|-
	\| [[Grundschutz:QS-Checkliste\|QS-Checkliste]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:QS-Checkliste Link] \|\| 4913 \|\| 2026-05-01 01:34:40 UTC \|\| Dirk \|\| Checkliste zur Qualitätssicherung von Praktiken und Anforderungen im BSI Grundschutz++		\| [[Grundschutz:QS-Checkliste\|QS-Checkliste]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:QS-Checkliste Link] \|\| 4913 \|\| 2026-05-01 01:34:40 UTC \|\| Dirk \|\| Checkliste zur Qualitätssicherung von Praktiken und Anforderungen im BSI Grundschutz++

Grundschutz:Migration

Dirk — Mon, 11 May 2026 12:59:47 GMT

Schritt 2: Anforderungsanalyse (PLAN - Strukturmodellierung)

Änderungen zeigen

ISMS-Tools

Evergreen Media MP — Mon, 11 May 2026 07:23:02 GMT

otris isms wurde als Tool hinzugefügt, da es gefehlt hat

← Nächstältere Version		Version vom 11. Mai 2026, 09:23 Uhr
Zeile 74:		Zeile 74:

	[https://shop.reguvis.de/online-ausgabe/it-grundschutz-cockpit/ Mehr Informationen zum IT-Grundschutz-Cockpit]		[https://shop.reguvis.de/online-ausgabe/it-grundschutz-cockpit/ Mehr Informationen zum IT-Grundschutz-Cockpit]

			=== otris isms ===
			otris isms ist die modulare ISMS-Fachlösung der otris compliance SUITE. Sie unterstützt revisionssicheres Informationssicherheitsmanagement nach ISO/IEC 27001, BSI IT-Grundschutz, NIS-2 und weiteren Richtlinien. Die Lösung umfasst Risiko-, Asset-, Vorfall-, Maßnahmen- und Auditmanagement, Dokumentenlenkung und Reporting. otris isms ist als SaaS oder On-Premises verfügbar, gezielte KI-Integration ist möglich. Die Software eignet sich für Unternehmen vom Mittelstand bis zum DAX-Konzern.

			[https://www.otris.de/produkte/isms-software/ Mehr Informationen zu otris isms]

	==== QSEC ====		==== QSEC ====

Inhalt-Übersicht

Dirk — Mon, 11 May 2026 04:00:05 GMT

Automatisch erzeugte Inhaltsübersicht aktualisiert

← Nächstältere Version		Version vom 11. Mai 2026, 06:00 Uhr
Zeile 3:		Zeile 3:
	{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}		{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}
	;Stand		;Stand
	:2026-05-10 04:00 (UTC)		:2026-05-11 04:00 (UTC)

	;Anzahl Seiten gesamt		;Anzahl Seiten gesamt
Zeile 164:		Zeile 164:
	\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.		\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.
	\|-		\|-
	\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| ~~47202~~ \|\| 2026-05-09 04:00:05 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.		\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| 47351 \|\| 2026-05-10 04:00:05 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.
	\|-		\|-
	\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.		\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.

← Nächstältere Version		Version vom 7. Juni 2026, 12:51 Uhr
Zeile 50:		Zeile 50:
	*[[Managementbericht\|Erstellen eines Managementberichts]]		*[[Managementbericht\|Erstellen eines Managementberichts]]
	*[[Reifegradmodell\|Erstellen eines Reifegradmodells]]		*[[Reifegradmodell\|Erstellen eines Reifegradmodells]]
			*[[Grundschutz:Überwachung und Audits\|Überwachung, interne Audits & kontinuierliche Bewertung]]⚠️
	*[[Dokumentenmanagement\|Einführung in das Dokumentenmanagement]]		*[[Dokumentenmanagement\|Einführung in das Dokumentenmanagement]]
	*[[Risikomanagement\|Einführung in das Risikomanagement]]		*[[Risikomanagement\|Einführung in das Risikomanagement]]

← Nächstältere Version		Version vom 5. Juni 2026, 10:19 Uhr
Zeile 73:		Zeile 73:
	*[[KI:EU AI Act\|EU AI Act: ISMS-Integration, Risiken & Umsetzung]]		*[[KI:EU AI Act\|EU AI Act: ISMS-Integration, Risiken & Umsetzung]]
	*[[KI-Nutzung\|Chancen und Risiken von KI]]		*[[KI-Nutzung\|Chancen und Risiken von KI]]
			*[[NIS2_Überblick_und_Anforderungen\|NIS2: Überblick & Anforderungen im ISMS-Kontext]]
	*[[Industrielle IT\|Grundlagen & Sicherheitsaspekte Industrieller IT]]		*[[Industrielle IT\|Grundlagen & Sicherheitsaspekte Industrieller IT]]
	*[[Bücher und Links\|Informative Bücher und Links]]		*[[Bücher und Links\|Informative Bücher und Links]]

← Nächstältere Version		Version vom 7. Juni 2026, 06:00 Uhr
Zeile 3:		Zeile 3:
	{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}		{{SHORTDESC:Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.}}
	;Stand		;Stand
	:2026-06-06 04:00 (UTC)		:2026-06-07 04:00 (UTC)

	;Anzahl Seiten gesamt		;Anzahl Seiten gesamt
Zeile 164:		Zeile 164:
	\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.		\| [[Inhalt\|Inhalt]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt Link] \|\| 1113 \|\| 2024-12-01 20:40:32 UTC \|\| Dirk \|\| Inhalt des Wiki sortiert nach Kategorien.
	\|-		\|-
	\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| 47633 \|\| 2026-06-05 04:00:06 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.		\| [[Inhalt-Übersicht\|Inhalt-Übersicht]] \|\| [https://wiki.isms-ratgeber.info/wiki/Inhalt-%C3%9Cbersicht Link] \|\| 47633 \|\| 2026-06-06 04:00:05 UTC \|\| Dirk \|\| Diese Seite wird täglich automatisch per API-Skript erzeugt und listet alle Inhaltsseiten des Wiki nach Namensräumen auf.
	\|-		\|-
	\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.		\| [[KMU Startseite\|KMU Startseite]] \|\| [https://wiki.isms-ratgeber.info/wiki/KMU_Startseite Link] \|\| 3570 \|\| 2025-03-05 08:23:14 UTC \|\| Dirk \|\| ISMS-Ratgeber Wiki Startseite für KMU,Handwerk und Freiberufler.
Zeile 338:		Zeile 338:
	\| [[Social Media\|Social Media]] \|\| [https://wiki.isms-ratgeber.info/wiki/Social_Media Link] \|\| 6589 \|\| 2025-03-05 07:58:15 UTC \|\| Dirk \|\| Informationssicherheit beim Einsatz von Social Media im Unternehmen.		\| [[Social Media\|Social Media]] \|\| [https://wiki.isms-ratgeber.info/wiki/Social_Media Link] \|\| 6589 \|\| 2025-03-05 07:58:15 UTC \|\| Dirk \|\| Informationssicherheit beim Einsatz von Social Media im Unternehmen.
	\|-		\|-
	\| [[State Level Actor\|State Level Actor]] \|\| [https://wiki.isms-ratgeber.info/wiki/State_Level_Actor Link] \|\| ~~6230~~ \|\| 2026-05-06 15:37:59 UTC \|\| Dirk \|\| State‑Level Actors in der Informationssicherheit: Definition, Ziele und Risiken		\| [[State Level Actor\|State Level Actor]] \|\| [https://wiki.isms-ratgeber.info/wiki/State_Level_Actor Link] \|\| 6225 \|\| 2026-06-06 08:44:54 UTC \|\| Dirk \|\| State‑Level Actors in der Informationssicherheit: Definition, Ziele und Risiken
	\|-		\|-
	\| [[Strukturanalyse\|Strukturanalyse]] \|\| [https://wiki.isms-ratgeber.info/wiki/Strukturanalyse Link] \|\| 18310 \|\| 2024-08-22 17:29:00 UTC \|\| Dirk \|\| Mustervorlage einer IT-Strukturanalyse		\| [[Strukturanalyse\|Strukturanalyse]] \|\| [https://wiki.isms-ratgeber.info/wiki/Strukturanalyse Link] \|\| 18310 \|\| 2024-08-22 17:29:00 UTC \|\| Dirk \|\| Mustervorlage einer IT-Strukturanalyse
Zeile 383:		Zeile 383:
	! Seite !! Web URL !! Länge !! Letzte Änderung !! Letzter Autor !! Kurzbeschreibung		! Seite !! Web URL !! Länge !! Letzte Änderung !! Letzter Autor !! Kurzbeschreibung
	\|-		\|-
	\| [[Grundschutz:Begriffsdefinition\|Begriffsdefinition]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:Begriffsdefinition Link] \|\| ~~15663~~ \|\| 2026-05-~~01 01~~:28:06 UTC \|\| Dirk \|\| Definition für typische Begriffe aus dem Grundschutz++.		\| [[Grundschutz:Begriffsdefinition\|Begriffsdefinition]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:Begriffsdefinition Link] \|\| 15672 \|\| 2026-06-06 10:18:46 UTC \|\| Dirk \|\| Definition für typische Begriffe aus dem Grundschutz++.
	\|-		\|-
	\| [[Grundschutz:Einführung und Aufbau\|Einführung und Aufbau]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:Einf%C3%BChrung_und_Aufbau Link] \|\| ~~44348~~ \|\| 2026-05-06 18:52:08 UTC \|\| Dirk \|\| Überblick zum aktuellen Stand im Grundschutz++		\| [[Grundschutz:Einführung und Aufbau\|Einführung und Aufbau]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:Einf%C3%BChrung_und_Aufbau Link] \|\| 44790 \|\| 2026-06-06 08:43:28 UTC \|\| Dirk \|\| Überblick zum aktuellen Stand im Grundschutz++
	\|-		\|-
	\| [[Grundschutz:Gestaltungsentscheidungen\|Gestaltungsentscheidungen]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:Gestaltungsentscheidungen Link] \|\| 9390 \|\| 2026-05-01 01:25:09 UTC \|\| Dirk \|\| Gestaltungsentscheidungen und Parameter im Grundschutz++ verständlich erklärt		\| [[Grundschutz:Gestaltungsentscheidungen\|Gestaltungsentscheidungen]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:Gestaltungsentscheidungen Link] \|\| 9390 \|\| 2026-05-01 01:25:09 UTC \|\| Dirk \|\| Gestaltungsentscheidungen und Parameter im Grundschutz++ verständlich erklärt
Zeile 397:		Zeile 397:
	\| [[Grundschutz:LF-Überwachung\|LF-Überwachung]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:LF-%C3%9Cberwachung Link] \|\| 442 \|\| 2026-04-30 19:24:49 UTC \|\| Dirk \|\| Leitfaden zu Grundschutz++ Grundschutzchecks		\| [[Grundschutz:LF-Überwachung\|LF-Überwachung]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:LF-%C3%9Cberwachung Link] \|\| 442 \|\| 2026-04-30 19:24:49 UTC \|\| Dirk \|\| Leitfaden zu Grundschutz++ Grundschutzchecks
	\|-		\|-
	\| [[Grundschutz:Migration\|Migration]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:Migration Link] \|\| ~~34260~~ \|\| 2026-05-~~11 12~~:59:47 UTC \|\| Dirk \|\| Migration von IT-Grundschutz zu Grundschutz++ – Herausforderungen und Praxistipps		\| [[Grundschutz:Migration\|Migration]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:Migration Link] \|\| 34373 \|\| 2026-06-06 09:21:00 UTC \|\| Dirk \|\| Migration von IT-Grundschutz zu Grundschutz++ – Herausforderungen und Praxistipps
	\|-		\|-
	\| [[Grundschutz:QS-Checkliste\|QS-Checkliste]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:QS-Checkliste Link] \|\| 4913 \|\| 2026-05-01 01:34:40 UTC \|\| Dirk \|\| Checkliste zur Qualitätssicherung von Praktiken und Anforderungen im BSI Grundschutz++		\| [[Grundschutz:QS-Checkliste\|QS-Checkliste]] \|\| [https://wiki.isms-ratgeber.info/wiki/Grundschutz:QS-Checkliste Link] \|\| 4913 \|\| 2026-05-01 01:34:40 UTC \|\| Dirk \|\| Checkliste zur Qualitätssicherung von Praktiken und Anforderungen im BSI Grundschutz++

← Nächstältere Version		Version vom 6. Juni 2026, 11:21 Uhr
Zeile 12:		Zeile 12:
	* Grundschutz++ stellt ab 2026 radikal auf ein modulares, prozessorientiertes System mit OSCAL/JSON-Struktur um. Die Anforderungshierarchie wird granularer (Praktiken, Zielobjektkategorien, Teilanforderungen), Redundanzen werden eliminiert, die Pflege dynamisch, Leistungskennzahlen und Prioritäten werden eingeführt. Die Methodik bleibt grundsätzlich erhalten, die Umsetzung jedoch wird teils automatisierbar, verlangt aber tiefgreifend neue Toollandschaften und Umdenkprozesse.		* Grundschutz++ stellt ab 2026 radikal auf ein modulares, prozessorientiertes System mit OSCAL/JSON-Struktur um. Die Anforderungshierarchie wird granularer (Praktiken, Zielobjektkategorien, Teilanforderungen), Redundanzen werden eliminiert, die Pflege dynamisch, Leistungskennzahlen und Prioritäten werden eingeführt. Die Methodik bleibt grundsätzlich erhalten, die Umsetzung jedoch wird teils automatisierbar, verlangt aber tiefgreifend neue Toollandschaften und Umdenkprozesse.

	== Zielsetzung ~~dies~~ Leitfadens ==		== Zielsetzung dieses Leitfadens ==
	Dieser Leitfaden unterstützt die Organisationen dabei, bestehende ISMS und vorhandene Sicherheitskonzepte auf Basis des IT-Grundschutzes schrittweise auf die Methodik Grundschutz++ zu übertragen. Er soll den Übergang fachlich einordnen, die wesentlichen methodischen Unterschiede verständlich machen und eine praktikable Orientierung für die Migration von Anforderungen, Strukturen, Rollen und Nachweisen geben.		Dieser Leitfaden unterstützt die Organisationen dabei, bestehende ISMS und vorhandene Sicherheitskonzepte auf Basis des IT-Grundschutzes schrittweise auf die Methodik Grundschutz++ zu übertragen. Er soll den Übergang fachlich einordnen, die wesentlichen methodischen Unterschiede verständlich machen und eine praktikable Orientierung für die Migration von Anforderungen, Strukturen, Rollen und Nachweisen geben.

Zeile 105:		Zeile 105:

	# '''Informationsverbund''' definieren (techn./org. Abgrenzung)		# '''Informationsverbund''' definieren (techn./org. Abgrenzung)
	# '''Assets''' für wichtigsten Geschäftsprozess erfassen		# '''Assets''' für die wichtigsten Geschäftsprozess erfassen
	# '''Asset → Zielobjektkategorien''' mapping (Hierarchie + Vererbung)		# '''Asset → Zielobjektkategorien''' mapping (Hierarchie + Vererbung)
	# '''Anforderungspaket''' generieren:		# '''Anforderungspaket''' generieren:
	#* ISMS-Praktiken (vollständig)		#* ISMS-Praktiken (vollständig)
	#* Zielobjektkategorie-Anforderungen (Sicherheitsniveau: normal/erhöht)		#* Zielobjektkategorie-Anforderungen (Sicherheitsniveau: normal/erhöht)
	#* Zielobjektlose Anforderungen prüfen		#* weitere Zielobjektlose Anforderungen prüfen
	# '''Ergänzungen''': Externe Verpflichtungen, anforderungslose Assets		# '''Ergänzungen''': Externe Verpflichtungen, anforderungslose Assets
	# '''Sicherheitsniveau''' prüfen		# '''Sicherheitsniveau''' prüfen
Zeile 162:		Zeile 162:
	# '''Anforderungspaket validieren''' (Aktualität prüfen)		# '''Anforderungspaket validieren''' (Aktualität prüfen)

	'''Ergebnis''': Auditberichte, Managementbericht		'''Ergebnis''': Auditberichte, Managementbericht, kontinuierliches Monitoring

	'''Weiterführende Informationen:'''		'''Weiterführende Informationen:'''
Zeile 187:		Zeile 187:

	'''Weiterführende Informationen:'''		'''Weiterführende Informationen:'''

			* ...

	=== Praktische Hinweise ===		=== Praktische Hinweise ===
Zeile 193:		Zeile 195:
	* '''Iteration''': Eine Migrations in einem Schritt ist praktisch kaum durchführbar, ein interatives Vorgehen auf jeden Fall sinnvoll. Wichtigster Geschäftsprozess zuerst, dann schrittweise erweitern		* '''Iteration''': Eine Migrations in einem Schritt ist praktisch kaum durchführbar, ein interatives Vorgehen auf jeden Fall sinnvoll. Wichtigster Geschäftsprozess zuerst, dann schrittweise erweitern
	* '''Risikobetrachtung''': Bei Sicherheitsniveau "hoch" oder Nicht-Umsetzung		* '''Risikobetrachtung''': Bei Sicherheitsniveau "hoch" oder Nicht-Umsetzung
	* '''Dokumentation''': bevorzugt ~~Maschinenlesbar~~ (OSCAL) für besseren Austausch		* '''Dokumentation''': bevorzugt maschinenlesbar (OSCAL -> ISMS-Tool) für besseren Austausch

	'''Zyklusdauer''': Jährlich oder ereignisgesteuert (Änderungen, Vorfälle, Audits)		'''Zyklusdauer''': Jährlich oder ereignisgesteuert (Änderungen, Vorfälle, Audits)
Zeile 220:		Zeile 222:
	=== Migration der Schutzbedarfslogik ===		=== Migration der Schutzbedarfslogik ===

	* Überführen der bisherigen Schutzbedarfsfeststellung in die GS++-'''Informationssicherheitseinstufung'''.		* Überführen der bisherigen Schutzbedarfsfeststellung in die GS++-'''[[Grundschutz:Informationssicherheitseinstufung\|Informationssicherheitseinstufung]]'''.
	* Prüfen, ob Schutzbedarfe auf Geschäftsprozesse und Informationen sauber genug beschrieben sind.		* Prüfen, ob Schutzbedarfe auf Geschäftsprozesse und Informationen sauber genug beschrieben sind.
	* Prüfen, wo bestehende Begründungen für Vertraulichkeit, Integrität und Verfügbarkeit wiederverwendbar sind.		* Prüfen, wo bestehende Begründungen für Vertraulichkeit, Integrität und Verfügbarkeit wiederverwendbar sind.

← Nächstältere Version		Version vom 6. Juni 2026, 10:43 Uhr
Zeile 1:		Zeile 1:
	[[Datei:Teamwork-2198961.png\|alternativtext=Zahnrad\|rechts\|~~240x240px~~]]{{#seo:		[[Datei:Teamwork-2198961.png\|alternativtext=Zahnrad\|rechts\|150x150px]]{{#seo:
	\|title=Grundschutz++ Einführung und Überblick		\|title=Grundschutz++ Einführung und Überblick
	\|keywords=ISMS, Wiki, BSI Grundschutz++, IT-Grundschutz, BSI-Standard 200-2, Bausteine, OSCAL, JSON, Informationssicherheit, Risikomanagement, Anforderungen		\|keywords=ISMS, Wiki, BSI Grundschutz++, IT-Grundschutz, BSI-Standard 200-2, Bausteine, OSCAL, JSON, Informationssicherheit, Risikomanagement, Anforderungen
Zeile 77:		Zeile 77:
	'''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.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.		'''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 keine spezifische Zielobjektkategorie benannt.

	Einzelne Teilanforderungen können auch in anderen Praktiken beschrieben sein.		Einzelne Teilanforderungen können auch in anderen Praktiken beschrieben sein.
Zeile 114:		Zeile 114:
	*'''Der Erfüllungsgrad''' zeigt, welche Anforderungen bereits umgesetzt wurden.		*'''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.		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.

			Der ursprüngliche Ansatz sah vor, dass Schwellwerte den Reifegrad und die Zertifizierbarkeit von Informationsverbünden dokumentieren sollten.

	=== Gestaltungsentscheidungen (Parameter) ===		=== Gestaltungsentscheidungen (Parameter) ===
Zeile 353:		Zeile 355:

	== Migration bestehender Sicherheitskonzepte ==		== Migration bestehender Sicherheitskonzepte ==
	~~tbd.~~..		Bisher gibt es noch keine offizielle MIgrationsstrategie von Grundschutz auf Grundschutz++. Es gibt erste KI-basierte Ansätze aus der Community, jedoch noch keine allgemein anerkannte Lösung.

	'''Weiterführende Informationen:'''		'''Weiterführende Informationen:'''
Zeile 365:		Zeile 367:

	=== Unklare Umsetzung einiger Ziele ===		=== 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.		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 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 ===		=== Geringer Mehrwert im Vergleich zu ISO 27001 ===
Zeile 371:		Zeile 373:

	=== Zu ambitionierter Zeitplan ===		=== 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.		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 eine unvollständige erste Version eines Leitfadens zur Methodik 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 größtenteils 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 IT-Grundschutz und Grundschutz++ ===		=== Zunehmende (Sicherheits-)Lücke zwischen IT-Grundschutz und Grundschutz++ ===
Zeile 380:		Zeile 382:

	=== Überholte Satzschablonen ===		=== Ü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.		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-sprachlich 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 ==		== Fazit ==
Zeile 391:		Zeile 393:
	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.		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:		Auch wenn abzuwarten bleibt, wann praxistaugliche Methoden verfügbar sind und wie lange die Übergangsfristen für die Umstellung sein werden (aktuelle Planung bis Ende 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).		*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).		*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.		**Ein guter Tip ist es, in aktuellen GSC jede Teilanforderung (jedes Modalverb wie MUSS oder SOLLTE) in der Umsetzung einzeln in jeweils einem Satz/Absatz 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.		*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~~.		*Frühzeitige Planung der Bereitstellung entsprechender personeller Ressourcen für die Umstellung auf Grundschutz++ ab Anfang 2027.
	*Gegebenenfalls frühzeitige Reservierung externer (personeller) Ressourcen zur Unterstützung.		*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.		*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.