Impact assessment and Transfer Impact Assessment

1. Description of the processing

Launchr is a production and delivery platform for campaign material. The customer uploads material and information, the platform develops and prepares campaign elements with AI services and delivers them to media. Categories of data processed:

• Account data: name, email, phone number and organization affiliation for the customer's users.
• Campaign data: briefs, scripts, specs and contact details for the customer's contacts (for example at media and partners).
• Material: images, video and audio, which can contain personal data in the form of voices and identifiable people.
• Metadata: audit log of actions (timestamp, user id, event), usage and billing data.

The processing does not include intentional processing of special categories of personal data (GDPR art. 9), and no automated decision-making with legal effects for individuals takes place (GDPR art. 22). Customers are instructed not to upload special categories.

2. Data flow and location

• Application and compute: Vercel, serverless functions in the EU (Stockholm, arn1).
• Database: Supabase (PostgreSQL) in Zurich, Switzerland (a country with an EU adequacy decision).
• File storage: Cloudflare R2 in an EU region, encrypted at rest.
• Transcoding and audio worker: our own worker at Fly.io in Stockholm, EU. Stem separation runs here, not with an external AI supplier.
• Film rendering: AWS Lambda in an EU region (Frankfurt/Stockholm), no persistent storage.
• AI calls: selected operations send material to AI suppliers in the USA (and for a few suppliers in the EU), see the TIA section. Only the material the individual operation requires is sent; nothing is mirrored continuously.

Data at rest therefore sits in the EU/EEA or in Switzerland. Transfers to the USA take place only in connection with specific AI operations and selected operational services (identity, job orchestration, SMS and error monitoring), as described in the sub-processor list in the data processing agreement.

3. Necessity and proportionality

• Purpose limitation: the processing takes place solely in order to deliver the Service; no resale, no marketing use of customer material.
• Data minimization: AI calls receive only the material the customer actively sends into the specific operation.
• Storage limitation: on termination, access is closed, and personal data is deleted or anonymized according to the customer's instruction as a documented action. No automatic deletion jobs run on a fixed deadline. At the AI suppliers, short deletion deadlines apply (typically 7 to 30 days), see the DPA list.
• Organization isolation: every row in the database carries the customer's organization_id, and every query filters on the organization the session belongs to. There is no route around the application: Supabase's Data API has no privileges on any table.
• Access management: role-based access (owner/admin/member) and a scope layer that separates personal and shared work within the organization.
• Traceability: append-only audit log with timestamp, user id and event.

4. Risks and measures

• Access across customers: countered with organization scoping of all tables and all queries, a database without public privileges (the Data API can neither read nor write), Row-Level Security as an extra lock on that route, and an automated isolation check as a mandatory check before every code change.
• Misuse of share links: public links are protected with one-time codes with a short expiry (5 minutes), single use and the option of revocation; rate limiting of the login screens is planned as an extra layer.
• Processing at AI suppliers: countered with SCC, documented no-training terms where they exist, short deletion deadlines and data minimization. Where a term is not yet confirmed in writing, that is stated openly in the DPA list.
• Data loss: point-in-time backups with a 7-day restore window for the database and cross-region replication of files.
• Personal data breaches: notification of the customer no later than 24 hours after discovery, so that the customer can meet the 72-hour deadline towards Datatilsynet, the Danish Data Protection Agency.
• Vulnerabilities: Dependabot, npm audit as a blocking CI gate, TypeScript strict mode and Zod validation at API boundaries.

5. DPIA conclusion

Overall, the processing is assessed not to pose a high risk to the rights and freedoms of the data subjects. The assessment rests on the character of the data categories (contact and campaign data plus commercial material), the absence of art. 9 processing and art. 22 decisions, the EU location of data at rest and the measures in sections 3 and 4. The assessment is revised if the character of the processing changes.

6. Transfer Impact Assessment (TIA)

For every sub-processor outside the EU/EEA, the transfer basis is the European Commission's Standard Contractual Clauses (2021/914); several suppliers are additionally certified under the EU-US Data Privacy Framework. The assessment of US law (including FISA 702 and the CLOUD Act) is:

• The character of the material: campaign material and contact data for business customers have a low likelihood of being a target for intelligence gathering.
• Supplementary measures: encryption in transit (TLS 1.2+), encryption at rest with the suppliers, data minimization per operation, short deletion deadlines and contractual no-training terms where documented.
• The suppliers' obligations: the SCC clauses oblige the suppliers to challenge disproportionate government requests and to notify where that is lawful.
• Residual risk: assessed as low. For suppliers where no-training or retention terms are not yet confirmed in writing (see the DPA list), the assessment is provisional and the material is limited; it is updated once the confirmations are in place.

Transfers per supplier, purpose, data categories and the status of confirmations appear in the sub-processor list in the data processing agreement, which forms part of this TIA.

7. Review

The document is reviewed on every change to the architecture or the sub-processor list, and at least once a year. Questions and requests for further documentation (data flow diagram, sub-processor roles, a copy of the assessment basis) should be sent to support@launchr.dk.