Change requests and data requests pass the same gate: the script is parsed, the risk band is calculated, approval steps are built, the approved content is compared again before execution and every step is written to the audit record.
There are three brakes and they are not equally hard.
If the script cannot be parsed, the request is never saved. This brake cannot be turned off.
If a standard marked "blocks save" is triggered, no record is created. Seven rules ship with this flag, for example UPDATE and DELETE without WHERE, and opening or closing a transaction by hand inside the script.
For other high tier findings the user is shown an acknowledgement, and the request is only saved on the second submission.
The rule set belongs to you. A catalogue of eighty eight SQL standards ships with the product. Each can be switched on or off, its tier changed, and the database types it applies to selected. Screen: Settings, SQL Standards.
Every SQL standard carries one of five tiers: Info, Low, Medium, High, Critical. A request's band is the highest tier among the rules it triggered.
Nothing is averaged and no points are summed. The reason is simple: the average of fifty small findings hides a single critical one. A worst case approach prevents that.
The screen also shows a number between 0 and 100. That number is a readable projection of the band and is used in no gate decision. Decisions belong to the band and the rule flags.
Rules that can never be skipped. Eight rules ship with this flag: dropping a critical object, accessing a critical object, schema change on a critical object, running an operating system command, permission changes, linked server usage and a manual COMMIT or ROLLBACK written inside the script. When one is triggered, the machine cannot execute the request on its own and the approval step tied to that rule cannot be skipped.
Approval is not a habit. It is a written rule, and it is frozen onto the request at save time.
Candidate policies are searched in this order of specificity: a specific server, then the environment, then global. When several candidates sit at the same level, the priority value decides. On a multi server query request each server is resolved separately and the policy that produces the most approval steps wins.
The approver role; triggering on specific rule keys; triggering at a risk band threshold; skipping at a low band; skipping when the requester's own role is high enough; and a lock that makes the step wait under all conditions.
The point most often misread. Only two fields make a step conditional: the rule key and the band threshold. Once a conditional step is triggered it is not skipped because the requester's role meets the approver role, nor because the band is low; only a role skip written explicitly on the step can apply, and not even that if the step is locked. A plain base step, by contrast, is skipped when the requester's own role is at or above the approver role, provided self approval is allowed.
When switched off, a requester can neither approve nor execute their own request.
When switched off, whoever closed a step cannot execute that same request.
When switched on, one person can close only one step on the same request.
The installation default is permissive: a requester may approve and execute their own request and an approver may execute; the Governance Setup Check screen shows each of these on its own line. The effective value of these three settings is frozen when the request is saved. A later change does not rewrite requests that were already decided.
An authorised user executes the request or schedules it for later. Automatic execution can be enabled per server, but if a never skip rule was triggered the machine will not run it and a person has to press the button.
The product can generate a rollback script from the original. A server can be marked so that nothing runs without one. A script can also be tried on a non production server inside a transaction that is rolled back at the end, and the result is attached to the request. The trial is not a full simulation of production; on Oracle a request containing DDL, DCL or TRUNCATE cannot be tried.
Let us be explicit about the scope. Automatic generation covers object definition changes: for tables, columns, indexes, views, procedures and the like, the current definition is read from the server and the reversing script is prepared. For statements that change data (INSERT, UPDATE, DELETE, MERGE, TRUNCATE) and for procedure calls (EXEC) the previous row values cannot be derived from the script, and today the product does not copy the affected rows before execution. In those cases that part stays in the generated script as a note to be completed by hand. If it runs without being completed, the part shows as "not applied" in the execution output and the evidence file records it as an exception; the rollback is not quietly counted as complete. A server setting can forbid execution without a rollback. Known limits: when a dropped table is rebuilt from the catalogue, the expression of a computed column is not carried over on SQL Server and PostgreSQL and the column comes back as a plain column (Oracle has no such loss); on SQL Server the table's triggers are not rebuilt either. The generated script lists what was left out in a note at the end, and the script should be reviewed before approval.
Several requests can be gathered into one package and run in order. A request inside an active package is governed by the package; editing and running it on its own is disabled.
An emergency request is routed to a separate emergency policy. A justification is mandatory, the emergency route opens only from a defined role level upward, and an emergency policy must contain at least one non skippable approval step.
Reading data from the live environment is a legitimate need: a customer complaint is investigated, the root cause of a bug is traced, a report is verified.
The problem is not the need but the way it is met. The query is passed on verbally, the result leaves as a file, and who saw which data is recorded nowhere. When the auditor asks who looked at production data last month, there is no answer.
The first looks at the column name, the second at the value itself. The second runs while the query executes, before the result is written to the package; if a set share of the values in a sample of the result matches a pattern, the column is treated as sensitive even when its name looks innocent. This catches data that has a pattern (identity, card, IBAN); fields without a pattern, such as names and addresses, rely on the column name catalogue. If detection runs out of time, the remaining columns are masked.
Not everything that matches a pattern is sensitive. Checksum algorithms run for national identifiers, tax numbers, card numbers and IBANs, so random digits are not masked by mistake. Patterns that collide with ordinary words (such as SWIFT/BIC) come disabled at installation; such columns are caught by name through the catalogue. A server can be moved, with a justification, to a content pattern only regime; there, fields with no pattern such as names and addresses go out unmasked.
A value can be hidden entirely, or the last few characters can be left visible. Partial masking is the middle ground: enough to recognise a record, not enough to carry the data.
An unmasked column is not forbidden, it is accounted for. Some investigations need the real value. The product does not block that; it asks for a justification, opens an extra approval step, and records which column went out unmasked and who approved it. Governance is not about banning access. It is about accounting for it.
The result is never rendered on screen; it is packaged as a password protected archive. The package password is stored encrypted and shown to the requester inside the application, with a reason recorded. Apart from the requester, only a user at a defined role level (change manager and above at installation) can download the file, and that is written as a separate event.
Delivery addresses can be checked. If an address has not been approved before, an extra approval step is added. The aim is to stop live data from quietly leaving for an external address.
The delivery mode is defined as an organisation wide ceiling. A request may only choose something stricter; loosening is rejected.
Each column's decision is kept as a separate record: a masked column with the rule that masked it, an unmasked column with its reason (no sensitive value in the sample, no data, and so on). Threshold and sampling settings are frozen at delivery time. The delivery record carries the file's digest and the address the email actually went to; if the column decision planned at save time differs from the one at delivery, the evidence file shows it as an exception.
Request, approval, execution and evidence file are the same on all three engines. The difference is in how the script is parsed and in each engine's own rules.
| SQL Server | PostgreSQL | Oracle | |
|---|---|---|---|
| Script parsing | ScriptDom (TSql170) | libpg_query | ANTLR4 PL/SQL grammar; falls back to pattern analysis when a statement cannot be parsed |
| Controlled execution | Yes | Yes | Yes; the transaction state is tracked in PL/SQL blocks |
| Isolated trial (sandbox) | Yes | Yes | Not for requests with DDL, DCL or TRUNCATE (implicit COMMIT) |
| Rollback generation | Generated for object definitions from the current definition on the target. No script is generated for data changes such as INSERT, UPDATE, DELETE or MERGE; a manual intervention note is written and the rollback counts as incomplete. | ||
| Connection | Targets are reached from the application server through standard drivers; nothing is installed on the target. Certificate validation is switched on in the server definition. | ||
In Oracle, statements such as DDL, GRANT, REVOKE and TRUNCATE implicitly commit whatever was pending before them. If a script updates data and then alters a table, the update cannot be rolled back even when the alter fails.
Two separate rules detect this ordering during parsing: a statement that causes an implicit commit appearing after a data change (blocks the save by default), and DDL mixed with DML in the same script (a warning). For what cannot be seen in the script text, execution is tracked too: the product reads Oracle's transaction id before and after every PL/SQL block. If an error comes after a COMMIT inside a procedure or dynamic SQL has made a data change permanent, the request is not executed again and moves to reconciliation.
Partial success is a state, not an accident. On Oracle an execution can stop halfway. The product treats that as its own state: for a request that failed during execution, generating and running a rollback script is allowed, because there really is a partial change to undo.
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.
Four flows, every step shown with a real product screen. No install, no sign up.