Grundschutz++ Is Here: What BSI Standard 300-1 Changes for Every Organisation Running an ISMS

CORE THESIS BSI Standard 300-1 moves the German baseline for information security from a catalogue of building blocks to a process-driven method with a machine-readable requirements library. For organisations with normal protection needs, the BSI has already done most of the risk work, and what remains is a disciplined management task: knowing the business processes, deciding which of them need high protection, closing every gap in the mandatory requirements, and documenting every exception in a way an auditor, and increasingly a tool, can check.

On 26 October 2026 the Federal Office for Information Security (BSI) announced the methodology of Grundschutz++ as BSI Standard 300-1; according to the BSI’s milestone plan, it was presented at it-sa in Nuremberg on 27 October.¹² The document itself, version 1.0 dated 20 October 2026, runs to 42 pages.³ That is short for a standard meant to replace one of the most widely used security methods in the German-speaking world, and in my reading the brevity has a reason: much of what used to sit in long prose now lives in a separately maintained, machine-readable library of requirements.

The BSI describes the standard as a further development of IT-Grundschutz, designed among other things for institutions with heterogeneous IT landscapes or complex virtualisation.¹ An ISMS implemented under Grundschutz++ is to be certifiable from 2027 and compatible with ISO/IEC 27001.¹ Version 1.0 is addressed first of all to “early adopters”, experienced institutions that want to implement Grundschutz++ early and whose experience will feed into the further development of Grundschutz++.³

Where the change comes from

IT-Grundschutz, as practised under BSI Standards 200-1 to 200-3, asked organisations to model their information network with building blocks from the IT-Grundschutz-Kompendium, on the basis of a structure analysis that also recorded business processes and applications, and to assign protection needs in three categories. An additional risk analysis was due for target objects with high or very high protection needs, for objects the building blocks could not adequately model, and for operating scenarios IT-Grundschutz did not foresee.⁴ In my experience it worked, and it produced a large community of trained practitioners. It also produced long documents that were hard to keep current and harder to check automatically.

Grundschutz++ keeps the idea of a baseline that the BSI pre-calculates for typical situations, and changes almost everything around it. The BSI’s press release highlights three features: the method is organised around business processes, the risk method can be chosen freely as long as defined minimum criteria are met, and all requirements are now available in a machine-readable format.¹ The second point is less new than it sounds: BSI Standard 200-3 already allowed another established risk method; what is new are the 35 binding minimum criteria that any method has to meet.³⁴ The “Stand der Technik” library replaces the IT-Grundschutz-Kompendium,² and it is published as OSCAL documents in a public repository under a Creative Commons licence.⁵

Five steps, one cycle

The method follows a PDCA cycle with five process steps.³ For the first two steps it names the ISO/IEC 27001 clauses they cover, and the methodology requirements as a whole reflect clauses 4 to 10.

• Step 1, survey and planning, carries out the activities of clauses 4 and 5 of ISO/IEC 27001: context, compliance management, scope, interested parties, business processes, protection needs, security policy, roles, documentation, management approval and the initiation of risk assessment.
• Step 2, requirements analysis, carries out the activities of clauses 6 and 10: delimiting the information network, recording assets, choosing blueprints and building an individual requirements package.
• Step 3, implementation, checks the status of every requirement, runs the risk assessment where it is needed, and turns the result into an implementation plan with owners and deadlines.
• Step 4, monitoring, covers performance evaluation, internal audits, management reviews, monitoring procedures and the validation of the requirements.
• Step 5, continual improvement, handles nonconformities, improvement potential, a correction and improvement plan, and the evaluation of whether measures actually worked.

Two details in step 1 deserve a manager’s attention. The responsibility for the ISMS lies with the institution’s management and cannot be delegated.³ And the information security officer, or another role from the security organisation, must be involved in security-relevant projects such as introducing a new system and informed about their essential content; the organisation determines when that involvement takes place.³

Processes first, assets second

The most visible change is the anchor. IT-Grundschutz also began its structure analysis with business processes, but it then assessed protection needs and assigned building blocks object by object;⁴ in Grundschutz++ the business process remains the reference point throughout. Organisations identify and document the business processes inside the scope before they look at systems. For public bodies the standard notes that their statutory mandates serve as the source.³ Where no process map exists, Annex 2 offers a deliberately minimal method: a process is a recurring, essential sequence of related activities with a traceable result, and each one needs only an ID, a name, the responsible person, role or unit, a short description and its main applications.³

Protection needs are then assessed per business process, not per system, and there are only two categories: normal, where the impact is limited and manageable, and high, where it can be considerable.³ Organisations may define additional categories of their own, but they must map them onto these two, and for a certifiable ISMS the state of the art must always be met in the lowest category.³ The standard recommends that an organisation implementing an ISMS for the first time begins with its most important process in the highest protection category, and then works through the others.³

The asset work follows from that choice. For a process with high protection needs, the assets’ membership in and dependencies on the process have to be documented, because the later risk assessment runs at process level and along the resource path. For normal protection needs that process-level documentation is not required, and the standard asks for less: at least the dependencies between applications and IT systems, and between IT systems and rooms.³ Existing CMDBs, asset registers, network plans and service maps may be reused.³

From assets to a requirements package

Assets are then assigned to target object categories, standardised classes such as buildings, server rooms, administrators, external network connections, cloud services, web applications or e-mail. Annex 1 defines them, and they form an inheritance hierarchy: a server room is also a room, and an asset assigned to a child category takes on the requirements of its parent categories as well.³

Grundschutz++ distinguishes three types of requirements.³ Methodology requirements reflect clauses 4 to 10 of ISO/IEC 27001 and apply to every information network, with no individual approach foreseen. Technical and organisational requirements without a target object category must also be included. Requirements tied to a category apply wherever assets have been assigned to it. The package is then supplemented where needed: with the organisation’s own requirements for assets the catalogue does not adequately cover, and with obligations from compliance management, the stakeholder analysis or the risk assessment.³ Blueprints, pre-configured requirement catalogues for specific scenarios, can pre-select requirements and fix their parameters, and some institutions may be obliged to use particular blueprints.³

In my view, parameters are the quiet innovation. A requirement may say that something is done “regularly”; where no blueprint or other binding value has already fixed it, the organisation decides what regularly means when or after it builds its package, and the standard notes that parameters can be used for automated checks.³

MUSS, SOLLTE, KANN: where the line now runs

Before a gap is treated, the first question is whether the requirement applies at all; where it does not, the reason is documented, and that is not the same as accepting a risk.³ Every applicable requirement carries a modal verb, and Grundschutz++ attaches clear consequences to each one.³

KANN requirements belong to the “elevated” security level and are optional. They are a menu for organisations whose risk assessment calls for more.

SOLLTE requirements that are not met have to be classified. A temporary non-fulfilment, with a sound justification and fulfilment planned for a foreseeable later point, does not by itself trigger a full explicit risk assessment. A residual-risk review is still required, and the identified risk must be approved by management, which carries it until the requirement is met. A permanent non-fulfilment does trigger a risk assessment, and the residual risks go to management for approval. The standard adds a warning: if permanent non-fulfilments pile up, the state of the art may not be reached overall, and a certification audit could record a major deviation.³

MUSS requirements are mandatory. Measures must be defined for every one that is not met, a risk assessment cannot replace their fulfilment, and neither an exception nor a risk acceptance is possible.³

In my view this is the sentence many organisations will feel first. ISO/IEC 27001 allows a risk-based selection of controls and the acceptance of residual risks within its requirements, although the mandatory ISMS requirements of clauses 4 to 10 cannot be waived that way. IT-Grundschutz already ruled out risk acceptance for its basic requirements as a rule;⁴ Grundschutz++ makes that absolute for every MUSS requirement and closes the route of an exception approval as well.

Risk assessment: only where triggered, with firmer rules

As under IT-Grundschutz, the BSI has built a general risk assessment into the requirements catalogue. It derives the requirements with 47 elementary threats as a basis, from G 0.1 fire to G 0.47 harmful side effects of IT-supported attacks, and, where the catalogue defines it, a technical or organisational requirement carries the G 0.x identifiers of the threats it counters; methodology requirements do not.³⁵ As a result, organisations with normal protection needs generally do not have to run their own explicit risk assessment, unless one of the triggers below applies; residual risks of SOLLTE requirements that are planned but not yet met still have to be reviewed and approved.³

An explicit risk assessment is required in three cases: a business process has high protection needs for at least one protection goal, a relevant asset is not adequately covered by the existing target object categories and their requirements, or an applicable SOLLTE requirement will be permanently unmet.³ Organisations may choose their own method, for example along ISO/IEC 27005 or ISO 31000, provided it meets the 35 binding minimum criteria in Annex 3.³

To me, those criteria read like a checklist an auditor will use. The institution sets its risk appetite and acceptance criteria, and management authorises the method, the roles, the criteria and the appetite. Every risk gets a risk owner, by default the owner of the business process, and a register entry with at least an ID, the object, a description, the affected protection goals, the risk level and the owner, plus priority, treatment option and assigned measures for risks to be treated. Temporarily accepted risks need an end date. Residual risks are authorised by management. The whole assessment is reviewed at least annually and in the event of planned or actual significant changes.³

Evidence that a tool can read

In my reading, the implementation step is written with automation in mind. Every measure must be linked to the requirements it addresses, and every requirement must show which measures serve it. Each measure records at least its requirement, the date of implementation or review, and the person who documented or checked it. Where a check is automated, the tool, the time and the result must be documented, and any report the tool produces is attached to the measure and the requirement.³

Status checks may range from interviews and document reviews to automated configuration checks and technical scans.³ Taken together with the machine-readable catalogue, this points, in my view, in one direction: the evidence chain from requirement to measure to proof is best maintained in tools, not reconstructed before an audit.

What is still open

Version 1.0 is candid about its gaps. Uniform rules for performance evaluation are still to be developed. Performance evaluation itself is already required: organisations design it themselves for now and present a traceable evaluation to management.³ The BSI’s timeline adds a performance measurement concept in February 2027 and performance indicators for each requirement of the methodology practices by the end of March 2027.² Training concepts for Grundschutz++ practitioners and consultants are announced for 30 November 2026, and a worked example using a fictional authority for December 2026.²

The timeline that matters

Date	Milestone
26/27 Oct 2026	BSI Standard 300-1 announced (press release, 26 Oct) and presented at it-sa (27 Oct); document version 1.0 of 20 Oct 2026
30 Nov 2026	Training concepts for practitioners and consultants
1 Jan 2027	Applications for ISO 27001 certification on the basis of Grundschutz++ possible
Q1 2027 – 31 Dec 2027	Early-adopter phase
30 Nov 2031	Certification under IT-Grundschutz ends

Sources: BSI press release of 26 October 2026 and BSI overview page on Grundschutz++, as of October 2026.¹²

The last line is the one to put in a planning document. According to the BSI’s roadmap, certification under IT-Grundschutz remains possible until 30 November 2031, five years after the publication of Grundschutz++. The page does not say whether certificates issued before that date remain valid until they expire; that should be clarified with the BSI before a migration plan relies on it. In my view that horizon is enough time to migrate deliberately, and short enough that a new ISMS project started today should be designed with Grundschutz++ in mind.

What else the standard asks for

The changes above are the ones most organisations will notice first. Version 1.0 contains more, and a few points deserve a place in any project plan.³

• Roles without conflicts. Roles in the security organisation need the necessary competence and clear interfaces, and conflicts of interest, for example between IT management and the information security officer or between the data protection officer and the information security officer, are to be avoided (chapter 2.8).
• Boundaries of the scope. A scope can contain several information networks. Their organisational, technical and infrastructural boundaries, including outsourced parts and interfaces to third parties, have to be documented (chapters 2.3 and 3.1).
• Two different levels. The protection-need categories normal and high are not the same as the security levels of the requirements, normal (state of the art) and elevated. Which additional requirements a high protection need calls for is decided in the risk assessment (chapters 2.6 and 3.4.2).
• Blueprints are maintained, not picked once. The selection and any adaptation of blueprints are documented, gaps in their coverage are closed, and the choice is reviewed when relevant things change (chapter 3.3).
• Planning with resources. The implementation plan is approved with resources and responsibilities, and progress and deviations are tracked continuously (chapters 4.4 and 4.5).
• Audits and management review. Internal audits follow a programme with competent, impartial auditors, and the management review draws on audit, performance, incident and risk-treatment results (chapters 5.2 and 5.3).
• Monitoring and improvement. Incidents, vulnerabilities and new threats are handled continuously, requirements are validated when the information network, the catalogue or the blueprints change, and improvements are checked for effectiveness (chapters 5.4 to 6).

Lessons learned

The following lessons are my own reading as a lead auditor, not statements of the BSI.

The first lesson is that Grundschutz++ is a management method before it is a technical one. Its first decisions, the scope, the protection needs of the business processes, the order in which they are worked through, the resources and the security policy, all have to be taken or approved by management, and the responsibility for the ISMS cannot be delegated.³ An organisation that cannot name its ten most important processes and their owners is not ready to start, however good its firewall rules are.

The second lesson concerns gaps. Sort them by modal verb before anything else. MUSS gaps need measures, and no risk acceptance will cover them. SOLLTE gaps need a label, temporary or permanent: temporary ones need a sound justification and management approval of the residual risk, permanent ones a risk assessment and management approval of the remaining risks.³ An organisation that today accepts risks by memo should check whether the requirement behind each memo is a MUSS.

The third lesson is about evidence. Grundschutz++ assumes that requirements, measures and proofs are linked unambiguously, with one measure allowed to serve several requirements, and kept current, with automated checks documented down to the tool and the timestamp.³ Spreadsheets can do this for a small information network. For anything larger, the requirement catalogue’s machine-readable format is an invitation to manage the ISMS in a tool that reads it directly.

The fourth lesson is about timing. According to the BSI’s roadmap, applications for ISO 27001 certification on the basis of Grundschutz++ can be submitted from 1 January 2027, and certification under IT-Grundschutz ends on 30 November 2031.² Organisations with a running IT-Grundschutz certificate should plan the move, not rush it. Organisations starting from scratch should start with Grundschutz++.

Glossary

Term	Meaning
Grundschutz++ (GS++)	The BSI’s successor to IT-Grundschutz for building an ISMS; its methodology is BSI Standard 300-1
Stand der Technik library	The BSI’s machine-readable collection of requirements and measures, published as OSCAL documents; it replaces the IT-Grundschutz-Kompendium
Anwenderkatalog GS++	The user catalogue of all Grundschutz++ requirements, including the methodology requirements
Business process	A recurring, essential sequence of related activities with a traceable result
Protection need	The required level of confidentiality, integrity and availability of a business process; Grundschutz++ knows “normal” and “high”
Information network (Informationsverbund)	The infrastructural, organisational, personnel and technical assets that represent the scope, or part of it, in practice
Target object category (ZOK)	A standardised class of assets, such as server room or cloud service, to which requirements are attached
Blueprint	A pre-configured requirement catalogue for a specific scenario, with parameters already set
Parameter	A variable element of a requirement, such as “regularly”, that the organisation fixes and a tool can check
MUSS / SOLLTE / KANN	Mandatory / to be met as a rule, deviation only with justification / optional requirements, each with its own consequence when unmet
Elementary threats	The 47 threats, G 0.1 to G 0.47, from which the BSI derives the requirements
OSCAL	Open Security Controls Assessment Language, a machine-readable format for security controls

Legal notice: This article serves general information purposes and does not constitute legal advice. It describes BSI Standard 300-1 in version 1.0; later versions may change details. As of: October 2026.

1. BSI, press release “Methodik zum Grundschutz++ als BSI-Standard 300-1 veröffentlicht”, 26 October 2026, https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/2026/BSI-Standard_300-1_261026.html (accessed 27 October 2026). ↩ ↩² ↩³ ↩⁴ ↩⁵

2. BSI, “Grundschutz++”, overview page with timeline (pilot phase, publication, certification from 1 January 2027, early-adopter phase, end of IT-Grundschutz certification on 30 November 2031), https://www.bsi.bund.de/dok/grundschutz-plus-plus (accessed 27 October 2026). ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

3. BSI, “BSI-Standard 300-1 – Methodik Grundschutz++”, version 1.0, 20 October 2026, 42 pages: introduction (target group, PDCA cycle), chapter 2 (survey and planning, incl. 2.6 protection needs, 2.8 role of the ISB, 2.10 non-delegable responsibility, 2.11 initiation of risk assessment), chapter 3 (requirements analysis, target object categories, blueprints, parameters), chapter 4 (implementation, incl. 4.1.2 MUSS/SOLLTE/KANN and 4.3 implementation planning, incl. evidence), chapter 5 (monitoring, incl. 5.1 performance evaluation), chapter 6 (improvement), Annex 1 (target object categories), Annex 2 (simplified business process analysis), Annex 3 (35 minimum criteria for risk assessment), Annex 4 (47 elementary threats). PDF: https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_300-1.pdf?__blob=publicationFile&v=3 (accessed 27 October 2026). ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴ ↩²⁵ ↩²⁶ ↩²⁷ ↩²⁸ ↩²⁹ ↩³⁰ ↩³¹ ↩³² ↩³³ ↩³⁴

4. BSI, “BSI-Standard 200-2 – IT-Grundschutz-Methodik”, version 1.0, 2017, chapter 8 (structure analysis incl. business processes and applications, protection needs, modelling; 8.4.2 and 9.2 on basic requirements; 8.5 risk analysis), https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_2.pdf?__blob=publicationFile&v=2 (accessed 28 October 2026); BSI Standard 200-3 – Risikoanalyse auf der Basis von IT-Grundschutz, version 1.0, 2017, section 1.4, https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_200_3.pdf?__blob=publicationFile&v=2 (accessed 28 October 2026). ↩ ↩² ↩³ ↩⁴

5. BSI, “Stand-der-Technik-Bibliothek”, GitHub repository with machine-readable OSCAL documents, licence CC BY-SA 4.0, https://github.com/BSI-Bund/Stand-der-Technik-Bibliothek (accessed 27 October 2026). ↩ ↩²