Data protection isn't a checkbox: how we build POPIA-conscious software

If a system we build touches the personal information of South African users, POPIA applies — regardless of where it's hosted, and regardless of how small the client is. We don't treat this as a legal formality bolted on before launch. It shapes decisions we make from the first data model onward.

This isn't a legal opinion, and it isn't a substitute for your own compliance review — every business's obligations differ by what it collects and why. It's the set of engineering practices we build into every system by default, so compliance isn't something retrofitted under deadline pressure.

Encryption, by default, not by request

Every system we build encrypts data in transit and at rest as a baseline, not an upsell. TLS on every connection, encryption on stored data, and access secured behind proper authentication — the same standard whether the client is a bank or a five-person business running its first real admin system.

Confidentiality is the default posture

NDAs are standard on every engagement, not something we sign only when asked. Your business information — and your customers' information — stays inside the engagement. That extends to how we handle access during development: staging environments don't get populated with real customer data by default, and access to production data is limited to what a given task actually requires.

Backups and recovery, designed in from the start

A recovery plan that gets written after an incident is a postmortem, not a plan. We build backup and recovery into the architecture of every system from the outset — regular, tested backups and a documented path back to a working state, so "we lost the data" is never the answer to a bad afternoon.

Designed for South African data protection requirements

Concretely, this shows up in decisions like: minimising what personal information a system actually collects rather than gathering it "in case it's useful later," being deliberate about how long data is retained, and building the access and deletion pathways a data subject is entitled to request — rather than treating those as a feature to add once someone asks.

Why this is an engineering decision, not a legal afterthought

The systems that end up non-compliant aren't usually the ones where nobody cared. They're the ones where compliance was treated as documentation to produce after the software was already built — at which point half of what a real POPIA posture requires would mean re-architecting, not just writing a policy.

We'd rather have that conversation with you in the discovery phase, when it costs a design decision, than after launch, when it costs a migration. Talk to us if you want a second opinion on where your current system stands.