POPIA compliance is usually bought as a document. A privacy policy is written, an Information Officer is registered, a consent banner appears on the website, and the matter is considered closed.
The part that tends not to get done is the part the Act actually asks for. Section 19 requires appropriate, reasonable technical and organisational measures to secure personal information — and “technical measures” is a statement about how your systems are built, not about what your policy says.
South Africa’s Protection of Personal Information Act has been fully enforceable since 1 July 2021, overseen by the Information Regulator, with penalties that reach R10 million for serious contraventions. Here is what that means for the software a business runs on.
Access control is the measure most often missing
The most common finding in internal systems is not weak encryption. It is that everybody can see everything.
Line-of-business applications tend to grow one role — “staff” — because that was sufficient when there were six people. By the time there are sixty, the support agent who handles delivery queries can also open the salary field, and nobody decided that; it simply was never separated.
Minimum viable work here is unglamorous: define roles against actual jobs, restrict record-level access where staff only need their own region or branch, and remove the shared login that exists “for the warehouse”. A shared account also destroys your audit trail, because every action is attributable to a username rather than a person.
Logs have to answer “who looked at this record”
Most systems log errors well and access badly. Error logs tell you when the software broke. They do not tell you whether someone read a customer’s file.
If a data subject asks what happened to their information, or the Regulator asks you to demonstrate your safeguards, the question is who accessed which record and when. That is a different log, it has to be written when the record is read rather than only when it is changed, and it has to be stored somewhere the people being logged cannot edit.
Keep it proportionate. Logging every read on every table will drown you. Log reads on the data that would actually matter in a breach.
Retention is a deletion schedule, not a paragraph
POPIA expects that personal information is not kept longer than necessary for the purpose it was collected for. Almost every retention policy we read states a period; almost none are implemented.
The gap is that deleting old records is work nobody has scheduled, and it feels risky, so it never happens. The result is a database holding fifteen years of personal information that the organisation’s own policy says should have gone.
Make it a job that runs, with a report of what it removed, and handle the awkward cases deliberately — records under legal hold, records subject to a different statutory retention period, and the backups, which are where “deleted” data usually continues to live.
Your operators are your exposure
Anyone processing personal information on your behalf is an operator, and you remain the responsible party. In software terms that is your hosting provider, your email and SMS gateways, your analytics, your CRM, your backup vendor, and increasingly whichever model API your application sends customer text to.
Two practical things. Know the list — most organisations cannot produce it, which means they cannot assess it. And know where each one puts the data, because a cross-border operator brings Section 72 into the conversation and that needs an answer before procurement, not after.
Breach notification has a clock, so build for it
The Act requires notification to the Regulator and to affected data subjects when there are reasonable grounds to believe personal information has been accessed by an unauthorised person.
The engineering consequence is that you must be able to establish scope quickly. Which records were exposed, whose they were, and what categories of information they contained. An organisation without access logs and without a current data inventory cannot answer that in a useful timeframe, and ends up either over-notifying everyone or guessing.
The time to build that capability is while nothing is wrong.
Compliant software does not make you compliant
Worth stating plainly, because vendors blur it: there is no such thing as a POPIA-certified platform that transfers the obligation to the supplier. You remain the responsible party. Good software makes the duties under Section 19 achievable — it cannot discharge them for you, and a product marketed as “POPIA compliant” is describing its features, not your position.
We build and run systems with these controls in place from the start — see custom software development and managed cloud services, or our team in Cape Town, South Africa. Related: what a managed cloud SLA should actually commit to.
Common questions
Does POPIA apply to a small business?
Generally yes. The Act applies to responsible parties processing personal information in South Africa, with limited exclusions, and it does not exempt an organisation for being small. What changes with size is what counts as appropriate and reasonable under Section 19, not whether the duty exists.
Is POPIA-compliant software enough to make us compliant?
No. Software is a tool, not a certificate. The responsible party remains responsible. The right platform makes access control, logging and retention achievable, but the obligations stay with your organisation and depend on how you configure and operate the system.
What are the penalties for getting POPIA wrong?
Enforcement runs through the Information Regulator, and serious contraventions can attract administrative fines reaching R10 million, with criminal sanction available for some offences. In practice the more common cost is an enforcement notice requiring remediation on the Regulator’s timetable rather than yours.
