POPIA-compliant software development

The Protection of Personal Information Act, 2013 (POPIA) is South Africa’s data protection law. It became fully enforceable on 1 July 2021, it’s overseen by the Information Regulator, and it applies to almost any system that touches the personal information of people in South Africa — customer records, ID numbers, location data, payment details, health information, and more.

For a development team, POPIA is mostly a set of architectural and process decisions. Get them in early and compliance is close to free; bolt them on later and you’re retrofitting security, consent, and data-handling into a system that wasn’t designed for them.

The eight conditions, from a builder’s chair

POPIA sets out eight conditions for the lawful processing of personal information. Each one has direct implications for how a system is built:

• Accountability — someone (the responsible party) owns compliance. Your system should make it possible to demonstrate it.
• Processing limitation — collect data lawfully, minimally, and with consent or another lawful basis. Don’t capture fields “just in case.”
• Purpose specification — collect for a defined purpose and don’t keep data longer than needed. Build in retention and deletion.
• Further processing limitation — new uses of existing data must be compatible with the original purpose.
• Information quality — keep data accurate and up to date; give users a way to correct theirs.
• Openness — tell people what you collect and why (Section 18 notification, privacy notices).
• Security safeguards — Section 19: appropriate, reasonable technical and organisational measures. This is the heart of the developer’s job.
• Data subject participation — people can ask what you hold, and request correction or deletion. Your data model needs to support that.

Section 19: what “reasonable measures” means in code

POPIA doesn’t prescribe a specific technology stack. It asks for measures appropriate to the sensitivity of the data and the risk. In practice, that translates into concrete engineering:

• Role-based access control — people see only the data their job requires.
• Encryption in transit (TLS everywhere) and at rest for sensitive fields.
• Audit logging — who accessed or changed what, and when.
• Secure authentication, password handling, and session management.
• Secure development practices and dependency management to keep known vulnerabilities out.
• A tested backup and recovery strategy.

Breach notification (Section 22)

If personal information is accessed or acquired by an unauthorised person, POPIA requires you to notify the Information Regulator and the affected data subjects as soon as reasonably possible. That obligation only works if your system can detect a compromise in the first place — which is why audit logging and monitoring aren’t optional extras.

Cross-border data and residency (Section 72)

Section 72 restricts sending South African personal information outside the country unless specific conditions are met. The simplest way to avoid that whole class of question is to host the data in South Africa. Microsoft operates two Azure regions in the country — South Africa North (Johannesburg) and South Africa West (Cape Town) — so we can keep personal data resident locally while still using world-class infrastructure. It’s a point where our stack and your compliance line up neatly.

How we build POPIA in from day one

We treat POPIA as a design input, not a launch-day scramble. During discovery we map what personal information the system will hold, why, and for how long. We design the data model around minimisation, access control, and deletion. And we choose infrastructure — often a South African Azure region — that keeps residency simple. The result is a system that holds up to scrutiny because privacy was part of its architecture, not painted on afterwards.

Frequently asked questions