Grundschutz++ from 2027: certifiable, but how mature?

Grundschutz++ becomes certifiable on 1 January 2027, as officially set out by the BSI. The methodology deliberately breaks with the prescriptive module catalogue of the classic IT-Grundschutz and moves closer to international standards. Central building blocks such as the risk assessment are still being developed.

Quotations from BSI documents in this article are translated from the German originals.

What is Grundschutz++ and when does it become certifiable?

Grundschutz++ is the newly developed, fully process-oriented ISMS methodology from the BSI, structured along the PDCA cycle. It is piloted from April to September 2026, published on 27 October 2026 at the it-sa in Nuremberg, and becomes certifiable on 1 January 2027 (ISO 27001 on the basis of Grundschutz++). It is currently in the "introduction and trial phase" (methodology guide, March 2026).

According to the BSI's own "Leitfaden zur Methodik Grundschutz++" (version March 2026), Grundschutz++ is "a consistent step in the evolution of the BSI's IT-Grundschutz in response to the changing information security landscape". The methodology was developed on the basis of "extensive practical experience and the feedback of numerous users".

The security process runs in five process steps along the PDCA cycle:

• Survey and planning (Plan)
• Requirements analysis (Plan)
• Implementation (Do)
• Monitoring (Check)
• Continual improvement (Act)

Each process step is assigned to one of three practice groups: ISMS practices, organisational practices and technical practices, 19 practices in total, presented in the BSI guide as a practices wheel.

The timeline is set out on the official BSI page on Grundschutz++: the pilot phase runs from 1 April to 30 September 2026 with "piloting partners from public administration and from private industry", publication follows on 27 October 2026 at the it-sa. The BSI states plainly: "Der GS++ ist zertifizierbar." From that date, applications for certification to ISO 27001 on the basis of GS++ can be submitted.

Compared with the previous IT-Grundschutz compendium, Grundschutz++ is considerably leaner: according to several consistent trade publications, the number of sub-requirements drops from 6,567 to 985 requirements, a reduction of roughly 85 percent, structured into the 19 process-oriented practices. These figures come from the trade press, not from the BSI page itself.

For the transition, current industry assessment holds that the previous IT-Grundschutz remains valid until the end of 2028, and existing certifications can be migrated to Grundschutz++ until 2029.

What changes methodologically compared with the classic IT-Grundschutz?

Grundschutz++ replaces the three rigid protection paths (Basis-, Standard- and Kern-Absicherung) with a single, process-oriented approach along the five PDCA process steps. Instead of adopting predefined modules one to one, the institution models requirements onto its own assets via target object categories. That shifts responsibility from the specification to the institution's own work.

The classic IT-Grundschutz rests on four BSI standards (200-1 to 200-4) and roughly 110 modules across ten layers in the 6th edition from 2023. Institutions chose one of three protection paths from it: basic, standard or core protection, depending on protection needs and resources. Some of these modules already cover requirements from the NIS2 environment today.

Grundschutz++ dissolves that choice. In its place comes a continuous five-step security process organised in the PDCA cycle: survey and planning, requirements analysis, implementation, monitoring and continual improvement.

The central methodological break lies in how requirements are assigned. Instead of adopting ready-made modules wholesale, Grundschutz++ demands asset modelling on the basis of target object categories: 31 target object categories, organised into 6 root nodes and 4 hierarchy levels, as the BSI methodology PDF sets out in figure 6. Requirements are inherited along this hierarchy rather than assigned on purely technical grounds.

The methodology PDF puts it this way: "The assignment is function-oriented, not only according to technical characteristics. What matters is how the asset acts within the business process."

This comes with greater methodological freedom inside a defined frame. On risk assessment it states: "Within this frame, the method for risk assessment can be chosen freely, provided it meets the requirements of the separate document on risk assessment." The classic Grundschutz prescribed a fixed risk analysis methodology through BSI Standard 200-3; that obligation falls away.

This positions itself as a deliberate move towards international standards: the process steps are considered ISO 27001-compatible, but deliberately go beyond it in depth of detail and process orientation. Whether the known fit with NIS2 also continues, which in the classic Grundschutz already covers roughly 80 percent of the requirements from § 30 BSIG, is not evidenced in the BSI primary sources on Grundschutz++. Given the closer proximity to ISO 27001, however, it seems plausible that this effect could carry over.

Where is Grundschutz++ not yet mature, particularly in risk assessment?

For risk assessment, the methodology guide refers to a separate document meant to set binding requirements for the risk methodology. As of March 2026 that document does not exist; the guide only lays it out as a future reference. As an institution you currently do not know which concrete risk model to follow.

The guide itself states the frame clearly. In chapter 2.10, "Initiierung des Risikomanagements", it reads: "In a separate document on risk assessment, binding requirements for the risk methodology are prescribed. The requirements are structured according to common risk management processes."

And further: "Within this frame, the method for risk assessment can be chosen freely, provided it meets the requirements of the separate document on risk assessment."

Chapter 3.8, "Durchführung der Risikobetrachtung", states similarly: "At this point the Methodik-GS++ provides for the transition into a separate risk assessment, insofar as this was explicitly required in the corresponding paragraphs of this document. The risk assessment uses the defined information and proceeds according to the requirements of the separate document on risk assessment."

In several places, then, a separate document on risk assessment is announced as a binding reference, yet it does not exist and is nowhere given substance in the PDF. For your planning today: the frame is laid out conceptually, the question of what to orient yourself towards is not yet answered.

That fits the general early stage that Grundschutz++ says it is in: the guide describes the methodology itself as being in the "introduction and trial phase". As a target frame, the trade press names only "by 2028" for a "robust, practical and certifiable framework".

For comparison: BSI Standard 200-3, the risk analysis procedure of the classic Grundschutz, has worked for years with fully articulated elementary threats and is correspondingly well practised. That texture is still missing from the Grundschutz++ risk assessment at this stage, because it was deliberately moved into a document that is not yet available.

A similar gap affects anyone already certified under the classic scheme who wants to migrate: the methodology PDF announces "migration guides" but, as with the risk assessment document, these are not yet available. Whether an existing certification is credited or a full reassessment under the Grundschutz++ logic is required cannot be answered from the available sources until those guides appear.

What does the machine-readable foundation of Grundschutz++ mean in practice?

For its technical extension, Grundschutz++ uses OSCAL (Open Security Controls Assessment Language), an open, machine-readable format for security requirements. The Grundschutz++ requirements catalogue is additionally made available under version control through the GitHub repository "Stand-der-Technik-Bibliothek" rather than appearing only as a PDF. This turns a rigid document into a structured, machine-processable data basis for tools and automation.

In the BSI's own methodology guide, this question of format appears concretely in only one place. Chapter 1.3, "Konzeptstruktur", records that "the technical layer will explain concrete information on handling requirement packages on the basis of the techniques available in OSCAL". Everything else in the guide stays with the description of processes and structures, without naming a data format.

External trade publications confirm the OSCAL connection independently of the BSI source: it turns rigid documents into processable data structures and thereby enables automation and tool support. JSON is named as the primary format, provided through the GitHub repository "Stand-der-Technik-Bibliothek", which the methodology PDF itself references.

OSCAL is not a BSI format but an open standard from the US National Institute of Standards and Technology (NIST) for representing security catalogues, controls and assessment results in machine-readable form. The BSI builds the Grundschutz++ requirements on it instead of developing a proprietary format, a step towards international, community-supported standards.

That has practical consequences too: because the requirements exist in structured form rather than as running text, Grundschutz++ can be integrated into external tools without friction, KaitoSec among them.

Why is the technology not the actual core of the change?

OSCAL is only the technical implementation. The real shift is a layer model in which the base version is extended by additional, community-supported layers such as a technical layer, an example layer and a planned audit layer. Tools and the professional community are meant to be able to dock directly onto this second level instead of merely consuming Grundschutz.

The BSI describes this concept in chapter 1.3, "Konzeptstruktur", of the methodology PDF as follows: "This base document can be used in combination with further layers [...], which are to be seen as a supplement to individual partial aspects of the base version. Each layer considers one very specific aspect of the extension."

Named concretely are the technical layer with OSCAL techniques and blueprints, and the example layer, which per the methodology PDF annotates passages of the base version with explanations and examples. As planned but not elaborated, the document names: "In addition, further layers, for example an audit layer, are envisaged."

This too points to the maturity of the methodology: as with the risk assessment, the audit layer has so far only been announced, not elaborated, a sign that despite certifiability from 2027, Grundschutz++ is still under active development in places.

That this model is not a purely technical detail shows in the authorship of the base document. The change history of the methodology PDF names not the BSI alone but BSI and the SdT community (Stand-der-Technik community). Independent trade publications confirm this, describing planned thematic layers (for example on technology, audits and risk assessment) and close involvement of pilot projects and the professional community. The reference to a possible risk assessment layer suggests that the risk methodology is one of the areas still to emerge within the layer model.

How practical collaboration is organised is shown by the reference to a GitHub repository named Stand-der-Technik-Bibliothek: development proceeds agilely via GitHub, with issues, pull requests and discussions.

OSCAL makes the requirements technically readable, the layer model makes them organisationally extensible. Only the combination allows tool vendors, consultants and individual institutions to contribute or use their own layers without changing the base version itself. That is the structural break with the previous Grundschutz compendium, published by the BSI alone.

What does this mean now for institutions preparing themselves?

If you already use the classic IT-Grundschutz, you can build on it until the end of 2028 and observe the 2026 pilot phase rather than migrating immediately. If you are starting fresh, you should plan the five process steps and the asset modelling principle of Grundschutz++ as your target picture, but align the risk methodology conservatively with BSI Standard 200-3 or ISO 27005 for the time being, until the separate risk assessment document is available.

This assessment comes from the editorial team, not from the BSI itself, and is a starting point for your own planning.

Concretely, for different starting positions:

• If you already use the classic Grundschutz: you have until the end of 2028 before the old standard expires, and until 2029 for the certification transition. Use that lead time instead of switching in haste, and observe the pilot phase in parallel.
• If you do not yet have an ISMS: the process structure of Grundschutz++ with its five steps, the PDCA cycle and asset modelling instead of a module catalogue is already worth using as a blueprint. It sits closer to ISO 27001 than the classic Grundschutz and is therefore doubly usable. See the framework overview.
• For risk assessment specifically: until the separate document on risk assessment is available, the methodology PDF refers only to "common risk management processes" as a structural specification. In practice, use established methods such as BSI Standard 200-3 or ISO/IEC 27005 as an interim solution and watch for updates from the BSI.
• Watch point, pilot phase: the pilot phase from 1 April to 30 September 2026 with partners from administration and industry is the next concrete milestone. It will show whether open points, the risk assessment above all, are closed by the planned publication in October 2026.

KaitoSec already maps BSI Grundschutz++ as one of several cross-mapping frameworks alongside ISO 27001, NIS2, DORA and GDPR, together with ISMS, BCMS and further management systems on a relational data model. If you carry ISO 27001 or NIS2 obligations alongside Grundschutz++, a typical case of multi-complex regulation, then in such an agentic workspace one control is maintained once rather than four times, regardless of which framework develops next. What that costs in concrete terms for a certification is broken down in our article on ISO 27001 certification costs.

Frequently asked questions about Grundschutz++

Is Grundschutz++ already certifiable today? No, not yet. The pilot phase runs from April to September 2026, publication follows on 27 October 2026 at the it-sa in Nuremberg. According to the BSI, the methodology becomes certifiable to ISO 27001 on the basis of Grundschutz++ only from 1 January 2027. Before that, only the classic IT-Grundschutz can be certified.

Do I have to migrate my existing IT-Grundschutz to Grundschutz++ now? Not immediately. According to current industry assessment, the classic IT-Grundschutz remains valid until the end of 2028, and a certification transition to Grundschutz++ is possible until 2029. Anyone already certified therefore has several years of lead time to observe the new methodology rather than switching in haste.

What is OSCAL and why does Grundschutz++ use it? OSCAL (Open Security Controls Assessment Language) is an open, machine-readable format for security requirements. According to the BSI methodology guide, Grundschutz++ builds its technical extension layer on OSCAL in order to provide requirement packages in automated form rather than as a rigid PDF document. That is the technical basis, not the actual core of the change.

How is risk assessment currently regulated under Grundschutz++? The methodology guide refers to a separate document on risk assessment that is meant to set binding requirements for the risk methodology. Within that frame, the concrete method can be chosen freely. As of March 2026, however, this document is not yet available in elaborated form, which leaves the concrete orientation for institutions currently underspecified.

What distinguishes Grundschutz++ most strongly from the classic IT-Grundschutz in methodological terms? Grundschutz++ replaces the three protection paths basic, standard and core with a single, process-oriented sequence using asset modelling on target object categories instead of rigid module assignment. Requirements are inherited function-oriented rather than assigned on purely technical grounds. That shifts responsibility further towards the institution and moves the methodology closer to international standards such as ISO 27001.