POPIA Section 19: what “appropriate security safeguards” requires

Every POPIA condition eventually gets a plain-English gloss somewhere, but section 19 is 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 measures are 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 measures are 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. Komply’s website scan, which runs every 30 days on every plan, checks the public side of several of them: the privacy policy and cookie consent, TLS and security headers, and the SPF, DKIM and DMARC records. It can’t see the internal ones.

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 — two sections apply:

• Section 20 binds the operator directly: it may process the information only with your knowledge or authorisation, and must keep it confidential.
• Section 21 requires a written contract in which you make sure the operator establishes and maintains the security measures section 19 requires, and the operator must tell you immediately if it has reasonable grounds to believe the information has been accessed by someone unauthorised.

It is easy to skip, 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. You can delay telling data subjects only if a public body responsible for investigating offences, or the Regulator, determines that notification would impede a criminal investigation (s22(3)); you can’t make that call yourself. Since 1 April 2025, the report to the Regulator goes through its eServices portal, not email.

Section 22 is not a rarely-used provision. The Information Regulator reported 2,374 security compromises in its 2024/25 year, and by the end of August 2026 over 8,000 since the Act commenced. Every one of those notifications is a business answering, with hindsight, the question this article opened with: were your section 19 safeguards appropriate and reasonable?

The Regulator’s August 2026 enforcement notice to the SABS shows how it asks that question. After a 2024 ransomware attack, it found weak safeguards, “failure to address known vulnerabilities” and no incident-response plan, and it was explicit that “this enforcement action is not being taken simply because SABS was the victim of a cyberattack.” Being attacked isn’t the breach of section 19. Not having done the work is.

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. Komply’s website scan produces the public part of that record every 30 days, kept in your Komply dashboard: what your privacy policy, consent banner, Information Officer disclosure, TLS, headers and email records showed on the day. Your vendor agreements, risk assessment and training records don’t sit on your website, so no scan can see them; that record is yours to keep.
• 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.