Trust and security

Separation between businesses is enforced by PostgreSQL itself, not by application code remembering to add a filter. Every table that carries a business identifier has row-level security enabled and FORCED. The distinction matters: enabling row-level security alone does not apply it to the table's owner, and this application connects to the database as the owner — so enabling without forcing would be decoration.

The reason this is enforced in the database rather than in code is that application filters are only as good as the last developer who remembered one. A missed WHERE clause in a single query is enough to show one company another company's ledger.

A check runs on every build that reads the live database and, for every table carrying a business identifier, asserts four things: that row-level security is on, that it is forced, that a policy actually references the current business, and that platform-wide support access can read but never write. There is no threshold and no sampling. One unprotected table fails the build.

Audit records are append-only: a database trigger refuses any UPDATE or DELETE against them, and the access policies refuse the connection. That stops the application from rewriting history.

It does not, by itself, stop somebody with full database credentials, who could disable the trigger, edit a row, and switch the trigger back on. So each audit row also carries a SHA-256 digest of its own contents and of the row before it, forming a chain. Altering any historical row changes its digest and breaks every link after it, which makes the alteration detectable rather than merely forbidden.

Being honest about the limit: a hash chain proves tampering happened. It does not prevent it, and it cannot recover the original text. Audit rows written before the chain was introduced sit outside it and are marked as such rather than quietly presented as chained.

When a period is closed, a database trigger refuses any transaction dated inside it. The refusal is on the document date, not the date the row was inserted — backdating is precisely the move the control exists to stop.

This is enforced at the database level for the same reason as the isolation above: a period close that only the user interface respects is not a period close. Reopening a period is possible, but it is a deliberate act by somebody permitted to do it, and it is recorded.

For a CA this is the difference between numbers that were signed off and numbers that were signed off and then quietly moved.

Support access to a customer workspace is called impersonation, and it is constrained by a policy held in one file that the banner, the server-side gate, the database checks and the tests all read from.

Access is read-only by default. Write access exists only where the customer has consented — either standing consent recorded by a workspace owner, revocable at any moment, or consent given by an admin for one specific incident.

Every session, in every mode, expires after thirty minutes. That is a hard ceiling applied on read as well as on write, so a session already in progress cannot outlive it. One support engineer may hold one session at a time.

Where no consent exists and the situation is urgent, an engineer may open a break-glass session. It is read-only, it is fifteen minutes, it requires a written justification, and the workspace's owners are notified immediately rather than in a monthly report. The reasoning was that a customer's inability to answer the phone should reduce what we may do, not increase it.

Some actions are refused even with full consent — changing roles, issuing invitations, and anything else that would outlive the session or that the customer could not undo themselves.

When you connect Ordence to another system, the credential you hand over is encrypted with AES-256-GCM before it reaches the database. What is stored is ciphertext, an initialisation vector, a masked display value, and the name of the key used — never the key itself, which is held in the deployment environment and not in the database.

Searchable fields use a keyed blind index rather than the plaintext, so a credential can be looked up without being stored in a readable form. Every read of a secret is written to an access log that no application role may delete.

Being precise about scope: this describes secrets held in the vault. It is not a claim that every field in the product is individually encrypted.

Pages are served with a Content-Security-Policy built per request around a fresh nonce. It contains no unsafe-inline in its script sources and it sets a base URI — the three ways a policy of this kind becomes decoration are each covered by a test that is phrased as the failure rather than the feature.

Session cookies and device-local preferences are the only things stored in your browser; the cookie banner describes that scope rather than a generic one.