POPIA, the Protection of Personal Information Act 4 of 2013, applies to almost every app a South African developer ships, because almost every app stores a name, an email address or a phone number. For developers it boils down to four things: only collect what you need for a stated purpose, secure it properly (section 19), know who else processes it for you (sections 20 and 21), and be ready to report a breach (section 22). This guide turns those legal duties into concrete engineering tasks.
Who is responsible - you or your client?
POPIA distinguishes between the responsible party (the person or organisation that decides why and how personal information is processed) and the operator (someone who processes it on the responsible party's behalf, under a contract, without coming under their direct authority).
- If you build and run your own SaaS product, your company is usually the responsible party.
- If you are an agency building an app for a client, the client is usually the responsible party and you may be an operator while you host or maintain it.
- Your hosting provider, email service and analytics tools are typically operators too.
Getting this right matters because it decides who must do what. The responsible party carries the core obligations; operators must treat the information as confidential and secure it (sections 20 and 21).
The eight conditions, translated into code
Section 4 lists eight conditions for lawful processing. Here is what each means in a codebase.
| Condition | Sections | What it means for developers |
|---|---|---|
| Accountability | 8 | Someone owns compliance. Document your data flows. |
| Processing limitation | 9-12 | Collect the minimum. Have a lawful basis (consent, contract, legal obligation, legitimate interest). |
| Purpose specification | 13-14 | Know why each field exists. Delete or de-identify it when no longer needed. |
| Further processing limitation | 15 | Don't reuse data for an unrelated purpose (for example, sign-up emails for marketing) without a basis. |
| Information quality | 16 | Let users correct their details. Validate input. |
| Openness | 17-18 | Tell users what you collect and why - a privacy notice at the point of collection. |
| Security safeguards | 19-22 | Appropriate technical and organisational measures, operator contracts, breach notification. |
| Data subject participation | 23-25 | Users can ask what you hold and request correction or deletion. |
Two extra rules catch developers out. Special personal information (sections 26-33) - religious beliefs, race, health, biometrics, criminal behaviour and more - generally may not be processed without a specific exemption such as explicit consent. Children's information (sections 34-35) needs the consent of a competent person, typically a parent. If your schema has a medical_aid_number or id_photo column, treat it with extra care.
Section 19 - security safeguards in practice
Section 19 requires a responsible party to secure the integrity and confidentiality of personal information by taking "appropriate, reasonable technical and organisational measures" to prevent loss, damage, unauthorised destruction and unlawful access. It also requires you to identify foreseeable risks, maintain safeguards, verify that they work and update them as risks change. The Act does not list specific controls, so "reasonable" is judged against generally accepted security practice.
A defensible baseline for a web app:
- Encryption in transit - HTTPS everywhere, HSTS, no mixed content. Free Let's Encrypt certificates make this easy.
- Encryption at rest for backups and especially sensitive columns (ID numbers, bank details).
- Strong authentication - hashed passwords (bcrypt, scrypt or Argon2), rate-limited logins, two-factor for admin accounts.
- Least privilege - separate database users for the app and for migrations; staff access by role.
- Secrets out of Git - environment variables, rotated when people leave.
- Patching - dependencies and runtimes kept current (
npm audit, Dependabot or similar). - Backups you have restored at least once.
- An incident process written down before you need it.
Our Node.js security checklist goes deeper on the application side.
Logs are personal information too
Developers often forget that logs contain personal information: IP addresses, email addresses in error messages, full request bodies, JWTs in headers. A few rules keep logs useful without turning them into a liability:
- Log identifiers (user ID) rather than names, emails or ID numbers.
- Redact sensitive fields before they reach the logger.
- Never log passwords, tokens, card data or one-time PINs.
- Set a retention period for logs and enforce it - section 14 applies to logs as much as to your main database.
A simple redaction helper in Node.js:
const SENSITIVE = new Set(['password', 'token', 'idNumber', 'email', 'phone', 'authorization']);
function redact(value) {
if (Array.isArray(value)) return value.map(redact);
if (value && typeof value === 'object') {
return Object.fromEntries(
Object.entries(value).map(([k, v]) => [k, SENSITIVE.has(k) ? '[redacted]' : redact(v)])
);
}
return value;
}
console.log(JSON.stringify(redact({ user: { email: '[email protected]', plan: 'starter' }, password: 'x' })));
// {"user":{"email":"[redacted]","plan":"starter"},"password":"[redacted]"}
Operators and section 21
Every third-party service that touches personal information on your behalf - hosting, email delivery, error tracking, analytics, AI APIs - is potentially an operator. Section 21 says the responsible party must ensure, through a written contract, that the operator establishes and maintains the security measures in section 19. The operator must also notify the responsible party immediately if it reasonably believes personal information has been accessed or acquired by an unauthorised person.
Practically, keep a list of every sub-processor, what data it receives and where its terms or data processing agreement live. If a service stores data outside South Africa, section 72 on transborder flows also applies - see POPIA section 72 and AI APIs.
Section 22 - breach notification
If there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person, section 22 requires the responsible party to notify the Information Regulator and the affected data subjects as soon as reasonably possible after discovery. A delay is allowed only for the legitimate needs of law enforcement or to determine the scope of the compromise and restore system integrity.
The notice to data subjects must be in writing and give enough information for them to protect themselves: the possible consequences, what you are doing about it, what they should do, and, if known, who accessed the information. The Regulator publishes the current reporting process and forms on inforegulator.org.za.
For developers, the job is to make breach response possible: audit logs showing who accessed what, the ability to identify affected users quickly, and a runbook that names who decides and who notifies.
Retention and deletion
Section 14 says records must not be kept longer than necessary for the purpose, subject to exceptions such as legal retention requirements (tax records, for example). Build this in:
- A scheduled job that purges or anonymises inactive accounts and old logs (see cron jobs for Node.js).
- A working "delete my account" flow that also removes data from search indexes and caches.
- A note on how long backups keep deleted data, and an honest statement of that in your privacy notice.
Frequently asked questions
Does POPIA apply to a small app or a side project?
If you process personal information in South Africa and you are not processing it purely for personal or household purposes, POPIA generally applies regardless of size. There is no small-business exemption in the Act.
Do I need to register an Information Officer?
Every responsible party has an Information Officer - by default the head of the organisation - and the Regulator has required registration of Information Officers. Check the Regulator's website for current requirements.
Is hashing an email address enough to make it non-personal?
Usually not. A hash of an email address can be linked back to the person by anyone who has the email list, so it is pseudonymised, not de-identified. Treat it as personal information.
What are the penalties for non-compliance?
The Act provides for administrative fines of up to R10 million and, for certain offences, imprisonment. Civil claims by data subjects are also possible. For your specific situation, get advice from a qualified privacy lawyer.
Does my hosting provider make me POPIA compliant?
No host can make you compliant on its own. A good host, acting as your operator, provides a secure platform and a clear agreement, but your app's design and processes are still your responsibility.
If you want a South African host that acts as your operator under a clear privacy policy, with encrypted environment variables, automatic backups and free SSL, see our Node.js hosting or compare plans.