I have seen a recurring pattern across organisations running security programmes. The people you hired to detect threats are spending most of their time looking after the tools meant to find them. It is understandable, modern security platforms are complex, the data volumes are huge, and the environments they cover keep changing.  

Splunk’s State of Security 2025 report, based on a survey of 2,058 security leaders across nine countries, puts a number on it. 46% of SOC teams spend more time maintaining their security tools than on active threat detection and response. 

This has direct consequences. While your team is keeping the lights on, attackers are moving. 

The hidden cost of platform upkeep 

What stands out when you look closely at how SOC time gets spent is how much of it is invisible in dashboards. It only becomes visible after a successful attack. 

• Every hour an analyst spends troubleshooting a broken data source is an hour not spent investigating a suspicious login.  

• Every week consumed by rule tuning is a week your detection coverage drifts further from the actual threat landscape.  

• Every false positive your team investigates is attention pulled from the alerts that matter. 

This is the quiet version of security platform drift.  

The engineers who could address this are the same people fighting incidents, onboarding new systems, and handling stakeholder requests. Platform upkeep has no incident ticket, no SLA, and no escalation path. So, it keeps getting deprioritised, keeps getting deferred, and keeps accumulating. 

That’s how you end up with Splunk’s number. Teams spending more time managing their tools than using them. The maintenance burden isn’t just an efficiency problem, it’s a risk exposure. A team that’s 46% occupied with platform upkeep is a team with 46% less capacity to detect, investigate, and respond to what’s running right now. 

What changes the outcome 

What shifts things is engineering discipline applied to the security platform itself. That means treating the platform as a product that needs to be engineered and maintained, not a tool that’s assumed to keep working. 

In practical terms, that looks like detection rules treated as code, with versioning, review, and testing. Configuration managed as auditable infrastructure rather than clicks in a console. Data pipelines built and maintained as engineered systems rather than ad-hoc connections. 

Where I’ve seen this work well, something important changes:  

• Maintenance becomes planned work, not background firefighting.  

• Detection logic stays aligned with the infrastructure it’s watching.  

• False positives fall.  

• Coverage stabilises.  

• Security analysts spend more time doing what they were hired to do. 

Before chasing another platform or another hire, I’d recommend answering one question honestly. 

If you measured where your team spent its time this week, not estimates but task-level data, how close would your number be to 46%? 

That number tells you more about your true security posture than most board reports ever will because the real risk isn’t in the alerts you see, it’s in what your platform quietly misses while your team is focused elsewhere. 

What it comes down to 

Platform maintenance isn’t going away and modern security tools will always need care. But when half your team’s capacity is absorbed by upkeep, you’re not running a detection capability, you’re running a maintenance function that occasionally catches threats.