Data processing agreement

Status. This is our standard DPA, published so you can read it before you ask. It has not yet been reviewed by external counsel, and we would rather say so than let you find out later. If your legal team needs changes, or needs it signed as a separate document rather than incorporated by reference, write to hello@klipqr.comand we will work from your paper.

1. Who is who

You are the data controller and Klip is your data processor. You decide which links exist and where they point; we process the scans that result, on your instructions, to give you the analytics the service promises. For your own account details (the email you signed up with, your billing records) we are the controller, and ourprivacy policy governs that instead.

That split matters more here than it does for most products. A person who scans your QR code has no relationship with us at all: they scanned your poster. We never contact them, never build a profile of them, and never use what we record for any purpose of our own.

2. What this covers, and for how long

This agreement applies for as long as you have a Klip account, and to every piece of personal data we process because of it. It forms part of our terms of service. Where this document and the terms disagree about personal data, this document wins.

3. What we do with it

We count scans, and we resolve redirects. Concretely: when someone follows one of your links we record that it happened, along with a small set of coarse attributes, so that we can show you totals. We do not enrich it, cross-reference it against other customers' data, or sell it.

4. Whose data, and what

Data subjects: people who scan or click your links, and the people you invite into your workspace.

We never store a raw IP address, and there is no code path that could. The address is used in memory to derive the country and the daily hash, and is then gone. That is a design decision made before the first line of the redirect path was written, and it is why several of the questions a DPA usually has to answer carefully have a short answer here.

5. Acting on your instructions

We process personal data only on your documented instructions, which, in practice, means using the product. We will tell you if we believe an instruction breaks data protection law, and we will not follow it in the meantime.

One exception, stated plainly. We will act without your instruction, and against them if necessary, to take down a link being used for phishing, malware or fraud. A single blocklisted destination attaches a browser warning to every link our domain has ever issued, including yours. That authority is in the terms and it is not negotiable.

6. Confidentiality

Everyone with access to your data is bound by confidentiality obligations that survive their involvement. Access is limited to the people who need it to run the service.

7. How it is protected

These are the measures in place, not a description of an intention:

• No raw IP addresses are stored, anywhere, at any layer.
• Visitor identifiers are re-salted daily. A hash from Tuesday cannot be matched to the same device on Wednesday. This limits what we can tell you (we report same-day repeat scans, not unique people) and that is the trade being made on purpose.
• Every query is scoped by workspace in the WHERE clause, not filtered afterwards. A request for another workspace's link returns "not found" rather than "forbidden", because "forbidden" would confirm the link exists.
• Transport is encrypted end to end, and data is encrypted at rest by our infrastructure providers.
• Session cookies are host-only on our API hostname, marked HttpOnly, Secure and SameSite=Lax, and state-changing requests are refused unless they carry a recognised origin.
• API keys are stored only as hashes. We cannot show you a key again after it is created, because we do not have it.
• Removing a team member revokes their credentials in the same request.
• Uploaded logos are addressed by content hash under a per-workspace prefix, so one workspace cannot name a path into another's.
• Schema changes are gated against a recorded fingerprint of the live database before a deploy is allowed.

8. Sub-processors

You give us general authorisation to use the sub-processors below. We keep the list short on purpose, and each one processes data only on our instructions.

We will tell you at least 30 days before adding or replacing a sub-processor that handles your data, so you have time to object. If you object on reasonable data-protection grounds and we cannot offer an alternative, you may terminate and we will refund the unused part of your term.

9. Helping you answer your users

If someone exercises their rights against you, we will help you respond. In practice most of this is already self-service: GET /v1/me/export returns everything we hold for your workspace as JSON, and closing your account deletes it.

One limit, stated because pretending otherwise would be worse. Individual scan events live in Cloudflare Analytics Engine, which has no per-record delete. We cannot erase one person's scan from that store. What we can say is that those records contain no raw IP address and no identifier that survives the day it was created, and they age out on their own within about ninety days.

10. If something goes wrong

We will notify you without undue delay and within 72 hours of becoming aware of a personal data breach affecting your data, with what we know at the time, what happened, which categories of data and roughly how many records, the likely consequences, and what we are doing about it. We will not wait until we have a complete picture to make the first contact.

11. Deletion and return

Retention follows your plan: 7 days on Free, 365 days on Starter, and for as long as your account is open on Studio. Beyond that, aggregates are pruned automatically.

When you close your account we delete your links, your analytics archives, your team records and your uploaded files. The workspace row itself survives in scrubbed form, holding no personal data, because payment records have to point somewhere for our own tax and accounting obligations. Export your data first (GET /v1/me/export) because after closure we cannot get it back for you.

12. Audits

We will make available the information needed to demonstrate compliance with this agreement, and allow an audit by you or an auditor you appoint, on reasonable notice, no more than once a year unless a regulator or a breach requires otherwise. We will try to answer with documentation first, because that is usually faster for both of us.

13. Where data goes

Our primary database is in AWS eu-central-1 (Frankfurt, Germany), and Cloudflare's network is global by nature, a scan is handled at the edge closest to whoever scanned it. That means personal data crosses borders as an ordinary part of how the service works.

For transfers out of the European Economic Area or the UK we rely on the European Commission's Standard Contractual Clauses, which are incorporated into this agreement by reference. For transfers out of Kenya we rely on the safeguards in the Data Protection Act 2019.

14. Kenya's Data Protection Act 2019

Klip is operated from Kenya, and the Data Protection Act 2019 applies to us directly. Where it and the GDPR both apply, we follow whichever gives the individual more protection rather than picking the easier one. Complaints can be made to the Office of the Data Protection Commissioner as well as to us.

15. Liability and precedence

Liability under this agreement is subject to the limitations in ourterms of service. Where this document conflicts with the terms on the processing of personal data, this document takes precedence.

16. Getting it signed

This DPA applies automatically to every account, without signature. If you need a countersigned copy for your records, or need us to work from your own template, emailhello@klipqr.com with the document and we will turn it around rather than insisting on ours.