What Is OSCAL? A Deep Dive Into Compliance as Code and BSI Grundschutz++

As of January 1, 2026, the German Federal Office for Information Security (BSI) has replaced the classic IT-Grundschutz with Grundschutz++. This was no version bump. It is the deepest methodological break in the agency's history. At the heart of that break sits an internationally developed data standard most mid-market companies have never heard of: OSCAL.

Four months after the cutover, one thing is clear: companies still maintaining their ISMS in Word and Excel either took the migration as a shock or are stuck mid-transition. Understanding how OSCAL works and why the BSI bet on it lets you close the gap in an orderly way and slash compliance overhead. This article is the deep dive for executives, CISOs and IT leads who need to catch up.

Why manual compliance no longer works

The regulatory landscape has changed fundamentally over the last two years. NIS2, the EU AI Act, GDPR, TISAX and DORA overlap, often in the same company. A Tier-1 automotive supplier that also sells SaaS to banks juggles at least four frameworks in parallel.

The traditional approach of mapping each norm into separate Word documents and Excel sheets collapses under that load. Three signals:

First, the hidden cost of manual compliance. Highly qualified security staff spend 60 to 80 percent of their time on document upkeep instead of real risk analysis. Each new framework adds 200 to 400 hours of initial effort that doesn't compound when you go for the next audit, because there is no technical link between the documents.

Second, the NIS2 reporting deadline. The 72-hour window for significant incidents cannot be hit with email chains and spreadsheets. If you have to compile evidence under the pressure of an active attack, you'll miss the deadline and face fines.

Third, the audit trap. External auditors ask the same questions every year. The company digs out the same evidence every year. There is no technical mechanism to reuse a single piece of evidence across multiple frameworks.

This is exactly the gap OSCAL closes.

What is OSCAL, exactly?

OSCAL stands for Open Security Controls Assessment Language. It is an open, machine-readable data standard developed by the US National Institute of Standards and Technology (NIST) together with FedRAMP.

The core idea is simple. Instead of maintaining security controls as prose in PDFs and tables, you describe them as structured data. OSCAL supports JSON (web APIs and SaaS platforms), XML (hierarchical structures) and YAML (human-readable, ideal for configuration management).

The decisive difference from the document world: every control, profile and asset gets a universally unique identifier (UUID). Controls can be referenced, compared and mapped across frameworks precisely, without copy-and-paste errors or version conflicts.

OSCAL lays the technical foundation for policy as code. The requirement "passwords must be at least twelve characters long" no longer lives only as a sentence in a policy document. It becomes a machine-readable parameter that a configuration scanner checks continuously against the reality of your IT infrastructure.

The five layers of OSCAL

OSCAL's strength lies in its layered architecture. Instead of a flat data model, it cleanly separates abstract norm from concrete implementation. That makes the model maintainable and automatable.

Layer	Model	Function
Control Layer	Catalog	The immutable base. Holds the raw controls of a norm such as ISO 27001, NIST SP 800-53 or BSI Grundschutz. Controls are parameterized (e.g. password length, retention periods) and tagged with metadata.
Profile Layer	Profile	Tailors generic controls for a specific use case. A profile selects controls, removes inapplicable ones, adds custom ones and sets parameters. Examples: "FedRAMP Moderate Baseline" or a BSI profile for critical infrastructure.
Implementation Layer	System Security Plan (SSP) and Component Definition	Describes the concrete implementation in your IT landscape. Component definitions are reusable building blocks (firewall, cloud service, identity provider). The SSP aggregates them into a system inventory with responsibilities and evidence references.
Assessment Layer	Assessment Plan (AP) and Assessment Results (AR)	Plans and records audits. The AP defines tasks, auditor roles and methods. The AR stores findings as compliant or non-compliant, references evidence and enables continuous monitoring.
Remediation Layer	Plan of Action and Milestones (POA&M)	Tracks the remediation of findings. Tasks with deadlines, owners and status. Linked directly to SSP and AR. Closes the risk-management loop.

The real lever is data inheritance. When the BSI publishes a new version of a practices catalog, you import only the updated OSCAL profile into your GRC platform. The software calculates which gaps emerge against your current implementation and creates the new tasks in the POA&M. What used to be a multi-month gap analysis runs in minutes.

BSI Grundschutz++: breaking with three decades of PDF tradition

In parallel with OSCAL's international rise, the BSI executed the most radical methodology shift in its history. The classic IT-Grundschutz, the de-facto standard for public sector and critical infrastructure for decades, was replaced by Grundschutz++ on January 1, 2026. The roadmap was finalized at it-sa 2024.

Four structural innovations distinguish Grundschutz++ from its predecessor:

Practices instead of building blocks. The rigid, predefined building blocks (e.g. APP.1.2 Web Browser) disappear. Thematic practices take their place: identity and access management, patch management, crisis management. Concrete requirements are derived from these practices contextually, drastically reducing redundancy.

Target object categories with inheritance. Assets are assigned to categories (server, cloud service, mobile device, building). Security requirements are formulated at category level. Individual assets inherit them automatically. If you introduce a new server model, you document it once at category level, not per asset.

Governance shift to risk owners. Information security is explicitly a leadership task in Grundschutz++. Responsibility for business-process risks no longer sits with IT but with the risk owners in the business units. Whoever runs sales is accountable for CRM data security. Whoever runs production is accountable for OT protection levels.

Open development with a state-of-the-art library. The BSI opens its development process to the professional community for the first time. The digital state-of-the-art library lets new measures emerge iteratively before they become official standards. The library is not a text archive but a structured data space queryable via APIs.

The PDCA cycle in Grundschutz++

Methodologically, Grundschutz++ follows the classic Plan-Do-Check-Act. New is the clean separation into five process steps that are coupled much more tightly to the OSCAL data structure than the predecessor.

Phase	Step	Content
Plan	1. Survey and planning	Capture organizational context, draft security policy, define scope, assign risk owners. Prevents scope creep, anchors security in business goals.
Plan	2. Requirements analysis	Delineate the information network, sort assets into target object categories, derive requirements from practices. Turns abstract threats into a parameterized requirement package.
Do	3. Realization	Capture current state, identify gaps, build implementation plan with deadlines, formally approve exceptions, ensure tracking.
Check	4. Monitoring	Verify effectiveness, run internal and external audits, prepare management review, validate automatically whether the requirement package still fits.
Act	5. Continuous improvement	Handle non-conformities, plan corrections, verify effectiveness, feed improvements back into the next cycle as parameters.

The central concept is Continuous ISMS. Every change in business processes, regulation or IT landscape immediately ripples through the requirement package. Updates are no longer cyclical exceptions before the audit. They become normal day-to-day operations.

The symbiosis: OSCAL as the engine of Grundschutz++

This is where the BSI's most strategic decision shows up. While every previous iteration of IT-Grundschutz shipped as hundreds of pages of PDFs, Grundschutz++ uses OSCAL as its native data core:

• The requirements layer is mapped via OSCAL Catalog and Profile.
• The implementation layer via Component Definitions and the System Security Plan.
• The assessment layer via Assessment Plans and Assessment Results.

The strategic implication is epochal. The state-of-the-art library becomes a structured, API-queryable data space that also takes in user-generated catalogs and AI-supported measure suggestions. Instead of downloading PDF updates, GRC platforms subscribe to the current BSI profile as a data stream.

What changes for IT administrators

Concrete examples from daily operations:

Configuration checks become automatic. Whether encryption algorithms match current state of the art, or whether patches were applied on time, is no longer asked via Excel checklist. Tools read the status from target systems via API and feed it directly into the OSCAL Assessment Results layer.

Findings generate tasks automatically. When a server is flagged non-compliant, the system generates an assignable task in the POA&M in the same moment. The responsible risk owner gets the escalation through workflow, not email forwarding.

Open-source profiles accelerate adoption. Initiatives like the ComplianceAsCode project on GitHub already provide profiles that automatically check Linux distributions, cloud configurations and databases for BSI conformity. Vendors like NTT Data show with their "BSI Grundschutz Edition 2023 Converter" how historical PDF modules can be transformed into OSCAL-compliant JSON catalogs through AI-driven pipelines.

Cross-framework mapping: one input, four frameworks

The strength of OSCAL's machine-readable architecture pays off fully when your company runs more than one framework. Almost every mid-market company that needs TISAX has parallel ISO 27001 demand from large customers, NIS2 obligations from critical infrastructure exposure and, going forward, Grundschutz++ requirements from public sector clients.

Worked in silos, the effort multiplies. OSCAL turns cross-walking into routine. A technical measure, marked once as implemented in the component definition, covers requirements across multiple frameworks simultaneously.

Example: multi-factor authentication for cloud services.

Framework	Requirement
ISO 27001:2022	A.5.16, A.5.17, A.8.5
NIS2	Art. 21(2)(d) identity management
BSI Grundschutz++	Practice "identity and access management"
TISAX 6.0	Control 4.x
DORA	Art. 9 ICT risk management

In the traditional world: five separate control proofs, five audit reports, five evidence collections. With OSCAL: one component definition, five automatic mappings, one findings report. The synergies between ISO 27001 and TISAX cut TISAX Level 3 implementation effort by 20 to 30 percent if a conformant ISMS exists. With Grundschutz++, this lever becomes a default feature.

NIS2 in practice: why OSCAL becomes a survival question

The sharpest example of the economic necessity of this transformation is the NIS2 reporting obligation. Affected companies must report significant incidents within 24 hours as an early warning and within 72 hours as a detailed report to the responsible authority.

If you log incidents in Excel, you cannot meet that deadline under the stress of an active cyberattack. In integrated platforms, the workflow runs natively:

1. A monitoring system detects an incident and triggers an automated workflow.
2. The system notifies the risk owners stored in the OSCAL SSP.
3. Immediate measures are delegated and tracked through the POA&M model.
4. Evidence for the authority report is aggregated and prepared automatically.

The NIS2 obligation for SMBs and suppliers is therefore not just a legal hurdle. It is probably the strongest driver of machine-readable compliance architectures in the German mid-market.

What this means for SMBs: ROI and tool selection

The investment in an OSCAL-native ISMS pays back on two paths: efficiency gains in daily operations and radically shorter audit cycles.

Implementation costs. A classic ISO 27001 implementation costs 25,000 to 250,000 euros initially with 6 to 18 months lead time. Documented ROI rates reach up to 440 percent through risk reduction and audit acceleration. With OSCAL-native platforms, the share between tool cost and consulting cost shifts heavily toward the tool, which lowers total cost.

Platform cost comparison. Global vendors like Vanta charge mid-market companies 14,000 to 23,000 euros per year for a single framework. Each additional framework costs extra. Audits not included. Modular European vendors like Kopexa start at 249 euros per month in the Lite tier with three users. The Pro plan from 599 euros per month includes unlimited frameworks, OSCAL support, vendor and asset management. Full breakdown on the pricing page and in the comparison of compliance software cost for SMBs.

Selection criteria for 2026. Three non-negotiable criteria for tool selection:

• Native OSCAL support in JSON, XML and YAML. Tools that import catalogs only as PDF are not future-proof from 2026.
• Cross-framework mapping engine with documented mappings between ISO 27001, NIS2, TISAX, DORA and Grundschutz++.
• Automated incident workflow with defined NIS2 escalation chain and authority reporting.

Strategic recommendations for 2026

Three time-critical recommendations for executive leadership and CISOs:

1. Finish the migration to Grundschutz++. Grundschutz++ has been mandatory since January 1, 2026. If you haven't migrated yet, start by cleaning up your asset management. A clean asset inventory is the only solid foundation for the new logic of target object categories and practices.

2. Investment in OSCAL-native, modular GRC platforms. Manual mapping across multiple frameworks is no longer defensible. Modular architectures let you start with one framework and grow organically without being trapped in rigid licensing.

3. Governance transformation toward risk ownership. Leaving security alone with IT is no longer an option under NIS2 and Grundschutz++. Define risk owners in every business unit and give them real-time dashboards that reflect their accountability. That is not just compliance. That is real risk management.

Bottom line: compliance as code is no longer a buzzword

The shift from document-driven to data-driven compliance is no longer theoretical. With OSCAL, a globally established data standard exists. With Grundschutz++, the BSI makes it the national default. With NIS2, the speed OSCAL enables becomes a legal necessity.

Anyone still running their ISMS in Excel in mid-2026 risks more than audit findings. They lose the ability to absorb new regulatory requirements in any reasonable time. Anyone migrating now to OSCAL-native platforms turns rising regulatory pressure into a strategic advantage.

If you want to see how OSCAL frameworks and a Grundschutz++ migration map to Kopexa concretely, book a demo or explore the framework catalog yourself.