The question usually arrives in one of two forms. A customer's security questionnaire asks, on the same page, "Are you ISO 27001 certified?" and "Are you POPIA compliant?" — and the person filling it in realises they do not know whether a yes to the first is a yes to the second. Or the Managing Director, who has just discovered that he is the organisation's Information Officer by default, asks what the ISMS the quality manager has been building for a year actually does for the Act he is now personally responsible for.
The honest answer is the same in both cases. ISO/IEC 27001 is not POPIA compliance and a certificate is not a POPIA certificate. But section 19 of the Act — the security duty, the one the Information Regulator's enforcement notices cite most — is almost a paragraph-by-paragraph description of what an information security management system does. Build the ISMS properly, scope it to include personal information, and most of the evidence the Regulator would ask for after a compromise already exists in the records an ISO auditor has already read. This article shows where, duty by duty, and is equally clear about the parts of the Act no management system covers.
A note on sources. This article paraphrases the Protection of Personal Information Act 4 of 2013 (sections 14, 17–24, 55–56 and 72), its 2018 Regulations (Regulation 4), the Information Regulator's published guidance, and ISO/IEC 27001:2022 in plain English. It reproduces no statute or standard text. Read the sections in full, work from your licensed copy of the standard, and treat the Regulator's own guidance notes as the authority. Qlause is an independent training and templates provider — not a law firm and not a certification body. Regulatory facts are as at October 2026.
What section 19 actually asks
Strip the drafting away and section 19 places five duties on a responsible party — the organisation that decides why and how personal information is processed.
First, secure the integrity and confidentiality of the personal information you hold, with technical and organisational measures that are appropriate and reasonable, against loss, damage, unauthorised destruction, and unlawful access or processing. That is the headline duty, and every word of it is a word an ISMS uses.
Second, identify the risks — all the reasonably foreseeable internal and external ones. Third, put safeguards in place against them and keep them in place. Fourth, verify regularly that the safeguards actually work. Fifth, keep them up to date as new risks appear and weaknesses are found. And in doing all of this, have regard to generally accepted information security practice and to any rules your industry imposes.
Read that list to anyone who runs a management system and they will hear clauses 6.1.2, 6.1.3, 9.1 and 10.2. That is not a coincidence. Section 19 was written, like most modern data-protection security provisions, with the risk-based management-system model in mind. The Act does not name ISO/IEC 27001 — it names "generally accepted information security practices and procedures" — but a certification body's auditor and the Regulator's investigator are asking for the same things.
Where the ISMS answers it, duty by duty
Identify the risks (section 19(2)(a)). Clause 6.1.2 requires a documented risk assessment method and a register of risks, scored against criteria you defined, with owners. If the asset inventory on which the register rests lists personal information as an asset — the HR files, the customer database, the mailbox full of other people's details — then the register is the section 19 risk identification, and it is dated, repeatable and reviewed. The Regulator's question "how did you identify the risks to personal information?" has a one-word answer: here. The Risk Assessment and SoA Toolkit builds exactly that register, with personal-information assets in the inventory and a worked example on a fictional logistics firm.
Establish and maintain safeguards (19(2)(b)). Clause 6.1.3 selects controls against the risks and records the selection in the Statement of Applicability. Annex A's reference set covers the measures the Regulator's guidance expects to see — access control (A.5.15, A.5.18), encryption (A.8.24), malware protection (A.8.7), backup (A.8.13), logging (A.8.15), endpoint control (A.8.1) — and the SoA is the written statement of which you apply and why. Where the Act says "appropriate and reasonable", the SoA's justifications say why these controls and not others.
Verify regularly (19(2)(c)). This is the duty organisations most often cannot evidence, and the one the standard is most insistent about. Clause 9.1 asks you to decide what to measure and to keep the results; clause 9.2 asks for internal audits on a programme; clause 9.3 puts the whole thing in front of top management. An access review that happened, a restore test that passed, a phishing simulation with a reported click rate, an audit report with findings closed — these are the verification section 19 asks for, and an ISMS produces them on a rhythm.
Keep safeguards up to date (19(2)(d)). Clause 6.1.2 requires the risk assessment to be repeated at planned intervals and when significant changes occur; clause 10.2 turns incidents and audit findings into corrective actions with effectiveness checks; A.5.7 threat intelligence and A.8.8 vulnerability management are the operational controls that keep the picture current. The evidence is the dated review, the threat-intelligence note that changed a score, the patch record.
Have regard to accepted practice (19(3)). An ISMS built to ISO/IEC 27001 and audited by an accredited body is the most direct evidence there is. The legal and contractual register (A.5.31) is where the sector rules the subsection also mentions — a bank customer's security schedule, a professional body's code — are listed and tracked.
The operator question: sections 20 and 21
POPIA draws a line that the standard does not: between the responsible party, who decides why and how personal information is processed, and the operator, who processes it for them. Most organisations are both. You are the responsible party for your employees' and customers' data; you are an operator for any customer whose personal information you handle on their behalf — the logistics firm holding its customers' consignees' details, the payroll bureau, the IT provider with administrator access.
Section 20 requires operators to process only with your knowledge or authorisation and to keep the information confidential. Section 21 requires a written contract obliging every operator to establish and maintain the section 19 measures — and it requires the operator to notify you immediately when it has reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person.
In the ISMS this is the supplier-relationship family — A.5.19 through A.5.23 — and clause 8.1's requirement to control outsourced processes. The gap most organisations find when they do the crosswalk is not that they lack supplier controls; it is that their operator agreements have commercial terms and no security schedule, no breach-notification clause and no deletion-on-termination clause. The Act requires the first; good practice and your own incident clock require the second. Fixing it is a contract addendum, not a project.
Section 22: the duty the ISMS does not make go away
A security compromise, in the Act's language, exists when there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person. When it does, the responsible party must notify the Information Regulator and the data subjects as soon as reasonably possible after discovery — delaying only for law enforcement's legitimate needs or for measures reasonably needed to establish the scope of the compromise and restore the system. Since 1 April 2025 the Regulator accepts those notifications only through its eServices portal; email and the older form are treated as non-compliant. The Regulator has also said plainly that there is no materiality threshold — every compromise is notifiable — and that the investigation does not have to be complete before you report.
The standard's incident controls — A.5.24 planning, A.5.25 assessment and decision, A.5.26 response, A.5.27 learning, A.5.28 evidence, A.6.8 reporting, A.5.5 contact with authorities — give you the machinery: a channel, a register, a classification step, a procedure, an evidence log, a review. What they do not give you is the section 22 decision itself, because ISO/IEC 27001 is written for every jurisdiction and does not know South African law. That decision — personal information involved? reasonable grounds? responsible party or operator? — has to be written into your incident procedure as an explicit step, with the Information Officer in the room and the clock visible. The Incident and Breach Response Kit is that step, built: a register that answers the section 22 question from two fields and keeps the clocks, a decision sheet that names every duty and deadline, the pack for the portal, and notices to data subjects carrying the four things section 22(5) requires.
Two further points from the Regulator's enforcement record are worth knowing. Failure to notify, or notifying late, features in most of the enforcement notices the Regulator has issued so far. And "it was a fraud, not a breach" is not a defence: a business-email compromise that diverts a payment also means an attacker has been reading a mailbox full of personal information.
Regulation 4 and the Information Officer
The 2018 Regulations give the Information Officer five duties under Regulation 4(1): see that a compliance framework is developed, implemented, monitored and maintained; see that a personal information impact assessment is done so that adequate measures and standards exist; develop, monitor and maintain the PAIA section 51 manual and make it available; develop internal measures and systems to process requests for information or access; and conduct internal awareness sessions on the Act, the Regulations, applicable codes of conduct and the Regulator's information.
An ISMS scoped to include personal information is a compliance framework — the policy, the risk register, the controls, the measures, the review are what "developed, implemented, monitored and maintained" looks like in practice, and clause 9.3's management review is where the Information Officer reports on it. The personal information impact assessment is the risk assessment viewed through the data subject's eyes: the same register, filtered to personal-information assets, with the consequences column written in terms of harm to people rather than harm to the business. The awareness duty is A.6.3 with POPIA content added to the programme. The manual and the request-handling system are not ISMS artefacts at all — they are the first of several things the Act requires that the standard does not.
The Information Officer must also be registered with the Regulator before taking up duties, and must have an eServices portal account before the day it is needed. Creating the account during the incident is the most common avoidable delay in South African breach notifications.
Why a certificate is not compliance
It is worth being exact about what each side does not cover, because the questionnaire asks both questions for a reason.
The standard does not test lawful basis, purpose limitation, consent, the data subject's rights of access and correction, retention limits as a legal matter, the content of privacy notices at collection, cross-border transfer rules, or the Information Officer's registration. A certified ISMS can process personal information unlawfully and never raise a nonconformity, because the certification body audits whether you do what you said you would do, not whether the processing itself is permitted. Sections 14 (retention), 17 and 18 (documentation and notification at collection), 23 and 24 (access and correction) and 72 (transfers) are POPIA duties the crosswalk maps to controls that help — A.5.33, A.8.10, A.5.34, A.5.14 — but that no audit will verify as compliance.
The Act, for its part, does not require a management system, a risk method, a Statement of Applicability or a certificate. It requires outcomes: information secured, risks identified, safeguards maintained, verified and updated, compromises notified. An organisation can meet section 19 without ISO/IEC 27001. It is simply much harder to prove, because the proof is the dated, owned, reviewed records a management system produces and ad-hoc security does not.
So the questionnaire's two questions have two answers, and the right response to the board is the same: the ISMS is how we evidence the security duty; the Information Officer's programme — manual, notices, requests, retention, transfers, registration — is how we meet the rest; and the two share a risk register, an incident procedure and a management review.
What to do this quarter
- Put personal information on the asset inventory as information assets in their own right — the HR files, the customer records, the mailboxes — with an owner and a classification, and let the risk register inherit them.
- Add a "POPIA section" column to the Statement of Applicability, or use the crosswalk alongside it, so that each control's justification can cite the duty it evidences as well as the risk.
- Read every operator agreement you hold, in both directions, and add a security schedule with a breach-notification clause and a deletion-on-termination clause where there is none.
- Write the section 22 decision into the incident procedure as an explicit, timed step with the Information Officer named — and confirm the Information Officer is registered and has a working portal account today.
- Put POPIA on the management-review agenda as a standing input: the Information Officer's report, the awareness sessions, the request log, any compromise.
- Run a tabletop exercise on a scenario that involves personal information, and time how long it takes the room to reach the notification decision.
Free download: the POPIA ↔ ISO 27001 Crosswalk
The crosswalk below is this article as a working spreadsheet: twenty-four POPIA and Regulation 4 duties in plain words, each mapped to the ISO/IEC 27001:2022 clauses and Annex A controls that evidence it, with the GDPR article and the NIST CSF 2.0 category alongside for the customers who ask in those languages, the evidence to show, and a status column that gives you a readiness percentage. A second sheet is the Information Officer's fourteen-point readiness check — registration, portal account, exercised procedure and the rest. Enter your email and it is on its way.
Frequently asked questions
Does ISO 27001 certification mean we are POPIA compliant?
No. Certification evidences the security duty in section 19 well, and the incident machinery section 22 needs, but it does not test lawful processing, data-subject rights, notices, retention as a legal matter, cross-border transfers or the Information Officer's registration. Those are the Information Officer's programme. Say so on the questionnaire; the customers who ask both questions know the difference.
Do we have to notify the Regulator of every compromise, even a small one?
Yes. The Regulator has stated that POPIA has no materiality threshold — a misdirected email with a dozen payslips is notifiable. The notification goes through the eServices portal only, as soon as reasonably possible after discovery, and the investigation does not have to be complete first.
Is there a 72-hour deadline under POPIA?
No. The Act says "as soon as reasonably possible" and sets no number of hours; the 72-hour clock belongs to the GDPR, which applies only if you serve or monitor people in the EU or UK. Many South African organisations set 72 hours as their own internal target so that "reasonably possible" has a number the incident team can work to — and that is the sensible thing to do, as long as nobody mistakes it for the law.
We are an operator for our customers. What changes?
Section 21 requires you to notify the responsible party immediately when you have reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person — immediately, not "as soon as reasonably possible" — and the customer then notifies the Regulator and the data subjects. Your contract will usually name a route and a time; your incident procedure needs the operator branch written in.
Who is our Information Officer if we never appointed one?
The head of the organisation — the Managing Director or Chief Executive — by default, under section 56, unless the duties have been delegated in writing. Either way the Information Officer must be registered with the Regulator, and the deputies too.
Does the Cybercrimes Act add another notification duty?
Not yet. Section 54 — a duty on electronic communications service providers and financial institutions to report certain offences to the police within 72 hours — had not been brought into operation as at October 2026. POPIA section 22 is the only statutory breach-notification duty in force; a police case number is still worth having for your insurer and for the Regulator's questions.
Qlause is an independent training and templates provider — not a law firm, not a certification body. This article paraphrases POPIA, its Regulations and the Information Regulator's guidance in plain English for a management-system reader and reproduces no statute or standard text; read the sections in full and take legal advice for your organisation. Sources: Protection of Personal Information Act 4 of 2013; POPIA Regulations 2018 (GN R1383); Information Regulator media statement on the eServices portal (7 April 2025) and fact sheet on security-compromise notifications (19 August 2025); ISO/IEC 27001:2022 (iso.org); Cybercrimes Act 19 of 2020 commencement notices.