NIS2 Reporting: From Implementation Status to Risk Decision

An implementation status alone does not make information security manageable. The management bodies of especially important and important entities must oversee the implementation of risk-management measures. To do so, they do not need a flood of technical detail, but a robust connection between risk, effectiveness, accountability and decision-making.

By Andreas Rühl · Published on 27 July 2026 · Sources reviewed on 27 July 2026

Note: This article explains requirements and one possible governance practice. It is neither a substitute for determining whether an entity falls within the scope of the BSIG nor for legal advice.
Legal status: BSI Act of 2 December 2025, in force since 6 December 2025, as amended by Article 4 of the Act of 11 March 2026.

Even a complete report may still fail to support a decision

Imagine a monthly report submitted to the management body. The first page lists 37 security measures in the implementation plan. Of these, 21 are green, 12 amber and 4 red. Alongside them are percentages indicating the degree of implementation.

The presentation looks orderly. Nevertheless, the crucial questions remain unanswered:

What business risk lies behind the four red measures?
Which services or processes could be affected?
Will the planned measure actually reduce the risk?
Who is accountable, and by when must action be taken?
Does the management body need to make a decision, or merely take note?

The example is hypothetical. The report’s weakness, however, is clear: it documents activity but does not enable decision-making.

This establishes a clear benchmark for NIS2 reporting. The management body does not need to master every technical detail. To exercise effective oversight, it needs information that enables it to assess whether material risks are being addressed appropriately, whether measures are effective and whether a decision or escalation is required. The questions in the BSI guidance are also directed towards this objective.

What the BSIG requires of management bodies

For especially important and important entities, responsibility is expressly regulated in the BSI Act.

§ 38(1) BSIG requires their management bodies to implement the risk-management measures to be taken under § 30 and to oversee their implementation. Subsection 3 requires regular training. This training is intended to provide sufficient knowledge and skills to identify and assess risks and risk-management practices and to evaluate their impact on the services provided.

For loss culpably caused, § 38(2) initially refers to the corporate-law liability rules applicable to the entity’s particular legal form. Only where those rules do not contain a corresponding liability provision does the BSIG itself establish liability towards the entity on a subsidiary basis. Whether liability exists in an individual case depends, among other things, on a breach of duty, fault and loss. A blanket statement that management bodies are liable for every “NIS2 error” would therefore be too broad.

§ 30(1) BSIG requires appropriate, proportionate and effective technical and organisational measures. Under sentence 3, compliance with this obligation must be documented. Subsection 2, number 6 expressly refers to policies and procedures for assessing the effectiveness of risk-management measures.

Three levels must therefore be distinguished:

Measures are planned or approved.
Measures have actually been implemented.
Measures achieve the intended effect on risk.

From the perspective of governance capable of supporting decisions, a management report remains incomplete if it shows only the first or second level.

The Act does not, however, prescribe a particular dashboard, a fixed reporting frequency or a list of mandatory metrics. For the proportionality of measures, § 30(1), sentence 2 expressly refers to the extent of exposure to risk, the size of the entity, implementation costs, and the likelihood and severity of possible security incidents, including their societal and economic impacts. The format, scope and frequency of a report can be guided by the same criteria.

Why evidential capability is more than good governance

Under § 30, the documentation obligation applies to the entity. Anyone who, contrary to § 30(1), sentence 3, intentionally or negligently fails to document compliance, or documents it incorrectly or incompletely, commits an administrative offence under § 65(2), number 3 BSIG. The ranges of fines differ according to the type of entity and, in some cases, its turnover. This institutional level of sanctions must be distinguished from the management body’s potential personal internal liability under § 38(2).

Supervision also follows this distinction. In relation to individual especially important entities, the BSI has more extensive inspection and enforcement powers under § 61 BSIG. Among other things, it may order independent bodies to conduct audits, inspections or certifications concerning the expressly specified obligations, including the training obligation under § 38(3). It may also review compliance with the statutory requirements. For important entities, § 62 BSIG requires facts suggesting that certain obligations have not been implemented, or have not been implemented correctly; the BSI may then review compliance and take measures under § 61.

None of these provisions prescribes a format for management reports. A traceable connection between risk, measure, evidence of effectiveness and decision does, however, improve the ability to provide information and demonstrate compliance during an inspection.

Oversight is more than taking note of a status

The BSI provides further detail on the role of the management body in its guidance document “Training for management bodies”, version 1.0 dated 17 April 2026.

As current official guidance, the document translates the requirements into key questions without itself constituting law. The BSI describes its objective as enabling management bodies to make informed and well-founded decisions in the context of cyber risks. It recommends structured questioning, strategic involvement and continuous review.

Practices identified as helpful by the BSI include:

documented risk-management measures;
regular assessment of their effectiveness;
incorporation of the results into the ISMS and management reports;
metrics relating to risks and effectiveness;
regular discussion of this information with the management body.

This does not imply a need for a complex system of metrics. The benchmark is whether the information presented supports oversight and risk decisions.

Five components of a decision-ready report

For practical purposes, I derive five components from these requirements. They are a professional recommendation, not a statutory list of minimum fields. Other forms of presentation may be equally suitable, provided that the essential relationships are apparent.

1. Risk and business significance

The report begins not with the measure, but with the risk.

This may include, for example:

the affected service or business process;
the relevant threat or outage scenario;
possible effects on availability, integrity or confidentiality;
operational, financial, regulatory or customer-related consequences;
the current risk assessment and its rationale.

“Patch management red” is not an adequate statement of risk. A more meaningful formulation would be: An internet-facing order-processing system has critical known vulnerabilities; the regular maintenance process has exceeded the internally defined time frame.

2. Measure and intended effect on risk

Every measure should be linked to its intended effect on risk.

Not every completed activity automatically reduces the material risk. A new policy, a procured tool or completed training initially demonstrates only that something has been done. What matters is its expected, and subsequently demonstrated, effectiveness.

Helpful questions include:

Which risk-treatment strategy does the measure pursue: avoidance, mitigation or transfer?
What assumptions underlie this expected effect?
Are there dependencies or compensating measures?
Will a relevant residual risk remain after implementation?

3. Evidence of effectiveness and development over time

A traffic-light status shows whether something is considered complete. It does not automatically show whether it works.

Depending on the measure, different forms of evidence may be appropriate for demonstrating effectiveness:

technical tests or sampling;
audit and assessment results;
exercises and recovery tests;
processing and response times;
trends in a risk metric;
recurring exceptions or control failures;
documented variances between the target and actual state.

Relevance to decision-making is therefore more important than ease of measurement. The number of closed tickets may increase while particularly critical vulnerabilities continue to remain unresolved for too long.

The European context illustrates why time and effectiveness matter. For its NIS Investments 2025 report, ENISA surveyed 1,080 professionals and managers from all 27 EU Member States. Of the organisations surveyed, 30 per cent had not conducted a cybersecurity assessment in the preceding twelve months, while 28 per cent required more than three months to patch critical vulnerabilities on critical systems.

The survey does not demonstrate the effectiveness of any particular reporting model. Its practical relevance lies in showing that a green implementation status may have limited meaning without reference to effectiveness and time. Because participation was voluntary and the sample was not designed in proportion to sectoral or market structures, the percentages are not representative prevalence estimates for the EU or Germany.

Methodological context: The telephone interviews took place from May to August 2025 and therefore before the German BSIG entered into force. The survey covered only sectors of high criticality under Annex I to the NIS 2 Directive; 83 per cent of the organisations were large enterprises and 17 per cent were SMEs. Other critical sectors under Annex II to the same Directive were not included in the sample.

4. Accountability, deadline and dependencies

A measure can be managed only if an accountable role and, depending on the type of measure, a deadline, review interval or target value have been defined.

The report must show:

which role is accountable for implementation and evidence;
which deadline, review interval or target value applies, and why;
which resources or decisions are lacking;
which third parties, systems or projects the implementation depends on;
when escalation will occur.

Simply naming a department is often insufficient. “IT” is not an unambiguous accountable role. The management body must also be able to determine whether a problem is being held up by insufficient resources, a conflict of objectives, a technical dependency or unclear accountability.

5. Noting, decision, escalation or risk acceptance

For every material item, the required treatment should ultimately be clear:

for noting: The measure is within the agreed parameters and requires no decision;
for decision: The budget, priority, risk treatment or exception must be determined;
for escalation: A deadline, risk threshold or effectiveness target has been exceeded;
for risk acceptance: A remaining risk is to be consciously and transparently accepted.

This transforms the report from an overview of activities into a management instrument.

Example: from implementation status to a decision paper

Consider a simplified, hypothetical example from vulnerability management.

Status report only:

Critical vulnerabilities: 42
Of which overdue: 9
Status: Red

The figures provide an overview of the situation, but are not sufficient on their own to support a management decision.

Decision-ready presentation:

Risk: Nine critical vulnerabilities have exceeded the defined remediation target. Two affect an externally accessible service required for order intake.
Cause: The necessary maintenance window was postponed twice because of a peak operating period.
Compensating measures: Additional monitoring and a temporary access restriction reduce exposure but do not eliminate the vulnerabilities.
Accountable role and date: Head of IT Operations; implementation by the infrastructure team during the next technically feasible maintenance window on the specified date.
Decision: Approve the maintenance window despite possible disruption to operations, or expressly accept the remaining risk until the later date.

The added value of the second presentation does not lie in its length. It connects the technical problem with the business impact, risk treatment and a specific decision.

What the management body does not need

Enabling decisions does not mean reporting every technical detail at management-body level.

As a rule, a management body does not need a complete list of all vulnerabilities, log entries or control steps. Too much detail can obscure material risks just as effectively as too little information.

Operational security work may be distributed among the responsible functions and teams. The management body’s own responsibility cannot, however, be transferred in this way. The BSI states in this regard that the management body must ensure that cybersecurity is an integral part of business activities and risk management and that it cannot delegate this task. The report must therefore provide the information that enables it to exercise this responsibility in practice.

A suitable reporting architecture distinguishes between several levels:

operational level: detailed processing, technical evidence and ongoing controls;
management level: aggregated risks, measures, effectiveness, exceptions and trends;
executive level: material exposures, conflicts of objectives, exceedances and decisions.

An escalation framework connects these levels. It defines when an operational matter must be included in the management report because of its risk, duration, impact or lack of effectiveness.

Five review questions for the existing report

The five components can be applied as a short practical test of an existing NIS2 or security report:

Which material business risks have changed since the last report?
Which measures are intended to reduce these risks specifically, and what assumptions underlie the expected effect?
How do we know that the measures are actually effective, and which target values or risk thresholds have been exceeded?
Which role is accountable, and which deadline, review interval or target value applies? Which dependencies are blocking implementation?
Which specific decision, escalation or documented risk acceptance is required today?

If these questions remain unanswered, the problem is not necessarily a lack of documentation. Often, what is missing is the connection between security work and leadership.

Conclusion: management capability arises from clarity of decision-making

NIS2 does not make information security a management responsibility solely by introducing new obligations. § 38 BSIG addresses the management bodies of especially important and important entities personally: they must implement the risk-management measures under § 30 and oversee their implementation.

A report does not fulfil this purpose merely because it appears complete. It must help the management body classify risks, assess the effectiveness of measures, identify conflicts of objectives and make necessary decisions in a traceable manner.

The crucial question is therefore not “How many measures are green?”, but:

Which risk decision can the management body make robustly on the basis of this report?

An initial practical test focuses on the three most important red items: Are the risk, evidence of effectiveness, accountable role and required decision clearly identifiable in each case?

Further information on reviewing existing reporting structures is available through my NIS2/KRITIS consulting services.

Sources

About the author

Andreas Rühl supports organisations as an interim CISO and ISMS/GRC consultant, including in relation to NIS2/KRITIS, ISO 27001, BSI IT-Grundschutz, TISAX, security governance and audit readiness. His focus is on making information security manageable, auditable and suitable for management oversight.