Six months ago a thread appeared in r/sysadmin: "Anyone else suddenly getting asked about data sovereignty in monitoring?" Twenty-plus replies followed. The answers were consistent: yes, legal and compliance teams are asking, and most IT operations teams don't have a clean answer ready.
The question is a reasonable one. When your application goes down at 2am, the incident data — alert payloads, log excerpts, host metrics, service topology, failure signatures — flows through a chain of monitoring and incident management tools before it reaches an engineer. Each tool in that chain is a SaaS service. Each SaaS service processes your data on infrastructure you did not select, in jurisdictions you may not have reviewed, under data processing agreements you may not have read.
This post is a straightforward audit of where incident data goes in a typical enterprise monitoring stack — and what the implications are for IT operations teams operating under data residency requirements, cross-border data transfer rules, or basic security hygiene.
Where your incident data actually goes
A typical enterprise IT operations stack in 2026 includes some combination of an observability platform, an event correlation layer, and an incident management tool. Here is where the data flows in the most common configurations:
Datadog
All metrics, logs, traces, and events are processed on Datadog's US infrastructure (AWS us-east-1 by default). EU customers can opt into EU data residency, but this is not the default and requires a specific contract. Infrastructure telemetry — including host names, IP addresses, service topology, and error payloads — is stored on Datadog servers for the duration of your retention period.
Splunk (Cisco)
Splunk Cloud processes data on AWS infrastructure. Following Cisco's acquisition in 2024, data governance is now subject to Cisco's policies in addition to Splunk's. On-premises Splunk deployments keep data local, but on-premises customers are a shrinking segment as Cisco accelerates the push to cloud. Log data sent to Splunk Cloud includes the full raw text of your logs — error messages, stack traces, and any data that appears in your application output.
PagerDuty
Alert payloads, incident details, on-call assignments, and escalation history are processed on AWS infrastructure in the United States. PagerDuty offers an EU data residency option for enterprise customers, but the default deployment routes all data through US-based AWS regions. Every alert your monitoring tools fire — including the context they carry about which service failed, which host was affected, and what the error was — passes through PagerDuty's US infrastructure.
Dynatrace
Dynatrace is SaaS-only. All data — including OneAgent telemetry from every host it instruments — is processed in Dynatrace's cloud environment. Dynatrace offers multiple SaaS regions including EU. However, there is no on-premises or self-hosted deployment option; all infrastructure telemetry leaves your network by design.
BigPanda
SaaS-only. Alert events from all your monitoring sources are ingested into BigPanda's cloud platform for correlation and enrichment. This means that alerts from every monitoring tool in your stack — consolidated into a unified incident view — are processed on BigPanda's infrastructure.
The picture this creates is a chain: your infrastructure fires an alert → your observability platform processes it → your correlation layer enriches it → your incident management tool pages someone. At each step, data leaves your network and enters a third-party cloud environment. By the time an engineer is paged, your incident data has touched three to four external platforms.
Three scenarios where this is a real problem
For many organizations, data flowing through SaaS monitoring tools is an accepted operational reality with acceptable risk. For others, it is not. Here are three scenarios where it becomes a concrete compliance or security issue.
Regulated industries — financial services, healthcare, government
HIPAA, PCI-DSS, SOC 2, FedRAMP, and equivalent frameworks all have requirements around where sensitive data can be processed and by whom. If your application logs — which flow through your observability platform — contain PHI, cardholder data, or personally identifiable information, the SaaS tool processing those logs becomes a business associate, data processor, or sub-processor under the relevant framework. Most enterprise SaaS monitoring vendors can sign BAAs and DPAs, but the processing still happens on their infrastructure, which introduces audit complexity and vendor risk.
Cross-border data transfers — EU, Canada, Australia
GDPR Article 44 restricts transfers of personal data to countries outside the EU without adequate protections. The Schrems II ruling invalidated the Privacy Shield framework that many US SaaS vendors relied on. The EU-US Data Privacy Framework (2023) restored a transfer mechanism, but it remains subject to legal challenge and is not universally trusted by European DPAs. Canadian PIPEDA and Australia's Privacy Act impose similar requirements. Organizations operating in these jurisdictions and sending telemetry through US-based SaaS platforms need to have reviewed their transfer mechanisms — most have not done this audit for their monitoring stack specifically.
Security incidents — when your monitoring data is most sensitive
The moment a security incident occurs, your monitoring stack generates its most sensitive data: which systems were accessed, what error signatures appeared, which accounts were active, what network traffic patterns looked unusual. This is precisely when your incident data is most valuable to an attacker and most sensitive from a disclosure perspective. It is also the moment it is flowing through multiple third-party SaaS platforms in real time. Most security teams have reviewed data handling for their SIEM — fewer have reviewed it for their AIOps and incident management stack.
The monitoring stack data audit: what to check
If you have not done this audit, here is a practical starting point:
Questions to ask for each tool in your stack
- 01 Where is data processed? Which cloud provider, which region? Is EU or in-country processing available, and is it the default or an add-on?
- 02 What data leaves your network? Alert payloads only, or full log content? Host metadata? Service topology? Application error text?
- 03 Who has access to your data at the vendor? Is there a sub-processor list? Does vendor support staff have access to your incident data for troubleshooting?
- 04 What are the retention periods? How long does the vendor retain your incident and telemetry data? What happens on contract termination?
- 05 What is the data processing agreement? Is there a signed DPA? Does it cover all jurisdictions where your data originates?
- 06 What happens in a vendor breach? Is your incident data stored in a way that would expose your infrastructure topology if the vendor was breached?
Options for keeping telemetry local
The options for self-hosted or on-premises monitoring have historically meant accepting significant tradeoffs in capability, maintenance burden, or both. That gap is narrowing.
Grafana + Prometheus (self-hosted)
Mature, widely deployed, strong community. Covers metrics and visualization. Does not cover alert correlation, CMDB enrichment, or automated remediation. Requires significant operational investment to run at scale.
Splunk Enterprise (on-premises)
Full log analytics capability with data sovereignty. Expensive, requires dedicated Splunk expertise, and Cisco is actively pushing customers toward cloud. Viable for organizations with existing Splunk investment and the staff to operate it.
IBM Cloud Pak for AIOps (on-premises via OpenShift)
Enterprise-grade AIOps with a genuine on-premises option. Heavy infrastructure requirement (OpenShift), complex deployment, and enterprise pricing. The only major AIOps platform that can run fully local at enterprise scale.
Axiometica AIR (self-hosted, Docker Compose)
Self-hosted AIOps platform covering the full incident lifecycle — detection through ticket closure — with infrastructure telemetry that never leaves your network. Local LLM support via Ollama. Single VM deployment with Docker Compose. Free for internal use. Early stage — no enterprise support contracts yet.
The practical reality
For most organizations, the right answer is not to rip out their monitoring stack. SaaS tools are SaaS tools for good reasons — managed infrastructure, automatic updates, elastic scale, and ease of deployment. The practical path is usually a combination: SaaS tools for the monitoring layers where data sensitivity is lower, and local processing for the AI and incident management layer where sensitive failure signatures are correlated and acted on.
What matters is that the decision is explicit. Most IT operations teams did not choose to send their incident data to three external clouds — it happened by default as each tool was adopted. An audit that surfaces those data flows is a reasonable baseline expectation in 2026, regardless of whether the conclusion is to change anything.
If your requirement is that infrastructure telemetry stays inside your network — during detection, correlation, AI analysis, and remediation — Axiometica AIR is built for that use case.
Self-hosted. Local LLM support. Docker Compose. Free for internal use.