Data Processing Agreement

1. Parties and roles

The Controller is the brand operating an onpack account. The Processor is Onpack GmbH, Nibelungengasse 1, 1010 Vienna, Austria — see the Impressum for full corporate identification.

The split is not uniform across the platform, and pretending it were would make this document useless in the one place it matters. onpack is the Processor for everything a brand does with its own product and scan data. onpack is an independent Controller for collector accounts — a collector signs up with onpack, holds one collection across every brand they scan, and the brand never receives their email address. The consequence is stated plainly rather than buried: a brand cannot instruct us to hand over collector identities, because they are not the brand's to instruct us about.

2. Subject matter, duration, nature and purpose (Art. 28(3))

• Subject matter: provision of the onpack platform — unit identity generation, product passports, scan resolution, analytics and, where the brand uses them, loyalty and promotion mechanics.
• Duration: for as long as the brand account is open, plus the retention period in §7 below.
• Nature and purpose: hosting, storage, retrieval, aggregation and display of the data the brand uploads or generates through use of the platform.
• Types of personal data: brand account contact details and sign-in records (time, IP address, approximate location, browser); scan metadata (timestamp, device type, approximate country, and IP address where the collector consented); and, where a collector has claimed a unit or redeemed a reward, the identifiers that link that action to the brand's records.
• Categories of data subject: the brand's own staff with platform access, and consumers who scan the brand's products.

3. Processor obligations (Art. 28(3)(a)–(h))

1. Documented instructions. We process personal data only on the brand's documented instructions, of which use of the platform and this agreement are the standing form, including as to third-country transfers — unless required otherwise by EU or Member State law, in which case we tell the brand before processing unless that law forbids it.
2. Confidentiality. Everyone we authorise to process the data is bound to confidentiality.
3. Security. We take the Art. 32 measures set out in Annex 1.
4. Subprocessors. The brand gives general authorisation for the subprocessors listed at /subprocessors. We give thirty days' notice before adding or replacing one, and the brand may object; if the objection cannot be resolved, the brand may terminate the affected service without penalty. Each subprocessor is bound by terms no less protective than these.
5. Data subject rights. We assist the brand, by appropriate technical and organisational measures, in answering requests under Chapter III. Requests reaching us directly about brand-controlled data are forwarded rather than answered.
6. Arts. 32–36. We assist the brand in meeting its security, breach-notification and impact-assessment obligations, taking into account the nature of processing and the information available to us.
7. Deletion or return. On termination, at the brand's choice, we delete or return the personal data, subject to the retention period in §7 and to any storage EU or Member State law requires.
8. Audit. We make available the information needed to demonstrate compliance with Art. 28 and allow for and contribute to audits, including inspections, conducted by the brand or an auditor it mandates. In practice this means answering a security questionnaire and, on reasonable notice and no more than once a year absent an incident, a remote audit session.

4. Personal data breach

We notify the brand without undue delay and in any case within 48 hours of becoming aware of a personal data breach affecting the brand's data, with the information available at that point, and supplement it as the picture fills in. Notification goes to the account's registered address. Report a suspected breach to [email protected].

5. Subprocessors

The current list, with each provider's purpose, location and transfer basis, is at /subprocessors and forms Annex III to this agreement.

6. International transfers

The platform and its database run in Germany. Of the 9 subprocessors, 7 involve a transfer outside the EEA — CDN, outbound email, billing, an IP-to-country lookup, and media storage. Each is covered by the Standard Contractual Clauses under Art. 46(2)(c) GDPR incorporated in that provider's own data processing agreement. Where a provider is additionally certified under the EU–US Data Privacy Framework, we treat that as an alternative rather than a substitute for the clauses.

7. Retention and deletion

Closing a brand account takes its public product pages down immediately. The product records behind them — passports, published versions and supporting documents — are kept for at least a year afterwards, and longer while any production lot on record is still within its date of minimum durability, because packaging stays in circulation after a business relationship ends and a product page that vanishes while the jar is on a shelf leaves a shopper with no ingredient or allergen information. This is a retention obligation we hold as controller for our own compliance purposes, and it overrides a deletion instruction to that extent. The brand can ask for the underlying data to be returned at any point during it.

8. Liability and governing law

Liability follows the Terms of Service. This agreement is governed by Austrian law; Art. 82 GDPR applies regardless.

Annex 1 — Technical and organisational measures (Art. 32)

Stated at the level we can actually stand behind. There is no certification behind these — onpack holds no ISO 27001 or SOC 2 — and claiming a control we do not operate would be the one failure this annex cannot afford.

• Encryption in transit: public websites and APIs use HTTPS. The application-to-database connection runs on the private container network on the same host; this internal connection is not currently TLS-encrypted.
• Encryption at rest: database backups are encrypted; sensitive application secrets use application-level encryption. This annex does not claim full-disk encryption of the database host.
• Access control: server-side role and account checks restrict access to brand data. Administrators can require two-factor authentication for their company.
• Authentication: passwords are hashed with bcrypt. Brand accounts support authenticator-app two-factor authentication and recovery codes. API tokens are stored as hashes and shown only at creation.
• API access: tokens support product-specific read/write permissions and optional restriction to a single brand. Company-wide tokens can access authorised brands within that company, never another company's data.
• Logging: application and access logs retained for incident investigation, with collector IP addresses and request headers stripped before anything reaches our error-monitoring provider.
• Backups: encrypted database backups held within the EEA.
• Resilience: database backups run four times daily. Recovery procedures include restoring into an isolated database and verifying the restored data.
• Development: automated test suite and static security analysis run on every change before it reaches production.