POPIA Compliance for South African SMBs: The IT Operations View

Every SMB owner in South Africa has by now read at least one POPIA explainer that begins with the words "data subject" and ends with a vague suggestion to "consult a legal professional." That has its place. This is not that article. This is the IT operations view: given that POPIA applies to your business, what must your actual IT setup do, day to day, to make compliance real rather than theoretical.

The point worth making up front is that POPIA compliance is mostly a controls problem, not a paperwork problem. You can have a beautifully drafted privacy policy on your website and still be non-compliant because nobody locks the comms cupboard. You can also have a one-page policy and be substantively compliant because your IT is set up correctly. The Information Regulator, when they do investigate breaches, looks at what you actually did, not what you said you would do.

What POPIA is actually asking of you

In one sentence: when you collect, store or share personal information about anyone — staff, customers, suppliers — you have to do so lawfully, securely, and only for the reasons you said you would. The Act lists eight conditions for lawful processing. In plain operator's language:

1. Accountability — somebody in the business is responsible for compliance, and that person is named.
2. Processing limitation — you only collect what you need, with consent or another lawful basis.
3. Purpose specification — you know why you are holding each piece of personal data.
4. Further processing limitation — you do not later use that data for new things the person did not agree to.
5. Information quality — you take reasonable steps to keep data accurate.
6. Openness — the person whose data you hold knows you hold it and can find your privacy notice.
7. Security safeguards — and this is the one this article is mostly about — you have appropriate technical and organisational security in place.
8. Data subject participation — people can ask what you hold, ask for corrections, or ask for deletion, and you can respond.

Most of conditions 1, 3, 6 and 8 are largely paperwork and process. Conditions 2, 4, 5 and especially 7 are where IT lives.

The IT-side controls POPIA effectively requires

Access management

Who can see what data, and how do you know? At minimum: every user has their own named account — shared logins for systems holding personal data are a clear failure. Multi-factor authentication is on for every account that touches email or cloud storage. Access is granted on a least-privilege basis. And there is a joiner-mover-leaver process: when someone resigns, their access is removed the same day, not three weeks later. That last point is one of the most common audit failures in SMBs.

Encryption at rest and in transit

Anywhere personal data sits on disk it should be encrypted. For Microsoft 365 and Google Workspace this is the default. For laptops, BitLocker (Windows) or FileVault (Mac) should be enforced via policy, not left to chance. A stolen, unencrypted laptop containing a customer list is a notifiable breach. In transit, every web service should be HTTPS, and Wi-Fi networks WPA2 or WPA3 with a guest network strictly separated from the business network.

Backup retention and recovery

The security condition explicitly includes preserving the integrity of personal information. Practically: backups exist, are tested, and can be restored within a reasonable window; they are stored off-site (the cloud is fine; another disk in the same office is not); retention periods are documented; and the backups themselves are protected, not lying on a USB drive in the same comms cupboard as the server.

Breach notification readiness

When a breach happens, POPIA requires you to notify the Information Regulator and affected individuals as soon as reasonably possible. That is not the moment to start working out who to call. You should have, in writing, before any breach: who decides it is a breach, who notifies the Regulator, what template you use, and what your IT provider is contracted to do in the first 24 hours.

Data subject request handling

Anyone whose personal information you hold can ask what you have, ask you to correct it, or ask you to delete it where lawful. For an SMB the practical requirements are a documented intake, a defined response window (30 days is the working standard), and the ability to actually search across your systems for an individual. The last point is the one most SMBs fail at.

Third-party processor agreements

The minute you put data into Microsoft 365, Xero, Sage, your CRM or payroll provider, that vendor is a "processor" under POPIA. You must have a written agreement with each one. The work is not negotiating them — the major providers have standardised addenda. The work is keeping a register of every third party that processes personal data on your behalf, with evidence the agreement is in place.

Three POPIA-IT gaps we see most often

Gap one: the ex-employee whose 365 account still works. Three months after they left, their Outlook still receives mail and their OneDrive is still active. A data leakage risk and a clear failure of access management. Fix: a documented leaver checklist that runs same-day, every time.

Gap two: the file share with everything in it. The "Company" folder where someone, years ago, dumped the staff salary spreadsheet, scans of every client's ID, and a folder marked "old contracts." Everyone can read it; most do not know it exists. Fix: a one-day exercise to audit shared-folder permissions and move sensitive data into properly permissioned locations.

Gap three: backups that have not been tested. The software says everything is fine. Nobody has restored a file in eight months. When you finally need to, the backup was running against the wrong folder. Fix: a quarterly test restore, with a written confirmation that it worked.

A 10-item POPIA-IT readiness checklist

Block a morning and walk through these. Be honest. The objective is to find gaps, not to feel good.

1. Named accountability. Who is the information officer? Is it documented and registered with the Regulator?
2. Data inventory. Do you have a list of what personal data you hold, where it lives, and why? A spreadsheet is fine.
3. Access review. When did you last review who has access to what? "Never" is the gap.
4. MFA coverage. Is MFA enforced on email, file storage, and any system holding personal data? Not "available" — enforced.
5. Encryption. Is full-disk encryption on by default on every company laptop? Can you prove it?
6. Leaver process. Pick someone who left in the last six months. Are all their accounts disabled?
7. Backup integrity. When was the last successful test restore? If you cannot give a date, treat it as a fail.
8. Breach response plan. If a laptop was stolen tonight, what happens in the morning?
9. Data subject request process. If a customer emailed today asking what you hold, how would you handle it, and in what timeframe?
10. Processor register. Can you produce a list of every third-party SaaS that holds your customer data, with evidence of an agreement?

If three or fewer have clean answers, your exposure is significant. If seven or more do, you are doing better than most SMBs and your remaining work is incremental.

When to escalate to legal, when to handle in IT

The clearest split: anything about controls, configuration, monitoring or response is IT. Anything about contracts, liability, regulatory interpretation, or representation in a complaint is legal. Configuring MFA: IT. Drafting a privacy notice: legal, with IT input on what is technically true. Removing an ex-employee's access: IT, same day. The sensible posture for an SMB is to keep a relationship with a privacy lawyer for the moments you genuinely need one, and run the day-to-day controls through your IT setup.

If you would like a structured POPIA-IT readiness assessment that produces a written priority list, contact CyberPeak. We do not write privacy policies, but we do make sure your IT is the kind that one could honestly defend.