Security Architecture and Integrations

The deployment model decides everything

SQL Change Guard runs inside your own network. It is not a cloud service. Connections to your managed databases are made by the application server in your own network, and your scripts and query results are not sent to any third party service. The product keeps its own records on your database server. The product does not send data out on its own; a query result goes only to an approved recipient, in an encrypted package, and approving the recipient address is the organisation's decision.

Outbound connections. The only outbound call switched on at installation is RFC 3161 timestamping: the shipped configuration points 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 not sent. In production the address should be repointed at the organisation's own authority, or the feature switched off with a single setting. The other connections (mail server, ticketing, identity provider, directory) ship switched off and their address is provided by the organisation; SIEM delivery does not start until the organisation defines an endpoint address. If one of them is a cloud service (Jira Cloud or Entra ID, for example), what reaches that service is limited to the job of the connection: the ticket number and note text, or the sign in flow.

Authentication and Session

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 (LDAPS or StartTLS). Password verification happens in the directory and the product stores no password. Roles come from directory groups. An account disabled in the directory also loses access here through a background sync.
Corporate sign in (SSO)	OpenID Connect (with PKCE) and SAML 2.0. The password never reaches the product; the identity provider's signed answer is verified. The role is assigned from the group in the identity provider; the system manager role is never granted by a mapping. Signing in with a local password while SSO is on is written as a separate event and goes to the SOC as an alarm. Details.
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.

Revoking a permission takes effect immediately

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.

Authorisation Model

Hiding a button in the interface is not a control. Every operation is authorised again on the server, independently of the interface.

Permission based access

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.

Segregation of duties

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. At installation all three are permissive: a requester may approve and execute their own request and an approver may execute; the Governance Setup Check screen shows each on its own line and you tighten them.

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 a separately named control change event, with old and new value, and, when settings approval (four eyes) is on, it goes to a second authorised person for approval; four eyes is off at installation. 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.

Four eyes on settings

With four eyes switched on, settings that could weaken a control (or, if you choose, all settings) 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.

Encryption and Secret Handling

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 ZIP	Data leaving production is delivered as an AES-256 encrypted ZIP package; the package password is stored in the database encrypted with AES-256-GCM. The package password is not emailed; the requester views it in the portal against a stated reason.
Audit records	SQL Server ledger	Records live in a SQL Server 2022 append-only ledger table; the database engine refuses updates and deletes for everyone. The ledger digest is taken every hour by default; where a signing key and an external output folder are configured, it is signed and written to the organisation's immutable store, so a difference shows in verification even if the database is rebuilt. If these two settings are not made, no external file is written and the Governance Readiness screen shows it.
Evidence file seal	SHA-256	The SHA-256 digest of every file in an exported evidence package is written into the manifest. The digest shows whether a file changed; where it came from is shown by the signature below.
Evidence package signature	RSA, SHA-256	Where a signing key is configured, the package manifest and the ledger digest files are signed asymmetrically (a 3072 bit key is recommended) and the public key needed to check them travels inside the package; that it is the right key is checked against the fingerprint the organisation publishes separately. 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.

How Production Data Is Handled

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.

Sensitive column detection

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 treated as sensitive when a set share of the values in a sample of the result matches a pattern. 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.

Unmasked access is a separate decision

Masked is the default. Unmasked data requires a written reason and an additional approval. The organisation can switch unmasked column requests off entirely; with that setting no unmasked request can be raised. The server definition sets the masking regime: the default strict regime uses both column names and data patterns, while the content only regime, which requires a written reason, ignores column names.

Download reasons are recorded

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.

Secrets do not leak into records

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.

Integrity of the Audit Trail

Audit records are kept in a single table in the product database, a SQL Server 2022 append-only ledger table. The database engine refuses updates and deletes on that table for everyone, the database administrator included. Records are written through a single procedure; that procedure, not the application, sets the event time, and the event commits in the same transaction as the work it describes. If the evidence cannot be written, the work is not done.

The product checks this write boundary every 15 minutes by default: the evidence table must have no trigger, the write procedure must match the published version, and the evidence schema must hold no unexpected object. If the boundary breaks, change operations stop and the event is recorded. The API and the Worker can connect to the database with separate, restricted accounts; the ledger itself keeps which account wrote each record.

The ledger lives inside the database, so on its own it is not enough: someone who rolls the database back to an older backup or edits the file directly could act against it too. That is why the ledger digest is taken every hour by default. Where a signing key and an external output folder are configured, the digest is signed with the organisation's RSA key and written as a file to the organisation's immutable store; if these two settings are not made at installation no external file is written and the Governance Readiness screen shows it. The API produces and signs the digest; the Worker only starts the cycle and has no access to the signing key. The auditor verifies a copy restored from backup in the organisation's own environment against those digests with SQL Server's own procedure; the backup does not leave the organisation. How the auditor does this is set out on a separate page.

Row changes in the product tables are also recorded by triggers: database login, host, application name, old and new value. This record is a lead; the evidence dossier looks at it to find who changed a field that disagrees with the ledger.

The evidence also leaves a copy on your own system. Audit events and ledger digest events can be streamed to your SOC collector over syslog (TLS, TCP, UDP) or to a file; on the marker based stream, if a delivery fails the next round resumes from the same place (over UDP a message too large for one packet can be lost, so TLS is recommended). You can narrow the scope but you cannot hide that you did: every change to the filter reaches the SOC as a separate event. Details.

An honest limit

No software can stop someone with full access to the server from doing anything at all. What the ledger gives is not immutability but detectability: a record altered or deleted after a digest was written out surfaces during verification. We state two limits plainly. First, the trust boundary is the application identity: someone holding the application account's password can write a consistent-looking event through the write procedure; the control against this is matching the independent monitoring records on the target (DAM or SQL Server Audit) with the execution windows. Second, that no digest file is deleted rests on the retention lock of the organisation's store; the product does not provide that lock itself. 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.

Integration	Connects to	What it does
Ticketing (ITSM)	ServiceNow, Jira, generic REST	Checks the ticket at save and at execution, stops on a closed or unapproved ticket and writes events back to the ticket as notes.
Corporate sign in (SSO)	OIDC: Entra ID, Keycloak, Okta SAML 2.0: AD FS, Entra ID, Keycloak	The password never reaches the product. The product role comes from the group in your identity provider.
Directory (LDAP) and second factor	Active Directory, standard LDAP directories	The password is checked in the directory, roles come from groups and an account disabled in the directory cannot sign in here either. A time based code can be enabled as a second factor.
SOC and SIEM	Syslog (TLS, TCP, UDP) and file CEF, LEEF, RFC 5424, JSON	Streams audit events over TLS or TCP; an event that cannot be delivered is not skipped and is retried on the next round. Narrowing the scope is allowed; hiding that you narrowed it from the SOC is not.

The ticketing, identity and directory connections ship switched off; SIEM delivery does not start until an endpoint address is defined. The Governance Setup Check screen shows the state of each. Turning them on is your decision.

Ticketing

The ticket was approved. Is the work that runs tied to that ticket?

The change advisory board (CAB) approves a ticket, but the script that will run is not in it, and the record may have been closed or withdrawn after approval. The product closes that gap at two points.

1. When the request is saved

The number is looked up in your ticketing system. If the record does not exist, is of the wrong type or is already closed, the request is not saved. There are three modes: off, warn and block. The default is block.

2. At the moment of execution

The same ticket is asked again. No cache is used, because approval may have been withdrawn after the job was queued. If the change record is not in an executable state, the work does not start. The request does not die: it stays approved and runs again once the record is ready.

Each request type maps to its record in the ticketing system

Request in the product	Record in the ticketing system	Rule
Change	Change record	Must exist, be of the right type and be in an executable state. Enforcing the planned window is optional.
Query result (data extraction)	Service request	Must exist, be of the right type and not be closed. Asking for data is not a change, so no CAB approval is required.
Emergency request	Incident record	Emergency approval is usually given afterwards, so CAB approval is not required. A closed or missing change record still stops the work; the incident number check is in warn mode by default and can be set to block. Every emergency execution that passes is written down as an exception.
Rollback	The source change's record	Exempt from the gate: the source record may already be closed, and locking a rollback would block the repair of a broken production system. The exemption is recorded.

The write direction: what the product does shows up in the ticket

When a request is opened, approved, rejected, scheduled, executed or fails, a short note is added to the ticket (a work note in ServiceNow, a comment in Jira). The note text is fixed and plain: it contains no script text, no result data and no password. If the ticketing system cannot be reached, the note is not lost; the next round resumes from the same place. A note that cannot be delivered for a long time raises a single alert event that goes to the SOC.

What happens when the ticketing system is off or unreachable

While it is off the request checks the ticket number against the format rule only. The integration ships switched off.
When it cannot be reached you choose one of two options: stop the work, or let it continue while the failed check is recorded and an alarm goes to the SOC. The default is the second. An unreachable ticketing system does not lock an emergency request.
For a scheduled job, cases where the gate will certainly stop it at run time are caught while you schedule it, so you do not learn about a stalled night job from an email in the morning.

What it shows the auditor

The record the product saw at that moment (state, type, approval field) is frozen into the audit trail as it was. Even if the record in the ticketing system changes later, the answer to "what was seen that day" is not lost. A ticket that breaks the rule, a record that could not be verified, an execution stopped at the gate or passed without CAB approval, and notes that could not be delivered are written under their own event names and reach the SOC regardless of the filter.

Connectors and setup

ServiceNow: change, incident and service request records through the Table API. Jira: REST v2 and v3; email and API token in the cloud, a personal access token on a data center installation. Generic REST: the lookup and note addresses are defined as templates, so another ticketing system can be used too. Connection settings live in the application settings file, secrets stay on the API server only, and certificate validation is on by default. On the Settings > ITSM screen "Test connection" looks up a real record. The connectors were tested end to end against a lab simulator that imitates the real response shapes of these three systems; we verify them together with you against your own instance at first setup.

Corporate sign in

The password never arrives here, the role comes from the group

A "Sign in with your corporate account" button appears on the sign in screen. The user types the password and the second step on the identity provider's own page; the product only verifies the signed answer.

Two protocols

OpenID Connect (authorization code flow with PKCE): Microsoft Entra ID, Keycloak, Okta. SAML 2.0 (HTTP-POST): AD FS, Microsoft Entra ID, Keycloak. More than one provider can be defined at once; a misconfigured provider is not used and does not affect the others or local sign in.

The role is assigned from the group

Groups in your identity provider are mapped to product roles. If several groups match, the highest role wins. If none matches, the person does not get in. The system manager role is never granted by a mapping; it is always assigned deliberately inside the product. An organisation that prefers to manage roles by hand can turn the mapping off.

A leaver is closed in one place

When the account is closed in your identity system, no new session can be opened. When a user's sessions are closed inside the product, the access token they still hold is rejected on the next request; it does not have to wait for its expiry.

The emergency sign in stays visible

If someone signs in with a local password while corporate sign in is on, it is written as a separate event and goes to the SOC as an alarm. The auditor sees "who signed in locally while SSO was on" on a single line.

Setup and verification status

Providers are defined in the application settings file; the API is restarted to apply a change. Automatic account creation on first sign in, session length and sign out from the identity provider are configurable. Addresses and SAML metadata are shown on the setup screen in copyable form. OpenID Connect and SAML were verified end to end against a local Keycloak and with automated tests. Setup steps for Entra ID and AD FS are ready and they use the same standard protocols; we verify them with you against your own tenant at first setup.

Directory and second factor

Your directory stays the source of identity

If you have no identity provider, or prefer to talk to the directory directly, Active Directory and standard LDAP directories are supported. The connection was tested end to end, with automated tests, against a test directory over LDAPS and StartTLS; we verify it with your Active Directory at first installation.

The password is checked in the directory. It is not kept in the product. The connection is encrypted with LDAPS or StartTLS; certificate validation is skipped only if you explicitly allow it. An empty password is never sent to the directory, because on many directories an empty password bind counts as an anonymous sign in and succeeds.
Roles come from groups. Nested groups are read; a read error never lowers a role, because a partly read list would quietly cut someone's access. Mapping can use the full name or the short name.
An account disabled in the directory cannot sign in here either. A background job sets accounts that are disabled or missing in the directory to no access. The last system manager is never closed this way. If the sync hits its mass disable limit or cannot reach the directory, it stops without changing anything and that goes to the SOC as an alarm.
Second factor. A time based one time code (authenticator app) is supported. "Second factor on" is not the same as "everyone uses it": mandatory enrolment is a separate setting. While it is on, the session of a user who has not enrolled works only for the enrolment step and for nothing else.

SOC and SIEM

The evidence sits in two places: in the product and in your SOC

The audit trail already sits in a tamper evident record. The SOC integration streams a copy of it into your own security system, in your own format. The decision is made in the product and your security team also sees the record on its own platform; it does not have to take the product's record on trust.

Four streams, two mechanisms

The audit (Audit) and ledger digest (Anchor) streams are read from the audit record table and advance with a "sent up to here" marker. If delivery fails the marker does not move and the next round resumes from the same place: nothing is lost. (UDP is the exception: it drops a message that does not fit one packet and does not say so, which is why TLS is recommended.) The application log goes through an in memory queue and, when the queue is full, the oldest record is dropped: loss is possible on this stream, and deliberately so. The heartbeat is a liveness signal.

Five formats, two transports: syslog and file

Formats: RFC 5424 with JSON (default), CEF (ArcSight), LEEF (QRadar), plain JSON and RFC 5424 structured data. Transports: syslog over TLS (recommended), TCP and UDP, plus a line by line JSON file for organisations with no collector. More than one endpoint can be defined and each keeps its own marker. On TLS, if a server certificate thumbprint is set, a connection that does not match is refused and the product never falls back silently to plain text.

You can narrow the scope, you cannot hide it

SIEM licences are priced by volume, so you choose which streams and which severity threshold go out. But five classes go out whatever the threshold: actions that change or loosen controls (identity and permission changes included), emergency actions and ticketing exceptions, denied permissions and failed sign ins, ledger digest events (a digest published or failed, a restore), and the evidence write boundary breaking or being restored. Every change to the filter also reaches the SOC as a separate announcement.

What leaves, and what does not

Only permitted fields enter a message; any field that is not recognised does not go. Facts that help classify an event, such as which server, which risk band and how many statements, go out; which rows came back does not. Script text is not sent to the SOC by default; sending it is a separate setting.

The Diagnostics, SOC and SIEM screen: defined endpoints, target, format, streams, threshold, lag and time of the last delivery — **Endpoint health** For each endpoint: target, format, streams, threshold, lag and time of the last delivery.

Two syslog lines arriving at the SOC collector: a Siem.FilterChanged event showing which streams the filter closed and reopened — **The announcement of narrowing** When a stream is removed from the filter, a Siem.FilterChanged event reaches the collector: old and new value together.

Topic	How it works
Where it is configured	Connection details (address, protocol, secrets) live in the application settings file. Filter and policy decisions are parameters on the Settings screen; a change is written to the audit trail and, if settings approval is on, goes through four eyes approval.
Setup check	The Governance Setup Check screen lists whether each integration is on or off, and any configuration errors. A faulty setting is never used silently.
Setup time	Step by step setup and the integration settings are described in the Installation and Operations document. The prerequisites list says in advance which accounts, certificates and ports are needed.

Roadmap: Not Implemented Yet

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.

Recording the statement that dynamic SQL runs. If a script builds and executes text at runtime (EXEC, sp_executesql) the product flags it as a high risk finding, but it cannot see or record the statement that actually runs. This limit follows from parsing itself.
Service accounts and access keys for delivery pipelines. Only people can sign in to the product today. A separate account and a time limited access key for Jenkins, Azure DevOps, GitLab CI and GitHub Actions come first on the roadmap.
Opening tickets and user provisioning. The product writes notes to the ticketing system but does not open tickets or change their state. It offers no automatic user provisioning protocol (SCIM) from the identity provider; the account is created at first sign in.
The product's own record store is SQL Server only. This is not a preference but today's limit: PostgreSQL and Oracle are not supported as the record store and are not offered as an option. The ledger table that holds the audit records therefore requires SQL Server 2022. Managed targets are unaffected: SQL Server, PostgreSQL and Oracle are all supported as targets today, each parsed with its own grammar and executed through its own connection layer.
Independent security certification. The product holds no certification and we do not claim otherwise. In return we are fully open to your own security review: architecture, data flow and control list are shared.