Starting point: what 300-1 says about migration
BSI Standard 300-1 contains no transition rules. It mentions neither BSI Standards 200-1 to 200-3 nor the IT-Grundschutz Compendium. According to its introduction (ch. 1), version 1.0 of 20 October 2026 is aimed „in erster Linie“ at „‚Early Adopters‘, also erfahrene Institutionen, die den Grundschutz++ zu einem frühen Zeitpunkt implementieren möchten“ (our translation: "primarily" at "early adopters, i.e. experienced organisations that want to implement Grundschutz++ at an early stage"). A migration is therefore project work: you decide which documents you carry over, adapt or rebuild, and you record this in a traceable way.
The time frame is set by the BSI milestone plan (as of October 2026). From 1 January 2027, applications for ISO 27001 certification based on Grundschutz++ can be submitted. Certifiability of classic IT-Grundschutz ends on 30 November 2031. That date concerns certification; it does not create a statutory deadline.
The catalogue is also still moving. In the user catalogue (Anwenderkatalog) of 29 October 2026, the guidance on UMS.1.1 still describes a two-value implementation status ("implemented", "not implemented"), while the standard knows three values. The guidance on STM.2.1.5 provides for deleting non-relevant requirements without a target object category from the package, while the standard requires them to be included. When migrating now, follow the standard and record the catalogue build with its date in every work package.
Dates at a glance: Grundschutz++ timeline. The changes between both methods: IT-Grundschutz vs. Grundschutz++.
Carry over or rebuild: document by document
"Carry over" means the content stays, is checked against 300-1 and supplemented where gaps exist. "New" means the result is produced under the new method, with the existing material serving as a data source.
| Existing document (classic) | Handling | Check under 300-1 |
|---|---|---|
| Information security policy (200-2 ch. 3.4) | carry over | Commitment of top management, specific and measurable objectives, strategy, security organisation; approval by top management (Institutionsleitung), communication to all staff (ch. 2.7) |
| Security organisation, roles (200-2 ch. 4) | carry over | Qualifications, avoidance of conflicts of interest (head of IT and information security officer, i.e. Informationssicherheitsbeauftragte/r or ISB; data protection officer and ISB), involvement of the ISB in security-relevant projects (ch. 2.8) |
| Framework conditions and scope (200-2 ch. 3.2.1, 3.3.4) | revise | Internal and external context (ch. 2.1), compliance (ch. 2.2), interested parties (ch. 2.4); define scope and information domain (Informationsverbund) separately (ch. 2.3, 3.1) |
| List of business processes (200-2 ch. 8.1.2) | carry over | Fields under Annex 2: identifier, name, owner, short description, main applications; the fields from 200-2 largely cover this |
| Structure analysis, network plan (200-2 ch. 8.1) | carry over as data source | Document dependencies according to the protection requirements of the process (ch. 3.2) |
| Protection requirements (200-2 ch. 8.2) | new | Per business process, two categories, approval by top management (ch. 2.6, 2.10); object ratings only as hints |
| Modelling with modules (Bausteine, 200-2 ch. 8.3) | new | Assignment to target object categories (Zielobjektkategorien) with inheritance, requirements package (Anforderungspaket, ch. 3.4); the old table supplies the asset list |
| IT-Grundschutz Check with "yes", "partially", "no", "dispensable" (200-2 ch. 8, 8.4) | reassess | Status "fulfilled", "not fulfilled", "not applicable" with justification (ch. 4.1.1); reuse existing evidence |
| Risk analysis under 200-3 | keep method, add framework | Method is free if the minimum criteria of Annex 3 are met (ch. 2.11); new triggers for an explicit risk assessment (Risikobetrachtung) |
| Implementation plan (Realisierungsplan, 200-2 ch. 9) | transfer | Each measure linked to requirement, date and documenting or checking person; assign evidence (ch. 4.3, 4.4) |
| Audits, management reports | carry over, extend | Internal audit programme (ch. 5.2), management review with the listed items (ch. 5.3) |
| Business continuity management under BSI Standard 200-4 | stays | 300-1 does not replace 200-4; under ch. 2.5 an existing BCMS can serve as a source for identifying business processes |
Ten work packages with sign-off points
The work packages follow the five process steps of 300-1. Where 300-1 requires approval by top management (Institutionsleitung), it is entered as the sign-off; the other sign-offs are our suggestion. Work packages 2 to 4 can partly run in parallel; package 5 requires the approved protection requirements.
| WP | Content | Result | Sign-off | 300-1 |
|---|---|---|---|---|
| 1 | Starting point and migration mandate | Inventory along the table above, migration plan, resource needs | Approval of resources by top management | ch. 2.10 |
| 2 | Context, compliance, interested parties | Documented influencing factors, list of obligations, stakeholders with requirements | Binding obligations defined with top management | ch. 2.1, 2.2, 2.4 |
| 3 | Scope and information domain | Scope, information domains, list of interfaces | Scope defined by top management | ch. 2.3, 2.10, 3.1 |
| 4 | Business processes and protection requirements | Process list under Annex 2, protection requirements per process, order | Approval of protection requirements and order by top management | ch. 2.5, 2.6, 2.10 |
| 5 | Asset recording | Assets with dependencies at the depth the protection requirements demand | Plausibility check by business units and IT | ch. 3.1, 3.2 |
| 6 | Requirements package | Assignment to target object categories, package with methodology requirements, requirements without a category, blueprints, additions, parameters | Review by the ISB, chosen blueprints documented with version | ch. 3.3, 3.4, 3.5 |
| 7 | Implementation status | Status per requirement, justifications for "not applicable", unfulfilled SHOULD requirements (SOLLTE) classified as temporary or permanent | Risks from planned, not yet fulfilled requirements reported to top management | ch. 4.1 |
| 8 | Risk framework and risk assessment | Risk appetite, acceptance criteria, roles, risk register, risk assessments for the mandatory cases | Framework authorised and residual risks approved by top management | ch. 2.11, 4.2, Annex 3 |
| 9 | Implementation plan (Umsetzungsplan) and evidence | Measures per requirement with owner, deadline, evidence | Approach approved by top management | ch. 4.3, 4.4, 4.5 |
| 10 | Monitoring, improvement and handover | Internal audit programme, management review, plan for validating requirements, nonconformity procedure with correction and improvement plan | Management review after the first cycle | ch. 5.1-5.5, 6.1-6.4 |
Implementation status: the most laborious part
The old IT-Grundschutz Check cannot be transferred one to one. It refers to module requirements, the new package to Grundschutz++ requirements, and the status values do not match. 200-2 knows "dispensable", "yes", "partially" and "no"; 300-1 knows only "fulfilled" (erfüllt), "not fulfilled" (nicht erfüllt) and "not applicable" (nicht anwendbar) in chapter 4.1.1, and the status of every requirement must be checked in full.
Three rules help with the transfer. An old "partially" becomes "not fulfilled" as long as the whole requirement is not met; the missing parts go into the implementation plan. An old "dispensable" only becomes "not applicable" if one of the two conditions in chapter 4.1.1 applies, i.e. „wenn die Anforderung funktional nicht erfüllt werden kann oder die zugrunde liegende Komponente nicht im Informationsverbund existiert“ (our translation: "if the requirement cannot be met functionally or the underlying component does not exist in the information domain"). An old "yes" is only a hint: check whether the earlier evidence covers the new requirement.
For temporarily unfulfilled SHOULD requirements (SOLLTE), 300-1 does not give a clear answer. Chapter 2.11 says: „Für SOLLTE-Anforderungen, die in der Umsetzungsplanung enthalten, aber noch nicht erfüllt sind, muss eine Restrisikobetrachtung durchgeführt werden.“ (our translation: "For SHOULD requirements that are included in the implementation plan but not yet fulfilled, a residual risk assessment must be carried out.") Chapter 4.1.2 says: „Eine temporäre Nichterfüllung löst keine Risikobetrachtung aus.“ (our translation: "A temporary non-fulfilment does not trigger a risk assessment.") How the two passages fit together is an open question of interpretation.
Evidence can be reused where it covers the new requirement. Chapter 4.3 requires evidence to be clearly assigned to the measure; for automated checks, the tool used, the time of the check and the result must be documented. Evidence filed per module is now assigned to measures and requirements.
Reusing a risk analysis under 200-3
300-1 leaves the risk method open as long as the binding minimum criteria (Mindestkriterien) of Annex 3 are met (chapter 2.11). The catalogue guidance on requirement GC.7.2 names ISO 27005, ISO 31000 and BSI Standard 200-3 as common bases. A 200-3 method can therefore still be used, but it must be checked against the minimum criteria, and the framework with risk appetite, acceptance criteria and roles is authorised by top management.
The triggers are new. Chapter 2.11 names three cases for an explicit risk assessment: high protection requirements of a business process for at least one protection goal, an asset that no target object category adequately covers, and a SHOULD requirement that is permanently not fulfilled. With normal protection requirements, no separate risk assessment is needed as long as neither of the other two triggers applies, because the user catalogue is based on a general BSI risk assessment; the residual risk assessment for planned but not yet fulfilled SHOULD requirements (see above) is a separate question. Under chapter 4.2.1, risks for a business process with high protection requirements are identified primarily at the level of the business process, with critical assets added where necessary.
The 2023 to Grundschutz++ mapping table as a checking aid
The State-of-the-Art Library (Stand-der-Technik-Bibliothek) contains a machine-readable mapping from requirements of the IT-Grundschutz edition 2023 to Grundschutz++. By our count it holds 1,185 mappings, 1,013 to technical and organisational requirements and 172 to methodology requirements. It has the status "draft" and is dated 21 July 2026. The mappings are typed as relationships such as subset, superset, intersection or equivalence.
In a migration the table is a checking aid for work packages 6 and 7: it shows which old requirements, and therefore which old evidence, may be relevant for a new requirement. It replaces neither the modelling nor the status check, and while it is a draft, every mapping must be marked as a draft.
Mistakes that make a migration vulnerable
- Protection requirements quietly downgraded. Setting former "high" ratings to normal needs a justification and approval by top management (ch. 2.10).
- Requirements without a target object category deleted from the package. 300-1 requires them to be included (ch. 3.4.1). If one of the two conditions in ch. 4.1.1 applies, they are kept as "not applicable" with a justification; otherwise they are "fulfilled" or "not fulfilled".
- Old "partially" carried over as "fulfilled". The status has no intermediate value (ch. 4.1.1).
- Catalogue build not recorded. The user catalogue changes continuously; without a date the package cannot be reproduced.
- Old scope taken over one to one as the information domain. 300-1 separates scope and information domain; interfaces are to be documented under ch. 3.1.
Support with the migration
Blackfort Technology supports migrations from the assessment of the existing ISMS and the migration concept to the implementation of the work packages; see IT-Grundschutz consulting. General ISMS and ISO 27001 consulting without a Grundschutz basis is described on https://www.blackfort-tec.de/en.