Category definition
The governance discipline for production database operations. Definition, scope, maturity levels and how it relates to adjacent disciplines.
Version 1.0 · 8 minute read · No form
Database Operations Governance is the discipline of making every production database action decided under a known rule, enforced without exception, and provable afterwards without human effort.
The three parts of the definition are not interchangeable.
Deciding means the action is tied to a rule. An approval on its own is not a decision. An approval is a signature. The decision is the rule that signature rests on.
Enforcement means the rule holds when people are in a hurry. If a rule can be skipped, it is not a rule. It is advice.
Provability means the trail exists without anyone gathering it afterwards. Evidence gathered later depends on the attention of whoever gathers it.
The word governance has settled for identity, network, code and cloud configuration. It has not settled for the production database.
The reason is not a shortage of tools. There are plenty of tools on the database side. What is missing is the accountability layer above them, and there was no word describing that layer.
| Existing term | What it covers | What it does not cover |
|---|---|---|
| Change Management | Approval and tracking of a change | Data access, evidence generation, work outside the pipeline |
| Database DevOps | Moving a change into production | The rule behind the decision, accountability, audit evidence |
| Data Governance | Meaning, ownership and quality of data | Operational actions performed on the database |
| GRC | The enterprise risk and compliance framework | A rule that is enforceable at database level |
| Database Security | Privileges, encryption, attack surface | Governance of actions taken by an authorised person |
The gap sits here: an authorised person performing a permitted action without a rule. That is not a security breach. It is a governance breach. It did not have a name.
The governance level of an organisation is measured by how quickly it can answer these four questions.
| Question | Short name | Where the answer should live |
|---|---|---|
| Who decided this action, and under which rule? | Decision | In the record itself |
| Was the rule enforced even when people were in a hurry? | Enforcement | In the system, not in a person |
| What proves this six months from now? | Evidence | In an independently verifiable record |
| Are all paths into production in scope? | Scope | In the scope list |
Five levels. An organisation sits at one level at a time. The weakest link sets the level.
The rule lives in people's heads. Work moves with seniority.
Tickets, pipelines and logs exist, in separate systems.
The rule is written down but the system does not enforce it. It gets skipped under pressure.
The rule lives in the system. Exceptions are recorded with their reason.
Evidence is produced by the action itself and can be verified independently. Scope covers every path into production.
Levels are not skipped. The distance between three and five is the distance between a written rule and an enforced one, and no document closes it.
Scope usually falls short in the same place: organisations govern only the pipeline. There are eight paths.
If an organisation governs three of these eight paths, its governance is not 37 per cent. It is absent. Partial scope produces partial evidence, and partial evidence does not count as evidence in an audit.
Decision rule. The predefined condition that determines whether an action is approved. Different from an approval: an approval is a signature, the decision rule is what that signature rests on.
Rule set version. The complete set of rules in force at the moment an action was evaluated. Even if the rules change later, that action is read against the rules of its own day.
Evidence. A trail produced by the action itself rather than gathered afterwards. The test of evidence is whether it can be verified independently of whoever produced it.
Scope. All paths that reach production data. Every path left out invalidates the governance as a whole.
Emergency shortening. Not the removal of the rule but its shortening. The skipped step is recorded with its reason.
Out of pipeline action. An intervention made into production outside the automated pipeline. It is common and it is not a fault. Leaving it out of scope is the fault.
Independent verification. The ability to check a record from outside the system that keeps it.
Database DevOps solves how a change reaches production. Database Operations Governance solves who decided it should, under which rule, whether the rule was enforced, and what proves it. One is about flow, the other about accountability. They coexist in the same organisation.
It is a discipline. Tools implement it and frameworks audit it, but it is neither. An organisation can reach some levels of it without buying anything. The scope and independent verification levels require tooling.
No. The governance layer does not replace your process, it sits above it. Your ticketing, your pipeline and your log platform stay where they are. The only change is that they now report into a single decision and evidence model.
In practice there are three candidates: database management, infrastructure and information security. The right answer varies by organisation, but governance without an owner does not exist. If ownership is unclear, the current state is level two or below.
Yes, and arguably more so. In a small team the rule usually lives in one person's head, and it leaves when they do. Governance is not about team size. It is about where the knowledge sits.
In practice
The sections below show what happens where the definition stays abstract: sentences from the field, the hidden cost, the limits of existing tools and an ordinary day in a team.
No executive says they have no process. What we hear is the opposite.
All of it is true. None of it is wrong. Every tool on that list does its own job well.
But each answers a different question, and none of them sees the answer of the others.
| What it does | What it does not do |
|---|---|
| Jira tracks the change | It does not carry the rule the decision rested on |
| Jenkins delivers the change to production | It does not ask whether it should have been delivered |
| QRadar sees the event | It does not know whether that event was permitted |
| Guardium monitors the access | It does not say whether that access was approved |
| The risk register defines the risk | It does not show the definition was applied at the moment of the action |
| The segregation of duties procedure writes the rule | It does not guarantee the rule held when people were in a hurry |
This is not a missing tool. It is a responsibility that none of these tools owns.
This cost has no budget line. It only shows up in people's calendars.
None of these opens an incident. All of them count as normal. What counts as normal is never measured, and what is never measured is never governed.
The most expensive risks hide inside the work everyone considers normal.
They all answer the right question. There is just one question missing.
The tools are not bad. They are very good. They just all answer the same question: how does a change reach production.
The auditor is not asking that question.
The auditor asks whether this change should have reached production, who decided, under which rule they decided, what that rule was on that day, and what proves it.
Work that reaches production outside the pipeline stays outside the governance scope.
| Tool family | The question it answers | The question it leaves open |
|---|---|---|
| Schema versioning tools | How is a schema change versioned and applied | Who decided this change was safe for production |
| Compare and release tools | How do we diff and publish | What rule was in force at the moment of approval |
| Pipeline and automation tools | How do we automate delivery | Who owns work performed outside the pipeline |
| Enterprise change systems | Who approved the change ticket | Do the ticket and the database agree |
| Server monitoring and management tools | What happened on the server | Was it allowed to happen |
| Log and SIEM platforms | What was recorded | What shows the record is unaltered and tied to a decision |
These tools solve the "how". Governance is the "who, under which rule, and what proves it".
The conclusion here is not that you should replace these tools. It is the opposite.
Jira, ServiceNow, Jenkins, Azure DevOps, Git, Guardium and your SIEM platform all stay and keep running. None is removed and none is replaced. Each does a job in its own area that we would not do better.
What is missing is not a tool. It is a single model where the decisions, rules and evidence these tools produce come together.
DevOps manages flow. Compliance manages proof. Nobody manages the decision.
The DevOps team exists to make delivery faster. They are right about that. It is their job.
The compliance team exists to produce proof. They are right about that too. It is their job.
Between the two sits an area nobody owns: the decision.
The layer that decides whether a change goes to production, under what condition, who can stop it, and what will prove it afterwards.
Without that layer, DevOps accelerates, compliance slows things down, the two blame each other, and the real decision falls to whoever happens to be the most senior person in the room.
Judgement does not scale. It cannot be audited. It cannot be handed over.
If the decision lives in one person's judgement, the organisation is not managing governance. It is managing luck.
None of this breaks a rule. This is a normal day. That is exactly the problem.
The next month the auditor asks: who approved the 16:20 change, and under which rule was it treated as an emergency?
The answer is in someone's memory.
Nobody in this team made a mistake. The rules existed too. They just lived in people, not in the system.
Not more process. Fewer questions.
| Before | After |
|---|---|
| Someone searches their inbox for who approved this | The question is never asked. The record is the answer. |
| The same risk gets a different answer depending on who assesses it | The same risk is assessed the same way every time |
| Audit preparation is a two week project | Audit preparation is a file download |
| An emergency means skipping the rule | An emergency means shortening the rule and recording why |
| One person knows the release order | The order lives in the system and survives the person |
| Institutional memory leaves with the person who leaves | Institutional memory stays in the system and a handover stops being a document |
| A data request is handled on personal initiative | A data request is recorded, approved and delivered with sensitive fields masked |
| The rollback is written that night | The rollback is prepared together with the change |
| When the rule changes, old records lose their meaning | Every record carries the rule that was in force that day |
Governance does not add work. It removes the work you do afterwards.
Six questions, five minutes. You get a level and a next step.
The platform that implements this discipline: SQL Change Guard.