Database activity monitoring (DAM) is often bought to pass an audit finding and then left producing reports nobody reads, while the privileged accounts and application service accounts that matter most go unwatched. DAM products record who ran which statement against which object, alert on risky activity and, in some designs, block it. They differ sharply in how they collect events (host agents, network inspection or the database's own native audit trail), which engines and cloud services they cover, and whether a database administrator can switch them off. This vendor-neutral buyer's guide is for security, database and audit teams choosing a DAM platform for PCI DSS, SOX and threat detection. For how to configure native audit logging and build detections yourself, read the Database Audit Log Detection Guide; for discovering where sensitive data sits and how it is exposed, see the DSPM Buyer's Guide, which covers posture rather than activity.
Key takeaways
- Decide first whether native audit is enough. Modern engines and cloud services produce detailed audit trails; a DAM platform earns its cost through separation of duties, cross-engine correlation, analytics and reporting, not raw collection.
- Collection method drives everything else. Host agents see local and encrypted sessions, network sensors miss them, and native audit depends on settings a privileged user may be able to change.
- Separation of duties is the core requirement. The people being watched, database administrators and powerful service accounts, must not be able to alter policy or delete records.
- Blocking is a high-risk feature. Inline blocking or session termination can break production; most organisations alert first and block only narrow, well-tested rules.
- Test on your busiest database. Latency, event loss under load and storage growth are where products fail, and datasheets rarely show them.
Define requirements
- Database estate: list every engine and version (commercial and open source relational engines, document stores and others), every managed cloud service, and where each runs. Note which hold cardholder data, financial reporting data or personal data.
- Compliance drivers: PCI DSS Requirement 10 expects logging of individual access to cardholder data and all actions by administrative accounts, protection of logs from modification, automated log review and retention of at least 12 months with three months immediately available. SOX IT general control testing typically examines privileged access and changes to financial databases. Write down the exact report each auditor asks for.
- Who you are monitoring: database administrators, application service accounts, batch and ETL identities, developers with production access, and third-party support staff. Each needs its own baseline.
- Threat use cases: bulk reads of sensitive tables, access outside business hours, privilege grants, audit policy changes, schema changes outside change windows, and service account credentials used from a new host or tool.
- Response expectations: alert only, terminate session, block statement, or quarantine a user. Agree who approves each.
- Operating model: who tunes policies, who reads alerts (SOC or database team), and what volume of events you can afford to store.
Capability areas
| Approach | How it works | Strengths | Limits |
|---|---|---|---|
| Host agent | Software on the database server captures activity from memory or the engine interface | Sees local connections, encrypted sessions and DBA activity on the host | Install and patch burden; performance overhead; not possible on most managed cloud services |
| Network sensor | Inspects database protocol traffic from a span port or inline appliance | No database change; inline mode can block | Blind to local and encrypted traffic unless keys are shared; inline failure can stop service |
| Native audit ingestion | Collects the engine's own trail: built-in audit features, audit extensions, cloud audit streams | Works on managed services; low footprint; vendor-supported | Quality depends on audit settings; privileged users may change them unless locked |
| Cloud activity stream | Provider pushes encrypted events to a stream the DAM consumes, such as a managed database activity stream delivered through the provider's streaming service | Separates collection from the DBA; near real time | Engine and edition limits; events may be lost during background errors in asynchronous modes |
Beyond collection, compare these functions:
- Policy and filtering: rules by user, object, statement type, client application and source host, so you can capture all privileged activity but only sensitive-object reads for the application.
- Data classification: discovery of sensitive columns so policies follow the data, not hand-maintained table lists.
- Behaviour analytics: baselines per identity that flag unusual row counts, new objects or new client tools.
- Tamper resistance: policy locked against DBA change, events signed or written to storage the DBA cannot reach, and alerts when collection stops.
- Prevention: session termination, statement blocking, or virtual patching, each with a simulation mode.
- Compliance reporting: scheduled reports mapped to PCI DSS, SOX and privacy requirements, with sign-off workflows that record who reviewed what.
- Integration: SIEM and data lake export in documented formats, SOAR and ticketing, identity provider and PAM context for user attribution.
Evaluation criteria
| Criterion | What good looks like | How to test it | Suggested weight |
|---|---|---|---|
| Coverage | Every in-scope engine and cloud service supported natively, with version list | Map vendor support matrix to your inventory line by line | [20%] |
| Separation of duties | DBAs cannot disable collection, alter policy or delete events; collection failure raises an alert | As a DBA, try to stop the agent or change audit settings | [20%] |
| Performance and fidelity | Measured latency overhead within your tolerance; no silent event loss | Replay peak load with and without monitoring | [15%] |
| Detection quality | Useful alerts on bulk reads, privilege changes and service account misuse with few false positives | Run the PoC scenarios below | [15%] |
| User attribution | Activity through shared application accounts or connection pools tied back to an end user where possible | Trace one application request to the user | [10%] |
| Reporting and evidence | Auditor-ready reports with review sign-off and retention controls | Ask your auditor to review sample output | [10%] |
| Cost and operations | Clear licence metric (per database, per core, per event volume) and storage cost model | Model three-year cost including log storage growth | [10%] |
Weights are illustrative: set them before responses arrive.
Decision guidance: an organisation with a few databases on one cloud provider may meet its needs with native audit streamed into an existing SIEM, provided audit settings are locked and storage is out of DBA reach. A dedicated DAM platform makes sense when the estate spans several engines, when auditors require evidence that administrators cannot tamper with monitoring, or when you need analytics and blocking. Large regulated estates usually combine agents on self-managed databases with native stream ingestion for managed services.
Questions to ask vendors
- Which engines, versions and managed cloud services do you support natively, and which only through logs we forward?
- How do you capture local connections and TLS-encrypted sessions?
- Can a database administrator with operating system or sysadmin rights stop collection or change policy? What happens when they try?
- What is the measured latency overhead at our peak transaction rate, and what happens to events when your collector is unavailable?
- How do you attribute activity through connection pools and shared application accounts to an end user?
- How do you baseline service accounts, and how do you alert when one is used from a new host or client tool?
- What blocking options exist, how do you simulate a rule before enforcing it, and how does inline mode fail?
- Where are events stored, how are they protected from modification, and how long can we retain them at what cost?
- Which credentials does your agent or collector need on our databases, and how are they stored and rotated?
Red flags
- Monitoring that a DBA can disable from the same console or host it monitors, with no alert.
- Support lists that say "planned" for a cloud service you already run.
- No figures for performance overhead, or figures only from a lab with no concurrent load.
- Compliance reports that are lists of raw events with no review workflow.
- A collector that needs a highly privileged database account with a static password and no rotation path.
- Blocking sold as the default mode with no simulation step.
Proof of concept
- Choose two production-like databases on different engines, including one managed cloud service, and connect them with the collection method you would use in production.
- Load representative traffic at peak rate and measure latency, CPU and event completeness against the engine's own trail.
- Run safe test scenarios: a bulk export of a sensitive table by an application account, a DBA granting themselves access to a restricted schema, a schema change outside the change window, a service account login from a new host, and a DBA attempting to disable auditing.
- Record time to alert, alert quality and the context provided for each scenario.
- Test one blocking or termination rule in simulation, then on a test database, and confirm rollback.
- Generate the PCI DSS and SOX reports your auditors expect and have them review the output.
- Measure storage growth over the PoC and project a year of retention.
The collector's own credentials are non-human identities with wide read access: vault them, scope them and rotate them. See the Database Credential and Access Security Guide.
How NHI Mgmt Group can help
We provide independent requirements, RFP and evaluation support. Browse vendors in our products directory or contact us.
Related NHI Mgmt Group resources: Database Audit Log Detection Guide · Database Security Guide · DSPM Buyer's Guide · Data Security Platform Buyer's Guide