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.