Grundschutz++ Explained: What the new BSI IT Baseline Protection Framework means for organisations

Where do we stand today? As of July 2026, Grundschutz++ is not yet a fully rolled-out successor to the existing IT Baseline Protection methodology. Instead, it is an applicable pilot version that the BSI is testing together with pilot partners.

Nevertheless, the topic remains highly relevant because the direction is clear: IT Baseline Protection is becoming more digital, process-oriented, and structured in a way that allows tools to process its content directly. For companies and public sector organizations, now is therefore the time for preparation and strategic alignment to avoid poor investments, duplicated effort and resource bottlenecks.

Grundschutz++ is a comprehensive modernisation of the BSI IT Baseline Protection framework. Requirements are provided through the State-of-the-Art Library as machine-readable OSCAL data in JSON format. According to the current BSI status, the framework consists of 19 practices and 921 requirements. The pilot phase runs until 30 September 2026, while publication of the methodology is planned for it-sa 2026 from 27 to 29 October. ISO 27001 certification applications based on Grundschutz++ are expected to be possible from 1 January 2027 onwards.

Grundschutz++ is neither a new law nor an additional compliance framework that companies and public sector organizations must implement alongside ISO 27001, NIS2 and DORA. It is a reform of the BSI methodology used by organizations to establish, operate and demonstrate an Information Security Management System.

The existing IT Baseline Protection methodology is characterized by extensive standards and methodology documents, requirement catalogues, implementation guidance and periodic editions. Grundschutz++ shifts the focus towards a process-oriented methodology and a structured data foundation. The BSI's objective is to modernize content and reduce effort within the ISMS, particularly where processes can be automated or data can be reused multiple times. [1][2]

The key change is therefore not “fewer controls” but more manageable controls. The expression ‘controls’ originates from the OSCAL data model, where individual requirements are represented as controls. This refers to the familiar baseline protection requirements, not an additional layer of controls. Requirements are intended to be clearly structured, version-controlled, filterable, and reusable within tools.

This creates opportunities for more data-driven security management through dashboards for implementation status, notifications of catalogue changes or metrics derived from linked evidence. However, it does not remove the organization’s responsibility for decisions, risks, implementation measures or effectiveness reviews.

Strategically, Grundschutz++ also gains importance through NIS2. Essential and important entities must implement appropriate measures that take the state of the art into account. The State-of-the-Art Library makes BSI security requirements available in a machine-readable format and therefore provides valuable guidance. Whether an organisation is affected and which measures are appropriate in a specific context must still be assessed independently.[3][6][7]

OSCAL stands for Open Security Controls Assessment Language. This open data model describes security requirements and related information in a machine-readable format. The BSI publishes its digitally structured security requirements through the State-of-the-Art Library, where the Grundschutz++ user catalogue is available as a JSON file.[2][3]

For practitioners, five effects are particularly relevant:

1. Changes become technically comparable: Instead of manually comparing two PDF versions, tools can analyze versions and deltas.
2. Content can be maintained continuously: Changes remain linked to a specific catalogue version and therefore remain traceable.
3. Catalogues become official data sources within tools:Supported ISMS and GRC platforms can import the original version-controlled catalogue rather than transferring content into proprietary formats.
4. Profiles can be tailored more precisely: A profile is a filtered, organization-specific package of requirements. Organizations adopt the content relevant to their context and process it further.
5. Evidence can be linked more systematically: A ticket can document implementation of a requirement, a metric can demonstrate effectiveness, and a policy can provide organizational evidence. Integrated platforms can support assessments through these linked sources.

This creates the foundation for “Compliance as Code”, if processes, data and evidence are integrated properly. A JSON file on its own does not make an organization compliant.

The current pilot catalogue organizes its content into 19 practices. The BSI differentiates between organizational, technical and overarching ISMS practices. The methodology is therefore aligned more closely with the activities that organizations must perform continuously, ranging from governance and structural modelling to detection, response and continuous improvement in a threat landscape increasingly shaped by the use of AI in cybercrime. [4]

The five ISMS practices form the governance cycle:

• GC – Governance and Compliance: Establish objectives, framework conditions and obligations.
• STM – Structural Modelling: Capture the information domain and derive an appropriate package of requirements.
• UMS – Implementation: Plan, implement and document security measures.
• PERF – Monitoring and Evaluation: Assess effectiveness, progress and suitability.
• VRB – Improvement: Address deviations and continuously develop the ISMS further.

These are complemented by seven organizational and seven technical practices. The purpose of this structure is to align recurring security activities more closely with responsibilities and operational processes. For organizations, this means that future mapping exercises should not only ask, “Which legacy module corresponds to which new entry?”, but also, “Which process provides the evidence, who owns it and from which system does the data originate?”

According to the BSI, the existing protection levels of Basic, Standard and High Protection Requirements are expected to be replaced by flexible performance metrics with dynamic thresholds. In addition, prioritization and weighting of requirements are intended to support implementation planning. Exactly how these performance metrics will be calculated has not yet been finalized in the pilot version. [1]

A low-threshold entry point is provided by the WiBA checklists (Path to Basic Protection), which are intended to become a permanent component of Grundschutz++. They are based on the machine-readable user catalogue. In the future, requirements should be filtered according to the relevant use case, based on target object categories and institutional context. This enables smaller organizations to implement fundamental security requirements without first establishing a complete ISMS. The BSI continues to refine the exact generation rules as part of the ongoing development process.

The official roadmap distinguishes between piloting, evaluation, publication and certifiability.

• 1 April 2026: Start of the pilot phase with an applicable version of the methodology.
• 30 September 2026: End of the pilot phase; feedback will be incorporated into further development.
• 27–29 October 2026: Planned publication of the methodology at it-sa 2026.
• 1 January 2027: Grundschutz++ is expected to become certifiable; according to the BSI, ISO 27001 certification applications based on Grundschutz++ can be submitted from this date onward.

For organizational planning: 2026 is the year for preparation and limited piloting. Organizations can already align data structures, roles, tools and processes. However, they should avoid anticipating methodological details that will only be finalized by the BSI after the pilot phase.

The same applies to existing certificates. The current BSI roadmap does not indicate an immediate discontinuation of the 2023 edition, nor does it define a binding end date for the transition phase. Organizations planning a recertification in 2026 or 2027 should therefore align their planning with both their certification body and the latest BSI guidance.

An established ISMS does not become obsolete because of Grundschutz++. Quite the opposite. Organizations that have already structured their scope, asset and risk ownership, policies, measures, audit processes and evidence management effectively already possess the most important foundational information

The following elements can typically be reused:

• The defined ISMS scope
• The inventory of information assets, processes, applications, infrastructure and service providers
• Roles and approval workflows
• Risk and exception management procedures
• Implementation plans, findings and remediation tracking
• Technical and organisational evidence

What does need to be reconsidered is the underlying data and process logic. Documents should no longer be viewed purely as finished files. What matters is whether an organization can properly manage and relate information: Which requirement applies in which context? Who is responsible? What demonstrates implementation? When was evidence last reviewed? Which catalogue change affects us?

Grundschutz++ can support a more consistent organization of evidence and regulatory requirements. The planned certification remains an ISO 27001 certification based on IT Baseline Protection. It does not replace NIS2 applicability assessments or the independent evaluation of other regulatory obligations.

Verify that your structural data reflects today’s reality, including cloud and SaaS services, outsourced operations, interfaces, user accounts and permissions. Also document data flows and critical dependencies. An outdated asset inventory will not improve simply because OSCAL is introduced.

Assign owners not only for assets but also for risks, security processes and evidence. A requirement only becomes manageable when it is clear who decides, who implements and who validates effectiveness.

Create an evidence inventory. Map policies, tickets, logs, technical metrics and audit reports to relevant requirements. Track version, validity, source and review date. This is already worthwhile regardless of the final Grundschutz++ specification.

Ask vendors specifically about OSCAL import and export functionality, version comparison, profile creation, parameterisation, API integration and complete audit trails. Request demonstrations of actual product capabilities and export options. Avoid solutions that store data exclusively in proprietary formats and unnecessarily complicate future migrations.

Start with a manageable but meaningful area, such as a cloud service, a critical business process or a clearly defined platform. Map existing controls and evidence to the pilot catalogue. Document not only control gaps but also issues involving data, ownership and tooling. Only then can the effort required for a broader migration be estimated realistically.

Grundschutz++ is often presented primarily as a tooling topic. That view is too narrow, but tool selection can either significantly simplify or permanently hinder the transition. At a minimum, organizations should be able to answer the following questions:

• Can the platform natively import and export OSCAL JSON??
• Can catalogue versions and changes be compared transparently?
• Can profiles, parameters and organization-specific additions be managed separately?
• Can evidence from ticketing systems, cloud platforms, IAM, vulnerability management and SIEM solutions be connected?
• Are decisions, exceptions, approvals and review histories retained in an audit-proof manner?
• Is it possible to change platforms without rebuilding the entire control and evidence model?

This list is not exhaustive, but it provides a solid starting point before evaluating the full functionality and additional selection criteria of a GRC or ISMS platform.

Grundschutz++ has the potential to resolve several long-standing challenges within the traditional methodology. The State-of-the-Art Library and OSCAL create a foundation for processing security requirements more quickly, identifying changes more efficiently and organizing evidence more consistently.

The transition is not automatic. It shifts effort away from redundant document maintenance and towards structured data management, clear accountability, integration-ready tooling and verifiable effectiveness.

The practical approach is therefore clear: organize the fundamentals, select a pilot area, monitor BSI developments and reassess after the pilot phase. This ensures that Grundschutz++ becomes the logical evolution of a functioning ISMS rather than the next compliance project lost in a big-bang migration.

We assess your scope, roles, evidence model and tooling landscape and develop a robust readiness and migration roadmap aligned with ISO 27001, IT Baseline Protection and your regulatory requirements.

Sources:

_[1] BSI: Grundschutz++ – Milestones and Current Status

_[2] BSI: Pilot Implementation of Grundschutz++ in the User Catalog

_[3] BSI: State-of-the-Art Library

_[4] BSI: Grundschutz++ User Catalog, OSCAL/JSON, as of June 24, 2026

_[5] BSI: IT-Grundschutz++ – Current Scope of the Digital Catalog

_[6] BSI: State of the Art – Mission and Library

_[7] BSI: Questions and Answers on NIS2