# Workflows — South Africa POPIA Compliance ## Workflow 1: POPIA Compliance Assessment ``` TRIGGER: Organisation processes personal information of data subjects in South Africa │ ├─► Phase 1: Applicability Determination │ ├─ Step 1.1: Confirm responsible party is domiciled in South Africa │ │ OR uses automated/non-automated means within South Africa │ ├─ Step 1.2: Identify whether juristic person data is also in scope │ │ (POPIA uniquely covers juristic persons, unlike GDPR) │ ├─ Step 1.3: Determine if any exclusions apply (Section 6-7): │ │ ├─ Processing for purely personal or household purposes │ │ ├─ Processing by or on behalf of a public body for national security │ │ ├─ Processing relating to the judicial functions of a court │ │ └─ Processing exclusively for literary or artistic expression │ └─ Step 1.4: Document applicability determination and rationale │ ├─► Phase 2: Gap Analysis Against Eight Conditions │ ├─ Step 2.1: Condition 1 — Accountability │ │ ├─ Is an Information Officer designated and registered? │ │ ├─ Are Deputy Information Officers appointed where necessary? │ │ └─ Is there a POPIA compliance programme in place? │ │ │ ├─ Step 2.2: Condition 2 — Processing Limitation │ │ ├─ Is a lawful basis identified for each processing activity? │ │ ├─ Is consent voluntary, specific, and informed where relied upon? │ │ ├─ Is collection adequate, relevant, and not excessive? │ │ └─ Is direct collection ensured, with exceptions documented? │ │ │ ├─ Step 2.3: Condition 3 — Purpose Specification │ │ ├─ Is the purpose specific, explicit, and lawful? │ │ └─ Are retention periods defined and not excessive? │ │ │ ├─ Step 2.4: Condition 4 — Further Processing Limitation │ │ └─ Is compatibility assessment performed for any secondary use? │ │ │ ├─ Step 2.5: Condition 5 — Information Quality │ │ └─ Are there mechanisms to ensure accuracy and completeness? │ │ │ ├─ Step 2.6: Condition 6 — Openness │ │ ├─ Is a Section 18 notification provided at collection? │ │ └─ Is PAIA manual updated to include POPIA requirements? │ │ │ ├─ Step 2.7: Condition 7 — Security Safeguards │ │ ├─ Are technical and organisational measures appropriate? │ │ ├─ Do operator contracts include Section 21 requirements? │ │ └─ Is a breach notification procedure in place per Section 22? │ │ │ └─ Step 2.8: Condition 8 — Data Subject Participation │ ├─ Can data subjects request access, correction, deletion? │ └─ Is the process for handling requests documented and timely? │ ├─► Phase 3: Remediation │ ├─ Step 3.1: Prioritise gaps by risk and regulatory exposure │ ├─ Step 3.2: Implement remediation actions with assigned owners │ ├─ Step 3.3: Update privacy notices to meet Section 18 requirements │ ├─ Step 3.4: Execute operator agreements per Section 21 │ └─ Step 3.5: Register Information Officer with the Information Regulator │ └─► Phase 4: Ongoing Compliance ├─ Step 4.1: Conduct annual POPIA compliance reviews ├─ Step 4.2: Monitor Information Regulator enforcement notices and guidance ├─ Step 4.3: Maintain training programme for all staff processing personal information └─ Step 4.4: Conduct periodic breach response simulations ``` ## Workflow 2: POPIA Section 22 — Security Compromise Notification ``` TRIGGER: Reasonable grounds to believe a security compromise of personal information has occurred │ ├─► Step 1: Immediate Assessment (within 24 hours) │ ├─ Confirm whether personal information has been accessed or acquired │ │ by an unauthorised person │ ├─ Determine categories of personal information affected │ ├─ Estimate number of data subjects affected │ └─ Assess whether identity theft or fraud risk exists │ ├─► Step 2: Notification to Information Regulator │ ├─ Notify "as soon as reasonably possible" (Section 22(1)) │ ├─ Include: nature of compromise, estimated data subjects, │ │ description of personal information involved, measures taken │ ├─ Note: the Information Regulator may direct the responsible party │ │ to publicise the compromise (Section 22(6)) │ └─ Delay permitted only if South African Police Service determines │ notification will impede a criminal investigation (Section 22(3)) │ ├─► Step 3: Data Subject Notification │ ├─ Notify affected data subjects "as soon as reasonably possible" │ ├─ Notification must be in writing (by mail or email) — Section 22(5) │ ├─ Include: description of the compromise, what information was involved, │ │ measures taken, recommended protective actions │ └─ If direct notification is not possible, publish in media │ └─► Step 4: Post-Compromise Actions ├─ Document compromise in internal breach register ├─ Implement remediation measures to prevent recurrence ├─ Cooperate with Information Regulator assessment (Section 89) └─ Update security safeguards as required ``` ## Workflow 3: Cross-Border Transfer Assessment (Section 72) ``` TRIGGER: Transfer of personal information outside South Africa proposed │ ├─► Step 1: Identify Transfer Mechanism │ ├─ Adequate level of protection in recipient country? (Section 72(1)(a)) │ ├─ Binding corporate rules? (Section 72(1)(a)) │ ├─ Binding agreement with sufficient protections? (Section 72(1)(a)) │ ├─ Data subject consent after being informed of risks? (Section 72(1)(b)) │ ├─ Necessary for contract performance? (Section 72(1)(c)) │ ├─ Pre-contractual measures at data subject's request? (Section 72(1)(d)) │ ├─ Benefit of data subject, consent impracticable? (Section 72(1)(e)) │ └─ Public record? (Section 72(1)(f)) │ ├─► Step 2: Assess Adequacy │ ├─ Review recipient country's data protection framework │ ├─ Consider Information Regulator guidance on adequacy (when issued) │ ├─ Evaluate enforceability of data subject rights in recipient jurisdiction │ └─ Document adequacy assessment rationale │ ├─► Step 3: Implement Safeguards │ ├─ Execute binding agreement with recipient where required │ ├─ Include all POPIA conditions in transfer agreement │ └─ Ensure right of data subject to enforce agreement provisions │ └─► Step 4: Record and Monitor ├─ Maintain register of all cross-border transfers ├─ Review transfers annually or when recipient country's legal framework changes └─ Report transfers to Information Regulator if required under prior authorisation ```