Essential Controls When Reducing Security Tools

By Alec Chizhik · June 26, 2026 · 9 min read

Here’s the translated HTML with full cultural adaptation and journalistic quality:

A typical scenario: three fewer tools, noticeably lower licensing costs, and a happy finance department. Six weeks later, the first real alarm goes off. A service account is rotating passwords overnight, with activity spanning three network segments. The SIEM is missing firewall logs from the decommissioned perimeter tool. Detection was there, but correlation failed because the log source was never migrated to the new platform. Consolidation saves money-but it must never take critical functions with it.

Key Takeaways

Cost is a legitimate factor: 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.
The law doesn’t mandate specific tools: 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.
A control is a function; a tool is just the vehicle: Decommissioning a tool without migrating its underlying function creates a visibility or compliance gap that will be flagged in an audit.
Effectiveness must remain provable: Section 30(2)(6) requires documented concepts and procedures to assess effectiveness. Consolidation without proof of continuity is an open audit risk.

Here’s the translated HTML with full journalistic quality and cultural adaptation:

Why the security stack is shrinking and where compliance boundaries lie

What is security stack consolidation? 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.

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.

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.

A control is a function-tools are just the vehicle

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.

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’s how gaps emerge: the shutdown itself is harmless, but the unnoticed erosion of control depth does the damage.

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.

Ten Mandatory Measures No License Can Replace

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.

Mandatory Control (Section 30)	Typical Tool	Can Tool Be Decommissioned?	What Must Remain in Place
Incident Response (No. 2)	SIEM, EDR/XDR, SOAR	Yes, if migrated	All log sources integrated, detection rules, alert routing, playbooks, retention periods, reporting capabilities
MFA and Secure Communication (No. 10)	Entra ID, Okta, Duo	Yes, if identity providers are consolidated	Enforced policy for remote access and privileged accounts, documented exception process
Procurement, Maintenance, Vulnerabilities (No. 5)	Tenable, Qualys, Rapid7	Yes, if coverage, depth, and timelines remain equivalent	Full asset coverage including cloud, patch timelines, vulnerability reporting process
Business Continuity and Backup (No. 3)	Veeam, Rubrik, Cloud Backup	Yes, with caution	Tested restore-not just successful backup jobs-immutability, documented RTO and RPO
Personnel Security, Access, Assets (No. 9)	IAM, CMDB	Partially	Access lifecycle management, privileged access controls, inventory of all critical assets
Effectiveness Assessment (No. 6)	GRC platform, manual processes	Yes, tools are interchangeable	Measurable evidence, KPI dashboard, audit history. This data must not vanish with the old export

Two legal principles underpin this table. Section 30(1) of the BSIG requires compliance to be documented. If evidence is tied to a decommissioned tool, an audit gap immediately emerges. For financial institutions subject to DORA (Digital Operational Resilience Act), DORA’s requirements for ICT risk management and incident reporting take precedence over the relevant BSIG obligations. Consolidation changes nothing about these requirements-only how they are technically implemented.

Five Pitfalls That Surface After Decommissioning

Mistakes rarely reveal themselves immediately. They emerge during the next incident or audit-long after the cost-cutting project has been declared complete.

Orphaned interfaces. An automation playbook keeps calling the API of a decommissioned tool. Detection works, but response stalls. The delay hits hardest where speed matters most.

Missing log sources. Firewall, proxy, cloud logs, or identity logs aren’t reconnected after the switch. Correlation breaks without anyone noticing an error-because nothing comes through at all.

Duplicate controls with inconsistent rigor. Two paths for the same process, one stricter than the other. The more expensive option gets cut, often without migrating the policy first. What remains is the looser version as the new default.

Evidence tied to the tool. Export reports, audit trails, and pentest documentation still reference old product names. When the auditor asks about continuity, the answer is nowhere to be found.

Skipped effectiveness assessment. The consolidation is checked off as “done” without verifying its impact before or after. That leaves a critical gap-the proof required by Section 30(2)(6) of Germany’s regulatory frameworks.

The Right Approach: Control Inventory Before Tool Inventory

The sequence determines the outcome. Starting with the license list shortchanges controls. Starting with the control inventory shortchanges tools. Six steps keep functionality intact while tools come and go.

First: Translate every mandatory measure from Section 30 into operational functions and measurable metrics-such as the share of assets with EDR, MFA coverage for admin accounts, or mean time to detection. Second: Build a matrix showing which tool covers which function, with what level of robustness, for which asset class. Third: Only phase out tools whose functions have been fully replicated and tested in the target system-not just listed as present in the vendor’s documentation.

Fourth: Define a migration path for each mandatory function, from log forwarding and detection rules to backup jobs, complete with a fallback plan. Fifth: Provide proof of effectiveness through before-and-after measurements, a restore test, and a run-through of the incident playbook. Sixth: Date the documentation to the point of control migration. What matters is when the function was transferred, not when the license was terminated. For critical functions like logging, EDR, and backup, a few weeks of parallel operation are worth the short-term cost to avoid the blind spot where no one knows if detection is still working.

Here is the translated HTML, adhering to all specified rules:

Frequently Asked Questions

Each question is locked. Tap to unlock the answer.

Can I consolidate security tools under NIS2 and the BSIG to reduce costs?

Yes. Section 30(1) of the BSIG (German Federal Office for Information Security Act) explicitly cites implementation costs as a proportionality criterion. However, cost savings do not justify omitting a mandatory function. Measures must remain effective, and their effectiveness must be demonstrated.

Are any controls in Section 30 of the BSIG tied to a specific tool?

No. The law defines requirements, not products. MFA, logging, backup, and vulnerability management must function effectively. Whether this is achieved through one provider or another is an implementation decision.

What happens to our audit records if we replace our SIEM or GRC platform?

Historical records must be archived. From the point of consolidation onward, new evidence of effectiveness will be generated by the replacement tool. Any gap in this chain could pose problems when demonstrating compliance to regulators.

Does DORA override NIS2 if we are a financial institution?

For ICT risk management and reporting of significant incidents, DORA (Digital Operational Resilience Act) takes precedence as the more specific regulation. However, any tool consolidation must continue to meet the requirements of the ICT risk framework.