At some point almost every growing business holds more personal information than it actively needs for day to day operations. Payroll spreadsheets, onboarding forms, performance reviews, a customer relationship database, workplace incident notes and security recordings all accumulate, and eventually you will want to use or share some of that material, whether for market analysis, internal reporting, product development, due diligence or handing a working subset to an external contractor. The problem is that the moment you use or disclose that personal information, the Privacy Act 1988 (Cth) and its Australian Privacy Principles (APPs) impose limits on what you can do with it, and those limits are the reason anonymisation, or de-identification, exists.
De-identification is the process of removing enough identifying detail from a data set that an individual can no longer be worked out from it. When done properly, the result stops being personal information at all under the Privacy Act, which means the APPs that restrict how you use, store and share personal information no longer apply to it. What you end up with is a dataset you can use, analyse or release more freely. One assumption people routinely carry into this process needs to be corrected up front: deleting names is not the same as de-identifying. A row that still contains a date of birth, a gender and a role within a small team can be enough to single out a specific person, which is why the real test is not what you removed but whether anyone could still re-identify someone from what remains.
Before you start: what you need in place
De-identification is not something you should improvise. A handful of things should be settled before you touch the data, and several of them tend to trip businesses up because people assume they are automatic:
- Confirmation your entity is covered by the Privacy Act: The APPs bind APP entities, which broadly means organisations with annual turnover above $3 million (with some exceptions), plus everyone dealing in certain information regardless of size. If your business falls under the small business exemption, the APPs may not apply to most of your data at all, which changes whether you need to de-identify in the first place.
- A clear purpose for the de-identification: Whether you are sharing data, publishing statistics or simply clearing old records, the purpose drives which technique works and how aggressive you need to be. De-identification for your own internal use is less demanding than releasing a dataset publicly.
- An inventory of the data sets involved: You cannot de-identify what you have not found. Before starting, map which systems and files hold personal information, where each sits and who can access it.
- An understanding of whether the data is even in scope: Much routine employee data is caught by the employee records exemption in s 7B(3) of the Privacy Act 1988 (Cth), which exempts an employer's acts that are directly related to a current or former employment relationship and an employee record. That is an important nuance for a workplace-focused project, because it can mean the APPs never applied to some of the data you are about to treat as if they did.
- A chosen release environment: Decisions about who will receive the de-identified data, and how openly, are part of the risk assessment itself, so you should decide this before you pick a technique.
- A person accountable for the process: Someone, ideally your privacy officer or data lead, should own the audit, sign off the risk assessment and keep a record of what was done.
The steps to anonymise the data
Once the groundwork is done, the process itself runs through three steps. There is no external agency or lodgement involved, but the order matters because each step builds on the one before it and all three feed into the single question that decides whether you have succeeded: has the risk of re-identification been made very low?
Locate every identifier in the data set
Before you can remove or alter anything, you need to know what is in front of you. Audit each data set you want to de-identify and list every field, then sort those fields into two groups:
- Direct identifiers: These point straight at a person and are usually obvious. They include a person's name, date of birth, home address, phone number, email address, tax file number, payroll identifier and sometimes a photograph or voice recording.
- Indirect or quasi-identifiers: These do not name anyone on their own, but become dangerous when combined. A date of birth, a gender, a job title, a team, a postcode and a hobby can sit innocently in a row, yet the combination of them can single out one unique person, especially in a small workplace. The classic mistake is to strip the name column and consider the job done, only to leave a set of indirect identifiers that between them re-identify the staff members. Your goal in this step is to produce a complete map of what could be used, directly or by combination, to work out who is in the data.
Choose your de-identification technique
The technique you choose depends on your purpose and your technical capacity. The three common approaches used in practice are suppression, generalisation and aggregation, and you will often combine them:
- Suppression: Deleting the identifying fields entirely. Stripping the name column from a payroll table removes the most obvious identifier, but if the remaining date of birth, gender and role are enough to identify people, suppression on its own has failed and you may need to also suppress or alter those remaining fields.
- Generalisation: Replacing precise values with broader ones rather than deleting them. Instead of a date of birth you keep only the year of birth, or you convert an exact salary figure into a band such as forty to fifty thousand dollars. The data stays useful for analysis, but it is harder to pair with other information to single someone out, which reduces the re-identification risk while retaining more value than deletion.
- Aggregation: Converting the individual records into summary statistics, so you report that twelve employees in the sales team are female rather than listing each person. This carries the lowest risk of re-identification because the individual-level records no longer exist in the output, but if you keep the underlying raw data you used to build the aggregate, the risk returns, so the source file generally needs to be destroyed or kept securely separate.
Alongside these, the OAIC guidance on de-identification emphasises a second lever: the environment you release the data into. A controlled access environment with restrictions, such as a secure research portal or an agreement that limits how a recipient may use and match the data, can be an alternative to, or a supplement for, heavy alteration of the data itself. Removing direct identifiers is only the first of two required steps; the second is either removing or altering the other information that could be used to re-identify someone, or putting controls in place in the data access environment to stop it happening.
Implement the technique and test the re-identification risk
With a technique chosen, you apply it to the data set. If you have an IT function, it may carry this out; otherwise you may bring in external technical support. But applying the technique is not where the process ends, because de-identification is judged by its outcome.
The legal test, as the OAIC sets out, is that information is de-identified only where the risk of an individual being re-identified in the relevant release context is very low, meaning there is no reasonable likelihood of re-identification. That assessment is contextual. It does not look at the data in isolation: it looks at who will receive it, what other information that recipient can combine it with, and how openly it will be released. Data that is de-identified when shared with a trusted contractor under a written restriction may not be de-identified if you publish it on a public website, because the audience and the data that audience can draw on are entirely different.
Your privacy officer or data lead should therefore review the output, run a re-identification risk assessment in the context of the intended recipients, and confirm the risk is very low before the data is released. If the risk is not low enough, you go back and modify further, whether by suppressing more fields, generalising more aggressively, aggregating further or tightening the access environment, and you repeat the review until the test is met. This is also the point at which de-identification overlaps with your retention obligations, because under APP 11.2 of the Privacy Act 1988 (Cth) an APP entity that no longer needs personal information for any permitted purpose must take reasonable steps to destroy or de-identify it. Failing the risk test means the information is still personal information, and every APP obligation that attaches to it, including the security duties in APP 11 and the use and disclosure limits in APP 6, continues to apply.
Where people commonly get held up
A few mistakes recur when teams run this step:
- Stopping at the name removal: Removing direct identifiers alone frequently leaves indirect identifiers that still identify people. The tell-tale sign is a dataset where a small combination of fields isolates a single employee.
- Treating the risk test as fixed: A dataset is not de-identified in the abstract. It is de-identified only in a particular release context, so the same file can be safe for one recipient and unsafe for another.
- Ignoring the source data: Aggregation and generalisation are undermined if the original identifiable records are left sitting somewhere recoverable, because the information has not genuinely left the Privacy Act's reach.
- Forgetting the employee records nuance: Where the exemption applies, the question is not simply whether you can use the data, but whether the APPs ever attached to it, which changes the whole framing of the task.
When you should involve a lawyer
The technical act of removing and altering data is usually an IT task, but the judgement calls around it are legal, and that is where a practitioner earns their keep. A lawyer can first confirm which law actually regulates the data you hold, because the answer is not always the Privacy Act. The employee records exemption in s 7B(3) can take routine employee records outside the APPs, while other information is governed by specific regimes that impose their own de-identification duties, such as tax file number information, credit reporting information and health information, and in some states health records carry their own obligations.
Beyond scoping, a lawyer assists with the parts of the project that carry ongoing risk after the data has left your hands. They can draft or review the agreements that govern how a third-party recipient may use and match the de-identified data, which directly supports the access-environment controls the OAIC identifies as part of proper de-identification. They can document your risk assessment and the steps you took, which matters if the Office of the Australian Information Commissioner ever questions whether information was genuinely de-identified. And when de-identification is happening as part of a larger transaction, such as selling a business or transferring a customer book, they sequence the work so the data and the surrounding legal documents move together.
The step that decides whether your anonymisation works
The part of this process that most often determines success is not the technique you pick but the re-identification risk assessment you run at the end, because it is the gate that decides whether the data has genuinely left the Privacy Act. A technically competent deletion that was never checked against what the recipient could combine with it can hand back the exact exposure you were trying to remove, and a dataset that still identifies people, no matter how carefully it was scrubbed, is still personal information with all the obligations that entails.
To summarise: start by confirming which laws apply to your data and which data sets are in scope, build a complete map of direct and indirect identifiers, choose a technique of suppression, generalisation or aggregation guided by your purpose and release environment, and close by testing the re-identification risk in context until it is very low. Done well, de-identification turns a liability into a usable asset. Done carelessly, it leaves you exposed to the same privacy obligations you were hoping to shed.