1. What we are protecting
Three things, in this order:
- The integrity of the record. The product is the numbers. Everything else is replaceable; a register whose past can be silently rewritten is worthless.
- Subscriber data. Small in volume, but it is people's email addresses and payment relationships.
- Availability. Least critical: an hour of downtime is an inconvenience, not a loss.
2. Authentication
- There is no password. Access is by a single-use link sent to your email address, valid for a short period. We therefore hold no password, and no password can be reused, guessed, phished from us or leaked by us.
- Sign-in links and sessions are stored only as salted hashes. The plaintext token exists only in your mailbox and your browser. Someone who read our whole database could not sign in as you with what they found.
- Sessions expire after 90 days, are visible to us and to you, and can be ended by either.
- Non-enumeration. A sign-in request always gives the same answer, whether or not the address is on the list.
- Rate limiting is applied per credential where one is presented, and per address otherwise.
- Administrative access uses a separate operator credential, held only by the publisher, and is never issued to a subscriber.
3. Payment
- Card data never reaches our systems. Checkout and the customer portal are hosted by Stripe, which is PCI-DSS Level 1.
- We store Stripe's identifiers and the billing information needed for a VAT invoice.
- Webhook deliveries are signature-verified before they are applied.
4. Data storage
- The subscriber database is Postgres, hosted by Supabase in Ireland (
eu-west-1), encrypted at rest and in transit. - Row-level security is on for every table with no permissive policy, so the anonymous key sees nothing. The relay, holding a service credential, is the only client.
- Backups are managed by the database provider.
5. The application
- HTTPS everywhere, with HSTS.
- A Content Security Policy,
X-Frame-Options: DENY,X-Content-Type-Options: nosniff, a Referrer-Policy and a Permissions-Policy, applied at the edge and tested against every page before release. - The paid payload is not on the public host at all. It is served only through the authenticated relay, because a static site hands the file over before any client-side check can run. A gate implemented in the browser is not a gate.
- The site is built from an explicit allowlist: the build assembles only the files that are meant to be public and fails if a published page references anything outside it. Source code, configuration and editorial method are not served.
- Access is checked before the payload is named, so an unauthorised request cannot be used to discover what exists.
6. Secrets and access
- Production secrets live in the hosting provider's environment store and in a local file outside every repository. No secret is committed to the working tree. [VERIFY before publishing: whether the full commit history has been scanned, not just the current state. This has been verified for the sister Index repository; it should be run here too.]
- Source repositories are private.
- Continuous integration uses only GitHub's own first-party actions (
actions/checkout,actions/setup-python,actions/cache,actions/upload-artifact) — no third-party action is used, which removes the largest single supply-chain risk in a CI pipeline — and runs with the minimum scope needed. Actions are pinned by major version rather than by commit digest. - Production access is limited to the director.
7. Integrity of the published record
- Published values are sealed: a figure that changes keeps the record of what it said before, and the correction is part of the row.
- The archive is append-only in practice and immutability has been verified across the commit history.
- [OPEN:] the record's integrity currently rests on the source history not being rewritten, and branch protection is not available on the current repository plan. An off-repository copy of the published archive would make a rewrite detectable. This is the one control in this document that is identified and not yet implemented.
8. Sub-processors
Listed in Annex A to our Privacy Policy, with what each of them handles and where.
9. Incident response
If personal data is compromised we will assess within hours, notify the Information Commissioner's Office within 72 hours where the threshold is met, and tell affected people without undue delay where there is a high risk to them. We follow a written internal procedure for subject rights and for breaches, which we will produce to a regulator on request.
We will tell you what happened, what was affected, and what we did — including where the cause was our mistake.
10. Reporting a vulnerability
We want to hear from you and we will not threaten you.
Write to hello@axiom.vc with what you found and how to reproduce it.
What we commit to:
- acknowledgement within 2 working days;
- an assessment and a plan within 10 working days;
- credit in our release notes if you would like it;
- we will not pursue legal action against anyone who researches in good faith within the boundaries below.
Please do: test only against your own account; stop at the point you have demonstrated the issue; give us reasonable time before disclosing.
Please do not: access, modify or delete data that is not yours; degrade the service for others; run automated scanning that generates significant load; use social engineering or physical attacks; or extract data as proof.
We do not currently run a paid bug bounty.
11. What we do not claim
We are a small publisher, not a bank, and this statement should be read as one.
- We hold no formal certification — no ISO 27001, no SOC 2. [If an Enterprise buyer requires one, that is a project, not a form to fill in.]
- We do not have 24/7 monitoring or an on-call rota.
- There is no contractual service level on the Free, Invitation, Monthly or Annual plans.
- We have not had an independent penetration test. [CONFIRM whether to commission one before the first Enterprise sale.]
We would rather tell you that than let you assume otherwise and find out in a procurement questionnaire.
End of Security Statement.