Data processing agreement
Last updated: October 9, 2026
This data processing agreement (“DPA”) is part of the terms of service between the customer (the “controller”) and QR Studio (the “processor”) for the use of QR Studio. It applies when a customer uses the service for business purposes and, in doing so, has us process personal data of its visitors, customers or contacts.
It doesn't cover the data of the customer's own account (name, email, billing): we process that as controller, as described in the privacy policy. Accepting the terms of service also accepts this DPA; no signature is needed. Questions: —.
1. Subject matter and duration
We process personal data only to provide the service: hosting and redirecting the customer's QR codes, showing its hosted pages, recording and displaying scan statistics, collecting answers to its forms and queues, and sending the reports and webhooks it sets up. Annex 1 describes the data and the people concerned.
This DPA lasts as long as the customer uses the service, and until the data has been deleted as set out in section 9.
2. Instructions
We process the data only on the customer's documented instructions: these terms, this DPA and the way the customer configures and uses the service. We don't use it for our own purposes and don't sell it. If we believe an instruction breaks data protection law, we'll tell the customer. If EU or member-state law requires other processing, we'll inform the customer first unless that law forbids it.
The customer is responsible for the lawfulness of the processing it asks for: having a legal basis, informing its visitors (for example in its own privacy notice) and not collecting special categories of data through the service.
3. Confidentiality
Everyone we authorise to access the data is bound by confidentiality, by contract or by law, and accesses it only as needed to run and support the service.
4. Security
We apply the technical and organisational measures in Annex 2, appropriate to the risk. We may update them as technology evolves, without lowering the overall level of protection.
5. Sub-processors
The customer gives a general authorisation to use the sub-processors in Annex 3. We impose on them data protection obligations equivalent to this DPA and remain responsible for them.
We'll announce new or replaced sub-processors on this page and by email to account owners at least 30 days before the change. The customer may object on reasonable data protection grounds; if we can't find a solution, it may close its account before the change takes effect.
6. Transfers outside the EEA
We prefer providers and data centres in the European Economic Area. Where a sub-processor processes data outside it, the transfer relies on an adequacy decision (such as the EU–US Data Privacy Framework) or on the European Commission's standard contractual clauses.
7. Data subjects' rights
The service lets the customer handle requests itself: it can delete codes and pages, reset a code's statistics, delete form answers and export its data. If a request reaches us directly, we'll forward it to the customer without undue delay and won't answer it ourselves unless instructed. We'll assist with anything the tools don't cover.
8. Breaches and other assistance
We'll notify the customer of a personal data breach affecting its data without undue delay, and in any case within 48 hours of becoming aware of it, with the information available at the time: what happened, the data and people concerned, likely consequences and the measures taken. We'll add details as we learn them.
Taking into account the nature of the processing and the information available to us, we'll assist the customer with security, breach notifications, data protection impact assessments and prior consultations (Art. 32–36 GDPR).
9. Deletion at the end of the service
Before closing its account the customer can export its data. Deleting a code, a page or the account removes the related data from the live database immediately; copies in backups are overwritten as backups expire, within 30 days. We don't keep the data afterwards unless the law requires it.
10. Information and audits
We'll make available the information needed to demonstrate compliance with Art. 28 GDPR, starting with this DPA and its annexes, and answer reasonable written questions. If that isn't enough, the customer, or an independent auditor it appoints and bound by confidentiality, may carry out an audit once a year with 30 days' notice, at its own cost and without disrupting the service; more often only where a supervisory authority requires it or after a breach.
11. Liability and order of precedence
Liability is governed by the terms of service, within the limits allowed by Art. 82 GDPR. On data protection matters this DPA prevails over the terms of service. It's governed by the same law as the terms.
Annex 1 – Description of the processing
- People concerned
- People who scan the customer's codes; people who fill in its forms (feedback, registration) or take a number in its queues; people whose details the customer publishes (for example on a contact card).
- Personal data
- Scans: date and time, device type, operating system, browser, language, approximate location (country, region, city), referring site and a pseudonymous visitor identifier; IP addresses aren't stored. Forms and queues: what people enter, for example name, email, phone and answers. Content: texts, contact details and files the customer publishes.
- Special categories
- None intended. The customer must not collect them through the service.
- Nature and purpose
- Storage, redirection, display and statistics needed to provide the service to the customer; sending reports and webhooks it sets up.
- Duration
- Until the customer deletes the data, the code or its account (see section 9).
Annex 2 – Technical and organisational measures
Measures in place today:
- Encryption in transit: every page, the API and webhooks use HTTPS (TLS).
- Passwords are stored only as salted scrypt hashes; two-factor authentication (TOTP) with recovery codes is available, and its secrets are encrypted at rest.
- API keys are shown once and stored only as hashes; webhooks are signed (HMAC) and can't reach private network addresses.
- Sessions are kept on the server, can be revoked from the account page and expire after 30 days of inactivity.
- Access control: each workspace sees only its own data; team members have roles (owner, editor, viewer); administrative access is limited to the provider.
- Data minimisation: scanners' IP addresses aren't stored, visitors are counted with a random identifier or a keyed one-way hash, and known bots aren't recorded.
- Rate limits on sign-in, the API and public forms; abuse reports can disable codes.
- Regular database backups; errors are monitored and logs are accessible only to the provider.
- Deleting a code, a page or an account removes its data from the live database immediately.
Annex 3 – Sub-processors
Sub-processors in use on this installation:
| Provider | Purpose | Location |
|---|---|---|
| Our hosting provider (details on request) | Servers and database | — |
| Cloudflare, Inc. (R2) | Storage of uploaded files | May involve transfers outside the EEA, covered by standard contractual clauses / Data Privacy Framework |
| Resend, Inc. | Sending emails | May involve transfers outside the EEA, covered by standard contractual clauses / Data Privacy Framework |
Payment providers process billing data of the customer's own account as independent controllers and aren't sub-processors under this DPA.