POPIA compliance for South African organisations: a technical primer

POPIA — the Protection of Personal Information Act — has been in force since 1 July 2021. Every organisation in South Africa that processes personal information is subject to it. Despite that, we still see boardrooms treating POPIA as a legal exercise that ends when the privacy policy is published. It does not.

POPIA is a technology problem as much as a legal one. The Act sets out eight conditions for lawful processing, and at least five of them translate directly into controls you build or operate inside your platform. This piece walks through what POPIA actually requires from your technology stack, where the most common gaps are, and what we look for when assessing readiness.

What POPIA covers, in one paragraph

POPIA regulates how organisations collect, use, store, share, and destroy personal information about identifiable people — customers, employees, suppliers, prospects, and partners. It applies to data held in any form: databases, spreadsheets, email, paper, recordings, photographs, and CCTV. Compliance is enforced by the Information Regulator. Penalties for serious breaches can reach R10 million or 10 years’ imprisonment, and the reputational damage from a publicised incident often exceeds the regulatory fine.

The eight conditions and what they mean for technology

POPIA defines eight conditions for lawful processing. Most of them are operational rather than purely legal:

1. Accountability. Someone in your organisation must be responsible for compliance — the Information Officer.
2. Processing limitation. You can only collect personal information you actually need for a defined purpose.
3. Purpose specification. The purpose must be explicit and lawful, and the data subject must know about it.
4. Further processing limitation. Using the data later for something else needs to be compatible with the original purpose.
5. Information quality. Data must be accurate, current, and complete.
6. Openness. Data subjects must be informed about what you hold and what you do with it.
7. Security safeguards. You must take “appropriate, reasonable, technical and organisational measures” to protect the data.
8. Data subject participation. People have the right to know what you hold, correct it, and request deletion.

Conditions 1, 2, 5, 7, and 8 are where most of the technology work sits. The other three are policy and process — important, but not where audits typically find issues.

Where most organisations fail an audit

In our assessment work across financial services, healthcare, and mid-market organisations, the same gaps come up. Not because the law is unclear, but because the technology controls were built for other purposes — security, productivity, cost — and never explicitly mapped to POPIA conditions.

Inventory of personal information

You cannot protect data you cannot find. The first question we ask in any POPIA assessment is: where is personal information held in your environment? The answer almost always starts confidently and gets less confident as we go. Customer database, yes. CRM, yes. Marketing platform, sure. Then: shared mailboxes that store contact details. SharePoint sites where someone uploaded a CSV “just for now”. Old laptops that still have client files. Backup tapes from 2017. Logging systems that capture form submissions in plain text. Vendor SaaS tools that nobody currently maps to a data flow diagram.

We help organisations build a personal-information inventory that lists each location, its purpose, the data subjects involved, the retention period, and the security controls in place. Without this, conditions 2 (processing limitation) and 7 (security safeguards) cannot be evidenced.

Identity and access controls

POPIA does not name MFA, RBAC, or Conditional Access. It says “appropriate, reasonable, technical and organisational measures”. In practice, every Information Regulator finding on a major breach has flagged weak access control as a contributing factor.

The controls we look for:

• Multi-factor authentication on every account that can read or write personal information — administrators, finance, HR, customer service, integration accounts.
• Role-based access control on databases, file shares, and SaaS platforms. The principle of least privilege applied, reviewed quarterly.
• Privileged access managed separately from day-to-day accounts. No permanent admin rights on user laptops or in the cloud console.
• Lifecycle automation: when someone leaves, access is revoked the same day. When someone changes role, old permissions are removed, not just stacked on.
• Audit logs of who accessed what, retained for at least 12 months, monitored for unusual patterns.

Data protection at rest and in transit

Encryption of personal information at rest and in transit is the practical baseline. Most cloud platforms provide this by default — Azure Storage, AWS S3, SharePoint Online, Microsoft 365 — but the default settings are not always enforced, and sensitive data sometimes ends up in places where encryption is not on by default. Old file servers, third-party applications, exported reports, and backup destinations are the usual offenders.

Transport encryption is broadly handled by TLS, but legacy systems sometimes still negotiate old protocol versions. We check for TLS 1.2 minimum, with TLS 1.3 preferred where supported.

Data loss prevention and SaaS governance

Personal information leaks more often through SaaS sharing settings than through external attack. A user shares a document “with anyone who has the link”, and six months later it is indexed by a search engine. We look for:

• DLP rules on Microsoft 365 or Google Workspace that block sharing of South African ID numbers, banking details, or medical information outside the organisation.
• Conditional Access policies that block download to unmanaged devices for sensitive sites.
• Periodic reviews of SaaS-tenant external sharing reports.
• Approval workflows for new SaaS tools before personal information is uploaded.

Breach detection and response

POPIA Section 22 requires that you notify the Information Regulator and the affected data subjects “as soon as reasonably possible” after a breach. To do that, you need to know a breach has happened. To know that, you need monitoring.

The minimum we recommend:

• Centralised logging of identity events (sign-in, MFA failures, privileged access use), file access events, and email forwarding rule changes.
• Alerts on unusual patterns: bulk downloads, mailbox forwarding to external addresses, sign-ins from unfamiliar geographies, mass permission changes.
• A documented incident response runbook that includes the POPIA notification path and the contact details for the Information Officer.
• A tested process for assessing the scope of an incident — what data was exposed, whose, and over what time window.

This is where most organisations are weakest. Logging exists, but nobody is watching the logs in real time, and the runbook either does not exist or has not been tested.

Subject access and deletion rights

Condition 8 gives data subjects the right to ask what you hold and request correction or deletion. To answer those requests practically, you need to be able to find the person’s data across every system that holds it. Without an inventory, this becomes a multi-week investigation every time. With an inventory and reasonable tooling, it becomes a workflow.

We help organisations document a Subject Access Request runbook with target response times, named owners per system, and a templated response that meets the legal minimum without exposing other people’s data.

What POPIA does not require

A few things that consultants sometimes claim POPIA mandates, but it does not:

• It does not require that personal information be hosted in South Africa. Cross-border transfer is allowed if the receiving country has comparable laws or contractual safeguards. For most cloud providers, this is handled by the standard data processing addendum.
• It does not require ISO 27001 certification. ISO 27001 is helpful evidence, but it is not the only way to demonstrate appropriate, reasonable measures.
• It does not require encryption of every field in every database. It requires appropriate measures based on risk. A list of newsletter subscribers is lower-risk than a database of medical records.

The Act is principle-based, not prescriptive. That cuts both ways: there is flexibility in how you comply, but you must be able to defend your choices.

A practical readiness assessment

When we run a POPIA technical readiness assessment, we look at six dimensions:

Each dimension is rated and supported by evidence — screenshots, exports, runbooks, tickets. The output is a prioritised improvement backlog, not a pass/fail certificate. POPIA compliance is operational, not a one-time project.

Where to start

If your organisation has not yet done a POPIA technical readiness assessment, the order we suggest is:

1. Designate the Information Officer formally and document the role.
2. Build the personal-information inventory across the top ten systems.
3. Audit identity and access controls against the principle of least privilege.
4. Confirm encryption and DLP defaults are turned on across cloud and SaaS.
5. Document the breach response runbook and test it once a year.
6. Map the subject access request process and confirm at least one person can run it end-to-end.

Each of these can be delivered as a focused engagement on its own, or as part of a broader cybersecurity and compliance assessment. We work vendor-neutral across Microsoft, Google, AWS, and the supporting tooling — Sentinel, Defender, Purview, Sharepoint sensitivity labels, Conditional Access, Intune, and the equivalents on AWS and Google Workspace.

Where this looks like in practice

POPIA readiness is not the same as POPIA certification — there is no such thing. It is the ability to defend your choices, evidence your controls, and respond to incidents and subject requests within reasonable time. The organisations we have helped pass external audits and respond to Regulator queries are the ones that treated it as ongoing operating discipline, not a one-off project.

If you would like to discuss your current state, start with a focused conversation. The first hour usually surfaces the biggest gaps without needing access to anything sensitive.