Data protection impact assessment — template

How to use this template

A data protection impact assessment is the controller's to carry out, and for an event page that is you, not heer(ish). GDPR Article 35 asks for one where processing is likely to result in a high risk; a private page showing where a few hundred people are staying is close enough to that line that the honest answer is to do one and keep it, even if you conclude the risk is not high.

Everything below is filled in as far as heer(ish) can fill it in. Replace anything in square brackets, delete what does not apply to your event, and keep the result with your records. heer(ish) does not store your completed assessment and never sees it.

Use your browser to print this page or save it as a PDF. Article 35(7) asks for four things — a description of the processing, an assessment of necessity and proportionality, an assessment of the risks, and the measures taken to address them — and they are the four parts that follow.

1. Description of the processing

Controller: [your organisation, address, and the contact point for data protection questions]. Processor: heer(ish), run by thatUkrainianGuy, Berlaarstraat 53, 1066 PJ Amsterdam, the Netherlands.

Purpose: to let the people attending [event name, dates, city] see who else is in town and arrange to meet, and to reduce the isolation of attendees travelling alone.

Data subjects: the people registered for or invited to the event — approximately [number], of whom [number] are expected to add a card. Adding a card is optional; an attendee who does nothing appears nowhere.

Personal data: name, and optionally a role or organisation, a photo, the dates in town, a named lodging place and a phone number. Each optional field has its own unticked checkbox and can be removed at any time. Sign-in uses [passphrase / a one-time link to the attendee's email address / Google, LinkedIn, Apple or your own Mighty Networks community, which also gives heer(ish) the member's email address to keep and their short bio to prefill the card's note / a link sent only to addresses on the roster you upload]. An attendee who switches notifications on for a device adds the address that device's push service issued and the keys that encrypt notifications to it, kept until they switch them off, sign out there or the card is deleted, and at the latest until the event is.

Special category data: none. No field asks for health, dietary, accessibility, religious or identity-document data, and attendees are told not to enter it.

Recipients: other signed-in attendees of this event, to the extent each attendee chooses; your organisation, through the console; the sub-processors listed at heerish.app/subprocessors; and, for an attendee who switches notifications on, the push service of their browser (Apple, Google, Mozilla or Microsoft), which carries the notifications encrypted and cannot read them.

Retention: the event is deleted in full on [deletion date], which is [number] days after it ends. Live systems are clear within 24 hours of that date and backups within 30 days. An email delivered through Resend is the exception: Resend keeps it for 30 days after it was sent, and in its backups for 7 more.

Transfers: the event is stored in [the European Union / the United States]. Transfers to the United States run on the standard contractual clauses, with the EU-US Data Privacy Framework as an additional safeguard, as set out at heerish.app/dpa.

2. Necessity and proportionality

Lawful basis: [Article 6(1)(f), the legitimate interest of the organisation and its attendees in making an event work — or Article 6(1)(a), consent, if you prefer to treat the whole page as consent-based]. Each optional field on a card is separately consented to under Article 6(1)(a) whatever basis the page as a whole runs on, and consent is logged with its wording, its version and the time it was given.

Legitimate interests assessment, if you rely on Article 6(1)(f): the interest is a functioning event where people can find each other; the processing is necessary because no less intrusive means achieves it, since a paper list or a group chat spreads more data to more people with no deletion date; and the balance favours the processing because participation is voluntary, every field is opt-in, the audience is limited to other attendees of the same event, and the data is deleted on a fixed date.

Legitimate interests assessment for invitations, which rest on Article 6(1)(f) whatever basis the page runs on: the interest is telling the people on your own list of registered or invited attendees that the page exists. The processing is necessary because those people cannot use a page they do not know about, and the email uses only the name and address you already hold. The balance favours it because the recipients registered for or were invited to the event and can reasonably expect to hear from you about it; each email carries the notice Article 14 requires, and the right to object set apart from the rest; one click on its unsubscribe link stops every further email at once, with no condition attached; and the list is deleted with the event.

Legitimate interests assessment for the called-off email, also on Article 6(1)(f): the interest is telling the people going to a plan that it is off before they set out for it, whether you or the plan's proposer called it off. The processing is necessary because the page's own list of called-off plans does not reach someone already on their way. An opt-in when answering a plan ("email me if this is called off") was considered as the less intrusive alternative and is not as effective: it reaches only the people who thought to tick it, for a message that matters only before the plan starts. The balance favours the email because the recipient said they were going themselves and can reasonably expect to be told; it carries only the plan's title and time, and leaves out the title when you called the plan off; it is sent at most once per plan; it goes only to attendees whose card is still live, so deleting a card stops it; and one click on its unsubscribe link stops it at once, with no condition attached.

Data minimisation: the only mandatory field is a name. Lodging is recorded as a named place — a city, a district or a hotel — never as a coordinate, and the organiser sets the finest precision the event allows, with the default being the city.

Proportionality of the alternatives considered: [what you would do instead — a printed attendee list, a WhatsApp group, nothing at all — and why this is a better fit].

Information to data subjects: the privacy notice linked from the event sign-in page, before anyone adds a card. Attendees exercise their rights on the page itself: editing, hiding and deleting are all one action. Deleting a card takes it off the event for everyone at once and deletes its photo at once; the card's row and its edit history are erased with the rest of the event on the deletion date.

3. Risks, and what is already built against them

Risk: an attendee is located by someone who wishes them harm. Mitigation already built: lodging is a named place and never a coordinate; there is no distance, no proximity sort, no "nearby" and no radius filter anywhere in the product or its API; the API never returns a precision finer than the one on display; hotel-level precision requires the organiser to acknowledge a logged warning; the phone number and the lodging are separate opt-ins. Residual risk: an attendee who shares a hotel name shares it with everyone signed in to the event. [Low / Medium — your call, given who is on your invitation list.]

Risk: someone who is not an attendee reaches the page. Mitigation already built: the page is not indexable and is excluded from search engines; the sign-in modes other than the shared passphrase tie a card to a verified email address or an identity provider; the roster mode sends a link only to an address you uploaded. Residual risk: a shared passphrase can be forwarded. [Choose a sign-in mode other than the passphrase if your attendee list is sensitive.]

Risk: harassment between attendees. Mitigation already built: block is instant, mutual, needs nobody's approval and notifies no one; a report makes reporter and reported invisible to each other immediately, with human review following separately; an actioned person is never told that someone reported them; hiding a field is indistinguishable from never having shared it. Residual risk: moderation is only as fast as the safety contact you name. [Name someone who reads reports during the event, with a response time you can meet.]

Risk: data stays around after the event. Mitigation already built: every event has a deletion date fixed at creation and enforced by a scheduled job, with a receipt showing what was deleted and when. Residual risk: backups are overwritten within 30 days rather than immediately, and an email delivered through Resend stays there for up to 37 days after it was sent. Low.

Risk: a child adds a card. Mitigation already built: every preset carries an "I am 16 or over" confirmation on card creation, and under-16s are never cards. Residual risk: the confirmation is a statement, not a verification. [If your event includes minors, do not use heer(ish) for them.]

Risk: data reaches a third country. Mitigation already built: the storage region is chosen per event; the EU setting is enforced by the database's own jurisdiction restriction, while the US setting is a database created in the United States, in Cloudflare's eastern North America location, with no jurisdiction restriction behind it; the named recipients and safeguards are at heerish.app/subprocessors. Residual risk: email is delivered through a worldwide network and, when that fails, through Resend, which stores it in the United States. Low.

Risk: an attendee's image is processed biometrically. Mitigation already built: none is possible — heer(ish) runs no face detection, no face search, no duplicate detection, no auto-tagging, and sends no photo to any third party. Residual risk: none from heer(ish).

Risk: a breach at heer(ish) or a sub-processor. Mitigation already built: no organiser or attendee has a password of their own, and an event's shared passphrase is stored only as a hash; organiser accounts require a second factor (a passkey or an authenticator app) after the email link, so a stolen inbox alone does not open the console; sign-in links are stored only as hashes; the card PIN is stored as a PBKDF2 hash; data is encrypted in transit and at rest; each event is separated from every other; heer(ish) notifies your security contact within 24 hours of becoming aware of a breach. The measures are described at heerish.app/security. Residual risk: [your own assessment].

4. Measures you take, and sign-off

Measures on your side: [who may sign in to the console, what you tell attendees before the event, who answers safety reports and how quickly, how you handle a request from an attendee, what happens to any list you upload after the event].

Consultation: [whether you asked your data protection officer, and what they said; whether you asked a sample of attendees, and what they said. Article 35(2) and 35(9)].

Conclusion: [the residual risk is / is not high after these measures]. Where it remains high after every measure you can take, Article 36 requires you to consult your supervisory authority before starting.

Reviewed and approved by [name, role, date]. Review again if the event grows substantially, if you change the sign-in mode or the lodging precision, or if this template changes — the date under the title above is its version.

Questions

heer(ish) will answer what it can about its own side of the processing: write to privacy@heerish.app. This template is information, not legal advice, and it is not a substitute for your own assessment.