How we handle the things you are trusting us with.
A security product should be able to say exactly what it does with your data, what it refuses to do, and what it cannot promise. Everything on this page is implemented, not planned.
Your user store is read, never written.
This is the one property everything else is built around, so it is not left to a configuration checkbox.
- Read-only by default in code
- The storage provider ships with writes disabled, and exactly one literal configuration value can ever enable them. A component created before that setting existed stays read-only rather than defaulting open.
- Asserted by a test, not a promise
- An automated suite fails the build if the write gate can be opened by default, and checks that both configuration keys are actually declared — the identity provider silently drops any key a factory does not list.
Sealed, with a way back out.
And two rotations that keep them recoverable.
- Encrypted at rest
- Tenant credentials are sealed through a single write choke point, so a value cannot reach the database unsealed by some path that forgot. Unsealing with a wrong or missing key raises rather than returning something plausible.
- Both rotations are staged
- The key-encryption key and each tenant signing key rotate in explicit phases — stage, distribute, promote, retire. Promotion refuses until clients have had time to fetch the new key, so a rotation is not an outage.
- Backups are verified, not assumed
- Daily: create, verify, prune. Verification reopens the archive, runs an integrity check and confirms the expected tables are present — a structurally perfect database with zero tenants fails.
- The archive does not contain the key
- Backups are written to the host rather than into a container volume, so removing volumes cannot take the data and its backups together — and the key that decrypts the sealed values is kept out of the archive on purpose. A stolen backup is not a breach of the secrets inside it.
Verifiable without trusting us.
Each tenant has its own chain, so a lawful deletion for one customer is not indistinguishable from tampering with another's history. Exports are ordered oldest-first in CSV or JSONL.
The verifier is a standalone script. It imports nothing from the platform, reads only the export you hand it, and exits non-zero on any finding — so the other party can check the chain on their own machine without taking our word for anything.
python3 verify_export.py audit-export.jsonl
chain intact 4,182 records
first 2026-01-04T09:12:00Z
last 2026-09-07T22:41:18Z
exit status 0Collect less, keep it for less time.
These reduce what is written, not merely what is displayed — turning a setting down means the data was never recorded.
- Address full · truncated · none
- Location precise · country · none
- Device full · none
- Replay on · off
- A ceiling you set, a floor they can lower
- A tenant can shorten any retention window but never extend it past the operator's limit. A window of zero means keep indefinitely, and that is stated rather than implied.
- Some things are refused, and it says why
- Erasure will not delete session revocations — removing one would reinstate a terminated account — nor break the hash-chained audit log. The request is refused with the reason rather than partially honoured in silence.
What we deliberately do not do.
A product that hides its limits is harder to trust than one that names them.
- We do not see your users
- The cross-tenant view an operator gets returns counts, rates and health — never identities. The tenant is the data controller for their own people, and that is enforced in the query layer rather than in the interface.
- Your source is not retained
- Integration analysis defaults to a model running inside your own deployment. Nothing analysed is written to disk or database on our side, and a credential scan runs before anything is transmitted at all.
- We are a final-year project
- VERISCO is built as a working system, not as a company with a support contract behind it. Both codebases run in CI on every push, and neither has been through an external security audit.
Questions we have not answered here?
If you are evaluating this seriously, ask us the awkward ones — we would rather answer them now than have you find out later.