POPIA Section 19: what “appropriate security safeguards” requires

Every POPIA condition eventually gets a plain-English gloss somewhere, but section 19 is the one businesses ask about the most, because it’s the one with the least room to fake. You can write a privacy policy in an afternoon. Security safeguards have to actually exist, actually work, and actually keep working — and section 19 is written specifically so that “we assumed it was fine” isn’t a defence.

This piece covers what the law requires from a compliance and governance standpoint: what section 19 actually says, what “appropriate and reasonable” means as a legal standard, what it requires of the vendors who touch your data, and what happens when it fails. If you’re specifically asking “is my web application secure enough” from a technical-testing angle, Deep Scan has its own breakdown of where section 19 meets web-application security testing — this piece is the governance half of the same obligation.

What Section 19 Actually Says

Section 19(1) requires a responsible party to secure the integrity and confidentiality of personal information in its possession or under its control, by taking appropriate, reasonable technical and organisational measures to prevent loss, damage, or unauthorised destruction of personal information, and unlawful access to or processing of personal information.

Section 19(2) turns that single sentence into a four-part, ongoing obligation. You must:

1. Identify all reasonably foreseeable internal and external risks to the personal information in your possession.
2. Establish and maintain safeguards against those risks.
3. Verify— regularly — that those safeguards are effectively implemented.
4. Update the safeguards continuously as new risks are identified.

Read closely, none of the four steps is a one-time event. This is a cycle, not a project with an end date, which is precisely why an annual audit is a partial answer at best — it satisfies step 3 once a year and does nothing for the eleven months in between.

“Appropriate and Reasonable” Is a Standard, Not a Checklist

The law deliberately avoids specifying a fixed list of controls. What’s “appropriate and reasonable” for a two-person consultancy is different from what’s appropriate for a business holding health records or financial account data for a hundred thousand customers. That’s a genuine feature — it lets you right-size your effort to your actual risk profile rather than forcing disproportionate spend on a small operation.

It’s also a trap, for exactly the same reason. “Appropriate and reasonable” is judged after the fact, usually after something has already gone wrong, and “we thought our controls were fine” is a much weaker position than a dated record showing you actually checked. The standard rewards businesses that can point to a process — risk identified, safeguard implemented, safeguard verified, safeguard updated — over businesses that can only point to a general sense that things were probably okay.

Technical Measures vs Organisational Measures

Section 19 asks for both, and they’re not the same discipline.

Technical measuresare the infrastructure-level controls: encryption in transit and at rest, patched software, access controls, secure configuration, monitoring. This is where confirmed testing earns its place — you can assert your application is secure, or you can have someone actively try to break it and show you the proof. That distinction matters more than it sounds: a control that’s never been tested is a belief, not a safeguard.

Organisational measuresare the governance layer around the technical controls: a documented risk assessment, an access-control policy that’s actually followed, staff training, a designated Information Officer, an incident-response process, and — critically — the operator agreements covered below. This is the layer that’s continuously monitorable in a way point-in-time technical testing isn’t. Has the privacy policy gone stale? Has a new SPF/DKIM/DMARC misconfiguration opened a spoofing risk? Has TLS configuration drifted? Is the cookie consent mechanism still doing what it claims to do? These are all checks that matter every month, not once a year — which is the specific reason Komply runs its POPIA module as a continuous monthly scan rather than a point-in-time report.

Sections 20 and 21: Your Vendors Carry the Same Duty

Section 19 doesn’t stop at your own infrastructure. The moment you hand personal information to a third party to process on your behalf — a payroll bureau, an email service provider, a cloud hosting company, an outsourced call centre — sections 20 and 21 require a written agreement obliging that operator to:

• Process the information only on your instruction, and keep it confidential.
• Maintain security measures at least equivalent to what section 19 requires of you directly.

This is the clause that gets skipped most often, because it’s paperwork rather than infrastructure. But it’s not optional, and “our vendor had a breach” is not a defence if there was never a written agreement in place obliging that vendor to secure the data properly. If you’re outsourcing any part of your data processing — and almost every business outsources at least email and often payroll or CRM — this is worth an actual audit of your vendor contracts, not an assumption that standard terms cover it.

Section 22: What Happens When It Goes Wrong

If there are reasonable grounds to believe personal information has been accessed by an unauthorised person, section 22 requires you to notify both the Information Regulator and the affected data subjects as soon as reasonably possible. Unlike the GDPR’s fixed 72-hour clock, POPIA doesn’t set a hard numeric deadline — but “as soon as reasonably possible” is a standard the Regulator will assess with hindsight, and sitting on a known compromise while you decide what to say is exactly the kind of delay that turns a bad day into a much worse one. The one narrow exception: notification to the data subject can be delayed if immediate disclosure would impede a criminal investigation into the compromise.

How to Actually Evidence Section 19 Compliance

This is the question that matters to a CFO or compliance officer more than the statutory text does: when a bank, an insurer, a large customer’s procurement team, or the Information Regulator asks what you’ve done about security, what do you actually show them?

The honest answer is that section 19 asks for two different kinds of proof, and no single tool gives you both:

• Continuous compliance evidence— a dated record that your organisational measures (policy, IO designation, vendor agreements, baseline technical hygiene like TLS and mail-server configuration) are in place and checked regularly. This is what Komply’s monthly POPIA scan produces automatically.
• Confirmed technical evidence— proof that your live application actually resists the specific attacks (SQL injection, broken access control, exposed admin panels, cross-site scripting) that section 19’s “foreseeable risks” language is really pointing at. That requires someone to actively test the application and reproduce what they find, which is a different exercise to a compliance scan. Deep Scan does exactly this — active, black-box testing with every finding backed by a re-runnable proof-of-concept, mapped to OWASP and NIST for anyone asking what standard you tested against.

Two layers of the same obligation. Neither one substitutes for the other, and a business that can show both is in a materially stronger position than one that can only show a policy document.

The Practical Starting Point

If you haven’t done this before, the fastest way to see where you actually stand is to run your own site against a working checklist rather than starting from the statute. We’ve built one in Is your website POPIA-compliant? A practical checklist.