Security overview

This page describes the security controls in the software that runs InvestorUniverse today, and says plainly what is not in place yet.

I. AI LTD trading as InvestorUniverse · Read from the running system on 5 October 2026, 22:30 UK time

Encryption

Contact fields. An investor's work email address and phone number are encrypted one field at a time with AES-256-GCM before they are stored. Each value gets its own random 96-bit nonce and an authentication tag, so a stored value that has been altered does not decrypt.
The key. One 256-bit key, held in the application's configuration and never in the database. In production the code refuses to encrypt or decrypt without it.
Matching without decrypting. To check an address against the suppression list or a bounce record we compare a keyed HMAC-SHA-256 of the address, so the lookup never needs the address in readable form.
Authenticator secrets. The secret behind a second sign-in step is sealed with the same key. Recovery codes are stored only as keyed hashes and are removed when used.
Change history. The log of changes to investor records records that a contact field changed and never its value.
In transit. The site tells browsers to use HTTPS only, for two years and on every subdomain (Strict-Transport-Security), and its content policy upgrades any insecure request. The application connects to its database over TLS and checks the server's certificate.
Backups we take ourselves. The backup script encrypts the database dump with AES-256 as it is written, using a key derived from a passphrase with PBKDF2, then reads the file back to prove it opens before keeping it. Nothing unencrypted is written to disk. The restore script checks the file against its checksum and refuses a database that already holds tables.

Other data in the database, such as accounts, orders and usage records, is not encrypted by the application. It is not described as encrypted on this page.

No passwords. You sign in with a link sent to your email address. The link works once and expires after 15 minutes. The link that confirms an email address from a results page lasts 24 hours.
Sign-in requests are limited to 5 a minute from one network address and 3 a minute for one email address. The answer is the same whether or not an account exists.
Sessions. A session is a random 192-bit token in a cookie that scripts cannot read (HttpOnly, SameSite=Lax, and Secure in production). It ends after 30 days. Your account page lists your signed-in devices, and you can end any of them or all of them.
Second step. Any account can add an authenticator app (time-based one-time codes). With it on, the emailed link alone opens nothing. Each code works once, 10 wrong codes lock the second step, and 8 one-time recovery codes are issued when it is set up. Setting up a new authenticator ends every other session of that account.
Staff must use it. Staff access is never granted to a session that has not passed the second step in the last 12 hours, and a staff account cannot switch it off.

Browser protections

Content security policy. Every page is served with a policy built for that request. Scripts run only from our own origin with a one-time nonce, and from our payment provider. Plug-in content is blocked, the page cannot be framed by another site (the embeddable funding widgets are the one exception), and forms can post only to us and to the payment page. Inline styles are allowed; inline scripts without the nonce are not.
Other headers. X-Frame-Options, X-Content-Type-Options, a strict Referrer-Policy, a Cross-Origin-Opener-Policy, and a Permissions-Policy that switches off camera, microphone, location and USB and limits payment to our payment provider.
Signed-in pages are never cached by a shared cache: account, dashboard, results and staff pages are sent as private and no-store.

Rate limits and the anti-scraping guard

Shared counters. Request limits are counted in the database, so they hold across every server instance. If the database cannot be reached, each instance falls back to its own counter.
Page views of investor data are metered per visitor and per account, with a daily allowance. A burst of views blocks the network address for 24 hours and locks the signed-in account.
Automated clients are refused on investor data pages: headless browsers, HTTP libraries and AI crawlers. Search engines are let through on the public pages.
Contact reveals have ceilings per account and per network address, by the hour and by the day. An account that passes them is locked on the spot and its sessions are ended.
An hourly scan reads the audit trail for unusual patterns, such as fast reveals, repeated exports, one account signing in from many places and repeated failed sign-ins, and alerts us.
Exports are traceable. Every export is recorded against the account that made it, and the file names that account.

Tenant isolation

A tenant is one company raising one round, identified by the account that owns the plan. A co-founder invited to that plan belongs to the same tenant. The company profile and the raise are shared inside the tenant. Each person's saved investors, lists and assistant history stay with that person.

Isolation is logical: tenants share one database, and every query on a founder's data is limited to the owning account. There is no separate database per customer.
A test reads every SQL statement in the source code and fails when a statement touching the company profile, the raise, list snapshots, intelligence runs, pipeline history or assistant messages has no such limit. A second test creates two companies and checks that neither can read the other's.
One figure is computed across tenants: how often founders report a reply from an investor. It is used only once enough founders have contacted that investor, and it never shows which founders they were.

Staff access and audit

Network restriction. The staff area can be restricted to named network addresses. From any other address it answers as if it did not exist.
Alerts. A staff sign-in from an address not seen before, and a staff account setting up its second step, each raise an alert.
Audit trail. Sign-ins and failed sign-ins, contact reveals, exports, plan and team changes, data requests and every staff action are written to an audit trail with the network address and browser.
Change history. Every change to an investor record is logged by the database itself with what it was before, what it is after and who made it.
Key rotation. Each service key has a rotation date. The hourly scan raises a flag 30 days before a key is due and when it is overdue.

Payments

Card details are entered with our payment provider and never reach our servers. We keep the payment reference and the amount. Messages from the payment provider are accepted only when their signature checks out. The provider is named on the sub-processors page.

What is not in place yet

No certification. We hold no security certification. When that changes it will be listed on this page with its date.
No single sign-on. Sign-in is by emailed link with an optional authenticator app. There is no SAML or OpenID Connect sign-in and no automated user provisioning.
The second step is optional for customers. It is required for staff only.
One encryption key. There are no per-customer keys and no customer-managed keys.
No dedicated database or choice of region for a customer.
No self-service account deletion. Deletion and export of an account's data are handled by a person, on request.
No bug bounty. See the disclosure policy.

Reporting a problem

Report a suspected vulnerability to privacy@investoruniverse.uk. The disclosure policy says what to send and what we commit to.

Trust Centre · Sub-processors · Data retention · Claims ledger