Grundschutz++ Einführung und Aufbau

Diese Seite ist derzeit noch ein Entwurf.

Weitere Informationen sowie Diskussionen über Änderungen an diesem Entwurf gibt es evtl. auf der Diskussion-Seite.

Dieser Artikel bietet einen schrittweisen Überblick über BSI Grundschutz++ und navigiert durch relevante Artikel des ISMS-Ratgeber-Wikis sowie BSI-Quellen. Es ersetzt keine Originaldokumente.

Einführung in Grundschutz++

Grundschutz++ ist die 2026 vom BSI eingeführte Weiterentwicklung des IT-Grundschutz-Kompendiums. Es transformiert das bewährte Grundschutz-Konzept in ein vollständig digitales, maschinenlesbares Format mit JSON-basierten Bausteinen und OSCAL-kompatibler Struktur.

Der aktuelle Stand von Grundschutz++ ist bisher nur sehr eingeschränkt praktisch anwendbar, da einige wesentliche Definitionen und Teile der Methodik noch fehlen. Dazu gehören beispielsweise die Nutzung von Kennzahlen, Blaupausen, Stufen, Schutzbedarf vs. Schutzniveau und die Modellierung.
Der Anforderungskatalog liegt zwar im OSCAL- und Excel-Format vor, ist ohne eine abgeschlossene und nachvollziehbare Methodik aber nicht sinnvoll anwendbar.

Wesentliche Neuerungen

OSCAL/JSON-basiertes Regelwerk: Der IT-Grundschutz wird in ein maschinenlesbares JSON-Format überführt, das teilweise automatisierte Compliance-Prüfungen und Integrationen in bestehende IT-Systeme ermöglicht. Dies ersetzt die bisherigen textbasierten PDFs und Listen.
Prozessorientierte Struktur: Die neue Version ist modular und objektorientiert aufgebaut, um Redundanzen zu reduzieren und die Dokumentationslast zu verringern.
Leistungskennzahlen: Kennzahlen sollen die Informationssicherheit messbar und den Sicherheitsgewinn einzelner Anforderungen transparenter machen.
Harmonisierung mit ISO 27001: Die Anforderungen werden stärker mit internationalen Standards wie ISO 27001:2022 abgestimmt, um Doppelzertifizierungen zu vereinfachen.
Erweiterung um moderne Technologien: Geplant sind auch spezifische Module für Cloud-Security, KI und IoT, die aktuelle Bedrohungsszenarien abdecken.

Ziele der Reform

Schlankere Prozesse: Durch Automatisierung soll der administrative Aufwand sinken.
Dynamische Anpassung: JSON ermöglicht schnellere, ggf. automatisierte Updates bei neuen Cyberbedrohungen.
Praxisorientierte Vereinfachung: Der BSI will die Dokumentationslast reduzieren und den Fokus auf risikobasierte Ansätze legen, insbesondere für KMU.
Priorisierung und Messbarkeit: Durch eine stufenweise Priorisierung von Anforderungen und Leistungskennzahlen soll ein zielgerichteteres Vorgehen und die bessere Messbarkeit der Sicherheit gefördert werden.

Die Änderungen reagieren auf Kritik an der bisherigen Komplexität und sollen besonders KMU entlasten, während die ganzheitliche Sicherheitsmethodik (technisch, organisatorisch, personell) erhalten bleibt.

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

Offizieller Starttermin für den Grundschutz++ war der 1.1.2026. Danach ist allerdings eine längere Übergangsphase geplant, in der beide Standards parallel genutzt werden können, so wie bei der letzten Modernisierung auch. Da jedoch zu erwarten ist, dass eine automatisierte Migration auch diesmal nicht oder nur eingeschränkt möglich sein wird, sollte speziell in größeren Verbünden rechtzeitig begonnen werden! Der jeweils aktuellen Grundschutz++ Katalog wird auf GitHub veröffentlicht.

Bedeutung von OSCAL im Grundschutz++

Das zugrundeliegende Format für Grundschutz++ ist OSCAL.

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

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

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

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

Das heißt aber nicht:

Das Anwender, Sicherheitsmanager oder Sicherheitsbeauftragte OSCAL lernen müssen oder OSCAL Formate lesen können müssen. (Dafür gibt es Tools, die die Inhalte lesbar und bearbeitbar zur Verfügung stellen)
Das alle Anforderungen automatisiert erfüllt und dokumentiert werden (viele Anforderungen sind nach wie vor organisatorische Anforderungen die nur von Menschen durch Erstellung und Beachtung entsprechenden Regelungen erfüllt werden können).
Das überhaupt irgendwelche Anforderungen automatisiert erfüllt und dokumentiert werden (Hierzu müssten die Systeme an ein ISMS-Tool angebunden sein und diese über entsprechende Schnittstellen mit Informationen bedienen). Sowohl die Tools als auch die Schnittstellen werden absehbar nicht vom Himmel fallen.

Satzschablonen

Anforderungen werden im Grundschutz++ zukünftig mit Satzschablonen erstellt, die wie folgt aussehen:

{Praktik} [für {Zielobjekt}] {MODALVERB} <Ergebnis> {Handlungswort} (TAGs) (Hinweise)

Praktik: Ein Prozess im Rahmen des ISMS, eine konkrete Sicherheitsmaßnahme oder eine allgemeine Vorgehensweise zur Erreichung eines Sicherheitsziels (z.B. IT-Betrieb, Personal, Konfiguration) - Im weitesten Sinne vergleichbar mit den bisherigen Bausteinen. Liste der gültigen Praktiken.

Zielobjekt: Wie bisher, das Objekt oder die Entität, auf die sich die Sicherheitsanforderungen beziehen (z.B. Daten, Personen, Endgeräte, Hostsysteme). Liste der Gültigen Zielobjekte.

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

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

Handlungswort: Das Verb, das die konkrete Sicherheitsmaßnahme oder Art der Tätigkeit beschreibt (regeln, zuweisen, konfigurieren). Handlungsworte können auch zur besseren Filterung genutzt werden. Liste der gültigen Handlungsworte.

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

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

Beispiel

Die Anforderung:

ISMS.1.A4 Benennung eines oder einer Informationssicherheitsbeauftragten (B) [Institutionsleitung]
Die Institutionsleitung MUSS einen oder eine ISB benennen. . . .
Die Institutionsleitung MUSS den oder die ISB mit angemessenen Ressourcen ausstatten.
Die Institutionsleitung MUSS dem oder der ISB die Möglichkeit einräumen, bei Bedarf direkt an sie selbst zu berichten. . . .

Wird jetzt zu den Anforderungen:

GOV.4.2: Die Governance MUSS einer Person die Rolle ISB zuweisen.
GOV.2.3: Die Governance MUSS für das ISMS erforderliche personelle, finanzielle und zeitliche Ressourcen zuweisen.

GOV.4.4: Die Governance MUSS dem ISB das direkte und jederzeitige Vorspracherecht bei der Institutionsleitung ermöglichen.

Da dies übergreifende Anforderungen sind, ist hier kein spezifisches Zielobjekt benannt.

Einzelne Teilanforderungen können auch in anderen Praktiken beschrieben sein.

Priorisierung

Alle Anforderungen werden einer Prioritätsstufe zugeordnet, um die Umsetzung effizient zu gestalten:

Stufe 0: Zwingend (sofort) umzusetzende Anforderungen zur Sicherstellung der ISO-Kompatibilität (MUSS-Anforderungen).

Die Stufen 1-4 geben den Umsetzungsaufwand der Anforderungen wieder:

Stufe 1: Schnell und mit geringem Aufwand (~1 Tag) realisierbare Maßnahmen (QuickWin) / keine laufenden Aufwände.
Stufe 2: Mit eigenen Mitteln leicht umsetzbare Anforderung (~1 Woche) / geringe laufende Aufwände.
Stufe 3: Mit normalem Aufwand (mehrere Wochen) und ggf. externer Unterstützung umsetzbar / normale laufende Aufwände.
Stufe 4: Höherer Umsetzungsaufwand, häufig in längerfristigen Projekten mit externen Experten.

Die nächste Stufe sind optionale Anforderungen als Vorschläge bei erhöhtem Schutzbedarf.

Stufe 5: Umfassende/zusätzliche Anforderungen für höheren Schutzbedarf.

Diese Einstufung ermöglicht eine schnelle Einschätzung des Umsetzungsaufwands und hilft bei der effizienten Ressourcenplanung.

Leistungskennzahlen

Leistungskennzahlen dienen der Messung und Bewertung der Umsetzung von Sicherheitsanforderungen im IT-Grundschutz. Sie ermöglichen eine objektive Einschätzung des Sicherheitsniveaus und unterstützen die kontinuierliche Verbesserung. Wie diese Leistungskennzahlen genutzt werden sollen ist nach wie vor unklar.

Bewertungskriterien

Jede Anforderung wird in Bezug auf die drei Schutzziele bewertet:

Vertraulichkeit (C)
Integrität (I)
Verfügbarkeit (A)

Anforderungen erhalten Punktwerte in diesen Kategorien, die zur Bestimmung des Schutzgrades genutzt werden (z.B. C=6, I=2, A=0 ist eine Anforderung die im Wesentlichen die Vetraulichkeit stärkt, in Teilen die Intgrität aber nicht die Verfügbarkeit).

Die einzelen Kennzahlen werden je Schutzziel, Praktik und/oder Zielobjekt aufsummiert und ergeben so den Erfüllungsgrad.

Schwellwerte und Erfüllungsgrad

Schwellwerte definieren das angestrebte Sicherheitsniveau basierend auf der Summe der Punktwerte aller umgesetzten Anforderungen je Schutzziel, Zielobjekt und Schutzstufe.
Der Erfüllungsgrad zeigt, welche Anforderungen bereits umgesetzt wurden.

Die Leistungskennzahlen bieten damit eine fundierte Entscheidungsgrundlage für Organisationen, um ihren Sicherheitsstatus gezielt zu verbessern, wenn sie wie ursprünglich geplant eingeführt werden.

Was bleibt erhalten?

Standards und Vorgehen

Trotz eines deutlich anderen Formats und einer anderen Gruppierung der Anforderungen bleibt das grundsätzliche Vorgehen weitgehend gleich.

D.h. die Standards 200-1 bis 200-4 sollen erst einmal weiter Verwendung finden. Die bisher üblichen Arbeitsschritte:

Festlegung des Geltungsbereichs
Strukturanalyse
Schutzbedarfsfeststellung
Modellierung
IT-Grundschutzcheck (GSC)
Risikoanalyse

bleiben grundsätzlich erhalten, ändern sich jedoch in der praktischen Anwendung (insbesondere in der Modellierung und den Grundschutzchecks). Parallel zur Einführung sollen die Standards weiter entwickelt werden.

MUSS-Anforderungen sind weiterhin verpflichtend für eine Zertifizierung.

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

Lediglich KANN-Anforderungen sind optional.

Tool-Einsatz

Auch der Einsatz von ISMS-Tools wird weiterhin Bestand haben. Alle größeren Tool-Hersteller arbeiten mit Hochdruck an der Integration von Grundschutz++ in ihre Tools. Hier wird es perspektivisch Erleichterungen durch einen leichteren Datenaustausch zwischen den Tools und mehr Automatisierungspotential geben.

Gegenüberstellung Grundschutz Kompendium vs. Grundschutz++

Das IT-Grundschutz-Kompendium 2023 und der zukünftige Grundschutz++ bieten unterschiedliche Konzepte für die Umsetzung von Informationssicherheit: Während das Kompendium auf feste Bausteine in thematisch gegliederten Schichten setzt, verwendet Grundschutz++ modulare, flexibel einsetzbare Praktiken.

Die folgende Tabelle stellt die wesentlichen Unterschiede und Gemeinsamkeiten zwischen beiden Ansätzen (nach aktuell verfügbaren Kenntnissen) gegenüber:


	Grundschutz Kompendium	Grundschutz++
	Fester verbindlicher Katalog von Anforderungen (PDF, Excel und XML), die je nach Reifegrad erfüllt werden müssen.	Der variable und erweiterbare OSCAL-Datenbestand kann beliebig an die Bedürfnisse der Organisation angepasst werden. Zusätzliche Kataloge/Erweiterungen (C5, Datenschutz, KRITIS/NIS2) können je nach Verfügbarkeit ergänzt werden. Durch die Beseitigung vermeintlicher Redundanzen soll die Anzahl der Anforderungen erheblich reduziert werden (~10–20 % verbleibende Anforderungen gegenüber dem aktuellen Kompendium).
	Järliche Aktualisierung zum Stichtag 1. Februar. (bis 2023)	Die Aktualisierung erfolgt fortlaufend nach Bedarf und Verfügbarkeit. Die Regelungen zur Relevanz für Zertifizierungen sind bislang noch nicht bekannt.
	Das Kompendium ist in 10 Schichten mit insgesamt 111 Bausteine gegliedert, die statisch die jeweiligen Anforderungen enthalten.	Praktiken sind allgemeinere und wiederverwendbare, sicherheitsrelevante Verfahren oder Maßnahmen. Sie können modular und situationsabhängig einzelnen Zielobjekten zugeordnet werden. Die voraussichtlich ca. 20 Praktiken liegen irgendwo zwischen Schichten und Bausteinen. Sie sind prozessorientierter, adressieren eher Zielgruppen oder Handlungstypen und sind nicht mehr starr bestimmten Zielobjekten zugeordnet.
	Drei Stufen (Vorgehensweisen): Basis, Standard, erhöhter Schutzbedarf bilden den Reifegrad der Organisation ab.	Es sind zukünftig sechs Stufen (0–5) geplant, die sich weitgehend am Umsetzungsaufwand der jeweiligen Anforderung orientieren: Je kleiner die Stufe, desto schneller bzw. leichter ist die Anforderung umsetzbar (Quick Win). Eine qualitative Bewertung des Reifegrads muss zukünftig anders erfolgen (z. B. über Leistungskennzahlen). Das Sicherheitsniveau gibt zukünftig an, in welchem Maß die definierten Sicherheitsziele erreicht sind. Es ergibt sich aus der wirksamen Umsetzung organisatorischer, technischer und personeller Anforderungen. Unterschieden werden: Normales Sicherheitsniveau: entspricht dem Stand der Technik Erhöhtes Sicherheitsniveau: für besonders schutzbedürftige Informationen oder Systeme
	Zielobjekte als gruppierte Sammlung von gleichartigen Assets die zur späteren Modellierung (Zuordnung der Bausteine und Abhängigkeiten) genutzt werden.	Zielobjekte werden auch in Zukunft eine ähnliche Funktion zur Gruppierung und Modellierung haben. Die konkreten Vorgaben zur Modellierung sind jedoch noch nicht bekannt. In der Modellierung werden die Praktiken nicht mehr statisch bestimmten Zielobjekttypen zugewiesen.
	Modalverben MUSS, SOLLTE, KANN bestimmen die Verbindlichkeit von Anforderungen.	Die Bedeutung der Modalverben (MUSS, SOLLTE, KANN) bleibt unverändert. Ein Ziel von Grundschutz++ ist es jedoch, die Anzahl der Muss-Anforderungen auf das Nötigste zu reduzieren (unter 10 %). Dadurch soll der Grundschutz flexibler werden. Die Verbindlichkeit von Anforderungen, die über MUSS-Anforderungen hinausgehen, ist noch unklar.
	-	Neu sind Leistungskennzahlen, die eine qualitative Bewertung der Anforderungen in Bezug auf Vertraulichkeit, Integrität und Verfügbarkeit darstellen. Sie sollen als Zahlenwert darstellbar sein und so den Reifegrad abbilden können. Bisher ist noch nicht bekannt, ob und wann diese eingeführt werden und wie die konkreten Regelungen aussehen werden.
	Gültigkeit voraussichtlich bis 2029	Gültig ab 1.1.2026. Zertifizierbar ab 2027.

Teilweise werden Begrifflichkeiten neu (und anders) definiert:

	Grundschutz Kompendium	Grundschutz++
	Zielobjekt als gruppierte Sammlung von gleichartigen Assets als Grundlage für die spätere Modellierung	Asset und gruppierte Assets. Die Gruppierung gleichartiger Assets kann weiterhin erfolgen es bleiben jedoch auch dann Assets. Der Begriff Zielobjekt wird hier nicht mehr genutzt.
	Baustein als Sammlung von Anforderungen für bestimmte Zielobjekttypen.	Zielobjekt sind zukünftig das was bislang die Bausteine waren, bestimmte Typen von Assets für die spezische Anforderungen gelten. Die Assets werden den Zielobjekten zugewisen und erhalten über diese ihre Anforderungen. Eine klare Definition der Begriffe steht noch aus.

Blaupausen

Blaupausen sind vorgefertigte Musterlösungen (wie die bisherigen IT-Grundschutz-Profile), die als Vorlage (Referenzmodell) für die Erstellung und Umsetzung von branchenspezifischen oder organisationsspezifischen Sicherheitskonzepten dienen.

Funktion der Blaupausen

Solche Blaupausen erfassen typische Strukturen, Risiken, Anforderungen und Maßnahmen für bestimmte Anwendungsszenarien, etwa die Nutzung der E-Akte oder den sicheren Betrieb von 5G-Infrastrukturen. Sie ermöglichen es, ein ISMS deutlich effizienter und strukturierter aufzubauen, weil die grundlegenden Überlegungen (Schutzbedarfsermittlung, Zuordnung von Praktiken, Zielobjekten und Maßnahmen, etc.) bereits allgemein gültig vorformuliert sind und nur noch organisationsspezifisch angepasst werden müssen.

Ziel und Nutzen

Blaupausen helfen, den Implementierungsaufwand für ISMS nach Grundschutz++ zu reduzieren.
Sie fördern die Standardisierung und Wiederverwendbarkeit von Sicherheitskonzepten für ähnliche Organisationen oder Branchen.
Besonders für kleinere Organisationen und typische Anwendungsfälle bieten sie einen niederschwelligen, strukturierten und praxiserprobten Einstieg in die Absicherung.

Damit sind Blaupausen im Grundschutz++ zentrale Instrumente, um bewährte Sicherheitsmethoden als Vorlage für den schnellen und einheitlichen Aufbau eines branchenspezifischen ISMS bereitzustellen.

Umsetzung

Umgesetzt werden Blaupausen technische als OSCAL-Profile mit zusätzlichen Erläuterungen in Textform, zukünftig sollen Blaupausen zu einem System Security Plan (SSP) weiter entwickelt werden.

Grundlagen und Standards

BSI-Standard 200-1: Anforderungen an ein ISMS.
BSI-Standard 200-2: IT-Grundschutz Methodik ( <- Wird neu erstellt )
- Methodik zum Grundschutz++ (Aktuell in Erstellung, ersetzt 200-2)
BSI-Standard 200-3: Risikomanagement mit Grundschutz.
BSI-Standard 200-4: Business Continuity Management
Artikel zu OSCAL (Open Security Controls Assessment Language).

Schritt-für-Schritt-Methodik

Die Methodik-Grundschutz++ folgt einem 5-stufigem PDCA-basierten Prozess mit Fokus auf Anforderungsmodellierung und maschinenlesbarer Verarbeitung. Hier das praktische Vorgehen:

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

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

Ergebnis: Organisatorischer Rahmen, Sicherheitsleitlinie, priorisierte Prozesse

Schritt 2: Anforderungsanalyse (PLAN - Strukturmodellierung)

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

Ergebnis: Individuelles Anforderungspaket pro Informationsverbund

Schritt 3: Realisierung (DO - Umsetzung)

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

Ergebnis: Umsetzungsplan + Status-Dokumentation

Schritt 4: Überwachung (CHECK - Monitoring/Evaluation)

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

Ergebnis: Auditberichte, Managementbericht

Schritt 5: Kontinuierliche Verbesserung (ACT - Verbesserung)

Nicht-Konformitäten analysieren (Root-Cause)
Verbesserungspotenziale identifizieren
Korrektur-/Verbesserungsplan → in Umsetzungsplan integrieren
Wirksamkeit prüfen nach Umsetzung
Sicherheitsniveau bewerten (Trendanalyse)
Compliance-Verstöße behandeln

Ergebnis: Aktualisiertes Anforderungspaket → neuer PDCA-Zyklus

Praktische Hinweise

Tool-gestützt: JSON/OSCAL-Bausteine, verinice.PRO empfohlen
Iteration: Wichtigster Geschäftsprozess zuerst, dann schrittweise erweitern
Risikobetrachtung: Nur bei "hoch" oder Niveauserhöhung/Nicht-Umsetzung
Dokumentation: Maschinenlesbar (GitHub-Link in Methodik)

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

Weiterführende Ressourcen

Fazit