> For the complete documentation index, see [llms.txt](https://docs.dispel.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dispel.com/documentation/documentation-de/absichern-and-steuern/overview/compliance-and-audit-readiness.md). # Erste Schritte Automatisierte Audit-Bereitschaft mit Dispel für NERC CIP-, NIST 800-53- und NIS2-Kontrollen. ## Erste Schritte Das Erstellen eines Dispel-Compliance-Pakets ist ein Workflow mit vier Phasen: 1. [**Wählen Sie**](#step-1-select-a-framework) die Framework(s), über die Ihre Organisation berichtet. 2. [**Bewerten**](#step-2-assess-dispels-coverage) die Abdeckung von Dispel anhand der aktuellen Konfiguration Ihres Mandanten. 3. [**Überprüfen**](#step-3-review-coverage-and-close-gaps) welche Kontrollen Dispel abdeckt, identifizieren Sie etwaige Lücken in der Abdeckung und verwenden Sie den Simulator, um Konfigurationsänderungen zu planen, die diese schließen. 4. [**Exportieren**](#step-4-export-the-inheritance-package) die OSCAL Component Definition und den PDF-Bericht und übergeben Sie sie an Ihr GRC-Team oder Ihren Auditor. *** #### Schritt 1: Ein Framework auswählen Wenn Sie ein Framework auswählen, legt Dispel fest, in welchem Kontrollvokabular seine Abdeckung ausgedrückt wird. Die meisten Organisationen wählen das Framework, von dem ihr Auditor oder die zuständige Behörde ausgeht. Sie können mehrere Frameworks gleichzeitig aktiv haben — nützlich, wenn dieselbe Dispel-Bereitstellung gegen mehr als ein regulatorisches Regelwerk geprüft wird. 1. Navigieren Sie in der linken Seitenleiste zum **Einstellungen**. 2. Öffnen Sie den **Compliance** -Tab. 3. Klicken Sie auf **Framework hinzufügen**. 4. Wählen Sie ein **Katalog** (z. B. *NIST SP 800-53 Rev 5*). 5. Wählen Sie ein **Profil** oder **Basislinie** (z. B. *Mäßig*). Profile schränken einen Katalog auf die Teilmenge der Kontrollen ein, die auf einer bestimmten Auswirkungsstufe erforderlich sind. 6. Klicken Sie auf **Hinzufügen**. Das Framework erscheint sofort in Ihrer Liste aktiver Frameworks. Dispel beginnt im Hintergrund mit der Bewertung seiner Abdeckung, und das Dashboard füllt sich, sobald die Bewertungen abgeschlossen sind. {% hint style="info" %} Das Hinzufügen mehrerer Frameworks erzeugt **keine** doppelten Aufwand. Dispel erzeugt einen einzigen Satz von Nachweisen über seine eigene Implementierung und drückt ihn über jedes aktive Framework hinweg erneut aus. Das Hinzufügen von NIST CSF zu NIST 800-53 verwendet dieselben zugrunde liegenden Nachweise. {% endhint %} **Ein Framework entfernen** Um ein aktives Framework zu entfernen, klicken Sie in der Liste der aktiven Frameworks auf das Papierkorb-Symbol daneben. Durch das Entfernen eines Frameworks wird dessen Scorecard gelöscht, aber weder ein anderes aktives Framework noch der zugrunde liegende Nachweisdatensatz beeinflusst. **Sie können entfernte Frameworks problemlos erneut hinzufügen, ohne einen Teil Ihrer Historie zu verlieren.** *** #### Schritt 2: Die Abdeckung von Dispel bewerten **Automatisierte Bewertung** Dispel wird mit einer Bibliothek von **Kontroll-Scannern** geliefert, die prüfen, ob Dispel — gegeben die aktuelle Konfiguration Ihres Mandanten — jede im Umfang enthaltene Kontrolle umsetzt. Zum Beispiel: `ist MFA auf diesem Mandanten erzwungen`, `ist Sitzungsaufzeichnung aktiviert`, `erfüllt die Kennwortrichtlinie die Framework-Schwelle`, und `liegen Lieferantenbestätigungen vor`. Jeder Evaluator wird einer oder mehreren Kontrollen in jedem aktiven Framework zugeordnet. So führen Sie eine Bewertung aus: 1. Navigieren Sie zu **Einstellungen** > **Compliance**. 2. Öffnen Sie das Framework, das Sie bewerten möchten. 3. Klicken Sie auf **Bewertung ausführen**. Bewertungsergebnisse werden mit einem Zeitstempel gespeichert. Jede Kontrolle erhält einen der folgenden Status, der beschreibt, wie Dispel diese Kontrolle auf Ihrem Mandanten implementiert: | Status | Bedeutung | | ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Implementiert** | Dispel implementiert diese Kontrolle auf Ihrem Mandanten vollständig. Sie können sie übernehmen. | | **Fehlgeschlagen** | Dispel **keine** implementiert diese Kontrolle derzeit nicht auf Ihrem Mandanten — in der Regel, weil eine Dispel-Einstellung geändert werden muss. Sie können sie in der aktuellen Konfiguration nicht übernehmen. | | **Nicht bewertet** | Für diese Kontrolle wird kein automatisierter Evaluator ausgeführt, oder die Evaluatoren sind noch nicht abgeschlossen. | | **Nicht anwendbar** | Die Kontrolle liegt außerhalb des Umfangs von Dispel (z. B. physische Sicherheit an Ihrer Einrichtung), und eine Übernahme von Dispel aus gilt hier nicht. | {% hint style="info" %} Bewertungen sind nicht destruktiv und nur lesend. Sie beobachten die Konfiguration von Dispel; sie ändern niemals Ihren Mandanten. {% endhint %} *** #### Schritt 3: Abdeckung überprüfen und Lücken schließen Das Compliance-Dashboard ist Ihr täglicher Arbeitsbereich, um zu verstehen, was Dispel auf Ihrem Mandanten abdeckt und wo die Abdeckung verbessert werden kann. **Scorecard** Jedes aktive Framework hat eine Scorecard, die den Prozentsatz der im Umfang enthaltenen Kontrollen anzeigt, die Dispel derzeit auf Ihrem Mandanten implementiert. Teilpunkte werden vergeben, wenn nur einige Unterkontrollen oder Erweiterungen implementiert sind. Bewegen Sie den Mauszeiger über eine Zahl, um die zugrunde liegende Aufschlüsselung zu sehen. **Sunburst-Diagramm** Die hierarchische Sunburst-Visualisierung zeigt die Abdeckung von Dispel auf einen Blick: Framework → Kontrollfamilie → einzelne Kontrolle. Implementierte (übertragbare) Kontrollen werden grün dargestellt; fehlgeschlagene (derzeit nicht übertragbare) rot; nicht bewertete grau. Klicken Sie auf ein beliebiges Segment, um zur Detailseite der Kontrolle zu gelangen. **Detailseite der Kontrolle** Wenn Sie eine Kontrolle auswählen, werden angezeigt: * **Status** — Dispel’s aktuelle und historische Implementierung der Kontrolle auf diesem Mandanten * **Nachweise** — die spezifischen Evaluatoren, die zum Status beigetragen haben, mit Zeitstempeln und den zugrunde liegenden Werten, die sie beobachtet haben * **Darstellung** — die Implementierungsbeschreibung von Dispel für die Kontrolle * **Abstammung** — jedes andere Framework, dessen Kontrollen auf denselben Nachweis abgebildet werden (sodass ein einzelner Übernahmeanspruch in mehreren Framework-Sprachen ausgedrückt werden kann) * **Hinweise zur Behebung** — bei fehlgeschlagenen Kontrollen eine Beschreibung der Dispel-Einstellung oder Konfigurationsänderung, die die Übernahme wiederherstellen würde **Simulation der Konfigurationsauswirkungen** Bevor Sie eine Dispel-Einstellung auf Ihrem Mandanten ändern, verwenden Sie den Simulator, um vorherzusagen, wie sich die Abdeckung verschiebt: 1. Im Dashboard anzeigen **Geschätzte Auswirkung** unter **Empfehlungen**. 2. Suchen Sie im Overlay-Bereich eine oder mehrere Dispel-Einstellungen (z. B. *MFA für alle Benutzer aktivieren*). 3. Vergleichen Sie die projizierte Scorecard mit Ihrer aktuellen Scorecard. Der Simulator ändert keine realen Einstellungen. Er ist ausschließlich ein Planungstool, um Änderungen so zu sequenzieren, dass die Dispel-Übernahme gestärkt wird. {% hint style="info" %} Verwenden Sie den Simulator, um Konfigurationsänderungen in der Reihenfolge zu planen, die zuerst die meisten übertragbaren Kontrollen wiederherstellt. {% endhint %} *** #### Schritt 4: Das Übernahmepaket exportieren **OSCAL Component Definition** Die OSCAL Component Definition ist das standardisierte Artefakt zur Dokumentation des Beitrags einer einzelnen Komponente zum System Security Plan eines Kunden. Bei Dispel ist diese Komponente Ihre Dispel-Bereitstellung, und die Component Definition ist der maßgebliche Nachweis darüber, wofür Ihr Auditor Ihnen die Übernahme anrechnen kann. 1. Öffnen Sie die Detailseite des Frameworks. 2. Klicken Sie auf **Exportieren** > **OSCAL Component Definition**. 3. Eine JSON-Datei wird heruntergeladen, die mit OSCAL 1.1.2 übereinstimmt. Der Export enthält: * Der Katalog und das Profil, in dem der Übernahmeanspruch ausgedrückt wird * Der Implementierungsstatus jeder im Umfang enthaltenen Kontrolle aus Sicht von Dispel (`implementiert`, `teilweise`, `nicht implementiert`, `nicht anwendbar`) * Die Implementierungsbeschreibung von Dispel für jede Kontrolle * Links zu den zugrunde liegenden Nachweisdatensätzen Diese Datei kann in eMASS-, Xacta-, RegScale-, FedRAMP- und GovRAMP-Einreichungen oder in jedes Tool importiert werden, das OSCAL unterstützt — dort liegt sie zusammen mit Component Definitions Ihrer anderen Anbieter und Ihren internen SSP-Inhalten. **Management-PDF-Bericht** Für interne Stakeholder und Audit-Begleitschreiben: 1. Öffnen Sie die Detailseite des Frameworks. 2. Klicken Sie auf **Exportieren** > **PDF-Bericht**. Der Bericht enthält: * Eine Zusammenfassung für Führungskräfte, die angibt, wie viel Prozent der im Umfang enthaltenen Kontrollen Sie heute von Dispel übernehmen können * Eine Framework-Scorecard * Jede Kontrolle, die Dispel auf Ihrem Mandanten derzeit nicht implementiert, zusammen mit der Konfigurationsänderung, die die Übernahme wiederherstellen würde * Die Liste der Nachweisquellen, die zur Bewertung beigetragen haben * Generierungszeitstempel und die Identität des Prüfers *** ### Kontinuierliche Nachweise und Audit-Trail Jeder Evaluatorlauf erzeugt einen **Nachweisschnappschuss** der mit einem Zeitstempel gespeichert wird. Der Schnappschuss hält fest, was Dispel in diesem Moment über seine eigene Abdeckung beobachtet hat. Auditoren, die einen bestimmten Zeitpunkt verifizieren müssen, können: 1. Den Bewertungsdatensatz für das betreffende Datum finden. 2. In den Nachweisschnappschuss für eine beliebige einzelne Kontrolle eintauchen. 3. Die genauen Werte sehen, die der Evaluator beobachtet hat, sowie den Zeitpunkt der Beobachtung. *** ### Was Dispel abdeckt (und was nicht) Dispel deckt die Sicherheitskontrollen ab, die innerhalb der Dispel-Plattform selbst implementiert sind — vor allem die Ebenen Fernzugriff, Identität, Sitzungsüberwachung, Netzwerksegmentierung und OT-Konnektivität. Kontrollen, die von Dispels eigener Unternehmensaufstellung abhängen (Lieferantenmanagement, Lieferkette, SDLC, Personalüberprüfung), werden ebenfalls über Dispels veröffentlichte Implementierungsbeschreibungen abgedeckt. Dispel **keine** deckt keine Kontrollen außerhalb seines Wirkungsbereichs ab: physische Sicherheit an Ihren Standorten, Härtung von Endgeräten auf Geräten, die Dispel nicht verwaltet, Anwendungsentwicklung in Ihren Geschäftssystemen, HR-Praktiken in Ihrer Organisation und so weiter. Diese Kontrollen verbleiben vollständig in Ihrem unternehmensweiten GRC-Tooling. Die folgende Tabelle fasst die Kategorien der von Dispel erzeugten Nachweise zusammen und die Framework-Kontrollfamilien, die sie typischerweise unterstützen. Dies ist illustrativ; die maßgebliche Zuordnung für Ihr aktives Framework wird auf der Detailseite jeder Kontrolle angezeigt. | Nachweiskategorie | Beispielhafte NIST-800-53-Familien | Beispielhafte NERC-CIP-Anforderungen | Beispielhafte NIS2-Maßnahmen (Durchführungsverordnung 2024/2690) | | ------------------------------------------ | ---------------------------------- | ------------------------------------ | ---------------------------------------------------------------- | | Identität, MFA, Sitzungslebenszyklus | AC, IA | CIP-004, CIP-005, CIP-007 | Identitäts- und Zugriffskontrolle; Authentifizierung | | Fernzugriff und Segmentierung | AC, SC | CIP-005, CIP-007 | Netzwerksicherheit; Zugriffskontrollrichtlinien | | Sitzungsaufzeichnung und Forensik | AU | CIP-007, CIP-008 | Vorfallbehandlung; Protokollierung und Überwachung | | Konfigurations- und Änderungsprotokolle | CM | CIP-010 | Asset-Management; Änderungsmanagement | | Lieferanten- und Lieferkettenbestätigungen | SR, PS | CIP-013 | Lieferkettensicherheit | | Plattformbestätigung und Integrität | SI, SC | CIP-007, CIP-010 | Vulnerabilitätsbehandlung und Offenlegung; Kryptografie | *** ### Häufig gestellte Fragen
Ändert das Ausführen einer Bewertung etwas auf meinem Mandanten? Nein. Bewertungen sind nur lesend. Sie beobachten den aktuellen Zustand Ihrer Dispel-Konfiguration und erzeugen Nachweisschnappschüsse über die Abdeckung von Dispel. Sie ändern niemals Einstellungen, Benutzer, Geräte oder Richtlinien.
Wie oft sollte ich eine Bewertung ausführen? Für die meisten Organisationen reicht es aus, nach jeder wesentlichen Konfigurationsänderung eine Bewertung auszuführen. Einige Auditoren verlangen Nachweise über regelmäßige Bewertungen (z. B. monatlich oder vierteljährlich) — planen Sie Bewertungen so, dass sie dem von Ihrem Auditprogramm geforderten Rhythmus entsprechen. Der OSCAL-Export und der PDF-Bericht erfassen den Zeitstempel der Bewertung.
Kann ich Dispel als mein vollständiges GRC-System verwenden? Nein. Dispel ist nur für die Kontrollen, die Dispel selbst implementiert, das führende System — die Übertragungsschicht unter Ihrem Audit. Für Kontrollen außerhalb des Wirkungsbereichs von Dispel (physische Sicherheit, HR-Prozesse, Softwareentwicklungspraktiken, Endgeräte, die Dispel nicht verwaltet, usw.) liegen die Nachweise in Ihrer unternehmensweiten GRC-Plattform. Die Dispel OSCAL Component Definition ist so konzipiert, dass sie als eine Komponente unter vielen in diese Plattform aufgenommen werden kann.
Was bedeutet „Nicht bewertet“ bei einer Kontrolle? Eine Kontrolle zeigt *Nicht bewertet* an, wenn bisher kein automatisierter Evaluator darauf ausgeführt wurde oder wenn die Evaluatoren noch nicht abgeschlossen sind. Dies ist nicht dasselbe wie *Nicht anwendbar*, was bedeutet, dass die Kontrolle außerhalb des Umfangs von Dispel liegt und nicht zu dem gehört, was Sie von Dispel übernehmen können.
Kann ich NIS2-Compliance mit Dispel nachweisen? Für den Teil von NIS2, den Dispel abdeckt, glauben wir: ja. Wählen Sie **NIS2** als aktives Framework, und Dispel erzeugt eine Component Definition, die sich an den Maßnahmen der EU-Durchführungsverordnung zu NIS2 (2024/2690) orientiert und gemäß der technischen Umsetzungsanleitung von ENISA auf NIST 800-53 abgebildet ist. Übergeben Sie sie Ihrer zuständigen Behörde zusammen mit Ihren übrigen NIS2-Unterlagen als Übertragungsschicht für Ihre Kontrollen zu Fernzugriff, Identität, Sitzungsüberwachung und OT-Konnektivität. ENISA hat keinen offiziellen NIS2-OSCAL-Katalog veröffentlicht. Der Dispel-Katalog wird direkt aus dem Rechtstext der Durchführungsverordnung erstellt. Wenn ENISA in Zukunft einen offiziellen Katalog veröffentlicht, wird Dispel ihn übernehmen.
Warum werden einige Kontrollen als „Nicht anwendbar“ angezeigt? Eine Kontrolle wird markiert *Nicht anwendbar* wenn sie außerhalb von Dispels Wirkungsbereich liegt und daher nicht etwas ist, das Sie von Dispel übernehmen können — zum Beispiel Kontrollen für den physischen Zugang zu Ihrer Einrichtung, Einstellungspraktiken in Ihrer Organisation oder Softwareentwicklung für Ihre internen Anwendungen. Die N/A-Feststellung wird im OSCAL-Export aufgezeichnet, damit Ihr Auditor genau sehen kann, welche Kontrollen aus dem Dispel-Übernahmeanspruch ausgeschlossen wurden, und sie über andere Kanäle verifizieren kann.
Was passiert mit meinen Daten, wenn ich ein Framework entferne? Nichts, es ist vollkommen sicher. Das Entfernen eines Frameworks löscht dessen Scorecard und entfernt es aus dem Dashboard. Zugrunde liegende Nachweisschnappschüsse und Kontrolldarstellungen bleiben erhalten und sind wieder verfügbar, wenn Sie das Framework erneut hinzufügen. Es geht keine Bewertungshistorie verloren.
Enthält der OSCAL-Export sensible Konfigurationen des Mandanten? Nein. Die Component Definition enthält den Implementierungsstatus, die Beschreibungen und Verweise auf Nachweise von Dispel — nicht jedoch rohe Konfigurationswerte, Zugangsdaten, IP-Adressen oder Benutzerdaten aus Ihrem Mandanten. Sie können sie bedenkenlos mit Auditoren teilen und in OSCAL-fähige GRC-Plattformen hochladen.
Kann derselbe Dispel-Nachweis mehr als ein Framework unterstützen? Ja. Das ist der zentrale Vorteil der OSCAL-basierten Architektur. Ein einzelner Dispel-Nachweis (z. B. „MFA ist auf diesem Mandanten erzwungen“) trägt gleichzeitig zu NIST 800-53 IA-2(1), NIST CSF PR.AA-03, NERC CIP-005-7 R2 und jeder anderen Kontrolle bei, die auf denselben Evaluator verweist. Derselbe Übernahmeanspruch kann in jeder Framework-Sprache ausgedrückt werden, die Ihre Audits jeweils erfordern.
Wie weise ich während eines Audit-Zeitraums die kontinuierliche Abdeckung durch Dispel nach? Führen Sie zu Beginn Ihres Audit-Zeitraums und am Ende eine Bewertung aus und stützen Sie sich dazwischen auf die zugrunde liegenden Nachweisschnappschüsse. Jeder Schnappschuss ist mit einem Zeitstempel versehen, sodass Sie zeigen können, dass Ihr Übernahmeanspruch von Dispel an jedem Tag des Audit-Zeitraums gültig war — nicht nur an dem Tag, an dem die Bewertung erzeugt wurde.
Kann ich mein eigenes internes Kontroll-Framework hinzufügen? Das Importieren eines benutzerdefinierten Katalogs ist in Planung. Heute werden interne Frameworks typischerweise dargestellt, indem die nächstliegende veröffentlichte Basislinie ausgewählt wird (z. B. NIST 800-53 Mäßig) — Dispel erzeugt seine Übernahme-Nachweise in diesem Vokabular, das Ihr GRC-Team dann innerhalb Ihrer unternehmensweiten GRC-Plattform auf das interne Framework umabbilden kann.
--- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation by asking a question. Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters: ``` GET https://docs.dispel.com/documentation/documentation-de/absichern-and-steuern/overview/compliance-and-audit-readiness.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.