← All policies

Kynto Events — data processing agreement

Last updated 2026-08-18 · version 2026-08-v1

When you create an event, you decide whose photographs get collected, who may see them and how long they are kept. That makes you the controller and me the processor, and Article 28 of the GDPR requires that to be written down rather than assumed. This is that document. It applies automatically to every event; there is nothing to sign.

Who is who

Controller: you, the account holder who created the event. Processor: Marcel Meijer, contactable at info@kynto.eu.

For your own account — your email address, your login, your billing — I am the controller and the privacy policy applies instead. This agreement covers only the data of your guests.

What is processed, and for whom

• Subject matter: running a shared event album on your behalf.
• Duration: from creating the event until it is deleted, either by you or by the retention period you chose.
• Categories of people: your guests, and anyone who appears in a photograph taken at your event — including people who never visit the gallery.
• Categories of data: photographs and videos, an optional display name, a language preference, chat messages if you enable them, a hashed session cookie, and a salted hash of the IP address a consent was given from.
• Special-category data: if, and only if, you switch face matching on — biometric templates of guests who consent, and of the faces in the photographs they are matched against. This is Article 9 data and is treated separately below.

Face matching, and what you are promising

Face matching is off by default. Switching it on asks you to confirm that you have told your guests, and records that confirmation with a timestamp. That confirmation is the whole legal basis for the feature, so it is worth being blunt about what it means.

A biometric template is special-category data under Article 9. Article 9 has no "legitimate interest" escape the way Article 6 does — for this purpose the only realistic basis is the explicit consent of the person concerned. I cannot obtain that: I have no relationship with your guests and no way to reach the stranger in the background of a group photograph. You were in the room; you can. By enabling the feature you are stating that you have informed the people who will be photographed, and that duty is yours, not mine.

What I do to keep the exposure small, whether or not you do your part:

• Nothing is computed until somebody asks. Enabling the switch creates no templates. The first guest to consent and submit a selfie starts the indexing. At an event where nobody uses the feature, no biometric data is ever created.
• Templates expire early. They are erased 30 days after last use, independently of how long the photographs are kept. A guest who returns later simply takes another selfie.
• A selfie is never stored. It is turned into a vector and discarded in the same request.
• Anyone can opt out without identifying themselves — no account, no name, no photograph. Requests that cannot be matched automatically are passed to you.
• Switching the feature off erases everything it created, immediately.

My instructions are yours

I process this data only on your documented instructions, which in practice are the settings you choose in the event: whether guests may upload, whether they may download, whether chat is on, whether face matching is on, and how long the event lives. I do not use your guests' photographs for anything else — not to train models, not for analytics, not to improve the product.

If an instruction of yours would breach data protection law, I will say so rather than follow it. If I am legally required to process something beyond your instructions, I will tell you before doing it unless the law forbids me from saying so.

Confidentiality and security

Access is limited to me. Everything travels over TLS. Photographs live in EU object storage; the database and the application run on a server in the EU. Guest sessions are identified by a hashed token, and IP addresses are hashed with a salt rather than stored. Biometric templates never leave the server and are never exposed through any API.

Backups are encrypted before they leave the machine. Administrative access to the server is by key only.

Sub-processors

I use these, and only these, and will tell you before adding another so you have a chance to object:

• OVH (EU) — object storage for photographs and video, and the server.
• Netcup (EU) — hosting for the application server.
• Google (Firebase Cloud Messaging) — push notifications. Receives a device token and the notification text; never photographs.
• The mail provider configured for outgoing email — invitations and retention warnings. Receives an email address and the message.

No sub-processor receives biometric data. Face matching runs entirely on my own infrastructure, on a container with no route to the public internet.

Helping you meet your own obligations

If a guest exercises a right — access, erasure, objection — send it to me and I will act on it, or give you what you need to answer. The event dashboard already lets you delete individual photographs, remove a guest, and erase all face data at once.

If you need to carry out a data protection impact assessment, the assessment I have written for the face matching feature is available on request; it is the same analysis you would otherwise have to repeat.

Breaches

If I become aware of a breach affecting your event, I will tell you without undue delay and in any case within 24 hours, with what I know: what happened, whose data, what the likely consequences are, and what I have done about it. Reporting to the supervisory authority is your call as controller; I will give you what you need to make it.

Deletion and return

When an event is deleted — by you, or when its retention period runs out — the photographs, the chat, the guest records and every biometric template are removed, and the underlying objects are deleted from storage. Encrypted backups age out on their own schedule within seven days.

Before that happens you can download the whole album. Ask if you want it in another form.

Audit

You may ask me to demonstrate that I am doing what this document says, and I will answer honestly and in detail. A full on-site audit of a one-person operation is not a realistic thing to offer and I would rather say so than pretend otherwise; what I can do is show you configuration, logs and code for the parts that concern your event.

Changes

This agreement is versioned. If it changes materially I will tell account holders before the new version takes effect. The version in force for an event is the one recorded when face matching was enabled.

This is a plain-language agreement rather than a lawyer's draft. It is written to be accurate and to be read; if you need it in a more formal shape for your own compliance, ask and I will provide one.