Security and architecture
How we protect your data
Last updated: 10 August 2026
This page is for your IT and compliance team. It gives a quick overview of Launchr's architecture, security measures and data processing, so that you can judge whether Launchr fits your governance before we talk about signing a DPA or running a pilot.
In short
Eight promises
The most important points first. Every promise is backed by architecture and documentation further down, and by our data processing agreement, DPIA and Transfer Impact Assessment.
Your data is not shared and never sold
Only the sub-processors needed to deliver the service. Never resale, never marketing.
No AI is trained on your data
Anthropic, Google and ElevenLabs contractually prohibit training on your content. Zero retention and EU residency can be turned on.
Everything is encrypted
TLS 1.2+ in transit, AES-256 at rest: database, file storage and sessions.
Data is processed and stored in the EU/EEA
Compute in Stockholm, database in Zurich (EU adequacy), storage and worker in the EU. Only AI calls go to the USA, under SCC.
GDPR from the ground up
You are the data controller, we are the data processor. DPA (art. 28), a published DPIA and TIA, and the full sub-processor list.
Isolated from every other customer
Every row carries your organization id, and every query filters on it. The Supabase Data API has zero privileges, so there is no route around the application.
A full audit trail
Every action is logged with timestamp, user and event, in an append-only stream we only write to.
Deletion when you ask for it
Access closes immediately, and all content is deleted permanently at your request. We confirm in writing once it is done.
When you dig in
The full technical picture: architecture, data residency, encryption, access control, sub-processors and GDPR processes.
The architecture in one sentence
Launchr is a multi-tenant SaaS platform built on a serverless Next.js 16 application, hosted on Vercel with serverless functions in the EU (Stockholm/arn1), PostgreSQL (Supabase, Zurich) as the primary database, Cloudflare R2 for file storage, Clerk for identity management and a hardened Fly.io worker in Stockholm for video and audio processing.
Data residency
All personal data and customer-facing data sits in the EU/EEA or in countries with an EU adequacy decision:
- PostgreSQL database: Supabase, Zurich (Switzerland), a country with an EU adequacy decision
- File storage (video, audio, images): Cloudflare R2, EU region
- Transcoding worker: Fly.io, Stockholm (Sweden)
- Email delivery (transactional + inbound): Resend, EU region
- Error monitoring: Sentry, EU region
- Compute + hosting: Vercel, serverless functions in the EU (Stockholm/arn1) + global edge cache
Identity management at Clerk is the only component with cross-regional infrastructure, and it uses SCC + EU data residency for session data.
Multi-tenant isolation
Every organization in Launchr gets its own logical space in the database. Every row in every table carries an organization_id, and every single query in the application filters on the organization the current session belongs to. The organization is always derived from the session, never from anything the client sends along.
There is no route around the application. Supabase's Data API (PostgREST and GraphQL) has zero privileges on our tables: the roles anon and authenticated hold neither SELECT, INSERT, UPDATE nor DELETE. Even with a leaked public key there is nothing to fetch. Row-Level Security is enabled on top as an extra lock on that route. We put it precisely, because that is how it works: the isolation is carried by the organization filters in the code plus a database that can only be reached through the application.
We test it instead of promising it. An automated isolation check verifies the invariants on every single code change, alongside type checking, linting, unit tests and vulnerability scanning. No code change reaches production unless all checks are green. The check verifies that the public roles still hold zero privileges, that RLS is enabled on every table, and that the search_path of the database functions is locked.
The check cannot report green without having measured. If it cannot reach the database, it turns red and blocks the merge instead of passing with a note. A green run also prints what it verified: how many tables were checked, how many of them have RLS enabled, and how many privilege combinations were reviewed. If you want to see the result from production, we run the check and send you the output.
Deletion and retention
We would rather be precise than promise a deadline that no machine enforces. Here is how it works today: when something is deleted in the platform, it is marked as deleted, and access disappears immediately for all users and all shared links. The rows remain in the database until they are removed permanently.
Permanent deletion happens at your request. Write to support@launchr.dk, and we delete your organization with everything attached to it (campaigns, deliveries, plans, productions and files in R2) and confirm in writing once it is done. The foreign keys in the database cascade, so deleting the organization takes all related rows with it.
We do not run automatic cleanup jobs that delete on a fixed deadline, and so we do not promise one either. If you need a fixed retention period in your governance, we agree it in writing and carry it out as a documented action.
Encryption
- In transit: TLS 1.2+ on all endpoints, including internal service-to-service calls. HSTS preload listed with a 2-year max-age + includeSubDomains.
- At rest: AES-256 at Supabase (database), Cloudflare R2 (files) and Clerk (sessions). Backup snapshots encrypted to the same standard.
- API keys (Partner API): hashed at rest with SHA-256. Revealed once on creation; can be revoked per key.
- Secrets (env vars): held in Vercel's environment management + Supabase Vault. Rotated on compromise or when an employee leaves.
Access control and authentication
- SSO + OAuth: email + Google (further identity providers can be connected on request).
- Multi-factor login: available through Clerk for all users; can be enforced at organization level by agreement.
- Role-based access: organization members hold one of three roles: owner, admin or member.
- Session handling: configurable session lifetime at Clerk; automatic logout after 7 days of inactivity by default.
- Access per module: an organization can be limited to exactly the modules (Media, Media plan, Production) it needs. Relevant for large customers who use only a subset.
Audit trail
Every change at domain level is logged in an append-only event stream with timestamp, user id and payload. That covers:
- creation, update and deletion of campaigns and spots;
- asset uploads, transcoding status and deliveries;
- approvals and rejections through share links;
- emails sent and replies received, with classification;
- quotes, invoices and payment status in Production.
The audit log is readable for organization admins in the UI. A complete export as JSON or CSV is available on request (coming: self-service export in the UI).
Backup and recovery
- Database: Supabase takes point-in-time backups with a 7-day restore window.
- Files: R2 is replicated across regions within the EU.
- Recovery Time Objective (RTO): we aim for 4 hours for critical systems.
- Recovery Point Objective (RPO): at most 1 hour of data loss for the database; no loss for files.
Cross-border transfers
Most data stays in the EU. Two categories of services have components in the USA:
- AI processing: Anthropic (Claude: text), Google (Gemini/Nano Banana: images; Veo: film in Akademi) and ElevenLabs (voice) are used for spec parsing, scripts, classification, storyboard images and film and voiceover generation. All are subject to SCC; data is not used for training, and zero retention + EU data residency can be turned on with each supplier. Parallel film rendering runs on AWS Lambda in an EU region.
- Supporting services: Clerk (identity), Inngest (job orchestration), Twilio (SMS, Production only) and Google Maps (geocoding, Production only), all with SCC.
Transfers take place on the basis of the European Commission's Standard Contractual Clauses (2021/914) and, for certain suppliers, additionally under the EU-US Data Privacy Framework. The Transfer Impact Assessment (TIA) is published at launchr.dk/en/legal/dpia.
Vulnerability handling
- Dependabot: opens weekly PRs for updates; security PRs around the clock.
- CI gate: npm audit on high and critical CVEs blocks merges that introduce new vulnerabilities.
- Type safety: TypeScript strict mode + Zod validation at all API boundaries prevents whole classes of bugs.
- Security headers: CSP, HSTS, X-Frame-Options DENY, strict referrer policy, Permissions-Policy with restrictive defaults.
Personal data breaches
If we discover a breach, we notify you as data controller without undue delay (no later than 24 hours after discovery) with information about the nature and scope of the breach, its likely consequences and the mitigating measures taken. Our role as data processor puts you in a position to meet your notification duty towards Datatilsynet, the Danish Data Protection Agency, within 72 hours (GDPR art. 33).
GDPR rights you can exercise on behalf of your data subjects
As data controller you can ask us to:
- hand over all data about a specific person in a common format;
- correct or delete specific persons' data;
- pause the processing temporarily;
- hand over the full audit trail for your processing;
- delete all data on termination (we carry out the deletion and confirm in writing once it is done).
Requests should be sent to support@launchr.dk. We reply within 30 days.
DPIA assessment
We have prepared a Data Protection Impact Assessment for Launchr, published at launchr.dk/en/legal/dpia and kept up to date. The assessment is that the processing does not pose a high risk to the rights of your data subjects. The processing does not intentionally cover special categories (GDPR art. 9) and carries out no automated decision-making with legal effects (art. 22).
If you need a DPIA of your own specific use of Launchr, we supply the documentation you need, including a data flow diagram, sub-processor roles and cross-border assessments.
Certifications and planned work
Our security model separates what is implemented today from what is planned:
- Today: GDPR-compliant architecture; Standard Contractual Clauses for transfers to the USA; DPIA and Transfer Impact Assessment prepared, published at launchr.dk/en/legal/dpia and kept up to date; continuous vulnerability handling (Dependabot + npm audit as a CI gate); incident and error monitoring through Sentry.
- In planning (2026–2027): ISO 27001 certification, SOC 2 Type II, external penetration testing and a formal test of the business continuity and disaster recovery plan (BCP/DR).
The DPIA and the Transfer Impact Assessment are published at launchr.dk/en/legal/dpia, the data processing agreement at launchr.dk/en/legal/dpa. Further documentation is provided on request.
Sub-processors
The full list of sub-processors (including roles, location and transfer mechanisms) is in the data processing agreement. We give you at least 30 days' notice before changes take effect, so that you can object.
Questions?
Write to support@launchr.dk. We normally answer security questions from prospective enterprise customers the same day. If you have a specific compliance template you want us to fill in (TISAX, ISO overlap, NIS2 assessment), send it over. We built the system with that kind of process in mind.