In Short: What Does POPIA Require of an Analytics Platform?
Broadly what GDPR does, with four differences that change implementation: POPIA covers juristic persons as well as individuals, uses responsible party and operator rather than controller and processor, requires written operator contracts, and is enforced by the Information Regulator with a specific compromise-notification duty. A GDPR-ready architecture gets you most of the way; these differences need deliberate handling.
It Applies to Analytics
The Protection of Personal Information Act governs the processing of personal information, and holding customer or employee data in a lakehouse for reporting is processing. The eight conditions for lawful processing apply to your analytics estate exactly as they do to the operational systems feeding it.
The Information Regulator is the supervisory authority and the authoritative source. What follows is how the obligations land in architecture.
The Difference That Catches People Out
POPIA covers juristic persons. Personal information under POPIA includes information about companies and other legal entities, not only natural persons.
This surprises teams who have built a mental model from GDPR, where B2B data about a company is generally outside scope. Under POPIA, a dataset of supplier or corporate customer records can fall within the Act.
The practical consequence: do not assume your B2B analytics estate is out of scope. Classify it and assess it the same way you would consumer data.
Responsible Party and Operator
POPIA's terminology maps roughly onto GDPR's controller and processor, and the mapping is close enough to be useful and different enough to be worth stating.
The responsible party determines the purpose and means of processing. That is you.
An operator processes personal information on behalf of the responsible party. That is your cloud provider, and it is your consultancy.
POPIA requires a written contract with operators obliging them to maintain confidentiality and establish appropriate security measures. Two things worth checking before it becomes urgent: that such an agreement exists with every consultancy and vendor touching your data, and that you know which of your suppliers are operators in the first place. This is a question that arrives badly during an incident.
Security: Reasonable and Demonstrable
POPIA requires appropriate, reasonable technical and organisational measures, judged against generally accepted information security practice. It does not prescribe products.
In an analytics context, "reasonable" translates fairly consistently to:
- Access control at the data layer - row-level security and role-based access through Entra, rather than permissions granted ad hoc per report.
- Classification so you know which datasets hold personal information, through Purview.
- Encryption in transit and at rest, which the platform provides but which should be confirmed rather than assumed.
- Audit logging, so access is evidenced.
- A documented process, because "reasonable measures" includes being able to show you thought about it.
The standard is demonstrability. Measures you have taken but cannot evidence are difficult to rely on.
Compromise Notification
POPIA requires notification to the Information Regulator and, where applicable, affected data subjects when there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person.
That duty has an architectural consequence people miss: you need to be able to establish quickly what data was affected and whose it was.
Without classification and lineage, answering that after an incident is a lengthy investigation conducted under time pressure and scrutiny. With them, it is a query. Build the capability before you need it, because the moment you need it is the worst possible moment to start.
Retention and Deletion
POPIA requires that records not be retained longer than necessary for the purpose, subject to statutory retention requirements that may pull the other way.
As with GDPR, the failure mode is a policy the platform does not implement. Retention needs to be lifecycle rules that delete, applied per category, with deletion evidenced.
And as with GDPR, deleting from an append-only lakehouse needs designing. How you partition determines how expensive erasure is - a decision worth making during design rather than under a request.
If You Already Comply With GDPR
Most of the work carries over, which is the good news for organisations operating in both jurisdictions - a common position for South African firms serving UK and EU clients.
What still needs specific attention:
Re-scope for juristic persons. Your GDPR classification may have excluded B2B data that POPIA covers.
Check operator agreements. GDPR processor agreements are a good starting point but should be reviewed against POPIA's specific requirements.
Confirm the notification path. The Information Regulator is a different authority with its own process.
Prior authorisation. Certain categories of processing require prior authorisation from the Regulator - worth confirming with your legal advisers whether anything you do falls into that group.
Where Solv Systems Comes In
Our engineering and delivery centre is in Gqeberha and we work across South African, UK and EU obligations, so POPIA is familiar ground rather than something we research per project.
We build platforms with classification, access control at the data layer, enforced retention and lineage designed in, so the compliance questions have factual answers. We are not attorneys and we do not give legal advice - your legal and compliance functions own interpretation. What we own is making the platform genuinely capable of doing what your policy says, and being able to prove it.
Sources and Further Reading
Frequently asked
Yes. POPIA governs the processing of personal information, and holding customer or employee data in a lakehouse for reporting is processing. The eight conditions for lawful processing apply to your analytics estate as they do to operational systems.
The frameworks are broadly aligned and much of a GDPR-ready architecture satisfies POPIA. The differences that matter operationally are the terminology - responsible party and operator rather than controller and processor - the treatment of juristic persons, which POPIA covers and GDPR does not, and the specific obligations around prior authorisation for certain processing.
The responsible party determines why and how personal information is processed; the operator processes it on their behalf. If you use a consultancy or cloud provider, they are typically an operator, and POPIA requires a written contract obliging them to maintain confidentiality and security. Check those agreements exist before an incident makes it urgent.
Yes, and this catches organisations out. POPIA's definition of personal information includes juristic persons, so data about companies - not just people - can fall within scope. A B2B dataset is not automatically outside the Act the way it often is under GDPR.
POPIA requires appropriate, reasonable technical and organisational measures, judged against generally accepted practice. In an analytics context that means access control at the data layer, encryption, classification of personal information, audit logging and a demonstrable process - not a specific product.
The Information Regulator, which has the power to issue enforcement notices and administrative fines. Practically, the more common trigger is a security compromise, which carries a notification obligation - so the ability to establish what data was affected quickly is worth building before you need it.
