Compliance & security · 7 min read
POPIA compliance for software products: what a compliant build actually includes
Published 25 August 2026 · Updated 15 September 2026 · By Sam Fourie, Niddo
POPIA compliance is not a policy you publish after the build. It is a set of behaviours the software has to have: consent recorded when data is collected, encryption at rest and in transit, access limited by role, an audit trail that cannot be edited, export and deletion on request, retention rules, and a clear position on where data lives and which processors touch it. Plan them from the first migration, because retrofitting any of them costs more than building them in.
What POPIA asks of a product, in plain words
The Protection of Personal Information Act sets eight conditions for processing personal information. For a product they translate to: be accountable for the data you hold; collect only what you need, lawfully; say what it is for and stick to that; keep it accurate; be open about what you do with it; secure it; and let people see, correct and delete what you hold about them. Everything below is one of those conditions turned into software.
The build checklist
- Consent capture. Record what the person agreed to, which version of the wording, when, and from where, and keep that record append-only. Separate consents for cross-border storage and for identity checks where they apply.
- Data minimisation. Collect the fields the workflow needs and nothing speculative. Every extra field is a liability with no revenue attached.
- Access by role. Users see their own data and nothing else, enforced in the database (row-level security), not just in the interface. Staff see what their role needs.
- Encryption. In transit everywhere, at rest for stored data, and field-level for the most sensitive values such as ID numbers, with keys held in a managed key service.
- An audit trail. Who did what, when, to which record, written by the database on every change and impossible to edit or delete by the application.
- Data subject tooling. Export everything held about a person in a usable format, and delete on request, with a countdown and a clear record that the deletion happened.
- Retention rules. A written schedule for what is kept, for how long and why (tax records, consent artefacts, legal records), and an automated path that enforces it.
- Breach readiness. Monitoring and alerts so you know when something is wrong, and a written process for notifying the Regulator and the people affected.
- A processor register. Every third party that touches personal data (hosting, email, payments, identity checks, analytics), with agreements in place.
- Cross-border transfers. If any data leaves South Africa, section 72 applies: the recipient must offer comparable protection, or the person must consent. In-country hosting for personal data, with only encrypted objects abroad, keeps this simple.
What is not the developer's job
Registering an Information Officer, drafting the privacy policy and consent wording, the PAIA manual, and agreements with processors are legal and administrative work for you and your POPIA adviser. A good studio builds the behaviours above and surfaces the wording at the right points; it does not write your law.
What it looks like in a real build
For ARC Legacy, an encrypted digital vault, the compliance layer is the product: consent recorded at sign-up, documents encrypted in the application under per-vault keys held in a key service in Cape Town, the database in a South African region, an append-only audit log enforced by the database, data-subject export and deletion with a countdown, and a retention schedule that says what survives and why. None of it was added at the end.
What it costs
Building the checklist in from the start adds roughly fifteen to twenty-five percent to a comparable product without it, mostly in the data model, the audit log and the tooling. Retrofitting it later costs multiples of that, and a breach costs more than either. See what custom software costs in South Africa.
Building with Niddo
If your product holds personal or financial information, we scope the compliance layer with the rest of the build and price it as one figure. Tell us what you are building.
Questions
People also ask.
Does POPIA require data to stay in South Africa?
No. It allows transfers where the recipient offers comparable protection or the person has consented, with the details in section 72. Keeping personal data in a South African region and sending only encrypted objects abroad makes the position much easier to defend.
Do we need a cookie banner?
POPIA does not require one for strictly necessary cookies, and analytics should be disclosed in your privacy policy. If you also serve visitors in the EU or UK, their rules require consent for non-essential cookies, so a banner shown to those regions is the safe answer.
Is GDPR the same thing?
The principles are close and a build that meets the checklist above is most of the way to GDPR. If you serve EU users you need to meet both, with GDPR's additional rules on lawful bases, data protection impact assessments and breach timelines.
Do we need a penetration test?
For anything holding sensitive data, yes, by an independent firm before launch, and the build should be designed expecting it. Budget for it separately from the software.