NIS-2 shifts the focus of information security. It’s not just firewalls, patches, or individual technical measures that take center stage, but the management of risks. Legislators and regulators are turning their attention to structures, responsibilities, and how organizations identify, assess, and treat risks.
The BSI IT-Grundschutz has provided a framework for this for years. With Standards 200-1 ( Management systems for information security) and 200-2 (IT-Grundschutz methodology), there is a method for establishing an information security management system (ISMS), including scope, structural analysis, determination of protection requirements, and modeling with building blocks from the IT-Grundschutz Compendium. This is where BSI Standard 200-3 comes in: it describes a risk analysis procedure on this basis and connects NIS-2 requirements with lived practice in organizations.
Risk treatment according to BSI Standard 200-3
Risk management under 200-3 does not stand alone. It builds on an ISMS that already performs fundamental tasks and at the same time forms an integral part of that system.
The information network is in place, and the scope is defined. Business processes, applications, IT systems, and infrastructures are covered in a structural analysis. Protection requirements for confidentiality, integrity, and availability are assigned. Building blocks from the IT-Grundschutz Compendium cover typical threats and measures; an initial IT-Grundschutz check flags gaps.
At this point, standard measures are no longer enough. NIS-2 requires a focus on concrete risks, on threat scenarios, and on the question of which functions of an organization are critical. BSI Standard 200-3 addresses this.
Threat overview and risk assessment
The method centers on target objects: for example, a line-of-business application, a data center, a cloud service, or a business-critical process.
A threat overview is created for each target object. The basis is the catalog of 47 elementary threats from IT-Grundschutz—such as eavesdropping, manipulation of information, fire, or staff unavailability—supplemented by specific scenarios from the organization’s own situation.
Ransomware, supply chain attacks, or service provider outages are included there, as are classic topics such as physical damage or user error.
This overview is followed by the assessment. Business units, IT, and information security officers discuss likelihood of occurrence and potential impact. Qualitative scales structure the appraisal. The result is a risk matrix with categories such as low, medium, high, or very high.
Such a matrix does not deliver mathematical truth, but it creates a shared picture. Leadership, business units, and technical teams are talking about the same risk, with the same classification and the same terms. This provides an important building block for NIS-2: proof that risks are not just perceived intuitively but are assessed systematically.
Risk treatment : Avoidance, reduction, transfer, acceptance
After the assessment comes the treatment. BSI Standard 200-3 distinguishes four directions.
Avoidance stands for decisions that remove a risk situation completely from operations, for example by decommissioning an obsolete system or foregoing a particularly risky procedure.
Reduction aims at additional technical or organizational measures, such as tighter access controls, segmentation, monitoring, or clear process specifications.
Transfer shifts portions of the risk to third parties, for example via service contracts or insurance.
Ultimately, there is always a remainder that leads to conscious acceptance or is deemed unacceptable. Each of these decisions requires documentation and justification; otherwise, it remains vulnerable to challenge.
Taken together, these decisions flow into a consolidated security concept and a risk register. These list risks, measures, owners, and deadlines, tied to a process for regular review. This yields robust evidence for NIS-2: risks are under observation, not just on a slide.
Governance and integration into existing structures
Risk management under BSI Standard 200-3 is incomplete without clear governance. Leadership defines principles for risk analysis, sets risk appetite and acceptance criteria, and empowers roles with a mandate. Information security officers facilitate analyses, contribute methodological expertise, and ensure consistency. Business units provide assessments of impacts; technical teams contribute knowledge of architectures and threats.
Regular reviews keep results up to date. New projects, changed supply chains, cloud migrations, or organizational upheavals alter the risk landscape. A static register no longer fits a NIS-2-driven environment. Standards such as ISO 31000 and ISO 27005 provide terminology and structures; BSI Standard 200-3 translates them into a concrete, usable approach aligned with IT-Grundschutz.
Risk management in the Atlassian ecosystem
In many organizations, projects, service processes, and changes already run in tools from the Atlassian ecosystem. Issues in Jira represent incidents, changes, or the reporting of security incidents. Confluence contains concepts, policies, and logs. Assets structures systems, services, locations, and other configuration items.
Risk management under BSI Standard 200-3 fits into that environment, not alongside it. Risks can be modeled as their own issue type in Jira. Each risk exists as a ticket with a clearly described target object, threat situation, classification, and risk matrix. Links lead to the affected objects in Assets, to concepts and policies in Confluence, and to measures in the form of changes or project tickets.
Risks are assigned Responsible Owners. These individuals are accountable for inherent and residual risk, describe the initial situation, assign measures, and coordinate with the business unit and the ISB. Inherent risk describes the situation without additional measures; residual risk describes the situation after implementing a specific policy, building block, or technical change.
Dashboards in Jira show open risks, high residual risks, overdue reviews, or measures not yet implemented. Assets maps dependencies: a quick look at a system is enough to see which risks are attached to it and which issues are still in progress. Confluence provides an explanation of the method, documentation from workshops, and the formal policy for risk analysis.
This creates a risk register that not only answers audit questions but also reflects the day-to-day work of the teams. NIS-2 speaks of reporting channels, responsibilities, and structured processes. An approach based on BSI Standard 200-3 and Atlassian tools maps exactly that.
Honicon as a partner across standards, regulation, and tools
This is where Honicon comes in. We come from process consulting and bring experience. We know how to model workflows cleanly in Jira, Confluence, and Assets. Certified information security officers on the team are familiar with BSI Standard 200-3, IT-Grundschutz, ISO 27001, and the requirements arising from NIS-2.
In joint workshops, we first establish the methodological foundation: target objects, threats, scales, risk matrix, governance. This is then translated into project structures, issue types, workflows, and fields. Formal requirements become a tangible process that aligns with existing ways of working.
In this way, organizations gain risk management that keeps NIS-2 in view, takes BSI Standard 200-3 seriously, and takes place in the familiar environment of Jira, Confluence, and Assets.