EU Data Residency for Event Photos: Why It Matters for B2B Procurement

A photo-sharing tool for your next conference looks, on the surface, like a low-stakes purchase. Guests scan a QR code, upload from their phones, and you get the album. It is the kind of thing an event manager can sign up for in an afternoon — until it reaches the desk of whoever owns vendor risk, and the first question comes back: where is the data actually stored?

For an EU enterprise, that question is not bureaucratic friction — it determines whether the tool can be approved at all. The photos are personal data of identifiable employees, clients, and guests, and the moment they leave a phone and land on a server, the jurisdiction of that server pulls the purchase into a body of law — the GDPR's rules on international transfers — that procurement is obliged to clear before signing.

This guide is for the people who answer that question: procurement, IT, and legal gatekeepers evaluating an event photo platform. It explains what "EU data residency" actually means (and how it differs from "GDPR compliant"), why it removes a specific legal burden from your team, how the EU–US transfer rules stand in mid-2026, and how to verify a vendor's residency claim instead of trusting the badge. It is written for the EU/EEA context.

What does "EU data residency" actually mean?

Data residency is the answer to which country's servers physically hold and process your data. For an event photo platform, that data is the uploads themselves — photos, videos, voice messages — plus the database records and any backups that describe them.

It is worth separating three things vendors often blur together in marketing copy:

• Data residency — where the data is stored and processed (the data centre's jurisdiction).

• Company location — where the vendor is incorporated. A company headquartered in Berlin can still store your data in Virginia; a US-incorporated company can host in Frankfurt. The two do not have to match.

• "GDPR compliant" — a claim about the vendor's practices generally. A US-hosted tool can be GDPR-compliant and still trigger a cross-border transfer the moment EU employees' photos hit its servers. It is not a synonym for "EU-resident."

This distinction matters to procurement because residency is the single fact that decides whether a transfer of personal data outside the EU has happened at all. Keep the data in the EU, and the transfer rules in Chapter V of the GDPR never come into play. Move it to a third country, and they do — with everything that follows.

Why does data residency matter for B2B procurement specifically?

Because the GDPR makes leaving the EU a regulated act, and the burden of proving it was done lawfully sits with you — the controller — not the vendor.

Under Chapter V, a transfer of personal data to a third country is lawful only if it rests on an adequacy decision (Article 45) or, failing that, on appropriate safeguards such as the European Commission's Standard Contractual Clauses (Article 46(2)(c)), with enforceable data-subject rights and effective remedies. That is not a box a vendor ticks for you. If your conference photos are processed in the United States, your organisation has to show which mechanism made that lawful — and, after Schrems II, that you assessed the destination and documented supplementary measures (more on the current rules below).

In practice that is concrete work a US-hosted tool creates and an EU-hosted tool removes: a transfer-impact assessment to perform and document, a defensible legal basis on file ready for a supervisory authority, and ongoing exposure to a legal status that has shifted more than once in the last decade — each shift a re-assessment for every US vendor you use. Keeping the data in the EU collapses all of that to nothing: no transfer, so no mechanism to choose, no impact assessment, and no adequacy decision whose fate you have to track. For a team trying to clear a low-value tool without a month of legal review, that is the value of residency — the difference between a quick approval and an open compliance file.

"But we already have a DPA" — isn't that enough?

A Data Processing Agreement and data residency answer two different questions, and you generally need both. When an external tool processes personal data on your behalf and on your documented instructions, Article 28(3) requires a binding written contract — the DPA — governing how the processor handles the data. But that contract does not, by itself, answer where the data lives or whether a cross-border transfer is lawful; that is the separate Chapter V question above. A vendor can hand you a perfectly good Article 28 DPA and still process your photos in a third country, leaving the transfer question open. So the procurement checklist is not "DPA or EU residency"; it is "DPA and a clear answer on residency." (For what an Article 28 DPA must actually contain, see our companion guide, Data Processing Agreements for Event Tech, linked below.)

How do the EU–US transfer rules stand in mid-2026?

This is the part that makes residency attractive as a simplification. The short version: transfers to the US are currently possible, but the ground has shifted before and an appeal is live, so a US-hosted tool is an ongoing assessment rather than a settled one. The state of play as of mid-2026:

• Standard Contractual Clauses survived, but with conditions. Schrems II invalidated the old Privacy Shield in 2020 while upholding SCCs in principle — subject to the case-by-case transfer-impact assessment and supplementary measures described above.

• The EU–US Data Privacy Framework adequacy decision is in force. Adopted on 10 July 2023, it lets transfers to DPF-certified US organisations rely on an Article 45 adequacy basis. The EU General Court dismissed the first challenge to it (T-553/23, Latombe v Commission) on 3 September 2025, confirming the US ensures an adequate level of protection.

• But an appeal is pending. An appeal against that ruling (C-703/25 P) is before the CJEU, with no hearing date announced as of mid-2026. The practical reading: the DPF is usable now, but it is not risk-free, and SCCs plus a transfer-impact assessment remain the prudent fallback.

None of this is a reason to panic about US tools. It is a reason to recognise that choosing one means owning a question whose answer has changed before and may change again — and re-papering every affected vendor each time it does. Choosing an EU-resident tool means the question never opens, and takes you out of the line of fire of the next Schrems-style decision.

The market splits sharply on residency — here is how it looks

Check where these tools actually host data and the market divides into three camps. The following reflects each provider's own publicly available company and privacy information as captured on 2026-06-08 — the gaps are as telling as the claims.

Explicitly US-based. Several popular tools state plainly that data sits in the United States, with no EU option: GuestCam (hosted on US-based cloud storage, no EU/European hosting), Kululu (primary content on Google Cloud / Firebase servers in the US), Fotify (operated by Lumenlio, LLC, a Delaware company), and Wedibox (a US company, Wedibox LLC). For any of these, an EU enterprise processing employee or guest photos is squarely in third-country-transfer territory and owns the full assessment.

Explicitly EU-resident. A smaller set names EU/EEA hosting directly: EventPics (run by an Austrian company, Aigner Software e. U., hosting in an EU region), JoinMyMoment (EU/EEA hosting, with sub-processors in Germany (Hetzner), France (Scaleway), and AWS Frankfurt), and Lense (servers in the European Union, personal data primarily stored and processed there). These are the tools where the transfer question does not arise.

Unstated or unclear — which is its own red flag. A meaningful share of tools do not clearly say where data lives. Several Germany- or EU-marketed apps lean on "Made in Germany" or "European servers" language without an explicit server statement; others — with an undisclosed company location, or running on Google Cloud with no stated EU region — leave the jurisdiction genuinely unknown. For procurement, unstated residency is a finding, not a neutral. If a vendor cannot tell you the hosting jurisdiction in writing, you cannot complete your transfer analysis, and the tool should not clear review until it does.

One caution: an EU residency claim on a marketing page is a starting point, not proof. The next section closes that gap.

How do I verify a vendor's EU data residency claim?

"DSGVO-konform" on a homepage is a marketing assertion. A procurement team needs evidence it can put in a file. Five questions turn a claim into something verifiable:

1. Name the data centre region, in writing. Not "Europe" in general — the actual jurisdiction (e.g. Germany/Frankfurt) for both stored uploads and the database. Ask for it in the DPA or an order form, where it becomes contractual rather than aspirational.

1. Get the sub-processor list. Most platforms run on third-party infrastructure — cloud storage, a database host, email and SMS delivery — and each sub-processor has its own location. A vendor that hosts in the EU but routes notifications through a US sub-processor still moves some personal data across the border. Ask for the full list and where each one sits.

1. Ask where backups and logs live. Primary storage in the EU does not help if nightly backups replicate to a US region. Residency has to cover the copies, not just the live data.

1. Confirm the DPA reflects it. The residency commitment and sub-processor terms should appear in the Article 28 contract you actually sign, so the obligation is enforceable — not just described in a blog post.

1. Ask about the erasure and deletion path. Residency is about where; you also need for how long and how to remove it. Confirm the vendor can action a data-subject erasure request within the statutory timeframe — under Article 17 the controller must erase without undue delay, and Article 12(3) sets a one-month response clock (extendable by two months for genuinely complex requests, with notice). A defined retention window plus a clear deletion path is what storage limitation (Art. 5(1)(e)) asks for in practice.

Answer all five cleanly and in writing, and you have residency you can defend. Point only to a badge, and you have a claim you can't.

Where Gathmo sits on this

Gathmo is built for exactly the procurement question this article is about. Its data residency is in the EU, with object storage in the EU jurisdiction, the primary database in Frankfurt, EU-based compute, and Data Processing Agreements in place with its processors. A DPA is available on request across the per-event tiers and is included on the B2B Studio, Agency, and Enterprise subscriptions. Retention is defined and finite rather than open-ended (the per-event tiers run from a 30-day window up to 2 years, depending on tier), which is the storage-limitation posture Article 5(1)(e) looks for. For a procurement or IT team whose default question is "does this keep our event data in Europe?", that is a yes that comes with the proof — a named data centre and processor DPAs — not a marketing badge alone.

Two points of honesty, because procurement should hear them from us rather than discover them later. First, 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 is a feature in itself: ordinary photo galleries that do not build face templates avoid the heightened, separate biometric-consent obligation that face-matching triggers under Article 9. Second, residency is becoming a crowded claim — several vendors advertise European servers — so we would frame Gathmo's edge not as "the only EU option" but as EU residency you can verify: a named jurisdiction, a sub-processor story, and a signed DPA. Run the five-question check above against us; that is what it is for.