mjEdit

FAQ – Häufige Fragen

Antworten auf die häufigsten Fragen rund um mjEdit, OSCAL-Integration, ISMS-Workflows und den Einsatz in der Beratung.

Hier finden Sie Antworten auf die häufigsten Fragen zu mjEdit – von der Namensherkunft über Zielgruppen und Rollen bis hin zu Dokumentenlenkung, KI-Analyse und OSCAL-Formaten.

Allgemeines

Was ist der Einsatzkontext von mjEdit?

mjEdit ist eine spezialisierte Desktop-Anwendung für alle Personen und Organisationen, die täglich mit Informationssicherheits-Managementsystemen (ISMS) arbeiten. Der primäre Einsatzkontext ist die Erstellung, Pflege, Prüfung und Steuerung von ISMS-Dokumentation auf Basis des OSCAL-Standards (Open Security Controls Assessment Language).

Typische Einsatzkontexte sind:

  • Beratungsunternehmen, die für Kunden ISMS-Projekte aufsetzen und betreiben
  • Informationssicherheitsbeauftragte (ISB / CISO), die ihr ISMS täglich steuern und dokumentieren
  • Interne und externe Auditoren, die ISMS-Umsetzungen prüfen und dokumentieren
  • IT-Abteilungen, die als System-Owner die technische Sicherheitsumsetzung dokumentieren
  • Multi-GRC-Umgebungen, in denen mehrere Frameworks (BSI Grundschutz, ISO 27001, NIS2, TISAX, C5) parallel betrieben werden

Was bedeutet der Name „mjEdit"?

mjEdit steht für modularer JSON-Editor. Der Name beschreibt den technischen Kern der Anwendung: ein hochspezialisierter Editor für JSON-Daten, der durch ein Plugin-System modular erweiterbar ist.

In der Praxis ist mjEdit jedoch weit mehr als ein Editor. Es ist ein flexibles Werkzeug, das mit JSON-Daten vielfältige Aufgaben und Anforderungen in unterschiedlichen Anwendungskontexten abdeckt – von der OSCAL-Dokumentation über Compliance-Dashboards bis hin zur KI-gestützten Analyse per MCP-Protokoll.

Was ist die Geschichte von mjEdit?

mjEdit ist aus dem täglichen Arbeitsbedarf der ISMS-Beratung bei Kunden entstanden. In der Praxis fehlte ein geeignetes Werkzeug, um ISMS-Projekte professionell aufzusetzen und zu betreiben – ohne ständig zwischen Word, Excel, PDF-Viewern und verschiedenen Online-Tools wechseln zu müssen.

Das Ergebnis ist eine integrierte Arbeitsumgebung, die genau die Aufgaben abdeckt, die in der täglichen ISMS-Arbeit anfallen: JSON-Bearbeitung, Markdown-Dokumentation, PDF-Annotation, OSCAL-Validierung und KI-Unterstützung – alles in einer einzigen Oberfläche.

Zielgruppen

Wer ist die primäre Zielgruppe von mjEdit mit dem OSCAL-Plugin?

mjEdit mit dem OSCAL-Plugin richtet sich an alle Personen, die täglich im ISMS-Umfeld arbeiten:

Rolle Aufgabenschwerpunkt
ISMS-Ersteller / Berater Erstellt und pflegt Informationssicherheitskonzepte für Kunden; arbeitet täglich mit OSCAL-Katalogen, Profilen und SSPs
Informationssicherheitsbeauftragter (ISB) Begleitet den Fortschritt und die Umsetzung des ISMS aktiv; nutzt mjEdit für Fortschrittscontrolling per Dashboard
Interner Prüfer / Auditor Dokumentiert und prüft die ISMS-Umsetzung; benötigt lückenlose Nachvollziehbarkeit und revisionssichere Dokumentenhistorie
IT-Mitarbeiter / System-Owner Dokumentiert täglich die technische Umsetzung von Sicherheitsmaßnahmen in mjEdit

Welchen Mehrwert hat mjEdit für den ISB?

Der ISB profitiert von mjEdit vor allem durch weniger Suchaufwand, mehr Überblick und revisionssichere Dokumentation:

  • Vorinstallierte Compliance-Kataloge: BSI IT-Grundschutz++ (2.128 Controls), NIST SP 800-53 (468 Controls), C5, BSI 200-x – kein manuelles Abtippen aus PDF-Quellen.
  • OSCAL-Dashboard: Fortschritt bei der Control-Implementierung auf einen Blick – nach System, Framework oder Verantwortlichem gefiltert.
  • POA&M-Tracking: Offene Maßnahmen mit Fristen, Status und Risikobewertung zentral verwaltet.
  • Mapping zwischen Frameworks: C5 ↔ ISO 27001, BSI ↔ NIS2 – Gap-Analyse per Klick statt per Handarbeit.
  • Audit-Vorbereitung: Cross-Reference-Bericht zeigt sofort, welche Controls implementiert, ausstehend oder nicht anwendbar sind.
  • Kein Tool-Wechsel: JSON-Daten, Markdown-Dokumentation, PDF-Prüfung und Browser – alles in einer Oberfläche.

Wie würde ein ISB mit mjEdit arbeiten?

Ein typischer Arbeitstag des ISB mit mjEdit könnte so aussehen:

  1. Morgens: Dashboard öffnen – offene Controls, überfällige Maßnahmen (POA&M) und anstehende Audit-Termine auf einen Blick.
  2. Control-Pflege: Einen neuen System-Owner zum Control OPS.1.1.5.A3 zuweisen und den Implementierungsstand auf „in Umsetzung" setzen.
  3. Risikoarbeit: Im Risiko-Tab eine neu identifizierte Bedrohung anlegen, ihr Maßnahmen zuweisen und den Risikowert berechnen lassen.
  4. Berichtswesen: Aus dem Markdown-Editor einen aktuellen Statusbericht für die Geschäftsführung als PDF exportieren.
  5. Audit-Vorbereitung: Cross-Reference-Bericht erzeugen lassen – fertig für den externen Auditor.

Durch die KI-Integration per MCP kann der ISB Routineaufgaben delegieren: „Erstelle einen Statusbericht über alle offenen POA&M-Einträge mit Frist vor dem 31.08.2026" – die KI erzeugt das Dokument automatisch.

Wie würde ein Berater mit mjEdit arbeiten?

Als ISMS-Berater arbeiten Sie häufig gleichzeitig für mehrere Kunden mit unterschiedlichen Frameworks. mjEdit unterstützt diesen Workflow durch:

  • Multi-Tab-Oberfläche: Paralleles Bearbeiten von Kundendokumenten in mehreren Tabs – SSP Kunde A, Katalog Kunde B, PDF-Dokument Kunde C.
  • OSCAL-Projekt-Struktur: Für jeden Kunden eine eigene OSCAL-Dokumentenkette: Katalog → Profil → SSP → AP → AR → POA&M.
  • Vorlagenbibliothek: Einmal erstellte Baseline-Profile für ISO 27001 oder BSI Grundschutz lassen sich für neue Kunden klonen und anpassen.
  • KI-gestützte Analyse: Per MCP-Protokoll lassen sich Kundendokumente automatisch analysieren, Lücken identifizieren und Maßnahmenvorschläge generieren.
  • PDF-Annotation: Kundenunterlagen direkt in mjEdit annotieren und die Fundstellen als OSCAL-Evidenz referenzieren.

Ein typischer Beratungsworkflow: Kundengespräch → Ergebnisse als Markdown notieren → KI erstellt daraus OSCAL-Maßnahmen → SSP wird direkt aktualisiert → Bericht als PDF für den Kunden.

Benutzerverwaltung & Rollen

Wie ist die Benutzer- und Rechteverwaltung in mjEdit?

mjEdit verfügt über kein rollenbasiertes Rechtekonzept, da es eine lokale Anwendung ist. Diese wird auch in dieser Form nicht benötigt, da jeder Anwender auf den lokalen Daten seines PC oder mit Dateien auf einem Netzlaufwerk arbeitet. Dabei bestimmen dann die Zugriffsrechte des Netzlaufwerks die Sichtbarkeit aller Dateien. Es ist aber sehr sinnvoll, wenn in einem Team arbeitet, das alle Dateien per GIT mit oder ohne zentralen Server verwaltet. So ist dann auch eine Teamarbeit möglich, die dann auch revisionssicher ist.

Grundprinzipien:

  • OSCAL und mjEdit können aber in jedem Dokument in den Metadaten ISMS-Rollen definieren und dokumentieren.
  • ISMS-Rollen lassen sich in den Dokumenten Systeme zuweisen, um Verantwortlichkeiten und Zuständigkeiten zu dokumentieren.
  • Änderungen werden revisionssicher protokolliert – wer hat wann was geändert, wenn man mit Revision speichert.

Wie kann mjEdit das ISMS-Rollenkonzept abbilden?

mjEdit bildet das ISMS-Rollenkonzept direkt als Konten im OSCAL-Tree-View im Knoten: Metadaten ab. Dabei gibt es vordefinierte Rollen, die in den OSCAL-Dokumenten zugewiesen werden können.

Rolle Anwendungsbeispiel
Administrator Vollzugriff auf ein IT-System z. B. Benutzerverwaltung, Konfiguration
ISB / CISO Betreiber vom ISMS, Freigabe, Berichtswesen
Berater ISK-Erstellung in zugewiesenen Projekten
System-Owner Eigentümer von Systemkomponenten, Erstellen von OSCAL-Components-Dateien
Interner Auditor Planen von Assessments, Lesen aller Dokumente, Erstellen von Assessment-Ergebnissen
Externer Auditor Planen von Audits, Prüfen und Bewerten von Evidenzen

Eigene Rollen können in OSCAL-Dokumenten ergänzt werden, um das spezifische Rollenkonzept der Organisation vollständig abzubilden.

OSCAL & Compliance

Wer nutzt in Deutschland schon OSCAL?

OSCAL wird in Deutschland zunehmend von Behörden, Zertifizierungsstellen und Unternehmen eingesetzt, die strukturierte, maschinenlesbare Compliance-Dokumentation benötigen. Bekannte Akteure im deutschsprachigen Raum:

  • BSI (Bundesamt für Sicherheit in der Informationstechnik): Das BSI beobachtet OSCAL aktiv und hat Teile des IT-Grundschutz-Kompendiums bereits als OSCAL-Katalog aufbereitet. mjEdit enthält den BSI IT-Grundschutz++ Katalog als vorinstallierte Datenbasis.
  • Regulierte Industrien: Unternehmen in den Bereichen Energie, Finanzen, Gesundheit und kritische Infrastruktur nutzen OSCAL, um NIS2- und KRITIS- oder ISO 27001-Anforderungen strukturiert zu dokumentieren.
  • NIST-Anwender: Organisationen, die nach NIST SP 800-53 oder CSF arbeiten (z. B. US-Niederlassungen), setzen OSCAL bereits produktiv ein.

OSCAL ist ein wachsender Standard – die Zahl der Anwender in Deutschland steigt mit jedem NIS2- oder BSI Grundschutz++ Umsetzungsprojekt.

Sind ISO 27001, NIS2 und TISAX als OSCAL-Format verfügbar?

Ja – die drei am häufigsten nachgefragten Frameworks sind in mjEdit als OSCAL-Kataloge verfügbar oder können direkt genutzt werden:

Framework Status in mjEdit
ISO/IEC 27001:2022 OSCAL-Katalog verfügbar; Controls als control-Objekte mit Statements (aber ist erst verfügbar wenn der Nachweis einer Lizenzierung vorliegt, bitte kontaktieren Sie uns)
NIS2 (EU-Richtlinie) IN VORBEREITUNG
TISAX (VDA ISA) IN VORBEREITUNG
BSI IT-Grundschutz++ Vorinstalliert, vollständig als OSCAL-Katalog
NIST SP 800-53 Rev. 5 Vorinstalliert, vollständig als OSCAL-Katalog
C5 (BSI Cloud) Vorinstalliert, vollständig als OSCAL-Katalog

Framework-übergreifende Zuordnungsanalysen (z. B. ISO 27001 ↔ NIS2 ↔ BSI Grundschutz) sind direkt über den Mapping-Tab möglich.

Dokumentenhistorie & Lenkung

Wie kann ich sehen, wer und wann welche Änderungen gemacht hat?

mjEdit führt eine revisionssichere Dokumentenhistorie, direkt beim Speichern eines OSCAL-Dokuments. So kann jede Änderung an einem OSCAL-Dokument automatisch protokolliert werden.

Die Historie enthält:

  • Wer hat die Änderung gemacht (Benutzer + Rolle)
  • Wann wurde die Änderung gemacht (Zeitstempel, ISO 8601)
  • Was wurde geändert (Diff auf Feldebene – welcher Wert von was auf was geändert wurde)
  • Warum wurde die Änderung gemacht (optionales Pflichtkommentar bei sicherheitsrelevanten Änderungen)

Die Historie ist im Revisionsknoten direkt einsehbar und kann im Markdown-Bericht exportiert werden.

Wie erfolgt die Dokumentenlenkung in mjEdit? Wie kann ein Auditor diese nachvollziehen?

Die Dokumentenlenkung in mjEdit folgt dem ISMS-Standard für kontrollierte Dokumente:

  1. Versionierung: Jedes OSCAL-Dokument enthält Versionsnummer, last-modified-Zeitstempel und Autor in den Metadaten – OSCAL-konform nach v1.2.2.
  2. Status-Workflow: Dokumente durchlaufen definierte Status: Entwurf → In Prüfung → Freigegeben → Archiviert. Statusübergänge sind rollengebunden (z. B. nur ISB kann freigeben).
  3. Freigabeprozess: Freigaben werden mit Benutzer, Zeitstempel und digitalem Kommentar protokolliert.
  4. Archivierung: Ältere Versionen werden automatisch archiviert und bleiben dauerhaft einsehbar.

Für Auditoren bietet mjEdit einen dedizierten Audit-Export: Ein vollständiger, signierbarer Bericht mit Dokumentenhistorie, Änderungsprotokoll, Status-Timeline und allen Freigaben – als PDF oder strukturiertes OSCAL-AR-Dokument. Der Auditor kann so lückenlos nachvollziehen, wer welche Sicherheitsmaßnahme wann implementiert und freigegeben hat.

KI & Analyse

Wie kann ich als ISMS-Berater mit mjEdit und KI eine Analyse der Kundendokumente erstellen?

mjEdit bietet über das MCP-Protokoll mehr als 100+ Tools an mit einer vollständigen KI-Integration, die die Analyse von Kundendokumenten erheblich beschleunigt. Der typische Analyse-Workflow:

Schritt 1 – Dokumente einlesen: Kundendokumente (PDF, Word-Export, bestehende OSCAL-Dateien) werden in mjEdit geladen. PDFs können direkt annotiert werden; Texte werden per AnythingLLM-RAG in die lokale Wissensbasis aufgenommen.

Schritt 2 – KI-gestützte Analyse: Über einen verbundenen KI-Agenten (AnythingLLM-RAG, Claude Desktop, Cursor, VS Code Copilot) stellen Sie Fragen in natürlicher Sprache:

„Analysiere die Kundendokumente und erstelle eine Gap-Analyse gegenüber ISO 27001:2022. Liste alle Controls, für die noch keine Umsetzungsnachweise vorhanden sind."

Schritt 3 – Automatisierte Auswertung per MCP: Die KI ruft über MCP-Tools wie oscal_compliance_check und oscal_mapping_auto_suggest die passenden Werkzeuge auf und erstellt strukturierte Ergebnisse direkt in mjEdit.

Schritt 4 – Bericht erstellen: Aus den Ergebnissen wird automatisch ein Markdown-Bericht erzeugt, der als PDF für den Kunden exportiert wird. Jede Aussage in der Analyse trägt eine evidence-source-Referenz – nachvollziehbar und zitatfest.

Datenschutz: Alle Analysen laufen lokal (AnythingLLM lokal, MCP-Server lokal) – Kundendaten verlassen die Umgebung nicht.