Data Processing Agreements for Event Tech: What to Check Before You Sign

A photo-sharing tool for your next conference looks like a small purchase. It is one event, a few hundred attendees, a QR code on a lanyard. Then legal asks for the Data Processing Agreement, and the small purchase becomes a procurement question — because the moment that tool collects a photo of an identifiable attendee, it is processing personal data on your behalf, and the contract that governs that processing is the DPA.

This guide is for the person who has to read that document before signing: the event manager, the HR lead, the procurement or IT reviewer running corporate events in the EU/EEA. It walks through what a Data Processing Agreement has to contain under the GDPR and what to check in a vendor's DPA before you commit. The aim is not to make you a lawyer — it is to let you read a DPA, know what "good" looks like clause by clause, and spot the gaps that should stop a signature.

Not legal advice. This is general guidance that cites the GDPR directly so you can check each point against the source text. It is not a substitute for advice from your own data protection officer or counsel on your specific event. Where this article names a Gathmo capability, it is to show what a compliant arrangement looks like in practice — verify the equivalent for whatever platform you choose.

The DPA is not boilerplate. It is the legal instrument GDPR requires whenever one organisation processes personal data on behalf of another, and it exists because of how the regulation splits responsibility. When you run a corporate event and decide to collect attendee photos and video, your organisation is the controller — you decide why and how the data is processed. The photo-sharing platform that stores and displays those images on your instructions is the processor. Article 28 says that relationship "shall be governed by a contract or other legal act" binding on the processor — a written agreement setting out the subject-matter and duration of the processing, its nature and purpose, the type of personal data and categories of data subjects, and the controller's obligations and rights (GDPR Art. 28(3)).

So if an event tech vendor processes your attendees' personal data, EU law obliges you to have a DPA — there is no "it's just one event" exemption, and the duty falls on you as controller as much as on the vendor. A missing or thin DPA is therefore a deal-stopper, not a nice-to-have: it is the one document that makes the whole arrangement lawful.

One scope note before the clauses: everything below assumes ordinary photo and video galleries — storing and displaying images. If a tool runs facial recognition to group or identify attendees, the data and the obligations change materially (more under sub-processors below); a face template built to uniquely identify a person is biometric data under a far stricter regime (GDPR Art. 9(1); Recital 51).

A DPA is not "good" because it is long or written on a law firm's letterhead. It is good when it actually contains what Article 28(3) requires. Read any vendor's agreement against these elements — a DPA that omits them is incomplete however polished it looks:

Those nine elements are the spine of any compliant DPA. You need not memorise the sub-clause letters — but reading a vendor's agreement, you should be able to find each idea in it. A gap here is not a formatting quibble; it is a missing legal obligation.

The clauses above tell you what a DPA must say. This section is about what to check against a specific vendor before you sign — the practical questions a procurement review actually turns on. Work through them in order; the first one is a gate.

Fail item 1 and the rest is moot. Pass it but stumble on 3, 4, or 5, and you have specific, citable gaps to raise before signing — exactly the position you want to be in during a procurement review.

For event tech, the sub-processor clause hides the most consequential detail — because a photo-sharing platform rarely does everything itself. It uses cloud storage, a media-processing provider, perhaps an email or SMS service, maybe an AI moderation engine. Each is a sub-processor touching your attendees' data, and Article 28 requires the same obligations to flow down to them (GDPR Art. 28(3)(d)). Two things to check beyond "does the clause exist":

Who are they, and where are they? A named sub-processor list makes the rest of your analysis possible. A provider outside the EU in the chain is not automatically disqualifying — but it is the point at which the transfer rules engage, and you need to know. A vendor that publishes its sub-processors hands you the map; one that won't is asking you to sign blind.

Does the stack pull you into stricter regimes you didn't ask for? This is the facial-recognition trap. A photograph of a face is not automatically special-category data — Recital 51 confirms images are biometric data "only when processed through a specific technical means allowing the unique identification or authentication of a natural person."

But a face-matching engine that builds templates to group attendees or let people "find all photos of me" is processing biometric data for the purpose of uniquely identifying a person, which Article 9(1) prohibits unless a specific exception (typically separate, explicit consent) applies (GDPR Art. 9(1); Recital 51). Several tools in this market lead with face-recognition photo-finding; at a corporate event with employees, that one sub-processor converts your photo collection into Article 9 processing and an explicit-consent obligation you never set out to take on.

So the sub-processor list is also where you check whether the data category quietly escalates.

Tooling note. Gathmo does not offer facial recognition or face-search at launch; it is a Phase 2 roadmap item, not a live feature. For a corporate buyer, that absence is the point — ordinary galleries build no face templates, so they stay out of Article 9 by default and the data category does not escalate underneath you.

A DPA does not, by itself, tell you where your data is. It governs the relationship; the location of the processing is a separate fact you have to establish — and it decides how much of the transfer regime you face. Transfers outside the EU are lawful only on an adequacy decision (Art. 45) or appropriate safeguards such as Standard Contractual Clauses (Art. 46), with enforceable rights and remedies (GDPR Art. 45, Art. 46(2)(c)). The EU-US Data Privacy Framework adequacy decision (adopted July 2023) remains in force as of mid-2026, so transfers to DPF-certified US organisations are possible — but it is not risk-free, and SCCs plus a transfer-impact assessment remain the prudent fallback (CJEU C-311/18 Schrems II; Commission DPF adequacy decision 2023).

The clean shortcut is to avoid the question entirely: keep the data in the EU, and there is no transfer to assess. Here the event-tech market splits sharply — looking only at each provider's own publicly available information as captured on 2026-06-08:

Gathmo is built for this check: EU data residency, with the primary database in Frankfurt, EU object storage and compute, and DPAs with its own processors. The residency comes with proof — a named data-centre location, not a marketing badge. Be precise, though: several vendors claim "European servers," so what a procurement team should test for is verifiable proof plus a signed DPA, not the EU claim alone.

Of all the obligations a DPA carries, deletion is the one most likely to be tested in the real world — because your attendees have a right to it, and it comes with a clock. Under Article 17(1) a data subject can require erasure without undue delay where a ground applies (the data are no longer necessary, or consent is withdrawn and there is no other legal basis), and Article 12(3) sets the deadline: respond without undue delay and in any event within one month of receipt, extendable by two further months only for genuinely complex or numerous requests, and only with notice of the extension within that first month (GDPR Art. 17(1); Art. 12(3)).

For the DPA, that is two checks. First: does the contract commit the processor to assist with — and action — deletion on request, including a specific person's erasure request, within the statutory window? That is the Article 28(3)(e) obligation made concrete; ask it directly and get it in writing. Second: does the engagement end with deletion or return of all the data (Art. 28(3)(g))? For Gathmo, GDPR-compliant deletion on request is part of the model — actioned within the statutory window on every tier — and because everything lands in one managed gallery, a one-month erasure request is one action, not a scramble across phones and shared drives.

A last word on the default alternative — collecting event photos through a WhatsApp group, a shared drive, or a chain of personal emails. That approach does not have a weak DPA; it has no DPA and no possibility of one — no processor to contract with, no sub-processor list, no defined retention, no deletion path, no audit trail. (It is also unpopular with the people in the chat: one survey found 40% of respondents felt overwhelmed by group-chat messages and notifications — The Conversation, 2023.) Ad-hoc collection cannot pass a DPA review because there is nothing to review.