Govern the source, not the copy
Pollution flows downstream. A bad schema change on a hot table, a manual UPDATE to a billing record, a shared credential that broke something. Whatever goes wrong at the source shows up in every dashboard by morning, and the dashboard is where people notice. By then the trail runs backward through the pipeline to a change nobody flagged.
The data stream: three territories along the stream, each flying its governing discipline as a flag
Three territories, three flags:
- Downstream, data governance rules the warehouse: catalog, lineage, meaning.
- Midstream, data engineering owns the pipeline.
- Upstream, where every number is first written to a production table, the flag says database governance. That is the one most teams never plant.
Everything downstream is a copy of the production database. Govern only the copy and you catch problems after they spread. Govern the source and you stop them first. Put the effort upstream.
The four controls
Governing the source is not one feature. It is four controls, each answering a different question.
Review the change before it ships
Does this change survive a second pair of eyes?
Every schema and data change goes through a workflow before it hits production. The migration is a versioned file, checked against policy automatically (naming, missing indexes, a DROP on a table that still has readers), approved by someone who is not the author, then deployed and recorded. The database gets a change history the way application code has a git history: every change tied to a person, a ticket, and a review.
The point is not the ceremony. It is that the change becomes visible beyond the person typing it. An unreviewed migration is a private decision with public consequences, and that is where most downstream surprises are born.
Grant scoped access just in time, don't share it
Who can touch this database, and for how long?
Most shops answer badly. A shared admin credential in a password manager, a bastion host, a read replica half the company can reach. Standing access nobody remembers granting and nobody revokes. It works until it doesn't.
Stop handing out standing access. Grant it just in time: one database, one role, one window, expiring on its own. On the read path that runs through the governance layer (the SQL editor and query API people use to inspect production), mask sensitive columns so an analyst debugging an order never sees a full card number. Masking covers this human path, not the application's own connection. It governs people, not the app.
Codify the policy
Is the rule enforced, or does it depend on everyone remembering it?
A review step a senior engineer can wave through, an access grant approved over Slack, a masking rule in one DBA's head. Governance that runs on memory decays the first busy week. Declare the policy as configuration and let the system apply it: this environment requires two approvals, this role gets two-hour read-only access, these columns are always masked, this SQL anti-pattern is always rejected. The config is versioned and reviewed like code, and enforced on every request. Policy defined, enforcement automatic.
Codified policy is what makes the other three real. A review rule you can bypass is a suggestion. Put the rule in the config, and it holds whether or not anyone is watching.
Audit where the data is born
Can you prove it afterward?
Every query and every change against the source, recorded: who, when, which database, what came back. Not the application's logs, which see only the app's service account, but the log of human-to-database operations an auditor actually asks for. When the postmortem or the SOC 2 review comes, the answer is a query, not a shrug. This works only if access ran through a governed path. You cannot audit a shared credential.
Where to start
Pick the control you are weakest on and close it first. Most teams have some change review and no real access control, or the reverse. This is not a big-bang program: four controls on one database, then the next.
The warehouse is where you find the problem. The source is where you prevent it.
For why the two disciplines differ, see Data Governance vs. Database Governance. For the mechanics of each control, see database change management, database access control, and database compliance.