Security and compliance, by design.

How we operate

1. /01

   Zero-trust, deny-by-default

   Private business records are read through server-side authorization, with row-level security and database grants restricting direct browser access. The server uses a privileged service-role credential that bypasses row-level security, so application permission checks are an essential boundary; that credential is not a least-privilege database role. Public enquiry endpoints validate submissions and do not expose lead records. Service credentials stay on the server, not in browser code.

2. /02

   Mandatory two-factor authentication

   Admin and private client routes use server-side role checks and a second-factor check. An unenrolled account is directed to enrollment; an enrolled account without a valid, user-bound second-factor marker is denied access. TOTP enrollment is required for these application accounts. Public pages and articles do not require sign-in. These are application controls, not a claim about every external provider's account policy.

3. /03

   Passkeys (WebAuthn)

   WebAuthn passkeys are supported as an additional second-factor option after TOTP enrollment. Verification checks the challenge, signature, relying-party ID, origin and authenticator counter. The relying-party settings come from server configuration, not a visitor-supplied header. An implementation check is not a substitute for testing sign-in on the deployed hostname and the user's authenticator.

4. /04

   Invite-only, reject-by-default access

   There is no self-serve signup — it is disabled and returns 403. Every account is created by an administrator, bound to its tenant, and the inviter is recorded. Onboarding is reject-by-default; access is provisioned per engagement and deprovisioned on exit. Today the only accounts are Veltheon's own — this is the policy the first customer account will be created under.

5. /05

   Least privilege

   Roles are default-deny: a principal can do only what its role explicitly grants, and authorization is derived from the session on the server — never from a request parameter. Admin surfaces are separated from customer surfaces, and deactivation or device revocation takes effect on the very next request, not at token expiry.

6. /06

   Accountability & tamper-evident audit

   Security and business events use a hash-chained audit trail. A verifier checks the covered fields and links between the records it receives. Detailed changes are covered only when their fingerprint is included in a chained record. This helps detect inconsistencies; it is not proof that every event was recorded, an independently anchored history, or protection against a privileged administrator rewriting the store.

7. /07

   Append-only pricing & records

   Pricing and business records are never edited in place. A change writes a new effective-dated row and stamps the prior one closed; the amount on a historical row is never rewritten. Retirement is an 'archived' or 'void' status, never a deletion.

8. /08

   Encryption in transit

   All traffic is served over TLS 1.2+, with HSTS enabled. Secrets are never committed to source control and are held in each platform's own secret store.

9. /09

   Encryption at rest

   Managed-database storage is encrypted at rest by the platform (inherited). Application-layer encryption — gzip, then AES-256-GCM, with the key held separately from the ciphertext — is a live control for private feedback screenshots: they are encrypted before upload, so the object store holds ciphertext and never a readable image. It does not yet cover large engagement artifacts in the separate contract bucket, which today rely on the provider's own encryption at rest; extending it there is a roadmap item, not a live control.

10. /10

    Canadian data residency

    The primary application database is a Canadian-region (ca-central-1) Supabase project, and application compute is pinned to Montréal (yul1) — so records are both stored and processed in Canada. It holds application records, including contact details and enquiry and consent records—not just non-personal metadata. See Where your data lives below for the sub-processors that process outside Canada.

Where your data lives

Veltheon is Canadian-first by design. Our primary application database is a Canadian-region (ca-central-1) Supabase project and holds application metadata and records. Private Cloudflare R2 delivery for large engagement artifacts is implemented but is not configured in production; no engagement artifact is stored there today. Private feedback screenshots, which a signed-in user may attach to a bug report, are stored in a separate R2 bucket and are encrypted by us before upload. Cloudflare R2 offers no Canadian jurisdiction — its published options are the EU, FedRAMP and the US — so files we hold in R2 are not Canada-resident, and we do not say otherwise. Cloudflare's Eastern North America placement is a best-effort location hint, not a Canadian-residency guarantee, so we will record the actual bucket location at provisioning and will not label R2 Canada-resident without evidence. We are honest that a small number of sub-processors process outside Canada — application rendering and API handling are pinned to Montréal (yul1), but the edge network in front of them is global, and some model / email providers are US-based. Where a cross-border transfer involves the personal data of a Québec resident, we run a privacy impact assessment (Law 25) first and minimize what is sent. We do not claim that all data stays in Canada — it does not; the exact region for every provider is on the sub-processors page.

Certifications & audit status

We publish exactly what is true today — no more. A badge turns “Certified” only the day an accredited body issues the certificate, and not a day earlier.

Payment cards: we do not process payment cards. Veltheon invoices its engagements directly, so cardholder data never touches our systems.

The roadmap to certification

1. /00

   Application control implementation · Implemented · operational evidence reviewed separately

   Access checks, second-factor gates and audit verification are implemented. Deployment configuration, restore exercises and operational checks require their own evidence; a code test is not a compliance certification.

2. /01

   Privacy substance · Underway

   The Privacy Officer and sub-processor register are published, and a minimum internal incident-response runbook now exists. Executed DPAs, a concrete retention schedule, a restricted incident register, and the first tabletop exercise remain underway.

3. /02

   SOC 2 Type I · On demand

   Continuous control monitoring and a point-in-time auditor report — engaged when an enterprise customer requires it.

4. /03

   SOC 2 II + ISO 27001 · As we scale

   An observation-period Type II report plus an accredited ISO 27001 ISMS certification.

Honesty clause

We do not claim certifications we don't yet hold. When a SOC 2 report or ISO 27001 certificate is issued, we'll publish it here and make the report available under NDA. Until then, the language on this page is exactly what it says.

Data & privacy

Veltheon is built privacy-first, aligned with PIPEDA and Québec Law 25. We collect only what we need, keep the primary datastore in Canada, restrict who can see it (deny-by-default), and give you clear control. A Privacy Officer is designated — reach them at [email protected]. You can ask us at any time to access, correct, or delete the personal information we hold about you (subject to our legal retention obligations), or withdraw consent. Healthcare / PHIPA engagements are counsel-gated before any personal health information touches a system. Full detail is in our Privacy Policy.

Responsible disclosure

We welcome reports from security researchers acting in good faith. If you believe you have found a vulnerability in a Veltheon system, please tell us before disclosing it publicly — report security concerns to [email protected]. We will not pursue legal action against researchers who act in good faith, avoid privacy violations and service disruption, and give us reasonable time to remediate before public disclosure. We ask that you not access, modify, or delete data that is not yours, and not run automated scanning that degrades service. In scope: veltheon.ca and its authenticated application surfaces. Out of scope: third-party sub-processor infrastructure (report those to the provider), denial-of-service, and reports without a demonstrable security impact. We do not currently run a paid bug-bounty program; we recognize good-faith reports.

Availability & resilience

Veltheon runs on resilient, managed infrastructure (Vercel and Cloudflare edge, Supabase managed Postgres) with the redundancy those platforms provide. The managed database is backed up by the platform, and cross-cloud DR replication for encrypted artifacts is planned. We monitor platform health and application errors, and log sign-ins and sensitive actions for security. We do not publish a public uptime SLA — specific availability commitments are set per engagement in the signed agreement, and status updates will be communicated directly to affected customers during any incident.