Contents
Most conversations about database governance open with the same sentence: "We already have a process." The sentence is true. There is a ticketing system, an approval flow, a working delivery pipeline, a database activity monitor that was paid for, risk tables that were built, and procedures that were written and signed. The issue is not whether the process exists, it is where its scope ends. This article walks through the questions a well built governance stack cannot answer.
A True Sentence With a Missing Scope
The enterprise stack matured around the application layer. There is a source repository, code review is mandatory, the pipeline runs tests, releases are tagged. On the application side the answer to what went to production sits in one place, and nobody argues about it.
The database layer never reached that maturity, and the reason is not technical: work that touches the database does not flow through a single channel the way an application release does. A schema change goes through the pipeline; a data correction does not. A permission change does not. An emergency fix at night does not. A request to extract data for an audit was never any pipeline's business. The process covers exactly one of the roads into production.
The scope test
Think of every statement that ran against your production database last month. What share of them went through the delivery pipeline? In most organisations the answer is below fifty per cent. The rest are unrecorded not because someone excluded them, but because no process ever described that road.
Where Each Tool in the Stack Stops
The table below does not claim any tool is deficient. Each one does its own job. Its purpose is to make visible which question falls outside which tool's remit.
| Tool | The question it answers | What falls outside its remit |
|---|---|---|
| Ticketing and service management (Jira, ServiceNow) | What was asked for, by whom, who approved it and when it closed | Whether the approved text is the text that ran. The ticket holds an attachment; the attachment can still be edited after approval, and the ticket cannot see what reached the database. |
| Delivery pipeline (Azure DevOps, Jenkins, GitLab) | Which version went to which environment and which step succeeded | Work that reaches production outside it. A pipeline knows only what it carried; about what it did not carry it is silent, and that silence gets read as nothing happened. |
| Schema migration tools (Liquibase, Flyway, Redgate) | The versioned state of the schema and consistency across environments | Everything outside planned schema work: data corrections, permission changes, maintenance and requests to read data. These tools were never designed to govern a request to look at production data. |
| Database activity monitoring (Guardium and similar) | What ran, from which session, at which second, against which table | The authorisation decision. These products can pull approval data in from a ticketing system and place it alongside in a report; they do not produce the approval and they do not stop the event before it happens. |
| Log platform and SIEM | Event correlation, rule based alerting and retention | Whether an event was authorised. The authorisation decision never reaches the SIEM; it can say this ran, it cannot say this was approved to run. |
| Risk tables and written procedures | The organisation's intent: how each kind of work should be done | Whether they were followed. A document is not a control, it is a description of one. An auditor asks for evidence that the description held, not for the description. |
Read row by row, what emerges is this: the stack answers what happened and what was asked for very well. The question left unanswered is the one that joins them. No single record shows that the work which happened is the work that was asked for, and that it was approved under the rule in force that day.
The Granularity Problem in Unauthorised Change Detection
A fair objection arrives at this point: modern service management platforms can detect unauthorised changes. When an unplanned change is seen on a configuration item, a record can be raised automatically. The capability is real and it works.
It has two limits, and both of them are decisive at the database layer.
The first is coverage. These mechanisms are built on discovery and service mapping; out of the box they check only configuration items attached to an application service. Items not attached to one, and newly discovered items, fall outside. Most organisations end up building custom logic to close that gap.
The second is granularity. The configuration item in the CMDB is usually a server or a database instance. Adding a column to a table, changing the body of a stored procedure, granting an extra permission to a user: none of these alters any attribute of the item. In other words the most critical database changes happen one level below what the detection mechanism can see. The server record has not drifted, so no alert fires and the report looks clean.
The quiet clean report
A line reading "no unauthorised changes detected" can mean two different things: none occurred, or none are visible where you looked. The only way to tell them apart is to ask at what granularity the detection runs. Detection at server level says nothing about a change at table level.
Seven Questions: A Fifteen Minute Self Assessment
None of the questions below are product questions. Each can be tried today against your own records. Pick one database change that ran in production last month at random and work down the list. The test is not whether an answer exists, but whether it can be shown within minutes.
| Question | What a slow answer means |
|---|---|
| 1. How do you show the text that ran is byte for byte the text that was approved? | The approval was given to an intention rather than to a text. That gap cannot be closed after the fact. |
| 2. On what stated basis was this change assigned its risk level? | The assessment rests on personal judgement. Someone else would classify the same script differently, and that inconsistency becomes an audit finding. |
| 3. What enforces, and what records, that the approver and the executor are different people? | Segregation of duties lives as an expectation. An expectation does not stand in for a control. |
| 4. How many change requests were rejected last quarter, and where are the rejected ones recorded? | Rejected requests may not be recorded at all. A record showing only approvals demonstrates the outcome, not that the control operated. |
| 5. How many emergency changes happened last month and how many had their post hoc review completed? | The emergency channel may have become an uncontrolled shortcut. Every emergency change without a post hoc review is accumulated debt. |
| 6. Can you show an approval decision from eighteen months ago together with the rule set in force on that date? | A past decision will be judged against today's rule. If the rule has changed since, the decision looks wrong through no fault of its own. |
| 7. Who extracted rows from production data last week, on what stated reason, and under which masking decision? | The read side is not governed at all. Even in organisations with the most mature change management, this is the widest gap. |
If three of the seven cannot be answered within minutes, your process is working but not producing evidence. In an audit those two situations lead to the same outcome.
Risks Carried Without Noticing
What these gaps have in common is that they are quiet. None of them causes an outage, none of them shows red on a dashboard and none of them generates an invoice. The price is paid on the day something goes wrong.
The unprovable control. The control may genuinely be operating. An auditor does not look for operation, they look for demonstrable operation. A control that cannot be demonstrated produces the same finding as one that was never applied. This is where organisations are most often caught out.
Key person dependency. In most organisations the number of people who know how work against the production database is done properly fits on one hand. They know the rules, they know which table is critical, they know which script must not run at night. None of it is written down. When that person leaves, what disappears is not knowledge, it is the control.
Silent scope drift. When the process was set up there were five servers. Today there are seventeen, and how many of the new ones fall inside the process is on nobody's agenda. When the scope list is a document written once and never revisited, coverage shrinks a little every month.
Personal data risk. Even in organisations mature on the change side, the read side goes ungoverned. A customer list pulled from production for a support ticket ends up as a spreadsheet on somebody's machine. Under data protection law there are three separate failures here: there is no record of who processed the data and for what purpose, the data was not minimised because more columns were pulled than needed, and because nobody knows where the extract went, no retention period can be applied. None of this produces an incident; it surfaces on the day a breach notification is required, and by then it cannot be corrected retrospectively.
Work escaping the process. If the approval route is slow, work does not stop, it reroutes. If waiting for the change board takes three days, by the end of the third day that change has most likely been made through another channel. This is not indiscipline, it is an outcome produced by the design of the process itself.
The Cheap Way to Close the Gap
None of these gaps requires replacing an existing tool. The ticketing system stays, the pipeline stays, the monitor stays. The only missing piece is a shared record that work touching the database passes through. When that record carries four fields on one row, all seven questions become answerable.
The text. The SQL itself, digested at the moment of approval and again at the moment of execution. If the two digests differ, execution does not start.
The assessment. Which rules produced the risk level, written down and reproducible. The same script submitted tomorrow must produce the same result.
The decision. Who approved it, under what authority, and which rule set was in force at that instant, frozen at the moment of decision.
The outcome. What ran, how many rows were affected, what happened if it failed, and whether a rollback script was produced.
SQL Change Guard exists to produce exactly that record. It does not replace your current tools; it adds the layer that answers the question they cannot, and it links to your ticketing system by ticket number and to your log platform by record identity.
Where to start
Not with a programme covering the whole estate, but with one production server. Bring every road into that server onto a single record, then ask the seven questions again a quarter later. Widening the scope with that measurement is far easier than widening it by argument.
Frequently Asked Questions
Our current processes pass audits. Is there really a gap?
Passing an audit shows that the gap did not fall into the sample, not that it does not exist. An auditor usually examines a limited number of changes, and the ones they pick tend to be planned work that went through the pipeline, whose records are already clean. Roads outside the scope stay invisible as long as they stay out of the sample. That is why the real measurement is a random pick from your own records rather than the auditor's list.
Could we not solve this by adding fields and approval steps to our ticketing system?
Partly. A script field can be added, an approver role defined, rejected requests recorded. What cannot be solved is this: a ticketing system cannot see what ran in the database. Proving that the approved text is the text that ran needs a digest computed at execution time and a gate that ties that digest to the decision. That falls outside a ticketing system's remit, and building it there produces an internal product you then have to maintain.
We have a database activity monitoring product. Is that not enough?
Monitoring and governance are not the same layer. A monitor records the event after it sees it, which is valuable for detection. A governance layer produces a decision before the event: a request is opened, risk is measured, approval is obtained, and execution opens only on the back of that approval. They are not alternatives; your monitor is the best possible cross check against a governance record. Indeed these products can pull approval information in from a ticketing system and show it alongside; they consume that data, they do not produce it.
Will this layer slow the process down?
What slows things down is not control, it is applying the same weight of control to every change. A model that gates by risk band speeds low risk changes up and sends only high risk ones through the full process. The number to measure is not how many approval steps exist, but how long a request takes from opening to execution. When that time falls, so does the amount of work escaping the process.
Do our existing investments lose their value?
No. This layer complements rather than replaces, and the deployment model makes that explicit: requests carry your ticket number, records can be forwarded to your log platform, and planned schema work stays in your migration tool. The only thing that changes is that no road remains by which work can touch the database without leaving a record.
Let us walk the seven questions together
Bring your own scenario; we will walk the flow from opening a request to the sealed evidence file live, and mark the gaps together.
Book a Demo →