Sovereign by construction
Where the data rests, what executes beside it, and what happens to the record if the vendor disappears
Every platform in the compliance-automation category is software as a service, in one vendor’s cloud, in one set of regions, with one tenancy model. For a great many organisations that is a fine answer. For a bank under a central bank’s outsourcing rules, a defence supplier, a ministry or a group whose shareholder agreement names a country, it ends the evaluation. This paper is about the other architecture.
What this paper establishes
- The same build runs in our hosted environment, in a customer’s own cloud account, or on a network with no route to the internet at all.
- Tenant isolation enforced by the database rather than by careful programming, and verified under the application’s own role on the customer’s instance.
- No third-party origin executes inside a signed-in session — no analytics, no tag manager, no chat widget, no font service.
There is a question that decides a procurement before the product has been seen at all, and it is never on the feature comparison. Where does the evidence rest?
Not the application. The evidence: the penetration test report naming unpatched hosts, the incident file with the regulator’s correspondence in it, the access review listing every privileged account, the breach assessment that decided not to notify. That material is the most sensitive collection an organisation holds about its own weaknesses, and a compliance platform is where all of it ends up in one place.
Four questions a residency claim has to answer
“We have a region in your country” answers one of them. The other three are usually left for the contract to imply.
- Where does the data restNot where the company is incorporated, and not where the support team sits. Which physical infrastructure holds the records and the files.
- What executes beside itWhich third-party code runs inside a signed-in session, and which external services a page reaches while an administrator is looking at customer evidence.
- Who can see it without askingWhether the vendor’s own staff can read a workspace, and whether the isolation between workspaces is enforced by the database or by application code a person can get wrong.
- What happens if the vendor stopsWhether the organisation holds a running copy and a readable export, or a login to something that will one day stop answering.
One instance, installable with no internet
Conscious runs as a single application with a PostgreSQL database behind it. The same build runs in our hosted environment, in a customer’s own data centre, in their own cloud account in their own region, or on a network with no route to the internet at all.
The modesty of the hardware is part of the claim. The load figures published with this library were measured on a 4 vCPU, 16 GB instance: 50 concurrent readers, 2,634 requests, none failed, 95th percentile 201 ms. An organisation does not need a platform team to run this, which is what makes the air-gapped option real rather than theoretical.
| Hosted by us | Your cloud account | Your data centre, no internet | |
|---|---|---|---|
| Where records rest | Our region | Your region, your account | Your building |
| Who operates it | Us | You, with our runbook | You, with our runbook |
| Model calls leave the network | Only if enabled | Only if enabled | Never |
| Upgrades | We apply them | You apply them | You apply them from media |
| Our staff can read your workspace | No | No | No access at all |
| Suitable for a regulator who names a country | Depends on the region | Yes | Yes |
Isolation enforced by the database, not by careful programming
Multi-tenancy is where platforms leak. The usual construction is a tenant identifier on every table and a discipline that every query includes it. That discipline holds until the one query that does not, which is how cross-tenant disclosures happen in products built by competent teams.
In Conscious the database enforces it. Every table holding customer data has row-level security forced on, so a query that forgets the tenant returns nothing rather than returning another organisation’s evidence. The isolation is verified as one of the suites a customer can run on their own instance, under the application’s own role rather than under an administrative one, because a check run as a superuser proves nothing.
Beside it sits a second decision with the same character. The console’s content security policy permits scripts from the application itself and from nowhere else. No analytics script, no tag manager, no chat widget, no font service executes inside a session that is holding another organisation’s compliance evidence. Every origin added to that policy would be an origin able to execute against a signed-in session, so the list stays empty.
A record the organisation keeps
The hardest question on the list is the fourth one, and almost no one in this category answers it: what does the organisation still hold if the relationship ends?
Three things, by construction. A running instance, if it is self-hosted, which continues to work with no licence call home. The records as real spreadsheets and documents rather than as a proprietary archive, exported by the organisation at any time. And the hash-chained audit record, verifiable by the organisation’s own auditor without the vendor’s cooperation, which is the only form of audit record that is worth anything after a vendor relationship has soured.
Backups are the operational half of the same question. They run nightly as two archives, the records and the evidence files those records describe, and the restore is rehearsed weekly into a scratch database with row counts compared and every evidence file hashed against the digest its record carries. An archive that fails is deleted and the job ends in failure. Off-site copies are configured per customer, because a second copy of customer data in another country is a regulatory decision that belongs to the customer and not to us.
What the organisation operates, and what it does not
A self-hosted instance is deliberately small to run. The platform is one application and a database, the upgrade rolls itself back automatically if a release fails its health checks, the backup and its restore rehearsal are scheduled jobs that report, and the health check runs every few minutes and alerts on silence as well as on failure.
- Upgrades run on the organisation’s schedule rather than on ours, which is what a change-managed environment requires in the first place.
- Backups and the weekly restore rehearsal run on the organisation’s own infrastructure, so the evidence never leaves it.
- Certificates, DNS and the perimeter stay with the team that already owns them.
- The machine layer points at a model the organisation chooses, inside its own network if it prefers — and switching it off leaves every register, assessment, export and audit function working.
For a bank, a ministry or a defence supplier, that list is a normal week and the residency answer is worth more than the convenience of another company running it. For an organisation that would rather not run anything, the same build runs as our hosted instance with no change to the product.
How to test a residency claim in any evaluation
- Ask for the list of third-party origins that execute inside a signed-in session. A product with an empty list will say so in one sentence.
- Ask whether tenant isolation is enforced by the database or by application code, and ask to see the check run as the application’s own role.
- Ask whether any employee of the vendor can read your workspace, and what record is made when they do.
- Ask what you hold if you stop paying: a running instance, an export, a verifiable record, or a login.
- Ask when the restore was last rehearsed, what it verified, and what happened the last time it failed.
- Ask whether the AI layer can be switched off entirely, and what stops working when it is.
Those six are answerable in a single meeting by any vendor who has made the decisions. A vendor who needs to come back to you on the first two has not made them.
Sources
- 1Isolation. Row-level security is forced on every table holding customer data, and the isolation suite runs as the application’s own role on a customer’s instance rather than as an administrative role.
- 2Content security policy. The console permits scripts from the application origin only. No third-party origin executes inside a signed-in session.
- 3Measured load. 50 concurrent readers, 2,634 requests, no failures, p95 201 ms and p99 380 ms on 11 September 2026, on a 4 vCPU, 16 GB instance. The same script produces a customer’s own figures on their own instance.
- 4Backups and restore. Two archives nightly with a weekly restore rehearsal into a scratch database: row counts compared, every evidence file restored and hashed against the digest its record carries, and a failing archive deleted with the job ending in failure.
About Conscious
Conscious is an independent assurance platform for organisations that answer to more than one authority. It carries 34 privacy regimes with their own transfer rules, breach clocks and subject rights, and 56 control frameworks, 16 of them at the authority’s own wording. Evidence, judgements and approvals sit in one hash-chained record, agents propose and named people decide, and the same instance can run in a customer’s own data centre.
Every figure Conscious publishes is measured from the running product and held to it by a test that fails the build when a document and the catalogue disagree. The verification suites run on the customer’s own instance rather than on ours, the audit record is verifiable by the customer’s own auditor, and the load figures come with the hardware printed beside them. Ask any vendor for the same and compare what comes back.
Put the same questions to us and to the platform you are already paying for. The assessment at consciousgrc.com/assess needs no call and no account, and it prints a record you keep whether or not you ever speak to us.