A final “Grundschutz++ migration guide” would promise more certainty than the official position supports on 2 August 2026. Germany’s Federal Office for Information Security (BSI) is developing Grundschutz++ as a new, process-oriented and machine-readable approach. The milestone plan dated 26 March 2026 sets the end of the pilot for 30 September 2026 and publication of the methodology for 27 October 2026.
Note: General professional guidance; not legal advice or a certification or audit guarantee.
Grundschutz++ is therefore relevant, but it is not yet a finished target operating model that organisations should simply roll out as binding. This interim period creates a management problem. Doing nothing may produce expensive rework later. Rebuilding everything too early may be equally costly if pilot feedback and the final methodology alter important details.
The defensible interim strategy is to make the ISMS migration-ready without destabilising current controls.
The real pain is semantic debt, not file format
Many Grundschutz environments hold extensive documentation: structural analyses, modelling records, control mappings, action lists, test protocols and policies. Yet essential relationships may only be understood by experienced individuals. Responsibilities sit in free text. Evidence is stored in folders whose logic is disconnected from the control model. Exceptions are approved by email. Object identifiers differ across the asset inventory, risk register and audit plan.
A machine-readable rule set will not automatically correct these weaknesses. Digitising inconsistent language merely creates inconsistency that software can process faster.
A hypothetical operating case exposes the semantic debt. The inventory calls a service “Central Directory Service”, the risk assessment uses “Identity Platform”, and the audit plan says only “IAM”. Three teams mean broadly the same thing, but no system can resolve the relationships reliably. When the knowledgeable owner is absent, apparently complete documentation becomes a search exercise. A migration would then have to reconstruct meaning rather than merely convert a format.
Migration readiness therefore begins with stable relationships. An object must remain recognisable when its name changes, a measure is revised or evidence is refreshed. Requirements, implementation, evidence and decisions may remain separate records, but their connection must not exist only in folder paths or individual experience. That semantic order is what makes later rules evaluable.
A PDF does not become a process because it lives in the process library. The mechanism is simple. A process needs triggers, roles, inputs, decisions, outputs and feedback. A document can describe those elements, but it cannot operate them by itself.
Semantic order is not a clean-up exercise for the ISMS team. It is an agreement between business functions, operations, risk management and audit. Each understands a different aspect of the service: its purpose, technical composition, accepted impacts or required evidence. If one perspective alone becomes the authoritative data model, mappings may look tidy while remaining unusable. One technical system may support several business processes; the same control may need different evidence or accountable roles depending on its use. Migration readiness represents these differences explicitly and routes changes through the affected roles.
A common management error is to fund data quality as a one-off cleansing project. A project team harmonises names, fills empty fields and delivers a green dashboard. Six months later, procurement, change management and organisational restructuring create new objects without applying the same rules. Management should therefore require a maintenance mechanism for identifiers, relationship approval, review triggers and quality deviations that require escalation. Only then does data cleansing become governance.
What the BSI currently announces
The BSI describes Grundschutz++ as a flexible, fully process-oriented redesign with minimum requirements. Requirements are intended to be captured as standardised rules that programs can interpret and evaluate. The “state-of-the-art” library is intended to replace the existing IT-Grundschutz Compendium and provide technical and organisational requirements. The BSI also envisages dynamic prioritisation, performance measurement and adaptable checklists. According to the official description, the existing assurance levels cannot be transferred to Grundschutz++.
This is an important direction, but it does not make current IT-Grundschutz obsolete overnight. The pilot feeds operational experience into further development. The milestone plan schedules publication of the methodology for 27 October 2026, the training concept for 31 October, the start of training for 1 November, applications for ISO 27001 certification based on Grundschutz++ from 1 January 2027, publication of performance measurement on 26 February 2027 and performance indicators on 31 March 2027.
Organisations should distinguish three levels:
- Current operating practice: existing ISMS and Grundschutz obligations, live audits, agreed evidence and the Compendium references needed until a controlled transition.
- Officially announced direction: process-oriented, rule-based, machine-readable requirements and more flexible prioritisation.
- Internal preparation: reversible improvements that remain useful regardless of final details.
Five low-regret steps towards migration readiness
1. Establish stable objects and ownership
Each relevant object—process, application, system, site, supplier or information asset—needs a stable identifier and an accountable owner. Reuse that identifier across inventories, risks, controls, evidence and action plans.
This is not a special Grundschutz++ requirement. It is sound governance, and it prevents a later migration from becoming a manual matching exercise.
In a bounded hypothetical test, start by assigning one business process a stable identifier. Do not rename its applications, systems, risks and evidence; connect them through that identifier. The exercise quickly reveals whether two functions define the same process differently or whether a system has a technical administrator but no accountable business risk owner. The resulting decision is concrete: harmonise the boundary, assign ownership, or record the difference deliberately. None of this requires a new platform.
2. Separate requirements from implementation details
Express the security outcome to be achieved separately from how it is currently implemented. A solution-independent requirement may be satisfied through several technical or organisational measures. The distinction supports later rule mapping, tool assistance and change control.
Do not discard current control and module logic prematurely. Structure it so that relationships can be exported and reviewed.
3. Treat evidence as a first-class control object
For each material control, identify the evidence that demonstrates operation and effectiveness, where it is stored, who provides it, which period it covers and when it must be refreshed. A screenshot without context or a test report without an object reference has limited reuse value.
Evidence metadata is particularly migration-safe. It improves current audits and future automation at the same time.
Suppose an audit team reviews a screenshot showing that a security setting is enabled. Without a timestamp, object reference, originator and test step, it is unclear whether the image represents production, a test environment or a state that has since changed. Add those metadata and a file becomes evidence that can be interpreted. The mechanism is unglamorous but effective: automation does not require more truth than people do; it merely has much less tolerance for missing context.
That produces a useful decision sequence. First define the assertion a control is expected to support. Then determine which evidence can support it and when that evidence expires. Only after those questions have answers does it make sense to choose manual, partly automated or automated collection. Starting with the tool can otherwise automate little more than the production of attractive files.
4. Make exceptions and risks decision-ready
A deviation should link to an object and requirement, carry a risk rationale and compensating measures, name an authorised decision-maker and have an expiry date. Free text may explain the decision, but it should not replace its structure.
Without an expiry date and review trigger, a temporary exception can become normal operations without being consciously decided again.
Assume, hypothetically, that a legacy application cannot yet satisfy one requirement in full. Its exception links to the affected object and requirement, describes compensating monitoring, and expires when the planned replacement is due. If the project slips, the decision reopens. Management can strengthen the interim control, restrict the remaining lifetime or prioritise replacement.
5. Test exportability before selecting a target tool
Organisations do not need to choose a Grundschutz++ tool today. They should test whether their current inventory, risk, action and evidence data can be exported in a structured form. Proprietary free-text fields and manual links are migration risks.
A practical test exports ten controls with their object, accountable owner, status, evidence and latest decision as a consistent structured dataset. Any failure identifies useful preparation work regardless of the eventual format of the BSI library.
A hypothetical operating case exposes the interactions
A medium-sized, explicitly hypothetical service provider selects “provision and revoke user access” for its readiness lab. The process uses a central identity platform, a ticketing system, an externally operated directory service and manual approvals for privileged roles. The current security concept describes all components. In practice, however, the business function, IT operations and Internal Audit maintain different lists of privileged accounts. Automated evaluation would not remove the disagreement; it would produce three conflicting answers at exemplary speed.
The lab starts with a stable process identifier and links systems, roles, requirements, measures and evidence to it. The first export shows that the ticketing system records the approver but not the business role on whose risk the approval is granted. The external provider’s monthly report does not align with the internal sample period. An old exception for technical accounts lacks both a current owner and a defensible end date. None of these gaps proves that the control is ineffective. Together, they prevent a traceable statement about what was controlled, for which period and under whose decision.
The organisational consequence is not an immediate tool replacement. The process owner confirms the boundary, operations maps the technical objects, risk management reopens the exception, and Internal Audit clarifies the assertion expected from the evidence. The same dataset is exported again. Management sees which relationships are reliable, which assumptions need manual confirmation, and which gap requires a decision. The case does not anticipate a perfect model; it creates the ability to expose ambiguity and resolve it under control.
A two-track roadmap until publication of the methodology
The first track stabilises current operations. Ongoing IT-Grundschutz work, audits, security concepts and improvement actions continue. Existing Compendium references and internal commitments remain traceable until a defensible transition to the methodology and “state-of-the-art” library has been approved; unchanged transfer of the existing assurance levels is not assumed.
The second track is a bounded readiness lab. Select one manageable information domain or business process. Harmonise identifiers, requirements, evidence metadata and exceptions. Record assumptions explicitly. Every change should be reversible and create value under today’s model.
The lab should not create a parallel world of special terminology and carefully selected showcase objects. Use a small but ordinary slice with real ambiguity: a process supported by several applications, one external service and at least one open action. This tests whether relationships can be exported, owners use terms consistently, and a change can be traced from requirement to decision. If the test fails, that is not a project failure. It is the early finding the lab was intended to produce.
The approval boundary remains clear. The lab may test a data model and way of working, but it must not claim final Grundschutz++ conformity or replace current Grundschutz commitments. Its outputs are hypotheses with documented origins. Once the methodology is published, test them against the official position; only confirmed relationships should become the basis for a wider migration.
After the pilot and planned publication of the methodology, run a formal delta assessment. It records confirmed assumptions, missing data fields and relationships, reusable artefacts and elements that must be rebuilt. Only then decide on the target architecture, tools, training and migration waves.
To prevent that decision from being overtaken by the momentum of an existing programme, the lab needs measurable stop and scale criteria from the outset. Scaling is plausible when selected relationships remain stable in routine maintenance, the export is reproducible, and current audit or control work demonstrably benefits. A stop or correction is appropriate when special fields proliferate, terminology works only inside the lab, or operational teams have to maintain parallel records. These are not minor technical concerns. They determine whether later scaling reduces work or merely creates a second layer of truth.
The investment logic changes accordingly. Before publication of the methodology, budgets should be tied to learning objectives, reversibility and current value rather than claims of future conformity. After the formal delta assessment, investment can follow confirmed reuse: durable data relationships and roles first, necessary process change second, then tooling and training. That sequence reduces the risk of transferring organisational ambiguity into software.
What management should not approve yet
An enterprise-wide big bang based on previews and presentation slides is not justified. Premature certification promises, blanket replacement of the current compendium, and buying a tool without a testable data model are equally risky.
What management can approve are bounded, reversible actions: data cleansing, ownership clarification, evidence metadata, structured exceptions, export tests and a defined decision point after publication of the methodology.
Review criteria for management approval
- The BSI milestone plan dated 26 March 2026 and pilot status on 2 August 2026 are documented.
- Current Grundschutz and ISMS activities continue without a governance gap.
- Core objects have stable identifiers and accountable owners.
- Requirements, measures, evidence and decisions are separated but linked.
- Exceptions have expiry dates and review triggers.
- Relevant data can be exported in a structured form.
- The readiness lab remains small, reversible and useful under the current model.
- A formal delta and investment decision is scheduled after 27 October 2026.
- The programme avoids pre-empting final methodology or certification outcomes.
Conclusion: the A-R-C impulse
Grundschutz++ should neither be ignored nor presented as complete before the official work is finished. The robust position in between is migration readiness: better data relationships, clear ownership, auditable evidence and reversible experiments.
The A-R-C impulse: export ten core controls with object, requirement, measure, owner, evidence and latest decision. Mark every relationship that exists only in one person’s head. Those gaps are the most useful preparation scope. This is how information security becomes controllable, auditable and management-ready—today and for a later migration.
Scope and limitations
This article is a professional governance assessment based on the BSI milestone plan dated 26 March 2026 and checked on 2 August 2026. It is not legal advice, a binding BSI interpretation or certification advice. It guarantees neither migration compatibility nor certification success. Final decisions should follow review of the published methodology and the organisation’s own circumstances.
Sources
- BSI, “Grundschutz++ – redesign of Grundschutz”, including milestone plan dated 26 March 2026, accessed 2 August 2026: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Grundschutz-in-der-Informationssicherheit/Grundschutz-Plus-Plus/grundschutz-plus-plus_node.html
- BSI, “IT-Grundschutz-Kompendium”, official entry page, accessed 2 August 2026: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/IT-Grundschutz-Kompendium/it-grundschutz-kompendium_node.html
- BSI, “Grundschutz in information security”, official overview, accessed 2 August 2026: https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/Grundschutz-in-der-Informationssicherheit/isms_node.html
About the author
Andreas Rühl supports organizations as an interim CISO and ISMS/GRC advisor. His focus is making information security manageable, auditable and fit for management decisions.