POPIA is usually introduced as a privacy law and then handed to legal. That framing is why so many South African security programmes end up with a POPIA folder that has almost nothing to do with how the organisation actually protects data.
The Protection of Personal Information Act has eight conditions for lawful processing. Only one of them, Condition 7, is squarely about security. But that single condition is where a security team carries most of the real obligation, and it is written in language that maps cleanly onto controls most teams are already building.
What Section 19 actually says
Section 19 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 of, damage to, or unauthorised destruction of personal information, and unlawful access to or processing of it.
Read that carefully, because two words do most of the work: appropriate and reasonable. POPIA does not hand you a control list. It does not name an encryption algorithm or a patching window. It asks whether your measures are proportionate to the risk, and it asks you to be able to show your reasoning.
Section 19 then sets out what you must actually do to get there:
- Identify all reasonably foreseeable internal and external risks to the personal information you hold
- Establish and maintain appropriate safeguards against those risks
- Regularly verify that the safeguards are effectively implemented
- Continually update the safeguards in response to new risks or identified deficiencies
That is a risk assessment, a control set, an assurance activity, and a review cycle. If it sounds like the shape of every security framework you have ever read, that is precisely the point.
The clause that imports the rest of the security world
Section 19(3) adds a requirement that is easy to skim past: the responsible party must have due regard to generally accepted information security practices and procedures which may apply to it generally, or be required by specific industry or professional rules and regulations.
This is the clause that quietly pulls the wider security world into POPIA. If your sector has a standard, you are expected to have considered it. It is also the clause that makes ISO 27001 or NIST CSF alignment genuinely useful as evidence rather than as a badge. You are not certifying in order to satisfy POPIA. You are pointing at a recognised practice and demonstrating that you had due regard for it.
Operators: the obligation you cannot outsource
Section 21 covers operators, POPIA’s term for a third party that processes personal information on your behalf. Your cloud provider, your payroll bureau, your email marketing platform, your managed service provider.
There are two requirements. First, the operator must process the information only with your knowledge or authorisation, and must treat it as confidential. Second, and this is the one that generates work, you must ensure that the operator establishes and maintains the security measures required by Section 19, and that arrangement must sit in a written contract.
A third piece catches teams out: an operator must notify you immediately where there are reasonable grounds to believe that personal information has been accessed by an unauthorised person. If your supplier contracts do not carry that obligation through, your own Section 22 clock starts late, and you will be explaining why to the Regulator rather than to your vendor.
Section 22 and the clock you do not control
Where there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person, you must notify the Information Regulator and the affected data subjects as soon as reasonably possible after discovering the compromise. The Act permits a delay only where a public body responsible for the prevention, detection or investigation of offences, or the Regulator itself, determines that notification would impede a criminal investigation. It is not a general grace period.
Notification to data subjects must be in writing and delivered by one of the routes the Act names: post to their last known address, email to their last known address, a prominent notice on your website, publication in the news media, or a method the Regulator directs.
The content is specified too. It must provide enough information for the data subject to take protective measures, describe the possible consequences, describe what you are doing about it, recommend what they should do, and, where you know it, identify who accessed the information.
Read that last list as a set of engineering requirements. To write that notification you need to know what data was in scope, whose it was, how it was accessed, and when. If your logging cannot answer those four questions within days, you will be writing a vague notification, and a vague notification is itself a finding.
Enforcement is no longer theoretical
For the first few years after commencement, POPIA enforcement was largely hypothetical, and a lot of programmes were budgeted accordingly. That is no longer a safe assumption. In 2023 the Information Regulator found that the Department of Justice and Constitutional Development had contravened Sections 19 and 22 following data breaches, issued an infringement notice, and followed it with an administrative fine.
The Act provides for administrative fines and, for certain offences, penalties of up to R10 million or imprisonment. The headline number matters less than the mechanism: the Regulator can act on a failure to secure and on a failure to notify, independently of whether anyone was demonstrably harmed.
Mapping POPIA onto controls you probably already have
Most of Section 19 is satisfied by work a competent security team is already doing. The gap is usually documentation and traceability rather than capability.
- Data inventory and classification. You cannot assess risk to personal information you have not located. This is the foundation, and it is the step most often skipped.
- Risk assessment. Documented, dated, repeated, and explicitly naming personal information as an asset class rather than burying it in a general IT risk register.
- Access control. Least privilege, joiner-mover-leaver, and evidence of access reviews. Section 19 cares about unlawful access, which is an access control outcome.
- Encryption in transit and at rest. Not named in the Act, but squarely inside generally accepted practice.
- Logging and monitoring. Required in practice by Section 22, because you cannot notify accurately without it.
- Exposure and vulnerability management. Reasonably foreseeable external risks include your internet-facing footprint. An unknown subdomain running an unpatched service is a foreseeable risk you failed to identify.
- Supplier assurance. Contracts, security schedules, and some form of ongoing verification for every operator.
- Incident response. A plan that includes the notification decision, with named decision makers and a known route to the Regulator.
- Awareness training. Organisational measures, in POPIA’s own words, not only technical ones.
Where teams get it wrong
Three patterns come up repeatedly.
The first is treating POPIA as a document exercise. A policy set that no control implements is worse than no policy set at all, because it establishes a standard you are visibly not meeting.
The second is scoping to the CRM and stopping. Personal information lives in your logs, your backups, your support tickets, your monitoring tools, your test environments, and your former employees’ mailboxes. Production data copied into a test environment is a recurring finding, and it is entirely avoidable.
The third is having no evidence of the review cycle. Section 19 requires you to regularly verify and continually update. If your last risk assessment is undated or three years old, you have not met the requirement, however good the underlying controls are.
Where to start
If you are building from nothing, the order that produces the most compliance per unit of effort is roughly this. Find the personal information. Write down the risks to it. Fix the ones your own risk assessment says are highest. Get the operator contracts in place. Confirm you could actually write a Section 22 notification if you had to. Then set a review date and keep it.
Compliance is what that work looks like from the outside. It is not a separate project, and it should never be the reason you do any of it.