Sikkerhet

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.

Encryption

• In transit: every connection to clarvia.io, the API at api.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: the frontend, the API and the database are managed services that speak to each other over TLS; no internal call is made in clear text.

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 post@clarvia.io. 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 and DPA: the full sub-processor register is section 7 of the privacy policy. Business customers can request our data processing agreement (databehandleravtale, GDPR Art. 28) from post@clarvia.io; it lists every sub-processor, retention period and security measure.
• 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_log entry.
• 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: the application runs on managed container infrastructure with only HTTPS exposed. There is no server to log into: no SSH, no shell access, and no administrative port reachable from the internet.

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: post@clarvia.io. We acknowledge responsibly-disclosed reports within 24 hours.

Compliance roadmap

• SSO (SAML / OIDC): on our roadmap for the Enterprise tier alongside the custom DPA and SLA. Not yet available - contact us if you need it and we'll scope timing with you.
• 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: post@clarvia.io