Grundschutz++ and BSI Standard 300-1: Methodology, user catalogue and the path to certification

Three components, one body of rules

The BSI provides Grundschutz++ for introducing an information security management system. The methodology is described in BSI Standard 300-1; according to the BSI, it gives users room for manoeuvre, for example with regard to the size of the organisation and the complexity of the information domain. The user catalogue complements the methodology: the BSI has transferred its normative aspects into requirements, so that the catalogue comprises all Grundschutz++ requirements – those of the methodology as well as the technical and organisational ones. It is provided in the State-of-the-Art Library, the technical platform on which the BSI publishes requirements and measures centrally and in machine-readable form. Because the requirements are available in machine-readable form, checking them can be automated; according to the BSI, digital tools are to support implementation in future.

What GS++ replaces – and what remains for now

According to the BSI, the State-of-the-Art Library replaces the IT-Grundschutz Compendium. As an evolution of IT-Grundschutz, the user catalogue only describes requirements that are not aimed at specific IT solutions; according to its description, the Kernel catalogue, from which the 901 technical and organisational requirements originate, contains exclusively technology- and vendor-neutral security requirements. Product-related modules, such as those the Compendium Edition 2023 contained for “Windows Server 2012” or “Clients under macOS”, therefore have no product-specific counterpart in the user catalogue; for such systems, the solution-neutral requirements of the appropriate target object categories apply. Instead of 111 modules in ten layers, the catalogue is structured into 20 practices; target object categories determine which requirements apply to an asset. In our view, the requirement counts of the Compendium and the catalogue are therefore only comparable to a limited extent, and the BSI, too, does not regard its mapping of the Compendium to GS++ as a 1:1 correspondence but as an orientation aid; as of 21/07/2026, it is marked as a draft. For the time being, IT-Grundschutz remains certifiable: according to the milestone plan, certifiability ends on 30/11/2031, five years after the publication of GS++. Applications for certification to ISO 27001 based on GS++ are intended to be possible from 01/01/2027; the early adopter phase is planned from the first quarter of 2027 until 31/12/2027. The BSI states that it adjusts the milestone plan on an ongoing basis.

Binding force: federal administration and NIS2 entities

For the entities of the federal administration, the BSI Act, as revised by the NIS2 Implementation Act of 2 December 2025, prescribes minimum requirements that derive from the BSI standards, the Grundschutz Compendium – together referred to in the Act as “IT-Grundschutz” – and the BSI minimum standards for the federal administration. Fulfilment must be demonstrated to the BSI no later than five years after the Act enters into force, which according to the BSI means 2030; those who implement the minimum requirements thereby also fulfil the statutory risk management requirements, unless an EU implementing act goes beyond them. The same Act tasks the BSI with modernising IT-Grundschutz by 1 January 2026, and the user catalogue refers in its metadata to precisely these requirements for the federal administration. None of the primary sources evaluated for this page explicitly specifies from when GS++ counts as the authoritative version for the purposes of this obligation. For particularly important entities and important entities, the BSI Act does not mention IT-Grundschutz: their measures are to comply with the state of the art and take into account the relevant European and international standards. In our view, GS++ is a possible route for them, not a prescribed one.

Structure: six chapters, four annexes

Target group, development, announced additions

In the change history, version 1.0 bears the date 20/10/2026 and the note “Initial publication of the first applicable version”; it names “S 13” as author, which according to the BSI's organisation chart is the unit “IT-Grundschutz und Mindeststandards” (IT-Grundschutz and Minimum Standards). According to the milestone plan, the standard was presented at it-sa in Nuremberg on 27/10/2026 and made available to the community for application. The target group is primarily early adopters, i.e. experienced organisations that introduce GS++ early and whose experience feeds into its further development. The methodology was developed together with the Grundschutz community and tested in selected pilot organisations; the pilot phase ran from 1 April to 31 August 2026. The “Leitfaden zur Methodik Grundschutz++” (Guide to the Grundschutz++ Methodology) from this phase is still available, but the standard is authoritative. Several items have so far only been announced by the BSI: training concepts for GS++ practitioners and GS++ consultants by 30/11/2026, an application example based on the fictitious sample authority “BDIT” in December 2026, the concept for performance measurement by 26/02/2027 and performance indicators for each requirement of the methodology practices by 31/03/2027.

Five process steps, four PDCA phases

The standard describes; it becomes binding through the catalogue: the BSI has transferred the normative content of the methodology into requirements and structured them in methodology practices. These 99 requirements apply to all organisations and are to be applied to every information domain; “an individual approach is not provided for”. How strict an individual obligation is depends on the modal verb in the user catalogue: 80 of the 99 methodology requirements are MUST, 19 SHOULD, none is MAY. The standard text and the catalogue do not always place the same emphasis. In several places, the standard formulates a recommendation where the catalogue requires MUST; for the residual risk of open SHOULD requirements, it is the other way round. VamiSec recommendation: Plan along the catalogue requirements and use the standard text as an explanation.

Context, compliance and scope

The context analysis captures factors that act on the organisation from outside – geopolitical; legal and regulatory, such as NIS2 or DORA; technological, such as the use of AI; economic, such as supply chain dependencies; societal; and ecological and physical, for example a location on a river – as well as factors from within: strategies and objectives, structure, established processes, the IT landscape without a detailed inventory, the organisational culture and attitude towards security, and resource shortages. Compliance management contributes the legal register, laws and requirements catalogues, internal rules as well as statutory and contractual obligations; whatever results from these is taken into account in the requirements set. Top management defines the scope: business processes, each in its entirety, the relevant organisational units, sites, applications and IT systems, plus the demarcation from external partners and service providers and, where applicable, excluded areas. Interested parties such as customers, service providers, supervisory authorities, employees or staff representative bodies are recorded together with their expectations; together with top management, it is determined which binding obligations are incorporated into the ISMS as requirements.

Business processes: as simple as possible, as precise as necessary

The business processes within the scope must be identified and documented; this also covers administrative and specialist procedures. They are the basis for the protection needs determination, asset recording and risk analysis. According to the standard, it is sufficient for the documentation that the purpose of the process is recognisable in relation to the organisation's objectives. Sources are process maps and existing management systems such as a BCMS or a data protection management system (DSMS), and for public authorities their statutory mandates. If such overviews are lacking, the simplified business process analysis from the annex of the standard helps; it is deliberately designed as a minimum requirement: neither comprehensive process management nor detailed process documentation is required.

1. 1
   Examine workflows

   A business process is repeated regularly or as occasion requires, is essential for the organisation's mandate or services, leads to a traceable result and consists of several activities that are related in substance. Individual work steps are not business processes; an overly fine breakdown should be avoided.

2. 2
   Use existing sources

   Organisation charts and schedules of responsibilities, tasks set by law or by the articles of association, the record of processing activities, application and system overviews from the CMDB, process registers, ISMS tools as well as overviews of contracts and service providers. Talking to the responsible persons can be particularly helpful.

3. 3
   Document five items

   Identifier, name, the person, role or organisational unit with functional responsibility, short description and key applications. The short description must make the purpose, the main result and the contribution to the organisation's objectives recognisable; the form – table, process register, wiki or ISMS tool – can be chosen freely.

Policy, security organisation and approval

The information security policy is the central document of the ISMS: it describes concrete and measurable objectives, for example according to SMART, and the strategy, sets out the commitment and responsibility of top management, is approved by top management and must be communicated to all employees. An information security organisation with defined roles and responsibilities is “strictly required”. Conflicts of interest, for example between the head of IT and the ISB or between the data protection officer and the ISB, are to be avoided, and the ISB or another role of the security organisation must be involved in security-relevant projects. Procedures for internal and external communication and for the control of at least all ISMS-relevant documents must be established. Responsibility for the ISMS lies with top management and “cannot be delegated”; top management receives decision papers on scope, protection needs, the order of the business processes, resources and the policy. Finally, the organisation initiates the risk analysis: risk appetite and risk acceptance criteria at the strategic level, procedures and criteria at the methodological level, roles including risk owners at the organisational level – top management authorises the framework.

In the protection needs determination, a decision is made for each recorded business process as to what protection needs it has with regard to the basic values of confidentiality, integrity and availability. The information processed in the process is to be used as the basis; what matters is the damage that may be associated with an impairment. Protection needs are to be determined and documented individually for each process, and top management approves them. The user catalogue makes the procedure and the classification MUST requirements and relates them to “business processes or information”; the classification takes the business objectives into account and is made in consultation with top management. According to the guidance text, a process is to be classified as high if there is a danger of existence-threatening financial or reputational damage or of serious consequences for business objectives or existing obligations, and likewise if it processes information classified as particularly confidential.

Five damage scenarios as an aid for “high”

• Violation of laws, regulations or contracts with existence-threatening consequences for the organisation
• Impairment of the right to informational self-determination that leads to considerable reputational damage
• Impairment of a person's physical integrity
• Negative internal or external impact that lastingly damages the organisation's reputation
• Financial impact on an existence-threatening scale

The organisation may optionally define additional categories of its own, but must map them to the two GS++ categories; for a certifiable ISMS, the state of the art must always be complied with in the lowest category. For the initial implementation, the standard recommends starting with the most important business process of the highest protection needs category – if there are several, top management chooses – and then successively examining all processes within the scope. The BSI relates the published state of the art to typical processing situations. In atypical situations or in the case of increased protection needs – government-classified data and special categories of personal data under the GDPR are mentioned – further protective measures may be necessary.

From protection needs to security level

Each requirement carries one of two security levels: normal-SdT, the standard security level, or elevated. Which requirements are selected depends on the protection needs of the business process under consideration. According to the standard, requirements of the elevated level contain the modal verb MAY and are optional to fulfil; they can be drawn on in the risk analysis to identify further measures, for example in the case of increased risk. In the catalogue of 22/10/2026, this applies to 224 of the 227 elevated-level requirements; three carry SHOULD. As a SHOULD requirement, the user catalogue provides for reviewing the initial classification of the security levels if the organisation's context deviates – according to the guidance text, especially in the case of high protection needs; it can also be changed for individual assets. The catalogue's guidance text explicitly names a downgrade from elevated to normal-SdT as a reason for a risk analysis.

Scope and information domain

The scope defines the formal and organisational extent of the ISMS; the information domain is its substantive and technical representation. A scope can contain one or more information domains; an information domain can cover the entire scope or individual areas divided according to organisational structure, shared business processes or applications. Assets are all tangible and intangible items of value that are needed for the business processes under consideration, such as applications, IT systems or rooms. A clear delimitation ensures that all relevant information, assets and dependencies are recorded; the recorded assets are a prerequisite for the requirements set. The user catalogue expresses this in two MUST requirements: define the traceably delimited information domain on the basis of the scope of application, and define its interfaces to external processes.

Relevant assets can in particular be business processes, information, systems and applications, network and communication components, infrastructural and physical assets, and personnel and organisational assets. For the documentation, the organisation can draw on existing asset registers and digitally recorded system data; the interfaces to external processes and systems or to other information domains are to be documented unambiguously in organisational, technical and infrastructural terms. The order of recording follows the prioritisation from the protection needs determination; assets with similar characteristics and a similar purpose may be grouped. The user catalogue requires as a MUST that all relevant assets of the business processes under consideration be defined; according to the guidance text, the assets of the most important business process suffice in the first PDCA iteration. For each asset, it provides for a unique designation, a short description with its purpose, the assignment to business processes and a responsible role or an asset owner.

Dependencies: depth according to protection needs

According to the standard, existing sources such as CMDBs, asset registers, operating manuals, network plans or service maps can be used for this representation in order to avoid duplicate work. What matters is that the essential dependencies are documented traceably, because the risk analysis for high protection needs starts at the level of the business process and follows the resource path. For processes with normal protection needs, the standard requires at least two types of relationship. The assets are then assigned to the target object categories.

Practices: thematic structure in three categories

According to the standard, practices serve to aid understanding: they group the requirements thematically and are divided into the categories Methodology, Organisational and Technical. With 99 requirements, the six methodology practices form the management framework and carry no target object category. The eight organisational and six technical practices contain 901 requirements; each of them begins with the subgroup “Fundamentals” and is then structured thematically – 103 subgroups in total, while the catalogue as a whole has 140. The BSI's definitions of each practice clarify the boundaries, for example that the Monitoring and Evaluation practice corresponds to the Check phase of the PDCA cycle, that Improvement concludes the cycle and at the same time initiates a new one, and that Detection leaves the handling of detected events to Security Incident Handling.

A pattern helps when reading: the 14 technical and organisational practices contain only 69 MUST requirements, and all of them are in the subgroup “Fundamentals”. In every practice they form the same process framework – establishing and documenting procedures and rules, assigning the associated tasks, informing those responsible and reviewing the rules regularly and on an event-driven basis; in the Awareness practice, a SHOULD requirement on measuring success takes the place of the review. The remaining 832 requirements of these practices are SHOULD or MAY, and MAY requirements belong without exception to the elevated security level. In our view, this makes SHOULD the actual benchmark of GS++: a deviation has to be carefully weighed and soundly justified, and permanent non-fulfilment triggers a risk analysis.

Target object categories: parent nodes and child nodes

The hierarchically higher nodes are called parent nodes, and the nodes subordinate to them child nodes. Requirements at the top level of a branch are mostly conceptual in nature, for example “establish procedures”; every category is defined in the annex of the standard, most of them additionally with examples, and every identified asset can be assigned to at least one category. Inheritance is decisive: all higher-level categories are also to be assigned to an asset, and only the direct and the higher-level categories together yield its requirements. A SaaS service recorded under Cloud Services thus inherits the requirements of Outsourcing, Services and Purchases – 9 direct ones plus 29, 31 and 39, 108 in total. The user catalogue makes assignment, inheritance and consolidation MUST requirements: assignment is function-oriented, i.e. based on how the asset acts in the business process; requirements that take effect multiple times are listed only once; and assets that are difficult to assign are analysed in the risk analysis.

Three types of requirement

The standard presents the path to the requirements set as a chain: business process with normal or high protection needs, assets, target object categories, requirements, requirements set – and, for high protection needs, the risk analysis. Each asset gives rise to organisational, technical, personnel and infrastructural specifications; requirements that apply across several assets of the same category appear only once in the requirements set. For requirements without a target object category, the texts differ: the standard requires that they be included on a mandatory basis, while the catalogue's guidance text provides for a relevance decision for each requirement and the justified removal of requirements that are not relevant. VamiSec recommendation: follow the standard, include all of them and, in the Implementation step, record requirements whose component does not exist in the information domain as “not applicable” with a documented justification – this keeps the approach traceable under both texts.

Blueprints: provided for, but not yet published

According to the standard, a blueprint is a prefabricated catalogue of requirements which, unlike the user catalogue, is tailored to specific application scenarios, makes a preselection and specifies the parameters. Blueprints can be assigned to groups of assets or to individual assets and combined; the selection including the version, the assignment and the adaptation are to be documented traceably, gaps are to be closed with further blueprints or requirements, and the selection is to be reviewed when the information domain or the available blueprints change. There may be mandatory blueprints for certain organisations; the standard does not say which ones. As of 29/10/2026, no artefact in the State-of-the-Art Library is designated as a blueprint. Published items include the profile “Stand der Technik WLAN” (State of the Art WLAN) with 48 selected requirements and three preset parameters such as “WPA3”, and a supply chain security profile with 146 requirements without preset parameters; the BSI does not say whether they count as blueprints. The BSI has presented a blueprint concept to a community working group as an alpha version for comment; it is not publicly available.

Custom requirements and design decisions

If an asset cannot be adequately represented with the existing requirements, or if obligations arise from compliance management or stakeholder analysis, the standard recommends developing supplementary requirements; the user catalogue turns both into MUST requirements. For assets without suitable requirements, the guidance text provides for documenting the assets concerned, justifying why the GS++ requirements are not sufficient, formulating new requirements related to the protection goals where necessary, adopting them permanently into the requirements set and submitting them to the BSI. The standard does not specify the “format provided for by GS++” for custom requirements; in our view, the sentence template on which all catalogue requirements are built lends itself to this: practice, target object category where applicable, modal verb, result, optionally a result specification, and an action word – for example “Information and Assets for IT Systems SHOULD document the maintenance needs for system components and the infrastructure required for operation”. The catalogue uses 27 action words, most frequently “establish”, “document” and “activate”, and names a recommended documentation type for 961 requirements.

The organisation makes design decisions via parameters: variable elements such as “regularly” that show auditors and users where there is latitude and can be used for automated checking. They are specified during or after the creation of the requirements set; the user catalogue requires as a MUST that concrete values be assigned – according to the guidance text, for example “daily”, “weekly” or “monthly” instead of “regularly”, or the persons and roles to whom each technical and organisational practice assigns the tasks in its “Fundamentals” subgroup. The catalogue contains 223 parameters in 210 requirements. The profile of the user catalogue sets only two of them: the standard for the ISMS, “BSI Grundschutz++”, and the one for a BCMS, “BSI-Standard 200-4”; all other values are determined by the organisation unless a blueprint specifies them.

Implementation status: three values, checked in full

For every requirement in the requirements set, the current implementation status must be checked in full. The standard provides for three values: “fulfilled”, “not fulfilled” and “not applicable”. The third value is subject to conditions: a requirement can be considered “not applicable” if it cannot be fulfilled functionally or if the underlying component does not exist in the information domain; the justification is to be documented. The determination should follow a structured procedure, which can range from interviews and document reviews to automated configuration checks and technical scans; the requirements with the normal-SdT security level are to be checked first. In the user catalogue, the status check is a MUST requirement – complete and regular – with the organisation setting the interval as a parameter. The guidance text there only uses “implemented” and “not implemented” and adds a rule that the standard does not mention: a requirement is only deemed implemented once all requirements that are in a dependency relationship with it have also been implemented.

Implementation plan: every measure tied to its requirement

A structured implementation plan is created from the requirements set. It defines concrete measures for each requirement and prioritises them; as example criteria, the standard names the effort of the underlying requirement, synergies between measures, the level of the risks, strategic importance and quick wins with high effectiveness. As a general rule, it recommends implementing the requirements of the parent nodes first. For each requirement, it must be clearly identifiable which measures are assigned to it; if a measure addresses several requirements, all assignments are to be shown, as are dependencies. For each measure, at least the associated requirement, the date of implementation or review and the person documenting or reviewing it are to be recorded. Responsibilities and realistic deadlines should be documented in a suitable form, for example in a project management or ticketing system; top management approves the approach because it has to provide the resources. Progress must be tracked continuously, and a possible conflict of interest between implementation and progress tracking is to be prevented by an appropriate allocation of roles.

Evidence, automated checking and history

Evidence used as a basis for assessment is to be assigned unambiguously to the respective measure so that implementation can be traced. For automated checks, the tool used, the time of the check and the result belong in the documentation; if the tool generates a check report, it is assigned to the measure and the requirement. If the assignment, implementation progress or check result changes, the documentation is to be updated, and for traceability the standard recommends a history with at least the time, the responsible person and the tool used. The guidance text on approving the implementation planning lists the content an implementation plan typically contains: from requirement description, target object, responsible party, deadlines and priorities, through risks with justification, resources and dependencies, to the approval date and the signature of the risk owner. The State-of-the-Art Library provides for a dedicated Assessment Layer for machine-readable check results; no artefacts have been published there yet.

When an organisation needs its own risk analysis

The user catalogue is based on a general risk analysis by the BSI that assumes a typical threat landscape; users with normal protection needs therefore do not have to carry out a risk analysis of their own. An explicit risk analysis is required if a business process has high protection needs for at least one protection goal, if an asset relevant to the information domain is not sufficiently covered by the target object categories and their requirements, or if an applicable SHOULD requirement is not fulfilled for the foreseeable future or permanently. In the user catalogue, these triggers are framed as MUST requirements: a dedicated risk analysis for business processes or information with high protection needs, and a risk analysis whenever the methodology calls for one. The associated guidance text additionally names the downgrading of the security level from elevated to normal-SdT, an occasion that the standard itself does not list. The organisation itself chooses the procedure for identification, evaluation and treatment, for example on the basis of ISO/IEC 27005, ISO 31000 or BSI Standard 200-3, as long as the minimum criteria for risk analysis are met. Among other things, these criteria are intended to make the method comparable and verifiable in the context of a certification.

Roles and approvals: who authorises what

Elementary threats: the link between the BSI's derivation and your own analysis

The 47 elementary threats G 0.1 to G 0.47, from fire to harmful side effects of IT-supported attacks, describe fundamental events, circumstances or actions at an abstract level. They are product- and technology-neutral, compatible with international standards, assigned to the basic values of confidentiality, integrity and availability, and aimed at realistic dangers; a missing or inadequately implemented security measure is, in principle, not an elementary threat. In GS++ they have two functions: they are a basis on which the BSI derived the requirements of the catalogue, and they serve users as the starting point for their own risk analyses. The link is visible in the catalogue. The 901 Kernel requirements carry G0 identifiers, all 47 threats occur, and the requirements of the methodology practices have none. For permanently unfulfilled SHOULD requirements, the assigned threats must be taken into account; in practice, the analysis of such a gap therefore begins with the G0 identifiers of the requirement concerned.

Performance evaluation: mandatory, but still without uniform specifications

A performance evaluation is required to review the effectiveness of the ISMS and its objectives. Because uniform specifications for this have yet to be developed in GS++, organisations are free to decide how to design it; the results should be presented to top management in a traceable manner. Free does not mean optional: as MUST requirements, the user catalogue demands procedures and rules for measuring and evaluating ISMS performance, the regular review and updating of the implementation plan, and a regular check of whether the requirements are still up to date. According to the milestone plan, the BSI intends to close the methodological gap in 2027: by 26/02/2027, the concept for performance measurement is to be integrated into the methodology and ready for application, and by 31/03/2027, every requirement of the methodology practices is to have performance indicators.

Audit, management review and monitoring

According to the standard, the internal audit serves the purpose of self-review: its focus is not on revealing nonconformities but on identifying opportunities for improvement. When planning, the audit programme objectives must be defined first; among other things, they should take into account the information security requirements, the performance of detection and security incident handling, the identified risks, the processes, the maturity of the ISMS and previous audit results. The risks of the audit programme itself must be identified and evaluated, including measures for confidentiality in the audit. Scope and frequency should be based on the number of information systems, sites and persons affected, the complexity of the ISMS and the significance of the risks; audits can take place on site, remotely or in combination, and the selection of the audit team should ensure objectivity and impartiality. In the management review, top management examines on the basis of the management report whether the ISMS is suitable, adequate and effective, with regard to audit results, performance evaluation, security incidents, the status of risk treatment, changes in the organisation or the threat landscape and the status of previous decisions. For monitoring, three procedures must be established; added to this is the regular validation of requirements:

• Detection of security incidents with early identification and reporting, ranging from manual processes to automated detection systems depending on the size and complexity of the organisation.
• Handling of vulnerabilities: identify, evaluate, treat and track them systematically, with feedback into the risk analysis.
• Recording of and response to newly emerging threats, likewise with feedback into the risk analysis.
• Validation of the requirements in the event of changes in the information domain, the State-of-the-Art Library, blueprints in use or the GS++ methodology, coordinated with the responsible organisational units and, where necessary, with adjustment of the requirements set.

Improvement: from finding to corrective and improvement plan

If requirements are not fulfilled to the intended extent, there is a deviation. Nonconformities are systematically recorded and examined for their causes, not only the immediate ones but also the underlying ones. This includes estimating how likely and how consequential a recurrence would be, looking at similar cases in other areas and asking whether there is a systemic weakness in the ISMS. Opportunities for improvement arise from, among other things, the threat landscape, the effectiveness of the implementation plan, audit results, security incidents and suggestions from employees; they should be evaluated according to risk reduction, resource expenditure, strategic importance, synergies and sustainability. The corrective and improvement proposals must be embedded in a corrective and improvement plan, which is prioritised according to resources, quick wins and the greatest potential for improvement and incorporated into the implementation plan. The evaluation then uses measurable criteria, tests or audits to check whether the measures are effective. Identified vulnerabilities and changed threat landscapes trigger a new cycle of risk analysis, and the loop back to the implementation plan of the Implementation step is closed.

Modal verbs, security levels and links to target object categories

Effort levels: how much work the BSI expects

What has changed since April 2026

The shifts mainly affect the methodology practices: subgroups there have been dropped or merged, ten of the twelve dropped requirements come from the methodology, and five methodology requirements were raised from SHOULD to MUST. In total, eleven requirements changed their modal verb; besides these five, four rose from MAY to SHOULD, and one each fell from SHOULD to MAY and from MUST to SHOULD. Most of the newly added requirements belong to the Access Rights practice (BER). More important in practice than any single figure is the insight behind them: IDs are position-dependent and can change between catalogue versions; the UUID is stable. A pure comparison of IDs would show significantly more new and dropped requirements than actually exist. Anyone who bases implementation status, mappings or Statements of Applicability on requirement IDs should therefore reconcile every new catalogue version via the UUIDs; in our view, this is a basic function of any GS++ tool. Further figures at a glance:

• Largest practices: KONF with 157, BES with 109, BER with 92, SENS with 87, DET with 82 and GEB with 75 requirements; the six methodology practices together comprise 99 requirements, of which 80 are MUST and 19 SHOULD.
• Most frequent documentation types: configuration history with 183, IT operations concept with 116, procurement criteria with 70, detection concept with 61, and work instruction and training plan with 60 mentions each.
• The most frequent parameter label is “regelmäßig” (regularly), with 68 occurrences; the profile of the user catalogue sets only two of the 223 parameters, and the organisation specifies all the others.
• Most frequent elementary threats: G 0.18 with 385, G 0.23 with 142, G 0.30 with 130, G 0.36 with 110, G 0.19 with 98 and G 0.39 with 95 assignments.
• Inheritance along the target object categories increases the volume per asset: an asset in the Cloud Services category is directly assigned 9 requirements; including the parent categories Outsourcing, Services and Purchases, there are 108.
• Sentence template: 27 different action words, most frequently “verankern” (establish) with 137, “dokumentieren” (document) with 100 and “aktivieren” (activate) with 78 requirements.

The State-of-the-Art Library

According to the BSI, the State-of-the-Art Library is the technical platform on which all requirements and measures are provided centrally; it replaces the IT-Grundschutz Compendium, and the Grundschutz++ user catalogue is part of it. The BSI states that the repository BSI-Bund/Stand-der-Technik-Bibliothek has been public since 29/09/2025 and is published under the CC BY-SA 4.0 licence. Since the switch to a layer structure on 27/07/2026, the BSI has been publishing updates as an automated “rolling publication” at varying intervals; up to the editorial cut-off on 29/10/2026, the most recent was on 23/10/2026. The format is OSCAL, the Open Security Controls Assessment Language of the US NIST; the BSI justifies this choice by not having to develop its own national solution and by increasing compatibility with international security standards. Formally, the BSI page “Stand der Technik” (State of the Art) still describes the library as being in its pilot phase.

What each requirement contains

• ID and UUID: according to the BSI's “Handbuch für Autoren” (Handbook for Authors) for the State-of-the-Art Library, the ID is position-dependent and can change during restructuring, while the UUID remains tied to the meaning of the requirement. Between April and October 2026, 157 requirements received a new ID.
• Sentence template made up of practice, target object category where applicable, modal verb, result and action word. According to the same Handbook for Authors, provisions must be worded so that an independent third party can check with a yes or no whether they are fulfilled.
• Metadata: security level, effort level and, where assigned, target object categories, documentation type and keywords; Kernel requirements additionally carry relevance values 0 to 2 for confidentiality, integrity, availability and authenticity as well as the G0 identifiers of the elementary threats.
• Parameters as fill-in-the-blank text for design decisions, such as “regularly”. Profiles can set values or narrow them down; the profile of the user catalogue sets only two, including “BSI Grundschutz++” as the standard for the ISMS.
• Links to related and prerequisite requirements, as well as guidance texts that explain a requirement and give implementation examples.

Mappings: bridges to ISO/IEC 27001 and the IT-Grundschutz Compendium

For reading, the README of the BSI repository recommends the “Stand-der-Technik-Viewer” (State-of-the-Art Viewer), a browser application from the community organisation bsi-community. It displays catalogs, component definitions and mappings on the client side, filters by attributes such as security level, effort, target object category, modal verb or threat, and automatically adds the parent categories when a target object category is selected. According to the BSI, numerous vendors of IT-Grundschutz tools are working on integrating the OSCAL data. The limitations should be clear: according to the BSI, OSCAL catalogs do not automate implementation and do not replace the expert on-site review, the Assessment Layer is still empty, and no artefact designated as a blueprint has been published so far. The profiles for supply chain security with 146 requirements and for WLAN with 48 requirements are selections from the Kernel; the BSI does not designate them as blueprints.

System certification: what is settled and what is open

What is settled: from 01/01/2027, applications for certification to ISO 27001 based on GS++ can be submitted. In its announcement on the publication of the standard, the BSI describes an ISMS implemented according to Grundschutz++ as certifiable from 2027 and compatible with ISO/IEC 27001. What remains open is the audit procedure: an auditing scheme for GS++ has not been published. According to the BSI programme for it-sa, a talk by the BSI's certification body entitled “Ausblick auf die Zertifizierung nach Grundschutz++” (Outlook on certification according to Grundschutz++) had been announced for 28/10/2026; it was to present current considerations on the auditing scheme, including the challenges concerning audit objects and audit criteria. The applicable documents for ISO 27001 certification based on IT-Grundschutz, i.e. audit basis 4.8, certification scheme 2.2 and auditing scheme 2.5 of 01/02/2026, refer to ISO/IEC 27001:2022, BSI Standard 200-2 and the IT-Grundschutz Compendium Edition 2023. The standard itself contains indications of future audit practice: if permanent non-fulfilments of SHOULD requirements accumulate, a significant deviation could be identified in the course of a certification, and the minimum criteria are intended, among other things, to make the risk method comparable and verifiable for a certification.

Training and personnel certification: GS++ practitioner, GS++ consultant, GS++ audit team leader

The BSI is also changing the qualification of individuals. Training concepts for training as a GS++ practitioner and as a GS++ consultant are to be published by 30/11/2026. From 01/01/2027, applications for certification as a GS++ consultant and as a GS++ audit team leader can be submitted; in the first quarter of 2027, separate further training for certification as a GS++ consultant or GS++ audit team leader respectively starts for IT-Grundschutz Consultants and audit team leaders who are already certified. The milestone plan does not state content, scope or admission requirements. In our view, this gives rise to a simple check for tenders and bids: no one can be certified as a GS++ consultant or GS++ audit team leader before 01/01/2027; existing BSI qualifications relate to IT-Grundschutz.

Who needs to observe what

As of 29/10/2026. The BSI continues to update the milestone plan; the certification documents published at any given time are authoritative. VamiSec is not a certification body, and GS++ personnel certification does not begin until 2027.

Path A: from IT-Grundschutz

Path B: from ISO/IEC 27001

90-day start plan

1. 1
   Days 1–15 · BSI 300-1 ch. 2.3 and 2.10 · GC.1.2, GC.6.1, GC.8.1Clarify mandate, scope and objective

   Top management confirms the project, defines the scope, approves resources and decides whether certification to ISO 27001 based on GS++ is to be sought in 2027. A core team of the ISB, process owners and IT is appointed.

2. 2
   Days 16–30 · ch. 2.5 and 2.6 · GC.7.1.1, GC.7.1.2Business processes and protection needs

   Document the business processes within the scope and, where no process map exists, use the simplified business process analysis from Annex 2. Select the most important process in the highest protection needs category and have top management approve the protection needs, normal or high, for each protection goal.

3. 3
   Days 31–50 · ch. 3 · STM.2.1.2 to STM.2.1.5, STM.5.1Assets, target object categories and requirements set

   According to the catalogue's guidance text, the assets of the most important business process are sufficient for the first iteration. Assign the assets to the target object categories, including the higher-level categories, include the methodology requirements and the requirements without a target object category, remove duplicates and define parameter values.

4. 4
   Days 51–70 · ch. 4.1 · UMS.1.1Record the implementation status

   Start with the normal-SdT requirements and document for each requirement, with a justification, whether it is fulfilled, not fulfilled or not applicable. Existing results from the IT-Grundschutz Check or the Statement of Applicability serve as a starting point, not as a result.

5. 5
   Days 71–85 · ch. 2.11 and 4.2 · Annex 3Set up risk analysis

   Have top management authorise the risk appetite, risk acceptance criteria, procedures and roles; start risk analyses for processes with high protection needs, assets that are not sufficiently covered and permanently unfulfilled SHOULD requirements.

6. 6
   Days 86–90 · ch. 4.3 to 4.5 and 5.3 · UMS.2.1, RISK.1.10, PERF.4.1Implementation plan and first management report

   Prioritise measures, parent nodes first, define responsible persons and deadlines, have the risk owners authorise the implementation planning and present the status, residual risks and the next business process to top management in the management report.

Open items: what the BSI has yet to deliver