Each flow opens with a one minute video. If you are in a hurry watch the video; if you want the detail, read the steps one by one.
Click a screenshot to read it. In the enlarged view you can move through every screen with the arrow keys and close it with Esc.
Request number, target server, risk band, which approval step it waits on and whose desk it sits on, all in one row. Emergency requests and those with a rollback plan are marked with badges.
The script is parsed with the real grammar of its database type. Triggered rules are listed with line and column numbers. The risk band is the highest finding triggered; nothing is averaged.
Every object the script will touch is listed together with the operation type. Objects your organisation marks as critical carry a badge, and that badge changes the approval path.
If a blocking finding is present, such as an UPDATE without a WHERE clause, the request cannot simply be saved. The user sees the finding and has to confirm it deliberately, and that confirmation is recorded too.
Which policy applied, how many steps there are and which role can close each one. Steps are triggered by a risk band or a rule key. A step marked non skippable cannot be passed by seniority.
The person who approves cannot execute. The rule is enforced on the button itself rather than in a document. Hovering the disabled button tells you why.
The same screen shows the mirror image for the person who may execute. Segregation of duties works both ways, and the two screens side by side are enough for an auditor on their own.
Execution is queued and carried out by the service. The record holds the person who started it, the process that ran it and the number of rows affected.
The hash taken at approval time and the hash at execution time are shown side by side. This answers the question most often asked in an audit and least often provable.
The current definition of the object is read from the target server. The added column and index appear inside it. The comparison is made against the server itself, not a file in a repository.
Object history answers it on one screen: which version, which request, which ticket, when and by whom. No archaeology is needed during an incident review.
An emergency request goes through the same rule set. Findings such as a missing row limit, a missing database context or a manual data change surface exactly the same way.
The moment the switch is on, the applied approval policy is replaced by the emergency policy and two mandatory fields appear. The switch only shows when an emergency policy is mapped to that server.
The request cannot be saved without stating why it is urgent and which incident it belongs to. The change ticket and the incident number are separate fields: one describes the fault, the other the intervention.
The product drafts the rollback from the definition it reads off the target server. Where it cannot produce a statement it does not invent one; it marks the gap. The rollback is a separate request with its own policy.
Even with the request approved, execution stays closed while the rollback script still has an unfinished part. The existence of a plan is not enough; its content has to be complete.
The person who opened the request cannot execute it themselves, not even in an emergency. A second authorised person is required. The rule again sits on the button, with its reason.
The moment execution completes, the post event review becomes available. This is not an approval; approval was taken before the event. Here the question answered is whether it was the right call.
Was it genuinely urgent, and was a request opened for the permanent fix. The assessment note is mandatory. The answer does not undo the request; it only goes on the record.
Who reviewed it, when and on what grounds sits on the request. An auditor can see how many emergency requests were reviewed from a single report.
The query, the business reason, the address the result will go to and the delivery method all sit on one request. The ticket number is validated against your format rule.
If the query touches a table marked critical, that is a finding and it sets the risk band. Missing pieces such as a row limit or a database context are stated here too.
The product asks the target server which columns the query will return, without reading a single row of data. Next to each column it states what will happen and which rule matched.
If a column is wanted in the clear, which column and why has to be written. The request is automatically routed into an extra approval step.
Access to a critical table added one step, an unrecognised delivery address a second and the unmasked column request a third. None of them were added by hand.
Once approved, only the requested column moves to open while the rest stay masked. The decision is not guessed at; it is read off the screen.
The masking result table states the decision for each column and the reason behind it. Against the column left open stands the name of the person who approved it.
The result file is password protected and the password is not shown without a stated reason. The viewing itself is written to the request history and the audit trail.
First name, surname, identity number, phone and IBAN come out masked. Only the column approved with a justification is open. Masking is not a promise made on screen; it is the file itself.
The catalogue works on column names. Deciding which column is sensitive therefore never requires anyone to see production data. Full and partial masking are defined separately.
Sign in, request, approval, execution, setting change and evidence download all sit in the same chain. The buttons above verify the chain and the sealed copy.
The question prove this record was not altered no longer rests on trusting the team that keeps it. How many records were checked is stated in the result.
The live version of each record is compared with its sealed copy in a separate database. The screen does not simply say green; if there is a difference worth looking at, it says so.
At intervals the digest of the chain up to that point is signed and stamped by an external timestamp authority. The record is thus tied to a date independent of the product itself.
Request identity, the segregation of duties assessment and the package seal are on the first page. If the roles were segregated it says so, and if they were not it says that too.
Masking settings, the number of active standards, the non skippable rules and the licence scope are frozen inside the file. Months later the decision is not explained with today's rule.
Does the recorded hash match the current one, which finding set the band, which columns were masked and which one went out in the clear and on whose approval.
The auditor uploads the manifest from the package they hold. The product states that the package is valid, which request it belongs to and who downloaded it and when.
The script that comes inside the package runs on a machine with no SQL Change Guard installed. The auditor recomputes the file digests, the signature and the keyless content chain themselves.
30 built in reports in five groups. Access, change, approval, exception and masking decisions, all filterable. Excel and PDF output sit next to every report.
If you read the "where it sits today" line at every step above, you have already asked the real question. What follows helps you answer it for your own organisation.
Six questions, computed in your browser, no email required. Not a sales call.
Measure yourself →One request's whole lifecycle in a single file. Real product output, not a mock-up.
Download Dossier.pdf →Ticketing, pipeline, monitoring and logs: what each keeps doing and what gets added.
See the table →Let us talk through your own script and your own rule set. Screen share, thirty minutes.
Book a call →If you would rather see every screen on one page, the gallery on the platform page holds all nineteen.