South Africa's Protection of Personal Information Act (POPIA, Act 4 of 2013) requires every responsible party to secure personal information with appropriate technical and organisational measures and to report security compromises to the Information Regulator, which now only accepts those reports through its eServices Portal. POPIA also protects juristic persons, makes prior authorisation a hard gate for some processing, and lets the Regulator fine organisations that ignore enforcement notices. This guide covers scope, the eight conditions for lawful processing, the section 19 and 22 security duties, the 2025 amendments to the Regulations, transfers under section 72, enforcement, and what the Act means for AI agents and machine credentials. It is written for security, privacy and engineering leads supporting South African processing.
Key takeaways
- Section 19 is a risk-based security duty: identify foreseeable internal and external risks, maintain safeguards against them, verify them regularly and update them, with due regard to generally accepted information security practices.
- Section 22 has no fixed clock: notify the Regulator and data subjects "as soon as reasonably possible" after discovering a compromise, and the Regulator's August 2025 fact sheet says all reports must go through the eServices Portal.
- Operators must tell you immediately: section 21 requires a written contract that binds the operator to section 19 measures and to notify the responsible party immediately of suspected unauthorised access.
- Information officers must be registered: under section 55(2) duties start only after registration with the Regulator.
- Non-compliance with enforcement notices is fined: the Regulator has issued R5 million fines to the Department of Justice (2023) and the Department of Basic Education (2024), against a stated ceiling of R10 million.
Scope: who and what is covered
POPIA applies to the processing of personal information entered in a record by or for a responsible party, by automated or non-automated means, where the responsible party is domiciled in South Africa, or where a party not domiciled there uses automated or non-automated means in the Republic, unless those means only forward information through the country (section 3).
| Element | POPIA position | Section |
|---|---|---|
| Responsible party | Determines, alone or with others, the purpose and means of processing (GDPR "controller") | s1 |
| Operator | Processes for a responsible party under contract or mandate (GDPR "processor") | s1, ss20-21 |
| Data subject | The person to whom the information relates, which includes an identifiable, existing juristic person (companies, trusts) as well as natural persons | s1 |
| Special personal information | Religious or philosophical beliefs, race or ethnic origin, trade union membership, political persuasion, health or sex life, biometric information, and certain criminal behaviour | ss26-27 |
| Information officer | By default the head of a private body; must be registered with the Regulator before taking up duties | ss55-56 |
Juristic persons matter for security teams: a breach of supplier or customer company records can be a section 22 compromise even when no individual's data is involved.
Key obligations
The eight conditions for lawful processing
Chapter 3 sets eight conditions, and section 8 makes the responsible party accountable for meeting them both when it determines purpose and means and during processing.
| Condition | Sections | What it means in practice |
|---|---|---|
| 1. Accountability | s8 | The responsible party owns compliance, including for operators |
| 2. Processing limitation | ss9-12 | Lawful, minimal processing on a listed justification such as consent, contract or legitimate interest |
| 3. Purpose specification | ss13-14 | Defined purpose; no longer retention than necessary |
| 4. Further processing limitation | s15 | New uses must be compatible with the original purpose |
| 5. Information quality | s16 | Complete, accurate, not misleading, updated where necessary |
| 6. Openness | ss17-18 | Documented processing and notice at collection |
| 7. Security safeguards | ss19-22 | Technical and organisational measures, operator controls, compromise notification |
| 8. Data subject participation | ss23-25 | Access, correction and deletion |
Security safeguards: section 19
Section 19(1) requires 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. Section 19(2) turns that into a cycle, which is the part auditors and the Regulator test:
- Identify all reasonably foreseeable internal and external risks to personal information in your possession or under your control.
- Establish and maintain appropriate safeguards against the risks identified.
- Regularly verify that the safeguards are effectively implemented.
- Update the safeguards in response to new risks or deficiencies in earlier safeguards.
Section 19(3) requires due regard to generally accepted information security practices and procedures, including those required by industry or professional rules. Mapping controls to ISO/IEC 27001 or the NIST CSF is the practical way to evidence that. The Regulator's own enforcement shows what "maintain" means: its 2023 action against the Department of Justice followed a finding that licences for anti-virus, SIEM and intrusion detection tooling had lapsed, and the enforcement notice required proof of renewal within 31 days.
Operators: sections 20 and 21
- Written contract (s21(1)): the responsible party must ensure, through a written contract, that the operator establishes and maintains section 19 measures.
- Immediate notice (s21(2)): the operator must notify the responsible party immediately where there are reasonable grounds to believe information has been accessed or acquired by an unauthorised person. Put a measurable deadline (for example 24 hours) and a named contact into each contract, because the section 22 clock in practice starts with you.
See the Third-Party Risk Management Guide.
Security compromise notification: section 22
| Element | Rule | Source |
|---|---|---|
| Trigger | Reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person | s22(1) |
| Who is told | The Regulator and, subject to the delay rule, the data subject (unless the identity of the data subject cannot be established) | s22(1) |
| Timing | As soon as reasonably possible after discovery, allowing for law enforcement needs and measures to establish scope and restore integrity | s22(2) |
| Delay of data subject notice | Only if a law enforcement public body or the Regulator decides notice would impede a criminal investigation | s22(3) |
| Form of data subject notice | In writing, by mail, email, prominent website notice, news media, or as the Regulator directs | s22(4) |
| Content of data subject notice | Possible consequences; measures taken or intended; recommended steps for the data subject; identity of the unauthorised person if known | s22(5) |
| Channel to the Regulator | eServices Portal (Security Compromises Reporting went live 1 April 2025); the Regulator's Fact Sheet on Handling of Security Compromises (19 August 2025) says all reports must be submitted through it | Regulator fact sheet |
No fixed deadline is not a licence to wait (compare the 72 hour expectation in the New Zealand Privacy Act Guide): the fact sheet says to notify once reasonably sure a compromise occurred, and investigation can continue afterwards. For a cross-jurisdiction workflow, see the Data Breach Notification Checklist and the Breach Notification Laws by Country Guide.
Prior authorisation: sections 57 and 58
Section 57(1) requires Regulator authorisation before: linking unique identifiers for a new purpose with other parties' information; processing criminal or objectionable conduct information for third parties; credit reporting; and transferring special or children's personal information to a foreign country without adequate protection. Under section 58 the Regulator has four weeks to say whether it will investigate, then up to 13 weeks to conclude, after which a favourable decision may be presumed.
Direct marketing and automated decisions
- Electronic direct marketing (s69): needs consent, except for existing customers offered an opt-out at collection and in every message; a non-customer may be asked for consent once.
- Automated decision making (s71): a data subject may not be subject to a decision with legal consequences or substantial effect based solely on automated processing intended to profile them (performance at work, creditworthiness, reliability, location, health, personal preferences or conduct), unless the decision is linked to a contract with safeguards or authorised by law or code. Safeguards must let the data subject make representations and give enough information about the underlying logic.
Transfers outside South Africa: section 72
A responsible party may transfer personal information to a third party in a foreign country only if one of these applies:
| Ground | Typical use |
|---|---|
| (a) Recipient subject to a law, binding corporate rules or binding agreement giving an adequate level of protection, substantially similar to POPIA's conditions, including onward-transfer rules | Cloud and SaaS contracts with POPIA-equivalent terms; intra-group BCRs |
| (b) Data subject consents | Narrow consumer use cases; weak for employees |
| (c) Necessary for a contract between data subject and responsible party, or pre-contract steps at the data subject's request | Booking travel abroad for a customer |
| (d) Necessary for a contract concluded in the data subject's interest with a third party | Benefits administration with a foreign provider |
| (e) For the data subject's benefit, consent impracticable but likely | Exceptional cases |
The Act itself provides no adequacy list or standard clauses, so most organisations rely on ground (a) through contract. Special or children's personal information going to a country without adequate protection also triggers section 57(1)(d) prior authorisation. For the regional comparison, see the International Data Transfers Map.
Information officer and PAIA
Section 55(1) makes the information officer responsible for encouraging compliance, handling requests and working with the Regulator. Regulation 4, as amended in 2025, still requires the information officer to ensure that a compliance framework is developed, implemented, monitored, maintained and continually improved, but the duty to develop the PAIA manual was removed from that regulation. POPIA and the Promotion of Access to Information Act (PAIA) remain linked: the openness condition relies on the PAIA manual, and data subject access requests follow PAIA procedures, so the manual still has to exist and be current.
Timeline and current status
| Date | Event |
|---|---|
| 11 April 2014 | Section 1, ss39-54 (the Regulator) and ss112-113 commence (Government Gazette 37544) |
| 1 July 2020 | Main provisions commence: ss2-38, 55-109, 111 and 114(1)-(3) (Government Gazette 43461 of 22 June 2020) |
| 30 June 2021 | Ss110 and 114(4) commence; the one-year transition for compliance ends |
| 1 July 2021 | Section 58(2) prior authorisation commences (Government Gazette 44383) |
| 1 April 2025 | Security Compromises Reporting goes live on the eServices Portal |
| 17 April 2025 | Amended Regulations relating to the Protection of Personal Information (Government Notice 6126 of 2025) published, effective immediately |
| 19 August 2025 | Regulator's Fact Sheet on Handling of Security Compromises: all reports via the eServices Portal |
| 30 September 2025 | Draft regulations on processing health or sex life information published for comment under s112(2)(c) |
| March 2026 | Final health information regulations reported as gazetted; they apply to insurers, medical schemes and administrators, managed healthcare organisations, pension funds and employers |
What changed in the 2025 Regulations
| Regulation | Change |
|---|---|
| Reg 2, objections | Free, Form 1 or similar, any expedient channel including SMS and WhatsApp; right to object stated at collection; telephonic objections recorded |
| Reg 3, correction and deletion | Form 2 or similar; data subject told once the action is done |
| Reg 4, information officer | PAIA manual duty removed, compliance framework duty kept |
| Reg 6, direct marketing | Form 4 or similar; calls recorded; opt-out is not consent |
| Reg 7, complaints | Wider list of complainants, Form 5, reference number within 14 days |
| Reg 13 (new), fines | Instalment payment may be arranged case by case |
Status as of October 2026: POPIA is in force with no amendments to the Act itself; the 2018 Regulations apply as amended on 17 April 2025, and the health information regulations add sector rules.
Enforcement and penalties
| Tool | What it does | Section |
|---|---|---|
| Assessment and investigation | Regulator may assess compliance on its own initiative or on complaint, and investigate | ss89, 76, 81 |
| Enforcement notice | Requires specified steps, or a stop to processing, within a set period; appealable to the High Court within 30 days | ss95, 97 |
| Infringement notice and administrative fine | For alleged offences; the Regulator states a ceiling of R10 million; the party may pay, arrange instalments, or elect to be tried in court | s109 |
| Criminal offences | Including failure to comply with an enforcement notice and obstruction of the Regulator; the most serious offences carry a fine or imprisonment of up to 10 years | ss100-107 |
| Civil action | Data subjects or the Regulator on their behalf may claim damages for interference with personal information | s99 |
Both public R5 million fines, against the Department of Justice (reported 4 July 2023) and the Department of Basic Education (23 December 2024), were for ignoring enforcement notices rather than for the underlying incident. The Justice notice required renewed anti-virus, SIEM and intrusion detection licences and disciplinary steps by 3 June 2023. Treat an enforcement notice as a hard project deadline with board visibility.
What it means for AI agents and non-human identities
POPIA is technology-neutral, but its definitions fit automated systems closely.
- A compromised credential is a section 22 question: if a service account password, API key or OAuth token that reaches personal information is used by an unauthorised person, there are reasonable grounds to believe information was accessed. The Snowflake breach shows the pattern: valid customer-held credentials without MFA opened data warehouses full of personal records. See the Secrets Management Guide.
- Machine credentials are a foreseeable risk under s19(2): your risk register should list leaked, over-privileged and unrotated non-human credentials explicitly, with safeguards (vaulting, scoping, rotation) and regular verification. See the Service Account Security Guide.
- Agents process for the responsible party: an agent reading a CRM must fit the original purpose (s15) and use the minimum access needed (s10).
- Section 71 bites on agent decisions: an agent that declines a claim, scores credit or blocks an account without human involvement is solely automated decision making. Keep a human review route and enough logged information about the logic to let the data subject make representations.
- Model providers are operators: a third-party LLM or agent platform receiving personal information needs a section 21 contract with security terms and immediate notice, and if it is abroad a section 72 ground, usually contractual adequacy.
- Juristic person data in prompts: company information pasted into an AI tool is still personal information under POPIA. See the AI and Privacy Guide.
Framework mapping
| POPIA requirement | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|
| Lawful basis and purpose (ss9-15) | GV.OC-03 | PT-2, PT-3 | A.5.34 |
| Risk identification and safeguards (s19(2)) | GV.OC-03, PR.DS-01 | RA-3, SC-28 | A.5.34, A.8.24 |
| Access limitation for people and machines (ss10, 19) | PR.AA-05 | AC-6, IA-5 | A.5.15, A.8.2 |
| Operator contracts (s21) | GV.SC-05 | SA-9 | A.5.19, A.5.20 |
| Compromise notification (s22) | RS.CO-02, RS.CO-03 | IR-6, IR-8 | A.5.24, A.5.26 |
| Records of processing and retention (ss14, 17) | ID.AM-07 | SI-12 | A.5.9, A.5.33 |
Compliance steps
- Confirm applicability: list every entity domiciled in South Africa and every system or device used in South Africa by a foreign entity, and include juristic person records in the inventory.
- Register the information officer and deputies on the Regulator's Information Officer Portal, and confirm the registration is current after any leadership change.
- Build the compliance framework (Reg 4): policies, a processing inventory, impact assessments for high-risk processing, training and monitoring. See the DPIA Guide for the assessment method.
- Run the section 19(2) cycle with a dated risk register, named safeguards, verification evidence (tests, scans, licence and tool health checks) and an update log.
- Fix operator contracts: section 21 security terms, a measurable "immediate" notice deadline, audit rights and deletion on exit.
- Rebuild the incident runbook around the eServices Portal: who holds portal access, which facts are needed, pre-approved data subject notice text covering the s22(5) items, and the criminal investigation delay path.
- Check prior authorisation: screen new projects for the s57(1) categories before build, not after.
- Document transfers: map each foreign recipient to a s72 ground and keep the contract evidence.
Small versus large organisations: a small business still needs a registered information officer, operator contracts and a portal-ready incident process, but can run the s19 cycle on a short annual register. A multinational should keep a South African layer in its global programme: juristic persons, the portal filing path and section 57 screening that GDPR processes do not cover.
Detection and measurement
- Time from discovery to eServices Portal report for each compromise and exercise, against an internal target such as 72 hours.
- Operator notification time: median hours from operator awareness to your notification, against the contractual deadline.
- Safeguard verification coverage: percentage of section 19 safeguards with test evidence in the last 12 months, including security tool licence and health status.
- Machine credentials reaching personal information with an owner, vault location and rotation date.
Common failure patterns
- Letting security tooling lapse: expired anti-virus, SIEM or IDS licences were at the centre of the Department of Justice enforcement, and "maintain" in s19(2)(b) covers them.
- Ignoring juristic persons: incident triage that only looks for natural persons misses reportable compromises of company records.
- No portal access: reports go through the eServices Portal; set up access before you need it.
- Waiting for the forensic report: hard to defend once you are reasonably sure a compromise occurred.
- Vague operator contracts: "immediately" with no named contact delays your own notice.
Practitioner checklist
- Confirm POPIA applicability per entity and system, including juristic person data.
- Register the information officer and deputies with the Regulator and keep it current.
- Maintain a dated section 19(2) risk register that names machine credentials and AI agents.
- Verify security tooling health and licences quarterly and keep the evidence.
- Put section 21 terms with a measurable notice deadline into every operator contract.
- Test the eServices Portal reporting path and data subject notice templates in a tabletop.
- Screen new processing for section 57(1) prior authorisation before build.
- Map every cross-border recipient to a section 72 ground.
Standards and references
- Government of South Africa: Protection of Personal Information Act 4 of 2013
- Government of South Africa: Protection of Personal Information Act, commencement notices
- SAFLII Law Library: Regulations relating to the Protection of Personal Information, 2018: Amendment (GN 6126 of 2025)
- Information Regulator (South Africa): official website
- Information Regulator: Media statement on the infringement notice issued to the Department of Basic Education
- SAnews: Information Regulator fines Justice Department
- Acts Online: Information Regulator Fact Sheet on Handling of Security Compromises
- Baker McKenzie: South Africa amendments to the POPIA Regulations
This guide summarises South Africa's POPIA and the Information Regulator's regulations and guidance as of October 2026 and is not legal advice. Related NHI Mgmt Group resources: Global Privacy Regulatory Map · International Data Transfers Map · Breach Notification Laws by Country Guide · GDPR Compliance Guide for Security Teams