Data Processing Agreement: DPP Host owner services

Version of 29 October 2026 (2026-10-29.3)

This text is published in English only.

Parties

The Brand (controller): the business named in its Organisation in the DPP Host Dashboard, acting through that Organisation. The Brand accepts this agreement in the Dashboard: an admin accepts it by a click in the Owner services settings, and accepting the Terms of Service is also accepting this agreement (clause 1.3 of the Terms of Service). DPP Host records who accepted which version and when.

Qubites ApS (processor), trading as DPP Host: Ulsøparken 49, 2. tv., 2660 Brøndby Strand, Denmark, CVR 37061026. Contact: privacy@dpphost.eu (data protection), hello@dpphost.eu (general).

1. Purpose and structure

1.1 The Brand uses DPP Host under the DPP Host Terms of Service (the "Main Terms"). When the Brand uses owner services, and in the other cases in Annex I, Qubites processes personal data on the Brand's behalf. This agreement sets the terms of that processing, as required by Article 28 of Regulation (EU) 2016/679 (the "GDPR") and the Danish Data Protection Act (databeskyttelsesloven, Act No. 502 of 23 May 2018).

1.2 The annexes are part of this agreement:

• Annex I: description of the processing
• Annex II: technical and organisational security measures
• Annex III: sub-processors

1.3 If this agreement conflicts with the Main Terms on the processing of personal data, this agreement prevails.

2. Definitions

Words defined in the GDPR (such as "personal data", "processing", "controller", "processor", "data subject" and "personal data breach") have the same meaning here. In addition:

• Owner services: the Premium module of DPP Host that lets people who have one of the Brand's items register it with the Brand, see the guarantee, ask for a repair, see the Brand's and its partners' offers, hand the item over at resale and mark it lost or stolen. It runs at app.dpphost.eu/owner/{handle}.
• Owner: a person who opens an owner account with the Brand in owner services, including a person who disputes a registration.
• Owner data: the personal data described in Annex I part A.
• Sub-processor: another processor that Qubites engages to process Owner data or other personal data covered by this agreement.

3. Roles and scope

3.1 The Brand is the controller and Qubites is the processor of the personal data in Annex I parts A, C and D, and of part B from the date Qubites gives notice under clause 4.4 and the Brand instructs it in writing. The Brand decides whether owner services run, which services and offers exist and how requests are handled.

3.2 This agreement does not cover personal data that Qubites processes as controller for its own purposes. Qubites' privacy notice covers that data: the accounts of the Brand's team members in the dashboard, invitations, partner organisations with their staff accounts, links and invitations, billing through Stripe, notices about content under the Digital Services Act, and Qubites' own security records.

3.3 Qubites processes Owner data only to provide owner services to the Brand. Qubites does not:

• use Owner data for its own purposes;
• combine it across brands (there is no cross-brand view of an owner's items);
• sell it;
• use it for marketing, analytics or profiling;
• use it to train or prompt AI models. Owner data is not sent to any AI model, and the DPP Host MCP server has no owner tools.

If Qubites determined the purposes and means of processing in breach of this agreement, it would be a controller for that processing (Art. 28(10)).

4. Instructions

4.1 Qubites processes the personal data covered by this agreement only on the Brand's documented instructions, including with regard to transfers to a third country, unless Union or Member State law requires otherwise. In that case Qubites informs the Brand of the legal requirement before processing, unless that law prohibits it on important grounds of public interest (Art. 28(3)(a), Art. 29).

4.2 The Brand's documented instructions are:

• (a) this agreement and Annex I;
• (b) the Brand's use and configuration of owner services in the dashboard and through the API. This covers turning the module on or off, settings, guarantees, offers, issuing claim codes, releasing registrations, freezing or unfreezing items and changing request status. Each of these actions is recorded. Actions by the Brand's members, including the staff of a partner the Brand linked to its organisation, are the Brand's instructions;
• (c) any further written instruction from the Brand to privacy@dpphost.eu that Qubites accepts in writing. An instruction that changes how owner services work for all brands may need a change to the service. Qubites may decline it, and the Brand may then end its use of owner services.

4.3 Qubites informs the Brand immediately if, in its opinion, an instruction infringes the GDPR or other Union or Member State data protection law (Art. 28(3), second subparagraph). Qubites may suspend that instruction until the Brand withdraws it or changes it so that it no longer infringes the law. Qubites is not obliged to carry out an instruction that it reasonably considers unlawful.

4.4 Qubites gives the Brand at least 30 days' notice, by email to the Brand's admins, of a change to owner services that changes the categories of Owner data, the purposes or the retention in Annex I. Security fixes and changes that reduce the processing may take effect at once.

4.5 The Brand is responsible, as controller, for:

• (a) having a legal basis for the processing, and for telling owners about it. The Brand gives the address of its privacy notice in the owner-services settings, and the owner area links to it;
• (b) the content it configures: the name shown to owners, its support address, guarantee terms, the guarantor's name and address, and offers;
• (c) its duties as seller or guarantor towards consumers. That includes the seller's liability for lack of conformity (Directive (EU) 2019/771 Art. 10), the content and delivery of a commercial guarantee statement (Art. 17 of that Directive), pre-contractual information on the legal guarantee of conformity, commercial guarantees (including a producer's commercial guarantee of durability) and after-sales services, using the harmonised notice and harmonised label where they apply (Directive 2011/83/EU, Arts. 5(1) and 6(1) and Art. 22a, as amended by Directive (EU) 2024/825), and the fairness of its offers (Directive 2005/29/EC as amended by Directive (EU) 2024/825). The owner area always shows the legal guarantee text separately from any commercial guarantee. It does not replace the Brand's own information;
• (d) the offers it or its partners make. DPP Host shows an offer only as a labelled link. It shows no price, sells and prices nothing, takes no commission and adds no Owner data to the link. The link opens with rel="noopener noreferrer", so the provider does not receive the owner-area address as referrer. The Brand will not ask Qubites to pass Owner data to an offer provider or to take any other step towards concluding an insurance contract (Directive (EU) 2016/97);
• (e) answering owners' repair requests and disputes, and any marketing it sends to owners who consented. The Brand does this from its own systems. Qubites sends owners no marketing. The only emails it sends owners are the service emails listed for Resend in Annex III part 1: sign-in and confirmation emails, the care reminders an owner turns on, the Brand's safety notices and safety address confirmations, registration links, and the handover links a shop asks DPP Host to send its customer;
• (f) carrying out any data protection impact assessment (Art. 35), with Qubites' help under clause 10;
• (g) not putting personal data into product passports, product pages, media or imports beyond what the law requires the passport to show (Annex I part D).

4.6 A partner in the DPP Host partner programme (the Partner Terms) that the Brand links to its organisation acts for the Brand. It is not an offer provider under clause 4.5(d). Qubites does not engage it, so it is not a sub-processor of Qubites and is not listed in Annex III. Where the partner processes personal data for the Brand, the Brand and the partner agree the terms of that processing between them (Art. 28(3)); partner staff act under the Brand's authority (Art. 29).

5. Confidentiality

5.1 Qubites ensures that the people it authorises to process personal data under this agreement have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality (Art. 28(3)(b)). The duty continues after their engagement ends.

5.2 Access is limited to the people who need it to run, secure and support the service (Annex II, section 2).

6. Security

6.1 Qubites takes the measures required by Article 32, as described in Annex II (Art. 28(3)(c)).

6.2 Qubites may change these measures, as long as the overall level of security does not decrease. Qubites keeps Annex II up to date and gives the Brand the current version on request.

7. Sub-processors

7.1 The Brand gives Qubites general written authorisation to engage sub-processors (Art. 28(2)). The sub-processors in use on the date of this agreement are listed in Annex III, part 1.

7.2 By a contract, Qubites imposes on each sub-processor the same data protection obligations as are set out in this agreement, in particular sufficient guarantees to implement appropriate technical and organisational measures so that the processing meets the requirements of the GDPR (Art. 28(4)). Where a sub-processor's standard terms are worded differently, Qubites checks that they give at least the protection this agreement requires, and records that check.

7.3 Qubites informs the Brand of any intended addition or replacement of a sub-processor at least 30 days before the new sub-processor processes personal data covered by this agreement. The notice goes by email to the Brand's owners and admins and on the list of sub-processors. It names the sub-processor, its location, what it does and the transfer mechanism, if any.

7.4 The Brand may object in writing to privacy@dpphost.eu within that notice period, on reasonable data protection grounds. The parties then try in good faith to find a solution. If they find none before the change takes effect, the Brand may end its use of owner services (and of any other affected service) with effect from that date, without penalty. Prepaid fees for the affected service are refunded pro rata under clause 5.13(f) of the Main Terms.

7.5 If Qubites must replace a sub-processor urgently to keep the service secure or available, it gives the notice in clause 7.3 as early as possible, and in any case before the new sub-processor processes personal data covered by this agreement. Where the emergency allows, it gives at least 5 working days' notice. The Brand may object under clause 7.4 during that time. If it does and no solution is found, it may end its use of owner services at once, without penalty.

7.6 The services in Annex III, part 3 are not in use and are not authorised by this agreement until Qubites has given notice under clause 7.3.

7.7 Qubites remains fully liable to the Brand for the performance of its sub-processors' obligations (Art. 28(4)).

8. Transfers outside the EEA

8.1 Owner data is stored in the EU: the database in Frankfurt, Germany (Supabase), and the receipts shops add in Cloudflare R2's EU jurisdiction (Annex II §1). The exception is Resend's copy of each email it sends, with its sending log, which Resend keeps in the United States for 30 days (clause 8.2(c)). Supabase's Edge Functions, including the one that sends the request notices to the Brand's admins, also run in Frankfurt: every call to them is pinned to that region, and a function refuses, without reading it, a call that reaches it in another region. Annex III states for each sub-processor where it processes data and the transfer mechanism it relies on.

8.2 Some processing can take place outside the EEA:

• (a) Cloudflare's network handles requests to DPP Host, including the owner area, at the Cloudflare data centre nearest to the visitor. That can be outside the EEA, especially for visitors outside Europe;
• (b) the US parent companies of Supabase, Cloudflare and Resend may access data remotely, for example for support or security;
• (c) Resend keeps a copy of each email it sends, and its sending log, in the United States for 30 days. For owners, that is their email address and the one-time sign-in or confirmation link; for the Brand's request notices, item identifiers and references (pseudonymous Owner data, Annex I A.7).

Those transfers rely on the Commission's standard contractual clauses (Implementing Decision (EU) 2021/914) in the providers' data processing agreements, and on the EU-US Data Privacy Framework where the provider is certified.

8.3 Qubites does not otherwise transfer personal data covered by this agreement outside the EEA, except on the Brand's documented instruction and under Chapter V GDPR.

9. Help with data subject rights

9.1 Qubites helps the Brand, by appropriate technical and organisational measures, as far as possible, to respond to requests from data subjects to exercise their rights under Chapter III GDPR (Art. 28(3)(e)).

9.2 Owner services provide these self-service tools to owners, on the Brand's behalf:

• Access and portability (Arts. 15, 20): "Download my data" returns, as JSON, the owner's account (email address, language, created and last-seen times, the version and text of the statement it was opened with), consents with the text each was given on, registrations with any guarantee registration and the reason of a current lost or stolen mark, requests with their text, the receipts the owner kept (type, size, the day the shop added it and the shop; never the file, which the owner downloads from the product page), and the item-log entries linked to the owner (event and time). The export names the Brand as controller and Qubites as processor. It does not contain the sign-in records (confirmation and sign-in times, sessions and their IP addresses, the sign-in event log), who set a mark, the details of item-log entries or the abuse-limit counters. Qubites provides those on the Brand's instruction under clause 9.3.
• Erasure (Art. 17): "Delete my account" works at once. It removes the account and consents, ends active registrations, deletes guarantee registrations and the text of requests, and removes the owner's link from the item log. The sign-in identity is deleted too if the address has no other owner account and no dashboard membership.
• Withdrawing marketing consent (Art. 7(3), Art. 21(3)): one action, recorded with its time.
• Rectification (Art. 16): owners can change the guarantee registration (purchase date, place of purchase) while the module is live. Other rectification, such as changing the email address, needs the Brand or Qubites (clause 9.3).

9.3 If a data subject request reaches Qubites, Qubites forwards it to the Brand's support address within 5 working days and does not answer it itself, unless the Brand instructs otherwise. For a request that the self-service tools do not cover (for example rectifying an email address, restriction under Art. 18, or erasure requested through the Brand), Qubites carries out the Brand's written instruction within 10 working days.

10. Help with security, breaches, impact assessments and consultation

10.1 Qubites helps the Brand meet its obligations under Articles 32 to 36, taking into account the nature of processing and the information available to Qubites (Art. 28(3)(f)). In particular, Qubites:

• (a) notifies breaches under clause 11;
• (b) provides, for the Brand's data protection impact assessment, this agreement and its annexes, a description of the data flows, and answers to reasonable questions. Before the first Brand starts owner services, Qubites prepares a written description of the processing, its data flows and the risks it sees from the processor's side, and gives it to the Brand for use in its DPIA;
• (c) helps with a prior consultation of a supervisory authority (Art. 36), if the Brand's DPIA requires one.

10.2 Help beyond what this agreement and the self-service tools provide may be charged at rates agreed in writing in advance, except where the help is needed because of a breach of this agreement by Qubites.

11. Personal data breaches

11.1 Qubites notifies the Brand of a personal data breach affecting personal data covered by this agreement without undue delay after becoming aware of it (Art. 33(2)). Qubites aims to notify within 24 hours and does so at the latest within 48 hours.

11.2 The notice goes to the email addresses of the Brand's admins and to any data protection contact the Brand has named to Qubites in writing. As far as known at the time, it describes:

• the nature of the breach, including the categories and approximate number of data subjects and of records concerned;
• the likely consequences;
• the measures taken or proposed, including measures to mitigate its possible adverse effects;
• a contact person at Qubites.

Information that is not yet available is given in phases, without further undue delay (Art. 33(4)).

11.3 Qubites takes reasonable steps at once to contain the breach and limit its effects. It documents the facts, effects and remedial action, and gives the Brand the documentation it needs for its own records (Art. 33(5)).

11.4 The Brand decides whether to notify the supervisory authority and the data subjects (Arts. 33, 34). Qubites does not notify them on the Brand's behalf unless the Brand instructs it to, or the law requires Qubites to.

12. End of the processing: deletion or return

12.1 When the Main Terms end, or the Brand stops using owner services and asks Qubites to end the processing, the Brand may instruct Qubites in writing to:

• (a) delete the Owner data; or
• (b) first return it as a JSON or CSV export and then delete it (Art. 28(3)(g)).

12.2 Unless the Brand instructs otherwise in writing before the end date, Qubites keeps the owner area open, paused, for 90 days after the end so that Owners can download or delete their data, and then deletes all Owner data within 30 days. If the Brand instructs deletion, or return and deletion, Qubites carries it out within 30 days of the instruction. Deleted data leaves the encrypted backups within 7 days. Qubites confirms the deletion in writing.

12.3 Qubites may keep personal data only where Union or Member State law requires it to be stored. It then keeps it only as long as the law requires, protects it under this agreement and processes it for no other purpose.

12.4 Ending Premium is not the end of the processing. When the Brand's Premium plan ends, owner services pause. New registrations, handovers and requests stop and offers are no longer shown. Owners keep access to their items, to "Download my data" and to "Delete my account", and Qubites keeps processing the Owner data under this agreement until clause 12.1 applies.

12.5 The retention periods during the term are in Annex I, part A.6.

12.6 For personal data in Annex I parts C and D, clause 16.5 of the Main Terms applies: 90 days after the Main Terms end, Qubites deletes Drafts, unpublished values, supplier contacts and evidence that no published passport version cites. Before then, the Brand can take the Organisation Export (Main Terms clause 15.9). Published passport versions stay available under clause 15 of the Main Terms.

13. Information and audits

13.1 Qubites makes available to the Brand all information necessary to demonstrate compliance with Article 28. It allows for and contributes to audits, including inspections, by the Brand or an auditor the Brand mandates (Art. 28(3)(h)).

13.2 Qubites meets requests first with documents: this agreement and its annexes, its record of processing activities, security documentation, and the sub-processors' certifications or audit reports, where available (for example SOC 2 or ISO/IEC 27001 reports).

13.3 If those documents are not enough, or after a personal data breach, or when a supervisory authority asks, the Brand may carry out an audit or inspection itself or through an independent auditor. The auditor must be bound by confidentiality and must not be a competitor of Qubites. Conditions:

• at least 30 days' written notice, except after a breach or at a supervisory authority's request;
• during normal business hours;
• without access to other customers' data;
• at most once a year, except after a breach or at a supervisory authority's request.

The Brand bears its own costs. Qubites' reasonable costs beyond one working day per audit are charged, unless the audit finds a material breach by Qubites.

13.4 Audits of sub-processors are carried out through the rights Qubites has under its contracts with them.

14. Records and cooperation

14.1 Qubites keeps a record of the processing it carries out on behalf of controllers (Art. 30(2)) and makes it available to the supervisory authority on request.

14.2 Qubites cooperates with the supervisory authority on request (Art. 31). Qubites' authority is Datatilsynet (Denmark).

15. Liability

15.1 Each party's liability under this agreement is governed by the limitation-of-liability provisions of the Main Terms.

15.2 Nothing in this agreement limits either party's liability towards data subjects under Article 82 GDPR.

16. Term, changes, law and venue

16.1 This agreement applies from the date the Brand accepts it as long as Qubites processes personal data on the Brand's behalf, including after the Main Terms end until clause 12 has been carried out.

16.2 Qubites may update this agreement to reflect changes in the law, or changes to the service under clauses 4.4 and 7.3, with 30 days' notice. If the Brand does not accept a change to the processing terms, it may turn owner services off and end its use of them, without charge, before the change takes effect. Other changes need both parties' written agreement.

16.3 This agreement is governed by Danish law. Disputes go to the venue in clause 21 of the Main Terms.

Annex I: Description of the processing

Part A. Owner services (in use)

A.1 Subject matter. Running the Brand's owner area at app.dpphost.eu/owner/{handle}: owner accounts, registration of items, handovers, lost or stolen marks, guarantee registrations, repair requests and disputes, the item log, the Brand's inbox and item views, webhooks and API access for the Brand; care reminders by email that an owner turns on for an item, on the Brand's schedules; registrations per product and their export to the Brand; and a listing helper that prepares a resale text for the owner (nothing is sent to any platform). Also the Brand's safety notices (warnings and recalls) by email to the registered owners of the items in scope and to safety contacts: people who asked for the Brand's safety alerts for an item without an owner account, and registered owners who gave a separate safety address; and registration links the Brand has emailed to a customer. Also an Apple Wallet card that an owner adds for a registered item from the owner area, and the answers to the owner's devices that keep it up to date. Also a Google Wallet card that an owner adds the same way, kept as an object at Google and updated there. Also handovers face to face with a live QR code and at a distance with a code and the seller's 4-digit number, and a view-only proof of registration link an owner makes and shares. Also the customer's receipt that a shop the Brand linked adds to its handover of the Brand's products to that customer, kept for the owner if the customer keeps it at the take-over; and guarantee claims, beside repair requests, to which the owner may attach that receipt. Also which of the Brand's batteries is fitted to which of its e-bikes registered to the same owner (the battery link), the owner's own note. Also, while an owner has marked an item lost or stolen and lets finders message them, a line on the item's passport page that its owner is looking for it, and a form through which a finder sends the owner where the item is, a way to reach them and a message. Of these, the receipt, the finder's messages and Google Wallet cards are not available to Brands yet.

A.2 Duration. The term of this agreement (clause 16.1), subject to the retention periods in A.6.

A.3 Nature of the processing. Collection (from owners, from the Brand and from finders), storage, organisation, retrieval, consultation, use, disclosure to the Brand (dashboard, API, the owner's own export), restriction, erasure and anonymisation. The processing is automated, through database functions. People at Qubites do not handle Owner data in the normal course of the service.

A.4 Purposes. On the Brand's behalf:

• signing owners in by email, with passwordless one-time links;
• registering an item to its owner with a claim code, and handling disputes during the 14-day dispute window;
• handing an item over to a new owner with a one-time handover code;
• marking an item lost or stolen, privately, so that it cannot be registered or handed over;
• recording guarantee registrations and showing the legal guarantee and the Brand's commercial guarantee;
• passing repair requests, guarantee claims and disputes to the Brand;
• showing the Brand's and its partners' offers as links;
• recording consents and marketing preferences for the Brand;
• sending an owner the care reminders the owner turned on for an item, on the Brand's schedules and with the Brand's text, and stopping them when the owner withdraws (in the owner area or with the one-click link in each email), the registration ends or the module is not live;
• counting registrations per product for the Brand, and exporting to the Brand's admins the contact details of owners who agreed to hear from the Brand (everyone else counted without personal data);
• keeping safety contacts only to email them the Brand's safety notices for their item (GPSR Art. 35(2)), never for marketing, confirming a registered owner's separate safety address by a link, and stopping a safety contact's alerts with the one-click link in each email;
• emailing the Brand's safety notices to the registered owners and safety contacts of the items in scope, and counting for the Brand, without personal data, how many addresses a notice reaches and how many safety contacts each product has;
• emailing a customer, once, the registration link the Brand asks for;
• issuing an owner an Apple Wallet card for a registered item and answering the owner's devices that keep it up to date: the card shows the registration as it is when a device asks, and says when it has ended; when what it shows changes (a safety notice, the end of the registration, a lost or stolen mark, a guarantee, a buyer asking for the owner's handover number), telling those devices through Apple's push service, with the device's push token and an empty message;
• issuing an owner a Google Wallet card for a registered item: creating the card's content as an object at Google under Qubites' issuer account when the owner asks for it, and changing it there when what the card shows changes (the same events), so that Google updates the devices that saved it and notifies them of a safety notice or of the registration's end;
• handing a registration over: showing the seller a QR code that changes every few seconds and keeping a buyer's scan for 10 minutes; checking a buyer's code before payment; showing the seller a 4-digit number for the buyer once the buyer has signed in, and cancelling the handover after 3 wrong numbers; and making, showing and counting the views of a proof of registration link the owner shares (the product, its serial and batch, the Brand and the registration's start, and the owner's initials or, if the owner chooses, the full name; never the owner's email address or postal address);
• keeping the receipt a shop adds to its handover for the owner, if the customer keeps it at the take-over, so that only the owner sees and downloads it, and giving it to the Brand only for a repair request or guarantee claim the owner attaches it to, while that request is open or in progress;
• keeping the owner's note of which battery is fitted to which bike, so that each card names the other part and a handover between owners can carry both;
• while an owner has marked an item lost or stolen and lets finders message them: saying so on the item's passport page, never who the owner is; taking a finder's message through a form with a bot check and limits; passing it to the owner only (in the owner area, on the owner's wallet card, and as an email that says a message came); deleting it after 30 days, when the owner reports it (its sender is then refused for 7 days), or when the registration ends;
• keeping an item log for the Brand and the owner;
• limiting abuse (limits on guessing codes and on requests);
• giving owners their data and deleting it on request;
• keeping the service secure.

A.5 Data subjects and personal data.

Data subjects:

• owners and people disputing a registration (consumers and other end users of the Brand's products);
• earlier owners of an item (in the item history, without contact details);
• safety contacts: people who asked for the Brand's safety alerts for an item without an owner account;
• customers to whom the Brand had a registration link emailed;
• customers of a shop the Brand linked, whose receipt the shop adds to its handover before they take the products over (the receipt goes if they never do);
• finders: people who send the owner of an item marked lost or stolen a message through its passport page;
• the Brand's own dashboard members, as the actors of brand actions in the item log (a user id).

Personal data:

Category	What exactly	Source
Sign-in identity	Email address, confirmation and sign-in times, preferred language, a marker that the address signed up for owner services; when the owner continues with Apple or Google, the identifier at that provider and the name and email address it shares (DPP Host's own processing as controller)	Owner (Supabase Auth), Apple or Google at the owner's request
Sign-in sessions	Session and refresh-token records with the IP address and browser (user agent) of each sign-in, one-time sign-in tokens, and Supabase Auth's log of sign-in events (with IP address)	Owner's device (Supabase Auth)
Owner account	Account id, the Brand it belongs to, language, created and last-seen times; a display name (up to 60 characters, from the name the owner's Apple or Google sign-in shares, never from the email address, and as the owner changes or removes it) and whether proof of registration links show it in full	System, owner, Apple or Google at the owner's request
Consents	Purpose (service, marketing, or care reminders for one registered item), given or withdrawn, text version, language, time, and whether given in the owner area or withdrawn with the email link (append-only)	Owner
Care reminders	The dates a reminder was queued for a registration (schedule, registration, date), and the reminder emails themselves (recipient address, language, the Brand's text, the item, a one-click stop token until sent)	System, Brand's schedules
Registrations	Item (GTIN, serial, batch, product), how it was registered (claim code or handover), start and end times, end reason, dispute window	Owner and Brand
Safety contacts	Email address, language, the item (GTIN, batch and serial as the passport page names it), kind (safety alerts only, or a registered owner's separate safety address), status (pending, active, stopped), hashes of the confirmation and stop tokens, created, confirmed and stopped times	Safety contact or owner
Safety notice emails	Recipient address, language, the Brand's notice text, the serials and batches in scope, the passport link, and for a safety contact the one-click stop token and link until sent	System, Brand's notice
Registration link emails	The customer's email address, language, the product, serial and batch, and the claim link with its code until sent	Brand
Wallet cards	A random card number (never the product's serial), the platform (Apple or Google), the registration and item it belongs to, keyed hashes (HMAC) of the authentication tokens of the card's latest downloads (at most 10), the hash of a download link valid 5 minutes, created, updated and voided times; per device that keeps the card up to date, the device library identifier and the push token Apple gave it, and when it registered; per update a device is due, the card and the device, what changed (a code), the attempts and the last answer of Apple's push service. The card itself (the product, serial, batch, registration date, guarantee end, lost or stolen mark, the passport's link, the Brand's contacts) is built on request and handed to the owner's device; DPP Host keeps no copy. For a Google card: the id of its object at Google, and per update it is due, the card, what changed (a code), the attempts and Google's last answer; Google stores the card's content (the product, serial, batch, registration date, guarantee end, lost or stolen mark, the Brand's safety notices, the links to the owner area's page of the item and to the passport, the product photo's address) as the card's object	Owner, the owner's device
Lost or stolen mark	That an item is marked lost or stolen, when, and whether by the owner or the Brand. No police reports or other data on criminal offences are collected.	Owner or Brand
Handover codes	Keyed hash (HMAC) of the code, last four characters, expiry, status	System
Handovers	Face to face: a random key for the live QR code (its changing token is derived, never stored), the hash of the reservation of the browser that scanned it, when and until when. At a distance: the buyer's owner account once the buyer asks for the seller's number, the number's random nonce (the number is derived, never stored) and validity, the number of wrong tries. Why a handover was cancelled (the seller, "not my buyer", 3 wrong numbers). Face to face, also the buyer's owner account once the buyer asks for the product, until the seller confirms or turns the buyer down (when, and that the seller turned the buyer down); each side sees the other's first name and the initial of the last name, the seller also how the buyer signed in (Apple, Google or an email code)	System, buyer
Proof of registration links	The hash of the link's token, the registration and item, created and expiry times, how often it was opened and when last. Nothing about the person who opens it	Owner
Claim codes	Keyed hash (HMAC) of the code, last four characters, status and redemption time, linked to the registration	Brand, system
Guarantee registration	Purchase date, where bought (free text, up to 200 characters), guarantee months at registration	Owner
Receipts	The customer's receipt for the products of a shop's handover, as the shop adds it: one per handover (a second replaces the first), a PDF, JPEG or PNG file of at most 5 MB (at the counter a photo, redrawn upright as a JPEG, or a PDF; from WooCommerce the order's invoice PDF, only when the merchant turns this on, or a PDF or photo the shop's staff choose in the order; from Shopify a proof of purchase the app draws from the order's Level 1 fields, never a customer field, only when the merchant turns it on; or a file through the API). It may show the customer's name and address, other things bought and the last digits of a payment card. An image's metadata (EXIF, location included) is removed before it is stored; a PDF's own metadata (author, software) is not; no file name is kept. The file is kept only in Cloudflare R2 (a private bucket in the EU jurisdiction), never in the database. The database keeps the receipt's facts: its type, size and SHA-256, the Brand and the shop, where it came from (the counter, WooCommerce, Shopify or the API), who at the shop added it (the staff member, or the API key or shop connection) and when, and whether and when the customer kept it; and the SHA-256 of its single-use upload and download tickets (a download ticket names the owner, or the Brand's member and the request)	Shop; the customer chooses at the take-over whether it is kept
Battery links	Which of the Brand's batteries is fitted to which of its e-bikes, both registered to the same owner: the bike, the battery, its place (1 or 2), whether it is built in, how and when the link was made; the batteries a handover between owners carries with the bike; on a shop's battery swap, the bike and the batteries it takes back	Owner, shop, system
Finders' messages	Whether the owner lets finders message them about an item marked lost or stolen (the switch, and since when); a finder's message to the owner of a registered item: where the item is (up to 200 characters) and, if the finder adds them, the finder's location (rounded to about a metre, with its accuracy), a way to reach the finder (up to 100 characters, for example a phone number) and a message (up to 500 characters); when it came and whether the owner has opened it; a keyed hash of the finder's network address (never the address), so that a sender the owner reports can be refused; the refused hashes and until when. While the item looks, a marker in a private R2 bucket whose key is the SHA-256 of the item's path and whose content is only an expiry	Finder, owner, system
Repair requests and disputes	Reference, kind (a repair request, a dispute or a guarantee claim), the owner's message (free text, up to 2,000 characters), status and times; on a repair request or guarantee claim, the receipt the owner attached	Owner
Item log	Event kind, actor kind (owner, Brand, system), link to the owner account, user id of the Brand member for brand actions, time	System
Abuse limits	Counters of failed code attempts and of requests, keyed by the user id and the Brand	System
Technical data	IP address and request data in the providers' logs	Owner's device

What the Brand sees:

• Viewers see, for each item: whether it is registered, since when and how (claim code or handover), the purchase date and guarantee months the owner recorded, any lost or stolen mark and whether the owner or the Brand set it, the claim-code status and last four characters, the number of earlier registrations and the item log (event, kind of actor, time). They do not see the owner's email address, marketing choice, place of purchase, or requests.
• Editors and admins also see the registered owner's email address, marketing choice and place of purchase, and requests with their text and the requester's email address.
• Editors and admins see a receipt only when the owner attaches it to a repair request or guarantee claim, and only while that request is open or in progress: the request shows that a receipt is attached (its type and size). Downloading the file in the dashboard is not available yet; when it is, it will be in the dashboard only, never through the API or MCP, and each download recorded in the Brand's action log without the file. The Brand's action log also records when a shop adds, replaces or removes a receipt on a handover of the Brand's products (the file's type, never the file). The email about a guarantee claim to the Brand's admins says "Guarantee claim {reference} for {product}" and, when the receipt is attached, "The owner attached the receipt"; it carries nothing else about the owner (A.7). Viewers never see a receipt.
• Every member sees, per product and size, the number of active registrations, how many have care reminders on and how many owners agreed to hear from the Brand; and, per care reminder, how many owners have it on. Admins can export a file of registrations: owners who agreed to hear from the Brand appear with serial, registration date, email address, language and the date of that consent; everyone else only in a count per product and size. Each export is in the Brand's action log (counts only).
• Every member sees, per product, how many safety contacts it has, and for a safety notice how many addresses it reaches: each a number from 5 or "fewer than 5". No member sees or exports a safety contact's address, a registered owner's separate safety address included, or a customer's address after a registration link was sent.
• No member sees which battery is fitted to which bike, whether an owner lets finders message them, or a finder's message: the Brand sees the lost or stolen mark as before and, like anyone, the item's passport page, which says only that its owner is looking for it; while the owner looks, the Brand cannot lift or change the mark.
• The registered owner and a person who disputes the registration never see each other's identity. The Brand's editors and admins see both email addresses: the registered owner's on the item and the disputer's on the request.

The Brand can link the records viewers see to a customer through its own sales records (the serial number), so they are pseudonymous personal data.

Not collected: postal addresses, phone numbers or payment data; no name beyond the display name the owner keeps or removes (above); except on a receipt a shop adds (above), which may show the customer's name and address, other things bought and the last digits of a payment card. No other files. A finder may give a phone number or other contact details as the way to reach them, and types where the item is; only the owner sees them, for 30 days at most. No special categories of data (Art. 9) and no data on criminal convictions or offences (Art. 10). Owners can type anything into the free-text fields (requests, disputes, place of purchase), and finders into their message. The Brand should tell owners not to include sensitive data there.

A shop's invoice copies (the invoice link): the shop is the controller of the copies its system sends to its intake address and Qubites its processor under the Retailer Terms, not this agreement; Qubites keeps none of a copy. For the Brand, the sale it reports is a stock event ("sold" by the shop, before an owner registers the bike), as a counter sale; the registration through the link then takes the invoice date as the day of sale. No data of the Brand's owners reaches the shop through it.

A.6 Retention during the term (deleted by a daily job; the period is 1,095 days, platform-wide):

Data	Kept	Then
Owner account and consents	Until the owner deletes the account, or 1,095 days after the last sign-in if no registration is active	Deleted
Care reminders: dates queued	400 days after each date	Deleted (daily job)
Care reminder emails	As the other emails of the email queue: until the recipient's sign-in identity is deleted (the email queue's own deletion period is not switched on today); the stop token leaves the row once sent	Deleted
Sign-in identity (email)	Until the owner deletes the last owner account and has no dashboard membership; when the retention job deletes the last owner account, or the identity never opened one, until 30 days without a sign-in (never while the address has a dashboard membership). A sign-in made to turn on safety alerts only is deleted as soon as they are on, unless it has an owner account or a dashboard membership	Deleted
Safety contacts (safety alerts only)	Until the person stops them (the one-click link) or the Brand's organisation is deleted	Deleted by the next daily job after the stop
A registered owner's separate safety address	While the registration is active; unconfirmed, 7 days	Deleted when the registration ends, when stopped, or after 7 days unconfirmed
Safety notice and registration link emails	As the other emails of the email queue; the stop token and the confirmation, stop and claim links leave the row once sent or failed	Deleted
Wallet cards and their device entries	While the registration is active, and 90 days after it ends (the card then says the registration ended); a device's entry until the device removes the card or Apple's push service no longer knows its push token; after the owner deletes the account, 7 days (the card then says the registration ended); a pending update until Apple's push service accepted it, one that failed 30 days; a Google card's pending update until Google accepted it, one that failed 30 days; a Google card's object at Google: Google's API deletes none, and after the registration ends it holds only the product, its serial, the end's date, the Brand's contact and the passport's link, until Google removes it	Deleted by the daily job; a device's entry at once when the device removes the card
Sign-in sessions and sign-in event log	A session: until sign-out, and at most 30 days without use or 90 days in all. The sign-in event log (with IP addresses) is not kept in the database: Supabase keeps it in its logs for 7 days, the period of the plan in use	Deleted
Active registration	While active	—
Ended registration	Link to the owner for 1,095 days after it ended	Link removed; guarantee registration deleted; the anonymous history stays
Requests and disputes	Text and owner link while open or in progress, and for 1,095 days after closing. When the owner's account is deleted (by the owner or by the idle-account rule), the text of every request goes at once, open or closed	Text and link removed; reference, item and dates stay. Gap: the text of a request that is never closed stays until the owner's account is deleted, by the owner or by the idle-account rule
Item log	Link to the owner for 1,095 days after each entry	Link removed; anonymous entry stays with the item
Handover codes	30 days after creation, once used, cancelled or expired	Deleted
Handovers (QR reservations, the buyer's account, the number's nonce and tries)	With the handover: 30 days after creation, once used, cancelled or expired; the buyer's account link at once when the buyer deletes the account	Deleted
Proof of registration links	Until withdrawn or replaced by a new link; a day after the link expired (24 hours after it was made); at once when the registration ends (by the next daily run) or the owner deletes the account	Deleted (daily job)
Receipts	Before the take-over: until the shop removes or replaces it, or the handover ends without the customer. After it, if the customer kept it: while a registration that the shop's handover started is active (when the owner hands one product of the purchase over and keeps another, such as a bike handed over and its battery from the same sale kept, the receipt stays with the registration that remains), or until the owner removes it ("Remove": one file, gone for every product of that purchase). A receipt whose upload never finished: a day	Deleted, so that it never passes to the next owner: when the last registration of that purchase ends (a handover to a new owner, a release, the shop's return, the owner's account deletion); at the take-over, if the customer left it out or it was added or replaced after the customer looked; when the handover ends without the customer (cancelled or expired). Its object is deleted from R2 within the hour (the receipts service's deletion run, every 10 minutes); a daily job (03:47 UTC) is the backstop
Receipt tickets and deleted receipts' keys	Upload tickets 15 minutes and download tickets 60 seconds, each single use and stored only as a SHA-256: a day after a ticket was used or ran out. A deleted receipt's storage key, as a tombstone: 7 days after its object was deleted	Deleted (daily job)
Battery links	While both parts are registered to the same owner	Ended when either part's registration ends, when the owner takes the battery off, or when a part is marked lost or stolen on its own (a built-in battery's link stays); a handover's parts go with the handover
Finders' messages	30 days after the message came at most; until then while the registration it was sent to is active	Deleted (daily job, 03:59 UTC); at once when the owner reports it or the registration ends
Refused senders' hashes and the form's counters	A reported sender's hash 7 days; the counters a day	Deleted (daily job)
The finder marker in R2	While the item looks; each marker carries an expiry 72 hours ahead, renewed hourly while the item looks, and the bucket deletes objects after 7 days	Deleted by DPP Host's publishing service within minutes of the item no longer looking
Abuse-limit counters	At least 1 day	Deleted daily
Webhook deliveries (the outgoing queue and the delivery log)	30 days	Deleted. They hold item identifiers, references and event times: pseudonymous Owner data (A.7)
Database backups	Up to 7 days. Receipts are never in a backup: the database backups hold only their facts (A.5), and neither the nightly passport copy nor any other backup includes the receipts bucket	Overwritten
Emails sent through Resend (sign-in and confirmation emails to owners; request notices to the Brand's admins; safety notices, safety address confirmations and registration links)	A copy of each email and its sending log: 30 days, at Resend in the United States (clause 8.2(c))	Deleted by Resend
Provider logs (IP address)	Short-lived, per the providers' log retention	Deleted by the provider

When an owner deletes the account (clause 9.2), everything linked to the owner goes at once, a receipt kept for the owner included, whose object leaves R2 within the hour. The exceptions are backups, which roll off within 7 days, and Resend's copies of emails already sent, which Resend deletes after 30 days.

A.7 Where Owner data goes, and where it never goes. These carry no Owner data by design, and the database tests check it:

• the published passport versions;
• the passport and page files in Cloudflare R2; the pointer file a passport page reads carries only the owner area's random handle;
• the integrity hashes of passport versions and their timestamps (OpenTimestamps receives only a daily hash);
• any blockchain;
• the offer links;
• scan telemetry (no IP address, user agent, cookie, serial or passport id; country only);
• the service that reads a shop's invoice copies (A.5): from a shop's public code it can only look up the frame numbers of the bikes the shop holds and the format of its Brands' frame numbers, and record what it read (frame numbers, an invoice number, a date, a status). It reaches no Owner data, and the database tests check that.

Webhooks and emails to the Brand carry only item identifiers (GTIN, serial, the passport's address path), references and event times, never an email address, message, purchase date or place of purchase. Care reminder emails go only to the owner who turned them on. They carry no tracking pixel and no tracked link: their one image is DPP Host's logo and their only other remote content DPP Host's typeface, each one fixed file for every email and every reader on DPP Host's own domains, so fetching it does not tell who opened an email; and Resend's open and click tracking is off, so nothing reports back whether an owner opened or clicked one. The listing helper sends nothing to the platforms it names; the owner copies the text. Because the Brand can link a serial to its own sales records, these are pseudonymous Owner data. They go only to endpoints and addresses the Brand configures, and the webhook delivery records are deleted after 30 days.

Safety notices reach the passport pages with the Brand's text and their scope only (GTINs, batches, serials), never a safety contact or an owner; the webhook event safety_notice.published carries no address or count of people. Safety notice emails carry no tracking pixel and no tracked link (their one image is the logo described above).

A wallet card carries the registration as the owner sees it in the owner area, never the owner's email address or a claim or handover code, and cannot be shared from Wallet. It shows the owner's own display name; while a buyer at a distance waits for it, the seller's card shows the buyer's first name and initial and the seller's 4-digit handover number, which leaves the card when it stops working (10 minutes); after a handover the previous owner's card shows the new owner's first name and initial. Apple keeps it on the owner's devices and in the owner's iCloud under the owner's own terms with Apple. When the card changes, Apple's push service receives a device's push token and an empty message, nothing of the card; Qubites sends Apple nothing else. The Brand sees no card, device or count. For a Google Wallet card (not available to Brands yet), Google stores the card's content as an object under Qubites' issuer account, and once the owner saves it, in the owner's Google account under the owner's own terms with Google.

A receipt is stored only in a private Cloudflare R2 bucket of its own (EU jurisdiction), with no public access and no custom domain, written and read only by DPP Host's receipts service (receipts.dpphost.eu). Receipts never reach the published passport versions, the passport bucket, a backup (the database's backups hold only their facts, and the backup service has no access to the receipts bucket, so the nightly passport copy and the other backups never include it), an organisation export, a webhook or the item log. A receipt reaches the Brand only as a download by its editors and admins in the dashboard, for a repair request or guarantee claim the owner attached it to, while that request is open or in progress; never through the API or MCP. The webhook repair.requested carries the request's kind (repair or guarantee), never the receipt.

A finder's message reaches only the owner: the owner area, the owner's wallet card (on an Apple card the place the finder typed; Google's copy of a card holds none of it, only that a message came) and an email to the owner that says a message came, never the finder's words, place or contact. It never reaches the Brand (its views of items, exports, the item log, webhooks, emails, the API or MCP), a passport version, the passport bucket or any backup but the database's own (7 days). While an item looks, a private Cloudflare R2 bucket (EU jurisdiction, no public access, no custom domain) holds an object whose key is the SHA-256 of the item's path and whose content is only an expiry, written and deleted only by DPP Host's publishing service and read only by the service that serves the passport pages, which shows on the item's page "The owner is looking for this bike" (or battery, or product) and nothing about the owner. The battery link likewise never reaches the Brand, a webhook, the item log, an export or a passport.

No public page says whether an item is registered, frozen or disputed, or who owns it.

Part B. Wallet sign-in and item tokens (not available yet; not authorised by this agreement)

DPP Host does not offer this today. Before it could be switched on for the Brand, it would need an addendum to this agreement, the Brand's express instruction and a DPIA. The processing would be:

• Off-chain, in the owner area:
• the owner's wallet address or addresses, linked to the owner account;
• "sign in with your wallet" messages and one-time nonces;
• anything the owner chooses to add, such as a name for the item, a receipt, or contact details for a finder. The storage location is not chosen; it would not be passport storage;
• order data from the Brand, used to check before a mint that the sale is final (the 14-day withdrawal period under Directive 2011/83/EU Arts. 9–10, plus the Brand's return window).
• On a public blockchain (Arbitrum One or Base; not chosen): DPP Host's minter for the Brand would write a token for the item (derived from GTIN and serial) to the owner's wallet address. Transfers and freezes are public events. No name, email or customer number is written. But the address is personal data when it can be linked to a person (EDPB Guidelines 02/2025 on blockchain). Anyone who sees the item can look up the address and everything else it holds. What is written cannot be erased or rectified.
• The owner's own wallet provider (for example Coinbase Smart Wallet) is chosen by the owner and is not Qubites' sub-processor.

Part C. Supplier contacts

The Brand keeps its suppliers' contacts in the Dashboard (name, email, country, facility id, role, language) and may have DPP Host email a supplier a request with a one-time link to the supplier form. The supplier contact persons' names and email addresses are processed on the Brand's behalf (clause 3.1):

• purpose: asking suppliers for product data;
• retention: while the Brand keeps the supplier record;
• supplier requests expire after 30 days by default (the Brand may set 7 to 90 days).

Part D. Personal data in the Brand's own content (incidental)

Product passports, product pages, images, imports and labels are the Brand's content. DPP Host stores and publishes it on the Brand's instructions.

This content is not meant to contain personal data, beyond what the law requires a passport to show (for example the name and contact of the economic operator, which may be a sole trader). The acceptable-use rules forbid consumer personal data in it.

The makers a Brand that is an EU representative represents are content of this kind: each maker's legal name, address, country, a business email address and telephone number (both optional) and its written mandate as a PDF the Brand uploads (whose signatures may name people), kept so that the Brand's passports name the maker as the manufacturer, until the Brand removes the maker.

Files and a product page a member drops on New passport, to have the passport's values read from them, are content of this kind too. This reading is switched off for Brands today (Annex III part 2). When it is on, Qubites sends them once to Anthropic's API, whose Claude model reads them outside the EU; Anthropic deletes them and the answer within 30 days, and Qubites keeps no copy itself: they are read in memory and dropped with the request. The values found are kept as suggestions in the Brand's draft, each with the file's name (or the page's address), the page and a quote of at most 500 characters showing where it was found, until a person confirms, changes or discards it; then as the draft's values.

A certificate a Brand's supplier drops on the supplier form, to have the supplier's answers filled in from it, is content of this kind too: it is kept as the Brand's evidence like any file the supplier attaches, and, when this reading is on for the Brand (it is switched off for Brands today), Qubites sends it once to Anthropic's API as above, with the labels of the fields the Brand asked and nothing else of the Brand. The values found fill the supplier's answers on the form; nothing is kept from the reading but its count. Any personal data on the certificate (for example a test engineer's name or a signature) is the Brand's content as part of its evidence.

If personal data is published by mistake, the Brand asks Qubites to redact the version. For an erasure under Art. 17, Qubites can also delete the version's integrity salt for good, so its timestamp can no longer be tied to any content.

Published passport versions are public and kept long term (at least 10 years), because the law requires them to stay available. Import rows are deleted 90 days after the import ends. A spreadsheet a member keeps as a saved import (its rows, the columns' fields and the import's history) is deleted 90 days after the import is closed (done or discarded), or after 365 days without a change while it is still open.

Part E. Not covered

See clause 3.2: data Qubites processes as controller.

Annex II: Technical and organisational security measures (Art. 32)

This annex describes what the system does today.

1. Hosting and encryption

• Owner data is stored in a PostgreSQL database run by Supabase in Frankfurt, Germany.
• Encryption at rest of the database and its backups is provided by Supabase. Qubites adds no application-level encryption to owner tables. Secrets are encrypted in Supabase Vault: the code pepper, the API-key pepper and the webhook signing key.
• All traffic uses TLS. The owner area is served over HTTPS only (HSTS for one year, including subdomains).
• Passport and page objects are in Cloudflare R2 with EU jurisdiction. They contain no Owner data.
• Receipts that shops add are stored in a private Cloudflare R2 bucket of their own, in the EU jurisdiction, with no public access and no custom domain; never in the database, which keeps only their facts (Annex I A.5). Cloudflare encrypts every object in R2, with its metadata, at rest with AES-256 (Cloudflare's R2 data security page). Uploads and downloads go over TLS to DPP Host's receipts service (receipts.dpphost.eu).
• While an owner lets finders message them about an item marked lost or stolen, a private Cloudflare R2 bucket (EU jurisdiction, no public access, no custom domain) holds one marker per item: the SHA-256 of the item's path as its key and an expiry, nothing else; written and deleted only by DPP Host's publishing service and read only by the service that serves the passport pages. Finders' messages are stored in the database only.

2. Access control

• Row-level security is on for every owner table, with a deny-all policy and no grants to anonymous or signed-in database roles. All access goes through database functions that run with a fixed, empty search path.
• Owner functions only return the signed-in person's own account and items at that Brand. The only function callable without signing in returns the Brand's public details and offers, never anything about items or owners.
• Owners never become members of the Brand's organisation and have no dashboard access.
• Brand functions check the member's role:
• viewers see registration status and dates, purchase dates, marks and the item log, but not owners' email addresses, marketing choices, places of purchase or requests;
• editors and admins also see owners' email addresses, marketing choices, places of purchase and requests;
• only admins, in the dashboard, turn the module on or off.
• API keys need the scopes owners:read or owners:write (editor or above, Premium). Keys are stored only as an HMAC with a pepper in Vault and shown once.
• Finders' messages: the finder's form needs no account; Cloudflare Turnstile checks that a person sends it; limits per sender (a keyed hash of the network address, never the address), per item and per Brand; plain text without links; only the owner reads the messages, through the owner functions; no Brand function, API key or MCP grant reaches them.
• Receipts:
• only DPP Host's receipts service has access to the receipts bucket and writes or reads it; no other service does, the backup service included;
• a shop adds a receipt only to its own open handover, through its editors and admins, its API keys with the scope handovers:write or its shop connections;
• a receipt is uploaded and downloaded only with a single-use ticket of 256 bits (upload 15 minutes, download 60 seconds), handed out once and stored only as its SHA-256;
• only the owner gets download tickets, for the receipt of the owner's own active registration (at most 20 downloads a day); the Brand's editors and admins see that a receipt is attached to a request, and cannot download it yet.
• Qubites personnel access production only through the providers' consoles and database roles, for operations and support. Access is limited to named people who need it, with multi-factor authentication on the provider accounts. Staff actions without an admin tool are database functions run with the database's administrative role.

3. Sign-in and codes

• Passwordless sign-in by a one-time code or link sent by email, valid for 15 minutes. The email address must be confirmed before an item can be registered.
• Claim codes are 80 bits and handover codes 60 bits. Both are stored only as HMAC-SHA-256 with a pepper that, in production, is held in Supabase Vault, so a copy of the database tables alone cannot be used to test guesses. Codes are shown once and never written to logs, URLs or webhooks.
• Unknown, revoked and used codes give the same answer. The exception is a claim code that someone else redeemed in the last 14 days: it answers "already registered", so that its holder can dispute. Only a person who has the code learns this.
• Guessing limits:
• 5 failed code attempts per person and Brand in 15 minutes, and 20 a day;
• 300 failures per Brand an hour for wrong codes (right codes always pass);
• 5 repair requests or disputes, and 5 handover codes, per person, Brand and day;
• Supabase Auth limits on sign-in emails.

4. Data minimisation and separation

• No postal addresses or phone numbers are collected, and no name but the display name the owner keeps or removes (Annex I A.5); a handover shows the other side only a first name and an initial, and the Brand sees no name. The exception is a receipt a shop adds, which may show the customer's name and address, other things bought and the last digits of a payment card; the Brand sees it only when the owner attaches it to a request (Annex I A.5).
• Owner data never reaches passports, the R2 passport and page objects, integrity anchoring or a blockchain; the one R2 bucket that holds Owner data is the receipts bucket (§1). Only item identifiers, references and event times reach webhooks and emails to the Brand (Annex I A.7).
• Receipts: an image's metadata (EXIF, location included) is removed before it is stored; a PDF's own metadata (author, software) is not; no file name is kept.
• Owner accounts are separate per Brand; there is no cross-brand view.
• Offer links carry no Owner data and send no referrer.

5. Integrity and logging

• The item log is append-only, enforced by database triggers. It cannot be updated, deleted (except with its item) or truncated.
• Brand actions are also written to the organisation's audit log, which cannot be truncated.
• An erasure is logged without personal data.
• Webhooks are signed (HMAC-SHA-256 with a timestamp). They go only to public HTTPS hosts on port 443 (checked against private addresses) and carry only item identifiers, references and event times.

6. Browser

• The owner area runs in the dashboard app with a strict Content Security Policy, no framing, nosniff, a restrictive Permissions-Policy and noindex.
• DPP Host sets no cookies and uses no analytics there. The owner-area sign-in, like the dashboard's sign-in pages, runs Cloudflare Turnstile (a bot check: IP address and browser and device signals, usually invisible). The widget is set up without a pre-clearance cookie. The sign-in session is kept in the browser's storage because the service needs it (Directive 2002/58/EC Art. 5(3), strictly necessary exemption).
• Error reporting (Sentry) is built in and switched off. It would be turned on only after notice under clause 7.3, and it is configured to send no user info, cookies, headers, bodies or query parameters.

7. Retention and deletion

• Daily jobs: the deletion of Owner data by the periods in Annex I A.6, and the housekeeping of abuse-limit counters and of webhook and import records.
• Owners can erase their own data at once.
• Backups are overwritten after 7 days.
• Receipts: a daily job (03:47 UTC), and the receipts service's deletion run every 10 minutes, which deletes a deleted receipt's object from R2 within the hour (Annex I A.6).

8. Availability and recovery

• Daily database backups kept up to 7 days, provided by Supabase.
• Receipts are in no backup (Annex I A.6), so a receipt lost from storage cannot be restored.
• A documented restore drill exists; it has not been run yet.

9. Development and testing

• Every change is recorded in the source code's history and merged only after the automated tests it touches have passed.
• Automated database tests cover owner services. They include:
• row-level security and function privileges;
• that no owner data reaches passports or the R2 passport objects, a planted receipt included, and that webhooks carry no email address, message or purchase data; that no receipt reaches an organisation export;
• guessing limits;
• export, erasure and retention.
• Secrets are not kept in the repository.

10. Organisation

• Confidentiality commitments for personnel (clause 5).
• A written breach procedure (clause 11).
• A record of processing as processor (clause 14).

Annex III: Sub-processors

1. In use for Owner data (authorised by clause 7.1)

On request, Qubites gives the Brand the name, location and role of every sub-processor in the chain (EDPB Opinion 22/2024).

2. Not sub-processors for Owner data

• Stripe: only DPP Host's own billing of the Brand, with Qubites as controller.
• Apple (Wallet): keeps the wallet cards an owner adds on the owner's devices and in iCloud, under the owner's own agreement with Apple. For each update of a card, Qubites sends Apple's push service the push token of each device that keeps the card up to date and an empty message, nothing of the card.
• Google (Wallet): Google Wallet cards are not available to Brands yet. For such a card, Google stores the card's content as an object under Qubites' issuer account (no Owner data: the product, its serial and batch, dates, the Brand's safety notices, links, the product photo's address) and notifies the devices that saved it; once saved, Google keeps it in the owner's Google account under the owner's own terms with Google, and its API deletes no object. Before these cards are offered to Brands, Qubites assesses whether Google is then a sub-processor (listed in part 1, with notice under clause 7.3), an independent controller once the owner saves the card, or both.
• Scaleway SAS (France), Object Storage in Paris (fr-par): not in use. DPP Host's nightly off-site copies there (of the published passports, and an encrypted copy of the database, which holds Owner data) are built and switched off; Qubites sends Scaleway no data today. Before they start, Scaleway is added to part 1 with notice under clause 7.3.
• OpenTimestamps calendars: they receive only one 32-byte Merkle root a day, built from salted hashes of published passport versions. They receive no personal data.
• Anthropic (Claude API) (Anthropic Ireland, Limited, Ireland, the contracting party for an EEA customer under Anthropic's Commercial Terms; processing by Anthropic, PBC, USA, and its sub-processors, Anthropic's list): built and switched off for Brands. Today it reads only for Qubites' own organisations, with Qubites' own content; a Brand's files are not read until the notice under clause 7.3 has run. When on, Anthropic's API reads, once, the files and the product page a Brand's member drops on New passport with its Claude model, to suggest the passport's values (Annex I part D); it receives no Owner data. It processes them in the United States or other countries where Anthropic runs its service, not in the EU. It deletes API inputs and outputs within 30 days; content its automated trust and safety systems flag as violating its Usage Policy may be kept up to 2 years; it may not train models on customer content. Anthropic's DPA (anthropic.com/legal/data-processing-addendum) incorporates the EU SCCs (Module Two and/or Three, Irish law; UK and Swiss addenda); new sub-processors of Anthropic come on "reasonable notice", with 15 days to object. No DPF certification of Anthropic was found. It moves to part 1 on the day the notice under clause 7.3 gives, which the list of sub-processors shows. It may also read, once, a certificate a Brand's supplier drops on the supplier form, with the labels of the fields the Brand asked, to fill the supplier's answers (Annex I part D); this too is switched off for Brands. Amazon Web Services (Amazon Bedrock in Frankfurt), named here from 12 to 18 Oct 2026 and announced on 12 Oct 2026, is not used and will not be used.
• Sentry (Functional Software, Inc.): not in use. Error reporting is built in and switched off. It would be added to part 1 with notice under clause 7.3 (EU region, ingest.de.sentry.io) before it is switched on. Even with its scrubbing settings, a report can contain the owner-area address with the Brand's handle.
• The owner's own wallet provider (Annex I part B, not available yet): chosen by the owner, not engaged by Qubites.
• Owner-offer providers (a Brand's offer partners): they receive data only from owners who follow their links, as their own controllers. Qubites passes them no Owner data (clause 4.5(d)).
• Partners in the partner programme (clause 4.6): they act for the Brand under its authority and see Owner data in the dashboard only through the Brand's organisation. Qubites does not engage them.
• The Brand's own webhook endpoints and systems: the Brand's own, not Qubites' sub-processors.
• A public blockchain (Annex I part B, not available yet): not a processor. Writing an owner's address next to an item's serial would be a disclosure to the public on the Brand's instruction, which cannot be undone.

3. Not in use (Annex I part B; notice under clause 7.3 before any use)

Service	Personal data	Assessment
Pimlico (paymaster and bundler, for sponsored fees of freeze, unfreeze and transfer actions from the owner area; entity and location not confirmed)	The owner's smart-account (wallet) address, the called contract and token id, the signed operation, and the IP address of whoever calls it (DPP Host's paymaster service; the owner's browser too, if it calls the bundler directly)	The wallet address is personal data when it can be linked to a person, and here it can: the Brand holds sales records, and the owner area links the address to an account. Pimlico processes it for Qubites, so it is a sub-processor. A DPA and a transfer check are needed. Condition: Pimlico's terms must not let it use user operations, addresses or IP addresses for its own purposes; otherwise it cannot be engaged as a sub-processor on those terms (Art. 28(3)(a), 28(4)). Alchemy is the alternative considered.
Blockchain RPC node provider (not chosen)	Wallet addresses in reads (who holds a token) and in the minter's transactions	Sub-processor, for the same reason
Key management (KMS or HSM) for the Brand's minter key (not chosen)	Signs transaction digests; normally sees no personal data	To assess once chosen
WalletConnect relay, if "Use another wallet" uses it under DPP Host's project id (not decided)	Connection metadata and the wallet address	To assess