To the point
Grundschutz++ expects all documents in native OSCAL format. But do you know whether your ISMS/GRC tool natively supports the OSCAL format? If not: There is an alternative - look at mjEdit.
For those interested
The good news: If usual practice is maintained, you probably have until 2028 to migrate your ISMS to Grundschutz++.
The challenge: Time passes quickly, especially when new tooling is needed, because the manufacturer of your previous GRC tool cannot clearly say when all OSCAL document types will actually be fully supported and the entire process can be mapped consistently.
There are also key migration questions:
- Which content can be reused?
- Which requirements need to be reassessed?
- Where is new content required?
This is exactly where mjEdit can provide support in combination with a RAG AI function: You chat with existing ISMS data, and the AI creates new OSCAL documents via MCP together with mjEdit.
For those who want to know exactly
The OSCAL format is a flexible, schema-based data format. This leads to a central question: Can a database-based GRC tool really represent the advantages of native OSCAL without frictional losses?
OSCAL is a standardized, schema-based exchange format with JSON/XML/YAML semantics as well as official JSON schemas and converters from NIST. This makes JSON the appropriate canonical representation for automated workflows.
Working directly with native OSCAL JSON files reduces conversion losses, simplifies reference resolution, and speeds validation compared to GRC tools that persist internally primarily in SQL. The most important risks lie in the integration effort and the maturity of the existing toolchain. Therefore, standards-compliant validators and resolvers should be integrated early into the creation and editing process.
Comparison table: Native OSCAL JSON vs. GRC tool with SQL backend
| argument | Justification | Impact | Risk | Risk assessment |
|---|---|---|---|---|
| No conversion round trips | Working with native OSCAL files avoids bidirectional mapping logic between OSCAL schema and relational model. | Fewer errors, faster processing, deterministic validation. | Migration effort with existing SQL infrastructure. | High |
| Obtaining OSCAL links and import chains | OSCAL models use imports, href and Back-Matter; Viewers/resolvers expect native OSCAL documents. |
Automatic chain resolution and consistent control display. | GRC tools need to recreate complex resolvers; Inconsistencies are possible. | High |
| Schema-driven validation | NIST provides JSON schemas and CLI tools for validation and conversion. | Early error detection; Audit verifiability. | Missing/outdated schema versions or missing evidence lead to audit deviations. | High |
| Interoperability with OSCAL ecosystem | Many OSCAL tools and libraries expect OSCAL JSON as input/output. | Easier integration with OSS tools, viewers and NIST artifacts. | Vendor lock-in with proprietary GRC APIs remains possible. | Medium |
| Complexity reduction compared to ORM/impedance mismatch | Relational models must represent dynamic and hierarchical OSCAL structures; ORMs can create mapping gaps. | Fewer special cases, lower maintenance costs. | Performance optimizations for queries need to be rethought. | Medium |
| Versioning and reproducibility | OSCAL-JSON is file-based and suitable for VCS, releases and metadata. | Traceable changes, simple audit trail. | Large collections need storage and indexing. | Medium |
| Evidence referencing instead of data storage | OSCAL references documents; it does not replace the source. | Clear separation between metadata and evidence. | Documents must continue to be neatly integrated organizationally. | Low |
Sources for the table:
- How OSCAL Viewer Works
- OSCAL Validation Concepts
- OSCAL CLI Converting Formats
- OSCAL Tools and Resources
- Decoding ORM
- OSCAL Releases- Practical example of OSCAL/GRC
In summary
- Conversion errors occur when relational tables need to cleanly map complex arrays, nested objects or
props/links; This leads to semantic gaps when re-exporting to OSCAL. - Reference resolution (Profile -> Catalog -> SSP chains) is specified in OSCAL; Viewers/resolvers expect original
hrefand back matter structures. - Validation and Tooling: NIST CLI and libraries enable standardized validation and conversion; this reduces audit risks compared to proprietary mappings.
A recommendation
If compliance interoperability, deterministic reference resolution and auditability are priorities, native OSCAL JSON is the better basis - as offered by mjEdit.
mjEdit supports the current OSCAL standard with all relevant document types: from catalog and profile to SSP to AP, AR and POA&M. This means ISB, ISK creators, IT specialists and auditors can work in one consistent tool.
For organizations with existing GRC-SQL infrastructure, a hybrid approach is recommended: OSCAL-native storage for canonical artifacts plus synchronized SQL views for UI and reporting, accompanied by automated validators and resolvers.