Key Takeaways<\/p>\n
- \n
- Cost is a legitimate factor:<\/strong> Section 30 of Germany’s BSIG (Federal Office for Information Security Act) requires appropriate, proportionate, and effective measures-and explicitly cites implementation costs as a criterion. Reducing tools is permitted.<\/li>\n
- The law doesn’t mandate specific tools:<\/strong> Section 30 defines ten minimum measures as functions. Whether MFA is delivered by one vendor or another is secondary; what matters is that it’s enforced.<\/li>\n
- A control is a function; a tool is just the vehicle:<\/strong> Decommissioning a tool without migrating its underlying function creates a visibility or compliance gap that will be flagged in an audit.<\/li>\n
- Effectiveness must remain provable:<\/strong> Section 30(2)(6) requires documented concepts and procedures to assess effectiveness. Consolidation without proof of continuity is an open audit risk.<\/li>\n<\/ul>\n<\/div>\n
Related:<\/span>Third-party risk is a program, not an audit checklist<\/a> \/<\/span> Why an ISO certificate alone isn’t enough for Germany’s BSI<\/a><\/p>\n
Here’s the translated HTML with full journalistic quality and cultural adaptation:<\/p>\n
Why the security stack is shrinking and where compliance boundaries lie<\/h2>\n
What is security stack consolidation?<\/strong> Security stack consolidation involves strategically merging or decommissioning security tools to reduce licensing costs, integration overhead, and alert noise. Multiple point solutions are typically consolidated into a single platform – for example, combining detection and response capabilities into a unified SIEM and EDR stack.<\/p>\n
The pressure to consolidate is very real. Over time, many security teams accumulate a sprawling tool zoo, where each solution brings its own parsers, interfaces, and maintenance burden. Alert fatigue compounds the problem: when teams miss genuine threats amid the noise of false positives, sometimes less actually means more security. That’s why consolidation often proves to be a sensible decision.<\/p>\n
Regulations don’t stand in the way of this trend. Section 30(1) of Germany’s BSIG (Federal Office for Information Security Act) requires “suitable, proportionate and effective” security measures, explicitly listing implementation costs as one of several proportionality factors – alongside risk exposure, organizational size, and potential damage. Cost pressure is therefore a legitimate consideration. The compliance boundary lies elsewhere: while paragraph 1 mandates effectiveness, paragraph 2(6) requires documented concepts and procedures to evaluate that effectiveness. Cost-cutting is permitted – but organizations violate their effectiveness obligations if they decommission a tool without maintaining the required security function it provided.<\/p>\n
A control is a function-tools are just the vehicle<\/h2>\n
Nearly every failed consolidation effort stumbles over the same misconception: thinking in products, not in functions. A control is a demonstrable capability-enforcing MFA for privileged accounts, keeping logs correlated over a defined period, or regularly testing backup restores. The tool is merely the carrier of that capability. Consolidation means reducing the number of carriers while retaining every capability.<\/p>\n
I once inherited two vulnerability scanners-one tightly configured, the other lax. Cost pressures led to the more expensive one being dropped. That was the strict one. On paper, vulnerability management continued; in practice, coverage shrank and response times quietly stretched. That\u2019s how gaps emerge: the shutdown itself is harmless, but the unnoticed erosion of control depth does the damage.<\/p>\n
Three patterns keep recurring. A log source disappears, but the detection rule in the SIEM stays in place, running on empty. An EDR covers workstations, but after a tool switch, servers or Linux hosts end up agentless. Or a strict control is replaced with a looser one-say, conditional access is swapped for a basic VPN. In every case, the function remains on the slide deck but vanishes from operations.<\/p>\n
Ten Mandatory Measures No License Can Replace<\/h2>\n
Section 30(2) of the BSIG (Federal Office for Information Security Act) lists ten minimum requirements. They serve as the litmus test for any decision to decommission a tool. The following overview translates the most critical measures into operational terms and specifies what must remain intact during a tool transition.<\/p>\n
\n - The law doesn’t mandate specific tools:<\/strong> Section 30 defines ten minimum measures as functions. Whether MFA is delivered by one vendor or another is secondary; what matters is that it’s enforced.<\/li>\n
![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/tprm-lieferkettenrisiko-nis2-dora-programm-cover-hero-250x143.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/06\/nis2-aufsichtsphase-bsi-pflichten-deutschland-cover-hero-250x143.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/05\/nis2-compliance-mittelstand-umsetzung-praxis-cover-hero-250x143.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/net-geopolitik-datacenter-roadmap-lieferkett-8054517-250x143.jpg\")
<\/span>![\"\"](\"https:\/\/www.securitytoday.de\/wp-content\/uploads\/2026\/07\/net-eu-ai-act-2026-kennzeichnungspflichten-m-35346140-250x143.jpg\")
<\/span>