Rewards platforms accumulate a surprising amount of information about people. Not because anyone set out to collect it, but because every recognition, every redemption and every login is a record, and records accumulate.
The Privacy Act 1988 and the Australian Privacy Principles set the framework. What follows is not legal advice — it is the practical version of the conversation we have with clients before launch.
Start With What Is Genuinely Needed
Data minimisation is not just good practice, it makes everything downstream easier. A shorter list is cheaper to secure, cheaper to audit and less painful if something goes wrong.
| Field | Needed? | Why |
|---|---|---|
| Name | Yes | Recognition is addressed to a person |
| Mobile number or email | Yes | Invitation and sign-in |
| Employment start date | Yes, if milestones are on | Anniversary calculation |
| Site or team | Yes | Budget allocation and reporting |
| Delivery address | Only on physical redemption | Entered by the staff member, not supplied by the employer |
| Date of birth | No | Not needed for anything in the program |
| Home address | No | See delivery address |
| Payroll number | Only if integrated | Matching records, nothing else |
| Salary | No | There is no reason for a rewards platform to hold this |
If a vendor's onboarding template asks for date of birth or salary band, ask what it is used for. "Segmentation" is not an answer that survives follow-up questions.
The Visibility Line
This is the question that matters most to staff, and the one they will ask if the program is any good: can my employer see what I bought?
The answer should be no. There is a clean line here and it is worth stating publicly.
| Employer sees | Employer does not see |
|---|---|
| Points issued to each person | Which reward a person chose |
| Aggregate redemption by category | Individual redemption history |
| Activation and usage per site | Login times or device details |
| Recognition sent and received | Delivery addresses |
Points issued is the employer's business, because the employer paid for them. What somebody spent them on is not.
Recognition Is Not Private, And That Is The Point
Worth being explicit with staff at launch: recognition messages are visible to the team. That is the mechanism, not an oversight. But it means the recognition feed is a form of published content about identifiable people, and it should be moderatable.
Two practical controls: an administrator can remove a recognition, and a staff member can ask for one about them to be removed. Neither gets used often. Both matter when they do.
Leavers
The most common privacy gap we see is not a breach — it is accounts that were never deactivated. Someone leaves, payroll knows, the rewards platform does not, and the account stays live for a year.
Either integrate the leavers feed or set a monthly reconciliation. A quarterly one is not enough, and an annual one is a finding waiting to happen.
Retention
Decide up front how long transaction records are kept after someone leaves. There is a tension: tax and financial record-keeping obligations pull one way, privacy principles pull the other.
- Set a retention period in writing, informed by your record-keeping obligations.
- Make sure the platform can actually enforce it, rather than keeping everything forever by default.
- Know what "deleted" means to your vendor — removed, or flagged and hidden.
Five Things To Settle Before The First Invitation
- The field list, cut to what is genuinely needed.
- Whether the employer can see individual redemptions. It should not.
- Where the data is hosted and who has administrative access.
- The leavers process and how often it runs.
- The retention period and who is accountable for enforcing it.
All five are ten-minute decisions before launch and multi-week projects afterwards. Our own positions on each are set out in the program terms, clause nine.
Need this for a privacy impact assessment?
We will send the field list, hosting details and retention settings in one document.