01Legal obligation: § 31(2) BSIG
The obligation to deploy attack detection systems was introduced by the German IT Security Act 2.0 (IT-Sicherheitsgesetz 2.0) and applied to KRITIS operators from 1 May 2023 (§ 8a(1a) BSIG, old version). With the NIS2 Implementation Act (NIS2-Umsetzungsgesetz), in force since 6 December 2025, it is now set out in § 31(2) BSIG: operators of critical facilities must deploy systems that “continuously and automatically record and analyse suitable parameters and characteristics from ongoing operations” – in compliance with the state of the art. § 2 BSIG defines SzA as processes supported by technical tools and organisational integration – explicitly not a mere product, but an interplay of technology and organisation. Under § 39 BSIG, implementation must be demonstrated through security audits, reviews or certifications – every three years under the new law (previously every two years under § 8a(3) BSIG, old version).
02The BSI guidance: MUST, SHOULD, MAY and implementation levels
The benchmark for implementation and audits is the BSI’s “Orientierungshilfe zum Einsatz von Systemen zur Angriffserkennung” (guidance on the use of attack detection systems, version 1.1 of 18 November 2024, editorially revised compared with the first edition of September 2022; it still refers to the previous legal situation). The guidance structures the requirements into the three areas of logging, detection and response and formulates them – following the IT-Grundschutz approach – as MUST (MUSS), SHOULD (SOLLTE) and MAY (KANN) requirements; for further orientation it refers, among others, to the modules OPS.1.1.5, DER.1 and DER.2.1. Assessment is based on an implementation-level model from 0 to 5: level 3 means that all MUST requirements are fulfilled in all areas; level 4 additionally requires all SHOULD requirements (exceptions only with sound justification), and level 5 includes the MAY requirements. As a rule, at least implementation level 3 must be achieved for the evidence; downward deviations are permissible only with justification.
03Log sources and logging: visibility before analytics
Effective detection starts with the question of which log data is collected in the first place. The guidance requires identifying all systems relevant to the critical service, storing the necessary log and logging data centrally, and making it available for analysis in filtered, normalised, aggregated and correlated form. Sources should be onboarded with priority from the outside in – from the network perimeters towards the inner network zones, and at system level starting with central critical systems such as process control and automation technology. The scope explicitly covers IT and OT as well as data centres and embedded systems. In addition, data protection and statutory deletion periods must be observed, and a change process must be established that keeps logging up to date whenever the scope changes.
04Detection engineering: Sigma rules and ATT&CK mapping
Detection content is increasingly developed like software: versioned, tested and reusable. Sigma has established itself as the open, YAML-based signature format for log events; rules can be converted into the query languages of common SIEM platforms via sigma-cli and pySigma and shared through the community-maintained SigmaHQ repository. For planning coverage, the BSI guidance recommends a standardised method such as MITRE ATT&CK or ATT&CK for ICS. In version 19 (April 2026), the Enterprise matrix describes 15 tactics, 222 techniques and 475 sub-techniques; mapping your own rules to ATT&CK makes it transparent which attack techniques are detected – and where gaps remain.
05Technology building blocks: SIEM, EDR and NDR
In practice, attack detection emerges from the interplay of several building blocks. A SIEM centrally collects and correlates log data from heterogeneous sources and delivers the required continuous, automated analysis with alerting when thresholds are exceeded. EDR provides detailed telemetry and response capabilities on endpoints and servers; NDR detects anomalies in network traffic and thus also covers areas where agents cannot be installed – such as OT environments or embedded systems. The guidance additionally and specifically requires centrally managed malware detection as well as network-based intrusion detection systems (NIDS) at the transitions between internal and external networks. No single tool fulfils the requirements on its own; what matters is documented coverage of the entire scope.
06Use-case lifecycle and common gaps
Detection use cases are not a one-off project but a portfolio with a lifecycle: threat analysis and prioritisation, rule development, testing and calibration under normal operations (baselining), production operation with tuning, and regular review and retirement. The guidance explicitly requires readjusting detection mechanisms based on the qualification of security-relevant events and keeping signatures up to date at all times. Typical gaps in audits and projects are incomplete log-source coverage, particularly in OT networks, missing or unpractised response processes, no reliable arrangement for analysis outside business hours, alert fatigue caused by uncalibrated rules, and missing documentation of planning and justified exceptions – the latter becomes apparent at the latest when the implementation level is assessed.
