Privacy notice

A notice like this has to start by naming the business that decides what happens to your data — the controller, in the words of the General Data Protection Regulation. That is the business named above. While those details are still blank this document names nobody, which is a gap rather than a nuance, and it is listed as blocking publication for exactly that reason.

Questions about anything written here, and every request described further down, go to hello@ceremonystudio.example. A person reads that address; there is no ticketing system behind it.

There is no data protection officer, and one is not required: that duty falls on public authorities, on businesses whose core activity is monitoring people at scale, and on those processing special categories at scale. A planner running a handful of weddings a year is none of the three. The address above is the one to write to.

Three things, which are one system: the public pages describing the weddings and the plans; the planning software behind them, which a couple, a planner or a supplier signs in to; and the wedding pages couples publish through it, which guests read without an account.

Four kinds of person appear in it. A couple, whose wedding it is. A planner or administrator, who runs it. A supplier — a venue, a caterer, a photographer — booked onto it. And a guest, who was invited to one and never signed up for anything. The section below is written for the fourth, because the law treats that case differently and because it is the one nobody else writes.

Your details did not come from you. They came from the couple getting married, who typed or imported their guest list — the name on your invitation, how many of you were invited, and an email address if they had one. That is what the law calls obtaining data from somewhere other than the data subject, and this section is the notice owed when that happens.

Held about you: the name as the couple wrote it, the size of your party, the code printed on your invitation, an email address if they had one, whether you replied and what you said, and anything you typed into the form yourself — dietary answers, access needs, and a message to the couple if you left one.

Used for: sending you an invitation, counting heads, seating a room, and giving the caterer numbers they can cook to. Not for advertising, not for a mailing list, and not for anything after the wedding.

You can object to any of it, ask for a copy of it, correct it, or ask for it to be removed — see the section on what you can ask for. Doing so needs no account, because you never had one. Telling the couple directly works too, and is usually faster: it is their guest list.

Every category the system stores, the purpose it is stored for, and the lawful basis under Article 6 that permits it. Where the basis is a legitimate interest, the interest is named rather than asserted, because an unnamed one cannot be argued with.

The one row that is not an Article 6 question is the fourth. Dietary answers are health information, which Article 9 forbids processing at all unless a specific exception applies, and it has a section to itself below.

An allergy is a fact about your health, and so is a wheelchair, a guide dog and the severity of a reaction. Article 9 of the GDPR prohibits processing that kind of data unless one of a short list of exceptions applies. The one relied on here is the first: your explicit consent.

In practice that means the question is optional and answering it is the consent. Nothing is inferred, nothing is filled in for you, and a blank answer is a valid RSVP — if you would rather tell the couple directly than type it here, do that instead and nothing is recorded by us at all. The form says so where it asks, in the language the form is written in.

Who sees what you write: the couple, the planners working on that wedding, and the suppliers who need it to do their job — the caterer, and the venue where access is concerned. Nobody else, and that is enforced by policies in the database rather than by which buttons a screen shows. It is used to cook and to seat, and for nothing else.

You can take that consent back at any time by writing to hello@ceremonystudio.example or by telling the couple. Doing so removes the answer; it does not undo the meals already planned around it, and it does not make what happened before unlawful.

We ask for what a kitchen needs and not for a diagnosis. The fourteen tick-boxes are the list EU regulation 1169/2011 requires a food business to declare — the same list the caterer already works to — and the free-text box beside them exists so nobody has to squeeze a condition into a category that does not fit.

Inside a wedding: the couple, the planners working on it, and the suppliers booked onto it — each of whom sees the part of it their job needs and not the rest. A supplier cannot read another supplier's booking, and a couple cannot read another couple's wedding. That is a property of the data rather than of the screens.

Nothing is sold, nothing is shared with a data broker, nothing funds advertising, and no analytics service is used at all — the cookie policy lists what is stored in your browser, and the answer is four keys, none of them a cookie and none of them a tracker.

Outside a wedding, five businesses are involved in running the service. Two hold everything, and three see a fragment when a particular button is pressed:

Both Google services and Spotify are operated by businesses in the United States, so using one of those three features sends the fragment described above outside the European Economic Area. Chapter V of the GDPR governs that, and it is declared here rather than left to be inferred from a provider's name.

What each transfer relies on is the receiving provider's own data processing terms — the EU–US Data Privacy Framework where that provider is certified under it, and the European Commission's standard contractual clauses where it is not. Confirming which applies to the specific accounts this deployment uses is part of the professional review this document is still waiting for, and this paragraph will say which rather than saying both once it has happened.

All three are optional and none of them runs on its own. No passage is translated until somebody presses translate, no address is looked up until a venue is saved with one, and nothing is sent to a music service until a word is typed into the search box. A guest reading a wedding page triggers none of them.

The periods below are what this business works to. One thing has to be said plainly beside them: there is no application server in this architecture and therefore nowhere for a scheduled job to live, so nothing expires on a clock today — deletion happens because somebody performs it. That is a real limitation, it is recorded as outstanding work rather than papered over, and it is the reason the right to erasure below is answered by a person rather than by a countdown.

A couple's wedding page is published at an address containing a few random characters. That address is unguessable in practice and it is not secret: anyone holding it can read the page, and anyone sent it can forward it. It is a public page, deliberately — that is how a guest reaches it with no account, on a phone, at an airport.

The RSVP form confirms whether an exactly-spelled name is on a guest list, which is what makes it usable by somebody who has no account and no code. Somebody who guessed both a published address and a name could learn that the name was invited. Both facts are consequences of a wedding page that works for the guests it was made for, and both are stated here so that nobody discovers them afterwards.

The rights the GDPR gives you, in the words that describe what they do: a copy of what is held about you, a correction of anything wrong, deletion of it, a pause on using it while a dispute is settled, a machine-readable export of what you gave us, an objection to a use that rests on a legitimate interest, and the withdrawal of a consent you gave.

How: write to hello@ceremonystudio.example, saying what you want. The answer comes within one month, and it costs nothing. Where it is not obvious who is asking, we will ask enough to be sure — for a guest that means the name on the invitation and whose wedding it was, not a passport.

None of this needs an account. A guest never had one, and requiring somebody to create an account before exercising a right over data they never handed over would be the wrong answer twice.

Where a request touches a couple's own guest list, we will normally tell them: it is their wedding and their list, and a guest disappearing from a headcount without explanation is a problem for the person cooking. Ask us not to and say why, and we will weigh that.

If you think this has been handled badly, you can complain to a supervisory authority. In the Netherlands that is the Autoriteit Persoonsgegevens; if you live or work in another EU country, the authority there can take your complaint instead.

We would rather hear it first, if you are willing — most of what a notice like this gets wrong is fixable in an afternoon by the people who wrote it.

No decision with a legal or similarly significant effect is made about anybody by software. Nothing profiles you, scores you, or sorts you into a category you were not told about.

No advertising, no ad network, no conversion pixel, no fingerprinting, and no analytics of any kind — not as a promise but as a property of the bundle: the site ships a Content Security Policy that lets these pages talk to their own database and nowhere else, so a tracker added by accident would be refused by the browser rather than quietly run.

Children appear on guest lists, because children go to weddings. Their details reach us the same way every other guest's does — from the couple — and what is held is what a seating plan and a kitchen need: a name, that they are in a party, and an allergy if one was declared.

Accounts are a different matter. There is no self-service sign-up on this system at all; an account is issued to a named adult by invitation, and nothing here is offered directly to a child.

The date at the top is when this last changed, and the version on this page is the current one. It changes in the same release as the behaviour it describes rather than afterwards, which is the whole reason it lives in the repository beside the code.

This document is written in English, on a site published in five languages. That is a deliberate choice and the same one the terms of use make: a machine-drafted legal translation is a liability rather than a courtesy. The link to it is translated everywhere it appears, and the sentence that points a wedding guest here is translated into every language the RSVP form itself is written in — because a consent nobody could read would not be a consent at all.

It has been written by the people who built the software and has not been reviewed by a lawyer. It is accurate about the system, which is the half that usually goes wrong. Anything you think it gets wrong: hello@ceremonystudio.example.