Contents
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.
An observation from the field
A security specialist with many years as a database administrator put it this way: a monitoring product is not especially interested in what the command actually is. It is built around who did what and when. Reading the content of a statement to weigh its risk is not part of its remit.
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 irreversible table truncation appears, the operation is not forbidden; the risk band rises, a policy can attach extra approval to that band, a rollback plan is required if the server demands one, automatic execution is switched off if a never skip rule fired, and the decision is recorded with its reasoning. An unqualified UPDATE or DELETE is one of the rules that block saving in the default installation; the organisation can relax this. 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:
| Layer | When | The question it answers |
|---|---|---|
| Governance layer | Before execution | Should this happen, under which rule, with whose approval, and what is the rollback plan |
| Activity monitoring | At execution time | What actually ran, from which session, at which second |
| Log and event platform | After execution | What this event means alongside the others, and how long it is retained |
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.
An honest boundary
SQL Change Guard is not a network level barrier. If someone connects to a production server directly with a client tool, the product cannot physically stop them. Any story claiming otherwise would mislead. What closes the gap is a combination of three things: removing personal production accounts, cross checking against the monitor, and a corporate standard saying that a change made outside this channel does not count as having been made.
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.
See the two layers side by side
We will show how a pre execution decision lands on the record and cross checks against your monitor, using your own scenario.
Book a Demo →Frequently Asked Questions
What is the difference between database activity monitoring and database governance?
A monitoring tool engages at and after execution; it records which session, using which account, ran what and in which second. A governance layer engages before execution; it records the rule the decision was made against, who approved it and what the rollback plan is. Monitoring writes the event that happened, governance writes who decided it should happen. They are different layers rather than alternatives.
We already have a product like Guardium. Why would we need a governance layer?
A monitoring tool inherently cannot see three things: whether an operation was authorised (the authorisation decision is not carried in the traffic), that the text that ran matches the approved text (it never saw the approved text), and the justification and delivery details of requests to read production data (who received it, which columns were masked, how long it will be kept). An auditor asks for all three. A governance layer produces them and does not replace the monitoring tool.
Our monitoring tool has a blocking mode. Is that not enough?
Blocking mode also stops work an authorised administrator does deliberately: a planned bulk update, maintenance that looks unconditional but is correct, a recovery intervention. So many organisations deliberately turn blocking off and settle for alerts. The result is that the highest risk operations are exactly the ones where blocking is off. Rather than always forbidding the operation, a governance layer can ask for additional approval by risk, disables automatic execution when a never skip rule fires, and records the decision with its justification.
Why do privileged account alerts from a monitoring tool decrease?
The legitimate work privileged accounts do triggers rules all day and an alert pile builds up; after a while nobody looks, the rule is relaxed, or the account is added to an exception list. In a setup where the decision is made in advance, a privileged account's work is already tied to a request, an approval and a rule. Expected behaviour becomes defined, and the meaningful alert becomes what is unexpected.
Does a governance layer stop someone connecting directly with SSMS?
No. The product is not a barrier at the network layer and a narrative claiming otherwise would be misleading. The gap is closed by a combination of three things: removing personal production accounts and holding credentials in a vault, cross verification with the monitoring tool (a change with no governance trace is an exception), and an organisational standard under which a change made outside this channel counts as not made.