To the DBA Who Says "We Do Not Want Prevention": Is Control a Burden or an Alibi?

This article is written to a DBA: the person who knows the work best and has the most justified doubts about products like this. Your doubt is legitimate. You have heard "yet another approval layer" many times. Often it slowed your work, got in the way of an urgent job at 02:00 and ended in a form nobody looks at. This article argues that a governance layer, set up correctly, is not the DBA's enemy but their insurance.

First, the Objection Stated Honestly

• "We do not want prevention. We know what we are doing."
• "This is a burden. Turning every job into a request is a waste of time."
• "Nobody has access to prod anyway, we have control."
• "Our database monitoring tool already produces alerts."

There is some truth in all of these objections. And they miss something.

A Block and Evidence Are Different Things

"We do not want prevention" is a correct answer to a blocking product. In work done under a DBA's control, a tool cutting the job off halfway is often more harmful than the job not being cut. But a governance layer does not have to be a blocking tool. What matters is the second question: what happens when something goes wrong?

When something goes wrong the same question is always asked: who did it, who allowed it, which command was run? A good DBA has an answer because they remember. But remembering is not evidence. And at exactly this point, in a system without records, the person who suffers most is the DBA: the person with the most access is the easiest to blame.

The Alibi: When Evidence Protects the DBA

Let us run a thought experiment. At 08:30 a customer complaint arrives: after last night's operation some records are corrupted.

• In a world without records: "Who ran it last night?" The DBA. "Who approved it?" Verbally, their manager. "Which command?" The DBA remembers. Result: an argument and the DBA's word.
• In a world with records: the request was opened at 14:12 with a written reason; risk band Medium, two people approved; the digest of the text that ran matches the approved text; the rollback plan was ready; 2,340 rows were affected. The corrupted records did not come from this job.

This is a thought experiment, not a real record. But the conclusion is real: evidence is the only thing that protects the DBA after an incident. In a code hosting service's 2017 incident an engineer ran a command on the wrong server. The company's post incident report did not name the engineer; its approach was to focus on "which door was missing" instead of "whose fault". A healthy culture does that. But that culture cannot be built without records.

The "Burden" Objection: Where It Is Most Fair

Delay is a real cost. Defending a governance product without accepting that is not honest. Two things determine the burden:

1. Is every job controlled with the same weight? It is not control that slows things down but applying the same depth of control to every change. With an approval policy the depth can be set by band: a single approval can be defined for a low band and more people can be required for a high band. Updating a column description and dropping a production table do not go through the same process.
2. What is measured? The number that matters is not the count of approval steps but the time from opening a request to execution. If that time is long a policy has been set up wrongly, and that is a visible figure.

02:00: The Emergency Path

"Will we gather approvals when a fire starts at night?" is a fair question. That is why the emergency path exists. An emergency request asks for a reason (the incident number can be made mandatory by an organisation setting); it shortens approval steps but does not skip them. A review is then due the next day; emergency requests not yet reviewed show separately in the report. The result: the work is done at night, and in the morning "why, who, was it needed" is answered once and closed. This is a second advantage for the DBA: the necessity of an emergency intervention is on record. The answer to "why did you do this at night" is a record.

"We Already Have a Monitoring Tool"

Database activity monitoring tools do good work: they see the traffic, generate rules and raise alerts. That is an observation layer, not governance. Observation tools see the command that ran and do not know the intent; they cannot answer "was this operation approved". The two layers do not replace each other; together they are strongest: observation sees everything and governance knows which access was allowed.

What Changes and What Does Not

• What does not change: the text is still SQL you write, the decision is still yours (which method, in which order), execution is still under your control: you can schedule it and try it in a sandbox.
• What changes: the reason and approval for the work sit in a request. The rollback plan is ready before execution (mandatory when the organisation switches on the "rollback required" rule), which reduces the "I wish I had checked the backup" moments. If a problem arises the evidence is ready.
• Segregation of duties: once the organisation switches on the segregation rules you cannot execute your own request. That is not distrust; it protects you by showing that even the most privileged person on the team is subject to the same rule. If the rules are off the Setup Check screen warns and the evidence file shows it as an exception.

The Honest Limits

• The product adds delay. Opening, approving and executing a request takes longer than running directly. Band based approval depth and the emergency path reduce it, they do not eliminate it.
• The product is not a blocker. It does not stop connecting to the database another way. Monitoring that is the job of DAM and SIEM.
• The team has to adopt it. The best built process is worthless if DBAs skip it because "this slows us down". That is why the policy should be built with DBAs, not against them.

The most important question is the third: this kind of tool will reach your organisation sooner or later. Will you set it up with your rules, or without your knowledge?

Frequently Asked Questions

Does a governance tool slow the DBA down?

Yes, opening and approving a request takes longer than running directly. An approval policy can set the depth by band and the emergency path shortens the time, but delay is not eliminated. The key measure is the time from opening a request to execution, and that is a visible figure.

Do you have to gather approvals for an urgent job at 02:00?

An emergency request asks for a reason (the incident number can be made mandatory by an organisation setting), shortens approval steps without skipping them, and is then due for review the next day; those not reviewed show in the report. So the work is done at night and in the morning "why, who, was it needed" is answered once and closed.

If we have a database monitoring tool, do we need governance?

They do not replace each other. A monitoring tool sees the command that ran but does not know whether it was approved. The governance layer knows what was allowed. Together they are strongest.