Frequently asked questions
Most of the answers are not about a product. They are about where the organisation stands today.
Jira carries the process, Jenkins automates delivery. Both do the right job. Neither one assesses the risk of a database operation, decides whose responsibility that risk is under the organisation's own rule, or produces evidence of the decision.
The governance layer does not replace these tools. It connects the decisions they produce into a single decision and evidence model.
How that connection works today: through the ticket number. The product looks the number up in ServiceNow or Jira, asks again at the moment of execution and writes events back to the ticket as notes. While the connector is off, the number's format rule is checked. The product does not open tickets and does not change a ticket's state itself. Details.
Yes. There is a connector for ServiceNow (Table API) and Jira (REST v2 and v3); another ticketing system can be defined through generic REST. The product looks the ticket number up when the request is saved and again at execution, stops the work on a closed or unapproved record and writes events back to the ticket as notes. The connector ships switched off. The product does not open tickets and does not change a ticket's state itself. The connectors were tested end to end against a lab simulator; we verify them with you against your own instance at first setup.
Yes. OpenID Connect and SAML 2.0 are supported; the flows were tested end to end with Keycloak, and we verify Entra ID and AD FS with your tenant at first installation. The user types the password on the identity provider's own page and the password never reaches the product. The product role is assigned from the group in the identity provider; the system manager role is never granted by a mapping. For organisations with no identity provider there are also an LDAP directory and a time based second factor.
Yes. The audit, ledger digest, application log and heartbeat streams go out over syslog (TLS, TCP, UDP) or to a file. Formats are RFC 5424 with JSON, CEF, LEEF, plain JSON and RFC 5424 structured data. On the audit and ledger digest streams a failed delivery is not skipped; the next round resumes from the same place. You can narrow the scope but you cannot hide that you did: every change to the filter reaches the SOC as a separate event.
The opposite. Governance makes visible and provable the work the team already does correctly.
Today the team makes the right call, but no trace of the call remains. When questions follow an incident, that leaves the team exposed.
Not much, if the control works by risk. What slows you down today is that every item gets the same weight of control.
When the organisation's rule determines the risk, the policy can reduce the approval steps for low risk work, and high risk work gets the attention it deserves.
SQL Server, PostgreSQL and Oracle. What an operation actually does is analysed in each platform's own language, while the rules are applied through the same governance model.
The rule engine parses the script with a real grammar and works on sentence structure. That is why it catches the cases defined in the rule catalogue that can be read from the script itself: an UPDATE without a filter, a DROP on a critical object, or a naming convention. The statement that dynamic SQL builds at runtime cannot be read from the script; the product flags it as a high risk finding.
Whether a query uses an indexed column, however, cannot be read from the script; it requires looking at the target database catalogue. That check is not in the scope of the rule engine today and belongs to database monitoring tools.
It is installed in your own environment. Access to your databases stays inside your network and the product does not send data out on its own; a query result goes only to an approved recipient, in an encrypted package. The only outbound call switched on at installation is timestamping, which sends only a file digest.
Mature processes are exactly who this is for. The question is not whether the process exists, but whether it runs independently of specific people.
If two different people cannot assess the same work with the same outcome, the process exists but has not yet become institutional.
Day to day, the database and application teams. Its decisions and reports are used by change management, information security and internal audit.
Ownership being defined in one place matters more than the number of users.
Because the record is not assembled after the event. It forms with the event and carries its own integrity. The auditor can verify for themselves that it was not altered later.
The value of evidence comes less from its content than from who did not prepare it.
Concretely: where a signing key is configured, the delivered zip holds an identity file listing the SHA-256 digest of every file, the RSA signature over it, and the public key that checks the signature. The steps and the commands are written out on the evidence verification page.
Yes, and the design is built around it. The package signatures and file digests are verified on the auditor's own machine with PowerShell or openssl; nothing connects to the product and nothing goes over the network. This requires a signing key and an external digest store to be configured; on an unsigned package the verification script reports UNSIGNED.
The records themselves live in a SQL Server ledger table: on a copy restored from backup in the organisation's own environment, the auditor runs SQL Server's own procedure against the signed ledger digests collected from the organisation's immutable store, or watches it being run. The backup does not leave the organisation. Every step is written out in the Auditor Kit document, available on request.
A signature shows where a package came from, not when. The date is written from the organisation's own server clock, and that clock can be changed. We say so plainly.
There are two answers. The first is the ledger: SQL Server itself keeps the commit time of every record, and the ledger digest is taken every hour by default and, where a signing key and an external output folder are configured, signed and written to the organisation's immutable store; a later change to a record covered by a digest shows up as a difference in verification; a backdated record that is added later shows up through the gap between its commit time and its event time. The second is RFC 3161 timestamping: the digest of the evidence dossier is sent to a timestamp authority and the response is placed in the package. Only the digest leaves; the record itself is not sent. The shipped configuration has this on and points at a free public authority; in production it should be repointed at the organisation's own authority or switched off with a single setting. When it is off, no network call is made at all.
By seeing which level the organisation is at today. A six question self assessment shows which area is the weakest link.
In governance, the overall level equals the weakest link.
Each of these tools is mature in its own area. Your ticketing system carries the corporate process, your pipeline automates delivery, your monitoring tool sees the event.
A product that tried to replace them would be a weaker copy in every area. Any organisation would rightly refuse it.
What is missing is not a tool. It is a single place where the decisions, rules and evidence these tools produce come together.
| Tool family | Keeps doing | What the governance layer adds |
|---|---|---|
| ITSM Jira, ServiceNow |
The corporate change process, approval chain and ticket lifecycle | Linking the ticket to the script run through the product, and the rule the decision rested on |
| CI/CD Jenkins, Azure DevOps, GitHub Actions, Octopus |
Build, test and delivery automation | Letting work that reaches production outside the pipeline be declared and enter the same decision model |
| Schema versioning Liquibase, Flyway, Redgate |
Versioning and applying schema changes | Who decided this version could run in production, and under which risk assessment |
| SIEM QRadar, Splunk |
Event collection, correlation and alerting | The execution window, session tag and expected account data the SIEM needs to tie an event to an approved request; the organisation writes the matching rule |
| Database activity monitoring Guardium |
Monitoring access and detecting suspicious behaviour | The request, reason and approval behind the access, and the masking decision on what was delivered |
| Server management ManageEngine, Quest |
Server inventory, health and performance management | Tying a change on the server to a decision and a rule |
| Log management and archiving Graylog, Elastic, WORM storage |
Collecting logs, storing them and managing retention | Letting the record be verified by the auditor without connecting to the product: signed packages, a public key and SQL Server ledger verification on a backup copy |
The ticket number is a binding field on the request. Its format is defined, it can be made mandatory, and it travels with the record. Your ticketing system stays where it is.
Your pipeline keeps running. There is no direct pipeline connection today (it is on the roadmap); for work that goes through the product the rule works by risk, and your policy decides how many approval steps a low risk change passes.
The audit record carries its own integrity and can be exported. Your log platform keeps seeing the event; this record is what gives that event evidential value.
Let us be precise, because the word "integration" means different things in different organisations. With the ticketing connector on, the product looks up the ticket number on the request in ServiceNow or Jira: does the record exist, is it of the right type, is it closed. It asks again at the moment of execution, does not start the work on an unapproved or closed record, and writes events back to the ticket as notes. With the connector off, the connection is only the ticket number field: you define the format rule and a request that does not match it is refused.
What does not exist today: the product does not open tickets and does not change a ticket's state itself; it only writes notes. There is no connection to delivery pipelines (Jenkins, Azure DevOps, GitLab CI, GitHub Actions). On identity there is the directory (LDAP) and corporate sign in (OpenID Connect, SAML 2.0). The audit trail can be streamed to your SOC platform over syslog or to a file.
How each connection works is on the integrations page, and what comes next is on the roadmap page. Saying what a product cannot do today is more useful than describing what it will do tomorrow.
This is a working list; it gives no dates.
Everything below works today and can be seen on the product screens. It is in the product, not on the roadmap.
The ticketing, identity and SOC connections are in the product. The next gap is the pipelines that originate changes: Jenkins, Azure DevOps, GitLab CI and GitHub Actions.
Today: Only people can sign in to the product: a local account, a directory account or a corporate account. For a pipeline to use the product, someone's password would have to sit in the pipeline settings, and that cannot work once corporate sign in or a second factor is on. So today a pipeline cannot use the product on its own.
Planned design: A separate service account for each pipeline; an access key that cannot sign in on screen and is time limited, narrow in scope and revocable; a separate versioned API and a single file command line tool. A pipeline does four things: analyse without opening a record, submit a request, wait for the result and trigger execution only where it is allowed. A request from a pipeline passes the same gates as one from the screen: ticket verification, risk, standards and the approval flow. By default a pipeline cannot execute in production; it submits and waits, and the product does the execution. The request is opened in the name of the person who triggered the pipeline, and segregation of duties applies to that person.
Status: The analysis is complete; development has not started. Details may change before development begins.
The reason this item comes first: organisations' security requirement lists often ask for service accounts and access keys, and today we do not meet that item. We do not hide it.
We make no promises about these. They enter the queue when an organisation asks for one in a contract or when enough demand appears.
| Item | When it enters the queue |
|---|---|
| Auditor portal: a separate, simplified interface just for auditors | The auditor role, the Verify Evidence screen and the period package are in the product today; a separate portal is planned alongside an organisation's audit calendar |
| Recording the origin of a script: a person, an assistant or an automated generator | The rule keeps looking at the text; the origin is kept only for the record and for reporting |
| A database client add-on (SSMS, DBeaver and similar) | When an organisation asks for it in a contract, and for a single client only |
| A fourth database engine | On request. Adding an engine means writing a real grammar parser and is not taken lightly |
The most useful part of a roadmap is where it says why some things are not on it.
Watching live traffic to catch unrecorded work belongs to database activity monitoring products, and those tools do it better than we would. We do not enter that space. We produce the decision and the evidence before execution; when your monitor's records are matched with ours, a change with no trace on our side shows up as an exception. The two layers verify each other.
Products that copy an entire database and mask it in bulk are a separate category. We mask the result of a query: the set that leaves production in answer to one request. If you are looking for a masked copy to fill a test environment, we are not the product you want, and we would rather say so up front.
How long a script will hold a lock in production depends on the data volume and concurrent load at that moment and cannot be predicted reliably in advance. What we do is different: we derive the risk from the content, prepare the rollback script in advance and record the affected row count after execution.