Data processing
Overview for customers using Quinn with personal or health-related data. The final DPA must be concluded as a contract with concrete parties, sub-processors and periods.
Last updated: May 2026
Role
Quinn as processor, customer as controller
Data types
Account, organisation, audio, transcript, documentation and audit data
Technology
Tenant separation, access protection, logging, private storage paths
Access
Roles, organisations and protected app areas
DPA structure
Quinn processes personal data to provide customers with documentation workflows, team management, AI-supported draft creation, storage, approval, export and support.
The customer is generally the controller for data relating to its data subjects, employees and organisation. Quinn acts as processor for processed customer data unless its own controllership applies.
Data subjects may include users, the customer's employees, people in need of care, relatives, contact persons and other people mentioned in documentation workflows.
Processed data may include identification and contact data, account data, roles, audio content, transcripts, free text, care and health information, SIS-related content, metadata, audit logs and export data.
Quinn generally processes customer data only on documented customer instruction, unless a statutory obligation prevents this. Product configuration, application use and support requests can specify instructions.
Sub-processors must be finally listed before go-live. Expected categories are hosting, database, storage, authentication, AI processing, error analysis and, where applicable, billing.
The intended measures include access control, role-based permissions, organisation boundaries, protected storage areas, audit logs, transport encryption, controlled admin access, backup and recovery processes and incident processes.
After contract end, customer data is deleted or provided in an appropriate form according to instructions, unless statutory obligations or legitimate evidence purposes prevent this. Concrete periods must be contractually defined.
Quinn supports customers as required with data subject rights, security incidents, data protection impact assessments and evidence, insofar as the information lies within Quinn's area of responsibility.
Customers receive appropriate evidence of compliance with the agreed measures. Scope, form and frequency of audits must be regulated in the final DPA.
TOM
Access control
Login, Supabase Auth, protected routes, roles and organisation context
Admission control
Private storage paths, service role server-side only, RLS policies and API context
Transfer control
Controlled exports, audit logs, no public audio or PDF paths
Input control
Logging of creation, editing, approval, export and team actions
Tenant separation
Organisation ID in data model, RLS and server-side auth context
Availability
Finalise backup, restore, monitoring and incident processes according to compliance documentation
Privacy by design
Approval before export, drafts instead of automatic final documentation, clear user responsibility