SQL Change Guard is a Database Operations Governance platform that governs database changes and production data access across SQL Server, PostgreSQL and Oracle. This page describes only the security controls implemented in the product today; roadmap items are in a separate section and clearly marked. Your security team can use this page as a question list.
SQL Change Guard runs inside your own network. It is not a cloud service. Connections to your managed databases never leave your network, and your scripts and query results are never sent to any external service. The product keeps its own records on your database server. This closes the first question in any security review: the data does not leave the organisation.
The one outbound connection. The configuration that ships with the product has RFC 3161 timestamping on, pointing at a free public authority, so an installation works end to end on day one. The only thing that call sends out is a SHA-256 digest; scripts, query results and record contents are never sent under any circumstances. In production the address should be repointed at the organisation's own authority, or the feature switched off with a single setting. With it off, the product makes no outbound call at all.
| Control | How it works today |
|---|---|
| Local account passwords | Hashed with BCrypt. Passwords are never stored in a reversible form, so even someone with database access cannot read them. |
| Directory integration | Can bind to your corporate directory over LDAP. Password verification then happens in the directory and no password is held in the product. |
| Multi factor authentication | Time based one time codes are supported and switched on for the organisation. Enrolment can also be made mandatory: with that setting on, a user who has not enrolled can sign in but the session is good for the setup step alone and nothing else runs. The rule is enforced on the server. How many users have enrolled is shown as a ratio on the diagnostics screen. |
| Session tokens | A short lived access token with a separate refresh token. Refresh tokens can be revoked, so all sessions for a user can be ended immediately. |
| Attempt limiting | Failed sign in attempts are counted and the account locks past a threshold. The application interface also applies request rate limiting. |
| Forced password change | Accounts created by an administrator must change their password at first sign in and can do nothing else until they do. |
When a user's permission is removed, the operation is refused even if their existing token is still valid. The check reads the current state in the database at the moment of the request rather than trusting what the token carries. This detail matters: in many systems a permission change only takes effect at the next sign in, and the interval between is an exposure.
Hiding a button in the interface is not a control. Every operation is authorised again on the server, independently of the interface.
Access is read from permissions rather than role names. Roles are bundles of permissions; what a user can do is decided by the permissions they hold, not by what their role is called. This lets an organisation build its own role structure.
There are three separate settings: whether a requester may approve their own request, whether an approver may execute, and whether the same person may close a second step in a multi step approval. All three can be switched by the organisation, and we do not present any of them as unchangeable.
The control is not in the setting but in how it can be changed. These three are classified as control settings: changing them is not an ordinary settings update but an event of weakening a control, and it goes to a second authorised person for approval. That classification list deliberately lives in code rather than in the database; otherwise someone could first remove an entry from the list and then switch the protection off unapproved.
The state of the setting at the time of the request is frozen onto that request, so a later relaxation does not affect past decisions. A blocked approval attempt is recorded as well: what proves a control actually operates is the refusals it produces.
Settings that could weaken a control cannot be changed by one person. The change is held as a separate record, the live setting is untouched, and it is applied only when a second authorised person approves.
| What | Method | Why this method |
|---|---|---|
| User passwords | BCrypt | Data that never needs to be reversed is hashed rather than encrypted. The algorithm is deliberately slow, which makes brute force expensive. |
| Server connection passwords | AES-256-GCM | These have to be decrypted to be used, so they are encrypted rather than hashed. GCM gives both confidentiality and integrity: if the ciphertext is tampered with, decryption fails. |
| Query result delivery package | AES-256-GCM | Data leaving production is delivered as an encrypted package. The package password is not emailed; the requester views it in the portal against a stated reason. |
| Audit record chain | HMAC-SHA256 | Each record carries the digest of the one before it and the chain is signed with a keyed digest. Because the key lives outside the database, even someone with full database access cannot recompute the chain. |
| Evidence file seal | SHA-256 | The contents of an exported evidence package are sealed with a single digest. An auditor can independently verify that the file they hold is the file that was produced. |
| Evidence package signature | RSA 3072, SHA-256 | The package manifest is signed asymmetrically and the public key needed to check it travels inside the package. The verifier never needs the private key, so an auditor can check the signature on their own machine without asking the organisation for any secret. Steps and commands. |
Encryption keys are held in the application configuration and fall under your own key management discipline. The key is set by you; there is no key embedded in the product. Existing encrypted values must be re encrypted before a key is rotated, and the installation document covers this separately.
On the change side the product does not read data. Data is only seen in the production query request flow, and that flow is controlled end to end.
A column name alone is not treated as sufficient. Content is assessed as well, and fields such as identity numbers, card numbers and IBANs are confirmed with checksum validation. Not every eleven digit number is treated as an identity number, and a column whose name gives nothing away is not missed.
Masked is the default. Unmasked data requires a written reason and an additional approval. An organisation can enforce a masked only regime per server, and under it an unmasked request cannot be raised at all.
Downloading the result is a separate event and is recorded with its reason. The answer to who reached the data, when and why sits on the request itself.
Password style fields are masked inside the payload written to the audit record. When a settings change is tracked, the secret that changed is not written into the trail.
The audit trail has three independent layers and each answers a different question. Application events are signed with a keyed digest chain. A full row copy of those records is written to a separate database, so the copy survives even if the original is deleted. Write operations on the database side are recorded separately by triggers.
Chain integrity can be verified from inside the product. If a record is deleted or altered, verification shows exactly where the chain breaks. The same verification can be run against the copy in the separate database.
Those three layers share one weakness: all of them sit on the organisation's own servers. Someone holding every key could rewrite the past, recompute the chain, and the in product verification would report it as intact. The anchor closes that gap. Every day the product produces a signed anchor carrying the digest of the last record at that moment, and the organisation delivers those anchors to the auditor on a schedule. The old anchor in the auditor's hands is now somewhere the organisation cannot reach, and it can be compared against today's records. The product runs the same comparison daily itself and writes the outcome into the signed manifest of the anchor package. How an auditor verifies this is set out on a separate page.
No software can stop someone with full database access from deleting records. What a signed chain gives is not immutability but detectability: a deleted or altered record surfaces during verification. The copy in a separate database and the database triggers strengthen that, because clearing the trail completely would require simultaneous action in three separate places. An anchor already delivered to the auditor is somewhere the organisation cannot reach at all, and no action inside the product can take it back. We do not promise more than this.
The full audit model and the evidence package handed to an auditor are covered on the audit trail and evidence page.
The following are not in the product today. Do not base your evaluation on them; they are listed here so you know what to ask about.
Bring your own control list. We will demonstrate the items that have an answer and say plainly which ones do not.
Request a demo →Related pages: compliance and control mapping, audit trail and evidence, production database access control.