Grundschutz++

BSI 300-1 vs. 200-1: What Grundschutz++ Changes

BSI Standard 300-1 puts the Grundschutz++ methodology into five process steps. What changes from 200-1, 200-2 and 200-3, and why OSCAL matters.

By KaitoSec Team · Published 27 October 2026 · 10 min read

BSI Standard 300-1, “Methodik Grundschutz++”, version 1.0 dated 20 October 2026 and presented at it-sa on 27 October, describes across 42 pages how to establish and operate an ISMS in five process steps. It brings together what used to be spread across 200-1, 200-2 and 200-3. The security requirements are not in the PDF: they are published as a machine-readable OSCAL catalogue on GitHub. Requirements, mappings and catalogue updates become data.

For background on Grundschutz++ and the planned transition, see the KaitoSec overview of Grundschutz++. This article covers what 300-1 now puts on the table.

What does BSI Standard 300-1 cover?

BSI Standard 300-1 sets out the methodology of Grundschutz++ (GS++): establishing and operating an ISMS in five process steps along the PDCA cycle, from collection and planning to continual improvement. It is aimed primarily at early adopters, experienced institutions whose feedback will shape further development. The methodology was developed with the Grundschutz community and tested in selected pilot institutions.

The five process steps in detail:

Collection and planning: context, scope, stakeholders, business processes, protection needs, policy and roles. This step covers the activities of clauses 4 and 5 of ISO/IEC 27001.
Requirements analysis: define the information domain, record assets, assign target-object categories, select blueprints (predefined requirement catalogues, for example for particular asset groups) and build the requirements package. This is where clauses 6 and 10 of ISO/IEC 27001 sit.
Implementation: assess the status of each requirement (“fulfilled”, “not fulfilled”, “not applicable”), consider risks, and draw up an implementation plan with owners and deadlines.
Monitoring: performance evaluation, internal audit programme, management review, monitoring and validation of requirements.
Continual improvement: handle nonconformities, plan corrections and improvements, evaluate their effectiveness.

The entry point is deliberately lean. Protection needs are assessed at the level of business processes, and the BSI recommends starting with the most important process in the highest protection-needs category. Organisations without a process map will find a simplified business process analysis in Annex 2, with five items per process: ID, name, responsible person, role or organisational unit, short description and essential applications. According to the standard, the description should be “as simple as possible and as precise as necessary”. How protection needs have been assessed under 200-2 so far is explained in the KaitoSec knowledge base on protection needs assessment.

How does 300-1 differ from 200-1?

200-1 is a framework standard; 300-1 is a process methodology. BSI Standard 200-1, “Information Security Management Systems”, dates from October 2017 and describes over 48 pages what an ISMS consists of. For the concrete approach it refers to 200-2, for risk analysis to 200-3. In substance, 300-1 is therefore the counterpart to 200-1 through 200-3, not just to 200-1.

Topic	BSI Standard 200-1 (2017)	BSI Standard 300-1 / GS++ (2026)
Character	Framework standard: what makes an ISMS	Process methodology in five PDCA steps
Approach	Refers to 200-2 (basic, standard, core safeguards)	Contained in the standard, one consistent methodology
Risk	Implicit risk assessment for normal protection needs, explicit analysis per 200-3	Same principle, method of choice, 35 mandatory minimum criteria (Annex 3)
ISO/IEC 27001	Compatible, own structure	Process steps 1 and 2 name the ISO clauses directly (4/5 and 6/10)
Requirements	IT-Grundschutz Compendium	GS++ user catalogue as OSCAL/JSON on GitHub, CC BY-SA 4.0
Modelling	Modules mapped to target objects	Practices and target-object categories in an inheriting hierarchy
Protection-needs categories	Three: normal, high, very high	Two: normal, high
Audience	All institutions	Primarily early adopters

The policy, roles and the non-delegable responsibility of top management from 200-1 appear in process step 1 of 300-1; management review and improvement sit in steps 4 and 5. The distinction between basic, standard and core safeguards from 200-2 no longer appears in 300-1. If you still work along those lines, our overview of the three approaches provides context. 300-1 itself names no retirement date; according to the BSI’s Grundschutz++ page, certification against classic IT-Grundschutz ends on 30 November 2031. BSI Standard 200-4 on business continuity management is not affected.

What does Grundschutz++ change in modelling and risk consideration?

Grundschutz++ replaces the modules with two structures: practices group the requirements by topic, and target-object categories determine which requirements apply to an asset. The categories form a parent-child hierarchy, and an asset inherits the requirements of all parent categories. Requirements without a category reference apply regardless.

In Annex 1 the BSI gives “email” as a child of “interpersonal communication applications”, which in turn sit under “applications”. The mapping logic that used to run through IT-Grundschutz modelling is now part of the data model.

On risk, the basic principle already described in 200-1 stays: for normal protection needs, users do not have to carry out their own risk consideration because the catalogue is already based on a risk consideration by the BSI. What is new is that it becomes visible. The technical and organisational requirements carry the identifiers of the elementary threats (G 0.1 to G 0.47) they counter. An explicit risk consideration is required in three cases:

for high protection needs,
for assets that no target-object category covers adequately,
for SHOULD requirements that are permanently not fulfilled.

Institutions choose the method themselves; the standard names ISO/IEC 27005 and ISO 31000 as examples. New are the 35 mandatory minimum criteria in Annex 3 that any method must meet. If you currently follow BSI Standard 200-3, check your method against these criteria. Unless defined otherwise, the risk owner is the owner of the affected business process.

The handling of modal verbs is clearly defined. A MUST requirement can be replaced neither by risk acceptance nor by an exception approval. For SHOULD requirements the standard distinguishes between temporary and permanent non-fulfilment. Only the permanent kind triggers a full risk consideration; for temporary non-fulfilment, the residual risk must still be considered and approved by top management. MAY requirements form the “increased” security level and can be drawn on for risk consideration.

Why is OSCAL more than a file format for Grundschutz++?

OSCAL turns the requirements of Grundschutz++ into data: requirements packages, catalogue updates, checks and custom profiles can be handled as queries, version comparisons or scripts instead of in Word and Excel. The user catalogue is published in the BSI’s State-of-the-Art Library on GitHub, as OSCAL JSON under CC BY-SA 4.0.

OSCAL stands for Open Security Controls Assessment Language and comes from NIST. The repository has three layers:

Control layer: catalogues, profiles, resolved catalogues and mappings. This is where Grundschutz++-resolved_catalog.json, the ready-to-use complete catalogue, lives. Other BSI requirements already sit alongside it in the same format, such as WLAN, supply chain security, risk management and a draft of the TLS minimum standard, plus mappings from the 2023 IT-Grundschutz Compendium and from ISO/IEC 27001:2022 Annex A to GS++.
Implementation layer: reusable component definitions, that is, descriptions of how requirements are actually implemented.
Assessment layer: intended for machine-readable assessment artefacts such as assessment plans and results; currently still empty.

As a result, four tasks that used to be manual become data operations:

Generating the requirements package. Once your assets are mapped to target-object categories, the chain asset → target-object category → requirements is a query over the catalogue.
Tracking catalogue updates. Catalogue states are versioned in the repository. A version comparison, via Git or OSCAL diff tools, shows which requirements changed. If your own mapping is machine-readable, it also shows which assets are affected.
Automating checks. According to section 3.5, parameters in the requirements (e.g. “regularly”) can also be used for automated checks. Where a check is automated, section 4.3 requires the tool, the time and the result to be documented.
Maintaining your own profiles. An OSCAL profile selects requirements, presets parameters and stays traceable to the source catalogue. Industry associations, corporate groups or service providers can keep their own profiles in sync with the BSI catalogue.

This creates technical options, not automatic compliance. For a readable starting point without your own tooling, the community provides the State-of-the-Art Viewer.

What foundations does the transition to Grundschutz++ need?

The transition to Grundschutz++ mainly needs clean, analysable data: a maintained asset inventory, documented business processes with named responsibility, versioned catalogue states, assessment infrastructure and measure tracking with owners and deadlines. Without these foundations, the machine-readable catalogue largely goes unused.

Asset inventory. Mapping to target-object categories only works if assets are recorded completely and kept current. The standard names CMDBs, asset registers and service maps as sources. The data should be analysable, as an export or via API.
Business processes. The minimum from Annex 2, with a responsible owner who usually also owns the risk.
Versioning. The catalogue comes as a repository. Comparing catalogue versions and mapping changes to your own objects becomes part of the job, whether by script or by tool.
Assessment infrastructure. Configuration management, compliance scanners or pipelines that check target values from the parameters against the actual state and store evidence with a timestamp.
Measure tracking. Section 4.4 names a project management or ticketing system as a suitable place for owners and deadlines.

None of this is exotic. In many organisations, however, asset data, process documentation and measures sit in separate silos with different levels of upkeep. The methodology can then still be worked through in spreadsheets, but the main advantage of the new format goes unused. The alternative is an ISMS platform that keeps inventory, risks, measures and evidence on a shared data foundation. KaitoSec is built that way and works with OSCAL-based catalogues for BSI IT-Grundschutz.

A realistic first step is a bounded pilot: load Grundschutz++-resolved_catalog.json, map the assets of a single business process to the target-object categories in Annex 1 and compare the resulting requirements package with today’s module mapping. This exposes data gaps before the methodology goes live. If you still work with the classic Compendium, KaitoSec’s IT-Grundschutz starter guide is a good place to begin.

What remains open in Grundschutz++?

There are no uniform requirements yet for evaluating ISMS performance; the BSI states that these are still to be developed and that institutions are free to design their own until then. 300-1 does not define a certification scheme for GS++. The BSI publishes the timeline separately on its Grundschutz++ page (German): applications for ISO 27001 certification on the basis of GS++ can be submitted from 1 January 2027, the early-adopter phase starts in Q1 2027, and certification against classic IT-Grundschutz ends on 30 November 2031. Organisations should add these dates to their roadmap and follow BSI publications.

To assess how your current ISMS, asset inventory and measure tracking fit GS++, discuss it in a KaitoSec demo.

Frequently asked questions about BSI 300-1 and Grundschutz++

Does BSI Standard 300-1 immediately replace 200-1?

No. Standard 300-1 itself names no retirement date. According to the BSI, classic IT-Grundschutz remains certifiable until 30 November 2031, and certification on the basis of GS++ is possible from 1 January 2027. If you work according to 200-1 through 200-3, that leaves time to trial GS++ in a parallel pilot.

Do I have to program OSCAL myself for Grundschutz++?

No. OSCAL is the publication format of the catalogue. What matters is traceable assets and mappings to target-object categories. Whether you process the data with a tool, via interfaces or with your own scripts is an implementation decision. For reading alone, the State-of-the-Art Viewer is enough.

When does GS++ require an additional risk consideration?

For high protection needs, for assets that no target-object category covers adequately, and for SHOULD requirements that are permanently not fulfilled. The chosen method must meet the 35 minimum criteria in Annex 3. For SHOULD requirements that are temporarily not fulfilled, at least the residual risk must be considered and approved by top management.

Can MUST requirements be waived in GS++?

No. The standard rules out replacing the fulfilment of a MUST requirement with risk acceptance or an exception approval. There is room for manoeuvre only with SHOULD requirements, whose non-fulfilment must be classed as temporary or permanent, and with the optional MAY requirements of the “increased” level.

Why are there only two protection-needs categories?

GS++ specifies “normal” and “high”; the “very high” category from the previous Grundschutz is dropped. Institutions may define their own categories but must map them to these two. For a certifiable ISMS, the lowest category must always meet the state of the art.

Is there a mapping from the IT-Grundschutz Compendium to GS++?

Yes. The control layer of the State-of-the-Art Library contains a mapping from the 2023 IT-Grundschutz Compendium to GS++, and another from ISO/IEC 27001:2022 Annex A. Both are a good starting point for comparing today’s module mapping with the new requirements package.

Sources

Grundschutz++
BSI IT-Grundschutz
ISMS
OSCAL
ISO 27001

Back to the blog