SQL Change Guard
SQL Change Guard standardizes and enforces risk based governance across every database operation, and produces the audit evidence as a by product.
Closing the governance gap requires four things to sit together in one place: the rule behind the decision, the enforcement of that rule, the evidence of the action, and coverage of every path into production.
When the four live in separate places, an organisation has all of them and can show none of them. The rule is in the policy, the enforcement is in a person, the evidence is in the logs, and the coverage is an assumption.
| Operation | Where the decision is made today | After governance |
|---|---|---|
| Schema and object change | A ticket plus personal judgement | The organisation's rule, recorded as it stood that day |
| Access to production data | A verbal agreement | A justified request, a decision, and a trace of what was delivered |
| Emergency intervention | The process is suspended | It enters a separate emergency policy, and at least one approval step stays locked |
| Release package | The order the senior person knows | Order and contents held in the organisation's record |
| Work done outside the pipeline | It lands in no record at all | It is declared as an emergency or as done manually, and its justification and the policy applied enter the record |
It does not remove the processes that already work for you. It takes them out of personal dependency.
Risk is assessed by the organisation's rule, so the same work gives the same result no matter who handles it. Even after the rules change, an old record is still read against the rules of its own day.
Evidence is not assembled afterwards. It forms with the event, carries its own integrity, and can be verified independently of whoever keeps the records.
What this layer changes can be measured under eight headings. None of them is the name of a screen. Each is a question your organisation can either answer today or cannot.
| Measure | What changes in the organisation |
|---|---|
| Policy Driven Governance | Policy stops being a document and becomes a working rule. The gap between what is written and what is enforced closes. |
| Standardized Risk Assessment | The same work carries the same risk no matter who handles it. Risk is set by the organisation's rule, not by individual instinct. |
| Policy Driven Approval | An approval is more than a signature. The rule the signature rests on sits inside the record. |
| Centralized Governance | Different teams, environments and database platforms report into one decision model. |
| Audit Readiness | An audit stops being a preparation project. Evidence is not assembled from mailboxes and spreadsheets; it forms with the event. |
| Traceability | Who, when, why, under which approval, under which risk assessment, with which script and with what result. All seven in one record. |
| Production Data Governance | Access to production data becomes an event with a stated reason and a decision, not just a connection log line. |
| Visible exceptions | Work that steps outside the process does not disappear. An emergency enters a separate policy, and the justification and the policy applied stay in the record. |
It does not write your scripts. It does not replace your pipeline. It does not cancel your ticket. It does not change your log platform.
It is installed in your own environment, and access to your databases stays inside your network.
Everything so far has been text. These two recordings show what the same governance model looks like on screen.
A product overview: which problem it solves, which flows it governs and where it sits in your organisation.
The request behind production data access, the decision, and the trace of what was delivered.
These are not a feature list. Each one shows where the answer to one of the questions above is kept.
Click for full screen. Navigate with arrows, close with ESC.