The differences in brief
Two versions are compared. On one side classic IT-Grundschutz: BSI Standard 200-2 „IT-Grundschutz-Methodik“ and 200-3 „Risikoanalyse auf der Basis von IT-Grundschutz“, each version 1.0 of October 2017, together with the IT-Grundschutz Compendium (IT-Grundschutz-Kompendium), edition 2023. On the other side Grundschutz++: BSI Standard 300-1 „Methodik Grundschutz++“, version 1.0 of 20 October 2026, and the Grundschutz++ user catalogue (Anwenderkatalog) in the State-of-the-Art Library (Stand-der-Technik-Bibliothek), here in the build of 29 October 2026.
Much remains familiar. Both methods work with an information domain (Informationsverbund), protection requirements for confidentiality, integrity and availability, a security policy (Informationssicherheitsleitlinie), a security organisation and the 47 elementary threats (elementare Gefährdungen). Both assume that, for normal protection requirements, the BSI has carried out the threat and risk assessment in advance. What is new is mainly the data model (business process, asset, target object category, requirements package), the assessment logic and the explicit recognition of automated checks as evidence. Business processes already existed in 200-2, where their protection requirements were inherited by IT systems, rooms and communication links (200-2, ch. 8.2.2). What is new in 300-1 is that protection requirements are determined per business process in two categories; 300-1 does not describe a separate protection requirements assessment for IT systems or rooms.
Change table: data, roles, documents, evidence
The table compares the rule under 200-2/200-3 with the rule under 300-1. The column "consequence" is our professional assessment. Chapter references refer to the respective standard.
| Area | IT-Grundschutz 2023 (200-2, 200-3, Compendium) | Grundschutz++ (300-1, user catalogue) | Consequence for your work |
|---|---|---|---|
| Data: rule set | IT-Grundschutz Compendium with modules in the layers ISMS, ORP, CON, OPS, DER, INF, NET, SYS, APP, IND, plus implementation notes (200-2, ch. 2.4, 8.3.1). | User catalogue in the State-of-the-Art Library, OSCAL in JSON; in the build of 29 October 2026, 1,000 requirements in 20 practices. According to the BSI, the library replaces the Compendium. | Record the catalogue version with its build date. References to Compendium requirement IDs (such as APP.3.6.A1) no longer apply to Grundschutz++. |
| Data: entry | Three approaches: basic, core and standard protection (Basis-, Kern- und Standard-Absicherung, 200-2, ch. 3.3). | No approaches of this kind in the text. Recommendation: start with the most important business process in the highest protection category, then all processes in scope step by step (ch. 2.6). | The order of the business processes becomes a decision for top management (ch. 2.10). |
| Data: protection requirements | Three categories "normal", "high", "very high". First for business processes and applications, then inherited by IT systems, rooms and communication links under the maximum principle, with accumulation and distribution effects (200-2, ch. 8.2). | Two categories, "normal" and "high", determined for each business process. Organisations may define additional categories of their own but must map them to these two (ch. 2.6). | Former "very high" ratings and object-based protection tables have to be reorganised. The justification per process becomes the central document. |
| Data: structure | Structure analysis (Strukturanalyse) with business processes, applications, network plan, IT systems, ICS, other devices and rooms; grouping for simplification (200-2, ch. 8.1). | Assets with dependencies. With high protection requirements, assignment and dependencies to the business process; with normal ones at least application to IT system and IT system to room. Existing CMDBs, asset registers and network plans may be used (ch. 3.1, 3.2). | Inventory data from operations becomes the source. Documentation depth depends on the protection requirements of the process. |
| Data: modelling | Modules are assigned to target objects; requirements are divided into basic, standard and elevated-protection requirements (200-2, ch. 8.3). | Assets are assigned to 39 target object categories; higher-level categories apply as well. Requirements without a target object category and methodology requirements always enter the package. In addition, blueprints and parameters such as "regularly" (ch. 3.3 to 3.5). | The modelling result is now called the requirements package (Anforderungspaket). Parameters must be set and documented. |
| Data: requirement types | Basic and standard requirements together represent the state of the art and must be met for certification; elevated-protection requirements are suggestions (200-2, ch. 2.7, 8.3.1). | Security level (Sicherheitsniveau) "normal-SdT" (SdT = Stand der Technik, state of the art) or "erhöht" (increased). "Erhöht" requirements use the modal verb KANN (MAY) and are optional (ch. 3.4.2). In the build of 29 October 2026: 149 MUSS (MUST), 627 SOLLTE (SHOULD) and 224 KANN (MAY) requirements; three of the 227 "erhöht" requirements still use SOLLTE (SHOULD) (BES.1.4, DET.4.12.1, REA.2.5). | The basic/standard split disappears. What is mandatory follows from modal verb and security level. |
| Roles: top management | Responsibility for information security remains with the top management level; the task is typically delegated to the information security officer (ISB) (200-2, ch. 2.3). | Responsibility lies with top management (Institutionsleitung) and cannot be delegated. Scope, protection requirements of the business processes, order of processing, resources and policy are submitted to it for approval (ch. 2.10). | More explicit, dated management approvals. Decision papers belong in document control. |
| Roles: security organisation | ISB, IS management team, area and project security officers, ICS ISB, IS coordination committee, data protection officer (200-2, ch. 4). | Roles with qualifications and competences, avoidance of conflicts of interest (head of IT and ISB, DPO and ISB), defined involvement of the ISB in security-relevant projects (ch. 2.8). Separation of implementation and progress tracking (ch. 4.5). | Add conflict checks and project involvement to role descriptions. |
| Roles: risk | Risk analysis under 200-3; top management sets the basic conditions, the procedure is laid down in a guideline it adopts (200-2, ch. 8.5). In its preliminary work, 200-3 asks whether risks are assigned to risk owners (ch. 2). | A risk owner (Risikoeigentümer) per risk, usually the business process owner; with several processes, a lead risk owner. Risk owners authorise the implementation plan (ch. 4.2, Annex 3 no. 16 and 31). | The information owners under 200-2 (ch. 3.2.1) will usually become risk owners and authorise the implementation plan. |
| Documents: survey and planning | Framework conditions with business processes, stakeholders, internal and external factors and legal framework (ch. 3.2.1), security objectives, initial process inventory, scope, policy; minimum details on labelling, version and approval of documents (ch. 5.2.3). | The same topics as separate steps along ISO/IEC 27001 clauses 4 and 5: context, compliance management, interested parties, documented business processes with the minimum details of Annex 2, and expressly a document control procedure (ch. 2.1 to 2.9). | Reuse existing documents and arrange them along 300-1; add a compliance overview, bring the process list up to the Annex 2 minimum. |
| Documents: risk | Risk analysis guideline, threat overview, risk rating with a matrix of frequency and impact, risk treatment (200-3). | Freely chosen procedure meeting the 35 minimum criteria (Mindestkriterien) of Annex 3, including risk appetite, acceptance criteria, risk register with minimum content, time limit for temporary acceptance, annual review. 300-1 does not name 200-3; ISO/IEC 27005 and ISO 31000 are mentioned as possible bases (ch. 2.11). | Check an existing 200-3 guideline criterion by criterion against Annex 3. |
| Evidence: implementation status | IT-Grundschutz Check as target/actual comparison with the values "dispensable", "yes", "partially", "no", mainly through interviews and samples (200-2, ch. 8.4). | Implementation status (Umsetzungsstatus): "fulfilled", "not fulfilled", "not applicable"; every non-applicability is justified. Methods from interviews and document reviews to automated configuration checks and technical scans (ch. 4.1). | Resolve all "partially" entries. "Dispensable" because of alternative measures is not provided for in the new scheme. |
| Evidence: unfulfilled requirements | SHOULD: normally to be met; deviations to be weighed carefully and soundly justified (200-2, ch. 2.7). | MUST: no exemption, no risk acceptance. SHOULD temporary: justification; handling of the risk regulated differently in ch. 2.11 and 4.1.2 (open question of interpretation). SHOULD permanent: risk assessment, residual risk for management approval (ch. 2.11, 4.1). | Split the exceptions register by modal verb. If permanent non-fulfilments of SHOULD requirements accumulate, 300-1 says the state of the art may not be achieved overall and a certification could find a significant deviation (erhebliche Abweichung). |
| Evidence: assignment | Implementation plan with target object, module, requirement, measure, schedule, budget and owners (200-2, ch. 9.4). | Each measure with its requirement, date of implementation or check and the documenting or checking person. For automated checks: tool, time and result, report assigned to the requirement; history recommended (ch. 4.3). | Evidence is kept per requirement and can be fed from operational tools. |
| Evidence: monitoring | Review based on indicators and a maturity model, review of implementation (200-2, ch. 10.1). | Performance evaluation (free until uniform requirements exist), internal audit programme, management review, procedures for incident detection, vulnerabilities and new threats, validation of requirements (ch. 5). | Keep existing indicators but mark them as your own until the BSI requirements (announced for February and March 2027) are available. |
| Evidence: certificate | ISO 27001 based on IT-Grundschutz for standard and, in principle, core protection; basic protection is not sufficient (200-2, ch. 11). | ISO 27001 based on Grundschutz++, applications from 1 January 2027 according to the milestone plan (Meilensteinplan). Certifiability of classic IT-Grundschutz ends on 30 November 2031. | Align the timing of the switch with your own certification dates. |
Assessment: status, modal verbs and risk
The status logic is stricter. 300-1 requires the implementation status of every requirement to be checked in full and recognises only "fulfilled", "not fulfilled" and "not applicable" (ch. 4.1.1). "Not applicable" is allowed only if the requirement cannot be met functionally or if the underlying component does not exist in the information domain, and it must always be justified. In the build of 29 October 2026 the catalogue guidance on UMS.1.1 still describes, in principle, only "implemented" and "not implemented"; here the catalogue lags behind the standard.
For temporarily unfulfilled SHOULD requirements, 300-1 is not consistent: under ch. 4.1.2 a temporary non-fulfilment does not trigger a risk assessment, under ch. 2.11 a residual risk assessment and approval by top management are required for SHOULD requirements that are planned but not yet fulfilled. This is an open question of interpretation that you can clarify with your certification body.
The triggers for a separate risk assessment have shifted. Under 200-2 and 200-3 it was required, among other things, for high or very high protection requirements of a target object, for target objects that cannot be adequately modelled with modules, and for deployment scenarios not foreseen in IT-Grundschutz. Under 300-1 it is required 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 (ch. 2.11). The third trigger is new as an explicit case; 200-2 already required the risk associated with unfulfilled or partially fulfilled requirements to be determined and documented in a suitable form (ch. 8.4.3). The method is free but bound to the 35 criteria of Annex 3; a 200-3 procedure can meet them but must be checked, for example for risk appetite, risk owners and time limits on temporary acceptance.
What the comparison does not settle
- Relationship to 200-1 to 200-3: 300-1 does not mention these standards and does not say whether they will be formally withdrawn. According to the milestone plan, classic IT-Grundschutz remains certifiable until 30 November 2031.
- Basic and core protection: 300-1 does not describe these approaches. Whether equivalents will follow is open.
- BSI Standard 200-4: business continuity management under 200-4 is not replaced by 300-1. 300-1 mentions a BCMS only as a possible source for identifying business processes (ch. 2.5).
- Mapping old to new: the BSI provides a machine-readable mapping from the Compendium 2023 to Grundschutz++. It has the status "draft" (as of 21 July 2026, 1,185 mappings in two tables). Every mapping from it must be treated as a draft and checked.
- Catalogue version: the user catalogue is not yet aligned with 300-1 in every respect. Its guidance on UMS.1.1 still describes, in principle, only "implemented" and "not implemented", and its guidance on STM.2.1.5 says that requirements without a target object category that are not relevant are removed from the package with a justification, whereas 300-1 (ch. 3.4.1) requires them to be included. For the method, the standard applies: we recommend keeping such requirements in the package and, where they do not apply, recording "not applicable" with one of the two reasons in ch. 4.1.1, i.e. the requirement cannot be met functionally or the underlying component does not exist in the information domain.
How to move an existing ISMS in an orderly way is described on Grundschutz++ migration. What the standard requires chapter by chapter is on BSI Standard 300-1, and the relevant dates on Grundschutz++ timeline.