Student society member records and privacy in Ireland

Ireland edition. This guide is written for volunteer-run clubs in Ireland. Where rules differ — grants, tax, incorporation, safeguarding — follow the Ireland-specific pointers below or check with your national body.

Somewhere in your society there is a file called something like members FINAL v3 (2).xlsx. It has 340 rows, of which maybe 190 are real people who still reply. It lives in the personal drive of a secretary who graduated eighteen months ago. At least four other committee members have downloaded a copy since, and nobody has ever deleted one.

That file is simultaneously your society's most valuable asset and the only thing on your committee's watch that could genuinely get you into trouble. It is why you can fill a room in week three, it is the evidence behind your next grant application, and it is the difference between a society that still exists in five years and one that restarts from nothing. It is also a few hundred people's contact details, sitting somewhere your committee does not control, protected by nothing much at all.

This guide is about fixing that without turning seven students into a compliance department. It covers what to record and what never to record, who should see what, what the rules actually ask of a volunteer-run group, how long to keep things, the four breaches student societies really have, and how to hand the lot to next year's committee without emailing a spreadsheet to somebody's personal address.

Start by finding every copy of your member list

Before you decide what your society should hold, find out what it does hold. Give it forty minutes at a committee meeting and say each copy out loud. A normal mid-sized society finds somewhere between six and twelve:

• the sign-up spreadsheet from the club fair, plus the three exports somebody made from it
• the paper sign-up sheets, still in a folder under a bed
• a free form tool's response sheet, owned by whoever's personal account created the form
• the mailing list, wherever that lives
• the chat server's member roster, and the phone numbers attached to it
• last year's ticket buyer list from the ball, which nobody has opened since
• payment records, in the treasurer's banking app or a payment link's dashboard
• photos of the paper sheets, taken on the night, still in someone's camera roll
• a screenshot of a member's private message, pasted into the committee chat during a discussion about them

Next to each one, write three things: whose account it sits in, who else holds a copy, and whether that person is still on the committee. The rows that matter are the ones where the last answer is "no" — you are not hunting for wrongdoing, you are finding the copies your society can no longer reach or delete.

Then make one decision you can enforce: one system is the member record, and everything else is a temporary working copy with a delete-by date. Societies that skip this step end up publishing a privacy statement describing a database they do not have.

What a member record should actually contain

Two rules govern everything below. Collect only what you will use this year. And know, for every field, what happens to it when the person stops being a member. If you cannot answer the second question, that is a strong sign you should not be collecting the field.

Notice how much of that is per-event rather than permanent. A member who tells you mid-semester that they use a wheelchair has told you something about one night's logistics — not something the society should carry in a spreadsheet for four years and hand to a fresh set of strangers at every handover. Collect it on the event form, use it, delete it with that event's working data. If they would rather you kept it so they never have to ask twice, that is theirs to decide: ask, record the answer, honour it.

The table also makes the paid-until date a first-class field rather than a tick box. A society that records only "paid: yes" cannot answer the two questions that decide affiliation and funding — how many current members do we have today, and when does each of them lapse? An expiry date turns the renewal chase into a filter. Our membership fees guide covers the pricing side of the same field.

The fields that quietly become liabilities

Some fields are not merely unnecessary. They are actively bad news the moment anything goes wrong.

• Full dates of birth. Unless an activity has an age limit you must enforce, a birth year is plenty and usually not needed at all. A date of birth plus a name plus an email is a starter kit for someone else's fraud.
• Health information. "Asthma", "recovering from surgery", "anxiety". If a member volunteers it so you can look after them at one event, deal with it there and delete it afterwards. Where you genuinely need medical information — a hiking trip, a contact sport — collect it per-trip on a form only the trip leaders can open.
• Free-text notes about people. The single worst field in student society administration. "Difficult at the last meeting." "Keeps asking about refunds." All of it is usually disclosable to the person it describes, and eventually some of it is disclosed.
• Copies of identity documents. Photographs of student cards, passports or visas collected "to verify membership" have no place in a society's records. Verify by email domain, or look at the card and record only that you looked.
• Screenshots of private messages. A screenshot in a committee chat is a permanent copy in every committee member's phone backup, including the ones stepping down at the end of the year.
• Anything disclosed in a welfare conversation. Welfare notes are not member records. They need a tighter home, a much smaller audience and usually a referral — most of the time the society should not be keeping them at all.

A quick test before you add a field: could you read that row aloud to the person it describes without wincing? If not, it either should not exist or needs a far smaller audience than "the committee".

Who on the committee should see what

"The committee" is not an access level. A committee of seven usually contains one person who genuinely needs payment records, one who needs to email everybody, one who needs emergency contacts on a trip weekend, and four who need names and nothing more.

None of that is about suspicion. It is about being able to remove one person in ten seconds when they graduate, go on exchange or step down in week nine. A society with per-person access does that at the handover meeting. A society with one shared login can only change the password, which locks everybody out at once — so nobody ever does, which is why so many societies have a former treasurer who could still export four hundred contact details tonight if the mood took them.

Three habits make it real. One account per person, never a shared login — website, mailing tool and payment account alike. Access follows the role, not the friendship: grant it on election, revoke it at the handover meeting while everyone is in the room, and write the date in the minutes. Keep a record of who did what, especially who exported the list and when, because "we think it was fine" is not an answer when a member asks how their number reached a sponsor.

Roles and per-position permissions handle the first two, and an audit log handles the third — every role grant, export and settings change recorded automatically and not editable afterwards, which is the only thing that makes a trail worth having in a dispute.

The rules you are actually under

Most student committees assume privacy law is somebody else's problem — a thing for hospitals and banks. In practice, a society holding a few hundred people's contact details is holding personal information, and the duties that come with it are mostly things you would want to do anyway. Five hold true wherever your campus is.

1. Collect for a stated purpose. Say at sign-up what each thing is for, in one sentence a tired first-year can read.
2. Use it only for that purpose. A list built to run a society is not a list to hand to a sponsor, a candidate in a student election, or the friend starting a business.
3. Let people see, correct and leave. Someone should be able to ask what you hold, fix a wrong entry and be removed — and get an answer in days, not never.
4. Keep it secure and keep it small. Fewer copies, fewer fields, fewer people with access.
5. Name someone accountable. One committee role, written into the position description, so "who looks after our member data?" has a name as its answer rather than a shrug.

The layer that reaches you first is usually not the statute. It is your student association's own data policy, which your affiliation agreement binds you to, and your university's policy behind it. Read those first — they are shorter, more specific, and breaking them costs you affiliation, which hurts a great deal sooner than a regulator will.

Your society sits under GDPR and the Data Protection Act 2018, and the crucial question is who the controller is. In most cases the students' union is the controller and your committee processes member data on its behalf, which makes the union's data protection policy the rule book you actually follow and its data protection officer the person you ring first. You still need a lawful basis for each use: usually legitimate interests for running the society, and consent for optional marketing. Access requests have a one-month clock, so pass them straight to the union rather than letting them sit in a committee inbox. The Data Protection Commission publishes short guidance aimed at small voluntary organisations that is genuinely readable in one sitting. If your society runs a website and mailing list outside the union's systems, tell your clubs and societies officer, because that shifts responsibility towards you. This is general information rather than legal advice.

Consent: two boxes, asked once

Two consents are worth capturing at sign-up, because chasing them afterwards is miserable and guessing at them is worse.

Photography. A single tick box — "I'm happy for the society to use photos of me in its posts and on its website" — plus a visible sign at the door and a named person to speak to on the night. Store the answer against the record so whoever writes the recap post can check it in two seconds instead of asking the group chat. Have a route for "please take that one down" that is faster than the next committee meeting, because the slow version is how a small request becomes a complaint to your association.

Non-essential email. Split the mail your members need from the mail they might enjoy. "Your membership expires next month", "the AGM is on the 14th", "the trip is cancelled" — that is the service they signed up for, and it goes to every member. The weekly what's-on, the sponsor's discount code and the alumni appeal are different: those need a yes, a working unsubscribe link in every send, and a clear statement of who is sending them.

Record both as dated flags rather than institutional memory. "She said it was fine at the fair" is not a record. And when someone unsubscribes, treat it as a permanent preference, not a decision to revisit at the start of next year when a new communications officer re-imports an old list.

Electronic marketing sits under the ePrivacy Regulations alongside the data protection rules, and they are stricter than most committees expect: consent is generally required before sending marketing email to individuals, with only a narrow existing-customer exception that does not fit a society well. In practice that means a tick box at sign-up, a stored record of the date, clear identification of the society in every send, and a working unsubscribe in every message. Because your students' union is usually the controller of member data, its mailing tools already meet these requirements, which is a strong argument for using them instead of a personal address with three hundred pasted addresses in the Bcc field. The Data Protection Commission and ComReg both publish guidance on electronic marketing rules. Fines here are aimed at commercial senders, but the reputational route runs through your clubs and societies officer. General information only, not legal advice.

How long to keep it, and what to delete

Retention is where societies fail quietly. Nobody ever decides to keep the 2019 sign-up list. They simply never decide to delete it, and eight committees later it is still there.

Two habits make a retention schedule survive a committee change. Aggregate before you delete. "213 members in 2025, 61% first-years, 78% renewal rate" is worth keeping forever and is not personal information; the 213 names are not, and your grant panel wants the first thing anyway — a future committee can still tell the story without inheriting the risk (the record your history guide covers the rest). Put deletion in the calendar next to the affiliation deadline and the AGM notice date: fifteen minutes once a year, in the month after the handover, owned by the secretary and listed as an agenda item so it visibly happens.

The four breaches student societies actually have

Not one of these involves a hacker.

1. The reply-all. Someone pastes 300 addresses into the To or Cc field. Now every member has every other member's address, one person replies to all with something regrettable, and two members who were deliberately not in contact are now in contact. This is the most common privacy incident in student societies by a distance, and it is entirely preventable by sending bulk mail through something that sends one message per person. The email and newsletters guide covers the alternative, and why club emails go to spam covers the deliverability half.

2. The link that was never private. A form tool's response sheet, a shared spreadsheet or a sign-up document set to "anyone with the link", then pasted into a public post or a chat server with 900 members in it. Every field is visible, including the ones you thought only the committee could see. Nobody notices for months, and you find out when a member asks why their phone number is on a public page.

3. The graduate who still has access. A shared login, or an account nobody removed. Rarely malicious — just a person no longer accountable to anyone in your society who can still export the list, mail everyone or change the website. If your handover has no revocation step performed in the room, assume this is your situation right now. The handover checklist has the step; so does the dormant society guide if you are inheriting a mess.

4. The device and the export. A laptop left in a library, a phone full of camera-roll photos of the paper sign-up sheets, a USB stick with an export on it, or a chat history saved "as a backup" and mailed to a personal address. The fix is to stop making the export at all unless it has a job to do, and to delete it the day that job is finished. Where the platform itself takes care of encrypted backups, nobody needs a personal copy for safety.

Rehearse the response before you need it, because you will be doing it at 11pm during exam week. Whoever notices tells the president and the accountable committee member within the hour. Those two establish four things: what was exposed, whose it was, who saw it, and whether it can be pulled back. Write the timeline down as it happens — that is what you will be asked for. Then tell the affected people plainly, and tell your association.

Where the students' union is the controller, the statutory clock belongs to the union — but it is 72 hours from becoming aware, so your job is to tell the union's data protection officer immediately rather than spending a day assessing severity yourself. Contain it, report it, then write down the timeline while people still remember it. The union decides whether the Data Protection Commission must be notified and whether affected members must be told directly, and it will need your account of what was exposed and who saw it. If your society runs a website or mailing list outside union systems you may be a controller in your own right, which puts the obligation on your committee — worth confirming with your clubs and societies officer before an incident rather than during one. General information only, not legal advice.

The handover, and your one-page data register

Records are the part of a handover that people promise to "send through" and then do not. Do it in the room, in one sitting, in this order.

1. Transfer inside the system, not by export. If the register lives somewhere both committees can log in to, the handover is a permissions change. If it lives in a spreadsheet, the handover is an email that creates yet another copy.
2. Create the incoming committee's accounts at the meeting, one per person, with the permissions their role needs and nothing more.
3. Remove the outgoing committee's access at the same meeting, while everyone is present. Not "next week". Note the date in the minutes.
4. Delete the working copies. Go back to the list you made in the first section of this guide and work down it — exports, camera-roll photos, old response sheets — ticking each one off out loud.
5. Hand over the consent record and the unsubscribe list, so the new communications officer does not re-add people who left.
6. Hand over the retention calendar — the annual deletion job, the affiliation deadline, the AGM notice date.
7. Hand over the data register below, updated and dated.

Your society's one-page data register

Half a page, one file, reviewed at the first committee meeting of every year. It is what your association will ask for, and it makes every other decision in this guide obvious:

• What we hold — the categories, in plain words
• Where it lives — the one system, named, with its address
• Why we hold each thing — one line per category
• Who can see what — the access table, by role rather than by name
• How long we keep it — the retention line per category
• Who is accountable — a committee role, plus the current holder's name
• What members can ask for — to see it, correct it, be deleted, unsubscribe, and exactly how to ask
• What we do if it goes wrong — who gets called, in what order, on the day
• Last reviewed — a date and a name

That register plus a public privacy statement is the whole story for a normal society. Our club privacy policy template gives you the public half; the register is the private half you keep for yourselves. The full handover checklist covers the other twelve things that move on the same afternoon, and the complete society guide puts all of it in the context of the year.

Frequently asked questions

Can our society just keep the member list in a spreadsheet?

You can, and thousands do, but understand what you are accepting. A spreadsheet has no per-person access, so anyone who can open it can see everything and download a copy. It leaves no record of who exported what. And it belongs to whichever account created it, so it leaves with its owner — the single most common way societies lose their entire membership history. If you stay on a spreadsheet, at minimum keep it in an account owned by the society rather than a person, and review who has access every semester.

A member has asked us to delete everything we hold about them. Do we have to?

In most cases yes, and treat it as a fair request rather than a fight. Delete the contact details, the consent flags and anything free-text, then confirm in writing what you have done. You can usually keep the parts you are obliged to keep for other reasons — payment records your association's finance rules require, and the fact that a membership existed in the counts you report. The right shape is: contact details gone, financial records retained as required, and the person off every mailing list within a day.

Who is legally responsible for our member list — us or the student association?

It depends on how your society collects and stores data, and it matters because it decides who answers a complaint and who carries the reporting duty. The general pattern is that the more you use your association's systems, the more the responsibility sits with the association; the more you run your own website, forms and mailing list, the more it sits with your committee. Either way your committee is accountable in practice, because you are the ones with the passwords. Ask your association directly and write the answer into your data register.

In practice the students' union is usually the controller and your committee processes on its behalf — ask the union's data protection officer to confirm in writing which of your tools they consider covered.

Can we keep emailing members after they graduate?

Only if they told you they wanted that, and only at an address that still works. Campus email addresses are deactivated after graduation, which is why alumni lists evaporate — so the moment to ask is at sign-up and again when a membership lapses. Send one clear message before the address dies: "we'd love to keep you on the alumni list, here's the link to give us a personal address". Treat non-responders as a no and delete them at the end of your retention period, rather than keeping dead addresses that quietly wreck your delivery rates.

Do we need a privacy statement on our society website?

Yes, and it should take an afternoon rather than a term. A society's version is short: what you collect, why, who can see it, how long you keep it, who to contact, and how to ask for a copy or a deletion. Publish it on your own site and link it from the sign-up form so people see it as they hand over their details. Our privacy policy template is written for volunteer committees, and your association may have model wording it prefers you use instead.

Where ClubHelix fits

Nearly everything in this guide gets easier when the member record lives in one system the society owns rather than in a file somebody owns. ClubHelix keeps the register, the paid-until dates, the consent flags, the event RSVPs and the mailing list in one place, with per-person committee accounts and permissions that follow the role — so a handover is a five-minute permissions change, not an archaeological dig through personal drives. Every role grant, export and setting change lands in an audit trail nobody can edit, and backups are taken and verified for you, so no committee member needs a personal copy "just in case".

If your society is still working from a spreadsheet and a shared login, the university clubs and societies page shows what the alternative looks like, and the pricing page includes a free tier for building the site and trying it out, with taking payments online and being found in search on the paid plans.

---

ClubHelix gives your committee per-person roles and permissions, an audit log that records who did what, and daily verified backups — so the member list belongs to the society, not to whoever set it up. Start free before your next handover.