BSI's elementary threats and ENISA's Threat Landscape are sound places to start a risk register. What makes the result yours is the decision you record for each entry, including the ones you leave out.
On 22 September 2026, ENISA published a new edition of its Threat Landscape. It covers incidents and events "observed from 1 January to 31 December 2025". The 2025 edition covered 1 July 2024 to 30 June 2025. The 2024 edition covered July 2023 to June 2024.
Each edition describes what happened to other organizations in a window that has already closed. A catalog records what happened to other people; a register records what you decided about it. That makes a catalog a good place to start a register and a poor place to stop. Copied without those decisions, a register inherits the catalog's date and someone else's world. The work that makes it yours is small, and it is the part an auditor reads.
A disclosure first. ISO/IEC 27001:2022 and ISO/IEC 27005:2022 are paywalled, and I have not quoted either. What follows rests on documents anyone can read: BSI's published mapping to the standard, BSI's certification scheme, and a summary published by ANSI, the American National Standards Institute.
Clause 6.1.2 of ISO/IEC 27001:2022 is the information security risk assessment clause, and it leaves the identification method to you. ANSI describes the standard as "a nonprescriptive framework" and notes that the asset, threat, and vulnerability identification method "was once a part of ISO/IEC 27001". Today that method lives in the guidance standard, ISO/IEC 27005, not in the requirements.
So a catalog is a legitimate input. BSI says so in its own mapping table from IT-Grundschutz to ISO/IEC 27001:2022. Against clause 6.1.2 it lists BSI Standard 200-3 and "Elementare Gefährdungen (G0-Gefährdungen) des IT-Grundschutz-Kompendiums", the elementary threats.
The freedom has a condition attached. BSI's guidance on reference documents for certification requires a documented risk-analysis policy. It then says the risk analysis is to be performed and documented "entsprechend der selbst definierten Richtlinie zur Risikoanalyse", according to the policy you defined yourself. It names BSI Standard 200-3 and ISO/IEC 27005 as example models. You pick the method. Then you are held to it.
ISO/IEC 27005:2022 describes two ways to identify risks. ANSI's summary puts it in one line: "The event-based approach was contrasted with the asset-based approach to risk identification." The same edition introduced risk scenario concepts. I can't read the clause text without buying it, so I won't paraphrase what either approach says in detail.
What I can say is where a threat catalog fits. The asset-based method works through assets, threats, and vulnerabilities. A catalog hands you the threat column, pre-filled. It knows nothing about your assets, your scope, or which events your management actually worries about.
BSI is explicit about what its catalog is. BSI Standard 200-3 says the BSI distilled the threats in its modules into "47 elementary threats". It lists the design goals: "Optimised for use in the risk analysis", "Product-neutral (always)", and "Compatible with comparable international catalogues and standards". It also says what was left out on purpose. Threats that "mainly address the lack of or inadequate implementation of security safeguards" were "deliberately not specified". The catalog names things that happen, such as G 0.1 Fire, G 0.8 Disruption or malfunction of power supply, or G 0.28 Software vulnerabilities or errors. Your weaknesses are yours to add.
BSI Standard 200-3 does not apply the catalog wholesale. It applies it per target object. A target object is whatever you are analyzing: an application, an IT system, a room, or a whole business process. For each object and each elementary threat, you decide one of three things (§4.1):
The standard's own example is a server operating system. G 0.25, failure of devices or systems, is relevant. G 0.1, fire, is not: "An operating system does not offer specific safeguards against fire." By the same logic, fire belongs on the room the server sits in. The same catalog entry gets different answers on different objects, and that is the point of the exercise.
The result is "a table that assigns a list of relevant elementary threats to each target object." Then comes a second pass for additional threats that arise from your specific setup. §4.2 keeps the ones that "could produce substantial damage" and are "realistic for the current application and area of use". It adds a warning I would print above every seeded register: "If relevant threats are not considered, this may produce gaps in the resulting security concept."
200-3 also evaluates each risk twice. The first evaluation assumes that security safeguards "have already been implemented or planned". The second considers the safeguards added for treatment. "By means of a before-and-after comparison, the effectiveness of the security safeguards which were used to treat risks can be checked." Keep that in mind when a catalog hands you ready-made ratings. A pre-filled "after" rating describes someone's idea of a treatment, and it may not be yours.
There is one published auditor instruction set I can point to. It is BSI's audit scheme for ISO 27001 certification on the basis of IT-Grundschutz, version 2.5. It governs that scheme only, not every accredited certification body. I still find it the most concrete public statement of what gets looked at. Three passages matter here (my translations):
Read those against a register seeded from a catalog. The auditor samples measures, so every kept entry needs a treatment someone owns. Exclusions get read, so every "not relevant" needs a sentence of reasoning. Accepted risks need a named approver. 200-3's own policy checklist asks the same question in plainer words: "Are risks assigned to the relevant risk owners?"
Here is the record I would keep, one row per catalog entry per scope, rejected entries included. The rows are illustrative, not from a real register.
| Catalog entry | Edition | Scope / object | Relevance | Rationale | Owner | Own rating (initial → residual) |
|---|---|---|---|---|---|---|
| BSI G 0.1 Fire | Kompendium 2023 | Customer web application | Not relevant | The application offers no safeguards against fire; assessed on the hosting site instead | Head of IT | n/a |
| BSI G 0.1 Fire | Kompendium 2023 | Colocation rack | Directly relevant | Provider room; suppression is theirs, backups are ours | Head of IT | 2×9 → 2×5 |
| ENISA ransomware | ETL 2024 (Jul 2023 to Jun 2024) | File shares | Directly relevant | Shared drives mounted on every client | Head of IT | 6×8 → 3×6 |
The edition column matters more than it looks. When ENISA moves its reporting window, a row that names its edition tells you which entries to reread. A row without one leaves you guessing. Record the "not relevant" rows too. They are the answer when someone asks why fire is missing from your register.
App 2.3.0 added a risk catalog to devguard. It can "create risks from the BSI IT-Grundschutz elementary threats, the ENISA Threat Landscape, CSA Top Threats, the OWASP Top 10 and the NIS2 and DORA operational risk areas." Here is how it maps to the record above.
The picker groups entries by source and names the edition each follows. The BSI entries follow the 2023 Compendium and cover a selection of the elementary threats, not all 47. The ENISA entries follow the 2024 Threat Landscape. Each entry shows the source's own reference, such as G 0.1. You cannot create anything until you choose an owner role, and every entry in one batch gets that owner. Each entry arrives with a description, an impact description, a treatment strategy and treatment description, and an initial and a residual rating. The residual rating assumes that described treatment is in place, so re-rate it against the treatment you actually have. The setup wizard preselects entries that fit your answers about how you run, such as cloud or on-premise. Untick the ones that don't fit.
Three things it deliberately does not do:
The judgment stays with you. The catalog saves you the typing; the decision recorded for each entry, with a name and a date against it, is what an auditor will read.
The risk catalog shipped in devguard App 2.3.0.
Vadim leads engineering, the architecture, automation, and integrations that let compliance live. He's set on making a serious, audit-grade system genuinely easy to run.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.
Start free, bring your frameworks, and keep the evidence attached as the work ships — no setup friction, no audit-week fire drill.