SilverQR — Data Processing Addendum
Version 2026-07-30. Incorporated into the Terms of Service by reference.
This Addendum ("DPA") applies where the Customer uses the SilverQR Service to process personal data relating to its guests. It forms part of the Terms of Service between Royal SoftWorks DOO Kragujevac ("Processor", "SilverQR") and the Customer ("Controller"). Terms defined in the Terms have the same meaning here. Where this DPA conflicts with the Terms on the subject of data protection, this DPA prevails.
"GDPR" means Regulation (EU) 2016/679 and, where applicable, the Serbian Law on Personal Data Protection ("Zakon o zaštiti podataka o ličnosti"), read together.
1. Roles — this is the operative allocation
1.1 In respect of Guest Data (defined in Annex 1), the Customer is the sole controller and SilverQR is a processor. The Customer determines the purposes and means; SilverQR processes only as set out in Annex 1 and on the Customer's documented instructions.
1.2 In respect of account-holder data — the Customer's own users' names, addresses, credentials and audit records — SilverQR is an independent controller and processes that data under its Privacy Policy. This DPA does not apply to it.
1.3 The Customer acknowledges that it, and not SilverQR, decides:
(a) which venues to operate and which mini-site features to enable;
(b) whether device recognition signals are enabled for a venue;
(c) what staff notes, ratings, flags and restrictions to record about identifiable individuals, and on what basis;
(d) what notice is given at the premises and on the mini-site, and what consent, if any, is collected;
(e) how long to keep data beyond the platform defaults, within the maxima SilverQR enforces.
1.4 Nothing SilverQR provides constitutes legal advice, a lawful basis, a legitimate-interests assessment, or a data-protection impact assessment for the Customer's processing. Where such an assessment is required, it is the Customer's to perform.
2. Customer obligations and warranties
2.1 The Customer warrants that:
(a) it has a valid lawful basis under Art. 6 GDPR for every category of Guest Data it collects through the Service, established and documented before collection begins;
(b) where a device-recognition signal, cookie, or equivalent local-storage identifier requires consent under applicable ePrivacy rules, the Customer has obtained that consent in a manner meeting the standard of Art. 7 GDPR — freely given, specific, informed, unambiguous, and demonstrable — and has retained the record;
(c) it has provided all transparency information required by Art. 13 GDPR, including the identity of the Customer as controller, the purposes, the retention periods, and the guest's rights;
(d) any rating, flag, comment or restriction it records about an identifiable individual is accurate, relevant, proportionate, not excessive, and not based on a special category of data under Art. 9 GDPR;
(e) it will not use the Service to process the data of anyone under 16, to profile on the basis of race, ethnicity, religion, health, sexual orientation, trade union membership, or political opinion, or to make automated decisions with legal or similarly significant effect;
(f) its instructions to SilverQR will not cause SilverQR to breach applicable data protection law.
2.2 The Customer will handle guest data-subject requests as controller, and will respond within statutory deadlines. SilverQR's self-service access and erasure tooling assists the Customer but does not discharge the Customer's duty.
2.3 Indemnity. The Customer will indemnify and hold SilverQR harmless against all claims, fines, penalties, corrective measures, investigation costs, damages and legal fees arising from: any breach of this §2; any assertion that the Customer lacked a lawful basis or valid consent; any complaint by a guest concerning data the Customer collected, rated, flagged, or restricted; and any finding that the Customer's notice or consent mechanism was inadequate. This indemnity is not subject to the liability cap in §13 of the Terms.
3. SilverQR obligations
SilverQR will:
3.1 process Guest Data only on the Customer's documented instructions, and inform the Customer if it considers an instruction to be unlawful (Art. 28(3));
3.2 implement and maintain the technical and organisational measures described in Annex 2, having regard to the state of the art and the risks presented;
3.3 ensure that personnel with access are bound by confidentiality and are authorised on a need-to-know basis;
3.4 notify the Customer without undue delay, and in any event within 48 hours of becoming aware of a personal-data breach affecting Guest Data, with the information reasonably available, so that the Customer can meet its own Art. 33 deadline;
3.5 assist the Customer, at the Customer's cost for anything beyond the self-service tooling, with data-subject requests, impact assessments, and prior consultations, to the extent the Customer cannot reasonably do so itself;
3.6 on termination, and at the Customer's option, delete or return Guest Data, save where retention is required by law. Absent instruction within 30 days of termination, SilverQR will delete it;
3.7 make available the information necessary to demonstrate compliance with Art. 28. Audits are addressed in §6.
4. Sub-processors
4.1 The Customer gives general authorisation for SilverQR to engage sub-processors. The current list is:
| Sub-processor | Purpose | Processing location | Entity established in |
|---|---|---|---|
| Momentum Minds LLC, trading as LuxVPS (https://luxvps.net) | Virtual private server hosting: compute, database, cache, object storage | Frankfurt, Germany (EU) | New Mexico, United States |
| Cloudflare, Inc. | CDN, DNS, TLS, DDoS protection, where enabled | Global edge | United States |
| SMTP relay provider | Transactional email | See §5 | See §5 |
4.2 SilverQR will give at least 14 days' notice of an intended addition or replacement, by email or dashboard notice. The Customer may object on reasonable data-protection grounds within that period. If the parties cannot resolve the objection, the Customer's sole remedy is to terminate the affected part of the Service. Continued use after the notice period constitutes approval.
4.3 SilverQR imposes data-protection obligations on each sub-processor no less protective than this DPA and remains liable for their performance.
5. International transfers
Where the data physically sits. All primary processing — application servers, the database, the cache, and stored files — takes place on servers located in Frankfurt, Germany, inside the EU. Guest Data is not routinely stored anywhere else.
Why a transfer analysis is still required. The hosting sub-processor named in §4 is established in the United States, and SilverQR itself is established in the Republic of Serbia. Neither is in the EEA. EU data-protection law treats access to data by an entity outside the EEA as a transfer irrespective of where the hardware stands, so the safeguards below apply to EU-hosted data as well:
(a) transfers to and access by the hosting sub-processor rely on the European Commission's Standard Contractual Clauses (Decision 2021/914), Module Three (processor-to-processor);
(b) transfers to SilverQR as Processor rely on the same Clauses, Module Two (controller-to-processor), Serbia having no adequacy decision at the date of this DPA;
(c) transfers via Cloudflare's edge network, where enabled, rely on the same Clauses;
(d) in each case supplementary technical measures apply, including TLS in transit, encryption at rest, access limited to named administrators, and minimisation of the personal data actually held (see §2 and the Privacy Policy).
The SCCs are incorporated by reference; in a conflict the SCCs prevail over this DPA.
Transactional email. Outgoing mail is relayed through a third-party SMTP provider. The Customer may obtain the provider's current identity and place of establishment on request to [email protected]. Mail content is limited to account and service messages (invitations, verification, password reset, data requests) and does not carry Guest Data beyond the recipient's own address.
Government access. No sub-processor has been granted standing access to Guest Data. Where SilverQR or a sub-processor receives a legally binding demand from a public authority for Guest Data, SilverQR will, unless legally prohibited, notify the Customer before disclosure and will challenge demands that appear unlawful or excessive.
6. Audits
6.1 SilverQR will respond to reasonable written information requests about its processing, at no charge, once per twelve-month period.
6.2 An on-site or third-party audit may be requested only where required by a supervisory authority or by mandatory law. Such an audit must be: requested at least 30 days in advance; limited to systems processing the Customer's Guest Data; conducted during business hours without disrupting operations; subject to confidentiality; conducted by an auditor who is not a competitor of SilverQR; and at the Customer's expense, including SilverQR's reasonable time at its then-current rates.
7. Liability
7.1 Liability under this DPA is subject to the limitations and exclusions in §13 of the Terms, save that the Customer's indemnity in §2.3 is uncapped.
7.2 Where both parties are held liable to a data subject, each bears the share of liability corresponding to its own responsibility for the damage (Art. 82(5)). The Customer accepts that decisions listed in §1.3 are its responsibility for this purpose.
8. Term
This DPA takes effect on acceptance of the Terms and continues while SilverQR processes Guest Data. Clauses that must survive to give effect to their purpose — including §2.3, §5, §7 and Annex 2 — survive termination.
Annex 1 — Details of processing
Subject matter. Provision of the SilverQR QR and mini-site platform.
Duration. The term of the Terms, plus the retention periods in the Privacy Policy, plus a maximum 30-day deletion window after termination.
Nature and purpose. Hosting, storing, displaying, de-duplicating, aggregating and deleting Guest Data so that the Customer can operate guest-facing mini-sites, receive service requests, view visit analytics, and enforce its house rules.
Categories of data subject. Guests and visitors of the Customer's venues.
Categories of personal data — "Guest Data".
- device recognition identifier (random, browser-stored);
- device-traits hash derived from GPU/renderer, screen metrics, platform, touch capability, memory, and canvas rendering;
- truncated SHA-256 hashes of IP address and user-agent string;
- visit records: timestamp, venue, area/table label, device class;
- name and email address, where volunteered by the guest in a service request;
- service-request content authored by the guest;
- staff-authored ratings (1–5), flags, and free-text notes about the guest;
- restriction records (venue, organisation, or platform scope).
Special categories. None. The Customer must not introduce any.
Frequency. Continuous, for the duration of the Terms.
Annex 2 — Technical and organisational measures
Access control. Role-based access with hierarchical scopes (organisation → brand → venue → area). Server-side enforcement on every request. Rank-dominance checks prevent privilege escalation by invitation or role assignment.
Authentication. bcrypt password hashing at cost 12. Mandatory email verification before any write operation. Short-lived access tokens (15 minutes) re-validated against live account and workspace status on every request. Refresh tokens are rotated on use, stored only as SHA-256 hashes, capped per user, and revoked in bulk on password change.
Key separation. Distinct secrets for session tokens, refresh tokens, QR signature material, and venue-access cookies. Production configuration refuses to start on a placeholder, a short, or a reused secret.
Pseudonymisation. IP addresses and user-agent strings are never stored in raw form against a guest — only truncated SHA-256 hashes. QR signatures are encrypted at rest.
Storage limitation. Automated retention sweep on a fixed schedule enforcing the published periods: visits 90 days, scan events 180 days, settled requests 30 days, dormant guest profiles 365 days, audit records 365 days. Expired tokens and invitations are purged.
Erasure. Self-service, email-verified guest erasure that removes visits, requests, ratings, recognition signals and the profile, retaining only what an active restriction requires.
Transport and storage security. TLS throughout, including origin. Encryption at rest for database and object storage volumes.
Availability. Nightly encrypted database backups retained 14 days and replicated to EU object storage. Readiness probes verify database and cache reachability rather than process liveness alone.
Abuse resistance. Distributed rate limiting on all public and authentication endpoints. Per-workspace resource quotas. Immediate platform-level workspace suspension capability.
Logging and accountability. Administrative actions written to an append-only audit log with actor, scope and detail. Erasure fulfilment is recorded against a hash of the subject's address rather than the address itself.
Error handling. A terminal exception filter prevents driver messages, SQL fragments and stack traces from reaching clients; a reference code correlates the client response with the server log.
Royal SoftWorks DOO Kragujevac · Kragujevac, Republic of Serbia [email protected]