Data protection isn't an afterthought bolted onto a data warehouse — it has to be designed in from the start. Under South Africa's Protection of Personal Information Act (POPIA), any business processing personal information carries real, specific obligations, and a data warehouse is often where those obligations either get honored or quietly ignored.

What POPIA Actually Requires

POPIA is built around a set of core conditions for lawfully processing personal information. For a data warehouse specifically, the ones that matter most are knowing exactly what personal information you hold, why you're processing it, who can access it, and how long you're allowed to keep it. These aren't abstract legal requirements — they translate directly into technical decisions: what gets ingested, how it's tagged, who gets a login, and what your retention and deletion policy actually does in practice.

Data Minimization by Design

Data minimization is the starting point — only collecting and processing what's actually needed, not everything a source system happens to generate. It's tempting to ingest everything "just in case it's useful later," but every field of personal information you store is also a field you're now responsible for protecting, justifying and eventually deleting.

• Only ingest fields you have a defined, legitimate business reason to hold
• Mask or exclude personal identifiers in datasets that don't need them
• Review what's actually being used against what's actually being stored, periodically

Access Control at the Data Layer

Access control matters just as much as minimization. Not every person in a business needs to see every piece of data, and a well-designed warehouse enforces that at the data layer itself — through row-level security, role-based permissions and audit logging — not just through a policy document nobody reads. A document that says "only finance can see salary data" means nothing if the underlying system lets anyone with a login query the table directly.

Governance and Lineage: Trusting Your Numbers

Governance and lineage — knowing where every piece of data came from and how it's been transformed along the way — isn't just a compliance nice-to-have. It's what lets a business actually trust the numbers it's making decisions on, and it's what lets you answer a regulator's question about a specific data point without a week of forensic digging through spreadsheets and email threads.

Getting It Right From Day One

Retrofitting POPIA compliance onto an existing data warehouse is possible, but it's slower and more expensive than designing it in from the start. A properly architected data warehouse treats POPIA compliance as a natural byproduct of good design — minimization, access control and lineage aren't separate compliance tasks bolted on afterward, they're just what good data architecture already looks like.