Data platform · Database security

Database activity monitoring: who read or changed sensitive data, and how to know

Database activity monitoring (DAM) records who connected to a database, what they read or changed, and when, and raises an alert when that activity breaks a rule. Organisations in Saudi Arabia usually meet the question during an audit, or after an incident, when nobody can say which account read a table of customer data. This guide explains what DAM is, the options from native database audit to a dedicated tool, and what Datadog and Redgate monitoring cover and what they do not.

Published November 11, 2026 10 min read

Talk to our database monitoring team Compare the options

Orientation

At a glance

The whole page in one table, before the detail.

What it is: A record of who did what in a database, kept and checked against rules, with alerts on what breaks them
What it answers: Which account read or changed sensitive data, from where, and whether that was expected
The options: Native database audit, a SIEM reading audit logs, performance monitoring, or a dedicated DAM tool
Saudi angle: Evidence for NCA controls and the PDPL; audit records hold personal data themselves
Where Datadog and Redgate fit: Query visibility, detection rules over collected audit logs, estate and access-rights views
Where they do not: They are not a dedicated DAM tool: no complete, independent capture of every statement and no blocking

The problem in plain words

The usual question: an auditor asks who read the customer table last quarter, or who changed a salary, and the answer is not on file.
What database activity monitoring does: records logins, reads, changes and permission changes, keeps the record, and alerts when activity breaks a rule.
What it is not: performance monitoring. A tool that finds slow queries samples activity; an audit control must keep all of the activity it is asked to keep.
The decision: many estates start with the database's own audit and a SIEM. Some requirements need a dedicated DAM tool, and it is better to know which before an audit.

What database activity monitoring is, and what it records

Database activity monitoring watches the statements and sessions that reach a database and keeps a record of them: which account logged in, from which host and application, which tables it read, which rows it changed, and which permissions or schema objects it altered. The record is then checked against rules, such as a support account reading a whole table of national ID numbers at night, or a new login being granted administrative rights, and the rules raise alerts.

Three properties separate DAM from ordinary logging. First, completeness: the activity in scope is kept, not sampled. Second, independence: the record is protected from the people it records, so a database administrator cannot switch it off or edit it unseen. Third, privileged users are covered: the riskiest sessions are often local or administrative, and they are the ones a weak setup misses. A database audit trail that lacks any of these can still be useful, but it will not answer every question an auditor asks.

Database activity monitoring tools and options compared

Four ways organisations answer the question, from what the database already has to a dedicated tool.

Database activity monitoring options compared by what they record, independence from administrators, alerting and limits
Option	What it records	Independent of DBAs?	Alerts and response	Main limit
Native database audit	The events you configure: logins, reads or changes on chosen objects, permission changes	Partly; administrators of the server can usually change the audit settings	None on its own; the log must be read by something	Overhead and storage grow with scope; each engine works differently
SIEM over audit logs	Whatever the native audit writes, collected centrally	Better; the copy leaves the database server quickly	Detection rules raise signals for analysts	Sees only what the native audit captured
Database performance monitoring	Query metrics, samples of executions, plans, waits, blocking	Not designed for it	Performance alerts, not access policy	Samples activity; not a complete audit record
Dedicated DAM tool	Statements and sessions captured by its own agents or network sensors, including privileged sessions	Designed for it, with separation of duties	Policy alerts, and in some tools blocking of a session	Licence, sensors on every server, and policy work to keep it useful

The options combine. A common shape is native audit on the sensitive objects, its logs sent at once to a SIEM that the database team cannot edit, and performance monitoring beside it for the operations side. A dedicated tool is added where a requirement goes beyond what that shape can show.

Why database audit matters in Saudi Arabia

Two authorities shape the question for most organisations in the Kingdom. The National Cybersecurity Authority (NCA) publishes cybersecurity controls that many entities must meet, and event logging and monitoring of systems that hold sensitive data are part of that picture; our overview of the NCA Essential Cybersecurity Controls gives the general shape. Personal data falls under the Personal Data Protection Law, overseen by the Saudi Data and Artificial Intelligence Authority (SDAIA). Which controls apply to you, and what evidence they require, is for your compliance owner to confirm from the authorities' own texts.

Two practical points follow. Audit records are themselves sensitive: they name people and accounts, and a captured statement can carry the national ID or mobile number it searched for. So decide where the records live before you collect them; Datadog, for example, is SaaS, and as of November 2026 its documented sites are outside the Middle East, which our Datadog data residency guide covers. And monitoring sits beside other controls, not in place of them: limiting who sees values in the first place is the job of access control and dynamic data masking.

Database audit built into the engines

Names as each vendor documents them. Features vary by version and edition, so confirm yours.

Native database audit options by engine, with what to check before relying on each
Engine	Native audit	Check before relying on it
SQL Server and Azure SQL	SQL Server Audit: server and database audit specifications written to a file or an event log	Who holds the rights to alter or stop an audit, and whether the target is collected off the server
PostgreSQL	Logging settings in the core database, and the pgAudit extension for session and object audit	Whether managed hosting offers the extension, and the log volume a broad setting creates
Oracle	The database's own auditing, configured by policy	Edition and licence terms, and where the audit records are stored
MySQL	An audit plugin, depending on edition and distribution	Which plugin your build has, and its output format for collection

Whatever the engine, write the audit scope per object: which tables hold sensitive data by your classification, which actions on them matter (read, change, export, permission change), and which accounts are expected. Auditing everything usually produces a log nobody reads and a storage bill; auditing too little leaves the question open.

Database security monitoring with Datadog: what it covers and what it does not

Interkey is an official Datadog partner in Saudi Arabia; it sells licences, implements and supports. Three Datadog products touch this subject, and each does a different job. Datadog Database Monitoring reads query metrics, samples of individual executions and explain plans; a sample shows the user, application or client host behind a query, which helps when you investigate a slowdown or an unusual load. Datadog Cloud SIEM applies detection rules, out-of-the-box or custom, to the logs collected by the Datadog Agent and integrations; if a database's native audit log is collected as a log source, rules can raise signals on it, such as a burst of failed logins or a grant of administrative rights. Datadog Audit Trail records who uses Datadog itself and what they do, which matters for the integrity of the monitoring, but it does not record activity inside your databases.

What this does not give you: Database Monitoring samples executions for performance work and is not built to keep a complete record of every statement; Cloud SIEM sees only what the native audit writes; and none of the three blocks a session or captures a privileged local session independently of the database. That is the job of a dedicated DAM tool. For many estates, native audit plus Cloud SIEM answers the questions auditors ask; where it does not, we will say so during scoping.

Where Redgate Monitor fits for SQL Server estates

Redgate Monitor is built for DBAs who look after a SQL Server estate, and Redgate also lists PostgreSQL among the platforms it monitors. Alongside query, wait, blocking and deadlock views, it collects configurations, access rights, installed versions and backups, which answers part of an audit: who has rights on which server, and what changed. Redgate describes its Enterprise edition as adding security monitoring and auditing and a sensitive action log. Like Datadog, it is a monitoring tool and not a dedicated DAM tool, so we check the edition's documented features against your requirement before you buy.

When you need a dedicated DAM tool instead

Monitoring and native audit go a long way. These requirements usually go further.

Signs a dedicated tool is the right answer

Every privileged statement, captured independently. Your auditor requires a record of all administrator activity that the administrators themselves cannot influence.
Blocking, not only alerting. A session that breaks a policy must be stopped while it runs, not reported the next morning.
Many engines under one policy. The estate mixes engines whose native audit cannot be brought to one standard.
Overhead the server cannot carry. Native audit at the required scope slows the database more than the business accepts.

A dedicated DAM product is not something Interkey sells. If you need one, choose it with your security team; its alerts can still reach the SIEM your analysts use, through the Datadog Agent or the HTTP API.

Which control fits: a checklist by requirement

Start from the question you must answer, not from the tool.

Matching database audit and monitoring requirements to the control that fits
Requirement	Control that fits	Why
Show who logged in, and failed to, on sensitive databases	Native audit sent to a SIEM	Login events are standard audit output, and a SIEM keeps them away from the server
Alert on a grant of administrative rights	Native audit plus a detection rule	Permission changes are auditable events; a rule turns them into a signal
Find the account behind an unusual load on a database	Database performance monitoring	Query samples name the user, application or client host
Review who holds rights across a SQL Server estate	Redgate Monitor estate views	Access rights and configurations are collected per server
Record every statement by administrators, beyond their control	Dedicated DAM tool	Needs capture and separation of duties outside the database
Stop a policy-breaking session as it runs	Dedicated DAM tool with blocking	Monitoring and SIEM tools alert; they do not block a database session

How Interkey helps

Interkey starts from the questions you must answer and the databases in scope: engines and versions, which objects hold sensitive data, and who reads them. From there we design the native audit scope per engine, collect the audit logs into Datadog Cloud SIEM with rules your analysts can act on, set up Database Monitoring or Redgate Monitor for the operations side, and agree with your security team where the records live and who may read them. Where a requirement calls for a dedicated DAM tool, we tell you plainly and leave room for it. Support comes from Riyadh, in Arabic and English. Licences are quoted at the vendors' terms alongside Interkey's work.

Questions buyers ask about database activity monitoring

What is the difference between database activity monitoring and database performance monitoring?

Performance monitoring samples queries to find what is slow and why. Database activity monitoring keeps a complete record of the activity in scope, who did what and when, protects it from the people it records, and alerts on access that breaks a rule.

Is the native audit in SQL Server or PostgreSQL enough for an audit in Saudi Arabia?

Often it is a large part of the answer, especially when its logs leave the server at once for a SIEM the database team cannot edit. Whether it is enough depends on what your auditor asks for; your compliance owner confirms the requirement from the NCA's and SDAIA's own texts.

Does Datadog Database Monitoring record every query for audit?

No. It samples executions for performance work, and a sample names the user, application or client host. For an audit record, collect the database's native audit log, which Datadog Cloud SIEM can read with detection rules.

Where are database audit records stored if we send them to Datadog?

On your Datadog site. As of November 2026 Datadog's documented sites are outside the Middle East, so agree with your security team which records may leave your network, and mask or drop the rest before they are sent.

When do we need a dedicated DAM tool rather than native audit and a SIEM?

When every privileged statement must be captured beyond the administrators' control, when sessions must be blocked as they run, or when many engines need one policy. Interkey does not sell a DAM product and will say when you need one.

How long does a database audit and monitoring project take, and how is it priced?

Both are estimated per project, from the number of databases and engines, the objects in audit scope, the log volume and how far rules are tuned. Interkey quotes its work per scope; Datadog and Redgate licences are quoted at each vendor's terms.

Next step

Find out what your database audit can prove

Tell us the databases that hold sensitive data, the engines and versions, and what an auditor or your security team has asked you to show. We reply with what native audit and monitoring can cover, where a dedicated tool is needed, and a first scope.

First name Last name

Company Email Company

Phone number (optional) What are you working on? (optional)

Required field

By sending this form, you agree to our Privacy Notice.

Published by Interkey. Last updated 2026-11-11. Interkey is registered in Riyadh, Saudi Arabia under commercial registration 1010156897.