Security & Trust

Last reviewed

How Securevoo handles your data, in one page. Securevoo answers supplier assurance questionnaires from your infrastructure telemetry — so we designed the platform around a simple rule: the sensitive parts of your estate should never reach us in the first place, and what does reach us is isolated by the database itself.

What we process — and what never reaches us

Collection happens inside your estate
Our collector is open source (github.com/giogaha/securevoo-collector) so you can audit exactly what leaves your estate. It runs on your machines and makes zero network calls, parsing exports from your identity providers (Microsoft Entra, Okta, Google Workspace, PingOne, JumpCloud) and vulnerability scanners (Trivy, enriched with the NVD CVE feed). You pipe its output to our API yourself, under your own key.
Secrets are scrubbed before anything leaves
Access keys, tokens, private keys, emails and IP addresses are detected and removed locally. Hostnames are replaced with salted, non-reversible pseudonyms. If anything sensitive survives the final sweep, the collector refuses to emit output at all — it fails closed rather than leaking.
We store evaluation evidence, not your infrastructure
What reaches Securevoo is sanitized, pseudonymized telemetry summaries and the questionnaire answers derived from them — never raw logs, credentials or personal data from your systems.
Questionnaire files are parsed in your browser
An uploaded questionnaire — Excel, CSV, PDF or Word — is read in the browser, and when we fill a buyer's workbook back in, it is written and downloaded there too. Only the extracted question text and the cell coordinates reach our API; the file itself never does.

Tenant isolation

Enforced by the database engine, not application code
Every tenant's rows are protected by PostgreSQL Row-Level Security (USING and WITH CHECK policies). The application connects as a non-owner database role that cannot bypass those policies, and every transaction is bound to the requesting tenant.
A missing filter cannot leak data
Application-level tenant filters exist as defense in depth, but they are not what your isolation rests on: a query that forgot its tenant clause returns nothing, because the database refuses to show other tenants' rows.
Adversarially tested
The isolation is covered by automated tests that attempt cross-tenant reads, writes, direct-ID fetches and cross-tenant updates as the application role — including runs of that suite against our production database.

Authentication & access

SSO only — we never hold your passwords
Sign-in is via your existing Google or Microsoft account (OpenID Connect). Sign-up is invite-gated. Sessions are first-party HttpOnly, Secure cookies; state-changing calls additionally require an anti-CSRF header.
API keys are hashed and shown once
Machine credentials are per-tenant, stored only as SHA-256 hashes, compared in constant time, and revocable at any moment from the workspace. The plaintext is displayed exactly once, at issue time.

AI use & human oversight

Compliance verdicts are never an AI decision
Pass/fail is computed by deterministic code gates — for example the Cyber Essentials v3.3 14-day patching window and global MFA scope. Evidence that is missing or older than its freshness window fails closed to a review status instead of being answered.
AI drafts prose, humans sign it off
The language model only writes the narrative over an already-decided verdict, citing the retrieved policy and telemetry, at temperature 0. Low-confidence drafts are queued for human review; approval stamps who signed off and when, and any amendment preserves the original draft for audit.
Exports enforce the review trail
Evidence-bundle exports refuse by default while any flagged draft lacks a recorded human sign-off; an explicit override marks such answers UNREVIEWED in every exported file.

Evidence anyone can re-check later

Proof packs are content-hashed, and the rule is published
An exported pack carries a SHA-256 over its canonical bytes — sha256(answers.json || 0x0A || evidence-manifest.csv || …) — together with the rule for recomputing it. That means the recipient does not have to trust us, or still have us: the digest is reproducible in any language, years after issue.
Verification happens in the recipient's browser
The public page at /v/<token> hashes the copy the recipient already holds, locally. Their file is never uploaded. The page states plainly that the report and manifest are outside the digest, because a document cannot contain its own hash.
The public lookup is read-only and answer-free
A verification token resolves exactly one record, through a row-level security policy rather than around it, and there is no public write path. It returns who issued the pack, when, and the evidence window — never a question or an answer.
Verdicts record the rule that produced them
Each deterministic gate declares a version, bumped whenever the DECISION changes, and that version travels with the verdict into the pack. Change a rule later and packs already in a buyer's hands still say which rule wrote them. Gate results supplied by a caller are marked "supplied, version unknown" rather than stamped with a number we cannot vouch for.
Every answer lists the facts under it
The pack's evidence manifest names each individual telemetry fact an answer leant on and how old it was at the time — so a reviewer can see not just the citation but its age.

Hosting & encryption

UK-region infrastructure
The application runs on Fly.io in London (lhr); the database is Neon PostgreSQL in AWS eu-west-2 (London). Managed providers encrypt storage at rest.
TLS everywhere
All traffic is forced to HTTPS with HSTS. There is no plaintext listener.

Certifications & insurance

Cyber Essentials certified
Securevoo is certified under the UK NCSC's Cyber Essentials scheme — the same scheme we help our customers evidence. We hold ourselves to the controls we defend.
Cyber liability insurance
Securevoo carries cyber liability insurance covering the business.

Software supply chain

Tested and scanned before it ships
Every change passes 600+ automated tests (including the RLS isolation suite) in CI before merge. Release images are vulnerability-scanned before publication — a fixable HIGH or CRITICAL finding blocks the release — built from digest-pinned base images, with a CycloneDX SBOM published for every release.
Dependencies stay current
Automated dependency updates run weekly across the backend, frontend, collector and CI itself, each vetted by the full test gate.

Subprocessors

Kept deliberately short
Fly.io (application hosting, London) · Neon (PostgreSQL, London) · Anthropic (narrative drafting over sanitized evidence) · Voyage AI (text embeddings for policy retrieval) · Upstash (task queue) · Google / Microsoft (sign-in only). None of them receive raw infrastructure data — the collector's scrubbing happens before anything is transmitted.

Data retention & deletion

You control the lifecycle
Evaluation runs are purged on a configurable retention schedule, API keys are revocable instantly, and tenant deletion requests are honored on request to the contact below.

Who runs Securevoo

Securevoo is built and run by Ahmed Hussein, its founder. Ahmed Hussein is CompTIA Security+ and Advanced Cyber Threat Intelligence certified, with four years in cyber security at UK central government (the Department for Work and Pensions and the Home Office). Securevoo Ltd is registered in England & Wales (company no. 17388176) at 195 Wood Street, London, E17 3NU.

Questions or due diligence?

We answer security review questions directly — it is, after all, what we do. Write to ahmed@securevoo.com.