Data Processing Agreement

Version: dpa-2026-10. This DPA is drawn up in Dutch and English. The Dutch version (Verwerkersovereenkomst) governs. If the two versions differ, the Dutch text prevails.

Parties

Controller: the customer that holds a workspace in QR Code Manager, as identified in the Order Form or, for self-service customers, by the workspace created at signup ("Customer").

Processor: bouwman.io, trading as QR Code Manager by bouwman.io, Cornelis Roelestraat 16a, 1151 CB Broek in Waterland, the Netherlands, Chamber of Commerce no. 42155003, support@bouwman.io ("Operator").

This DPA forms part of the Service Agreement or, where there is no signed Service Agreement, of the Terms of Service. It is the agreement required by article 28(3) of the General Data Protection Regulation (GDPR).

1. Definitions

1.1 Terms such as "personal data", "processing", "controller", "processor", "data subject", "personal data breach" and "supervisory authority" have the meaning given in the GDPR. 1.2 "Service", "Workspace", "Scan Data", "Short Link", "Users" and "Custom Domain" have the meaning given in the Service Agreement or, if none, the Terms of Service. 1.3 "Sub-processor": a third party engaged by Operator that processes personal data on Customer's behalf.

2. Subject matter, duration, nature and purpose

2.1 Subject matter: the processing of personal data needed to provide the QR Code Manager Service to Customer. Details are in Annex A. 2.2 Duration: for as long as Customer has a Workspace, plus the 60-day exit window in clause 11. 2.3 Nature: hosting, storage, recording of scan events (scans of tracked QR codes and clicks on Short Links), recognising automated visits such as link previews from the User-Agent header, lookup of approximate location, aggregation into analytics, export, deletion, sending of transactional email to Users. 2.4 Purpose: letting Customer manage QR codes and Short Links, redirect scans and clicks, see their statistics and manage its Users. Operator does not process the personal data for any other purpose.

3. Roles

3.1 Customer is the controller of the personal data in Annex A. Operator is the processor. 3.2 Operator is an independent controller for data about Customer's own relationship with Operator: account contact details, billing data, invoices, support emails and the security audit log to the extent it is kept for Operator's own security. That processing is described in the Privacy Policy, not in this DPA. 3.3 Customer confirms it has a legal basis for the processing and gives people who scan its codes or open its Short Links the information the GDPR requires, where applicable.

4. Instructions

4.1 Operator processes the personal data only on Customer's documented instructions. This DPA, the Service Agreement, the Terms of Service and the settings Customer makes in the Service are those instructions. 4.2 Operator does not process the personal data for its own purposes, does not sell it and does not combine it with other customers' data, except as aggregated, non-identifying usage statistics. 4.3 If Operator believes an instruction breaks the GDPR or other law, it tells Customer right away and may pause that instruction until it is resolved. 4.4 If EU or member state law requires Operator to process the data in another way, Operator informs Customer before doing so, unless the law forbids that.

5. Confidentiality of personnel

5.1 Operator makes sure that everyone who may access the personal data (Operator's staff, if any, and contractors) is bound by a confidentiality obligation, contractual or statutory, and is given access only as far as needed for their work. 5.2 At the date of this DPA, production access is limited to Remco Bouwman. Operator informs Customer if this changes materially.

6. Security

6.1 Operator takes the technical and organisational measures in Annex B. Together they give a level of security appropriate to the risk, taking into account the state of the art, costs, and the nature of the data (mainly pseudonymous technical data about scans; no special categories). 6.2 Operator may change the measures as long as the overall level of protection does not decrease. Annex B is kept current at [URL]. 6.3 Customer is responsible for security on its side: strong passwords, removing Users who leave, securing the DNS of its Custom Domain, and the safety of exported data once downloaded.

7. Sub-processors

7.1 Customer gives Operator general authorisation to use the Sub-processors in Annex C. 7.2 Operator puts each Sub-processor under written data protection obligations that are at least as protective as this DPA, and remains fully liable to Customer for the Sub-processor's performance. 7.3 Before adding or replacing a Sub-processor, Operator notifies Customer's admins by email at least 30 days in advance, with the name, the service provided and the location of processing. The current list is published at [URL]. 7.4 Customer may object in writing within those 30 days on reasonable data protection grounds. The parties then discuss a solution. If no solution is found within 30 days after the objection, Customer may terminate the Service Agreement for the affected Workspace with immediate effect, and Operator refunds prepaid fees for the period after termination. 7.5 Replacing a Sub-processor urgently for security or continuity reasons is allowed without prior notice; Operator notifies Customer as soon as possible, and the objection right of 7.4 applies from that notice.

8. Assistance

8.1 Data subject requests. If Operator receives a request from a data subject (access, rectification, erasure, restriction, portability, objection) that concerns Customer's Workspace, Operator forwards it to Customer within 5 Business Days and does not answer it directly, except to point the person to Customer. 8.2 Operator helps Customer answer such requests with the tools in the Service (export, per-code deletion, per-scan deletion on request) and, where the tools are not enough, with reasonable manual help. 8.3 Note on scan data: Operator can usually not link a scan record to a named person, because the Service stores no identity of the scanner. If a data subject supplies an IP address and time window, Operator can locate and delete matching records for Customer. 8.4 DPIAs and consultation. Operator gives Customer the information it reasonably needs for a data protection impact assessment or a prior consultation with a supervisory authority, to the extent it concerns the Service. 8.5 Assistance that goes beyond what the Service offers and takes more than [4] hours per calendar year may be charged at EUR [rate] per hour, agreed in advance.

9. Personal data breaches

9.1 Operator informs Customer's admins by email without undue delay, and at the latest within 48 hours after becoming aware of a personal data breach that affects Customer's personal data. 9.2 The notice contains, as far as known at that point: the nature of the breach, the categories and approximate number of data subjects and records, the likely consequences, the measures taken or proposed, and a contact point. Operator follows up with missing information as it becomes available. 9.3 Operator helps Customer meet its own notification duties (articles 33 and 34 GDPR). Operator does not notify a supervisory authority or data subjects on Customer's behalf unless Customer asks in writing. 9.4 Operator documents all breaches, their effects and the remedial action taken.

10. Audits

10.1 Operator makes available the information needed to show compliance with article 28 GDPR: this DPA, Annex B, the Sub-processor list, a summary of its security practices and, where available, third-party reports of its Sub-processors (such as SOC 2 reports from Render, Neon and Resend). 10.2 Customer may audit Operator's compliance once per calendar year, and additionally after a personal data breach or on request of a supervisory authority. 10.3 An audit starts with written questions. Operator answers within 15 Business Days. If the written answers leave reasonable doubts, Customer may hold an on-site or remote audit, by itself or by an independent auditor bound to confidentiality, announced at least 30 days in advance, during business hours, and without disrupting the Service or the confidentiality of other customers' data. 10.4 Customer bears the costs of the audit, including Operator's reasonable time at EUR [rate] per hour, unless the audit shows a material breach of this DPA by Operator. 10.5 [OPTIONAL, only if the software is published as open source: Customer can also review the source code at [repository URL] at any time.]

11. Deletion and return

11.1 Customer's admins can export all personal data in Annex A at any time from within the Service, in JSON and CSV, without a fee. Exports never contain raw IP addresses. 11.2 Customer can delete individual QR codes or Short Links (which deletes their Scan Data), individual Users, or the whole Workspace at any time. 11.3 When the Workspace is deleted, or the Service Agreement ends, a 60-day exit window starts. The Workspace is locked and Users can no longer sign in. Nothing is deleted yet. Customer is expected to export before deleting; during the window Operator provides the same export to Customer's contact on written request within 5 Business Days, and restores the Workspace on written request. 11.4 At the end of the 60-day window Operator permanently deletes all personal data in Annex A from production systems. Backup copies are overwritten within Operator's normal backup cycle of at most [30] days after that. 11.5 Operator confirms deletion in writing on request. 11.6 Exception: invoices and the billing records needed to support them (plan, period, amounts, counts of scans, codes and Short Links per billing period, billing contact) are kept for 7 years under art. 52 of the Dutch General Tax Act (Algemene wet inzake rijksbelastingen). They contain no Scan Data. For this retention Operator acts as controller. 11.7 Custom Domains are deregistered at Customer's request within 5 Business Days and at the latest at the end of the exit window, and are never retained.

12. International transfers

12.1 Operator processes the personal data in the European Economic Area. Operator does not transfer it outside the EEA unless a valid transfer mechanism under Chapter V GDPR is in place. 12.2 The hosting location and transfer mechanism of each Sub-processor are stated in Annex C. Where a Sub-processor is based in the United States, Operator relies on the EU-US Data Privacy Framework where the Sub-processor is certified, and otherwise on the European Commission's Standard Contractual Clauses (2021/914) included in that Sub-processor's data processing terms. 12.3 Operator informs Customer at least 30 days in advance of any change of hosting region outside the EEA, and the objection right in clause 7.4 applies.

13. Liability

13.1 The liability provisions of the Service Agreement (clause 14) apply to this DPA, including the higher cap for data protection breaches. If there is no Service Agreement, the liability clause of the Terms of Service applies, with the addition that Operator's liability for breach of this DPA is capped at twice the fees paid in the 12 months before the event. 13.2 Each party is liable towards data subjects as set out in article 82 GDPR.

14. Term and precedence

14.1 This DPA applies for as long as Operator processes personal data for Customer. 14.2 If this DPA conflicts with the Service Agreement or the Terms of Service on anything concerning personal data, this DPA prevails. 14.3 Operator may update this DPA to reflect changes in law, in Sub-processors or in the Service. Operator gives Customer's admins at least 30 days notice by email of material changes. Changes that reduce Customer's protection require Customer's acceptance. 14.4 Dutch law applies. Disputes go to the court that is competent under the Service Agreement or, if none, the competent court in the Netherlands.

---

Annex A: Processing details

A.1 Categories of data subjects

1. Scanners: people who scan a tracked QR code of Customer or open one of its Short Links. They have no account and are usually unknown to Customer and Operator by name. Automated visitors such as link previews and search engine crawlers are recorded the same way but marked as bots (see device below).
2. Users: people Customer gives access to its Workspace (admins and members), and people Customer invites.

A.2 Categories of personal data

Scanners (table scan_events, one row per scan of a tracked code or click on a Short Link):

Field	Content	Shown in product	In export	Retention
ts	date and time of the scan	yes	yes	life of the scan record
ip	IP address of the scanning device (IPv4 or IPv6, stored in full)	never	never	life of the scan record (no truncation or separate deletion; used only to count unique scans and to look up location at scan time)
device	device type from the User-Agent header, or bot for automated visits (crawlers, link previews, scripts, requests without a User-Agent); bot rows are kept but left out of the statistics, click counts and the monthly limit	yes	yes	life of the scan record
os	operating system name and version from the User-Agent header	yes	yes	life of the scan record
browser	browser or in-app browser name and version from the User-Agent header	yes	yes	life of the scan record
country	country, looked up from the IP against a locally hosted GeoLite2 database	yes	yes	life of the scan record
subdivision	region, state or province, same lookup	yes	yes	life of the scan record
city	city, same lookup	yes	yes	life of the scan record
latitude, longitude	approximate coordinates of the city centre from the same lookup, not GPS	yes (map)	yes	life of the scan record
host	the hostname the code was scanned or the Short Link opened on (standard domain, Operator's short domain or Custom Domain)	no	yes	life of the scan record
qr_code_id or short_link_id, tenant_id	which code or Short Link, and which Workspace	yes	yes	life of the scan record

A scan record lives as long as the QR code or Short Link it belongs to, or until Customer deletes the code or link, the scan, or the Workspace (subject to the 60-day exit window). Billing periods keep only counts (number of scans, codes and Short Links), no scan records.

Users (tables users, invites, password_resets, refresh_tokens, audit_log):

Category	Content	Retention
Identification	email address, role, status (pending, active, disabled)	life of the account
Credentials	password as bcrypt hash only; hashed invite and reset tokens; refresh token identifiers	password: life of the account; invite and reset tokens: until used or expired; refresh tokens: 7 days or until logout
Audit log	actions such as login, invite, reset, role change, disable, with actor, target and timestamp	life of the Workspace; entries about the deletion of the Workspace itself are kept afterwards without the tenant reference, as evidence of the deletion
Content	QR codes created by a User, including name, destination, content and style, which may contain personal data if Customer puts it there (for example a vCard or an email address in a static code)	life of the code

A.3 Special categories

None. Customer must not use the Service to process special categories of personal data (article 9 GDPR) or data about criminal convictions.

A.4 Processing operations

Receiving the scan or click request and redirecting the visitor; recording it; parsing the User-Agent header, including recognising automated visits; looking up approximate location in a locally hosted database; aggregating scans into charts and counts; exporting; deleting; storing Users and their credentials; sending transactional emails (invites, password resets, scan limit notices) to Users via the email Sub-processor; writing the audit log.

Annex B: Security measures

1. Tenant isolation. Every tenant-scoped table is protected by PostgreSQL row-level security. The application database role cannot read or write another Workspace's rows, whatever the application code does. The tenant context is set per transaction. The JWT's tenant must match the tenant in the URL, or the request is rejected.
2. Two database roles. The application runs as a restricted role; an admin role with RLS bypass is used only for operator actions, each of which is audited.
3. Transport encryption. All traffic uses TLS, including on Custom Domains, for which certificates are provisioned automatically by the hosting provider. Connections to the database use TLS.
4. Encryption at rest. Database storage and backups are encrypted at rest by the database provider.
5. Authentication. Passwords are stored only as bcrypt hashes with a cost of [12]. Login uses a comparison with a dummy hash so that unknown emails cannot be told apart from wrong passwords by timing. Login endpoints are rate limited per tenant and per IP.
6. Session security. Short-lived access tokens (Bearer header only, never cookies, so CSRF does not apply). Refresh tokens are single-use, rotate on every use, can be revoked server-side and expire after 7 days. Reuse of a rotated refresh token is treated as theft and ends every session of that account. Logout revokes server-side. Disabling a User invalidates its tokens immediately. Token class and algorithm are pinned.
7. Invite and reset tokens. Only SHA-256 hashes are stored, tokens are single-use and time-limited, and the raw link is only ever sent to the recipient's inbox.
8. Input validation. All input is validated with a schema; unknown fields are rejected. Only parameterised queries. Destinations are validated as http or https at save time and again at redirect time, to prevent open redirects. Branding images are accepted only as bounded data URIs, never remote URLs. Security headers via helmet and a Content Security Policy.
9. Host handling. The tenant and Custom Domain are resolved from the Host header, not from client-supplied forwarding headers.
10. Audit log. Login, invite, reset, disable, role change, tenant create, disable, delete and all operator actions are logged in the same transaction as the action, with actor, target and timestamp.
11. Data minimisation. Raw IP addresses are never shown in the product or included in any export; they are used only to count unique scans and to look up approximate location. Location lookups run against a GeoLite2 database hosted by Operator; no scan data is sent to a third party for this.
12. Secrets and configuration. Secrets live in environment variables, never in code. Production refuses to start with unsafe configuration (for example, emails printed to logs).
13. Backups. Daily automated database backups by the database provider, retained [7 to 30] days. Restores are tested at least [twice] a year.
14. Access control at Operator. Production access limited to Remco Bouwman, protected by multi-factor authentication at the hosting, database, email and payment providers. Personal devices are encrypted and locked.
15. Monitoring. External availability monitoring of the redirect endpoint; error alerting; dependency updates reviewed regularly.
16. Deletion. Workspace deletion locks the Workspace immediately, revokes every session, and purges all data after the 60-day window; the purge is automated and audited.
17. Incident response. Documented procedure: contain, assess, notify Customer within 48 hours, remediate, write a post-incident report on request.

Annex C: Sub-processors

Sub-processor	Service	Personal data	Location of processing	Transfer mechanism
Render Services, Inc. (United States)	Application hosting, TLS certificates for Custom Domains, outbound connections	All data passing through the application, including scan requests (IP, User-Agent) and Custom Domain hostnames	Render region [Frankfurt, EU, to confirm in the Render dashboard]; Render's support staff may access from the US	EU-US Data Privacy Framework and SCCs in Render's DPA
Neon, Inc. (United States)	Managed PostgreSQL database and backups	All stored data in Annex A	Neon project region [AWS eu-central-1 Frankfurt, to confirm in the Neon console]	EU-US Data Privacy Framework and SCCs in Neon's DPA
Resend, Inc. (United States)	Transactional email	Email addresses of Users; content of invites, password resets, scan limit notices, invoices. No Scan Data.	United States, with EU sending region [to confirm]	SCCs in Resend's DPA
Mollie B.V. (Netherlands)	Payment processing for self-service subscriptions	Billing contact name and email, payment method details entered by Customer at Mollie, payment status. No Scan Data. Mollie is an independent controller for the payment itself.	European Union (Netherlands)	Not applicable (EEA)

Not a Sub-processor, listed for transparency: MaxMind, Inc. publishes the GeoLite2 database Operator downloads and hosts itself. No personal data is sent to MaxMind. Google Analytics runs only on the public marketing site after cookie consent and never processes Customer's Scan Data or User data; it is covered by the Privacy Policy.

Date of this list: [date]. Current list: [URL].