Start with the actual flow
A cloud service can be configured in a South African region while support, analytics, backups or subprocessors operate elsewhere. The location selected during setup is therefore not a complete data-flow answer. Organisations need to understand who receives personal information, where processing occurs and which safeguards apply throughout the chain.
This article offers operational guidance, not legal advice. Obtain qualified advice for your circumstances.
Map the personal information from collection to deletion. Include production storage, backups, observability, support access, email delivery, identity services, analytics, disaster recovery and data exports. Record the countries involved and the legal entity receiving the information.
Do not rely only on an architecture diagram. Compare it with contracts, subprocessor lists, service settings and operational practice. A vendor may change subprocessors or support locations over time, so assign responsibility for monitoring changes.
Understand section 72
Section 72 of the Protection of Personal Information Act regulates transfers of personal information from South Africa to a third party in a foreign country. It provides several possible conditions, including adequate protection through law, binding corporate rules or a binding agreement, consent in applicable circumstances and necessity for specified contractual purposes.
The correct basis depends on the facts. Record the selected mechanism and supporting evidence rather than assuming a global provider makes the transfer acceptable. Consider onward transfer to additional recipients.
Clarify the parties
Identify the responsible party, operators and any further operators or subprocessors. Contracts should describe the processing purpose, security obligations, incident cooperation, deletion, audit evidence and restrictions on further use.
A supplier may use customer data to provide the service and seek separate rights to improve its products or train models. These purposes should not be blended into one vague clause. Confirm what is optional, how it is disabled and whether the setting applies to historical data.
Apply data minimisation
Reduce the personal information sent to the service. Remove fields that are not required, use pseudonymous identifiers where practical and keep sensitive values out of logs and support tickets. Define retention per data type instead of keeping everything indefinitely.
Access should follow role and purpose. Review privileged access, support access, multi-factor authentication and audit evidence. Encryption helps protect data, but key control, identity and export paths also matter.
Prepare for incidents and exit
Section 19 of POPIA requires reasonable technical and organisational measures to secure the integrity and confidentiality of personal information. Define how the supplier will notify and assist the organisation after a security compromise. Test whether the information needed for assessment and notification will be available.
Plan the end of the service. Confirm export format, deletion timelines, backup expiry and evidence of deletion. Understand which dependencies would make migration difficult. Exit planning is part of accountability, not a future procurement task.
Create a review record
For each material cloud service, keep a short decision record covering:
- processing purpose and data categories;
- data subjects and possible harm;
- recipients, countries and subprocessors;
- section 72 transfer basis and legal review;
- contractual and technical safeguards;
- retention, deletion and exit;
- incident responsibilities; and
- owner and next review date.
Review the record when the service, purpose, data or supplier chain changes.
A well-designed cloud decision makes the data path visible and keeps responsibility inside the organisation, even when processing is distributed.
Algoza can help map technical data flows, supplier dependencies and practical controls alongside your legal and privacy advisers.