Skip to content
Grundschutz++ Docs

Loading search …

DEEN
phase after the publication of BSI Standard 300-1 (until 12/2026).Timeline (German)

Methodology: how to apply Grundschutz++

This is a reading aid, not advice and not legal advice. The authority is BSI Standard 300-1 itself, which is in German. Translations and paraphrases are ours and the German text governs. This project is independent and not affiliated with the BSI. Chapter references such as “(3.4)” point to the standard. The catalog pages linked here are in German.

The source is BSI Standard 300-1, © Bundesamt für Sicherheit in der Informationstechnik 2026. Summaries are paraphrased and give the chapter; verbatim quotes are in quotation marks. The PDF is linked here, not offered for download. The BSI’s terms of use apply (in German).

The catalog says what an organization should implement. The methodology says how to get there: in what order, with which decisions, and when to look closer. The BSI has published it as BSI Standard 300-1 “Methodik Grundschutz++” (press release of 26 October 2026, in German). The PDF is version 1.0, and its change history gives 20 October 2026 as the date.

According to the standard, version 1.0 is aimed first of all at early adopters: experienced organizations that want to start early. Their experience is meant to feed into further development (1). An information security management system (ISMS) built on Grundschutz++ is planned to be certifiable from 2027.

The five steps

Section titled “The five steps”

The methodology describes a PDCA cycle (Plan, Do, Check, Act) with five process steps. Each step is itself run iteratively (1). Figure 1 of the standard assigns them like this: Plan is steps 1 and 2, Do is step 3, Check is step 4 and Act is step 5.

PDCA1 · PLANSurveyand planning2 · PLANRequirementsanalysis3 · DORealization4 · CHECKMonitoring5 · ACTContinualimprovement
  1. 1PlanSurvey and planning
  2. 2PlanRequirements analysis
  3. 3DoRealization
  4. 4CheckMonitoring
  5. 5ActContinual improvement
  6. back to step 1
  • 1 Survey and planning (chapter 2 of the standard, ISO/IEC 27001 clauses 4 and 5): GC Governance and compliance
  • 2 Requirements analysis (chapter 3, ISO/IEC 27001 clauses 6 and 10): STM Structure modeling
  • 3 Realization (chapter 4): UMS Implementation, RISK Risk management
  • 4 Monitoring (chapter 5): PERF Monitoring and evaluation
  • 5 Continual improvement (chapter 6): VRB Improvement

The standard names ISO clauses explicitly only for steps 1 and 2. The practice after the colon is my own mapping by topic and title, not a statement by the BSI. Only the grouping of the practices into three groups comes from the standard (figure 2): methodology (GC, STM, UMS, VRB, PERF, RISK), technical (ARCH, BER, DET, REA, KONF, DEV) and organizational (ASST, PERS, BES, DLS, TEST, GEB, SENS, NOT).

Step 1: survey and planning

Section titled “Step 1: survey and planning”

Top management decides what the ISMS covers and what it does not (2). That decision is theirs: responsibility for the ISMS lies with top management and cannot be delegated (2.10). The standard names these sub-steps, each followed by the catalog requirements that fit it:

Protection needs: only two levels

Section titled “Protection needs: only two levels”

Each business process gets a protection need for confidentiality, integrity and availability. There are two categories (2.6):

  • normal (normal): the impact is limited and manageable.
  • high (hoch): the impact can be considerable.

You may define additional categories of your own, but they have to be mapped onto these two. For a certifiable ISMS, the lowest category must always meet the state of the art.

If you are setting up an ISMS for the first time, the standard says to start with the most important business process in the highest category and then work through the rest in turn.

Protection needs decide whether a risk assessment is required. With normal protection needs you do not have to carry out one of your own, because the catalog is already based on a general BSI risk assessment (2.11). With high protection needs, one is required. More on that below.

Step 2: requirements analysis

Section titled “Step 2: requirements analysis”

This step turns the catalog into an individual requirements package (Anforderungspaket) for your information domain (3.4). The way there:

  1. Delimit the information domain (3.1), STM.1.1 and STM.1.2. The scope sets the formal extent of the ISMS; the information domain maps it in terms of content and technology.
  2. Record the assets (3.2), STM.2.1.2. For high protection needs you must document which assets belong to the business process and how they depend on each other. For normal protection needs, document at least the dependencies between applications, IT systems and rooms. Figures 3 and 4 show the chains: for high protection needs business process, application, IT system, network or network component, room. For normal protection needs it is application to IT system and IT system to room.
  3. Map assets to target object categories (3.4.2), STM.2.1.3. These are standardized classes such as “web servers”, “cloud services” or “server rooms”. Annex 1 of the standard defines 39 of them, and the BSI also provides them as a CSV file. They form a hierarchy of seven root nodes and four levels (figure 6): an asset also receives the categories above its own (STM.2.1.4.1).
  4. Consider blueprints (3.3). A blueprint is a ready-made catalog of requirements for a particular scenario, with predefined parameters. For some organizations there may be mandatory blueprints.
  5. Add requirements (3.4.3) if an asset is not covered by the catalog or if duties arise from compliance or the stakeholder analysis: STM.2.1.6 and STM.2.1.7.
  6. Set parameters (3.5), STM.5.1. Parameters are the variable parts of a requirement, such as “regularly”. The organization makes them concrete.

The package contains three kinds of requirements (3.4):

  • Methodology requirements apply to every information domain and are mandatory. They sit in the methodology practices (GC, STM, UMS, VRB, PERF, RISK) and reflect ISO 27001 clauses 4 to 10. “An individual approach is not intended” (3.4.1). In the catalog that is 99 requirements.
  • Requirements without a target object category from the technical and organizational practices are likewise mandatory (STM.2.1.5). In the catalog that is 265.
  • Requirements with a target object category apply as far as you have assets in that category (STM.2.1.4). In the catalog, 636 requirements carry the category in a field called target_object_categories. Together with the other two groups that makes the 1,000 requirements.

A requirement that affects several assets of the same category enters the package only once (STM.2.1.4.2).

The target object categories are stored per requirement in the catalog (field target_object_categories; all 39 categories occur and match the BSI’s CSV file). This page shows it next to every requirement as “Gilt für” (applies to), and the search can filter by it.

MUSS, SOLLTE, KANN and the two security levels

Section titled “MUSS, SOLLTE, KANN and the two security levels”

Every requirement carries a modal verb and a security level. In the catalog (version 22 October 2026, 1,000 requirements) the split is:

Modal verb Count Level
MUSS (must) 149 normal-SdT
SOLLTE (should) 624 normal-SdT
SOLLTE (should) 3 erhöht (elevated)
KANN (may) 224 erhöht (elevated)

On the levels, the standard says (3.4.2): requirements at the elevated level contain the modal verb KANN and are optional. You can use them to find further measures where the risk is elevated.

The three SOLLTE requirements at the elevated level are BES.1.4, DET.4.12.1 and REA.2.5. That does not quite match the standard’s sentence. If you filter by level, keep them in mind.

Step 3: realization

Section titled “Step 3: realization”

Determine the implementation status

Section titled “Determine the implementation status”

The status of every requirement in the package has to be checked (UMS.1.1). The standard knows three values (4.1.1): “fulfilled”, “not fulfilled” and “not applicable”. “Not applicable” needs a documented reason, for example when the underlying component does not exist in the information domain.

The catalog puts it more briefly: the status is basically “implemented (yes)” or “not implemented (no)”, and a requirement counts as implemented only if all requirements it depends on are implemented too. “Not applicable” is not mentioned there. In practice it helps to read both texts together.

To keep track of the status, this site offers a spreadsheet to fill in: Excel export (a German page, and the column names in the file are German). It is a tool of this site and not part of the standard.

What happens when a requirement is not met

Section titled “What happens when a requirement is not met”

If a requirement is not yet met but already in the implementation plan, the risk that is not yet covered must be identified and reported to top management, which has to bear it (4.1.1). Everything else depends on the modal verb (4.1.2):

  • KANN: optional, need not be considered.
  • SOLLTE, temporarily not met: fulfilment is planned for later. A sound justification is enough. This does not trigger a risk assessment.
  • SOLLTE, permanently not met: meaning “for the foreseeable future or for good”. Then a risk assessment is mandatory, and the residual risk goes to top management for approval.
  • MUSS: mandatory. A risk assessment cannot replace fulfilment. According to the standard, an exemption or risk acceptance is not possible.

The standard warns that if permanent non-fulfilments of SOLLTE requirements pile up, the state of the art as a whole may count as not reached, so a certification could find a significant deviation.

In the catalog, UMS.5.1 is titled “Authorization of exceptions”. It refers to exemptions where obligations conflict. Both statements apply side by side.

Plan the implementation

Section titled “Plan the implementation”

The requirements package becomes an implementation plan (UMS.2.1, UMS.2.2) (4.3). For each measure, record at least the related requirement, the date of implementation or review, and the person who documents or checks it. If checks are automated, record the tool, the time and the result.

Add owners and deadlines (UMS.3.1, UMS.4.1) (4.4) and progress tracking (UMS.6.1, UMS.6.2) (4.5). The standard recommends implementing the requirements of parent nodes in the category hierarchy first, because they are mostly conceptual (“establish a procedure”).

When a risk assessment is mandatory

Section titled “When a risk assessment is mandatory”

The catalog already contains a general risk assessment based on an assumed typical threat situation. The underlying threats are stored as metadata on the requirements. In the catalog, 901 of 1,000 requirements carry such data, covering 47 distinct elementary threats (Annex 4). With normal protection needs, this is all you need.

An explicit risk assessment is required in these cases, according to the standard (2.11):

  1. A business process has high protection needs for at least one protection goal (GC.7.2).
  2. A relevant asset is not adequately covered by the target object categories and their requirements.
  3. An applicable SOLLTE requirement is permanently not met.

In STM.4.1 the catalog names a further trigger, the downgrading of the security level from elevated to normal-SdT. The standard’s list does not include this case.

For residual risks of SOLLTE requirements that are in the implementation plan but not yet met, a residual risk assessment is required and top management must approve the risk (UMS.1.2).

The method is free, the minimum criteria are not

Section titled “The method is free, the minimum criteria are not”

You choose how to identify, assess and treat risks, for example following ISO/IEC 27005 or ISO 31000 (2.11). The 35 minimum criteria in Annex 3 are binding, so that the result stays comparable and verifiable, for instance in a certification. Some of them:

  • a uniform, documented procedure for identification, assessment and treatment (criteria 1 to 4)
  • a defined risk appetite and risk acceptance criteria (7, 8)
  • a risk owner for every risk, by default the business process owner (RISK.1.3) (5, 16)
  • a risk register with fixed minimum fields (15)
  • authorization of procedures, criteria and residual risks by top management (RISK.1.5) (9, 30)
  • review at least annually and on significant changes (35)

Steps 4 and 5: monitor and improve

Section titled “Steps 4 and 5: monitor and improve”

The standard requires (5):

  • a performance evaluation of the ISMS (5.1). According to the standard, uniform rules for it are still to come, and until then organizations are free. In the timeline the BSI gives 26 February 2027 for the performance measurement concept.
  • an internal audit programme (5.2), meant above all to show room for improvement
  • management reviews by top management (5.3)
  • monitoring with procedures for security incidents, vulnerabilities and new threats (5.4)
  • validation of the requirements, for example after changes to the information domain or the catalog (5.5)

Continual improvement (6) closes the loop: analyse non-conformities, assess improvement potential, add a correction and improvement plan to the implementation plan, check effectiveness.

What I have not checked

Section titled “What I have not checked”
  • What blueprints are in practice, the standard says only in general terms. Besides the user catalog, the BSI repository contains catalogs on WLAN (48 requirements) and supply chain security (146). They fit the standard’s description (tailored to an application scenario), but the BSI does not call them blueprints there. I have not established whether blueprints in the standard’s sense exist yet.
  • This page is the wrong source for duties under the law. For that, see If your company operates in Germany.

Sources

Section titled “Sources”