Grundschutz++ is designed for automation
The biggest change lies in the format. All requirements are machine-readable, and the BSI draws the conclusion itself: „Dadurch wird die Prüfung der Anforderungen automatisierbar.“ (our translation: "This makes it possible to automate the checking of the requirements.") The BSI announces that tools are to monitor compliance with the requirements and support users in implementing them.
300-1 reflects this in the method. Besides interviews and document reviews, it expressly names automated configuration checks and technical scans as methods for determining the implementation status (Umsetzungsstatus) (chapter 4.1). Parameters such as "regularly" can expressly be used for automated checks (chapter 3.5), and existing CMDBs and asset registers may feed into the recording of assets (chapters 3.1 and 3.2). Human decisions remain where the standard requires them: the protection requirements of business processes, the risk assessment (Risikobetrachtung) and everything that top management approves.
Five process steps in the PDCA cycle
300-1 divides the ISMS into five process steps that are run through repeatedly along the PDCA cycle: survey and planning, requirements analysis, implementation, monitoring and continual improvement.
In the first step the organisation establishes its context, involves compliance management, defines the scope, analyses interested parties and identifies its business processes. The information security policy, the roles of the security organisation, a document control procedure and the framework for risk assessment follow. Responsibility for the ISMS lies with top management (Institutionsleitung) and, according to the standard, cannot be delegated (chapter 2.10). Among other things, the scope, the protection requirements of the business processes, the order of processing, the resources and the policy are submitted to top management for approval.
For the first two process steps the standard names the corresponding clauses of DIN EN ISO/IEC 27001; according to the standard, the methodology requirements reflect clauses 4 to 10 (chapter 3.4). In its announcement of 26 October 2026 the BSI describes an ISMS built under Grundschutz++ as compatible with ISO/IEC 27001.
Reading path: chapter, decision, document
The table shows for each chapter what you decide or define there and which document results. The "document" column summarises what the standard requires to be documented; it mostly leaves the form open.
| Chapter of 300-1 | What is decided or defined | Resulting document |
|---|---|---|
| 2.1-2.4 Context, compliance, scope, interested parties | Which areas the ISMS covers and which it excludes; which obligations enter the ISMS as requirements (agreed with top management) | Short context description, overview of legal and contractual obligations, scope with exclusions, list of interested parties |
| 2.5-2.6 Business processes, protection requirements | Which business processes are in scope, "normal" or "high" per process, which process you start with | Process list (under Annex 2: identifier, name, responsible unit, short description, main applications), protection requirements per process |
| 2.7-2.10 Policy, roles, documentation, approvals | Security objectives and strategy, roles with responsibilities (such as the information security officer, Informationssicherheitsbeauftragter or ISB, and IT operations), procedures for communication and document control | Policy approved by top management, role descriptions, document control procedure, decision papers for top management |
| 2.11 Initiating the risk assessment | Risk appetite, risk acceptance criteria, procedure, roles including risk owners | Risk framework authorised by top management |
| 3.1-3.2 Information domain, assets | Boundaries of the information domain (Informationsverbund) and its interfaces; which dependencies to document (depending on protection requirements) | Description of the information domain with interfaces, asset overview with dependencies (table, CMDB, network plan or service map) |
| 3.3-3.5 Blueprints, requirements package, parameters | Which blueprints (Blaupausen) in which version, assignment of assets to target object categories (Zielobjektkategorien), own additions, parameter values | Requirements package with defined parameters, documented choice of blueprints |
| 4.1-4.2 Implementation status, risk assessment | Status per requirement, classification of unfulfilled SHOULD requirements as temporary or permanent, risk treatment | Status list with a justification for every "not applicable", risk register, approval of residual risks by top management |
| 4.3-4.5 Implementation planning, responsibilities, progress | Measures per requirement, priority, owners, deadlines | Implementation plan linking measure, requirement and evidence |
| 5.1-5.5 Monitoring | Performance evaluation, internal audit programme, management review, monitoring procedures, validation of requirements | Audit programme and audit reports, management report, documented validation result |
| 6.1-6.4 Continual improvement | Handling of nonconformities, priority of corrections | Correction and improvement plan (included in the implementation plan), evaluation result |
| Annexes 1-4 | Reference: 39 target object categories, simplified business process analysis, 35 minimum criteria, 47 elementary threats | - |
For a first pass: read chapters 2.10 and 2.6 first (what top management decides and how protection requirements are set), then Annex 2 with chapter 2.5 (recording business processes and choosing the starting process), then chapters 3.1 to 3.5 with Annex 1 (information domain, target object categories, requirements package), then chapters 4.1 and 4.3 (status, measures, evidence). Chapters 2.11, 4.2 and Annex 3 follow once a trigger for an explicit risk assessment exists, and chapters 5 and 6 for ongoing operation.
The business process comes first
The organisation determines protection requirements per business process, for confidentiality, integrity and availability of the information processed (chapter 2.6). Business processes already existed in BSI Standard 200-2: there, protection requirements were first set for business processes and applications and then inherited by IT systems, rooms and communication links, in three categories. What is new in 300-1 is that protection requirements are determined per business process in only two categories: "normal" („die Auswirkungen sind begrenzt und überschaubar“, our translation: "the impact is limited and manageable") and "high" („die Auswirkungen können beträchtlich sein“, our translation: "the impact can be considerable"). Own additional categories are allowed but must be mapped to these two. For a certifiable ISMS, the state of the art must always be met in the lowest category.
For a first introduction the standard recommends starting with the most important business process in the highest protection category and then examining the remaining processes in scope step by step. An ISMS therefore does not have to begin with a complete model of the whole organisation.
Documentation depth also follows the protection requirements (chapter 3.2). For normal protection requirements, the standard only asks for dependencies between applications and IT systems and between IT systems and rooms. The assignment of assets to the business process with their main dependencies is only required for high protection requirements. Existing CMDBs, asset registers, operating manuals, network plans or service maps may be used.
From asset to requirements package
Assets are assigned to target object categories (Zielobjektkategorien). Annex 1 of the standard defines 39 categories, from sites, users, networks and IT systems to applications with subcategories such as directory services or web applications; the standard places cloud services under outsourcing. Higher-level categories apply as well (chapter 3.4.2). The requirements follow from the assigned categories.
The individual requirements package (Anforderungspaket) has three parts (chapter 3.4): the methodology requirements that apply to every information domain, the technical and organisational requirements without a target object category, which must always be included, and the requirements of the assigned categories. In the build of 29 October 2026 these are 95 methodology requirements, 265 technical and organisational requirements without and 636 with a target object category, plus four requirements on risk management (own count). Blueprints, ready-made catalogues for particular scenarios with preset parameters, and own additions, for example from compliance management, come on top. According to the standard, blueprints may be mandatory for certain organisations.
Many requirements contain parameters such as "regularly". The organisation sets them when or after the package is created.
Status and modal verbs
The implementation status of every requirement in the package is checked in full (chapter 4.1.1). It is "fulfilled" (erfüllt), "not fulfilled" (nicht erfüllt) or "not applicable" (nicht anwendbar). "Not applicable" is possible only if the requirement cannot be met functionally or the underlying component does not exist in the information domain (chapter 4.1.1), and it must be justified. There is no "partially". The IT-Grundschutz Check under BSI Standard 200-2 still had the values "partially" and "dispensable" (entbehrlich).
What follows from an unfulfilled requirement depends on the modal verb (chapter 4.1.2):
- MUST (MUSS): measures to fulfil the requirement must be defined. A risk assessment does not replace fulfilment; the standard states: „Eine Ausnahmegenehmigung oder Risikoakzeptanz ist nicht möglich.“ (our translation: "An exemption or risk acceptance is not possible.")
- SHOULD (SOLLTE): non-fulfilment is classified as temporary or permanent. Temporary means fulfilment is planned; the non-fulfilment must then be soundly justified. Chapter 4.1.2 says a temporary non-fulfilment does not trigger a risk assessment. Chapter 2.11 requires, for SHOULD requirements that are included in the implementation plan but not yet fulfilled, a residual risk assessment and approval of the risk by top management; chapter 4.1.1 requires the risk to be identified and reported to top management. How the two passages fit together is an open question of interpretation. To stay on the safe side, identify the residual risk, report it to top management and have it approved. Permanent means the requirement will not be fulfilled for the foreseeable future; a risk assessment is then required and the residual risk goes to top management for approval. If permanent non-fulfilments accumulate, the state of the art may be missed overall according to the standard; in a certification, a significant deviation (erhebliche Abweichung) could then be found (chapter 4.1.2).
- MAY (KANN): requirements at the security level "erhöht" (increased) are optional. They serve as a pool of additional measures in the risk assessment.
Risk assessment: fewer mandatory cases, fixed minimum criteria
Because the user catalogue is based on a general risk assessment by the BSI, the standard says organisations with normal protection requirements do not need their own (chapter 2.11). An explicit risk assessment is nevertheless mandatory in three cases, two of which can also arise with normal protection requirements: when a business process has high protection requirements for at least one protection goal, when a relevant asset is not adequately covered by the target object categories, and when an applicable SHOULD requirement is permanently not fulfilled. For SHOULD requirements that are planned but not yet fulfilled, chapter 2.11 adds a residual risk assessment; how this fits with chapter 4.1.2 is the open question described above.
The method can be chosen freely; ISO/IEC 27005 and ISO 31000 are given as examples. It must, however, meet the 35 binding minimum criteria (Mindestkriterien) of Annex 3. They include a defined risk appetite, risk acceptance criteria, a risk owner (Risikoeigentümer) for every risk, minimum content of the risk register, authorisation of residual risks by top management, a time limit for temporarily accepted risks and a review at least once a year. The starting point is the 47 elementary threats (elementare Gefährdungen) G 0.1 to G 0.47; the technical and organisational requirements in the catalogue carry the identifier of the threat they counter (Annex 4).
Automated checks as evidence
To determine the implementation status, the standard names methods ranging from interviews and document reviews to automated configuration checks and technical scans (chapter 4.1). The evidence used must be clearly assigned to the measure. For automated checks, the tool used, the time of the check and the result must be documented; if the tool produces a report, it must be assigned to the measure and the requirement (chapter 4.3).
The basis is the machine-readable catalogue in OSCAL format as JSON. In the build of 29 October 2026 (commit c3f37859) the user catalogue contains 1,000 requirements in 20 practices, 773 at the security level "normal-SdT" (SdT = Stand der Technik, state of the art) and 227 at "erhöht" (increased) (own count across all nesting levels on 1 November 2026). The library also contains mapping tables from ISO/IEC 27001:2022 Annex A and from the IT-Grundschutz Compendium 2023 to Grundschutz++.
Federal administration and companies
For bodies of the German federal administration, Section 44(1) BSIG refers to minimum requirements from the BSI standards, the IT-Grundschutz Compendium (Grundschutzkompendium) and the federal minimum standards (Mindeststandards des Bundes) in the versions applicable at the time, which the BSI publishes on its website. Under Section 44(2) BSIG, implementing these minimum requirements ensures compliance with Section 30 BSIG, unless an implementing act of the European Commission under Article 21(5), second subparagraph, of the NIS2 Directive sets further technical and methodological requirements. In the BSI sources we evaluated, we found no express statement on whether the Compendium 2023, Grundschutz++ or both currently apply. If a federal body is also an operator of critical facilities (Betreiber kritischer Anlagen) and the requirements conflict, Section 30(9) and Section 31 BSIG take precedence.
Under Section 30(2) BSIG, the measures of essential entities (besonders wichtige Einrichtungen) and important entities (wichtige Einrichtungen) are to comply with the state of the art and take relevant European and international standards into account. The provision does not prescribe a particular framework, so Grundschutz++ is one of several ways. Whether it is the right one depends on the individual case, for example on whether public-sector clients expect Grundschutz evidence. Whether a requirement legally applies to you is for your legal department to assess.
What is still missing
Some parts will follow later. On performance evaluation, the standard itself states that uniform requirements are still pending and that organisations are free to design it until then (chapter 5.1); according to the milestone plan, indicators follow in spring 2027.
The user catalogue in the build of 29 October 2026 also still deviates from the standard. The guidance on requirement UMS.1.1 says the implementation status can „grundsätzlich nur ‚umgesetzt‘ (‚ja‘) oder ‚nicht umgesetzt‘ (‚nein‘) sein“ (our translation: "in principle only be 'implemented' ('yes') or 'not implemented' ('no')"), while the standard knows three values. The guidance on STM.2.1.5 provides that requirements not relevant to the business processes are „aus dem Anforderungspaket gestrichen“ (our translation: "deleted from the requirements package"), whereas the standard makes all technical and organisational requirements without a target object category mandatory in the package and records non-applicability only in the status. Anyone setting up templates or tools now should follow the standard.
300-1 mentions neither Standards 200-1 to 200-3 nor the previous approaches of basic, core and standard protection; whether these variants continue under Grundschutz++ is left open. The standard makes no statement on BSI Standard 200-4 (business continuity management); it mentions a BCMS only as a possible source for identifying business processes (chapter 2.5).
Readiness: what you can prepare now
- Decide on the framework and submit it to top management. Clarify whether you stay with classic IT-Grundschutz, work under ISO 27001 without a Grundschutz basis or move to Grundschutz++, and by when. An existing certificate does not have to be converted immediately; the schedule should follow the recertification date.
- Record business processes. Where no process map exists, Annex 2 accepts a simple table with identifier, name, responsible unit, short description and main applications. Set the protection requirements per process and choose the process to start with.
- Check your risk method against the minimum criteria. Whether you work under 200-3, ISO/IEC 27005 or your own method, compare procedure, roles, criteria and risk register with the 35 criteria of Annex 3, in particular whether risk appetite and acceptance criteria are defined and authorised by top management and whether temporarily accepted risks have a time limit (criteria 7, 8, 9 and 28).
- Compare existing documentation using the mapping tables. The table for the Compendium 2023 has the status draft, so its mappings must be checked; the table for ISO 27001 covers only the controls of Annex A.
- Automate evidence where it is technically possible. Record which tool delivered which result when, and assign it to the measure and the requirement.
- Justify "not applicable" properly. Because requirements without a target object category always enter the package, every non-applicability needs a traceable justification.
How the changes compare with the classic method is shown on IT-Grundschutz vs. Grundschutz++, the work packages of a switch on Grundschutz++ migration, and all dates on Grundschutz++ timeline. If you prefer not to do the comparison with 300-1 alone, see IT-Grundschutz consulting.