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.

First, why event tech needs a DPA at all

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).

What a GDPR Article 28 DPA must contain

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:

• The processing description — subject-matter and duration, nature and purpose, type of personal data, and categories of data subjects (Art. 28(3)). For event media it should be legible that the processor handles attendees' photos, video, and any voice messages, to collect and display them, for a defined period. Vagueness here is itself a flag.

• Processing only on documented instructions (Art. 28(3)(a)) — you decide what happens to the photos; the vendor cannot repurpose them.

• A confidentiality commitment binding anyone the processor authorises (Art. 28(3)(b)).

• Article 32 security — appropriate technical and organisational measures for the risk (Art. 28(3)(c)).

• Sub-processor conditions — no further processor without authorisation, same obligations down the chain (Art. 28(3)(d)). This governs who else touches your data; its own section is below.

• Assistance with data-subject rights, including — critically for event media — erasure (Art. 28(3)(e)).

• Assistance with your Articles 32–36 duties — security, breach notification, and impact assessments where they apply (Art. 28(3)(f)).

• Deletion or return at the end of the engagement, at the controller's choice, plus deletion of copies unless law requires retention (Art. 28(3)(g)). This is the clause that ends the data's life — get it in the contract, not a sales email.

• Information for, and submission to, audits (Art. 28(3)(h)).

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 pre-signature checklist: what to verify before you commit

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.

1. Is there a DPA at all — and can you read it before you buy? The gate. If a vendor cannot produce a GDPR Article 28 agreement, an EU enterprise cannot lawfully use it for a corporate event, full stop — the contract has to be in place for the processing to be lawful (Art. 28(3)). Many consumer-focused photo tools are sold as a one-time purchase with no enterprise contracting path at all: fine for a private party, a blocker for a company event. Ask to see the DPA before you commit.

1. Does it contain the Article 28(3) elements above? Run it against the nine-element list. The ones most often thin in lightweight agreements are the sub-processor conditions, the deletion-or-return obligation, and the audit provision.

1. Will the vendor name its sub-processors and where they sit? A DPA that permits sub-processing without naming the sub-processors leaves you unable to complete a transfer or vendor-risk analysis — you cannot assess what you cannot see. (Section below.)

1. Where is the data hosted, and does any of it leave the EU? Keep it in the EU and you sidestep the transfer analysis; let it leave and you need a lawful mechanism the DPA's annexes should reflect. "We don't disclose that" is a fail. (Section below.)

1. Does the deletion path have a clock on it? Check that the DPA commits the processor to action deletion — including a specific person's erasure request — within the statutory timeframe (Art. 17(1); Art. 12(3)). (Section below.)

1. Is the DPA included, extra, or unavailable on your tier? A commercial check with compliance consequences. For Gathmo, a DPA is available on request across the per-event tiers and included on the B2B Studio, Agency, and Enterprise plans — so the contracting path exists whether you buy a single event or a subscription.

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.

Sub-processors: the part of the DPA that hides surprises

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.

Where the data lives: the residency question the DPA sits on top of

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:

• Several popular tools are explicitly US-based — GuestCam states its data is on US-based cloud storage with no EU option; Kululu stores primary content on Google Cloud (Firebase) servers in the United States; Fotify is operated by a Delaware, US company.
• A smaller set is EU-hosted and says so — EventPics (an Austrian company, hosting in an EU region) and JoinMyMoment (EU/EEA sub-processors in Germany, France, and AWS Frankfurt) name EU residency explicitly.
• Some tools do not clearly state where the data sits — its own red flag, because you cannot fill in a DPA's transfer annex against a blank.

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.

The deletion clause: a right with a deadline

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.