Every January, South African newspapers publish matric results. For years the names were printed in full. Since 2022, after POPIA came fully into force, the results have appeared as examination numbers with outcomes and no names. In late 2024 the Information Regulator took the view that this still contravened POPIA, issued an enforcement notice and then an infringement notice carrying a R5 million fine. Many people still remember that headline.
It is not the current position. In December 2025 a full bench of the Gauteng High Court set both notices aside. In June 2026 the same court refused the Regulator leave to appeal. The Regulator then asked the Supreme Court of Appeal for leave to appeal, and a later news report says leave was granted. A data-governance team that classified this matter in 2024 and never looked again would now be wrong twice: wrong about the outcome, and wrong to think the outcome was settled.
CloudNala's view is that this dispute teaches two engineering lessons that outlast its final result. First, whether data is personal information cannot be fixed as a static column label; it depends on who could identify a person, using what they already hold and how much effort it takes. Second, an organisation's register of legal obligations needs versions, because a notice, an appeal, a judgment and a further appeal are different legal states.
This series is general information about running privacy controls in production systems, not legal advice. This part discusses litigation that was still open at the time of writing. The court's reasoning is described from the published judgments; the broader architecture guidance is CloudNala's analysis, not a legal holding. Check the current position and take advice from a qualified legal practitioner before relying on any of it.
What happened, in order
The facts below come from the full-bench judgment of 12 December 2025 and the leave-to-appeal judgment of 3 June 2026, both in the Gauteng Division, Pretoria.
- 18 January 2022. After POPIA came fully into force, a court order based on a settlement between the parties allowed the 2021 results to be published with only the examination number and the result. The department published the same way in the following years. The parties later disagreed about whether that order covered anything beyond the 2021 results.
- 6 November 2024. Following an own-initiative assessment, the Regulator issued an enforcement notice. Among other steps, it required an undertaking not to publish the 2024 results in newspapers, a consent system for 2025, and either a different way of assigning examination numbers or publication that stopped learners from the same school identifying one another.
- 23 December 2024. The Regulator issued an infringement notice for non-compliance. The fine was reported as R5 million.
- 12 December 2025. The full bench condoned the department's appeal, which had been served six days after the 30-day period in section 97(1), upheld it, and set aside both the enforcement notice and the infringement notice.
- 3 June 2026. The court dismissed the Regulator's application for leave to appeal.
- July 2026. The Regulator applied directly to the Supreme Court of Appeal for leave to appeal.
- September 2026. BusinessTech reported on 18 September 2026 that the Supreme Court of Appeal had granted the Regulator leave to appeal. We could not confirm this against a court record on 3 November 2026. If leave was granted, the appeal itself is still to be heard, so on either reading the matter is open.
The argument was about identifiability
POPIA defines personal information as information relating to an identifiable, living natural person and, where applicable, an identifiable existing juristic person. The list of examples includes "any identifying number, symbol" or "other particular assignment to the person". The department accepted that an examination number is a unique identifier of a learner. The dispute was about whether publishing that number next to a result, in a newspaper, relates the result to an identifiable person.
The Regulator's case, as the judgment records it, was that examination numbers are issued sequentially per school and that learners sit in examination rooms in the same order. A learner could therefore work out the numbers of the people who sat beside them and read their results in the paper.
The court disagreed on the evidence. It held that the Regulator had not shown how the scenario worked in its original report, called the contention "fanciful" and "akin to a poorly constructed thought experiment" unsupported by empirical evidence, and concluded that the manner of publication did not amount to processing personally identifiable information. Because of that conclusion it did not decide the other issues, including consent and the other lawful grounds for processing. In refusing leave to appeal, the court said that its phrase "personally identifiable information" only described the facts in dispute and did not rewrite the Act.
Notice what the court did not say. It did not say examination numbers are never personal information. It decided whether this publication, in this form, made learners identifiable on the evidence before it. That distinction is the engineering lesson.
The same identifier in three hands
An examination number is a good teaching case because the same number is clearly personal information in one setting and arguably not in another.
To the school administrator who holds the register linking numbers to learners, the number identifies a person directly. To a newspaper reader with no link to the register, it is a meaningless string. Between those two sits the contested case: someone with partial auxiliary knowledge, such as a seating order or knowing that numbers are sequential, who might narrow a number down to a person. Whether that middle case counts depends on the facts, how likely it is that someone would do it, and the effort required. Reasonable people, and here a regulator and a court, can disagree about it.
That is why a data catalogue column that says pii: false for an identifier is a decision dressed up as a fact. The right question is not "is this field an identifier?" but "could someone who receives this, combined with what they plausibly hold, identify a person, and with how much effort?" Several properties change the answer:
- Direct, indirect or pseudonymous. A name is direct. A date of birth with a postcode is indirect. A random token is pseudonymous: personal information to whoever holds the key, possibly not to anyone else.
- Structure. Sequential or structured identifiers leak information that random identifiers do not. An identifier that encodes a school, a branch, a date or an order of arrival gives anyone who knows the pattern a head start.
- Auxiliary data. Identifiability depends on what else is available to the recipient: class lists, social media, a leaked file, or other datasets published by the same organisation.
- Audience. Publishing to the world is different from sharing with one contracted operator, and both are different from internal use.
This matters directly for AI systems. A dataset "de-identified" for model training, an evaluation set built from replaced customer identifiers, or traces that keep a stable user token are all identifier decisions. A stable pseudonymous key held in the same environment as the lookup table is, in practice, not much of a barrier. Retention and agent memory raise the same question over time.
A contextual identifiability assessment
The practical answer is to record identifier decisions as assessments, with an owner and a review date, instead of as static labels. A useful record has these fields:
| Field | What it captures |
|---|---|
| Data element | The field or combination being released, for example examination number plus result |
| Direct visibility | Does the release show a name, image or contact detail directly? |
| Linkability | How could a recipient link it to a person: structure, sequence, other releases |
| Auxiliary data | What plausible recipients already hold or can easily obtain |
| Likely actors | Who receives it: the public, a partner, staff, a model provider |
| Effort required | What someone would actually have to do to identify a person |
| Harm | What follows if they do: embarrassment, discrimination, fraud, safety |
| Legal position | The applicable authority and any ruling, with its date and status |
| Decision and owner | Release, transform, restrict or withhold, and who decided |
| Review date and supersession | When to look again, and what new authority would reopen it |
The last two rows connect the technical assessment to the legal state. If the decision rests on a judgment that is under appeal, the record says so, and the review date follows the appeal.
Why the register needs versions
The second lesson is about how organisations track legal obligations. A team that wrote "DBE fined R5m for publishing exam numbers" into its privacy knowledge base in December 2024, and used it to justify a design decision, would have built on a position that a court has since set aside, and that may yet change again on appeal.
An obligation register for privacy, public law or regulation should therefore:
- Record the event and the legal state separately. "Infringement notice issued" is an event. "Fine imposed, under challenge" is a state. "Set aside, appeal pending" is a later state of the same matter.
- Keep every version. Do not overwrite the 2024 entry. Supersede it, so you can show what you relied on when you made a decision.
- Link decisions to the version they relied on. If a design choice cites a ruling, the register should show which state of the ruling, so a change triggers a review of the decision.
- Give each open matter a watch owner and a check date. Courts do not notify your architecture team.
- Keep architecture, data governance and legal in one record. The lawful-basis decision, the identifier assessment and the legal position belong together, not in three teams' separate files.
The same discipline applies to the Justice Department matter in Part 7, where a fine reported in 2023 was still reported as disputed in 2026.
What this series adds up to
Across eight parts, POPIA in Production has made one argument from several angles: the Act is met in running systems that produce evidence, not in documents that describe intentions. The fictional lender in Parts 1 to 6 showed how to build those controls. The two public matters in Parts 7 and 8 show what happens at the edges: a safeguard that lapses before anyone notices, an order whose clock runs out, and a classification that depends on context and on a legal position that keeps moving.
Start this week
- Find three identifiers you publish or share outside the organisation and write a contextual identifiability assessment for each, including what a well-informed recipient could do with them.
- Check whether any identifier is sequential or encodes meaning, and decide whether a random identifier would remove a risk you do not need to carry.
- Look at your privacy knowledge base for legal positions recorded as settled facts, add the date and status to each, and assign someone to watch the ones still open.
This is the last part of the series. Start again at Part 1, A privacy policy is not a privacy control, or see all parts on the series page.
How CloudNala can help
CloudNala helps data and technology teams replace static personal-information labels with contextual identifiability assessments, review identifier design in datasets, AI training and evaluation sets, and traces, and set up a versioned obligation register that links design decisions to the legal positions they rely on. We work alongside your information officer and legal advisers, who remain responsible for legal interpretation.
Work with CloudNala
CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.
Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.
Book a POPIA Controls Review or write to us at consult@cloudnala.co.za