Datadog · Security monitoring
Security monitoring in Saudi Arabia: logs, detections and response with Datadog
Security monitoring is continuous work with three parts: collecting your systems' logs in one place, running detection rules that raise a signal when a suspicious pattern appears, and a team that receives the signal and decides whether it is an incident. This guide explains, for IT and security managers in the Kingdom, what that means in practice, how it relates to the National Cybersecurity Authority's controls, who can handle the alerts, and where Datadog Cloud SIEM and Cloud Security fit beside a security operations centre (SOC), and where they do not.
Published 9 min read
Orientation
At a glance
The guide in one table, for the reader with five minutes.
- What it is
- Collecting security logs continuously, applying detection rules to them, and turning what matters into a case someone owns
- What it covers
- Identities, cloud accounts, network, hosts and containers, applications, and the platform itself
- How it relates to regulation
- The Essential Cybersecurity Controls (ECC) include a subdomain for cybersecurity event logs and monitoring management
- Datadog products
- Cloud SIEM for logs and detection rules, Cloud Security for configuration, identity risks and vulnerabilities, Workload Protection for hosts and containers
- Who handles the alerts
- Your SOC, a provider you appoint, or the operations team under an agreed procedure
- Where the data goes
- To your Datadog site; as of November 2026 Datadog lists no site in the Middle East
- What Interkey does
- Datadog licences, source onboarding, storage and masking design, rule tuning and technical support from Riyadh
In short, for managers
- Security monitoring is not a product you install and forget; it is logs, rules and people working together every day.
- A tool raises signals; people close them. Before buying any platform, decide who reads the alert at three in the morning.
- Security logs often contain personal data, so where they are stored is decided before the licence, not after.
- Start with a short list of sources that catch most early attack steps, then widen once they produce alerts someone acts on.
What continuous security monitoring means for a Saudi organisation
Most systems already write logs: the identity provider records sign-ins, the firewall records connections, the cloud account records configuration changes. The trouble is that the logs are scattered and read only after something has gone wrong. Continuous monitoring changes that in three steps:
- Logs: collected from the sources that matter into one place, with common fields and a known retention per class.
- Detections: rules that read the logs as they arrive and look for patterns, such as many failed sign-ins followed by a successful one from an unusual country, or administrator rights granted to a new account out of hours. Each match becomes a signal with a severity.
- Response: a named person reviews the signal, dismisses it or turns it into a case or an incident, and what was done is recorded.
Read more
Specialists also call this threat detection. The tool that collects the logs and applies the rules is usually called a SIEM; our guide to a SIEM solution on Datadog Cloud SIEM covers its parts. This guide stays with the wider picture.
Why security monitoring matters in the Kingdom: controls and data
The National Cybersecurity Authority (NCA) issues the Essential Cybersecurity Controls, currently in the ECC-2:2024 edition. One of their subdomains is titled "Cybersecurity Event Logs and Monitoring Management", and others, such as identity, vulnerability and incident management, need logs to show that they work. Which controls apply to you, and what they require, is set by the authority's current text. Our NCA ECC guide explains the evidence assessors usually expect.
Read more
The second point is data. Security logs carry user names and device addresses, and in some applications national ID and mobile numbers. The Personal Data Protection Law, overseen by SDAIA (the Saudi Data and AI Authority), makes where that data is kept a question to answer in writing. Datadog is a SaaS platform, and as of November 2026 its documented sites are in the US, Germany, Japan, Australia and the UK, none in the Middle East. So decide which log classes may leave your network, and mask or drop sensitive fields before sending. Our Datadog data residency guide sets out the options.
The third point is people. Many organisations in the Kingdom have a small security team for working hours, with an external provider or a parent group's SOC covering the rest. Good monitoring is designed around that reality.
Relatedthe Saudi Data and AI AuthorityDatadog data residency guide
The layers of security monitoring, and the Datadog product for each
Few organisations need every layer on day one. The last column follows Datadog's own product descriptions.
| Layer | The question it answers | Datadog product |
|---|---|---|
| Logs and detection rules | Do identity, network, cloud and server logs show a known attack pattern? | Cloud SIEM, built on Log Management, with out-of-the-box and custom detection rules |
| Cloud configuration | Is there a setting in our accounts that opens a door we did not intend? | Cloud Security: continuous configuration audits (Misconfigurations) |
| Identity risks and vulnerabilities | Who can do what, and which images and hosts carry known vulnerabilities? | Cloud Security: Identity Risks and Vulnerabilities |
| Hosts and containers | What processes, files and connections are active on this host or container right now? | Workload Protection |
| Applications and APIs | Is someone trying to exploit a vulnerability in the application's code? | App and API Protection |
| Sensitive data in telemetry | Do the logs carry data that should not be sent? | Sensitive Data Scanner |
| The platform itself | Who changed a rule, a dashboard or a permission inside Datadog? | Audit Trail |
Most organisations start with the first two layers. Our guide to cloud security monitoring with Datadog covers configuration, identity risks, vulnerabilities and Workload Protection in depth, and the Datadog Log Management page explains the log collection Cloud SIEM is built on.
Who handles the alerts: the options and their trade-offs
The first question is not which tool, but who reads the signal and when. One organisation may combine two of these.
| Option | Suits | Trade-off | What it needs from the platform |
|---|---|---|---|
| An in-house SOC | An organisation with a security team on shifts and written procedures | The cost of the team and its rota, in return for the most control | Signals with clear severities, cases, and links to the team's existing tools |
| A security monitoring provider you appoint | An organisation that does not want to build a round-the-clock team | A contract that defines what is escalated and when, and data shared with a third party | Scoped access for the provider, and export of signals to its tools |
| Operations team with periodic security review | A smaller organisation with a limited set of services | Less cover out of hours, so alerts must be few and precise | A small set of tuned rules, alerts to the on-call engineer, and a dashboard for the weekly review |
In all three, deciding what counts as an incident stays with the organisation and whoever it appoints. The platform gets the right signal to the right person, with the logs that explain it.
Before you choose a security monitoring platform
These decisions set the scope, cost and timeline more than any feature list:
- The first sources: usually sign-ins and privileged account changes, cloud audit logs, firewall and VPN, and the servers that hold sensitive data.
- An owner for each severity: which signals wake someone at night, and which wait for the morning.
- Log classes and where they live: what may leave your network, what is masked, and what stays in a system inside the Kingdom.
- Retention per class: as the text that applies to you sets it, not one number for everything.
- Your existing tools: the ticketing and chat tools your security team uses.
- An alert on silence: a source that stops sending looks like a quiet day, so monitor for missing logs too.
Where Datadog Cloud SIEM and Cloud Security fit next to a SOC, and where they do not
Datadog's documentation describes Cloud SIEM as detecting real-time threats to your applications and infrastructure, and Cloud Security as delivering real-time threat detection and continuous configuration audits across your cloud infrastructure. Both run on the platform that holds the operations team's metrics, logs and traces, so a signal links straight to the host or service it concerns.
When you already have a SOC
Read more
Your security team does not have to leave its tools. Datadog states that signal notifications can reach individuals and teams by email, Slack, Microsoft Teams, Jira, ServiceNow, webhooks and Case Management cases. The SOC receives what concerns it, with its severity, and its analysts can investigate the underlying logs. This suits estates in the cloud or on Kubernetes, where security wants to see what operations sees.
When it does not fit
- If every security log, without exception, must stay inside the Kingdom, a SaaS platform with no Middle East site does not fit that part, and it stays in a system inside.
- A team watching alerts around the clock is an organisational decision: your own SOC or a provider you appoint. The platform makes their work clearer.
- If the important systems do not write logs yet, switching logging on comes first, before any licence.
What drives the cost and the timeline
Cloud SIEM cost follows mainly the volume of logs analysed and how long they stay searchable; Cloud Security and Workload Protection follow the number of hosts and cloud resources in scope and the features switched on. So the first sources and the storage design per log class move the bill most. Interkey is an official Datadog partner in Saudi Arabia: it sells the licences, implements and supports them, and quotes licences together with set-up and technical support. Our Datadog page covers the products and implementation.
Read more
The timeline depends on the number of sources, how clean their log formats are, how many rules need tuning, and how quickly an owner is agreed for each signal. Connecting a source is configuration; agreeing who follows up is the real work, so any duration we give is an estimate made after scoping.
How Interkey helps
-
Set the scope.
The first sources, their owners, and who follows up on signals today: your team or your provider.
-
Agree the data.
Which log classes may be sent and the masking rules, signed off by your security team.
-
Quote the licences.
Datadog licences for the log volumes and resources in scope, with implementation and technical support.
-
Connect and store.
Content Packs, the Agent and integrations, and the right storage for each log class.
-
Tune and route.
Review which rules are on, tune the noisy ones, and route each severity to your SOC's tools.
-
Support after go-live.
Interkey supports the platform, its sources and its rules from Riyadh; assessing signals stays with your team or whoever you appoint.
Questions security and IT managers ask
Does Datadog map its rules to the NCA controls out of the box?
No. Datadog's documentation names frameworks such as PCI and SOC 2 among its built-in ones and does not list NCA controls. So your compliance team and Interkey agree, control by control, which rule, log or report provides the evidence, and where the platform does not help.
Can Datadog signals reach the SOC we already work with?
Yes. Datadog states that signal notifications can go by email, Slack, Microsoft Teams, Jira, ServiceNow, webhooks and Case Management cases. We route each severity to the tool your SOC uses and give its analysts access to search the underlying logs.
Who assesses the security signals once Datadog is running?
Your security team, a monitoring provider you appoint, or the operations team under an agreed procedure. Interkey looks after the platform: licences, sources, storage, rule tuning and technical support from Riyadh, so whoever assesses the signals receives clear ones.
How is Datadog security monitoring licensed, and what pushes the cost up?
Cloud SIEM cost follows the volume of logs analysed and how long they stay searchable; Cloud Security and Workload Protection follow the hosts and resources in scope. Sending every log from day one pushes it up most. Interkey sells the licences in Saudi Arabia and quotes them with set-up and support.
Which of our security logs can we keep inside the Kingdom?
The ones you choose. Logs you send are processed on your Datadog site, and as of November 2026 none is in the Middle East. What must stay is masked or dropped inside your network before sending, or kept in a system inside, and the decision is recorded with your security team.
When does security monitoring start producing alerts the team can act on?
There is no fixed figure. It depends on the number of sources, the quality of their logs, how many rules are noisy and how quickly owners are agreed. A short list of sources and early rule tuning shorten it; we estimate after scoping.
Next
Read next
Next step
Plan your security monitoring scope
Tell us which systems should be monitored first, who handles alerts today, and which logs must stay in the Kingdom. We will suggest a first scope and quote licences, set-up and support together.
Or directly
+966-11-2180999 [email protected]Tawuniya Towers, North Tower, 7th Floor, King Fahad Highway, Olaya, P.O. Box 56835, Riyadh 11564, Saudi Arabia