How to keep student society member records safely

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 the Privacy Act and its Australian Privacy Principles, alongside your state or territory's information privacy legislation, which typically reaches student organisations through the university. Whether the Act binds your small society directly is a genuinely fiddly question — turnover thresholds and exemptions apply — but it is the wrong question to spend a committee meeting on, because your guild's own privacy policy binds you regardless and asks for much the same things. Practically: publish a short collection statement at sign-up, let members access and correct their record, keep it secure, and delete what you no longer use. Notifiable breaches go to the Office of the Australian Information Commissioner where the Act applies, and to your guild's privacy contact in every case. Name one committee member as the accountable person and put it in their role description. This is general information rather than legal advice — the guild's clubs and societies office can tell you which policies bind your society specifically.

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 is governed by the Spam Act, which asks for three things: consent, accurate sender identification, and a functional unsubscribe that you honour within five working days. Consent can be express (they ticked a box) or inferred from an existing relationship — a paid-up member of your society is a reasonable inference for society news; four hundred people who wrote an email address on a clipboard at Market Day are much weaker ground, so ask them explicitly in your first message. The unsubscribe link must work without requiring a login or a fee, and it must keep working for at least thirty days after the message is sent, which rules out sending from a personal address with "reply to opt out" at the bottom. The regulator does act on complaints, and a complaint from one annoyed member reaches your guild long before it reaches anyone else. 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.

If your society falls under the Privacy Act, the notifiable data breaches scheme applies: where a breach is likely to result in serious harm you must assess promptly — thirty days is the outer limit for an assessment, not a target — and then notify both the Office of the Australian Information Commissioner and the affected individuals. Whether or not the scheme reaches your society, your guild's own policy will almost certainly require you to report an incident to its clubs and societies office immediately, and the university's policy sits behind that. So the practical sequence is: contain it, tell your guild contact the same day, write the timeline, then follow their instruction on external notification rather than deciding alone. Where the breach involves payment information, tell the payment provider too. Notifying members early and honestly costs you far less goodwill than being found out three weeks later. 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 guild's privacy policy binds you through your affiliation agreement whether or not the Privacy Act reaches your society directly, so the guild's clubs and societies office is the right place to ask.

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.