Database Operations Governance

Execution does not open until approval completes. Data is not delivered until sensitive columns are masked. The evidence sits in one file. SQL Change Guard binds every script bound for SQL Server, PostgreSQL or Oracle, and every request for production data, into one approval, risk and audit loop.

Change The script is parsed, its risk is set, it passes the approvals the policy requires and then runs under control.
Access Reading production data is tied to a request, sensitive columns are masked and the result is delivered in an encrypted package.
Evidence Who asked, who approved and what ran is handed to the auditor as one sealed file.
Walk the screens (no install) Watch the product run Request a demo
SQL Server PostgreSQL Oracle

These three are the managed target systems. The product keeps its own records on SQL Server.

88 SQL rules, each can be switched on or off
5 risk bands: Info, Low, Medium, High, Critical
31 built in reports, in five groups
3 independent audit layers
The sentence we hear most

"We already have this process."

It is probably true. Change management, approvals and a delivery pipeline really do work in most organisations. These three questions show exactly where that process ends.

What share of the SQL statements that ran in production last month went through your process?

A pipeline knows what it carried and stays silent about what it did not. Silence reads as "nothing happened". If no system computes this share, the answer is a guess.

The last customer list pulled from production: whose machine is it on, on what stated basis, and with which columns?

The change side may well be governed. The read side is usually not governed at all, and that is where personal data leaves.

How many change requests were rejected last quarter?

If the answer is zero, the control is filtering nothing. An approval is only an approval to the extent that it can say no, and auditors ask for the record of rejections separately.

The answers to these three questions do not live in your ticketing system, your pipeline or your database log. They fall outside every one of those remits. SQL Change Guard exists to answer exactly these three.

Six question self assessment Where your current tools end

What SQL Change Guard is

It is a governance layer installed inside your own network. It sits between your production databases and the people who touch them. Every script that will run and every request for production data is assessed against a written rule before the work happens, passed through the approvals the policy requires, and left behind as one record that can be proved later. The name for this approach is Database Operations Governance: it covers not only database change but production data access under the same roof.

Who it is for: organisations that need change and data access decisions on production databases to be on the record. Four questions let you measure yourself.

If two of them are a no, this layer is for you. If all four are a yes, you have already built it.

What it is not: not a deployment tool, not a ticketing system, not a monitoring product, not a database administration tool. Jira, ServiceNow, your CI/CD pipeline, Liquibase and your log platform all stay where they are. This layer does not replace them; it answers the question that falls outside every one of their remits.

Controls are not missing. They just do not know about each other.

Change management is in place. Approvals are in place. CI/CD is in place. Logging is in place. An audit happens twice a year. All of it works, and all of it lives in a different system.

Change approval lives in one system, data access in another, audit evidence in a third. When the auditor arrives, screenshots are collected from six places.

Nobody did anything wrong. It is just that nobody owns the whole.

What Database Operations Governance is
The morning of the audit

"Who changed this table in production at 14:00 on Tuesday, and who approved it?"

The answer exists inside the organisation. The problem is that it sits in four separate systems in pieces. Matching those pieces by hand takes time, and that time is paid again at every audit.

Today's setup

Four systems, four half answers

  • Ticketing Says what was asked for. It does not know the final text of the script.
  • Delivery pipeline Says what it carried. It never sees work that arrives outside the pipeline.
  • Database logging Says what ran. It does not say why it ran or who allowed it.
  • Email and chat This is where the decision was actually taken, and it does not count as evidence.

The correlation tax: Answering a single question means lining up timestamps across four systems by hand. That effort is paid per audit, it leaves screenshots as evidence, and the match is never complete.

SQL Change Guard

One record, the whole answer

  • Request and ticket The script, the target servers and a ticket number matching your format rule, in one record.
  • Decision and rule Which rule set the risk, which policy demanded which approval, and who approved.
  • Execution The fingerprint of the text that ran, on which server, when, who started it and the outcome.
  • Evidence The whole lifecycle exports as one sealed file that can be verified independently.

The outcome: The auditor's question comes down to one request number. The evidence is produced by the work itself rather than prepared for the audit.

The auditor asks Where the answer lives when tooling is scattered With SQL Change Guard
Who asked for this change? In the ticket, not linked to the final script On the request, together with the script
Under which rule did it go for approval? Usually nowhere; it follows habit The rule set of that day, frozen onto the request
Was the text that ran the text that was approved? Compared by hand, and usually not at all The script fingerprint stays on the record
Who read production data, and why? In the activity monitor; the reason is in a chat thread On the query request: the reason, the masking decision and the delivery address
Could the record itself have been altered? It rests on trusting the team that keeps the record A signed trail, a sealed copy in a separate database and a verify action
How it runs alongside your current tools Read about the correlation tax
Two separate flows

Two paths into production, one governance model

Changing something and reading something are different risks. The product handles them as two separate flows.

Flow A

Database change governance

Every script that changes schema or data.

  • Request Opened with the script, target server and ticket number.
  • Validation The script is parsed with a real grammar and the enabled rules from the catalog are applied.
  • Risk The highest tier among triggered rules sets the request band.
  • Policy and approval Approval steps are generated from server, environment and band.
  • Execution After approval the application executes it, with optional scheduling and a rollback script.
  • Audit Every step is written to a signed audit trail.
Details
Flow B

Production query governance

Requests to read data from the live environment.

  • Query request Opened with the query, its justification and the delivery addresses.
  • Rule check Critical object access and query rules are applied.
  • Sensitive data detection Columns are classified against patterns and validators.
  • Masking and approval Sensitive columns are masked; an unmasked column needs a justification and an extra approval.
  • Controlled delivery The result is not shown on screen; it is delivered as an encrypted, password protected package.
  • Audit Who took which data and why stays on the record.
Details
Lifecycle

How a request moves from start to finish

One request. One lifecycle you can follow end to end.

1 Request Scripts, target servers and the ticket number are entered. The ticket format is checked against your rule.
2 Validation The script is parsed with the grammar of its database type. A syntax error stops the save.
3 Risk The band is the highest tier triggered. Nothing is averaged; one critical finding sets it.
4 Policy The policy matching the server, environment and request type is selected and the steps follow from it.
5 Approval The required role closes the step. A locked step cannot be skipped by seniority.
6 Execution The application runs the script on the target server. Result, duration and any error are recorded.
7 Audit Every step goes into a signed chain and can be exported as evidence in a single file.

The rule holds even under pressure. When a rule marked never skip is triggered, the machine cannot execute the request on its own and the approval step tied to that rule cannot be skipped. Six rules ship marked this way.

Capabilities

What it does, why it matters

CHANGE

Change governance

What it does: Request creation, multiple scripts, real grammar parsing, risk banding, controlled execution, scheduled execution, rollback script generation, sandbox trial and release packages.

Why it matters: A script bound for production goes through the same gate every time, and what happened stays readable afterwards.

Details
POLICY

Policy governance

What it does: Policy selection by server, environment and request type; steps triggered by rule key or risk band; critical object definitions; non skippable step locks; separation of duties parameters.

Why it matters: Approval stops being a habit and becomes a written rule. The rule as it stood that day is frozen onto the request.

Details
QUERY

Production query governance

What it does: Query requests, sensitive column detection, full and partial masking, justified extra approval for unmasked columns, encrypted package delivery, recipient address approval and a masking audit record.

Why it matters: "Run this query and send me the result" turns into a recorded process.

Details
AUDIT

Audit and evidence

What it does: A signed audit trail, a sealed second copy in a separate database, database level trigger records, a per request evidence file, 31 built in reports and object change history.

Why it matters: Audit preparation stops being a project. The evidence is produced by the work itself.

Details
Four things that set it apart

Four things your stack has no answer for

Some of the capabilities above already have a counterpart in your organisation. These four usually do not, and they are the reason the product exists.

The empty shelf

Governing the read, not only the change

On the change side most organisations have a process. On the side of reading production data, almost none do. Ticketing does not carry read requests, the pipeline does not carry them, and a monitor sees that the query ran but not why, nor where the file went.

Here the request, its reason, sensitive column detection, masking, a justified approval for unmasked columns, encrypted delivery and the approved recipient all sit on one record. Every question asked in a personal data audit is answered from it.

Query governance →
Time

The rule behind a decision is frozen to its day

Rule sets change. Explaining a decision from six months ago with today's rule is misleading and an auditor will not accept it. When a request opens, the rule set in force that day is frozen onto the record.

This is not a feature that can be bolted on later; it is a decision the data model has to make from the start. Adding it afterwards does not rescue past records.

Audit and evidence →
Evidence

Evidence verifies without us, and exceptions are not hidden

A request's whole lifecycle becomes one sealed file. The seal is written into the audit record; hand the file back later and the digest is recomputed and compared. Nobody has to say "trust the team that keeps the record".

And the file writes against itself: if the requester executed their own request, that is recorded as an exception. Governance is not measured by the absence of violations but by whether they surface.

Download the sample file →
Scope

Three engines, one model, a real grammar

Most organisations run at least two database engines, and the maker of one does not govern the other. Here SQL Server, PostgreSQL and Oracle all enter the same decision model, each parsed with its own real grammar.

The real grammar matters: text matching cannot tell a delete inside a comment from a real one. A rule is only reliable when it runs on the syntax tree of the statement.

Platform →

It is installed inside your organisation, your data never leaves, and the interface and support are available in Turkish with compliance documents written in the language of local data protection law. We compare where your current tools end on a separate page.

Product screens

Where the decision and the evidence live

Change request screen with the script, the validation findings and the risk band
Change request and risk The script, the rules it triggered and the request band, on one screen.
Approval policy definition screen with the steps, the roles and the trigger conditions
Approval policies When each step comes into play is written here.
Query result request detail with the masked columns and the delivery information
Query result and masking Which column was masked and who the result went to.
Audit records screen with chain verification and the event list
Audit records The event list and the check that shows the chain is unbroken.
Parameters screen, segregation of duties tab: whether the approver may execute and whether the requester may approve their own request
Segregation of duties settings What nobody may do is written here rather than in a policy document.
Release packages screen with the approved requests in the package, the execution order and the dependencies
Release packages Approved requests, the execution order and the dependencies between them.

What these screens produce

The screens above are where the decision is made. The evidence is not a screen but a file: a request's whole lifecycle exports as one sealed file, and that file is what the auditor receives. It holds who asked, which rule set was in force that day, the timeline, the script fingerprint, the risk rationale, the masking decision and the verified audit records.

It is real product output, not a mock-up made for a brochure. You can download and inspect it without signing up.

Sample evidence dossier (PDF) Machine readable copy (JSON) How it is sealed
See all nineteen screens Walk the screens step by step
Product videos

Watch it running

No slides, the product itself. Three flows for the three pillars: a change going to production, the evidence the auditor receives and data leaving production.

All ten videos, with chapter titles
End to end walkthrough

How a change reaches production

A request to add a column, from the moment it is opened to the moment it appears in production. A minute and a half, silent, narrated by on-screen text. Every screen in it is real product output.

  • The script is parsed and the risk band is computed
  • A rule stops the work before it is even saved
  • The approval path is built from the content of the request
  • For the approver, the execute button stays closed
See it on your own environment

What the auditor actually receives

Evidence is not prepared separately for the audit. It comes out of the work itself and can be verified without the product.

How data leaves production

Most organisations govern changes but not reads. This flow follows the read side.

Architecture

Where it sits in your environment

It runs on your own servers. It sits on the path to your databases and moves no data outside.

Users and roles Web interface. Sign in with the corporate directory and a second factor. Eight role levels.
SQL Change Guard Application server and background service. It keeps its records in its own database.
RiskRule engine
PolicyStep decision
ApprovalRole and lock
Target databases SQL Server, PostgreSQL, Oracle. Each is parsed and executed with its own grammar.
Audit and evidence A signed trail, a sealed copy in a separate database and database level trigger records.

Your ticketing system, your pipeline and your log platform stay where they are. The product does not replace them.

Deployment and security

The four questions your organisation will ask

Where does our data go?

Nowhere. The product runs on your own servers and keeps its records in your own database. There is no cloud dependency and your production data does not leave the organisation.

What permissions does it need?

The schema is installed from numbered scripts shipped with the product. There is a validation mode for banks and similar institutions: your database administrator applies the scripts through their own process and the application account is never granted schema modification rights.

How does sign in work?

Sign in through your corporate directory is supported and a second factor can be enabled. Authorisation is managed through eight role levels and screen level permissions, and it is enforced on the server rather than in the interface.

What does it give us for data protection?

Access to production data is tied to a request, sensitive columns are masked, and unmasked access is recorded with its justification. User and server passwords are stored encrypted and the audit trail is signed. A compliance document is available to download.

Compliance document (PDF) System architecture and topology (PDF)
Evidence

What you show the auditor

A request's whole lifecycle exports as a single file: who asked, which rule set was in force that day, the timeline, the script fingerprint, the risk rationale, the masking decision and the verified audit records.

The file carries its own seal, and the seal is written into the audit record. That seal is how you check the file has not changed since it was produced.

Exceptions are not hidden. If the requester executed their own request, the file records it as an exception. Governance is not measured by the absence of violations but by whether they surface.

We are not describing it, we are showing it

The files below are real product output, not mock-ups made for a brochure. Download and inspect them without signing up or leaving an email. If you sit on the audit or compliance side, judge us on this file rather than on a slide deck.

PDF

Sample evidence dossier

One request's whole lifecycle: the request, the rule set of that day, the timeline, the script fingerprint, the risk rationale, the approvals and the audit records.

Download Dossier.pdf
JSON

Machine readable copy and seal

The same file as data, plus the package digest. The seal is written into the audit trail; hand the file back to the product later and the digest is recomputed and compared.

Dossier.json · Manifest.json
PDF

Data protection compliance note

What the product does and does not do about personal data, retention, masking and the audit trail. Written for the questions your legal and compliance team will ask.

Download Compliance_KVKK_EN.pdf
PDF

System architecture and topology

Components, network topology, data flow and which account reaches what. The document to read before a security review starts.

Download SystemArchitecture_EN.pdf
Audit and evidence All documents
Who benefits

What changes for your role

CIO, IT Director

You see from one place how controlled database operations are and what happened in the past.

 CISO, Compliance

Who reached production data, for what stated reason, and which column went out unmasked, all stay on record.

 Database team

Request, approval and execution move in one flow. The rollback script and the sandbox trial come from the product.

 CTO, DevOps Manager

Database work joins a controlled delivery process while your pipeline stays where it is.

 Internal Audit

Who did what, why, who approved it and what ran: the evidence sits in one file.

 Change Manager

The approval rule becomes written, and the rule set of that day stays readable later.

 Infrastructure Manager

What ran on which server, who holds which permission and where pending work stands all become visible.

Not another tool. The layer that was missing.

Your pipeline stays. Your ticket stays. Your log stays. Governance is added.

Database Operations Governance
Schema versioning
Pipeline and automation
Change ticketing
Server monitoring
Log and SIEM
Backup

Most enterprises do not want another tool. They are right. There are already enough tools.

This product places accountability above the ones you have. Your pipeline keeps running, your change ticket stays where it is, your log platform does not move. One thing changes: all of them now report into a single decision and evidence model.

It is also worth saying what it does not do. It does not write your scripts, it does not run your tests and it does not close your ticket. It does one thing, and none of your tools is doing it: it keeps the decision, the rule and the evidence of work bound for production on the same record.

You are not adding another tool. You are putting one decision and evidence model on top of what you already run.
How it relates to your tools

Short answers

The six questions that come up most in a first conversation. The longer answers are on the frequently asked questions page.

What is Database Operations Governance?

It is the practice of assessing work that touches a production database against a written rule before it happens, having an authorised person approve it, and being able to prove it afterwards. It covers two areas at once: database change and production data access. It differs from change management in that it governs whether the work is allowed through rather than how it is carried.

What exactly does SQL Change Guard do?

It parses a script with a real grammar, produces findings against a rule catalog and sets a risk band. Execution does not open until the approvals the policy requires are complete. At execution the digest of the text is sealed into the audit record, and the outcome and affected row count are recorded. For object definition changes a rollback script is prepared in advance. Requests to extract production data go through the same loop: sensitive columns are masked and the result is delivered as an encrypted package.

Does it replace Jira, ServiceNow or our delivery pipeline?

No. A ticketing system knows what was asked for, a pipeline knows what it carried, a monitor knows what ran. None of them can show that the text that ran is the text that was approved, because that is outside all of their remits. SQL Change Guard makes that link and connects to your existing system by ticket number. How it relates to your current tools.

Which databases are supported?

As managed targets, SQL Server, PostgreSQL and Oracle. Each is parsed with its own grammar; no shared syntax is assumed. The product keeps its own records on SQL Server today.

Where does it run, and does our data leave?

It runs inside your own network; it is not a cloud service. Your scripts and query results are never sent to any external service, and the product keeps its records on your server. Encryption keys live in your configuration; there is no key embedded in the product. Security architecture.

Will it slow us down?

What slows things down is not control, it is applying the same weight of control to every change. Approval depth follows the risk band: a low band passes with one approval, a high band requires several. The number to measure is not how many approval steps exist but how long a request takes from opening to execution.

Does this layer exist in your organisation

Six questions. Five minutes. Not a sales call.

1Can you show under which rule a change running in production was approved, together with the rule as it stood that day?
2Can you see in one place who read production data and for what stated reason?
3Are the steps skipped during an emergency recorded with their justification?
4Can your audit evidence be verified independently of whoever keeps the records?
5How many separate paths deliver change to your production database, and how many sit inside the same governance model?
6If your most senior database administrator took a month of leave, where is the release order written down?
If you cannot say yes to three of these, the problem is not your tooling. The layer is missing.
Request a demo Complete the self assessment