POPIA Compliance: 12 Critical IT Controls You Must Prove

POPIA compliance has been enforceable since 1 July 2021, and most of the conversation about it still happens between lawyers and the board. That is reasonable — much of the Act is a legal question. But a meaningful part of it lands squarely on whoever runs your systems, and that part is rarely written down in plain terms.

This is an IT operations checklist for POPIA compliance, not legal advice. The Protection of Personal Information Act 4 of 2013 has obligations well beyond technology — lawful basis, consent, data subject rights, direct marketing rules, cross-border transfers. Get those from a qualified advisor. What follows is the technical half: the controls a reasonable systems person should be able to demonstrate.

Where IT actually sits in POPIA compliance

The Act sets out eight conditions for the lawful processing of personal information. Most concern why and whether you may process data. One — security safeguards — is largely about how, and that one is yours.

Section 19 requires that a responsible party secure the integrity and confidentiality of personal information by taking reasonable technical and organisational measures to prevent loss, damage, unauthorised destruction and unlawful access. Section 21 extends the same obligation to operators — the third parties processing on your behalf. Section 22 requires notification to the Information Regulator, and to affected data subjects, where there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person.

Read those together and three practical duties fall out: know where the data is, control who can reach it, and be able to tell when something went wrong. Almost everything below serves one of those three.

The POPIA compliance checklist

Know where personal information lives

• A written inventory of systems holding personal information — including the ones nobody counts: shared mailboxes, that Excel export on a file share, the CRM trial from 2022 that still holds records, backups, and staff devices.
• For each: what categories of data, roughly how many records, who owns it, and where it physically or logically resides.
• Special personal information identified separately. Health, biometrics, religious or political affiliation, and children's information carry heavier obligations, and you cannot apply them if you do not know where such data is.
• A retention position for each store. "We keep everything forever" is a decision, and usually the wrong one — data you no longer hold cannot be breached.

Control who can reach it

• Multi-factor authentication on email, remote access and any administrative console. If you do one thing on this list, do this one. Credential theft remains the most common route in, and MFA defeats the overwhelming majority of it.
• Access granted by role, reviewed on a schedule, and — critically — removed on the day someone leaves. Orphaned accounts of departed staff are a recurring finding.
• Administrative rights separated from daily-use accounts. An administrator browsing the web with domain privileges is one bad click from a very bad day.
• Third-party and operator access enumerated. Every vendor with a login is a route to your data, and section 21 makes their security your problem.
• Encryption in transit as a baseline, and at rest for laptops and portable media. A stolen unencrypted laptop is a reportable event; an encrypted one usually is not.

Be able to tell when something went wrong

• Logging that is actually retained. Sign-in logs, mailbox audit logs, file access on sensitive shares. Default retention is often days — long enough to miss the incident entirely.
• Alerting on the things that matter: impossible-travel sign-ins, mass file downloads, new mail-forwarding rules, privilege escalation.
• A written incident procedure that names people, not roles in the abstract. Who decides it is an incident. Who contacts the Information Regulator. Who talks to affected people. What gets preserved before anyone starts "fixing".
• Backups that are tested, and at least one copy that ransomware cannot reach from a compromised admin account. An untested backup is a hypothesis.

The organisational half you cannot delegate to a tool

• An Information Officer registered with the Information Regulator. By default this is the head of the organisation, and the duty exists whether or not anyone has thought about it.
• Operator agreements in writing with anyone processing personal information for you — your IT provider included. Section 20 and 21 require the relationship be governed by a written contract.
• Staff who have been told, in language that makes sense, what they may and may not do with customer data. The most common cause of a reportable incident is not a sophisticated attack; it is an email to the wrong recipient.

The POPIA compliance findings that come up again and again

Across assessments, the same handful of gaps recur — and none of them are exotic:

1. MFA on most accounts, but not all. The exceptions are usually service accounts and senior people who found it inconvenient. Both are exactly the accounts an attacker wants.
2. Leavers who still have access. Offboarding gets done in the HR system and not in the identity system.
3. Nobody knows where the data is. Not through negligence — through fifteen years of accumulation and no inventory.
4. Log retention shorter than detection time. Incidents are frequently discovered weeks after the fact, by which point the evidence has rolled off.
5. Backups never restored. Monitored, green, and never once tested end to end. Availability is a POPIA compliance duty as much as confidentiality is, and an untested restore proves neither — we set out what a real drill involves in 7 failures backup testing exposes.

Why this is worth doing beyond compliance

The penalties are real — the Act provides for administrative fines and, for certain offences, criminal sanction. But compliance is rarely what makes this worth the effort.

Every control above is something you would want regardless. Knowing where your data lives makes migrations cheaper. Role-based access makes onboarding faster. Retained logs turn "we think we were fine" into an answer. Tested backups are the difference between an incident and a catastrophe. And an organisation that can answer these questions quickly wins the client security questionnaire and the insurance renewal without a fortnight of scrambling.

The POPIA compliance deadline is the reason it gets scheduled. The operational resilience is the reason it is worth doing properly.

Turning POPIA compliance into evidence you can show

A control you cannot demonstrate is, for practical purposes, a control you do not have. Regulators, insurers and enterprise clients all ask the same question in different words: show me.

For each item above, decide now what the evidence looks like. A screenshot with a date. An exported policy. A signed operator agreement. A restore test with a result and a name against it.

Keep it somewhere that survives a laptop failure and a resignation. The single most common reason a business fails a security questionnaire is not missing controls — it is being unable to find proof of controls it genuinely has.

Who is accountable, in practice

The Information Officer duty defaults to the head of the organisation. It can be delegated to a Deputy Information Officer, but the accountability does not move, and registration with the Information Regulator is a formal step rather than an internal note.

The Information Regulator publishes the registration process and guidance notes directly, and it is worth reading the primary source rather than a summary — including a vendor's.

For IT specifically, the useful framing is that you are not accountable for POPIA compliance as a whole. You are accountable for being able to answer, accurately and quickly, what data exists, who could reach it, and what happened. Everything else is a legal and business determination.

Three questions that expose a gap immediately

"If a mailbox were compromised today, could we say what was in it?" This tests inventory and log retention simultaneously. Most businesses discover their answer is no, and that the reason is a default retention setting nobody chose.

"Who has access to the CRM, and when did we last check?" If the answer involves opening the system to look, the access review process does not exist. That is fine to discover; it is not fine to leave.

"Which third parties process personal information for us?" Almost everyone under-counts. Payroll, email security, backup, CRM, the accounting platform, the recruitment tool. Each one needs an operator agreement, and if any of them is your IT provider, that includes them — a point we make in our piece on co-managed IT. A provider working remotely from another country raises the same POPIA compliance question plus a cross-border one, which we cover in remote IT consulting across timezones.

How POPIA compliance intersects with the security work you are already doing

The controls in this checklist are not a separate workstream. They are close to identical to the controls that actually reduce breach risk.

That overlap is convenient and worth exploiting when arguing for budget. Multi-factor authentication, access reviews, log retention and tested backups all appear in POPIA compliance conversations, cyber-insurance applications and client security questionnaires alike.

It also means the threat picture should shape your priorities. Identity-led intrusion now outranks software exploitation as the leading cause of ransomware, which makes access control and identity logging the highest-value items on this list — the evidence is in our analysis of why identity attacks beat exploits.

If you are choosing where to start and the list feels long, start there. Know where the data is, then control who can reach it.

A realistic sequence for a small business

Doing all of this at once is not realistic for a business without dedicated security staff. A sensible order:

• Month one. MFA everywhere with no exemptions, and a written list of any exemption that genuinely cannot be removed yet.
• Month two. The data inventory. Tedious, and the thing every later decision depends on.
• Month three. Access review and leaver process, with the identity system as the source of truth rather than the HR system.
• Month four. Log retention extended past your realistic detection time, plus alerting on the handful of events that matter.
• Month five. Operator agreements with every third party that processes personal information.
• Month six. A tested restore, documented, with a name and a date against it.

Six months of modest, scheduled work puts a small business in a materially stronger position than most of its peers — and produces the evidence file that makes the next questionnaire straightforward.

The technical controls in that sequence are the same ones an insurer or a client questionnaire asks about, which is why we run them as one piece of work — see cybersecurity risk management for how the assessment is scoped.

POPIA compliance is also not the only regime with a notification clock attached to it. If your organisation ships software or connected devices into the European Union, the Cyber Resilience Act adds a 24-hour reporting duty of its own from 11 September 2026 — a different regulator, the same discipline of knowing who decides and who reports.