The Hidden Tax on Security: How Data Costs Are Eating Your Controls Budget
A few months ago I was in a conversation with a CISO at a large financial institution that I’ve known and respected for years, and she said something that every CISO I know has felt but doesn’t get said nearly loudly enough. “Preston, I can justify every dollar I spend on detection. I cannot justify what I’m spending just to move data.”
That statement was more precise than it might sound. She wasn’t complaining about a vendor invoice. She was describing a structural problem that is quietly eroding security programs at organizations of every size: a growing and largely invisible share of the security budget is being consumed by the act of moving, normalizing, and ingesting data — before a single detection fires, before a single analyst touches a case, before any security control delivers any value. The money is gone before the work begins.
This is a conversation the industry needs to be having — one as consequential as which threat actor is targeting which sector, or which framework to adopt next. The infrastructure tax that is steadily bleeding resources away from the controls, tools, and people that actually reduce risk deserves the same attention.
A Budget Built on Sand
Security budgets are typically framed around outcomes: detection coverage, response capability, compliance posture, risk reduction. What they rarely account for explicitly is the cost of getting data to the point where any of those outcomes are possible. Data movement and ingestion are treated as infrastructure overhead — a line item that gets buried in platform costs or allocated to IT rather than examined as a security spend category in its own right. That accounting convention obscures a serious problem.
A mid-size enterprise today can generate terabytes of security telemetry per day across cloud workloads, SaaS applications, endpoint agents, network infrastructure, identity systems, and an expanding IoT and OT footprint. Every one of those sources needs to be connected, normalized, and delivered to the controls and platforms that make use of it. The attack surface has grown dramatically, and the cost of instrumenting that surface has grown with it in ways that most security budget models have not caught up to.
The result is a quiet but persistent reallocation of resources. Dollars that were planned for new detection capabilities, threat intelligence programs, or analyst headcount end up absorbed by ingestion overages, data maintenance, and the engineering effort required to keep telemetry flowing. Security leaders discover midway through their fiscal year that they are tracking cost overages for their data platform budgets — not because the program expanded, but because the data kept growing and the pricing model billed accordingly. The controls budget takes the hit.
The True Cost of Moving Security Data
The dollar figure on a SIEM or data platform invoice is only part of what data movement actually costs a security program. The fuller accounting includes several categories of spend that rarely appear on the same page.
Engineering time is the largest and most underappreciated component. Every security data source — firewall logs, cloud audit trails, endpoint detection events, authentication records, DNS queries, SaaS activity logs — arrives in a different format, with different field names, different timestamp conventions, and different levels of completeness. Normalizing and mapping all of that telemetry into a coherent schema is labor-intensive and fragile work. It requires people who sit at the intersection of security operations, software development, and data architecture. Those people are expensive to hire, harder to retain, and their time spent maintaining data movement is time not spent on detection engineering, threat hunting, or incident response. The trade-off is direct and rarely made explicit.
Schema drift compounds the problem. Vendors update log formats in routine releases. Cloud providers change event structures. SaaS applications add fields without notice. A parser that took weeks to build can silently break overnight, and the gap in telemetry coverage may go undetected for days or weeks. This is precisely the window an adversary needs. Managing schema drift is a continuous operational burden that consumes engineering cycles that security programs can ill afford.
Source onboarding lag carries its own cost. When a new business system goes live, when an acquisition adds a new network environment, or when a cloud migration introduces a new logging architecture, security visibility does not begin until that telemetry is flowing, normalized, and mapped to detection logic. In complex organizations, that onboarding process routinely takes months. During that window, the environment is instrumented on paper but dark in practice. Adversaries operate with far more freedom than the coverage map suggests.
Filtering decisions create the most consequential cost of all: coverage gaps that become adversary opportunity. When ingestion budgets are exhausted mid-year, the pragmatic response is to reduce what comes in. Lower-priority sources get dropped. Verbose but high-value telemetry gets sampled. Log retention windows get shortened. Each of these decisions is defensible in isolation. Collectively, they carve out the blind spots where sophisticated threat actors have learned to operate, knowing that cost pressure makes full instrumentation unlikely.
What Gets Crowded Out
The downstream effect of all of this on actual security capability deserves to be named directly. When data movement consumes a disproportionate share of the security budget, specific categories of investment suffer.
Detection engineering capacity shrinks. The analysts and engineers who should be building new detection logic, tuning existing rules, and developing behavioral baselines spend their cycles instead on data issues, parser failures, and telemetry gaps. Detection content stagnates. Coverage against emerging techniques deteriorates. The SIEM fills with aging rules while the threat landscape moves on.
Threat hunting programs get starved. Effective threat hunting depends on broad, high-fidelity telemetry that can be queried retrospectively across meaningful time windows. When ingestion cost pressure forces organizations to narrow their data retention or limit which sources flow into the analytics tier, the investigative surface shrinks with it. Hunters are left working with partial data, which means partial conclusions and missed detections.
Analyst headcount gets constrained. In conversations with security leaders across industries, one pattern appears consistently: when platform and infrastructure costs rise unexpectedly, the first offset considered is headcount. Not because people matter less, but because headcount is the largest discretionary line item and the most visible place to find budget relief. The result is that the people capable of acting on security data are reduced precisely as the cost of acquiring that data rises.
Tool consolidation decisions get forced prematurely. When ingestion budgets are under pressure, security leaders are pushed toward reducing the number of platforms they feed data into, regardless of whether those platforms are delivering value. Purpose-built tools for identity threat detection, cloud security posture, network analytics, or OT visibility get cut not because they aren’t effective, but because the cost of supplying them with telemetry has become untenable. The security program narrows in response to data economics, not risk prioritization.
A Different Approach to the Infrastructure Layer
The conventional response to this pressure has been to negotiate lower per-gigabyte pricing, compress log formats, or hire more data engineers. Those are tactics, not solutions. They address the symptom without touching the structural issue, which is that the ingestion layer is being treated as undifferentiated infrastructure when it should be treated as a strategic control point.
An ingestion architecture built with security economics in mind does something fundamentally different: it routes telemetry based on its actual detection and investigative value before it ever reaches the analytics platform. High-fidelity, time-sensitive signals — authentication anomalies, privilege escalation indicators, lateral movement telemetry, command-and-control patterns — belong in a real-time analytics tier where they can be correlated and acted on immediately. High-volume, lower-urgency data — DNS query logs, verbose application event streams, network flow records — carries real investigative and compliance value but does not need to be processed at the same cost tier in real time. Routing these streams deliberately, upstream, can produce cost reductions of 40% to 60% on analytics-tier ingestion without reducing detection coverage or investigative capability.
This tiered approach also changes the economics of source onboarding. When the ingestion layer is capable of applying normalization, classification, and routing logic at ingest time rather than relying on downstream transformation, new sources can be connected and validated faster. The engineering burden shifts from bespoke parser development toward configuration and policy. The time between a new environment coming into scope and security visibility beginning compresses from weeks to days.
The broader point is that the ingestion layer is not neutral infrastructure. It is where coverage, cost, and timeliness are determined for every detection and investigation that follows. Security leaders who treat it as a strategic layer that enforces data governance, routing policy, and cost discipline will find more budget available for the controls and people that actually reduce risk.
Four Questions Worth Asking Before the Next Budget Cycle
The security programs that navigate this challenge most effectively will not necessarily be the best-funded ones. They will be the ones that applied deliberate architectural thinking to their data infrastructure before the budget pressure arrived. Four questions are worth bringing into the next planning conversation.
Do you know your top ten most expensive security data sources by ingestion volume and cost? If the answer is no, that visibility gap is worth closing before the next budget cycle. Cost discipline at the source level is the precondition for any meaningful reallocation toward controls.
Do you have a documented telemetry classification policy that specifies which sources belong in which analytics tier, at what latency, and under what retention requirements? Most security programs don’t, and the absence of that policy is what makes ingestion costs unpredictable and budget overruns recurring.
How long does it take your team to onboard a new security data source end-to-end, from initial connector development to validated, normalized telemetry flowing through detection logic? If the answer is measured in weeks or months, that lag is a coverage gap with direct risk implications. Every week without visibility is a week where the environment is instrumentally unprotected.
How much of your current ingestion spend is being driven by telemetry that has never contributed to a detection or an investigation? For most programs, the honest answer is substantial. That is where the reallocation conversation becomes possible — and where the budget that belongs in controls can be recovered.
This all requires a deliberate decision to treat the data ingestion layer as a first-class security architectural decision, not an operational afterthought. When security leaders design a data pipeline layer with the same intentionality they bring to detection platforms, response tooling, and control frameworks, the economics shift. Data ingestion and engineering costs that once silently consumed 30% to 40% of the security budget become efficient, governed infrastructure with predictable costs and measurable coverage. The dollars that were absorbed by ingestion overages, parser maintenance, and reactive data engineering flow back into the program — into detection engineers who build and tune content, into analysts who hunt and investigate, into controls that actually intercept adversary behavior. The pressure on security budgets is real and will only grow as data volumes expand and attack surfaces multiply. The answer is not to accept that data costs are fixed and coverage gaps are inevitable. The answer is to build smarter — to treat data movement as a strategic capability that serves the security mission, not competes with it — and to redirect every recovered dollar toward the people and controls that exist to protect the organization.
