Security Overview
Provider: Valiquest AB · Org.nr 559577-0347 · Stockholm, Sweden Service: Virtual Customer Version: v1 — 2026-04-22 (DRAFT — pre-counsel review) Public URL (after publication): https://app.virtualcustomer.io/legal/security.html
This document tells customers, design partners, and prospects what we actually do to keep their data safe — and, just as importantly, what we do not yet do. We have deliberately avoided "marketing security" language. Controls that are implemented but still awaiting production cutover evidence are labelled as pre-production.
1. Trust posture (one paragraph)
Virtual Customer is operated by Valiquest AB, a small Swedish startup. We design the product on the basis that we are not yet certified (no SOC 2, no ISO 27001, no PCI scope), so we minimise our own attack surface by delegating as much of the heavy security work as possible to vetted infrastructure providers (Google Cloud / Firebase, Railway, Paddle). Our own work focuses on least-privilege access, transport security, secret hygiene, encrypted-at-rest storage from the platform, billing-event traceability, and a small, reviewed change pipeline. Public production claims require runtime evidence from the production cutover checklist.
2. People and access
2.1 Who has access to production data
- Authorised personnel today: the two Valiquest founders (Fredrik and one co-founder once on-boarded). No other employees, contractors, or interns currently have production access.
- Access basis: least-privilege Firebase / Google Cloud IAM roles; no shared "root" account.
- Authentication: Google account with hardware-key two-factor authentication (FIDO2) or Authenticator-app TOTP. No SMS-based 2FA.
- Onboarding/offboarding: new authorised personnel are added by an existing founder via a documented checklist (see internal
documents/runbooks/onboarding-personnel.mdonce published). When personnel leave, access is revoked the same business day.
2.2 What we do NOT (yet) do
- We do not have a formal background-check process for new personnel.
- We do not have an automated identity-and-access-management (IAM) provisioning system. Access changes are manual and logged in a runbook.
- We do not have an internal SSO; founders log in directly to each provider.
3. Hosting and infrastructure
- Application runtime: Railway (container hosting) — see
subprocessor-list-v1.md§2. - Identity / database / storage / serverless: Google Cloud / Firebase — see Subprocessor List §1.
- Billing: Paddle (merchant of record) — see Subprocessor List §3.
- Email: Resend (with SendGrid as fallback) — see Subprocessor List §8.
- DNS and CDN: Cloudflare (DNS) and the Firebase Hosting CDN where applicable. Reviewer flag — confirm Cloudflare contracting entity and SCC posture.
We rely on the SOC 2 / ISO 27001 / PCI-DSS posture of these providers for the underlying compute, storage, and network. We do not independently audit them; we read their published reports.
4. Data classification and storage
| Class | Examples | Where it lives | Encrypted at rest? | Encrypted in transit? |
|---|---|---|---|---|
| Customer Content | Study briefs, transcripts, AI summaries, themes, quotes, uploaded files. | Firebase Firestore + Firebase Storage. | Yes — provider-managed AES-256. | Yes — TLS 1.2+. |
| Account data | Email, name, organisation membership, role. | Firebase Firestore. | Yes — provider-managed AES-256. | Yes — TLS 1.2+. |
| Billing data | Invoices, payment-instrument metadata, subscription state. | Paddle (primary); Firebase Firestore (mirror of subscription/billing fields, no card numbers). | Yes — provider-managed. | Yes — TLS 1.2+. |
| Operational logs | Request timestamps, model latency, token counts, masked error context. | Railway and Google Cloud Logging. | Yes — provider-managed. | Yes — TLS 1.2+. |
| Backups | Periodic exports / platform backup material. | Google Cloud / Firebase backup locations; current repo HEAD excludes backups/, and historical repo cleanup is a cutover task. | Yes — provider-managed or bucket-level encryption. | Yes — TLS 1.2+. |
Customer-managed encryption keys (CMEK / BYOK): not yet supported. Roadmap §10.
5. Network and transport security
- TLS: all public endpoints serve HTTPS only, with HSTS, modern cipher suites (TLS 1.2 minimum, prefer 1.3), and HTTP→HTTPS redirects at the platform edge.
- Certificates: managed by Cloudflare and the Firebase Hosting CDN; auto-renewed.
- HTTP security headers:
helmetmiddleware is implemented inserver.jsbehindHELMET_ENABLEDand defaults on in staging. Production activation is a cutover task. CSP is currently disabled in the helmet rollout while we build a strict allow-list; tightening CSP is on the roadmap. - Rate limiting:
/api/*rate limiting viaexpress-rate-limitis implemented behindRATE_LIMIT_ENABLEDand defaults on in staging. Production activation is a cutover task. We trustX-Forwarded-Forfrom the platform proxy (app.set('trust proxy', 1)) so per-IP limits work behind Railway's load balancer once enabled. - DDoS: absorbed by the upstream platform edge (Cloudflare and Google front-ends). We have not commissioned a stand-alone DDoS protection service.
6. Authentication and authorisation
- End-user authentication: Firebase Authentication (email + password, plus Google OAuth). Passwords are never stored by us; Firebase manages the hash.
- Email verification: required on sign-up before users can do anything substantive.
- Password policy: Firebase Authentication default password policy. Breach-list checks are not claimed until the Firebase Identity Platform tier/configuration is confirmed.
- Two-factor authentication for end-users: not yet supported. Roadmap §10.
- API authorisation: protected product API routes validate a Firebase ID token (
requireAuth) and, where organisation data is involved, an organisation-membership/role check (requireOrgMember/requireOrgOwner/requireCreator). Public, auth-bootstrap, webhook, health, and legal/static routes are explicit exceptions. - Internal admin endpoints: require an additional
X-Internal-Admin-Requestheader matching a server-side secret (SERVER_TO_SERVER_SECRET). Used by cron jobs and one-off operational scripts. Fail-closed since security finding F-025 was fixed (G7.x). - Webhooks: Paddle webhook verification is implemented and active where Paddle env vars are configured. Unsigned or mis-signed webhook requests are rejected by the handler.
7. Application security and secure development
- Source control: GitHub with a documented branch policy:
devfor staging,prod-nextas temporary live-production transition branch, andmainas target production after cutover. Pushes/merges to live branches require explicit founder approval; confirm branch-protection settings before public launch. - CI: GitHub Actions run the current deploy-staging unit-test/config gate and warning-only staging smoke. The default
npm testcommand now runs the fast unit gate, and staging smoke stays warning-only until it has 5 green runs before cutover evidence is treated as stable. - Code review: changes to
server.js,firestore.rules, billing modules, and authentication flows require founder review before production promotion. This is an operating policy today, not yet a fully enforced GitHub rule. - Dependency hygiene: dependency reviews are handled through the repo's test/review process today. Dedicated Renovate/Dependabot automation and formal CVE SLAs are roadmap items, not current controls.
- Secret management: secrets live in Railway / Google Cloud secret stores; never in the repository. The repository's
.gitignorecovers.env*,data/,backups/and is enforced bylint-no-backups-or-pii.js. - Static analysis / SAST: not yet running a dedicated SAST tool. We rely on the lint suite and code review.
- Penetration testing: no formal third-party pen test has been commissioned. We have an internal "Cursor security bot" review on file (
documents/handoff/security-cursorbot-findings-2026-04-22.md); findings F-023 through F-027 were addressed in G7.x.
8. Operational security and monitoring
- Logging:
server.jsemits structured operational logs. Secret masking is implemented at the logger boundary (lib/mask-secrets.js), defaults on in staging, and is a production cutover flag. - Billing event logging: Paddle webhooks are recorded in
webhook_events/{eventId}for dedupe, processing status, and support traceability. Fullaudit-eventscoverage with before/after semantics is not yet claimed. - Security-critical action logging: selected flows write operational records, but a complete audit-grade log for all seat changes, invitation acceptances, role escalations, and feature flips is still a roadmap/cutover evidence item.
- Alerting: basic Railway/Firebase/provider alerts go to founders where configured. Dedicated billing failure alerting and Slack routing must be verified before production cutover.
- Backups: backup/export procedures are documented, but the first recorded restore test remains a pre-cutover requirement.
- Disaster recovery: RTO/RPO targets are internal planning assumptions until backup and restore evidence is recorded.
What we do NOT (yet) have
- We do not have a 24/7 SOC.
- We do not have a SIEM.
- We do not have automated anomaly detection on user behaviour.
- We do not yet have a completed production cutover evidence pack for every security control above.
- We do not have a formal SOC 2 or ISO 27001 certification (target: SOC 2 Type I within 12 months of first paid customer at scale; ISO 27001 in year two).
9. Incident response
- Detection: founder/provider alerts, customer reports to
info@valiquest.com, abuse reports toinfo@valiquest.com, and CI/log signals. Email aliases must be verified before public launch. - Triage SLA: acknowledge within 3 business days. (Aligned with the AUP §8 vulnerability-disclosure SLA — see internal review note 3.2.)
- Personal data breach notification: if a confirmed breach affects Customer Personal Data, we will notify the Customer's billing contact without undue delay and in any event within 72 hours of confirmation, per GDPR Art. 33 cascaded to us as Processor (DPA §10).
- Status page: not yet live. Roadmap §10. In the meantime, status updates go via the
info@virtualcustomer.iomailing list and on the in-product banner. - Post-incident review: for any incident causing more than 1 hour of unavailability or any confirmed personal-data breach, we publish a post-incident review to affected customers within 14 days.
10. Roadmap (deliberately public)
We commit to making and publishing progress on the following. Items are listed roughly in priority order.
| Item | Target |
|---|---|
| Verify public legal/security contact aliases before launch. | Pre-cutover. |
| Public status page (Better Stack / Statuspage / similar). | Q3 2026. |
| 2FA for end-user accounts (TOTP first, WebAuthn later). | Q3 2026. |
Tighten CSP to remove 'unsafe-inline'. | Q4 2026. |
| First quarterly backup-restore test on record. | Pre-cutover weekend (already scheduled). |
| Formal third-party penetration test. | Q1 2027 (post first paid customer at scale). |
| SOC 2 Type I readiness assessment. | Q2 2027. |
| SOC 2 Type II report. | Year-end 2027. |
| Customer-managed encryption keys (BYOK) for Customer Content. | Year 2 (subject to demand from enterprise tier). |
| ISO 27001 certification. | Year 2-3. |
| Background-check policy for new personnel. | Before headcount > 4 people. |
We will update this roadmap on every material change.
11. Contacts
- Security & vulnerability disclosure:
info@valiquest.com - Privacy / data protection:
info@valiquest.com - Abuse:
info@valiquest.com - Billing security:
info@virtualcustomer.io - Compliance / DPA / contract requests:
info@valiquest.com
These aliases must route to a monitored inbox before the public pages are used as production commitments.
PGP key for info@valiquest.com: to be published (roadmap §10).
Reviewer flags
For the external Swedish data protection / IT lawyer (G4.6.13):
- [REVIEW] §2 Confirm "authorised personnel today" wording vs. the Privacy Policy and DPA — we want them to mirror each other so we cannot be tripped up on a discrepancy.
- [REVIEW] §3 Confirm Cloudflare DPA + SCC posture; confirm that "Firebase Hosting CDN" should be referenced as Google or Cloudflare.
- [REVIEW] §6 Confirm Identity Platform tier vs. legacy Firebase Auth tier (affects breach-list claim).
- [REVIEW] §8 Confirm 7-year retention for billing audit logs against Bokföringslagen 7§ — current draft says 7 calendar years from end of fiscal year.
- [REVIEW] §9 Confirm 72-hour notification window matches the DPA template (G4.6.4) verbatim.
- [REVIEW] §10 Confirm we are comfortable making roadmap items publicly committed (these become representations and warranties in B2B procurement reviews).
End of draft v1 — 2026-04-22