Database Activity Monitoring Is Not Governance

Database activity monitoring tools are mature products. They see the traffic, they let you write rules, they raise alerts and they hand you a serious pile of records at audit time. This article does not claim they fall short. The point is simpler: monitoring and governance do not answer the same question. One writes down what happened, the other records who decided it should.

"We Have Guardium, Why Would We Need You"

We hear this often and it is a reasonable thing to say. The organisation paid real money for a monitoring tool, deployed it, wrote the rules and passed an audit with it. Asking why another layer is needed is the right reflex.

The answer comes down to one distinction. A monitoring tool engages at execution time and afterwards. A governance layer engages before execution. The difference is the difference between a camera and a turnstile. The camera records what happened, and that has value. The turnstile decides who gets in. Needing both does not mean either one is inadequate.

What a Monitoring Tool Actually Does

A database activity monitor captures the traffic reaching the database and records or alerts on it according to rules you write. What it captures is typically this: which session, which account, which source address, which second, which statement. That information is accurate, and no other source gives it to you as reliably.

What a monitoring tool inherently does not know is the decision itself. Rules are written against traffic. Whether a statement was permitted is not carried inside the traffic; that fact lives in another system, usually a ticket or an email thread.

Three Things Monitoring Cannot See

1. The permission decision and the rule behind it

A monitoring tool says "this update ran". It cannot say "the approval this update required had been obtained, and that approval rested on this rule", because the approval never reaches it. The auditor wants the second sentence. The first alone does not close a finding.

2. That the text which ran was the text that was approved

One script sits in the ticket and a different one runs. The gap is rarely bad faith; it is an ordinary correction, a column name added or a condition changed. The monitor sees the text that ran but has never seen the text that was approved, so it cannot compare them. That comparison can only happen where both texts live on the same record.

3. The reason and the delivery on the read side

The monitor sees that a query ran. What it does not see is this: why it ran, how many rows came back, which columns were masked, who received the file, whether that recipient address was approved and how long the file will be kept. These are exactly the questions asked in a personal data audit, and none of them travel in the traffic.

The Rule Paradox: Why Prevention Gets Turned Off

Many monitoring products have a prevention mode. When an unqualified update arrives, they can stop it. In theory this solves the problem at the root. In practice a good share of organisations deliberately switch prevention off, and their reasons are sound.

The reason is this: prevention also stops work that an authorised, experienced administrator is doing on purpose. A planned update over millions of rows, a maintenance job that looks unqualified but is entirely correct, a recovery action. Blocking those locks up operations. So the organisation does the reasonable thing: it turns prevention off, leaves alerting on, and names "an experienced person plus logging" as the compensating control.

Here is the paradox: the highest risk operations are precisely the ones where prevention is switched off. And the compensating control depends on a person. This is not bad design; it is a boundary that comes from the nature of monitoring. A monitor cannot know the intent behind a statement, so it either stops all of them or none.

A governance layer resolves the dilemma from a different angle. The aim is not to block the operation but to raise the barrier in proportion to the risk. When an unqualified update or an irreversible table truncation appears, the operation is not forbidden; an extra approval is required, automatic execution is switched off, a rollback plan is asked for, and the decision is recorded with its reasoning. The experienced administrator carries on working, only now the work is on the record.

Privileged Account Noise

The best known pain in a monitoring deployment is the alert pile produced by privileged accounts. A database administrator does work all day that trips the rules. All of it is legitimate, all of it raises alerts, and after a while nobody reads the alerts. The organisation either loosens the rule or adds the account to an exception list. Both narrow the scope.

Where the decision is made in advance, that noise naturally drops. The work a privileged account does is already tied to a request, an approval and a rule. Expected behaviour is now defined for the monitor, and the meaningful alert becomes the unexpected one.

How the Two Work Together

The right arrangement is not a contest between the two but a stack. Three layers verify each other:

The most valuable output of this arrangement is the cross check between two layers. If corporate standard says every path into a production database goes through the governance channel, then a change with no trace in that channel but a clear trace in the monitor is an exception by definition. Neither layer can say that alone; put them side by side and the answer falls out. The same logic lowers the correlation tax: a person no longer has to rebuild the match every time.

Measure Your Own Setup

Measure the scope of your decisions rather than the scope of your monitor. Five questions:

• What share of last month's alerts came from privileged accounts, and how many were actually reviewed?
• For which rules is prevention on, and for which is it deliberately off?
• How many minutes and how many systems does it take to say "this operation was approved" about one alert?
• Where do the stated reason and the delivery address of production data requests live?
• Does your corporate standard say "no change outside the governance channel", or is that just a habit?

If the answer to the third question is measured in minutes, the two layers are already connected. If it is measured in hours, a person is rebuilding that connection every single time.