Security
How we handle your data
We ask regulated firms to connect us to their identity systems. That deserves a straight account of what we do with the access, and what we have not done yet.
Read-only by design
Every connection we make is read-only, and we request the narrowest scopes each provider offers. We hold no write credentials to any customer system.
This is a deliberate constraint rather than a current limitation. It means the worst case if we were ever compromised is disclosure of access metadata — never a change to your access controls, and never a foothold in your environment.
What we hold
- Identities: names, work email addresses, roles
- Whether a second authentication factor is enrolled
- Devices: name, operating system, posture, encryption state
- Access records: who signed in, when, from where, allowed or denied
- Email content
- Files, documents or their contents
- Browsing activity or network traffic
- Anything requiring write access
Where your data lives
Application and database both run in Frankfurt, Germany. Your data does not leave the European Economic Area. We use no sub-processor outside the EEA for customer data.
Tenant isolation
Separation between customers is enforced by the database, not only by application code. Every customer-scoped table carries a tenant identifier with PostgreSQL row-level security enabled and forced, and queries run as a role that cannot bypass it.
That distinction matters: a bug that omits a tenant filter returns an empty result rather than another customer’s data. We verified this against the live database, including that a query with no filter at all still cannot cross a tenant boundary.
Credentials
Provider credentials are sealed with AES-256-GCM before storage, bound to your organisation so a ciphertext cannot be decrypted in another tenant’s context. They are never returned by any part of the interface and are redacted from logs. Encryption keys are held in the environment, never in the database — a database disclosure alone yields nothing usable.
Authentication
- Passwords hashed with scrypt and a per-password salt
- Session tokens held in httpOnly cookies, never reachable by page scripts
- Refresh tokens are single-use; presenting a rotated token revokes the whole session family, on the assumption it was captured
- Optional TOTP two-factor authentication
- Database connections verified against a pinned certificate authority
Evidence integrity
Issued evidence packs are sealed with a SHA-256 hash chain over a canonical representation. Altering, removing or reordering any entry invalidates every digest that follows. There is no route to edit or delete an issued pack — not in the interface, and not in the database schema.
A pack can be verified independently of us, which also means your evidence remains valid if you stop being a customer.
Our own audit trail
Privileged actions on our side — sign-ins, connector changes, evidence issuance — are appended to a per-customer hash-chained log. You can re-verify that chain yourself from within the product, without taking our word for it.
Sub-processors
| Provider | Purpose | Location |
|---|---|---|
| Supabase | Database | Frankfurt, Germany |
| Fly.io | Application hosting | Frankfurt, Germany |
| Vercel | Web interface delivery | Global edge; no customer data at rest |
What we have not done yet
Stated plainly, because you are going to ask and because a security page that claims completeness is not credible.
- We are not SOC 2 or ISO 27001 certified. We are a new company and readiness work is under way. If your vendor policy requires a certified supplier today, we would rather tell you now than waste your time.
- No external penetration test has been completed. One is planned before we take on customers handling regulated client data at scale.
- Our framework mappings have not been reviewed by a practising auditor. They are carefully reasoned against the source texts, but they are our reading. Treat the output as strong supporting evidence, not as an assurance opinion.
- Encryption keys are not yet held in a managed key service. Moving to envelope encryption is on the roadmap.
Data processing
We act as a data processor under GDPR. We will sign a Data Processing Agreement before any connection is made, and we will delete your data on request. Ask and we will send the DPA alongside our full security model.
Reporting something
If you believe you have found a vulnerability, email hg@norrstone.com. We will acknowledge within one working day. We do not run a bug bounty, and we will not take legal action against anyone reporting a genuine issue in good faith.