Observability is usually framed as an engineering and cost problem. It is also a security and compliance problem, and a serious one. The moment your logs, metrics, and traces leave your environment for a third-party SaaS, you have exported some of your most sensitive data to someone else’s cloud. This post looks at telemetry security and compliance risk: what is actually in your telemetry, why sending it to an external vendor is a liability, and how a bring-your-own-cloud model removes the risk.
Your telemetry contains more than you think
Logs and traces are written by hundreds of developers across years of code, and they capture whatever happened to be in scope at the time. In practice that means telemetry routinely contains:
- Personally identifiable information (PII): emails, names, IPs, user and device identifiers.
- Protected health information (PHI) in healthcare systems, and cardholder data in payment systems.
- Secrets and tokens: session identifiers, API keys, and auth headers that slipped into a debug line.
- Internal topology: hostnames, service maps, and query parameters that describe how your systems work.
You can redact aggressively and still not catch everything, because the whole point of a log line is that a developer wrote it to capture context. Telemetry is, functionally, a sensitive-data firehose.
Why third-party telemetry is a compliance liability
Once that firehose is pointed at an external observability or SIEM vendor, several compliance and security problems follow:
- Expanded breach surface. Frameworks like SOC 2, ISO 27001, HIPAA, and PCI DSS all care about where regulated data lives and who can touch it. A copy of your logs in a vendor’s platform is now in scope for every one of them, and the vendor’s breach becomes your reportable incident.
- Data residency and sovereignty. If regulation requires data to remain in a jurisdiction or under your control, exporting telemetry to a vendor’s region can violate it outright.
- Access you cannot fully attest. Proving who can read your logs is difficult when the authoritative copy sits in a third-party system with its own staff, subprocessors, and support tooling.
- Retention you do not control. Regulated audit trails often require specific, tamper-evident retention. That is far harder to guarantee when the data lives somewhere you do not administer.
The cheapest way to reduce the compliance scope of your telemetry is to stop copying it somewhere you do not control.
Keep security analytics where the data already lives
The instinct to ship logs to an external SIEM comes from a real need: you have to run detections, correlation, and investigations across everything. But that need does not require the data to leave. Sasquatch Labs runs the security layer, Yeti, inside your own cloud, on the same losslessly compressed telemetry your observability teams use. Detections, correlation, and threat analytics execute in place, so your security operations never depend on exporting logs to a third-party analytics platform.
Investigations work the same way. Our agentic AI layer, Signal, and the Snowman query engine run against your in-cloud storage, so an analyst can ask a natural-language question or run an SPL, LogQL, or KQL query without a single byte being sent to us. Full-fidelity data, complete audit trail, nothing exported.
Bring your own cloud: the security default
The architectural answer to telemetry security risk is bring your own cloud. When collection, compression, storage, query, and SIEM all run inside your environment, the sensitive-data firehose never crosses your perimeter. Compliance scope shrinks because there is no external copy to account for. Data residency is satisfied by construction. And because nothing egresses, you remove a recurring cost at the same time you remove the risk. We cover that model in BYOC observability and data sovereignty.
Treat telemetry like the sensitive data it is
If you would not casually copy your production database to a third-party cloud, you should think twice about doing it with your logs, because they often contain the same regulated data. Keep telemetry in your own cloud, run observability and the Yeti SIEM on it in place, and let nothing leave. See how it works at sasquatchlabs.io, or read about the cost side of the same decision.