The 35 Minimum Criteria for Risk Assessment in Grundschutz++, Explained One by One with Examples
BSI Standard 300-1 lets organisations choose their own risk method, provided it meets 35 binding minimum criteria in Annex 3. What each criterion means, what an auditor will look for, and a worked example for every one of them.
Published on October 28, 2026
The 35 Minimum Criteria for Risk Assessment in Grundschutz++, Explained One by One
CORE THESIS Grundschutz++ says it outright: organisations may run their risk assessment with a method of their own choosing. The price of that freedom is Annex 3 of BSI Standard 300-1, a list of 35 binding minimum criteria that make every method comparable and auditable. Read together, the criteria say three things. Management decides the framework and carries what remains. Every risk has an owner. And every step leaves a record that someone else can check.
BSI Standard 300-1, the methodology of Grundschutz++, was published on 26 October 2026.1 For business processes with normal protection needs, the BSI has already built a general risk assessment into its requirements catalogue. An explicit risk assessment of their own becomes necessary when a business process has high protection needs for at least one protection goal, when a relevant asset is not adequately covered by the target object categories, or when an applicable SOLLTE requirement will be permanently unmet.2 A SOLLTE requirement that is only temporarily unmet, with fulfilment planned, does not trigger a full explicit risk assessment, but its residual risk must still be reviewed and approved by management.2 Whenever that happens, the method an organisation uses has to meet the 35 criteria in Annex 3. The standard names ISO/IEC 27005 and ISO 31000 as possible bases, and adds that the criteria exist so that the chosen method can be compared and checked, for example in a certification.2
This article goes through all 35 criteria. For each one it says in plain words what is required, and gives a concrete example. The criteria themselves come from the standard; the explanations and every example are my own illustration, not BSI text.
The running example
To keep the examples concrete, they all follow one fictional organisation. The town of Musterstadt runs a citizens’ portal through which residents submit applications online: residence registration, parking permits, childcare places. Applications contain names, addresses, income details and copies of identity documents. The town has rated the process as high for confidentiality and integrity, so criterion 32 applies and a risk assessment is required.
The process runs on a resource path that will reappear throughout: the portal web application, a specialised back-office application for case handling, a database server, the server room in the town hall, and an external hosting provider for the public front end.
The standard notes that the numbering is for reference only and does not describe a sequence, and that some criteria apply across phases.2 The order below follows the phases in which the standard groups them.
Phase 1: Initiation and preparation (criteria 1–10)
Before a single risk is written down, the framework has to stand. These ten criteria decide whether two people assessing the same risk would arrive at a comparable result.
Criterion 1 — A uniform procedure for identifying and assessing risks
In plain words: the organisation fixes one procedure for finding and rating risks and uses it everywhere, not one method in IT and another in facilities.
Example: Musterstadt adopts a scenario-based procedure along ISO/IEC 27005 for all departments. The IT department had previously used its own spreadsheet with a 1–10 scale; that spreadsheet is retired so that the citizens’ portal and the payroll process are rated the same way.
What an auditor will want to see: The procedure document, and registers from two different departments that use the same scales.
Criterion 2 — A uniform procedure for treating risks
In plain words: once risks are rated, there is one fixed way of deciding what happens to them.
Example: every risk above the acceptance threshold goes through the same three steps: choose a treatment option, define measures, submit the result to the risk owner. No department can simply decide that a risk “is fine” outside this route.
What an auditor will want to see: The treatment route in the procedure, and a sample of treated risks that went through it.
Criterion 3 — The identification and assessment procedure is documented
In plain words: the procedure from criterion 1 exists in writing, so that it can be audited and repeated.
Example: a six-page “Risk assessment procedure” document describes the scales, the workshop format, who takes part and where results are recorded. An auditor can read it and then check whether the register follows it.
What an auditor will want to see: The current, approved version of the identification and assessment procedure, with a version history.
Criterion 4 — The treatment procedure is documented
In plain words: the same applies to the treatment route from criterion 2.
Example: the procedure document has a chapter on treatment: which options exist, who decides, which template is used for the treatment plan, and how decisions reach management.
What an auditor will want to see: The treatment chapter or document, including the template for the treatment plan.
Criterion 5 — Roles, responsibilities and authority, especially the risk owner
In plain words: it is defined who does what in risk management, and who may decide what. The role of risk owner is singled out.
Example: Musterstadt defines four roles. The information security officer moderates and documents. Process owners act as risk owners. The IT lead assesses technical feasibility. The mayor authorises the framework and residual risks.
What an auditor will want to see: A role description or RACI that names the risk owner and states what each role may decide.
Criterion 6 — Criteria for identifying and assessing risks
In plain words: the criteria are fixed in advance for both steps: which scenarios are taken into the register at all (identification), and how frequency and impact are measured and combined (assessment).
Example: Musterstadt defines four frequency classes for a three-year period (rare, possible, likely, frequent) and four impact classes (low, noticeable, considerable, threatening to the town’s ability to act), each with descriptions, for example for “considerable”: “data of more than 1,000 residents disclosed”. For identification, Musterstadt’s procedure states that every scenario affecting a process in scope is recorded if it could plausibly reach at least “noticeable” impact, with existing measures noted as they stand.
What an auditor will want to see: The criteria for taking risks into the register, the frequency and impact scales with their definitions, and the rule that combines them.
Criterion 7 — Risk appetite
In plain words: the organisation states how much risk it is prepared to take in pursuit of its goals.
Example: “For processes with high protection needs, Musterstadt does not, as a rule, take on high information security risks; the only way out is a justified, recorded exception by management under criterion 27. Medium risks are tolerated temporarily if a treatment plan with a date exists.”
What an auditor will want to see: A written risk appetite statement that management has approved.
Criterion 8 — Risk acceptance criteria, derived from the appetite
In plain words: the appetite is translated into concrete rules that say which risk level is acceptable. The standard only requires that these criteria take the appetite into account; also saying by whom and for how long is good practice.
Example: the risk owner may propose low risks for acceptance; like all residual risks, they are then authorised by the mayor together with the others (criterion 30). Medium risks may be accepted by the mayor for at most twelve months with a treatment plan. High and very high risks may not be accepted for processes with high protection needs; they must be treated, unless management authorises a justified exception (criterion 27).
What an auditor will want to see: Acceptance criteria that refer to the appetite and say which level is acceptable, ideally also by whom and for how long.
Criterion 9 — Management authorises procedures, roles, criteria and appetite
In plain words: the whole framework from criteria 1 to 8 is signed off by the institution’s management, not by the security team alone.
Example: the mayor approves the procedure document, the role model, the scales, the acceptance criteria and the risk appetite in a recorded decision. Without that signature, the framework is a proposal.
What an auditor will want to see: A dated management decision, such as minutes or a signed memo, approving procedures, roles, criteria and appetite.
Criterion 10 — The methodological basis for identification
In plain words: the organisation decides how it finds risks: by pairing threats with vulnerabilities, by working through risk scenarios, or by another documented approach.
Example: Musterstadt works with scenarios. For each process, the workshop asks “what could happen to this process, through whom or what, and with which consequence?” The 47 elementary threats of Grundschutz++ serve as a checklist so that no category is forgotten.
What an auditor will want to see: The documented choice of method, for example scenario-based or threats and vulnerabilities, and the checklist used.
Phase 2: Risk identification (criteria 11–17)
These seven criteria decide what is examined, what is written down about each risk, and who owns it.
Criterion 11 — The objects under examination are documented
In plain words: for every risk assessment it is recorded what was looked at.
Example: the assessment of October 2026 covers “business process citizens’ portal (GP-04), with the external hosting provider examined separately as a critical asset”. The canteen menu process is explicitly not part of it.
What an auditor will want to see: The scope statement of each assessment: which processes and assets were examined, and which were not.
Criterion 12 — Existing and planned measures are taken into account
In plain words: when risks are identified and rated, the measures already in place and those already planned, with their status, are part of the picture. This applies both to identification and to assessment.
Example: the risk “account takeover of a portal administrator” is rated with the knowledge that strong passwords and a lockout are implemented, while multi-factor authentication is planned for March 2027 but not yet live. Both are recorded with their status; the planned measure is noted, but it does not yet count as protection in the rating.
What an auditor will want to see: Register entries that show existing and planned measures with their status at the time of rating.
Criterion 13 — Risks at process level, and at critical assets where needed
In plain words: risks should be identified for the business process as a whole, and additionally for individual assets only where the view of the process does not capture their situation.
Example: most risks of the citizens’ portal are described at process level, for instance “applications are manipulated before decision”. The external hosting provider is examined separately as a critical asset, because its contract and its location raise questions that the process view does not answer.
What an auditor will want to see: Risks described at process level, plus a reason wherever an individual asset was examined separately.
Criterion 14 — Every risk is assigned the affected protection goals
In plain words: each risk states which of confidentiality, integrity and availability it affects, at a minimum.
Example: “applicant data disclosed through a misconfigured storage bucket” is marked confidentiality. “Applications altered by an attacker” is marked integrity. “Portal unavailable during the application deadline” is marked availability.
What an auditor will want to see: A protection-goal field in every register entry, with at least confidentiality, integrity and availability available.
Criterion 15 — Minimum fields in the risk register
In plain words: every risk in the register has at least a unique ID, the object under examination, a description, the affected protection goals, the risk level and the risk owner. For risks to be treated, the priority, the treatment option and a reference to the assigned measures are added.
Example: R-007, “takeover of a portal administrator account through credential phishing; applicant data read or altered”, object GP-04 admin access, protection goals confidentiality and integrity, level high (likely × considerable), owner head of citizens’ services; as a risk to be treated also priority 1, option reduce, measures M-031 to M-033 (Figure 4).
What an auditor will want to see: A register in which every entry has all six minimum fields, and risks to be treated also have priority, option and measures.
Criterion 16 — Every risk has a risk owner
In plain words: each risk is assigned to a risk owner. Unless something else is defined, that is the owner of the business process.
Example: all risks of the citizens’ portal belong to the head of the citizens’ services department, who owns the process. A risk that affects both the portal and payroll is assigned to one lead owner chosen from the two process owners.2
What an auditor will want to see: A named owner for every risk and, where a risk affects several processes, a lead owner chosen from the affected process owners.
Criterion 17 — Elementary threats for permanently unmet SOLLTE requirements
In plain words: if a SOLLTE requirement will not be met in the foreseeable future, the elementary threats assigned to that requirement in the catalogue must be considered in the risk assessment.
Example: suppose an applicable SOLLTE requirement for multi-factor authentication of administrative access cannot be met because the case-handling application does not support it, and no replacement is foreseeable before 2029. In this illustration, the requirement carries the identifiers G 0.23 (unauthorised intrusion into IT systems) and G 0.36 (identity theft). Both threats are then explicitly examined for the citizens’ portal, and compensating measures are assessed against them.
What an auditor will want to see: For each permanently unmet SOLLTE requirement, the elementary threats assigned to it and how they were assessed.
Phase 3: Risk evaluation (criteria 18–22)
These five criteria turn an identified risk into a level that can be compared with the acceptance criteria.
Criterion 18 — Frequency is estimated against fixed criteria and a fixed period
In plain words: how often an event is expected is estimated using the defined classes and for a defined period, not by gut feeling.
Example: “credential phishing against portal administrators” is rated “likely” for a three-year period. The town recorded two such attempts in the last year; with only passwords and a lockout in place, it assumes, as a conservative estimate, that at least one attempt in three years could lead to a successful account takeover.
What an auditor will want to see: Frequency ratings that use the defined classes and the defined period, with the source of the estimate.
Criterion 19 — Impact is estimated against fixed criteria, with a reason
In plain words: the size of the damage is rated using the defined classes, and the rating is justified.
Example: “considerable, because the portal holds data of about 18,000 residents, including identity documents, and a disclosure would trigger notification duties and lasting loss of trust”.
What an auditor will want to see: Impact ratings that use the defined classes, each with a short written reason.
Criterion 20 — The risk level combines frequency and impact
In plain words: the risk level is derived from both values together, following the defined rule.
Example: in Musterstadt’s matrix, “likely” and “considerable” give the level “high”.
What an auditor will want to see: Risk levels that can be reproduced from frequency and impact using the documented rule.
Criterion 21 — Risks to be treated are prioritised
In plain words: the organisation fixes in which order risks are treated.
Example: risks are treated first by level, and within the same level by the number of residents affected. The administrator takeover risk is priority 1.
What an auditor will want to see: A documented prioritisation rule and the resulting order of risks to be treated.
Criterion 22 — Every risk is compared with the acceptance criteria
In plain words: every rated risk is checked against the acceptance criteria.
Example: the administrator takeover risk is “high” for a process with high protection needs and therefore not acceptable under criterion 8. The risk “portal FAQ page unavailable for a few hours” is “low” and acceptable.
What an auditor will want to see: For every rated risk, a recorded result of the comparison with the acceptance criteria.
Phase 4: Risk treatment (criteria 23–31)
These nine criteria cover what happens to a risk after it has been rated, and who authorises what remains.
Criterion 23 — A treatment option for every risk to be treated
In plain words: each risk to be treated gets one of four options: reduce, avoid, transfer or accept.
Example: the administrator takeover risk is reduced. The risk of residents sending applications as unencrypted e-mail attachments is avoided by switching off the e-mail channel. Part of the financial impact of a data breach is transferred through a cyber insurance policy. The low risk that the portal’s FAQ page is unavailable for a few hours is accepted.
What an auditor will want to see: A treatment option recorded for every risk that is to be treated.
Criterion 24 — Reduction measures follow from the assessment
In plain words: measures are chosen in a traceable way, based on what the assessment found.
Example: because the assessment named phishing of administrators as the cause, the measures are aimed there: a hardware security key for the three administrators, administrative access only from the internal network, and alerting on failed logins. A general awareness campaign can complement these; whether it would be enough on its own would have to be shown by the re-assessment.
What an auditor will want to see: Measures whose choice can be traced back to the cause or scenario named in the assessment.
Criterion 25 — The link between risks and measures is documented
In plain words: it is visible which measures belong to which risk, and the reverse.
Example: risk R-007 refers to measures M-031, M-032 and M-033 in the implementation plan, and each of those measures refers back to R-007.
What an auditor will want to see: A traceable mapping between risks and measures, for example references in the register and the implementation plan.
Criterion 26 — Assessment and treatment are repeated if the risk is still too high
In plain words: if a risk still does not meet the acceptance criteria after treatment, it is assessed and treated again.
Example: once M-032 and M-033 are live in November 2026, stolen credentials can no longer be used from outside the town’s network, and misuse attempts trigger an alert. Musterstadt therefore lowers the frequency of the same scenario by one class: R-007 is re-rated as “possible” and “considerable”, which gives “medium”. Medium is acceptable for at most twelve months with a plan, and the plan is M-031, the security keys, due on 31 March 2027. So the loop ends here. Had the result still been “high”, a further round would have been needed.
What an auditor will want to see: Re-assessment records for risks that did not meet the acceptance criteria after a first round.
Criterion 27 — Management authorises risks that will not be treated further
In plain words: if a risk does not meet the acceptance criteria and is nevertheless not to be treated further, the institution’s management must authorise this as an exception. Such an exception cannot replace the fulfilment of an applicable MUSS requirement.2
Example: the case-handling application cannot be hardened further and its replacement is not foreseeable before 2029. The remaining “high” risk is put to the mayor with an explanation; the mayor signs an exception. Without that signature, the risk would have to be treated further.
What an auditor will want to see: A documented exception authorised by management, for example a recorded decision or signed memo, for every risk above the acceptance criteria that is not treated further.
Criterion 28 — Temporary risk acceptance needs an end date
In plain words: if a risk is accepted only for a while, the period is fixed.
Example: the “medium” residual risk of R-007 is accepted until 31 March 2027, the date on which the security keys (M-031) are due to go live as multi-factor authentication. On that date, the acceptance expires and the risk is reassessed.
What an auditor will want to see: An end date for every temporarily accepted risk, and evidence that expired acceptances were reassessed.
Criterion 29 — Accepted risks are documented
In plain words: every accepted risk is documented. The standard says no more; noting what was accepted, by whom and when makes the record auditable.
Example: the register shows for R-007: “medium, accepted temporarily until 31.03.2027; risk owner: head of citizens’ services; authorised by the mayor on 12.11.2026”.
What an auditor will want to see: A list of accepted risks showing what was accepted, by whom and when.
Criterion 30 — Management authorises the residual risks
In plain words: the risks that remain after treatment are presented to the institution’s management and authorised by it.
Example: the residual risk overview for the citizens’ portal, one page with all remaining risks and their levels, is part of the management report and is signed by the mayor.
What an auditor will want to see: A documented authorisation of the residual risks by management, for example a recorded decision or the signed management report.
Criterion 31 — Risk owners authorise the implementation plan
In plain words: the plan for the measures decided in treatment is approved by the risk owners. The further planning and steering of the measures then happen in the implementation phase.2
Example: the head of citizens’ services approves the plan with the three measures for R-007, their owners and their deadlines. The IT department then carries out the plan and reports progress.
What an auditor will want to see: The risk owner’s approval of the implementation plan for the measures decided in treatment.
Cross-phase requirements (criteria 32–35)
The last four criteria do not belong to one phase. Three of them say when a risk assessment must take place at all, and one says how often it is reviewed.
Criterion 32 — Risk assessment for high protection needs
In plain words: every business process with high protection needs for at least one protection goal gets a risk assessment.
Example: the citizens’ portal is high for confidentiality and integrity, so it is assessed. The canteen menu is normal for all three goals and is covered by the catalogue’s general risk assessment.
What an auditor will want to see: A risk assessment for every process rated high in at least one protection goal.
Criterion 33 — Assets not adequately covered
In plain words: if a relevant asset is not adequately covered by the existing target object categories and their requirements, a risk assessment is carried out for it.
Example: the town’s building control system, which steers heating and access doors in the town hall, can be assigned to a target object category, but the requirements assigned to that category do not adequately cover its specific operating scenario. The remaining risks are therefore examined in their own risk assessment, and the requirements package is supplemented.
What an auditor will want to see: A list of assets not adequately covered by target object categories, each with its own risk assessment.
Criterion 34 — Permanent non-fulfilment of a SOLLTE requirement
In plain words: every SOLLTE requirement that will be permanently unmet triggers a risk assessment.
Example: the missing multi-factor authentication in the case-handling application from criterion 17 is a permanent non-fulfilment. It triggers a risk assessment, and criterion 17 says which threats it must cover.
What an auditor will want to see: A list of permanently unmet SOLLTE requirements, each linked to a risk assessment.
Criterion 35 — Review at least annually and on significant changes
In plain words: the risk assessment is reviewed at least once a year, and also when significant changes are planned or have occurred.
Example: Musterstadt reviews its risk assessment every October. It also reviews it before the planned move of the portal to a new hosting provider in spring 2027, and immediately after a serious security incident that changes the risk picture.
What an auditor will want to see: Review dates at least once a year, and reviews linked to planned or actual significant changes.
What auditors are likely to look at first
The 35 criteria are not equally hard. In my experience as a lead auditor, organisations that already run a risk process along ISO/IEC 27001 meet most of them without changes. Four are where I expect gaps.
The first is a written risk appetite (criteria 7 and 8). Many organisations have scales and a matrix, but no statement of how much risk management is prepared to carry, and no rule that turns that statement into acceptance criteria.
The second is the end date for temporary acceptance (criterion 28). Risks are often accepted “for now”, which in practice means indefinitely.
The third is the link to elementary threats for permanently unmet SOLLTE requirements (criterion 17). Threat cross-references for unmet requirements already existed in IT-Grundschutz; what is new is that Annex 3 makes this link an explicit minimum criterion. In an ISO-oriented method, it is worth checking whether it is already there.
The fourth is the difference between the two authorisations at the end (criteria 30 and 31). Management authorises what remains; the risk owner authorises the plan. These are two decisions about two different things, and both need to be traceable. In many registers only one of them is recorded, or neither.
Lessons learned
The following lessons are my own reading, not statements of the BSI.
First, treat the 35 criteria as a checklist for your existing method, not as a new method. If you already work along ISO/IEC 27005 or ISO 31000, map each criterion to the place where your method already meets it, and close only the gaps.
Second, write down what management decides. Criteria 9, 27 and 30 require authorisation by the institution’s management. A risk process that is run well by the security team but never signed off does not meet them.
Third, keep the register lean but complete. Criterion 15 does not ask for many fields, but it asks for all six for every risk, and three more for every risk to be treated.
Fourth, put the review in the calendar. Criterion 35 is the easiest to meet and the easiest to forget.
Glossary
| Term | Meaning |
|---|---|
| Risk appetite | The amount of risk an organisation is prepared to take in pursuit of its goals |
| Risk acceptance criteria | Rules derived from the appetite that say which risk level is acceptable |
| Risk owner | The person, role or organisational unit responsible for a risk; in Grundschutz++ by default the business-process owner |
| Risk register | The record of all identified risks with the minimum fields of criterion 15 |
| Treatment option | Reduce, avoid, transfer or accept a risk |
| Residual risk | The risk that remains after treatment |
| Exception | Management’s authorisation of a risk that does not meet the acceptance criteria and is not treated further |
| Elementary threats | The 47 threats G 0.1 to G 0.47 from which the BSI derives the Grundschutz++ requirements; a G 0 identifier names a threat, not a missing measure or a risk level |
| SOLLTE requirement | A requirement that should be met; permanent non-fulfilment triggers a risk assessment |
Legal notice: This article serves general information purposes and does not constitute legal advice. It describes Annex 3 of BSI Standard 300-1 in version 1.0. The town of Musterstadt and all examples are fictional illustrations, not BSI content. As of: October 2026.
-
BSI, press release “Methodik zum Grundschutz++ als BSI-Standard 300-1 veröffentlicht”, 26 October 2026, https://www.bsi.bund.de/DE/Service-Navi/Presse/Alle-Meldungen-News/Meldungen/2026/BSI-Standard_300-1_261026.html (accessed 28 October 2026). ↩
-
BSI, “BSI-Standard 300-1 – Methodik Grundschutz++”, version 1.0, 20 October 2026: chapter 2.11 (initiation of the risk assessment, triggers, free choice of method subject to Annex 3, residual risk), chapter 4.2 (risk identification, assessment and treatment, lead risk owner for risks affecting several processes) and Annex 3 (minimum criteria 1 to 35, with notes on numbering and overlaps), https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Grundschutz/BSI_Standards/standard_300-1.pdf?__blob=publicationFile&v=3 (accessed 28 October 2026). ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7