Security Overview
How we store, process, and protect your data
A plain, complete account of our security posture: where your data lives, how it is encrypted, who can reach it, and the standards we hold ourselves to.
Clarvia AS · Norway · Last updated May 2026
What we store and what we don't
Clarvia analyses public web pages and produces AI-visibility scores plus actionable rewrites. The data we keep is the minimum needed to deliver and improve that service:
- What we store: the URLs you analyse, the scraped public HTML of those pages, the scores and suggestions Clarvia generates, project-level brand context you optionally provide, your account profile (email, plan, locale), and aggregate usage events for billing and product analytics.
- What we do not store: we do not collect raw credit-card numbers (Stripe handles payment instruments end-to-end), we do not store API keys you might paste into Canvas for OAuth-connected CMS push, and we do not retain the body of email magic-link confirmations beyond delivery.
- Data minimisation: screenshots and raw HTML captured during analysis are kept for as long as the analysis is referenced (default: 90 days for Free, retained for the contract term on Pro and Enterprise). Older snapshots are deleted automatically.
EU data residency in Frankfurt
All customer data is stored and processed inside the European Union. Supabase Postgres (our primary database), object storage for screenshots and PDF reports, and Realtime channels all run in the EU Central (Frankfurt, Germany) region. Anthropic Claude is invoked via the EU API endpoint where available; OpenAI and Google Gemini calls fall under their respective EU data-processing addenda.
We do not replicate customer data to US or APAC regions for any reason. Backups are encrypted and stored within the same EU region as the primary database.
Encryption
- In transit: every connection to
clarvia.io, the API atapi.clarvia.io, and the Supabase backend uses TLS 1.3. HSTS is enabled with subdomain inclusion; HTTP requests redirect unconditionally to HTTPS. - At rest: Postgres data is encrypted at the disk layer (AES-256). Object storage (screenshots, PDFs, generated assets) uses server-side encryption with platform-managed keys.
- Sensitive fields: CMS-push credentials and OAuth client secrets entered into Canvas are encrypted at the application layer with Fernet (AES-128-CBC + HMAC-SHA256) before being written to the database; the key is held only in the server runtime environment, not in source control.
- Transport between services: internal calls between the frontend, backend, and database run inside an encrypted overlay network on the host (Tailscale + Cloudflare Tunnel) and never traverse the public internet without TLS.
Row-level multi-tenancy
Clarvia is a multi-tenant SaaS. Every customer record (analyses, projects, suggestions, citation scans, billing events) is tagged with a user_id and a workspace_id. Postgres Row Level Security (RLS) is enforced on every table, so a query made with a user's session token can only return rows that belong to that user or their workspace. RLS policies are version-controlled in the repo and reviewed on every change.
The backend service role key, which can bypass RLS, is held only in the server environment and used exclusively for administrative tasks (admin dashboards, scheduled jobs, audit-logged operations). It is never exposed to the browser.
GDPR & data subject rights
Clarvia AS is a Norwegian data controller. We comply with the GDPR and the Norwegian Personal Data Act. Specifically:
- Right to access: request a copy of your data at [email protected]. Delivery within 30 days.
- Right to erasure: closing your account triggers a 30-day grace period followed by complete deletion of analyses, scores, screenshots, and account metadata. Billing records may be retained for the period required by Norwegian accounting law (5 years).
- Right to portability: all analyses can be exported as JSON or PDF from the dashboard. Bulk export is available on request for in-house teams, agencies, and Enterprise.
- Sub-processors: a public sub-processor list is maintained at [email protected] on request. Primary processors include Supabase (database + storage, EU), Anthropic (AI inference), OpenAI (AI inference), Google Cloud (Gemini inference), Resend (transactional email), and Stripe (payments).
- Data processing agreements: a standard DPA is offered automatically with every Pro and Enterprise contract, covering in-house teams and agencies alike. Custom DPAs are accommodated on Enterprise.
Application security
- Authentication: passwordless magic-link sign-in by default, with optional password set per user. Supabase Auth manages sessions; tokens are short-lived JWTs with refresh rotation.
- Authorisation: RLS on Postgres + explicit admin-role gates on backend routes (audit-logged). Every admin action writes an
admin_audit_logentry. - Secrets management: API keys and credentials live in the server's environment, never in source. CI builds use scoped secrets that cannot be exfiltrated to logs.
- Dependency hygiene: automated security advisories on every PR via GitHub's Dependabot equivalent. Critical-severity advisories block merge.
- Static analysis: TypeScript strict mode + ESLint security rules on every commit; Python typing enforced; a 12-agent in-house QA pipeline runs on every deploy.
- Network surface: only ports 80 and 443 are exposed publicly via Cloudflare. SSH access is keyed-only over Tailscale; the prod host is not internet-reachable on port 22.
Incident response
If we discover a security incident affecting your data, we will:
- Notify affected customers by email within 72 hours of confirming the incident.
- Provide what is known about scope, root cause, and immediate mitigations as soon as that information is reliable. We do not wait for a complete post-mortem.
- File any required notifications to the Norwegian Data Protection Authority (Datatilsynet) and other applicable regulators on the GDPR-mandated timeline.
- Publish a public post-mortem for any incident with material customer impact.
To report a vulnerability or suspected incident: [email protected]. We acknowledge responsibly-disclosed reports within 24 hours.
Compliance roadmap
- Q3 2026, SSO (SAML / OIDC): available on the Enterprise tier alongside the custom DPA and SLA. Already engineered and ready to enable on demand.
- 2027, SOC 2 Type II: readiness work begins Q4 2026, audit window opens 2027. Audited by a Big Four or top-tier US firm.
- EU AI Act alignment: Clarvia's AI use sits in the limited-risk category. Transparency and human-oversight controls are already in place; we monitor the implementing acts as they are published and update the disclosure surface accordingly.
- ISO 27001: planned for 2028 once SOC 2 has been operational for 12+ months.
Contact
Security, privacy, vulnerability disclosures, DPAs, sub-processor lists, data-export requests: [email protected]
Talk to us about security and DPAs