GDPR wedding website: invitation codes, privacy and hosting

Most of what is written about privacy and weddings is aimed at the provider: where the servers stand, which contracts exist, which badge sits in the footer. Useful, but it answers a question you did not ask.

The part you actually control sits upstream of all of it. A form with four fields creates less to look after than one with twelve, and that holds in every jurisdiction, under whichever acronym applies where you are.

Most of the data is not created by the technology but by the questions you ask. Every field on the RSVP form is a decision that outlives the celebration: menu choice, allergy, plus-one, number of children, mobile number. A shorter form is the most effective privacy measure you personally control.

The second point is almost always missing from comparisons: what happens after the wedding? A page that quietly stays online is an open archive of names, replies and pictures. That is sensibly decided before booking. This is not legal advice — it is the set of questions worth putting to yourselves and to your provider in advance.

Before any rule can be applied, the inventory has to exist, and it is longer than couples expect.

Nothing on it is exotic. It is the ordinary by-product of inviting people, which is exactly why it accumulates without anyone deciding that it should.

To see what privacy concretely involves, list what actually accumulates, in the order planning creates it:

• the guest list you type yourselves: a name per invitation, often an email address, a head count;
• the access code belonging to that one invitation;
• the reply: yes or no, plus-ones, menu, allergies, shuttle, accommodation, high chairs;
• the seat assignment, once the seating plan exists;
• pictures and videos in the gallery, each carrying the invitation it was uploaded through;
• technical by-products: when an invitation email was last sent and when a record was last changed.

Two of these weigh more than the rest. Allergies and dietary notes say something about health and sometimes about religion. And photographs of guests and their children are what people still ask about years later.

The pricing model is a privacy decision in disguise, and this is the article where the two have to be looked at together.

Two questions carry most of it: how does this offer earn its keep, and what happens on the day it stops? Neither appears on a feature table, and both decide how long your guests' details go on existing.

For privacy, the interesting part is how a free offer earns its keep. Advertising on the guest page means third parties on a page holding acceptances and allergies. Requiring guests to create an account means their details sit with a provider on that provider's terms rather than yours.

Two questions decide more than the monthly fee: can the guest list be exported, and what happens when the term ends? Without an export, deleting costs you the keepsake, so nobody deletes. And if nobody states whether the page goes offline, gets deleted or simply keeps running on the closing date, retention is decided by accident. A subscription is not automatically worse either: if the gallery should stay open for relatives abroad for years, a fixed term is the wrong shape.

Access control at a wedding does two jobs, and the second one is the reason it belongs in a privacy guide at all.

Keeping strangers and search engines out is the obvious job, and most tools manage it. What separates them is what happens on the reply side.

Beyond protection, the code has a second job: it makes a reply attributable. An open reply page collects details from people you cannot reliably identify afterwards — and unattributable data is exactly the kind that is hardest to find and remove when somebody asks. Even where the content may be public, the form should stay behind the code.

If the code sits inside the QR code, nobody types anything, but it travels into chats and screenshots with every forwarded link. That is a fair trade as long as each invitation has its own code: a passed-on link then costs one blocked invitation rather than a new password for the whole circle. Which variant suits which wedding is covered in the guide to passwords and invite codes.

The General Data Protection Regulation is European law. It binds providers established in the EU and anyone offering services to people there, which for a wedding usually means it applies if your provider, your venue or a sizeable part of your guest list sits in Europe. Where it does not apply, its questions still translate: names, contact details, menu choices, allergies and photographs count as personal data under most regimes, and processor contracts exist elsewhere under other names.

Three things are worth establishing before you enter a single guest, whichever regime you are under: where the data is stored, who can open it, and whether guests reach the content only through an invitation code. For galleries and guest lists, less public visibility is nearly always the right default.

The questions are yours, not the tool's. So apply one test per field: what would we do differently once we know the answer? The allergy is answered by the caterer, the head count by the seating, the date of birth by nothing at all. Where there is no answer, the field goes.

Then come the copies: the caterer, the venue and whoever builds the seating plan all receive extracts, and those do not disappear when you delete your own list. Hand over the column that is needed and name a date by which the copy should be gone. If a guest asks what you hold about them, you should be able to answer from one place.

And plan the ending. The day after the celebration, the guest list is a keepsake and the allergy list is a liability. A workable order: download the gallery, export the guest list, block the access codes so old links lead nowhere, and take the page down. If a second celebration is still to come, postpone that date deliberately.

A short list of questions is more useful here than a feature comparison, because the ones that matter are about what happens after the wedding rather than during it.

Getting Married keeps guest replies behind a per-invitation code and gives the page a fixed term, so that taking it down is the default rather than something you have to remember.

Add the questions for afterwards, because comparisons almost never ask them: can a single picture be deleted? Can one access code be blocked without changing everyone else's? Can the page go offline without the account disappearing? And how many people end up holding a login to the admin area?

Agree between the two of you who answers guest questions and maintains the records. Two people correcting the same list independently is the most common reason for duplicate invitations and for replies nobody can find again. How to keep that list clean is covered in the online guest list guide.