POPIA in Production
Most organisations have a privacy policy. Far fewer can show the mechanism that keeps each promise in it, or the evidence that the mechanism ran. This six-part series is for the engineers, architects, data teams and managers who run the systems personal information flows through. It maps POPIA's eight conditions to controls and a control register, treats purpose and lawful basis as attributes a platform can check, builds retention as a deletion pipeline that reaches logs, backups and vector indexes, designs access and correction requests as a system capability, sets out an incident classification path agreed in advance, and ends with governance after an AI feature fails. It follows Amanzi Credit, a fictional Gqeberha store-card and personal-loan lender; its systems, incidents and figures are illustrative. The series is general information, not legal advice; section references and the Information Regulator's reporting route were checked on 31 October 2026.
6 articles
- Part 1A privacy policy is not a privacy controlMost South African organisations have a privacy policy. Far fewer can show the mechanism that keeps each promise in it, or the evidence that the mechanism ran. Part 1 of POPIA in Production maps the Act's eight conditions to controls and evidence, and introduces the control register.10 min read
- Part 2Lawful basis is a design input, not a legal footnoteWhether a new use of personal information is allowed is usually asked after the pipeline already exists. Part 2 of POPIA in Production treats purpose and lawful basis as attributes of the data, carried through every pipeline, and puts a further-processing gate in front of new uses, AI features included.9 min read
- Part 3Retention is a deletion pipeline, not a scheduleMost retention schedules are spreadsheets that nothing executes. Part 3 of POPIA in Production treats retention as a pipeline: a rule catalogue, triggers from systems of record, an executor for every store including vector indexes and traces, and a deletion record that proves it ran.8 min read
- Part 4An access request is a test of your whole systemWhen a customer asks what you hold about them, the answer depends on whether you can find one person across every system, including the scores, segments and AI summaries you generated. Part 4 of POPIA in Production treats access and correction requests as an engineering capability, not a desk procedure.8 min read
- Part 5Classify the incident before you argue about itWhen something goes wrong with personal information, teams lose hours arguing about whether it counts as a breach. Part 5 of POPIA in Production turns sections 19, 21 and 22 and the Information Regulator's guidance into a classification path agreed in advance, so the day itself is spent on facts.8 min read
- Part 6Governance after an AI failureAn AI feature put one customer's details into another customer's summary. What happens next decides whether the organisation learns anything. Part 6 of POPIA in Production sets out the governance sequence after an AI failure: contain, classify, reconstruct, fix the control rather than the person, and re-enable on evidence.8 min read
Working through any of this in your own organisation?
These articles come out of delivery work rather than theory. If the problems in this series look familiar, a short scoping conversation is usually the quickest way to work out what is worth doing first.
Talk to CloudNala