Attendee data and privacy

Registration collects personal data. This page sets out what is stored, where it appears, and the practices that keep handling it defensible.

What is stored

Per registration, on the event:

• the email address;
• the telephone, when that field was enabled and filled;
• the comments, when enabled and filled;
• the country, when enabled and filled;
• the status — confirmed, waiting list or cancelled.

Plus a WordPress user account for the email address, carrying the name that was submitted.

Where it appears

It is never shown publicly. The event page shows counts and remaining places, never who registered.

The comments field is the sensitive one

Free-text comments regularly contain information people would consider private: health conditions, disabilities, mobility needs, dietary requirements tied to religion or belief.

Treat the comments column as the most restricted part of the record:

• limit who can open the event editor;
• do not copy comments into chats, tickets or shared documents;
• never include them in a support request;
• delete exported files when they are no longer needed.

Consent

The registration form shows a consent checkbox and your clause text only when a privacy policy URL is configured under Settings → POM Events → Single event.

Configure it before taking any real registration. Without it, the form collects personal data with no consent step and no link to your policy.

See Privacy and consent copy.

Collect less

The strongest privacy measure available to you is on the Registration form tab: turn off the optional fields you will not use.

• No telephone if you will never ring anyone.
• No country if you will not report on it.
• No comments if nobody will read them.

Every field you disable is data you never have to protect, export carefully or delete later.

Retention

POM Events does not delete anything automatically. Attendee data stays on the event until someone removes it, and past events keep their lists indefinitely.

Decide a retention policy and apply it manually:

1. How long after an event the list is kept.
2. Who reviews old events.
3. What is deleted — registrations, user accounts, or both.
4. What happens to exported files.

Write it in your privacy policy, then actually run it. A stated retention period nobody executes is worse than none.

Exports are copies

Every export is a new copy of the personal data, outside WordPress and outside your access controls.

• Name and store them in one known place.
• Do not email them casually.
• Do not leave them in downloads folders or shared drives.
• Delete them when the event's retention period ends.
• Never attach one to a support request — see Safe information to send with a support request.

Data-subject requests

Access. The person's data is on the event and in their user account. Compile it from the attendee panel and the export.

Deletion. Cancel and delete their registrations, delete the user account if the request covers it, and delete the exported files containing their data.

Correction. The name comes from the user account, edited under Users. Other values are stored with the registration.

What POM Events does not do

• It does not send anything to attendees, so it does not process their data for messaging.
• It does not share data with any external service on its own.
• It does not anonymise or delete on a schedule.
• It does not log who viewed or exported an attendee list.

Everything on that list is a responsibility that stays with the organization.

A short checklist

• [ ] The privacy policy URL is configured, so consent is collected.
• [ ] The clause text describes what is collected and why.
• [ ] Only the fields you actually use are enabled.
• [ ] Access to event editing is limited to the people who need it.
• [ ] A retention period is defined and someone runs it.
• [ ] Exported files are stored deliberately and deleted on schedule.
• [ ] Nobody sends attendee data in support requests.