Each flow opens with a short 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 save blocking finding is present, such as an UPDATE without a WHERE clause, the request cannot be saved and no confirmation lets it through. For a high tier finding that does not block, 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.
Because approvers may not execute in this installation, the person who approves cannot execute; at installation this setting is permissive by default. 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.
Because this installation makes the incident number mandatory, 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.
Because self execution is switched off in this installation, 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 and evidence download are written to a SQL Server append-only ledger table. The database engine refuses to alter or delete these records for everyone. The ledger digest taken every hour also shows up in the list as an event.
Whether the evidence table really is a ledger, whether the write boundary is intact and whether the latest digest was taken on time and written to the organisation's external store are shown in one window. The screen does not say "verified"; it says verification is done on the auditor's copy.
Request identity, the segregation of duties assessment and the package seal are on the first page. If the roles were segregated it says so; if the organisation setting did not enforce segregation, it says that too.
Server settings, approval rules and the ticket requirement are frozen inside the file. Months later the decision is not explained with today's rule.
Does the recorded digest match the script that ran, which finding set the band, was a non skippable rule triggered. All on the same page.
The session behind each decision is frozen at the moment of the decision. Exceptions are not hidden. The evidence state names the ledger digest file in the external store that covers the request's last record.
While the file is produced, every field read from the tables is compared with its state in the ledger: PASS, MISMATCH, MISSING, UNEXPECTED. In this sample all 116 fields match and the ledger verification passes up to the external digest.
The time of every event is compared with its commit time in the ledger, and the database account that wrote it is shown. Only the product's API and Worker accounts appear here; any other account would be a red exception.
The auditor supplies the manifest of the package they hold. The product states that the package is valid, which request it belongs to and who downloaded it and when. Even a single character difference raises a warning.
The script inside the package checks the file digests and the signature and prints the public key fingerprint. The ledger digest file's signature is checked with openssl and the ledger itself with SQL Server's sp_verify_database_ledger procedure. This screen is real output from the demo environment; the auditor runs the same steps on a copy restored in the organisation's environment.
34 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.