Grundschutz++ Explained: The New BSI Standard 300-1 and What Changes for Your ISMS | DevOps

Grundschutz++ Explained: The New BSI Standard 300-1 and What Changes for Your ISMS | DevOps | Tobias Weiss

Part of the Content index — see also Compliance Without the Merry-Go-Round: BSI C5:2026, NIST and CCM.

Source: BSI-Standard 300-1 „Methodik Grundschutz++" (PDF).

On 26 October 2026 the German Federal Office for Information Security (BSI) published BSI-Standard 300-1, the methodology of Grundschutz++ — the biggest overhaul of IT-Grundschutz in its 30-year history. Modules and protection levels are out; a process-oriented ISMS with a machine-readable requirements catalogue is in. Certification becomes possible on 1 January 2027; the classic IT-Grundschutz remains certifiable until 30 November 2031.

Diagram: Grundschutz++ replaces the module-based IT-Grundschutz with five PDCA process steps — Erhebung & Planung, Anforderungsanalyse, Realisierung, Überwachung, kontinuierliche Verbesserung — driven by the machine-readable Anforderungskatalog

Background: Why Grundschutz++ exists

IT-Grundschutz is the BSI's baseline methodology for information security — for 30 years the de-facto reference for German public administration and, increasingly, for companies that serve it. The classic approach (Standards 200-1 to 200-3 plus the IT-Grundschutz-Kompendium) is built around modules (Bausteine): organise your systems into modules, apply the linked safeguards, done. It worked — but it grew unwieldy. Thousands of safeguards, protection levels, and a static, document-based Kompendium that was hard to keep current and impossible to automate.

Grundschutz++ is the answer to four pressures:

Heterogeneous and virtualised IT — cloud, containers, and complex virtualisation no longer fit the "one module per system" world of the 1990s.
Automation — regulations (NIS2, KRITIS-Dachgesetz) demand evidence that is auditable and automatable, not prose in a PDF.
ISO/IEC 27001 alignment — institutions increasingly need both; a methodology that maps cleanly onto the international standard saves double documentation.
Risk orientation — one-size-fits-all safeguards waste effort on low-value assets and under-protect critical business processes.

What is new in a nutshell

Dimension	Classic IT-Grundschutz	Grundschutz++ (Standard 300-1)
Focus	IT systems / modules	Business processes (assets follow)
Structure	Kompendium, ~100+ Bausteine	5 PDCA process steps
Catalogue	Static documents	Machine-readable (OSCAL) requirements
Protection needs	normal / high / very high	normal / high
Risk assessment	Mandatory for all	Implicit (BSI) for normal; explicit only for high
Method	Fixed BSI method	Free choice, 34 minimum criteria (Anhang 3)
Certification	From day one	From 1 Jan 2027; transition until 30 Nov 2031

The five process steps (PDCA)

Grundschutz++ is organised as a Plan-Do-Check-Act cycle with exactly five process steps. Every step is described in the standard as a set of formalised requirements — the same "sentence template" language used throughout the catalogue:

Erhebung und Planung (P) — "survey and planning": institution context, compliance management, scope, stakeholder analysis, business processes, protection needs, security policy, roles, documentation, risk-assessment kick-off.
Anforderungsanalyse (D) — "requirements analysis": define the Informationsverbund, capture assets, select blueprints, build the individual Anforderungspaket (requirements package), and set parameters ("Gestaltungsentscheidungen").
Realisierung (D) — "implementation": assess implementation status per requirement, run the risk assessment for what is not covered, plan and prioritise measures, assign responsibilities and deadlines, track progress.
Überwachung (C) — "monitoring": ISMS performance evaluation, internal audit programme, management reviews, monitoring methods and tools, requirement validation.
Kontinuierliche Verbesserung (A) — "continual improvement": non-conformity handling with root-cause analysis, improvement planning, correction plan, evaluation.

Anforderungskatalog: machine-readable requirements

The most radical change is the Anwenderkatalog that replaces the IT-Grundschutz-Kompendium. It ships in OSCAL (the NIST open format for security catalogues) and every requirement is atomic with structured metadata:

Field	Meaning	Example / values
`id`, `title`	Unique identity, e.g. `UMS.1.1`	~1,000 requirements
`modal_verb`	Binding force	MUSS (149) / SOLLTE (627) / KANN (224)
`sec_level`	Security level	`normal-SdT` (state of the art) / `erhöht`
`categories`	Target-object categories the requirement attaches to	e.g. application, IT system, room
`params`	Open parameters such as "regelmäßig" — you set the value	`<param>` placeholder
`threats`	Linked elementary threats (G 0.1 – G 0.47)	traceable chain to risk
`effort_level`	0–5, 0 = mandatory, 1 = quick win … 5 = complex	drives prioritisation
`sec_data`	Effect on confidentiality / integrity / availability	0–2 per security goal

Three types of requirements:

MUSS — binding. Cannot be waived, risk acceptance impossible. A risk assessment never replaces fulfilment.
SOLLTE — expected. A temporary shortfall needs a documented reason; a permanent shortfall triggers a risk assessment with management sign-off on residual risk.
KANN — optional, "erhöht" level; a pool of extra measures you can draw from in the risk assessment.

The exact numbers (149 / 627 / 224) come from independent analyses of the released OSCAL catalogue — the PDF ships the counts machine-readable in the data model, not as headlines. (Roughly 1,000 requirements in total; of the 773 at the "normal" security level, the rest are "erhöht".)

Risk assessment: implicit for normal, explicit for high

Grundschutz++ flips the risk model:

For normal protection needs, the BSI has done the risk thinking for you — an implicit risk assessment is baked into the catalogue. You do not run your own risk assessment for normal-protection processes. This is by far the biggest workload reduction for most institutions.
For high protection-need processes, you run an explicit risk assessment on the level of the business process and critical assets along the resource path.
You are free to choose the method (e.g. ISO/IEC 27005, ISO 31000) as long as you comply with the 34 binding minimum criteria in Anhang 3 — from risk appetite and acceptance criteria (criteria 7 and 8) to the risk register's mandatory fields (15), risk owner (16), and management authorisation of residual risks (criteria 27 and 30).

Blueprints and the requirement package

Instead of "pick modules", you now build an Anforderungspaket (requirements package) from three sources:

Mandatory methodology requirements (apply to every Informationsverbund).
Technical and organisational requirements, selected by mapping your assets to target-object categories (Zielobjektkategorien) — a hierarchy where parent categories inherit requirements to child categories. All assets fit at least one category.
Supplementary requirements you add yourself, e.g. from compliance management or your own risk assessment.

Blaupausen (blueprints) are pre-configured slices of the catalogue for recurring scenarios with parameters pre-set. For some institutions mandatory blueprints may exist; otherwise you select, document, and combine multiple blueprints. Customise an individual requirement with parameters ("regelmäßig" → "quarterly", "monthly"…) at package creation.

Elementary threats (G 0.1 – G 0.47)

A slim, technology-neutral list of 47 elementary threats replaces the sprawling legacy threat catalogues. Each requirement in the catalogue is linked to the threats it mitigates — so you can always trace why a requirement exists, and reuse the mapping in your own risk assessments. Threats are grouped along the classic categories: higher force, organisational shortfalls, human error, technical failure, and deliberate acts.

What this means in practice

For institutions already certified on classic IT-Grundschutz: you have a transition runway until 30 November 2031. Don't panic-migrate; do start a delta analysis — most evidence carries over, and the ISO/IEC 27001 alignment means your existing ISMS documentation maps almost 1:1.

For newcomers: this is the cheapest clean start the BSI has ever offered — implicit risk assessment for the 90% of your processes that are "normal" removes the historically biggest blocker to getting certified.

For tool and GRC vendors: the OSCAL catalogue is the real prize. Requirements are now data: filter, prioritise, and map them automatically — no more scraping a 2,000-page PDF. Standards tell you the model; the market now builds the tools.

Timeline:

Date	Event
20 Oct 2026	Standard 300-1 v1.0 published (PDF)
26 Oct 2026	BSI announcement
1 Jan 2027	Certification per Grundschutz++ possible
Q1 2027	Training for certified advisors / audit-team leaders
31 Dec 2027	Early-adopter phase ends
30 Nov 2031	End of certification per classic IT-Grundschutz

Bottom line: Grundschutz++ is not a facelift — it is a different operating model for German information security: process-first instead of module-first, machine-readable instead of document-based, and risk-appropriate instead of uniform. If your institution lives anywhere in the German public sector, NIS2, or KRITIS, this is the standard you will certify against for the next decade.

November 14, 2026. Read the standard yourself: BSI-Standard 300-1 „Methodik Grundschutz++" (PDF). For the cloud side of German compliance, see C5:2026, NIST and CCM.