Data access: the hidden cost of security vendor lock-in
Getting data into a security platform is always easy; getting it back out is where vendors add cost, extra tooling, and latency, and it is the part of the evaluation most teams overlook.
Your security data is the most important asset in your SOC. Not the dashboards, not the detections, not the AI features on the roadmap slide. The data. And most vendors make you pay, wait, or license your way to getting it back out. Every investigation your analysts run, every model you train, every agent you deploy is only as good as the telemetry underneath it. So here is the question I want you to ask every vendor in your stack: if I want my data, right now, what does that take?
Most vendors cannot answer it cleanly. And the answer matters more than almost anything else on the RFP.
What open actually means
The industry has gotten comfortable treating “open” as a checkbox. Support an open schema, publish an API, sponsor a standard, done. But a standard tells you how data is shaped. It tells you nothing about whether you can actually get it. Open data means three things, and you need all three:
It is yours, at no additional cost. You generated this telemetry. You paid to collect it, and you paid to store it. If your vendor charges you a second time to access it, that is not a data feature. That is a toll booth on your own driveway.
It is all of your data. Not the alerts. Not a normalized summary. Not the tables the vendor decided are ready. The full-fidelity record because you cannot predict today which field matters in next year’s investigation.
It is real time. This one used to be a nice-to-have. Not anymore. CrowdStrike’s own 2026 Global Threat Report clocked the average eCrime breakout time at 29 minutes, the fastest at 27 seconds, and one intrusion where exfiltration started four minutes after initial access. Attackers are moving faster too, using AI to shorten the gap between breaking in and doing real damage. If your telemetry arrives in batches, minutes apart, the attack can be over before your data shows up. You would not accept a smoke detector that checks for fire twice an hour.
When a vendor fails any of these three, they are not protecting your data. They are building an artificial moat with it. Ingestion is always frictionless. Egress is licensed, delayed, or degraded. That asymmetry is not an accident of engineering. It is the business model, and the industry has a name for it: lock-in.
What the documentation actually says
Don’t take our word for it. Every claim in this table links to the vendor’s own documentation. Read it yourself, and hold us to the same bar.
Vendor | How you get your data out | Cost to access your data | Freshness | Fidelity | Openness |
CrowdStrike | Falcon Data Replicator: batched file export to object storage | Bulk batches, not a live stream; deleted after 7 days for CrowdStrike managed-buckets | Raw telemetry is only available via FDR; the event stream API sends detections, not telemetry | Restricted | |
Palo Alto Networks | XSIAM Event Forwarding: batch files to a Palo Alto-managed bucket | Two paid Event Forwarding add-ons: GB and Endpoint | Endpoint and log data split across the two add-ons | Restricted | |
Microsoft | Defender streaming API; Sentinel data export | Streaming: pay Azure infra; Sentinel export billed per GB | Real-time stream (via Azure Event Hubs) | Generally-available fields only; Azure destinations only | Partially open |
Bulk export to your storage, or a continuous BigQuery feed | Export capped; BigQuery billed by query | Live feed 5-10 min behind (top tier only); raw export is point-in-time | Live feed is normalized only; no continuous raw path | Limited | |
Splunk | Included | On-demand query via export data API; data available near-real-time | Full events returned as structured JSON | Open | |
Elastic | REST APIs including Search, Point in time and ES|QL | No export license or per-query export fee; Elastic Cloud applies ordinary cloud data-transfer metering, not an egress toll | On-demand query via API; data available to query as soon as it is indexed | Full raw and parsed events, returned as structured JSON | Open |
This table reflects each vendor's public documentation as of September 2026.
A note on the ratings, because we want them to be defensible, not convenient. Open means all three tests pass: no added cost, full fidelity, and no batch window between the moment data arrives and the moment you can use it. Data you can query the moment it lands clears that bar; a scheduled batch measured in minutes or hours does not. Partially open means the vendor genuinely tries but with real constraints; credit to Microsoft for a true streaming path, even if it covers only generally-available fields and only lands in Azure. Limited means the data comes back, but late or in a form only the vendor can read. Restricted means access to your own telemetry is a paid product, a delayed batch, or both.
And since Elastic is on this list too, as an endpoint agent and a SIEM, hold us to the same bar. Our rating is about live access: APIs that return JSON, with no license between you and your own telemetry. On Elastic Cloud you pay ordinary data-transfer rates like any cloud service. What you never pay is a license to reach data that was already yours.
If any vendor believes we have mischaracterized their documentation, I genuinely want to hear it, and we will correct it.
So what does this actually cost you?
Here is what that comparison means when it really counts, in the middle of an incident. Detection you cannot act on in time is not detection. When your telemetry arrives in scheduled batches, a window opens between the alert and the evidence. Sometimes minutes, sometimes longer, and in that window the attack is live while your data is not yet in front of you. You paid to collect that telemetry. You paid to store it. And at the one moment it matters, it is still in transit. Or worse, it is not there at all because exporting it requires a separate license. That’s the difference between stopping an intrusion and reading about it afterward.
You do not create that gap during an incident. You inherit it at purchase. You already run a strong endpoint agent. It works, and you trust it. Now that same vendor offers to be your SIEM as well. One console, one relationship, one invoice. There is nothing wrong with one vendor doing both. We do both at Elastic. The question is what it costs you to change your mind. So look closely at what it takes to move that endpoint telemetry somewhere other than their own platform. Every vendor makes it easy to get data in. Getting it back out is something you buy, then wait for.
It is rarely just one handoff. Most security environments are heterogeneous by design, with each layer chosen because it is good at its own job. Modern attacks move across all of them, from a stolen identity to a cloud workload to an endpoint, and you only see the full chain if the data from each can meet in one place, quickly and without a toll. When a vendor makes its telemetry expensive or slow to share, it is not just charging you. It’s fragmenting the picture, and a fragmented picture is exactly where intrusions hide. The all-in-one pitch offers to solve that. But the fragmentation was manufactured: vendors made their data hard to move, then sold you the one console where it comes back together. So before convenience makes the decision for you, ask three questions, and make the vendor answer them in writing:
Can I get all of my telemetry out, continuously, without buying a separate license to do it?
How long, exactly, from the moment an event happens to the moment it is usable in a system I chose?
On the day I add a different analytics engine, a data lake, or a new AI model, what breaks?
If the honest answers are “extra cost,” “in batches,” and “quite a lot,” then you are not buying a SIEM. You are renting access to your own data. The point is not that these layers must stay separate. Plenty of teams consolidate for good reasons, and we sell both layers ourselves. The point is that the choice should stay yours: you can add the analytics platform you want, or leave the one you have, without paying a toll or waiting on a batch to get your own data. The only reason to accept less is that a vendor made leaving hard enough that staying felt like a decision. It was not a decision. It was the absence of one.
The strategic question
Your SIEM is not a tool you bought. It is where isolated alerts become an attack story, and where you go to find out what actually happened. The vendor holding it is a strategic dependency, whether you planned it that way or not.
So evaluate them like one. Put data portability on the RFP, not in the demo, and score it on two things: what it costs to move your telemetry somewhere else, and how much delay it adds.
Because you cannot build a real-time defense on a delayed copy of your own telemetry, and you should not have to buy your data back to try.
It is your data. Any vendor who makes that complicated has told you what kind of partner they intend to be.