01
Metrics
Aggregates: CPU percentages, request counts, latencies. They describe how systems behave and rarely contain protected data, though their tags can leak more than intended.
Observability
Observability data residency in Saudi Arabia: where telemetry actually lands
The residency question stops more Saudi observability projects than any feature ever started. This guide works through what telemetry contains, the three deployment models and where each one puts your data, and how to design a split you can defend in an audit.
Technical guide Published 6 min read
01The gate
Why this question stops projects
Somewhere in every Saudi observability evaluation, someone from security or compliance asks the question the vendor deck skipped: where does this data physically go? If the answer is a shrug, the project stalls there, correctly. Telemetry is not abstract: metrics describe your infrastructure, traces describe your transactions, and logs, the worst offender, routinely contain user identifiers, internal hostnames, tokens someone forgot to redact, and fragments of exactly the data your classification rules exist to protect.
The mistake is treating residency as a blocker to argue with. It is a design input, and designed for early, it usually has a workable answer. Designed for after the agents are deployed, it has an expensive one.
02Know your data
The three kinds of telemetry are not equally sensitive
Residency conversations go better when they stop treating “telemetry” as one substance. This is why a single yes/no answer to “can we use a SaaS observability platform” is usually wrong: the defensible answer is a split, which classes of telemetry, treated how, may go where.
02
Traces
Individual transactions moving through services. They sit in the middle, because span attributes can carry identifiers.
03
Logs
The problem child: free text written by developers under deadline, which means anything can be in there, and eventually everything is.
03The architecture
The split, drawn
The design that makes a SaaS platform defensible in this market puts a control point you own between your systems and anything that leaves: everything is collected in-Kingdom, filtered and redacted in-Kingdom, and only the classes you decided may travel actually do.
-
Your systems
Applications, infrastructure, network, on-premise and cloud alike
-
Collection, inside the Kingdom
Agents and OpenTelemetry collectors, in your environment
-
The in-Kingdom control point
Filter, redact, sample and route, on infrastructure you own
-
Three destinations, by decision
Approved classes → SaaS region Sensitive logs → in-Kingdom store Some things → never leave -
One investigation experience
Engineers work in the platform; the sensitive tail stays home and is reachable when needed
The control point is the load-bearing element: an aggregation and processing layer running on your own infrastructure (vendor pipeline tooling or an OpenTelemetry collector tier), where filtering, redaction and routing happen before egress, and where the audit trail of what left, and what never did, is produced.
04The options
Three deployment models, and where each puts your data
| Model | Where telemetry lands | When it fits |
|---|---|---|
| Straight SaaS | Everything goes to the vendor’s region, chosen at account creation | Estates with no in-Kingdom obligation on any telemetry class. Simplest to run; the region choice still deserves deliberation, because it is sticky. |
| SaaS with an in-Kingdom control point | Approved classes reach the SaaS region after filtering and redaction; sensitive material stays on your infrastructure | The common Saudi enterprise answer: SaaS leverage for the team, a defensible boundary for the data, and an audit trail at the control point. |
| Self-hosted, in-Kingdom | Nothing leaves: the whole stack runs on infrastructure you control | Estates whose obligations rule out egress for the classes that matter. The honest price is ownership: someone operates that stack for years. |
05The vendor map
What the vendors actually offer here, as of August 2026
Facts a Saudi evaluation should hold, each verifiable against the vendor’s own documentation, and each worth re-checking, because region maps change without ceremony. As of August 2026: Datadog publishes nine operating regions, none of them in the Middle East, and no Saudi or Gulf sovereign construct; choosing a region happens once, at account creation. Grafana’s managed cloud documents a Saudi hosting region, a fact that lives in its documentation rather than its pricing page, with constraints worth reading closely. Several platforms, including Elastic and Grafana’s stack, can be self-hosted entirely in-Kingdom.
Two practical consequences. First, “is there a Saudi region?” is a question to ask every vendor in writing, dated, during procurement, not a fact to trust from any third-party page, including this one. Second, the absence of an in-Kingdom region is not automatically disqualifying: it is what makes the control point architecture above the load-bearing design, because it moves the decision about what leaves from the vendor’s map to your own configuration.
Regulated sectors
What regulated buyers should do with their frameworks
This guide does not restate what any framework requires
Saudi banks, government entities and critical-infrastructure operators evaluate observability under named frameworks: the National Cybersecurity Authority’s controls, SAMA’s cybersecurity framework for the financial sector, the telecom regulator’s requirements, and the Personal Data Protection Law. This guide deliberately does not restate what any of them requires, no article numbers, no retention durations, because summaries of controls, this one included, are exactly how wrong requirements propagate. Read the authority’s own text, with someone qualified to read it.
What can be said structurally: these frameworks tend to care about where data is stored and processed, who can access it, and whether monitoring itself is continuous and evidenced. Which means your observability architecture is not just subject to compliance; done properly, it is evidence for the monitoring controls. The design work is making both true at once, and it is exactly the work the control-point architecture exists to make demonstrable.
06Prove it
What you should be able to show an assessor
A residency design that lives in the architect’s head fails its first audit. The deliverable is the ability to demonstrate, on request:
- A written telemetry inventory: what is collected, from which systems, in which classes
- The routing decision per class: what leaves, what stays, and who approved it
- The redaction and filtering rules at the control point, under version control
- Where each destination physically is: the SaaS region by name, the in-Kingdom store by location
- Who can access each store, and how that access is itself logged
- Evidence the egress rules are enforced: the control point’s own logs and configuration
Facing this question on a live evaluation? Interkey runs a scoped classification-and-residency review: your telemetry, your obligations, and a written architecture recommendation, a topology, not an opinion.
07Buyer questions
What buyers ask us
Direct answers to the questions that come up in real evaluations. Anything missing, ask us at the bottom of the page.
Is there a Datadog region in Saudi Arabia?
As of August 2026, no: Datadog’s published region list has no Middle East entry. Verify against the current list during procurement. What that means in practice, and the architecture that deals with it, is the subject of this guide; the implementation page covers how the answer shapes a rollout.
Can we redact telemetry before it leaves the Kingdom?
Yes, and that is the point of the control-point architecture: filtering, redaction and sampling happen on infrastructure you own, before egress, under rules you version and can show an auditor. The practical work is deciding the rules per telemetry class and keeping them honest as systems change.
Is a self-hosted stack the only compliant option?
For some estates and some data classes, yes; for many, no. The answer depends on your classifications and your regulator, which is a determination for your compliance owner, not for any vendor or partner page. What engineering can do is give compliance a real choice: a designed split with an audit trail, rather than all-or-nothing.
What about logs specifically?
Treat them as the highest-risk class by default: free text accumulates sensitive material over time even when it started clean. The workable pattern is redaction at the control point, a short indexed set in the platform for live investigation, and the sensitive tail retained in-Kingdom, reachable when an incident or audit needs it. The log cost guide shows how the same split controls the bill.
From the insights library
Continue exploring observability
Buyer guide
Controlling Datadog log costs
The same control point that enforces residency is the lever that controls the bill: the cost half of this design.
ComparisonWhen Datadog is not the right platform
If residency rules out SaaS for your classes, this is the honest account of what that means for platform choice.
Implementation guideKubernetes monitoring in Saudi Arabia
Sovereign and on-premise clusters raise the same questions one layer down; here is the cluster-level answer.
Next step
Get a residency answer you can defend
If residency is the question holding your observability project, describe the regulator and the workloads involved — the architecture on this page is a conversation we have ready.
Or directly
+966-11-2180999 info@interkey.com.saTawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia
Elsewhere